Re: [Cake] strict(er) priority model

[Jonathan Morton <chromatix99@gmail.com>]

> On 19 Nov, 2015, at 11:22, Dave Taht <dave.taht@gmail.com> wrote:
> 
> There are a few circumstances where the inherent bandwidth/latency
> tradeoffs in cake are trumped by perceived needs for strict priority
> queues.

It must be emphasised that strict-priority PHB semantics *must* be accompanied by admission control to prevent abuse.  This is not typically present in Cake’s primary use case, at the consumer edge of the network, but is a reasonable prerequisite for small-office uplinks.

The existing priority mechanism implementation can approximately support strict-priority tins with a modification to the tin parameters, setting both the bandwidth-balance and priority-balance weights equal and very high (making the threshold for these tins irrelevant).  If I changed the DRR algorithm to always start its scan from the top tin (rather than remembering its place), the approximation would be closer still.  Under saturated conditions, the modified algorithm would still let a small amount of normal traffic through, which is probably the correct behaviour in practice, since it would assist recovery from a DDoS that managed to bypass admission control.

To support VoIP and BGP in this mode, a five-tin scheme would perhaps be appropriate, with CS7 defining the top tin for routing traffic, and CS6, EF and VA defining the next one down for VoIP, NTP etc.  All other elevated-priority traffic would then occupy Tin 2.

The alternative form of DRR is probably also needed elsewhere in the code, to support dual host-flow isolation.  This would allow me to treat source hosts and destination hosts independently, greatly simplifying the choice of default configuration.

 - Jonathan Morton