General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Bob McMahon <bob.mcmahon@broadcom.com>
To: Matt Mathis <mattmathis@google.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	Michael Richardson <mcr@sandelman.ca>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople
Date: Mon, 17 May 2021 17:47:49 -0700	[thread overview]
Message-ID: <CAHb6LvqKZEprtbLhxEZ3VXNPjTvhZ_PGLGkCopq1_Cn0ryOQVw@mail.gmail.com> (raw)
In-Reply-To: <CAH56bmDK5M1V8gY52wjYNgEJ_urUcMPLn8K9r_0Xu1JhdP2SRw@mail.gmail.com>


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

  reply	other threads:[~2021-05-18  0:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 13:22 Livingood, Jason
2021-05-12 16:02 ` Michael Richardson
2021-05-12 16:40   ` Dave Taht
2021-05-12 21:10     ` Michael Richardson
2021-05-14  3:47       ` Bob McMahon
2021-05-16 18:07       ` Jonathan Morton
2021-05-17 21:27         ` Matt Mathis
2021-05-18  0:47           ` Bob McMahon [this message]
2021-05-18  6:31           ` Neil Davies
2021-05-18 15:24             ` Matt Mathis
2021-05-18 20:59             ` Bob McMahon
2021-05-18 22:29               ` David Lang
2021-05-19  0:02                 ` Bob McMahon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHb6LvqKZEprtbLhxEZ3VXNPjTvhZ_PGLGkCopq1_Cn0ryOQVw@mail.gmail.com \
    --to=bob.mcmahon@broadcom.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=mattmathis@google.com \
    --cc=mcr@sandelman.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox