I see that L4S is not really solving everything (I read about issues with Wi-Fi), although it seems to be a step in the right direction, to be improved, let's hope.
At least, Nokia is implementing it in its network gear (for mobile operators), so the bufferbloat problem is somehow acknowledged by industry, at least initially or partially. I have seen two consecutive RFCs to 9330: https://www.rfc-editor.org/info/rfc9331 https://www.rfc-editor.org/info/rfc9332 I suspect that optimal results require the bufferbloat to be addressed not only at network layer (IP), but also with some pipelining or cross-layering at link level (Ethernet, Wi-Fi or any other link technology, such as 5G, SATCOM, VHF...) Regards, David F. Date: Tue, 7 May 2024 08:46:03 -0400 From: Dave Collier-Brown <dave.collier-br...@indexexchange.com> To: starlink@lists.bufferbloat.net Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f45...@indexexchange.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" It has an RFC at https://datatracker.ietf.org/doc/rfc9330/ I read it as a way to rapidly find the available bandwidth without the TCP "sawtooth". The paper cites fc_codel and research based on it. I suspect My Smarter Colleagues know more (;-)) --dave On 2024-05-07 08:13, David Fernández via Starlink wrote: Is L4S a solution to bufferbloat? I have read that gamers are happy with it. Sorry, I read it here, in Spanish: https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone Regards, David F.
_______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
