And while I look over this very old, first presentation at stanford that tried to describe codel and fq_codel, I see multiple places that we have since improved. 1) I have fallen back to saying that instead of TCP-friendly, codel is "RTT-friendly". There's not a good definition of this latter phrase. Matt Mathis suggests I use "window friendly" instead, but I try to think of "RTT-friendly" as "waiting long enough for a congestion signal to reach the other side" and entirely outside of a tcp context... could use a harder definition.... 2) My waving hands talking about 1/(sqrt(count) being the inverse of tcp's increases has since been dropped. I still wish we had a better graphic explaining what really goes on than I have in that preso, it requires a lot of talking still to explain it.... 3) we have sfq and drr based versions of "fq_codel" in ns2. I've long encouraged QFQ's author to try the same thing (and qfq + codel can be easily played with using the debloat script, but you rapidly run out of memory on teeny routers). There is hfsc + codel in freebsd now (as well as their fairq variant that I don't know anything about.) I have a couple variants of codel and fq_codel in patch form and in cerowrt... as well as a pie still in progress... Shapers are using (htb or hfsc) + fq_codel... in shapers where people were using sfq and/or red before. I frankly do not understand hfsc well enough to say if this is a good idea. 4) And the ever prolific edumazet's pure (non-stochastic) fq just appeared in net-next with some very interesting and useful properties as to informing the queue about the host tcp behaviors... http://marc.info/?l=linux-netdev&m=137781660312650&w=2 (but no codel) Lots of fun stuff going on! On Tue, Aug 27, 2013 at 1:58 PM, Dave Taht wrote: > > > > On Tue, Aug 27, 2013 at 1:44 PM, Dave Taht wrote: > >> >> >> >> On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi wrote: >> >>> Hi >>> >>> Slide 37 of below link mentions that SFQRED implemented in Linux 3.4 >>> upwards, "Utilized a better version of RED (“ARED”) from Sally Floyd >>> in 2002". However I'm unable to find the "adaptive" bit of SFQRED in >>> the kernel and iproute code. Can anyone (Dave or Eric) confirm that >>> the mentioned statement is correct? >>> >>> http://netseminar.stanford.edu/seminars/Inside_Codel_and_Fq_Codel.pdf >>> >>> >> I think you are correct in that the adaptive RED code never formally made >> it into SFQRED. SFQRED was a brief blip in time before codel showed up... >> I'd talked about it in that talk as a steppingstone in hybrid fq+aqm >> history. (prior to that we were working with qfq + red as entirely >> separate, modular qdiscs). So... oops. >> > > While I'm correcting slides and trying to keep history straight, after > that talk it was pointed out that head drop from the biggest flow had been > proposed as early as 1999, and possibly as early as the mid-late 1980s... > > https://lists.bufferbloat.net/pipermail/bloat/2013-February/001345.html > > I enjoyed the literature search around that thread a lot. What was new was > old again. > > >> I think the work was interesting and valuable, and if you want to play >> with the ARED variant probably all you have to do is OR in the >> TC_ADAPTATIVE value into the flags on the red setup in sch_sfq.c >> >> Eric added ARED support to sch_red in kernel commit: >> 8af2a218de38f51ea4b4fa48cac1273319ae260c >> >> >> https://android.googlesource.com/kernel/exynos/+/8af2a218de38f51ea4b4fa48cac1273319ae260c >> >> and some ip route version later corrected "adaptive" to be the >> user-facing syntax. I just ran a quick, dirty and (nonsensical*) rrul test >> with this: >> >> tc qdisc add dev eth0 root red limit 40000 min 30000 max 90000 avpkt 1000 >> burst 55 ecn adaptive bandwidth 10Mbit >> >> tc -s qdisc show dev eth0 >> qdisc red 8005: root refcnt 2 limit 40000b min 30000b max 90000b ecn >> adaptive >> Sent 858913226 bytes 823269 pkt (dropped 4866, overlimits 123 requeues >> 0) >> backlog 0b 0p requeues 0 >> marked 0 early 123 pdrop 4743 other 0 >> >> which "just worked" with ubuntu 13.4. >> >> The ARED option could be enabled with GRED/SFQRED with adding the right >> knob to iproute2. >> >> >> Regards, >>> Naeem >>> >> >> >> * I have thankfully managed to completely forget how to configure RED or >> ARED to what little extent I understood it in the first place >> -- >> Dave Täht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html