<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Matt<div class=""><br class=""></div><div class="">This is such a great idea that the Broadband Forum has been working on it for a couple of years now - see TR452.1 <a href="https://www.broadband-forum.org/download/TR-452.1.pdf" class="">https://www.broadband-forum.org/download/TR-452.1.pdf</a> - 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). </div><div class=""><br class=""></div><div class="">Neil<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 17 May 2021, at 22:27, Matt Mathis via Bloat <<a href="mailto:bloat@lists.bufferbloat.net" class="">bloat@lists.bufferbloat.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I just got a cool idea: I wonder if it is original....?<div class=""><br class=""><div class="">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. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">This would expose problematic delays in all parts of the stack, including excess socket buffers, etc.</div><div class=""><br class=""></div><div class="">This could be adapted to any application protocol that has an appropriate framing layer, including ndt7.<br class=""><div class=""><br class=""></div><div class="">Thanks,<div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">--MM--<br class="">The best way to predict the future is to create it. - Alan Kay<br class=""><br class="">We must not tolerate intolerance;</div><div dir="ltr" class=""> however our response must be carefully measured: </div><div class=""> too strong would be hypocritical and risks spiraling out of control;</div><div class=""> too weak risks being mistaken for tacit approval.</div></div></div></div></div><br class=""></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 17, 2021 at 4:14 AM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" class="">chromatix99@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><blockquote type="cite" class="">On 13 May, 2021, at 12:10 am, Michael Richardson <<a href="mailto:mcr@sandelman.ca" target="_blank" class="">mcr@sandelman.ca</a>> wrote:<br class=""><br class="">But, I'm looking for terminology that I can use with my mother-in-law.<br class=""></blockquote><br class=""><div class="">Here's a slide I used a while ago, which seems to be relevant here:</div><div class=""><br class=""></div><div class=""><span id="cid:1797c1ed86cdb94463a1"><fast-quick.001.png></span></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""> - Jonathan Morton</div></div>_______________________________________________<br class="">
Bloat mailing list<br class="">
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank" class="">Bloat@lists.bufferbloat.net</a><br class="">
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank" class="">https://lists.bufferbloat.net/listinfo/bloat</a><br class="">
</blockquote></div>
_______________________________________________<br class="">Bloat mailing list<br class=""><a href="mailto:Bloat@lists.bufferbloat.net" class="">Bloat@lists.bufferbloat.net</a><br class="">https://lists.bufferbloat.net/listinfo/bloat<br class=""></div></blockquote></div><br class=""></div></body></html>