Re: [tcpm] [draft-ietf-tcpm-rto-consider-07] Interaction with other time-based recovery schemes?

["Mark Allman" <[e-mail]>]

> I just have some concerns about the interactions between this
> document and other time-based retransmissions schemes that could
> be more aggressive than the RTO (e.g. RACK).

I don't really follow this.  What do you mean "other"?  This is
meant to be an umbrella under which timer-based retransmission
schemes live.

> As an example of source of confusion, the description of the
> process (see below) should be clearer otherwise RACK falls into
> the scope of RTO.

The details of RACK are not in my head at the moment.  But, my
general model of it is that it provides per-packet retransmission
timers that are consistent with the requirements listed in
rto-consider.  (E.g., the timeout period is based on measurements,
those measurement shouldn't be ambiguous, etc.).  Is there something
specific to RACK's mechanism that is at odds with rto-consider?

> Moreover, there is not one only timer-based retransmission in
> Google-QUIC [
> https://datatracker.ietf.org/meeting/103/materials/slides-103-tcpm-sessb-quic-loss-detection-congestion-control-01
> ] (slide 17).  IMHO, a "Best Current Practice" should consider
> that, or add an element in the scope (S6) about other loss repair
> mechanisms that could be time-based.

I don't follow this either.  Are you saying that a particular
protocol could be using multiple time-based schemes to ensure
reliability?  And, you would like to see a note to that effect in
S.6 (where we note that other reliability schemes could be in play)?
If that is the point, sure, I buy that.

allman