|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Satellite latency
On Tue, Mar 05, 2002 at 09:38:42AM -0500, Richard A Steenbergen wrote: > > You should also beware of turning up TCP window settings to whatever big > number you feel like. I can only vouch for unix systems here, but the way > the socket interface and kernel tcp works requires a buffer which is big > enough to hold all data in flight be maintained in the kernel for every > connection. This data cannot be released until it has been ACK'd (incase > TCP needs to retransmitit), which is generally the limiting factor of TCP > window sizes. > > Say for example you turn up your socket buffers to 1MB, and enable your > RFC1323 extensions (window scaling is the one you care about, it's > basically just adding a multiplier value so you can get bigger values then > 65535). While this does let you to keep a whole lot of data in-flight, it > also makes your system quite unstable. Consider the case where you are > transfering a large file to a slow host: you will immediately fill the 1MB > kernel buffer (the write() on the socket goes into that first, also the > userland program has no way of knowing if that is a fast host or a big > kernel buffer and will misreport speed). Open a few more connections like > that and you've exausted your kernel memory and most likely will have a > panic. If you did these settings on a web server, all it would take is a > few dialups trying to download a big file before you go boom. Since this buffer is determined by the receive window (and thus by the receiving system), I don't see why it matters. Most receivers will be using OS defaults, and the ones who adjust their receive window size up are probably doing so because they have a fast enough link to warrant it. I can't see where a dialup user would find any cause to give himself a huge receive window. -c
|