Re: [tcpm] Extending RFC 1323 window scaling?

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm