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 fixed.
Never mind if it is not a universal fix.
We only need to show one happy, very visible community.
Give me something to work with that we can defend from the list of do-nothing
reasons you list.
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.
An energetic, vocal community is very valuable. They aren’t satisfying if we
want to debate the technology. We shouldn’t care. We just want to win adoption.
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.ch...@ieee.org
m 781-799-0233 (in Honolulu)
> On May 6, 2024, at 1:25 AM, Rich Brown <richb.hano...@gmail.com> 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
> <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/
>
> <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
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html>
> [4] https://github.com/lynxthecat/cake-autorate
> <https://github.com/lynxthecat/cake-autorate>
> [5]
> https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos
>
> <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 <mailto: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.ch...@ieee.org <mailto:eugene.ch...@ieee.org>
>> m 781-799-0233 (in Honolulu)
>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
