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 1ABC521F308 for ; Wed, 25 Feb 2015 00:29:53 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YQXLm-0004kl-6x for bloat@lists.bufferbloat.net; Wed, 25 Feb 2015 09:29:46 +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:29:46 +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:29:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bloat@lists.bufferbloat.net From: Alex Elsayed Date: Wed, 25 Feb 2015 00:29:36 -0800 Message-ID: References: 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:30:22 -0000 David Lang wrote: > 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. I suspect you're conflating RED with delay-based congestion-control algorithms such as Vegas.