Other traffic gets a turn, while congestion signals help control the backlog.
Both modes start with the same demand and connection capacity. After a congestion signal, the illustrated sender adjusts its pace.
01Classify
Traffic is organized into four classes. Each class can contain many separate flow queues.
02Isolate
Competing flows get a turn, so a busy download does not put every other flow behind its backlog.
03Control delay
When a queue stays busy, CAKE signals the sender to slow down. A responsive sender eases its pace, helping the queue settle.
How this works
This is a conceptual illustration, not a benchmark or an exact CAKE simulation. The waiting-time gauges describe the latest served packet from each example flow, not all traffic in its class.
Real CAKE selects among four Diffserv classes (tins), then schedules individual flow queues within each class. It uses byte-based fairness, sparse-flow treatment, and priority/bandwidth sharing. This illustration uses equal-size packets, a simplified weighted class schedule, and separate flow selection. It does not reproduce CAKE's exact weights, thresholds, or timing.
CAKE's active queue management, COBALT, combines CoDel and BLUE. It can mark ECN-capable packets to signal congestion or drop packets. Here, a small ! means a congestion mark: the packet continues to the output. The example sender responds after a delay representing feedback travelling through the network. We illustrate that feedback using a simplified persistent-queue rule, not an implementation of COBALT. Packet loss, nonresponsive senders, and full transport behavior are not simulated.
Both modes start with identical demand and output capacity. Actual arrivals change when the sender reacts to feedback. A generic FIFO has one arrival-ordered queue here; it is not a representation of a competitor. Application icons represent example flows with appropriate packet markings, not automatic application detection. The loop restarts the same scenario.
Read the CAKE documentation ↗