From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "hubrelay-rd.bt.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2D45921F297 for ; Wed, 25 Feb 2015 00:06:58 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 25 Feb 2015 08:06:54 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 25 Feb 2015 08:06:53 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 25 Feb 2015 08:06:53 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.96.103]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id t1P86o5N011632; Wed, 25 Feb 2015 08:06:51 GMT Message-ID: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 25 Feb 2015 08:06:50 +0000 To: sahil grover From: Bob Briscoe In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: bloat@lists.bufferbloat.net 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:07:27 -0000 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. HTH Bob ________________________________________________________________ Bob Briscoe, BT