[Cake] Re: [LibreQoS] Re: [Starlink] Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[Cake] Re: [LibreQoS] Re: [Starlink] Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[James Forster]

Wow, that’s fantastic, Frantisek!  Great work making this happen. 

These sort of titles aren’t my favorite. I think I understand the sentiment but find the issues more nuanced than that. :-)

If you can get clear audio, not much quality is needed for panels and talking beads.   Best would be a feed right into an iPhone/android. 

Jim

[Cake] Re: [LibreQoS] Re: [Starlink] Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[Frantisek Borsik]

Thanks, Jim. Well, true that - but I wanted to do it either way, because of
our dear Dave and - as a conversation starter.
As @Jason Livingood <jason_livingood@comcast.com> said - "Bandwidth is
dead. Long live latency."
https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-latency

I will do my best to get the audio/video right and to share it with you all.

PS: Sending you separate email.

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


On Tue, Sep 30, 2025 at 10:25 PM James Forster <jim@connectivitycap.com>
wrote:

> Wow, that’s fantastic, Frantisek!  Great work making this happen.
>
> These sort of titles aren’t my favorite. I think I understand the
> sentiment but find the issues more nuanced than that. :-)
>
> If you can get clear audio, not much quality is needed for panels and
> talking beads.   Best would be a feed right into an iPhone/android.
>
> Jim

[Cake] Re: [LibreQoS] Re: [Starlink] Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[dan]

I actually really like the title ;)

It's that most of the time people are told they need more bandwidth to
solve a problem, when they really need lower latency and jitter.  So the
vast majority of the time 'more bandwidth' as a solution really is a lie.

On Tue, Sep 30, 2025 at 2:47 PM Frantisek Borsik via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> Thanks, Jim. Well, true that - but I wanted to do it either way, because of
> our dear Dave and - as a conversation starter.
> As @Jason Livingood <jason_livingood@comcast.com> said - "Bandwidth is
> dead. Long live latency."
> https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-latency
>
> I will do my best to get the audio/video right and to share it with you
> all.
>
> PS: Sending you separate email.
>
> 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
>
>
> On Tue, Sep 30, 2025 at 10:25 PM James Forster <jim@connectivitycap.com>
> wrote:
>
> > Wow, that’s fantastic, Frantisek!  Great work making this happen.
> >
> > These sort of titles aren’t my favorite. I think I understand the
> > sentiment but find the issues more nuanced than that. :-)
> >
> > If you can get clear audio, not much quality is needed for panels and
> > talking beads.   Best would be a feed right into an iPhone/android.
> >
> > Jim
> _______________________________________________
> LibreQoS mailing list -- libreqos@lists.bufferbloat.net
> To unsubscribe send an email to libreqos-leave@lists.bufferbloat.net
>

[Cake] Re: [LibreQoS] Re: [Starlink] Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[Frantisek Borsik]

Let's say that I love it, channeling my inner Dave Taht. But there were a
couple of voices asking if I won't consider to change it a bit, to be "less
hostile" to our "bandwidth is king!" friends...and I was trying, but this
was really sticky and I'm happy that it stayed this way.


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


On Wed, Oct 1, 2025 at 9:25 PM dan <dandenson@gmail.com> wrote:

> I actually really like the title ;)
>
> It's that most of the time people are told they need more bandwidth to
> solve a problem, when they really need lower latency and jitter.  So the
> vast majority of the time 'more bandwidth' as a solution really is a lie.
>
> On Tue, Sep 30, 2025 at 2:47 PM Frantisek Borsik via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
>> Thanks, Jim. Well, true that - but I wanted to do it either way, because
>> of
>> our dear Dave and - as a conversation starter.
>> As @Jason Livingood <jason_livingood@comcast.com> said - "Bandwidth is
>> dead. Long live latency."
>> https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-latency
>>
>> I will do my best to get the audio/video right and to share it with you
>> all.
>>
>> PS: Sending you separate email.
>>
>> 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
>>
>>
>> On Tue, Sep 30, 2025 at 10:25 PM James Forster <jim@connectivitycap.com>
>> wrote:
>>
>> > Wow, that’s fantastic, Frantisek!  Great work making this happen.
>> >
>> > These sort of titles aren’t my favorite. I think I understand the
>> > sentiment but find the issues more nuanced than that. :-)
>> >
>> > If you can get clear audio, not much quality is needed for panels and
>> > talking beads.   Best would be a feed right into an iPhone/android.
>> >
>> > Jim
>> _______________________________________________
>> LibreQoS mailing list -- libreqos@lists.bufferbloat.net
>> To unsubscribe send an email to libreqos-leave@lists.bufferbloat.net
>>
>

[Cake] Re: [LibreQoS] Re: [Starlink] Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[Frantisek Borsik]

Hello to all,

Recording of our QoE/QoS panel discussion is out! It was really great and
believe you will like it:

https://www.youtube.com/watch?v=T1VET0VYQ6c

We have touch bandwidth, L4S, Starlink and more.

Here are the slides with additional reading:
https://docs.google.com/presentation/d/1ML0I3Av3DCtQDiP8Djr_YGH2r4-UDZP25VEk-xyJcZE/edit?slide=id.p#slide=id.p

We hope to continue this conversation into more practical, demo-like
environment of sort, that we can see at IETF Hackathon and used to see in
the early WISPA event days, with Animal Farm.


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


On Wed, Oct 1, 2025 at 11:32 PM Frantisek Borsik <frantisek.borsik@gmail.com>
wrote:

> Let's say that I love it, channeling my inner Dave Taht. But there were a
> couple of voices asking if I won't consider to change it a bit, to be "less
> hostile" to our "bandwidth is king!" friends...and I was trying, but this
> was really sticky and I'm happy that it stayed this way.
>
>
> 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
>
>
> On Wed, Oct 1, 2025 at 9:25 PM dan <dandenson@gmail.com> wrote:
>
>> I actually really like the title ;)
>>
>> It's that most of the time people are told they need more bandwidth to
>> solve a problem, when they really need lower latency and jitter.  So the
>> vast majority of the time 'more bandwidth' as a solution really is a lie.
>>
>> On Tue, Sep 30, 2025 at 2:47 PM Frantisek Borsik via LibreQoS <
>> libreqos@lists.bufferbloat.net> wrote:
>>
>>> Thanks, Jim. Well, true that - but I wanted to do it either way, because
>>> of
>>> our dear Dave and - as a conversation starter.
>>> As @Jason Livingood <jason_livingood@comcast.com> said - "Bandwidth is
>>> dead. Long live latency."
>>>
>>> https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-latency
>>>
>>> I will do my best to get the audio/video right and to share it with you
>>> all.
>>>
>>> PS: Sending you separate email.
>>>
>>> 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
>>>
>>>
>>> On Tue, Sep 30, 2025 at 10:25 PM James Forster <jim@connectivitycap.com>
>>> wrote:
>>>
>>> > Wow, that’s fantastic, Frantisek!  Great work making this happen.
>>> >
>>> > These sort of titles aren’t my favorite. I think I understand the
>>> > sentiment but find the issues more nuanced than that. :-)
>>> >
>>> > If you can get clear audio, not much quality is needed for panels and
>>> > talking beads.   Best would be a feed right into an iPhone/android.
>>> >
>>> > Jim
>>> _______________________________________________
>>> LibreQoS mailing list -- libreqos@lists.bufferbloat.net
>>> To unsubscribe send an email to libreqos-leave@lists.bufferbloat.net
>>>
>>

[Cake] Re: [Starlink] [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[Jim Forster]

Frank — I’m watching it now, Great job pulling this group together, and nice, balanced opening statement. 

  — Jim

> On Nov 7, 2025, at 5:53 AM, Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> 
> Recording of our QoE/QoS panel discussion is out! It was really great and
> believe you will like it:
> 
> https://www.youtube.com/watch?v=T1VET0VYQ6c
> 
> We have touch bandwidth, L4S, Starlink and more.
> 
> Here are the slides with additional reading:
> https://docs.google.com/presentation/d/1ML0I3Av3DCtQDiP8Djr_YGH2r4-UDZP25VEk-xyJcZE/edit?slide=id.p#slide=id.p
> 
> We hope to continue this conversation into more practical, demo-like
> environment of sort, that we can see at IETF Hackathon and used to see in
> the early WISPA event days, with Animal Farm.

[Cake] Re: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[J Pan]

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 ;-)
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Fri, Nov 7, 2025 at 8:19 AM Jim Forster via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> Frank — I’m watching it now, Great job pulling this group together, and nice, balanced opening statement.
>
>   — Jim
>
> > On Nov 7, 2025, at 5:53 AM, Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net> wrote:
> >
> >
> > Recording of our QoE/QoS panel discussion is out! It was really great and
> > believe you will like it:
> >
> > https://www.youtube.com/watch?v=T1VET0VYQ6c
> >
> > We have touch bandwidth, L4S, Starlink and more.
> >
> > Here are the slides with additional reading:
> > https://docs.google.com/presentation/d/1ML0I3Av3DCtQDiP8Djr_YGH2r4-UDZP25VEk-xyJcZE/edit?slide=id.p#slide=id.p
> >
> > We hope to continue this conversation into more practical, demo-like
> > environment of sort, that we can see at IETF Hackathon and used to see in
> > the early WISPA event days, with Animal Farm.
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Cake] Re: [Starlink] [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[Jim Forster]

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 ;-)

[Cake] Re: [Starlink] [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[J Pan]

marketing is even worse. some claim 200mbps because 150mbps down and
50mbps up at peak data rate. of course, this is not the only problem
in telecom, but likely the worst

nevertheless, there are stats such as 10% inflation for food and 20%
for gas, so in total 30% ;-) at this rate, any numbers can be floating
around but none are telling the truth ;-)
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Fri, Nov 7, 2025 at 10:55 AM Jim Forster <jim@connectivitycap.com> wrote:
>
> 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 ;-)
>
>

[Cake] Re: [LibreQoS] Re: [Starlink] Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[dan]

I'm starting to see the signs that raw bandwidth is starting to lose
it's dominance for marketing.  It's still the clear #1 ask but price
is rapidly overtaking speed for our customer requests.

I believe we've hit this era's threshold on throughput needs and
people have started to notice that 'more' doesn't feel like a faster
service.

one common scenario that we are using to win customers, in combination
with facebook testimonials, is that people have bad experiences with
wifi and they order a faster service from cable/fiber company and the
wifi just gets worse.  This scenario I think is incredibly common and
seems to be a catalyst for 'speed isn't everything'.  We come in with
50-500Mbps of service and solid whole-home wifi and they are
converted.

I hope we're not to far off from having 'speed' be just a feature, not
the entire story.

and yes, we QoE or service with cake via libreqos which is the
difference between great service and inadequate service IMO.

On Fri, Nov 7, 2025 at 12:50 PM J Pan via LibreQoS
<libreqos@lists.bufferbloat.net> wrote:
>
> marketing is even worse. some claim 200mbps because 150mbps down and
> 50mbps up at peak data rate. of course, this is not the only problem
> in telecom, but likely the worst
>
> nevertheless, there are stats such as 10% inflation for food and 20%
> for gas, so in total 30% ;-) at this rate, any numbers can be floating
> around but none are telling the truth ;-)
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Fri, Nov 7, 2025 at 10:55 AM Jim Forster <jim@connectivitycap.com> wrote:
> >
> > 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 ;-)
> >
> >
> _______________________________________________
> LibreQoS mailing list -- libreqos@lists.bufferbloat.net
> To unsubscribe send an email to libreqos-leave@lists.bufferbloat.net

[Cake] Re: [LibreQoS] Re: [Starlink] Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[J Pan]

yes, availability (at least two competing network providers with
reliable services), affordability (so the competition to bring the
price and cost down) and applicability to modern internet applications
(video streaming, conferencing and gaming in addition to email and web
browsing) shall be the user-centric metrics in addition to throughput,
latency/jitter, packet loss, etc
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Sat, Nov 8, 2025 at 8:00 AM dan <dandenson@gmail.com> wrote:
>
> I'm starting to see the signs that raw bandwidth is starting to lose
> it's dominance for marketing.  It's still the clear #1 ask but price
> is rapidly overtaking speed for our customer requests.
>
> I believe we've hit this era's threshold on throughput needs and
> people have started to notice that 'more' doesn't feel like a faster
> service.
>
> one common scenario that we are using to win customers, in combination
> with facebook testimonials, is that people have bad experiences with
> wifi and they order a faster service from cable/fiber company and the
> wifi just gets worse.  This scenario I think is incredibly common and
> seems to be a catalyst for 'speed isn't everything'.  We come in with
> 50-500Mbps of service and solid whole-home wifi and they are
> converted.
>
> I hope we're not to far off from having 'speed' be just a feature, not
> the entire story.
>
> and yes, we QoE or service with cake via libreqos which is the
> difference between great service and inadequate service IMO.
>
> On Fri, Nov 7, 2025 at 12:50 PM J Pan via LibreQoS
> <libreqos@lists.bufferbloat.net> wrote:
> >
> > marketing is even worse. some claim 200mbps because 150mbps down and
> > 50mbps up at peak data rate. of course, this is not the only problem
> > in telecom, but likely the worst
> >
> > nevertheless, there are stats such as 10% inflation for food and 20%
> > for gas, so in total 30% ;-) at this rate, any numbers can be floating
> > around but none are telling the truth ;-)
> > --
> > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> >
> > On Fri, Nov 7, 2025 at 10:55 AM Jim Forster <jim@connectivitycap.com> wrote:
> > >
> > > 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 ;-)
> > >
> > >
> > _______________________________________________
> > LibreQoS mailing list -- libreqos@lists.bufferbloat.net
> > To unsubscribe send an email to libreqos-leave@lists.bufferbloat.net

[Cake] Re: [Starlink] [LibreQoS] Re: Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[Sebastian Moeller]

Hi J,


> On 8. Nov 2025, at 18:03, J Pan via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> yes, availability (at least two competing network providers with
> reliable services),

As David already mentioned that gets us a duopoly, but going mildly higher still results in an oligopoly... As a market realist (that is someone who accepts efficient market when he sees them, but does not naive believe in the fairy tales of the invisible hand of the market) I think that we would be often much better off with a competently managed/regulated monopoly than with duo- to oligopolies that are treated as if they were efficient markets... Infrastructure (and at least access networks are at least infrastructure-ish IMHO) is not something where the free market typically excels at.

> affordability (so the competition to bring the
> price and cost down)

I agree, but that is really at odds with your first point, to get that from a market we clearly need to grow the supply side to get out of oligopoly territory, and I am not sure that that is actually feasible.

> and applicability to modern internet applications
> (video streaming, conferencing and gaming in addition to email and web
> browsing) shall be the user-centric metrics in addition to throughput,
> latency/jitter, packet loss, etc

I am 100% behind this. I will mention though that I believe that latency increase under load is a decent proxy for the utility of a given access link for the usability with interactive applications.

Regards
	Sebastian

> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> 
> On Sat, Nov 8, 2025 at 8:00 AM dan <dandenson@gmail.com> wrote:
>> 
>> I'm starting to see the signs that raw bandwidth is starting to lose
>> it's dominance for marketing.  It's still the clear #1 ask but price
>> is rapidly overtaking speed for our customer requests.
>> 
>> I believe we've hit this era's threshold on throughput needs and
>> people have started to notice that 'more' doesn't feel like a faster
>> service.
>> 
>> one common scenario that we are using to win customers, in combination
>> with facebook testimonials, is that people have bad experiences with
>> wifi and they order a faster service from cable/fiber company and the
>> wifi just gets worse.  This scenario I think is incredibly common and
>> seems to be a catalyst for 'speed isn't everything'.  We come in with
>> 50-500Mbps of service and solid whole-home wifi and they are
>> converted.
>> 
>> I hope we're not to far off from having 'speed' be just a feature, not
>> the entire story.
>> 
>> and yes, we QoE or service with cake via libreqos which is the
>> difference between great service and inadequate service IMO.
>> 
>> On Fri, Nov 7, 2025 at 12:50 PM J Pan via LibreQoS
>> <libreqos@lists.bufferbloat.net> wrote:
>>> 
>>> marketing is even worse. some claim 200mbps because 150mbps down and
>>> 50mbps up at peak data rate. of course, this is not the only problem
>>> in telecom, but likely the worst
>>> 
>>> nevertheless, there are stats such as 10% inflation for food and 20%
>>> for gas, so in total 30% ;-) at this rate, any numbers can be floating
>>> around but none are telling the truth ;-)
>>> --
>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>> 
>>> On Fri, Nov 7, 2025 at 10:55 AM Jim Forster <jim@connectivitycap.com> wrote:
>>>> 
>>>> 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 ;-)
>>>> 
>>>> 
>>> _______________________________________________
>>> LibreQoS mailing list -- libreqos@lists.bufferbloat.net
>>> To unsubscribe send an email to libreqos-leave@lists.bufferbloat.net
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net