Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice

[Mark Allman <[e-mail]>]

I just want to quickly correct one thing here ...

> [the draft] then recommends a minimum RTO of one second

(a) It DOES NOT say this at all.  The document does not specify ANY
    minimum RTO.  The document does says this:

        In the absence of any knowledge about the latency of a path,
        the initial RTO MUST be conservatively set to no less than 1
        second.

    But, as soon as there is some notion (e.g., a RTT measurement)
    then there is knowledge and this no longer applies.  I.e., this
    is for the startup case where we are beginning transmission into
    an unknown network path.

(b) If this is too hefty for some application, that's fine.  Do what
    we do now and get consensus to use something different.  Again,
    the document says:

        The correct way to view this document is as the default
        case.

        [...]

        The requirements in this document may not be appropriate in
        all cases and, therefore, inconsistent deviations may be
        necessary (hence the "SHOULD" in the last bullet).  However,
        inconsistencies MUST be (a) explained and (b) gather
        consensus.

    In other words, the worst case is the current case.

I am not entirely sure I understand the remaining points in the
review as it's pretty rambling to me.  Certainly we use heartbeats
(in things like SCTP) and control packets (think TCP zero window
probes or keep-alives).  The document is very simply saying that if
these are used in some fashion we can also use them to measure FT
information.  That seems pretty reasonable to me and I can't figure
out what your complaint about that is.  Perhaps you could try again
so my pea brain can understand the complaint?

Thanks!

allman