From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=gmail.com; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=gmail.com policy.dmarc=quarantine Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by mail.toke.dk (Postfix) with ESMTPS id AED7D93B6A4 for ; Sun, 09 Nov 2025 16:40:52 +0100 (CET) Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-37a48fc48deso20482161fa.3 for ; Sun, 09 Nov 2025 07:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762702849; x=1763307649; darn=lists.bufferbloat.net; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=v9foA3N0b8l+9zTskuirIoZzl69Vv+cxkvX4tw+nc4I=; b=I6HR9fJJVdMJToopX7snOzqmft85mJlScWzf0IxypfyehdTbq/st0KS6nTlbGKC9sd PxzBllGMvVwTu8+j8gdg/9S3nPbBtotl+rHq7Ql5WoZoEZEJYzGh767pQJgbDMxy2Xs5 IRZKAaMu6vRCasyg8vOuHXnnD0K7nMmikGpW8XbCIDFD9RWoKOC54Vb8f3kTsx4yV827 RBzaejZYYZql2EWYMlVBhbw2HlPQRMrPvlFReezeowQ5PX2MS4C9zxWUTpQYszqnKWGS NuoqDn3nAa4dQ38AgQ3cR925Mu+7rszuZlz05ihBGcOfPOa+O0suMxZKdfaEcL5phqzx rAwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762702849; x=1763307649; h=content-transfer-encoding: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=v9foA3N0b8l+9zTskuirIoZzl69Vv+cxkvX4tw+nc4I=; b=TVBQ7cdThNILm2cNHy9li3QDGutvrzoEe555L57GWbrFXUcnYxCOZ1duTu7JI7b5zw dcR8oc/r6GwbCzRq7iyame0dUeIDXUZngnyPqzvlbzhzx55ATD9aVwxvndrAsoFi/UG9 VHfCgPB+2t3wdZ9F14Fb/JCjbQzV4bUKeZ68Av6n+dEGPsZkm+/RJZeSCxEJnk0tdLFn 06I0Jplh124e9xpBzeE2sIwUqWcVTGrRNKTjLh+U5JGlyDk88cmIchom/ArP3EoGNeoR WaB8mTt6OhPou/mu+zdRtOd06BsWe0RB+W4wJHjTQUoHwf1c+KbXFGQDNR8jPZyuRAWJ HHwQ== X-Gm-Message-State: AOJu0Yy6vS6qaUiqxH2GPMb2Jqjyx3oc/3lBJWYDQ6k7sSWr3GIREi1r 4IFQ5tDZoIhB+6qaT7WSJYFYueduurAOmO2LMv5iJF6qaTbRUQc5qPZdZb/uKfNC9rj6t8GFZFu OOdj+iQ+xgl0wNacktCvI+05Dzq1QHEeg+9mV99zH3+mC X-Gm-Gg: ASbGncvdmM9/0HSL51sIqXrQWDffFeOtQdyRvKFHhPzjXq54ml8RzhnLZgXrwjnRpmS 1MnMQz9QHLUIpxI/fD7CLt0K3CWliinaCP8EJcauzglDGSB7cN5LobdbN3VgC0uKA7OobIwBGyR Mp6VrHEM7LQeduO/ftXRSiVZUdlFwV9ZupxdPXVnUuM0F6Ip3jW4wsq7bc/OXQlgjWDXmGkZrRH 2dvdIQ/nI3krwg/LHjHGptqbfrYLdGgcgGhY/vIF4S8XZnxO9EUgDGBQFI= X-Google-Smtp-Source: AGHT+IH9yH+o0Tf6ZYax5W4bXTbrmeYZcHGDvOeoX58vhtqQtITg0c6/6RL9uEaPBxlULcq15M+q0yLnOwH2reWdChg= X-Received: by 2002:a2e:8a95:0:b0:375:ffc2:1b1d with SMTP id 38308e7fff4ca-37a7b1786eamr14955941fa.4.1762702849151; Sun, 09 Nov 2025 07:40:49 -0800 (PST) MIME-Version: 1.0 References: <176265023563.1347.14746013472164055053@gauss> In-Reply-To: <176265023563.1347.14746013472164055053@gauss> From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Sun, 9 Nov 2025 16:40:11 +0100 X-Gm-Features: AWmQ_bkenbAU-FQr5gp1vY_X5Garmw8fWDnIGrSdsn4OgjaSececBQ1T56rOqqg Message-ID: To: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: E3L5M274QHZHANEW24KNQNRUL57JUUC2 X-Message-ID-Hash: E3L5M274QHZHANEW24KNQNRUL57JUUC2 X-MailFrom: davidfdzp@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: Starlink Digest, Vol 55, Issue 9 List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: "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 .>=3D 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-connecti= on-and-recommended-encoding-settings > Date: Sun, 9 Nov 2025 14:03:35 +1300 > From: Ulrich Speidel > Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is > To: starlink@lists.bufferbloat.net > Message-ID: > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > 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=E2=80=AFAM David Fern=C3=A1ndez wrote: > >> "making the link layer more reliable is "the way"", indeed. In the wir= eless 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 lay= er errors uniformly distributed and not higher than 0.1%, for TCP, while fo= r wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% PL= R 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 characteris= tics 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 erro= r > >>> 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 an= d > >>> 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 Starl= ink > >>> wrote: > >>>> Thanks for sharing this Frank. > >>>> > >>>> In slide 3, I think that another effect not to be missed is packet l= osses > >>>> due to errors, which could be analogous to pipe leaks. Sometimes, it > >>>> happens that they are not negligible, in some cases with wireless li= nks, > >>>> 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 tha= t you > >>>> could get more errors, bad for watching video, they were saying, but > >>>> reduced latency (good for videogames). When packet losses due to err= ors 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 > >>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth= Is > >>>>> A Lie! at WISPAPALOOZA 2025 (October 16) > >>>>> To: Cake List , bloat > >>>>> , codel@lists.bufferbl= oat.net, > >>>>> Jeremy Austin via Rpm , libreqo= s > >>>>> , 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 gre= at 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-= UDZP25VEk-xyJcZE/edit?slide=3Did.p#slide=3Did.p > >>>>> > >>>>> We hope to continue this conversation into more practical, demo-lik= e > >>>>> 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, b= ut 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 w= rote: > >>>>>> > >>>>>>> I actually really like the title ;) > >>>>>>> > >>>>>>> It's that most of the time people are told they need more bandwid= th 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 i= s a > >>>>> lie. > >>>>>>> On Tue, Sep 30, 2025 at 2:47=E2=80=AFPM Frantisek Borsik via Libr= eQoS < > >>>>>>> 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 - "Bandwi= dth 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 w= ith 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 th= is happen. > >>>>>>>>> > >>>>>>>>> These sort of titles aren=E2=80=99t my favorite. I think I unde= rstand the > >>>>>>>>> sentiment but find the issues more nuanced than that. :-) > >>>>>>>>> > >>>>>>>>> If you can get clear audio, not much quality is needed for pane= ls and > >>>>>>>>> talking beads. Best would be a feed right into an iPhone/andr= oid. > >>>>>>>>> > >>>>>>>>> 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/ > ****************************************************************