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

[Alexander Zimmermann <[e-mail]>]

Hi David,

comments are inline.


Am 14.07.2009 um 01:12 schrieb David Borman:

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

Sure. As you mentioned offline last time after the meeting the new  
version
of the alg. is version that most OS implement. I fully agree with you  
that we
should adopt the updated version.

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

However, *if* reordering is present in the network the case that I  
mentioned
is not so unlikely. We saw the phenomenon during some measurements/ 
dumps...

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

Definitely.
I know that for example Linux implement also an heuristic to detect  
reordered ACK.
Maybe we can put a point to that.

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

Alex

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