Requirements for Time-Based Loss Detection
draft-ietf-tcpm-rto-consider-17

I note the shepherd and GenART review comments about the requirements language at the end of Section 2, and I don't find it to be problematic generally given this passed WGLC in multiple working groups (a wise move, by the way) and a proper IETF Last Call.

These triple hyphens throughout the document are supposed to be em dashes, I presume?

** What’s “network safety” in the context of this document?  How do I know I have it?  IMO, precision is needed since there is normative language around assuring it; and it likely has a different connotation when used in the security operations setting.

** References supporting the following claims/observations would be helpful:

-- Section 1.  Per “… we leverage the conservative notion that loss is an implicit indication of congestion .. it has historically served us well.”

-- Section 1.  Per “At this point, our experience leads to a recognition that often specific tweaks that deviate from standardized time-based loss detectors do not materially impact network safety with respect to congestion control.”

** Section 3.  S.1 and S.2.  The text would benefit from a more precise definition of primary and last resort timers as these are scoping the document

** Section 6.  I might mention that one of the applications of loss measurements in the network is in DoS detection.

Thank you for the work put into this document. 

Please address the minor points of the IoT directorate review by Wesley Eddy (in cc): 
https://mailarchive.ietf.org/arch/msg/iot-directorate/KGPrkW0KJeW__Bf8gWaOXk0d4FY

-éric

I agree with Ben that the use of "we" and "our" is a little jarring and the document would be improved if those instances could be changed.

— Section 1 —

    Given that packet loss is routine in best effort networks, loss
    detection is a crucial activity for many protocols and applications
    and is generally undertaken for two major reasons:

The “given that” doesn’t seem the right introduction to the rest of the sentence.  Do you mean, maybe, “Even though”?  And “best-effort” should be hyphenated.

            and is overwhelming some portion of the network path.  Data
            senders can therefore use loss to trigger transmission rate
            reductions.

Or other congestion-avoidance mechanisms, no?  For example, real-time applications such as media streaming might reduce the load by changing the tradeoff between quality and data size/bandwidth usage.

    Many protocols and applications use their own time-based loss
    detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP
    [RFC3261]).

Nit: this reads as if it’s saying that TCP, SCTP, and SIP are loss detection mechanisms.  The examples should be more closely attached to what they’re examples of (protocols and applications).  I suggest this:

NEW
    Many protocols and applications, such as TCP [RFC6298],
    SCTP [RFC4960], and SIP [RFC3261], use their own time-based
    loss detection mechanisms.
END

— Section 2 —

    requirements document---because we had no idea how to write such a
    document!

You might note the comment at the bottom of this page:
   https://en.m.wikipedia.org/wiki/Talk:Exclamation_mark#Multiple_exclamation_marks!!!

— Section 4 —

        Often measuring the time required for delivery confirmation is
        is framed as assessing the "round-trip time (RTT)" of the
        network path as this is the minimum amount of time required to
        receive delivery confirmation and also often follows protocol
        behavior whereby acknowledgments are generated quickly after
        data arrives.

This is an awkward sentence with at least two errors in it (a missing comma and a duplicate word).  The awkwardness makes the antecedent to “this” in the following sentence unclear.  I suggest rewording this sentence, perhaps as two sentences.  I’ll also note that the antecedent to “this” two sentences down (“However, this is somewhat mis-leading”) is completely missing, so please have a fresh look at the whole paragraph.

        (a) If/when available, the RTO SHOULD be set based on multiple
            observations of the FT. 

If/when *what* is available?  Do you mean, “Whenever possible”?

            Some protocols use non-data exchanges for various
            reasons---e.g., keepalives, heartbeats, control messages.

Again, the examples are detached from what they’re examples of, so it looks as if they are examples of reasons, rather than of non-data exchanges.  Please re-order the sentence.

— Section 5 —

    mechanisms for many years seemingly without large scale problems

Nit: hyphenate “large-scale”.  Also in the last sentence of the same paragraph.

    Further, a number of implementations use a steady-state minimum RTO
    that are less than the 1 second specified

Nit: make it “that is less” to match the singular subject.

Thank you for the updates; they seem to address the core topics I raised and found
the appropriate places to do so (even when I did not) -- I may have to reference this
document when giving authors an example of the degree of interpretation available
to them when responding to IESG (or, really, any) comments.

Having said that, "a healthy amount of randomness" is perhaps not very clear guidance
in terms of how much is "healthy", but I recognize the goal of not being overly prescriptive,
and am reluctant to suggest additional changes.

Thank you for this document.  I have no significant comments, just a few nits:

1   Introduction

    This document provides guidelines for developing an understanding of
    one path property: loss
    
Recommend: "loss" -> "packet loss"

    (S.1) The requirements in this document apply only to the primary or
          last resort time-based loss detection.
          
    (S.2) The requirements for time-based loss detection mechanisms in
          this document are for the primary or "last resort" loss
          detection mechanism whether the mechanism is the sole loss
          repair strategy or works in concert with other mechanisms.

I found the wording for these two requirements to be repetitive, possibly could be reworded and combined.


      
4   Requirements      

    (1) As we note above, loss detection happens when a sender does not
        receive delivery confirmation within an some expected period of
        time.
        
Nit: Delete "an" or "some"

        Often measuring the time required for delivery confirmation is
        is framed
        
Nit: "is is" -> "is"

Regards,
Rob