From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 46C4321F1E1 for ; Tue, 28 Apr 2015 07:02:46 -0700 (PDT) Received: by oift201 with SMTP id t201so116772131oif.3 for ; Tue, 28 Apr 2015 07:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uC2sIrOzd3/NjHhygWPbI50ZChBSyFe3EWUCAcjqbK0=; b=mGPamUoW+F50g0VswmEKzRTCIYdOMdnRFvqHP8wRcAq8EoFL+B1jrlr8GYUGp0aVky bXZrCpMOkshKhp2YcLr39JbR8HdNgmR0AxIRWAApcs+clZIMKv1IS0SAWRm05Vh+6kHC P8JxAVzd43xarSzhlgAJ/bORWxChZ0ZSmfUe+EIG974KtAlOjsOTrJNBJ7ByY5RLaPxu z7/1DwvSVa48F8TMceAsjf1EyqMWRkUx2O4mjmIpqB6LfhIfjHYz9NpeQKfguqvebzZd huuLa+ZrjysLhhF/zh1NiEOLP064RfKbfpAf86RzuTpl2LWENz2EML8y12aeMjB8XW6C Tq3A== MIME-Version: 1.0 X-Received: by 10.182.78.101 with SMTP id a5mr14530045obx.45.1430229762705; Tue, 28 Apr 2015 07:02:42 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Tue, 28 Apr 2015 07:02:42 -0700 (PDT) In-Reply-To: <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> <1D70AD75-F177-4146-A4D6-2FD6DB408B63@gmx.de> Date: Tue, 28 Apr 2015 07:02:42 -0700 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 14:03:18 -0000 On Tue, Apr 28, 2015 at 12:18 AM, Sebastian Moeller wrote= : > Hi Dave, > > On Apr 27, 2015, at 18:39 , Dave Taht wrote: > >> On Fri, Apr 24, 2015 at 11:03 PM, Sebastian Moeller wr= ote: >>> 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 Justi= n is measuring total latency because he is only taking a few samples the pe= ak values will be a little higher. >>> >>> If your voip number are for peak total latency they need literat= ure citations to back them up, as they are way shorter than what the ITU re= commends 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 n= umbers here and not bake our own thresholds (and for all I know your number= s are fine, I just don=E2=80=99t know where they are coming from ;) ) >> >> 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 t= o the document you are referring to? I tend to refer to this as the fq+aqm "manifesto": https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-= traditional-aqm-is-not-enough/ Although jim takes too long to get to the fq portion of it. This was because the uphill battle with the ietf was all about e2e vs aqm techniques with FQ hardly on the table at all when we started. Also I view many of the numbers he cited as *outer bounds* for latency. While some might claim a band can make good music with 30ms latency, I generally have to stay within 8 feet or less of the drummer.... >My personal issue with new standards is that it is going to be harder to c= onvince others that these are real and not simply selected to push our agen= da., hence using other peoples numbers, preferably numbers backed up by res= earch ;) Sebastian pointed out to me privately about the old ATM dispute: "The way I heard the story, it was France pushing for 32 bytes as this would allow a national net without the need for echo cancelation, while the US already required echo cancelation and wanted 64 bytes. In true salomonic fashion 48 bytes was selected, pleasing no one ;) (see http://cntic03.hit.bme.hu/meres/ATMFAQ/d7.htm). Nice story." >I also note that in the ITU numbers I dragged into the discussion the meas= urement pretends to be mouth to ear (one way) delay, so for intermediate bu= ffering the thresholds need to be lower to allow for sampling interval (I t= hink typically 10ms for the usual codecs G.711 and G.722), further sender p= rocessing and receiver processing, so I guess for the ITU thresholds we sho= uld subtract say 30ms for processing and then doube it to go from one-way d= elay 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 u= nderlay those numbers... The analogy I use when discussing this with people in the real world, goes like this: "Here we are discussing this around a lunch table. a single millisecond is about a foot, and I am about 3 feet from you, so the ideal latency for conversation is much, much less than the maximum laid out by multiple standards for voice. Shall we try to have this conversation from 30ms/feet apart?" Less latency =3D more intimacy. How many here have had a whispered conversation into a lover's ear? Would it have been anywhere near as good if you were across the hall? Far be it for me to project internet latency reductions as being key to achieving world peace and better mutual understanding[1], but this simple comparison of real world latencies to established standards makes a ton of sense to me and everyone I have tried this comparison on. The existing standards for voice were driven by what was achievable at the time, more than they were driven by psychoacoustics. I am glad that the opus voice codec can get as low as 2.7ms latency, and sad that we have to capture whole frames (~16ms) nowadays for video. Perhaps we will see scanline video grabbers re-emerge as a viable videoconferencing tool one day. > >> >> 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 a= llowances 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 instea= d 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) > >> >> 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. >> >> 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 ab= ove fails; induced latency will contribute significantly to jitter and henc= e is a good proxy for link-suitability for real-time applications. So I agr= ee using the induced latency as measure to base the color bands from sounds= like a good approach. Yea! Let's do that! [1] http://the-edge.blogspot.com/2003_07_27_the-edge_archive.html#105975402= 040143728 > > >> >> >>> 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' manifes= to. >>>>> >>>>> 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 w= ould say >>>>>> things like >>>>>> >>>>>> 100ms - VoIP applications work well >>>>>> 250ms - VoIP applications - conversation is not as natural as it cou= ld be, >>>>>> although users may not notice this. >>> >>> The only way to detect whether a conversation is natural is if u= sers notice, I would say... >>> >>>>>> 500ms - VoIP applications begin to have awkward pauses in conversati= on. >>>>>> 1000ms - VoIP applications have significant annoying pauses in conve= rsation. >>>>>> 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, takin= g >>>>>> 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 l= inks. >>>>>> >>>>>> 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 k= eep it >>>>>>>> pretty close to this. Certainly under 20-30 ms of added latency. S= o 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 t= hreshold >>>>>>> by their base-latency alone, but guess what telephony via satellite= leaves >>>>>>> something to be desired. That said if the alternative is no telepho= ny I >>>>>>> would take 1 second one-way delay any day ;). >>>>>>> What I liked about fixed thresholds is that the test would g= ive a >>>>>>> good indication what kind of uses are going to work well on the lin= k under >>>>>>> load, given that during load both base and induced latency come int= o play. I >>>>>>> agree that 300ms as first threshold is rather unambiguous though (a= nd I am >>>>>>> certain that remote X11 will require a massively lower RTT unless o= ne likes >>>>>>> to think of remote desktop as an oil tanker simulator ;) ) >>>>>>> >>>>>>>> The other increments I have less opinions about, but 100 ms does s= eem to >>>>>>>> be a nice round number, so do yellow from 30-100 ms, then start wi= th 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 se= cond? >>>>>>>> >>>>>>>> >>>>>>>> I very much think that raising peoples expectations and being quit= e >>>>>>>> ambitious about what to expect is an important part of this. Of co= urse >>>>>>>> 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 b= ad >>>>>>>> results when we see them is reasonable! >>>>>>> >>>>>>> Okay so this would turn into: >>>>>>> >>>>>>> base latency to base latency + 30 ms: gre= en >>>>>>> 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 >>> >> >> >> >> -- >> Dave T=C3=A4ht >> Open Networking needs **Open Source Hardware** >> >> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67