On Wed, Apr 8, 2015 at 1:21 PM, Robert Seastrom <rs@seastrom.com> wrote:
On Apr 8, 2015, at 1:58 PM, Dave Taht <dave.taht@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-hardw...