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 94F3121F1AF for ; Tue, 28 Apr 2015 06:44:43 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LejNC-1Z58lF28FC-00qU1o; Tue, 28 Apr 2015 15:44:39 +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 15:44:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:wmFbIamAFwo4Rdzv/mxkM3nrkFbCvAzzJX1B9vEqPLhSGA3p0Ft 0+nUGqo8KNjNfAswOFtnVGrABo79nppZqXnw1e+yklOLsCyYQeGzfnMjH//uHhj8SxIfwhJ JSDMDGRS9qeb2Fai6pDlt4RT3Ha8XwvVfPJU+mi6Hp04SNLHwT6JiJm4XE2ANkRxOaF3NuE j8zuYR3W+T4JP6j87gU9g== 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 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 X-List-Received-Date: Tue, 28 Apr 2015 13:45:16 -0000 Hi Mikael, On Apr 28, 2015, at 14:24 , Mikael Abrahamsson wrote: > On Tue, 28 Apr 2015, Sebastian Moeller wrote: >=20 >> =46rom "Table 4.1 Delay Specifications=94 of that link we = basically have a recapitulation of the ITU-T G.114 source, one-way mouth = to ear latency thresholds for acceptable voip performance. The rest of = the link discusses additional sources of latency and should allow to = come up with a reasonable estimate how much of the latency budget can be = spend on the transit. So in my mind an decent thresholds would be (150ms = mouth-to-ear-delay - sender-processing - receiver-processing) * 2. Then = again I think the discussion turned to relating buffer-bloat inured = latency as jitter source, so the thresholds should be framed in a = jitter-budget, not pure latency ;). >=20 > Yes, it's all about mouth-to-ear and then back again. I have = historically been involved a few times in analyzing end-to-end latency = when customer complaints came in about delay, it seemed that customers = started complaining around 450-550 ms RTT = (mouth-network-ear-mouth-network-ear). Ah, this fits with the ITU figure 1 data, at ~250ms one-way = delay they switch from =93users very satisfied=94 to =93users = satisfied=94, also showing that the ITU had very patient subjects in = their tests=85 So if we need to allow for sampling and de-jittering at = both ends costing say 50ms we end up with a threshold of acceptable = total threshold of ~400ms network RTT for decent voip conversations. = Actually lets assume the sender takes 30ms for sampling and packetizing, = and the recover takes actual jointer ms for its dejittering = filter/buffer, then we can draw the threshold as a function of maximum = latency under load increase... Do you have numbers for acceptable jitter levels? >=20 > This usually was a result of multiple PDV (Packet Delay Variation, = a.k.a jitter) buffers due media conversions on the voice path, This sucks. > for instance when there was VoIP-TDM-VoIP-ATM-VoIP and potentially = even more conversions due to VoIP/PSTN/Mobile interaction. I hope the future will cut this down to at max one transition, = or preferably none ;) (with both PSTN and TDM slowly going the way of = the Dodo). Best Regards Sebastian >=20 > So this is one reason I am interested in the bufferbloat movement, = because with less bufferbloat then one can get away with smaller PDV = buffers, which means less end-to-end delay for realtime applications. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se