Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jim Forster <jim@connectivitycap.com>
To: J Pan <Pan@uvic.ca>
Cc: Frantisek Borsik <frantisek.borsik@gmail.com>,
	Cake List <cake@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>,
	codel@lists.bufferbloat.net,
	libreqos <libreqos@lists.bufferbloat.net>,
	l4s-discuss@ietf.org, starlink@lists.bufferbloat.net
Subject: [Cake] Re: [Starlink] [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)
Date: Fri, 7 Nov 2025 13:55:18 -0500	[thread overview]
Message-ID: <3934C9BE-EED5-4DF7-9451-E438E0FEFE3E@connectivitycap.com> (raw)
In-Reply-To: <CAHn=e4iyb6FDc+Jrwx+5jdhZ35qoM8Weoz=Ktvth-NdUKZ7VmA@mail.gmail.com>

Exactly so.

Consumer expectations and service provider marketing may be influenced by memories of experience when transmission delay did matter.  At one time I was very happy with my home ISDN connection, and even shared it with my neighbor.  At about 128kbs, it was three orders of magnitude slower than my home fiber link.  I’ve not run the numbers but I’m pretty sure transimission speed mattered for video, even for crummy quality video,  So then when I learned a bit about digital video, and cable’s 64 QAM 27mbps channels, I got excited and thought, “wow, they could deliver 1mbps service!  And wouldn’t it be cool to have 1M home online at 10x the speed of ISDN?”.  It was cool!  And two more orders of magnitude later, here we are.

  — Jim

> On Nov 7, 2025, at 12:52 PM, J Pan <Pan@uvic.ca> wrote:
> 
> latency is based on round-trip time, and one-way delay includes
> transmission delay, propagation delay, queuing delay and processing
> delay. bandwidth does affect transmission delay (or serialization
> delay), propagation delay is determined by the link length and the
> "travel" speed of the signal, queuing delay is the hardest part and
> affected by the buffer bloat a lot, and processing delay is another
> variable. of course, transmission delay takes less and less portion of
> the end-to-end delay now due to higher and higher "speed" links
> 
> consumers may mistaken the speed of the link (the "width" of their
> pipe) as how fast their internet is (the "length" of the pipe), due to
> the poor terminology we have been using ;-)


  reply	other threads:[~2025-11-07 18:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-30 20:24 [Cake] Re: [LibreQoS] Re: [Starlink] " James Forster
2025-09-30 20:48 ` Frantisek Borsik
2025-10-01 19:24   ` dan
2025-10-01 21:32     ` Frantisek Borsik
2025-11-07 10:53       ` Frantisek Borsik
2025-11-07 16:19         ` [Cake] Re: [Starlink] [LibreQoS] " Jim Forster
2025-11-07 17:52           ` [Cake] Re: [Starlink] " J Pan
2025-11-07 18:55             ` Jim Forster [this message]
2025-11-07 19:50               ` [Cake] Re: [Starlink] " J Pan
2025-11-08 16:00                 ` [Cake] Re: [LibreQoS] Re: [Starlink] " dan
2025-11-08 17:03                   ` J Pan
2025-11-08 18:11                     ` [Cake] Re: [Starlink] [LibreQoS] " Sebastian Moeller

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=3934C9BE-EED5-4DF7-9451-E438E0FEFE3E@connectivitycap.com \
    --to=jim@connectivitycap.com \
    --cc=Pan@uvic.ca \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cake@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    --cc=frantisek.borsik@gmail.com \
    --cc=l4s-discuss@ietf.org \
    --cc=libreqos@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