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 for Android: free password hash cracker in your pocket

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

Message-ID: <1322776643.2750.45.camel@edumazet-laptop>
Date:	Thu, 01 Dec 2011 22:57:23 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Dave Taht <dave.taht@...il.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	Thomas Graf <tgraf@...radead.org>,
	netdev <netdev@...r.kernel.org>, Jim Gettys <jg@...edesktop.org>
Subject: Re: [PATCH] sch_red: fix red_change

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



> 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