netdev - Re: [PATCH] sch_red: fix red

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ED7F9DF.8020903@freedesktop.org>
Date:	Thu, 01 Dec 2011 17:04:15 -0500
From:	Jim Gettys <jg@...edesktop.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Dave Taht <dave.taht@...il.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	Thomas Graf <tgraf@...radead.org>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] sch_red: fix red_change

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@...il.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.
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html