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-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by mail.toke.dk (Postfix) with ESMTPS id 23EEF93C015 for ; Sun, 09 Nov 2025 18:54:05 +0100 (CET) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-71d6014810fso17782177b3.0 for ; Sun, 09 Nov 2025 09:54:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762710844; x=1763315644; 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=2tbwlu/qZBh5oZbHFPqCyKTHlGDaU/jfdU+TFqKrsqs=; b=WQ+X1oMd2umk7zKSDYO2iZWyBZWAFxtGws/RyP5dIbpaSpRx4UTXcZnyTGRwRCs2DH 7JU0CwmRUHnh+2wFLcxJ8yBQJJVnTaAtNkVqodTfUw2kMX7co4FxgBz9JGvMGgclGE86 k+wfs4QNXVDxuDIBhMj+ccBowBnI2rgD6pMigfvCoWW3W7yL8iea8Ub79lTu4X6CjsOQ RsloQ6jlaOzG6A8VvmlQ1eo+1DXCborpzMezJC0oS/+15ijAmo3l44QlvsrCRiyUmneU E5uMzAd+4Jy0J7NzwxxX4K4ThtbyzBQPm6PQR5G0YSSJrdk3D+l/uX9JJcve2hcT4Djm BIzQ== X-Gm-Message-State: AOJu0Yy9mgkMxsJlzZ17MWACC7yiiYcvfUE6ROOQLZMxUdYAHelTrsJW cd184uuZwVKIEoAJxh5wWgcIacqN1z3tF0T7/cQLXaHLnJCOTYJDQacHVNC6P5vsrp9UK41LYOO XfHtQ1xqS0MnBc5wW+DtdMcPcZNC2QL8= X-Gm-Gg: ASbGncuYCdbTiDZ2PD2Yn1ODxlO6mJ0kD+n8j0IYZvXrtQEQnb/EgW4C4E3SDXvqOc2 22E0VfHL69tecNt9rDtZsBJlFucT+ruhYwK+6TdbFm9hU0zUZf5tK1BLhRV9qYuT2PpIRx+Q8CM dBc4bugUPA7AuLpQFyefSZPAzra7UP1TUXrcbM3JhPMRzk3EZbnzpoFj6zSkwNG2NMsJmCTlgKZ 1Ln5X/kWie+d+QyGqtL2AN2BqyxcEi3C5upLYvQAaqYLvM4DlR1+HMOpDaD X-Google-Smtp-Source: AGHT+IEMgDqrahfHR9GLsRKyfwfTcs2nRLNYqYW90Ap5dC6DbEhWVPfnRecVXP5fLvEHn45KmLue55RI8WMJTb3LHDo= X-Received: by 2002:a05:690c:252:b0:786:7434:dd67 with SMTP id 00721157ae682-787d536463emr45559257b3.3.1762710843899; Sun, 09 Nov 2025 09:54:03 -0800 (PST) MIME-Version: 1.0 References: <176254173597.1347.15997824594759319437@gauss> In-Reply-To: From: J Pan Date: Sun, 9 Nov 2025 09:53:53 -0800 X-Gm-Features: AWmQ_bkzCkbDZVHt_Nt1_yf0rkifX-xV2dYHYGBs7jwjln4lGzvgNgm29k68TDs Message-ID: To: =?UTF-8?Q?David_Fern=C3=A1ndez?= Cc: starlink Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: Z7B3Q7AJQLLCXNHHUKILKCPLB3C6WGAM X-Message-ID-Hash: Z7B3Q7AJQLLCXNHHUKILKCPLB3C6WGAM 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: yes, starquic is a sender-only fix to address the regular handover in starlink, especially for the downlink from the netflix oca in the starlink pop toward the user dish for video streaming -- 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:45=E2=80=AFAM David Fern=C3=A1ndez wrote: > > Interesting, so this use of StarQUIC somehow reminds me of the use of > PEPs in GEO satellites, breaking the end to end TCP connection and > using SCPS-TP between the satellite terminal and the gateway, to > overcome the issues with higher propagation latency. > > Certainly, if you control the servers and the clients as Netflix may > do, with a particular app, instead of a generic browser, you can tune > the transport protocol to adapt to anything happening in lower layers, > and QUIC is highly customizable, being in user space. > > > On Sat, 8 Nov 2025 at 20:57, J Pan 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 wi= reless data link design projects I have participated, it has always been th= e requirement to have packet loss rate (PLR) at IP layer due to physical la= yer errors uniformly distributed and not higher than 0.1%, for TCP, while f= or wireless links carrying only VoIP, using RTP and G.729 codec, up to 1% P= LR 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 an= d 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 characteri= stics in terms of bandwidth, latency and packet losses from the layers belo= w 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 err= or > > >> control, and at that time, packet loss was the only reliable > > >> congestion signal without router collaboration, and the legacy stay= s. > > >> from the experience of tuning tcp on cellular networks, making the > > >> link layer more reliable is "the way", at the cost of more buffers a= nd > > >> 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 Star= link > > >> 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 - Bandwi= dth 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 = 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_YGH2= r4-UDZP25VEk-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 t= here 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 tryin= g, 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 ban= dwidth to > > >> > > >> solve a problem, when they really need lower latency and jitt= er. So the > > >> > > >> vast majority of the time 'more bandwidth' as a solution real= ly 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 - "Ba= ndwidth is > > >> > > >>> dead. Long live latency." > > >> > > >>> > > >> > > >>> > > >> > > https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-li= ve-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 maki= ng 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.bufferb= loat.net > > >> > > >>> > > >> > > >> > > >> > > > > >> > > > > >> > _______________________________________________ > > >> > Starlink mailing list -- starlink@lists.bufferbloat.net > > >> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.n= et