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

From: Mark Allman <[email-masked]>
Date: Fri, 06 Apr 2007 17:16:24 -0400

>   (1) The semantics of the SEG.WND field in the TCP header could be
>       changed, i. e., the receive window is scaled in <SYN,ACK>
>       segments under some constraints. Whether or not the receive
>       window is scaled could be announced explicitly by a flag, or
>       implicitly, e. g., due to the presence of Quick-Start options or
>       other options. However, changing the semantics of the receive
>       window header field creates interoperation issues with hosts
>       that do not implement such a modification.
> 
>   (2) The true amount of free buffer space is announced somehow, and
>       overwrites the (unscaled) value in the TCP header, which remains
>       unscaled in order to be compatible with hosts that do not
>       implement this mechanism. This requires some new mechanism to
>       signal a scaled receive window in <SYN,ACK> segments.
> 
> The proposed new TCP option is a straightforward realization of
> approach (2).

I am not sure if we need a (2).  As you note, Quick-Start is currently
the only thing that really runs into a problem and maybe something else
could.  To be precise, I think we can say that the only place where this
is a problem is when the initiator of a connection wants to (and can)
send more than 64KB in the first RTT of the connection.  Unless we
pretty drastically change the rules it seems that this is going to have
to be done only with some explicit communication and so using that as an
implicit signal seems fine to me.  (We clearly botched this in terms of
Quick-Start because we were too dumb to think of it and you found it
after publication.)  Further, it is not clear that we need to add new
functionality like this for something experimental (Quick-Start).  But,
maybe ...

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.

allman

---

From: David Borman <[email-masked]>
Date: Mon, 30 Apr 2007 13:16:57 -0500

(Catching up on some old email...)

> unscaled and so less than it really is and so there is no danger in

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.

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.

			-David Borman
>
> allman
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm