Subject: [Tsvwg] Re: [tcpm] Extending RFC 1323 window scaling?

From: Michael Scharf <[email-masked]>
Date: Mon, 7 May 2007 09:41:27 +0200

On Mon, 30 Apr 2007 at 13:16:57, David Borman wrote:
> 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?)  That would mean that Quick-start wouldn't  
> be able to fully act just on the SYN,ACK, but should immediately get  
> the window update with the right value, without having to wait for a  
> full RTT.  The only down-side would be if the two packets got re- 
> ordered, and the ACK with the window update arrived before the  
> SYN,ACK.  In that case, the window update would be (and should be)  
> dropped, because at a minimum, the scale factor that should be  
> applied to it would be unknown (it's in the SYN,ACK).  So, a TCP  
> implementation might need to still send out another window update  
> when it got back the ACK completing the 3-way handshake, just to be  
> sure that the window update got through.

Sending an additional ACK back-to-back with the <SYN,ACK> is, of
course, the obvious solution, and it has also been noticed that the
robustness of this mechanism can be increased by sending more than one
ACK. However, it must be emphasized that sending one (or several)
additional 40 byte-ACKs is a little bit efficient, in order to
transmit an information equivalent to 1 bit (window scaled or not
scaled).

BTW: At least the Linux 2.6.x TCP stack needs some minor modifications
in order to correctly process additional ACKs with receive window
updates within or immediately after the 3-way handshake. Thus, if the
TCP stack needs to be changed anyway to allow a scaled window, one
could also think of implementing some new TCP option.

Michael

---

From: Mark Allman <[email-masked]>
Date: Thu, 10 May 2007 14:47:05 -0400

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

> 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