Metrics and Methods for One-Way IP Capacity
draft-ietf-ippm-capacity-metric-method-12

[[ 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?

Thank you to Rifaat Shekh-Yusef for the SECDIR review.

Thanks for the work on the document. I consider this document to be an important one when it comes to IP layer capacity for access networks.

After my review and observing the IPPM working group discussions, I consider the valid discuss points raised by Magnus Westerlund is now addressed in the -10 version of this document.

please find my comments and observations below -

* Major Issue: I didn't find any restriction imposed by the memo on the number of allowed concurrent tests between same Source and Destination. My understanding is this memo should either strictly prohibit the concurrent tests between same Source and Destination or provide a maximum limit of concurrent tests where the algorithm has been tested to provide valid results. I am not going to hold a discuss on this but I would like to be corrected if I am wrong in the understanding.

* Minor Issues , nits:

   ** I found it a bit odd to not find Magnus Westerlund's name in the acknowledgement section as his review and comments has improved the algorithms and the document a lot. I would encourage the author's to include names of the individuals who has provided any sort of review (including the directorate reviews) that improved this document.
  
   ** Section 2: 

      *** I am not getting the context of "local goal", what does it really mean?

      *** I kind of feel that the paragraph 2 and 3 should swap their order to focus the goal of "defining efficient test procedure" and then "harmonizing the metric and method across the industry" becomes "another goal". This is based on the current text which makes me feel there are number of goals and the ranks (if there is any) of the goals are not clear. If there is not rank among the goals then simply putting them in a bullet list would help the readability.

   ** Section 8.1: 

      *** paragraph 1: s/ agressiveness / aggressiveness .

      *** paragraph 2: It will be helpful if it is mentioned who pre-builts the table and  who (and where) it will be used.
   
   ** Section 10 : I find 4, 5, 6 of the new security considerations introduced in this section not entirely security related rather general considerations on how to run the tests. I think those mentioned considerations are more suitable to put it in section 8 (in section 8.3). I understand the feeling the everyone should read the security considerations but there is no guarantee that it is the case specially while implementing the tests. Hence, putting then in section 8 likely will bring these to attention early.

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric


== COMMENTS ==

Generic comment about the 1 Mbps granularity, this may of course be well suited for many connection but not really for constrained networks where the measurement techniques of this I-D could be applied.

Should the payload content random content to avoid some compression techniques on the path ?


-- Section 4 --
s/the address of a host/one of the IP addresses of a host/

Should there be a SHOULD rather than a MAY in "The IPv6 flow label MAY be included" ?

-- Section 5.3 --
"   o  n0 is the total number of IP-Layer header and payload bits that
      can be transmitted in standard-formed packets [RFC8468] from the
      Src host and correctly received by the Dst host during one
      contiguous sub-interval, dt in length, during the interval [T,
      T+I],"

If we want to split hairs, in the case of IP fragmentation or NAT64, the received bits will be different than the one sent ;-)
I had no time to read RFC 8468 (day job...), but, does the above remark fall in the same category as "Some compression affects on measurement are discussed in Section 6 of [RFC8468]."

-- Section 8.3 --
"  The number of concurrent, independent tests between
   the same Source and Destination SHALL be limited to one."

Is it between hosts or between network? I.e.n "same source and destination networks?"

-- Section 8.4 --
"supports IPv4 and IPv6 address families." does it support a NAT64 function on the path ?

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.

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

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.