Re: Window Scale option

[David Borman <[e-mail]>]

> Subject: Re: Window Scale option 
> Date: Mon, 04 May 1998 14:34:50 -0700
> From: "Kevin M. Lahey" <[e-mail]>
>
> In message <[e-mail]>[e-mail] writes
> >Hmmmm.  It seems clear in retrospect that a host really wants to allow
> >its applications to dynamically adjust the amount of receive buffering
> >they can have, and thereby possibly adjust the window scaling.
>
> I'd certainly like to see this happen dynamically -- I often wind up
> with windows on my HIPPI LAN that are either way too small or way too
> large.  Just specifying a large value is problematic, as it will wind
> up, as Dave Borman points out, in burning buffer for small, slow

I don't think I quite said that, but that is true. :-)

> links.   In the BSD stack, it is possible to associate socket buffer
> sizes with routes, so this can take care of some of the problem.

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.

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...

I guess what I'm really saying is that if you have a user interface
to TCP to allow the application to specify the window scale value
without having to set the buffer size, and the server turns around
the window scale value, then you can make TCP connections that are
ready to use large buffers if the application wants them, without
having to pre-allocate any extra buffer space on either the client
or the server (and thus have an initial large window).  But typically
the client will know whether or not large buffers are wanted, so
having it set a large receive buffer, and having the server turn around
the scale option (without changing the buffer size) is usually sufficient.

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).

		-David Borman, [e-mail]