Hi Simon,
On May 6, 2015, at 07:08 , Simon Barber <[email protected]> wrote:
> Hi Sebastian,
>
> My numbers are what I've personally come up with after working for many years
> with VoIP - they have no other basis.
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.
> One thing is that you have to compare apples to apples - the ITU numbers are
> for acoustic one way delay.
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.
> 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.
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).
> 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’.
We could turn this around by estimating to what distance voip quality
will be good/decent/acceptable/lughable…
Best Regards
Sebastian
>
> Simon
>
>
> On 4/24/2015 11:03 PM, Sebastian Moeller wrote:
>> Hi Simon, hi List
>>
>> On Apr 25, 2015, at 06:26 , Simon Barber <[email protected]> wrote:
>>
>>> 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.
>> 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 ;) )
>>
>> Best Regards
>> Sebastian
>>
>>
>>> Simon
>>>
>>> Sent with AquaMail for Android
>>> http://www.aqua-mail.com
>>>
>>>
>>> On April 24, 2015 9:04:45 PM Dave Taht <[email protected]> wrote:
>>>
>>>> simon all your numbers are too large by at least a factor of 2. I
>>>> think also you are thinking about total latency, rather than induced
>>>> latency and jitter.
>>>>
>>>> Please see my earlier email laying out the bands. And gettys' manifesto.
>>>>
>>>> If you are thinking in terms of voip, less than 30ms *jitter* is what
>>>> you want, and a latency increase of 30ms is a proxy for also holding
>>>> jitter that low.
>>>>
>>>>
>>>> On Fri, Apr 24, 2015 at 8:15 PM, Simon Barber <[email protected]> wrote:
>>>>> I think it might be useful to have a 'latency guide' for users. It would
>>>>> say
>>>>> things like
>>>>>
>>>>> 100ms - VoIP applications work well
>>>>> 250ms - VoIP applications - conversation is not as natural as it could be,
>>>>> although users may not notice this.
>> The only way to detect whether a conversation is natural is if users
>> notice, I would say...
>>
>>>>> 500ms - VoIP applications begin to have awkward pauses in conversation.
>>>>> 1000ms - VoIP applications have significant annoying pauses in
>>>>> conversation.
>>>>> 2000ms - VoIP unusable for most interactive conversations.
>>>>>
>>>>> 0-50ms - web pages load snappily
>>>>> 250ms - web pages can often take an extra second to appear, even on the
>>>>> highest bandwidth links
>>>>> 1000ms - web pages load significantly slower than they should, taking
>>>>> several extra seconds to appear, even on the highest bandwidth links
>>>>> 2000ms+ - web browsing is heavily slowed, with many seconds or even 10s of
>>>>> seconds of delays for pages to load, even on the highest bandwidth links.
>>>>>
>>>>> Gaming.... some kind of guide here....
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/24/2015 1:55 AM, Sebastian Moeller wrote:
>>>>>> Hi Toke,
>>>>>>
>>>>>> On Apr 24, 2015, at 10:29 , Toke Høiland-Jørgensen <[email protected]> wrote:
>>>>>>
>>>>>>> Sebastian Moeller <[email protected]> writes:
>>>>>>>
>>>>>>>> I know this is not perfect and the numbers will probably require
>>>>>>>> severe "bike-shedding”
>>>>>>> Since you're literally asking for it... ;)
>>>>>>>
>>>>>>>
>>>>>>> In this case we're talking about *added* latency. So the ambition should
>>>>>>> be zero, or so close to it as to be indiscernible. Furthermore, we know
>>>>>>> that proper application of a good queue management algorithm can keep it
>>>>>>> pretty close to this. Certainly under 20-30 ms of added latency. So from
>>>>>>> this, IMO the 'green' or 'excellent' score should be from zero to 30 ms.
>>>>>> Oh, I can get behind that easily, I just thought basing the
>>>>>> limits
>>>>>> on externally relevant total latency thresholds would directly tell the
>>>>>> user
>>>>>> which applications might run well on his link. Sure this means that
>>>>>> people
>>>>>> on a satellite link most likely will miss out the acceptable voip
>>>>>> threshold
>>>>>> by their base-latency alone, but guess what telephony via satellite
>>>>>> leaves
>>>>>> something to be desired. That said if the alternative is no telephony I
>>>>>> would take 1 second one-way delay any day ;).
>>>>>> What I liked about fixed thresholds is that the test would give a
>>>>>> good indication what kind of uses are going to work well on the link
>>>>>> under
>>>>>> load, given that during load both base and induced latency come into
>>>>>> play. I
>>>>>> agree that 300ms as first threshold is rather unambiguous though (and I
>>>>>> am
>>>>>> certain that remote X11 will require a massively lower RTT unless one
>>>>>> likes
>>>>>> to think of remote desktop as an oil tanker simulator ;) )
>>>>>>
>>>>>>> The other increments I have less opinions about, but 100 ms does seem to
>>>>>>> be a nice round number, so do yellow from 30-100 ms, then start with the
>>>>>>> reds somewhere above that, and range up into the deep red / purple /
>>>>>>> black with skulls and fiery death as we go nearer and above one second?
>>>>>>>
>>>>>>>
>>>>>>> I very much think that raising peoples expectations and being quite
>>>>>>> ambitious about what to expect is an important part of this. Of course
>>>>>>> the base latency is going to vary, but the added latency shouldn't. And
>>>>>>> sine we have the technology to make sure it doesn't, calling out bad
>>>>>>> results when we see them is reasonable!
>>>>>> Okay so this would turn into:
>>>>>>
>>>>>> base latency to base latency + 30 ms: green
>>>>>> base latency + 31 ms to base latency + 100 ms: yellow
>>>>>> base latency + 101 ms to base latency + 200 ms: orange?
>>>>>> base latency + 201 ms to base latency + 500 ms: red
>>>>>> base latency + 501 ms to base latency + 1000 ms: fire
>>>>>> base latency + 1001 ms to infinity:
>>>>>> fire & brimstone
>>>>>>
>>>>>> correct?
>>>>>>
>>>>>>
>>>>>>> -Toke
>>>>>> _______________________________________________
>>>>>> Bloat mailing list
>>>>>> [email protected]
>>>>>> https://lists.bufferbloat.net/listinfo/bloat
>>>>>
>>>>> _______________________________________________
>>>>> Bloat mailing list
>>>>> [email protected]
>>>>> https://lists.bufferbloat.net/listinfo/bloat
>>>>
>>>>
>>>> --
>>>> Dave Täht
>>>> Open Networking needs **Open Source Hardware**
>>>>
>>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> [email protected]
>>> https://lists.bufferbloat.net/listinfo/bloat
>
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
