From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 8161621F24E for ; Wed, 6 May 2015 11:03:44 -0700 (PDT) Received: from hms-beagle-5.home.lan ([217.247.216.138]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MEo4s-1Z0Wyg12DK-00G4T8; Wed, 06 May 2015 20:03:36 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 6 May 2015 20:03:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <393E0254-820A-48D3-9AC3-DCF30C952AEB@gmx.de> 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: Jim Gettys X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:W0wFW9kkXJOAQkHX1SOXHKa0h5MCsPVtJHoZf2D8z9pbYh47pZb dyHSn528r72ZiIw+AvI+bnPUGjgLVfqXh4a/0dIINPMsa1iexDjGnLWEz3I9uudgVTXXyHi ffmP6DIdBNU35sgUWVEyAMqAq27i7yGXFeigiLeYaZpBmpw0tZLKmONCVNtuwitOC/RHm++ b6iaGOxCXcxJYP2g9q0SQ== 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 18:04:18 -0000 Hi Jim, hi List, On May 6, 2015, at 17:30 , Jim Gettys wrote: >=20 >=20 > On Wed, May 6, 2015 at 4:50 AM, Sebastian Moeller = wrote: > Hi Simon, >=20 > On May 6, 2015, at 07:08 , Simon Barber wrote: >=20 > > Hi Sebastian, > > > > My numbers are what I've personally come up with after working for = many years with VoIP - they have no other basis. >=20 > 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. >=20 > > One thing is that you have to compare apples to apples - the ITU = numbers are for acoustic one way delay. >=20 > 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. >=20 > > 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. >=20 > 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 = =E2=80=9Cbloat-measurement=E2=80=9D 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). >=20 > > 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=E2=80=99= . >=20 > We could turn this around by estimating to what distance voip = quality will be good/decent/acceptable/lughable=E2=80=A6 >=20 > =E2=80=8B >=20 > =E2=80=8BMean 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. >=20 > 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. Yes, I fully endorse this! What I tried to propose in a slightly = convoluted way, was to use the fact that we have a handle on at least = one major jitter source, namely the induced latency under load, so we = can take the mean RTT and a proxy for the jitter into account. We = basically can say that with a given jitter (assuming a proper dimension) = we can estimate how far a given one-way mouth to ear delay will carry a = voip call: e.g.: ;et=E2=80=99s take the 150ms ITU number just for a = start, subtract an empirically estimated max induced latency of say 60ms = (to account for the required de-jitter buffer), as well as 20ms = sample-time-per-voip packet (and then just ignore all other processing = overhead) and end up with 150-60-20 =3D 70ms which at 5ms per 1000Km = means 70/5 * 1000 =3D 14000km, which still is decent it also shows that = at shorter distances the delay will be shorter. Or to turn this argument = around the same system with a induced latency/jitter of 10ms will carry = (150-10-20)/5 * 1000 =3D 24000 km. TL;DR with a measured latency under load we have a decent = estimator for the jitter and can for example express the gain of beating = buffer bloat in increased reach (be it voip call distance or for gamers = distance to servers with still acceptable reactivity or some such). Best Regards Sebastian > - Jim >=20 >=20 > =E2=80=8B=20 > =20 > =E2=80=8B >=20 > > > > Simon > > > > > > On 4/24/2015 11:03 PM, Sebastian Moeller wrote: > >> Hi Simon, hi List > >> > >> On Apr 25, 2015, at 06:26 , Simon Barber = 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=E2=80=9D 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=E2=80=99t 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 = 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 = 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=C3=B8iland-J=C3=B8rgensen = wrote: > >>>>>> > >>>>>>> Sebastian Moeller writes: > >>>>>>> > >>>>>>>> I know this is not perfect and the numbers will probably = require > >>>>>>>> severe "bike-shedding=E2=80=9D > >>>>>>> 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 > >>>>>> Bloat@lists.bufferbloat.net > >>>>>> https://lists.bufferbloat.net/listinfo/bloat > >>>>> > >>>>> _______________________________________________ > >>>>> Bloat mailing list > >>>>> Bloat@lists.bufferbloat.net > >>>>> https://lists.bufferbloat.net/listinfo/bloat > >>>> > >>>> > >>>> -- > >>>> Dave T=C3=A4ht > >>>> Open Networking needs **Open Source Hardware** > >>>> > >>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > >>> > >>> _______________________________________________ > >>> 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