On Wed, Apr 8, 2015 at 1:21 PM, Robert Seastrom r...@seastrom.com wrote:
On Apr 8, 2015, at 1:58 PM, Dave Taht dave.t...@gmail.com wrote:
I do wish they had bufferbloat-fighting queue managment on the ISP
side, it is otherwise
pretty good hardware.
Again, I LOVE the apple gear - with stuart cheshire the godfather of
the bufferbloat movement I would have expected apple to use these new
algos long ago. They have sufficient infrastructure to do a better UI
and distributed internet test infrastructure than anyone except
google.
I suck at UIs. Apples are great. They could fix bufferbloat on all
their edge hardware in a matter of days.
As you're well aware since your name is in the acknowledgements, there's been
some effort in this direction at CL.
And sometimes I wish it wasn't.
If the problem gets solved in the CMTS and the CM, what the router does is
kind of beside the point
Sore points here, sorry for the noise on your thread.
Been at this for 4.5 years now. Comcast, closer to 7. I am getting
older, waiting.
A) I have seen no public sign of progress from the CMTS makers that
they are implementing any fixes. The only public sign of a fix came
from ARRIS´s CTO 2 years back, and they got a nice improvement (4 way
set associative hashing) in to SFQ but got their AQM horribly wrong.
http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Presentation.pdf
http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf
I would certainly like it if the CMTS makers made a public
announcement as to their plans and schedules for addressing
bufferbloat on their side. After fixing the uplinks with a fq+aqm, the
downlinks also tend to be seriously overbuffered, and any sufficiently
long download (one just slightly longer than speedtest!) can trigger
unacceptable latency.
If their fixes require new hardware it will be a decade before we see
them in the field. Thus - it seems better to continue fixing bloat on
users equipment, and not waiting for them and their ISPs downstream to
get off their duffs. (and multiple cable ISPs are desperate to try
anything! anything! that will get bufferbloat off there list of
problems especially for their business customers)
Someone here feel free to bug Arris, Cisco, and casa-systems as to
their CMTS update plans and schedule.
B) sfq_codel was the algorithm that won the benchmarks before the
numbers got extensively jiggled to favor docsis-pie.
The test results were ultimately gamed, the sfq_codel implementation
de-optimized ridiculously, and the tests absurdly weighted, to make
the pie algorithm come out (barely) on top, in simulation. I have
tried not to be too publicly bitter about this.
Follow up tests using the algorithm in the real world shows it
performing worse on a wider variety of workloads than fq_codel.
I STILL support docsis-pie! as it is vastly better than what exists
today, but have taken refuge in the fact that the docsis 3.1 CM
specification also allows for better fq/aqm technologies to be in the
box.
C) Since the docsis-3.1 evaluations, of course, fq_codel has swept the
aftermarket firmware market, is now the default qdisc in fedora 22,
arch and other linuxes, shipped in ubnt´s edgerouters, and in vyos,
part of click, and available across the board in all linux
distributions... and a derivative (sch_fq) serves up over 25% of the
internet traffic in the world...
... and there is not one single sign of a pie deployment in the real
world. I look forward, very much, to my first docsis 3.1 modem to play
with...
and I do hope some CM maker pays attention to the alternate AQM
portion of the DOCSIS 3.1 specification, some CMTS maker fixes their
gear where I live, and I can quit this task and go back to making
spacecraft.
But, until then... We hack.
Upcoming is a refinement of fq_codel, now under test, which I hope we
will also get into BSD and things like pfsense later this year. Let me
know offlist if you are interested.
In this chart I included current docsis 3.0 behavior here (and you
can´t take the extra bandwidth in the default as real, it is set to
native for that portion of the graph, I do have emulated results to
show around - but you can take the latency as real!) :
http://snapon.lab.bufferbloat.net/~d/cake3-fixed/baseline.png
Cake works to manage inbound rates at 115Mbit/12Mbit (a now common
cable rate) on cheap hardware, so anyone that wants to, can fix their
network for themselves on their own gateways and firewalls. We hope to
shave more cpu off of it as we finalize the algorithm.
I can´t wait til CMs and CMTSes showed up. :) Aside from the huge
induced latency problems, I honestly quite like cable internet, and
the ipv6 stuff - aside from being dynamically renumbered at the drop
of a hat - is pretty good also. I can´t wait til I can buy a static
/48.
(unless we've progressed to wanting to do it on the wireless side too).
Yes! we have progressed to that side. Our datasets (mlabs, others)
show that once downlink bandwidth cracks
