From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E3CEB21F0A2 for ; Tue, 3 Sep 2013 11:31:07 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id qa5so9289740ieb.32 for ; Tue, 03 Sep 2013 11:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4JlME7ogRGt/OYcnPVMs+ARGsDuei5FnW3kYF0u6SHs=; b=yPmcs0Ppol3F0KkeI7tKLb7uF6Yor+nkH7dvv7MJsL6oV406BnaOtoI61d4LAogLhM jvI+bV+/FC1/220vx3r3ZaO9weZXhB3HkX/o4ysVUXJccyhVVCuoHAUMqKKtet8gwwpP vbw1si4SqeqLjtL1acmgIfQDQEc3ji61BQ2sdq71VisrfsZSlZ/iaETErTIwBDpjhDyn 88AYOtc37NAdbcAwXxiIFK2m1oPMaBCGRwDmWbBcnhP6OWTPpJvviDv2iJgz/zwcTtws GXv9h6e28mWHH75RVJ0tI7VNv+WCgai+OoPFxa2YOrEmY5c/6AXWh4yJpiZ8y3aoRCKb oQRA== MIME-Version: 1.0 X-Received: by 10.50.20.99 with SMTP id m3mr16851074ige.54.1378233067091; Tue, 03 Sep 2013 11:31:07 -0700 (PDT) Received: by 10.64.231.35 with HTTP; Tue, 3 Sep 2013 11:31:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Sep 2013 11:31:06 -0700 Message-ID: From: Dave Taht To: Naeem Khademi Content-Type: multipart/alternative; boundary=047d7bd6b2b46252f104e57ee460 Cc: Eric Dumazet , bloat Subject: Re: [Bloat] SFQRED or SFQARED? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 18:31:08 -0000 --047d7bd6b2b46252f104e57ee460 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=3Dlinux-netdev&m=3D137781660312650&w=3D2 (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 (=93ARED=94) from Sally Floy= d >>> 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 mad= e >> 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 bee= n > 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 wa= s > 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/+/8af2a218de38f51ea4b4fa4= 8cac1273319ae260c >> >> and some ip route version later corrected "adaptive" to be the >> user-facing syntax. I just ran a quick, dirty and (nonsensical*) rrul te= st >> with this: >> >> tc qdisc add dev eth0 root red limit 40000 min 30000 max 90000 avpkt 100= 0 >> 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=E4ht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --047d7bd6b2b46252f104e57ee460 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
And while I look over this very old, first presentati= on at stanford that tried to describe codel and fq_codel, I see multiple pl= aces that we have since improved.

1) I have fallen back t= o saying that instead of TCP-friendly, codel is "RTT-friendly". T= here's not a good definition of this latter phrase. Matt Mathis suggest= s I use "window friendly" instead, but I try to think of "RT= T-friendly" as "waiting long enough for a congestion signal to re= ach 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 in= verse 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_code= l" in ns2. I've long encouraged QFQ's author to try the same t= hing (and qfq + codel can be easily played with using the debloat script, b= ut you rapidly run out of memory on teeny routers). There is hfsc + codel i= n freebsd now (as well as their fairq variant that I don't know anythin= g 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 w= ere using sfq and/or red before. I frankly do not understand hfsc well enou= gh to say if this is a good idea.

4) And the ever prolific edumazet's pure (non-stochastic) fq just a= ppeared in net-next with some very interesting and useful properties as to = informing the queue about the host tcp behaviors...

http://marc.info/?l=3Dlinux-netdev&m=3D137781660312650&w= =3D2

(but no codel)

Lots of fun stuff going on!

<= div class=3D"gmail_extra">
On Tue, Aug 27, 2013 a= t 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 (=93ARED=94) from Sally Flo= yd
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_Cod= el_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 t= hat talk as a steppingstone in hybrid fq+aqm history. (prior to that we wer= e 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/bloa= t/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_ADAPTATIV= E value into the flags on the red setup in sch_sfq.c

Eric added ARED support to sch_red in kernel commit: 8af2a218de38f51ea4b4fa= 48cac1273319ae260c

http= s://android.googlesource.com/kernel/exynos/+/8af2a218de38f51ea4b4fa48cac127= 3319ae260c

and some ip route version later corrected "adaptive" to be th= e user-facing syntax. I just ran a quick, dirty and (nonsensical*) rrul tes= t with this:

tc qdisc add dev eth0 root red limit 40000 min 30000 ma= x 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
=A0Sent 858913226 bytes 823269 pkt = (dropped 4866, overlimits 123 requeues 0)
=A0backlog 0b 0p requeues 0 <= br> =A0 marked 0 early 123 pdrop 4743 other 0

which "jus= t 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 ARE= D to what little extent I understood it in the first place
--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.tek= libre.com/cerowrt/subscribe.html=20



--
Dave T=E4ht<= br>
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/s= ubscribe.html=20



--
Dave T=E4ht

Fixi= ng bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.ht= ml=20
--047d7bd6b2b46252f104e57ee460--