[Bloat] Fixing bufferbloat in 2017

[Rich Brown]

Dave Täht attempts to refocus the group, and asks: 

> Can I encourage folk to think big and out of the technical box?
> 
> On Tue, Nov 22, 2016 at 7:32 AM, Dave Taht <dave.taht at gmail.com> wrote:
>> What's left to do?
>> 
>> What else can we do?
>> 
>> What should we stop doing?
>> 
>> What can we do better?

Lots of good thoughts on this thread. 

My impression is that we have reached a strong technical point. We have solved some really hard, really significant problems. We are in a position to Declare Victory on a large part of the problem, even though there are loads of details to clean up.

Most of the suggestions in this thread deal with Getting the Word Out. That's good - that's the declaring victory part. The bad news is that this is not our collective skill set. 

Some thoughts about what we *can* do:

1) Toke et al published (are publishing?) a scholarly paper on the make-wifi-fast efforts that "looks like real academic research" (by *actually being* academic research :-) This makes it credible to other academicians, and throws down the gauntlet with a low latency value that others need to improve upon. (No more academic papers that say, "We really worked hard, and got latency down to 100 ms. Aren't you proud of us?")

Are there other papers bottled up inside team members?

2) I wonder if we would gain credibility by updating the bufferbloat web site. I see two things that could be done.
	a) Change the www.bufferbloat.net home page to use a one-page design (see, just as an example, https://bootstrapmade.com/demo/Baker/) with sections that address our primary constituencies: Home users, Gamers, Manufacturers, Software Developers, and Network Researchers. It adds a bit of polish, while keeping our message simple. People can drill down into the (existing) pages for more information. 
	b) We should make a pass through the site, organizing according those constituencies, and removing content that is no longer relevant.
	c) I also grabbed the DNS name "makewififast.com" in case we want to use it.

3) I think it's great to contact reviewers - ArsTechnica and AnandTech were mentioned. (I did reach out to Wirecutter and ask that they incorporate bufferbloat tests in their router recommendations. I was disappointed by the total radio silence.)

4) Do we know people at any of the cell phone companies, or router vendors on whom we could try one last push?

As part of organizing my thoughts for this note, I also collected the following ideas from this thread. I add my $0.02 below.

Rich

1) I don't see that Ookla has much incentive to include bufferbloat measurements in their test, since they private-label it for lots of ISPs who (presumably) wouldn't want their CPE to be proven crappy. ("It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" -Upton Sinclair)

2) The gamer community seems like such a perfect target for these improvements. But I fear that the thought leaders are so wrapped up in the fame generated by their own clever QoS tricks that they can't believe that fq_codel plus the make-wifi-fast fixes could possibly address such a complicated subject. (Upton Sinclair, again.)

3) On the other hand, Comcast (whose DOCSIS modems *might* someday support PIE or other SQM) is in a position to benefit from an increased awareness of the phenomenon, leaving a little ray of hope.

[Note - I wrote 4 & 5 below before I learned of IQrouter... I'm still skeptical of the mainline router vendors adopting this technology anytime soon into their stock firmware.] 

4) I do wish that there were a way to we could stop saying, "Just update your router firmware (trust us...)"  as a solution. It would be so much better to say, "Just buy this low-cost (or medium-cost) router that'll make you supremely happy."

5) But I'm not hopeful that any of the COTS router vendors are going to adopt these techniques, simply because they've been impervious to our earlier entreaties. That doesn't mean we shouldn't try again - it'd be a helluva competitive advantage to incorporate the 25-50 man years of intense software development that has gone into this work.

6) It *is* a good idea to think about attracting the attention of vendors who are hurt by bufferbloat - VoIP, video streaming folks, gaming companies, etc. But it feels like the wrong end of the lever - a gaming company can't fix crappy CPE, and they're stuck saying 

7) Cell phones are another place that obviously would benefit, although, again, it's hard to break through the notion that "It's always been like that..."

What else?

Rich