Subject: [tcpm] TCP window max size?

From: Vinicius Romão <[email-masked]>
Date: Tue, 24 Aug 2010 11:30:40 -0300

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.

---

From: David Borman <[email-masked]>
Date: Tue, 24 Aug 2010 16:22:23 -0500

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

			-David Borman

On Aug 24, 2010, at 9:30 AM, Vinicius Romão wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: David Borman <[email-masked]>
Date: Tue, 24 Aug 2010 17:07:47 -0500

>    count must be limited to 14 (which allows windows of 2**30 = 1

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.

---

From: Vinicius Romão <[email-masked]>
Date: Tue, 24 Aug 2010 23:44:48 -0300

Borman,

Thank you very much for your clarifications.

After reading your explanation, I agree that 1Gbyte is the best choice to
the TCP window max size.

Thanks.

Vinicius M. Romao

2010/8/24 David Borman <[email-masked]>