Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Pete Heist <peteheist@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] flow isolation for ISPs
Date: Thu, 06 Apr 2017 12:50:05 +0200	[thread overview]
Message-ID: <87r315u7xe.fsf@alrua-kau> (raw)
In-Reply-To: <8E96329F-A57D-49C7-A7EE-60BD165B4D5C@gmail.com> (Pete Heist's message of "Thu, 6 Apr 2017 12:26:59 +0200")

Pete Heist <peteheist@gmail.com> writes:

>  On Apr 6, 2017, at 11:33 AM, Toke Høiland-Jørgensen <toke@toke.dk> 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’m just exploring
> 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’s 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 “We 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 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 :)

-Toke

  reply	other threads:[~2017-04-06 10:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06  8:27 Pete Heist
2017-04-06  8:39 ` David Lang
2017-04-06  8:48   ` Pete Heist
2017-04-06  8:57 ` Jonathan Morton
2017-04-06  9:04   ` Pete Heist
2017-04-06 10:26   ` Andy Furniss
2017-04-06  9:11 ` Jonathan Morton
2017-04-06  9:26   ` Pete Heist
2017-04-07  8:13     ` Pete Heist
2017-04-07  8:28       ` Jonathan Morton
2017-04-07  9:37         ` Pete Heist
2017-04-07 11:13           ` Sebastian Moeller
2017-04-07 11:42             ` Pete Heist
2017-04-08  6:16           ` Pete Heist
2017-04-07 10:56         ` John Sager
2017-04-06  9:33 ` Toke Høiland-Jørgensen
2017-04-06 10:26   ` Pete Heist
2017-04-06 10:50     ` Toke Høiland-Jørgensen [this message]
2017-04-06 11:34       ` Pete Heist
2017-04-06 12:14         ` Toke Høiland-Jørgensen
2017-04-06 13:30           ` Pete Heist
2017-04-06 13:42             ` Toke Høiland-Jørgensen
2017-04-06 13:50               ` Pete Heist
2017-04-06 14:41               ` Dave Taht
2017-04-06 12:48     ` Andy Furniss
2017-04-06 13:19 Konstantin Shalygin
     [not found] <mailman.340.1491486631.3609.cake@lists.bufferbloat.net>
2017-04-06 14:18 ` Pete Heist
2017-04-06 15:41   ` Andy Furniss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r315u7xe.fsf@alrua-kau \
    --to=toke@toke.dk \
    --cc=cake@lists.bufferbloat.net \
    --cc=peteheist@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox