[45961] in North American Network Operators' Group
Re: Satellite latency
daemon@ATHENA.MIT.EDU (Clayton Fiske)
Tue Mar 5 18:53:47 2002
Date: Tue, 5 Mar 2002 15:52:31 -0800
From: Clayton Fiske <clay@bloomcounty.org>
To: nanog@merit.edu
Message-ID: <20020305155231.F59327@bloomcounty.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20020305143842.GQ413@overlord.e-gerbil.net>; from ras@e-gerbil.net on Tue, Mar 05, 2002 at 09:38:42AM -0500
Errors-To: owner-nanog-outgoing@merit.edu
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
