"My understanding is that everything Cisco and Juniper is wred. It can handle huge bandwidth amounts due to offloading to the ASIC, but is almost certainly much worse than any of the newer AQM solutions. I believe those running Cisco and Juniper have no ability to even consider codel or fq_codel or cake on the service provider side. "
Cisco has AFD now. Both providers have switches that can do P4 for which there is fq-codel. But it is still early days for the big iron and offloads there.
“I suppose the difference is how much these AQM technologies are really designed to be used on the client side vs the service provider side. If I was daring enough to upgrade our core routers to 7.1 (I am not), what would make the difference - should we do cake queues for each customer at the ISP end, or should we deploy local cake queues to their routers, or should we do it on both ends? And if we should do at both ends, then why?”
It would be pretty cool if fq-codel or cake were backported to the most popular stable shipping mikrotik release. That’s how we got deployment on ubnt’s gear, initially.
You just used the word “core routers” and mikrotik in the same sentence. My impression was that the big iron was core, mikrotik more of a leaf? In all honesty I don’t know much about mikrotik’s stuff outside of their wireless gear and a few switches. Another thing I don’t know much about is the prevalance of MPLS, or even the possibility of running a fiber interface on whatever standards deloyed for it at a physical line rate?
Ideally an ISP would running fq_codel everywhere at line rate (using sch_fq instead for tcp heavy servers), and replace an existing HTB + FIFO shaper (if you have any, and I really hope that the default for most ISPs in the mikrotik market is presently HTB + SFQ) with HTB + FQ_CODEL, or cake, flowing in the customer’s direction, and the CPE, cake on the uplink.
Inbound shaping is more cpu intensive than outbound (and less accurate), and yet at the same time most home routers have so much more CPU that stuff at the headends that it may well be that a primitive shaper at the ISP is what remains, in use, in which case, inbound/outbound shaping via cake with better communication from the ISP of the actual configured rate to the CPE or router behind it (And and ongoing changes thereof), is one of my deepest wishes. There are PPPoe and DHCP messages for that now, and cake was designed to take a message and be able to dynamically change the
bandwidth to the link without interruption of service. Most of the confusing noise on the web today is from users attempting to correctly infer the ISP’s set rate, and it really needn’t be this complicated. Evenroute, for example, has means of scraping quite a few DSL modems built in, but it would be so much better to have a dsl modem or ONT that told you it’s rate so a cake could set it.
"I ask this because most of the documentation I have seen about cake and fq_codel is about what the client should do rather than what the ISP should do. There is a lot of useful information geared towards the regular end user, but very little geared towards ISPs who want to improve services for their users. "
Until now there was very little direct ISP deployment (though evenroute and eero I am told do do deals with ISPs). I’d like to change that. My hope was that a string of smaller, more nimble mikrotik based ISPs would leap all over this stuff, share data, build better backends, or, like preseem/libreQos, etc, build something that leveraged this tech that could actually have a business model. A blog from an ISP that deploys this would be nice. I LOVED that Comcast published this B/A comparison study: https://arxiv.org/pdf/2107.13968.pdf they were rolling out DOCSIS-PIE and had one modem with a broken implementation of that so they used that opportunity to do some really compelling, unique science.
Me, wearing my scientist’s hat getting a chance to look at and publish an ISP’s data as they deploy, would be nice. There’s more problems in this world than just network queuing, too.
It’s kind of hard to monetize or support or write extensive documentation on something as simple to just turn on as fq_codel or cake are, essentially one line of configuration, each. In writing this and the page we started from ( http://forum.mikrotik.com/t/some-quick-comments-on-configuring-cake/152505/1 ) my hope has been to provide a deeper understanding of network behaviors, better benchmarking and analysis tools, and clear demonstrations of the end-user benefits of deploying these technologies to all the users. The rest is up to y’all. I’m very interested in feature requests for cake, and in benchmarks of enabling fq_codel on the higher end mikrotik gear. Benchmarks of web PLT, MOS scores and statistics about loss, marks, backlogs, and delay I’d love to see.
If I have any one feature request of mikrotik’s future releases, is that I’d really like those statistics to be available, and secondly, we’d put in a couple nice optimizations for ipsec and wireguard in linux 5.7 for fq-codel that are very useful for site-site vpns.