From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from st-node03.ct.uk (st-node03.ct.uk [109.69.232.42]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 161E63B29E for ; Tue, 18 May 2021 02:31:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by st-node03.ct.uk (Postfix) with ESMTP id EEE8929DDC80; Tue, 18 May 2021 07:31:19 +0100 (BST) X-Virus-Scanned: by SpamTitan at ct.uk Received: from st-node03.ct.uk (localhost [127.0.0.1]) by st-node03.ct.uk (Postfix) with ESMTP id 4847B29DDC9E; Tue, 18 May 2021 07:31:16 +0100 (BST) Authentication-Results: st-node03.ct.uk; none Received: from relay.smtp.pnsol.com (ec2-54-246-165-192.eu-west-1.compute.amazonaws.com [54.246.165.192]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) (Authenticated sender: predictable) by st-node03.ct.uk (Postfix) with ESMTPSA id 21FB029DDC9C; Tue, 18 May 2021 07:31:16 +0100 (BST) Received: from mail.la.pnsol.com ([172.20.5.206]) by relay.smtp.pnsol.com with esmtp (Exim 4.82) (envelope-from ) id 1litOi-0002ug-PW; Tue, 18 May 2021 06:40:08 +0000 Received: from [172.20.101.45] (helo=ip-172-20-101-45.eu-west-1.compute.internal) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1litFo-0006Vq-VT; Tue, 18 May 2021 07:30:57 +0100 From: Neil Davies Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A159769A-E308-49E8-8005-ED59C7FA6750"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Date: Tue, 18 May 2021 07:31:13 +0100 In-Reply-To: Cc: Jonathan Morton , Bob McMahon , bloat To: Matt Mathis References: <666B8455-7B26-4E89-A7F2-0279B4D67FCB@cable.comcast.com> <13254.1620835357@localhost> <28847.1620853812@localhost> <3368CD2E-E92E-418A-ACA6-772D42FEC2AD@gmail.com> X-Mailer: Apple Mail (2.3445.9.7) Subject: Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 06:31:21 -0000 --Apple-Mail=_A159769A-E308-49E8-8005-ED59C7FA6750 Content-Type: multipart/alternative; boundary="Apple-Mail=_B2B6D7B0-779D-463B-92A9-7059982AC42A" --Apple-Mail=_B2B6D7B0-779D-463B-92A9-7059982AC42A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99t 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 = wrote: >=20 > I just got a cool idea: I wonder if it is original....? >=20 > 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. >=20 > 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. >=20 > This would expose problematic delays in all parts of the stack, = including excess socket buffers, etc. >=20 > This could be adapted to any application protocol that has an = appropriate framing layer, including ndt7. >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > 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. >=20 >=20 > On Mon, May 17, 2021 at 4:14 AM Jonathan Morton > wrote: >> On 13 May, 2021, at 12:10 am, Michael Richardson > wrote: >>=20 >> But, I'm looking for terminology that I can use with my = mother-in-law. >=20 > Here's a slide I used a while ago, which seems to be relevant here: >=20 > >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > - 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 --Apple-Mail=_B2B6D7B0-779D-463B-92A9-7059982AC42A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99= 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

= --Apple-Mail=_B2B6D7B0-779D-463B-92A9-7059982AC42A-- --Apple-Mail=_A159769A-E308-49E8-8005-ED59C7FA6750 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzmChmYLHZj0CWbh3+akwcLL+52oFAmCjXzEACgkQ+akwcLL+ 52rdrw//Q3vYLvufohSn1NUkGDYRDK4bwAmQ4Vdml3/5pwyU/20qV6b8+s9b8ovT Vy3xwjxLasY001+BusDdmeAAyW4ApF7UrzZmebB9DHAtWEO3lRXf7SUlbVGKFcTE 5XDADV7CnTnrT7pTQv/AX/av+wwMAoR2gWYVNyAcHdOxe9lXjP9Eq964UaT60b0d p6aU0RqXEIYbqU6Iq+mgoagYoc8rcIalHKYJkj2R7XgU+TMLnorvJ1j9Bnvr0YlH WLSa7Mu04CZSsJuYW+PvxL0wL2bO5zksJDudiLjYRYnKXxJEJLxfNYffp9MxTneK UTf+B3x7fRHBqEzJMpu9lkNddqrKmwnLE3uDcifv8lZI8VVZJ7Q0iqQMwyoUTQIj UxYrKw0V/P0IwCFWDLpng07ot+v0c98GaDaxMdTCXtQV/PlTobzfpyDafSB9N8IZ 5MOMPgqG0sDQLEyCPZ+MmKmnqr7WG14Swmf0z0wHqGZJVdMOM6hzb0Y2jRaPa5HG KpCq4iMzhAOrrp5fhVyFLBqEDggqDSiVfLg7S1TncweneLgnJM6mOU7d9ylJJMfB jRWX2I5hf9BITRFPDylv/oh4kT7yFRN/3rFciRnw1cTq6kfYZmxUw2oyw4IpSG57 CWxmChZdDe/gD8dcyZZ2wP4BouZwJxtMucE2g/brpEGVoMvzshE= =5EZh -----END PGP SIGNATURE----- --Apple-Mail=_A159769A-E308-49E8-8005-ED59C7FA6750--