Subject: Re: Window Scale option

From: [email-masked]
Date: Mon, 4 May 1998 13:39:30 -0700

Dave,

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
wonder if it's too late to do that, or whether it has to await a
"second generation TCP".  I recall that Van believed that the window
scale ought to be determined in the Syn exchange, but I don't recall
his argument for it.

I expect the main problem is reliable transmission of the R value in
ACK segments.  I can imagine something like this: Once the 3 way
handshake has negotiated scaling, any data/ACK packet can carry
ScaleOption(S,R).  If I want to change my R to R', I start sending a
receive window with the R' scaling, together with ScaleOption(S,R').
Once the other side echos R' in its ScaleOption(R',S), I can stop
sending the option.  This is obviously more complicated than the
current window scaling scheme, but it would at least support what
applications really want.

I suppose I should have reviewed the TCPLW archives before sending this
message...

Bob Braden

---

From: "Kevin M. Lahey" <[email-masked]>
Date: Mon, 04 May 1998 14:34:50 -0700

In message <[email-masked]>[email-masked] writes
>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

>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

---

From: Matt Mathis <[email-masked]>
Date: 05 May 1998 14:53:46 -0400

The SYN only restriction is far more problematic for the timestamp
option than it is for than the window scale option.

For example, if you have a laptop with a radio modem and a 100bT
interface, you are likely to find that you are either wasting the
skinny link with uncompressible timestamps, or underfilling the LAN
because you didn't negotiate timestamps.  Although you could implement
per-route or per-interface flags to control TCPLW features, the real
problem is the pervasive 1323 mindset that new options must never
appear after the SYN-ACK.

If this mindset is relaxed, I believe it is a 1 line code change to
allow timestamps to be turned on at any point.  Thus all TCP
connections could start without timestamps, and once they enter a
regime where timestamps help (due to either PAWS or RTTM) timestamps
could be turned on.

Unfortunately, RFC1323 is structured such that relaxing this
specification requires almost a complete rewrite.  I tried it at one
point, and had to abandon the project.

Is this worth revisiting?

About window scale option:

The cost of negotiating an excessive window shift is very small - it
increases the quantization in the flow control for applications which
are receiver limited.  This might be an issue to an application that
*depends* on being able to advance (or control) the window in tiny
increments, but I know of none.

In our autotuning TCP the window shift defaults to the smallest value
needed to support the largest socket buffer allowed on the system.
(As specified by sb_max on most systems).  The actual receiver window
can then default to some small value, to be updated by the application
or other mechanisms as needed.  See
ftp://ftp.psc.edu/pub/networking/papers/autotune_sigcomm98.ps

Thanks,
--MM--