Re: [PATCH] sch_red: fix red_change

[Jim Gettys <jg@freedesktop.org>]

On 12/01/2011 04:57 PM, Eric Dumazet wrote:
> Le jeudi 01 décembre 2011 à 22:35 +0100, Dave Taht a écrit :
>> On Thu, Dec 1, 2011 at 10:06 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> Le mercredi 30 novembre 2011 à 14:36 -0800, Stephen Hemminger a écrit :
>>>
>>>> (Almost) nobody uses RED because they can't figure it out.
>>>> According to Wikipedia, VJ says that:
>>>>  "there are not one, but two bugs in classic RED."
>> Heh. "There were not two, but four bugs in Linux red".
>>
>> Now reduced to 2. :)
>>
> This story about VJ and bugs in classic RED is urban legend if you ask
> me :)
>

Well, I've heard this directly from Van, first hand.  So you are now
second hand.

 And you can see much of what's wrong by tracking down "RED in a
different light", which he tried to get published to get people aware of it.
                - Jim

>
>> RED is useful for high throughput routers, I doubt many linux machines
>>> act as such devices.
>> "High throughput" at the time red was designed was not much faster
>> than a T1 line.
>>
>> RED appears to be used by default in both gargoyle's and openwrt's QoS systems,
>> underneath unholy combinations of HTB, HSFC, and SFQ
>> so it's more widely used than you might think. Not that works well.
>>
>> RED doesn't work worth beans on variable bandwidth links (cable
>> modems/wireless).
>>
> Adaptative RED is the answer
>
>> Once you are simulating a fixed rate link (e.g with HTB), then it sort of
>> kinda maybe can apply.
>>
>> RED was also designed at a time when long distance traffic was fixed rate
>> and bidirectional, so the 'average packet' parameter made sense.
>> Modern day traffic is far more asymmetric.
>>
> The truth is : For RED be effective (with say 20 to 100 flows), you need
> a reasonable amount of packets in queue, and low wq (high burst value in
> linux), depending on the RTT. And on consumer links (ADSL, cable
> modem ...), RTT is quite big.
>
> RED performance is best when the average queue size is estimated over a
> small _multiple_ of round-trip times, not over a fraction of a single
> round-trip time.
>
> In this respect, your RED setups are pathological (minimum burst value,
> meaning wq = 0.5 or so), so in a small fraction of RTT, avgqsz value is
> completely changed, so flows have no chance to be able to react
> smoothly.
>
>
>