Ballot deferred by Lars Eggert on 2021-05-03.
Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
DOWNREF from this Standards Track doc to Informational RFC7497. I didn't see this called out in the Last Call, and it's also not a document we have in the DOWNREF registry already.
Section 1, paragraph 3, comment: > Here, the main use case is to assess the maximum capacity of the > access network, with specific performance criteria used in the > measurement. If the main use case is to measure access network paths, that applicability should be made very explicit, i.e., in the title and abstract. Section 2, paragraph 2, comment: > The scope of this memo is to define a metric and corresponding method > to unambiguously perform Active measurements of Maximum IP-Layer > Capacity, along with related metrics and methods. I'm not sure what "unambiguously perform" is meant to express? Section 2, paragraph 3, comment: > A local goal is to aid efficient test procedures where possible, and > to recommend reporting with additional interpretation of the results. What is this goal "local" to - the IETF? Also, I'm unclear what "reporting with additional interpretation of the results" is supposed to express. Section 2, paragraph 10, comment: > - If a network operator is certain of the access capacity to be > validated, then testing MAY start with a fixed rate test at the > access capacity and avoid activating the load adjustment algorithm. > However, the stimulus for a diagnostic test (such as a subscriber > request) strongly implies that there is no certainty and the load > adjustment algorithm will be needed. Since the first sentence of this paragraph uses a RFC2119 MAY, I'd suggest rephrasing the second sentence to end with "there is no certainty and use of the load adjustment algorithm is RECOMMENDED." Section 3, paragraph 4, comment: > 1. Internet access is no longer the bottleneck for many users. What is the bottleneck then, and if it's not the access bandwidth, why is a new metric for it helpful? Section 4, paragraph 4, comment: > o Src, the address of a host (such as the globally routable IP > address). > > o Dst, the address of a host (such as the globally routable IP > address). For many hosts, their IP address is not globally routable, and hasn't been for decades. Or did you mean CPE? Section 8.1, paragraph 1, comment: > 8.1. Load Rate Adjustment Algorithm I wonder why this section is trying to define a crude new AIMD scheme, when we have lots of good experience with TCP's AIMD approach, which converges on the available bandwidth relatively well? Also, the description of the algorithm itself is far from clear. Section 8.1, paragraph 7, comment: > If the feedback indicates that no sequence number anomalies were > detected AND the delay range was below the lower threshold, the > offered load rate is increased. If congestion has not been confirmed > up to this point, the offered load rate is increased by more than one > rate (e.g., Rx+10). This allows the offered load to quickly reach a > near-maximum rate. Conversely, if congestion has been previously > confirmed, the offered load rate is only increased by one (Rx+1). The first sentence talks about sequence number anomalies and delay ranges. The rest of the paragraph then talks about whether congestion and whether it was confirmed or not. Does this mean that (some amount of) sequence number anomalies and/or delay indicates congestion? Is that defined somewhere? Section 8.1, paragraph 7, comment: > If the feedback indicates that sequence number anomalies were > detected OR the delay range was above the upper threshold, the > offered load rate is decreased. The RECOMMENDED values are 0 for This doesn't agree with the previous paragraph, which says "Conversely, if congestion has been previously confirmed, the offered load rate is only increased by one (Rx+1)." (Or I don't understand the difference between congestion and sequence number anomalies/delay ranges; see previous comment.) Section 8.4, paragraph 2, comment: > This section is for the benefit of the Document Shepherd's form, and > will be deleted prior to final review. Should this section have been deleted before the IESG review then? Would you like the IESG to ignore it? You probably also need to instruct the RFC Editor to remove it before publication? This document uses RFC2119 keywords, but does not contain the recommended RFC8174 boilerplate. (It contains some text with a similar beginning.) ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 5, nit: - authors found that a high percentage of paths tested support UDP + authors found that a high percentage of paths tested support the UDP + ++++ Section 3, paragraph 8, nit: - to less traffic crossing ISP gateways in future. + to less traffic crossing ISP gateways in the future. + ++++ Section 8.1, paragraph 2, nit: - agressiveness (speed of ramp-up and down to the Maximum IP-Layer + aggressiveness (speed of ramp-up and down to the Maximum IP-Layer + + Section 8.2, paragraph 5, nit: - Another approach comes from Section 24 of RFC 2544[RFC2544] and its - -------- + Another approach comes from Section 24 of [RFC2544] and its Section 8.3, paragraph 4, nit: - The path measured may be state-full based on many factors, and the - - - + The path measured may be stateful based on many factors, and the Section 14.2, paragraph 5, nit: - measurements with a clear and concise rate reduction when warrented, - ^ + measurements with a clear and concise rate reduction when warranted, + ^ "I", paragraph 2, nit: > to the specifications of other Standards Development Organizations (SDO) (t > ^^^^^^^^^ An apostrophe may be missing. "S", paragraph 2, nit: > t Maximum IP-Layer Capacity is unknown (which is sometimes the case; service > ^ Unpaired symbol: ')' seems to be missing Section 6.3, paragraph 14, nit: > urement systems MUST be higher than than the smallest of the links on the pa > ^^^^^^^^^ Possible typo: you repeated a word Section 6.3, paragraph 15, nit: > PM list over all dt-length intervals in I. Measurements according to these de > ^^^^ Did you mean "in me", "in her", "in him", "in us", or "in them"? Section 8, paragraph 3, nit: > work, since this is an active test method and it will likely cause congestion > ^^^^^^^^^^ Use a comma before 'and' if it connects two independent clauses (unless they are closely connected and short). Section 8.2, paragraph 4, nit: > etons (dt = 1 second) has proven to a be of practical value during tests of > ^^^^ After 'a', do not use a verb. Make sure that the spelling of 'be' is correct. If 'be' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 8.3, paragraph 4, nit: > nts based on those packets. Many different traffic shapers and on-demand acce > ^^^^^^^^^^^^^^ Consider using "Many". Section 8.3, paragraph 6, nit: > , where packet losses may occur independently from the measurement sending ra > ^^^^^^^^^^^^^^^^^^ The usual collocation for "independently" is "of", not "from". Did you mean "independently of"? Section 10, paragraph 10, nit: > ffic (for example, the range of I duration values SHOULD be limited). The exa > ^^^^^^^^^^ Do not use a noun immediately after the pronoun 'I'. Use a verb or an adverb, or possibly some other part of speech. "R", paragraph 1, nit: > ble) seqErr = 0 # Measured count of any of Loss or Reordering impairments de > ^^^^^^^^^ Consider simply using "of" instead. Section 14.1, paragraph 10, nit: > g a test when connectivity is lost for an longer interval (Feedback message o > ^^ Use "a" instead of 'an' if the following word doesn't start with a vowel sound, e.g. 'a sentence', 'a university'. Section 14.2, paragraph 10, nit: > easurements. A brief review of some of the other SHOULD-level requirements fo > ^^^^^^^^^^^ If the text is a generality, 'of the' is not necessary. "Authors' Addresses", paragraph 2, nit: > 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 > ^^ Two consecutive commas "Authors' Addresses", paragraph 5, nit: > 200 Laurel Avenue South Middletown,, NJ 07748 USA Email: lencia@att > ^^ Two consecutive commas
A) Section 8. Method of Measurement I think the metrics are fine, what makes me quite worried here is the measurement method. My concerns with it are the following. 1. The application of this measurement method is not clearly scoped. Therefore I will assume that across the Internet measurements are possible. However in that context I think the definition and protection against severe congestion has significant short comings. The main reason is that the during a configurable time period (default 1 s) the sender will attempt to send at a specified rate by a table independently on what happens during that second. 2. The algorithm for adjusting rate is table driven but give no guidance on how to construct the table and limitations on value changes in the table. In addition the algorithm discusses larger steps in the table without any reflection of what theses steps sides may represent in offered load. 3. Third the algorithms reaction to any sequence number gaps is dependent on delay and how it is related to unspecified delay thresholds. Also no text discussion how these thresholds should be configured for safe operation. B) Section 8. Method of Measurement There are no specification of the measurement protocol here that provides sequence numbers, and the feedback channel as well as the control channel. Is this intended to use TWAMP? From my perspective this document defines the metrics on standards track level. However, the method for actually running the measurements are not specified on a standards track level. No one can build implementation. And if the section is intended to provide requirements on a protocol that performs these measurements I think several aspects are missing. There appear several ways forward here to resolve this; one is to split out the method of measurement and define it separately to standard tracks level using a particular protocol, another is to write it purely as requirements on a measurement protocols.
Thank you to Rifaat Shekh-Yusef for the SECDIR review.
I reviewed the diff from -06 to -10, and did not see any security-relevant concerns. Given that some use of terminology/symbols was updated, a fresh gen-art-like review of the entire document for internal consistency might be warranted.
[[ comments ]] * Thanks for addressing previous round of comments.
Since a SHOULD leaves an implementer with a choice, it's preferable to see prose explaining why one might deviate from the SHOULD advice. Thus, the SHOULDs in Sections 5.3 and 6.3 leave me wondering under what circumstances an implementer might legitimately choose to do something else. If there are none, should it be a MUST?
I'm stealing Robert's ballot text, because it perfectly explains my position/views: "Thank you for this document, I found it interesting to read. I have no comments that haven't already been raised by other AD reviews. "
Thank you for this document, I found it interesting to read. I have no comments that haven't already been raised by other AD reviews.