Subject: [tcpm] TCP Reassembly: Advertising TCP rcv window

From: "Vishal Study" <[email-masked]>
Date: Sat, 24 Mar 2007 04:30:35 -0700

Hi:

If a host has out of sequence packets in its RX_Q, how does it
advertise its rcv_window?
Is it supposed to consider out of sequence pkts and advertise only the
"real" available space.

For e.g.
RX_Q size: 10,000 bytes
Out of sequence pkts: From seqnum 100 to 400 and then 500 to 100000

Should the host advertise rcv_window of 200 or 0?

Thanks,
Vishal.

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

---

From: "Agarwal Anurag-A20729" <[email-masked]>
Date: Sun, 25 Mar 2007 00:15:42 +0800

The missing seq. nos. should be in-flight on the network. Now assuming
that no ACK has 
been generated by the receiver as yet, the sender has utlized the adv.
window fully. So 
I think receiver should advertize a window of size 0.

Regards,
Anurag

-----Original Message-----
From: Vishal Study [mailto:[email-masked]] 
Sent: Saturday, March 24, 2007 5:01 PM
To: [email-masked]
Subject: [tcpm] TCP Reassembly: Advertising TCP rcv window

Hi:

If a host has out of sequence packets in its RX_Q, how does it advertise
its rcv_window?
Is it supposed to consider out of sequence pkts and advertise only the
"real" available space.

For e.g.
RX_Q size: 10,000 bytes

Thanks,
Vishal.

---

From: "Vishal Study" <[email-masked]>
Date: Sat, 24 Mar 2007 10:33:31 -0700

What happens if the missing seq nos were dropped by the network?

Can the sender still reTransmit the dropped pkts given that the
rcv_window has become 0 now.

Am I missing something?

Thanks,
Vishal.

---

From: "Agarwal Anurag-A20729" <[email-masked]>
Date: Sun, 25 Mar 2007 04:08:58 +0800

Receive Window dropping to zero limits the sender from sending fresh
data.
It wouldn't limit retransmissions.

Retransmissions are for 'in-window' data which receiver should always be
ready to accept.
If the receiver already received that data and it is a spurious
retransmission it shall be simply acknowledged.
Else if it didn't already arrive at the receiver, there would be a
missing sequence and hence memory space to handle
this retransmitted missing sequence in the receiver.

Best Regards,
Anurag

-----Original Message-----
From: Vishal Study [mailto:[email-masked]] 
Sent: Saturday, March 24, 2007 11:04 PM
To: Agarwal Anurag-A20729
Cc: [email-masked]
Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window

Am I missing something?

Thanks,
Vishal.

> that no ACK has been generated by the receiver as yet, the sender has 
> utlized the adv.
> window fully. So

---

From: "Vishal Study" <[email-masked]>
Date: Sat, 24 Mar 2007 15:38:55 -0700

Hi:

Does ir mean that a sender can (or should) reTx data even if
receiver's rcv_win is 0.

thanks,
Vishal.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Mar 2007 21:01:38 -0300

>Does ir mean that a sender can (or should) reTx data even if

No. Out-of-order data is not considered in the advertised window.

(The advertised window is the amount of data that TCP is willing to 
accept starting from the sequence number contained in the 
Acknowlegement field of the same segment.)

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Vishal Study" <[email-masked]>
Date: Sun, 25 Mar 2007 01:30:05 -0700

Hi Fernando:

I guess you meant "Yes" below...i.e. if out of order data is not
considered in adv window, sender can reTx data even if receiver's
rcv_window is 0.

Is that correct?

Thanks,
Vishal.

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Sun, 25 Mar 2007 12:35:39 -0700

> sender can reTx data even if receiver's rcv_window is 0.
> 
> Is that correct?

Nope.

If the receiver's receive window becomes zero, the sender goes to
persist state which means the only thing it can send are zero window
probes, until atleast a +ve window advertisement occurs. 

So the basic TCP flow control rule applies : sender cannot (re)-transmit
data when receiver's rcv_win becomes 0. 

-Anantha

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Mar 2007 07:44:32 -0300

>considered in adv window, sender can reTx data even if receiver's

The out of order data do not affect the advertised window. If some 
data were lost then, unless the TCP receiver has shrunk its receive 
window, the advertised window will not be zero.

---

From: David Borman <[email-masked]>
Date: Mon, 26 Mar 2007 09:19:17 -0500

Vishal,

The advertised window is an offset relative to the ACK field.  When  
the receiver gets out of order data, it has to buffer that data until  
the missing segment arrives, and will continue to send an ACK with  
the same sequence number of the last in-order data that was  
received.  The out-of-order data is considered part of the window.   
If the receiver continues to put in the same value for the window,  
the right edge of the window will not advance since the ACK is not  
advancing.  Fernando is wrong below, the out of order data is, and  
must be, within the receivers advertised window, or it would be  
dropped by the receiver.

Retracting the window, e.g. by decreasing the window field and not  
advancing the ACK, is strongly discouraged.  See RFC 1122, section  
4.2.2.16.  If the ACK field isn't moving, the window field should not  
be decreasing.  The only way that the window field should ever go to  
zero is by the ACK field increasing, and the window field decreasing  
by the same amount, leaving the right edge of the window fixed; when  
the ACK reaches the right edge of the window, the window field in the  
packet will then be zero.

In summary, the window field communicates how much data the receiver  
is willing to receive relative to the ACK field, so adding the window  
to the ACK field gives the right edged of the window, or the largest  
sequence number that the receiver is willing to receiveAll data,  
whether in order or out of order, must be within the window (i.e,  
between the last ACK and ACK + window), or it will be dropped by the  
receiver.

			-David Borman