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

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

> 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