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 8944521F0AF for ; Fri, 30 Nov 2012 13:17:35 -0800 (PST) Received: from snappy-wlan.parc.xerox.com ([13.1.108.21]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TeXxi-0008Mr-LN; Fri, 30 Nov 2012 21:17:31 +0000 Message-ID: <50B92267.9040806@superduper.net> Date: Fri, 30 Nov 2012 13:17:27 -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: Mark Watson References: <15815375-7E44-42DE-AE49-6630A053B88B@netflix.com> In-Reply-To: <15815375-7E44-42DE-AE49-6630A053B88B@netflix.com> 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: Fri, 30 Nov 2012 21:17:35 -0000 Both cellular and wireless lan suffer from the same problem - in some situations a packet loss rate of 30% can be optimal operation for best throughput before stepping down a rate at the physical layer. Obviously TCP was not designed to handle this level of loss, so a 'wire like' emulation layer is used, with retries. Unfortunately the number of retries is fixed, and non optimal, causing problems. Simon On Fri 30 Nov 2012 10:56:59 AM PST, Mark Watson wrote: > It's also interesting to note that cellular wireless systems have been designed with a primary objective of reducing packet loss, at the expense of delay and especially delay variability introduced by link layer ARQ and other schemes. This approach maximizes the throughput of a single long-lived TCP connection, which is not an especially common traffic pattern. > > Furthermore, the throughput of a cellular wireless radio channel varies by orders of magnitude on fairly rapidly (channel conditions are reassessed hundreds of times per second): what was a reasonable sized buffer for the throughput at one moment becomes a bloated one a fraction of a second later. > > Best, > > Mark Watson > > > On Nov 28, 2012, at 8:39 AM, Dave Hart wrote: > >> On Sun, Nov 25, 2012 at 3:21 PM, Dauran raza wrote: >>> My name is Dauran Raza and i am currently doing Masters in Computer Science >>> from University Paderborn. Currently i am researching on the Problem of >>> Bufferbloat for a course under Prof Holger Karl. I have been regularly >>> reading you articles on your websites about this problem and it has been >>> really helpfull. I have a problem which is not answered so far through any >>> research paper. I wanted to know is there any difference in Wired and >>> Wireless networks caused by this problem and can you guide me with any good >>> paper or article to read on. >> >> I wish you well in your graduate studies, and I commend Prof. Holger >> Karl for his interest in the topic. I am, however, cautious that I >> don't want to do your research for you. >> >> Briefly, as you would hopefully anticipate, wireless presents more >> challenges to addressing bufferbloat than wired. For example, the >> jitter (delay variability) is much worse than wired, and 802.11n >> requires aggregation of multiple packets into one transmission to >> achieve its higher throughputs vs. 802.11g, which further increases >> jitter and complicates AQM. >> >> Even ignoring wireless, gigabit wired is more challenging than 100 >> Mbit, again because techniques used to maximize peak throughput (such >> as deeper transmit buffers and receive interrupt coalescing) tend to >> make bufferbloat more of a challenge. >> >> There's a theme here -- those developing network advancements have >> tended to focus on maximizing achievable throughput without enough >> consideration of the negative effects on bufferbloat, often (at least >> historically) with no understanding of bufferbloat at all. >> >> I pray I have not said too much already, and if I have, please convey >> my apologies to Prof. Karl. >> >> I suggest digging into the mailing list archives: >> >> https://lists.bufferbloat.net/listinfo >> >> I'd start with the bloat and bloat-devel lists, then the Codel-related >> lists, and possibly other -devel and -commit lists. Also, if you make >> yourself useful in one or more bufferbloat.net projects, you will gain >> firsthand knowledge of the issues as well as personal relationships >> with people well-versed in the issues. >> >> Thanks for your interest, >> Dave Hart >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat