Proportional Integral (PI) Controller and PI Controller Enhanced (PIE) Queue Disciplines

The proportional Integral (PI) Controller is the AQM algorithm. It manages the queue at the output port of the router. It includes the major features which were absent in RED. The proportional Integral (PI) controller was designed to overcome the problems of RED. It uses ‘instantaneous queue length’ as a congestion metric. 

PI operates during the ‘enqueue’ time just like the RED algorithm. Note this point and do not confuse this with ‘input port’ in the router architecture. PI runs on the ‘output port’, but during the ‘enqueue’ time PI ‘does not operate on the arrival of every packet like RED does. RED works on the arrival of each packet during enqueue time. But, PI runs once in every 6ms (variably called w). PI decides whether the incoming packet should be enqueued or dropped after some calculation. 

Working of PI Controller:

The PI algorithm contains the following components:

• Calculation of current queue length, just like the RED algorithm, PI first calculates the current queue length, it uses it as a congestion metric. Based on the current queue length the algorithm will take a further step and decide whether to discard the incoming packet or forward it to the next device.
• Calculation of drop probability, if the drop prob is greater than a certain threshold then the packet will be dropped else it will be forwarded.
• Decision making logic, this logic helps to decide whether the incoming packet should be enqueued or dropped

1. How does the Calculation of current queue length (PI) takes place? Unlike the RED, which invokes the algorithm every time a new packet arrives. PI runs in a certain frequent interval of time, this is denoted by variable w in the original RFC of PI. Every ‘w’ ms, PI algorithm fetches the information regarding the current queue.

2. How does the Calculation of drop probability (PI) takes place? Drop probability is calculated as shown in the equation below:

=> drop_prob = a (cur_qlength – target) – b (old_qlength – target) + old_drop_prob

=> cur_qlength= current queue length calculated in above step.

=> target= target queue length, it is a fixed value.

=> old_qlength= old or previous queue length calculated last time PI was invoked.

=> old_drop_prob= it is old probability calculated last time PI was invoked. a and b are the constant weights associated. 

3. How does the Decision making logic made? Once the ‘drop_prob’ is calculated, PI use the following logic to decide whether the incoming packet must be enqueued or dropped:

=> if (drop_prob ≤ R) enqueue the incoming packet

=> else drop the incoming packet

=> where, R = uniformly distributed random  number generated between [0, 1]

=> Note: It is important that a well known random number generator is used to generate R. 

=> If the implementation of the random number generator is not correct, PI and PIE’s performance might get affected.

 PI  Controller Enhanced:

PI Controller Enhanced (PIE) queue discipline is proposed in RFC 8033. It is a popular variant of PI Controller.  PIE uses queue delay as a congestion metric, like CoDel. PIE is implemented in the Linux kernel from scratch by the NITK team. 

Like the RED algorithm, PIE also operates during the ‘enqueue’ time. Enqueue time is when the packet is coming to the output port. Before further forwarding, the packet is buffered at the output port. PIE runs on the ‘output port’, but during the ‘enqueue’ time PIE ‘does not operate on the arrival of every packet like RED does.  PIE runs once in every 15 ms (variably called t_update), it does not run on the arrival of each packet like RED. PIE decides whether the incoming packet should be enqueued or dropped based on some calculation.

Working of PI Controller Enhanced:

PIE algorithm contains the following components:

• Calculation of instantaneous queue delay (PIE).
• Calculation of drop probability.
• Decision-making logic helps to decide whether the incoming packet should be enqueued or dropped

Algorithm:

Calculation of current queue delay (PIE). There are two possible approaches to compute the current queue delay. Both the methods are mentioned in the original RFC 8033. The PIE algorithm is invoked every ‘t_update’ time period. Like RED it is not invoked every time a new packet arrives. 

1. For every ‘t_update’ ms, the PIE algorithm calculates the queue delay. Two ways to estimate current queue delay (cur_qdelay):

=> Little’s Law  method is recommended as default in RFC 8033.

=> cur_qdelay = cur_qlength / avg_departure_rate Eq. (1)

=> current queue delay is calculated by dividing the current queue length by the average departure rate.

=> suppose current queue length is 20 packets, and avg departure rate is 5 packets/ms. then all the packets will be dequeued in 4 ms, that means a packet will be delayed by atmost 4 ms in the queue.

=> Using timestamps like CoDel, as shown in Eq. (2).  

=> cur_qdelay = dequeue_time – enqueue_time Eq. (2)

=> enqueue_time= the time when the packet entered in the queue.

=> dequeue_time= the time when the packet left the queue. the difference between these two times is the delay faced by currently leaving packet. This is more accurate way of calculating the current queue delay. 

=> Initially the researchers had implemented the first method. But later of Team from NITK proved that first method was inefficient and implemented the second method.

2. Calculation of drop probability (PIE)

=> Drop probability is calculated as shown in the equation below:

=> drop_prob = a (cur_qdelay – target) + b (cur_qdelay – old_qdelay) Eq. (4) a and b are the fixed constants. Their value can be changed manually.

=> cur_qdelay = current queue delay

=> target = it is the target value of the queue delay, its also fixed constant.

=> old_qdelay = it is the old value of the queue delay,calculated the last time PIE was invoked.

3. Decision-making logic is exactly the same as PI Controller.

Additional Features in PIE:

PI and PIE are both advancements of the RED algorithm. But PIE has more features than PI Controller. 

• Burst allowance. PIE allows small bursts to pass by without getting punished, it does not punish the small bursts. When 5-10 packets come in together, then it does not punish this small burst by dropping some of the packets rather it forwards them safely. The major difference between CODEL and PIE is that CODEL waits for 100 ms before entering the dropping phase whereas PIE waits for 150 ms before punishing the bursts. So, if the burst is small then it would go away in 150ms.
• Auto-tuning the drop_prob. There exist many pairs of [a, b] values in the actual implementation. Looking at the current value of drop prob, we can decide the value of a and b. Here is the circular dependency. [a, b] depends on drop prob and drop_prob depends on [a, b].
• Avoids a sharp rise in drop_prob. Drop prob is increased slowly just like adaptive RED. It increases the drop_prob slowly rather than drastically increasing. 
• Decays drop_prob when the queue is idle. When no packets are coming in, it decays the drop prob. RED does not decay the drop_prob when the queue is empty. RED also doesn’t update queue length and drop_prob when the queue is empty but PIE updates the qdelay and drop_prob when the queue is empty. 
• Activating/deactivating PIE depending on current queue length. PIE takes more CPU cycles, more computational power. So if PIE is not required when the queue size is less than a threshold, so deactivate the PIE when not needed. When PIE is needed, activate it, this idea was recommended in the original RFC. But NITK team found it troublesome to switch the PIE mode frequently and thus didn’t implement this feature in the Linux kernel.

Other PI variants:

Flow Queue PIE (FQ-PIE) queue discipline. It maintains a separate queue for each flow. A popular variant of PIE is implemented in the Linux kernel. Another variant is the DOCSIS PIE queue discipline, which is proposed in RFC 8034. A variant of PIE was developed for the DOCSIS standard.