Consumer products with baked-in VLAN tagging

Wed Apr 8 21:19:11 UTC 2015

On Wed, Apr 8, 2015 at 1:21 PM, Robert Seastrom <rs at seastrom.com> wrote:
>
> On Apr 8, 2015, at 1:58 PM, Dave Taht <dave.taht at 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 35Mbit the bottlenecks and
latencies move to the wifi. Which is often horrible at even lower
rates. That project is called make-wifi-fast, which is documented
elsewhere. Fixes are starting to land, like "minstrel-blues" - somehow
wifi has to scale to the increased densitity of 10 billion more
devices in the next 5 years.

>> Do they also supply that vlan to the ethernet?
>
> You mean to the southbound ethernet when running as a router instead of to the northbound ethernet while running as a bridge?  No idea.  That's not my normal use case.

With multiple APS routing guest to guest over ethernet makes sense on
the VLAN also.

>
>> How is their ipv6 with comcast?
>
> Beats me.  No Comcast handy to test with.
>
>  I *can* tell you that a freshly factory reset Airport Express 802.11n (2nd Generation) aka A1392 - the currently for sale $99 one - does pretty much exactly what you would hope when plugged into a freshly rebooted cablemodem on Another Pretty Darned Big MSO.  That is to say, it gets a PD /64 and you're off to the races with native IPv6 on the wireless side.  No warranties expressed or implied, but it seems to do what it says on the tin.

I hope to be able get the /60 often distributed (comcast does /60s and
I think /56s now) with an apple device also. I will check. Thx for the
update, as you noted the 3rd generation was hopeless here.

>
> A similar test with a freshly factory reset Airport Extreme 802.11n (3rd Generation) aka A1301 is disappointing; default configuration is IPv6 link local only and although there is a knob to put it into "native/automatic" IPv6 configuration it doesn't work as advertised.  But hey, it was discontinued five and a half years ago at this point so what do you want?  I figured that a test with an even older example I have sitting around in the junk box (A1143) would be similarly unsatisfying.
>
> I'd really like to try these native IPv6 tests with my Verizon FIOS at home, but I think I already know the outcome...

I know people that reliably use hurricane day in and day out to get
ipv6 tunneled over fios. Static ipv6 tunnels are so much easier than
dynamic ipv6 native.

> -r
>
>

[1] The only place where pie won was with insane amounts of
bittorrent, and on vpn access, on benchmarks that were unrealisticly
emulating behaviors of both. Other benchmarks - gaming and web access,
and other typical use cases, sfq_codel smoked it. and fq_codel is
better than sfq_codel.

-- 
Dave Täht
We CAN make better hardware, ourselves, beat bufferbloat, and take
back control of the edge of the internet! If we work together, on
making it:

https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking