Dave, Thank you for calling attention to the RFC. I took a quick peek, and I need to put more time into reading the whole doc. It feels very intuitive.
What I like is that it is written for incremental adoption. I will focus on that in my next pass. It opens the door to be incrementally deployed to pacify an influential squeaky wheel. I like the possibility that a happy squeaky wheel becomes a role model attracting more squeaky wheels until it makes more sense to just adopt broad deployment. If you read my earlier emails, you know I am in the hunt for an influential squeaky wheel. :P Anticipating more discussion in this direction, are there core router vendors that have a favorable view of L4S? Are there router implementations just waiting to be turned on? Gene ---------------------------------------------- Eugene Chang > On May 7, 2024, at 2:46 AM, Dave Collier-Brown via Starlink > <[email protected]> wrote: > > It has an RFC at https://datatracker.ietf.org/doc/rfc9330/ > <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 >> >> <https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone> >> >> Regards, >> >> David F. >> >> Date: Tue, 7 May 2024 06:50:41 -0400 >> From: Rich Brown <[email protected] <mailto:[email protected]>> >> To: Eugene Y Chang <[email protected] <mailto:[email protected]>> >> Cc: Sebastian Moeller <[email protected] <mailto:[email protected]>>, >> Colin_Higbie >> <[email protected]> <mailto:[email protected]>, Dave Taht via >> Starlink >> <[email protected] >> <mailto:[email protected]>> >> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem >> Message-ID: <[email protected] >> <mailto:[email protected]>> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Gene, >> >> > On May 6, 2024, at 8:38 PM, Eugene Y Chang <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > It seems like you signed off on this challenge. Don’t do that. Help give >> > me the tools to push this to the next level. >> >> Not at all - I'm definitely signed up for this. But I collected all these >> points so we can be clear-eyed about the objections that people cite. >> >> Bufferbloat definitely exists. And there are straightforward technical >> solutions. And as you say, our challenge is to find a way to build the case >> for broad adoption of these techniques. >> >> Best regards, >> >> Rich >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/ecb7b91e/attachment-0001.html >> >> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/ecb7b91e/attachment-0001.html>> >> >> >> _______________________________________________ >> Starlink mailing list >> [email protected] <mailto:[email protected]> >> https://lists.bufferbloat.net/listinfo/starlink >> <https://lists.bufferbloat.net/listinfo/starlink> > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > [email protected] > <mailto:[email protected]> | -- Mark Twain > > CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any > and all attachments, contains confidential information intended only for the > person(s) to whom it is addressed. Any dissemination, distribution, copying > or disclosure is strictly prohibited and is not a waiver of confidentiality. > If you have received this telecommunication in error, please notify the > sender immediately by return electronic mail and delete the message from your > inbox and deleted items folders. This telecommunication does not constitute > an express or implied agreement to conduct transactions by electronic means, > nor does it constitute a contract offer, a contract amendment or an > acceptance of a contract offer. Contract terms contained in this > telecommunication are subject to legal review and the completion of formal > documentation and are not binding until same is confirmed in writing and has > been signed by an authorized signatory. > > _______________________________________________ > Starlink mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/starlink
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Starlink mailing list [email protected] https://lists.bufferbloat.net/listinfo/starlink
