[Bloat] Computer generated congestion control

[Dave Taht]

Several items about remy:

1) The core flaw in the work was that they targeted really long RTTs
(>100ms) where here we are working in a range of RTTs, mostly shorter.
I would have been much happier had the work continued (has it?) to
look at solving for all RTTs passing through the network. That said,
solving for long RTTs is a hard problem with real world use cases.

2) There is this persistent opinion in academia, notably in the e2e
folk, that > 100ms of delay is "ok".

We *never* defined a limit to bufferbloat in the original definition
of the word - because we did not know what a good limit was!

Several otherwise good papers then go forth to define "bufferbloat" as
RTTs greater than 200ms, and then through statistical legerdemain show
that it doesn´t exist (my favorite was the one that discarded half the
data just to start with, then chopped off everything above the 95th
percentile). I referenced one of those papers in my rant at sigcomm:
http://conferences.sigcomm.org/sigcomm/2014/doc/slides/137.pdf

... where we in the aqm world have settled on about 20-30ms as the
outer bound for induced delay, and fq world, 5ms for sparse flows. I
wish we could come up with another word, or better define bufferbloat
than we have, to have real numbers in it. Closest we have come is:

https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/

3) I for one welcome our new congestion algorithm producing computer
overlords! The job is too hard for humans! I thought this work on remy
was astoundingly promising and hope that work continues. In
particular, *thinking* about congestion control as a meta problem was
a breakthrough. If remy could produce results that achieved 5-25ms
added latency e2e - or it got extended to managing the routers
inbetween - I could quit this and go back to working on spacecraft.

Many of the other products of this group of people are really amazing
(mosh for one, the mahimahi and delayshell stuff also
https://github.com/ravinet/mahimahi )

If you are not using mosh for all your day to day interactive traffic,
particularly on wifi you are annoying yourself for no good reason. But
try the mosh-multipath work if you want to get on the bleeding edge...

(note on mahimahi delayshell - there was a bug in that in that it
assumes an infinite queue. I am not sure to what extent that was used
in the remy work. There are patches for adding codel to it in a branch
that I had discussed with keith a while back, I hope that got merged.
(I meant to do it myself, forgot to take the day out I needed)

I would like it if those producing test tools took a hard look at
leveraging mahimahi in particular (I am looking at you... facebook) )

https://github.com/ravinet/mahimahi

4) Another MIT paper that I really liked was one that specified a FPGA
in every router - not that that idea was cost feasible today - but it
set me to thinking about what problems in this space could be better
solved in gates, rather than code, what could be considered as
massively parallel, and so on. I initially thought they were crazy...
but after thinking about it a while I worked out a set of cool things
that could be one day reduced to chips and would like to work on
them....

That is partially why I have been backing this kickstarter project
https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking
 as it gets the cost down to something a grad student could afford...
but it seems likely that they won´t raise another 25k in the next 6
days to produce their first batch of boards.

Note: They added a "get one give one" program at my request....
Anybody got a spare 25k to subsidize a whole bunch of really cool
boards that cut the cost on a FPGA based home router re-design from 7k
to 700 dollars? anyone???
I can think of a dozen+ people with the chops, if not the money, to
work on FPGA based stuff.