[ippm] Lars Eggert's Discuss on draft-ietf-ippm-capacity-metric-method-10: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-ippm-capacity-metric-method-10: Discuss

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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Zahed is still on leave and has not had a chance to review Magnus' earlier DISCUSS.
I deferred this document last time it was on the agenda, but since Zahed is still
not back, I will put in a placeholder DISCUSS for him, so that he has a chance to
complete his review.

I apologize to the authors and the WG for doing this; these are exceptional
circumstances. I will clear this placeholder DISCUSS as soon as Zahed is able to
resume as AD (or Martin Duke indicates that he has reviewed Magnus' DISCUSS.)

All that said, I do have one DISCUSS item:

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.


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

(These are my comments and not related to the placeholder DICUSS above.)

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 6.4, paragraph 2, nit:
>  the capacity Samples, RTD[T,I] and OWL[T,I]. The interval dtn,dtn+1 where M
>                                     ^^^^^
The word 'OWL[T' is not standard English. Did you mean "OWL'T" (curly
apostrophe) or "OWL'T" (straight apostrophe)?

Section 6.4, paragraph 3, nit:
> ting sub-interval within RTD[T,I] and OWL[T,I]. Other metrics MAY be measured
>                                       ^^^^^
The word 'OWL[T' is not standard English. Did you mean "OWL'T" (curly
apostrophe) or "OWL'T" (straight apostrophe)?

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

"T", paragraph 8, nit:
> oad | | | largest value that | | size, bytes |
>           ^^^^^^^
A determiner is probably missing here: "the largest".

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 8.3, paragraph 18, nit:
> P- Layer Capacity measurements", [Y.Sup60], which is the result of continued
>                                     ^^^^^
Add a space between sentences

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.

Section 12, paragraph 1, nit:
> s to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, Wolfgang Balzer
>                                     ^^^^^^^
Add a space between sentences

"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 5, nit:
> nning code [LS-SG12-A] [LS-SG12-B] [Y.Sup60]. Also, the UDP aspect of these m
>                                       ^^^^^
Add a space between sentences

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:
> esting [LS-SG12-A] [LS-SG12-B] [Y.Sup60] supported this statement hundreds o
>                                   ^^^^^
Add a space between sentences

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.

Section 15.2, paragraph 16, nit:
> rec/T-REC-Y.1540-201912-I/en>. [Y.Sup60] Morton, A., "Recommendation Y.Sup60
>                                   ^^^^^
Add a space between sentences

Section 15.2, paragraph 16, nit:
> Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting ITU
>                                        ^^^^^
Add a space between sentences

Section 15.2, paragraph 17, nit:
>  <https://www.itu.int/rec/T-REC-Y.Sup60/en>. Authors' Addresses Al Morton
>                                   ^^^^^
Add a space between sentences

"Authors' Addresses", paragraph 2, nit:
>  200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: [phone]
>                                    ^^
Two consecutive commas

"Authors' Addresses", paragraph 5, nit:
>  200 Laurel Avenue South Middletown,, NJ 07748 USA Email: lencia@att
>                                    ^^
Two consecutive commas