PDF控制队列延迟
现代主动队列管理（AQM）只是解决缓冲区膨胀问题的一个环节。
Kathleen Nichols，Pollere Inc.
Van Jacobson，PARC
自从首次诊断出“持续满缓冲区问题”近三十年后，最近被揭露为缓冲区膨胀6,7的一部分，这个问题仍然存在，并且由于两个趋势而变得越来越关键。首先，廉价的内存和“多多益善”的心态导致了缓冲区的膨胀和扩散。其次，动态变化路径特性在今天更为常见，并且是消费者互联网边缘的常态。当链路速率和路径延迟降至标称值以下时，合理大小的缓冲区会变得异常过大。
持久满缓冲区的解决方案，即主动队列管理（AQM），已经为人所知二十年，但由于实施困难以及对互联网数据包丢失和队列动态的普遍误解，尚未得到广泛部署。未管理的缓冲区在今天更加关键，因为缓冲区大小更大，对延迟敏感的应用程序更为普遍，并且大型（流媒体）下载很常见。互联网边缘持续存在的极端延迟可能会影响其可用性，并阻碍新应用程序的增长。
本文旨在提供缓冲区膨胀解决方案的一部分，提出一种适用于当今互联网的创新型 AQM 方法，称为 CoDel（Controlled Delay 的缩写，发音像“coddle”）。这是一种“无旋钮”的 AQM，可适应变化的链路速率，并且适合在基于 Linux 的路由器（以及硅芯片）中部署和实验。
应对缓冲区膨胀
数据包网络需要缓冲区来吸收短期到达速率波动。虽然缓冲区对于数据包网络的运行至关重要，但缓冲区往往会在拥塞链路处填满并保持满状态，从而导致过度的流量延迟，并丧失其吸收突发流量的预期功能。“满缓冲区问题”在互联网早期就被认识到，当时就探索了缓解措施。9,15,17
1998 年，互联网研究任务组（Internet Research Task Force）敦促在互联网中部署主动队列管理1，特别推荐了随机早期检测（RED）。5 虽然 RED 简单且可以有效地减少持久队列，但几乎没有关于设置其配置参数的指南，并且它在许多情况下运行不佳。这导致人们普遍不愿使用它。随着 RED 问题的显现，研究记录了这些问题并提出了新的 AQM，为原始 RED 增加了更多的配置和复杂性。尽管 Feng 等人22 在 2002 年指出队列长度不是拥塞的良好预测指标，但它仍然被使用。尽管研究仍在继续，但部署却没有。
互联网通过链路速率的不断提高和使用模式，避免了灾难性的后果。在过去的十年中，越来越多的证据表明，这种自欺欺人的做法不能再继续下去了，否则将严重影响互联网的使用：独立的测量研究4,13 发现边缘排队延迟从数百毫秒到几秒不等。这些测量研究和缓冲区膨胀项目2 记录了网络边缘大型、未管理缓冲区的有害影响。
正确的缓冲区大小调整并非易事。缓冲区过小——使缓冲区小于传统的 BDP（带宽延迟乘积）——会带来诸多问题，8 Guillaume Vu-Brugier 等人20 很好地说明了这一点。今天的链路带宽各不相同，并且各个连接的往返时间（BDP 中使用的“延迟”）也各不相同。这使得为大多数边缘链路正确选择静态大小变得不可能。13,14 一种简单、稳健的算法，可以管理缓冲区延迟，而无需考虑缓冲区大小和链路带宽，并且不会对利用率产生负面影响，可以使过大的缓冲区变得无关紧要。
理解队列
有效的主动队列管理的发展受到了对队列的起因和意义的误解的阻碍。网络缓冲区存在是为了吸收统计复用网络中自然发生的数据包突发。队列的出现是由于上游资源争用、传输会话启动瞬态和/或共享链路的会话数量变化导致流量到达率和离开率的短期不匹配。不幸的是，其他网络行为也会导致缓冲区填满，其影响远非良性。由于对队列的概念模型错误，AQM 的操作范围有限，需要大量的配置调整，并且经常会损害而不是改善性能。
图 1 显示了 TCP 连接启动后不久的情况（更多讨论请参阅“拥塞避免和控制”8）。发送方背靠背地启动其 25 个数据包的窗口，它们流经网络，直到遇到瓶颈（带宽减少）。在那里，随着每个数据包的带宽被压缩，它必须在时间上拉伸，因为其大小保持不变。垂直方向是带宽（比特/秒），水平方向是时间（秒），因此每个矩形的面积是数据包大小（比特/秒 × 秒 = 比特）。例如，如果数据包的长度为 1 毫秒，并且带宽从 100 Mbps 减少到 10 Mbps，那么第二个数据包将在第一个数据包到达后 1 毫秒到达，但必须额外等待 9 毫秒，因为第一个数据包需要 10 毫秒才能离开。第三个数据包必须额外等待 18 毫秒，等待第一个和第二个数据包都离开，依此类推。这种瓶颈引起的等待是造成队列在链路的数据包缓冲区中形成的原因。
图 2 显示了连接在一个 RTT（往返时间）后的情况。瓶颈将数据包隔开，并且它们在离开后保持这种间隔。接收方只是将数据包转换为 ack（确认数据包），因此 ack 流在返回路径上保持间隔。发送方将每个 ack 转换为数据包，因此，仅在一个 RTT 后，瓶颈处的数据包到达率完全等于离开率，并且队列不会增长。这在图 3 中清晰可见，图 3 显示了瓶颈队列大小与时间的关系。有一个初始峰值，对应于初始窗口大小的背靠背数据包，但它在一个 RTT 后消散，仅留下由到达和离开过程中的小相位差引起的 ±1 个数据包的波动。
但是请注意，图 3 中的稳态队列不为零。图 1 和图 2 的尺寸大小使得发送方和接收方之间的时间距离为 10 个瓶颈数据包时间（例如，如果瓶颈数据包间隔为 10 毫秒，则为 100 毫秒）；因此，需要 20 个正在传输的数据包来“填满管道”并使用 100% 的瓶颈容量。在此示例中，窗口大小为 25 个数据包，比管道中可容纳的数据包多五个（BDP，以数据包衡量）。这些数据包创建了一个常设队列，无法消散。这在图 2 中清晰可见：当第 26 个数据包即将到达瓶颈时，其队列中仍然有五个数据包；但是，从此时起，每当一个数据包离开时，另一个数据包就会到达。因此，队列中将始终有五个数据包（±1），即使发送方的速率是恒定的。常设队列与发送方的速率无关，而与发送方的窗口大小超出管道大小的程度有关。
这种由窗口大小和管道大小不匹配导致的常设队列是缓冲区膨胀的本质。它会造成大的延迟，但不会提高吞吐量。它不是排队论或流量理论处理的现象，不幸的是，这导致它几乎普遍地被错误地归类为拥塞（一种完全不同且更为罕见的病态）。这些理论通常假设泊松到达过程，根据定义，这些过程是不相关的。诸如 TCP 之类的闭环、可靠传输过程的到达是完全相关的，从而导致到达率和离开率相等，理论家们认为这是不自然的，并且极不可能发生。由于诸如使用限制或基于使用的计费之类的针对拥塞的常规疗法对缓冲区膨胀无效，但会惹恼客户并阻碍网络使用，因此解决真正的问题是明智的。
缓冲区膨胀问题，即使窗口大小与管道大小匹配，很难解决。窗口大小由发送方选择，而队列则在瓶颈网关处显现。发送方很难计算窗口大小，因为瓶颈带宽和 RTT 这两个术语都随着连接的来来往往、路径因重新路由而改变、第 1 层和第 2 层协议适应带宽以适应不断变化的物理条件等而不断变化。由于队列可以在瓶颈处直接测量，因此最有希望的方法是在那里检测问题，然后向发送方发出信号以减小其窗口大小（通过 TCP 拥塞控制机制）。
然而，可靠的检测很困难。图 3 开始时的大队列是连接启动所必需的，因此队列大小不包含有关过度队列的信息。问题在于图 3 的平坦部分这一事实导致一些研究人员将缓冲区被占用的时间视为一个指标。
图 4 显示了 TCP 接收方的队列与时间的关系，该接收方每个窗口发送一个 ack，而不是每个数据包发送一个 ack。这是一种合法的，但脆弱的操作模式，一些商业操作系统使用这种模式，这些操作系统具有非常高的每数据包开销，以减少生成的 ack 的数量，从而在基准测试中表现出色。这种队列长度变化也出现在 Web 流量中——主要是小型传输的叠加，这些传输本质上都是启动瞬态。由于这种 ack 策略意味着一个完整窗口的数据包总是作为背靠背突发交付，因此初始启动瞬态每 RTT 重复一次，并且缓冲区始终被占用。但是，窗口完全填满了管道，并且没有过度的队列，因此任何减少此队列的尝试都会导致瓶颈的利用率低下。因此，占用时间不包含有关过度队列的信息。
图 4 和图 3 的前导部分显示了队列正在执行其工作——充当减震器，将突发到达转换为平稳、稳定的离开。这是好的队列。图 3 的尾端显示了一个队列除了造成过度延迟外什么也没做。这是坏的队列。缓冲区膨胀检测问题的核心是将好的队列与坏的队列分开。图 3 暗示了成功的策略：好的队列是大约在一个 RTT 内消失的占用；坏的队列持续几个 RTT。分离两者的一种简单、稳健的方法是取一个滑动时间窗口内的队列长度的最小值，该窗口比标称 RTT 长。
受控延迟管理
在 1998 年初，我们着手了解为什么最初的 RED 难以配置，并提出了一种新的 RED 算法（在一次演讲和一篇未发表的论文10,12 中描述），该算法只需要一个参数：队列的输出带宽或平均离开率。尽管性能有所提高，但问题仍然存在——几乎任何东西都适用于长寿命 TCP 传输，但几乎没有任何东西适用于突发流量。自那以后的十年中，许多研究人员在 AQM 方面取得了长足的进步，但没有人生产出具有以下特性的 AQM
• 它是无参数的——它没有供运营商、用户或实施者调整的旋钮。
• 它区别对待好的队列和坏的队列——也就是说，它在保持低延迟的同时允许突发流量。
• 它控制延迟，同时对往返延迟、链路速率和流量负载不敏感。
• 它适应动态变化的链路速率，而不会对利用率产生负面影响。
• 它简单而高效——它可以轻松地跨越从低端、基于 Linux 的接入点和家庭路由器到高端商业路由器芯片的范围。
一个代码模块，没有旋钮，任何链路速率
CoDel（受控延迟管理）具有三个主要创新，使其与之前的 AQM 区分开来。首先，CoDel 的算法不是基于队列大小、队列大小平均值、队列大小阈值、速率测量、链路利用率、丢包率或队列占用时间。从 Van Jacobson 2006 年的见解11 出发，我们使用局部最小队列作为更准确、更稳健的常设队列度量。然后我们观察到，只需保持一个单状态变量，记录最小值高于或低于常设队列延迟目标值的时间长度，而不是保持一个值窗口来计算最小值就足够了。最后，与其以字节或数据包为单位测量队列大小，不如使用数据包在队列中的停留时间。使用每个数据包经历的实际延迟与链路速率无关，比使用缓冲区大小提供更好的性能，并且与用户可见的性能直接相关。
使用最小值有一些重要的含义。只有当数据包出队时，才能减小最小数据包停留时间，这意味着 CoDel 的所有工作都可以在数据包出队进行传输时进行，并且在实现中不需要锁。最小值是唯一具有此属性的统计量。数据包到达的唯一增加是创建数据包到达时间的时间戳。如果缓冲区在数据包到达时已满，则可以像往常一样丢弃数据包。
CoDel 假设目标值的常设队列是可以接受的，并且当缓冲区中字节数少于一个 MTU（最大传输单元）时，丢弃数据包是不可接受的。CoDel 通过跟踪数据包经历的（局部）最小队列延迟来识别持久延迟。为了确保最小值不会过时，它必须在最近的间隔内经历过。当队列延迟超过目标值至少间隔时间时，将丢弃一个数据包，并且控制律设置下一个丢弃时间。下一个丢弃时间与自进入丢弃状态以来丢弃次数的平方根成反比地减小，使用丢包率与吞吐量之间的众所周知的关系来获得吞吐量的线性变化。12,16 当队列延迟低于目标值时， 控制器停止丢弃。如果缓冲区包含的字节数少于一个 MTU，则不执行丢弃。附加逻辑可防止在退出丢弃状态后过快地重新进入丢弃状态，并在最近的控制级别恢复丢弃状态（如果存在）。
目标值和间隔是具有直接解释的常数：可接受的常设队列延迟和与通过瓶颈的连接的最坏情况 RTT 数量级的时间。我们进行了实验以确定目标值和间隔值，这些值在各种带宽、RTT 和流量负载下都能提供始终如一的高利用率和受控延迟。低于 5 毫秒的目标值，在某些条件和流量负载下，利用率会受到影响；高于 5 毫秒，利用率几乎没有或没有改善。间隔与 RTT 松散相关，因为它被选择为给端点时间做出反应，而又不会太长而导致响应时间受到影响。100 毫秒的设置在 10 毫秒到 1 秒的 RTT 范围内效果良好（在 10 到 300 毫秒范围内实现了出色的性能）。（CoDel 的伪代码包含在附录中，可在以下网址获取： https://queue.org.cn/appendices/codel.html">
CoDel 的高效实现和缺乏配置是使其适用于管理现代数据包缓冲区的独特功能。三个创新——使用最小值而不是平均值作为队列度量、简化的最小值的单状态变量跟踪以及队列停留时间的使用——直接导致了这些独特的功能。
模拟实验
没有网络模拟能够高度逼真地表示现实；CoDel 的真正考验将来自在网络上的部署。尽管 CoDel 的功能及其优点的评估是我们主要关注的问题，但一些 AQM 比较可以作为健全性检查。我们进行了数千次模拟运行，瓶颈带宽从 64kbps 到 100mbps 不等，端到端延迟从 5ms 到 1 秒不等，同时批量数据传输从 0 到 50 不等，PackMime Web 流量强度从 0 到 80 不等，有和没有 CBR 流量，同时使用 Reno 和 CUBIC TCP 拥塞控制，并且所有这些都使用 CoDel，使用附录中给出的相同、恒定的配置值。如下几节中的汇总数据所示，CoDel 表现非常好。最重要的是，当链路速率动态变化时——即使变化多达两个数量级——CoDel 也能适应。结果足以令人信服，可以继续进行下一步，即在基于 Linux 的路由器中进行广泛的真实世界测试。
模拟器配置。 为了方便起见，我们使用了免费提供的 ns-2 模拟器。18 我们的文件传输应用程序使用了 Linux TCP 套件，主要使用 CUBIC 拥塞控制。结果（在线提供）与 New Reno 相似，但利用率略低，正如预期的那样。为了模拟 Web 浏览负载，我们使用了 PackMime，21 它与 ns-2 Full-TCP 协议一起运行，并使用 New Reno 拥塞控制算法。恒定比特率应用程序使用 UDP（用户数据报协议），并配置为 64 Kbps，数据包大小为 100 字节。所有 TCP 都配置了现代参数，包括使用 SACK。在大多数情况下，CoDel 的管理缓冲区设置得非常大（约 8xBDP 数据包），以验证缓冲区的实际大小无关紧要。为了进行比较，我们还使用 ns-2 RED AQM 模块代替 CoDel 运行了许多测试场景。我们使用了 ns-2 RED 的最新设置和代码，它读取初始链路带宽和延迟来调整其设置，而不是 Floyd 和 Jacobson 的原始 RED。5 我们还尝试使用 BLUE22 运行场景，但其默认设置表现不佳，并且有限的实验并没有产生效果良好的设置，因此我们没有继续进行。
指标。 AQM 感兴趣的指标——队列延迟和大小、链路利用率以及流量之间丢包的“公平性”——可能对流量混合类型和链路带宽非常敏感，10,12,20 因此我们测试了一系列流量负载和条件。成功传输（未丢弃）的数据包的每数据包队列延迟特别有用。可以针对单次运行的模拟时间查看此延迟，也可以使用运行期间的统计信息（例如，中位数和第 95 个百分位数）进行比较和趋势分析。监控链路利用率可确保队列管理不会对吞吐量产生负面影响。虽然不是我们主要关注的问题，但我们使用了 Jain 公平性指数来查看每个源的丢包份额是否在一定程度上与传输的数据包数量成比例，为 n 个样本计算如下：
跨越一系列静态链路速率的性能
CoDel 是相同的代码，具有相同的设置，与出口链路速率无关。为了了解它的工作效果如何，我们从许多流量负载（FTP，有和没有添加 Web 浏览和恒定比特率应用程序）和 10-500 毫秒的 RTT 中收集了中位数数据包延迟和链路利用率值，按链路带宽对其进行排序，并绘制了箱线图结果。这些结果分别显示在较大带宽（图 5 中的 3 Mbps、10 Mbps、45 Mbps 和 100 Mbps）和较小带宽（图 6 中的 128 Kbps、256 Kbps、512 Kbps 和 1.5 Mbps）中。RED 的结果也显示在较大带宽中，但较小集合的中位数延迟过高（100-200 毫秒）。
CoDel 仅在其最小延迟统计量超过 5 毫秒且缓冲区至少包含链路 MTU 大小的字节数时才会丢弃数据包。对于 MTU 小于 5 毫秒（较大带宽组）的链路以及由所有长寿命 FTP 组成的流量负载，中位数延迟应接近此目标值。CoDel 旨在允许短期突发；因此，突发流量模式的中位数应高于 5 毫秒的目标值。对于较大带宽，数据包突发造成的延迟与目标值相比很小（例如，在 100 Mbps 时，1,500 字节的数据包在 0.1 毫秒内传输），因此负载变化对中位数的影响较小。在较小带宽下，附加数据包造成的延迟与目标值相比显着（例如，对于 3 Mbps 链路为 4 毫秒），并且中位数延迟将明显更大。这正是所需的行为：较长的延迟不会过高，并且允许链路利用率保持在较高水平。图 5 显示 CoDel 延迟符合预期，并且链路利用率良好。RED 的延迟和利用率对于 3 Mbps 链路相似，但对于 10 Mbps 及以上的链路，延迟和利用率较小。低利用率表明 RED 可能过度控制。
图 6 中显示的较低带宽值使用较小的 RTT 范围（30-100 毫秒）。此类链路速率可以在消费者互联网接入边缘（手持设备、家庭）或降级的 Wi-Fi 链路上预期。静态低带宽链路通常使用较小的链路 MTU，因此我们收集了链路 MTU 设置为 500 字节以及用于所有其他运行的 1,500 字节 MTU 的数据。正如预期的那样，较大的 MTU 会增加延迟，但随着带宽的增加，增加的幅度较小。低带宽链路的利用率通常良好，因为它们很容易通过 FTP 混合流量来填充。在每个带宽下，只有 PackMime Web 浏览完成了一些运行，这使得难以获得高利用率；我们不得不接受超过 10% 的丢包率才能获得超过 60% 的利用率。
动态链路上的性能
在模拟中可以进行一些动态链路测试。为了大致模拟受降级影响的（标称）100 Mbps Wi-Fi 链路，我们使用了每秒 4 个 FTP 和 5 个 Web 连接的负载，并在 50 秒的时间间隔内（在 300 秒的模拟时间内）更改链路速率，首先降至 10 Mbps，然后降至 1 Mbps，然后跳至 50 Mbps，降至 1 Mbps，最后跳回 100 Mbps。缓冲区容量对于标称速率为单个 BDP（830 个数据包）。针对 CoDel、尾部丢弃（Tail Drop）和 RED 重复了此场景。
图 7 显示了每数据包队列延迟和随着模拟时间推移累积传输的千字节数。正如预期的那样，尾部丢弃通常会保持其缓冲区满，从而使数据包延迟的时间量等于在当前链路速率下传输满缓冲区的数据包所需的时间。该延迟可能高达 10 秒。RED 使队列延迟小于尾部丢弃，但对更改的响应不如 CoDel 快。CoDel 允许在 FTP 启动时出现初始峰值，并为当前条件学习丢包率。当链路速率下降时（在 50 秒、100 秒和 250 秒时），延迟会飙升，因为队列大小对于新速率而言现在太长了。CoDel 在 100 毫秒内计算出一个新的控制点，这是局部最小值有效的最大间隔。是否应该做任何事情来加速这一点是一个悬而未决的问题；初步研究表明，最好不要尝试“清除”积压。如果几分钟内发生一个或多个数量级的速率变化很常见，那么这个问题可能需要进一步研究。
将传输的千字节数与队列延迟进行比较，很容易看出高利用率不需要长延迟。CoDel 传输的总千字节数几乎与尾部丢弃相同，差异出现在速率跳跃（150 秒和 250 秒）时，此时 CoDel 的 FTP 必须加速以填充新的管道大小，而尾部丢弃的队列则发送其积压。缓冲区过小不是解决缓冲区膨胀的答案。图 7 显示了使用 10 个数据包缓冲区的相同场景，该大小适用于 1 Mbps 速率。对于所有三种方案，吞吐量都减少了约 75%（尾部丢弃和 CoDel 是相同的）。尾部丢弃倾向于保持其 10 个数据包的缓冲区满，这将导致最坏情况下的延迟为 120 毫秒，但吞吐量仅为使用大型 CoDel 管理缓冲区可实现的吞吐量的 25%，而大型 CoDel 管理缓冲区的平均延迟为 2.7 毫秒，第 75 个百分位延迟为 5 毫秒，并且在总模拟时间的 95% 内小于 90 毫秒。
丢弃正确的数据包
尽管当今大多数网络分析都假设连接具有未加载的 100 毫秒 RTT，但在实践中，RTT 会发生变化。除非路径包含卫星链路，否则 1 秒范围内的 RTT 通常是由缓冲区膨胀引起的，而不是固有的路径特性。在消费者边缘，很少有连接的 RTT 小于 30 毫秒。由于 CoDel 的间隔与 RTT 弱相关，因此我们测试了 100 毫秒设置在各种可能的 RTT 范围内的有效性，并报告了 10 到 500 毫秒范围内的结果。
图 8 显示了按 RTT 排序的各种流量负载的结果。CoDel 和 RED 都保持了较低的中位数延迟，但 CoDel 具有更高的链路利用率和更好的丢包份额公平性，这表明 CoDel 的设计在丢弃正确的数据包方面更有效。CoDel 的利用率非常接近尾部丢弃的利用率（除了 500 毫秒的 RTT），但延迟要小得多。CoDel 的性能指标在 30-200 毫秒 RTT 之间没有显着差异。随着 RTT 的增加，利用率略有下降，并且范围更大，因为某些流量负载难以保持较大的管道满载。500 毫秒 RTT 利用率显示出更大的变化，低端对应于单个 FTP，这些 FTP 难以保持非常大的管道满载。
图 9 比较了这些运行中 CoDel 和 RED 的源丢包份额的 Jain 公平性指数。CoDel 在此指标方面始终优于 RED。这似乎部分是因为对原始 RED 的更改使得丢包的随机分布性降低，而 CoDel 从丢包间隔和数据包到达的独立性中获得随机性。
消费者边缘
此场景大致模拟了两个（对称）带宽的消费者边缘：512 KB 和 1.5 MB。负载包括双向 64 Kbps CBR（类似 VoIP）、无限 FTP 作为下载、每秒两个连接的 Web 浏览以及小型 FTP 的上传——1 MB，在两者之间有短暂的空闲期（5 到 15 秒，均匀分布）。表 1 列出了结果，“C”表示 CoDel，“T”表示尾部丢弃，并且每个链路方向分别显示。尽管 CoDel 的数据包丢包率永远不会高于尾部丢弃，但它保持了小得多的队列并传输了相似数量的数据，这为驯服缓冲区膨胀提供了鼓励。
此处介绍的实验主要由“前向”流量组成，其中所有数据流量都朝分析方向流动。反向流量存在众所周知的 ack 压缩或数据摆动问题，这些问题往往会推高延迟并降低利用率。存在已知的缓解措施来改善 ack 和数据包的混合，这些措施将在家庭路由器实现中执行。即使是未经缓解的模拟实验也显示出可接受的性能。
AQM 不能替代差异化排队，以提供需要低延迟和抖动的数据包的优先级。过去我们已经说过很多关于此类流量的解决方案；AQM 应应用于处理常见互联网流量的数据包队列，而延迟绑定逐跳行为应用于延迟敏感型流量。
CoDel 适用于在基于 Linux 的路由器中高效实现，这对于在边缘部署至关重要。其他 AQM 实现需要在队列上加锁，而 CoDel 不需要。状态变量的数量也很少。我们相信 CoDel 的算法可以在硅芯片中高效实现。
管理正确的队列
此时，精明的用户可能会试图通过启用 CeroWrt 的边缘路由器来部署 CoDel，以消除缓冲区膨胀。不幸的是，大型缓冲区并非总是位于可以管理的地方，而是可能无处不在且隐藏。6,7 示例包括连接到有线调制解调器的消费者边缘路由器和具有环形缓冲区的无线接入点。许多用户通过电缆调制解调器访问互联网，上行链路速度各不相同：2 Mbps 是典型值。家庭网络或家用计算机通过以太网电缆连接到 100 Mbps-1 Gbps 范围内的电缆调制解调器（图 10）。调制解调器的缓冲区位于快到慢的转换处，队列将在那里建立：在用户控制范围之外的密封设备内部。路由器上的任何 DiffServ（区分服务）排队和缓冲区管理都可能被电缆调制解调器中的满队列击败。已提出三种方法：（1）将以太网链路限制为上行链路速率；（2）将缓冲区管理和 DiffServ 队列放在电缆调制解调器中，并为 DiffServ 队列提供配置接口；（3）在调制解调器和上游路由器之间实施以太网流量控制。
选项 1 的优点是用户无需更改电缆调制解调器即可实施，缺点是它必须将速率限制为预期的上行链路速率。如果速率下降，则队列仍将在电缆调制解调器中建立，并且任何额外的短期带宽都无法利用。选项 2 将缓冲区管理直接放在瓶颈链路上，但要求供应商对调制解调器架构进行（可能重大的）更改并允许配置。选项 3 也要求供应商进行更改，但使用以太网流量控制来仅允许调制解调器缓冲区中良好传输利用率所需的数据包数量，同时将队列推送到路由器中，在那里可以对其进行管理，并且可以更轻松地部署新算法。选项 2 或 3 更可取，但需要电缆调制解调器供应商和/或电缆数据网络服务提供商将此作为调制解调器要求的一部分。
现代 AQM 只是解决缓冲区膨胀问题的一个环节。串联队列在数据包通信中很常见，瓶颈队列通常对用户和许多网络工程师不可见。一个完整的解决方案必须包括提高意识，以便相关的供应商既被授权，又被激励去销售具有缓冲区管理功能的设备。
下一步
开源项目 CeroWrt3 正在使用 OpenWrt 探索缓冲区膨胀的解决方案。CoDel 的实现正在进行中，之后可以研究真实世界的数据。我们计划提供我们的 ns-2 模拟代码以及一些进一步的结果。19
参考文献
1. Braden, R., et al. 1998. 互联网中队列管理和拥塞避免的建议。RFC 2309。
2. 缓冲区膨胀项目； http://www.bufferbloat.net。
3. CeroWrt 项目； http://www.bufferbloat.net/projects/cerowrt。
4. Dischinger, M., et. al. 2007. 住宅宽带网络的特征。在互联网测量会议论文集，圣地亚哥，加利福尼亚州。
5. Floyd, S., Jacobson, V. 1993. 用于拥塞避免的随机早期检测网关。IEEE/ 网络事务。
6. Gettys, J. 2011. 缓冲区膨胀：互联网中的暗缓冲区。Backspace 专栏，IEEE 互联网 计算 15(3):95-96。
7. J. Gettys 和 K. Nichols. 2011. 缓冲区膨胀：互联网中的暗缓冲区。 通讯 9(11):57-65。
8. Jacobson, V. 1988. 拥塞避免和控制。SIGCOMM '88 论文集，斯坦福，加利福尼亚州。
9. Jacobson, V. 1989. 在性能工作组会议记录中报告。可可海滩互联网工程任务组会议论文集，雷斯顿，弗吉尼亚州。国家研究倡议公司。
10. Jacobson, V. 1998. 关于使用 RED 进行队列管理和拥塞避免的注释。在 NANOG 13（北美网络运营商组）上发表的演讲； ftp://ftp.ee.lbl.gov/talks/vj-nanog-red.pdf。
11. Jacobson, V. 2006. 关于队列的咆哮。在麻省理工学院林肯实验室，列克星敦，马萨诸塞州发表的演讲； http://www.pollere.net/Pdfdocs/QrantJul06.pdf。
12. Jacobson, V., Nichols, K., Poduri, K. 1999. 不同光线下的 RED； http://www.cnaf.infn.it/~ferrari/papers/ispn/red_light_9_30.pdf。
13. Kreibich, C., et. al. 2010. Netalyzr：照亮边缘网络。在互联网测量会议论文集，墨尔本，澳大利亚。
14. Li, T., Leith, D. 2008. 802.11e WLAN 中 TCP 流的自适应缓冲区大小调整。在中国通信和网络会议论文集。
15. Mankin, A. 1990. 随机丢弃拥塞控制。在SIGCOMM '90 论文集。
16. Mathis, M., Semke, J., Mahdavi, J. 1997. TCP 拥塞避免算法的宏观行为。 SIGCOMM 计算机通信评论 27(3)。
17. Nagle, J. 1984. IP/TCP 互联网中的拥塞控制。RFC 896; http://www.ietf.org/rfc/rfc896.txt。
18. 网络模拟器 - ns-2； http://nsnam.isi.edu/nsnam/index.php/User_Information。
19. http://www.pollere.net/CoDel.html。
20. Vu-Brugier, G., et. al. 2007. 对最近提出的缓冲区大小调整策略的批判。 SIGCOMM 计算机通信评论 37(1)。
21. Weigle, M. C. 2002. 在 ns-2 中使用 PackMime-HTTP 生成 Web 流量； http://www.cs.odu.edu/~mweigle/research/packmime。
22. Feng, W., et. al. 2002. BLUE 主动队列管理算法。在IEEE/ 网络事务，10(4): 513-528。
喜欢它，讨厌它？请告诉我们
KATHLEEN NICHOLS 是 Pollere Inc. 的创始人兼首席技术官，Pollere Inc. 是一家在政府和商业网络领域工作的咨询公司。她在网络领域拥有 30 年的经验，包括在多家硅谷公司工作，并曾是 Packet Design 的联合创始人。
VAN JACOBSON 是 PARC 的研究员，他在那里领导其以内容为中心的网络研究项目。他曾在劳伦斯伯克利国家实验室、思科系统公司工作，并且是 Packet Design 的联合创始人。
© 2012 1542-7730/12/0400 $10.00
最初发表于 Queue vol. 10, no. 5—
在 数字图书馆 中评论这篇文章
更多相关文章
David Collier-Brown - 你不了解带宽
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽，问题就是延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果您是一家 ISP，并且所有客户都讨厌您，请振作起来。这现在是一个可以解决的问题，这要归功于一群执着的人，他们追查到这个问题，解决了它，然后在家庭路由器中验证了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和物联网设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职加速流程，供应链中的信任关系必须在设备中正式化，以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径追踪的分布式延迟分析
低延迟是许多 Google 应用程序（如搜索）的重要功能，延迟分析工具在维持大规模低延迟方面起着关键作用。对于包含功能和数据不断演变的服务的复杂分布式系统，将总体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实的分布式系统中，现有的工具（如 RPC 遥测、CPU 分析和分布式追踪）对于理解整个系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。
David Crawshaw - 一切 VPN 焕然一新
VPN（虚拟专用网络）已有 24 年历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也随之发展。VPN 在 2000 年代的互联网中经历了尴尬的青春期，与其他广泛流行的抽象概念互动不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。