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

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

Hi Per,

>> (i) Should we have a section in the draft describing a socket option?
>
> What're the useful cases in your mind?

I don't think that a granularity on a per-session level would really do any good; having a global sysctl (or similar) to influence the overall behavior of the stack is fine. But from a troubleshooting point of view, I doubt that such a fine level of control will do any good.

>> (ii) Should we apply RTO restart for all segments or only when the
>> amount of outstanding data is too small to support fast retransmit?
>
> Part of these compilation comes from resetting cwnd on timeout. It's like
> a time-ticking bomb for TCP performance. Consider the case where the
> entire cwnd is delivered except the last one. There is no point to re-
> slow-start to restore the ack clock, because you already have
> cwnd-1 acks last round.
> 
> I plan to implement rto-restart idea in Linux as base of a new loss
> recovery, but probably not the cwnd checking part. When an RTO fires it's
> time to retransmit. The need to check cwnd implies my timer is
> problematic.

Provided that you have other means (ie TS) to detect if the ACK was due to an spurious retransmit (RTO) or genuinely needed, I'm not sure if that complexity of checking the currently outstanding segments really is needed.

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



Seasons greetings,


Richard Scheffenegger