From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C995621F2A2 for ; Tue, 24 Feb 2015 22:54:15 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t1P6sCGS026950; Tue, 24 Feb 2015 22:54:12 -0800 Date: Tue, 24 Feb 2015 22:54:12 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Mikael Abrahamsson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 06:54:44 -0000 On Wed, 25 Feb 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. > >> anyone please tell me in simple words here only,because i don't want to >> read any paper like "RED in a different light". > > These issues are not simple. There are several presentations/talks available > on Youtube on the issues if you want it in presentation form. Search for > "Dave Taht", "Jim Gettys", "bufferbloat" and other such topics and you'll > find excellent presentations from different forums. > >> (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. more importantly (as I understand it), if you use RED while the rest of the users on the network stick with stock systems, you will keep yielding to them and only get to use a fraction of the available bandwidth. David Lang