Re: [Bloat] RED against bufferbloat

[David Lang <david@lang.hm>]

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