[Cake] upstreaming cake in 2017?

Jonathan Morton chromatix99 at gmail.com
Sat Dec 24 12:22:43 EST 2016


> On 24 Dec, 2016, at 17:55, Benjamin Cronce <bcronce at gmail.com> wrote:
> 
> What was also interesting is the flows consuming the majority of the buffer were always in flux. You would think the same few flows that were consuming the buffer at one moment would continue to, but that is not the case, TCP keeps them alternating.

That sounds like the links are not actually congested on average, and the flows which temporarily collect in the buffer are due to transitory bursts - which is what you’d expect from a competently-managed backbone.  A flow-isolating AQM doesn’t really help there, though Cake should be capable of scaling up to 10Gbps on a modern CPU.

Conversely, there have been well-publicised instances of congestion at peering points, which have had substantial impacts on performance.  I imagine the relevant flow counts there would be very much higher, definitely in the thousands.  Even well-managed networks occasionally experience congestion due to exceptional loads.

The workings of DRR++ are also somewhat more subtle than simply counting the flows instantaneously in the buffer.  Each queue has a deficit, and in Cake an empty queue is not normally released from tracking a particular flow until the deficit has been repaid (by cycling through all the other flows and probably servicing them) and decaying the AQM state to rest, which may often take long enough for another packet to arrive for that flow.

The number of active bulk flows can therefore exceed the number of packets actually in the queue.  This is especially true if the AQM is working optimally and keeping the queue almost empty on average.

While fq_codel does not explicitly assign queues to specific flows (ie. to avoid hash collisions), the effects of hash collisions are similarly felt under the same circumstances, resulting in the colliding flows failing to receive their theoretical fair share of the link, even if they never have packets physically in the queue at the same time.

With that said, both fq_codel and Cake should work okay with statistical multiplexing to handle exceptional flow counts.  In such cases, Cake’s triple-isolate feature should be turned off, by selecting either “hosts” or “flows” modes.  I could run an analysis to show how even the multiplexing should be.

 - Jonathan Morton



More information about the Cake mailing list