From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by huchra.bufferbloat.net (Postfix) with ESMTP id 017BD21F31F for ; Tue, 24 Feb 2015 14:39:28 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id CE2361DE070; Tue, 24 Feb 2015 14:39:27 -0800 (PST) Received: from kmnimac.local (c-50-156-111-45.hsd1.ca.comcast.net [50.156.111.45]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id AB6CA1DE060; Tue, 24 Feb 2015 14:39:27 -0800 (PST) Message-ID: <54ECFD9F.4020205@pollere.com> Date: Tue, 24 Feb 2015 14:39:27 -0800 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Tue, 24 Feb 2015 22:39:57 -0000 Good, point. I like to think of the original RED as more 1) noting that all those full buffers weren't doing anyone any good and 2) noting that one could perhaps be aware of creeping congestion and "gently" prevent it. Those two items are still important it's just that making 2) work has more "ahas" in it than was apparent at first blush. I think it is good for us as a community to figure out what doesn't work and what directions we should explore. For example, as has been mentioned, creating better mixes of traffic shows the issues of acks mixed with data real fast. Separate queues fixes those issues very nicely. But we have to be standing on a stepping stone along the path to see this stuff. Kathie On 2/24/15 8:13 AM, Matt Mathis wrote: > RED doesn't work so well, by hindsight it has the wrong estimators and > control functions. However every algorithm on the table today is in > some sense derived from that ground breaking work. > > "Red in a different light" and others are the stepping stones between > then and now. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy > and security as matters of life and death, because for some users, they are. > > On Tue, Feb 24, 2015 at 7:43 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. > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >