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

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 4 Mar 2019 14:56:44 +0000

Thanks for the update that covers my comments. 

Cheers,

Nico

-----Message d'origine-----
De : Mark Allman <[email-masked]> 
Envoyé : jeudi 21 février 2019 22:01
À : 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 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 :
> "  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."

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