[Bloat] fixing bufferbloat in 2017
dave.taht at gmail.com
Wed Nov 23 13:17:56 EST 2016
On Wed, Nov 23, 2016 at 9:54 AM, David Lang <david at lang.hm> wrote:
> On Wed, 23 Nov 2016, Mikael Abrahamsson wrote:
>> If Comcast sells you 100/20 (I have no idea if this is a thing), you set
>> your upstream on this box to 18 meg fq_codel, and then Comcast
>> oversubscribes you so you only get 15 meg up part of the time, then you're
>> still bloated by the modem. This is not a solution.
>> I don't think "buy $thing, install *WRT on it, configure it like this" is
>> above most gamers, but I'm afraid we don't even have a working solution for
>> someone with that kind of skillset.
> perfect is the enemy of good enough
I agree that we are getting close to the point where we can recommend
several off the shelf products to home and small business users. In
addition to the netduma, there's the edgerouters, and the asus-merlin
on arm, and turris omnia. There is also ipfire, and pfsense is coming
along as well.
There are multiple other commercial products whose methods could be
benchmarked and evaluated, notably meraki, google wifi, eero, plume,
and portal. The latter two i believe are openwrt based. eero is
debian. google wifi is it's own thing, not fully buildroot, debian,
chromeos, or brillo. There are more than a few others - linksys itself
is closely tracking the work nowadays - and in most cases folk are
using automated tests to configure things. I'm pretty sure eero has
got the qos work working along the edge, and the google folk are well
aware of the work and I hope pushing towards deployment on the gfiber
and onhub products (the "google wifi" stuff ships dec 7th, don't know
a lot about it). Meraki has a fq_codel like solution and airtime
fairness being rolled out in beta mode now, I'm told.
There's also the longstanding qca streamboost stuff.
I have an issue with these latter products in that most are claiming
the benefit comes from their cloud based analytics software, rather
than better algorithms, and I'm allergic to snoopy stuff on my core
network equipment sharing anything about my network activity with a
"private" cloud. This is one of the few places where my politics has
got in the way of doing better science. Google has been good with
networks, as no doubt eero has, but I've never been in a position
where ethically I could deal with this in our projects (nor, if I did,
could I cope with the potential liability). I have been grateful for
what bits of data google was willing to publish.
I would love to see a barracuda ship something for small to medium
business, or something of that caliber from a cisco
> stop trying for perfection, you will never be able to address all problems.
> But we already have several options that would address the very real
> problems people are having if they could just be deployed.
> you don't even need to use cake and worry about what your uplink bandwidth
> is if you can just use fq_codel on the real edge device. The fact that it is
> almost impossible to buy a router that has a DSL interface on it, so you
> have to try to artificially move the bottleneck is a problem.
I do regard the total lack of one bql-enabled dsl device firmware as a
real market disappointment.
Similarly, a lack of transparency into whatever is shipping in
multiple big ISP's gear - notably the FIOS folk are very good about
the GPL side of their stuff, but it's never been clear that they've
been paying attention - at least one FIOS device I tested had sfq on
outbound by default.
I have spent a bit of time on an upcoming cablemodem product that I
can't talk about but I am presently very frustrated with how it abuses
linux's network stack.
> Deploy what we already know to work on the real edge devices and things get
> vastly simpler.
> David Lang
> Bloat mailing list
> Bloat at lists.bufferbloat.net
Let's go make home routers and wifi faster! With better software!
More information about the Bloat