[Cake] strict(er) priority model

[Cake] strict(er) priority model

[Dave Taht]

There are a few circumstances where the inherent bandwidth/latency
tradeoffs in cake are trumped by perceived needs for strict priority
queues.

One fairly common one is on boxes doing bgp, where the bgp flow "must"
complete as fast as possible. There are probably other cases in the
network routing world (how does ISIS exchange routes? ospf?)

A common case for voip-ers is to strictly prioritize udp sip/rtp flows
over everything else.

Having a model available closer in implementation (and NOT the
default) to the strict priority queues sch_fq and pfifo_fast have may
ease adoption. ?

then there are vlans and so on...


Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi

Re: [Cake] strict(er) priority model

[Jonathan Morton]

> 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