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-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by mail.toke.dk (Postfix) with ESMTPS id EA0A693B723 for ; Sun, 09 Nov 2025 16:45:35 +0100 (CET) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-37a49389deeso16299901fa.0 for ; Sun, 09 Nov 2025 07:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762703135; x=1763307935; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OkXw7Nx2vHq5XnkpO87B4ODpDahIWUFVzlJamAfAHW8=; b=l4fHj0e3e6YDd5VqerpCIPfA2BEhkM6UzFGVi6Vu5sIttY7J4t9RlVHRNzwE9zgFqw lfHnqPtLkjMsH9hHnYw4uOrf3dciQGJzL7x7n5HVii7fAAGKjrZDJ0uuykjd2T8rVT6c haTdyLccpbOvZKRaFHAa1bEdZnCRzLr9kmp3WwO5pHR26qsmkDzxDvBHhwKxdS2C6iU3 eXbPeMLcU0oBvIp542o7DPhz61Y4VfvxroXz0cxH/D1iwxTXV6KEG8rKbiq7M628qLEs Vm036WQr0lH/kgzFUoxBh8ezaFyRY/WsOU+2pO2NtDKj/OMutKDiXPVXY6gSrFgqOsGm zXGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762703135; x=1763307935; 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=OkXw7Nx2vHq5XnkpO87B4ODpDahIWUFVzlJamAfAHW8=; b=Gy0JHg/qb0kCgxCeDHUMY9FYemCnhHslqbED0hsh0RkMzf+dwv/3Dv7dtJlpIVbxdd 2e8BL1AXYb86fHP5E9fhPN8XZRPUXY7RcIN6q4GJ/LMwVlySqhFIsxrXdoZtXPShREqg 5FtG+s2RKUvAMacs2uXJTg+r45OXaw0zyYhD3NJUQmrCnQ2BF+REPEda3g1CW4Y+9lYA JJ4SF4R2kwPPiGOG5NWiEzwwqje8tg7NDKMVVinaBxYarbcdVWpVJbufrUPmarMLjC9p kqTe+Qmg8XkOzcRV1Rtujkb0T8BOnPzUxEYMHPx//mntLtaAC19pwwSwoKaohomfV6qZ FgaA== X-Gm-Message-State: AOJu0Yyzlx7hXk7OvoNHNBt7H9sFR8L5O38/0JDTtDBJeENg6WoFOk/J X50lh+T60Z6ANn3z9TcU2YZhhzxqe+mp4FoRtfZKsYdfy4IibA6nS9pExEMiDMO9YAzO4ouXSHn KZbJgFXU33tKac4kXK0+/e87wquyW1wJpGMWHiNAzwA== X-Gm-Gg: ASbGncu6eSzUxFKvLNmvO8amGqAC6oSc7oKp3GkXBHv+4BmPMSxaMM0vhnuIV805zS7 ZbhP4lkyXU6RreMsBvhmsaIaf0X/Gi9pwOta+0+SWR4Sfl9t1GgqQmZj3YQ4UxuHjVpBacVp8mE /K+rBp7op5sw2lUgBLTHmQ94DESq0bLWfhgLrXw2pNs1KqrBtLW6VYKYG5O/qaCO4tBHazEVNyX rhtqrL+MMOMDKrs9WJ3sywU4DqryhJaiYC5n77HnMozOpvzbfAQGvmZcz//4QcWT664lw== X-Google-Smtp-Source: AGHT+IGjsVE4+qjIt9tsG6fyrBe2KU7O7ya6moFCo+sSNue1ebHQy9vyUNcYluCA9a3BHMfGdaa0G6SAzcM/lfBNB+0= X-Received: by 2002:a2e:7c03:0:b0:36d:501:76d5 with SMTP id 38308e7fff4ca-37a7b2c496bmr10262451fa.26.1762703134440; Sun, 09 Nov 2025 07:45:34 -0800 (PST) MIME-Version: 1.0 References: <176254173597.1347.15997824594759319437@gauss> In-Reply-To: From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Sun, 9 Nov 2025 16:44:57 +0100 X-Gm-Features: AWmQ_bn6ilOZh8h0i7pfo_ckf1I8k0A6YUUTW4Ub91lvwqrl4DlqwblAp16aZ-Y Message-ID: To: J Pan Cc: starlink Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ZS5X6ZJHTQZRS73M52DPAWHWY2FOJ2TG X-Message-ID-Hash: ZS5X6ZJHTQZRS73M52DPAWHWY2FOJ2TG 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: [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: 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/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 wire= less 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 laye= r 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 t= o 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, h= ow is the transport layer getting info nowadays about the path characterist= ics 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 n= ot 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.C= A/~pan > >> > >> On Fri, Nov 7, 2025 at 2:51=E2=80=AFPM David Fern=C3=A1ndez via Starli= nk > >> 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 - Bandwidt= h 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 gr= eat 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-li= ke > >> > > 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 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-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=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 u= nderstand the > >> > > >>> > sentiment but find the issues more nuanced than that. :-) > >> > > >>> > > >> > > >>> > If you can get clear audio, not much quality is needed for p= anels and > >> > > >>> > talking beads. Best would be a feed right into an iPhone/a= ndroid. > >> > > >>> > > >> > > >>> > 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.net