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

[Kuhn Nicolas <[e-mail]>]

Hi, 

Sorry if my previous message was not clear. 
Trying to make it clearer below. 

Cheers,

Nico

-----Message d'origine-----
De : Mark Allman <[e-mail]> 
Envoyé : lundi 11 février 2019 18:37
À : Kuhn Nicolas <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : Re: [draft-ietf-tcpm-rto-consider-07] Interaction with other time-based recovery schemes?


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

[NK] IMHO, if this is meant to be an umbrella under which timer-based retransmission live, this should be stated more clearly in the draft. Otherwise, this can lead to confusion. The hierarchical view of timer that you mentioned here could be clearly stated in the document. Or you could try to harmonize it with the "PTO" notion in QUIC https://tools.ietf.org/html/draft-ietf-quic-recovery-18#section-6.2.2 

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

[NK] RACK was just an example of another timer that may trigger a timer-based retransmission before an actual TCP-RTO. Thus, the scope of this draft was not clear to me at this point. 

> Moreover, there is not one only timer-based retransmission in 
> Google-QUIC [
> https://datatracker.ietf.org/meeting/103/materials/slides-103-tcpm-ses
> sb-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?  

[NK] This is the case when RACK and RTO are used conjointly in TCP. 

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.

[NK] This was my main point indeed. At the moment, at TCP and Google-QUIC level, we have RTO and RACK - which seem to have been unified under the "PTO" to avoid confusion.  

allman