摘要

本备忘录向互联网社区提出了有关改进和保持互联网性能的措施的建议。它强烈建议在网络设备中测试、标准化和广泛部署主动队列管理（AQM），以提高当今互联网的性能。它还敦促各方共同努力，研究、测量和最终部署AQM机制，以保护互联网免受对拥塞通知响应不够的流量的影响。

基于15年的经验和新研究，本文件取代RFC 2309的建议。

1. 介绍

Internet协议体系结构基于使用Internet协议的无连接端到端分组服务，无论是IPv4[RFC791]还是IPv6[RFC2460]。无连接设计的优点——灵活性和健壮性——已经得到了充分的证明。然而，这些优点并非没有成本：需要仔细设计，以便在重载下提供良好的服务。事实上，缺乏对数据包转发动态的关注可能会导致严重的服务降级或“互联网崩溃”。这种现象最早出现在20世纪80年代中期互联网的早期发展阶段[RFC896][RFC970]；它在技术上被称为“拥塞崩溃”，是RFC2309的一个关键焦点。

尽管大规模的拥塞崩溃在互联网上并不常见，但局部拥塞崩溃的出现绝非罕见。因此，继续避免拥塞崩溃非常重要。

自1998年RFC2309编写以来，互联网已被用于各种通信。在当前的互联网中，低延迟对于许多交互式和基于事务的应用程序来说非常重要。RFC 2309倡导的用于对抗拥塞崩溃的同一类型技术也能有效地限制延迟，以减少应用程序所经历的交互延迟（延迟）[15]。高或不可预测的延迟可能会影响端到端协议（包括使用TCP的拥塞控制算法）使用的控制环路的性能。现在，人们还关注使用相同的技术减少网络延迟。

本文档中描述的机制可以在包括路由器、交换机和其他网络中间件的端点之间的路径上的网络设备中实现。这些方法还可以在连接到网络的端点设备内的网络栈中实现。

1.1. 拥塞崩溃

互联网崩溃的最初修复方案是由Van Jacobsen提供的。从1986年开始，Jacobsen开发了拥塞避免机制[Jacobson88]，现在实现TCP[RFC793][RFC1122]需要这些机制。（[RFC7414]提供了帮助识别TCP相关文档的路线图。）这些机制在Internet主机中运行，导致TCP连接在拥塞期间“back off”。我们说TCP流“响应”拥塞信号（如丢弃或标记为显式拥塞通知[RFC3168]）。主要是这些TCP拥塞避免算法，防止当今互联网的拥塞崩溃。其他非TCP传输也指定了类似的算法。

然而，这并不是故事的结局。自1988年以来，人们对互联网动态进行了大量的研究，互联网也得到了发展。显然，拥塞避免机制[RFC5681]虽然必要且强大，但不足以在所有情况下提供良好的服务。基本上，从网络边缘可以完成的控制量是有限的。网络设备中需要一些机制来补充端点拥塞避免机制。这些机制可以在网络设备中实现。

1.2. 用于管理延迟的AQM

为了提高Internet应用程序和协议的响应速度，Internet延迟已成为人们关注的焦点。延迟的一个主要来源是网络设备中队列的累积。每当设备入口的数据到达率超过当前出口率时，就会发生排队。这种排队在分组交换网络中是正常的，并且通常是吸收传输中的突发和执行业务统计复用所必需的，但是过度排队可能导致不必要的延迟，从而降低某些Internet应用程序的性能。

RFC2309引入了“主动队列管理”（AQM）的概念，这是一类通过向TCP等常见拥塞控制传输发送信号来管理网络缓冲区中队列大小的技术。RFC2309还描述了一种特定的AQM算法，即随机早期检测（RED），并建议在路由器中广泛实现和默认使用该算法。

如果有一组合适的参数，RED是一种有效的算法。然而，动态预测这组参数是困难的。因此，RED在默认情况下未启用，目前在Internet上的使用受到限制。自RFC2309发布以来，已经开发了其他AQM算法，其中一些算法在适用范围内是自动调整的。因此，尽管本备忘录继续建议部署AQM，但不再建议默认使用RED或任何其他特定算法。相反，它提供了关于IETF过程的建议，以选择适当的算法，特别是推荐的算法能够自动进行常见部署场景所需的任何调优。

在网络中部署AQM可以显著减少互联网路径上的延迟，并且自RFC 2309编写以来，这已成为在互联网中使用AQM的一个关键动机。在AQM的上下文中，区分两类相关的算法很有用：“队列管理”和“调度”算法。大致来说，队列管理算法通过在必要或适当时标记或丢弃数据包来管理数据包队列的长度，而调度算法则确定下一个要发送的数据包，主要用于管理流之间的带宽分配。虽然这两种机制密切相关，但它们解决不同的性能问题，并在不同的时间尺度上运行。两者都可以组合使用。

1.3. 概述

本备忘录中的讨论适用于“尽力而为”流量，也就是说，由接受在途流量偶尔丢失、重复或重新排序的应用程序生成的流量。它还适用于其他流量，例如可以调整其发送速率以减少丢包和延迟的实时流量。对于弹性流量，当自适应发生在单个往返时间（RTT）或少量RTT的时间尺度上时，最有效[RFC1633]。

突出了两个性能问题：

第一个问题是需要一种高级形式的队列管理，我们称之为“主动队列管理”，即AQM。第2章总结了主动队列管理可以带来的好处。文献中描述了许多AQM程序，具有不同的特点。本文没有特别推荐其中任何一项，但它确实提出了一些建议，这些建议在理想情况下会影响在给定实施中使用的程序的选择。

本备忘录第4章讨论的第二个问题是，由于流量对拥塞指示无响应或响应不足，未来互联网拥塞崩溃的可能性。不幸的是，虽然调度可以减轻与无响应流共享网络队列的一些副作用，但目前还没有一致的解决方案来控制这种攻击性流造成的拥塞。拥塞暴露（ConEx）[RFC6789]等方法提供了一个框架[ConEx]，可以更新网络设备以减轻这些影响。在提供任何解决方案之前，需要进行大量的研究和工程设计。必须积极开展减轻无响应流量影响的工作，以确保互联网的可接受性能和未来稳定性。

第4章总结了备忘录，并就AQM的使用向互联网社区提出了一系列建议，以及定义AQM算法的建议。

1.4. RFC 2309建议的变更

本备忘录取代了[RFC2309]中的建议，该建议源于互联网研究任务组（IRTF）端到端研究小组过去对端到端性能、互联网拥塞和RED的讨论。它源于RED和其他算法的经验，以及IETF[AQM-WG]中的AQM讨论。

鉴于RFC 2309根据队列长度描述了AQM，本备忘录使用AQM来指代允许网络设备控制队列长度和数据包在队列中花费的平均时间的任何方法。

该备忘录还明确废除了将随机早期检测（RED）用作互联网默认AQM机制的建议。取而代之的是一套详细的建议，用于选择适当的AQM算法。与RFC 2309一样，本备忘录说明了继续研究的必要性。本备忘录还阐明了本备忘录发布时所需的研究，并列举了适当的例子。

2. 主动队列管理的必要性

主动队列管理（AQM）是一种允许网络设备控制队列长度或数据包在队列中花费的平均时间的方法。虽然AQM可以应用于一系列部署环境，但本文中的建议适用于通用Internet。预计原则和指南也适用于广泛的环境，但可能需要针对特定类型的链路或网络进行调整（例如，适应数据中心的流量模式、无线基础设施的挑战或卫星互联网链路上遇到的更高延迟）。本节的其余部分确定了AQM的需求以及部署AQM方法的优势。

在网络设备中管理队列长度的传统技术是为每个队列设置最大长度（以数据包为单位），接受队列的数据包直到达到最大长度，然后拒绝（丢弃）后续传入的数据包，直到队列中的数据包被传输，队列变短。这种技术称为“尾部丢弃”，因为最近到达的数据包（即队列尾部的数据包）在队列已满时丢弃。这种方法多年来一直在互联网上使用，但它有四个重要的缺点：

1. 队列满

“尾部丢弃”原则允许队列长时间保持满（或几乎满）状态，因为尾部丢弃仅在队列满时发出拥塞信号（通过丢包）。减少稳态队列大小很重要，这可能是队列管理最重要的目标。

原始的假设可能是，在延迟和吞吐量之间存在一个简单的权衡，将队列保持在“非满”状态的建议本质上转化为端到端低延迟比高吞吐量更重要的建议。然而，这并没有考虑到数据包突发在互联网性能中所起的关键作用。例如，尽管TCP限制流的拥塞窗口，但数据包通常以突发方式到达网络设备[Leland94]。如果队列已满或几乎满，到达的突发将导致多个数据包从同一流中丢弃。突发性丢包可能导致流的全局同步减小流，然后是链路利用率的持续降低，从而降低总体吞吐量[Flo94][Zha90]。

网络中缓冲的目标是吸收数据突发，并在（希望）随后的突发沉默期间传输它们。这对于允许突发数据的传输至关重要。通常较小的队列是网络设备中的首选队列，具有足够的队列容量来吸收突发。与直觉相反的结果是，保持通常较小的队列可以带来更高的吞吐量和更低的端到端延迟。总之，队列限制不应反映我们希望在网络中保持的稳态队列；相反，它们应该反映网络设备需要吸收的突发的大小。

2. 锁定（Lock-Out））

在某些情况下，尾部丢弃允许单个连接或几个流独占队列空间，从而使其他连接处于饥饿状态，从而阻止它们在队列中获得空间[Flo92]。

3. 减轻数据包突发的影响

大数据包突发可能会延迟其他数据包，从而中断控制循环（例如，TCP ACK时钟对数据流的调速），并降低共享一个共同瓶颈的数据流的性能。

4. 控制回路同步

与其他端到端机制一样，拥塞控制在主机之间引入了一个控制循环。因此，共享一个共同网络瓶颈的会话会同步，从而引入周期性中断（例如抖动/丢包）。“锁定”通常也是同步或其他时间效应的结果。

除了尾部丢包，当队列满时可以应用的两种替代队列管理规则是“满时随机丢包”或“满时头部丢包”。当新数据包到达“完全随机丢弃”原则的满队列时，网络设备从队列中丢弃随机选择的数据包（这可能是一个昂贵的操作，因为它需要在队列中进行O（N）遍历）。当一个新的数据包到达“满时头部丢弃”原则到的满队列时，网络设备将队列前面的数据包丢弃[Lakshman96]。这两种方法都解决了锁定问题，但都不能解决上述的满队列问题。

通常，我们知道如何解决“响应”流（即响应拥塞通知而减小的流）的满队列问题。在当前的互联网上，丢弃的数据包提供了一种关键的机制，向主机发出拥塞通知。满队列问题的解决方案是，网络设备在队列变满之前丢弃或ECN标记数据包，以便主机能够在缓冲区溢出之前响应拥塞。我们称这种主动的方法为AQM。通过在缓冲区溢出之前丢弃或ECN标记数据包，AQM允许网络设备控制何时丢弃数据包以及丢弃多少数据包。

总之，主动队列管理机制可以为响应流提供以下优势。

1. 减少网络设备中丢弃的数据包数量

数据包突发是分组网络不可避免的一个方面[Willinger95]。如果网络设备中的所有队列空间已经提交给“稳态”流量，或者如果缓冲空间不足，则网络设备将无法缓冲突发。通过保持平均队列大小为较小值，AQM将提供更大的容量来吸收自然发生的突发，而不会丢弃数据包。

此外，如果没有AQM，当队列溢出时会丢弃更多的数据包。这是不可取的，原因有几个。首先，对于共享队列和“尾部丢弃”规则，这可能导致不必要的流全局同步，从而降低平均链路利用率，从而降低网络吞吐量。其次，不必要的数据包丢弃表示丢弃点之前路径上的网络容量浪费。

虽然AQM可以管理队列长度并减少端到端延迟，即使在没有端到端拥塞控制的情况下，但它只能在端到端拥塞控制仍然占主导地位的环境中减少丢包。

2. 提供低延迟的交互式服务

通过保持较短的平均队列，AQM将减少流所经历的延迟。这对于交互式应用程序尤其重要，例如短web传输、POP/IMAP、DNS、终端流量（Telnet、SSH、Mosh、RDP等）、游戏或交互式音频视频会话，当端到端延迟较低时，其主观（和客观）性能更好。

3. 避免锁定行为

AQM可以通过确保传入数据包几乎总是有可用的缓冲区来防止锁定行为。出于同样的原因，AQM可以防止对低容量但高突发的流的偏见。

锁定是不可取的，因为它在流之间构成了严重的不公平。然而，我们并没有将这种好处称为“增加的公平性”，因为流之间的一般公平性需要每个流状态，而队列管理并没有提供这种状态。例如，在使用AQM的网络设备中，只有FIFO调度，两个TCP流可能会有非常不同的网络容量份额，这仅仅是因为它们具有不同的RTT[Floyd91]，并且不使用拥塞控制的流可能会比使用拥塞控制的流有更多的容量。因此，AQM可以与在多个队列之间划分网络流量的调度机制相结合（2.1）。

4. 降低控制回路同步的概率

如果网络设备在触发发送主机处拥塞避免的AQM功能中引入随机性，则可以降低网络控制环路同步的概率。

2.1. AQM与多队列

网络设备可以使用具有调度算法的每流或每类排队来对某些应用程序或业务类别进行优先级排序、限制传输速率或在公共类别内的不同业务流之间提供隔离。例如，路由器可以通过诸如各种形式的公平排队（FQ）[Dem90][Sut99]的每流调度算法来维持每流状态以实现一般公平性，包括加权公平排队（WFQ）、随机公平排队（SFQ）[McK90]、赤字循环（DRR）[Shr96][Nic12]，和/或基于类的队列调度算法，如CBQ[Floyd95]。也可以使用分层队列，例如，作为分层令牌桶（HTB）或分层公平服务曲线（HFSC）的一部分[Sto97]。这些方法还用于实现一系列服务质量（QoS）行为，这些行为旨在满足流量类别的需求（例如，使用集成或差异化服务模型）。

甚至对于使用每流或每类排队的网络设备，也需要AQM，因为调度算法本身并不控制总体队列大小或单个队列的大小。AQM机制可能需要控制总体队列大小，以确保能够在不丢弃数据包的情况下容纳到达的突发。AQM还应用于控制每个流或类的队列大小，以便它们不会经历不必要的高延迟。在多个队列之间使用AQM和调度的组合已被证明在实验使用和某些类型的操作使用中提供了良好的结果。

简而言之，调度算法和队列管理应该是互补的，而不是相互替代的。

2.2. AQM和显式拥塞标记（ECN）

AQM方法可以使用显式拥塞通知（ECN）[RFC3168]代替丢弃来标记轻度或中度拥塞下的数据包。ECN标记可允许网络设备在传输发生拥塞丢包或额外排队延迟之前的某一点发出拥塞信号[ECN-Benefit]。4.2.1描述了将ECN与AQM结合使用的一些好处。

2.3. AQM和缓冲区大小

区分交换机/路由器或其他网络设备中队列的缓冲区大小选择以及决定AQM算法如何和何时运行的阈值和其他参数非常重要。最佳缓冲区大小是操作要求的函数，通常大小足以缓冲预期的最大正常流量突发。此大小取决于到达队列的流量的数量和突发性以及流量离开队列的速率。

AQM的一个目标是最小化锁定的影响，防止一个流阻止其他流获取容量。当一个新的TCP流将数据包注入一个几乎满的队列时，这种需要可以通过一个简单的尾部丢包排队示例来说明。TCP流的拥塞控制算法[RFC5681]增加了流量，以最大化其有效窗口。这将在网络中构建一个队列，导致流和共享此队列的其他流出现延迟。一旦队列填满，就会丢失。发送初始突发的新流填充剩余队列，并使丢包概率增加。因此，可以防止新流在多个RTT期间有效地共享队列。相比之下，AQM可以最小化平均队列深度，从而降低竞争会话实质上妨碍彼此良好运行的概率。

AQM使设计人员无需限制分配给队列的缓冲区空间以获得可接受的性能，允许分配足够的缓冲以满足特定流量模式的需要。不同类型的流量和部署场景将导致不同的需求。因此，AQM算法和相关参数的选择取决于经历拥塞的方式以及实现可接受性能所需的反应。后者是以下各节的主要主题。

3. 管理攻击性的流

互联网成功的关键之一是TCP的拥塞避免机制。由于TCP在拥塞期间“back off”，因此大量TCP连接可以共享单个拥塞链路，从而在类似位置的流之间合理公平地共享链路带宽。流之间带宽的公平共享取决于所有运行兼容拥塞避免算法的流，即符合当前TCP规范的方法[RFC5681]。

在本文中，如果流的拥塞响应近似于TCP流预期的平均响应，则称为“TCP友好”。TCP友好方案的一个示例方法是TCP友好速率控制算法[RFC5348]。在本文中，该术语更一般地用于描述满足这些目标的本算法和其他算法。

网络流有多种类型。描述流的一些类有：（1）TCP友好流，（2）无响应流，即发生拥塞时不会减慢的流，以及（3）响应性强但对拥塞的响应不如TCP的流。最后两个类包含更具攻击性的流，可能对Internet性能造成重大威胁。

1. TCP友好流

TCP友好流在少量RTT内响应拥塞通知，并且在稳定状态下，它使用的容量不超过在类似条件下运行的一致TCP（丢包率、RTT、数据包大小等）。本文其余部分对此进行了说明。

2. 非响应流

非响应流不在少量RTT内的响应拥塞通知、调整其速率；它还可以使用比在类似条件下运行的一致TCP更多的容量。越来越多的应用程序的拥塞避免算法不足或不存在（即，当遇到拥塞时，流不会限制其发送速率）。

UDP [RFC768]向应用程序和上层协议（在本文的其余部分中均简称为“应用程序”）提供最小、最大努力的传输，但其本身不提供防止拥塞崩溃或建立一定程度公平性的机制[RFC5405]。

使用UDP的示例包括一些用于分组语音和视频的流应用程序，以及一些多播批量数据传输。其他流量在聚合时也可能对拥塞通知不响应。如果不采取任何措施，这种无响应流可能导致新的拥塞崩溃[RFC2914]。一些应用程序甚至可以增加其流量以响应拥塞（例如在丢包时添加前向纠错），它们可能导致拥塞崩溃。

一般来说，应用程序需要结合有效的拥塞避免机制[RFC5405]。仍然需要进行研究，以确定和开发为目前无响应的应用程序实现拥塞避免的方法。网络设备需要能够保护自己不受无响应流的影响，必须开发和部署实现这一点的机制。这种机制的部署将通过使用拥塞控制传输（例如TCP、SCTP[RFC4960]和DCCP[RFC4340]）或在应用程序[RFC5405][RFC6679]中加入它们自己的拥塞控制来激励所有应用程序做出响应。

3. 比TCP响应性差的传输流

第二个威胁来自于对拥塞做出响应的传输协议实现，但是，无论是有意还是错误的实现，有效窗口的减少程度都小于TCP流对拥塞做出响应的程度。这涵盖了（1）和（2）之间的一系列行为。如果应用程序对拥塞信号响应不够，它们可能会获得不公平的可用网络容量份额。

例如，互联网的普及导致了TCP实现数量的激增。其中一些因为实现较差可能无法正确实现TCP拥塞避免机制。其他的可能会故意使用在容量使用方面比其他TCP实现更具攻击性的拥塞避免算法；这样的供应商可以声称拥有“更快的TCP”。这种实现的逻辑结果将是一个日益激进的TCP实现的螺旋，导致回到没有有效的拥塞避免和互联网长期拥塞的地步。

另一个例子是RTP/UDP视频流，它使用自适应编解码器，但不完全响应拥塞指示或响应时间过长。

这种流量不太可能在相当于少量端到端传输延迟的时间范围内响应拥塞信号。然而，在更长的时间范围内，可能是几秒钟的持续时间，他们可以降低速度，或者在确定可用容量的情况下提高速度。

承载多个（短）TCP流的隧道式流量聚合可能比标准的批量TCP更具攻击性。应用程序（例如，主要支持HTTP 1.1和对等文件共享的web浏览器）通过打开到同一端点的多个连接来利用这一点。

最后，一些应用程序（例如，主要支持HTTP 1.1的web浏览器）为单个会话打开大量连续的短TCP流。这可能导致每个流的大部分时间都花费在指数TCP慢启动阶段，而不是TCP拥塞避免阶段。因此，产生的总流量可能比单个标准TCP流的响应性差得多。

第2类和第3类流量中更具攻击性的流量在互联网总流量中所占比例的预计增加可能对未来互联网的性能构成威胁。因此，迫切需要对目前的情况进行测量，并进一步研究管理这种流的方法。这在寻找具有可接受开销成本的方法时提出了许多困难的问题，这些方法可以识别和隔离无响应流或响应性不如TCP的流。最后，关于这些威胁可能被实现的速度或管理这些流量的算法的预期效益，目前还没有多少测量或模拟证据。

另一个需要考虑的主题是在考虑队列管理方法时“流”的适当粒度。有几个“自然”答案：1）传输（例如TCP或UDP）流（源地址/端口、目标地址/端口、协议）；2）区分服务码点；3）源/目的主机对（IP地址）；4）给定源主机或给定目标主机，或上述主机的各种组合；5）接收互联网服务的用户或站点（企业或住宅）。

在许多情况下，源/目标主机对提供了适当的粒度。然而，不同的供应商/提供者使用不同的粒度来定义流（作为彼此“区分”的方式），并且可以为网络中的不同位置选择不同的粒度。在这种情况下，粒度可能不如网络设备需要能够处理更多无响应的数据这一事实重要。

拥塞管理流的粒度至少在一定程度上是一个需要在更广泛的IETF社区中解决的政策问题。

4. 结论和建议

IRTF在编制[RFC2309]时，以及IETF在随后的讨论中，就AQM程序的实施和操作使用制定了一套具体建议。本文提供的建议总结如下：

1. 网络设备应该实现一些AQM机制来管理队列长度，减少端到端延迟，并避免互联网中的锁定现象。

2. 部署的AQM算法应支持显式拥塞通知（ECN）以及端点信号丢失拥塞。

3. AQM算法不应要求在常见用例中调整初始或配置参数。

4. AQM算法应该响应测量的拥塞，而不是应用程序配置。

5. AQM算法不应解释特定的传输协议行为。

6. 传输协议的拥塞控制算法应最大限度地利用可用容量（当有数据要发送时），而不会造成不适当的丢包或不适当的往返延迟。

7. 需要进行研究、工程和测量工作，以设计机制来处理对拥塞通知无响应或有响应但比现有TCP更具攻击性的流。

这些建议是用“应该”一词表达的。这是因为认识到可能存在本文中未设想的、建议不适用的用例。因此，在得出一个人的用例属于该类别的结论时，应该谨慎；在互联网的生命周期中，此类用例很少被观察和报告。相反，现有研究[Choi04]指出，即使是网络核心中通常深度非常稳定且行为非常稳定的高速链路，也会偶尔遇到需要缓和的问题。以下各节详细介绍了这些建议。

4.1. 运营部署应使用AQM程序

AQM过程旨在最大限度地减少由于主机行为而导致的队列填充在网络中引起的延迟和缓冲区耗尽。标记和丢包行为提供了一个信号，表明网络设备中的缓冲区正在变得不必要地满，发送方可以很好地调节其行为。

在网络中，使用调度机制（如优先级排队、类排队和公平排队）通常可以有效地帮助网络满足一系列应用的需要。网络运营商可以使用这些方法来管理通过瓶颈的流量。[RFC2474]和[RFC2475]对此进行了讨论。使用调度时，AQM应跨类或流以及每个类或流应用：

o AQM机制需要控制总队列大小，以确保能够在不丢弃数据包的情况下容纳到达的突发。

o AQM机制需要允许与其他机制（如调度）相结合，以允许实现在不同流之间提供公平性的策略。

o AQM应用于控制每个流或类的队列大小，以便它们不会经历不必要的高延迟。

4.2. 发送到传输端点的信号

网络设备可以通过多种方式向端点发出信号，表明网络正在变得拥塞并触发速率降低。信令方法包括：

o延迟在途数据段（数据包），如在队列中排队。

o 丢弃传输中的数据段（数据包）。

o 标记数据段（数据包），例如使用显式拥塞控制[RFC3168][RFC4301][RFC4774][RFC6040][RFC6679]。

增加的网络延迟被用作拥塞的隐含信号。例如，在TCP中，额外的延迟会影响ACK时钟，并导致新数据的传输速率降低。在实时传输协议（RTP）中，网络延迟会影响RTCP报告的RTT，并且延迟的增加会触发发送方调整其速率。低额外延迟背景传输（LEDBAT）[RFC6817]等方法假设延迟增加是拥塞的主要信号。适当使用基于延迟的方法和AQM的含义目前仍然是一个有待进一步研究的领域。

所有Internet主机都必须对丢包做出响应[RFC5681][RFC5405][RFC4960][RFC4340]。负载下的网络设备丢包有两种效果：保护网络，这是网络设备丢弃包的主要原因。丢包检测还使用实用但不明确的启发式方法向可靠传输（例如TCP、SCTP）提供信号，表明存在初期拥塞。然而，当网络丢弃飞在途消息时，丢失可能意味着路径中存在故障设备或媒介，或者可能意味着存在拥塞。为了保守起见，传输协议必须假设它可能是后者。使用不可靠传输（例如UDP）的应用程序需要对丢失做出类似的反应[RFC5405]。

网络设备应使用AQM算法来测量本地拥塞，并确定要标记或丢弃的数据包，以便对拥塞进行管理。

通常，在同一RTT中从同一会话丢弃多个数据包是无效的，并且会降低吞吐量。此外，同时从多个会话丢弃或标记数据包可能具有使其同步的效果，从而导致后续流量负载中的高峰和低谷增加。因此，AQM算法应随机化时间丢包，以降低只有一小部分活动流经历拥塞指示的概率。

由于丢弃而导致的丢包也会影响流的效率，并会显著影响某些应用程序类别。在可靠传输中，丢弃的数据随后必须重新传输。虽然其他应用程序/传输可以适应数据丢失的情况，但这仍然意味着可用容量的使用效率低下，并且丢弃的流量可能会影响其他流。因此，由丢失引起的拥塞信令不是完全正的；这是一种必然的罪恶。

4.2.1. AQM和ECN

Explicit Congestion Notification (ECN) [RFC4301] [RFC4774] [RFC6040] [RFC6679] is a network-layer function that allows a transport to receive network congestion information from a network device without incurring the unintended consequences of loss. ECN includes both

显式拥塞通知（ECN）[RFC4301][RFC4774][RFC6040][RFC6679]是一种网络层功能，它允许传输从网络设备接收网络拥塞信息，而不会导致意外的丢包。ECN包括在传输机制和网络设备中实现的功能；后者依赖于使用AQM来决定何时以及是否进行ECN标记。

支持ECN的传输的拥塞由网络设备在IP报头中设置Congestion Experienced（CE）码点发出信号。远程接收端点记录该码点，并使用传输协议机制将其发回发送方，从而允许发送方触发及时的拥塞控制。设置CE码点的决定需要配置有阈值的AQM算法。不支持ECN的流（默认）在拥塞情况下丢弃。

网络设备应使用AQM算法，该算法在做出拥塞响应决策时标记支持ECN的流量。网络设备需要通过标记支持ECN的流量或丢弃不支持ECN的流量来实现此方法。

ECN的安全部署要求网络设备丢弃过多的流量，即使标记为来自支持ECN的传输。这是必要的安全预防措施，因为：

1. 不符合、损坏或恶意的接收者可能会隐藏ECN标记，不会向发送者报告；

2. 不符合、损坏或恶意的发送者可能忽略报告的ECN标记，因为它可以忽略丢包而不使用ECN；

3. 出现故障或不符合要求的网络设备可能“隐藏”ECN标记（或无法正确设置网络隧道出口处的ECN码点）。

在正常操作中，这种情况应该非常罕见；但是，需要过载保护来保护流量不受ECN配置错误或恶意使用的影响（例如，拒绝服务攻击，该攻击生成对CE标记无响应的支持ECN的流量）。

当ECN被添加到方案中时，ECN支持可以定义一组与用于控制数据包丢弃的参数不同的参数。AQM算法仍应自动调整这些ECN特定参数。这些参数也应手动配置。

网络设备应使用算法丢弃过多的流量（例如，在高于CE标记阈值的某个级别），即使数据包标记为支持ECN。

4.3. AQM算法部署不应要求操作调整

已经提出了许多AQM算法。许多需要对初始网络条件进行某种形式的参数调整或设置。这会使这些算法难以在运营网络中使用。

AQM算法需要考虑“初始条件”和“操作条件”。前者包括在收集关于算法使用的任何经验之前存在的值，例如接口的配置速度、对全双工通信的支持、接口MTU以及链路的其他属性。其他属性包括通过监视队列大小、经历的排队延迟、数据包丢弃率等观察到的信息。

因此，本文规定，拟在互联网上部署的AQM算法具有以下特性：

o AQM算法部署不需要调整。算法必须提供默认行为，以便在典型网络操作条件下自动调谐到合理的性能。预计这将简化部署和操作。AQM算法可能需要初始条件，例如接口速率和MTU大小或从中导出的其他值。

o AQM算法部署可支持进一步的手动调整，以提高特定部署网络中的性能。缺少此类变量的算法是可以接受的，但如果存在此类变量，则应将其外部化（使操作员可见）。规范应确定自动调谐不可能达到可接受性能的任何情况，并就必要的参数调整提供指导。例如，可能需要将算法的预期响应配置为适应最大的预期路径RTT，因为在初始化时无法知道该值。本指南预计将使算法能够部署在具有特定特征的网络中（具有可变或更大延迟的路径、容量受到与下层机制交互影响的网络等）。

o AQM算法部署可提供日志记录和报警信号，以帮助识别使用手动或自动调整的算法是否按预期运行。（例如，这可以基于输入、输出和标记/删除率随时间变化的内部一致性检查。）这将鼓励默认部署，并允许运营商识别与其他网络功能的潜在交互。

因此，优选自校正算法。IETF推荐用于一般互联网部署的算法需要设计为不需要操作（特别是手动）配置或调整。

4.4. AQM算法应该响应测量的拥塞，而不是应用程序配置

并非所有应用程序都传输相同大小的数据包。尽管应用程序的特点可能是数据包大小的特定配置，但这不应作为AQM的基础（见4.5）。存在其他方法，例如区分服务排队、拥塞前通知（PCN）[RFC5559]，可用于区分和管理应用程序的类别。网络设备可以将AQM与这些流量分类机制相结合，并且仅在网络设备内的特定队列上执行AQM。

AQM算法不应故意试图影响性能最佳的数据包大小（即，仅基于数据包大小优先丢弃/标记）。选择要丢弃/标记的数据包的过程应观察数据包在队列中的实际或预计时间（以模拟时间的速率计算的字节）。当AQM算法决定是否丢弃（或标记）数据包时，建议不考虑特定数据包的大小[RFC7141]。

应用程序（或传输程序）通常知道它们正在使用的数据包大小，因此可以根据它们希望发送的数据以及对延迟、吞吐量或其他性能参数的预期影响来判断是否使用小数据包或大数据包。当传输或应用程序响应丢弃或标记的数据包时，速率降低的大小应与发送的数据包的大小成比例[RFC7141]。

启用AQM的系统可以实例化AQM算法的不同实例以应用于同一业务类别中。可以基于访问控制列表（ACL）、分组DSCP[RFC5559]来区分业务类别，从而能够使用ECN字段（即ECT（0）、ECT（1）或CE）[RFC3168][RFC4774]中的任何一个），该多字段（MF）分类器组合了一组协议字段的值（例如，IP地址、传输、端口）或较低层的等效码点。该建议超出了RFC 3168中的定义，允许实现可以使用AQM算法的多个实例来处理支持ECN和不支持ECN的数据包。

4.5. AQM算法不应依赖于特定的传输协议行为

在部署AQM时，网络设备需要支持一系列互联网流量，并且不应对网络支持的一组传输/应用程序所需的特性进行隐含假设。也就是说，AQM方法对于传输和应用的选择应该是不透明的。

AQM算法通常通过考虑TCP[RFC793]和有限数量的应用来评估。尽管TCP是当今互联网上的主要传输方式，但这不再代表对验证流量的充分选择。UDP[RFC768]在语音和视频服务中有着重要的用途，一些应用程序在SCTP[RFC4960]和DCCP[RFC4340]中发现了实用性。因此，AQM算法应该用TCP以外的传输来演示操作，并且需要考虑各种应用。在选择AQM算法时，需要考虑使用可能承载流量聚合的隧道封装。

AQM算法不应针对特定传输/应用所需的特性，也不应推导出隐含的假设。传输和应用程序需要及时（最迟在几个RTT内）响应AQM提供的拥塞信号（即丢弃或ECN标记）。

4.6. 与拥塞控制算法的交互作用

应用程序和传输需要对接收到的指示拥塞存在的隐式或显式信号作出反应。本节确定了在使用AQM的路径时可能影响传输协议设计的问题。

传输协议和应用程序需要及时的拥塞信号。当网络设备将数据包排入缓冲区时，检测和响应拥塞所需的时间会增加。在更高层检测尾部丢失可能很困难，这有时可能需要传输计时器或探测数据包来检测和响应此类丢失。丢失模式还可能影响及时检测，例如，当网络设备不从同一流丢弃长时间运行的数据包时，时间可能会缩短。

弹性传输拥塞控制协议的一个共同目标是，当数据包在网络中的缓冲区中排队时，允许应用程序在不引起过度延迟的情况下交付最大速率的数据。为了实现这一点，传输应尝试以低于负载/延迟曲线拐点（有时称为“曲棍球棒”曲线的弯曲）的速率运行[Jain94]。当拥塞窗口允许负载接近该弯曲时，端到端延迟开始增加——这是拥塞的结果，因为数据包可能在不重叠的时间到达。一方面，在该点以上运行的传输可能会遇到拥塞损失，也可能触发运营商活动，如[RFC6057]中所述。另一方面，当一个流在这个拐点附近运行时，它可以实现接近最大吞吐量和低延迟，对路由器拥塞的贡献最小。因此，选择适当的速率/拥塞窗口可以显著影响流所经历的丢失和延迟，并将影响共享公共网络队列的其他流。

某些应用程序可能以较低的速率发送数据，或在任何给定时间保留较少的未完成段。示例包括以某种自然速率（或一组速率）流式传输的多媒体编解码器或自然交互的应用程序（例如，一些web应用程序、基于交互服务器的游戏、基于事务的协议）。这类应用可能有不同的目标。他们可能不希望最大化吞吐量，但可能希望较低的丢包率或有界延迟。

启用AQM的网络设备的正确操作不得依赖于对拥塞信号的特定传输响应

4.7. 进一步研究的必要性

[RFC2309]的第二项建议要求进一步研究网络队列和主机应用程序之间的交互以及它们之间的信令方式。这项研究已经开展，我们作为一个社区已经学到了很多。然而，我们还没有完成。

我们了解到，拥塞、延迟和缓冲区大小的问题并没有消失，并且对许多用户来说变得越来越重要。许多自校正AQM算法被发现为部署的网络提供了显著的优势。人们对部署AQM和ECN的潜力也重新产生了兴趣。

流量模式可以依赖于网络部署场景，因此互联网研究需要考虑不同范围的应用交互的影响。这包括确保机制的组合以及流量模式的组合不会相互影响，导致流量吞吐量显著降低或延迟显著增加。

在写作的时候（2015），一个明显的例子是需要考虑在数据中心发现的多对一通信模式，称为CurAST[RUN12]，（例如，由MAP/Read应用程序产生）。这种分析不仅需要研究每种应用程序流量类型，还需要研究流量类型的组合。

研究还需要考虑扩展我们的传输会话分类，不仅包括“老鼠”和“大象”，还包括“旅鼠”。在这里，“旅鼠”是一群闪现的“老鼠”，网络无意中试图向它们发出信号，就好像它们是“大象”流一样，从而导致数据中心部署场景中的头部阻塞。

其他所需研究的例子包括：

o 新的AQM和调度算法

o 适当使用基于延迟的方法和AQM的含义

o 用于标记支持ECN的数据包的合适算法，这些数据包不需要操作配置或调优以供通用

o 与AQM一起部署ECN的经验

o 用于启用AQM（和ECN）部署和测量性能的工具

o 缓解不一致和恶意流影响的方法

o 使用新网络和传输方法对应用的影响

因此，本文件重申了RFC2309的要求：随着应用程序的开发，我们需要继续研究。

RFC7567-IETF关于主动队列管理（AQM）的建议相关推荐

NS2 队列管理机制
两种传统的包的调度策略在介绍Drop Tail之前,我们先介绍两种传统的包的调度策略-决定包的传送顺序. FIFO (First In First Out,先进先出) 是一种经典的包调度策略,它的 ...
com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: 为队列管理器提供的安全性认证无效...
com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: 为队列管理器"zm_queue_manager"提 ...
Oracle 自己主动内存管理 SGA、PGA 具体解释
ASMM自己主动共享内存管理: 自己主动依据工作量变化调整最大程度地提高内存利用率有助于消除内存不足的错误 SYS@PROD>show parameter sga NAME ...
tensorflow随笔-队列管理器QueueRunner－生产者与消费者
# -*- coding: utf-8 -*- """ Spyder EditorThis is a temporary script file. "" ...
IBM MQ - 连接远程队列管理器报AMQ4036错误
解决方法 : 首先确定好服务器连接通道是否正常,如SERVER_CHL: 修改其相关属性 : ALTER CHL('SERVER_CHL') CHLTYPE(SVRCONN) MCAUSER('m ...
队列管理器连接数设置_详解！基于Redis解决业务场景中延迟队列的应用实践,你不得不服啊...
一.业务概述我们假定设置两个队列,一个队列维护正式工单,另一个队列维护挂起工单.对于挂起操作,我们通过Redis设置key有效时间,当key失效时,客户端监听失效事件,获取工单,实现挂起工单队列的 ...
tensorflow : 队列管理 FIFOQueue amp;amp; RandomShuffleQueue
『TensorFlow』第十弹_队列&多线程_道路多坎坷目录一.基本队列: tf.FIFOQueue(2,'int32') tf.RandomShuffleQueue(capacity=1 ...
网络中常用的队列管理方法比较
队列管理属于链路IP层的拥塞控制策略,主要是在路由器中采用排队算法和数据包丢弃策略.排队算法通过决定哪些包可以传输来分配带宽,而丢弃策略通过决定哪些包被丢弃来分配缓存. 1.先进先出(FIFO,Fir ...
（三）Horizon 队列管理工具
文档地址:https://learnku.com/docs/laravel/7.x/horizon/7514 安装提示:由于 Horizon 使用了异步进程信号,所以 PHP 7.1+ 以上版本才可 ...

RFC7567-IETF关于主动队列管理（AQM）的建议

摘要