[Cake] the Cake stalemate

[Pete Heist <pete@heistp.net>]

Whether or not it helps with the upcoming talk or future plans, I’m thinking about the most recent experience with trying to upstream Cake and how to break the stalemate.

Cake stretches (arguably breaks) what qdiscs were designed for, which, correct me if I’m wrong, is what caused a lot of the pushback. I’m thinking of NAT support, ingress mode, host isolation, diffserv modes, and ack filtering, at a minimum. Each of those things can be useful in one case or another both individually and together, as evidenced by a satisfied user base. But when upstreaming I think each got a response with some variation on “no swimming in my bathtub.”

It seems that some would rather see Cake broken into pieces, and yet Dave points out that what makes Cake useful is the ability to easily address some common real world scenarios from one place:

> On Jun 19, 2018, at 3:46 AM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> One of cake's "minor" features is the *perfect* defeat of the htb
> based shaper in cable modems. If you know the set-rate on the modem,
> you just set it to the same thing and get vastly superior performance to
> docsis 3.1, pie, or the sqm-scripts.

Some of its functionality is painful to implement using separate qdiscs, iptables rules, misc kernel modules, etc. So Cake is something useful that can’t be delivered to the world because of something like an impedance mismatch. There’s something wrong here, right? I’m just asking the question, what is it:

1) Should we accept qdiscs and Linux networking as they are and work within their borders?

or

2) Are there problems with the qdisc architecture or improvements from our experience that we can suggest for Linux networking that would help?

Or some combination?

Thoughts on this:

- The need to use an IFB device to control the ingress queue seems cumbersome, and that one should be able to control both the egress and ingress queues with one qdisc and one device, since egress and ingress traffic can be related (say for half-duplex devices).

- And let’s say you wanted to try to control the queue of a half-duplex physical layer with varying, asymmetrical rates and airtime considerations like WiFi. That would be a real challenge within the qdisc architecture. Realistically, you’d have to write a driver for every device that exists, right? It seems that situation could be better.

- Is there a right way to implement host isolation with NAT support?

- Just as a brainstorm, if I understand it right, qdiscs and tc live outside of the netfilter framework and within iproute2. Wouldn’t it have more conceptual integrity if netfilter and iproute2 were integrated? I’m thinking of a modular architecture that regardless of whether you queue, route, filter, prioritize, etc, you work in the same space. Or if that sounds like mayhem, then at least I question, does queueing belong with routing?

- Related: instead of a qdisc, could Cake rather be written as a netfilter module or series of modules with a common configuration utility?

I’m writing a bit beyond my experience here and those who’ve written a qdisc could surely have better ideas on what the path forward is…