[tcpm] F-RTO and RFC 3517 interaction issues

[Murari Sridharan <muraris at microsoft.com>]

I am seeing an inconsistency between FRTO and RFC 3517. May be the authors could clarify.

 

F-RTO defines recovery as follows

 

Set variable "recover" to

      indicate the highest segment transmitted so far.

 

RFC 3517 defines

"HighData" is the highest sequence number transmitted at a given

      point.

 

RFC 3517 clearly mandates that if RTO occurs during loss recovery new recovery phase MUST not be initiated until the RecoveryPoint is crossed.

“If an RTO occurs during loss recovery as specified in this document,

   RecoveryPoint MUST be set to HighData.  Further, the new value of

   RecoveryPoint MUST be preserved and the loss recovery algorithm

   outlined in this document MUST be terminated.  In addition, a new

   recovery phase (as described in section 5) MUST NOT be initiated

   until HighACK is greater than or equal to the new value of

   RecoveryPoint.”

Now FRTO spec seems to violate the above rule with the following statement

If the algorithm exits with

   SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus

   allowing fast recovery on incoming duplicate acknowledgments.

This means that if we are in the middle of loss recovery and a real timeout occurs we save the recovery point per RFC 3517. At this point we continue with slow start and congestion avoidance, now say we are still below the earlier recovery point and a new timeout occurs. This time if the timeout is classified as SPUR_TO, then RecoveryPoint is set to SndUNA, overwriting the older value and a new recovery phase can begin, clearly violating RFC 3517. 

Thanks

Murari 

_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm