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 <[email protected]> > 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 <[email protected] > <mailto:[email protected]>> wrote: >> On 13 May, 2021, at 12:10 am, Michael Richardson <[email protected] >> <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.bufferbloat.net/listinfo/bloat > <https://lists.bufferbloat.net/listinfo/bloat> > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
