[Bloat] RED against bufferbloat

[Dave Taht]

On Thu, Feb 26, 2015 at 10:59 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> On Thu, 26 Feb 2015, Dave Taht wrote:
>
>> First, everyone saying that fq_codel can't be done in hardware is *wrong*
>> See my last point far below, I know I write over-long emails...
>
>
> What do you define as "hardware"?
>
>> YES, at the lowest level of the hardware, where packets turn into light or
>> fuzzy electrons, or need to be tied up in a an aggregate (as in cable) and
>> shipped onto the wire, you can't do it. BUT, as BQL has
>
>
> I am talking about doing this in the NPUs that are available on the market
> today and in the future.
>
> We're talking about these kinds of devices:
>
> http://www.tilera.com/News/PressRelease/?ezchip=97

Wow. That is one impressive piece of hardware.

> I'm afraid that your experience with CPU driven devices isn't a great match
> here, and we're talking past each other.

To a certain extent we were. Thank you for dropping the above link
into the conversation.

1) I mostly care about fixing the end user devices. Which can easily
have enough horsepower to cope with whatever cheap crap the ISP wants
on their side. Sure, there are a lot of trendlines that are negative
here, the world I wanted to live in had a standard for jack you
plugged into a the wall, which you could then do anything you wanted
with, from gear you could buy from any retailer.

2) I realize that you (at least) want to do the best job possible with
the best gear available on the market, and I respectively submit that
the best thing that you can do is to avoid vendor lock.

3) If that chipmaker is unable to run a simple benchmark of their
shaper + qos system, vs the sqm-scripts with fq_codel, and not realize
that that they could, indeed, do much better, I wouldn't do business
with them.

> I would love to be able to use my employers purchasing power to drive demand
> on AQM, but I need to know what the requirements are, and that they're
> feasable to do, preferrably with an engineering effort for the vendor in the
> range of few man years. I can't produce this document myself, I have already
> tried pointing them in the direction of presentations etc, but I need "hard"
> documents, outlining exactly what they need to do.

Sucks to be you.

I am glad a few other people here care enough to help create the
needed paperwork.

As for me: I am *done* with doing big company's essential R&D for them
for free. I spent my entire retirement savings on fixing bufferbloat
in the first year alone, and have been living a hand to mouth
existence ever since. I just went through a 4 month month period with
no revenue at all. I live in a yurt, the cheapest housing I could find
in california, just so I could maintain sufficient independence to
kick the entire industry in the ass, and never have to filter a single
word, or commit through, a patent attorney, ever again.

Given that so much great stuff is now happening - I am thinking I can
finally quit. Everybody gets it now, and I am really tired of it (and
a lot of people are tired of me being such a nag about it!), and I
want to go off and do something else - anything else! But it would
have been nice somewhere along the way to have landed a position that
kept a better roof over my head, and eliminated some of my stressors
and uncertainty, and still let me keep kicking the industry in the ass
on a regular basis. Maybe, I dunno, I will quit this and go for a PHD
and get a chance to write a ton more stuff down, at least, and do
something genuinely new...

But - as much as I might want to quit - I can't quit yet.

I have one *last* thing left on bufferbloat that I care about, and
that is fixing wifi, for the 2.8+ billion current users and the
billions of new devices left to come. While I am glad we have at least
theoretically fixed the edge, wifi was the actual problem that I
started with, and there had accumulated so many fundamental problems
since I had last paid attention to it, that it has taken 2+ years
since clearly identifying what the problems there were, to having come
up with code-able fixes, to get ready to even start.

There is still quite a bit of theory work left to be done to get it
right, and a ton of rearchitectural work in the kernel and the device
firmwares themselves left to do.

Solving *wifi problems* is what has kept me awake at night - and
despite stumping around the world for the last two years to try to
raise sufficient awareness and funding to tackle the job, have still
only raised 1/10th the funds I thought would be required to do it
right.

And I am going to go start doing it anyway, starting last week, with
some of the fiercely talented volunteers we have here, pitching in to
help - and some of the the few clued companies also pitching in - and
we are going to get it done - and THEN I can quit this f-ing
self-assigned job that I took on as a favor to jim and vint and esr,
and go work on some VC's concept for the next pets.com and watch the
money start rolling back into my 401k.

If anyone here works at a company that cares that wifi gets genuinely
better, for everybody, please contribute a resource, or ante up:

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

I know I am not the only person that cares deeply about wifi, but
blows my mind how few seem to understand that it doesn't need to suck
- given what we now understand about fixing bufferbloat.

> Do we have this currently? In that case, whereto should I point them?

Does the ID not help?

>
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb