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-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by mail.toke.dk (Postfix) with ESMTPS id 3F026936496 for ; Sat, 08 Nov 2025 20:57:23 +0100 (CET) Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-786635a8ce4so15404487b3.2 for ; Sat, 08 Nov 2025 11:57:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762631842; x=1763236642; 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=tgrMm7NXdzA8QAM8dm9jHIvb91nfH2KIHfSrn6EzzmY=; b=Yq5m/6BHgrhadaz97QbR7sk+oX0NBjcXTWxzE+BYpOvDbDVWeKer0OtkAQYIR9p8f+ 1G7G4oad56KC6njukZo1qXyOaw7dsl/l8y/Mp3PkTyAdpX8GpVoCHNKijnye2gJfg0h0 9L2ZU3G9xw4lfoQI/Y0Gr5tf1pz53ilVyip3YIAtwwHYF8Oug4agCoJOrPx9NvfGfHk5 AluHoMbxVvVATi7ajmA34jNCU9BwyAsSvrTVUXf4o4bHWWazblKDkar6JEMwulVPTb0u G52SVZUeQRUt0PUqdh9GVShKr1dCW3bxzeHuzhMlcgz5GT4U7jy33xfGFGXRDr5N0HsS /4Hg== X-Gm-Message-State: AOJu0YwnHcuAbVyn4hziIG/oa5tZxbQSzBFlhWH3tsyhS4c+0Pn6HtKN BmHy8QKgKgtGnLQ1JxSAOAXwvoJdfaaMwCb/UgItQpnVDSlEGiG1pN3jHMV7HGB+ZC8GGcwLuXf Tl9wLtep6dtrPkK0vsDHRZI+xBMg31pC8N1n+3xM= X-Gm-Gg: ASbGnctfc2P3lpdJdHnqT3g2bNryLua6pP3rILzFQWLWkHporPrOZF9kEp/Pm2a1hxx /Mz69zs9zmg60btB9C+LiPhNBFbttNwCSXlke64bI2tquJQsCIgXjk8T0jbSBnPbmLbm3RIkIMu a4yS9RKewYquLZ8dgSg7pWSwFUukCAHfnTxU8zB1R5l8S6/bIRpRs1XtRua1pnemuHVlDnhMxgR 6B/yGxCinnxBqHZTDDBh2kfb2poV2itwp8o1d/lbqTd9IBMSdSK25CsuZhZ3GD+yO0c4NY= X-Google-Smtp-Source: AGHT+IESlcLfJs7QJTX3xDVMLvebRImJNOwvYrpeBN2mxUbJERCoiD2kIaXsaPk4y+APMm1cfWu+zmH2DTl6omVhmqQ= X-Received: by 2002:a05:690c:6ac9:b0:785:cbf4:72cd with SMTP id 00721157ae682-787d53524b1mr38174117b3.3.1762631842332; Sat, 08 Nov 2025 11:57:22 -0800 (PST) MIME-Version: 1.0 References: <176254173597.1347.15997824594759319437@gauss> In-Reply-To: From: J Pan Date: Sat, 8 Nov 2025 11:57:11 -0800 X-Gm-Features: AWmQ_bkI57WpCg3qcjXmc1dzodEgz75wAIMgZcmn_F4vliY3dF1tZpBxoraUIgs 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: PLKG7RNCAT4M7WVJNHHSMXPUOA7GNKOX X-Message-ID-Hash: PLKG7RNCAT4M7WVJNHHSMXPUOA7GNKOX 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: 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/202= 4/09/leonet24-victor.pdf -- J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pa= n 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 los= ses >> > due to errors, which could be analogous to pipe leaks. Sometimes, it >> > happens that they are not negligible, in some cases with wireless link= s, >> > mainly, but it could happen too in DSL. I remember that I had a DSL li= ne 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 error= s 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.bufferbloa= t.net, >> > > 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 grea= t 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-U= DZP25VEk-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 s= ee 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-l= atency >> > > >>> >> > > >>> 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 t= his happen. >> > > >>> > >> > > >>> > These sort of titles aren=E2=80=99t my favorite. I think I und= erstand the >> > > >>> > sentiment but find the issues more nuanced than that. :-) >> > > >>> > >> > > >>> > If you can get clear audio, not much quality is needed for pan= els and >> > > >>> > talking beads. Best would be a feed right into an iPhone/and= roid. >> > > >>> > >> > > >>> > 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