<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Let's split this thread and use this message to continue the discussion of L4S. Thanks<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 8, 2024, at 5:31 AM, David Fernández via Starlink <<a href="mailto:starlink@lists.bufferbloat.net" class="">starlink@lists.bufferbloat.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">I have seen two consecutive RFCs to 9330:</div><div class=""><a href="https://www.rfc-editor.org/info/rfc9331" class="">https://www.rfc-editor.org/info/rfc9331</a></div><div class=""><a href="https://www.rfc-editor.org/info/rfc9332" class="">https://www.rfc-editor.org/info/rfc9332</a></div><div class=""><br class=""></div><div class="">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...)<br class=""></div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">David F.<br class=""></div><div class=""><br class=""></div><div class="">
Date: Tue, 7 May 2024 08:46:03 -0400</div>
From: Dave Collier-Brown <<a href="mailto:dave.collier-Brown@indexexchange.com" target="_blank" class="">dave.collier-Brown@indexexchange.com</a>><br class="">
To: <a href="mailto:starlink@lists.bufferbloat.net" target="_blank" class="">starlink@lists.bufferbloat.net</a><br class="">
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem<br class="">
Message-ID: <<a href="mailto:3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com" target="_blank" class="">3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com</a>><br class="">
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br class="">
<br class="">
It has an RFC at <a href="https://datatracker.ietf.org/doc/rfc9330/" rel="noreferrer" target="_blank" class="">https://datatracker.ietf.org/doc/rfc9330/</a><br class="">
<br class="">
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.<br class="">
<br class="">
I suspect My Smarter Colleagues know more (;-))<br class="">
<br class="">
--dave<br class="">
<br class="">
<br class="">
<br class="">
On 2024-05-07 08:13, David Fernández via Starlink wrote:<br class="">
Is L4S a solution to bufferbloat? I have read that gamers are happy with it.<br class="">
<br class="">
Sorry, I read it here, in Spanish:<br class="">
<a href="https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone" rel="noreferrer" target="_blank" class="">https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone</a><br class="">
<br class="">
Regards,<br class="">
<br class="">
David F.

</div>
_______________________________________________<br class="">Starlink mailing list<br class=""><a href="mailto:Starlink@lists.bufferbloat.net" class="">Starlink@lists.bufferbloat.net</a><br class="">https://lists.bufferbloat.net/listinfo/starlink<br class=""></div></blockquote></div><br class=""></body></html>