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

From: Greg Mirsky <[email-masked]>
Date: Tue, 1 Sep 2020 06:43:39 -0700

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.
   - 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.
   - A number of references don't work as links, e.g., "[ refs to ITU-T
   SG12, ETSI STQ, BBF liaisons ]". 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.
   - 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?
   - 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.
   - It is not obvious whether "Note that the UDP transport layer is one
   requirement specified below." applies to the test protocol or something
   else.
   - 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.

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

Several nits:

   - s/[copycat
   <https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-03#ref-copycat>
   ][copycat]/[copycat]/
   -  s/sequnce/sequence/
   - A reference in "Type-P is a parallel concept to "population of
   interest" defined in ITU-T Rec. Y.1540." will be helpful.
   - 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?
   - Capitalization in "Target performance threshold" throughout the
   document needs consistency, on several occasions, it is used as "target
   performance threshold".

Regards,
Greg

On Fri, Aug 14, 2020 at 2:21 PM Tommy Pauly <tpauly=
[email-masked]> 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
>
> The last call will end on *Wednesday, September 2*. Please reply to
> [email-masked] with your reviews and comments, and indicate if you think
> the document is ready to progress!
>
> Best,
> Tommy & Ian
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 02 Sep 2020 09:14:40 -0700

Hello all,

Thank you for your feedback! It sounds like we do have consensus that this document is something we think is ready to progress, once several comments and nits are addressed.

Authors, please submit an updated version of draft when possible to address the feedback from José Ignacio, Joachim, Frank, and Greg. Once that had been done, we’ll submit this to the IESG.

Best,
Tommy & Ian

> On Aug 14, 2020, at 2:21 PM, Tommy Pauly <tpauly=[email-masked]> 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://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02>
> 
> The last call will end on Wednesday, September 2. Please reply to [email-masked] <mailto:[email-masked]> with your reviews and comments, and indicate if you think the document is ready to progress!
> 
> Best,
> Tommy & Ian

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 2 Sep 2020 16:38:42 +0000

Yes Tommy,

THANKS for your reviews and support everyone! Many important comments to address, ASAP!
Ignacio, Joachim, Frank, and Greg will all be ACK’d in the next version.

for the co-authors,
Al

From: Tommy Pauly [mailto:[email-masked]]
Sent: Wednesday, September 2, 2020 12:15 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hello all,

Best,
Tommy & Ian

On Aug 14, 2020, at 2:21 PM, Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>> wrote:

Hello IPPM,

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=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=rPPbqy_YKTD14gUFwHtKuUFtlcvZxas60t1bATFI9Y8&s=mZXW9pbW0MeY7OqhoblPzhNaZyj9w_uUrVhkNRzsVCE&e=>

The last call will end on Wednesday, September 2. Please reply to [email-masked]<mailto:[email-masked]> with your reviews and comments, and indicate if you think the document is ready to progress!

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=rPPbqy_YKTD14gUFwHtKuUFtlcvZxas60t1bATFI9Y8&s=wlvRAc-vejuvZrHEvv7aCvc32AH8DyDvspX0Tj6BqlE&e=>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 5 Sep 2020 14:20:03 +0000

Hi Ignacio,

please see replies below,

Al, for the co-authors

> -----Original Message-----
> From: J Ignacio Alvarez-Hamelin [mailto:[email-masked]]
> Sent: Monday, August 31, 2020 9:57 AM
> To: Tommy Pauly <tpauly=[email-masked]>
> Cc: IETF IPPM WG ([email-masked]) <[email-masked]>; MORTON, ALFRED C (AL)
> <[email-masked]>
> I think this draft is useful, and it represents some methods that are used
> nowadays. I have a couple of comments:
> 
> 1_ The equation in section 5.3 does not consider times spending on
> transmitting (or I did not see it clearly). It is true that for some
> measurements, the destination is close to the source, and these times are
> tiny.
[acm] 
The definition of T says that this equation corresponds to measurement at the destination, making the rate measurements much simpler/more practical. I have added some clarifications in the definitions of T, I, and dt to make this more clear.

> 2_ A recommendation about the minimum time during the process could be
> useful to overcome some traffic shapers operation.
[acm] 
We have recommended several default times for key parameters. It's more tricky to recommend minimums without knowing more deployment details. I don't think we can "overcome some traffic shapers operation", or want to do it. We want to measure at reasonable time-frames.

> 3_ 3_ For the "Related Round-Trip Delay and Loss Definitions" sections, I
> suggest to include the "median," according to the observations in draft-
> ietf-ippm-route-10.
[acm] 
Ok

> 
> Many thanks to the authors for their work.
[acm] 
Thanks for your re-review and comments (noting that you commented on the Individual Draft last year).

> 
> 
> Sincerely,
> 
> 	J. Ignacio Alvarez-Hamelin
> 
> 
> _______________________________________________________________
> 
> Dr. Ing. José Ignacio Alvarez-Hamelin
> CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
> Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
> +54 (11) 5285 0716 / 5285 0705
> e-mail: [email-masked]
> web: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cnet.fi.uba.ar_ignacio.alvarez-2Dhamelin_&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=HGcCacbF-
> cOYzrXhe4od_eSTP4dG7KLAZwI_owkTBV0&s=DfeP2Q3ym7BiQlqJQaaPSHi_UBVGEOi3QrBhL
> VspmiQ&e=
> _______________________________________________________________
> 
> 
> 
> > On 28 Aug 2020, at 19:34, Tommy Pauly
> <tpauly=[email-masked]> wrote:
> >
> > Hi IPPM,
> >
> > A reminder that our WGLC is ending next week for draft-ietf-ippm-
> capacity-metric-method. Please take a moment to review the document!
> >
> > Thanks,
> > Tommy
> >
> >> On Aug 14, 2020, at 2:31 PM, MORTON, ALFRED C (AL)
> <[email-masked]> wrote:
> >>
> >> Thanks Tommy and Ian!
> >>
> >> While updating a few references this week, I noticed that the 02 draft
> had no Security Considerations Section.  That won’t do!
> >>
> >> The co-authors came together and supplied new text for the Section in
> version 03, posted minutes ago. Please consider version 03 of the draft
> during WGLC.  Thank you IPPM.
> >>
> >> For the co-authors,
> >> Al
> >>
> >>
> >> From: ippm [mailto:ippm-bounces@ietf..org] On Behalf Of Tommy Pauly
> >> Sent: Friday, August 14, 2020 5:21 PM
> >> Subject: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
> >>
> >> Hello IPPM,
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-
> 2D02&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=HGcCacbF-
> cOYzrXhe4od_eSTP4dG7KLAZwI_owkTBV0&s=BCaAJgx9uak_j2yvR1gRA-
> 4QPkgFs62IW_8oahO5F7M&e=
> >>
> >> The last call will end on Wednesday, September 2. Please reply to
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=HGcCacbF-
> cOYzrXhe4od_eSTP4dG7KLAZwI_owkTBV0&s=KyLZuLZlcdue8OhCgk9UZg4xWS79k3NZ81-
> CIUDLyWo&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=HGcCacbF-
> cOYzrXhe4od_eSTP4dG7KLAZwI_owkTBV0&s=KyLZuLZlcdue8OhCgk9UZg4xWS79k3NZ81-
> CIUDLyWo&e=

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 5 Sep 2020 15:32:25 +0000

Hi Joachim,

Thanks for your comments!  Please see [acm] replies below.

Al, for the co-authors

> From: ippm [mailto:[email-masked]] On Behalf Of Joachim Fabini
> Sent: Monday, August 31, 2020 10:33 AM
> To: Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG
> ([email-masked]) <[email-masked]>
> Cc: MORTON, ALFRED C (AL) <[email-masked]>
> All,
> as a follow-up some nits that I noticed while reading through the
> capacity draft:
> 
> 1. Newly added security considerations: my expectation is that UDP-based
> capacity measurements can be potentially more harmful and more difficult
> to protect against when compared to TCP-based ones, in particular when
> considering (D)DoS. First, there is no state involved at transport layer
> that an attacker may need to track/establish and no flow/congestion
> control involved. Second, firewalls and other stateful protection
> devices can easily identify a missing 3-way handshake for TCP and block
> subsequent (unsolicited, harmful) measurement packets sent by an
> attacker. But there's no such option for UDP, meaning that the
> application layer must handle this case.
> If an attacker misuses the packet pattern of UDP capacity measurements
> and directs these measurements to an open UDP port of the
> destination/target, then middlebox and firewall protections may fail and
> consider the traffic to be a legitimate one.
> The authors may consider adding some details and guidelines on these
> aspects to the security section.
[acm] 
Yes, Len Ciavattone and I have added a new list item 2, which is based on the udpst "running code" (after setting-up the measurement architecture with some new text in Section 8):

2. A REQUIRED user client-initiated setup handshake between cooperating hosts allows firewalls to control inbound unsolicited UDP which either go to a control port [expected and w/authentication] or to ephemeral ports that are only created as needed. Firewalls protecting each host can both continue to do their job normally.
> 
> 2. A potential architectural/wording issue (disclaimer: I just skimmed
> over the draft and may have ommitted some relevant statements, will
> hopefully find some more time during the next weeks to review it more
> thoroughly): in the beginning the unidirectionality of the capacity
> measurement was not obvious to me. Perhaps add it to the draft title to
> make this explicit?
[acm] 
I see the ambiguity now, too.  Besides the fixes for Ignacio's comments, I added "One-way" to the title and the formal metric names.

> In particular the discussion about round-trip delay (RTD) and round-trip
> loss (RTL) created this impression and, infact, may also be misleading
> wrt inferences about the capacity measurement results.
[acm] 
Here, we make have an architectural requirement that sending rate is controlled using feedback messages from the receiver, and this is the source of round-trip delay measurements (the most reliable from a time-accuracy perspective).

Also, I made a mistake representing the Loss measurements. They are One-way, like the Capacity measurement, and are a key measurement in the feedback messages. This is now clarified.

> I assume that the correct capacity measurement depends on the forward
> path only, but a lossy reverse path may increase the RTL. This may
> introduce some artificial bias and impression that the measurement limit
> is reached, while infact the forward link is still under-utilized. So
> I'm wondering if Round-trip delay/loss is acceptable or one-way-loss is
> needed and more accurate.
[acm] 
You are right, of course!  The udpst "running code" uses one-way loss (only) and allows the use of one-way delay variation (when sender and receiver clocks are stable)
> 
> But, as written in the disclaimer: it's a potential issue that needs
> some more time and deeper analysis. Hope to find some time to go more
> into details later on.
[acm] 
Len Ciavattone and I have evaluated many different measurement feedback combinations. So far, RTD and OWL (one-way loss) are both sufficient and reliable.

> 
> Overall I find the concept of UDP-based capacity measurement to be a
> compelling mechanism that can help to overcome some of the downsides of
> TCP-based bulk transfer capacities. Thanks to the authors for their
> contribution.
[acm] 
Thanks for your continuing contributions to this work, Joachim! You engaged in many discussions last year, and you sent two very important comments/catches again this time. Much appreciated!

> 
> regards
> Joachim
> 
> On 29/08/2020 00:34, Tommy Pauly wrote:
> > Hi IPPM,
> >
> > A reminder that our WGLC is ending next week for
> > draft-ietf-ippm-capacity-metric-method. Please take a moment to review
> > the document!
> >
> > Thanks,
> > Tommy
> >
> >> <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Thanks Tommy and Ian!
> >>
> >> version 03, posted minutes ago. Please consider version 03 of the
> >> draft during WGLC.  Thank you IPPM.
> >>
> >> For the co-authors,
> >> Al
> >>
> >>
> >> *From:* ippm [mailto:ippm-bounces@ietf..org] *On Behalf Of *Tommy Pauly
> >> *Sent:* Friday, August 14, 2020 5:21 PM
> >> *To:* IETF IPPM WG ([email-masked] <mailto:[email-masked]>)
> >> <[email-masked] <mailto:[email-masked]>>
> >> *Subject:* [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
> >>
> >> Hello IPPM,
> >>
> >> The latest version can be found
> >> here: https://urldefense.proofpoint.com/v2/url?u=https-
> 2D02&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=lcASpR1GwpzDKv3GRJhRZMLY_CPvEf6m7InH8POWY0k&e=
> >> <https://urldefense.proofpoint.com/v2/url?u=https-
> 2D02&d=DwMFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=SIvlMcMEEzV1Wv8tA8hftr1Fvi38_
> c2R6bgbotceIsU&s=WEcaTbukpUJlfOGrn8Lbw-jjrpTxRsPst6bsHPjjExE&e=>
> >>
> >> The last call will end on *Wednesday, September 2*. Please reply
> >> to [email-masked] <mailto:[email-masked]> with your reviews and
> >> comments, and indicate if you think the document is ready to progress!
> >>
> >> Best,
> >> Tommy & Ian
> >> [email-masked] <mailto:[email-masked]>
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=9N8ZNy8TlO27Uuxnqq_iP8HKY5mkWISE0Y9V-j0JMe8&e=
> >
> >
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=9N8ZNy8TlO27Uuxnqq_iP8HKY5mkWISE0Y9V-j0JMe8&e=
> >
> 
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=9N8ZNy8TlO27Uuxnqq_iP8HKY5mkWISE0Y9V-j0JMe8&e=

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 5 Sep 2020 17:26:31 +0000

Hi Frank,

Thanks for your careful review and many comments!
Please see replies below,
Al, for the co-authors

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: Monday, August 31, 2020 10:40 AM
To: MORTON, ALFRED C (AL) <[email-masked]>; Tommy Pauly <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: Tommy Pauly <tpauly=[email-masked]>
Subject: RE: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Thanks for getting the document to the finish line. I support advancing the document – but noticed a couple of nits while reading through the -03 version of draft (see below).

Cheers, Frank

A few nits:

* Section 1: [copycat][copycat] mentioned twice
[acm] ok, thanks
* Notation: Would it make sense to use a notation which is more Latex-style, e.g. use dt_n, dt_n+1 instead of dtn,dtn+1. Initially I got a bit confused because the dtn wasn’t defined in section 4, whereas dt was.
[acm] Let me take the approach of defining dtn in section 4, if you will.

* Notation: Would it make sense to use a different character that “I” for the duration, because “I” can easily be confused with (me, myself)? E.g. section 8 says: “The duration of a test, I, MUST be constrained in a production network, since this is an active test method and it will likely cause congestion on the Src to Dst host path during a test.”.. and at first glimpse, I was wondering why I should be constrained in a production network :-).
[acm] Well, you are constrained if you set the parameter to a non-default value. We can clarify by saying “parameter I” where it helps.

* Section 5.3: IMHO it would be useful to add a sentence / stress the fact, that the definition of “IP Layer Capacity” is always wrt/ particular endpoints, i.e. E2E – rather than that of a channel between endpoints. I.e. the capacity of the channel between endpoints could be lower (in case e.g. compression is used) than the capacity between endpoints. Another place to put this discussion could be section 8.3.
[acm]
In 5.3, added “The IP-layer capacity depends on the Src and Dst hosts, the host addresses, and the path between the hosts.”
Also, in section 8.2:
“It is of course necessary to calibrate the equipment performing the IP-layer Capacity measurement, to ensure that the expected capacity can be measured accurately, and that equipment choices (processing speed, interface bandwidth, etc.) are suitably matched to the measurement range.”
There are some techniques to make compression less-effective or ineffective, Section 6 of RFC covers some forms of compression and we’ll site that near the term “Standard Formed” (same reference).

* Section 5.4: Shouldn’t the text say [T0, T0+I]? T0 is defined in section 4, T is not. (There are several occurrences of T in the document)
[acm]
The last definition in Section 4 is “T”, and I think we have clarified why T is the right variable sufficiently now (all times in the metric definition are defined at the receiver).

* Section 6.3: Replace “[see section Related Round-Trip Delay and Loss Definitions below]” with a proper reference
[acm] ok
* Section 6.3: What are “Standard Formed packets”? Could we add a reference?
[acm]
Yes, it’s Section 5 of RFC 8468.

* Section 6.5: Line break in “Maximum_C(T,I,PM)”

[acm] I think an extra space was causing the split, should be fixed now.

* Section 6.6: Does one Megabit consist of 1048576 bits or 1000000 bits?

[acm] 1 million bits, we aren’t talking about 1000 kibibits

* Section 8.1: If I understand things correctly, the examples given here refer to Mbps as a unit, i.e. Rx+10 would mean Rx+10Mbps. Correct? Is there a way to future proof these numbers and methods: What is Mbps might be Gbps in 10 years? E.g. we could consider defining those formulas in relation to the nominal interface speeds of the Src and Dst. Relative numbers might be better than absolute values, e.g. Rx-30: How would we know that we can always reduce the rate by 30 Mbps?

[acm]

That’s a feature the pre-built table provides, I added at the end:

All the values used above are relevant to searches in the 1 to 10 Gbps capacity range, and can accommodate higher rate capacities by changing the rates in the pre-built table.

* Section 8.4: Empty bullet

[acm] poof, it’s gone.

* Section 10.: How about adding a requirement that the identity and integrity of Src and Dst should be checked and confirmed? That way we ensure that we indeed measure Src to Dst  and not to some MIM “friendly” proxy that would give me the impression of stellar IP layer capacity...

[acm]

Yes, I think we killed two birds (comments) with one stone for this. A new item 2. that says:

2. A REQUIRED user client-initiated setup handshake between cooperating hosts and allows firewalls to control inbound unsolicited UDP which either go to a control port [expected and w/authentication] or to ephemeral ports that are only created as needed. Firewalls protecting each host can both continue to do their job normally.

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of MORTON, ALFRED C (AL)
Sent: Samstag, 29. August 2020 01:53
To: Tommy Pauly <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi Tommy,
Thanks for sending the reminder!
I support this as an author of course,
Al

From: Tommy Pauly [mailto:[email-masked]]
Sent: Friday, August 28, 2020 6:35 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi IPPM,

A reminder that our WGLC is ending next week for draft-ietf-ippm-capacity-metric-method. Please take a moment to review the document!

Thanks,
Tommy

On Aug 14, 2020, at 2:31 PM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Tommy and Ian!

While updating a few references this week, I noticed that the 02 draft had no Security Considerations Section.  That won’t do!

The co-authors came together and supplied new text for the Section in version 03, posted minutes ago. Please consider version 03 of the draft during WGLC.  Thank you IPPM.

For the co-authors,
Al

From: ippm [mailto:ippm-bounces@ietf..org] On Behalf Of Tommy Pauly
Sent: Friday, August 14, 2020 5:21 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hello IPPM,

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=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=SIvlMcMEEzV1Wv8tA8hftr1Fvi38_c2R6bgbotceIsU&s=WEcaTbukpUJlfOGrn8Lbw-jjrpTxRsPst6bsHPjjExE&e=>

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
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=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=WhdjOJaLaKnkqCY9q-_CdCoH6_wwB1_QaV9FHk-qgNc&s=mMx6KKiG6xhHD9mZLMLJ70_AsL7gk_GnydQqC14aB00&e=>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 5 Sep 2020 19:14:35 +0000

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:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, September 1, 2020 9:44 AM
To: Tommy Pauly <tpauly=[email-masked]>
Cc: IETF IPPM WG ([email-masked]) <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> wrote:
Hello IPPM,

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=>

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
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=>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 6 Sep 2020 12:38:48 +0000

Hi Frank,
As I re-read the complete working draft this morning, I tweaked the section 8.1 new text.
Please see below,
Al

From: MORTON, ALFRED C (AL)
Sent: Saturday, September 5, 2020 1:26 PM
To: 'Frank Brockners (fbrockne)' <[email-masked]>; Tommy Pauly <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: Tommy Pauly <tpauly=[email-masked]>
Subject: RE: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi Frank,

To: MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>>; Tommy Pauly <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>

Cheers, Frank

A few nits:

[acm]

[acm] Revised:

All the values used above are relevant to searches in the 1 Mbps to 10 Gbps capacity range. Searches can accommodate higher rate capacities by changing the rates in the pre-built table.

[acm] poof, it’s gone.

[acm]

Hi Tommy,

Hi IPPM,

Thanks,
Tommy

Thanks Tommy and Ian!

For the co-authors,
Al

Hello IPPM,

Best,
Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 11 Sep 2020 11:40:26 -0700

Hi Al,
thank you for your consideration of my comments. Please find my notes
in-line under the GIM>> tag.

Regards,
Greg

On Sat, Sep 5, 2020 at 12:14 PM MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, September 1, 2020 9:44 AM
> *To:* Tommy Pauly <tpauly=[email-masked]>
> *Cc:* IETF IPPM WG ([email-masked]) <[email-masked]>
> *Subject:* Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
>
>
>
> Hi Tommy,
>
> thank you for this work. I have several questions and a number of
> editorial suggestions that you might find useful. I greatly appreciate your
> *[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).*
>
> *[acm] If you’ll allow, most of the acronyms are already defined in list
> of Section 4, and others at first usage of course.*
>
GIM>> I'm looking at the current version of the draft in the datatracker
<https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/?include_text=1>.
I think that some acronyms never expanded, e.g., RTD, RTL, OWL.

>    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.*
>
> *[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
> *[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!*
>
GIM>> Thank you, I agree with the resolution.

> *[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!*
>
GIM>> I agree with the update, thank you.

> *[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].*
>
> GIM>> Thank you. Referencing TR-471 is fine by me but some might think
differently.

>
>    - Security Consideration section references RFC 4656 OWAMP and RFC
>    5357 TWAMP. Do you think that adding references to RFC 8672 STAMP and
> *[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).*
>
> *[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.*
>
GIM>> Thank you.

> 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*
>    interest" defined in ITU-T Rec. Y.1540." will be helpful.*[acm] * *ok,
>    it’s clause 6.1.1, added*
>    correct?*[acm] * *yes, fixed.*
>    performance threshold".*[acm] * *ok, fixed.*
>
> Regards,
>
> Greg
>
>
>
>
>
> <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=>
>
>
>
> <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=>
>
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 12 Sep 2020 12:34:12 +0000

Thanks Greg, on:

  *   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.
GIM>> I'm looking at the current version of the draft in the datatracker<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod_-3Finclude-5Ftext-3D1&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=mveK6SlHXHHfVlkbUSs_cAqAHneVKxD_r0vI0D48GLc&s=S0xmkPDX6fwLFN28pv2Y-zZHnvxukYmlyQk2viTFrWs&e=>. I think that some acronyms never expanded, e.g., RTD, RTL, OWL.

We may have missed some, and RTL should not be there at all. Something for next release though.

Al