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

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 11 Feb 2019 16:23:53 +0000

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

---

From: "Mark Allman" <[email-masked]>
Date: Mon, 11 Feb 2019 12:37:11 -0500

> 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

---

From: Kuhn Nicolas <[email-masked]>
Date: Tue, 12 Feb 2019 09:05:29 +0000

Hi, 

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

Cheers,

Nico

-----Message d'origine-----
De : Mark Allman <[email-masked]> 
Envoyé : lundi 11 février 2019 18:37
À : Kuhn Nicolas <[email-masked]>
Cc : [email-masked]; [email-masked]
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. 

> 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

---

From: "Mark Allman" <[email-masked]>
Date: Tue, 12 Feb 2019 09:05:42 -0500

Hi Nico!

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

Can you give me suggestions?  I just re-read sections 1 & 2 and I'm
not sure I have better words in my head.  E.g., do you find the last
paragraph of the new context section unclear?

> 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

(I don't follow this.  I don't think I sketched a "hierarchical
view".  So, I am confused.)

> [...]
> [NK] This was my main point indeed.

So, does all this boil down to you want another example under S.6
that says (essentially) "multiple retransmission timers could be in
play"?  I.e., something analogous to the notion that is in there now
that "there may be timers and ACKs/SACKs in play" but explicitly
noting it could be more than one timer?  That sounds like a fine and
reasonable idea to me.  But, I am unclear on whether this covers
your entire comment or not.

Thanks!

allman

---

From: Kuhn Nicolas <[email-masked]>
Date: Wed, 13 Feb 2019 17:02:00 +0000

Hi, 

I think that most of the confusion came for the usage of "RTO" while the draft actually covers is more generic than TCP-RTO. A change in the name or a disclaimer at the beginning of the draft could help. 
An example of clarification could be: 
" This process
    of ensuring reliability via time-based loss detection and resending
    lost data is commonly referred to as a "retransmission timeout
    (RTO)" mechanism."
" This process
    of ensuring reliability via time-based loss detection and resending
    lost data can be referred to as a "retransmission timeout
    (RTO)" mechanism.

    Disclaimer: protocols may currently use a time-based retransmission
    mechanisms called RTO and other time-based retransmission
    mechanisms. For the sake of genericity, this draft considers RTO as any
    time-based loss detection and resending lost data mechanism.
"

I have added some more comments inline.

Hope this helps,
Cheers,

Nico

-----Message d'origine-----
Envoyé : mardi 12 février 2019 15:06

Hi Nico!

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

Can you give me suggestions?  I just re-read sections 1 & 2 and I'm not sure I have better words in my head.  E.g., do you find the last paragraph of the new context section unclear?

[NK] The last paragraph of section 2 indeed somehow covers what I was meaning. I now see it more clearly but some rewording may be relevant. I would propose to rephrase the beginning as follows :
"  However, adding a requirements umbrella to a body of existing
    specific retransmission timer specifications is inherently messy and
    we run the risk of creating "inconsistencies".  The correct way to
    view this document is as the default case and these other
    specifications as agreed upon deviations from the default."
" Existing protocols may exploit multiple specific retransmission timers 
   and there may be inconsistencies between the recommendation of this
   draft and the actual use of timers for retransmissions. As example, this 
   document assesses retransmission timeouts in general, while TCP may 
   exploit RACK and RTO for a timer-based reliability. The correct way to
   view this document is as a general protocol-agnostic case."
 
> 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

(I don't follow this.  I don't think I sketched a "hierarchical view".  So, I am confused.)

> [NK] This was my main point indeed.

So, does all this boil down to you want another example under S.6 that says (essentially) "multiple retransmission timers could be in play"?  I.e., something analogous to the notion that is in there now that "there may be timers and ACKs/SACKs in play" but explicitly noting it could be more than one timer?  That sounds like a fine and reasonable idea to me.  But, I am unclear on whether this covers your entire comment or not.
[NK] I think that with a disclaimer at the beginning of the document, things are clearer. 

Thanks!

allman

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 21 Feb 2019 16:01:13 -0500

> I think that most of the confusion came for the usage of "RTO"
> while the draft actually covers is more generic than TCP-RTO. A
> change in the name or a disclaimer at the beginning of the draft
> could help.

OK.  I thought this was pretty clear, but I added some words to the
second paragraph sort of along the line of your suggestion.  I now
have this as the beginning of the second paragraph.  The second
sentence is new.  See what you think ...

    Various protocols have defined their own RTO mechanisms (e.g., TCP
    [RFC6298], SCTP [RFC4960], SIP [RFC3261]).  In this document, our
    use of "RTO" does not refer to any one specific scheme, but rather
    is a generic term that includes all timer-based retransmission
    mechanisms.  The specifics of retransmission timeouts often
    represent a particular tradeoff between correctness and
    responsiveness [AP99].

> [NK] The last paragraph of section 2 indeed somehow covers what I
> was meaning. I now see it more clearly but some rewording may be
> relevant. I would propose to rephrase the beginning as follows :

These words I am less happy with.  I think the suggested words
exclude the meaning of the original words.  And, this is more detail
about multiple timers than I really think is useful in setting the
context.

That said, I get the multiple timer scenario that you've brought up
and think it'd be good to specifically call that out.  I added the
following to the S.6 note in the draft.

          E.g., some protocols may leverage more than one retransmission
          timer simultaneously.  In these cases, the general guidance in
          this document can be applied to all such timers.

Please send along further thoughts.  Many thanks!

allman