Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Thomas Croghan <tcroghan@lostcreek.tech>
To: Cake@lists.bufferbloat.net
Subject: [Cake] ISP Implementation
Date: Wed, 3 Mar 2021 18:54:30 -0700	[thread overview]
Message-ID: <CADmwGqvtAg9p_+RHN2bGms=8XLNU698irJ_VVoXjYpZ2v7=Vyw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

So, a beta of Mikrotik's RouterOS was released some time ago which finally
has Cake built into it.

In testing everything seems to be working, I just am coming up with some
questions that I haven't been able to answer.

Should there be any special considerations when Cake is being used in a
setting where it's by far the most significant limiting factor to a
connection? For example: <internet> --10 Gbps Fiber -- <ISP Router> --10
Gbps Fiber -- [ISP Switch] -- 1 Gbps Fiber -- <500 Mbps Customer>
In this situation very frequently the "<ISP Router>" could be running Cake
and do the bandwidth limiting of the customer down to 1/2 (or even less) of
the physical connectivity. A lot of the conversations here revolve around
Cake being set up just below the Bandwidth limits of the ISP, but that's
not really going to be the case in a lot of the ISP world.

Another question would be based on the above:

How well does Cake do with stacking instances? In some cases our above
example could look more like this: <Internet> -- [Some sort of limitation
to 100 Mbps] -- <ISP Router> -- 1 Gbps connection- <25 Mbps Customer X 10>

In this situation, would it be helpful to Cake to have a "Parent Queue"
that limits the total throughput of all customer traffic to 99-100 Mbps
then "Child Queues" that respectively limit customers to their 25 Mbps? Or
would it be better to just setup each customer Queue at their limit and let
Cake handle the times when the oversubscription has reared it's ugly head?


To be honest I have a few more questions, but I don't think many people
want to read pages and pages of my ignorance. If my question isn't too
stupid, I would love to ask a few others.

[-- Attachment #2: Type: text/html, Size: 2163 bytes --]

             reply	other threads:[~2021-03-04  1:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04  1:54 Thomas Croghan [this message]
2021-03-04  2:47 ` Jonathan Morton
2021-03-04  2:51   ` Dave Taht
2021-03-04  2:55     ` Jonathan Morton
2021-03-04  3:14       ` Dave Taht
2021-03-04  3:18         ` Jonathan Morton
2021-03-04  6:31           ` Thomas Croghan
2021-03-04  8:14             ` Jonathan Morton

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='CADmwGqvtAg9p_+RHN2bGms=8XLNU698irJ_VVoXjYpZ2v7=Vyw@mail.gmail.com' \
    --to=tcroghan@lostcreek.tech \
    --cc=Cake@lists.bufferbloat.net \
    /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