Re: [Cake] second system syndrome

[Jonathan Morton <chromatix99@gmail.com>]

Addressing the subject line of this thread directly:

I intended, from the start, for Cake to integrate the best available algorithms for shaping, AQM, flow isolation, and priority queuing.  This has, of necessity, resulted in Cake becoming larger and more complex than most other qdiscs.  I do agree that it’s important to avoid *needless* complexity, for performance reasons if none other.

Shaping, AQM, flow isolation and priority queuing are Cake’s core feature set.  I’m not going to remove or cripple any of those functions in the name of elegance - that would be counter-productive.  So features that directly contribute to those functions - such as the packet-size compensation which the shaper relies upon, and the GSO peeling which the packet-size compensator relies upon - are also clearly within scope, even though they might complicate the configuration interface.

The “dual flow isolation”, which after a great deal of thought I’ve decided to rename “triple flow isolation” (for reasons that will become clear later), is within scope because it improves the flow-isolation feature.  If and when I can get my head around all the little changes that keep (potentially) breaking everything behind my back, I’ll be able to actually implement it some day.

It could reasonably be argued that some logic should be moved out of kernel space and into userspace, and/or vice versa.  However, we need concrete justifications for doing so, and a certain level of self-consistency.  We also need *really* strong justification before making optimisations which make future adjustments more difficult.

One such justification might be to more clearly separate the user-visible link characteristics (such as bandwidth, inherent latency and encapsulation) from the algorithm implementation parameters required to make best use of it (such as interval, target, etc).  These are parameters that are calculated at configuration time, so they do not need to be especially fast.

The most difficult function to define and scope has been the priority queue, due in no small part to the hilariously weak specification that is Diffserv.  I have tried to carve a fresh path of clarity here, interpreting the existing specifications into a coherent implementation in the hope that it’ll actually get used as such in future.

In that context, the “squash” and “wash” features truly baffle me.  I’d prefer to see them both gone.  Either you want to *use* Diffserv, in which case downstream networks might also benefit from the same markings, or you want to *ignore* it, in which case you might as well leave the existing marks alone, or you want to do something more sophisticated that Cake’s core feature set doesn’t support.

In short, Cake is *not* the right place to change the DSCP field.  A separate qdisc could be written to do that job with minimal overhead and a dedicated configuration interface, and be inserted either before or after Cake as required.  Or we could wait for pre-ingress-qdisc firewall rules to become available.

The AQM layer is also apparently a source of controversy.  Codel is really, *really* good at dealing with single, well-behaved TCP flows in the congestion-avoidance phase.  It’s also really, *really* bad at dealing with unresponsive UDP flows, and somewhat mediocre at dealing with TCP in slow-start or multiple TCP flows in the same queue.  This is a problem that we need to address, one way or another - whether by modifying Codel or finding some way to switch between two or more different AQM schemes based on traffic characteristics.  In the meantime, we have to experiment.

I am happy to see optimisations go in, as long as they’re clearly beneficial, don’t change the logic, and don't preclude changes to areas that are not entirely settled.  For anything else, please make it a separate branch with a pull request, so that I don’t have to be distracted by reverting stuff that doesn’t work.

 - Jonathan Morton