On Thu, 1 Dec 2011, Eric Dumazet wrote:

Le jeudi 01 décembre 2011 à 22:35 +0100, Dave Taht a écrit :

quoted

On Thu, Dec 1, 2011 at 10:06 PM, Eric Dumazet [off-list ref] wrote:

quoted

Le mercredi 30 novembre 2011 à 14:36 -0800, Stephen Hemminger a écrit :

quoted

(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 :)

I think at least one bug he claims to find in "the" manuscript is not a 
bug at all :-). Essentially he assumes that once instantaneous queue is 
zero, the load is zero, which is not true (e.g., during any typical slow 
start while the link is still not saturated).

quoted

RED is useful for high throughput routers, I doubt many linux machines

quoted

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

I disagree. Slowly responding adaptation is not going to do much good if 
put together with variable something.

And besides, Adaptive RED is as hard if not even harder to configure than 
the standard RED. That is, it has one key parameter and absolutely no info 
is given how that should be configured?!? :-)

quoted

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.

To be more exact, it's BDP (BW-delay product) which matters, not the RTT 
alone.

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.

I disagree. If there's any slow starting flow that alone can fill the 
bottleneck, anything significantly larger than RTT just harms. RED is 
just "too slow" if you follow the recommended parametrization..

In a core router you can probably get away with multiple RTTs, but near 
edge that is a grave mistake due to how slow-start behaves. With average 
based on many RTTs, RED still estimates that the link has low load while 
congestion has escalated to higher dimensions due to slow start. As a 
result, RED graciously falls back to tail-drop once the physical queue 
runs out and the flows respond allowing the load to decrease. However, 
finally RED reaches a state where it starts to "pro-actively" react to an 
"incipient congestion"?!? :-/ => Problem is made worse by those extra 
drops/marks happening too late.

...And the obvious looking solution by making physical buffer size 
larger brings in even worse problems. There's simply no other way around 
this than making wq larger instead of smaller in order to arrest the slow 
start in time. (We have a paper to appear about these in AINA 2012.)

I know this is pretty much against the mantra repeated about RED. And I'm 
not too surprised why so many have found out that RED does not help.

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.

Here I agree, 0.5 is probably too much though... only if BDP is very small 
this is useful but then RED is probably having other problems due to 
granularities affecting its measurement accuracy.


-- 
 i.