From: Dave Taht <dave.taht@gmail.com>
To: Ignacio Ocampo <nafiux@gmail.com>
Cc: libreqos@lists.bufferbloat.net
Subject: Re: [LibreQoS] LibreQoS upstream + Cake/FQ_Codel in CPE Router?
Date: Mon, 11 Sep 2023 09:23:25 -0700 [thread overview]
Message-ID: <CAA93jw4VquGRP0qtPbva_oJ49R+TiTjLonRYPqwwsFL8nNaRpg@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw5YE73vckKmC33zd-3=+ChLnfAh+NVscWiEuNk6nxYBjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2930 bytes --]
On Mon, Sep 11, 2023 at 9:18 AM Dave Taht <dave.taht@gmail.com> wrote:
> Most of our users are in the libreqos chat, and you will in general get
> fasters responses there than here.
>
>
> On Sun, Sep 10, 2023 at 7:35 PM Ignacio Ocampo via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
>> Hi all,
>>
>> Is it recommended (or not), to run Cake/FQ_Codel in CPE routers, even if
>> LibreQoS is running upstream?
>>
>
> We recommend running cake on the CPE up, and LibreQos to manage the down.
> It is very helpful to have cake running in nat mode on the actual device
> doing nat (and in that case managing the down also at that device can help)
>
> We recommend using wifi routers that run fq_codel natively on the wifi,
> also, as at higher rates the bottlenecks' bloat shift to the wifi.
>
> https://lwn.net/Articles/705884/
>
> Many devices support fq_codel on the wifi natively, the eero 5, evenroute,
> and many gl.inet products do.
>
>>
>> If so, which are the advantages?
>>
>
> Running cake on the actual bottleneck prevents malignant traffic from
> escaping the home network. A mere ping flood can be controlled by libreqos,
> but it is better to slow that down and mix it up with all the other traffic
> at the cpe. The algorithms for ack-filtering and congestion management are
> always more accurate when put on the actual bottleneck.
>
To clarify this a bit further, by default libreqos ships with two
parameters that actually override the overall settings somewhat. We
multiply by 1.09 by default to allow for sufficient slop to look good on
speedtest,
and have another parameter that helps modify the per hop transit settings.
What you were sort of suggesting below is conciously underprovisioning the
cpe, where by default we already overprovision libreqos.
>
> Also, I'm assuming I will have to set up the router with a lower bandwidth
>> than the assigned by LibreQoS?
>>
>
> yes.
>
>>
>> For instance, if LibreQoS is assigning 13Mbit to the customer, the router
>> (with Cake or FQ_Codel) enabled need to have a limit of ~11Mbit?
>>
>
> On up from the cpe traffic, you should be able to use the same number as
> you use in libreqos. For shaping the down at the cpe the historical
> recommendation has always been 85-90%, but with libreqos managing that, no
> shaping of the down is needed, although I do call out the nat case as a
> potential exception.
>
>
>>
>> Please advise. Thanks!
>>
>> --
>> Ignacio Ocampo
>>
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
>
>
> --
> Oct 30:
> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> Dave Täht CSO, LibreQos
>
--
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
[-- Attachment #2: Type: text/html, Size: 5511 bytes --]
prev parent reply other threads:[~2023-09-11 16:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 2:35 Ignacio Ocampo
2023-09-11 16:18 ` Dave Taht
2023-09-11 16:23 ` Dave Taht [this message]
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/libreqos.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw4VquGRP0qtPbva_oJ49R+TiTjLonRYPqwwsFL8nNaRpg@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=libreqos@lists.bufferbloat.net \
--cc=nafiux@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