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

[Dave Collier-Brown <dave.collier-Brown@indexexchange.com>]

[-- Attachment #1: Type: text/plain, Size: 12323 bytes --]

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 Chang via Starlink wrote:
> 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 end up where 
> we are and effectively say the problem is too complex to solve.
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> IEEE Communications Society & Signal Processing Society,
>     Hawaii Chapter Chair
> IEEE Life Member Affinity Group Hawaii Chair
> IEEE Entrepreneurship, Mentor
> eugene.chang@ieee.org
> m 781-799-0233 (in Honolulu)
>
>
>
>> On May 6, 2024, at 2:11 AM, Dave Collier-Brown via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> 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.
>>
>> https://www.reddit.com/r/HomeNetworking/comments/174k0ko/low_latency_gaming_and_bufferbloat/#:~:text=If%20there's%20any%20chance%20that,out%20any%20intermittent%20latency%20spikes. 
>>
>>
>>  (I used to work for World Gaming, and follow the game commentators 
>> more that I do now)
>>
>> --dave
>>
>>
>> On 2024-05-06 07:25, Rich Brown via Starlink wrote:
>>> 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. Corrections welcome.
>>>
>>> Rich
>>> ------
>>>
>>> If we are going to take a shot at opening people's eyes to 
>>> bufferbloat, we should know some of the "objections" we'll run up 
>>> against. Even though there's terrific technical data to back it up, 
>>> people seem especially resistant to thinking that bufferbloat might 
>>> affect their network, even when they're seeing problems that sound 
>>> exactly like bufferbloat symptoms. But first, some history:
>>>
>>> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 
>>> 2011 [1] couldn't believe it, and he's a smart networking guy,. At 
>>> the time, it seemed incredible (that is "not credible" == 
>>> impossible) that something could induce 1.2 seconds of latency into 
>>> his home network connection. He called in favors from technical 
>>> contacts at his ISP and at Bell Labs who went over everything with a 
>>> fine-toothed comb. It was all exactly as spec'd. But he still had 
>>> the latency.
>>>
>>> This led Jim and Dave Täht to start the investigation into the 
>>> phenomenon known today as "bufferbloat" - the undesirable latency 
>>> that comes from a router or other network equipment buffering too 
>>> much data. Over several years, a group of smart people made huge 
>>> improvements: fq_codel was released 14 May 2012 [3]; it was 
>>> incorporated into the Linux kernel shortly afterward. CAKE came in 
>>> 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 
>>> 2018. In 2021 cake-autorate [4] arrived to handle varying speed ISP 
>>> links. All these techniques work great: in 2014, my 7mbps DSL link 
>>> was quite usable. And when the pandemic hit, fq_codel on my OpenWrt 
>>> router allowed me to use that same 7mbps DSL line for two 
>>> simultaneous zoom calls.
>>>
>>> As one of the authors of [2], I am part of the team that has tried 
>>> over the years to explain bufferbloat and how to fix it. We've 
>>> spoken with vendors. We've spent untold hours responding to posts on 
>>> assorted boards and forums with the the bufferbloat story.
>>>
>>> With these technical fixes in hand, we cockily set about to tell the 
>>> world about how to fix bufferbloat. Our efforts have been met with 
>>> skepticism at best, or stony silence. What are the objections?
>>>
>>> - This is just the ordinary behavior: I would expect things to be 
>>> slower when there's more traffic (Willfully ignoring orders of 
>>> magnitude increase in delay.)
>>> - Besides, I'm the only one using the internet. (Except when my 
>>> phone uploads photos. Or my computer kicks off some automated 
>>> process. Or I browse the web. Or ...)
>>> - It only happens some of the time. (Exactly. That's probably when 
>>> something's uploading photos, or your computer is doing stuff in the 
>>> background.)
>>> - Those bufferbloat tests you hear about are bogus. They 
>>> artificially add load, which isn't a realistic test. (...and if you 
>>> actually are downloading a file?)
>>> - Bufferbloat only happens when the network is 100% loaded. (True. 
>>> But when you open a web page, your browser briefly uses 100% of the 
>>> link. Is this enough to cause momentary lag?)
>>> - It's OK. I just tell my kids/spouse not to use the internet when 
>>> I'm gaming. (Huh?)
>>> - I have gigabit service from my ISP. (That helps, but if you're 
>>> complaining about "slowness" you still need to rule out bufferbloat 
>>> in your router.)
>>> - I can't believe that router manufacturers would ever allow such a 
>>> thing to happen in their gear. (See the Jim Gettys story above.)
>>> - I mean... wouldn't router vendors want to provide the best for 
>>> their customers? (No - implementing this (new-ish) code requires 
>>> engineering effort. They're selling plenty of routers with 
>>> decade-old software. The Boss says, "would we sell more if they made 
>>> these changes? Probably not.")
>>> - Why would my ISP provision/sell me a router that gave crappy 
>>> service? They're a big company, they must know about this stuff. 
>>> (Maybe. We have reached out to all the vendors. But remember they 
>>> profit if you decide your network is too slow and you upgrade to a 
>>> faster device/plan.)
>>> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
>>> - Besides, I just spent $300 on a "gaming router". Obviously, I 
>>> bought the most expensive/best possible solution on the market (But 
>>> I still have lag...)
>>> - You're telling me that a bunch of pointy-headed academics are 
>>> smarter than commercial router developers - who sold me that $300 
>>> router? (I can't believe it.)
>>> - And then you say that I should throw away that gaming router and 
>>> install some "open source firmware"? (What the heck is that? And why 
>>> should I believe you?)
>>> - What if it doesn't solve the problem? Who will give me support? 
>>> And how will I get back to a vendor-supported system? (Valid point - 
>>> the first valid point)
>>> - Aren't there any commercial solutions I can just buy? (Not at the 
>>> moment. IQrouter was a shining light here - available from Amazon, 
>>> simple setup, worked a treat - but they have gone out of business. 
>>> And of course, for the skeptic, this is proof that the 
>>> "fq_codel-stuff" isn't really a solution - it seems just like snake 
>>> oil.)
>>>
>>> So... All these hurdles make it hard to convince people that 
>>> bufferbloat could be the problem, or that they can fix for themselves.
>>>
>>> A couple of us have reached out to Consumer Reports, wondering if 
>>> they would like a story about how vendors would prefer to sell you a 
>>> new, faster router (or new faster ISP plan) than fix your 
>>> bufferbloat. This kind of story seemed to be straight up their 
>>> alley, but we never heard back after an initial contact. Maybe they 
>>> deserve another call...
>>>
>>> The recent latency results from Starlink give me a modicum of hope. 
>>> They're a major player. They (and their customers) can point to an 
>>> order of magnitude reduction in latency over other solutions. It 
>>> still requires enough "regular customers" to tell their current ISP 
>>> that they are switching to Starlink (and spend $600 to purchase a 
>>> Dishy plus $100/month) to provide a market incentive.
>>>
>>> Despite all this doom and gloom, I remain hopeful that things will 
>>> get better. We know the technology exists for people to take control 
>>> of their network and solve the problem for themselves. We can 
>>> continue to respond on forums where people express their dismay at 
>>> the crummy performance and suggest a solution. We can hope that a 
>>> major vendor will twig to this effect and bring out a mass-market 
>>> solution.
>>>
>>> I think your suggestion of speaking to eSports people is intriguing. 
>>> They're highly motivated to make their personal networks better. And 
>>> actually solving the problem would have a network effect of bringing 
>>> in others with the same problem.
>>>
>>> Good luck, and thanks for thinking about this.
>>>
>>> Rich Brown
>>>
>>> [1] 
>>> https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf
>>> [2] 
>>> https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
>>> [3] 
>>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html
>>> [4] https://github.com/lynxthecat/cake-autorate
>>> [5] 
>>> https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos
>>>
>>>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink 
>>>> <starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Of course. For the gamers, the focus is managing latency. They have 
>>>> control of everything else.
>>>>
>>>> With our high latency and wide range of values, the eSports teams 
>>>> train on campus. It will be interesting to see how much 
>>>> improvements there can be for teams to be able to training from 
>>>> their homes.
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>> IEEE Communications Society & Signal Processing Society,
>>>>     Hawaii Chapter Chair
>>>> IEEE Life Member Affinity Group Hawaii Chair
>>>> IEEE Entrepreneurship, Mentor
>>>> eugene.chang@ieee.org
>>>> m 781-799-0233 (in Honolulu)
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@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@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@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@indexexchange.com  |              -- Mark Twain

[-- Attachment #2: Type: text/html, Size: 30963 bytes --]