Subject: Re: [tcpm] TCP window max size?

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 06 Oct 2010 11:54:53 +0200

Hi David,

we had recently also a discussion here in our group about
max window size. What I understand form your example that
a size of 2^31 is not possible since your example stated that it 
would fail. But in theory (regardless the scaling factor) what
is the maximal possible window size so that everything would go ok?
(2^31)-1?

Another question that comes in my mind: TCP says sequence number
x < y <=> 0 < y-x < 2^31. Why do we say here 2^31 and not for example
2^32-20?

Alex

Am 25.08.2010 um 00:07 schrieb David Borman:

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

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: Vinicius Romão <[email-masked]>
Date: Thu, 7 Oct 2010 02:16:46 -0300

Alexander,

   Despite I'm not an expert, I commented the second question:

2010/10/6 Alexander Zimmermann <[email-masked]>

> x < y <=> 0 < y-x < 2^31. Why do we say here 2^31 and not for example

 The TCP uses 2's complement arithmetic to verify if a number y is greater
than x. This way, y must be at most 2^31 away from x to be considered a new
data, otherwise it will be considered older (duplicated).

The 2's complement (Modular Arithmetic) is used to handle the wrap around
problem of a finite sequence number space (32 bits).

You can find a good explanation in the section 24.7 TCP Sequence Numbers
from Stevens, W., and Gary Wright. *TCP/IP Illustrated, Vol. 2: The
Implementation*. Addison-Wesley Pub. Co, 1994.