From: Thomas Croghan <tcroghan@lostcreek.tech>
To: Cake List <Cake@lists.bufferbloat.net>
Subject: Re: [Cake] ISP Implementation
Date: Wed, 3 Mar 2021 23:31:59 -0700 [thread overview]
Message-ID: <CADmwGqvcnFbAnwqeFEKgYgmBA2CqB=6Gv8zwLbCrR470_ritKQ@mail.gmail.com> (raw)
In-Reply-To: <E562AC96-88D9-4EE8-994E-97546EF71A0C@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
>Cake is *best* used as the bottleneck inducer with effectively unlimited
inbound bandwidth,
I kind of figured that Cake was designed to be the bottleneck, but I don't
want to be telling people the wrong things.
I'll have to take another look LibreQoS, maybe there's a way to duplicate
their work, though I like the processor efficiency I have seen on Cake. (It
could be a Mikrotik implementation or my poor configuration of FQ_Codel
though...)
The issue I had with the LibreQoS model is that you are distancing yourself
from the customer with the bandwidth limiter. In theory you want a
bandwidth limiter limiting the upload traffic from your customer and a
bandwidth limiter right at your upstream connection to limit each
customer's download bandwidth so that your internal network infrastructure
get's efficiently used and prevents your equipment from being the source of
bufferbloat. At least that's the running theory with HTB Bandwidth limiters
that most people are running right now. So in my second question it's
probably going to be best to have a Cake instance on either side of the
limitation.
So this would be preferable right? <Theoretically unlimited bandwidth> --
<Cake Instance Limiting bandwidth going left to right> -- <Some sort of
limit to 100 Mbps> -- <Cake Instance Limiting bandwidth going right to
left> -- <10 x 25 Mbps Customers>
On Wed, Mar 3, 2021 at 8:18 PM Jonathan Morton <chromatix99@gmail.com>
wrote:
> > On 4 Mar, 2021, at 5:14 am, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > yes, that. can it be made to work with cake?
>
> The README says there is experimental support. I haven't looked at it
> closely.
>
> - Jonathan Morton
--
Tommy Croghan
Lost Creek Tech
[-- Attachment #2: Type: text/html, Size: 2398 bytes --]
next prev parent reply other threads:[~2021-03-04 6:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 1:54 Thomas Croghan
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 [this message]
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='CADmwGqvcnFbAnwqeFEKgYgmBA2CqB=6Gv8zwLbCrR470_ritKQ@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