From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 2E1B021F2B5 for ; Wed, 6 May 2015 23:19:58 -0700 (PDT) Received: from u-089-csam313b.am5.uni-tuebingen.de ([134.2.89.14]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MPlY2-1Yu72z2BrW-004z5z; Thu, 07 May 2015 08:19:51 +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: Thu, 7 May 2015 08:19:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E1DA017-9E4A-4CB0-8207-00B62B36496A@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: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:PUKThes/TriASQj39NL66K5T18vYuroLiJ2EerxtDTAUWlOsCBh K0IQOENsZZvQCfyU0ycJdrsTpuFKwaWc2hjWuugg+ra4GSdtB8WgiA/SqH7D1HeqgVkUOW4 6tEd36NwKyUM0yhAAYOsMBSIkV6nsxeua82OMQFFJZvWNj0Qwjxo9fIg87EuShfffsoN+vD QxTMohlVpp2JeBL9XO1tA== 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: Thu, 07 May 2015 06:20:27 -0000 Hi Jonathan, On May 6, 2015, at 22:25 , Jonathan Morton = wrote: > So, as a proposed methodology, how does this sound: >=20 > Determine a reasonable ballpark figure for typical codec and = jitter-buffer delay (one way). Fix this as a constant value for the = benchmark. But we can do better, assuming captive de-jitter buffers (and = they better are), we can take the induced latency per direction as first = approximation of the required de-jitter buffer size. >=20 > Measure the baseline network delays (round trip) to various reference = points worldwide. >=20 > Measure the maximum induced delays in each direction. >=20 > For each reference point, sum two sets of constant delays, the = baseline network delay, and both directions' induced delays. I think we should not count the de-jitter buffer and the = actually PDV twice, as far as I understand the principle of the = de-jittering is to introduce a buffer deep enough to smooth out the real = variable packet latency, so at best we should count max(induced latency = per direction, de-jitter buffer depth per direction), so the induced = latency (or a suitable high percentile if we aim for good enough instead = of perfect) is the best estimator we have for the jitter-induced delay. = But this is not my line of work so I could b out to lunch here... >=20 > Compare these totals to twice the ITU benchmark figures, rate = accordingly, and plot on a map. I like the map idea (and I think I have seen something like this = recently, I think visualizing propagation speed in fiber). Now any map = just based on actual distance on the earth=92s surface is going to give = a lower bound, but that should still be a decent estimate (unless = something nefarious like = http://research.dyn.com/2013/11/mitm-internet-hijacking/ is going on = then all bets are off ;) ) Best Regards Sebastian >=20 > - Jonathan Morton