比例积分控制器以及改进型比例积分控制器，用于控制队列行为。

比例积分控制器是一种AQM算法。它负责管理路由器输出端口上的队列情况。该控制器包含了RED中缺失的主要功能。比例积分控制器的设计目的是为了解决RED所存在的各种问题。它使用“瞬时队列长度”作为拥塞的衡量标准。

PI在“入队”时刻进行操作，其原理与RED算法类似。需要注意的是，不要将PI与路由器架构中的“输入端口”混淆。PI是在“输出端口”上运行的，但在“入队”时刻，PI并不会像RED那样处理每一个到达的数据包。RED则是在每个数据包进入时进行处理。而PI则每隔6毫秒运行一次（这个时间间隔可以称为w）。PI会经过一些计算后，决定该接收的数据包是应该被放入队列中，还是被丢弃。

PI控制器的工作原理：

PI算法包含以下组成部分：

• 与RED算法类似，PI算法也会先计算出当前的队列长度，并将其作为拥塞的衡量指标。根据当前队列的长度，算法会进一步决定是丢弃传入的数据包，还是将其转发到下一个设备。
• 如果丢包的概率大于某个阈值，那么数据包将被丢弃；否则，该数据包将被继续传输。
• 决策逻辑：这种逻辑有助于判断某个传入的数据包应该被加入队列还是被丢弃。

1.那么，当前队列长度的计算是如何进行的呢？与RED不同的是，PI并不是在每次有新数据包到达时都调用该算法。PI会在一定的时间间隔内运行，这个时间间隔用变量w来表示。每过‘w’毫秒，PI就会获取关于当前队列的信息。

2. 那么，滴落概率的计算是如何进行的呢？滴落概率的计算过程如下：

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

=> cur_qlength = 上述步骤中计算得到的当前队列长度。

=> 目标队列长度是一个固定值。

=> old_qlength = 上次调用PI时计算得到的队列的旧长度或之前的长度。

=> old_drop_prob=这是上次调用PI时计算得到的旧概率值。a和b则是与之相关的常数权重值。

3.决策逻辑是如何制定的呢？一旦“drop_prob”值被计算出来之后，PI就会使用以下逻辑来决定是否将传入的数据包放入队列中，或者将其丢弃。

=> 如果 (drop_prob ≤ R)，则将传入的数据包放入队列中。

=> 否则，丢弃传入的数据包。

=> 其中，R表示在[0, 1]区间内均匀分布的随机数。

=> 注意：使用知名的随机数生成器来生成R是非常重要的。

=> 如果随机数生成器的实现方式不正确，那么 PI 和 PIE 的性能可能会受到影响。

PI控制器得到了升级：

在RFC 8033中提出了PI Controller Enhanced（PIE）的队列调度机制。这是一种常见的PI Controller的变体。PIE将队列延迟作为拥塞的度量标准，类似于CoDel的做法。PIE是由NITK团队在Linux内核中从头开始实现的。

与RED算法类似，PIE算法也在“入队”时刻发挥作用。 入队时间指的是数据包到达输出端口的时刻。 在进一步转发之前，该数据包会被暂存于输出端口上。 PIE是在“输出端口”上运行的，但在“入队”过程中，PIE并不像RED那样处理每一个到达的数据包。 PIE每15毫秒运行一次（有时也被称为t_update）。与RED不同，它并不是在每个数据包到达时都进行处理的。 PIE会根据某些计算结果来决定是否将传入的数据包加入队列或丢弃它。

PI控制器的工作效率得到了提升：

PIE算法包含以下组成部分：

• 瞬时排队延迟的计算（PIE）。
• 滴落概率的计算。
• 决策逻辑有助于决定是否应该将传入的数据包放入队列中，还是将其丢弃。

算法：

当前队列延迟的计算方式有两种。这两种方法都在原始的RFC 8033中被提及。PIE算法会在每个“t更新”的时间间隔内被调用一次。与RED算法类似，它也不会在每次有新数据包到达时都被调用。

1.对于每毫秒的“t_update”时间，PIE算法会计算出队列的延迟。有两种方法可以用来估算当前的队列延迟（cur_qdelay）：

根据RFC 8033的规定，建议将Little’s Law方法作为默认的处理方式。

=> cur_qdelay = cur_qlength / avg_departure_rate 方程(1)

当前队列的延迟时间，是通过将当前队列的长度除以平均离开率来计算的。

假设当前队列中的数据包数量为20个，平均传输速率是5个数据包每秒。那么，所有数据包将在4毫秒内被处理完毕。这意味着，每个数据包在队列中的等待时间最多为4毫秒。

=> 使用类似于 CoDel 的时间戳，如公式(2)所示。

=> cur_qdelay = enqueue_time – dequeue_time 等式（2）

=> enqueue_time：数据包进入队列时的时间。

dequeue_time：数据包离开队列的时刻。这两个时间之间的差值，就代表了当前正在离开队列的数据包所遇到的延迟。这是一种更精确来计算当前队列延迟的方法。

最初，研究人员采用了第一种方法。但后来，NITK团队证明第一种方法效率不高，于是他们改用了第二种方法。

2. 滴落概率的计算（PIE）

=> 下降概率的计算方式如下：

=> drop_prob = a * (cur_qdelay – target) + b * (cur_qdelay – old_qdelay) 公式(4)中，a和b都是固定的常数。它们的值可以手动进行调整。

=> cur_qdelay = 当前队列的延迟时间

=> target：即队列延迟的目标值，它也是一个固定的常数。

=> old_qdelay = 队列延迟的旧值，该值是在最后一次调用PIE时计算得出的。

3. 决策逻辑与PI控制器完全相同。

PIE中的其他功能：

PI和PIE都是RED算法的改进版本。不过，PIE比PI控制器拥有更多的功能。

• PIE允许一些较小的数据包能够顺利通过，而不会受到惩罚。当5到10个数据包同时到达时，PIE不会对这些小数据包进行惩罚，而是将它们安全地转发过去。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值的急剧上升。drop_prob的值会像adaptive RED那样逐渐增加。也就是说，drop_prob的值是缓慢增加的，而不是突然增加的。
• 当队列处于空闲状态时，丢包概率会下降。当没有数据包进入队列时，丢包概率会继续下降。而RED则不会在队列为空时降低丢包概率。此外，RED也不会在队列为空时更新队列长度和丢包概率。不过，PIE会在队列为空时更新qdelay和丢包概率。
• 根据当前队列的长度来激活/禁用PIE。启用PIE会消耗更多的CPU资源，需要更多的计算能力。因此，当队列长度低于某个阈值时，就不应该启用PIE。而当需要启用PIE时，则可以将其激活。这一思路最初在原始RFC中被推荐了。不过，NITK团队发现频繁切换PIE的模式比较麻烦，因此没有在Linux内核中实现这一功能。

其他PI变体：

Flow Queue PIE（FQ-PIE）是一种队列调度方式。它为每个流都维护一个独立的队列。PIE的一种常见实现方式是在Linux内核中使用的。另一种实现方式则是DOCSIS PIE队列调度方式，该方式在RFC 8034中被提出。此外，还有针对DOCSIS标准的PIE变体也被开发出来。