Re: [Bloat] RED against bufferbloat

[Alex Elsayed <eternaleye@gmail.com>]

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.