Re: Satellite latency

[Clayton Fiske <clay () bloomcounty org>]

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