Re: [tcpm] 1323bis - PAWS check's problem with reodering on the reverse path

[David Borman <[e-mail]>]

I've been thinking about this recently, and I think that while it may  
be a real issue, it's not one that we need to worry about.  I believe  
that the problem that the change fixes is a more likely scenario, so  
if you have to choose between the two, that's the one to pick.

Also, for this issue that Alexander brings up, the timestamp has to be  
changing between ACKs.  If the timestamp hasn't changed between the re- 
ordered ACKs, then the "SEG.TSval >= TS.recent" check will succeed.   
Generally, the TS clock shouldn't be ticking that often, if it is  
changing with every ACK then it might be going faster than it needs to.

So, this issue only occurs when ACKs are re-ordered, *and* the  
Timestamp clock has ticked between the reordered ACKs.  I'm thinking  
that 1323bis should just note that this situation does exist.

What does everyone else think?  Shall we leave the text as is and just  
document this edge case, or do people disagree with me and feel that  
this is a real problem that needs to be addressed, and is more  
important than the problems that the original change fixes?

			-David

On Mar 26, 2009, at 6:10 PM, Alexander Zimmermann wrote:

> Hi David, hi TCPM Folks,
>
> in the 1323bis draft the PAWS check has a problem (discarding ACKs)  
> if reordering is present on the
> reverse path and no data is piggybacked. Actually, it's not the PAWS  
> check itself, it's the modification
> of section 3.4: "Which Timestamp to Echo".
>
> The important parts of the RFC1323 and the draft (in this order) are
>
> ---
> (2) If Last.ACK.sent falls within the range of sequence numbers
>      of an incoming segment:
>
>         SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN
>
>      then the TSval from the segment is copied to TS.Recent;
>      otherwise, the TSval is ignored.
>
> ---
>
> (2) If:
>
>       SEG.TSval >= TS.recent and SEG.SEQ <= Last.ACK.sent
>
>       then SEG.TSval is copied to TS.Recent; otherwise, it is
>       ignored.
> ---
>
> The addition of "SEG.TSval >= TS.recent" is not important for us at  
> moment. As the appendix said,
> this check is included for consistency with the PAWS test only.
>
> The relevant paragraph is the change from "SEG.SEQ <= Last.ACK.sent  
> < SEG.SEQ + SEG.LEN" to the
> reduced form "SEG.SEQ <= Last.ACK.sent". Again, the appendix said  
> that this change was made
> since the original algorithm to control which timestamp is echoed  
> was incorrect in two regards:
>
> (1) It failed to update TSrecent for a retransmitted segment that  
> resulted from a lost ACK.
>
> (2) It failed if SEG.LEN = 0.
>
> It's right that the 1323bis algo fix these two problems, however,  
> it's introduced the new problem mentioned
> already above.
>
> Following situation:
> - One-way flow from TCP A to TCP B
> - Reordering on the reverse path
>
> Consequence
> - TCP A will discard all ACKs with were delayed
> - Harmful in the case ABC (RFC 3465) is off, since we count ACKs for  
> slow-start and congestion avoidance
>
> Examples are attached.
>
> Alex
>
> <PAWS 1323.txt><PAWS 1323bis.txt>
> //
> // Dipl.-Inform. Alexander Zimmermann
> // Department of Computer Science, Informatik 4
> // RWTH Aachen University
> // Ahornstr. 55, 52056 Aachen, Germany
> // phone: [phone], fax: [phone]
> // email: [e-mail]
> // web: http://www.umic-mesh.net
> //
>