<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 4:50 AM, Sebastian Moeller <span dir="ltr"><<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Simon,<br>
<span class=""><br>
On May 6, 2015, at 07:08 , Simon Barber <<a href="mailto:simon@superduper.net">simon@superduper.net</a>> wrote:<br>
<br>
> Hi Sebastian,<br>
><br>
> My numbers are what I've personally come up with after working for many years with VoIP - they have no other basis.<br>
<br>
</span> I did not intend to be-little such numbers at all, I just wanted to propose that we either use generally accepted scientifically measured numbers or make such measurements our self.<br>
<span class=""><br>
> One thing is that you have to compare apples to apples - the ITU numbers are for acoustic one way delay.<br>
<br>
</span>True, and this is why we easily can estimate the delay cost of different stages of the whole voip one-way pipeline to deuce how much latent budget we have for the network (aka buffer bloat on the way), but still bases our numbers on some reference for mouth-to-ear-delay. I think we can conservatively estimate the latency cost of the sampling, sender processing and receiver processing (outside of the de-jitter buffering) seem harder to estimate reliably, to my untrained eye.<br>
<span class=""><br>
> The poor state of jitter buffer implementations that almost every VoIP app or device has means that to hit these acoustic delay numbers you need significantly lower network delays.<br>
<br>
</span> I fully agree, and if we can estimate this I think we can justify deductions from the mouth-to-ear budget. I would as first approximation assume that what we call latency under load increase to be tightly correlated with jitter, so we could take our “bloat-measurement” in ms an directly deduct it from the budget (or if we want to accept occasional voice degradation we can pick a sufficiently high percentile, but that is implementation detail).<br>
<span class=""><br>
> Also note that these numbers are worst case, which must include trip halfway around the globe - if you can hit the numbers with half globe propagation then you will hit much better numbers for 'local calls’.<br>
<br>
</span> We could turn this around by estimating to what distance voip quality will be good/decent/acceptable/lughable…<br>
<br><span class="HOEnZb"><font color="#888888"><div class="gmail_default" style="font-size:small;display:inline"></div></font></span></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">Mean RTT is almost useless for VOIP and teleconferencing. What matters is the RTT + jitter; a VOIP or teleconferencing application cannot function at a given latency unless the "drop outs" caused by late packets is low enough to not be obnoxious to human perception; there are a number of techniques to hide such late packet dropouts but all of them (short of FEC) damage the audio stream.</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">So ideally, not only do you measure the delay, you also measure the jitter to be able to figure out a realistic operating point for such applications.</div></div><div><div class="gmail_default" style="font-size:small;display:inline"> - Jim</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><div class="gmail_default" style="font-size:small;display:inline"></div><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Simon<br>
><br>
><br>
> On 4/24/2015 11:03 PM, Sebastian Moeller wrote:<br>
>> Hi Simon, hi List<br>
>><br>
>> On Apr 25, 2015, at 06:26 , Simon Barber <<a href="mailto:simon@superduper.net">simon@superduper.net</a>> wrote:<br>
>><br>
>>> Certainly the VoIP numbers are for peak total latency, and while Justin is measuring total latency because he is only taking a few samples the peak values will be a little higher.<br>
>> If your voip number are for peak total latency they need literature citations to back them up, as they are way shorter than what the ITU recommends for one-way-latency (see ITU-T G.114, Fig. 1). I am not "married” to the ITU numbers but I think we should use generally accepted numbers here and not bake our own thresholds (and for all I know your numbers are fine, I just don’t know where they are coming from ;) )<br>
>><br>
>> Best Regards<br>
>> Sebastian<br>
>><br>
>><br>
>>> Simon<br>
>>><br>
>>> Sent with AquaMail for Android<br>
>>> <a href="http://www.aqua-mail.com" target="_blank">http://www.aqua-mail.com</a><br>
>>><br>
>>><br>
>>> On April 24, 2015 9:04:45 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>>><br>
>>>> simon all your numbers are too large by at least a factor of 2. I<br>
>>>> think also you are thinking about total latency, rather than induced<br>
>>>> latency and jitter.<br>
>>>><br>
>>>> Please see my earlier email laying out the bands. And gettys' manifesto.<br>
>>>><br>
>>>> If you are thinking in terms of voip, less than 30ms *jitter* is what<br>
>>>> you want, and a latency increase of 30ms is a proxy for also holding<br>
>>>> jitter that low.<br>
>>>><br>
>>>><br>
>>>> On Fri, Apr 24, 2015 at 8:15 PM, Simon Barber <<a href="mailto:simon@superduper.net">simon@superduper.net</a>> wrote:<br>
>>>>> I think it might be useful to have a 'latency guide' for users. It would say<br>
>>>>> things like<br>
>>>>><br>
>>>>> 100ms - VoIP applications work well<br>
>>>>> 250ms - VoIP applications - conversation is not as natural as it could be,<br>
>>>>> although users may not notice this.<br>
>> The only way to detect whether a conversation is natural is if users notice, I would say...<br>
>><br>
>>>>> 500ms - VoIP applications begin to have awkward pauses in conversation.<br>
>>>>> 1000ms - VoIP applications have significant annoying pauses in conversation.<br>
>>>>> 2000ms - VoIP unusable for most interactive conversations.<br>
>>>>><br>
>>>>> 0-50ms - web pages load snappily<br>
>>>>> 250ms - web pages can often take an extra second to appear, even on the<br>
>>>>> highest bandwidth links<br>
>>>>> 1000ms - web pages load significantly slower than they should, taking<br>
>>>>> several extra seconds to appear, even on the highest bandwidth links<br>
>>>>> 2000ms+ - web browsing is heavily slowed, with many seconds or even 10s of<br>
>>>>> seconds of delays for pages to load, even on the highest bandwidth links.<br>
>>>>><br>
>>>>> Gaming.... some kind of guide here....<br>
>>>>><br>
>>>>> Simon<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On 4/24/2015 1:55 AM, Sebastian Moeller wrote:<br>
>>>>>> Hi Toke,<br>
>>>>>><br>
>>>>>> On Apr 24, 2015, at 10:29 , Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br>
>>>>>><br>
>>>>>>> Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> writes:<br>
>>>>>>><br>
>>>>>>>> I know this is not perfect and the numbers will probably require<br>
>>>>>>>> severe "bike-shedding”<br>
>>>>>>> Since you're literally asking for it... ;)<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> In this case we're talking about *added* latency. So the ambition should<br>
>>>>>>> be zero, or so close to it as to be indiscernible. Furthermore, we know<br>
>>>>>>> that proper application of a good queue management algorithm can keep it<br>
>>>>>>> pretty close to this. Certainly under 20-30 ms of added latency. So from<br>
>>>>>>> this, IMO the 'green' or 'excellent' score should be from zero to 30 ms.<br>
>>>>>> Oh, I can get behind that easily, I just thought basing the limits<br>
>>>>>> on externally relevant total latency thresholds would directly tell the user<br>
>>>>>> which applications might run well on his link. Sure this means that people<br>
>>>>>> on a satellite link most likely will miss out the acceptable voip threshold<br>
>>>>>> by their base-latency alone, but guess what telephony via satellite leaves<br>
>>>>>> something to be desired. That said if the alternative is no telephony I<br>
>>>>>> would take 1 second one-way delay any day ;).<br>
>>>>>> What I liked about fixed thresholds is that the test would give a<br>
>>>>>> good indication what kind of uses are going to work well on the link under<br>
>>>>>> load, given that during load both base and induced latency come into play. I<br>
>>>>>> agree that 300ms as first threshold is rather unambiguous though (and I am<br>
>>>>>> certain that remote X11 will require a massively lower RTT unless one likes<br>
>>>>>> to think of remote desktop as an oil tanker simulator ;) )<br>
>>>>>><br>
>>>>>>> The other increments I have less opinions about, but 100 ms does seem to<br>
>>>>>>> be a nice round number, so do yellow from 30-100 ms, then start with the<br>
>>>>>>> reds somewhere above that, and range up into the deep red / purple /<br>
>>>>>>> black with skulls and fiery death as we go nearer and above one second?<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> I very much think that raising peoples expectations and being quite<br>
>>>>>>> ambitious about what to expect is an important part of this. Of course<br>
>>>>>>> the base latency is going to vary, but the added latency shouldn't. And<br>
>>>>>>> sine we have the technology to make sure it doesn't, calling out bad<br>
>>>>>>> results when we see them is reasonable!<br>
>>>>>> Okay so this would turn into:<br>
>>>>>><br>
>>>>>> base latency to base latency + 30 ms: green<br>
>>>>>> base latency + 31 ms to base latency + 100 ms: yellow<br>
>>>>>> base latency + 101 ms to base latency + 200 ms: orange?<br>
>>>>>> base latency + 201 ms to base latency + 500 ms: red<br>
>>>>>> base latency + 501 ms to base latency + 1000 ms: fire<br>
>>>>>> base latency + 1001 ms to infinity:<br>
>>>>>> fire & brimstone<br>
>>>>>><br>
>>>>>> correct?<br>
>>>>>><br>
>>>>>><br>
>>>>>>> -Toke<br>
>>>>>> _______________________________________________<br>
>>>>>> Bloat mailing list<br>
>>>>>> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
>>>>>> <a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Bloat mailing list<br>
>>>>> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
>>>>> <a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Dave Täht<br>
>>>> Open Networking needs **Open Source Hardware**<br>
>>>><br>
>>>> <a href="https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67" target="_blank">https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Bloat mailing list<br>
>>> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
>>> <a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
><br>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</div></div></blockquote></div><br></div></div>