6.3 Controlled Delay
Last updated
Last updated
在前一节中提到，RED从未被广泛采用。可以肯定的是，它对于互联网的拥塞控制还没有产生足够的影响，所以还不是那么有必要部署它。具体来说，不部署的一个原因是RED很难配置成在各种场景下都带来提升，有太多的参数影响了它的运行（例如MinThreshold, MaxThreshold, 和 Weight）。研究表明，RED 在不同的流量类型和参数设置时，可以产生不同的结果，而并非所有结果都有益。这增加了部署它的不确定性。
经过多年的合作，以其在TCP拥塞控制领域的工作以及作为原始RED论文的共同作者而闻名的Van Jacobson与Kathy Nichols以及其他研究人员，一起提出了一种新的 AQM 方法，改进了RED。这项工作被称为CoDel（发音为coddle），全称为Controlled Delay AQM。CoDel的提出是基于几十年来围绕TCP和AQM的经验。
更多阅读：K. Nichols and V. Jacobson. Controlling Queue Delay. ACM Queue, 10(5), May 2012.
队列是网络中的一个重要环节，可以预期队列会时不时堆积。例如，一个新打开的TCP 连接可能会向网络中发送相当于一个窗口大小的数据包，这些数据包很可能在瓶颈链路处形成队列堆积。本身这并不是问题。网络设备应该有足够的缓存容量（即队列）来吸收这种突发。但是当缓存容量不足以吸收突发，导致过度丢包时，问题就出现了。在1990年代，人们开始明白缓存空间应该需要能够至少容纳一个带宽延迟积的数据包——但是这个要求又可能太过分了，被随后的研究所质疑。但事实是，缓存空间是必要的，并且可以预期它们将被用来吸收突发流量。CoDel的作者将这样的队列称为“good queue”，如图38（a）所示。
如果队列持续满载，这将成为问题。满载的队列除了增加网络延迟外，无任何其他作用，并且如果它永远不完全清空，也将没有足够的空间来吸收突发流量。Jim Gettys 将大缓冲区和这些缓冲区内持续存在的队列命名为“Bufferbloat”。很明显，持续满载的队列是一个设计良好的 AQM 机制需要试图避免的。长时间保持满载而不排空的队列，不出所料地被称为“bad queue”，如图 38（b）所示。
更多阅读：J. Gettys. Bufferbloat: Dark Buffers in the Internet. IEEE Internet Computing, April 2011.
因此，在某种意义上，AQM 算法面临的挑战是区分“good queue”和“bad queue”，并且只有在“bad queue”时才触发丢包。实际上，这正是 RED 通过其 Weight 参数在做的事情（过滤掉瞬时的队列长度变化，识别持续的队列堆积）。
CoDel的一个创新之处在于关注 sojourn time：即任何特定数据包在队列中等待的时间。sojourn time 与链路的带宽无关，并且即使在带宽随时间变化的链路上（如无线链接），也能给出sojourn time 指示。一个表现良好的队列会频繁地清空至零，相应的部分数据包将经历接近零的sojourn time，如图 38(a)所示。相反，一个拥塞的队列会增加每个数据包的延时，最小 sojourn time 永远不会接近零，如图38(b)所示。因此，CoDel测量 sojourn time ——对于每个数据包来说，这是容易做到的——并跟踪它是否持续保持在某个较小的数值之上。这里的“持续”被定义为“超过典型的RTT时间”。
CoDel并不要求使用者确定参数才能较好的工作，该算法选择了合理的默认值。使用 5ms 作为目标sojourn time，以及 100ms 作为滑动测量窗口。直觉上，与 RED 一样，100ms 是跨越互联网的流量的典型 RTT，如果拥塞持续时间超过 100ms，我们可能会进入“bad queue”区域。因此 CoDel 监控相对于 5ms 的目标sojourn time。如果超过目标 sojourn time 的时间超过 100ms，则是时候开始通过丢包（如果ECN 可用则标记）来减少队列。选择 5ms 是因为它接近于零（以获得更好的延迟），但又不至于太小以致于算法过于敏感导致队列会一直为空（注，从而降低吞吐）。应该注意的是，大量的实验和仿真已经投入到这些数字的选择中，但更重要的是，算法似乎对它们的变化不是过于敏感。
总的来说，CoDel算法大部分时候忽略持续时间少于一个RTT的队列堆积，但是一旦队列堆积持续时间超过一个RTT，它就开始采取行动。通过对互联网RTT做出合理假设，这个算法不需要配置任何参数。
CoDel算法通过逐渐增加丢包率的方式来处理持续超过目标sojourn time的情况。正如第7.4节讨论的那样，TCP吞吐量已被证明与丢包率的平方根成反比。因此，只要 sojourn time 持续超过目标值，CoDel会按照已经丢包数量的平方根的一定比例来设定增加其丢包率（因为丢包数在持续增加，所以丢包率也在持续增加）。理论上，这样做的效果是造成受影响的TCP连接的吞吐量线性下降。最终，这会导致到达路由器的流量足够少，从而使得队列能够清空，从而使sojourn time回落到目标值以下。
CoDel算法在Nichols和Jacobson的论文中有更多的细节介绍，包括广泛的模拟实验来证明其在各种场景下的有效性。该算法已被IETF在RFC 8289中标准化为“实验性”的。它也在Linux内核中得到了实现，这促进了其部署。特别是，在经常遇到 bufferbloat 的端到端路径上的一个点（参见图39）——家用路由器（通常基于Linux）中，CoDel提供了价值。
