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 9E10C21F3B4 for ; Fri, 24 Apr 2015 01:55:24 -0700 (PDT) Received: from u-089-d066.biologie.uni-tuebingen.de ([134.2.89.66]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lt2BW-1ZR4Fn3VMo-012aIU; Fri, 24 Apr 2015 10:55:13 +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: <87wq123p5r.fsf@toke.dk> Date: Fri, 24 Apr 2015 10:55:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2288B614-B415-4017-A842-76E8F5DFDE4C@gmx.de> References: <2C987A4B-7459-43C1-A49C-72F600776B00@gmail.com> <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <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> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:pUPOBl0OcmXP1teFggPoXbra8IvF3GFzpAXefgJaGcVbiTOFTtE NEfMYPgYxHCn4exj7l+HWW3mP+/zx4yzfRVBoK5givOVpu2C00+Fu96SJCgW1AI1OkXyRhA 1sHh4UHvg2y6qWyPMITHzKEVrdYvTFiqK9/NSCyPtsCetBQN7CtUAD8v/Lpq9l9tNGEff7b l1NF1ymnByIPYhjcwIPrw== 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: Fri, 24 Apr 2015 08:55:54 -0000 Hi Toke, On Apr 24, 2015, at 10:29 , Toke H=F8iland-J=F8rgensen = wrote: > 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. 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 = ;).=20 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: 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? >=20 > -Toke