From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 D454121F1E1 for ; Tue, 28 Apr 2015 00:18:44 -0700 (PDT) Received: from u-089-d061.biologie.uni-tuebingen.de ([134.2.89.61]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lz3nU-1ZQkRy0T68-014Czp; Tue, 28 Apr 2015 09:18:38 +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: Date: Tue, 28 Apr 2015 09:18:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D70AD75-F177-4146-A4D6-2FD6DB408B63@gmx.de> References: <20150422040453.GB36239@sesse.net> <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> <1429710657.18561.68.camel@edumazet-glaptop2.roam.corp.google.com> <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> To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:rIMKSg9J7+rwFJn10W8lrAJV/2KQUOS0qpxyuWwstL5T9wcvVK8 1wQPuDmlG9DVGGbXG3XhfQOz4aHS3nZLLX14OVSG6ca9Wi/ER4Cb97tHbCEPkXqkljk57nU Lqsz5WjN/P65LYNNbd1wHkxDFwUKUlzqWe9OFLJkuGJnd/yT1a1sgXA7H2EKHuH10HNspQ+ 21TxXXB/dFDaAKQfODaLA== 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: Tue, 28 Apr 2015 07:19:14 -0000 Hi Dave, On Apr 27, 2015, at 18:39 , Dave Taht wrote: > On Fri, Apr 24, 2015 at 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. >>=20 >> 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 > At one level I am utterly prepared to set new (And lower) standards > for latency, and not necessarily pay attention to compromise driven > standards processes established in the 70s and 80s, but to the actual > user experience numbers that jim cited in the fq+aqm manefesto on his > blog. I am not sure I git the right one, could you please post a link = to the document you are referring to? My personal issue with new = standards is that it is going to be harder to convince others that these = are real and not simply selected to push our agenda., hence using other = peoples numbers, preferably numbers backed up by research ;) I also note = that in the ITU numbers I dragged into the discussion the measurement = pretends to be mouth to ear (one way) delay, so for intermediate = buffering the thresholds need to be lower to allow for sampling interval = (I think typically 10ms for the usual codecs G.711 and G.722), further = sender processing and receiver processing, so I guess for the ITU = thresholds we should subtract say 30ms for processing and then doube it = to go from one-way delay to RTT. Now I am amazed how large the resulting = RTTs actually are, so I assume I need to scrutinize the psycophysics = experiments that hopefully underlay those numbers... >=20 > I consider induced latencies of 30ms as a "green" band because that is > the outer limit of the range modern aqm technologies can achieve (fq > can get closer to 0). There was a lot of debate about 20ms being the > right figure for induced latency and/or jitter, a year or two back, > and we settled on 30ms for both, so that number is already a > compromise figure. Ah, I think someone brought this up already, do we need to make = allowances for slow links? If a full packet traversal is already 16ms = can we really expect 30ms? And should we even care, I mean, a slow link = is a slow link and will have some drawbacks maybe we should just expose = those instead of rationalizing them away? On the other hand I tend to = think that in the end it is all about the cumulative performance of the = link for most users, i.e. if the link allows glitch-free voip while = heavy up- and downloads go on, normal users should not care one iota = what the induced latency actually is (aqm or no aqm as long as the link = behaves well nothing needs changing) >=20 > It is highly likely that folk here are not aware of the extra-ordinary > amount of debate that went into deciding the ultimate ATM cell size > back in the day. The eu wanted 32 bytes, the US 48, both because that > was basically a good size for the local continental distance and echo > cancellation stuff, at the time. >=20 > In the case of voip, jitter is actually more important than latency. > Modern codecs and coding techniques can tolerate 30ms of jitter, just > barely, without sound artifacts. >60ms, boom, crackle, hiss. Ah, and here is were I understand why my simplistic model from = above fails; induced latency will contribute significantly to jitter and = hence is a good proxy for link-suitability for real-time applications. = So I agree using the induced latency as measure to base the color bands = from sounds like a good approach. >=20 >=20 >> Best Regards >> Sebastian >>=20 >>=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. >>=20 >> 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: >>>>>>=20 >>>>>> 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 >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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! >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Bloat mailing list >>>>>> Bloat@lists.bufferbloat.net >>>>>> https://lists.bufferbloat.net/listinfo/bloat >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Bloat mailing list >>>>> Bloat@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/bloat >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Dave T=E4ht >>>> Open Networking needs **Open Source Hardware** >>>>=20 >>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >>>=20 >>>=20 >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht > Open Networking needs **Open Source Hardware** >=20 > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67