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