Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Livingood, Jason]

[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]

Yes, he is the colleague to whom I referred. ;-) Anyway – appreciate all the input as I try out some new terminology on laypeople. So far working latency seems to be more comprehensible for folks but we shall see.

JL

From: Greg White <g.white@CableLabs.com>
Date: Tuesday, May 11, 2021 at 5:26 PM
To: Jonathan Foulkes <jf@jonathanfoulkes.com>, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: [EXTERNAL] Re: [Bloat] Terminology for Laypeople

I recently heard Stuart Cheshire (sort of tongue-in-cheek) refer to “idle latency” as “the latency that users experience when they are not using their internet connection” (or something along those lines).

I think terminology that reinforces that the baseline (unloaded) latency is not always what users experience, and that latency under load is not referring to some unusual corner-case situation, is good.  So, I like “idle latency” and “working latency”.

-Greg



From: Bloat <bloat-bounces@lists.bufferbloat.net> on behalf of Jonathan Foulkes <jf@jonathanfoulkes.com>
Date: Monday, May 10, 2021 at 2:10 PM
To: Jason Livingood <Jason_Livingood@comcast.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Terminology for Laypeople

Hi Jason,

I’ve found that idle is a good descriptor for unloaded metrics, and for semi-technical audiences ‘working’ is a very good term. But for lay people, the term ‘loaded’ seems to work better, especially since we are talking about a metric that relates to capacity.

e.g.

When my truck is unloaded, my truck stops quickly, but when loaded, it takes longer to stop.

so now:

When my Internet line is unloaded, my latency is low, but when it is highly loaded (iCloud photo sync), the latency is very high.

Cheers,

Jonathan Foulkes




On May 4, 2021, at 8:02 PM, Livingood, Jason via Bloat <bloat@lists.bufferbloat.net<mailto:bloat@lists.bufferbloat.net>> wrote:

Like many of you I have been immersed in buffer bloat discussions for many years, almost entirely within the technical community. Now that I am starting to explain latency & latency under load to internal non-technical folks, I have noticed some people don’t really understand “traditional” latency vs. latency under load (LUL).

As a result, I am planning to experiment in some upcoming briefings and call traditional latency “idle latency” – a measure of latency conducted on an otherwise idle connection. And then try calling LUL either “active latency” or perhaps “working latency” (suggested by an external colleague – can’t take credit for that one) – to try to communicate it is latency when the connection is experiencing normal usage.

Have any of you here faced similar challenges explaining this to non-technical audiences? Have you had any success with alternative terms? What do you think of these?

Thanks for any input,
Jason
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<mailto:Bloat@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/bloat<https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!SviWp1tUK05mhY86CJjmhVNVM210b56Lvk770IAgUQ_kIDOfyPAnlca8voyyYQP3Oi04yg$>


[-- Attachment #2: Type: text/html, Size: 9052 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Michael Richardson]

The part I'd like to simplify is "latency"....
Most people can understand that the hot water tap doesn't produce hot water
instantly, but I don't know how leverage that experience to networking directly.
Idle and Working are good.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Dave Taht]

On Wed, May 12, 2021 at 9:02 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
> The part I'd like to simplify is "latency"....
> Most people can understand that the hot water tap doesn't produce hot water
> instantly, but I don't know how leverage that experience to networking directly.
> Idle and Working are good.

The demo I did in my broadcom preso ages back was the simplest I could imagine,
but not on the slides. ( http://www.taht.net/~d/broadcom_aug9_2018.pdf  )

I brought a coffee pot, a large carafe, two differently sized funnels,
an eye dropper, (and a towel!)

and showed how sending more data at the sender didn't change the
receiving rate, and how a human,
at least, reacted to tail "packet loss" by slowing down.

It strikes me that this demo is amiable to doing via videoconference.
Perhaps something that floats could be used to represent voip, like a
dried pea.

Being a perfectionist, I've not liked that this demo does not also
represent what happens when the upstream link
is clogged, but perhaps with some video trickery... (there's
videoconferencing filters for inverting the video), and intensely
dislike that it doesn't at all cover how RTT on every packet is the
driver but but that would require a water fountain as per VJ's big
demo at IETF 84.

We'd done a lot of more complicated vids than this (my modena talk,
shemminger's linux plumbers talk) trying to then explain aqm and fq,
but it seems like this mere starting point would be a useful visual
aid nowadays for laypeople.

https://courses.cs.washington.edu/courses/cse550/14au/papers/CSE550.congavoid.pdf
for engineers.

>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]


Dave Taht <dave.taht@gmail.com> wrote:
    > On Wed, May 12, 2021 at 9:02 AM Michael Richardson <mcr@sandelman.ca>
    > wrote:
    >>
    >> The part I'd like to simplify is "latency"....  Most people can
    >> understand that the hot water tap doesn't produce hot water instantly,
    >> but I don't know how leverage that experience to networking directly.
    >> Idle and Working are good.

    > The demo I did in my broadcom preso ages back was the simplest I could
    > imagine, but not on the slides. (
    > http://www.taht.net/~d/broadcom_aug9_2018.pdf )

    > I brought a coffee pot, a large carafe, two differently sized funnels,
    > an eye dropper, (and a towel!)

Yes, that's a good demonstration for technical people.
I tried to do this at a LUG with audience involved theatre, but then you did
it better at some Australian event.

But, I'm looking for terminology that I can use with my mother-in-law.
(She's just signed up with a 802.11 based rural provider for her cottage for
the summer.  Made financially feasible only because they'll let her cancel
for 6 months when it's winter.  I'm providing a modem.  I suspect that the
bandwidth is not-constant, so I wonder what I'll tell sql scripts...)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 2688 bytes --]

hmm, it seems kinda like the speed of causality
<https://www.sciencealert.com/watch-why-the-speed-of-light-is-not-about-light#:~:text=As%20Matt%20explains%2C%20the%20speed,the%20Universe%2C%20can%20agree%20on.>
applied to computers that share information in order to proceed

Bob

On Wed, May 12, 2021 at 2:10 PM Michael Richardson <mcr@sandelman.ca> wrote:

>
> Dave Taht <dave.taht@gmail.com> wrote:
>     > On Wed, May 12, 2021 at 9:02 AM Michael Richardson <mcr@sandelman.ca
> >
>     > wrote:
>     >>
>     >> The part I'd like to simplify is "latency"....  Most people can
>     >> understand that the hot water tap doesn't produce hot water
> instantly,
>     >> but I don't know how leverage that experience to networking
> directly.
>     >> Idle and Working are good.
>
>     > The demo I did in my broadcom preso ages back was the simplest I
> could
>     > imagine, but not on the slides. (
>     > http://www.taht.net/~d/broadcom_aug9_2018.pdf )
>
>     > I brought a coffee pot, a large carafe, two differently sized
> funnels,
>     > an eye dropper, (and a towel!)
>
> Yes, that's a good demonstration for technical people.
> I tried to do this at a LUG with audience involved theatre, but then you
> did
> it better at some Australian event.
>
> But, I'm looking for terminology that I can use with my mother-in-law.
> (She's just signed up with a 802.11 based rural provider for her cottage
> for
> the summer.  Made financially feasible only because they'll let her cancel
> for 6 months when it's winter.  I'm providing a modem.  I suspect that the
> bandwidth is not-constant, so I wonder what I'll tell sql scripts...)
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

[-- Attachment #1.2: Type: text/html, Size: 3641 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

> On 13 May, 2021, at 12:10 am, Michael Richardson <mcr@sandelman.ca> wrote:
> 
> But, I'm looking for terminology that I can use with my mother-in-law.

Here's a slide I used a while ago, which seems to be relevant here:



The important thing about the term "quick" in this context is that throughput capacity can contribute to it in some circumstances, but is mostly irrelevant in others.  For small requests, throughput is irrelevant and quickness is a direct result of low latency.

For a grandmother-friendly analogy, consider what you'd do if you wanted milk for your breakfast cereal, but found the fridge was empty.  The ideal solution to this problem would be to walk down the road to the village shop and buy a bottle of milk, then walk back home.  That might take about ten minutes - reasonably "quick".  It might take twice that long if you have to wait for someone who wants to scratch off a dozen lottery tickets right at the counter while paying by cheque; it's politer for such people to step out of the way.

My village doesn't have a shop, so that's not an option.  But I've seen dairy tankers going along the main road, so I could consider flagging one of them down.  Most of them ignore the lunatic trying to do that, and the one that does (five hours later) decides to offload a thousand gallons of milk instead of the pint I actually wanted, to make it worth his while.  That made rather a mess of my kitchen and was quite expensive.  Dairy tankers are set up for "fast" transport of milk - high throughput, not optimised for latency.

The non-lunatic alternative would be to get on my bicycle and go to the supermarket in town.  That takes about two hours, there and back.  It takes me basically the same amount of time to fetch that one bottle of milk as it would to conduct a full shopping trip, and I can't reduce that time at all without upgrading to something faster than a bicycle, or moving house to somewhere closer to town.  That's latency for you.

 - Jonathan Morton

[-- Attachment #2.1: Type: text/html, Size: 2768 bytes --]

[-- Attachment #2.2: fast-quick.001.png --]
[-- Type: image/png, Size: 58634 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Matt Mathis]

[-- Attachment #1.1: Type: text/plain, Size: 3502 bytes --]

I just got a cool idea: I wonder if it is original....?

Write or adapt a spec based on "A One-way Active Measurement Protocol"
(OWAMP - RFC4656), as an application layer LAG metric.   Suitably framed
OWAMP messages could be injected as close as possible to the socket write
in the sending applications, and decoded as close as possible to the
receiving application's read, independent of all other protocol details.

This could expose lag, latency and jitter in a standardized way, that can
be reported by the applications and replicated by measurement diagnostics
that can be compared apples-to-apples.  The default data collection should
probably be histograms of one way delays.

This would expose problematic delays in all parts of the stack, including
excess socket buffers, etc.

This could be adapted to any application protocol that has an appropriate
framing layer, including ndt7.

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 Mon, May 17, 2021 at 4:14 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> On 13 May, 2021, at 12:10 am, Michael Richardson <mcr@sandelman.ca> wrote:
>
> But, I'm looking for terminology that I can use with my mother-in-law.
>
>
> Here's a slide I used a while ago, which seems to be relevant here:
>
>
> The important thing about the term "quick" in this context is that
> throughput capacity can contribute to it in some circumstances, but is
> mostly irrelevant in others.  For small requests, throughput is irrelevant
> and quickness is a direct result of low latency.
>
> For a grandmother-friendly analogy, consider what you'd do if you wanted
> milk for your breakfast cereal, but found the fridge was empty.  The ideal
> solution to this problem would be to walk down the road to the village shop
> and buy a bottle of milk, then walk back home.  That might take about ten
> minutes - reasonably "quick".  It might take twice that long if you have to
> wait for someone who wants to scratch off a dozen lottery tickets right at
> the counter while paying by cheque; it's politer for such people to step
> out of the way.
>
> My village doesn't have a shop, so that's not an option.  But I've seen
> dairy tankers going along the main road, so I could consider flagging one
> of them down.  Most of them ignore the lunatic trying to do that, and the
> one that does (five hours later) decides to offload a thousand gallons of
> milk instead of the pint I actually wanted, to make it worth his while.
> That made rather a mess of my kitchen and was quite expensive.  Dairy
> tankers are set up for "fast" transport of milk - high throughput, not
> optimised for latency.
>
> The non-lunatic alternative would be to get on my bicycle and go to the
> supermarket in town.  That takes about two hours, there and back.  It takes
> me basically the same amount of time to fetch that one bottle of milk as it
> would to conduct a full shopping trip, and I can't reduce that time at all
> without upgrading to something faster than a bicycle, or moving house to
> somewhere closer to town.  That's latency for you.
>
>  - Jonathan Morton
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #1.2: Type: text/html, Size: 4752 bytes --]

[-- Attachment #2: fast-quick.001.png --]
[-- Type: image/png, Size: 58634 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Bob McMahon]

[-- Attachment #1.1.1: Type: text/plain, Size: 5284 bytes --]

iperf 2 <https://sourceforge.net/projects/iperf2/> supports one way delay
and histograms for UDP packets, TCP writes to reads, and frames. The trick
is to synchronize the clocks using something like PTPd2 or PTP4l to a
reference, e.g. the GPS atomic clock. One can build a stratum 1 time server
with a raspberry pi 4 and a GPS receiver that gives pulse per second. The
output supports histograms and mean/min/max/stdev. \The network power
metric uses avg throughput over one way delay.

For  internal use we have more granularity than end/end and everything is
mapped to the GPS time domain which allows for per message delay
analysis as well as system analysis as a function of time.

We're finding that one way delay is becoming a key performance metric for
our WiFi customers and peak throughput less so.

Bob

On Mon, May 17, 2021 at 2:27 PM Matt Mathis <mattmathis@google.com> wrote:

> I just got a cool idea: I wonder if it is original....?
>
> Write or adapt a spec based on "A One-way Active Measurement Protocol"
> (OWAMP - RFC4656), as an application layer LAG metric.   Suitably framed
> OWAMP messages could be injected as close as possible to the socket write
> in the sending applications, and decoded as close as possible to the
> receiving application's read, independent of all other protocol details.
>
> This could expose lag, latency and jitter in a standardized way, that can
> be reported by the applications and replicated by measurement diagnostics
> that can be compared apples-to-apples.  The default data collection should
> probably be histograms of one way delays.
>
> This would expose problematic delays in all parts of the stack, including
> excess socket buffers, etc.
>
> This could be adapted to any application protocol that has an appropriate
> framing layer, including ndt7.
>
> 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 Mon, May 17, 2021 at 4:14 AM Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> On 13 May, 2021, at 12:10 am, Michael Richardson <mcr@sandelman.ca>
>> wrote:
>>
>> But, I'm looking for terminology that I can use with my mother-in-law.
>>
>>
>> Here's a slide I used a while ago, which seems to be relevant here:
>>
>>
>> The important thing about the term "quick" in this context is that
>> throughput capacity can contribute to it in some circumstances, but is
>> mostly irrelevant in others.  For small requests, throughput is irrelevant
>> and quickness is a direct result of low latency.
>>
>> For a grandmother-friendly analogy, consider what you'd do if you wanted
>> milk for your breakfast cereal, but found the fridge was empty.  The ideal
>> solution to this problem would be to walk down the road to the village shop
>> and buy a bottle of milk, then walk back home.  That might take about ten
>> minutes - reasonably "quick".  It might take twice that long if you have to
>> wait for someone who wants to scratch off a dozen lottery tickets right at
>> the counter while paying by cheque; it's politer for such people to step
>> out of the way.
>>
>> My village doesn't have a shop, so that's not an option.  But I've seen
>> dairy tankers going along the main road, so I could consider flagging one
>> of them down.  Most of them ignore the lunatic trying to do that, and the
>> one that does (five hours later) decides to offload a thousand gallons of
>> milk instead of the pint I actually wanted, to make it worth his while.
>> That made rather a mess of my kitchen and was quite expensive.  Dairy
>> tankers are set up for "fast" transport of milk - high throughput, not
>> optimised for latency.
>>
>> The non-lunatic alternative would be to get on my bicycle and go to the
>> supermarket in town.  That takes about two hours, there and back.  It takes
>> me basically the same amount of time to fetch that one bottle of milk as it
>> would to conduct a full shopping trip, and I can't reduce that time at all
>> without upgrading to something faster than a bicycle, or moving house to
>> somewhere closer to town.  That's latency for you.
>>
>>  - Jonathan Morton
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

[-- Attachment #1.1.2: Type: text/html, Size: 6770 bytes --]

[-- Attachment #1.2: fast-quick.001.png --]
[-- Type: image/png, Size: 58634 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Neil Davies]

[-- Attachment #1.1: Type: text/plain, Size: 4579 bytes --]

Matt

This is such a great idea that the Broadband Forum has been working on it for a couple of years now - see TR452.1 https://www.broadband-forum.org/download/TR-452.1.pdf <https://www.broadband-forum.org/download/TR-452.1.pdf> - it is being actively worked on, it can exploit existing infrastructures (such equipment that supports STAMP etc), it doesn’t need accurate clocks (just reasonable precision), it can be used both end-to-end and hop-by-hop (using the same measurement stream) and it has a formal mathematical basis (which has a whole host of benefits that companies are starting to exploit).

Neil

> On 17 May 2021, at 22:27, Matt Mathis via Bloat <bloat@lists.bufferbloat.net> wrote:
> 
> I just got a cool idea: I wonder if it is original....?
> 
> Write or adapt a spec based on "A One-way Active Measurement Protocol" (OWAMP - RFC4656), as an application layer LAG metric.   Suitably framed OWAMP messages could be injected as close as possible to the socket write in the sending applications, and decoded as close as possible to the receiving application's read, independent of all other protocol details.
> 
> This could expose lag, latency and jitter in a standardized way, that can be reported by the applications and replicated by measurement diagnostics that can be compared apples-to-apples.  The default data collection should probably be histograms of one way delays.
> 
> This would expose problematic delays in all parts of the stack, including excess socket buffers, etc.
> 
> This could be adapted to any application protocol that has an appropriate framing layer, including ndt7.
> 
> 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 Mon, May 17, 2021 at 4:14 AM Jonathan Morton <chromatix99@gmail.com <mailto:chromatix99@gmail.com>> wrote:
>> On 13 May, 2021, at 12:10 am, Michael Richardson <mcr@sandelman.ca <mailto:mcr@sandelman.ca>> wrote:
>> 
>> But, I'm looking for terminology that I can use with my mother-in-law.
> 
> Here's a slide I used a while ago, which seems to be relevant here:
> 
> <fast-quick.001.png>
> 
> The important thing about the term "quick" in this context is that throughput capacity can contribute to it in some circumstances, but is mostly irrelevant in others.  For small requests, throughput is irrelevant and quickness is a direct result of low latency.
> 
> For a grandmother-friendly analogy, consider what you'd do if you wanted milk for your breakfast cereal, but found the fridge was empty.  The ideal solution to this problem would be to walk down the road to the village shop and buy a bottle of milk, then walk back home.  That might take about ten minutes - reasonably "quick".  It might take twice that long if you have to wait for someone who wants to scratch off a dozen lottery tickets right at the counter while paying by cheque; it's politer for such people to step out of the way.
> 
> My village doesn't have a shop, so that's not an option.  But I've seen dairy tankers going along the main road, so I could consider flagging one of them down.  Most of them ignore the lunatic trying to do that, and the one that does (five hours later) decides to offload a thousand gallons of milk instead of the pint I actually wanted, to make it worth his while.  That made rather a mess of my kitchen and was quite expensive.  Dairy tankers are set up for "fast" transport of milk - high throughput, not optimised for latency.
> 
> The non-lunatic alternative would be to get on my bicycle and go to the supermarket in town.  That takes about two hours, there and back.  It takes me basically the same amount of time to fetch that one bottle of milk as it would to conduct a full shopping trip, and I can't reduce that time at all without upgrading to something faster than a bicycle, or moving house to somewhere closer to town.  That's latency for you.
> 
>  - Jonathan Morton
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net <mailto:Bloat@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat <https://lists.bufferbloat.net/listinfo/bloat>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


[-- Attachment #1.2: Type: text/html, Size: 6892 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Matt Mathis]

[-- Attachment #1: Type: text/plain, Size: 5479 bytes --]

Looks cool, I will have to read it more carefully.

I could not tell in a quick scan if this could be used inside of TCP or
QUIC with a suitable message framing.

The point would be an always on application to application lag measurement
that could expose semi-standard measurements to millions of end users, who
could feed suitable commentary to ISP marketing people.

Engineers speaking to engineers don't have enough clout within ISPs to
convince product managers to that buffer bloat is a problem.

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 Mon, May 17, 2021 at 11:31 PM Neil Davies <neil.davies@pnsol.com> wrote:

> Matt
>
> This is such a great idea that the Broadband Forum has been working on it
> for a couple of years now - see TR452.1
> https://www.broadband-forum.org/download/TR-452.1.pdf - it is being
> actively worked on, it can exploit existing infrastructures (such equipment
> that supports STAMP etc), it doesn’t need accurate clocks (just reasonable
> precision), it can be used both end-to-end and hop-by-hop (using the same
> measurement stream) and it has a formal mathematical basis (which has a
> whole host of benefits that companies are starting to exploit).
>
> Neil
>
> On 17 May 2021, at 22:27, Matt Mathis via Bloat <
> bloat@lists.bufferbloat.net> wrote:
>
> I just got a cool idea: I wonder if it is original....?
>
> Write or adapt a spec based on "A One-way Active Measurement Protocol"
> (OWAMP - RFC4656), as an application layer LAG metric.   Suitably framed
> OWAMP messages could be injected as close as possible to the socket write
> in the sending applications, and decoded as close as possible to the
> receiving application's read, independent of all other protocol details.
>
> This could expose lag, latency and jitter in a standardized way, that can
> be reported by the applications and replicated by measurement diagnostics
> that can be compared apples-to-apples.  The default data collection should
> probably be histograms of one way delays.
>
> This would expose problematic delays in all parts of the stack, including
> excess socket buffers, etc.
>
> This could be adapted to any application protocol that has an appropriate
> framing layer, including ndt7.
>
> 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 Mon, May 17, 2021 at 4:14 AM Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> On 13 May, 2021, at 12:10 am, Michael Richardson <mcr@sandelman.ca>
>> wrote:
>>
>> But, I'm looking for terminology that I can use with my mother-in-law.
>>
>>
>> Here's a slide I used a while ago, which seems to be relevant here:
>>
>> <fast-quick.001.png>
>>
>> The important thing about the term "quick" in this context is that
>> throughput capacity can contribute to it in some circumstances, but is
>> mostly irrelevant in others.  For small requests, throughput is irrelevant
>> and quickness is a direct result of low latency.
>>
>> For a grandmother-friendly analogy, consider what you'd do if you wanted
>> milk for your breakfast cereal, but found the fridge was empty.  The ideal
>> solution to this problem would be to walk down the road to the village shop
>> and buy a bottle of milk, then walk back home.  That might take about ten
>> minutes - reasonably "quick".  It might take twice that long if you have to
>> wait for someone who wants to scratch off a dozen lottery tickets right at
>> the counter while paying by cheque; it's politer for such people to step
>> out of the way.
>>
>> My village doesn't have a shop, so that's not an option.  But I've seen
>> dairy tankers going along the main road, so I could consider flagging one
>> of them down.  Most of them ignore the lunatic trying to do that, and the
>> one that does (five hours later) decides to offload a thousand gallons of
>> milk instead of the pint I actually wanted, to make it worth his while.
>> That made rather a mess of my kitchen and was quite expensive.  Dairy
>> tankers are set up for "fast" transport of milk - high throughput, not
>> optimised for latency.
>>
>> The non-lunatic alternative would be to get on my bicycle and go to the
>> supermarket in town.  That takes about two hours, there and back.  It takes
>> me basically the same amount of time to fetch that one bottle of milk as it
>> would to conduct a full shopping trip, and I can't reduce that time at all
>> without upgrading to something faster than a bicycle, or moving house to
>> somewhere closer to town.  That's latency for you.
>>
>>  - Jonathan Morton
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
>

[-- Attachment #2: Type: text/html, Size: 7483 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 5520 bytes --]

The idea of precision without accuracy seems an issue.  Curios about that.

Bob
On Mon, May 17, 2021 at 11:31 PM Neil Davies <neil.davies@pnsol.com> wrote:

> Matt
>
> This is such a great idea that the Broadband Forum has been working on it
> for a couple of years now - see TR452.1
> https://www.broadband-forum.org/download/TR-452.1.pdf - it is being
> actively worked on, it can exploit existing infrastructures (such equipment
> that supports STAMP etc), it doesn’t need accurate clocks (just reasonable
> precision), it can be used both end-to-end and hop-by-hop (using the same
> measurement stream) and it has a formal mathematical basis (which has a
> whole host of benefits that companies are starting to exploit).
>
> Neil
>
> On 17 May 2021, at 22:27, Matt Mathis via Bloat <
> bloat@lists.bufferbloat.net> wrote:
>
> I just got a cool idea: I wonder if it is original....?
>
> Write or adapt a spec based on "A One-way Active Measurement Protocol"
> (OWAMP - RFC4656), as an application layer LAG metric.   Suitably framed
> OWAMP messages could be injected as close as possible to the socket write
> in the sending applications, and decoded as close as possible to the
> receiving application's read, independent of all other protocol details.
>
> This could expose lag, latency and jitter in a standardized way, that can
> be reported by the applications and replicated by measurement diagnostics
> that can be compared apples-to-apples.  The default data collection should
> probably be histograms of one way delays.
>
> This would expose problematic delays in all parts of the stack, including
> excess socket buffers, etc.
>
> This could be adapted to any application protocol that has an appropriate
> framing layer, including ndt7.
>
> 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 Mon, May 17, 2021 at 4:14 AM Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> On 13 May, 2021, at 12:10 am, Michael Richardson <mcr@sandelman.ca>
>> wrote:
>>
>> But, I'm looking for terminology that I can use with my mother-in-law.
>>
>>
>> Here's a slide I used a while ago, which seems to be relevant here:
>>
>> <fast-quick.001.png>
>>
>> The important thing about the term "quick" in this context is that
>> throughput capacity can contribute to it in some circumstances, but is
>> mostly irrelevant in others.  For small requests, throughput is irrelevant
>> and quickness is a direct result of low latency.
>>
>> For a grandmother-friendly analogy, consider what you'd do if you wanted
>> milk for your breakfast cereal, but found the fridge was empty.  The ideal
>> solution to this problem would be to walk down the road to the village shop
>> and buy a bottle of milk, then walk back home.  That might take about ten
>> minutes - reasonably "quick".  It might take twice that long if you have to
>> wait for someone who wants to scratch off a dozen lottery tickets right at
>> the counter while paying by cheque; it's politer for such people to step
>> out of the way.
>>
>> My village doesn't have a shop, so that's not an option.  But I've seen
>> dairy tankers going along the main road, so I could consider flagging one
>> of them down.  Most of them ignore the lunatic trying to do that, and the
>> one that does (five hours later) decides to offload a thousand gallons of
>> milk instead of the pint I actually wanted, to make it worth his while.
>> That made rather a mess of my kitchen and was quite expensive.  Dairy
>> tankers are set up for "fast" transport of milk - high throughput, not
>> optimised for latency.
>>
>> The non-lunatic alternative would be to get on my bicycle and go to the
>> supermarket in town.  That takes about two hours, there and back.  It takes
>> me basically the same amount of time to fetch that one bottle of milk as it
>> would to conduct a full shopping trip, and I can't reduce that time at all
>> without upgrading to something faster than a bicycle, or moving house to
>> somewhere closer to town.  That's latency for you.
>>
>>  - Jonathan Morton
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

[-- Attachment #1.2: Type: text/html, Size: 7241 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[David Lang]

precision without accuracy is having clocks that may differ from each other by a 
few seconds, but both count the same number of milliseconds for a duration.

https://wp.stolaf.edu/it/gis-precision-accuracy/

David Lang

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 1228 bytes --]

ok, though I see that as accuracy in the first derivative more than
inaccurate precision that mitigates the need for "ground truths."

Bob

On Tue, May 18, 2021 at 3:29 PM David Lang <david@lang.hm> wrote:

> precision without accuracy is having clocks that may differ from each
> other by a
> few seconds, but both count the same number of milliseconds for a duration.
>
> https://wp.stolaf.edu/it/gis-precision-accuracy/
>
> David Lang
>
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

[-- Attachment #1.2: Type: text/html, Size: 1705 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]