Re: [Bloat] RED against bufferbloat

[Mikael Abrahamsson <swmike@swm.pp.se>]

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