Re: Window Scale option

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

The autotuning work by PSC might take care of some of the problems with
buffer space being tied up unnecessarily:

ftp://ftp.psc.edu/pub/networking/papers/autotune_sigcomm98.ps

>I expect the main problem is reliable transmission of the R value in
>ACK segments.

Why not just send it with every segment?  The space isn't really a
problem -- we're typically burning 12 octets for the timestamp options
as it is, in order to get nice alignment.  We could define a new 11
octet timestamp/window scale option that would fold in both values, and
would fit into the same 12 octet space.

It shouldn't really require (much?) more CPU than the normal window shift
that we're going to have to perform anyway -- we're just grabbing the
value to use from the TCP options, rather than the tcpcb...

Kevin