Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi Greg,

Thanks for your careful review and comments!

Please see [acm] replies below, all changes are implemented in the working version.

Al, for the co-authors

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Tuesday, September 1, 2020 9:44 AM
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi Tommy,
I support the publication of this document. It is well-written and, when published, become an essential component of industry-wide work on defining the IP Maximum Capacity metric and its measurement methodology.

Dear Authors,
thank you for this work. I have several questions and a number of editorial suggestions that you might find useful. I greatly appreciate your consideration of the comments below:

  *   Is this document intended to update an RFC? The first page suggests that you have thought about that but have not yet pointed to the RFC to be updated. If you decide that the new document does update the existing RFC, you may note that also in the Abstract.
[acm] RFC5136, mentioned in the Abstract and Intro, is only Informational Status. We are revisiting the problem with a more practical standards track solution, and developed new metrics as a result (not updating the old ones).

  *   The document uses a significant number of acronyms that probably are not well-known at IETF, e.g., RTD, RTL, etc. I think that adding a sub-section Acronyms will be helpful to a reader.
[acm] If you’ll allow, most of the acronyms are already defined in list of Section 4, and others at first usage of course.

  *   A number of references don't work as links, e.g., "[ refs to ITU-T SG12, ETSI STQ, BBF liaisons ]".
[acm] I chose a couple of key LS and provided the references.
Also, several sections are references by title, e.g., "[see section Related Round-Trip Delay and Loss Definitions below]", and that makes finding the right place more challenging.
[acm] I think these are all fixed now.

  *   In Section 4 a source IP address of a host accompanied with a note "such as the globally routable IP address". Should the note be interpreted as an example or as a normative statement?
[acm] “such as” typically indicates an example follows, and that’s the case here.

  *   Section 4 defines dt as "dt, the duration of N equal sub-intervals in I (default 1 sec)". But further in the document, on two occasions, it is noted that "all sub-intervals SHOULD be of equal duration". If dt MAY be of varying duration, then the definition in Section 4 might be changed to "dt, the duration of N sub-intervals in I (default 1 sec)". On the other hand, if that definition is interpreted as normative, then s/SHOULD/MUST/2.
[acm] I was trying to cover practical realities in timing at hosts with “SHOULD”. Maybe it’s better to add “nominal” to the definitions of I and dt, then the text can use MUST and avoid intentional variation << which is NOT what we want!

  *   It is not obvious whether "Note that the UDP transport layer is one requirement specified below." applies to the test protocol or something else.
[acm] Ok, clarified as:  Type-P, the complete description of the test packets for which this assessment applies (including the flow-defining fields). Note that the UDP transport layer is one requirement for test packets specified below.
Keep in mind that Type-P always applies to the test packets; control packets could be anything!

  *   Also, in Section 4, the last sentence notes that
   Note that time stamps, sequnce numbers, etc. will be established by
   the test protocol.
Perhaps that may be put as a requirement for the test protocol.
[acm] I added this in Section 9.1:
For example, timestamp resolution requirements that influence the choice of the test protocol are provided in Table 2 of [TR-471].

  *   Security Consideration section references RFC 4656 OWAMP and RFC 5357 TWAMP. Do you think that adding references to RFC 8672 STAMP and draft-ietf-ippm-stamp-option-tlv, as STAMP and its extensions, might be used as the protocol to measure the IP Capacity, is helpful?
[acm] I read the unique STAMP considerations in RFC 8762, and there seems to be enough coverage from the (now) 6 new security considerations we have written for Capacity testing (and other requirements in the memo).

  *   I think that the requirement to provide control of the number of concurrent test sessions can be stronger, as the rate-limiting requirement, than a recommendation. The requirement is more applicable to the test protocol that MUST provide control over the number of simultaneous test sessions.
[acm] OK, I can live with up-levelling concurrent test session control to a MUST. It seems like an easy limit for server code to enforce.
Several nits:

  *   s/[copycat<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-2D03-23ref-2Dcopycat&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=yKzCaDdxr4ZdtpAPWdBs6Wb5h1-FvV9zQ-I02NWaLWA&s=beL2wAnc1YD9IALGvCN_EpsLAeRb8zYKb7Mlx4oxmuw&e=>][copycat]/[copycat]/[acm]  ok
  *    s/sequnce/sequence/[acm]  ok
  *   A reference in "Type-P is a parallel concept to "population of interest" defined in ITU-T Rec. Y.1540." will be helpful.[acm]  ok, it’s clause 6.1.1, added
  *   I assume that in "T, the host time of the *first* test packet's *arrival* as measured at MP(Dst)", MP stands for Measurement Point. Is that correct?[acm]  yes, fixed.
  *   Capitalization in "Target performance threshold" throughout the document needs consistency, on several occasions, it is used as "target performance threshold".[acm]  ok, fixed.
Regards,
Greg

On Fri, Aug 14, 2020 at 2:21 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>> wrote:
Hello IPPM,

As discussed at IETF 108, draft-ietf-ippm-capacity-metric-method is stable, and the group felt it is ready for Working Group Last Call.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-2D02&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=yKzCaDdxr4ZdtpAPWdBs6Wb5h1-FvV9zQ-I02NWaLWA&s=XJLQkG2WsakslD6KgDyuPlbYYPyQ_p9iWs_WVGuv4ag&e=>

The last call will end on Wednesday, September 2. Please reply to ippm@ietf.org<mailto:ippm@ietf.org> with your reviews and comments, and indicate if you think the document is ready to progress!

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=yKzCaDdxr4ZdtpAPWdBs6Wb5h1-FvV9zQ-I02NWaLWA&s=K2fFqjaHzvIMcEC6GDeXGDKXo66lSqVsO0sreMaEraI&e=>