* [Starlink] Re: Starlink Digest, Vol 55, Issue 9
2025-11-09 15:40 ` [Starlink] Re: Starlink Digest, Vol 55, Issue 9 David Fernández
@ 2025-11-09 18:22 ` J Pan
2025-11-09 19:57 ` Ulrich Speidel
1 sibling, 0 replies; 3+ messages in thread
From: J Pan @ 2025-11-09 18:22 UTC (permalink / raw)
To: David Fernández; +Cc: starlink
uplink is even harder for video (broadcasting, e.g., teaching from
home) so ibm is even more conservative on setting video data rate.
certain techniques, e.g., super resolution, can help
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
On Sun, Nov 9, 2025 at 7:41 AM David Fernández via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> "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."
>
> IBM recommends B .>= 2X Mb/s, if I understand correctly this:
>
> "A good rule of thumb is for the bitrate of your stream to use no more
> than 50% of your available upload bandwidth capacity on a dedicated
> line. For example, if the result you get from a speed test shows that
> you have 2Mbps of upload speed available, your combined audio and
> video bitrate should not exceed 1Mbps.
> To stream in HD, you'll want at least 3-8Mbps upload speed available"
>
> https://support.video.ibm.com/hc/en-us/articles/207852117-Internet-connection-and-recommended-encoding-settings
>
>
> > Date: Sun, 9 Nov 2025 14:03:35 +1300
> > From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
> > To: starlink@lists.bufferbloat.net
> > Message-ID: <d46e6897-2f66-4dc1-a625-651bce744381@auckland.ac.nz>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Starlink] Re: Starlink Digest, Vol 55, Issue 9
2025-11-09 15:40 ` [Starlink] Re: Starlink Digest, Vol 55, Issue 9 David Fernández
2025-11-09 18:22 ` J Pan
@ 2025-11-09 19:57 ` Ulrich Speidel
1 sibling, 0 replies; 3+ messages in thread
From: Ulrich Speidel @ 2025-11-09 19:57 UTC (permalink / raw)
To: starlink
Note the "available and accessible" part.
Just because bandwidth is available, it isn't necessarily accessible to
whatever you use for streaming - if that something alternates between
gross over- and underestimation of BDP, you can't access much of the
available bandwidth.
The point is: Bandwidth matters. Lower latency improves bandwidth
accessibility, but unless that bandwidth is available in the first
place, it won't be accessible.
IBM's recommendations are entirely compatible with that insight.
On 10/11/2025 4:40 am, David Fernández via Starlink wrote:
> "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."
>
> IBM recommends B .>= 2X Mb/s, if I understand correctly this:
>
> "A good rule of thumb is for the bitrate of your stream to use no more
> than 50% of your available upload bandwidth capacity on a dedicated
> line. For example, if the result you get from a speed test shows that
> you have 2Mbps of upload speed available, your combined audio and
> video bitrate should not exceed 1Mbps.
> To stream in HD, you'll want at least 3-8Mbps upload speed available"
>
> https://support.video.ibm.com/hc/en-us/articles/207852117-Internet-connection-and-recommended-encoding-settings
>
>
>> Date: Sun, 9 Nov 2025 14:03:35 +1300
>> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is
>> To: starlink@lists.bufferbloat.net
>> Message-ID: <d46e6897-2f66-4dc1-a625-651bce744381@auckland.ac.nz>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> 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/
****************************************************************
^ permalink raw reply [flat|nested] 3+ messages in thread