From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DA8E63B2A4 for ; Tue, 18 May 2021 11:25:02 -0400 (EDT) Received: by mail-wr1-x434.google.com with SMTP id z17so10658704wrq.7 for ; Tue, 18 May 2021 08:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BSN9ab1zWaMSWM0iihF8ObSqjI9rUQQWfTOheA/czh0=; b=MvgOl1LqPLE6iOHBRsAuqbJ8c3VMJ4XeZzbFSxHBw8uJtcTrZ788TOcRqtVz3nRnlk 5BFJgF6Fs/q1bv8yg/h17Qd6GRiSTLu/x8NAVGw1eXNry1xm+sfwsz2XYH2g7J0RzkOd MTgEQKgZPQ14HeCH//1qdswwqiVxtY+26thcdkm1naXZpHmO+DpwYifmtaGmbYg8QM89 PnXTSjxvdQe0DsqY69OjWP1sm5PULcro6BdPs9lXgLKa96+cxQla/rOFRF13J6doyg3U ziKigjDWikl9lN4vGedpO5dGZJtsr2LP+Fvf4dQ2PXmK0PSw2hrLQAf9UCXuOP/tfk9p hyiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BSN9ab1zWaMSWM0iihF8ObSqjI9rUQQWfTOheA/czh0=; b=eb9629fYuOriM+KOzaLDX8DA4NIprXGJjEiFa5snn7ECZVCjGv57tk1r/jyk9cAWQi tu39/FrDpWu+f/sh4X37zndhPIAzKl1ayi80mV4/2T+qRLL+/se33h48Ae7XRw4nVkFm W/0siQvpiMZDj95G/xodI/Eu3GDgI2UCUZ9u5E3zIJtMSF9FoFqpgAIhmsbjiwsfpWH9 HqjxA0Zm8OF8jKm1pYW3fPQh0MnWSNLJm1pqZIGwkTIOBV7ahLm+UQULnUSAXvOwNLS5 DbfqGt/9Mjx8CuaS47D0JzOqUYd5c012NGTSGT6wz1tYjAUcLDeEan6KKdb1Detb5MYk oXfg== X-Gm-Message-State: AOAM532nqbR0ySzzvRTXKM8SBF8DPaxXmFtUepQ9cvN8r/2Jrh1q6F4K ArtyXXJmH6r+K8UL3ELsbzJJUGXiFUgoRouSh6OcUA== X-Google-Smtp-Source: ABdhPJyWha/1vrOFz34EvFZRWkDVt1UKn2qhHpdCKqAkB4a1A17fTcZF29urkTbrZIvKmI+BErikp4oNAXSNFJA6Vhk= X-Received: by 2002:adf:e4c4:: with SMTP id v4mr7788440wrm.346.1621351501786; Tue, 18 May 2021 08:25:01 -0700 (PDT) MIME-Version: 1.0 References: <666B8455-7B26-4E89-A7F2-0279B4D67FCB@cable.comcast.com> <13254.1620835357@localhost> <28847.1620853812@localhost> <3368CD2E-E92E-418A-ACA6-772D42FEC2AD@gmail.com> In-Reply-To: From: Matt Mathis Date: Tue, 18 May 2021 08:24:48 -0700 Message-ID: To: Neil Davies Cc: Jonathan Morton , Bob McMahon , bloat Content-Type: multipart/alternative; boundary="000000000000524b1605c29c501a" 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 15:25:03 -0000 --000000000000524b1605c29c501a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 equipme= nt > that supports STAMP etc), it doesn=E2=80=99t need accurate clocks (just r= easonable > 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 shoul= d > 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 > wrote: > >> On 13 May, 2021, at 12:10 am, Michael Richardson >> 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 irreleva= nt >> 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 ide= al >> solution to this problem would be to walk down the road to the village s= hop >> and buy a bottle of milk, then walk back home. That might take about te= n >> 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 on= e >> of them down. Most of them ignore the lunatic trying to do that, and th= e >> one that does (five hours later) decides to offload a thousand gallons o= f >> 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 ta= kes >> 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 a= ll >> 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 > > > --000000000000524b1605c29c501a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks cool, I will have to read it more carefully.
I could not tell in a quick scan if this could be used inside o= f TCP or QUIC with a suitable message framing.

The= point would be an always on application to application lag measurement tha= t could expose semi-standard measurements to millions of end users, who cou= ld feed suitable commentary=C2=A0to ISP marketing people.

Engineers=C2=A0speaking to engineers don't have enough clout wi= thin=C2=A0ISPs to convince product managers to that buffer bloat is a probl= em.

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

We must not tol= erate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however= our response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypocritical and risks spirali= ng out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 gre= at idea that the Broadband Forum has been working on it for a couple of yea= rs now - see TR452.1=C2=A0https://www.broadband-forum.org/download= /TR-452.1.pdf=C2=A0- it is being actively worked on, it can exploit exi= sting infrastructures (such equipment that supports STAMP etc), it doesn=E2= =80=99t need accurate clocks (just reasonable precision), it can be used bo= th 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 compa= nies are starting to exploit).=C2=A0

Neil
=
On 17 May 2021, at 22:27, Matt Mathis vi= a 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.=C2=A0 =C2=A0Suitabl= y=C2=A0framed OWAMP messages could be injected as close as possible=C2=A0to= the socket write in the sending applications, and decoded as close as poss= ible to the receiving application's read, independent of all other prot= ocol details.=C2=A0

This could expose lag, latency= and jitter in a standardized way, that can be reported=C2=A0by the applica= tions and replicated=C2=A0by measurement diagnostics that can be compared a= pples-to-apples.=C2=A0=C2=A0The default data collection should probably be = histograms of one way delays.=C2=A0 =C2=A0

This w= ould expose problematic delays in all parts=C2=A0of the stack, including ex= cess 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 fut= ure is to create it. =C2=A0- Alan Kay

We must not tolerate intoleran= ce;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response m= ust be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 too strong would be hypocritical and risks spiraling out of cont= rol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks bei= ng mistaken for tacit approval.


On Mon, May 17, 2021 at 4:14 AM Jonathan Morton <chromatix99@gmail.com> w= rote:
On 13 May, 2021, at 12:10 am, Michael Richardson <<= a href=3D"mailto:mcr@sandelman.ca" target=3D"_blank">mcr@sandelman.ca&g= t; wrote:

But, I'm looking for terminology that I can use with m= y mother-in-law.

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

<fast-quick.001.pn= g>

The important thing about the term &q= uot;quick" in this context is that throughput capacity can contribute = to it in some circumstances, but is mostly irrelevant in others.=C2=A0 For = small requests, throughput is irrelevant and quickness is a direct result o= f low latency.

For a grandmother-friendly analogy,= consider what you'd do if you wanted milk for your breakfast cereal, b= ut found the fridge was empty.=C2=A0 The ideal solution to this problem wou= ld be to walk down the road to the village shop and buy a bottle of milk, t= hen walk back home.=C2=A0 That might take about ten minutes - reasonably &q= uot;quick".=C2=A0 It might take twice that long if you have to wait fo= r someone who wants to scratch off a dozen lottery tickets right at the cou= nter while paying by cheque; it's politer for such people to step out o= f the way.

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

The non-lunatic alternative would be to g= et on my bicycle and go to the supermarket in town.=C2=A0 That takes about = two hours, there and back.=C2=A0 It takes me basically the same amount of t= ime 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 somethi= ng faster than a bicycle, or moving house to somewhere closer to town.=C2= =A0 That's latency for you.

=C2=A0- Jonathan M= orton
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
=

--000000000000524b1605c29c501a--