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

["David Fernández" <davidfdzp@gmail.com>]

"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
>