<!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">Having more detail available but not shown by default on the main page might keep the geeks happy and make diagnosis easier.</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 25, 2021 12:11:02 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 kind words, Simon!</div>
<div dir="auto"><br></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">Since you are measuring buffer bloat - how much latency *can* be caused by the excessive buffering, expressing the jitter number in terms of 95%ile would be appropriate - as that’s closely related to how large the excessive buffer is. The average jitter is more related to how the competing TCP streams have some gaps due to congestion control and these gaps can temporarily lower the buffer occupancy and result in a lower average jitter number.</div>
</blockquote>
<div dir="auto"><br></div>
<div dir="auto">I'm thinking that we might even remove jitter altogether from the UI,</div>
<div dir="auto">and instead just show 95%ile latency. 95%ile latency and 95%ile jitter</div>
<div dir="auto">should be equivalent, but 95% latency is really the more meaningful</div>
<div dir="auto">measure for real-time communications, it feels like?</div>
<div dir="auto"><br></div>
<div dir="auto">On Thu, Feb 25, 2021 at 11:57 AM 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">Hi Sina,</div>
<div dir="auto"><br></div>
<div dir="auto">That sounds great, and I understand the desire to separate the fixed component of latency and the buffer bloat / variable part. Messaging that in a way that accurately conveys the end user impact and the impact due to unmitigated buffers while being easy to understand is tricky.</div>
<div dir="auto"><br></div>
<div dir="auto">Since you are measuring buffer bloat - how much latency *can* be caused by the excessive buffering, expressing the jitter number in terms of 95%ile would be appropriate - as that’s closely related to how large the excessive buffer is. The average jitter is more related to how the competing TCP streams have some gaps due to congestion control and these gaps can temporarily lower the buffer occupancy and result in a lower average jitter number.</div>
<div dir="auto"><br></div>
<div dir="auto">Really appreciate this work, and the interface and ‘latency first’ nature of this test. It’s a great contribution, and will hopefully help drive ISPs to reducing their bloat, helping everyone.</div>
<div dir="auto"><br></div>
<div dir="auto">Simon</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">On Feb 25, 2021, at 11:47 AM, 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 #669900; padding-left: 0.75ex;">
<div dir="auto">So perhaps this can feed into the rating system, total latency < 50mS is an A, < 150mS is a B, 600mS is a C or something like that.</div>
</blockquote>
<div dir="auto"><br></div>
<div dir="auto">The "grade" we give is purely a measure of bufferbloat. If you start</div>
<div dir="auto">with a latency of 500 ms on your connection, it wouldn't be fair for</div>
<div dir="auto">us to give you an F grade even if there is no increase in latency due</div>
<div dir="auto">to bufferbloat.</div>
<div dir="auto"><br></div>
<div dir="auto">This is why we added the "Real-World Impact" table below the grade -</div>
<div dir="auto">in many cases people may start with a connection that is already</div>
<div dir="auto">problematic for video conferencing, VoIP, and gaming.</div>
<div dir="auto"><br></div>
<div dir="auto">I think we're going to change the conditions on that table to have</div>
<div dir="auto">high 95%ile latency trigger the degraded performance shield warnings.</div>
<div dir="auto">In the future it might be neat for us to move to grades on the table</div>
<div dir="auto">as well.</div>
<div dir="auto"><br></div>
<div dir="auto"><br></div>
<div dir="auto">On Thu, Feb 25, 2021 at 5:53 AM Simon Barber <simon@superduper.net> 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">So perhaps this can feed into the rating system, total latency < 50mS is an A, < 150mS is a B, 600mS is a C or something like that.</div>
<div dir="auto"><br></div>
<div dir="auto">Simon</div>
<div dir="auto"><br></div>
<div dir="auto">On February 25, 2021 5:49:26 AM Mikael Abrahamsson <swmike@swm.pp.se> wrote:</div>
<div dir="auto"><br></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">On Thu, 25 Feb 2021, Simon Barber wrote:</div>
<div dir="auto"><br></div>
<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #CC0000; padding-left: 0.75ex;">
<div dir="auto">The ITU say voice should be <150mS, however in the real world people are</div>
<div dir="auto">a lot more tolerant. A GSM -> GSM phone call is ~350mS, and very few</div>
<div dir="auto">people complain about that. That said the quality of the conversation is</div>
<div dir="auto">affected, and staying under 150mS is better for a fast free flowing</div>
<div dir="auto">conversation. Most people won't have a problem at 600mS and will have a</div>
<div dir="auto">problem at 1000mS. That is for a 2 party voice call. A large group</div>
<div dir="auto">presentation over video can tolerate more, but may have issues with</div>
<div dir="auto">talking over when switching from presenter to questioner for example.</div>
</blockquote>
<div dir="auto"><br></div>
<div dir="auto"><br></div>
<div dir="auto">I worked at a phone company 10+ years ago. We had some equipment that</div>
<div dir="auto">internally was ATM based and each "hop" added 7ms. This in combination</div>
<div dir="auto">with IP based telephony at the end points that added 40ms one-way per</div>
<div dir="auto">end-point (PDV buffer) caused people to complain when RTT started creeping</div>
<div dir="auto">up to 300-400ms. This was for PSTN calls.</div>
<div dir="auto"><br></div>
<div dir="auto">Yes, people might have more tolerance with mobile phone calls because they</div>
<div dir="auto">have lower expectations when out and about, but my experience is that</div>
<div dir="auto">people will definitely notice 300-400ms RTT but they might not get upset</div>
<div dir="auto">enough to open a support ticket until 600ms or more.</div>
<div dir="auto"><br></div>
<div dir="auto">--</div>
<div dir="auto">Mikael Abrahamsson email: swmike@swm.pp.se</div>
</blockquote>
<div dir="auto"><br></div>
<div dir="auto"><br></div>
</blockquote>
</blockquote>
<div dir="auto"><br></div>
</blockquote>
</blockquote>
</div><div dir="auto"><br></div>
</div></body>
</html>