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-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by mail.toke.dk (Postfix) with ESMTPS id B6D6393C227 for ; Sun, 09 Nov 2025 19:22:29 +0100 (CET) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-787df0d729dso7294697b3.3 for ; Sun, 09 Nov 2025 10:22:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762712548; x=1763317348; 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=xMb/R0h3x66dz8q5Cuyqg6LFqLdiEaH6suK3RjQaHn8=; b=uHlv/Lm/o+ADdtV4RIhFYLV4AzJwJJEiPMfZBbNFKrr+vXKcn+380sijA17QUKNMmD MKVgxHMKeq/ZpM1CBQvvHK7ppnmegq6cmrh2vpWzLJ9H+sodsp8yZRmgwm1/9rhzvc4I JT6m9tXzgy4+SUPgi9NXwSaGfd1NRpSdBmHkGInrXUv6GYJFkaVynjNOn68SG6fyiPK8 tSe+HR5OnkDuQrUAs4mdv28F1DhL/OwJwJhyUrDjC4uuQdHXbqxQYT7+V/770HN+mZZf OqXutpii9igodIWKabZHMfpKJySKQa/50xL2n9q0SeCb5ruZRSWg9u+hRdowwi5SB6De 1w3w== X-Gm-Message-State: AOJu0YykjglSVHCTaMpUj4xWPzadeAZQxSQcBi9Hzfn87gkJzMJAcVN/ j7srUshK3sAoiprEKD9V26EhmKjvBYrrGnmm7bPcTVXq6PbQbAwMjtMqNTqdfMepJU/FlO3LkoB 9vugoal3Fsn5MLKcDhgxX5D+EtOl68OPMmQ== X-Gm-Gg: ASbGncsBhpQ+VhPMJGmFpy1+ahZksCCSWO6+xStlpx8Ncd2cpIEH5ZeagryB5/e8u22 x1nZuTDfKZIpvPSDhFLtxTR9yiyamk5PICpZolVgXqLdBbQIOGgDsFzxFrd35S7mHfGVYd+FMrX yjlnjHHSKISZyPtTexQyPwtXBO4qozIHf5cLsfnsFv0y87XfhdT5bQ9XRcdHEIDyA88COx8fIkm hlPptLYFRaCnICuWi0kzKKGuZS5iSceNzWjJJgT3bu8hSxzvTW3exqxQ0CUkNVmb9Q6liE= X-Google-Smtp-Source: AGHT+IHDZzBefSO6x4ioJ/iB3QbbZ3Vu+Xy3S2LjUZ4ZCklMmCgW21lNu/AOcslt7NbxN6VOKH+8Lci56XoC9VLLZHE= X-Received: by 2002:a05:690c:6385:b0:786:5379:afb5 with SMTP id 00721157ae682-787d53a2660mr69435257b3.24.1762712547960; Sun, 09 Nov 2025 10:22:27 -0800 (PST) MIME-Version: 1.0 References: <176265023563.1347.14746013472164055053@gauss> In-Reply-To: From: J Pan Date: Sun, 9 Nov 2025 10:22:17 -0800 X-Gm-Features: AWmQ_bnu_2vrAIhFefJB5hZpRhGOUWtrkQ-C-aNVTUy81vf1-G4GjIovmgKtt2k Message-ID: To: =?UTF-8?Q?David_Fern=C3=A1ndez?= Cc: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: SUOTKGHGF6JG2IFI47WCVMFWZCQZRIP6 X-Message-ID-Hash: SUOTKGHGF6JG2IFI47WCVMFWZCQZRIP6 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: 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: 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/~pa= n On Sun, Nov 9, 2025 at 7:41=E2=80=AFAM David Fern=C3=A1ndez 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 .>=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-connec= tion-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 sa= t > > B. Up until handover time, packets heading to your dishy get sent to th= e > > 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 roa= d > > 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 b= e > > 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 mak= e > > 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) vie= w > > 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 competin= g > > 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 th= e > > 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 yo= u > > 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 netfli= x > > > 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/88= 76/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 w= ireless data link design projects I have participated, it has always been t= he requirement to have packet loss rate (PLR) at IP layer due to physical l= ayer 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 u= p to 6% or more even, but TCP works anyway, somehow. It may be that CUBIC a= nd 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 character= istics in terms of bandwidth, latency and packet losses from the layers bel= ow or info like the one you mentioned about Starlink handovers? I still hav= e 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 er= ror > > >>> control, and at that time, packet loss was the only reliable > > >>> congestion signal without router collaboration, and the legacy sta= ys. > > >>> 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 fo= r > > >>> 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.UVi= c.CA/~pan > > >>> > > >>> On Fri, Nov 7, 2025 at 2:51=E2=80=AFPM David Fern=C3=A1ndez via Sta= rlink > > >>> 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 DS= L line in > > >>>> which the router had the option to disable interleaving, warning t= hat you > > >>>> could get more errors, bad for watching video, they were saying, b= ut > > >>>> reduced latency (good for videogames). When packet losses due to e= rrors are > > >>>> misinterpreted as congestion by the transport protocols, the resul= t 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 - Bandwid= th Is > > >>>>> A Lie! at WISPAPALOOZA 2025 (October 16) > > >>>>> To: Cake List , bloat > > >>>>> , codel@lists.buffer= bloat.net, > > >>>>> Jeremy Austin via Rpm , libre= qos > > >>>>> , Dave Taht via Starli= nk > > >>>>> , 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 g= reat 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_YGH2r= 4-UDZP25VEk-xyJcZE/edit?slide=3Did.p#slide=3Did.p > > >>>>> > > >>>>> We hope to continue this conversation into more practical, demo-l= ike > > >>>>> environment of sort, that we can see at IETF Hackathon and used t= o 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 the= re 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 bandw= idth 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 Li= breQoS < > > >>>>>>> libreqos@lists.bufferbloat.net> wrote: > > >>>>>>> > > >>>>>>>> Thanks, Jim. Well, true that - but I wanted to do it either wa= y, > > >>>>> because > > >>>>>>>> of > > >>>>>>>> our dear Dave and - as a conversation starter. > > >>>>>>>> As @Jason Livingood said - "Band= width is > > >>>>>>>> dead. Long live latency." > > >>>>>>>> > > >>>>>>>> > > >>>>> https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-liv= e-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=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 un= derstand the > > >>>>>>>>> sentiment but find the issues more nuanced than that. :-) > > >>>>>>>>> > > >>>>>>>>> If you can get clear audio, not much quality is needed for pa= nels and > > >>>>>>>>> talking beads. Best would be a feed right into an iPhone/an= droid. > > >>>>>>>>> > > >>>>>>>>> Jim > > >>>>>>>> _______________________________________________ > > >>>>>>>> LibreQoS mailing list -- libreqos@lists.bufferbloat.net > > >>>>>>>> To unsubscribe send an email to libreqos-leave@lists.bufferblo= at.net > > >>>>>>>> > > >>>>> > > >>>> _______________________________________________ > > >>>> Starlink mailing list -- starlink@lists.bufferbloat.net > > >>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.n= et > > > _______________________________________________ > > > 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