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

I am appreciating this email thread. It is really hard to “sell” the features ala carte. They need to be bundled into reference packages. This you know. > The wisps totally got it with fq codel and cake arriving native for mikeotiks > entire product line and much of ubnts gear prior to that.

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

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

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

Sorry - I meant ~ 4,5 % of the ISPs, not 2 :) All the best, Frank Frantisek (Frank) Borsik https://www.linkedin.com/in/frantisekborsik Signal, Telegram, WhatsApp: +421919416714 iMessage, mobile: +420775230885 Skype: casioa5302ca frantisek.bor...@gmail.com On Wed, May 8, 2024 at 9:58 AM

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

Just to add the latest numbers from our (LibreQoS) ongoing "QoE competitive landscape research": Out of 66k plus ISPs worldwide, barely 3k use some QoE middle-box. Preseem is the market leader, with well over 400 T2 & T3 ISPs (number shared in their wonderful Fixed Wireless Network Report 2024 Q1

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

This was a wonderful post, rich! I note that preseem, paraqum, bequant and libreqos (a bufferbloat.net backed project) are in the fq codel or cake Middlebox for isps *Qoe) market and all of us have made a substantial dent in the problem for oh, call it 1000 isps worldwide total between us.

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

Thanks Frank, So it is not the universal cure. Not surprising. I don’t see a show-stopper for pushing adoption. Gene -- Eugene Chang IEEE Life Senior Member IEEE Communications Society & Signal Processing Society, Hawaii Chapter Chair IEEE Life

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

Here is a current view of it, IIRC: https://forum.openwrt.org/t/rfc9330-rfc9331-rfc9332-for-lower-latency/180519/12 All the best, Frank Frantisek (Frank) Borsik https://www.linkedin.com/in/frantisekborsik Signal, Telegram, WhatsApp: +421919416714 iMessage, mobile: +420775230885 Skype:

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

I thought I saw a reference to an OpenWRT implementation with L4S. How well does that work? Gene -- Eugene Chang > On May 7, 2024, at 9:46 AM, Dave Taht wrote: > > Pete heist, jon morton, and rod grimes published a TON of research as > to where

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

Pete heist, jon morton, and rod grimes published a TON of research as to where l4s went wrong in these github repos: https://github.com/heistp The last was: https://github.com/heistp/l4s-tests?tab=readme-ov-file#key-findings They were ignored. Me, I had taken one look at it 7+ years ago and

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

On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink < starlink@lists.bufferbloat.net> wrote: > The RFC is very plausible but the methods break down in multiple ways, > particularly with wifi. > Dave, can you elaborate more on the failures? Are these being researched or addressed in the

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

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 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

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

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

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

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

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

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 To: Eugene Y Chang Cc:

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

Oh goodness, I wasn't suggesting that we had a total solution, I was pointing out that the gaming community was missing the point, even with evidence in their hands. That suggests we have not made the point to a technically aware part of our community. --dave On 2024-05-06 20:43, Eugene Y

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

Hi Gene, > On May 6, 2024, at 8:38 PM, Eugene Y Chang 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

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

Dave, We just can’t represent that we have the total solution. We need to show the problem can be reduced. We need to show that latency is a significant negative phenomena. Take out one contributor and sic the users to the next contributor. If we expect to solve the whole problem in one step, we

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

Rich, Thanks for the recap in the email. I have seen all of those bits. I will help with the marketing magic needed. We need a team of smart people engaged to help vouch for the technical integrity. We need a simple case (call it a special case, if you must) that shows the problem can be

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

Thanks! I just posted to: https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/ It has mild edits from the original to address a broader audience. Also posted to the bloat list. Rich > On May 6, 2024, at 3:05 PM, Frantisek Borsik > wrote: > > Hey Rich, > >

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

I think that gamer experience doing simple (over-simple) tests with CAKE is a booby-trap. This discussion suggests that the real performance of their link is horrid, and that they turn off CAKE to get what they think is full performance... but isn't.

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

Hi Gene, I've been vacillating on whether to send this note, but have decided to pull the trigger. I apologize in advance for the "Debbie Downer" nature of this message. I also apologize for any errors, omissions, or over-simplifications of the "birth of bufferbloat" story and its fixes.