Re: [Bloat] SFQRED or SFQARED?

[Dave Taht <dave.taht@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4900 bytes --]

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 <dave.taht@gmail.com> wrote:

>
>
>
> On Tue, Aug 27, 2013 at 1:44 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi <naeem.khademi@gmail.com>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

[-- Attachment #2: Type: text/html, Size: 7564 bytes --]