Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)

"MORTON, ALFRED C (AL)" <acm@research.att.com> Fri, 12 March 2021 03:16 UTC

Return-Path: <acm@research.att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895363A1C3B; Thu, 11 Mar 2021 19:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrqRteFNAALw; Thu, 11 Mar 2021 19:16:04 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EA13A1C33; Thu, 11 Mar 2021 19:16:04 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 12C3FkC9039192; Thu, 11 Mar 2021 22:15:55 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049297.ppops.net-00191d01. with ESMTP id 376yuv93uj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Mar 2021 22:15:54 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 12C3FrNc058658; Thu, 11 Mar 2021 21:15:53 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 12C3FluN058531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Mar 2021 21:15:47 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id 130CB4009E73; Fri, 12 Mar 2021 03:15:47 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30494.vci.att.com (Service) with ESMTP id C53474000693; Fri, 12 Mar 2021 03:15:46 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 12C3FkQv060679; Thu, 11 Mar 2021 21:15:46 -0600
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 12C3Fc95059896; Thu, 11 Mar 2021 21:15:39 -0600
Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-green.research.att.com (Postfix) with ESMTP id 40FF510A18C8; Thu, 11 Mar 2021 22:15:38 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0513.000; Thu, 11 Mar 2021 22:15:58 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "magnus.westerlund@ericsson.com" <magnus.westerlund@ericsson.com>
CC: "tpauly@apple.com" <tpauly@apple.com>, "ianswett@google.com" <ianswett@google.com>, "draft-ietf-ippm-capacity-metric-method@ietf.org" <draft-ietf-ippm-capacity-metric-method@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)
Thread-Index: AQHXC4EzqJ5daDOk8keYoMTRANvS6qpo9txggAGffICAACldMIAGGjkAgADI6CCAAuLjkIABA+eAgAAUJgCAAB+NgP//reVwgAS5AYCAAEW4oIAEopYAgABYSYCAAEA8QA==
Date: Fri, 12 Mar 2021 03:15:58 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF0147CACA0C@njmtexg5.research.att.com>
References: <161426272345.2083.7668347127672505809@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF01476A0C0E@njmtexg5.research.att.com> <66f367953ae838c8ba7505c60e51367843117787.camel@ericsson.com> <4D7F4AD313D3FC43A053B309F97543CF01476A0FE3@njmtexg5.research.att.com> <HE1PR0702MB3772A66E2C0409F5A69DC7DA95999@HE1PR0702MB3772.eurprd07.prod.outlook.com> <4D7F4AD313D3FC43A053B309F97543CF0147CA50DA@njmtexg5.research.att.com> <HE1PR0702MB377281B141FBB6D63015CC1895969@HE1PR0702MB3772.eurprd07.prod.outlook.com> <FRYP281MB01127EE4544CADF8B6E6E2E19C969@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <HE1PR0702MB37725A93AE2748D0619DB95D95969@HE1PR0702MB3772.eurprd07.prod.outlook.com> <4D7F4AD313D3FC43A053B309F97543CF0147CA565A@njmtexg5.research.att.com> <FRYP281MB01125B1728BCEF1D721B81EE9C939@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <4D7F4AD313D3FC43A053B309F97543CF0147CA9031@njmtexg5.research.att.com> <VI1PR0702MB37757902F5B59F99C5D8F24995909@VI1PR0702MB3775.eurprd07.prod.outlook.com> <FRYP281MB01124DAB19CA73818AE5F3759C909@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To: <FRYP281MB01124DAB19CA73818AE5F3759C909@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.234.13.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-12_01:2021-03-10, 2021-03-12 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 adultscore=0 mlxscore=0 spamscore=0 priorityscore=1501 phishscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103120020
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/w4-6vlSbYo0-RTNoxdQFN27dRqU>
Subject: Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 03:16:12 -0000

Hi Magnus,

In addition to Rudiger's questions, please see in-line replies from me.

Al
> -----Original Message-----
> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
> Sent: Thursday, March 11, 2021 11:32 AM
> To: magnus.westerlund@ericsson.com
> Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-
> metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
> iesg@ietf.org; MORTON, ALFRED C (AL) <acm@research.att.com>
> Subject: AW: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-
> metric-method-06: (with DISCUSS)
> 
> Hi Magnus,
> 
> Before going to discuss details some questions:
> 
> Would it help to insert text that person initiating test is required to
> parametrize an access bandwidth to be validated?
> I'm asking, as the intent of the draft might not be to capture a
> completely unknown access bandwidth (but I think it doesn't say so
> explicitely yet).
> 
> Do some of your comments address a concern that a test creates to much
> congestion during one feedback interval FT?
> That may stem from the idea, that we've exactly reached access bandwidth
> AB during FT and badly congest the access during FT+1 (I don't deny that
> this is possible).
> 
> If that's your concern, would an approach to limit the maximum congestion
> created before FT+1 is reached being bound to a limit
> Buffer_max[ms]@AB[Bit/s] based on the last captured congestion free
> bandwidth AB during FT?
> As an example, Buffer_max = 0,05 s if AB < 1 Gbit/s (smaller Buffer_max
> values may be applicable at higher rates). This would result in a formula
> determining the sending behaviour during st, rather than a table.
> 
> Regards,
> 
> Rüdiger
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Magnus Westerlund <magnus.westerlund@ericsson.com>
> Gesendet: Donnerstag, 11. März 2021 12:16
> An: acm@research.att.com; Geib, Rüdiger <Ruediger.Geib@telekom.de>
> Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-
> metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; iesg@ietf.org
> Betreff: RE: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-
> metric-method-06: (with DISCUSS)
> 
> Hi,
> 
> I have reviewed the text changes in context.
> 
> First of all I like to be clear that these changes do need review from the
> rest of the WG and a confirming consensus call as they are substantial.
> 
> Section 2.
> 
> I think the scope text is still fairly open. Yes it is clear that the load
> algorithm is only intended for measurements. However, the usage is not
> particular limited, especially in regards to my main concern of edge to
> central nodes across multiple AS in the Internet like the different TCP
> speed tests often are deployed. The security consideration requirements
> are good for a number of reasons but put no limitations on that aspect. So
> I would prefer a more explicit statement here. I think an important aspect
> here is that any ISP seeing issues from these measurements should know who
> to talk to. I don't know how to best formulate that.
> 
> 
> Section 8.1:
> 
> So I am trying to understand the implication of the load algorithm at
> higher rates and how recommendations works out in relation to the
> definition of the rate.
> 
> So the document says:
> 
>     Each rate is defined as
>    datagrams of size ss, sent as a burst of count cc, each time interval
>    tt (default for tt is 1ms, a likely system tick-interval)
> 
> So I think this definition is fine for lower rate as the number of packets
> in each 1 ms burst is fairly small and the buffer it hits will likely be
> relatively large compared to the increase in load. However at higher rates
> like beyond 10 GBPS where 1 GBPS steps are recommended. So transmitting at
> bursts every 1 ms intervals means that one are transmitting 833 packets
> each burst at 10 GBP rate of 1500 bytes size, so likely even higher for
> more moderate 1200 byte size packets. That is almost 1,3 mb of data. So
> where pacing may be quite good at lower bit-rates < 1Gbps I wonder if it
> starts breaking down at higher rates, which appears to in the region where
> buffers becomes more shallow due to the cost of having large buffers and
> where good pacing reduces the need for buffering. I would also note that
> the reaction time for the control can be 1RTT + 50 ms which thus the
> increase in offered load for a step size becomes 10s of MB during an
> regulation period.
> 
> As the load algorithm hasn't been tested beyond 10Gbps and it appears that
> the numbers can start to become more problematic at these speeds, wouldn't
> it be better to say that this is not intended beyond 10 Gbps.
> 
> On the table I have the following comments:
> 
>    +--------------+-------------+--------------+-----------------------+
>    | Parameter    | Default     | Tested Range | Expected Safe Range   |
>    |              |             | or values    | (not entirely tested, |
>    |              |             |              | other values NOT      |
>    |              |             |              | RECOMMENDED)          |
>    +--------------+-------------+--------------+-----------------------+
>    | FT, feedback | 50ms        | 20ms, 100ms  | 5ms <= FT <= 250ms    |
>    | time         |             |              | Larger values may     |
>    | interval     |             |              | slow the rate         |
>    |              |             |              | increase and fail to  |
>    |              |             |              | find the max          |
>    +--------------+-------------+--------------+-----------------------+
> 
> I would note that a FT of 5 ms will have the potential to result in
> significant fluxtuations in some systems like mobile systems as the
> scheduler time is actually likely to be longer than 5 ms.
[acm] 
Then we can increase the low end of the range, what value would you prefer??

> 
>    +--------------+-------------+--------------+-----------------------+
>    | Feedback     | L*FT, L=10  | L=100 with   | 0.5sec <= L*FT <=     |
>    | message      | (500ms)     | FT=50ms      | 30sec Upper limit for |
>    | timeout      |             | (5sec)       | very unreliable test  |
>    | (stop test)  |             |              | paths only            |
>    +--------------+-------------+--------------+-----------------------+
> 
> Even the default means that one looses 10 feedback packets in a row. That
> is a lot and shows that one have a serious interruption on the return
> path. Already loosing 3 feedback packets in a row indicates that one have
> significant outages if this is lost.
> 
> Secondly, this is formulated only based on  intervals of FT. For startup
> the RTT is relevant factor. So I think there are several factors here for
> the timeout that maybe need to be teased apart? So initially one offers a
> very low load and one may not have a good measurement on base RTT. 
[acm] 
All the timeouts are conducted on inter-packet arrival times at a single interface.
This removes the dependency on RTT. 

> Thus, time to first feedback is okay to be fairly large and 500 ms is likely
> okay but quite longer than expected for an access to local internet
> exchange measurement. However, when one scale up the rate I think these
> values are way to long as the total amount of traffic sent without
> feedback becomes quite significant. Receiving no feedback for more than 10
> reporting intervals are already way to long. And to state that 30 seconds
> would be an acceptable value I can't support even for a measurement tool.
[acm] 
We are willing to revise values, especially 30 sec, but would like to avoid 
prematurely shutting down measurements due to (what we consider to be)
short interruptions.

> 
> The definition of what "Feedback message timeout" and "Load packet
> Timeout" is not defined. I assume that Feedback message timeout is the
> time without receiving any feedback messages after starting a measurement.
[acm] 
That's close:
Operation: The load packet timeout SHALL be reset to the configured value 
each time a load packet received. If the timeout expires, the receiver 
SHALL be closed and no further feedback sent.


> Is the load packet timeout the time the receiver is waiting before using
> signalling channel to end the measurement without receiving any packets,
> or for the sender to receive feedback that says that no packets have been
> received? The roles here are not clear.
[acm] 
Operation: The feedback message timeout SHALL be reset to the configured 
value each time a feedback message is received. If the timeout expires, 
the sender SHALL be closed and no further load packets sent.

> 
> Sending packets for several seconds without seeing any result appears
> problematic and allowing values beyond several seconds looks broken.
[acm] 
Then let us make some revisions together. You've seen our proposals.
Our concern is stopping a test unnecessarily. There can be a happy 
conclusion.


> 
>    +--------------+-------------+--------------+-----------------------+
>    | table index  | 0.5Mbps     | 0.5Mbps      | when testing <=10Gbps |
>    | 0            |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
>    | table index  | 1Mbps       | 1Mbps        | when testing <=10Gbps |
>    | 1            |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
> 
> Why is this value not relevant when testing beyond 10 Gbps, the ramp up
> time becomes to long with these values or?
[acm] 
"not relevant" is different from the title of the column, which is:

Expected Safe Range:  when testing <=10Gbps

The parameters above and several others simply determine where a test starts.

This parameter:
+--------------+-------------+--------------+-----------------------+
| table index  | 1Mbps       | 1Mbps -      | same as tested        |
| (step) size  |             | 1Gbps        |                       |
+--------------+-------------+--------------+-----------------------+  

> 
> 
>    | ss, UDP      | none        | <=1222       | Recommend max at      |
>    | payload      |             |              | largest value that    |
>    | size, bytes  |             |              | avoids fragmentation  |
>    +--------------+-------------+--------------+-----------------------+
> 
> So isn't there a mismatch between the metric and the load algorithm values
> here? With the rate definition in Section 8.1 being defined as based on
> "ss" that UDP payload bytes, rather than IP packet sizes that are used?
[acm] 

Not really, UDP is mandatory in the metric definition.

> 
> I understand that one want to ensure that one measure using a size that
> actually works in the path. However, I think one should be warned that one
> might run into packet rate limitations rather than byte limits if one
> would use too small.
[acm] 
Ok
"Use of too-small payload size might result in unexpected sender limitations."

> `
>    +--------------+-------------+--------------+-----------------------+
>    | cc, burst    | none        | 1 - 100      | same as tested        |
>    | count        |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
> 
> So the cc value is dependent on target rate and the value of ss and tt. So
> should it be included in this table? Especially as 100 is not sufficient
> for multi-gigabit speeds with a tt of 1 ms.
[acm] 
We can remove it if the values cause confusion.

> 
>    +--------------+-------------+--------------+-----------------------+
>    | low delay    | 30ms        | 5ms, 30ms    | same as tested        |
>    | range        |             |              |                       |
>    | threshold    |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
> 
> So I think this value is highly dependent on several aspects and maybe
> should get more discussion. First for a measurement campaign it is
> relevant what one consider as the target additional latency that is
> acceptable when finding capacity. Secondly, the jitter in the network
> technology. For WIFI,  mobile and DOCIS a to low value may be shorter than
> the scheduling latencies that might occur. It is also a question about how
> precise the implementation are capable of measuring per packet latency
> variances.
[acm] 
As we discussed much earlier in this long thread, we arrived at both the 
delay threshold values after testing with the WIFI, mobile and DOCIS access
services we could use in production, and many others.


> 
>    +--------------+-------------+--------------+-----------------------+
>    | high delay   | 90ms        | 10ms, 90ms   | same as tested        |
>    | range        |             |              |                       |
>    | threshold    |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
> 
> Also here I wished there was a bit more discussion. So this value clearly
> must be above expected jitter for the network technology. It also needs to
> be sufficient large to represent a fair amount of queue to avoid
> measurement errors. I assume that if one would chose a value larger than
> available buffer depth one would drive the network into packet loss. And
> as long as there are some room between low delay range threshold and the
> actual delay causing loss or this higher one has a chance to regulate to
> that rate.
> 
>    +--------------+-------------+--------------+-----------------------+
>    | sequence     | 0           | 0, 100       | same as tested        |
>    | error        |             |              |                       |
>    | threshold    |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
> 
> What is this value really?
[acm] 
When loss or reordering occur, initially these impairments appear as missing 
or unexpected sequence numbers in the stream, or sequence errors.


> 
>    +--------------+-------------+--------------+-----------------------+
>    | consecutive  | 2           | 2            | Use values >1 to      |
>    | errored      |             |              | avoid misinterpreting |
>    | status       |             |              | transient loss        |
>    | report       |             |              |                       |
>    | threshold    |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
> 
> Also here I am uncertain what is the criteria here?
[acm] 
From the draft, where consecutive status reports are sent at feedback intervals:

   Lastly, the method for inferring congestion is that there were
   sequence number anomalies AND/OR the delay range was above the upper
   threshold for two consecutive feedback intervals.

> 
>    +--------------+-------------+--------------+-----------------------+
>    | Fast mode    | 30          | 3 * Fast     | same as tested        |
>    | decrease, in |             | mode         |                       |
>    | table index  |             | increase     |                       |
>    | steps        |             |              |                       |
>    +--------------+-------------+--------------+-----------------------+
> 
> So is the recommended value 30 or 3*Fast mode increase? Should they be
> proportional or not?
[acm] 
The Default can be 3 * Fast mode increase if you want, that's what we tested.

> 
> The last entry appears to be a summary fact of the parameterization, and
> is it relevant?
[acm] 
It might be removed, we thought it was useful info.
> 
> 
> What is the goal here in relation to push other congestion controlled
> traffic out of the way? It appears that it is likely to cause delay based
> congestion to be pushed out of the way. I am more uncertain how it
> interacts with loss based ones, as depending on situation it appears that
> it could avoid going into the loss regim.
[acm] 
The goal is to measure the true maximum rate during the test duration.

> 
> My conclusion is that some aspect of this do appear more clarifications on
> what they are 
[acm] 
These ASCII tables don't provide much space for explanation without becoming
awkward due to row height.  We'll add some definitions elsewhere.

> and further assumptions on how the load algorithm will be
> deployed spelled out so that its function is more controlled.
[acm] 
We could use some text suggestions to continue the discussion productively, 
having already tried several times.

thanks,
Al

> 
> Cheers
> 
> Magnus
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: MORTON, ALFRED C (AL) <acm@research.att.com>
> > Sent: den 8 mars 2021 18:33
> > To: Ruediger.Geib@telekom.de; Magnus Westerlund
> > <magnus.westerlund@ericsson.com>
> > Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-
> > metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
> > iesg@ietf.org
> > Subject: RE: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-
> > metric-method-06: (with DISCUSS)
> >
> > Hi all,
> >
> > The working text was just submitted as version 07. [0] We can continue
> > discussions from this point.
> >
> > Thanks again for all the IESG reviews!
> >
> > Al (for the co-authors)
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-ietf-ippm-capacity-
> metric-
> > method
> >
> >
> > > -----Original Message-----
> > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
> > > Sent: Monday, March 8, 2021 3:19 AM
> > > To: MORTON, ALFRED C (AL) <acm@research.att.com>;
> > > magnus.westerlund@ericsson.com
> > > Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-
> > > metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
> > > iesg@ietf.org
> > > Subject: AW: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-
> > > metric-method-06: (with DISCUSS)
> > >
> > > Hi Al, hi Magnus,
> > >
> > > To make progress within the time left, it's likely best to leave
> > > things as they are. That produces a standard and a benchmark. A cross
> > > domain deployment may be tested against that benchmark to gain more
> > > experience on operational aspects.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: MORTON, ALFRED C (AL) <acm@research.att.com>
> > > Gesendet: Freitag, 5. März 2021 14:22
> > > An: Magnus Westerlund <magnus.westerlund@ericsson.com>; Geib,
> > Rüdiger
> > > <Ruediger.Geib@telekom.de>
> > > Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-
> > > metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
> > > iesg@ietf.org
> > > Betreff: RE: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-
> > > metric-method-06: (with DISCUSS)
> > >
> > > Hi Magnus and Rüdiger,
> > >
> > > The working text on the "applicability" limits that we added to the
> > > scope section *included an earlier agreement* to add the first
> > > sentence below and the bullet, so now the whole paragraph reads:
> > >
> > >    The primary application of the metric and method of measurement
> > >    described here is the same as in Section 2 of [RFC7479] where:
> > >
> > >    o  The access portion of the network is the focus of this problem
> > >       statement.  The user typically subscribes to a service with
> > >       bidirectional access partly described by rates in bits per
> second.
> > >
> > >    In addition, the use of the load adjustment algorithm described in
> > >    section 8.1 has the following additional applicability limitations:
> > >
> > >    - MUST only be used in the application of diagnostic and operations
> > >    measurements as described in this memo
> > >
> > >    - MUST only be used in circumstances consistent with Section 10,
> > >    Security Considerations
> > >
> > > We can make further edits to balance your comments but let's start
> > > here, and sorry for not including the whole paragraph last night - it
> > > seems that I should have.
> > >
> > > Al
> > >
> > > > -----Original Message-----
> > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> > > > Sent: Friday, March 5, 2021 8:06 AM
> > > > To: Ruediger.Geib@telekom.de
> > > > Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-
> > > > metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
> > > > iesg@ietf.org; MORTON, ALFRED C (AL) <acm@research.att.com>
> > > > Subject: RE: Magnus Westerlund's Discuss on
> > > > draft-ietf-ippm-capacity-
> > > > metric-method-06: (with DISCUSS)
> > > >
> > > > Hi,
> > > >
> > > > Ruediger, if you can find a formulation that covers that national
> > > > test case I am likely fine with it. If the involved parties know who
> > > > to discuss issues with and can get them addressed I am not worried.
> > > > I am worried where someone deploys a couple of servers, like the
> > > > current TCP speed tests and users run it totally by themselves.
> > > >
> > > > And to be clear I think with more experience with large scale
> > > > deployment of the algorithm and more experiments beyond the
> > intended
> > > > deployment model this should be possible to update the specs to
> > > > remove this type of limitation.
> > > >
> > > > Cheers
> > > >
> > > > Magnus
> > > >
> > > > > -----Original Message-----
> > > > > From: Ruediger.Geib@telekom.de <Ruediger.Geib@telekom.de>
> > > > > Sent: den 5 mars 2021 12:13
> > > > > To: Magnus Westerlund <magnus.westerlund@ericsson.com>
> > > > > Cc: tpauly@apple.com; ianswett@google.com;
> > > > > draft-ietf-ippm-capacity- metric-method@ietf.org;
> > > > > ippm-chairs@ietf.org; ippm@ietf.org; iesg@ietf.org;
> > > > > acm@research.att.com
> > > > > Subject: AW: Magnus Westerlund's Discuss on
> > > > > draft-ietf-ippm-capacity-
> > > > > metric-method-06: (with DISCUSS)
> > > > >
> > > > > <snip>
> > > > >
> > > > > I think this is a bit to unclear in regards to the limitation of
> > > scope.
> > > > My
> > > > > worry are internet wide measurements. Reading what exists in the
> > > > currently
> > > > > available draft in the Section 10, there are no limitation here
> > > > described to
> > > > > only use this algorithm only across controlled networks.
> > > > > Especially as bullet
> > > > > 5 in Section 10 relies on the load algorithm what is currently
> > > > > written
> > > > is
> > > > > fine
> > > > > across the whole internet as long as sender and receiver are okay
> > > > > with
> > > > the
> > > > > measurement which is not what I at least thought we agreed.
> > > > >
> > > > > Can you please be explicit that the load algorithm is limited to
> > > > > use
> > > > across
> > > > > networks path that are controlled or managed and not intended for
> > > > Internet
> > > > > wide usage.
> > > > >
> > > > >  - MUST only be used as part of measurements within managed
> > > > > networks, and not across general Internet.
> > > > >
> > > > > [RG] That's tough, as regulators are interested in this test and
> > > > regulators
> > > > > aren't part of a domain. So they might resort to TCP speed tests,
> > > > > being
> > > > less
> > > > > accurate and precise and not standardised (note that penalties are
> > > > discussed
> > > > > to be linked to results). I'd be interested in finding agreement
> > > > > to have metric and method standardized for at least nations under
> > > > > authority of a single regulator. No idea how exactly. Would a
> > > > > bound on RTT/in some countries multiple instances and some
> > > > > additional parametrization information prior
> > > > to
> > > > > start, e.g., a contracted access bandwidth, help?
> > > > >
> > > > > [RG] I'm off for the weekend (I'm out for a lasting solution, not
> > > > > necessarily a speedy one) - regards,
> > > > >
> > > > > Ruediger