[Cake] Cake implementations

[Toke Høiland-Jørgensen]

"Adam Moffett" <adam at plexicomm.net> writes:

>>>
>>>  Are there any commercial products already using Cake?
>>
>>Evenroute, eero, ubnt top that list. Evenroute's implementation is
>>superb, the first one that used active line measurements to handle
>>"sag". Anything derived from openwrt (somewhere between 10-30% of the
>>home router market). I'm not sure if preseem is using it or not.
>>dd-wrt. Most other things doing "SQM" are doing it via htb + fq_codel.
>>
>>
> An idea which was floated was to experiment with routing ISP customer 
> traffic through a Linux server using cake to improve customer 
> experience.  Basically like Preseem.  My colleague has toyed with it a 
> bit in small test cases and was impressed with the outcomes.
>
> He's looked closer than I have, but I'm trying to picture how his idea 
> would scale.  I believe I'm seeing a CLI tool for configuring policies.  
> It seems like we'd have to create a middle layer to create/update 
> policies for customer's IP address based on information obtained from 
> our AAA and CRM systems.  I can picture some shapes that might take, but 
> I think it would ultimately have to revolve around scripting the tc 
> command.  There would be thousands of policies and a policy would be 
> created/updated whenever a subscriber reconnects (e.g. when a DHCP lease 
> renews or a RADIUS auth event happens or similar).

I know several ISPs that do this (route traffic through a Linux box and
shape there). This deployment mode has not been the primary focus of
CAKE, though; the "standard" way to do it is with HTB+FQ-CoDel, which
allows you to set up arbitrarily complex configurations on a single
interface. This can also be made to scale, but there's a central qdisc
lock in Linux that you have to get around to scale to multiple cores.
Fortunately, Jesper has already solved this particular issue:

https://github.com/netoptimizer/xdp-cpumap-tc

> Should we even pursue this idea?

In my own totally non-biased opinion: Yes! :)

> Although most staff who would touch this will have studied programming 
> in college, I would not qualify any of us as "programmers" per se.  My 
> biggest concern would be hitting a service affecting problem that we 
> can't solve.

One way to go about this would be to open source the entire solution.
There are already bits and pieces available as open source (such as
Jesper's repository above, and sqm-scripts[0]) that you can build on,
and this way you could enlist community help to solve any issues with
the Linux side. You'd still need to get the data from your internal
systems, of course, but you could define a simple configuration format
that was part of the open source code; then you'll just need to write a
script that grabs customer info from your CRM and outputs the config
format...

> Second concern is that many of our equipment vendors already use
> Linux. Even Cisco now in some products. Maybe we'll waste our time
> trying to roll our own solution and then find that a software update
> from a vendor next year gives us everything we needed anyway.

This would be great, of course, and do go and bug your vendors to solve
this problem! Note, however, that just because a system is running
Linux on the control plane, it may be using a hardware-offloaded data
plane that does not have any of the bufferbloat mitigation features
(unless the vendor specifically implemented them). I'm hoping that
*eventually* these things will be ubiquitous across the industry, but
thus far this has seemed to be an "any decade now" kind of proposition :/

-Toke