[Starlink] The "reasons" that bufferbloat isn't a problem
Dave Collier-Brown
dave.collier-Brown at indexexchange.com
Tue May 7 08:05:08 EDT 2024
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 at ieee.org
> m 781-799-0233 (in Honolulu)
>
>
>
>> On May 6, 2024, at 2:11 AM, Dave Collier-Brown via Starlink
>> <starlink at 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 at 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 at ieee.org
>>>> m 781-799-0233 (in Honolulu)
>>>
>>>
>>> _______________________________________________
>>> 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
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/29672f17/attachment-0001.html>
More information about the Starlink
mailing list