
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<body>

<div dir="auto">

<div dir="auto">And what counts is round trip end to end total latency. This is fixed latency plus jitter (variation above the fixed) - ie peak total latency.</div><div dir="auto"><br></div><div dir="auto">Peak total or high percentile 95/98 will be a much closer approximation to the performance of a real world jitter buffer in a voip system than average jitter. The higher the percentile the better.</div><div dir="auto"><br></div><div dir="auto">2% drops distributed evenly over the call is one dropout every second. Most users would notice that and most jitter buffers would expand to avoid that high a level of loss. One quarter second burst loss every 10 seconds is lower impact but about the same percentage, so you see the loss pattern matters. Every jitter buffer is designed slightly differently so this measurement is an approximation. But the key is that peak or close to peak latency is the right measure.</div><div dir="auto"><br></div><div dir="auto">Simon</div><div dir='auto'><br></div>

<div id="aqm-original" style="color: black;">

<div dir="auto">On February 24, 2021 11:33:07 PM Sina Khanifar <sina@waveform.com> wrote:</div>

<div><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;">

<div dir="auto">Thanks for the explanation.</div>

<div dir="auto"><br></div>

<div dir="auto">Right now, our criteria for phone/audio is "latency < 300 ms" and</div>

<div dir="auto">"jitter < 40 ms".</div>

<div dir="auto"><br></div>

<div dir="auto">It seems like something along the lines of "95th percentile latency <</div>

<div dir="auto">300 ms" might be advisable in place of the two existing criteria?</div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">Sina.</div>

<div dir="auto"><br></div>

<div dir="auto">On Wed, Feb 24, 2021 at 11:15 PM Simon Barber <simon@superduper.net> wrote:</div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;">

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">On February 24, 2021 9:57:13 PM Sina Khanifar <sina@waveform.com> wrote:</div>

<div dir="auto"><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #9933CC; padding-left: 0.75ex;">

<div dir="auto">Thanks for the feedback, Dave!</div>

<div dir="auto"><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #669900; padding-left: 0.75ex;">

<div dir="auto">0) "average" jitter is a meaningless number. In the case of a videoconferencing application, what matters most is max jitter, where the app will choose to ride the top edge of that, rather than follow it. I'd prefer using a 98% number, rather than 75% number, to weight where the typical delay in a videoconfernce might end up.</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">Both DSLReports and Ookla's desktop app report jitter as an average</div>

<div dir="auto">rather than as a max number, so I'm a little hesitant to go against</div>

<div dir="auto">the norm - users might find it a bit surprising to see much larger</div>

<div dir="auto">jitter numbers reported. We're also not taking a whole ton of latency</div>

<div dir="auto">tests in each phase, so the 98% will often end up being the max</div>

<div dir="auto">number.</div>

<div dir="auto"><br></div>

<div dir="auto">With regards to the videoconferencing, we actually ran some real-world</div>

<div dir="auto">tests of Zoom with various levels of bufferbloat/jitter/latency, and</div>

<div dir="auto">calibrated our "real-world results" table on that basis. We used</div>

<div dir="auto">average jitter in those tests ... I think if we used 98% or even 95%</div>

<div dir="auto">the allowable number would be quite high.</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">Video and audio cannot be played out until the packets have arrived, so late packets are effectively dropped, or the playback buffer must expand to accommodate the most late packets. If the playback buffer expands to accommodate the most late packets then the result is that the whole conversation is delayed by that amount. More than a fraction of a percent of dropped packets results in a very poor video or audio experience, this is why average jitter is irrelevant and peak or maximum latency is the correct measure to use.</div>

<div dir="auto"><br></div>

<div dir="auto">Yes, humans can tolerate quite a bit of delay. The conversation is significantly less fluid though.</div>

<div dir="auto"><br></div>

<div dir="auto">Simon</div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #9933CC; padding-left: 0.75ex;">

<div dir="auto"><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #669900; padding-left: 0.75ex;">

<div dir="auto">1) The worst case scenario of bloat affecting a users experience is during a simultaneous up and download, and I'd rather you did that rather than test them separately. Also you get a more realistic figure for the actual achievable bandwidth under contention and can expose problems like strict priority queuing in one direction or another locking out further flows.</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">We did consider this based on another user's feedback, but didn't</div>

<div dir="auto">implement it. Perhaps we can do this next time we revisit, though!</div>

<div dir="auto"><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #669900; padding-left: 0.75ex;">

<div dir="auto">This points to any of number of problems (features!) It's certainly my hope that all the cdn makers at this point have installed bufferbloat mitigations. Testing a cdn's tcp IS a great idea, but as a bufferbloated test, maybe not so much.</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">We chose to use a CDN because it seemed like the only feasible way to</div>

<div dir="auto">saturate gigabit links at least somewhat consistently for a meaningful</div>

<div dir="auto">part of the globe, without setting up a whole lot of servers at quite</div>

<div dir="auto">high cost.</div>

<div dir="auto"><br></div>

<div dir="auto">But we weren't aware that bufferbloat could be abated from the CDN's</div>

<div dir="auto">end. This is a bit surprising to me, as our test results indicate that</div>

<div dir="auto">bufferbloat is regularly an issue even though we're using a CDN for</div>

<div dir="auto">the speed and latency tests. For example, these are the results on my</div>

<div dir="auto">own connection here (Cox, in Southern California), showing meaningful</div>

<div dir="auto">bufferbloat:</div>

<div dir="auto"><br></div>

<div dir="auto">https://www.waveform.com/tools/bufferbloat?test-id=ece467bd-e07a-45ea-9db6-e64d8da2c1d2</div>

<div dir="auto"><br></div>

<div dir="auto">I get even larger bufferbloat effects when running the test on a 4G LTE network:</div>

<div dir="auto"><br></div>

<div dir="auto">https://www.waveform.com/tools/bufferbloat?test-id=e99ae561-88e0-4e1e-bafd-90fe1de298ac</div>

<div dir="auto"><br></div>

<div dir="auto">If the CDN was abating bufferbloat, surely I wouldn't see results like these?</div>

<div dir="auto"><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #669900; padding-left: 0.75ex;">

<div dir="auto">3) Are you tracking an ecn statistics at this point (ecnseen)?</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">We are not, no. I'd definitely be curious to see if we can add this in</div>

<div dir="auto">the future, though!</div>

<div dir="auto"><br></div>

<div dir="auto">Best,</div>

<div dir="auto"><br></div>

<div dir="auto">On Wed, Feb 24, 2021 at 2:10 PM Dave Taht <dave.taht@gmail.com> wrote:</div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #669900; padding-left: 0.75ex;">

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">So I've taken a tiny amount of time to run a few tests. For starters,</div>

<div dir="auto">thank you very much</div>

<div dir="auto">for your dedication and time into creating such a usable website, and faq.</div>

<div dir="auto"><br></div>

<div dir="auto">I have several issues though I really haven't had time to delve deep</div>

<div dir="auto">into the packet captures. (others, please try taking em, and put them</div>

<div dir="auto">somewhere?)</div>

<div dir="auto"><br></div>

<div dir="auto">0) "average" jitter is a meaningless number. In the case of a</div>

<div dir="auto">videoconferencing application,</div>

<div dir="auto">what matters most is max jitter, where the app will choose to ride the</div>

<div dir="auto">top edge of that, rather than follow it. I'd prefer using a 98%</div>

<div dir="auto">number, rather than 75% number, to weight where the typical delay in a</div>

<div dir="auto">videoconfernce might end up.</div>

<div dir="auto"><br></div>

<div dir="auto">1) The worst case scenario of bloat affecting a users experience is</div>

<div dir="auto">during a simultaneous up and download, and I'd rather you did that</div>

<div dir="auto">rather than test them separately. Also you get</div>

<div dir="auto">a more realistic figure for the actual achievable bandwidth under</div>

<div dir="auto">contention and can expose problems like strict priority queuing in one</div>

<div dir="auto">direction or another locking out further flows.</div>

<div dir="auto"><br></div>

<div dir="auto">2) I get absurdly great results from it with or without sqm on on a</div>

<div dir="auto">reasonably modern cablemodem (buffercontrol and pie and a cmts doing</div>

<div dir="auto">the right things)</div>

<div dir="auto"><br></div>

<div dir="auto">This points to any of number of problems (features!) It's certainly my</div>

<div dir="auto">hope that all the cdn makers at this point have installed bufferbloat</div>

<div dir="auto">mitigations. Testing a cdn's tcp IS a great idea, but as a</div>

<div dir="auto">bufferbloated test, maybe not so much.</div>

<div dir="auto"><br></div>

<div dir="auto">The packet capture of the tcp flows DOES show about 60ms jitter... but</div>

<div dir="auto">no loss. Your test shows:</div>

<div dir="auto"><br></div>

<div dir="auto">https://www.waveform.com/tools/bufferbloat?test-id=6fc7dd95-8bfa-4b76-b141-ed423b6580a9</div>

<div dir="auto"><br></div>

<div dir="auto">And is very jittery in the beginning of the test on its estimates. I</div>

<div dir="auto">really should be overjoyed at knowing a cdn is doing more of the right</div>

<div dir="auto">things, but in terms of a test... and linux also has got a ton of</div>

<div dir="auto">mitigations on the client side.</div>

<div dir="auto"><br></div>

<div dir="auto">3) As a side note, ecn actually is negotiated on the upload, if it's</div>

<div dir="auto">enabled on your system.</div>

<div dir="auto">Are you tracking an ecn statistics at this point (ecnseen)? It is not</div>

<div dir="auto">negotiated on the download (which is fine by me).</div>

<div dir="auto"><br></div>

<div dir="auto">I regrettable at this precise moment am unable to test a native</div>

<div dir="auto">cablemodem at the same speed as a sqm box, hope to get further on this</div>

<div dir="auto">tomorrow.</div>

<div dir="auto"><br></div>

<div dir="auto">Again, GREAT work so far, and I do think a test tool for all these</div>

<div dir="auto">cdns - heck, one that tested all of them at the same time, is very,</div>

<div dir="auto">very useful.</div>

<div dir="auto"><br></div>

<div dir="auto">On Wed, Feb 24, 2021 at 10:22 AM Sina Khanifar <sina@waveform.com> wrote:</div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #FF8800; padding-left: 0.75ex;">

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">Hi all,</div>

<div dir="auto"><br></div>

<div dir="auto">A couple of months ago my co-founder Sam posted an early beta of the</div>

<div dir="auto">Bufferbloat test that we’ve been working on, and Dave also linked to</div>

<div dir="auto">it a couple of weeks ago.</div>

<div dir="auto"><br></div>

<div dir="auto">Thank you all so much for your feedback - we almost entirely</div>

<div dir="auto">redesigned the tool and the UI based on the comments we received.</div>

<div dir="auto">We’re almost ready to launch the tool officially today at this URL,</div>

<div dir="auto">but wanted to show it to the list in case anyone finds any last bugs</div>

<div dir="auto">that we might have overlooked:</div>

<div dir="auto"><br></div>

<div dir="auto">https://www.waveform.com/tools/bufferbloat</div>

<div dir="auto"><br></div>

<div dir="auto">If you find a bug, please share the "Share Your Results" link with us</div>

<div dir="auto">along with what happened. We capture some debugging information on the</div>

<div dir="auto">backend, and having a share link allows us to diagnose any issues.</div>

<div dir="auto"><br></div>

<div dir="auto">This is really more of a passion project than anything else for us –</div>

<div dir="auto">we don’t anticipate we’ll try to commercialize it or anything like</div>

<div dir="auto">that. We're very thankful for all the work the folks on this list have</div>

<div dir="auto">done to identify and fix bufferbloat, and hope this is a useful</div>

<div dir="auto">contribution. I’ve personally been very frustrated by bufferbloat on a</div>

<div dir="auto">range of devices, and decided it might be helpful to build another</div>

<div dir="auto">bufferbloat test when the DSLReports test was down at some point last</div>

<div dir="auto">year.</div>

<div dir="auto"><br></div>

<div dir="auto">Our goals with this project were:</div>

<div dir="auto">* To build a second solid bufferbloat test in case DSLReports goes down again.</div>

<div dir="auto">* Build a test where bufferbloat is front and center as the primary</div>

<div dir="auto">purpose of the test, rather than just a feature.</div>

<div dir="auto">* Try to explain bufferbloat and its effect on a user's connection</div>

<div dir="auto">as clearly as possible for a lay audience.</div>

<div dir="auto"><br></div>

<div dir="auto">A few notes:</div>

<div dir="auto">* On the backend, we’re using Cloudflare’s CDN to perform the actual</div>

<div dir="auto">download and upload speed test. I know John Graham-Cunning has posted</div>

<div dir="auto">to this list in the past; if he or anyone from Cloudflare sees this,</div>

<div dir="auto">we’d love some help. Our Cloudflare Workers are being</div>

<div dir="auto">bandwidth-throttled due to having a non-enterprise grade account.</div>

<div dir="auto">We’ve worked around this in a kludgy way, but we’d love to get it</div>

<div dir="auto">resolved.</div>

<div dir="auto">* We have lots of ideas for improvements, e.g. simultaneous</div>

<div dir="auto">upload/downloads, trying different file size chunks, time-series</div>

<div dir="auto">latency graphs, using WebRTC to test UDP traffic etc, but in the</div>

<div dir="auto">interest of getting things launched we're sticking with the current</div>

<div dir="auto">featureset.</div>

<div dir="auto">* There are a lot of browser-specific workarounds that we had to</div>

<div dir="auto">implement, and latency itself is measured in different ways on</div>

<div dir="auto">Safari/Webkit vs Chromium/Firefox due to limitations of the</div>

<div dir="auto">PerformanceTiming APIs. You may notice that latency is different on</div>

<div dir="auto">different browsers, however the actual bufferbloat (relative increase</div>

<div dir="auto">in latency) should be pretty consistent.</div>

<div dir="auto"><br></div>

<div dir="auto">In terms of some of the changes we made based on the feedback we</div>

<div dir="auto">receive on this list:</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Toke’s feedback:</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015960.html</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015976.html</div>

<div dir="auto">* We changed the way the speed tests run to show an instantaneous</div>

<div dir="auto">speed as the test is being run.</div>

<div dir="auto">* We moved the bufferbloat grade into the main results box.</div>

<div dir="auto">* We tried really hard to get as close to saturating gigabit</div>

<div dir="auto">connections as possible. We redesigned completely the way we chunk</div>

<div dir="auto">files, added a “warming up” period, and spent quite a bit optimizing</div>

<div dir="auto">our code to minimize CPU usage, as we found that was often the</div>

<div dir="auto">limiting factor to our speed test results.</div>

<div dir="auto">* We changed the shield grades altogether and went through a few</div>

<div dir="auto">different iterations of how to show the effect of bufferbloat on</div>

<div dir="auto">connectivity, and ended up with a “table view” to try to show the</div>

<div dir="auto">effect that bufferbloat specifically is having on the connection</div>

<div dir="auto">(compared to when the connection is unloaded).</div>

<div dir="auto">* We now link from the results table view to the FAQ where the</div>

<div dir="auto">conditions for each type of connection are explained.</div>

<div dir="auto">* We also changed the way we measure latency and now use the faster</div>

<div dir="auto">of either Google’s CDN or Cloudflare at any given location. We’re also</div>

<div dir="auto">using the WebTiming APIs to get a more accurate latency number, though</div>

<div dir="auto">this does not work on some mobile browsers (e.g. iOS Safari) and as a</div>

<div dir="auto">result we show a higher latency on mobile devices. Since our test is</div>

<div dir="auto">less a test of absolute latency and more a test of relative latency</div>

<div dir="auto">with and without load, we felt this was workable.</div>

<div dir="auto">* Our jitter is now an average (was previously RMS).</div>

<div dir="auto">* The “before you start” text was rewritten and moved above the start button.</div>

<div dir="auto">* We now spell out upload and download instead of having arrows.</div>

<div dir="auto">* We hugely reduced the number of cross-site scripts. I was a bit</div>

<div dir="auto">embarrassed by this if I’m honest - I spent a long time building web</div>

<div dir="auto">tools for the EFF, where we almost never allowed any cross-site</div>

<div dir="auto">scripts. * Our site is hosted on Shopify, and adding any features via</div>

<div dir="auto">their app store ends up adding a whole lot of gunk. But we uninstalled</div>

<div dir="auto">some apps, rewrote our template, and ended up removing a whole lot of</div>

<div dir="auto">the gunk. There’s still plenty of room for improvement, but it should</div>

<div dir="auto">be a lot better than before.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Dave Collier-Brown’s feedback:</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015966.html</div>

<div dir="auto">* We replaced the “unloaded” and “loaded” language with “unloaded”</div>

<div dir="auto">and then “download active”  and “upload active.” In the grade box we</div>

<div dir="auto">indicate that, for example, “Your latency increased moderately under</div>

<div dir="auto">load.”</div>

<div dir="auto">* We tried to generally make it easier for non-techie folks to</div>

<div dir="auto">understand by emphasizing the grade and adding the table showing how</div>

<div dir="auto">bufferbloat affects some commonly-used services.</div>

<div dir="auto">* We didn’t really change the candle charts too much - they’re</div>

<div dir="auto">mostly just to give a basic visual - we focused more on the actual</div>

<div dir="auto">meat of the results above that.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Sebastian Moeller’s feedback:</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015963.html</div>

<div dir="auto">* We considered doing a bidirectional saturating load, but decided</div>

<div dir="auto">to skip on implementing it for now. * It’s definitely something we’d</div>

<div dir="auto">like to experiment with more in the future.</div>

<div dir="auto">* We added a “warming up” period as well as a “draining” period to</div>

<div dir="auto">help fill and empty the buffer. We haven’t added the option for an</div>

<div dir="auto">extended test, but have this on our list of backlog changes to make in</div>

<div dir="auto">the future.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Y’s feedback (link):</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015962.html</div>

<div dir="auto">* We actually ended up removing the grades, but we explained our</div>

<div dir="auto">criteria for the new table in the FAQ.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Greg White's feedback (shared privately):</div>

<div dir="auto">* We added an FAQ answer explaining jitter and how we measure it.</div>

<div dir="auto"><br></div>

<div dir="auto">We’d love for you all to play with the new version of the tool and</div>

<div dir="auto">send over any feedback you might have. We’re going to be in a feature</div>

<div dir="auto">freeze before launch but we'd love to get any bugs sorted out. We'll</div>

<div dir="auto">likely put this project aside after we iron out a last round of bugs</div>

<div dir="auto">and launch, and turn back to working on projects that help us pay the</div>

<div dir="auto">bills, but we definitely hope to revisit and improve the tool over</div>

<div dir="auto">time.</div>

<div dir="auto"><br></div>

<div dir="auto">Best,</div>

<div dir="auto"><br></div>

<div dir="auto">Sina, Arshan, and Sam.</div>

<div dir="auto">_______________________________________________</div>

<div dir="auto">Bloat mailing list</div>

<div dir="auto">Bloat@lists.bufferbloat.net</div>

<div dir="auto">https://lists.bufferbloat.net/listinfo/bloat</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">--</div>

<div dir="auto">"For a successful technology, reality must take precedence over public</div>

<div dir="auto">relations, for Mother Nature cannot be fooled" - Richard Feynman</div>

<div dir="auto"><br></div>

<div dir="auto">dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto">_______________________________________________</div>

<div dir="auto">Bloat mailing list</div>

<div dir="auto">Bloat@lists.bufferbloat.net</div>

<div dir="auto">https://lists.bufferbloat.net/listinfo/bloat</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

</blockquote>

</blockquote>

</div><div dir="auto"><br></div>

</div></body>

</html>