[Starlink] The "reasons" that bufferbloat isn't a problem

Dave Taht dave.taht at gmail.com
Tue May 7 15:11:22 EDT 2024


The RFC is very plausible but the methods break down in multiple ways,
particularly with wifi.

On Tue, May 7, 2024 at 12:10 PM Eugene Y Chang via Starlink
<starlink at lists.bufferbloat.net> wrote:
>
> 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 <starlink at lists.bufferbloat.net> wrote:
>
> 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.
>
> Date: Tue, 7 May 2024 06:50:41 -0400
> From: Rich Brown <richb.hanover at gmail.com>
> To: Eugene Y Chang <eugene.chang at ieee.org>
> Cc: Sebastian Moeller <moeller0 at gmx.de>, Colin_Higbie
>         <CHigbie1 at Higbie.name>, Dave Taht via Starlink
>         <starlink at lists.bufferbloat.net>
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <175CC5C3-F70A-49E8-A84D-87E24C04EABD at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Gene,
>
> > On May 6, 2024, at 8:38 PM, Eugene Y Chang <eugene.chang at ieee.org> 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>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> 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
> dave.collier-brown at indexexchange.com |              -- 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
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
Dave Täht CSO, LibreQos


More information about the Starlink mailing list