比例积分 (PI) 控制器和 PI 控制器增强 (PIE) 队列规则
比例积分 (PI) 控制器是 AQM 算法。它管理路由器输出端口的队列。它包括 RED 中没有的主要功能。比例积分 (PI) 控制器旨在克服 RED 的问题。它使用“瞬时队列长度”作为拥塞度量。
PI 就像 RED 算法一样在“入队”时间运行。请注意这一点，不要将其与路由器架构中的“输入端口”混淆。 PI 在“输出端口”上运行，但在“入队”期间，PI 不会像 RED 那样在每个数据包到达时运行。 RED 在排队期间处理每个数据包的到达。但是，PI 每 6 毫秒运行一次（可变称为 w）。 PI 在一些计算之后决定传入的数据包是否应该入队或丢弃。
PI控制器的工作：
PI 算法包含以下组件：
- 当前队列长度的计算，就像RED算法一样，PI首先计算当前队列长度，并将其作为拥塞度量。根据当前队列长度，算法将采取进一步的步骤，并决定是丢弃传入的数据包还是将其转发到下一个设备。
- 丢弃概率的计算，如果丢弃概率大于某个阈值，则数据包将被丢弃，否则将被转发。
- 决策逻辑，该逻辑有助于决定传入的数据包是否应该入队或丢弃
1.如何计算当前队列长度 (PI)？与 RED 不同，每次新数据包到达时都会调用算法。 PI 在某个频繁的时间间隔内运行，这在 PI 的原始 RFC 中用变量 w 表示。每 'w' 毫秒，PI 算法获取有关当前队列的信息。
2.掉落概率 (PI) 的计算是如何进行的？丢弃概率的计算如下公式所示：
=> 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 weigths associated.
3.决策逻辑是如何产生的？一旦计算出“drop_prob”，PI 使用以下逻辑来决定传入数据包是否必须入队或丢弃：
=> 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 控制器增强：
PI Controller Enhanced (PIE) 队列规则在 RFC 8033 中提出。它是 PI Controller 的一个流行变体。 PIE 使用队列延迟作为拥塞度量，就像 CoDel 一样。 PIE 由 NITK 团队从头开始在 Linux 内核中实现。
与 RED 算法一样，PIE 也在“入队”期间运行。入队时间是数据包到达输出端口的时间。在进一步转发之前，数据包在输出端口被缓冲。 PIE 在“输出端口”上运行，但在“入队”期间，PIE 不会像 RED 那样在每个数据包到达时运行。 PIE 每 15 毫秒运行一次（可变称为 t_update），它不像 RED 那样在每个数据包到达时运行。 PIE 根据一些计算决定传入的数据包是否应该入队或丢弃。
PI控制器的工作增强：
PIE算法包含以下组件：
- 计算瞬时队列延迟 (PIE)。
- 掉落概率的计算。
- 决策逻辑有助于决定传入的数据包是否应该入队或丢弃
算法：
当前队列延迟 (PIE) 的计算。有两种可能的方法来计算当前队列延迟。这两种方法都在原始 RFC 8033 中提到。PIE 算法在每个“t_update”时间段被调用。与 RED 一样，它不会在每次新数据包到达时调用。
1.对于每个 't_update' ms，PIE 算法计算队列延迟。估计当前队列延迟（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 lenght 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.掉落概率（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. There 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 、决策逻辑与PI Controller完全相同。
PIE 的附加功能：
PI 和 PIE 都是 RED 算法的进步。但是 PIE 比 PI Controller 有更多的功能。
- 突发津贴。 PIE 允许小脉冲通过而不会受到惩罚，它不会惩罚小脉冲。当 5-10 个数据包一起进入时，它不会通过丢弃一些数据包来惩罚这个小突发，而是安全地转发它们。 CODEL 和 PIE 之间的主要区别在于 CODEL 在进入丢弃阶段之前等待 100 毫秒，而 PIE 在惩罚突发之前等待 150 毫秒。因此，如果突发很小，那么它将在 150 毫秒内消失。
- 自动调整 drop_prob。实际实现中存在多对[a, b]值。查看 drop prob 的当前值，我们可以确定 a 和 b 的值。这是循环依赖。 [a, b] 取决于 drop prob，而 drop_prob 取决于 [a, b]。
- 避免 drop_prob 急剧上升。掉落概率会像自适应 RED 一样缓慢增加。它缓慢增加 drop_prob 而不是急剧增加。
- 当队列空闲时衰减 drop_prob。当没有数据包进来时，它会衰减丢弃概率。当队列为空时，RED 不会衰减 drop_prob。 RED 也不会在队列为空时更新队列长度和 drop_prob，但 PIE 在队列为空时更新 qdelay 和 drop_prob。
- 根据当前队列长度激活/停用 PIE。 PIE 需要更多的 CPU 周期，更多的计算能力。因此，如果队列大小小于阈值时不需要 PIE，则在不需要时停用 PIE。当需要 PIE 时，激活它，这个想法是在原始 RFC 中推荐的。但 NITK 团队发现频繁切换 PIE 模式很麻烦，因此没有在 Linux 内核中实现该功能。
其他 PI 变体：
Flow Queue PIE (FQ-PIE) 队列规则。它为每个流维护一个单独的队列。 PIE 的一个流行变体是在 Linux 内核中实现的。另一个变体是在 RFC 8034 中提出的 DOCSIS PIE 队列规则。为 DOCSIS 标准开发了 PIE 的变体。