Re: [tcpm] Extending RFC 1323 window scaling?

[David Borman <[e-mail]>]

(Catching up on some old email...)

On Apr 6, 2007, at 4:16 PM, Mark Allman wrote:

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

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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm