From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 1DFDE21F175 for ; Tue, 24 Feb 2015 22:46:39 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E03BBA3; Wed, 25 Feb 2015 07:46:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424846795; bh=cOfAZ2JnwY1vcKlMcrCOoS6n9R9oVQuuPOuEEhvY/Jw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dBiQk7BXRa+ljNGC/jdx5yI1uQs4xirTaLwr6Pmiqnsb+tuo7II3mitzNlNA7Shid +6GPSCqp8mUdIxv1F9PV2G9h+215Dc1m8jMVop/mKwkRiKLFMTPrCRAGklefczdih+ zCacIO1lSHHxHEbug/WctuPNoHtwWkhaSq0yKDXA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D6120A2; Wed, 25 Feb 2015 07:46:35 +0100 (CET) Date: Wed, 25 Feb 2015 07:46:35 +0100 (CET) From: Mikael Abrahamsson To: sahil grover In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW 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:47:08 -0000 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. What we need are mechanisms that work better in real life and that are adaptive. -- Mikael Abrahamsson email: swmike@swm.pp.se