Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness

From: Marcus Ihlar <[email-masked]>
Date: Mon, 6 Dec 2021 15:52:58 +0000

Hi IPPM,

This email starts an adoption call for draft-cpaasch-ippm-responsiveness, "Responsiveness under Working Conditions". This document specifies the "RPM Test" for measuring user experience when the network is fully loaded. The intended status of the document is Experimental.

https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/

https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01

This adoption call will last until Monday, December 20. Please review the document, and reply to this email thread to indicate if you think IPPM should adopt this document.

BR,

Marcus

---

From: "MORTON JR., AL" <[email-masked]>
Date: Fri, 17 Dec 2021 23:50:47 +0000

Hi authors and ippm-chairs,

Thanks for writing this-up!

I took one pass through, and have the following comments during Adoption call for draft-cpaasch-ippm-responsiveness:

TL;DR:
Many previously undefined terms were used here, and a more direct description using the term "saturation" seems possible, IMO. IPPM has used a template for metric drafts, and use of the hierarchy of singleton, sample, and statistic metrics from RFC 2330 will help with clarity/answer many of my questions.

regards (I'm off-line for a while now, so enjoy the holidays),
Al

>From the Abstract:

   This document specifies the "RPM Test" for measuring responsiveness.
   It uses common protocols and mechanisms to measure user experience
   especially when the network is fully loaded ("responsiveness under
   working conditions".)  The measurement is expressed as "Round-trips
   Per Minute" (RPM) and should be included with throughput (up and
   down) and idle latency as critical indicators of network quality.

"fully loaded" and "working conditions" aren't necessarily the same, to me.  I'll be looking for better definitions.

3<https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-3>.  Goals

   The algorithm described here defines an RPM Test that serves as a

   good proxy for user experience.  This means:

   1.  Today's Internet traffic primarily uses HTTP/2 over TLS.  Thus,

       the algorithm should use that protocol.

       As a side note: other types of traffic are gaining in popularity

       (HTTP/3) and/or <???? UDP ???> are already being used widely (RTP).

There are many measurement stability challenges when TCP is involved, see section 4 of RFC8337:  https://datatracker.ietf.org/doc/html/rfc8337#section-4
RFC8337 intentionally broke the TCP control loop to make measurements in the face of these challenges.

4.1<https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.1>.  Working Conditions

   For the purpose of this methodology, typical "working conditions"

   represent a state of the network in which the bottleneck node is

   experiencing ingress and egress flows similar to those created by

   humans in the typical day-to-day pattern.

   While a single HTTP transaction might briefly put a network into

   working conditions, making reliable measurements requires maintaining

   the state over sufficient time.

   The algorithm must also detect when the network is in a persistent

   working condition, also called "saturation".

   Desired properties of "working condition":

   o  Should not waste traffic, since the person may be paying for it

   o  Should finish within a short time to avoid impacting other people

      on the same network, to avoid varying network conditions, and not

      try the person's patience.

These seem like reasonable goals for the traffic that loads the network.
New terms needing definition were introduced:
"persistent working condition = saturation",
which is different from
"ingress and egress flows similar to those created by humans in the typical day-to-day pattern"

Later in 4.1.1, terms like "saturate a path"  and "fill the pipe" appear, and

   The goal of the RPM Test is to keep the network as busy as possible

   in a sustained and persistent way.  It uses multiple TCP connections

   and gradually adds more TCP flows until saturation is reached.

The terms "busy as possible", and "typical day-to-day pattern", or
"saturation" and "working conditions" indicate different load levels to me.

@@@@ Suggestion: I think it would help to simplify the terminology in this draft. You intend to measure a saturated path, so just say that. No "typical", no "working conditions", etc., in these early sections.

The sentence beginning "The goal..." should really appear in Section 3. Goals

Also, you have defined a measurement method in the sentence, "It uses..." above. This method of adding connections has been observed in other measurement systems, but it isn't typical of user traffic, especially when each connection has an ~infinite amount of data to send during the test.

4.1.2<https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.1.2>.  Parallel vs Sequential Uplink and Downlink

...

   To measure responsiveness under working conditions, the algorithm

   must saturate both directions.

Bi-directional saturation is really atypical of usage. I don't think the benefit of "more data" pays off.

...

   However, a number of caveats come with measuring in parallel:

   o  Half-duplex links may not permit simultaneous uplink and downlink

      traffic.  This means the test might not saturate both directions

      at once.

   o  Debuggability of the results becomes harder: During parallel

      measurement it is impossible to differentiate whether the observed

      latency happens in the uplink or the downlink direction.

   o  Consequently, the test should have an option for sequential

      testing.

@@@@ Suggestion: IMO, tests/results with Downlink saturation OR Uplink saturation would be more straightforward, and can be understood by users (especially those who have tested in the past). Avoid the pitfalls and make Sequential testing the preferred option.

4.1.3<https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.1.3>.  Reaching saturation

   The RPM Test gradually increases the number of TCP connections and

   measures "goodput" - the sum of actual data transferred across all

   connections in a unit of time.  When the goodput stops increasing, it

   means that saturation has been reached.

...

   Filling buffers at the bottleneck depends on the congestion control

   deployed on the sender side.  Congestion control algorithms like BBR

   may reach high throughput without causing queueing because the

   bandwidth detection portion of BBR effectively seeks the bottleneck

   capacity.

   RPM Test clients and servers should use loss-based congestion

   controls like Cubic to fill queues reliably.

With the evolution of Congestion control algorithms seeking to avoid filling buffers, does it make sense to require a full buffer at the bottleneck to achieve saturation?

In fact, the definition above, "When the goodput stops increasing,..." does not require full buffers; it requires maximizing a delivery rate measurement instead.

In 4.1.4, the final steps of the algorithm were not clear to me:

      *  Else, network reached saturation for the current flow count.

@@@@ This wording implies it to be the final step, but there are further conditions to test.

     Maybe this step is "Else, Candidate for stable saturation"?

         +  If new flows added and for 4 seconds the moving average

            throughput did not change: network reached stable saturation

@@@@ Maybe:

         +  If the 4 second moving average of "instantaneous aggregate goodput" with no new

            flows added did not change

            (defined as: moving average = "previous" moving average +/- 5%),

            then the network reached stable saturation

----------------------------------------------------------------------------------------------------

         +  Else, add four more flows

@@@ ??? and return to start?

Finally, in 4.1.4, the Note explains:

   Note: It is tempting to envision an initial base RTT measurement and

   adjust the intervals as a function of that RTT.  However, experiments

   have shown that this makes the saturation detection extremely

   unstable in low RTT environments.  In the situation where the

   "unloaded" RTT is in the single-digit millisecond range, yet the

   network's RTT increases under load to more than a hundred

   milliseconds, the intervals become much too low to accurately drive

   the algorithm.

Well, TCP senders/control-loops are involved here, and likely play a
role in behavior categorized as "difficult to measure".

By the time we get to

4.2<https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.2>.  Measuring Responsiveness

   Once the network is in a consistent working conditions, the RPM Test

   must "probe" the network multiple times to measure its

   responsiveness.

   Each RPM Test probe measures:

You previously started at least four TCP connections with infinitely large files.
The "create connection" RPM probes establish additional connections, DNS, TCP, etc.
Is each new connection an RPM probe? or is the set of connection tests a single probe?
(later we learn it is the set of
What if one of the set of connections fails/times-out?

I take it that the "load-bearing" connections are driving the path to saturation.
Maybe "load-generating connections" is more clear?

4.2.1<https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.2.1>.  Aggregating the Measurements

   The algorithm produces sets of 5 times for each probe, namely: DNS

   handshake, TCP handshake, TLS handshake, HTTP/2 request/response on

   separate (idle) connections, HTTP/2 request/response on load bearing

   connections.  This fine-grained data is useful, but not necessary for

   creating a useful metric.

@@@@ So, only ONE of the load-generating connections runs the 1-byte GET ?  (it says connections, and there are at least 4) The various handshakes result in 4 RT measurements.

But, do you mean *5 repeated measurement sets*? Each set with:

DNS HS, TCP HS, TLS HS, HTTP/2 idle GET, and the potentially much longer GET on the

load generating connections.

   To create a single "Responsiveness" (e.g., RPM) number, this first

   iteration of the algorithm gives an equal weight to each of these

   values.  That is, it sums the five time values for each probe, and

   divides by the total number of probes to compute an average probe

   duration.  The reciprocal of this, normalized to 60 seconds, gives

   the Round-trips Per Minute (RPM).

@@@@ I'm missing a step, I think:

Are the "time values for each probe" the sum of handshake or response times for

DNS HS, TCP HS, TLS HS, HTTP/2 idle GET and load generating connections?

The processing doesn't seem to include this preliminary calculation to produce

"five time values".

In Section 5, "no new protocol is defined", but

   The client begins the responsiveness measurement by querying for the

   JSON configuration.  This supplies the URLs for creating the load

   bearing connections in the upstream and downstream direction as well

   as the small object for the latency measurements.

The client needs to know how the server response will be organized, down to key: value, right?
Some client and server agreements needed...

From: ippm <[email-masked]> On Behalf Of Marcus Ihlar
Sent: Monday, December 6, 2021 10:53 AM
To: [email-masked]
Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness

Hi IPPM,

https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/__;!!BhdT!zI6d5je1i8cafA6NXByD5tvxHFKKPMjYgtM6t2aLUHFPsyPz-XwPFguwa1HS$>
https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01__;!!BhdT!zI6d5je1i8cafA6NXByD5tvxHFKKPMjYgtM6t2aLUHFPsyPz-XwPFq67PfWg$>

BR,
Marcus

---

From: Matt Mathis <[email-masked]>
Date: Sun, 19 Dec 2021 19:38:45 -0800

I support this draft, and I have even offered to be a co-author.

Thank you  Al. for the extensive comments.   I only have a moment for some
high level responses:

In some sense this document  is opposite of RFC8337.  Responsiveness is
about measuring the how well/early the bottleneck signals congestion to the
transport without incurring excessive queueing.   This not only depends on
the loop behavior of the bottleneck and the measurement stream, it also
depends on the loop behavior, population and RTT's of the cross traffic.
 I do not expect any of the theory to be mature enough to be able to do any
of this as abstractly as IPPM does with most metrics.   At this time I
expect a responsiveness metric to require fingerprinting the hardware, OS
and application software, and include a warning that results may be
sensitive to the details of the implementation.

WiFi is a poorly modeled half duplex shared broadcast channel, that is a
critical (dominant?) part of the responsiveness for typical Internet
users.     Bidirectional traffic matters a lot, but I fear the scope might
be too broad.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.

On Fri, Dec 17, 2021 at 3:51 PM MORTON JR., AL <[email-masked]> wrote:

> I took one pass through, and have the following comments during Adoption
> call for draft-cpaasch-ippm-responsiveness:
>
>
>
> TL;DR:
>
> Many previously undefined terms were used here, and a more direct
> description using the term “saturation” seems possible, IMO. IPPM has used
> a template for metric drafts, and use of the hierarchy of singleton,
> sample, and statistic metrics from RFC 2330 will help with clarity/answer
> many of my questions.
>
>
>
> regards (I’m off-line for a while now, so enjoy the holidays),
>
> Al
>
>
>
> From the Abstract:
>
>
>
>    *especially when the network is fully loaded ("responsiveness under*
>
> *   working conditions"*.)  The measurement is expressed as "Round-trips
>
> “fully loaded” and “working conditions” aren’t necessarily the same, to me.
> I’ll be looking for better definitions.
>
>
>
> 3 <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-3>.  Goals
>
>
>
>        (HTTP/3) and/or *<???? UDP ???>* are already being used widely (RTP).
>
>
>
> There are many measurement stability challenges when TCP is involved, see
> section 4 of RFC8337:
> https://datatracker.ietf.org/doc/html/rfc8337#section-4
>
> 4.1 <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.1>.  Working Conditions
>
>
>
> “persistent working condition = saturation”,
>
> which is different from
>
> “ingress and egress flows similar to those created by humans in the
> *typical* day-to-day pattern”
>
>
>
> Later in 4.1.1, terms like “saturate a path”  and “fill the pipe” appear,
> and
>
>
>
>    *The goal of the RPM Test is to keep the network as busy as possible*
>
> The terms “busy as possible”, and “typical day-to-day pattern”, or
>
> “saturation” and “working conditions” indicate different load levels to me.
>
>
>
> @@@@ Suggestion: I think it would help to simplify the terminology in this
> draft. You intend to measure a saturated path, so just say that. No
> “typical”, no “working conditions”, etc., in these early sections.
>
>
>
> The sentence beginning “The goal...” should really appear in Section 3.
> Goals
>
>
>
> Also, you have defined a measurement method in the sentence, “It uses...”
> above. This method of adding connections has been observed in other
> measurement systems, but it isn’t typical of user traffic, especially when
> each connection has an ~infinite amount of data to send during the test.
>
>
>
> 4.1.2 <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.1.2>.  Parallel vs Sequential Uplink and Downlink
>
>
>
> ...
>
> Bi-directional saturation is really atypical of usage. I don’t think the benefit of “more data” pays off.
>
>
>
> ...
>
>
>
> @@@@ Suggestion: IMO, tests/results with Downlink saturation OR Uplink
> saturation would be more straightforward, and can be understood by users
> (especially those who have tested in the past). Avoid the pitfalls and make
> Sequential testing the preferred option.
>
>
>
>
>
> 4.1.3 <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.1.3>.  Reaching saturation
>
>
>
> In fact, the definition above, “When the goodput stops increasing,...” does not require full buffers; it requires maximizing a delivery rate measurement instead.
>
>
>
>
>
>      Maybe this step is “Else, Candidate for stable saturation”?
>
>
>
> role in behavior categorized as “difficult to measure”.
>
>
>
> By the time we get to
>
>
>
> 4.2 <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.2>.  Measuring Responsiveness
>
>
>
> The “create connection” RPM probes establish additional connections, DNS,
> TCP, etc.
>
> I take it that the “load-bearing” connections are driving the path to
> saturation.
>
> Maybe “load-generating connections” is more clear?
>
>
>
> 4.2.1 <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01#section-4.2.1>.  Aggregating the Measurements
>
>
>
> But, do you mean **5 repeated measurement sets**? Each set with:
>
> @@@@ I’m missing a step, I think:
>
> Are the “time values for each probe” the sum of handshake or response times for
>
> The processing doesn’t seem to include this preliminary calculation to produce
>
> “five time values”.
>
>
>
>
>
> In Section 5, “no new protocol is defined”, but
>
>
>
> *From:* ippm <[email-masked]> *On Behalf Of *Marcus Ihlar
> *Sent:* Monday, December 6, 2021 10:53 AM
> *To:* [email-masked]
> *Subject:* [ippm] Adoption call for draft-cpaasch-ippm-responsiveness
>
>
>
> Hi IPPM,
>
>
>
> This email starts an adoption call for draft-cpaasch-ippm-responsiveness,
> "Responsiveness under Working Conditions”. This document specifies the “RPM
> Test” for measuring user experience when the network is fully loaded. The
> intended status of the document is Experimental.
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/__;!!BhdT!zI6d5je1i8cafA6NXByD5tvxHFKKPMjYgtM6t2aLUHFPsyPz-XwPFguwa1HS$>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01__;!!BhdT!zI6d5je1i8cafA6NXByD5tvxHFKKPMjYgtM6t2aLUHFPsyPz-XwPFq67PfWg$>
>
>
>
> This adoption call will last until *Monday, December 20*. Please review
> the document, and reply to this email thread to indicate if you think IPPM
> should adopt this document.
>
>
>
> BR,
>
> Marcus
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: "Hawkins III, William (hawkinwh)" <[email-masked]>
Date: Mon, 20 Dec 2021 20:58:13 +0000

(Forgive the top posting)

My name is Will Hawkins and I am a professor at the University of Cincinnati and former researcher at MeasurementLab who is working with the draft's authors. I have independently implemented a client for this draft protocol (https://github.com/hawkinsw/goresponsiveness). I am working closely with the draft's authors to refine the standard and I strongly support adopting this draft.

I hope that this message is appropriate.

Will

________________________________________
From: Christoph Paasch <[email-masked]>
Sent: Monday, December 20, 2021 3:51 PM
To: Hawkins III, William (hawkinwh)
Subject: Fwd: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness

Begin forwarded message:

From: Marcus Ihlar <marcus.ihlar=[email-masked]<mailto:marcus.ihlar=[email-masked]>>
Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness
Date: December 6, 2021 at 7:52:58 AM PST
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fippm.ietf.org%2F&data=04%7C01%7Chawkinwh%40ucmail.uc.edu%7Cce7eb2d69a9f47e012fc08d9c3fa77c0%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C637756302812695180%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LSs70lhEFzy0Qvs0V7a4fN8kJpRjafgkvHVWgDGITKc%3D&reserved=0>>

Hi IPPM,

This email starts an adoption call for draft-cpaasch-ippm-responsiveness, "Responsiveness under Working Conditions”. This document specifies the “RPM Test” for measuring user experience when the network is fully loaded. The intended status of the document is Experimental.

https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cpaasch-ippm-responsiveness%2F&data=04%7C01%7Chawkinwh%40ucmail.uc.edu%7Cce7eb2d69a9f47e012fc08d9c3fa77c0%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C637756302812695180%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vM6kh8t%2FVRIziHMCoWxkO87ySCCghtmTMDdDvX0UZyk%3D&reserved=0>
https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-cpaasch-ippm-responsiveness-01&data=04%7C01%7Chawkinwh%40ucmail.uc.edu%7Cce7eb2d69a9f47e012fc08d9c3fa77c0%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C637756302812695180%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=38XGB57Wii%2BKlS5bvvlFesWQqZoOOYgH0pqYIDmbSTQ%3D&reserved=0>

BR,
Marcus

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=04%7C01%7Chawkinwh%40ucmail.uc.edu%7Cce7eb2d69a9f47e012fc08d9c3fa77c0%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C637756302812695180%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6K2LZa8vxwIeAIBhUUJlMjl56NHiI0reFrjU1Qa1DxI%3D&reserved=0>

---

From: <[email-masked]>
Date: Thu, 23 Dec 2021 07:16:54 +0000

Hi Marcus,

Noting that some more work needs to be added, I support adoption.

Some comments:
- I'd appreciate if the draft was covering expectable operational scenarios, namely
  * There may be no bottleneck buffer - the test/metric needs to detect that and act appropriate.
  * One might be interested in the metric while the test adds an insignificant load only. While receiver tries to consume service X, what's the metric seen from Y? 
     (may help to clarify, whether the access causes trouble or another network section).

- Measuring the maximum RPM as seen from the test server is part of the test or it isn't? That's not clear to me by now.
  I'm favouring to make measuring the maximum RPM part of the test, this may help to scale results.

- The test set-up should prevent application as DoS attack tool.

Regards,

Ruediger

From: Marcus Ihlar <[email-masked] >
Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness
Date: December 6, 2021 at 7:52:58 AM PST
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
List-Id: IETF IP Performance Metrics Working Group 

Hi IPPM,

BR,
Marcus

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Dec 2021 23:43:50 -0800

Dear Marcus, Authors, et al,
apologies for the belated response.
I've read the draft and have some comments to share with you:

   - as I understand it, the proposed new responsiveness metric is viewed
   as the single indicator of a bufferbloat condition in a network. As I
   recall, the discussion at Measuring Network Quality for End-Users workshop
   and on the mailing list
   <https://mailarchive.ietf.org/arch/browse/network-quality-workshop/?gbt=1&index=cuW_1lh4DD22V28EvlPFB_NjjZY>
   indicated, that there’s no consensus on what behaviors, symptoms can
   reliably signal the bufferbloat. It seems that it would be reasonable to
   first define what is being measured, characterized by the responsiveness
   metric. Having a document that discusses and defines the bufferbloat would
   be great.
   - It seems like in the foundation of the methodology described in the
   draft lies the assumption that without adding new flows the
   available bandwidth is constant, does not change. While that is mostly the
   case, there are technologies that behave differently and may change
   bandwidth because of the outside conditions. Some of these behaviors of
   links with variable discrete bandwidth are discussed in, for example, RFC
   8330 <https://datatracker.ietf.org/doc/rfc8330/> and RFC 8625
   <https://datatracker.ietf.org/doc/rfc8625/>.
   - Then, I find the motivation not to use time units to express the
   responsiveness metric not convincing:

   "Latency" is a poor measure of responsiveness, since it can be hard
   for the general public to understand.  The units are unfamiliar
   ("what is a millisecond?") and counterintuitive ("100 msec - that
   sounds good - it's only a tenth of a second!").

I would appreciate these topics being discussed and addressed in the draft
before it is adopted by the WG.

Regards,
Greg

---

From: Dave Taht <[email-masked]>
Date: Thu, 23 Dec 2021 07:40:34 -0800

I support adoption. My concerns are that I do not know if a single
metric is achievable, and also the methods created SHOULD try to find
the bottleneck link. I'd like open source software created along the
way (the apple effort which I applaud has released the server side) to
explore the issues.

On Wed, Dec 22, 2021 at 11:44 PM Greg Mirsky <[email-masked]> wrote:
> as I understand it, the proposed new responsiveness metric is viewed as the single indicator of a bufferbloat condition in a network. As I recall, the discussion at Measuring Network Quality for End-Users workshop and on the mailing list indicated, that there’s no consensus on what behaviors, symptoms can reliably signal the bufferbloat. It seems that it would be reasonable to first define what is being measured, characterized by the responsiveness metric. Having a document that discusses and defines the bufferbloat would be great.
> It seems like in the foundation of the methodology described in the draft lies the assumption that without adding new flows the available bandwidth is constant, does not change. While that is mostly the case, there are technologies that behave differently and may change bandwidth because of the outside conditions. Some of these behaviors of links with variable discrete bandwidth are discussed in, for example, RFC 8330 and RFC 8625.
> Then, I find the motivation not to use time units to express the responsiveness metric not convincing:
>
> I would appreciate these topics being discussed and addressed in the draft before it is adopted by the WG.
>
> Regards,
> Greg
>
> On Mon, Dec 6, 2021 at 7:53 AM Marcus Ihlar <marcus.ihlar=[email-masked]> wrote:
>>
>> Hi IPPM,
>>
>>
>>

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC