From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 893483B2A4 for ; Thu, 6 Apr 2017 07:34:12 -0400 (EDT) Received: by mail-wr0-x22d.google.com with SMTP id w11so53526811wrc.3 for ; Thu, 06 Apr 2017 04:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=TTN+Sa8R4LMFREqlEXogjt0hKAJyi0KQ8J4aU5rrxaE=; b=g6wvXPuj1aTNTPPcqeA5u20GGlxA56vSiyNi/QETWX3ThZGlj40ceM9dXmL8R/m/jp XpERZNCIAegfkPvMkIE7qP0BlqAwDZvPXF2t7kD9J0D87gcXBV6zL4w1CYuzu0hRhYcD CzaahNX2rLgx1OXOvKi/UM0xfDxBwh1yePdaF1moj3JMXm0H7fpmGzI5aZDQwAL9Tkkf 3pel8BoIrODyEhiyA6oKdobTB0Vams8b7JU4K+GtRDXAp/zXboZxg2acPFjqQJYkUagI bD7aszgvHEEym4BcqpoE43UDfJYmwOiSx+mHKPdjKeWbONFEiG7HAMv5o4KpiCNA3Iy+ MxYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TTN+Sa8R4LMFREqlEXogjt0hKAJyi0KQ8J4aU5rrxaE=; b=T8fTwKYTMuahD7AfgPVhpihVoJ8DaF7OGUswR5mZTFcoG34RQEFSEvl5Kq+BTmFttw ku2rVnxj2JO80W3XXbxUMSnobAdShcNRbBs9pYeJilvlxpIozuLljJm+h0NuZR9MaLjr 6vJVhH5UNYbeDEH9OOd0UIKAAutPMV9Nfe2WhVMirDRY8iOGQJJE9WUgZs804zAl2ttb oPzjzDRzfpT7ETqDChCjtUXbjbAZiIBZXJKz4L/MtGArje4nZTha2kOhD1HVGPZj49Jl 7bHXEbseACLpYaUzIWzQRgYE5G8++h5mSJ074sqkJfKH5SwnBwq18/Q9H1fTutHAy6Fz jZZw== X-Gm-Message-State: AFeK/H3vDSeOY3E9sdHhhGd+LQ/GGszCggDVbXLkBHOzvWvSNgOJd+nJ5o2QEBWoBwhsjQ== X-Received: by 10.223.144.8 with SMTP id h8mr27689828wrh.45.1491478450803; Thu, 06 Apr 2017 04:34:10 -0700 (PDT) Received: from [10.72.0.130] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id t21sm26024022wmd.19.2017.04.06.04.34.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Apr 2017 04:34:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_09C8F764-FBA0-4843-B007-B5CA7232CB99" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <87r315u7xe.fsf@alrua-kau> Date: Thu, 6 Apr 2017 13:34:08 +0200 Cc: cake@lists.bufferbloat.net Message-Id: References: <2FD59D30-3102-4A3E-A38E-050E438DABF0@gmail.com> <87ziftubgy.fsf@alrua-kau> <8E96329F-A57D-49C7-A7EE-60BD165B4D5C@gmail.com> <87r315u7xe.fsf@alrua-kau> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] flow isolation for ISPs X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 11:34:12 -0000 --Apple-Mail=_09C8F764-FBA0-4843-B007-B5CA7232CB99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 6, 2017, at 12:50 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Pete Heist > writes: >=20 >> The fq_codel qdisc does have support for arbitrary tc filters to = replace >> the default hashing, BTW. If you don't need the cake shaper, that = might >> be a solution? >>=20 >> I see, I found mention of it in Chapter 6 of a draft RFC that it = looks >> like you wrote, actually >> (https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06#section-6). = :) >> To try it out, am I heading the right direction by looking at tc >> filter=E2=80=99s skbedit action, or is that just for MQ devices? >> (http://man7.org/linux/man-pages/man8/tc-skbedit.8.html) >>=20 >> I also saw this mention of =E2=80=9CWe are not aware of any = deployments >> utilising the custom classification feature" >> https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-02#section-5.1.1, >> so not sure how often this has been tried. :) >=20 > Yeah, haven't actually heard of anyone using the feature in = production. > It's basically this section from the 'classful qdiscs' section of 'man > tc': >=20 > When a packet enters a classful qdisc it can be classified to = one of the classes within. Three criteria are available, although not = all qdiscs will use all three: >=20 > tc filters > If tc filters are attached to a class, they are consulted = first for relevant instructions. Filters can match on all fields of a = packet header, as well as on the firewall mark applied by ipchains or = iptables. >=20 > So you can basically use the full capabilities of tc-filter in place = of > the built-in hashing of fq_codel. The tc-u32 man page has some = examples, > which is probably a good starting point. >=20 > If you do try this out and feel like writing up a small > example/tutorial, I'm happy to add a link (or the whole thing) = somewhere > on bufferbloat.net :) Sure, if I get it working I=E2=80=99ll include an example in my paper, = but I=E2=80=99m still a little confused. Is fq_codel actually a classful = qdisc? I get the part about matching with tc-filter and the u32 selector (as = intuitive as that is :), but am not sure of the action the filter needs = to take. However, I do see the example towards the bottom of the tc-u32 = man page where a hash table is created and filters move packets into the = right buckets. Perhaps it will be eventually decipherable from this=E2=80=A6= :)= --Apple-Mail=_09C8F764-FBA0-4843-B007-B5CA7232CB99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 6, 2017, at 12:50 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:

Pete Heist <peteheist@gmail.com> writes:

The fq_codel qdisc does have support for arbitrary tc = filters to replace
the default hashing, BTW. If you don't = need the cake shaper, that might
be a solution?

I see, I found mention of it in Chapter 6 of a = draft RFC that it looks
like you wrote, actually
(https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06#section-= 6). :)
To try it out, am I heading the right direction = by looking at tc
filter=E2=80=99s skbedit action, or is = that just for MQ devices?
(http://man7.org/linux/man-pages/man8/tc-skbedit.8.html)

I also saw this mention of =E2=80=9CWe are not = aware of any deployments
utilising the custom = classification feature"
https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-02#section-= 5.1.1,
so not sure how often this has been tried. = :)

Yeah, haven't actually heard of anyone = using the feature in production.
It's basically this section from the = 'classful qdiscs' section of 'man
tc':

      When a = packet enters a classful qdisc it can be classified to one of the = classes within. Three criteria are available, although not all qdiscs = will use all three:

      tc = filters
          &nb= sp;  If tc filters are attached to a class, they are consulted = first for relevant instructions. Filters can match on all fields of a = packet header, as well as on the firewall mark applied by ipchains or = iptables.

So you can = basically use the full capabilities of tc-filter in place of
the built-in = hashing of fq_codel. The tc-u32 man page has some examples,
which is probably a = good starting point.

If you do try this out and feel like writing up = a small
example/tutorial, I'm happy to add a link (or = the whole thing) somewhere
on bufferbloat.net :)

Sure, if I get it working I=E2=80=99ll = include an example in my paper, but I=E2=80=99m still a little confused. = Is fq_codel actually a classful qdisc?

I get the part about matching with = tc-filter and the u32 selector (as intuitive as that is :), but am not = sure of the action the filter needs to take. However, I do see the = example towards the bottom of the tc-u32 man page where a hash table is = created and filters move packets into the right buckets. Perhaps it will = be eventually decipherable from this=E2=80=A6 :)
= --Apple-Mail=_09C8F764-FBA0-4843-B007-B5CA7232CB99--