In message <200003011939.OAA11193@lawyers.lerc.nasa.gov>Mark Allman writes
>
>> Changing timestamps and window scaling on the fly would be great!
>
>Just to clarify...  Is it really the window scaling?
>
>My hit is that window scaling is fine.  Just set the default to
>something big.  The problem with the current approach is that
>turning on window scaling means you need to turn on timestamps
>immediatly.  I would rather turn on timestamps (or another such
>mechanism) when we need them for PAWS.  

Admittedly, window scaling isn't that big a deal.  My take on it
is that, since we can change the granularity of the window size from
1 to 16384, it'd be nice to be able to tweak that granularity on
the fly.  The current autotuning code uses a fixed scaling factor
of some relatively small value, like 4, I think.  That allows a maximum
window of 1MB.

That's all good, but I could eventually imagine a system that was
running connections to little wireless doowahs that had windows of
1KB, and also LFN connections that might require multiple megabytes
worth of window scaling.  That scale factor might eventually
become important.

>Would you have window scaling itself be enabled in the middle of a
>connection?  I see that as ugly, I think.

Right, you'd have to send the window scaling factor along with every
segment, you couldn't just change it once, as there would be ordering
problems.

It'd be easy to do if you are sending timestamps already -- most
implementations burn an extra two bytes of NOPs that could be instead
used to send the scaling factor along with timestamps in a new option
type.  

Of course, if we're talking about toggling timestamps on and
off, on-the-fly window scaling suddenly doesn't look as attractive.  
In fact, it seems like burning a three bytes for damn little benefit.

Kevin
kml@logictier.com