[Starlink] Re: Starlink Digest, Vol 55, Issue 3

[Starlink] Re: Starlink Digest, Vol 55, Issue 3

[David Fernández]

Thanks for sharing this Frank.

In slide 3, I think that another effect not to be missed is packet losses
due to errors, which could be analogous to pipe leaks. Sometimes, it
happens that they are not negligible, in some cases with wireless links,
mainly, but it could happen too in DSL. I remember that I had a DSL line in
which the router had the option to disable interleaving, warning that you
could get more errors, bad for watching video, they were saying, but
reduced latency (good for videogames). When packet losses due to errors are
misinterpreted as congestion by the transport protocols, the result is also
a band quality of experience.

Regards,

David

Date: Fri, 7 Nov 2025 11:53:44 +0100
> From: Frantisek Borsik <frantisek.borsik@gmail.com>
> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>         A Lie!  at WISPAPALOOZA 2025 (October 16)
> To: Cake List <cake@lists.bufferbloat.net>, bloat
>         <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>         Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>         <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>         <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
> Message-ID:
>         <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
> uhiQPd3KOg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> >>>
> >>
>
>

[Starlink] Re: Starlink Digest, Vol 55, Issue 3

[J Pan]

yes, end-to-end congestion control was an add-on to tcp flow and error
control, and at that time, packet loss was the only reliable
congestion signal without router collaboration, and the  legacy stays.
from the experience of tuning tcp on cellular networks, making the
link layer more reliable is "the way", at the cost of more buffers and
latency. but now physical, link and network layer have more info for
the transport layer to make the right decision, e.g., starlink
handovers at 12th, 27th, 42nd and 57th second of every minute with
delay spike and losses
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> Thanks for sharing this Frank.
>
> In slide 3, I think that another effect not to be missed is packet losses
> due to errors, which could be analogous to pipe leaks. Sometimes, it
> happens that they are not negligible, in some cases with wireless links,
> mainly, but it could happen too in DSL. I remember that I had a DSL line in
> which the router had the option to disable interleaving, warning that you
> could get more errors, bad for watching video, they were saying, but
> reduced latency (good for videogames). When packet losses due to errors are
> misinterpreted as congestion by the transport protocols, the result is also
> a band quality of experience.
>
> Regards,
>
> David
>
> Date: Fri, 7 Nov 2025 11:53:44 +0100
> > From: Frantisek Borsik <frantisek.borsik@gmail.com>
> > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
> >         A Lie!  at WISPAPALOOZA 2025 (October 16)
> > To: Cake List <cake@lists.bufferbloat.net>, bloat
> >         <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
> >         Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
> >         <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
> >         <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
> > Message-ID:
> >         <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
> > uhiQPd3KOg@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > 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
> > >>>
> > >>
> >
> >
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[David Fernández]

"making the link layer more reliable is "the way"", indeed. In the wireless
data link design projects I have participated, it has always been the
requirement to have packet loss rate (PLR) at IP layer due to physical
layer errors uniformly distributed and not higher than 0.1%, for TCP, while
for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1%
PLR is acceptable.

Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6%
or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR
are more robust to higher packet loss rates due to error than Reno.

"now physical, link and network layer have more info for
the transport layer to make the right decision", but do they? I mean, how
is the transport layer getting info nowadays about the path characteristics
in terms of bandwidth, latency and packet losses from the layers below or
info like the one you mentioned about Starlink handovers? I still have not
seen this happening, have you?

Regards,

David

On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:

> yes, end-to-end congestion control was an add-on to tcp flow and error
> control, and at that time, packet loss was the only reliable
> congestion signal without router collaboration, and the  legacy stays.
> from the experience of tuning tcp on cellular networks, making the
> link layer more reliable is "the way", at the cost of more buffers and
> latency. but now physical, link and network layer have more info for
> the transport layer to make the right decision, e.g., starlink
> handovers at 12th, 27th, 42nd and 57th second of every minute with
> delay spike and losses
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> Web.UVic.CA/~pan
>
> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
> <starlink@lists.bufferbloat.net> wrote:
> >
> > Thanks for sharing this Frank.
> >
> > In slide 3, I think that another effect not to be missed is packet losses
> > due to errors, which could be analogous to pipe leaks. Sometimes, it
> > happens that they are not negligible, in some cases with wireless links,
> > mainly, but it could happen too in DSL. I remember that I had a DSL line
> in
> > which the router had the option to disable interleaving, warning that you
> > could get more errors, bad for watching video, they were saying, but
> > reduced latency (good for videogames). When packet losses due to errors
> are
> > misinterpreted as congestion by the transport protocols, the result is
> also
> > a band quality of experience.
> >
> > Regards,
> >
> > David
> >
> > Date: Fri, 7 Nov 2025 11:53:44 +0100
> > > From: Frantisek Borsik <frantisek.borsik@gmail.com>
> > > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
> > >         A Lie!  at WISPAPALOOZA 2025 (October 16)
> > > To: Cake List <cake@lists.bufferbloat.net>, bloat
> > >         <bloat@lists.bufferbloat.net>,
> codel@lists.bufferbloat.net,
> > >         Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
> > >         <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
> > >         <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
> > > Message-ID:
> > >         <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
> > > uhiQPd3KOg@mail.gmail.com>
> > > Content-Type: text/plain; charset="UTF-8"
> > >
> > > 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
> > > >>>
> > > >>
> > >
> > >
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Starlink Digest, Vol 55, Issue 3

[Sebastian Moeller]

> On 8. Nov 2025, at 18:30, J Pan via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> yes, end-to-end congestion control was an add-on to tcp flow and error
> control, and at that time, packet loss was the only reliable
> congestion signal

And it still is, when push comes to shove all an over-congested router can do to shovel itself out of an overload is aggressively dropping packets. So this still is a valid signal a rate controller should respect... I am not sure BBR's cavalier approach to loss is actually a good thing for the internet.

> without router collaboration, and the  legacy stays.

See above, because in the extreme it is still an important observable, no?

> from the experience of tuning tcp on cellular networks, making the
> link layer more reliable is "the way", at the cost of more buffers and
> latency. but now physical, link and network layer have more info for
> the transport layer to make the right decision, e.g., starlink
> handovers at 12th, 27th, 42nd and 57th second of every minute with
> delay spike and losses

It is one thing knowing that starlink has these 15 seconds (and 4 seconds?) events but another one how to properly deal with them. 

> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> 
> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
> <starlink@lists.bufferbloat.net> wrote:
>> 
>> Thanks for sharing this Frank.
>> 
>> In slide 3, I think that another effect not to be missed is packet losses
>> due to errors, which could be analogous to pipe leaks. Sometimes, it
>> happens that they are not negligible, in some cases with wireless links,
>> mainly, but it could happen too in DSL. I remember that I had a DSL line in
>> which the router had the option to disable interleaving, warning that you
>> could get more errors, bad for watching video, they were saying, but
>> reduced latency (good for videogames). When packet losses due to errors are
>> misinterpreted as congestion by the transport protocols, the result is also
>> a band quality of experience.
>> 
>> Regards,
>> 
>> David
>> 
>> Date: Fri, 7 Nov 2025 11:53:44 +0100
>>> From: Frantisek Borsik <frantisek.borsik@gmail.com>
>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>>>        A Lie!  at WISPAPALOOZA 2025 (October 16)
>>> To: Cake List <cake@lists.bufferbloat.net>, bloat
>>>        <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>>>        Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>>>        <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>>>        <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
>>> Message-ID:
>>>        <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
>>> uhiQPd3KOg@mail.gmail.com>
>>> Content-Type: text/plain; charset="UTF-8"
>>> 
>>> 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
>>>>>> 
>>>>> 
>>> 
>>> 
>> _______________________________________________
>> Starlink mailing list -- starlink@lists.bufferbloat.net
>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[J Pan]

if there are no obstructions, starlink nowadays can achieve 1% packet
loss, often 0.1%, mostly due to satellite handover, so for the netflix
open connect appliances inside starlink pop, they can do some
starlink-specific optimization to mask away the handover for starlink
users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
>
> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
>
> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
>
> "now physical, link and network layer have more info for
> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
>
> Regards,
>
> David
>
> On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
>>
>> yes, end-to-end congestion control was an add-on to tcp flow and error
>> control, and at that time, packet loss was the only reliable
>> congestion signal without router collaboration, and the  legacy stays.
>> from the experience of tuning tcp on cellular networks, making the
>> link layer more reliable is "the way", at the cost of more buffers and
>> latency. but now physical, link and network layer have more info for
>> the transport layer to make the right decision, e.g., starlink
>> handovers at 12th, 27th, 42nd and 57th second of every minute with
>> delay spike and losses
>> --
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>
>> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>> >
>> > Thanks for sharing this Frank.
>> >
>> > In slide 3, I think that another effect not to be missed is packet losses
>> > due to errors, which could be analogous to pipe leaks. Sometimes, it
>> > happens that they are not negligible, in some cases with wireless links,
>> > mainly, but it could happen too in DSL. I remember that I had a DSL line in
>> > which the router had the option to disable interleaving, warning that you
>> > could get more errors, bad for watching video, they were saying, but
>> > reduced latency (good for videogames). When packet losses due to errors are
>> > misinterpreted as congestion by the transport protocols, the result is also
>> > a band quality of experience.
>> >
>> > Regards,
>> >
>> > David
>> >
>> > Date: Fri, 7 Nov 2025 11:53:44 +0100
>> > > From: Frantisek Borsik <frantisek.borsik@gmail.com>
>> > > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>> > >         A Lie!  at WISPAPALOOZA 2025 (October 16)
>> > > To: Cake List <cake@lists.bufferbloat.net>, bloat
>> > >         <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>> > >         Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>> > >         <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>> > >         <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
>> > > Message-ID:
>> > >         <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
>> > > uhiQPd3KOg@mail.gmail.com>
>> > > Content-Type: text/plain; charset="UTF-8"
>> > >
>> > > 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
>> > > >>>
>> > > >>
>> > >
>> > >
>> > _______________________________________________
>> > Starlink mailing list -- starlink@lists.bufferbloat.net
>> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[Ulrich Speidel]

Starlink is a bit unusual in terms of its packet loss mechanism.

In "normal" networks, we have damaged packets (low SNR or interference 
leading to symbol errors in the modulation that then translate into bit 
errors and failing checksums), queue drops as part of the normal 
congestion control behaviour, and - not sure how much of a problem this 
still is these days - receive window overflows.

In the case of Starlink and handovers, there appears to be an uplink 
queue for uplink to each satellite on the gateway side of things. 
Suppose your dishy talks to sat A first and then gets handed over to sat 
B. Up until handover time, packets heading to your dishy get sent to the 
queue for sat A, thereafter to the queue for sat B. These queues appear 
to be different and - with different packets and different volume in 
them - seem to lead to situations when a packet addressed to you that's 
been enqueued for A hasn't reached the front of the queue by handover 
time to B. As A now no longer talks to you, this packet is now on a road 
to nowhere.

Of course, this loss only ever happens at handover time. No such thing 
as a uniform distribution here. Moreover, it's NOT a loss that should be 
interpreted as a congestion control signal to a TCP sender (or whatever 
other protocol is trying to congestion control itself, e.g., some QUIC 
implementation or somesuch).

On the latency vs. bandwidth debate: To me, this seems a bit like 
arguing whether width or height are more important for area. Both 
matter, and both are equally badly understood by marketing folk.

If your video needs to stream X Mb/s to the viewer, then the channel 
between the sender and receiver needs B > X Mb/s of available and 
accessible bandwidth. That's why bandwidth matters. Basta.

The "accessible" part of the bandwidth is where the latency comes in. 
Remember the goal is to hit bandwidth-delay product on the lowest 
bandwidth link along the forwarding chain of your packets, i.e., to make 
sure you have that bit of pipe filled. It's a lofty goal because 
whatever you do in terms of increasing or decreasing your sending rate 
only has an effect some time later, by which time the conditions you're 
trying to respond to may have changed. Your picture of the current 
conditions is always outdated (and more outdated the longer the 
latency), and just to add insult to injury, the conditions (available 
bandwidth, RTT) can also change without your control input. That change 
is among others driven by algorithms that are possibly trying to fill a 
different pipe, or has at the very least a different (time-shifted) view 
of the conditions at the pipe you're trying to fill. This is a 
fundamental control problem, not a matter of BBR over BIC or Reno or 
Vegas or whatever you've tried on ns2.

There are things that make this control problem a little easier: lower 
latency obviously, but also exclusive links (or at least fewer competing 
flows if you can't get exclusivity), fewer bandwidth bottlenecks along 
your hops and bottlenecks that are more predictable, i.e., where the 
input queues get processed at a constant processing rate. This is why 
last mile fibre and Ethernet in your home are so nice (just because you 
have your own WiFi router doesn't mean you have the channel to 
yourself). It's also why CDNs are so popular: They combine low latency 
with less competition for bandwidth and fewer hops.

Starlink's challenge is that their bandwidth per cell is limited. Not 
quite to the point where it's a problem everywhere, but certainly to the 
point where it's becoming a problem in some places. If you're being 
asked to pay a congestion surcharge when you sign up, you're in one of 
those places. Moving to fq_codel and bringing down the latency has made 
more of that bandwidth accessible, but again there's a limit to what you 
can do there - it's not like reducing latency increases total bandwidth.

On 9/11/2025 8:57 am, J Pan via Starlink wrote:
> if there are no obstructions, starlink nowadays can achieve 1% packet
> loss, often 0.1%, mostly due to satellite handover, so for the netflix
> open connect appliances inside starlink pop, they can do some
> starlink-specific optimization to mask away the handover for starlink
> users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
>> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
>>
>> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
>>
>> "now physical, link and network layer have more info for
>> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
>>
>> Regards,
>>
>> David
>>
>> On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
>>> yes, end-to-end congestion control was an add-on to tcp flow and error
>>> control, and at that time, packet loss was the only reliable
>>> congestion signal without router collaboration, and the  legacy stays.
>>> from the experience of tuning tcp on cellular networks, making the
>>> link layer more reliable is "the way", at the cost of more buffers and
>>> latency. but now physical, link and network layer have more info for
>>> the transport layer to make the right decision, e.g., starlink
>>> handovers at 12th, 27th, 42nd and 57th second of every minute with
>>> delay spike and losses
>>> --
>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>>
>>> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
>>> <starlink@lists.bufferbloat.net> wrote:
>>>> Thanks for sharing this Frank.
>>>>
>>>> In slide 3, I think that another effect not to be missed is packet losses
>>>> due to errors, which could be analogous to pipe leaks. Sometimes, it
>>>> happens that they are not negligible, in some cases with wireless links,
>>>> mainly, but it could happen too in DSL. I remember that I had a DSL line in
>>>> which the router had the option to disable interleaving, warning that you
>>>> could get more errors, bad for watching video, they were saying, but
>>>> reduced latency (good for videogames). When packet losses due to errors are
>>>> misinterpreted as congestion by the transport protocols, the result is also
>>>> a band quality of experience.
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> Date: Fri, 7 Nov 2025 11:53:44 +0100
>>>>> From: Frantisek Borsik <frantisek.borsik@gmail.com>
>>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>>>>>          A Lie!  at WISPAPALOOZA 2025 (October 16)
>>>>> To: Cake List <cake@lists.bufferbloat.net>, bloat
>>>>>          <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>>>>>          Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>>>>>          <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>>>>>          <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
>>>>> Message-ID:
>>>>>          <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
>>>>> uhiQPd3KOg@mail.gmail.com>
>>>>> Content-Type: text/plain; charset="UTF-8"
>>>>>
>>>>> 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
>>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[J Pan]

starlink can use bicast to reduce handover loss, especially for the
downlink to the user terminal, but there are still handover delay
spike and packet loss, especially for the uplink as well
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Sat, Nov 8, 2025 at 5:04 PM Ulrich Speidel via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> Starlink is a bit unusual in terms of its packet loss mechanism.
>
> In "normal" networks, we have damaged packets (low SNR or interference
> leading to symbol errors in the modulation that then translate into bit
> errors and failing checksums), queue drops as part of the normal
> congestion control behaviour, and - not sure how much of a problem this
> still is these days - receive window overflows.
>
> In the case of Starlink and handovers, there appears to be an uplink
> queue for uplink to each satellite on the gateway side of things.
> Suppose your dishy talks to sat A first and then gets handed over to sat
> B. Up until handover time, packets heading to your dishy get sent to the
> queue for sat A, thereafter to the queue for sat B. These queues appear
> to be different and - with different packets and different volume in
> them - seem to lead to situations when a packet addressed to you that's
> been enqueued for A hasn't reached the front of the queue by handover
> time to B. As A now no longer talks to you, this packet is now on a road
> to nowhere.
>
> Of course, this loss only ever happens at handover time. No such thing
> as a uniform distribution here. Moreover, it's NOT a loss that should be
> interpreted as a congestion control signal to a TCP sender (or whatever
> other protocol is trying to congestion control itself, e.g., some QUIC
> implementation or somesuch).
>
> On the latency vs. bandwidth debate: To me, this seems a bit like
> arguing whether width or height are more important for area. Both
> matter, and both are equally badly understood by marketing folk.
>
> If your video needs to stream X Mb/s to the viewer, then the channel
> between the sender and receiver needs B > X Mb/s of available and
> accessible bandwidth. That's why bandwidth matters. Basta.
>
> The "accessible" part of the bandwidth is where the latency comes in.
> Remember the goal is to hit bandwidth-delay product on the lowest
> bandwidth link along the forwarding chain of your packets, i.e., to make
> sure you have that bit of pipe filled. It's a lofty goal because
> whatever you do in terms of increasing or decreasing your sending rate
> only has an effect some time later, by which time the conditions you're
> trying to respond to may have changed. Your picture of the current
> conditions is always outdated (and more outdated the longer the
> latency), and just to add insult to injury, the conditions (available
> bandwidth, RTT) can also change without your control input. That change
> is among others driven by algorithms that are possibly trying to fill a
> different pipe, or has at the very least a different (time-shifted) view
> of the conditions at the pipe you're trying to fill. This is a
> fundamental control problem, not a matter of BBR over BIC or Reno or
> Vegas or whatever you've tried on ns2.
>
> There are things that make this control problem a little easier: lower
> latency obviously, but also exclusive links (or at least fewer competing
> flows if you can't get exclusivity), fewer bandwidth bottlenecks along
> your hops and bottlenecks that are more predictable, i.e., where the
> input queues get processed at a constant processing rate. This is why
> last mile fibre and Ethernet in your home are so nice (just because you
> have your own WiFi router doesn't mean you have the channel to
> yourself). It's also why CDNs are so popular: They combine low latency
> with less competition for bandwidth and fewer hops.
>
> Starlink's challenge is that their bandwidth per cell is limited. Not
> quite to the point where it's a problem everywhere, but certainly to the
> point where it's becoming a problem in some places. If you're being
> asked to pay a congestion surcharge when you sign up, you're in one of
> those places. Moving to fq_codel and bringing down the latency has made
> more of that bandwidth accessible, but again there's a limit to what you
> can do there - it's not like reducing latency increases total bandwidth.
>
> On 9/11/2025 8:57 am, J Pan via Starlink wrote:
> > if there are no obstructions, starlink nowadays can achieve 1% packet
> > loss, often 0.1%, mostly due to satellite handover, so for the netflix
> > open connect appliances inside starlink pop, they can do some
> > starlink-specific optimization to mask away the handover for starlink
> > users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
> > --
> > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> >
> > On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
> >> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
> >>
> >> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
> >>
> >> "now physical, link and network layer have more info for
> >> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
> >>
> >> Regards,
> >>
> >> David
> >>
> >> On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
> >>> yes, end-to-end congestion control was an add-on to tcp flow and error
> >>> control, and at that time, packet loss was the only reliable
> >>> congestion signal without router collaboration, and the  legacy stays.
> >>> from the experience of tuning tcp on cellular networks, making the
> >>> link layer more reliable is "the way", at the cost of more buffers and
> >>> latency. but now physical, link and network layer have more info for
> >>> the transport layer to make the right decision, e.g., starlink
> >>> handovers at 12th, 27th, 42nd and 57th second of every minute with
> >>> delay spike and losses
> >>> --
> >>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> >>>
> >>> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
> >>> <starlink@lists.bufferbloat.net> wrote:
> >>>> Thanks for sharing this Frank.
> >>>>
> >>>> In slide 3, I think that another effect not to be missed is packet losses
> >>>> due to errors, which could be analogous to pipe leaks. Sometimes, it
> >>>> happens that they are not negligible, in some cases with wireless links,
> >>>> mainly, but it could happen too in DSL. I remember that I had a DSL line in
> >>>> which the router had the option to disable interleaving, warning that you
> >>>> could get more errors, bad for watching video, they were saying, but
> >>>> reduced latency (good for videogames). When packet losses due to errors are
> >>>> misinterpreted as congestion by the transport protocols, the result is also
> >>>> a band quality of experience.
> >>>>
> >>>> Regards,
> >>>>
> >>>> David
> >>>>
> >>>> Date: Fri, 7 Nov 2025 11:53:44 +0100
> >>>>> From: Frantisek Borsik <frantisek.borsik@gmail.com>
> >>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
> >>>>>          A Lie!  at WISPAPALOOZA 2025 (October 16)
> >>>>> To: Cake List <cake@lists.bufferbloat.net>, bloat
> >>>>>          <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
> >>>>>          Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
> >>>>>          <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
> >>>>>          <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
> >>>>> Message-ID:
> >>>>>          <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
> >>>>> uhiQPd3KOg@mail.gmail.com>
> >>>>> Content-Type: text/plain; charset="UTF-8"
> >>>>>
> >>>>> 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
> >>>>>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Starlink mailing list -- starlink@lists.bufferbloat.net
> >>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[David Fernández]

Interesting, so this use of StarQUIC somehow reminds me of the use of
PEPs in GEO satellites, breaking the end to end TCP connection and
using SCPS-TP between the satellite terminal and the gateway, to
overcome the issues with higher propagation latency.

Certainly, if you control the servers and the clients as Netflix may
do, with a particular app, instead of a generic browser, you can tune
the transport protocol to adapt to anything happening in lower layers,
and QUIC is highly customizable, being in user space.


On Sat, 8 Nov 2025 at 20:57, J Pan <Pan@uvic.ca> wrote:
>
> if there are no obstructions, starlink nowadays can achieve 1% packet
> loss, often 0.1%, mostly due to satellite handover, so for the netflix
> open connect appliances inside starlink pop, they can do some
> starlink-specific optimization to mask away the handover for starlink
> users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
> >
> > "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
> >
> > Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
> >
> > "now physical, link and network layer have more info for
> > the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
> >
> > Regards,
> >
> > David
> >
> > On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
> >>
> >> yes, end-to-end congestion control was an add-on to tcp flow and error
> >> control, and at that time, packet loss was the only reliable
> >> congestion signal without router collaboration, and the  legacy stays.
> >> from the experience of tuning tcp on cellular networks, making the
> >> link layer more reliable is "the way", at the cost of more buffers and
> >> latency. but now physical, link and network layer have more info for
> >> the transport layer to make the right decision, e.g., starlink
> >> handovers at 12th, 27th, 42nd and 57th second of every minute with
> >> delay spike and losses
> >> --
> >> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> >>
> >> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
> >> <starlink@lists.bufferbloat.net> wrote:
> >> >
> >> > Thanks for sharing this Frank.
> >> >
> >> > In slide 3, I think that another effect not to be missed is packet losses
> >> > due to errors, which could be analogous to pipe leaks. Sometimes, it
> >> > happens that they are not negligible, in some cases with wireless links,
> >> > mainly, but it could happen too in DSL. I remember that I had a DSL line in
> >> > which the router had the option to disable interleaving, warning that you
> >> > could get more errors, bad for watching video, they were saying, but
> >> > reduced latency (good for videogames). When packet losses due to errors are
> >> > misinterpreted as congestion by the transport protocols, the result is also
> >> > a band quality of experience.
> >> >
> >> > Regards,
> >> >
> >> > David
> >> >
> >> > Date: Fri, 7 Nov 2025 11:53:44 +0100
> >> > > From: Frantisek Borsik <frantisek.borsik@gmail.com>
> >> > > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
> >> > >         A Lie!  at WISPAPALOOZA 2025 (October 16)
> >> > > To: Cake List <cake@lists.bufferbloat.net>, bloat
> >> > >         <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
> >> > >         Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
> >> > >         <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
> >> > >         <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
> >> > > Message-ID:
> >> > >         <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
> >> > > uhiQPd3KOg@mail.gmail.com>
> >> > > Content-Type: text/plain; charset="UTF-8"
> >> > >
> >> > > 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
> >> > > >>>
> >> > > >>
> >> > >
> >> > >
> >> > _______________________________________________
> >> > Starlink mailing list -- starlink@lists.bufferbloat.net
> >> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[J Pan]

yes, starquic is a sender-only fix to address the regular handover in
starlink, especially for the downlink from the netflix oca in the
starlink pop toward the user dish for video streaming
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Sun, Nov 9, 2025 at 7:45 AM David Fernández <davidfdzp@gmail.com> wrote:
>
> Interesting, so this use of StarQUIC somehow reminds me of the use of
> PEPs in GEO satellites, breaking the end to end TCP connection and
> using SCPS-TP between the satellite terminal and the gateway, to
> overcome the issues with higher propagation latency.
>
> Certainly, if you control the servers and the clients as Netflix may
> do, with a particular app, instead of a generic browser, you can tune
> the transport protocol to adapt to anything happening in lower layers,
> and QUIC is highly customizable, being in user space.
>
>
> On Sat, 8 Nov 2025 at 20:57, J Pan <Pan@uvic.ca> wrote:
> >
> > if there are no obstructions, starlink nowadays can achieve 1% packet
> > loss, often 0.1%, mostly due to satellite handover, so for the netflix
> > open connect appliances inside starlink pop, they can do some
> > starlink-specific optimization to mask away the handover for starlink
> > users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
> > --
> > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> >
> > On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
> > >
> > > "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
> > >
> > > Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
> > >
> > > "now physical, link and network layer have more info for
> > > the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
> > >
> > > Regards,
> > >
> > > David
> > >
> > > On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
> > >>
> > >> yes, end-to-end congestion control was an add-on to tcp flow and error
> > >> control, and at that time, packet loss was the only reliable
> > >> congestion signal without router collaboration, and the  legacy stays.
> > >> from the experience of tuning tcp on cellular networks, making the
> > >> link layer more reliable is "the way", at the cost of more buffers and
> > >> latency. but now physical, link and network layer have more info for
> > >> the transport layer to make the right decision, e.g., starlink
> > >> handovers at 12th, 27th, 42nd and 57th second of every minute with
> > >> delay spike and losses
> > >> --
> > >> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> > >>
> > >> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
> > >> <starlink@lists.bufferbloat.net> wrote:
> > >> >
> > >> > Thanks for sharing this Frank.
> > >> >
> > >> > In slide 3, I think that another effect not to be missed is packet losses
> > >> > due to errors, which could be analogous to pipe leaks. Sometimes, it
> > >> > happens that they are not negligible, in some cases with wireless links,
> > >> > mainly, but it could happen too in DSL. I remember that I had a DSL line in
> > >> > which the router had the option to disable interleaving, warning that you
> > >> > could get more errors, bad for watching video, they were saying, but
> > >> > reduced latency (good for videogames). When packet losses due to errors are
> > >> > misinterpreted as congestion by the transport protocols, the result is also
> > >> > a band quality of experience.
> > >> >
> > >> > Regards,
> > >> >
> > >> > David
> > >> >
> > >> > Date: Fri, 7 Nov 2025 11:53:44 +0100
> > >> > > From: Frantisek Borsik <frantisek.borsik@gmail.com>
> > >> > > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
> > >> > >         A Lie!  at WISPAPALOOZA 2025 (October 16)
> > >> > > To: Cake List <cake@lists.bufferbloat.net>, bloat
> > >> > >         <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
> > >> > >         Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
> > >> > >         <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
> > >> > >         <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
> > >> > > Message-ID:
> > >> > >         <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
> > >> > > uhiQPd3KOg@mail.gmail.com>
> > >> > > Content-Type: text/plain; charset="UTF-8"
> > >> > >
> > >> > > 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
> > >> > > >>>
> > >> > > >>
> > >> > >
> > >> > >
> > >> > _______________________________________________
> > >> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > >> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[Sebastian Moeller]

Hi Ulrich,


> On 9. Nov 2025, at 02:03, Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Starlink is a bit unusual in terms of its packet loss mechanism.
> 
> In "normal" networks, we have damaged packets (low SNR or interference leading to symbol errors in the modulation that then translate into bit errors and failing checksums), queue drops as part of the normal congestion control behaviour, and - not sure how much of a problem this still is these days - receive window overflows.
> 
> In the case of Starlink and handovers, there appears to be an uplink queue for uplink to each satellite on the gateway side of things. Suppose your dishy talks to sat A first and then gets handed over to sat B. Up until handover time, packets heading to your dishy get sent to the queue for sat A, thereafter to the queue for sat B. These queues appear to be different and - with different packets and different volume in them - seem to lead to situations when a packet addressed to you that's been enqueued for A hasn't reached the front of the queue by handover time to B. As A now no longer talks to you, this packet is now on a road to nowhere.
> 
> Of course, this loss only ever happens at handover time. No such thing as a uniform distribution here. Moreover, it's NOT a loss that should be interpreted as a congestion control signal to a TCP sender (or whatever other protocol is trying to congestion control itself, e.g., some QUIC implementation or somesuch).
> 
> On the latency vs. bandwidth debate: To me, this seems a bit like arguing whether width or height are more important for area. Both matter, and both are equally badly understood by marketing folk.
> 
> If your video needs to stream X Mb/s to the viewer, then the channel between the sender and receiver needs B > X Mb/s of available and accessible bandwidth. That's why bandwidth matters. Basta.

Well, you are of course right. However for almost all interactive use-cases the capacity that is actually usable by an application (and where less capacity results in noticeably worse results, while more capacity does not increase the perceived quality any more) is well below the access capacities that are sold.
For example page load times do generally not improve once the capacity exceeds 20-25 Mbps, FullHD streaming needs 5-8 Mbps, 4K streaming (still rare) 15-20 Mbps, videoconferencing typically also needs less than 20 Mbps, and traditional VoIP only takes around 100 Kbps (per direction)... even cloud gaming at high spatial and temporal resolutions (with short time windows to compress the video) only requires more than 65 Mbps (for 5K@120 Hz). And remote desktop is quite mild
So if we are generous and/or want to allow multiple concurrent users 50-100 Mbps is the capacity that will cover most typical interactive use-cases quite well. And at that point halving the latency will result in a bigger improvement than doubling the capacity... (I like your area model conceptually, yet increasing latency does not improve things, reducing does).


> 
> The "accessible" part of the bandwidth is where the latency comes in. Remember the goal is to hit bandwidth-delay product on the lowest bandwidth link along the forwarding chain of your packets, i.e., to make sure you have that bit of pipe filled. It's a lofty goal because whatever you do in terms of increasing or decreasing your sending rate only has an effect some time later, by which time the conditions you're trying to respond to may have changed. Your picture of the current conditions is always outdated (and more outdated the longer the latency), and just to add insult to injury, the conditions (available bandwidth, RTT) can also change without your control input. That change is among others driven by algorithms that are possibly trying to fill a different pipe, or has at the very least a different (time-shifted) view of the conditions at the pipe you're trying to fill. This is a fundamental control problem, not a matter of BBR over BIC or Reno or Vegas or whatever you've tried on ns2.
> 
> There are things that make this control problem a little easier: lower latency obviously, but also exclusive links (or at least fewer competing flows if you can't get exclusivity), fewer bandwidth bottlenecks along your hops and bottlenecks that are more predictable, i.e., where the input queues get processed at a constant processing rate. This is why last mile fibre and Ethernet in your home are so nice (just because you have your own WiFi router doesn't mean you have the channel to yourself). It's also why CDNs are so popular: They combine low latency with less competition for bandwidth and fewer hops.
> 
> Starlink's challenge is that their bandwidth per cell is limited. Not quite to the point where it's a problem everywhere, but certainly to the point where it's becoming a problem in some places. If you're being asked to pay a congestion surcharge when you sign up, you're in one of those places. Moving to fq_codel and bringing down the latency has made more of that bandwidth accessible, but again there's a limit to what you can do there - it's not like reducing latency increases total bandwidth.

True, yet proper scheduling and AQM makes links that operate around saturation point still quite usable even for interactive use-cases.


> 
> On 9/11/2025 8:57 am, J Pan via Starlink wrote:
>> if there are no obstructions, starlink nowadays can achieve 1% packet
>> loss, often 0.1%, mostly due to satellite handover, so for the netflix
>> open connect appliances inside starlink pop, they can do some
>> starlink-specific optimization to mask away the handover for starlink
>> users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
>> --
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>> 
>> On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
>>> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
>>> 
>>> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
>>> 
>>> "now physical, link and network layer have more info for
>>> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
>>> 
>>> Regards,
>>> 
>>> David
>>> 
>>> On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
>>>> yes, end-to-end congestion control was an add-on to tcp flow and error
>>>> control, and at that time, packet loss was the only reliable
>>>> congestion signal without router collaboration, and the  legacy stays.
>>>> from the experience of tuning tcp on cellular networks, making the
>>>> link layer more reliable is "the way", at the cost of more buffers and
>>>> latency. but now physical, link and network layer have more info for
>>>> the transport layer to make the right decision, e.g., starlink
>>>> handovers at 12th, 27th, 42nd and 57th second of every minute with
>>>> delay spike and losses
>>>> --
>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>>> 
>>>> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
>>>> <starlink@lists.bufferbloat.net> wrote:
>>>>> Thanks for sharing this Frank.
>>>>> 
>>>>> In slide 3, I think that another effect not to be missed is packet losses
>>>>> due to errors, which could be analogous to pipe leaks. Sometimes, it
>>>>> happens that they are not negligible, in some cases with wireless links,
>>>>> mainly, but it could happen too in DSL. I remember that I had a DSL line in
>>>>> which the router had the option to disable interleaving, warning that you
>>>>> could get more errors, bad for watching video, they were saying, but
>>>>> reduced latency (good for videogames). When packet losses due to errors are
>>>>> misinterpreted as congestion by the transport protocols, the result is also
>>>>> a band quality of experience.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> David
>>>>> 
>>>>> Date: Fri, 7 Nov 2025 11:53:44 +0100
>>>>>> From: Frantisek Borsik <frantisek.borsik@gmail.com>
>>>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>>>>>>         A Lie!  at WISPAPALOOZA 2025 (October 16)
>>>>>> To: Cake List <cake@lists.bufferbloat.net>, bloat
>>>>>>         <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>>>>>>         Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>>>>>>         <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>>>>>>         <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
>>>>>> Message-ID:
>>>>>>         <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
>>>>>> uhiQPd3KOg@mail.gmail.com>
>>>>>> Content-Type: text/plain; charset="UTF-8"
>>>>>> 
>>>>>> 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
>>>>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>> _______________________________________________
>> Starlink mailing list -- starlink@lists.bufferbloat.net
>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> 
> -- 
> ****************************************************************
> Dr. Ulrich Speidel
> 
> School of Computer Science
> 
> Room 303S.594 (City Campus)
> 
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
> 
> 
> 
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[Ulrich Speidel]

But what does bicast mean? It means sending a packet to both queues - 
the one for sat A and the one for sat B, right?

Let's assume that time of handover is when Dishy switches its beam over. 
Then for a packet from sat A to reach it, that packet needs to make it 
to the front of the TX queue for sat A a minimum of L_a ms before 
handover time to allow for transit delay to Dishy.

Then we have the following possible scenarios:

  * The packet reaches the front of the queue for sat A before the
    handover and gets transmitted to sat A, and from there to Dishy.
    Then the packet that's in the queue for sat B is surplus to
    requirements. But does it get removed? If not, it needlessly takes
    up capacity needlessly (=introduces delay) on sat B. But that could
    be solved I guess, as long as handover is to/from the same gateway.
  * The packet is still in both queues by the time of handover. Then we
    don't get packet loss, but the packet in queue for sat A is now
    also surplus to requirements. But does it get removed? If not, it
    needlessly takes up capacity on sat B.
  * The packet reaches the front of the queue for sat B more than L_a
    ms before the handover, but there's no client there yet to transmit
    it to. What does Starlink do with that packet? If it drops the
    packet, it risks that the packet in queue for sat A won't make it to
    the front of that queue in time.

The list isn't complete but it shows that bicast alone isn't a fix.

You could however look at the expected queue sojourn time in each queue 
as well as the expected propagation delay to Dishy and then shove the 
packet into the queue that it needs to be in. But maybe that's not 
happening yet?

On 9/11/2025 6:08 pm, J Pan wrote:
> starlink can use bicast to reduce handover loss, especially for the
> downlink to the user terminal, but there are still handover delay
> spike and packet loss, especially for the uplink as well
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM),Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Sat, Nov 8, 2025 at 5:04 PM Ulrich Speidel via Starlink
> <starlink@lists.bufferbloat.net> wrote:
>> Starlink is a bit unusual in terms of its packet loss mechanism.
>>
>> In "normal" networks, we have damaged packets (low SNR or interference
>> leading to symbol errors in the modulation that then translate into bit
>> errors and failing checksums), queue drops as part of the normal
>> congestion control behaviour, and - not sure how much of a problem this
>> still is these days - receive window overflows.
>>
>> In the case of Starlink and handovers, there appears to be an uplink
>> queue for uplink to each satellite on the gateway side of things.
>> Suppose your dishy talks to sat A first and then gets handed over to sat
>> B. Up until handover time, packets heading to your dishy get sent to the
>> queue for sat A, thereafter to the queue for sat B. These queues appear
>> to be different and - with different packets and different volume in
>> them - seem to lead to situations when a packet addressed to you that's
>> been enqueued for A hasn't reached the front of the queue by handover
>> time to B. As A now no longer talks to you, this packet is now on a road
>> to nowhere.
>>
>> Of course, this loss only ever happens at handover time. No such thing
>> as a uniform distribution here. Moreover, it's NOT a loss that should be
>> interpreted as a congestion control signal to a TCP sender (or whatever
>> other protocol is trying to congestion control itself, e.g., some QUIC
>> implementation or somesuch).
>>
>> On the latency vs. bandwidth debate: To me, this seems a bit like
>> arguing whether width or height are more important for area. Both
>> matter, and both are equally badly understood by marketing folk.
>>
>> If your video needs to stream X Mb/s to the viewer, then the channel
>> between the sender and receiver needs B > X Mb/s of available and
>> accessible bandwidth. That's why bandwidth matters. Basta.
>>
>> The "accessible" part of the bandwidth is where the latency comes in.
>> Remember the goal is to hit bandwidth-delay product on the lowest
>> bandwidth link along the forwarding chain of your packets, i.e., to make
>> sure you have that bit of pipe filled. It's a lofty goal because
>> whatever you do in terms of increasing or decreasing your sending rate
>> only has an effect some time later, by which time the conditions you're
>> trying to respond to may have changed. Your picture of the current
>> conditions is always outdated (and more outdated the longer the
>> latency), and just to add insult to injury, the conditions (available
>> bandwidth, RTT) can also change without your control input. That change
>> is among others driven by algorithms that are possibly trying to fill a
>> different pipe, or has at the very least a different (time-shifted) view
>> of the conditions at the pipe you're trying to fill. This is a
>> fundamental control problem, not a matter of BBR over BIC or Reno or
>> Vegas or whatever you've tried on ns2.
>>
>> There are things that make this control problem a little easier: lower
>> latency obviously, but also exclusive links (or at least fewer competing
>> flows if you can't get exclusivity), fewer bandwidth bottlenecks along
>> your hops and bottlenecks that are more predictable, i.e., where the
>> input queues get processed at a constant processing rate. This is why
>> last mile fibre and Ethernet in your home are so nice (just because you
>> have your own WiFi router doesn't mean you have the channel to
>> yourself). It's also why CDNs are so popular: They combine low latency
>> with less competition for bandwidth and fewer hops.
>>
>> Starlink's challenge is that their bandwidth per cell is limited. Not
>> quite to the point where it's a problem everywhere, but certainly to the
>> point where it's becoming a problem in some places. If you're being
>> asked to pay a congestion surcharge when you sign up, you're in one of
>> those places. Moving to fq_codel and bringing down the latency has made
>> more of that bandwidth accessible, but again there's a limit to what you
>> can do there - it's not like reducing latency increases total bandwidth.
>>
>> On 9/11/2025 8:57 am, J Pan via Starlink wrote:
>>> if there are no obstructions, starlink nowadays can achieve 1% packet
>>> loss, often 0.1%, mostly due to satellite handover, so for the netflix
>>> open connect appliances inside starlink pop, they can do some
>>> starlink-specific optimization to mask away the handover for starlink
>>> users, e.g.,https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
>>> --
>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM),Pan@UVic.CA, Web.UVic.CA/~pan
>>>
>>> On Sat, Nov 8, 2025 at 11:12 AM David Fernández<davidfdzp@gmail.com> wrote:
>>>> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
>>>>
>>>> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
>>>>
>>>> "now physical, link and network layer have more info for
>>>> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> On Sat, 8 Nov 2025, 22:30 J Pan,<Pan@uvic.ca> wrote:
>>>>> yes, end-to-end congestion control was an add-on to tcp flow and error
>>>>> control, and at that time, packet loss was the only reliable
>>>>> congestion signal without router collaboration, and the  legacy stays.
>>>>> from the experience of tuning tcp on cellular networks, making the
>>>>> link layer more reliable is "the way", at the cost of more buffers and
>>>>> latency. but now physical, link and network layer have more info for
>>>>> the transport layer to make the right decision, e.g., starlink
>>>>> handovers at 12th, 27th, 42nd and 57th second of every minute with
>>>>> delay spike and losses
>>>>> --
>>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM),Pan@UVic.CA, Web.UVic.CA/~pan
>>>>>
>>>>> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
>>>>> <starlink@lists.bufferbloat.net> wrote:
>>>>>> Thanks for sharing this Frank.
>>>>>>
>>>>>> In slide 3, I think that another effect not to be missed is packet losses
>>>>>> due to errors, which could be analogous to pipe leaks. Sometimes, it
>>>>>> happens that they are not negligible, in some cases with wireless links,
>>>>>> mainly, but it could happen too in DSL. I remember that I had a DSL line in
>>>>>> which the router had the option to disable interleaving, warning that you
>>>>>> could get more errors, bad for watching video, they were saying, but
>>>>>> reduced latency (good for videogames). When packet losses due to errors are
>>>>>> misinterpreted as congestion by the transport protocols, the result is also
>>>>>> a band quality of experience.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> Date: Fri, 7 Nov 2025 11:53:44 +0100
>>>>>>> From: Frantisek Borsik<frantisek.borsik@gmail.com>
>>>>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>>>>>>>           A Lie!  at WISPAPALOOZA 2025 (October 16)
>>>>>>> To: Cake List<cake@lists.bufferbloat.net>, bloat
>>>>>>>           <bloat@lists.bufferbloat.net>,codel@lists.bufferbloat.net,
>>>>>>>           Jeremy Austin via Rpm<rpm@lists.bufferbloat.net>, libreqos
>>>>>>>           <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>>>>>>>           <starlink@lists.bufferbloat.net>,l4s-discuss@ietf.org
>>>>>>> Message-ID:
>>>>>>>           <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
>>>>>>> uhiQPd3KOg@mail.gmail.com>
>>>>>>> Content-Type: text/plain; charset="UTF-8"
>>>>>>>
>>>>>>> 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 tolibreqos-leave@lists.bufferbloat.net
>>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Starlink mailing list --starlink@lists.bufferbloat.net
>>>>>> To unsubscribe send an email tostarlink-leave@lists.bufferbloat.net
>>> _______________________________________________
>>> Starlink mailing list --starlink@lists.bufferbloat.net
>>> To unsubscribe send an email tostarlink-leave@lists.bufferbloat.net
>> --
>> ****************************************************************
>> Dr. Ulrich Speidel
>>
>> School of Computer Science
>>
>> Room 303S.594 (City Campus)
>>
>> The University of Auckland
>> u.speidel@auckland.ac.nz
>> http://www.cs.auckland.ac.nz/~ulrich/
>> ****************************************************************
>>
>>
>>
>> _______________________________________________
>> Starlink mailing list --starlink@lists.bufferbloat.net
>> To unsubscribe send an email tostarlink-leave@lists.bufferbloat.net

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz 
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[Ulrich Speidel]

On 10/11/2025 7:42 am, Sebastian Moeller wrote:
> Hi Ulrich,
>
>
>> On 9. Nov 2025, at 02:03, Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
>>
>> Starlink is a bit unusual in terms of its packet loss mechanism.
>>
>> In "normal" networks, we have damaged packets (low SNR or interference leading to symbol errors in the modulation that then translate into bit errors and failing checksums), queue drops as part of the normal congestion control behaviour, and - not sure how much of a problem this still is these days - receive window overflows.
>>
>> In the case of Starlink and handovers, there appears to be an uplink queue for uplink to each satellite on the gateway side of things. Suppose your dishy talks to sat A first and then gets handed over to sat B. Up until handover time, packets heading to your dishy get sent to the queue for sat A, thereafter to the queue for sat B. These queues appear to be different and - with different packets and different volume in them - seem to lead to situations when a packet addressed to you that's been enqueued for A hasn't reached the front of the queue by handover time to B. As A now no longer talks to you, this packet is now on a road to nowhere.
>>
>> Of course, this loss only ever happens at handover time. No such thing as a uniform distribution here. Moreover, it's NOT a loss that should be interpreted as a congestion control signal to a TCP sender (or whatever other protocol is trying to congestion control itself, e.g., some QUIC implementation or somesuch).
>>
>> On the latency vs. bandwidth debate: To me, this seems a bit like arguing whether width or height are more important for area. Both matter, and both are equally badly understood by marketing folk.
>>
>> If your video needs to stream X Mb/s to the viewer, then the channel between the sender and receiver needs B > X Mb/s of available and accessible bandwidth. That's why bandwidth matters. Basta.
> Well, you are of course right. However for almost all interactive use-cases the capacity that is actually usable by an application (and where less capacity results in noticeably worse results, while more capacity does not increase the perceived quality any more) is well below the access capacities that are sold.
> For example page load times do generally not improve once the capacity exceeds 20-25 Mbps, FullHD streaming needs 5-8 Mbps, 4K streaming (still rare) 15-20 Mbps, videoconferencing typically also needs less than 20 Mbps, and traditional VoIP only takes around 100 Kbps (per direction)... even cloud gaming at high spatial and temporal resolutions (with short time windows to compress the video) only requires more than 65 Mbps (for 5K@120 Hz). And remote desktop is quite mild
> So if we are generous and/or want to allow multiple concurrent users 50-100 Mbps is the capacity that will cover most typical interactive use-cases quite well. And at that point halving the latency will result in a bigger improvement than doubling the capacity...

It boils down to the "available and accessible" bit. There are various 
reasons for why an application may not be able to access bandwidth even 
though it is available. And that can even be the case when you average 
over a large number of users.

When we looked into the first MEO link into the Cook Islands 10 years 
ago, we found that the local ISP wasn't ever seeing more than 50% 
bandwidth utilisation on their international link, yet the locals were 
quick to complain about the service. A lot of finger pointing went on 
but the culprit was actually TCP congestion control over a long latency 
bandwidth bottleneck. The ISP's monitoring tool looked at average 
bandwidth utilisation over a time period of many RTTs, which masked the 
fact that the input queue to their sat link was oscillating between 
tsunami and drought conditions. The bandwidth that was available after 
everyone had backed off wasn't accessible.

> (I like your area model conceptually, yet increasing latency does not improve things, reducing does).
Yes, that's taken as read I guess ;-)
>
>
>> The "accessible" part of the bandwidth is where the latency comes in. Remember the goal is to hit bandwidth-delay product on the lowest bandwidth link along the forwarding chain of your packets, i.e., to make sure you have that bit of pipe filled. It's a lofty goal because whatever you do in terms of increasing or decreasing your sending rate only has an effect some time later, by which time the conditions you're trying to respond to may have changed. Your picture of the current conditions is always outdated (and more outdated the longer the latency), and just to add insult to injury, the conditions (available bandwidth, RTT) can also change without your control input. That change is among others driven by algorithms that are possibly trying to fill a different pipe, or has at the very least a different (time-shifted) view of the conditions at the pipe you're trying to fill. This is a fundamental control problem, not a matter of BBR over BIC or Reno or Vegas or whatever you've tried on ns2.
>>
>> There are things that make this control problem a little easier: lower latency obviously, but also exclusive links (or at least fewer competing flows if you can't get exclusivity), fewer bandwidth bottlenecks along your hops and bottlenecks that are more predictable, i.e., where the input queues get processed at a constant processing rate. This is why last mile fibre and Ethernet in your home are so nice (just because you have your own WiFi router doesn't mean you have the channel to yourself). It's also why CDNs are so popular: They combine low latency with less competition for bandwidth and fewer hops.
>>
>> Starlink's challenge is that their bandwidth per cell is limited. Not quite to the point where it's a problem everywhere, but certainly to the point where it's becoming a problem in some places. If you're being asked to pay a congestion surcharge when you sign up, you're in one of those places. Moving to fq_codel and bringing down the latency has made more of that bandwidth accessible, but again there's a limit to what you can do there - it's not like reducing latency increases total bandwidth.
> True, yet proper scheduling and AQM makes links that operate around saturation point still quite usable even for interactive use-cases.
I'm not arguing with this - but there's a short distance between "around 
saturation point" and "beyond saturation point".
>
>
>> On 9/11/2025 8:57 am, J Pan via Starlink wrote:
>>> if there are no obstructions, starlink nowadays can achieve 1% packet
>>> loss, often 0.1%, mostly due to satellite handover, so for the netflix
>>> open connect appliances inside starlink pop, they can do some
>>> starlink-specific optimization to mask away the handover for starlink
>>> users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
>>> --
>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>>
>>> On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
>>>> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
>>>>
>>>> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
>>>>
>>>> "now physical, link and network layer have more info for
>>>> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
>>>>> yes, end-to-end congestion control was an add-on to tcp flow and error
>>>>> control, and at that time, packet loss was the only reliable
>>>>> congestion signal without router collaboration, and the  legacy stays.
>>>>> from the experience of tuning tcp on cellular networks, making the
>>>>> link layer more reliable is "the way", at the cost of more buffers and
>>>>> latency. but now physical, link and network layer have more info for
>>>>> the transport layer to make the right decision, e.g., starlink
>>>>> handovers at 12th, 27th, 42nd and 57th second of every minute with
>>>>> delay spike and losses
>>>>> --
>>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>>>>
>>>>> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
>>>>> <starlink@lists.bufferbloat.net> wrote:
>>>>>> Thanks for sharing this Frank.
>>>>>>
>>>>>> In slide 3, I think that another effect not to be missed is packet losses
>>>>>> due to errors, which could be analogous to pipe leaks. Sometimes, it
>>>>>> happens that they are not negligible, in some cases with wireless links,
>>>>>> mainly, but it could happen too in DSL. I remember that I had a DSL line in
>>>>>> which the router had the option to disable interleaving, warning that you
>>>>>> could get more errors, bad for watching video, they were saying, but
>>>>>> reduced latency (good for videogames). When packet losses due to errors are
>>>>>> misinterpreted as congestion by the transport protocols, the result is also
>>>>>> a band quality of experience.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> Date: Fri, 7 Nov 2025 11:53:44 +0100
>>>>>>> From: Frantisek Borsik <frantisek.borsik@gmail.com>
>>>>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>>>>>>>          A Lie!  at WISPAPALOOZA 2025 (October 16)
>>>>>>> To: Cake List <cake@lists.bufferbloat.net>, bloat
>>>>>>>          <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>>>>>>>          Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>>>>>>>          <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>>>>>>>          <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
>>>>>>> Message-ID:
>>>>>>>          <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
>>>>>>> uhiQPd3KOg@mail.gmail.com>
>>>>>>> Content-Type: text/plain; charset="UTF-8"
>>>>>>>
>>>>>>> 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
>>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>>>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>>> _______________________________________________
>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>> -- 
>> ****************************************************************
>> Dr. Ulrich Speidel
>>
>> School of Computer Science
>>
>> Room 303S.594 (City Campus)
>>
>> The University of Auckland
>> u.speidel@auckland.ac.nz
>> http://www.cs.auckland.ac.nz/~ulrich/
>> ****************************************************************
>>
>>
>>
>> _______________________________________________
>> Starlink mailing list -- starlink@lists.bufferbloat.net
>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[J Pan]

bicast is starlink's terminology. it just reduces but does not
eliminate packet loss, and it introduces duplicate packets too as we
observed. hope to do more measurement with wayne too
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Sun, Nov 9, 2025 at 11:51 AM Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
>
> But what does bicast mean? It means sending a packet to both queues - the one for sat A and the one for sat B, right?
>
> Let's assume that time of handover is when Dishy switches its beam over. Then for a packet from sat A to reach it, that packet needs to make it to the front of the TX queue for sat A a minimum of L_a ms before handover time to allow for transit delay to Dishy.
>
> Then we have the following possible scenarios:
>
> The packet reaches the front of the queue for sat A before the handover and gets transmitted to sat A, and from there to Dishy. Then the packet that's in the queue for sat B is surplus to requirements. But does it get removed? If not, it needlessly takes up capacity needlessly (=introduces delay) on sat B. But that could be solved I guess, as long as handover is to/from the same gateway.
> The packet is still in both queues by the time of handover. Then we don't get packet loss, but the packet in queue for sat A is now also surplus to requirements. But does it get removed? If not, it needlessly takes up capacity on sat B.
> The packet reaches the front of the queue for sat B more than L_a ms before the handover, but there's no client there yet to transmit it to. What does Starlink do with that packet? If it drops the packet, it risks that the packet in queue for sat A won't make it to the front of that queue in time.
>
> The list isn't complete but it shows that bicast alone isn't a fix.
>
> You could however look at the expected queue sojourn time in each queue as well as the expected propagation delay to Dishy and then shove the packet into the queue that it needs to be in. But maybe that's not happening yet?
>
> On 9/11/2025 6:08 pm, J Pan wrote:
>
> starlink can use bicast to reduce handover loss, especially for the
> downlink to the user terminal, but there are still handover delay
> spike and packet loss, especially for the uplink as well
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Sat, Nov 8, 2025 at 5:04 PM Ulrich Speidel via Starlink
> <starlink@lists.bufferbloat.net> wrote:
>
> Starlink is a bit unusual in terms of its packet loss mechanism.
>
> In "normal" networks, we have damaged packets (low SNR or interference
> leading to symbol errors in the modulation that then translate into bit
> errors and failing checksums), queue drops as part of the normal
> congestion control behaviour, and - not sure how much of a problem this
> still is these days - receive window overflows.
>
> In the case of Starlink and handovers, there appears to be an uplink
> queue for uplink to each satellite on the gateway side of things.
> Suppose your dishy talks to sat A first and then gets handed over to sat
> B. Up until handover time, packets heading to your dishy get sent to the
> queue for sat A, thereafter to the queue for sat B. These queues appear
> to be different and - with different packets and different volume in
> them - seem to lead to situations when a packet addressed to you that's
> been enqueued for A hasn't reached the front of the queue by handover
> time to B. As A now no longer talks to you, this packet is now on a road
> to nowhere.
>
> Of course, this loss only ever happens at handover time. No such thing
> as a uniform distribution here. Moreover, it's NOT a loss that should be
> interpreted as a congestion control signal to a TCP sender (or whatever
> other protocol is trying to congestion control itself, e.g., some QUIC
> implementation or somesuch).
>
> On the latency vs. bandwidth debate: To me, this seems a bit like
> arguing whether width or height are more important for area. Both
> matter, and both are equally badly understood by marketing folk.
>
> If your video needs to stream X Mb/s to the viewer, then the channel
> between the sender and receiver needs B > X Mb/s of available and
> accessible bandwidth. That's why bandwidth matters. Basta.
>
> The "accessible" part of the bandwidth is where the latency comes in.
> Remember the goal is to hit bandwidth-delay product on the lowest
> bandwidth link along the forwarding chain of your packets, i.e., to make
> sure you have that bit of pipe filled. It's a lofty goal because
> whatever you do in terms of increasing or decreasing your sending rate
> only has an effect some time later, by which time the conditions you're
> trying to respond to may have changed. Your picture of the current
> conditions is always outdated (and more outdated the longer the
> latency), and just to add insult to injury, the conditions (available
> bandwidth, RTT) can also change without your control input. That change
> is among others driven by algorithms that are possibly trying to fill a
> different pipe, or has at the very least a different (time-shifted) view
> of the conditions at the pipe you're trying to fill. This is a
> fundamental control problem, not a matter of BBR over BIC or Reno or
> Vegas or whatever you've tried on ns2.
>
> There are things that make this control problem a little easier: lower
> latency obviously, but also exclusive links (or at least fewer competing
> flows if you can't get exclusivity), fewer bandwidth bottlenecks along
> your hops and bottlenecks that are more predictable, i.e., where the
> input queues get processed at a constant processing rate. This is why
> last mile fibre and Ethernet in your home are so nice (just because you
> have your own WiFi router doesn't mean you have the channel to
> yourself). It's also why CDNs are so popular: They combine low latency
> with less competition for bandwidth and fewer hops.
>
> Starlink's challenge is that their bandwidth per cell is limited. Not
> quite to the point where it's a problem everywhere, but certainly to the
> point where it's becoming a problem in some places. If you're being
> asked to pay a congestion surcharge when you sign up, you're in one of
> those places. Moving to fq_codel and bringing down the latency has made
> more of that bandwidth accessible, but again there's a limit to what you
> can do there - it's not like reducing latency increases total bandwidth.
>
> On 9/11/2025 8:57 am, J Pan via Starlink wrote:
>
> if there are no obstructions, starlink nowadays can achieve 1% packet
> loss, often 0.1%, mostly due to satellite handover, so for the netflix
> open connect appliances inside starlink pop, they can do some
> starlink-specific optimization to mask away the handover for starlink
> users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
>
> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
>
> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
>
> "now physical, link and network layer have more info for
> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
>
> Regards,
>
> David
>
> On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
>
> yes, end-to-end congestion control was an add-on to tcp flow and error
> control, and at that time, packet loss was the only reliable
> congestion signal without router collaboration, and the  legacy stays.
> from the experience of tuning tcp on cellular networks, making the
> link layer more reliable is "the way", at the cost of more buffers and
> latency. but now physical, link and network layer have more info for
> the transport layer to make the right decision, e.g., starlink
> handovers at 12th, 27th, 42nd and 57th second of every minute with
> delay spike and losses
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
> <starlink@lists.bufferbloat.net> wrote:
>
> Thanks for sharing this Frank.
>
> In slide 3, I think that another effect not to be missed is packet losses
> due to errors, which could be analogous to pipe leaks. Sometimes, it
> happens that they are not negligible, in some cases with wireless links,
> mainly, but it could happen too in DSL. I remember that I had a DSL line in
> which the router had the option to disable interleaving, warning that you
> could get more errors, bad for watching video, they were saying, but
> reduced latency (good for videogames). When packet losses due to errors are
> misinterpreted as congestion by the transport protocols, the result is also
> a band quality of experience.
>
> Regards,
>
> David
>
> Date: Fri, 7 Nov 2025 11:53:44 +0100
>
> From: Frantisek Borsik <frantisek.borsik@gmail.com>
> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>          A Lie!  at WISPAPALOOZA 2025 (October 16)
> To: Cake List <cake@lists.bufferbloat.net>, bloat
>          <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>          Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>          <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>          <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
> Message-ID:
>          <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
> uhiQPd3KOg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>

[Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is

[Sebastian Moeller]

Hi Ulrich,

as so often on this list(s) great discussion with loads of interesting facts.

On 9 November 2025 21:08:50 CET, Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
>On 10/11/2025 7:42 am, Sebastian Moeller wrote:
>> Hi Ulrich,
>> 
>> 
>>> On 9. Nov 2025, at 02:03, Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
>>> 
>>> Starlink is a bit unusual in terms of its packet loss mechanism.
>>> 
>>> In "normal" networks, we have damaged packets (low SNR or interference leading to symbol errors in the modulation that then translate into bit errors and failing checksums), queue drops as part of the normal congestion control behaviour, and - not sure how much of a problem this still is these days - receive window overflows.
>>> 
>>> In the case of Starlink and handovers, there appears to be an uplink queue for uplink to each satellite on the gateway side of things. Suppose your dishy talks to sat A first and then gets handed over to sat B. Up until handover time, packets heading to your dishy get sent to the queue for sat A, thereafter to the queue for sat B. These queues appear to be different and - with different packets and different volume in them - seem to lead to situations when a packet addressed to you that's been enqueued for A hasn't reached the front of the queue by handover time to B. As A now no longer talks to you, this packet is now on a road to nowhere.
>>> 
>>> Of course, this loss only ever happens at handover time. No such thing as a uniform distribution here. Moreover, it's NOT a loss that should be interpreted as a congestion control signal to a TCP sender (or whatever other protocol is trying to congestion control itself, e.g., some QUIC implementation or somesuch).
>>> 
>>> On the latency vs. bandwidth debate: To me, this seems a bit like arguing whether width or height are more important for area. Both matter, and both are equally badly understood by marketing folk.
>>> 
>>> If your video needs to stream X Mb/s to the viewer, then the channel between the sender and receiver needs B > X Mb/s of available and accessible bandwidth. That's why bandwidth matters. Basta.
>> Well, you are of course right. However for almost all interactive use-cases the capacity that is actually usable by an application (and where less capacity results in noticeably worse results, while more capacity does not increase the perceived quality any more) is well below the access capacities that are sold.
>> For example page load times do generally not improve once the capacity exceeds 20-25 Mbps, FullHD streaming needs 5-8 Mbps, 4K streaming (still rare) 15-20 Mbps, videoconferencing typically also needs less than 20 Mbps, and traditional VoIP only takes around 100 Kbps (per direction)... even cloud gaming at high spatial and temporal resolutions (with short time windows to compress the video) only requires more than 65 Mbps (for 5K@120 Hz). And remote desktop is quite mild
>> So if we are generous and/or want to allow multiple concurrent users 50-100 Mbps is the capacity that will cover most typical interactive use-cases quite well. And at that point halving the latency will result in a bigger improvement than doubling the capacity...
>
>It boils down to the "available and accessible" bit. There are various reasons for why an application may not be able to access bandwidth even though it is available. And that can even be the case when you average over a large number of users.

Ak, okay, I had not understood accessible that way, but that is quite senaible avdefinition.

>
>When we looked into the first MEO link into the Cook Islands 10 years ago, we found that the local ISP wasn't ever seeing more than 50% bandwidth utilisation on their international link, yet the locals were quick to complain about the service. A lot of finger pointing went on but the culprit was actually TCP congestion control over a long latency bandwidth bottleneck. The ISP's monitoring tool looked at average bandwidth utilisation over a time period of many RTTs, which masked the fact that the input queue to their sat link was oscillating between tsunami and drought conditions. The bandwidth that was available after everyone had backed off wasn't accessible.

Yepp, longer term averages tend to hide fine temporal scale events ;) 

>
>> (I like your area model conceptually, yet increasing latency does not improve things, reducing does).
>Yes, that's taken as read I guess ;-)
>> 
>> 
>>> The "accessible" part of the bandwidth is where the latency comes in. Remember the goal is to hit bandwidth-delay product on the lowest bandwidth link along the forwarding chain of your packets, i.e., to make sure you have that bit of pipe filled. It's a lofty goal because whatever you do in terms of increasing or decreasing your sending rate only has an effect some time later, by which time the conditions you're trying to respond to may have changed. Your picture of the current conditions is always outdated (and more outdated the longer the latency), and just to add insult to injury, the conditions (available bandwidth, RTT) can also change without your control input. That change is among others driven by algorithms that are possibly trying to fill a different pipe, or has at the very least a different (time-shifted) view of the conditions at the pipe you're trying to fill. This is a fundamental control problem, not a matter of BBR over BIC or Reno or Vegas or whatever you've tried on ns2.
>>> 
>>> There are things that make this control problem a little easier: lower latency obviously, but also exclusive links (or at least fewer competing flows if you can't get exclusivity), fewer bandwidth bottlenecks along your hops and bottlenecks that are more predictable, i.e., where the input queues get processed at a constant processing rate. This is why last mile fibre and Ethernet in your home are so nice (just because you have your own WiFi router doesn't mean you have the channel to yourself). It's also why CDNs are so popular: They combine low latency with less competition for bandwidth and fewer hops.
>>> 
>>> Starlink's challenge is that their bandwidth per cell is limited. Not quite to the point where it's a problem everywhere, but certainly to the point where it's becoming a problem in some places. If you're being asked to pay a congestion surcharge when you sign up, you're in one of those places. Moving to fq_codel and bringing down the latency has made more of that bandwidth accessible, but again there's a limit to what you can do there - it's not like reducing latency increases total bandwidth.
>> True, yet proper scheduling and AQM makes links that operate around saturation point still quite usable even for interactive use-cases.
>I'm not arguing with this - but there's a short distance between "around saturation point" and "beyond saturation point".

True that, this is why the game here is to push the traffic down to never cause full saturation (for too long), easier on fixed rate links, trickier on variable rate links.


>> 
>> 
>>> On 9/11/2025 8:57 am, J Pan via Starlink wrote:
>>>> if there are no obstructions, starlink nowadays can achieve 1% packet
>>>> loss, often 0.1%, mostly due to satellite handover, so for the netflix
>>>> open connect appliances inside starlink pop, they can do some
>>>> starlink-specific optimization to mask away the handover for starlink
>>>> users, e.g., https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet24-victor.pdf
>>>> --
>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>>> 
>>>> On Sat, Nov 8, 2025 at 11:12 AM David Fernández <davidfdzp@gmail.com> wrote:
>>>>> "making the link layer more reliable is "the way"", indeed. In the wireless data link design projects I have participated, it has always been the requirement to have packet loss rate (PLR) at IP layer due to physical layer errors uniformly distributed and not higher than 0.1%, for TCP, while for wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR is acceptable.
>>>>> 
>>>>> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching up to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC and BBR are more robust to higher packet loss rates due to error than Reno.
>>>>> 
>>>>> "now physical, link and network layer have more info for
>>>>> the transport layer to make the right decision", but do they? I mean, how is the transport layer getting info nowadays about the path characteristics in terms of bandwidth, latency and packet losses from the layers below or info like the one you mentioned about Starlink handovers? I still have not seen this happening, have you?
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> David
>>>>> 
>>>>> On Sat, 8 Nov 2025, 22:30 J Pan, <Pan@uvic.ca> wrote:
>>>>>> yes, end-to-end congestion control was an add-on to tcp flow and error
>>>>>> control, and at that time, packet loss was the only reliable
>>>>>> congestion signal without router collaboration, and the  legacy stays.
>>>>>> from the experience of tuning tcp on cellular networks, making the
>>>>>> link layer more reliable is "the way", at the cost of more buffers and
>>>>>> latency. but now physical, link and network layer have more info for
>>>>>> the transport layer to make the right decision, e.g., starlink
>>>>>> handovers at 12th, 27th, 42nd and 57th second of every minute with
>>>>>> delay spike and losses
>>>>>> --
>>>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>>>>> 
>>>>>> On Fri, Nov 7, 2025 at 2:51 PM David Fernández via Starlink
>>>>>> <starlink@lists.bufferbloat.net> wrote:
>>>>>>> Thanks for sharing this Frank.
>>>>>>> 
>>>>>>> In slide 3, I think that another effect not to be missed is packet losses
>>>>>>> due to errors, which could be analogous to pipe leaks. Sometimes, it
>>>>>>> happens that they are not negligible, in some cases with wireless links,
>>>>>>> mainly, but it could happen too in DSL. I remember that I had a DSL line in
>>>>>>> which the router had the option to disable interleaving, warning that you
>>>>>>> could get more errors, bad for watching video, they were saying, but
>>>>>>> reduced latency (good for videogames). When packet losses due to errors are
>>>>>>> misinterpreted as congestion by the transport protocols, the result is also
>>>>>>> a band quality of experience.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> David
>>>>>>> 
>>>>>>> Date: Fri, 7 Nov 2025 11:53:44 +0100
>>>>>>>> From: Frantisek Borsik <frantisek.borsik@gmail.com>
>>>>>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>>>>>>>>          A Lie!  at WISPAPALOOZA 2025 (October 16)
>>>>>>>> To: Cake List <cake@lists.bufferbloat.net>, bloat
>>>>>>>>          <bloat@lists.bufferbloat.net>,        codel@lists.bufferbloat.net,
>>>>>>>>          Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>, libreqos
>>>>>>>>          <libreqos@lists.bufferbloat.net>,   Dave Taht via Starlink
>>>>>>>>          <starlink@lists.bufferbloat.net>, l4s-discuss@ietf.org
>>>>>>>> Message-ID:
>>>>>>>>          <CAJUtOOhzJAymDiKsnRPho80B8GZ4wzd8W7FWccS=
>>>>>>>> uhiQPd3KOg@mail.gmail.com>
>>>>>>>> Content-Type: text/plain; charset="UTF-8"
>>>>>>>> 
>>>>>>>> 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
>>>>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>>>>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>>>> _______________________________________________
>>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>>> -- 
>>> ****************************************************************
>>> Dr. Ulrich Speidel
>>> 
>>> School of Computer Science
>>> 
>>> Room 303S.594 (City Campus)
>>> 
>>> The University of Auckland
>>> u.speidel@auckland.ac.nz
>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> ****************************************************************
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.