From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 179AB3B2A4 for ; Thu, 6 Apr 2017 06:50:08 -0400 (EDT) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id C278CB3729; Thu, 6 Apr 2017 12:50:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1491475807; bh=iZ5W4p8w7iSireCWDVpsD44w+5L+gcw2daMBhBeWIVY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=awaU4u7ks1Wq/+Obn83OVpHdANUNrbP/xSF9HlXdBfmjy7bkqvy9D8FUROB9FbgPk MOcQz4CswvKValgb3o7AadmdCX2YluE1A8j0lehclJibySSvUAEgTLwTo9keekd5nZ EUcMUmfz0aQSaIXgd+634zPomkXnLi+rkECZhSTV8cejZSMQVNF4RQhJ1dC9eiavbM GzqcDJ1m5wsd/Kr2nSqJ4ikAuUEZOf57ZtFxo1iDHvfUF0svkVX0ZPVXV0fT2ln6od 4v6hjl7Vi1KEpasp/W73ECSzAa0VA22m9BM5HjpqGmxYNdoAqRtN26D8kd0BVQNZbi 16k1sQ077kiIw== Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 32F45C40276; Thu, 6 Apr 2017 12:50:05 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Pete Heist Cc: cake@lists.bufferbloat.net References: <2FD59D30-3102-4A3E-A38E-050E438DABF0@gmail.com> <87ziftubgy.fsf@alrua-kau> <8E96329F-A57D-49C7-A7EE-60BD165B4D5C@gmail.com> Date: Thu, 06 Apr 2017 12:50:05 +0200 In-Reply-To: <8E96329F-A57D-49C7-A7EE-60BD165B4D5C@gmail.com> (Pete Heist's message of "Thu, 6 Apr 2017 12:26:59 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r315u7xe.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 10:50:09 -0000 Pete Heist writes: > On Apr 6, 2017, at 11:33 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Once upon a time I implemented something like this; it was basically a > PHP script that would generate an HTB bucket (with sfq as leaf qdisc; > this was pre-fq_codel) per subscriber ID and use tc filter to map the > list of IPs registered to that customer into the right bucket. The HTB > shaper was used to enforce the bandwidth each customer was paying for. > > Did it work? Yup, mostly. Was it ugly? Oh boy, yes! > > Oh my, ok, so it is possible. It can take a while to apply many qdiscs > and filters on lower end devices, so I picture some delay while > modifying the list or restarting the routers, but I=E2=80=99m just explor= ing > options now, so it is one. What I did was 10 years ago on what was fairly high-end x86 hardware at the time; scaling to 10s (or maybe low 100s) of users. So depending on the scale, it's probably doable on somewhat cheaper hardware now. But yeah, if you need to modify things often, you may have problems. > 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 If tc filters are attached to a class, they are consulted fir= st for relevant instructions. Filters can match on all fields of a packet h= eader, 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 :) -Toke