From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E547F21F22F for ; Wed, 6 May 2015 01:51:12 -0700 (PDT) Received: from u-089-csam313b.am5.uni-tuebingen.de ([134.2.89.14]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4002-1Z7rZ00pWs-00rY4n; Wed, 06 May 2015 10:50:44 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <5549A1B8.50005@superduper.net> Date: Wed, 6 May 2015 10:50:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@email.android.com> <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> <5537CDB7.60301@orange.com> <1429722979.18561.112.camel@edumazet-glaptop2.roam.corp.google.com> <5537DA20.1090008@orange.com> <5537DE4D.8090100@orange.com> <553882D7.4020301@orange.com> <1429771718.22254.32.camel@edumazet-glaptop2.roam.corp.google.com> <6C0D04CF-53AA-4D18-A4E4-B746AF6487C7@gmx.de> <87wq123p5r.fsf@toke.dk> <2288B614-B415-4017-A842-76E8F5DFDE4C@gmx.de> <553B06CE.1050209@superduper.net> <14ceed3c818.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <0C930D43-A05B-48E2-BC01-792CAA72CAD1@gmx.de> <5549A1B8.50005@superduper.net> To: Simon Barber X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:jOPoj8tlgh0JhTMDk2lyQyuqbl7kg9bWTpkNKYYoIEWUQJV3NZE O7zKsdqn/a9H9TPwQhWGpRH52CPVxx3EH7qPJhBP99Sjp9hWqwn/qEkM/Rtt/seOgWoDwzW rrsI3nTNqwBkBDYql4V1+MyoOaLcPT/D6oYwR9XrLKFbI6OCAcdiHbpIYHhLcgHtyXGlGiQ mX06vr0FTUxz/DZHr7++g== X-UI-Out-Filterresults: notjunk:1; Cc: bloat Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 08:51:41 -0000 X-List-Received-Date: Wed, 06 May 2015 08:51:41 -0000 X-List-Received-Date: Wed, 06 May 2015 08:51:41 -0000 Hi Simon, On May 6, 2015, at 07:08 , Simon Barber wrote: > Hi Sebastian, >=20 > 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 =93bloat-measurement=94= 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=92. We could turn this around by estimating to what distance voip = quality will be good/decent/acceptable/lughable=85 Best Regards Sebastian >=20 > Simon >=20 >=20 > On 4/24/2015 11:03 PM, Sebastian Moeller wrote: >> Hi Simon, hi List >>=20 >> On Apr 25, 2015, at 06:26 , Simon Barber = wrote: >>=20 >>> 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=94 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=92t know where they are coming = from ;) ) >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>> Simon >>>=20 >>> Sent with AquaMail for Android >>> http://www.aqua-mail.com >>>=20 >>>=20 >>> On April 24, 2015 9:04:45 PM Dave Taht wrote: >>>=20 >>>> 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. >>>>=20 >>>> Please see my earlier email laying out the bands. And gettys' = manifesto. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> On Fri, Apr 24, 2015 at 8:15 PM, Simon Barber = wrote: >>>>> I think it might be useful to have a 'latency guide' for users. It = would say >>>>> things like >>>>>=20 >>>>> 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... >>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Gaming.... some kind of guide here.... >>>>>=20 >>>>> Simon >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4/24/2015 1:55 AM, Sebastian Moeller wrote: >>>>>> Hi Toke, >>>>>>=20 >>>>>> On Apr 24, 2015, at 10:29 , Toke H=F8iland-J=F8rgensen = wrote: >>>>>>=20 >>>>>>> Sebastian Moeller writes: >>>>>>>=20 >>>>>>>> I know this is not perfect and the numbers will probably = require >>>>>>>> severe "bike-shedding=94 >>>>>>> Since you're literally asking for it... ;) >>>>>>>=20 >>>>>>>=20 >>>>>>> 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 ;) ) >>>>>>=20 >>>>>>> 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? >>>>>>>=20 >>>>>>>=20 >>>>>>> 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: >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> correct? >>>>>>=20 >>>>>>=20 >>>>>>> -Toke >>>>>> _______________________________________________ >>>>>> Bloat mailing list >>>>>> Bloat@lists.bufferbloat.net >>>>>> https://lists.bufferbloat.net/listinfo/bloat >>>>>=20 >>>>> _______________________________________________ >>>>> Bloat mailing list >>>>> Bloat@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/bloat >>>>=20 >>>>=20 >>>> -- >>>> Dave T=E4ht >>>> Open Networking needs **Open Source Hardware** >>>>=20 >>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >>>=20 >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >=20