Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01

["Scheffenegger, Richard" <[e-mail]>]

Hi Anna,

>> As Yuchung points out, removing this would reduce the complexity of the
>> algorithm. If spurious retransmits are a problem, and they often are, the
>> stack requires some other way of dealing with those anyway, because
>> "fixing" only rto-restart won't address all the other (currently
>> happening) instances of spurious rtos...
>>
> 
> This is not only about spurious RTOs, it is also about how you recover
> lost packets. You don't want an RTO for that if a fast retransmit can be
> done.

But how do you positively know in advance, if a fast retransmit can be done? Looking at cwnd alone is not sufficient, as you also need a model of the receiver (delayed ACK - phase and frequency) and return path (ACK loss, delay)... Just because there may exist a chance to do fast retransmits doesn't imply that fast retransmits will be the most timely loss recovery...
 
> Also for spurious RTOs, TS isn't always used, and anyway all mechanisms
> for spurious timeout detection detect and repair the problem *after* it
> happened ... this is better than nothing, but it's even better to keep the
> spurious timeout from happening in the first place. It is a simple check,
> so I think that one line of code is worthwhile.


Again, without precognition on the sender side, you'll always need some reactive mechanisms; trying to be proactive alone will not always help...

Overall, I think making rto-restart dependent on cwnd should be optional, not necessarily normative. Implementers who have repair mechanisms after spurious RTOs happened may choose to implement a more simple rto restart; or they may choose to make a better model to trigger RTO (ie. improving the timeout calculation utilizing additional information ) 

Richard Scheffenegger