Note: This ballot was opened for revision 16 and is now closed.
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.
** 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 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.
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?
— 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 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
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