From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id DA9CC201A98 for ; Sat, 1 Dec 2012 13:47:56 -0800 (PST) Received: from 199-83-222-22.public.monkeybrains.net ([199.83.222.22] helo=[192.168.1.112]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TeuuY-0003Df-M4; Sat, 01 Dec 2012 21:47:47 +0000 Message-ID: <50BA7AFE.7060102@superduper.net> Date: Sat, 01 Dec 2012 13:47:42 -0800 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Richardson References: <15815375-7E44-42DE-AE49-6630A053B88B@netflix.com> <1306.1354395193@obiwan.sandelman.ca> In-Reply-To: <1306.1354395193@obiwan.sandelman.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) Cc: "" , "" , Dauran raza Subject: Re: [Bloat] Bufferbloat research: Help required 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: Sat, 01 Dec 2012 21:47:58 -0000 Voice over data can actually work very well in 3G networks (better than dedicated voice even), but it requires prioritisation. There is a bunch of work going on to enable this in existing networks to support the new services that VoLTE will enable, over older networks (Joyn). This is a *huge* transition in carrier networks, and will take some time to arrive. Even today only 1 US carrier uses VoLTE, all the others switch to 3G to make or receive a phone call. Simon On Sat 01 Dec 2012 12:53:13 PM PST, Michael Richardson wrote: > >>>>>> "Mark" == Mark Watson writes: > Mark> It's also interesting to note that cellular wireless [DATA] systems > Mark> have been designed with a primary objective of reducing packet > Mark> loss, at the expense of delay and especially delay variability > Mark> introduced by link layer ARQ and other schemes. This approach > Mark> maximizes the throughput of a single long-lived TCP > Mark> connection, which is not an especially common traffic > Mark> pattern. > > A question, given that I inserted [DATA]. > > I wonder to what extent the pre-LTE systems were designed this way in > part to make sure that voice over data would always be crappy? > > The LTE roadmap says that voice is now over data, so it's now in the > carrier's interest to do things differently. > > Mark> Furthermore, the throughput of a cellular wireless radio > Mark> channel varies by orders of magnitude on fairly rapidly > Mark> (channel conditions are reassessed hundreds of times per > Mark> second): what was a reasonable sized buffer for the throughput > Mark> at one moment becomes a bloated one a fraction of a second > Mark> later. > > Does ECN help us here? >