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

[Kuhn Nicolas <[e-mail]>]

Hi,

This email concerns the RTO consider draft (v07). Thanks for this interesting document.
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).

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.

This process
    of ensuring reliability via time-based loss detection and resending
    lost data is commonly referred to as a "retransmission timeout
    (RTO)" mechanism.

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.
Then a discussion in the requirements should precise how these time-based loss recovery mechanisms should/could interoperate.

Cheers,

Nico