From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5E95D21F1AF for ; Tue, 28 Apr 2015 05:24:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 255CCA1; Tue, 28 Apr 2015 14:24:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1430223858; bh=8QOHhiRUCpIai8ztAIJ+7dTkjkCfEmu4VSkBt/XIhes=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bHtUxEqxJieAl0LwDty/iw1v4MaUZjQexJIaFGxzX3b/T7Bwj/9EvCWAKJRVDvKmJ n2bYgiNejbjFoeXg+mgp06d3crrxAPiy0zX2n5ZOW19prVfrgkFSz4TK8nMGxbIidP nAxebg0WzOMVtZXjFH8jb9SDODQAWJ3RU9XxbVh8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1D5A69F; Tue, 28 Apr 2015 14:24:18 +0200 (CEST) Date: Tue, 28 Apr 2015 14:24:18 +0200 (CEST) From: Mikael Abrahamsson To: Sebastian Moeller In-Reply-To: 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-2028509926-1430223858=:16871" 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 12:24:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-2028509926-1430223858=:16871 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 28 Apr 2015, Sebastian Moeller wrote: > From "Table 4.1 Delay Specifications” 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 ;). 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). This usually was a result of multiple PDV (Packet Delay Variation, a.k.a jitter) buffers due media conversions on the voice path, for instance when there was VoIP-TDM-VoIP-ATM-VoIP and potentially even more conversions due to VoIP/PSTN/Mobile interaction. 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. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-2028509926-1430223858=:16871--