From: Pete Heist <peteheist@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] flow isolation for ISPs
Date: Thu, 6 Apr 2017 15:50:25 +0200 [thread overview]
Message-ID: <89266506-4EBA-4C7C-870A-31C4A00522B2@gmail.com> (raw)
In-Reply-To: <87r315r6ty.fsf@alrua-kau>
[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]
> On Apr 6, 2017, at 3:42 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Ah, right; you can't get the two-level scheduling that Cake does with
> just FQ-CoDel. Didn't realise you were looking for that, sorry...
>
> You could assign a fixed number of hash buckets to each member (i.e.
> member #1 gets buckets 1-10, say, hashing flows into those). But the
> FQ-CoDel scheduler would be oblivious to the hierarchy, so a member with
> 10 active queues would get service for each of those each time another
> member with just one active queue gets service for his queue.
>
> To get the hierarchical sub-division, you'd need to have a two-level
> scheme where you have a separate instance of fq-codel per member.
Well, it's only perhaps a requirement. I’m in the middle of some flow isolation tests to look at the difference between Cake’s ‘srchost’ and ‘dual-srchost’ keywords and try to figure out whether one or the other is “better" to use on a ISP backhaul’s egress. I’m not sure yet, but if there are any opinions on it it could help.
But this is also helpful, because either per-member scheduling is good enough, or we’d need multiple fq_codel instances, and at that point it could also be Cake as well… :)
[-- Attachment #2: Type: text/html, Size: 8700 bytes --]
next prev parent reply other threads:[~2017-04-06 13: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
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 [this message]
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=89266506-4EBA-4C7C-870A-31C4A00522B2@gmail.com \
--to=peteheist@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=toke@toke.dk \
/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