From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=fail; arc=none (Message is not ARC signed); dmarc=fail (Used From Domain Record) header.from=uvic.ca policy.dmarc=none Received: from mail-yx1-f50.google.com (mail-yx1-f50.google.com [74.125.224.50]) by mail.toke.dk (Postfix) with ESMTPS id 55A7693CF09 for ; Sun, 09 Nov 2025 22:15:31 +0100 (CET) Received: by mail-yx1-f50.google.com with SMTP id 956f58d0204a3-63fc8c337f2so1812460d50.0 for ; Sun, 09 Nov 2025 13:15:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762722930; x=1763327730; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XlmwCCiUdi5yJZSgQ56qplXFd05VTm0FhRuo38gVvGU=; b=KGRZKfsvX3aGeCXtSbaEpnfmbCVwprXnGMXIZOJxGu96kNXLJ/8YUetxU0DFfy/5km RVUFgqTN703LqJfBT4EYYciSTPQR3gdhqX/cEHxVqHPvV+dA5ov/OZCRTn0T+AmAoWaT Nm03c4f7KigeSPn3wDDluHGBY0oLM3fstVqMg20/7F1rAXhvhwVVWwve9T/X25Y1LEmB c/RNB0LSTdeLYaldLJrdLM0sjU+Z/4AeLqw3tKjKouWmqMEoHCRzhFqciz9SlNvMjVnJ /MQEk+fIQnp485CD8qeh6ysn4Tmno4nvZnoI8z/Yz+BXnktglqsEy/WXxrGIr9YdibwP iZ9w== X-Gm-Message-State: AOJu0YwLwxSg1nOw6RaZD2knGLxA8ZVXbgu036q7f/03e3/af6987JW6 iu2If0P+MUhg7nhjmEM4fU0QuEcinerCvR4VJUrWrrgLzy+0rwzKurVaPRKF7EkdBlCCMMF7Pb/ I571AEw34oPz3/VT06qAezyaO/XbSWSY= X-Gm-Gg: ASbGncsjHQL+78w3s6J6fIelrHiyBORhgrvlILsy8xGXBsR39lNzCVDnHHALclZgBTc WKIxaNZ/HbngNPMNYbN0pA6s/gpwjcqsuBN7L85Fxf+pW/FjO3cyyM7eJFLFGsL4u/o5tkEaKhV oPJZ8nBZh0M0yBupElERxnaWYgAYw80VA1h3iSSAw/+5R/fqclSYZ9k+jwr52HU/TwTpX4IqeFn z0WRdPYhcrHJ+aBM5jrQRhlJ+/TVcpgGSmQY7fRU82sD5+inArtmKGIQThS6OrlxaKAFrs= X-Google-Smtp-Source: AGHT+IE125Gi/+aGinF3F/bp0X4qjhXriUOM/ZypSs0YelxfTQ1KVgiIndhL2y1rCqggzy04ryBgKsHeEpCuzTk9MTU= X-Received: by 2002:a05:690c:22c3:b0:786:a892:8a13 with SMTP id 00721157ae682-787d54609a5mr98716847b3.61.1762722929945; Sun, 09 Nov 2025 13:15:29 -0800 (PST) MIME-Version: 1.0 References: <176254173597.1347.15997824594759319437@gauss> In-Reply-To: From: J Pan Date: Sun, 9 Nov 2025 13:15:19 -0800 X-Gm-Features: AWmQ_bkCE1EltGYqcLkNnz3d7kvkZzRqLB-AoRtbythmnBmG_yzs952gNAgvMNM Message-ID: To: Ulrich Speidel Cc: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: AN6TXFGLFKCM7XELNQC4UDCOSK3MAFCJ X-Message-ID-Hash: AN6TXFGLFKCM7XELNQC4UDCOSK3MAFCJ X-MailFrom: panatuvicdotca@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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/~pa= n On Sun, Nov 9, 2025 at 11:51=E2=80=AFAM Ulrich Speidel 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 t= he 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 a= nd 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 remov= ed? If not, it needlessly takes up capacity needlessly (=3Dintroduces delay= ) on sat B. But that could be solved I guess, as long as handover is to/fro= m 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 capac= ity on sat B. > The packet reaches the front of the queue for sat B more than L_a ms befo= re the handover, but there's no client there yet to transmit it to. What do= es 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 a= s 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=E2=80=AFPM Ulrich Speidel via Starlink > 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/2= 024/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=E2=80=AFAM David Fern=C3=A1ndez wrote: > > "making the link layer more reliable is "the way"", indeed. In the wirele= ss data link design projects I have participated, it has always been the re= quirement 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 w= ireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PLR i= s 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 BB= R 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 characteristic= s 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, 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=E2=80=AFPM David Fern=C3=A1ndez via Starlink > 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 a= re > misinterpreted as congestion by the transport protocols, the result is al= so > a band quality of experience. > > Regards, > > David > > Date: Fri, 7 Nov 2025 11:53:44 +0100 > > From: Frantisek Borsik > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is > A Lie! at WISPAPALOOZA 2025 (October 16) > To: Cake List , bloat > , codel@lists.bufferbloat.ne= t, > Jeremy Austin via Rpm , libreqos > , Dave Taht via Starlink > , l4s-discuss@ietf.org > Message-ID: > uhiQPd3KOg@mail.gmail.com> > Content-Type: text/plain; charset=3D"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=3DT1VET0VYQ6c > > We have touch bandwidth, L4S, Starlink and more. > > Here are the slides with additional reading: > > https://docs.google.com/presentation/d/1ML0I3Av3DCtQDiP8Djr_YGH2r4-UDZP25= VEk-xyJcZE/edit?slide=3Did.p#slide=3Did.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=C3=A4ht: *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=E2=80=AFPM 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=C3=A4ht: *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=E2=80=AFPM dan 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=E2=80=AFPM 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 said - "Bandwidth is > dead. Long live latency." > > > https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-latenc= y > > 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=C3=A4ht: *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=E2=80=AFPM James Forster < > > jim@connectivitycap.com> > > wrote: > > Wow, that=E2=80=99s fantastic, Frantisek! Great work making this happen. > > These sort of titles aren=E2=80=99t 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/ > **************************************************************** > > >