Subject: [tcpm] Barry Leiba's No Objection on draft-ietf-tcpm-rto-consider-16: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 08 Jul 2020 19:58:02 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-tcpm-rto-consider-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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