摘要

  • Nichols 在与 Van Jacobson 合作设计受控延迟主动队列管理（CoDel）之前，职业生涯横跨 DiffServ、Cisco 架构、Packet Design，以及通过 Pollere 开展的独立咨询工作。
  • CoDel 在出队时测量数据包驻留时间，当最近的最小值在一个时间区间内持续高于目标值时作出响应，从而区分瞬时突发与持久积压。
  • 该设计减少了常见的逐链路调优，但目标值、时间区间、时间戳运算、队列位置和服务速率变化仍决定其假设的适用范围。
  • FQ-CoDel、Linux 集成及后来的队列系统属于更广泛的作者和维护者社区；CoDel 的持久贡献在于决定控制持久时间，而不仅仅是队列占用。

CoDel 让队列测量它所增加的时间

CoDel 在数据包离开队列时进行关键测量。将数据包的出队时间与其入队时间进行比较，得出队列本身所增加的驻留延迟。Kathleen Nichols 和 Van Jacobson 围绕这一本地事实设计了控制器，因为包含相同数据包数量的队列在一条链路上可能无害，而在另一条链路上则令人无法忍受。

这种运营矛盾并不陌生：接入连接可以在语音、游戏或交互式请求被持续积压阻塞的同时，仍然达到其标称吞吐量。缓冲区在吸收短暂突发并排空时是有用的；当每个离开的数据包都被替换，等待时间成为往返时间中永久的一部分，却未创造更多容量时，缓冲区就变得有害。

CoDel 在一个时间区间内追踪最小驻留时间。如果即使观察到的等待时间最短的数据包仍持续等待超过目标值，控制器就认为积压是持久的，并根据其控制律增加拥塞信号。该设计寻求可在常见互联网链路上通用的普通默认值，而无需每个运营商根据速率、缓冲区大小和流量组合推导队列阈值。

关键问题在于，基于时间的控制器能在多大程度上将低延迟转化为运营默认状态。CoDel 只控制其所在的队列。隐藏的硬件缓冲区、可变的服务速率、不响应的发送方以及错误的位置仍可能主导整条路径。Nichols 的贡献最好理解为改变了队列测量什么以及运营商必须验证什么：不是数据包数量少，而是在负载下等待时间是否持续偏高。

DiffServ 与产品工作将分类与队列控制分离

Kathleen M. Nichols 的公开履历描述了一段跨越研究实验室、科技公司和互联网标准的职业生涯。她的技术职务包括 AT&T Bell Labs、Apple、Philips Research Laboratories、Com21 和 Bay Networks。她后来担任 Cisco 首席技术官办公室高级互联网架构总监，加入 Packet Design 创始团队并成为其网络科学副总裁，还创立了 Pollere LLC。

现有公开记录对该机构序列的确认比对其每一次职务变动的确切日期更为清晰。负责任的档案不应以重建的企业年表填补空白。这一序列足以表明，她的职业生涯反复处于理论、设备设计与运营商证据之间。

Nichols 拥有加利福尼亚大学伯克利分校电气工程与计算机科学博士学位，以及匹兹堡大学电气工程学士学位。其工程背景之所以重要，是因为 CoDel 不仅仅是一个统计分类器。它是一个嵌入数据包调度器的反馈控制器，其计时、状态转换和实现运算必须在负载下正常工作。

她在 CoDel 之前的工作还涉及互联网服务质量。Nichols 曾共同主持 IETF Differentiated Services 工作组，该工作组开发了一种可扩展的架构，用于对流量进行分类并应用不同的逐跳处理。DiffServ 解决了一个现实问题：运营商无法为每个互联网数据包维护逐流预留状态，却可能需要为延迟敏感、受管或尽力而为的流量设置类别。

然而，类别架构并不能决定该类别内部的队列是否仍然满载。为数据包标记优先处理只能决定其进入哪个队列或接受何种行为。调度决定队列如何共享服务。主动队列管理决定队列何时应发出拥塞信号。这些是相关的控制层，而不是可以互换的标签。

这一区别有助于在 Nichols 的职业生涯中定位 CoDel。DiffServ 探讨的是策略应如何在大规模环境中表达。Packet Design 专注于网络智能与分析。Cisco 将架构置于大型设备情境中。Pollere 提供了网络与电信咨询的独立载体。CoDel 所针对的正是流量策略转变为数据包实际等待时间的那个节点。

Pollere 的公开页面将 Nichols 列为创始人兼首席执行官。该页面仍然存在，但现有公开记录中没有近期的任命公告，也没有完整的当前业务披露。最稳妥的当前描述是，她创立了 Pollere，并且仍公开与其咨询和研究工作相关联，而确切的当前高管身份应在一份对时效敏感的传记中重新确认。

这段机构路径之所以重要，是因为 CoDel 回应了一种反复出现的部署失败。早期的主动队列管理方案在受控研究中可能表现良好，但在产品中仍难以配置。一个要求根据链路速率、缓冲区大小和流量组合推导阈值的算法，等于要求每个运营商或供应商都成为队列控制专家。Nichols 和 Jacobson 的目标是设计一种普通默认值更具通用性的控制器。

Differentiated Services 创造了一种方法，可在 IP 报头中编码流量类别并定义逐跳行为，而无需构建全局预留系统。网络可以根据策略将数据包放入队列或调度类别。该架构之所以具备可扩展性，是因为路由器无需为每个流维护详细的端到端状态。

这项工作塑造了围绕 CoDel 的术语体系。分类回答数据包应接受何种处理；调度回答下一个应为哪个队列服务；整形可以设定受控的服务速率；主动队列管理决定排队流量何时应收到拥塞反馈。完整的低延迟设计可能需要全部四种机制。

假设运营商创建一个低延迟类别和一个批量类别。类别边界可以保护交互式流量免受部分竞争。但它无法保证低延迟队列的容量设置或管理是正确的。如果允许该队列持续满载，那么标签承诺了优先级，而实现仍然在增加延迟。

反向问题同样存在。AQM 可以控制一个聚合队列的延迟，而批量流与其中稀疏的交互式流相互竞争。聚合延迟看起来可以接受，但稀疏流仍可能在一个突发数据包后面等待。这一限制后来成为区分独立 CoDel 与 FQ-CoDel 的核心。

因此，Nichols 的 DiffServ 经验不应被视为履历中无关的一行。它提供了一种架构纪律：分离各项控制功能，并准确说明每项功能能够保证什么。CoDel 不是一个 QoS 系统，而是一个可置于更大流量架构内部的队列控制器。

标准工作还教导人们对部署声明保持谨慎。RFC 可以定义一种机制和可互操作的语言。但供应商仍需实现它，运营商仍需启用它，端点仍需作出响应。CoDel 后来作为 Experimental RFC 发布，保留了算法和详细伪代码，但并未宣称每个网络在任何条件下都应使用它。

队列长度无法区分突发与持久性损害

许多队列管理设计使用占用率。当队列超过某个阈值时，可能会开始丢弃或标记，并随着队列增长采取更激进的措施。其表面逻辑很简单：缓冲区越满，拥塞越严重。

这一测量值会随链路而变化。慢速链路上的十个数据包所代表的时间，可能远多于快速链路上的十个数据包。字节计数改善了这种关系，但仍需了解服务速率。适合某一接入速率的阈值，在升级后可能太小，而在其他场景中可能又太大。

平均队列长度又增加了一层。平滑处理可以防止短暂突发引发过度响应，但平均常数和阈值会成为与速率、往返时间和流量相互作用的参数。供应商可以发布默认值，但这些默认值在产品的众多运行条件下可能表现各异。

驻留时间提出了一个更直接的问题。数据包在进入队列时被加上时间戳。当它到达出队时，控制器可以计算它等待了多久。五毫秒在兆比特链路和千兆比特链路上是相同的单位，即使这一延迟所代表的字节数差异很大。

时间并不会自动成为完美的信号。时间戳分辨率和回绕必须正确处理。队列必须知道数据包是何时进入的。在快速路径中，时钟开销很重要。如果数据包离开受控队列后在另一个隐藏队列中等待，CoDel 无法看到后续的延迟。

其优势在于，测量值对应队列对延迟的贡献。这使控制器能够将其目标描述为可容忍的持久延迟，而不是为某台设备间接选择的缓冲区占用率。

传感器选择的改变也改变了运营对话。链路容量可能因速率自适应、无线条件、整形或服务升级而变化。基于队列长度的控制器可能需要新的阈值；基于时间的控制器则可以继续追问数据包是否等待过久，但这要受其目标值和时间区间所设计适用条件范围的限制。

CoDel 宣称减少调优正是基于这种关系，而非依赖于总能起作用的魔法常数。该算法围绕一种测量值设计，当维持链路忙碌所需的数据包或字节数发生变化时，这种测量值仍然可解释。

“好队列，坏队列”这一说法不仅仅是一种教学上的简化。它说明了静态占用阈值为何难以奏效。相同的队列深度，在某一时刻可能代表有用的缓冲吸收，在另一时刻则可能代表持久的延迟。

设想一个应用在收到响应后发出短暂突发。到达速率暂时超过链路速率，数据包因此累积。如果发送方随后暂停，队列排空，那么缓冲区就平滑了突发并保持了链路忙碌。如果移除所有吸收该突发的能力，可能会导致丢失和利用率不足，却无法改善长期延迟。

再设想一个批量发送方，其拥塞窗口持续维持足够的在途数据，使缓冲区保持被占用。每个离开的数据包都会被另一个数据包替代。队列可能稳定在某个水平，产生可靠的吞吐量和较大的往返时间。此时缓冲区不再弥合瞬时不匹配，而是变成了以毫秒度量的额外路径长度。

基于数据包计数的阈值可以看到两个队列都包含五十个数据包，却无法知道队列是否在两次突发之间排空。平均值可以描述随时间变化的占用率，但仍可能无法区分一次长时间积压与若干次平均值相近的短突发。最近最小驻留时间提出的正是区分性问题：是否有任何数据包在没有承受持续等待的情况下通过？

这种方法也重新定义了利用率。低延迟并不要求队列在每一瞬间都为空。链路可以保持忙碌，同时最小值周期性地低于目标值。CoDel 的目标不是缓冲区图表上的视觉整洁，而是在所选时间区间内保留服务追赶到达的证据。

当流量组合变化时，这一区别就具有运营意义。服务于一个长时间传输的队列可能很稳定；加入交互式流量后，同样的持续积压就会表现为用户延迟；再加入许多短流，突发模式又会改变。基于时间的控制器可以继续评估本地后果，而基于占用率的控制器可能需要对每种流量组合使用不同的阈值。

目标值的选择仍需要判断。五毫秒的持续延迟相对于一条路径可能很小，相对于另一条路径则可能影响显著。关键在于，这种判断以用户体验的单位表达。网络所有者可以直接讨论服务目标，而不必争论一个间接的数据包数量，其时间含义会随速率变化。

最近最小值揭示队列是否曾排空

只看一个数据包的驻留时间会过于敏感。即使队列随后立即排空，短暂突发也可能使若干数据包等待超过目标值。一旦某个数据包越过阈值就丢弃，可能会惩罚有益的突发吸收。

CoDel 转而追踪一个时间区间内观察到的最小驻留时间。最小值询问的是队列是否曾接近排空，而不是它是否曾忙碌。如果至少有一个数据包经历了较短的等待时间，积压可能是暂时的；如果整个区间内观察到的等待时间最短的数据包都等待过久，那么队列就是持续积压的。

使用局部最小值是设计的核心。突发后的平均延迟可能仍然偏高，并可能掩盖队列是否已排空。最大延迟由最差的数据包主导。最小值则提供了服务至少一次赶上到达的证据。

时间区间必须足够长，以观察普通互联网流量的反馈动态。RFC 8289 将 100 毫秒作为通常地面环境的设计值，并讨论了可能需要不同数值的环境。该区间并不是对每个流精确往返时间的测量，而是一个持久积压应当显现出来的时间尺度。

目标值在规范和实现中通常为五毫秒，代表该队列可容忍的持续延迟。它并不承诺端到端延迟会是五毫秒。传播、处理、无线调度和其他队列仍然存在。它是控制器用于判断自身贡献是否持续过高的本地阈值。

这些数值经常在脱离限定条件的情况下被引用。“五和一百”是正常互联网条件下的设计默认值，而不是网络法则。极短的数据中心路径、卫星系统、异常低速率链路或特殊服务目标可能都需要分析。CoDel 的成就在于，普通运行被设计为不需要每个链路所有者都计算新值。

最近最小值测试也解释了为什么队列可以很大却并非持续有害。突发可能暂时占用大量数据包；如果它在区间内排空，控制器不会仅因峰值而将状况归类为持久。该算法在保护突发容忍能力的同时，将从未低于目标值的时间视为拥塞证据。

出队计时与控制律将观察转化为信号

队列管理的讨论常常聚焦于到达。数据包进入时，队列检查其长度并决定接受还是丢弃。CoDel 的主要观察发生在数据包离开时，因为出队处才能测量实际的驻留时间。

数据包携带或关联着其入队时间戳。在出队时，控制器用当前时间减去该时间。它更新该区间的最小值，并判断队列是否已长时间保持在目标值之上，足以进入拥塞信号发送状态。

在出队时采取行动具有实际逻辑。服务过程决定数据包的等待何时结束。控制器可以在队列被排空的确切速率下观察队列，包括会使固定占用阈值产生误导的速率变化。

实现仍然与入队交互。时间戳必须被记录和保留。调度器或排队规则必须暴露数据包状态。如果数据包被交给设备队列，而该队列的后续延迟对软件控制器不可见，硬件卸载就可能使边界复杂化。

当 CoDel 断定延迟已经持续，它会丢弃数据包，或在适当策略下对符合条件的数据包标记显式拥塞通知（ECN）。该信号要求响应型发送方降低负载。随后队列观察情况是否改善。

当队列清空或延迟充分下降时，算法退出丢弃状态。它并非旨在永久保持惩罚性。目标是恢复一种状态，使瓶颈在保持利用率的同时不携带持续积压。

这种出队导向是为什么实现细节不能被当作单纯编码而忽略的原因之一。时间戳运算、状态转换、空队列处理以及数据包被标记或丢弃的顺序，决定了所发布的控制律是否真正被复现。

Linux 实现涉及 Eric Dumazet 和其他内核贡献者，以及更广泛的审查与集成。Nichols 和 Jacobson 提供了 CoDel 设计；已部署的 qdisc 是集体基础设施。这一区分保护了两类贡献。只有当维护者将设计转化为可靠的数据包路径时，设计才变得有用。

一旦 CoDel 进入拥塞信号发送状态，它不会在丢弃或标记之间使用固定间隔。其时间间隔会根据信号发送事件计数，按照反平方根关系变得越来越激进。

该控制律反映了拥塞控制流量的动态。在持续过载下，一次信号可能不够。以随持续拥塞而增加的速率发送信号，可以更快地降低队列。反平方根形式避免了要求运营商为特定链路和负载配置丢弃概率。

这一机制应当被谨慎描述。CoDel 并不是在估计确切的 TCP 流数量并计算其窗口。它应用一种旨在与常见拥塞响应配合工作的控制时间表。结果取决于对丢失或 ECN 作出反应的流量。忽略反馈的发送方可以继续占用容量。

实现该时间表需要高效的运算。内核数据包路径不能随意使用昂贵的浮点运算。定点或整数近似、定时器分辨率和回绕行为都很重要。在重负载下，一个小的数学错误就可能改变信号序列。

这正是 Nichols 以控制为导向的贡献最为明显之处。估计器判断是否存在持久延迟。目标值定义期望区域。控制律决定系统在保持在区域之外时如何响应。这些部分中的任何一个单独都不构成 CoDel。

队列控制器也不能选择服务速率。如果真正的瓶颈位于已配置 qdisc 的下游，qdisc 可能会将数据排入更深的设备缓冲区，而自身几乎看不到延迟。运营商经常将 AQM 与整形配合使用，使受控软件队列成为有效瓶颈，并能在隐藏队列填满之前发出信号。

因此，反平方根时间表属于一个运营系统。当队列观察到瓶颈、时间戳正确且发送方作出响应时，它是有用的。它不能替代容量、流量隔离或对故意不响应流的策略管制。

减少调优仍依赖于正确的时间

CoDel 经常被称为无参数。这种简略说法抓住了重要目标，但如果按字面理解就会变得不准确。该算法有目标值和时间区间。实现中包含常数、计时状态和运行选择。

RFC 8289 更精确的表述是，在正常的互联网部署中无需配置。Nichols 和 Jacobson 寻求能够覆盖常见地面速率和往返时间的数值与传感器，而无需早期 AQM 方法所需的逐链路调优。

这一区别影响采购和工程。供应商可以合理地声称 CoDel 设计为使用正常默认值工作，但不应声称从片上互连到卫星链路的每个网络都共享同一计时域。运营商应当理解其环境何时超出假设范围。

数据中心的例子很有启发性。往返时间可能远短于通常的互联网区间。队列可能位于具有浅但高速率缓冲区的交换机中，工作负载可能产生多对一拥塞（incast）。检测持久驻留时间这一相同原则仍然适用，而目标值和区间可能需要反映环境。

极低速率链路构成另一种边界情况。单个大数据包的串行化时间可能超过数毫秒。控制器必须区分不可避免的服务时间与持续队列。整形、最大传输单元和数据包调度都会影响结果。

无线链路的速率可能快速变化，并在可见接口之下包含队列。基于时间的传感器比固定数据包计数更能适应速率变化，但它无法控制不属于自己的固件队列。位置仍然具有决定性。

因此，称 CoDel 对参数不敏感，比称其无参数更为妥当。该设计减少了普通运营商需要选择的网络特定数值，但并未消除了解瓶颈所在以及服务所需时间目标的需要。

这一限定并不削弱贡献。运营上的简单性往往来自精心选择的默认值和稳健的测量，而不是删除所有控制。相关检验在于，系统是否在其预期范围内可接受地运行，而无需专家干预。

CoDel 的传感器依赖以数据包处理速度从出队时间中减去入队时间。表面上的简单隐藏了关于时钟源、分辨率、整数宽度和回绕的选择。

推进过于粗糙的时钟会量化短延迟；昂贵的逐包时间戳会在控制器本应改善的路径上增加开销；发生回绕的计数器仍须允许在目标值和区间之间进行正确比较。实现通常采用高效的整数表示和经过仔细定义的时间比较。

控制状态有其自身的计时。区间窗口必须正确重置，下一次标记或丢弃时间必须遵循反平方根时间表而不溢出。空队列和重新进入拥塞状态需要明确的行为，以免陈旧状态惩罚后来的突发。

这些细节正是公开伪代码和开源内核代码重要的原因。实现者可以比较运算和状态转换，而不是模仿文字描述。测试可以覆盖吞吐量基准可能永远无法触及的回绕边界和队列转换。

Nichols 和 Jacobson 提供了一种为便于实现而设计的算法。内核和设备开发者仍然对每个实现的正确性负责。产品可以标榜 CoDel 之名，但在时间戳精度、ECN 策略或队列位置上的差异足以改变结果。

工程上的教训与该设计的核心主张一致：测量质量决定控制质量。如果队列自身对时间的表示不可靠，它就无法调节持续的等待时间。

只有当反馈路径尊重标记时，ECN 才能替代丢弃

数据包丢失是一种有力的拥塞信号，但它也会丢弃可能需要重传的工作。显式拥塞通知（ECN）允许具备能力的队列改为标记符合条件的数据包，在保留数据包的同时告知端点已发生拥塞。

CoDel 可以根据实现和策略使用 ECN 标记。控制器的持续延迟检测器保持不变，动作则从丢弃符合条件的数据包变为设置拥塞指示。

其益处取决于端到端语义。发送方必须收到反馈并降低发送速率。隧道、中间设备和端点实现必须保留或正确转译该信号。没有任何发送方理会的标记不是拥塞控制。

这一边界防止了 CoDel “消除数据包丢失”的夸大说法。它可以在部署了 ECN 的地方标记符合条件的流量，同时仍然丢弃无法标记或不响应的流量。在严重过载下，丢失可能仍是必要的。

ECN 还引入了策略选择。经典 ECN 传输和较新的低延迟方法可能在不同的架构下解释队列标记。队列不应应用端点不期望的语义。AQM、调度器和传输生态系统必须被一起评估。

Nichols 在流量架构方面更广泛的工作清楚地说明了这一点。只有每一层都就其含义和后续动作达成一致时，报头中的一个位才是有用的。队列管理提供证据和信号，传输层闭合反馈回路。

独立 CoDel 与 FQ-CoDel 解决队列的不同部分

CoDel 控制单个队列中的持久延迟。它本身并不把流量划分到不同的流队列中。如果大型传输和稀疏交互式流共享同一个 FIFO，那么即使聚合控制器将长期延迟保持在一定范围内，稀疏数据包仍可能在一个突发后面等待。

FQ-CoDel 将流队列和调度与应用于队列内部的 CoDel 结合起来。数据包通常通过哈希被分类到流队列中。调度器在活跃队列之间分配服务，而 CoDel 控制每个队列中的持续延迟。稀疏流无需在批量流的完整突发后面等待即可获得服务。

作者身份必须保持精确。Nichols 和 Van Jacobson 共同设计了 CoDel。记录 FQ-CoDel 的 RFC 8290 由 Toke Høiland-Jørgensen、Paul McKenney、Dave Taht、Jim Gettys 和 Eric Dumazet 撰写。Nichols 的工作是该组合系统的基础，但她不是该 RFC 的作者。

这一区别既是传记性的，也是技术性的。流隔离解决竞争问题；CoDel 解决持续延迟问题。调度器决定队列获得服务的顺序。将它们结合起来可以产生比部署一个聚合 CoDel 队列更有用的边缘 qdisc。

哈希并非完美的身份识别。不同的流可能在同一个队列中发生碰撞；某些应用会打开许多流；流量分类的依据可能不止常规元组。调度器的量子和整形上下文都很重要。FQ-CoDel 是一种实用架构，而不是绝对的每用户公平。

其运营采用情况也不应被用作衡量独立 CoDel 部署的直接标准。平台可能暴露 FQ-CoDel、将其作为默认发布、作为选项包含，或在硬件队列之上放置另一个 qdisc。可用性并不能证明它在真正的瓶颈上被正确且主动地使用。

后来的系统如 CAKE 在相关思想的基础上增加了整形、更丰富的公平性和策略。DualQ/L4S 等较新的低延迟架构使用不同的信令假设。CoDel 的影响力可以在后续系统中延续，但这并不意味着 Nichols 是之后每一个队列设计的作者。

控制器必须位于真正造成延迟的队列上

AQM 只能看到其所在的队列。这是最重要的运营限制，也是最容易在软件演示中被忽视的限制之一。

Linux 主机可以对接口应用 CoDel 或 FQ-CoDel，然后把数据包交给拥有自身发送环和固件缓冲区的网络设备。宽带调制解调器可能有另一个队列；Wi-Fi 系统可能在固件中调度帧；提供商的接入网络可能增加更多缓冲。如果这些后续队列之一成为持续积压，软件 qdisc 可以报告健康的延迟，而用户仍在等待。

整形可以通过设置略低于下游服务的速率，将有效瓶颈移入受控队列。随后软件调度器会在隐藏设备队列之前累积数据包。这种方法需要准确或保守的服务估计，并且在链路速率变化时可能牺牲部分峰值容量。

接收方向同样复杂。端点控制自己发送数据包的时机，却无法直接调度已经从提供商到达的数据包。入站整形、中间功能块和端点反馈可以有所帮助，但其位置和架构与简单的出站队列不同。

硬件卸载增加了另一个边界。驱动程序可能把许多数据包传递给设备。即使 NIC 稍后才会发送它们，操作系统也将其视为已出队。字节队列限制（Byte Queue Limits）和相关机制可以减少隐藏的驱动程序缓冲，但队列所有权仍然因平台而异。

结论并不是 CoDel 在实验室之外就会失败，而是部署必须识别瓶颈，并防止其下游不受控制的缓冲重新制造问题。一个位于错误队列上的好控制器，观察的是错误的系统。

这就是用户可感知测试重要的原因。运营商应测量负载下的延迟，而不仅仅是检查 qdisc 配置。双向测试、应用性能和硬件计数器可以揭示软件队列之外的延迟。算法的内部状态只是关于某一层的证据，而不是整条路径的全部真相。

许多接入链路并没有固定的离开速率。无线调制随信号条件变化；有线电视和无源光系统共享容量；移动调度器随时间分配无线资源。家庭路由器可能只知道标称服务等级，而不知道瞬时瓶颈。

固定数据包阈值在这种环境中表现尤其糟糕，因为数据包所代表的延迟会随速率变化。驻留时间保持其单位，这也是 CoDel 具有吸引力的原因之一。队列可以观察到数据包开始等待更久，而无需先估计与目标值相对应的新字节数。

控制器仍然只在其所在位置运行。如果可变速率调制解调器或无线电在主机之后保留一个大队列，软件 CoDel 就无法观察到真实的离开时间表。设置在最低预期速率以下的整形器可以将队列移入软件，但可能在链路改善时浪费容量。跟踪速率的整形器表现更好，但需要来自接入技术的可靠反馈。

这种权衡解释了为什么 AQM 常常与设备集成密不可分。算法可以是通用的，而高质量产品需要速率信息、硬件队列限制以及与链路调度的协调。公开伪代码降低了实现门槛，但并未消除供应商的工程责任。

可变服务也使对区间的解释复杂化。CoDel 的设计目的是在与常见往返相关的时间尺度上对持续延迟作出反应，而不是追逐每一次瞬时的速率波动。反应过快可能在无线电短暂降速时丢弃有用的突发；反应过慢则会让积压变得用户可见。

设计中对最近最小值的运用有所帮助。如果容量恢复后队列排空，最小值会记录这一缓解；如果尽管速率变化队列始终未排空，持续状况仍然可见。这比瞬时占用率是否越过固定阈值的问题更为稳定。

较新的接入系统可以增加更丰富的调度和按站公平性。这些特性可能解决独立 CoDel 无法处理的竞争问题。该算法仍然是一个组件，其传感器之所以有用，正是因为链路的字节容量并非恒定。

不响应流量与策略可能压垮延迟控制器

CoDel 的信号假设有足够多的流量通过降低发送负载来作出响应。TCP 和其他受拥塞控制的传输协议被设计为这样。忽略丢失和 ECN 的应用或攻击则可以继续以相同速率发送。

队列无法创造容量。如果不响应流量占据瓶颈，更频繁地对其进行丢弃或标记可能保护部分响应流量，但可能还需要策略和调度。逐流排队可以隔离违规者；策略管制可以强制速率；受管服务可能需要准入或应用控制。

这一限制并非 CoDel 独有。拥塞控制是一种协作架构，部分通过端点行为、部分通过网络策略来执行。关于拥塞责任的 RFC 指南之所以存在，是因为一个不响应的流就可能给其他流带来延迟和丢失。

流量类别可以提供帮助，也可能造成另一种故障模式。没有有效速率限制的优先类别可能使尽力而为流量挨饿；分类规则可能错误或被滥用。每个队列内部的 AQM 管理延迟，但它并不决定类别分配是否正当。

运营任务是理顺激励。当队列及早发出信号且竞争者也降低负载时，响应型应用受益。不响应发送方在受到网络边界约束之前，可能从占据更多份额中获益。FQ-CoDel 及相关调度器改善了隔离，但它们不能替代所有滥用防护或服务策略控制。

当置于这种系统视角中时，Nichols 的工作最有说服力。CoDel 提高了本地拥塞证据的质量和反馈时机，但它并不声称对路径上的每个发送方或每个队列拥有绝对权威。

Linux 与 RFC 将设计转化为持续维护的基础设施

从论文和伪代码到内核排队规则，需要实现、审查、测试和长期维护。Linux 支持使 CoDel 可用于各种基于该内核构建的主机、路由器和产品。

Eric Dumazet 是与 Linux 实现相关的贡献者之一，后来的 FQ-CoDel 工作则涉及另一组开发者。内核源码为具体变更提供了有边界的证据，但这并不使每次部署都成为某个贡献者的个人项目。

qdisc 必须与 Linux 流量控制、时间戳、数据包元数据、ECN 和调度器惯例集成。用户空间工具需要配置和显示它。发行版和设备供应商决定是否构建、暴露该模块并将其设为默认。硬件路径决定其外部还保留多少缓冲。

这一供应链使开放实现变得重要。研究人员和运营商可以检查代码、将其与 RFC 对比并测试修改。缺陷仍可能存活。不同的内核可以反向移植修复或携带供应商变更。可用的源码树是审计机会，而不是每台设备都运行相同代码的保证。

RFC 8289 于 2018 年 1 月作为 Experimental 发布，保留了详细伪代码和设计推理。其类别很重要：它记录了一种旨在实现和评估的机制，而不是强制要求进入标准轨道。广泛可用性与 Experimental 状态可以并存。

RFC 对归属的界定也比产品营销通常更清晰。Nichols 和 Jacobson 是 CoDel 的设计者，而编辑和实现社区有自己的角色。FQ-CoDel 的 RFC 列出了一个不同的作者团队。

这种分层作者身份在基础设施中很常见。研究人员定义控制律；内核开发者使其安全高效；发行版维护者将其打包；运营商将其放入拓扑；应用用户体验最终结果。当档案遵循这条链条，而不是寻找低延迟的唯一发明者时，会更准确。

RFC 8289 被归类为 Experimental。在公开讨论中，这一标签有时被解读为该机制未经证实的警告，有时又被忽略，仿佛每个 RFC 都是互联网标准。两种解读都不充分。

IETF 使用文档类别来表示状态和意图。Experimental RFC 可以提供完整、可审查的规范，用于实现和评估，而无需产生标准轨道要求。CoDel 的 RFC 包含详细推理和伪代码，因为独立实现需要的不仅仅是一篇高层次论文。

该类别将部署决定留给实现者和运营商。Linux qdisc、路由器固件或接入产品都可以使用该算法。供应商应验证实现并说明环境。RFC 编号并不认证产品，Experimental 状态也不禁止生产使用。

这一状态还可以防止事后的夸大。CoDel 或 FQ-CoDel 在开放系统中的存在是其影响力和可用性的证据，但并不存在对活跃配置、瓶颈位置或性能的完整审计普查。软件包数量和产品文档无法填补这一空白。

标准成熟度与运营成熟度可能以不同速度推进。一种机制可能被广泛部署，却仍保持 Experimental，因为标准流程尚未改变其类别；另一种机制可能处于标准轨道却极少被启用。报道应同时描述这两个维度，而不是让一个标签代表另一个。

RFC 的价值部分是档案性的。它确定了设计假设、目标值和区间的含义、控制律以及可用于代码审查的实现说明。后来的内核变更和平台适配都可以与该基线进行比较。

对 Nichols 的档案而言，这一状态强化了以证据为主导的论点。CoDel 是作为一个具有明确假设和限制的实用控制器被提出的，而不是宣称低延迟问题已经解决的命令。它的声誉应该继续取决于真实队列中的测量结果。

Pollere 将独立专业知识置于标准与产品之间

Pollere LLC 为 Nichols 提供了一个位于大型设备供应商或传统研究实验室之外的机构载体。其公开描述以网络与电信咨询为中心。现有证据未披露完整的客户名单、收入、员工数量或当前业务量。

这种信息缺失限制了商业画像，但也澄清了相关重点。Pollere 使技术工作和咨询得以继续，而无需将 CoDel 视为初创公司拥有的专有产品。该算法被公开发表、开放实现，并通过 IETF 制定规范。

独立咨询可以将运营商问题与研究议程联系起来，但也可能使项目资金和时间分配变得不透明。一份公开 RFC 可能在全球被使用，而其背后的设计工作却可能通过咨询、雇主时间、研究合作或无报酬贡献来支持，各部分比例对读者不可见。

其经济模式与销售设备的供应商不同。Pollere 的价值在于专业知识：架构、分析和建议。CoDel 的价值在于供应商和运营商可以实现的开放机制。使用 CoDel 的产品收入不会成为 Pollere 的收入，产品采用也不意味着与 Nichols 建立了商业关系。

这种分离使文章避免两个常见错误：一是把开放算法描述成公司产品；二是从技术影响力推断商业规模。Nichols 的工作可以塑造许多系统中的队列，却并不一定在每个部署上都形成已披露的经常性业务。

关于当前职位的保留说明应放在这里。Pollere 的公开页面将她列为创始人兼首席执行官，但没有附带近期的、注明日期的领导层公告。该职位可以按公司的公开描述来报道，并附上这一限制，而不是被悄然转换为一项刚刚核实的任命。

CoDel 承继 RED，但并未抹去早期 AQM 的价值

CoDel 属于活跃队列管理谱系，其中包括 Sally Floyd 和 Van Jacobson 的随机早期检测（RED）。RED 提出在溢出之前通过跟踪平均队列大小来发出拥塞信号，并在平均值超过配置阈值时按概率丢弃或标记。这是远离尾部丢弃的开创性举措。

RED 也暴露了一个运营问题。阈值、平均值和丢弃概率与容量、往返时间和流量相互作用。精心配置的部署可以表现良好；通用设备默认值则可能过于保守、过于激进或实际上不起作用。这一困难导致采用情况不均衡，也促使后来设计更具自适应性的控制器。

Nichols 的工作不应被叙述成新一代对 Floyd 工作的修正，仿佛后者已经过时。RED 确立了主动队列管理和早期拥塞信号的必要性；CoDel 改变了被观察的变量以及信号强度的控制方式。两种设计都是协作成果，源于同一广泛关切：等待缓冲区溢出并不是管理反馈网络的良好方式。

这一比较澄清了 CoDel 的贡献。RED 根据平均占用率估计拥塞；CoDel 根据最近最小驻留时间估计持久队列延迟。RED 通常需要配置最低和最高阈值以及最大标记或丢弃概率；CoDel 使用目标值、区间和有状态控制律，旨在以正常默认值工作。

两种算法都无法克服缺失的反馈回路。二者都依赖响应型流量或补充性的调度与策略管制；二者都可能被放在错误的队列上；二者都可能被一次改变多个系统变量的基准测试所误读。

历史关联也需要精确的个人归属。Jacobson 与 Floyd 合作过 RED，与 Nichols 合作过 CoDel。这一共同的合作者并不意味着两个算法是同一个项目，也不意味着作者身份在两位研究人员之间转移。Floyd 在 ECN、拥塞原则和评估方面的更广泛工作帮助塑造了 CoDel 后来运行其中的架构；Nichols 的设计则针对一个具体的控制器和部署问题。

成熟的新闻报道保留这种连续性，比宣布谁胜出更有价值。基础设施通过暴露早期机制局限性的机制而演进。RED 使早期信号合法化；CoDel 使持久等待时间成为传感器；FQ-CoDel 后来将该控制器与流隔离结合。每一层都回答了不同的运营问题。

负载延迟测试改变了运营商能够提出的要求

队列管理算法很难通过空闲测量来评估。当没有流量竞争瓶颈时，几乎任何队列看起来都是低延迟的。有用的测试会制造持续负载，并观察在吞吐量保持活跃的同时出现了多少额外延迟。

这种负载延迟视角将缓冲区膨胀研究与用户体验联系起来。它使链路传播时间与压力下队列所增加的时间之间的差异变得可见。接入产品不能再仅凭测速吞吐量来为糟糕的交互性辩护。

测量必须谨慎设计。单一的 ping 流可能受到特殊对待，也可能不代表应用流量。单向加载可能遗漏确认和反向路径队列的影响。短时测试可能无法揭示控制器收敛。附近的测试服务器对长路径传播说明不了什么，却可以更清晰地隔离接入排队。

运营商应区分若干量：基线往返时间、上传期间的额外延迟、下载期间的额外延迟、丢失或 ECN 标记、实际吞吐量以及负载停止后的恢复。好的结果不是某一维度上可能的最小值，而是与服务目标相符的、可辩护的平衡。

CoDel 内部的驻留测量与外部的负载延迟测试回答不同的问题。内部控制器知道一个队列中的等待；外部测试观察的是队列和路径效应的总和。当 qdisc 报告低延迟而外部测试报告高延迟时，这种差异就是存在另一个瓶颈或隐藏缓冲区的证据。

这种比较可以指导部署。运营商可以以受控速率进行整形、启用 FQ-CoDel、重复负载测试并检查延迟在哪里发生了变化。这一过程比仅仅因为配置命令成功就认定某个有名算法已经解决问题更为可靠。

产品声明也需要同样的纪律。“支持 CoDel”只是确认了一个选项；“默认使用 CoDel”只是确认了一种配置。二者都不能确证在客户接入技术下的低延迟。结果取决于速率检测、卸载、Wi-Fi、固件、提供商调度和端点行为。

Nichols 工作更广泛的意义在于，它使本地控制目标与外部服务指标相兼容。可以要求队列将其持续贡献保持在目标值以下，并在负载下测试网络，以检验本地成功是否惠及用户。

低延迟是一个多指标结果，也需要退出路径

如果 AQM 浪费容量、惩罚某些流或在条件变化时变得不稳定，那么即使它减少了持续延迟，也可能并不合适。评估 CoDel 需要多项测量，其间的权衡应当保持可见。

吞吐量确证瓶颈是否被有效利用。延迟应作为分布来测量，包括负载下的数值和尾部数值，而不仅仅是平均值。丢失和 ECN 标记显示反馈的成本和形式。队列占用率有助于解释机制，尽管它不是 CoDel 的主要传感器。

公平性有多种定义。流公平性询问并发流是否获得可比较的份额；用户公平性认识到一个应用可以打开许多流；RTT 公平性考察较短路径是否获得优势。稀疏交互式流与持续批量传输对服务的价值不同，这就是流排队可能比单一的聚合延迟统计更重要的原因。

收敛和恢复值得单独测试。控制器应在负载上升时作出响应，并在队列改善后停止发送信号。可变速率链路、突然的容量损失和短突发可能暴露稳态基准中隐藏的振荡或迟缓。

比较时必须保持系统其他部分不变。用 FQ-CoDel 替换尾部丢弃会同时改变队列管理和调度；添加整形器会移动瓶颈；禁用卸载会改变数据包表示和 CPU 成本。这些干预可能是正确的，但报告不应把全部结果都归于 CoDel 本身。

工作负载的多样性也很重要。长 TCP 流揭示稳态反馈；类似 Web 的短传输强调启动和排队；实时流量测试稀疏数据包；不响应 UDP 揭示隔离或策略管制的必要性；混合 RTT 和双向负载暴露单流测试中所没有的相互作用。

Nichols 的贡献鼓励这种严谨，因为算法始于一个可测量的目标。同样的严谨也必须应用于关于成功的声明。较低的本地驻留时间是关于受控队列的有力证据；有用的产品结果应将该证据与规定条件下的吞吐量、公平性和端到端体验联系起来。

队列策略可能因内核回归、不适当的默认值或与硬件的意外交互而失败。运营商应当能够将新 qdisc 与先前状态进行比较，在不丢失管理访问的情况下回滚，并保留故障期间的证据。

回滚并不只是一条命令。替换 qdisc 会改变已排队的数据包，并可能导致瞬时丢失或突发。整形器可能已经移动了瓶颈，因此将其移除可能重新填满隐藏的调制解调器队列，即使恢复了先前的配置，延迟也可能变得更糟。

受控部署应记录内核、驱动、卸载、目标值、区间、整形速率和流量组合。它在负载下测量前后差异，并在软件升级后保持相同测试。这些证据可以区分算法问题与链路或设备路径的变化。

CoDel 的设计初衷是减少常规调优。由于队列是实时流量上的主动控制点，运营纪律仍然必要。

CoDel 的遗产在于决定控制时间而不是占用率

队列管理仍在不断演进。PIE 使用另一种面向延迟的控制器；FQ-CoDel 将流调度与 CoDel 结合；CAKE 增加整形和公平策略；L4S 和 DualQ 通过不同的 ECN 语义和传输期望追求低延迟服务。硬件供应商实现专有队列系统，其细节可能较少可见。

CoDel 的持久贡献并非证明某个算法在每次比较中都获胜，而是改变了众多工程师围绕其定义问题的变量。用户体验的是时间。一个保持占用的队列之所以有害，是因为它制造的延迟和推迟的反馈，而不是因为某个数据包数量在道义上过大。

最近最小值估计器为队列是否排空提供了实用测试；控制律提供了一种无需运营商设定丢弃概率的响应；通用默认值使部署无需逐链路的专业知识即可进行。

即使在后续系统增加流隔离、更丰富的整形或不同信令之后，这些思想仍然存在。它们也暴露了自身的局限：控制器无法看到隐藏队列；无法强迫不响应发送方合作；无法决定类别策略；无法保证端到端延迟。

Nichols 的职业生涯为这一机制提供了更广泛的背景。DiffServ 将流量处理分离为可扩展的行为；供应商和初创公司的角色将架构与产品连接起来；Pollere 保留了一个独立的基础。CoDel 将这种经验聚焦于一个可测量的失败：数据包在等待无法带来额外吞吐量的地方持续等待。

克制的评价比英雄式的评价更有力。Nichols 并没有单枪匹马解决缓冲区膨胀、创建 FQ-CoDel 或定义所有现代 AQM。她共同设计了一个控制器，其测量方式和运营追求改变了该领域的实践词汇。

运营商从这项工作中可以得到的最有用一句话，也是最苛刻的一句话是：找到真正的瓶颈，测量数据包在那里花费的时间，并在队列成为路径永久组成部分之前发出信号。