From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 400D621F308 for ; Wed, 25 Feb 2015 00:42:24 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YQXXy-0003E3-5i for bloat@lists.bufferbloat.net; Wed, 25 Feb 2015 09:42:22 +0100 Received: from 66.87.138.144 ([66.87.138.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Feb 2015 09:42:22 +0100 Received: from eternaleye by 66.87.138.144 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Feb 2015 09:42:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bloat@lists.bufferbloat.net From: Alex Elsayed Date: Wed, 25 Feb 2015 00:42:13 -0800 Message-ID: References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 66.87.138.144 User-Agent: KNode/4.14.3 Subject: Re: [Bloat] RED against bufferbloat 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: Wed, 25 Feb 2015 08:42:53 -0000 Bob Briscoe wrote: > Sahil, > > At 06:46 25/02/2015, Mikael Abrahamsson wrote: >>On Tue, 24 Feb 2015, sahil grover wrote: >> >>>(i) First of all,i want to know whether RED was implemented or not? >>>if not then what were the reasons(major) ? >> >>RED has been available on most platforms, but it was generally not >>turned on. It also needs configuration from an operator, and it's >>hard to know how to configure. > > About a decade ago my company (BT) widely deployed RED in the > upstream 'head-end' of our global MPLS network, i.e. the likely > bottleneck in the customer edge router where the customer's LAN > traffic enters their access link. We deployed it as WRED, i.e. > different configurations of RED across the various diffserv classes, > in order to minimise queuing latency in all the classes, including > the lowest priority class. A configuration calculator was developed > to help the engineers during set up. We still use this setup > successfuly today, including for all our particularly latency > sensitive customers in the finance sector. > > We did not deploy RED on our broadband platform (ie public Internet), > altho in retrospect we should have done, because any AQM is much > better than none. We're fixing that now. > >>>(ii)Second, as we all know RED controls the average queue size from >>>growing. >>>So it also controls delay in a way or we can say is a solution to >>>bufferbloat problem. Then why it was not considered. >> >>It was designed to fix "bufferbloat" long before the bufferbloat >>word was even invented. It's just that in practice, it doesn't work >>very well. RED is configured with a drop probability slope at >>certain buffer depths, and that's it. It doesn't react or change >>depending on conditions. You have to guess at configure-time. >> >>What we need are mechanisms that work better in real life and that >>are adaptive. > > If you were prepared to read a paper, I would have suggested: > "The New AQM Kids on the Block: An Experimental Evaluation of CoDel and > PIE" > > This compares CoDel and PIE against Adaptive RED, which was a variant > of RED proposed by Sally Floyd & co-authors in 2001 and available > since Linux kernel version 3.3. ARED addressed the configuration > sensitivity problem of RED by adapting the parameters to link rate > and load conditions. > > The paper convinced me that ARED is good enough (in the paper's > simulations it was often better than PIE or CoDel), at least for > links with fixed rate (or only occasionally varying rate like DSL).* > This is important for us because it means we can consider deploying > AQM by adding soft controls on top of the RED implementations we > already have in existing equipment. This could reduce deployment > completion time from decades to a few months. > > * I'm not sure ARED would be able to cope with the rapidly changing > rate of a wireless link tho. One thing that was brought up on the CoDel list (which Sahil's original question was cross-posted to) by Dave Taht is that much of this testing utterly fails to account for two crucial factors: 1.) Asymmetric paths. When the uplink is considerably smaller than the downlink, he's seen significant behavioral differences - and that's _exactly_ the case of DSL. 2.) Elephants, mice and ants - response of mixed (and latency-sensitive) traffic under load. The RRUL (Realtime Response Under Load) toolkit he created is explicitly designed to test this case... which is a close match to common use cases like watching a Youtube video, but still needing things like DNS to be responsive. Or the bursty traffic of web browsing while a VoIP call is occurring. The former is completely ignored by the presentation you linked to, and the latter is a one-line mention under "future work": "More realistic traffic types (here, only bulk TCP traffic) including bursty traffic" Considering those, that slide deck convinces me of very, very little indeed.