Re: Window Scale option

[Matt Mathis <[e-mail]>]

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