From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by huchra.bufferbloat.net (Postfix) with ESMTP id 1FCC821F2AA for ; Tue, 24 Feb 2015 08:27:25 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t1OGRMC3031699 for ; Tue, 24 Feb 2015 11:27:23 -0500 Received: (qmail 27215 invoked by uid 0); 24 Feb 2015 16:27:22 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.2?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 24 Feb 2015 16:27:22 -0000 Message-ID: <54ECA667.8050807@mti-systems.com> Date: Tue, 24 Feb 2015 11:27:19 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sahil grover , codel@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat. X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:27:54 -0000 On 2/24/2015 10:37 AM, 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) ? > anyone please tell me in simple words here only,because i don't want to > read any paper like "RED in a different light". > > (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. > There is an IETF document from the AQM working group which contains some discussion towards your first question, at least: https://tools.ietf.org/html/draft-ietf-aqm-recommendation-10 (this should be published as an RFC "soon") Specifically, the text says: With an appropriate set of parameters, RED is an effective algorithm. However, dynamically predicting this set of parameters was found to be difficult. As a result, RED has not been enabled by default, and its present use in the Internet is limited. Other AQM algorithms have been developed since RC2309 was published, some of which are self-tuning within a range of applicability. Hence, while this memo continues to recommend the deployment of AQM, it no longer recommends that RED or any other specific algorithm is used as a default; instead it provides recommendations on how to select appropriate algorithms and that a recommended algorithm is able to automate any required tuning for common deployment scenarios. -- Wes Eddy MTI Systems