From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=gmx.de header.i=moeller0@gmx.de; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=gmx.de policy.dmarc=quarantine Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mail.toke.dk (Postfix) with ESMTPS id 74A5193F8A7 for ; Mon, 10 Nov 2025 07:43:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1762757018; x=1763361818; i=moeller0@gmx.de; bh=oCx8shVkUiQQyzs69FjFJlEh70LnVH4cBSDEx1GhSTg=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=Ng0S7LQSwN+eBFIZYRxRLPgW3Et7Z9jzdNCczhS+Lh6No/1JXIwnclm11313R1Z8 TemP9jtRerzNgA6M3bkiQ1qWG/zPj/Lii3EHCPwDlDkAnbWWQ1OaLxYfCU4vHbWCR ipRiSlQ7GWZsq71+2/XAaejzdgrbYa6N0vUHe1OlYwKPJbWAN/GYG9/zAhP5OJVWk hz32NR2cvaGgWJca9czzQkhvx2Uc0u1S1MOuiD9hX/sAhfTOzS5xIhsBIvtMavqrn rzNNzP8aJx8yANgx53XIUNJy/roMUVXsmQZqmexgcFfrN9Kh3EZcIQtZGKliHrCFf KoG5+VJeaJuw5OdKPQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ehlo.thunderbird.net ([80.187.114.136]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0oFz-1w5WMZ0Q5t-010Kyy; Mon, 10 Nov 2025 07:43:38 +0100 Date: Mon, 10 Nov 2025 07:43:32 +0100 From: Sebastian Moeller To: Ulrich Speidel CC: starlink@lists.bufferbloat.net User-Agent: K-9 Mail for Android In-Reply-To: <4196b569-d999-4559-90d5-ae084083df27@auckland.ac.nz> References: <176254173597.1347.15997824594759319437@gauss> <7A603AC1-0A9F-4A71-80E5-3C0B187266BA@gmx.de> <4196b569-d999-4559-90d5-ae084083df27@auckland.ac.nz> Message-ID: <801561B0-DB00-49BF-89C6-C95F19327E8D@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:tr8AZVimWOlTQmxOlbZYpMVD9jGbzUXzzhMl0Kwg1vy3TOL8lV4 IydP4t4Ylbb+q/EyzkZInTOpIMOJuaHa24/mA3iKsXuKaLUmcw9O7hzw/K0JCBXrUR7CtWl m1dLrl5ZckWi1+uJQsyt2R6Sqi6dFzXwBzBHCI5YeikD1D0JHil7k7N7DAesObQfHEaDMA/ WZg3DyEdnHzfUZUa0SdVg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:MVEG1k+I+Pg=;fpS27AuYt+XBLb1wesVnSOB+Ryg xIrJdU6RI+6y29nRMBh3pyc3qMqUwswcYtPFcdgKjcXdtTr7zF/Agahc3UQjZrM4l+QAnQRW9 MIzrS6JdgZ6QeLNgXOTqRtKhh0gSpHoPgs3ZG/8rJXiL1ShDfBofs7HloTNChKQFLaaqfa6XG XJVzj3kQKyrmSU0WwgplGUvr+m0oaR1HhnURp1mK3gAEFyM6KjecVMJSHn4fBxvExG1pAq5So W7IYBdqsMJDk4m1gvAifSUrBqoJl3FVUWCwOiQpGLOXUrCbwstWY9Fc17MuijQSHAv3rQwfgN WqhBRyVNjHjHh306B+0xg3LVjsZpilCb0MxIPjLmtWSFXu6jmQHCDJz0QBZPWS+Z5Wl0rRqmL oIqZZBsgULR2fRMr+oBIvZUICEsKeji+r+mR5tz1uCdXAe9cQGtfym3FnDgoXLMtIh4Vwx0P8 vs8S9JUPX30n/FJufN1rl4hhE7I1U4+pdHryHjrvqecjCqaXM/FzAfVUFPnQJIGnSz79gSXAO We5fckTbNCc9m3r3iOSz7WYiSXx1joSQW3V8Y9ZEq2BnzUhcDf8rSnhrTHrsGjZ0NjF3iTXCZ QxMTmqh3VYyyYV4DsGeG4/GhCvlg0mMJ8kGBc+A6981vlbqjTYzS2LT1APpAnGMwh20CrF42D Dq4WAVuvR/ncggMwqHjqPvvArxPz1T/sPXtEgi/wkk/F8x/QWt0i49SvBNSjIGWa/DsEzRtG6 ksBssal2sPpNWz5VIJ3Ax1mV/ULSBob2/bmcB1SOtGPcFAiXfSD9/fk5Xco1XE69AygehQQwc DSxKeWHcNrxTVZIG1niQMElpCQpDOtHqlyE+CdVQtiYfU35fOvDA7HrdgijDEfdlXxywv32Ba n4ak99O14ChIWKGKhjG/ipmwsEmeQt24Y5hsB21CJEAuhRFl1kBgmE8b4PLvGspnbcrAsO8DD nU+Z7zoNnjlK69JmKLNAvndZyd35f4c6nbKf53hXzJ6rfPPW/QiPspeM2mEXbMIifayuno59v R0C2NLlgIYwgUCsiTMM4dJAJafNFZ4/BTlBxIlf1HMTsO5p8bxjMr+bgPi2qLKiAtcuRrEQKv usraTWz//ViWTBLE8gpBq91vGw+M2nqvE5W5HFW6O3PGwH+eL4mIhq850GCy8ZXObvPO88pgO jPrcjBcjPtKzndl8BTDEFpd9tu3pk4Mq9ENPWlDmF+Iy4Ax7s6u1heMz2qZnxYtfwkp2rUIK9 iA/PwPy7YkP6L9+wkZ7QMBM6L/Frh2RA/+v9uWNxSxnNslTMbobgGjA2J/He+Hfu07GEkErh0 8USv6Urx3qlTppRAxMjCrRN6/TA7fMpcFEKE2IznmGlhr0yB5qhCIN/A2Kb0nAFInCzgEPxC1 CxcX+Om3qHUXR3licVqlBwvM6bUDa8AzRJymTgsagLLQz3TbFou2e3bLdZL7vpFqWAFWeo8lR plfj1OVfepOwFpbl4fFzUukAnWwYCOyoN/Hh27XIPF+M+zhMBo/JjgecaKmuy5SVqnTS+X4iZ 6hCvjtJPgfb8aleqWf1/YlM+cvcn/b2tmsYHK5SYNNOUcJGSDMKjF1aiXBW7CgiQfkdTRwQAb rcqCGZ7eGNPbf4hAjZdzJpqN+p8z2AHsc6fDfTIK3Oc5LEtLr+w1ZpRr396lOVN2hyKnvn92h ydYMlj0rYfVcJ5wxBVYuniBoh6qlKbKWvOqGVV/XXX7Nh2dZzsISBE6F+WPdV9mCgRB+XRc7w 1YZrom4VnEhoC3JkaRWwjjhpA9W4+fdKs4T0Uxppd/Mx5cUDv0fFiv4e8QCDCMtFSWoXLF7vU NCd1dC+xxICDi2PElccr14VTW50z3mw2qk2rCOKV68oxszhFYOlyUBU/JVrjTnjijxpHZ0383 szyPCfLXahdIJBcDxLupwek+B9otR0I8Vw2n0ljYoCQyzbQiAFvZfQmbJ6WKkJEQcW5Xz5y75 BwqpsUYjo9cdN8KLHJEglGcq94cAAX8Cx3Ej6qsWTNpsA8fxDTII4+CPqvuT6j7ztU25kxxOF eSIecrmkdQDRq+IReI3jM6AYt0xmOAg4N2/nHQYijOlsD30Y8dlHR4jhD5Y87D+rERYZlAyup lfm3/isRmB3efEvuxzYgi5wOZU+bV3H57167+X7VMYFkdzHVrfPo+XfbpoWRu8X4mavnLhuiz DFgF2z1x6HU1fmxl5LNODOidbp1zsuHRssHjt4s4QkndQTkYlswU5EOqW2Lrm/LwYK2Bw0rg6 fkGlprySjKOhPgeAsTw8eiXvVoSh7N4yg6fTuJ/ZswO0DmSaHLcepcDqlIBBTjeMhH37hL8Aj FbXXw/W2Pv4zQA9gk+ITLNUOVMnhzW52zdhZBsq7Ld3MoMMpZ42+RC0mA6q/czLqAGb3Tj8i8 DcfXblZi9tnt5XgnB0TLibqqNMxv6HBlGRO/PoHQTx/VUkg6NX8PP9Cdx+gfg+kc1oSiICpoE vJduVpjyoaWYjFYQiImTSXDHHi+0dsOR1ak4zl8bqpbfe3S1KI4gOhWnXy4Zw+MtO5tLmE/nh fzJjrUmJQ5y8AbAWxUX0VhZy1JYveAWc6/jzn0Kg7gUoFdF1QodvHRihLrek57P6zcJAzbzbe tRlhe5Y3fmDl1j/wFxcREzsDoGErmk4yf0ugEDZDzII78AzeSBPq5Ux4U/D80TXX6a9lHrvrw vRf4if0LUK0KJi8yb0XAeoRJ8IyuPJz81CP1qBnrtZfT9QHBkLGsLFAnQBth+qsN2upYjXEBH KBPoaHtDvg9G2SFsURHUYPRVyYTWKWBf471L66ubi59mxyOfXtMk1VAhjVpBJ0cisi9QjA45Z fK+OdVpDLgFtgsBxeqvKNXwvwhbj/Cy8UBdEa7GxzVtc70Sfl3ASKSFHbdHD59F093z+1owI3 AA3WBkTmupri2M2lJSrMzkojiYCvfPrzejtenXYf1YAEKgbo/eXe5lZwG9BjJfYCl08u4K/4S m+2ZB9q5h9Zrx2ZsJGUOr0/v1kymrdp7/0uRWHsII404i5WO1ZE2ZFf522tJVVgqLhqqBq++Z FhaxwEaOIPe6gU+llgGqgxENFERuorjieFkb7AnB+EY2ANV66n5i7hc1XwAApHMFLL26G4WfQ 3Bl9e2ozdykpipR0xFcfJzj2/MCiPFbohK1vxqgZrYvMgB6PmWwhHJMSQTlyT+Hbbn71IU1Cn TJG7Xmmqqg+zNcUWJYDQxFg8vshmgRDXOWeqADrzhX+qr7ayW1N9dbooeqNVk2vvBBs6Ipx71 cbv7Ep4IN2e1oSr8Zm+305Rtv7FydGp//Tvz8QszbExsze5OkEuyfbL8454Jofi6KEDNQc0/I fmrY11e71QfL++ipxw+6i/a/223/jsd6Ry1CCSApAZiOvD/qvYZg5+YGzolP2N00NVPe9FfcF n6iUixr8HjCe82BOZB2mOSZ6lrCf5/T1XbtO/CW6kpRmBRZgQwMZmMIPSPToNV0HJXG32YGFa JRh1HItIBaCfL6b0w69p2C351hqnKobsW7DT6rS6k8zr60b97DMKuEEf7u4yD5VX/KEW4QqVZ mLzofQMbYfHJGwd1vb5syR2uJ72n0GQUlrINpViCcWoVVfzHdJ/iUH/PS6sjEBc7YwKdZnAHu ZAt7vAChkuC3XRwLsJ2UEfvMswweRCed1Uh52E6BNaRMIuIdZZONfHPYZT5SWDmA8zD42t8jl aHVnQ9/0h0x5bcvaSfDriAQxRZvaccsuH/uQ2e5zzIJvAhCEU6SUGde9AJYOTI9CpqjjiOB6l zVEjGrSxgIgb+1CkImt5YCa+KyFf8sK+BmwCLLkVaZaq9aY1rBUTZwVWPOtcA845OJFXEeYGZ /UdcCF2B2x277QhtnZb+t1Z3dL2XtzP9llhoMLZdxFrcM+RG9DsvduKQeNgTC2NnQ9DK4wrv8 2OXYIy/xjPZ+VlQhL0ChL55zciLAtKL0QpYoTE8C4bq5ROjx4uexy1pgtoKF8Kdl/ATgNQffG FXxO5JhJEWESlWwrZ3tTs7WK06nO5Qm0rBN1ddwG2ggnHJCq0Lye3EmgTYOZ6j5SgVnwTD9ji 2ppzCFNIYZg1MkzYCgOURl89uCoPkoAyrc1cmShN32Cit2teHb5Y0foPn9LqU30j9L8fsrJqy ZVYPc63b/ite1shJ42yGEVQnZjpRdvDKgC+OMmuPiWa3YRf1x6R0Y3KQRFFYdBbA6MLRxzzAL 9SNDqE1OKwR12RU0+8C/Ad2ZM+CjBz2O9t8scoIKwe8gRLU9B8xunLmb2wnljSbIcoSiz3ju4 oVvkGvCPEOjHh/NXhGloZSRq6JTI30K8H8IbaOeX+0rhy8ATnMM9N+CkaiN1BMa1IVqWs4oe8 +VrFVIjGbmTfWchulIUMWlIdRCjuCj5+OmhqsA2GvuJLEeiMfnCXUtqElzaBqEOyWpx8xr1Bf lR7WB3ZEFVnQNhy32mdb8pJtX2GilZtcntlkI4oZr1Ah1mG8wzAZRITeVcybiyXwZCRXDm32G l1Uf5EnowJZUX0I3w1KNfSwskheRw+gL7o/XSMdZJ+Vl1zDq8uFpvRXtAOCFML6QLQPb1cM0x ckz2YP3iaRTmqak6iWeVUeeKDgMtU7RagTszX4OCwzgT6eSDQiG6bbkBetndHK2p0DfMYxpcW W92fPEXwaYQ+eOF58xOjGdsSOJOlDOEnPnwPkho0FxAZ5atlt8YobJQcNYDFlEnFnCQEHeqND BRfPvQgcARJYgVDXnuYmLoellR5yCiVDNdwHB26iuJHlipSdHm1VXYof9ZWYFsL3YnP/7iHeo yf2es2+yfSQUFIkSsR8pVGPhyrd6OITygR700Dki866vDa/IfssyYr8Vk+PWHViWv72kYsjQ0 pgpSlGtg7ZY1HQ0DabFpxrsShPfKT9zUfxFfsVMg0ABcO94oeRZRYfIS5aRGwvDeiAX9YcpjS PTPhrejHehDU2GR28rR5A0NMnDx5jcyMSdRVJ00Ot/4Q3jFouI3b7Kd8kDLyO0X4IgRggi6va Me6f88gLnL0N9vPCFE88ELJY6tlzqFgYbukDTjHw5VSpgM24VOhrPrtL0EhRu7p22Kk7dh36V +XyaX9srCOgCZdAXJ+vhh+ThUNP7agTGv60npZ4r3Kv7+yxs+QYL3KZZgqj0Bu2DpYVR2MU37 YBeJ3XHB3WCXAkfRPcjJPJdnLZZZIQpzgme/dkha62uBcCMvPMOa1OJ2XXsEEpxu+Wj8UEQpv mQLUxEBk= Message-ID-Hash: W62LZSMEJX7OJVY2RAADGL3DRF4Q3YG3 X-Message-ID-Hash: W62LZSMEJX7OJVY2RAADGL3DRF4Q3YG3 X-MailFrom: moeller0@gmx.de 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: Hi Ulrich, as so often on this list(s) great discussion with loads of interesting fac= ts=2E On 9 November 2025 21:08:50 CET, Ulrich Speidel wrote: >On 10/11/2025 7:42 am, Sebastian Moeller wrote: >> Hi Ulrich, >>=20 >>=20 >>> On 9=2E Nov 2025, at 02:03, Ulrich Speidel via Starlink wrote: >>>=20 >>> Starlink is a bit unusual in terms of its packet loss mechanism=2E >>>=20 >>> In "normal" networks, we have damaged packets (low SNR or interference= leading to symbol errors in the modulation that then translate into bit er= rors and failing checksums), queue drops as part of the normal congestion c= ontrol behaviour, and - not sure how much of a problem this still is these = days - receive window overflows=2E >>>=20 >>> In the case of Starlink and handovers, there appears to be an uplink q= ueue for uplink to each satellite on the gateway side of things=2E Suppose = your dishy talks to sat A first and then gets handed over to sat B=2E Up un= til handover time, packets heading to your dishy get sent to the queue for = sat A, thereafter to the queue for sat B=2E These queues appear to be diffe= rent and - with different packets and different volume in them - seem to le= ad 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=2E As A now no = longer talks to you, this packet is now on a road to nowhere=2E >>>=20 >>> Of course, this loss only ever happens at handover time=2E No such thi= ng as a uniform distribution here=2E 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=2Eg=2E, some QUIC = implementation or somesuch)=2E >>>=20 >>> On the latency vs=2E bandwidth debate: To me, this seems a bit like ar= guing whether width or height are more important for area=2E Both matter, a= nd both are equally badly understood by marketing folk=2E >>>=20 >>> If your video needs to stream X Mb/s to the viewer, then the channel b= etween the sender and receiver needs B > X Mb/s of available and accessible= bandwidth=2E That's why bandwidth matters=2E Basta=2E >> Well, you are of course right=2E However for almost all interactive use= -cases the capacity that is actually usable by an application (and where le= ss capacity results in noticeably worse results, while more capacity does n= ot increase the perceived quality any more) is well below the access capaci= ties that are sold=2E >> For example page load times do generally not improve once the capacity = exceeds 20-25 Mbps, FullHD streaming needs 5-8 Mbps, 4K streaming (still ra= re) 15-20 Mbps, videoconferencing typically also needs less than 20 Mbps, a= nd traditional VoIP only takes around 100 Kbps (per direction)=2E=2E=2E eve= n cloud gaming at high spatial and temporal resolutions (with short time wi= ndows to compress the video) only requires more than 65 Mbps (for 5K@120 Hz= )=2E And remote desktop is quite mild >> So if we are generous and/or want to allow multiple concurrent users 50= -100 Mbps is the capacity that will cover most typical interactive use-case= s quite well=2E And at that point halving the latency will result in a bigg= er improvement than doubling the capacity=2E=2E=2E > >It boils down to the "available and accessible" bit=2E There are various = reasons for why an application may not be able to access bandwidth even tho= ugh it is available=2E And that can even be the case when you average over = a large number of users=2E Ak, okay, I had not understood accessible that way, but that is quite sena= ible avdefinition=2E > >When we looked into the first MEO link into the Cook Islands 10 years ago= , we found that the local ISP wasn't ever seeing more than 50% bandwidth ut= ilisation on their international link, yet the locals were quick to complai= n about the service=2E A lot of finger pointing went on but the culprit was= actually TCP congestion control over a long latency bandwidth bottleneck= =2E The ISP's monitoring tool looked at average bandwidth utilisation over = a time period of many RTTs, which masked the fact that the input queue to t= heir sat link was oscillating between tsunami and drought conditions=2E The= bandwidth that was available after everyone had backed off wasn't accessib= le=2E Yepp, longer term averages tend to hide fine temporal scale events ;)=20 > >> (I like your area model conceptually, yet increasing latency does not i= mprove things, reducing does)=2E >Yes, that's taken as read I guess ;-) >>=20 >>=20 >>> The "accessible" part of the bandwidth is where the latency comes in= =2E Remember the goal is to hit bandwidth-delay product on the lowest bandw= idth link along the forwarding chain of your packets, i=2Ee=2E, to make sur= e you have that bit of pipe filled=2E It's a lofty goal because whatever yo= u do in terms of increasing or decreasing your sending rate only has an eff= ect some time later, by which time the conditions you're trying to respond = to may have changed=2E Your picture of the current conditions is always out= dated (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=2E That change is among others driven by algorithms that= are possibly trying to fill a different pipe, or has at the very least a d= ifferent (time-shifted) view of the conditions at the pipe you're trying to= fill=2E This is a fundamental control problem, not a matter of BBR over BI= C or Reno or Vegas or whatever you've tried on ns2=2E >>>=20 >>> There are things that make this control problem a little easier: lower= latency obviously, but also exclusive links (or at least fewer competing f= lows if you can't get exclusivity), fewer bandwidth bottlenecks along your = hops and bottlenecks that are more predictable, i=2Ee=2E, where the input q= ueues get processed at a constant processing rate=2E 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)=2E It's also wh= y CDNs are so popular: They combine low latency with less competition for b= andwidth and fewer hops=2E >>>=20 >>> Starlink's challenge is that their bandwidth per cell is limited=2E No= t quite to the point where it's a problem everywhere, but certainly to the = point where it's becoming a problem in some places=2E If you're being asked= to pay a congestion surcharge when you sign up, you're in one of those pla= ces=2E Moving to fq_codel and bringing down the latency has made more of th= at bandwidth accessible, but again there's a limit to what you can do there= - it's not like reducing latency increases total bandwidth=2E >> True, yet proper scheduling and AQM makes links that operate around sat= uration point still quite usable even for interactive use-cases=2E >I'm not arguing with this - but there's a short distance between "around = saturation point" and "beyond saturation point"=2E True that, this is why the game here is to push the traffic down to never = cause full saturation (for too long), easier on fixed rate links, trickier = on variable rate links=2E >>=20 >>=20 >>> 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=2E1%, mostly due to satellite handover, so for the netf= lix >>>> open connect appliances inside starlink pop, they can do some >>>> starlink-specific optimization to mask away the handover for starlink >>>> users, e=2Eg=2E, https://oac=2Euvic=2Eca/starlink/wp-content/uploads/= sites/8876/2024/09/leonet24-victor=2Epdf >>>> -- >>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic=2ECA, Web=2EU= Vic=2ECA/~pan >>>>=20 >>>> 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=2E In the= wireless 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= layer errors uniformly distributed and not higher than 0=2E1%, for TCP, wh= ile for wireless links carrying only VoIP, using RTP and G=2E729 codec, up = to 1% PLR is acceptable=2E >>>>>=20 >>>>> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching u= p to 6% or more even, but TCP works anyway, somehow=2E It may be that CUBIC= and BBR are more robust to higher packet loss rates due to error than Reno= =2E >>>>>=20 >>>>> "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? >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> David >>>>>=20 >>>>> 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=2E >>>>>> 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=2E but now physical, link and network layer have more info = for >>>>>> the transport layer to make the right decision, e=2Eg=2E, 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=2ECA, Web= =2EUVic=2ECA/~pan >>>>>>=20 >>>>>> On Fri, Nov 7, 2025 at 2:51=E2=80=AFPM David Fern=C3=A1ndez via Sta= rlink >>>>>> wrote: >>>>>>> Thanks for sharing this Frank=2E >>>>>>>=20 >>>>>>> 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=2E Sometimes= , it >>>>>>> happens that they are not negligible, in some cases with wireless = links, >>>>>>> mainly, but it could happen too in DSL=2E I remember that I had a = DSL 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)=2E When packet losses due to= errors are >>>>>>> misinterpreted as congestion by the transport protocols, the resul= t is also >>>>>>> a band quality of experience=2E >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> David >>>>>>>=20 >>>>>>> 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=2E= bufferbloat=2Enet, >>>>>>>> Jeremy Austin via Rpm , l= ibreqos >>>>>>>> , Dave Taht via St= arlink >>>>>>>> , l4s-discuss@ietf= =2Eorg >>>>>>>> Message-ID: >>>>>>>> >>>>>>> uhiQPd3KOg@mail=2Egmail=2Ecom> >>>>>>>> Content-Type: text/plain; charset=3D"UTF-8" >>>>>>>>=20 >>>>>>>> Hello to all, >>>>>>>>=20 >>>>>>>> Recording of our QoE/QoS panel discussion is out! It was really g= reat and >>>>>>>> believe you will like it: >>>>>>>>=20 >>>>>>>> https://www=2Eyoutube=2Ecom/watch?v=3DT1VET0VYQ6c >>>>>>>>=20 >>>>>>>> We have touch bandwidth, L4S, Starlink and more=2E >>>>>>>>=20 >>>>>>>> Here are the slides with additional reading: >>>>>>>>=20 >>>>>>>> https://docs=2Egoogle=2Ecom/presentation/d/1ML0I3Av3DCtQDiP8Djr_Y= GH2r4-UDZP25VEk-xyJcZE/edit?slide=3Did=2Ep#slide=3Did=2Ep >>>>>>>>=20 >>>>>>>> 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=2E >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> All the best, >>>>>>>>=20 >>>>>>>> Frank >>>>>>>>=20 >>>>>>>> Frantisek (Frank) Borsik >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> *In loving memory of Dave T=C3=A4ht: *1965-2025 >>>>>>>>=20 >>>>>>>> https://libreqos=2Eio/2025/04/01/in-loving-memory-of-dave/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> https://www=2Elinkedin=2Ecom/in/frantisekborsik >>>>>>>>=20 >>>>>>>> Signal, Telegram, WhatsApp: +421919416714 >>>>>>>>=20 >>>>>>>> iMessage, mobile: +420775230885 >>>>>>>>=20 >>>>>>>> Skype: casioa5302ca >>>>>>>>=20 >>>>>>>> frantisek=2Eborsik@gmail=2Ecom >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Oct 1, 2025 at 11:32=E2=80=AFPM Frantisek Borsik < >>>>>>>> frantisek=2Eborsik@gmail=2Ecom> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Let's say that I love it, channeling my inner Dave Taht=2E 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=2E=2E=2Eand I was t= rying, but this >>>>>>>>> was really sticky and I'm happy that it stayed this way=2E >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> All the best, >>>>>>>>>=20 >>>>>>>>> Frank >>>>>>>>>=20 >>>>>>>>> Frantisek (Frank) Borsik >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> *In loving memory of Dave T=C3=A4ht: *1965-2025 >>>>>>>>>=20 >>>>>>>>> https://libreqos=2Eio/2025/04/01/in-loving-memory-of-dave/ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> https://www=2Elinkedin=2Ecom/in/frantisekborsik >>>>>>>>>=20 >>>>>>>>> Signal, Telegram, WhatsApp: +421919416714 >>>>>>>>>=20 >>>>>>>>> iMessage, mobile: +420775230885 >>>>>>>>>=20 >>>>>>>>> Skype: casioa5302ca >>>>>>>>>=20 >>>>>>>>> frantisek=2Eborsik@gmail=2Ecom >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Oct 1, 2025 at 9:25=E2=80=AFPM dan wrote: >>>>>>>>>=20 >>>>>>>>>> I actually really like the title ;) >>>>>>>>>>=20 >>>>>>>>>> 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= =2E So the >>>>>>>>>> vast majority of the time 'more bandwidth' as a solution really= is a >>>>>>>> lie=2E >>>>>>>>>> On Tue, Sep 30, 2025 at 2:47=E2=80=AFPM Frantisek Borsik via Li= breQoS < >>>>>>>>>> libreqos@lists=2Ebufferbloat=2Enet> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Thanks, Jim=2E Well, true that - but I wanted to do it either = way, >>>>>>>> because >>>>>>>>>>> of >>>>>>>>>>> our dear Dave and - as a conversation starter=2E >>>>>>>>>>> As @Jason Livingood said - "Ba= ndwidth is >>>>>>>>>>> dead=2E Long live latency=2E" >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>> https://pulse=2Einternetsociety=2Eorg/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=2E >>>>>>>>>>>=20 >>>>>>>>>>> PS: Sending you separate email=2E >>>>>>>>>>>=20 >>>>>>>>>>> All the best, >>>>>>>>>>>=20 >>>>>>>>>>> Frank >>>>>>>>>>>=20 >>>>>>>>>>> Frantisek (Frank) Borsik >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> *In loving memory of Dave T=C3=A4ht: *1965-2025 >>>>>>>>>>>=20 >>>>>>>>>>> https://libreqos=2Eio/2025/04/01/in-loving-memory-of-dave/ >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> https://www=2Elinkedin=2Ecom/in/frantisekborsik >>>>>>>>>>>=20 >>>>>>>>>>> Signal, Telegram, WhatsApp: +421919416714 >>>>>>>>>>>=20 >>>>>>>>>>> iMessage, mobile: +420775230885 >>>>>>>>>>>=20 >>>>>>>>>>> Skype: casioa5302ca >>>>>>>>>>>=20 >>>>>>>>>>> frantisek=2Eborsik@gmail=2Ecom >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Sep 30, 2025 at 10:25=E2=80=AFPM James Forster < >>>>>>>> jim@connectivitycap=2Ecom> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Wow, that=E2=80=99s fantastic, Frantisek! Great work making = this happen=2E >>>>>>>>>>>>=20 >>>>>>>>>>>> These sort of titles aren=E2=80=99t my favorite=2E I think I = understand the >>>>>>>>>>>> sentiment but find the issues more nuanced than that=2E :-) >>>>>>>>>>>>=20 >>>>>>>>>>>> If you can get clear audio, not much quality is needed for pa= nels and >>>>>>>>>>>> talking beads=2E Best would be a feed right into an iPhone/= android=2E >>>>>>>>>>>>=20 >>>>>>>>>>>> Jim >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> LibreQoS mailing list -- libreqos@lists=2Ebufferbloat=2Enet >>>>>>>>>>> To unsubscribe send an email to libreqos-leave@lists=2Ebufferb= loat=2Enet >>>>>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Starlink mailing list -- starlink@lists=2Ebufferbloat=2Enet >>>>>>> To unsubscribe send an email to starlink-leave@lists=2Ebufferbloat= =2Enet >>>> _______________________________________________ >>>> Starlink mailing list -- starlink@lists=2Ebufferbloat=2Enet >>>> To unsubscribe send an email to starlink-leave@lists=2Ebufferbloat=2E= net >>> --=20 >>> **************************************************************** >>> Dr=2E Ulrich Speidel >>>=20 >>> School of Computer Science >>>=20 >>> Room 303S=2E594 (City Campus) >>>=20 >>> The University of Auckland >>> u=2Espeidel@auckland=2Eac=2Enz >>> http://www=2Ecs=2Eauckland=2Eac=2Enz/~ulrich/ >>> **************************************************************** >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Starlink mailing list -- starlink@lists=2Ebufferbloat=2Enet >>> To unsubscribe send an email to starlink-leave@lists=2Ebufferbloat=2En= et > --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E