Many ISPs need the kinds of quality shaping cake can do
 help / color / mirror / Atom feed
From: Frantisek Borsik <frantisek.borsik@gmail.com>
To: Cake List <cake@lists.bufferbloat.net>,
	codel@lists.bufferbloat.net, bloat <bloat@lists.bufferbloat.net>,
	Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>,
	Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
	libreqos <libreqos@lists.bufferbloat.net>
Subject: [LibreQoS] Bandwidth is Dead. Long Live Data Logistics (Part 2 of "Bandwidth is Dead")
Date: Sun, 26 Oct 2025 14:47:25 +0100	[thread overview]
Message-ID: <CAJUtOOgmZePzM9XH3CN97MLbOE7EJ4usRuhzgz27WdDTHj8XUg@mail.gmail.com> (raw)

Micah Beck, following up on Jason Livingood's Bandwidth is Dead. Long Live
Latency
<https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-latency>
:

"There is a long history of failed attempts to introduce quality of service
(QoS) guarantees within the public Internet. These efforts have been
focused on guaranteeing a minimal bandwidth throughout the lifetime of a
transport layer connection. An important problem with such approaches is
that the reservation of bandwidth within an otherwise best-effort total is
a strong guarantee, which reduces the deployment scalability of the
network. Proponents of creating a “low latency lane”, such as L4S, seem to
think this is not a form of QoS guarantee."

https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-data-logistics

Well, because big vendors want to continue to sell big buffers (Van
Jacobson was talking <https://www.youtube.com/watch?v=MAni0_lN7zE> about it
at Netdevconf 2018 really extensively!), big telco and big ISP want to sell
the newest Wi-Fi and or 3GPP standard every couple of years - they didn't
implement FQ-CoDel and/or CAKE, for the most part.

There wouldn't be any need for Quality of Experience middle-box, like
LibreQoS, Bequant, Preseem, Paraqum or AppLogic (formerly Sandvine), which
are fixing these issues one ISP network at a time. But there is, and there
will be even more reasons for that. ISPs will continue to buy big, fat
pipes, big telco will be deploying L4S, but the problem would NOT go away.
Everybody and their mother will be asking why :)

They will be pushing 6G on us (heck, they even started - Ericsson guys at
IETF 123 in Madrid, this July), Wi-Fi 8 because lo and behold, Wi-Fi 6/E
didn't fix it and Wi-Fi 7 combined with Gigabit speeds won't do it either.

And yet, the solutions are well know, free na open source: FQ-CoDel and
CAKE.

Long Live Dave Täht. This should be a 3rd part of the "Bandwidth is Dead"
series, but..it won't be. Because we, the industry, will continue to march
in lockstep, on this road with many Dead End Road signs along the way.

Well, I'm still too young and naive (as Dave was!), but one way smarter and
bit older gentleman that was part of our "Keynote: QoE/QoS - Bandwidth Is A
Lie!"
<https://www.wispaevents.org/WPALOOZA25/session/3007494/keynote-qoeqos-bandwidth-is-a-lie>
panel discussion at WISPAPALOOZA 2025 some 10 days ago told me, that
exactly like Starlink was in dire need to fall on their knees when they
badly missed with using old version of OpenWrt without FQ-CoDel/CAKE when
they were starting and got it fixed only after the paint was too much, the
same must most probably happen to Project Kuiper and other satellite
internet providers that are coming up.

I was frustrated that Amazon/Project Kuiper people Dave and I were trying
to talk, were...well, just oblivious to the whole bufferbloat issue.

But it is what it is. BANDWIDTH IS DEAD. LONG LIVE DAVE TÄHT.

Happy Sunday to you all.

All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com

                 reply	other threads:[~2025-10-26 13:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=CAJUtOOgmZePzM9XH3CN97MLbOE7EJ4usRuhzgz27WdDTHj8XUg@mail.gmail.com \
    --to=frantisek.borsik@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cake@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    --cc=libreqos@lists.bufferbloat.net \
    --cc=rpm@lists.bufferbloat.net \
    --cc=starlink@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