Controlled Delay (CoDel) Queue Discipline

AQM stands for Active Queue Management; these are the algorithms that take care of the router queues. RED and its variants are the active queue management algorithms. There have been proposed some other algorithms for actively handling the queues at the router. Controlled Delay is such AQM. CoDel was proposed in RFC 8289  by Van Jacobson and the team at Google. This is the latest algorithm for AQM.

CoDel is the first AQM algorithm to use ‘Queue Delay’ as a metric of congestion. The previous algorithms (RED and variants) don’t use ‘Queue Delay’ as a metric of congestion. The main idea of CoDel is to minimize the impact of ‘Bufferbloat’. Bufferbloat is the state of congestion at the router when a lot of packets arrive and its queue gets filled and thus packets start to drop. It has lesser knobs than other AQM algorithms. RED has 4 knobs, but CoDel has only 2 knobs. Knobs are basically the parameters that the user has to configure. CoDel algorithm is described in RFC 8289. CoDel is implemented in the Linux kernel. 

There exist some variants of CoDel as well. Flow Queue CoDel (FQ-CoDel) queue discipline is a popular variant of CoDel implemented in the Linux kernel. FQ-CoDel is used as a default queue discipline in many operating systems. 

CoDel – BLUE Alternate (COBALT) queue discipline. It is another variant of the original CoDel. It is an improvement over CoDel, implemented as a part of the CAKE queue disc in Linux. 

Working of CoDel:

CoDel operates during the ‘dequeue’ time. Note: CoDel runs on the ‘output port’, during the ‘dequeue’ time! whereas RED runs at the output port during enqueue time. CoDel operates ‘on the departure of every packet’ from the output port queue. Hence, there is no periodic time interval in which CoDel is invoked. It is not like CoDel will invoke every 100 ms or some other regular time period gap. It only invokes when a packet is outgoing from the output port. If packets do not arrive (hence, do not depart), the CoDel algorithm is not invoked. 

CoDel algorithm runs in two phases.  These two phases are the Dropping and Non-dropping phases. CoDel decides whether the outgoing packet should be dequeued or dropped. Dequeue means CoDel successfully transfers the packet to the next device. The drop means that packet is not forwarded instead it is discarded and the sender has to retransmit it. So, how and why does CoDel drops the packet. Basically, the packet is dropped when CoDel senses the congestion in the network due to dequeuing the packet.

=> Two main components of CoDel:

=> Calculation of ‘instantaneous queue delay’. 

=> Decision making logic (whether to dequeue or drop the outgoing packet)

Two Configurable Parameters in CoDel Algorithm:

RED has 4 configurable parameters while CoDel has only 2 such parameters. One is target queue delay and the second is ‘time interval’.

• target (default: 5 ms) [Note: this is same as ‘target queue delay’ in Adaptive RED]. target is the maximum queue delay that is allowed. target is 5 ms, which means an enqueued packet should not remain in the queue for more than 5 ms, it must get dequeued within 5 ms.
• interval (default: 100ms) [Note: assumption is average RTT in Internet is 100ms]. interval is the amount of time for which the CoDel controller will wait for the congestion to recover by itself, if this does not happen then the controller will handle the congestion state. 

Algorithm:

Step 1: Attach a ‘timestamp’ when the packet is enqueued (to indicate enqueue_time). It is like the entry register in any official building.

Step 2: Calculate current queue delay (cur_qdelay) for every outgoing packet: cur_qdelay = dequeue_time – enqueue_time Eq. (1)

Step 3: When cur_qdelay > target for the first time, start the ‘interval’ timer. when the current queue delay is more than the target queue delay, that means the router queue is congested enough for the queue delay to exceed the target value.

Step 4: If the current queue delay for subsequent packets is consistently greater than the target(5 ms) value for interval time (100 ms) then enter dropping phase, only if cur_qdelay > target for the entire ‘interval’.

• Step (4A): If cur_qdelay > target for time lesser than 100 ms, stay in non-dropping phase because it was a short burst. if the current queue delay was greater than for a shorter time(i.e. 20ms, 40ms, 99ms) then congestion is not concerned much.
• Step (4B): If cur_qdelay > target for 100 ms then enter dropping phase. Drop all the packets till the cur_qdelay > target, but the time for packet drop is calculated by the controller. next_drop_time = current_time + interval/sqrt(count) Eq. (2) where count=number of packets dropped in this dropping phase.

Step 5: when the current queue delay becomes again less than the target then, comes out of the dropping phase.‘interval’ timer is reset and it will set again when waiting for cur_qdelay > target.

What Happens in the dropping Phase:

On entering the dropping phase, the algorithm will drop the outgoing packet. As soon as the algorithm enters the dropping phase, the very packet will get dropped immediately instead of dequeuing. Now, when does the next packet is dropped? Unlike DropHead or DropTail passive queue management algorithms, CODEL does not keep dropping the subsequent dequeuing packets while it is in the dropping phase. Instead, it calculates the exact time for dropping the next packet. For calculating the exact time of the next packet drop, CoDel uses a local variable called count, count is the number of packets dropped so far in the dropping phase. So, when the first packet is dropped, Increment ‘count’ (indicates a number of packets dropped in ‘this’ dropping phase). 

Calculate time to drop the next packet using the Control Law:

next_drop_time = current_time + interval/sqrt(count)

While in the dropping phase, CoDel continues to drop packets using Eq. (2) till cur_qdelay > target. So, basically we want to know when does dropping phase will end? When will the packets stop dropping? CoDel will keep on dropping the packet till the current queue delay is greater than the target delay value. When the current queue delay comes under the target value, then CoDel senses that the congestion is over. So, When cur_qdelay < target, exit the dropping phase. When the dropping phase stops, the local variables are resetted to their default value. Reset the value of the count to 0. The count is incremented for a specific dropping phase only, it gets resetted when dropping phases are over. Enter the non-dropping phase.

Example: Assume that packets are consistently coming to the queue and going out of it.

target: 5 ms, interval: 100 ms, queue: enqueue->[11,10, 9, 8, 7, 6, 5, 4, 3, 2, 1]->dequeue

=> 1st packet has current queue delay = 4ms, dequeue this packet.

=> 2nd packet has current queue delay = 6ms, start the timer of 100ms and wait for 100ms. timer=0. This packet will not be dropped, it will be forwarded to the next device.

=> at timer=8, 3rd packet has current queue delay = 10ms, still the timer of 100ms is running, This packet will not be dropped, it will be forwarded to next device.

=> at timer=42, 4th packet has current queue delay = 44ms, still, the timer of 100ms is running, This packet will not be dropped, it will be forwarded to next device.

=> at timer=82, 5th packet has current queue delay = 41ms, still, the timer of 100ms is running, This packet will not be dropped, it will be forwarded to next device.

=> at timer=100, 6th packet has a current queue delay = 25ms, but the timer just got expired, so the codel enters the dropping phase. This packet will be dropped off immediately.

CoDel’s working in the dropping phase:

=> Assume: current_time = 1000ms and count = 1, then next_drop_time = current_time + interval/sqrt(count) Eq. (2)

• next_drop_time = 1000ms + 100ms/sqrt(1)
• next_drop_time = 1100ms

=> At time=1100ms, drop the next packet, increment the count, count=2. Until time=1100ms, don’t drop any packet, just dequeue them.

=> At time=1050, 7th packet is ready for dequeue, it has current queue delay = 60ms, (60ms > 5ms) so codel is still in dropping phase. It will not drop this packet, it will forward it successfully. 

=> At time=1090, 8th packet is ready for dequeue, it has current queue delay = 52ms, (52ms > 5ms) so codel is still in dropping phase. It will not drop this packet, it will forward it successfully. 

=> Suppose 9th packet is not ready for dequeue till 1100ms, so at time=1100ms, 9th packet will be dropped. current_time=1100 ms, count=2, then

•  next_drop_time = 1100ms + 100ms/sqrt(2)
•  next_drop_time = 1100ms + 71ms = 1171ms

=> At time=1171ms, drop the next packet, increment the count, count=3.

=> at time=1160, 10th packet is ready for dequeue, it has a current queue delay = 70ms, (70ms > 5ms) so the codel is still in the dropping phase. It will not drop this packet, it will forward it successfully. 

=> Suppose 11th packet is not ready for dequeue till 1171ms, so at time=1171ms, 11th packet will be dropped.

• current_time=1171 ms, count=3, then
• next_drop_time = 1100ms + 100ms/sqrt(3)
• next_drop_time = 1100ms + 58ms = 1229ms

=>  At time=1229ms, drop the next packet, increment the count, count=4.

Known problems with CoDel:

Queue control is lost when some of the flows are unresponsive. Responsive flows are UDP flows. To manage queues for such flows, another algorithm is being proposed. It is called FQ-CoDel. It stands for Flow Queue CoDel. FQ-CoDel isolates flow by providing a separate queue to every flow. We know that these AQM algorithms are deployed at the router. The router maintains a separate queue for each flow. The router is very clever, it easily identifies each flow uniquely. Flow is identified by: Source IP, Source port, Destination IP, Destination Port, and Protocol Number.