Re: Window Scale option

["Kevin M. Lahey" <[e-mail]>]

In message <[e-mail]>David Borman writes
>A couple of points.  First, you don't have to have large buffers
>to use the window scale option.  In reality, what the window scale
>option does is change the granularity of the window updates.  As long
>as that granularity is smaller than your threshhold for silly window
>syndrom avoidance, things will work just fine.  A window shift of 4
>allows a megabyte of window, with a window update granularity of 16
>bytes, which is well below any SWS threshhold value.  So, using
>typical 8K buffers, you can use window scale values of at least
>5 or 6 without having any impact on performance.

I guess I agree.  My only thought is that if we have window scales
of up to 11 (1 GB/sec over 100ms link = 27 bits worth of window)
we could get into a situation in which the scaling would be over the
top.  Obviously, hosts behind slow links that use small windows
could decide not to echo back the value, or could echo back a
smaller value.  It isn't clear to me that this is a real big problem.
I just like the idea of dynamically changing the value, so perhaps
I've got a hammer looking for a pretty rare nail...

>So, if bulk-data transfer clients send a window shift option, and
>the server automatically turns it around, it shouldn't cause any
>problems on the server.  In BSD/OS I turn around the window scale,
>but I limit it to no more than 4 (changable by sysctl) to keep us from
>getting into trouble if we receive a window scale of 13 or 14 and our
>receive buffer is only 8K...

Sounds great to me.  I think that this'll help out enormously as
more and more people try to deal with LFNs...

>The only reason you don't want to always send a window scale option
>of at least 3 or 4 in the SYN is to avoid possible interoperability
>problems with older TCPs that don't properly ignore unknown TCP
>options, especially if there is no way that the application will ever
>be able to take advantage of it (i.e, it doesn't have a lot of data
>to transfer).

Heck, since we're supposed to send the option even when we set the 
shift value to 0, we might as well start to default to setting the 
value to 3 or 4.  I'm up for it!

Kevin
[e-mail]