Re: [tcpm] Extending RFC 1323 window scaling?

> (Catching up on some old email...)

likewise

> > If I were going to take approach (2) I would suggest a two-byte option
> > that indicates the value in the standard TCP header is to be scaled.
> > Why add another 2 byte window value when one of them is going to be
> > ignored?  This fails safe because if a host doesn't understand the new
> > ("the window is scaled") option it will think the advertised window is
> > unscaled and so less than it really is and so there is no danger in
> > running into problems.
> 
> I'm not sure I agree.  Yes, it's safe in that if you treat a scaled
> window as unscaled, you will not send more data than they are
> willing  to receive.  But if the shift value is large enough, and
> the initial  window small enough, you can get a tiny initial window.
> E.g., an  extreme case, if your initial window is 256K, but you have
> a shift  value of 14, that'll become a window of 16 bytes, not
> enough to send  much of anything until you get a window update.

Ah - good point.  So, perhaps the rule would then be if you were going
to send such a "scale this window, please" option then you could make
your window size suitable for both cases.  I.e., the actual value in the
window size would be at least 4380 bytes (current allowed upper bound on
the initial cwnd).

But, perhaps that is getting too complicated to save two bytes.  And,
like my original note said, I am not sure I eve think such an option is
needed.

> An alternate way of dealing with this situation where the initial
> window exceeds 64K would be to immediately follow the SYN,ACK with a
> window update; send the two packets out back-to-back.  (Has this
> already been mentioned?)  

Yep - that has been mentioned.  I think that is a fine way to do this.  

I also think that we could make the rule that if QS and WS options are
present then that means the SYN+ACK has a scaled window.  (I.e., this is
only a problem for things like QS that need a bigger advertised window
*right away* and to support QS is going to take changes on the receiver
anyway so let's just make it part of such proposals.)

allman