[Cake] Using cake to shape 1000’s of users.

[Dan Siemon]

On Fri, 2018-07-27 at 00:38 +0300, Jonathan Morton wrote:
> It would also be valuable to have a firmer handle on the actual
> requirements in the field.  For example, if it is feasible to focus
> only on current Linux kernels, then a lot of backwards compatibility
> cruft can be excised when importing existing code from Cake.  If all
> users will have the same link-layer technology (with the same
> overhead parameters), then these can be set globally - or if not,
> they can be set per-tier.  Is the Diffserv support from Cake likely
> to be useful, and if so how flexible should the configuration
> be?  And are there only a few discrete settings for bandwidth per
> user, or do we have to be more flexible to handle a BRAS
> environment?  Is it also necessary to account per-user traffic
> accurately, or will an external tool be used for that?

Obviously I can't speak for other potential users but we follow the
upstream kernel very aggressively and have no interest in porting
something like this to older kernels.

We have some deployments with multiple access technologies (eg DOCSIS,
DSL and wireless) behind the same box so per customer overhead would be
useful.

I am interested in the diffserv class ideas in Cake but need to do some
experimentation to see if that helps in this environment. It would be
interesting to be able to target sub-classes (not sure what the proper
Cake terminology is) based on a eBPF classifier.

Re accounting, we currently count per-IP via eBPF not via qdisc counts.

Each subscriber can have several IPs in which case the traffic for
those IPs needs to go to a single class so that their entire traffic
envelope is shaped to the desired plan rate. At present we do this via
eBPF since it is essentially a map lookup operation.

A few of the above points touch on something that may be somewhat
unique service provider deployments vs homes, there are many situations
where the classification logic has to be a map lookup and cannot be
done just by looking at a given packet.

> Many other low-level considerations can be adjusted on the fly during
> the conversion, so they are not in themselves a problem.  In this
> category are questions like "how many simultaneous users and flows
> can be supported".  There are ways to design the code so that it
> scales up much more nicely in these dimensions than Cake does, at the
> expense of a few extra CPU cycles per packet.
> 
>  - Jonathan Morton
> 
>