Re: [tcpm] TCP window max size?

[David Borman <[e-mail]>]

On Aug 24, 2010, at 4:22 PM, David Borman wrote:

> This reasoning is explained in RFC 1323, section 2.3, at the bottom of
> page 10 and the top of page 11:
> 
>    TCP determines if a data segment is "old" or "new" by testing
>    whether its sequence number is within 2**31 bytes of the left edge
>    of the window, and if it is not, discarding the data as "old".  To
>    insure that new data is never mistakenly considered old and vice-
>    versa, the left edge of the sender's window has to be at most
>    2**31 away from the right edge of the receiver's window.
>    Similarly with the sender's right edge and receiver's left edge.
>    Since the right and left edges of either the sender's or
>    receiver's window differ by the window size, and since the sender
>    and receiver windows can be out of phase by at most the window
>    size, the above constraints imply that 2 * the max window size
>    must be less than 2**31, or
> 
>         max window < 2**30
> 
>    Since the max window is 2**S (where S is the scaling shift count)
>    times at most 2**16 - 1 (the maximum unscaled window), the maximum
>    window is guaranteed to be < 2*30 if S <= 14.  Thus, the shift
>    count must be limited to 14 (which allows windows of 2**30 = 1
>    Gbyte)...

And what I forgot to ask was whether you or someone else disagreed with
this logic, but this is why it is 14.  However, even if the logic is
faulty, the max value will remain at 14, the only way to change it would
be via a new TCP option number.

But mostly the place for trouble is at the boundary conditions, and if
you had a 2^31 window and the sender/receiver windows were fully skewed,
any outstanding packet from before left edge of the senders window could
show up at the receiver and be viewed as new data at the right edge of
the receivers window, which would be a bad thing.

1) Sender has a full 2^31 window of unacknowledged data,
   receiver is a full 2^31 ahead of the sender.
2) Sender retransmits a packet at left edge of it's window.
3) In-transit Ack from Receiver arrives, acks all data, and
   advances window by 2^31.
4) Sender sends a new packet.
5) New packet gets reordered in transit with the retransmitted packet.
6) New packet arrives, and receiver advances window.
7) Retransmitted packet arrives, and it now appears to be at the
   right edge of the receivers window as new data.

A 2^14 max window keeps things well away from those boundary conditions.


> 
> 			-David Borman
> 
> On Aug 24, 2010, at 9:30 AM, Vinicius Romão wrote:
> 
>> Hi Fellows.
>> 
>> (Apologies if this is not the correct forum to this e-mail, but the tcplw WG
>> and list are already concluded.)
>> 
>> The RFC-1323 specifies the TCP Window Scale Option. It states that the
>> maximum window size is 2^30 (1Gbyte), please see the last paragraph in the
>> page 10. It limits the shift.count <= 14, this way the requirement above is
>> guaranteed. Note that the maximum window size is one-quarter of the TCP
>> sequence number space (2^32 = 4Gbyte).
>> 
>> However the references below indicate that a Sliding Window protocol works
>> properly if the maximum window size is at most half of the sequence number
>> space available. The key is insure that once the receiver advances its
>> window, the new range of valid sequence numbers does not overlap with the
>> old one.
>> 
>> In this case the maximum window size of TCP could be 2Gbyte instead of
>> 1Gbyte. Even with a window length of 2Gbyte it does not seem possible to
>> duplicate sequence numbers in the same window by overlap or segment/ack
>> losses. Duplicates are still possible due earlier packet incarnations,
>> however they must be handled by the Maximum Segment Lifetime or PAWS
>> extension.
>> 
>> I would be grateful it someone could explain me or recommend a reference to
>> understand the reason why the TCP window max size is limited to 1Gbyte
>> (2^30) instead 2Gb(2^31).
>> 
>> Thank you for any help you can provide.
>> 
>>        Vinicius M. Romao
>> 
>> 
>> References:
>> 1 - Tanenbaum, Andrew. Computer Networks. 4Ed. Prentice Hall Pub, 2002.
>> Section: 3.4.3 A Protocol Using Selective Repeat.
>> 
>> 2 - Peterson, Larry, and Davie, Bruce. Computer networks: A Systems
>> Approach. 3Ed. Boston: Morgan Kaufmann Pub, 2003. 104-105. Section: 2.5.2
>> Sliding Window.
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm