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

["MORTON JR., AL" <[e-mail]>]

Hi Lars,

I'll trim this reply down to the essentials.

Al

> -----Original Message-----
> From: Lars Eggert <[e-mail]>
> Sent: Tuesday, May 18, 2021 3:05 AM
> To: MORTON JR., AL <[e-mail]>
...
> 
> Hi Al,
> 
> On 2021-5-17, at 21:00, MORTON JR., AL <[e-mail]> wrote:
...
> 
> yes, another LC will unfortunately be needed. It's an action item for
> Martin.
[acm] 
Martin obtained a waiver for the LC; this DOWNREF didn't appear in the memo
until we addressed Magnus' comments. We're good here.

> 
> Note that everything below was comments, which are not blocking the
> document:
> 
> >> 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.
> >
> > Two things:
> >
> > 1. The term "access" doesn't have a universally agreed definition
> regarding the portion of the network it covers, and that's partly because
> there are many architectures in use.
> >
> > 2. If we add access to the title or abstract, we are unnecessarily
> limiting the scope that we define later. We refer to section of RFC 7497
> where the figure includes the subscriber's device, multiple private
> networks, and various devices and gateways ending at a transit gateway.
> >
> > So, I don't want to emphasize the term "access" as you propose.
> 
> That's fine, too. When reading the document, I came away with the
> impression that it did want to focus on measuring access networks, because
> it actually says that in several places (e.g., the quote above.) If the
> intent is for this to be a general metric for IP paths, maybe review the
> places where the document talks about "access" to make sure they are not
> giving the wrong impression.
> 
> > Perhaps we can clarify this further in the Intro, because the Scope says:
> >
> >   The primary application of the metric and method of measurement
> >   described here is the same as in Section 2 of [RFC7497]...
> >
> > How about:
> > Here, the main use case is to assess the maximum capacity of one or more networks
> > where the subscriber receives specific performance assurances, sometimes
> > referred to as the Internet access.
> 
> It's not only the intro, though. There is text talking about "access"
> throughout the document.
[acm] 
I have substituted more descriptive terms where possible. Note that we 
use "Internet access" to describe a service, and that "on-demand access"
is now clarified as "on-demand communications access". The later clarification
convinced me to avoid pairing terms like "access" and "capacity" in the title,
where access capacity might be misconstrued as a number of users, or sessions,
or something else we don't intend.

...
> 
> >> 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?
> >
> > [RG]+[acm] 1.  Internet access is no longer the bottleneck for many
> users, but subscribers expect network providers to honor contracted access
> performance.
> >
> > [acm] IOW, when you subscribe to a 1 Gbps service, then your ISP, you,
> and possibly other parties want to assure that performance level is
> delivered. If you test and confirm the subscribed performance level, then
> you can seek the location of the bottleneck elsewhere.
> 
> That context would be helpful to have in the document in some form, IMO.
[acm] 
Ok, added to the intro.

> 
...
> 
> > 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?
> >
> > [acm] "crude"?? Our algorithm has the advantage of receiver measurements of rate,
> > loss, and delay. So, we aren't making inferences based on ACKs, we communicate
> > measurement feedback instead.
> 
> Maybe I should have said "complex" :-)
[acm] 
That's closer, although it's 20 lines of pseudocode... wondering how that 
compares to CUBIC or BBR (and not stopping to look).
...

> >>
> >> -----------------------------------------------------------------------
> ---
> >> -----
> >> 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.
> >
> > Ok, thanks.  I would like to know which tool(s) you used (and if free,
> > even on a trial basis). Seemed to do a decent job.
> 
> https://github.com/larseggert/ietf-reviewtool
[acm] 
Thanks, I had tried the idcomments tool, once. I must not have been won-over.
I'll try yours at my next opportunity (which is probably already in my to-do
list).

Thanks again for your review!  We have Zahed's comments now and there will be a 
revised draft shortly.

Al