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

[Ballot comment]
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.

[Ballot comment]
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

[Ballot 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.

[Ballot comment]
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.

[Ballot comment]
** 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.

[Ballot discuss]
If we are providing BCP-level requirements for time-based loss detection
via absence of protocol-level acknowledgment, for new protocols, it
seems appropriate to mandate that the acknowledgment signal is reliable,
i.e., not spoofable by at least an off-path attacker, and ideally not
spoofable by an on-path attacker either.  I would love for this to be a
cryptographically protected mechanism, but expect that I can't get away
with mandating something that strong, and that something with "enough
bits of entropy" will suffice.  (I'd prefer "enough" to be 128 but could
perhaps be persuaded that a lower value is appropriate as a minimum
requirement.)

Point S.3 in Section 3 indicates that "[t]he requirements in this
document apply only to endpoint-to- endpoint unicast communication.
Reliable multicast (e.g., [RFC5740]) protocols are explicitly outside
the scope of this document."  This limitation of scope should be
reflected in the document's title, Abstract, and Introduction.

I would also like to get an explicit confirmation that the various
(non-)requirements on the details of exponential backoff and reduced
weighting for old FT samples are as-intended (see COMMENT).
Specifically, are there limitations on the base of the exponent for the
exponential backoff, and is there a requirement to give more recent FT
samples more precedence than older FT samples when computing an RTO
estimate?

[Ballot comment]
As a general note, the style of this document is somewhat divergent from
what I understand to be "modern RFC style".  While there's not a strict
requirement to adhere to such a common style, and I do not have specific
suggestions for changes, it did seem noteworthy.

Abstract

    of congestion along a network path).  While many mechanisms have
    been designed to detect loss, protocols ultimately can only count on
    the passage of time without delivery confirmation to declare a
    packet "lost".  Each implementation of a time-based loss detection

I'm not entirely convinced that the literal meaning of what these words
say is universally true for all protocols (specifically "can only count
on" and omitting a qualifier such as "many" or "most" protocols or
"reliably count on").  Consider, for example, the DTN bundle protocol,
which has some circumstances in which a given store-and-forward node
will flat-out not attempt to forward a protocol onward to its final
recipient, but can send back a status report to the sender noting the
confirmed lack of delivery.  I suggest adding some form of qualifier to
admit the possibility of such unusual situations.

Section 1

    missing.  However, despite our best intentions and most robust
    mechanisms we cannot place ultimate faith in receiving such
    acknowledgments, but can only truly depend on the passage of time.
    Therefore, our ultimate backstop to ensuring that we detect all loss
    is a timeout.  [...]

Despite the superficial similarity of tone, a strict reading of these
words does not seem to share the issue I raised about the Abstract.
(That said, this phrasing still seems a bit overblown and my personal
preference would be to tone it down some.)

Section 2

      - This document does not update or obsolete any existing RFC.
        These previous specifications---while generally consistent with
        the requirements in this document---reflect community consensus
        and this document does not change that consensus.

      - The requirements in this document are meant to provide for
        network safety and, as such, SHOULD be used by all time-based
        loss detection mechanisms.

I'm not sure that I understand how the combinations of these two
statements apply to existing specifications.  Is there some sense that
existing specs might leave some flexibility and when there is such
flexibility, implementations/deployments SHOULD use the flexibility to
match this document as closely as possible?  Or are existing deployments
and implementations of existing RFCs also grandfathered out?  If the
intent of the second bullet is to only apply to new protocols, please
say so explicitly.  (Section 4 seems to imply the "only new protocols"
case, but it's hard to be sure.)

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

Similarly, is this statement only forward-looking?  Presumably the first
bullet ("does not update or obsolete any existing") trumps this one, but
it's good to be clear.

Additionally, I share the GenART reviewer's unease with this strong of a
requirement and have low confidence that the IETF will reliably adhere
to it in the future.

nit(?): "inconsistent deviations" may be redundant?

Section 3

    (S.1) The requirements in this document apply only to the primary or
          last resort time-based loss detection.

I'm not sure I understand what "primary or last resort [sic]" means.
Are there time-based loss-detection mechanisms that are neither primary
nor last resort?  (nit: hyphenate "last-resort" as a compound adjective,
and many other compound adjectives throughout.)
(May also affect S.2.)
I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary
non-last-resort schemes, however, I think we should be more clear about
what we mean when we introduce the term and why we exclude certain
classes of time-based loss-detection mechanisms.

          detectors.  However, these mechanisms do not obviate the need
          for a "retransmission timeout" or "RTO" because---as we
          discuss in Section 1---only the passage of time can ultimately
          be relied upon to detect loss.  In cases such as these, the

[This text is more like the Abstract's, implying that the passage of
time is the only way to detect loss, universally]

Section 4

            In other words, the RTO should represent an empirically-
            derived reasonable amount of time that the sender should
            wait for delivery confirmation before deciding the given
            data is lost.  Network paths are inherently dynamic and
            therefore it is crucial to incorporate multiple FT samples
            in the RTO to take into account the delay variation across
            time.

It feels weird to say that the delay will vary over time here but say
nothing about the corresponding need to discount very old FT samples.
Point (b) talks about adding new samples in, but not about removing or
discounting old samples.  That the TCP example does exhibit this
property does not excuse a lack of explicit mention as a property of
note.

        (d) An RTO mechanism MUST NOT use ambiguous FT samples.

            Assume two copies of some segment X are transmitted at times
            t0 and t1 and then at time t2 the sender receives
            confirmation that X in fact arrived.  In some cases, it is

"segment" feels like use of TCP-specific terminology without disclaimer
or generalization.

            There are cases where two copies of some data are
            transmitted in a way whereby the sender can tell which is
            being acknowledged by an incoming ACK.  E.g., TCP's
            timestamp option [RFC7323] allows for segments to be
            uniquely identified and hence avoid the ambiguity.  In such
            cases there is no ambiguity and the resulting samples can
            update the RTO.

Perhaps note that QUIC was designed from the start to avoid the
ambiguity about retransmitted segments?

    (3) Loss detected by the RTO mechanism MUST be taken as an
        indication of network congestion and the sending rate adapted
        using a standard mechanism (e.g., TCP collapses the congestion
        window to one segment [RFC5681]).
        [...]
        An exception to this rule is if an IETF standardized mechanism
        determines that a particular loss is due to a non-congestion
        event (e.g., packet corruption).  In such a case a congestion

If it's a MUST with an exception, doesn't that make it ... no longer a
MUST?

    (4) Each time the RTO is used to detect a loss, the value of the RTO
        MUST be exponentially backed off such that the next firing
        requires a longer interval.  [...]

Do we expect this to be exponential backoff by doubling, or is it
admissible to use an alternative base for the exponent?  (Is there a
minimum allowable value?  E.g., 1.000001 does not seem like it would
provide much protection for the network.)

        As with guideline (3), an exception to this rule exists if an
        IETF standardized mechanism determines that a particular loss is
        not due to congestion.

(Same as above.)

Section 5

    Also, note, that in addition to the experiments discussed in [AP99],

nit: s/note, that/note that,/

    Further, a number of implementations use a steady-state minimum RTO
    that are less than the 1 second specified in [RFC6298] (which is
    different from the initial RTO we specify in Section 4, Requirement
    1).  While the implication of these deviations from the standard may

Just to check: our requirement 1 is the same as RFC 6298, and the "less
than 1 second" is what's different.  Perhaps wording this akin to "and
as such is in violation of the RTO specified in Requirement 1 from
Section 4" would avoid the ambiguity about what is different from what.

    Finally, we note that while allowing implementations to be more
    aggressive could in fact increase the number of needless
    retransmissions the above requirements fail safe in that they insist

nit: I suggest a comma after "needless retransmissions"

Section 6

Noting that we incorporate the security considerations of RFC 6298 by
reference, and quoting from there:

  In addition, even if the attacker can cause the sender's RTO to reach
  too small a value, it appears the attacker cannot leverage this into
  much of an attack (compared to the other damage they can do if they
  can spoof packets belonging to the connection), since the sending TCP
  will still back off its timer in the face of an incorrectly
  transmitted packet's loss due to actual congestion.

Just to check my understanding: this "actual congestion" would need to
be between the sender and the attacker, right?  Since the attacker's
spoofed ACKs would cause the sender to not detect loss due to congestion
that occurs between the attacker and the intended recipient.

References

The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]")
implies that it should be categorized as normative.  Similarly for RFC
6298 itself.

    [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC
        2134, June 2001.

Fix the typo, please -- RFC 2134 is the articles of incorporation of
ISOC.

[Ballot comment]
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

[Ballot comment]
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?

1. Summary

The document shepherd is Yoshifumi Nishida
The responsible Area Director is Martin Duke

This document provides high-level guidance to design the primary or last resort time-based
loss detection schemes for general use on the Internet, which can be applied to not only TCP,
but also other transport protocols and applications that need their own loss detection mechanisms.
The WG requests to publish this draft as Best Current Practice document because it describes
generic principles to update existing loss detection algorithms or to develop new ones.

2. Review and Consensus

The draft was originally written for TCP and hence presented and adopted at TCPM WG.
As the discussions on the draft proceeded, the focus of the draft has been extended to other
transport and application protocols because the same principle can be applied to them.
Because of this updates, we have decided to run WGLC for this draft on both TSVWG and TCPM WG
while we still have used TCPM WG as the venue for the discussions.

The draft has been reviewed and discussed by various participants in the WG for long time.
Most of discussion points were the choice of exact wordings in order not to create any
contradictions to other documents.
In addition, we have assigned two experts to get specific feedback from the viewpoint of
non-TCP protocols such as QUIC. The WGLC on both WG ended successfully without any major issues.
I believe there is a strong consensus in both WGs for publication.

During ART reviews, there were some discussions on the scope and the applicability of the document.
The main point of discussions was how we can apply this document to the cases where we have
some knowledge about the network. The document has been updated several times in order to
address the points raised during the discussions, however, complete agreements have not been archived.
We decided to leave the final decision to IESG with regard to this.

3. Intellectual Property

Each author has confirmed that their direct, personal knowledge of any
IPR related to this document has already been disclosed.
None of the authors is aware of any IPR related to this document.

4. Other Points

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tcpm-rto-consider-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-06-01):

From: The IESG
To: IETF-Announce
CC: nsd.ietf@gmail.com, Yoshifumi Nishida , tcpm-chairs@ietf.org, tcpm@ietf.org, martin.h.duke@gmail.com, draft-ietf-tcpm-rto-consider@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice


The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'Requirements for Time-Based
Loss Detection'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-06-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


    Many protocols must detect packet loss for various reasons (e.g., to
    ensure reliability using retransmissions or to understand the level
    of congestion along a network path).  While many mechanisms have
    been designed to detect loss, protocols ultimately can only count on
    the passage of time without delivery confirmation to declare a
    packet "lost".  Each implementation of a time-based loss detection
    mechanism represents a balance between correctness and timeliness
    and therefore no implementation suits all situations.  This document
    provides high-level requirements for time-based loss detectors
    appropriate for general use in the Internet.  Within the
    requirements, implementations have latitude to define particulars
    that best address each situation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/



No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Yoshifumi Nishida
The responsible Area Director is Martin Duke

This document provides high-level guidance to design the primary or last resort time-based
loss detection schemes for general use on the Internet, which can be applied to not only TCP,
but also other transport protocols and applications that need their own loss detection mechanisms.
The WG requests to publish this draft as Best Current Practice document because it describes
generic principles to update existing loss detection algorithms or to develop new ones.

2. Review and Consensus

The draft was originally written for TCP and hence presented and adopted at TCPM WG.
As the discussions on the draft proceeded, the focus of the draft has been extended to other
transport and application protocols because the same principle can be applied to them.
Because of this updates, we have decided to run WGLC for this draft on both TSVWG and TCPM WG
while we still have used TCPM WG as the venue for the discussions.

The draft has been reviewed and discussed by various participants in the WG for long time.
Most of discussion points were the choice of exact wordings in order not to create any
contradictions to other documents.
In addition, we have assigned two experts to get specific feedback from the viewpoint of
non-TCP protocols such as QUIC. The WGLC on both WG ended successfully without any major issues.
I believe there is a strong consensus in both WGs for publication.

3. Intellectual Property

Each author has confirmed that their direct, personal knowledge of any
IPR related to this document has already been disclosed.
None of the authors is aware of any IPR related to this document.

4. Other Points

1. Summary

The document shepherd is Yoshifumi Nishida
The responsible Area Director is Martin Duke

This document provides high-level guidance to design the primary or last resort time-based
loss detection schemes for general use on the Internet, which can be applied to not only TCP,
but also other transport protocols and applications that need their own loss detection mechanisms.
The WG requests to publish this draft as Best Current Practice document because it describes
generic principles to update existing loss detection algorithms or to develop new ones.

2. Review and Consensus

The draft was originally written for TCP and hence presented and adopted at TCPM WG.
As the discussions on the draft proceeded, the focus of the draft has been extended to other
transport and application protocols because the same principle can be applied to them.
Because of this updates, we have decided to run WGLC for this draft on both TSVWG and TCPM WG
while we still have used TCPM WG as the venue for the discussions.

The draft has been reviewed and discussed by various participants in the WG for long time.
Most of discussion points were the choice of exact wordings in order not to create any
contradictions to other documents.
In addition, we have assigned two experts to get specific feedback from the viewpoint of
non-TCP protocols such as QUIC. The WGLC on both WG ended successfully without any major issues.
I believe there is a strong consensus in both WGs for publication.

3. Intellectual Property

Each author has confirmed that their direct, personal knowledge of any
IPR related to this document has already been disclosed.
None of the authors is aware of any IPR related to this document.

4. Other Points