Subject: Re: Send window update algorithm ...

From: Kacheong Poon <[email-masked]>
Date: Thu, 29 Jun 2000 01:28:22 -0700 (PDT)

> In fact, during my testing, I ran exactly into case 3 mentioned above.
> Instead of using the window information from a retransmission by the
> peer which ACKed new data that we sent and which made the window 0, we
> ignored the SEG.WND information (as SEG.SEQ < SND.WL1) and continued to
> think that we had a non-zero window and tried to send another segment.

In the case described by Ramesh, if he follows 4.2.2.16 of RFC 1122, then
the worst case is that TCP sends some segments which are not accepted by
the other end, because the window update in the retransmitted segment is
not accepted.  Can it be treated as a "shrinking" window case?  TCP can
handle shrinked window, right?

It seems to me that there can be quite a few corner cases when the current
check can fail.  The problem is that window updates do not have sequence
number.  I think this means that whatever we check, there can be cases when
the check fails.  The question is if we can catch the majority of cases so
that TCP works well.  And for those cases when the check fails, TCP should
still work, as in the case Ramesh described.

> Probably, correct approach prioritizes ACK and SEQ updates
> in backward order, so that check should look like:
> 
> if (SEG.ACK > SND.UNA ||
>     (SEG.ACK == SND.UNA &&
>      (SEG.SEQ > SND.WL || (SEG.SEQ == SND.WL && SEG.WIN > SND.WND)))) {
> 	SND.WND = SEG.WND;
> 	SND.WL = SEG.WL;
> }

Isn't the first check above equal to the sentence on page 72 of RFC 793 below?

	If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
	updated.  

It is interesting that no implementation I know of has this simple check?  
There must be a reason...  IMHO, the above check seems to work.

							K. Poon.
							[email-masked]

---

From: [email-masked]
Date: Thu, 29 Jun 2000 23:03:53 +0400 (MSK DST)

Hello!

> 	If SND.UNA < SEG.ACK =< SND.NXT, the send window should be

This is mipsrint in RFC, fixed in RFC1122. 4.2.2.10g. The first < reads as <=.

In the pseudo-code above, the first line is required to eliminate
case of SEG.ACK==SND.UNA. The second line is redundant, indeed.

Alexey

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 29 Jun 2000 12:30:22 -0700 (PDT)

> This is mipsrint in RFC, fixed in RFC1122. 4.2.2.10g. The first < reads as

It seems to me that RFC 1122's correction (4.2.2.20g) is not correct in the
window update part.  It is correct in the part dealing with duplicate ACK. 
The send window should not be updated unconditionally when SND.UNA == SEG.ACK.
No implementation does that anyway.  I think the original check in RFC 793 
above is correct.  So no need to be corrected C:

Alexey, can you send your suggested check to end2end list to see if people
see any problem in that?  Thanks.

							K. Poon.
							[email-masked]