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

["MORTON, ALFRED C (AL)" <[e-mail]>]

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)' <[e-mail]>; Tommy Pauly <[e-mail]>; IETF IPPM WG ([e-mail]) <[e-mail]>
Cc: Tommy Pauly <tpauly=[e-mail]>
Subject: RE: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi Frank,

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

From: Frank Brockners (fbrockne) [mailto:[e-mail]]
Sent: Monday, August 31, 2020 10:40 AM
To: MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>>; Tommy Pauly <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>
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.

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



* 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of MORTON, ALFRED C (AL)
Sent: Samstag, 29. August 2020 01:53
To: Tommy Pauly <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>
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:[e-mail]]
Sent: Friday, August 28, 2020 6:35 PM
To: IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>; MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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 ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

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=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 [e-mail]<mailto:[e-mail]> with your reviews and comments, and indicate if you think the document is ready to progress!

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