Internet Engineering Task Force (IETF) N. Kuhn, Ed.
Request for Comments: 7928 CNES, Telecom Bretagne
Category: Informational P. Natarajan, Ed.
ISSN: 2070-1721 Cisco Systems
N. Khademi, Ed.
University of Oslo
D. Ros
Simula Research Laboratory AS
July 2016
Internet Engineering Task Force (IETF) N. Kuhn, Ed.
Request for Comments: 7928 CNES, Telecom Bretagne
Category: Informational P. Natarajan, Ed.
ISSN: 2070-1721 Cisco Systems
N. Khademi, Ed.
University of Oslo
D. Ros
Simula Research Laboratory AS
July 2016
Characterization Guidelines for Active Queue Management (AQM)
主动队列管理（AQM）特性描述指南
Abstract
摘要
Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing. This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.
当今网络中未经管理的大型缓冲区已经引起了一系列性能问题。这些性能问题可以通过某种形式的主动队列管理（AQM）机制来解决，可以选择与分组调度方案（如公平队列）相结合。本文档描述了在部署之前，在开发期间的实验室测试中可以使用的AQM方案特征描述的各种标准。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7928.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7928.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Reducing the Latency and Maximizing the Goodput . . . . . 5
1.2. Goals of This Document . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 7
2. End-to-End Metrics . . . . . . . . . . . . . . . . . . . . . 7
2.1. Flow Completion Time . . . . . . . . . . . . . . . . . . 8
2.2. Flow Startup Time . . . . . . . . . . . . . . . . . . . . 8
2.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Packet Loss Synchronization . . . . . . . . . . . . . . . 9
2.5. Goodput . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Latency and Jitter . . . . . . . . . . . . . . . . . . . 11
2.7. Discussion on the Trade-Off between Latency and Goodput . 11
3. Generic Setup for Evaluations . . . . . . . . . . . . . . . . 12
3.1. Topology and Notations . . . . . . . . . . . . . . . . . 12
3.2. Buffer Size . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Congestion Controls . . . . . . . . . . . . . . . . . . . 14
4. Methodology, Metrics, AQM Comparisons, Packet Sizes,
Scheduling, and ECN . . . . . . . . . . . . . . . . . . . . . 14
4.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Comments on Metrics Measurement . . . . . . . . . . . . . 15
4.3. Comparing AQM Schemes . . . . . . . . . . . . . . . . . . 15
4.3.1. Performance Comparison . . . . . . . . . . . . . . . 15
4.3.2. Deployment Comparison . . . . . . . . . . . . . . . . 16
4.4. Packet Sizes and Congestion Notification . . . . . . . . 16
4.5. Interaction with ECN . . . . . . . . . . . . . . . . . . 17
4.6. Interaction with Scheduling . . . . . . . . . . . . . . . 17
5. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 18
5.1. TCP-Friendly Sender . . . . . . . . . . . . . . . . . . . 19
5.1.1. TCP-Friendly Sender with the Same Initial Congestion
Window . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Reducing the Latency and Maximizing the Goodput . . . . . 5
1.2. Goals of This Document . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 7
2. End-to-End Metrics . . . . . . . . . . . . . . . . . . . . . 7
2.1. Flow Completion Time . . . . . . . . . . . . . . . . . . 8
2.2. Flow Startup Time . . . . . . . . . . . . . . . . . . . . 8
2.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Packet Loss Synchronization . . . . . . . . . . . . . . . 9
2.5. Goodput . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Latency and Jitter . . . . . . . . . . . . . . . . . . . 11
2.7. Discussion on the Trade-Off between Latency and Goodput . 11
3. Generic Setup for Evaluations . . . . . . . . . . . . . . . . 12
3.1. Topology and Notations . . . . . . . . . . . . . . . . . 12
3.2. Buffer Size . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Congestion Controls . . . . . . . . . . . . . . . . . . . 14
4. Methodology, Metrics, AQM Comparisons, Packet Sizes,
Scheduling, and ECN . . . . . . . . . . . . . . . . . . . . . 14
4.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Comments on Metrics Measurement . . . . . . . . . . . . . 15
4.3. Comparing AQM Schemes . . . . . . . . . . . . . . . . . . 15
4.3.1. Performance Comparison . . . . . . . . . . . . . . . 15
4.3.2. Deployment Comparison . . . . . . . . . . . . . . . . 16
4.4. Packet Sizes and Congestion Notification . . . . . . . . 16
4.5. Interaction with ECN . . . . . . . . . . . . . . . . . . 17
4.6. Interaction with Scheduling . . . . . . . . . . . . . . . 17
5. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 18
5.1. TCP-Friendly Sender . . . . . . . . . . . . . . . . . . . 19
5.1.1. TCP-Friendly Sender with the Same Initial Congestion
Window . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2. TCP-Friendly Sender with Different Initial Congestion
Windows . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Aggressive Transport Sender . . . . . . . . . . . . . . . 19
5.3. Unresponsive Transport Sender . . . . . . . . . . . . . . 20
5.4. Less-than-Best-Effort Transport Sender . . . . . . . . . 20
6. Round-Trip Time Fairness . . . . . . . . . . . . . . . . . . 21
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 21
6.3. Metrics to Evaluate the RTT Fairness . . . . . . . . . . 22
7. Burst Absorption . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 23
8. Stability . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 24
8.2.1. Definition of the Congestion Level . . . . . . . . . 25
8.2.2. Mild Congestion . . . . . . . . . . . . . . . . . . . 25
8.2.3. Medium Congestion . . . . . . . . . . . . . . . . . . 25
8.2.4. Heavy Congestion . . . . . . . . . . . . . . . . . . 25
8.2.5. Varying the Congestion Level . . . . . . . . . . . . 26
8.2.6. Varying Available Capacity . . . . . . . . . . . . . 26
8.3. Parameter Sensitivity and Stability Analysis . . . . . . 27
9. Various Traffic Profiles . . . . . . . . . . . . . . . . . . 27
9.1. Traffic Mix . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 28
10. Example of a Multi-AQM Scenario . . . . . . . . . . . . . . . 29
10.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Details on the Evaluation Scenario . . . . . . . . . . . 29
11. Implementation Cost . . . . . . . . . . . . . . . . . . . . . 30
11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 30
11.2. Recommended Discussion . . . . . . . . . . . . . . . . . 30
12. Operator Control and Auto-Tuning . . . . . . . . . . . . . . 30
12.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 30
12.2. Recommended Discussion . . . . . . . . . . . . . . . . . 31
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Security Considerations . . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.2. TCP-Friendly Sender with Different Initial Congestion
Windows . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Aggressive Transport Sender . . . . . . . . . . . . . . . 19
5.3. Unresponsive Transport Sender . . . . . . . . . . . . . . 20
5.4. Less-than-Best-Effort Transport Sender . . . . . . . . . 20
6. Round-Trip Time Fairness . . . . . . . . . . . . . . . . . . 21
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 21
6.3. Metrics to Evaluate the RTT Fairness . . . . . . . . . . 22
7. Burst Absorption . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 23
8. Stability . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 24
8.2.1. Definition of the Congestion Level . . . . . . . . . 25
8.2.2. Mild Congestion . . . . . . . . . . . . . . . . . . . 25
8.2.3. Medium Congestion . . . . . . . . . . . . . . . . . . 25
8.2.4. Heavy Congestion . . . . . . . . . . . . . . . . . . 25
8.2.5. Varying the Congestion Level . . . . . . . . . . . . 26
8.2.6. Varying Available Capacity . . . . . . . . . . . . . 26
8.3. Parameter Sensitivity and Stability Analysis . . . . . . 27
9. Various Traffic Profiles . . . . . . . . . . . . . . . . . . 27
9.1. Traffic Mix . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 28
10. Example of a Multi-AQM Scenario . . . . . . . . . . . . . . . 29
10.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Details on the Evaluation Scenario . . . . . . . . . . . 29
11. Implementation Cost . . . . . . . . . . . . . . . . . . . . . 30
11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 30
11.2. Recommended Discussion . . . . . . . . . . . . . . . . . 30
12. Operator Control and Auto-Tuning . . . . . . . . . . . . . . 30
12.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 30
12.2. Recommended Discussion . . . . . . . . . . . . . . . . . 31
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Security Considerations . . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Active Queue Management (AQM) addresses the concerns arising from using unnecessarily large and unmanaged buffers to improve network and application performance, such as those presented in Section 1.2 of the AQM recommendations document [RFC7567]. Several AQM algorithms have been proposed in the past years, most notably Random Early Detection (RED) [FLOY1993], BLUE [FENG2002], Proportional Integral controller (PI) [HOLLO2001], and more recently, Controlled Delay (CoDel) [CODEL] and Proportional Integral controller Enhanced (PIE) [AQMPIE]. In general, these algorithms actively interact with the Transmission Control Protocol (TCP) and any other transport protocol that deploys a congestion control scheme to manage the amount of data they keep in the network. The available buffer space in the routers and switches should be large enough to accommodate the short-term buffering requirements. AQM schemes aim at reducing buffer occupancy, and therefore the end-to-end delay. Some of these algorithms, notably RED, have also been widely implemented in some network devices. However, the potential benefits of the RED scheme have not been realized since RED is reported to be usually turned off.
主动队列管理（AQM）解决了因使用不必要的大缓冲区和非托管缓冲区来提高网络和应用程序性能而引起的问题，如AQM建议文档[RFC7567]第1.2节所述。过去几年中提出了几种AQM算法，最显著的是随机早期检测（RED）[FLOY1993]，蓝色[FENG2002]，比例积分控制器（PI）[HOLLO2001]，以及最近的受控延迟（CoDel）[CoDel]和比例积分控制器增强（PIE）[AQMPIE]。通常，这些算法主动与传输控制协议（TCP）和任何其他传输协议交互，这些协议部署了拥塞控制方案来管理它们在网络中保留的数据量。路由器和交换机中的可用缓冲空间应足够大，以满足短期缓冲要求。AQM方案旨在减少缓冲区占用，从而减少端到端延迟。其中一些算法，尤其是RED算法，也已在一些网络设备中广泛实现。然而，红色计划的潜在好处尚未实现，因为据报道红色通常会关闭。
A buffer is a physical volume of memory in which a queue or set of queues are stored. When speaking of a specific queue in this document, "buffer occupancy" refers to the amount of data (measured in bytes or packets) that are in the queue, and the "maximum buffer size" refers to the maximum buffer occupancy. In switches and routers, a global memory space is often shared between the available interfaces, and thus, the maximum buffer size for any given interface may vary over time.
缓冲区是存储一个队列或一组队列的内存物理卷。在本文档中提到特定队列时，“缓冲区占用率”指的是队列中的数据量（以字节或数据包为单位），而“最大缓冲区大小”指的是最大缓冲区占用率。在交换机和路由器中，全局内存空间通常在可用接口之间共享，因此，任何给定接口的最大缓冲区大小可能随时间而变化。
Bufferbloat [BB2011] is the consequence of deploying large, unmanaged buffers on the Internet -- the buffering has often been measured to be ten times or a hundred times larger than needed. Large buffer sizes in combination with TCP and/or unresponsive flows increases end-to-end delay. This results in poor performance for latency-sensitive applications such as real-time multimedia (e.g., voice, video, gaming, etc.). The degree to which this affects modern networking equipment, especially consumer-grade equipment, produces problems even with commonly used web services. Active queue management is thus essential to control queuing delay and decrease network latency.
Bufferbloat[BB2011]是在Internet上部署大型非托管缓冲区的结果——缓冲区通常被测量为所需缓冲区的十倍或一百倍。大缓冲区大小与TCP和/或无响应流相结合会增加端到端延迟。这导致实时多媒体（如语音、视频、游戏等）等对延迟敏感的应用程序的性能较差。这在多大程度上影响了现代网络设备，尤其是消费级设备，甚至对常用的web服务也会产生问题。因此，主动队列管理对于控制队列延迟和减少网络延迟至关重要。
The Active Queue Management and Packet Scheduling Working Group (AQM WG) was chartered to address the problems with large unmanaged buffers in the Internet. Specifically, the AQM WG is tasked with standardizing AQM schemes that not only address concerns with such buffers, but are also robust under a wide variety of operating
主动队列管理和数据包调度工作组（AQM WG）是为解决Internet中大型非托管缓冲区的问题而成立的。具体而言，AQM工作组的任务是标准化AQM方案，该方案不仅解决了此类缓冲区的问题，而且在各种操作条件下都很稳健
conditions. This document provides characterization guidelines that can be used to assess the applicability, performance, and deployability of an AQM, whether it is a candidate for standardization at IETF or not.
条件本文件提供了可用于评估AQM适用性、性能和可部署性的特征化指南，无论AQM是否为IETF标准化候选产品。
The AQM algorithm implemented in a router can be separated from the scheduling of packets sent out by the router as discussed in the AQM recommendations document [RFC7567]. The rest of this memo refers to the AQM as a dropping/marking policy as a separate feature to any interface-scheduling scheme. This document may be complemented with another one on guidelines for assessing the combination of packet scheduling and AQM. We note that such a document will inherit all the guidelines from this document, plus any additional scenarios relevant for packet scheduling such as flow-starvation evaluation or the impact of the number of hash buckets.
如AQM建议文件[RFC7567]中所述，在路由器中实现的AQM算法可与路由器发送的数据包调度分离。本备忘录的其余部分将AQM称为一种丢弃/标记策略，作为任何接口调度方案的一个单独功能。本文件可补充另一份关于分组调度和AQM组合评估指南的文件。我们注意到，这样的文档将继承本文档中的所有准则，以及与数据包调度相关的任何其他场景，如流饥饿评估或哈希桶数量的影响。
The trade-off between reducing the latency and maximizing the goodput is intrinsically linked to each AQM scheme and is key to evaluating its performance. To ensure the safety deployment of an AQM, its behavior should be assessed in a variety of scenarios. Whenever possible, solutions ought to aim at both maximizing goodput and minimizing latency.
减少延迟和最大化吞吐量之间的权衡与每个AQM方案有着内在的联系，是评估其性能的关键。为确保AQM的安全部署，应在各种场景中评估其行为。只要有可能，解决方案的目标应该是最大化goodput和最小化延迟。
This document recommends a generic list of scenarios against which an AQM proposal should be evaluated, considering both potential performance gain and safety of deployment. The guidelines help to quantify performance of AQM schemes in terms of latency reduction, goodput maximization, and the trade-off between these two. The document presents central aspects of an AQM algorithm that should be considered, whatever the context, such as burst absorption capacity, RTT fairness, or resilience to fluctuating network conditions. The guidelines also discuss methods to understand the various aspects associated with safely deploying and operating the AQM scheme. Thus, one of the key objectives behind formulating the guidelines is to help ascertain whether a specific AQM is not only better than drop-tail (i.e., without AQM and with a BDP-sized buffer), but also safe to deploy: the guidelines can be used to compare several AQM proposals with each other, but should be used to compare a proposal with drop-tail.
本文件建议对AQM提案进行评估的通用场景列表，同时考虑潜在性能增益和部署安全性。该指南有助于量化AQM方案在延迟减少、goodput最大化以及两者之间的权衡方面的性能。该文件介绍了应考虑的AQM算法的核心方面，无论在何种情况下，如突发吸收容量、RTT公平性或对波动网络条件的恢复能力。指南还讨论了理解与安全部署和运行AQM计划相关的各个方面的方法。因此，制定指南背后的一个关键目标是帮助确定特定AQM是否不仅优于drop tail（即，没有AQM且具有BDP大小的缓冲区），而且部署安全：指南可用于相互比较多个AQM提案，但应用于将提案与落尾提案进行比较。
This memo details generic characterization scenarios against which any AQM proposal should be evaluated, irrespective of whether or not an AQM is standardized by the IETF. This document recommends the relevant scenarios and metrics to be considered. This document
本备忘录详细说明了应根据其评估任何AQM提案的通用特征描述场景，无论AQM是否由IETF标准化。本文件建议要考虑的相关场景和指标。本文件
presents central aspects of an AQM algorithm that should be considered whatever the context, such as burst absorption capacity, RTT fairness, or resilience to fluctuating network conditions.
介绍了AQM算法的核心方面，无论在何种情况下都应予以考虑，例如突发吸收容量、RTT公平性或对波动网络条件的恢复能力。
These guidelines do not define and are not bound to a particular deployment scenario or evaluation toolset. Instead, the guidelines can be used to assert the potential gain of introducing an AQM for the particular environment, which is of interest to the testers. These guidelines do not cover every possible aspect of a particular algorithm. These guidelines do not present context-dependent scenarios (such as IEEE 802.11 WLANs, data centers, or rural broadband networks). To keep the guidelines generic, a number of potential router components and algorithms (such as Diffserv) are omitted.
这些准则不定义特定的部署场景或评估工具集，也不受其约束。相反，指南可以用来断言为特定环境引入AQM的潜在收益，这是测试人员感兴趣的。这些指南并不涵盖特定算法的所有可能方面。这些指南不提供上下文相关的场景（如IEEE 802.11无线局域网、数据中心或农村宽带网络）。为了保持指南的通用性，省略了一些潜在的路由器组件和算法（如Diffserv）。
The goals of this document can thus be summarized as follows:
因此，本文件的目标可概括如下：
o The present characterization guidelines provide a non-exhaustive list of scenarios to help ascertain whether an AQM is not only better than drop-tail (with a BDP-sized buffer), but also safe to deploy; the guidelines can also be used to compare several AQM proposals with each other.
o 目前的描述指南提供了一个非详尽的场景列表，以帮助确定AQM是否不仅优于drop tail（具有BDP大小的缓冲区），而且部署起来是否安全；指南还可用于相互比较多个AQM提案。
o The present characterization guidelines (1) are not bound to a particular evaluation toolset and (2) can be used for various deployment contexts; testers are free to select a toolset that is best suited for the environment in which their proposal will be deployed.
o 本描述指南（1）不受特定评估工具集的约束，（2）可用于各种部署环境；测试人员可以自由选择最适合其方案部署环境的工具集。
o The present characterization guidelines are intended to provide guidance for better selecting an AQM for a specific environment; it is not required that an AQM proposal is evaluated following these guidelines for its standardization.
o 本鉴定指南旨在为更好地为特定环境选择AQM提供指导；不要求AQM提案按照这些标准化指南进行评估。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
o Application-limited traffic: A type of traffic that does not have an unlimited amount of data to transmit.
o 应用程序限制流量：一种没有无限量数据传输的流量。
o AQM: The Active Queue Management (AQM) algorithm implemented in a router can be separated from the scheduling of packets sent by the router. The rest of this memo refers to the AQM as a dropping/ marking policy as a separate feature to any interface scheduling scheme [RFC7567].
o AQM：路由器中实现的主动队列管理（AQM）算法可以与路由器发送的数据包调度分离。本备忘录的其余部分将AQM称为一种丢弃/标记策略，作为任何接口调度方案的单独功能[RFC7567]。
o BDP: Bandwidth Delay Product.
o 带宽延迟积。
o Buffer: A physical volume of memory in which a queue or set of queues are stored.
o 缓冲区：存储一个队列或一组队列的内存物理卷。
o Buffer Occupancy: The amount of data stored in a buffer, measured in bytes or packets.
o 缓冲区占用率：缓冲区中存储的数据量，以字节或数据包为单位。
o Buffer Size: The maximum buffer occupancy, that is the maximum amount of data that may be stored in a buffer, measured in bytes or packets.
o 缓冲区大小：最大缓冲区占用率，即缓冲区中可存储的最大数据量，以字节或数据包为单位。
o Initial Window 10 (IW10): TCP initial congestion window set to 10 packets.
o 初始窗口10（IW10）：TCP初始拥塞窗口设置为10个数据包。
o Latency: One-way delay of packets across Internet paths. This definition suits transport layer definition of the latency, which should not be confused with an application-layer view of the latency.
o 延迟：数据包在Internet路径上的单向延迟。此定义适合延迟的传输层定义，不应将其和延迟的应用层视图混淆。
o Goodput: Goodput is defined as the number of bits per unit of time forwarded to the correct destination, minus any bits lost or retransmitted [RFC2647]. The goodput should be determined for each flow and not for aggregates of flows.
o Goodput：Goodput定义为转发到正确目的地的每单位时间的位数减去丢失或重新传输的任何位数[RFC2647]。应为每种流量而不是流量的集合确定输电量。
o SQRT: The square root function.
o SQRT：平方根函数。
o ROUND: The round function.
o ROUND：ROUND函数。
End-to-end delay is the result of propagation delay, serialization delay, service delay in a switch, medium-access delay, and queuing delay, summed over the network elements along the path. AQM schemes may reduce the queuing delay by providing signals to the sender on the emergence of congestion, but any impact on the goodput must be carefully considered. This section presents the metrics that could
端到端延迟是传播延迟、序列化延迟、交换机中的服务延迟、介质访问延迟和排队延迟的结果，沿路径在网络元素上求和。AQM方案可以通过在出现拥塞时向发送方提供信号来减少排队延迟，但必须仔细考虑对goodput的任何影响。本节介绍了可能的指标
be used to better quantify (1) the reduction of latency, (2) maximization of goodput, and (3) the trade-off between these two. This section provides normative requirements for metrics that can be used to assess the performance of an AQM scheme.
用于更好地量化（1）延迟的减少，（2）输出的最大化，以及（3）两者之间的权衡。本节提供了可用于评估AQM方案性能的指标的规范性要求。
Some metrics listed in this section are not suited to every type of traffic detailed in the rest of this document. It is therefore not necessary to measure all of the following metrics: the chosen metric may not be relevant to the context of the evaluation scenario (e.g., latency vs. goodput trade-off in application-limited traffic scenarios). Guidance is provided for each metric.
本节中列出的一些指标并不适用于本文档其余部分中详述的每种类型的流量。因此，无需测量以下所有指标：所选指标可能与评估场景的上下文无关（例如，在应用程序受限的流量场景中，延迟与良好延迟的权衡）。为每个指标提供指导。
The flow completion time is an important performance metric for the end-user when the flow size is finite. The definition of the flow size may be a source of contradictions, thus, this metric can consider a flow as a single file. Considering the fact that an AQM scheme may drop/mark packets, the flow completion time is directly linked to the dropping/marking policy of the AQM scheme. This metric helps to better assess the performance of an AQM depending on the flow size. The Flow Completion Time (FCT) is related to the flow size (Fs) and the goodput for the flow (G) as follows:
当流量大小有限时，流量完成时间是最终用户的一个重要性能指标。流大小的定义可能是矛盾的来源，因此，该度量可以考虑作为单个文件的流。考虑到AQM方案可能丢弃/标记分组的事实，流完成时间与AQM方案的丢弃/标记策略直接相关。此度量有助于根据流大小更好地评估AQM的性能。流量完成时间（FCT）与流量大小（Fs）和流量输出（G）有关，如下所示：
FCT [s] = Fs [byte] / ( G [bit/s] / 8 [bit/byte] )
FCT [s] = Fs [byte] / ( G [bit/s] / 8 [bit/byte] )
Where flow size is the size of the transport-layer payload in bits and goodput is the transport-layer payload transfer time (described in Section 2.5).
其中，flow size是传输层有效负载的大小（以位为单位），goodput是传输层有效负载传输时间（如第2.5节所述）。
If this metric is used to evaluate the performance of web transfers, it is suggested to rather consider the time needed to download all the objects that compose the web page, as this makes more sense in terms of user experience, rather than assessing the time needed to download each object.
如果使用此度量来评估Web传输的性能，建议考虑下载构成网页的所有对象所需的时间，因为这在用户体验方面更有意义，而不是评估下载每个对象所需的时间。
The flow startup time is the time between when the request was sent from the client and when the server starts to transmit data. The amount of packets dropped by an AQM may seriously affect the waiting period during which the data transfer has not started. This metric would specifically focus on the operations such as DNS lookups, TCP opens, and Secure Socket Layer (SSL) handshakes.
流启动时间是从客户端发送请求到服务器开始传输数据之间的时间。AQM丢弃的数据包数量可能严重影响数据传输尚未开始的等待时间。该指标将特别关注DNS查找、TCP打开和安全套接字层（SSL）握手等操作。
Packet loss can occur en route, this can impact the end-to-end performance measured at the receiver end.
数据包丢失可能发生在路由过程中，这可能会影响在接收器端测量的端到端性能。
The tester should evaluate the loss experienced at the receiver end using one of two metrics:
测试人员应使用以下两个指标之一评估接收器端经历的损失：
o The packet loss ratio: This metric is to be frequently measured during the experiment. The long-term loss ratio is of interest for steady-state scenarios only;
o 数据包丢失率：在实验过程中，经常要测量这个指标。长期损失率仅适用于稳态情况；
o The interval between consecutive losses: The time between two losses is to be measured.
o 连续损失之间的间隔：测量两次损失之间的时间。
The packet loss ratio can be assessed by simply evaluating the loss ratio as a function of the number of lost packets and the total number of packets sent. This might not be easily done in laboratory testing, for which these guidelines advise the tester:
分组丢失率可以通过简单地评估丢失率作为丢失分组数量和发送分组总数的函数来评估。这可能不容易在实验室测试中完成，这些指南建议测试人员：
o To check that for every packet, a corresponding packet was received within a reasonable time, as presented in the document that proposes a metric for one-way packet loss across Internet paths [RFC7680].
o 检查每个数据包是否在合理的时间内收到了相应的数据包，如文件中所述，该文件提出了跨互联网路径单向数据包丢失的度量[RFC7680]。
o To keep a count of all packets sent, and a count of the non-duplicate packets received, as discussed in [RFC2544], which presents a benchmarking methodology.
o 如[RFC2544]中所述，保持发送的所有数据包的计数和接收的非重复数据包的计数，这提供了一种基准测试方法。
The interval between consecutive losses, which is also called a "gap", is a metric of interest for Voice over IP (VoIP) traffic [RFC3611].
连续丢失之间的间隔，也称为“间隔”，是IP语音（VoIP）通信量的重要度量[RFC3611]。
One goal of an AQM algorithm is to help to avoid global synchronization of flows sharing a bottleneck buffer on which the AQM operates ([RFC2309] and [RFC7567]). The "degree" of packet-loss synchronization between flows should be assessed, with and without the AQM under consideration.
AQM算法的一个目标是帮助避免共享AQM操作的瓶颈缓冲区的流的全局同步（[RFC2309]和[RFC7567]）。在考虑AQM和不考虑AQM的情况下，应评估流之间丢包同步的“程度”。
Loss synchronization among flows may be quantified by several slightly different metrics that capture different aspects of the same issue [HASS2008]. However, in real-world measurements the choice of metric could be imposed by practical considerations -- e.g., whether fine-grained information on packet losses at the bottleneck is available or not. For the purpose of AQM characterization, a good candidate metric is the global synchronization ratio, measuring the
流之间的损失同步可以通过几个略有不同的度量来量化，这些度量捕获了同一问题的不同方面[HASS2008]。然而，在实际测量中，度量的选择可能受到实际考虑的影响——例如，关于瓶颈处数据包丢失的细粒度信息是否可用。为了描述AQM，一个很好的候选度量是全局同步比率，它测量
proportion of flows losing packets during a loss event. This metric can be used in real-world experiments to characterize synchronization along arbitrary Internet paths [JAY2006].
在丢失事件期间丢失数据包的流的比例。该指标可用于现实世界的实验，以表征沿任意互联网路径的同步[JAY2006]。
If an AQM scheme is evaluated using real-life network environments, it is worth pointing out that some network events, such as failed link restoration may cause synchronized losses between active flows, and thus confuse the meaning of this metric.
如果使用真实网络环境评估AQM方案，则值得指出的是，某些网络事件（如链路恢复失败）可能会导致活动流之间的同步丢失，从而混淆此度量的含义。
The goodput has been defined as the number of bits per the unit of time forwarded to the correct destination interface, minus any bits lost or retransmitted, such as proposed in Section 3.17 of [RFC2647], which describes the benchmarking terminology for firewall performances. This definition requires that the test setup needs to be qualified to assure that it is not generating losses on its own.
goodput被定义为转发到正确的目标接口的每单位时间的位数减去任何丢失或重新传输的位数，如[RFC2647]第3.17节中提出的，该节描述了防火墙性能的基准术语。该定义要求测试设置必须经过鉴定，以确保其自身不会产生损失。
Measuring the end-to-end goodput provides an appreciation of how well an AQM scheme improves transport and application performance. The measured end-to-end goodput is linked to the dropping/marking policy of the AQM scheme -- e.g., the fewer the number of packet drops, the fewer packets need retransmission, minimizing the impact of AQM on transport and application performance. Additionally, an AQM scheme may resort to Explicit Congestion Notification (ECN) marking as an initial means to control delay. Again, marking packets instead of dropping them reduces the number of packet retransmissions and increases goodput. End-to-end goodput values help to evaluate the AQM scheme's effectiveness in minimizing packet drops that impact application performance and to estimate how well the AQM scheme works with ECN.
通过测量端到端goodput，可以了解AQM方案改善传输和应用程序性能的程度。测量的端到端goodput与AQM方案的丢弃/标记策略相关联——例如，数据包丢弃的数量越少，需要重新传输的数据包就越少，从而将AQM对传输和应用程序性能的影响降至最低。此外，AQM方案可以求助于显式拥塞通知（ECN）标记作为控制延迟的初始手段。同样，标记数据包而不是丢弃数据包会减少数据包的重新传输次数，并提高吞吐量。端到端goodput值有助于评估AQM方案在最小化影响应用程序性能的丢包方面的有效性，并评估AQM方案与ECN的配合情况。
The measurement of the goodput allows the tester to evaluate to what extent an AQM is able to maintain a high bottleneck utilization. This metric should also be obtained frequently during an experiment, as the long-term goodput is relevant for steady-state scenarios only and may not necessarily reflect how the introduction of an AQM actually impacts the link utilization during a certain period of time. Fluctuations in the values obtained from these measurements may depend on other factors than the introduction of an AQM, such as link-layer losses due to external noise or corruption, fluctuating bandwidths (IEEE 802.11 WLANs), heavy congestion levels, or the transport layer's rate reduction by the congestion control mechanism.
goodput的测量允许测试人员评估AQM能够在多大程度上保持高瓶颈利用率。该指标也应在实验期间经常获得，因为长期有效输出仅与稳态场景相关，并且可能不一定反映AQM的引入在特定时间段内实际影响链路利用率的方式。从这些测量中获得的值的波动可能取决于除引入AQM之外的其他因素，例如由于外部噪声或损坏而导致的链路层损失、波动的带宽（IEEE 802.11 wlan）、严重拥塞水平或拥塞控制机制导致的传输层速率降低。
The latency, or the one-way delay metric, is discussed in [RFC7679]. There is a consensus on an adequate metric for the jitter that represents the one-way delay variations for packets from the same flow: the Packet Delay Variation (PDV) serves well in all use cases [RFC5481].
[RFC7679]中讨论了延迟或单向延迟度量。对于表示来自同一流的数据包的单向延迟变化的抖动度量，有一个共识：数据包延迟变化（PDV）在所有用例中都能很好地发挥作用[RFC5481]。
The end-to-end latency includes components other than just the queuing delay, such as the signal-processing delay, transmission delay, and processing delay. Moreover, the jitter is caused by variations in queuing and processing delay (e.g., scheduling effects). The introduction of an AQM scheme would impact end-to-end latency and jitter, and therefore these metrics should be considered in the end-to-end evaluation of performance.
端到端延迟包括除排队延迟之外的组件，例如信号处理延迟、传输延迟和处理延迟。此外，抖动是由排队和处理延迟的变化（例如，调度效应）引起的。AQM方案的引入将影响端到端延迟和抖动，因此在端到端性能评估中应考虑这些指标。
The metrics presented in this section may be considered in order to discuss and quantify the trade-off between latency and goodput.
为了讨论和量化延迟和良好输出之间的权衡，可以考虑本节中介绍的指标。
With regards to the goodput, and in addition to the long-term stationary goodput value, it is recommended to take measurements at every multiple of the minimum RTT (minRTT) between A and B. It is suggested to take measurements at least every K * minRTT (to smooth out the fluctuations), with K=10. Higher values for K can be considered whenever it is more appropriate for the presentation of the results, since the value for K may depend on the network's path characteristics. The measurement period must be disclosed for each experiment, and when results/values are compared across different AQM schemes, the comparisons should use exactly the same measurement periods. With regards to latency, it is recommended to take the samples on a per-packet basis whenever possible, depending on the features provided by the hardware and software and the impact of sampling itself on the hardware performance.
关于goodput，除了长期稳定goodput值外，建议在A和B之间的最小RTT（minRTT）的每一个倍数处进行测量。建议在K=10的情况下，至少每K*minRTT进行一次测量（以消除波动）。由于K值可能取决于网络的路径特性，因此只要更适合结果的表示，就可以考虑K值更高。必须为每个实验披露测量周期，当在不同AQM方案中比较结果/值时，比较应使用完全相同的测量周期。关于延迟，建议尽可能根据硬件和软件提供的功能以及采样本身对硬件性能的影响，对每个数据包进行采样。
From each of these sets of measurements, the cumulative density function (CDF) of the considered metrics should be computed. If the considered scenario introduces dynamically varying parameters, temporal evolution of the metrics could also be generated. For each scenario, the following graph may be generated: the x-axis shows a queuing delay (that is, the average per-packet delay in excess of minimum RTT), the y-axis the goodput. Ellipses are computed as detailed in [WINS2014]: "We take each individual [...] run [...] as one point, and then compute the 1-epsilon elliptic contour of the maximum-likelihood 2D Gaussian distribution that explains the points. [...] we plot the median per-sender throughput and queueing delay as a circle. [...] The orientation of an ellipse represents the
从每一组测量值中，应计算所考虑指标的累积密度函数（CDF）。如果所考虑的场景引入了动态变化的参数，那么也可以生成度量的时间演化。对于每个场景，可以生成以下图形：x轴显示排队延迟（即，超过最小RTT的平均每个数据包延迟），y轴显示goodput。椭圆的计算详见[WINS2014]：“我们将每个单独的[…]运行[…]作为一个点，然后计算解释这些点的最大似然2D高斯分布的1-ε椭圆轮廓。[…]我们将每个发送方吞吐量和排队延迟的中值绘制为一个圆。[…]椭圆的方向表示
covariance between the throughput and delay measured for the protocol." This graph provides part of a better understanding of (1) the delay/goodput trade-off for a given congestion control mechanism (Section 5), and (2) how the goodput and average queue delay vary as a function of the traffic load (Section 8.2).
协议测量的吞吐量和延迟之间的协方差。”该图提供了更好地理解（1）给定拥塞控制机制（第5节）的延迟/良好输出权衡，以及（2）良好输出和平均队列延迟如何随流量负载变化的部分信息（第8.2节）。
This section presents the topology that can be used for each of the following scenarios, the corresponding notations, and discusses various assumptions that have been made in the document.
本节介绍了可用于以下每个场景的拓扑、相应的符号，并讨论了文档中所做的各种假设。
+--------------+ +--------------+
|sender A_i | |receive B_i |
|--------------| |--------------|
| SEN.Flow1.1 +---------+ +-----------+ REC.Flow1.1 |
| + | | | | + |
| | | | | | | |
| + | | | | + |
| SEN.Flow1.X +-----+ | | +--------+ REC.Flow1.X |
+--------------+ | | | | +--------------+
+ +-+---+---+ +--+--+---+ +
| |Router L | |Router R | |
| |---------| |---------| |
| | AQM | | | |
| | BuffSize| | BuffSize| |
| | (Bsize) +-----+ (Bsize) | |
| +-----+--++ ++-+------+ |
+ | | | | +
+--------------+ | | | | +--------------+
|sender A_n | | | | | |receive B_n |
|--------------| | | | | |--------------|
| SEN.FlowN.1 +---------+ | | +-----------+ REC.FlowN.1 |
| + | | | | + |
| | | | | | | |
| + | | | | + |
| SEN.FlowN.Y +------------+ +-------------+ REC.FlowN.Y |
+--------------+ +--------------+
+--------------+ +--------------+
|sender A_i | |receive B_i |
|--------------| |--------------|
| SEN.Flow1.1 +---------+ +-----------+ REC.Flow1.1 |
| + | | | | + |
| | | | | | | |
| + | | | | + |
| SEN.Flow1.X +-----+ | | +--------+ REC.Flow1.X |
+--------------+ | | | | +--------------+
+ +-+---+---+ +--+--+---+ +
| |Router L | |Router R | |
| |---------| |---------| |
| | AQM | | | |
| | BuffSize| | BuffSize| |
| | (Bsize) +-----+ (Bsize) | |
| +-----+--++ ++-+------+ |
+ | | | | +
+--------------+ | | | | +--------------+
|sender A_n | | | | | |receive B_n |
|--------------| | | | | |--------------|
| SEN.FlowN.1 +---------+ | | +-----------+ REC.FlowN.1 |
| + | | | | + |
| | | | | | | |
| + | | | | + |
| SEN.FlowN.Y +------------+ +-------------+ REC.FlowN.Y |
+--------------+ +--------------+
Figure 1: Topology and Notations
图1：拓扑和符号
Figure 1 is a generic topology where:
图1是一个通用拓扑，其中：
o The traffic profile is a set of flows with similar characteristics -- RTT, congestion control scheme, transport protocol, etc.;
o 流量配置文件是一组具有类似特征的流——RTT、拥塞控制方案、传输协议等。；
o Senders with different traffic characteristics (i.e., traffic profiles) can be introduced;
o 可以引入具有不同流量特征（即流量剖面）的发送方；
o The timing of each flow could be different (i.e., when does each flow start and stop?);
o 每个流的计时可能不同（即，每个流何时开始和停止？）；
o Each traffic profile can comprise various number of flows;
o 每个流量剖面可以包括不同数量的流；
o Each link is characterized by a couple (one-way delay, capacity);
o 每个链路都有一对（单向延迟、容量）；
o Sender A_i is instantiated for each traffic profile. A corresponding receiver B_i is instantiated for receiving the flows in the profile;
o 为每个流量配置文件实例化发送方A_i。实例化相应的接收器B_i以接收简档中的流；
o Flows share a bottleneck (the link between routers L and R);
o 流共享一个瓶颈（路由器L和R之间的链路）；
o The tester should consider both scenarios of asymmetric and symmetric bottleneck links in terms of bandwidth. In the case of an asymmetric link, the capacity from senders to receivers is higher than the one from receivers to senders; the symmetric link scenario provides a basic understanding of the operation of the AQM mechanism, whereas the asymmetric link scenario evaluates an AQM mechanism in a more realistic setup;
o 测试人员应该考虑不对称和对称瓶颈链路在带宽方面的场景。在非对称链路的情况下，从发送方到接收方的容量高于从接收方到发送方的容量；对称链路场景提供了对AQM机制操作的基本理解，而非对称链路场景在更现实的设置中评估AQM机制；
o In asymmetric link scenarios, the tester should study the bidirectional traffic between A and B (downlink and uplink) with the AQM mechanism deployed in one direction only. The tester may additionally consider a scenario with the AQM mechanism being deployed in both directions. In each scenario, the tester should investigate the impact of the drop policy of the AQM on TCP ACK packets and its impact on the performance (Section 9.2).
o 在非对称链路场景中，测试人员应研究A和B（下行链路和上行链路）之间的双向通信量，其中AQM机制仅部署在一个方向上。测试人员还可以考虑在两个方向上部署AQM机制的场景。在每种情况下，测试人员应调查AQM的丢弃策略对TCP ACK数据包的影响及其对性能的影响（第9.2节）。
Although this topology may not perfectly reflect actual topologies, the simple topology is commonly used in the world of simulations and small testbeds. It can be considered as adequate to evaluate AQM proposals [TCPEVAL]. Testers ought to pay attention to the topology used to evaluate an AQM scheme when comparing it with a newly proposed AQM scheme.
尽管这种拓扑可能无法完美地反映实际拓扑，但在仿真和小型试验台中，通常使用简单拓扑。可以认为它足以评估AQM提案[TCPEVAL]。测试人员在将AQM方案与新提出的AQM方案进行比较时，应该注意用于评估AQM方案的拓扑结构。
The size of the buffers should be carefully chosen, and may be set to the bandwidth-delay product; the bandwidth being the bottleneck capacity and the delay being the largest RTT in the considered network. The size of the buffer can impact the AQM performance and is a dimensioning parameter that will be considered when comparing AQM proposals.
缓冲器的大小应仔细选择，并可设置为带宽延迟乘积；带宽是瓶颈容量，延迟是所考虑网络中最大的RTT。缓冲区的大小会影响AQM性能，是比较AQM建议时要考虑的一个尺寸参数。
If a specific buffer size is required, the tester must justify and detail the way the maximum queue size is set. Indeed, the maximum size of the buffer may affect the AQM's performance and its choice should be elaborated for a fair comparison between AQM proposals. While comparing AQM schemes, the buffer size should remain the same across the tests.
如果需要特定的缓冲区大小，测试人员必须证明并详细说明最大队列大小的设置方式。实际上，缓冲区的最大大小可能会影响AQM的性能，应详细说明其选择，以便在AQM提案之间进行公平比较。在比较AQM方案时，整个测试中的缓冲区大小应保持不变。
This document considers running three different congestion control algorithms between A and B:
本文件考虑在A和B之间运行三种不同的拥塞控制算法：
o Standard TCP congestion control: The base-line congestion control is TCP NewReno with selective acknowledgment (SACK) [RFC5681].
o 标准TCP拥塞控制：基线拥塞控制是TCP NewReno和选择性确认（SACK）[RFC5681]。
o Aggressive congestion controls: A base-line congestion control for this category is CUBIC [CUBIC].
o 主动式拥塞控制：此类别的基线拥塞控制为立方[立方]。
o Less-than-Best-Effort (LBE) congestion controls: Per [RFC6297], an LBE service "results in smaller bandwidth and/or delay impact on standard TCP than standard TCP itself, when sharing a bottleneck with it." A base-line congestion control for this category is Low Extra Delay Background Transport (LEDBAT) [RFC6817].
o 小于最大努力（LBE）拥塞控制：根据[RFC6297]，LBE服务“在与标准TCP共享瓶颈时，对标准TCP的带宽和/或延迟影响小于标准TCP本身。”此类基线拥塞控制是低额外延迟后台传输（LEDBAT）[RFC6817]。
Other transport congestion controls can OPTIONALLY be evaluated in addition. Recent transport layer protocols are not mentioned in the following sections, for the sake of simplicity.
此外，还可以选择评估其他交通拥堵控制措施。为了简单起见，以下各节中未提及最新的传输层协议。
4. Methodology, Metrics, AQM Comparisons, Packet Sizes, Scheduling, and ECN
4. 方法、指标、AQM比较、数据包大小、调度和ECN
A description of each test setup should be detailed to allow this test to be compared with other tests. This also allows others to replicate the tests if needed. This test setup should detail software and hardware versions. The tester could make its data available.
应详细说明每个测试设置，以便将此测试与其他测试进行比较。这还允许其他人在需要时复制测试。此测试设置应详细说明软件和硬件版本。测试人员可以提供其数据。
The proposals should be evaluated on real-life systems, or they may be evaluated with event-driven simulations (such as ns-2, ns-3, OMNET, etc.). The proposed scenarios are not bound to a particular evaluation toolset.
建议应在现实系统上进行评估，也可以使用事件驱动模拟（如ns-2、ns-3、OMNET等）进行评估。建议的方案不受特定评估工具集的约束。
The tester is encouraged to make the detailed test setup and the results publicly available.
鼓励测试人员公开详细的测试设置和结果。
This document presents the end-to-end metrics that ought to be used to evaluate the trade-off between latency and goodput as described in Section 2. In addition to the end-to-end metrics, the queue-level metrics (normally collected at the device operating the AQM) provide a better understanding of the AQM behavior under study and the impact of its internal parameters. Whenever it is possible (e.g., depending on the features provided by the hardware/software), these guidelines advise considering queue-level metrics, such as link utilization, queuing delay, queue size, or packet drop/mark statistics in addition to the AQM-specific parameters. However, the evaluation must be primarily based on externally observed end-to-end metrics.
本文档介绍了端到端指标，这些指标应用于评估第2节中所述的延迟和良好输出之间的权衡。除了端到端度量之外，队列级别度量（通常在操作AQM的设备上收集）还可以更好地理解所研究的AQM行为及其内部参数的影响。只要有可能（例如，取决于硬件/软件提供的功能），这些指南建议除AQM特定参数外，还考虑队列级别指标，如链路利用率、队列延迟、队列大小或数据包丢弃/标记统计。但是，评估必须主要基于外部观察的端到端指标。
These guidelines do not aim to detail the way these metrics can be measured, since that is expected to depend on the evaluation toolset.
这些指南的目的不是详细说明这些指标的衡量方式，因为这取决于评估工具集。
This document recognizes that these guidelines may be used for comparing AQM schemes.
本文件承认这些指南可用于比较AQM方案。
AQM schemes need to be compared against both performance and deployment categories. In addition, this section details how best to achieve a fair comparison of AQM schemes by avoiding certain pitfalls.
AQM方案需要与性能和部署类别进行比较。此外，本节还详细介绍了如何通过避免某些陷阱来实现AQM方案的公平比较。
AQM schemes should be compared against the generic scenarios that are summarized in Section 13. AQM schemes may be compared for specific network environments such as data centers, home networks, etc. If an AQM scheme has parameter(s) that were externally tuned for optimization or other purposes, these values must be disclosed.
应将AQM方案与第13节总结的一般方案进行比较。可以对特定网络环境（如数据中心、家庭网络等）的AQM方案进行比较。如果AQM方案具有为优化或其他目的而进行外部调整的参数，则必须披露这些值。
AQM schemes belong to different varieties such as queue-length based schemes (for example, RED) or queuing-delay based scheme (for example, CoDel, PIE). AQM schemes expose different control knobs associated with different semantics. For example, while both PIE and CoDel are queuing-delay based schemes and each expose a knob to
AQM方案属于不同的种类，例如基于队列长度的方案（例如RED）或基于队列延迟的方案（例如CoDel、PIE）。AQM方案公开了与不同语义相关的不同控制旋钮。例如，PIE和CoDel都是基于延迟的排队方案，每个方案都有一个旋钮
control the queuing delay -- PIE's "queuing delay reference" vs. CoDel's "queuing delay target", the two tuning parameters of the two schemes have different semantics, resulting in different control points. Such differences in AQM schemes can be easily overlooked while making comparisons.
控制排队延迟——PIE的“排队延迟参考”与CoDel的“排队延迟目标”，两种方案的两个调整参数具有不同的语义，导致不同的控制点。在进行比较时，AQM方案中的这种差异很容易被忽略。
This document recommends the following procedures for a fair performance comparison between the AQM schemes:
本文件建议采用以下程序对AQM方案进行公平绩效比较：
1. Similar control parameters and implications: Testers should be aware of the control parameters of the different schemes that control similar behavior. Testers should also be aware of the input value ranges and corresponding implications. For example, consider two different schemes -- (A) queue-length based AQM scheme, and (B) queuing-delay based scheme. A and B are likely to have different kinds of control inputs to control the target delay -- the target queue length in A vs. target queuing delay in B, for example. Setting parameter values such as 100 MB for A vs. 10 ms for B will have different implications depending on evaluation context. Such context-dependent implications must be considered before drawing conclusions on performance comparisons. Also, it would be preferable if an AQM proposal listed such parameters and discussed how each relates to network characteristics such as capacity, average RTT, etc.
1. 相似的控制参数和含义：测试人员应该知道控制相似行为的不同方案的控制参数。测试人员还应该知道输入值的范围和相应的含义。例如，考虑两种不同的方案——（a）基于队列长度的AQM方案，和（b）基于排队延迟的方案。A和B可能有不同类型的控制输入来控制目标延迟——例如，A中的目标队列长度与B中的目标队列延迟。设置参数值，例如A为100 MB，B为10毫秒，将根据评估上下文具有不同的含义。在就绩效比较得出结论之前，必须考虑这些上下文相关的影响。此外，如果AQM提案列出这些参数并讨论每个参数与网络特性（如容量、平均RTT等）的关系，则更可取。
2. Compare over a range of input configurations: There could be situations when the set of control parameters that affect a specific behavior have different semantics between the two AQM schemes. As mentioned above, PIE has tuning parameters to control queue delay that have different semantics from those used in CoDel. In such situations, these schemes need to be compared over a range of input configurations. For example, compare PIE vs. CoDel over the range of target delay input configurations.
2. 在一系列输入配置上进行比较：当影响特定行为的一组控制参数在两个AQM方案之间具有不同的语义时，可能会出现这种情况。如上所述，PIE具有用于控制队列延迟的调优参数，这些参数的语义与CoDel中使用的不同。在这种情况下，需要在一系列输入配置上对这些方案进行比较。例如，在目标延迟输入配置范围内比较PIE和CoDel。
AQM schemes must be compared against deployment criteria such as the parameter sensitivity (Section 8.3), auto-tuning (Section 12), or implementation cost (Section 11).
AQM方案必须与部署标准进行比较，如参数敏感性（第8.3节）、自动调整（第12节）或实施成本（第11节）。
An AQM scheme may be considering packet sizes while generating congestion signals [RFC7141]. For example, control packets such as DNS requests/responses, TCP SYNs/ACKs are small, but their loss can severely impact application performance. An AQM scheme may therefore be biased towards small packets by dropping them with lower probability compared to larger packets. However, such an AQM scheme
AQM方案可以在生成拥塞信号时考虑分组大小[RFC7141]。例如，DNS请求/响应、TCP SYNs/ACK等控制数据包很小，但它们的丢失会严重影响应用程序性能。因此，与较大的分组相比，AQM方案可能以较低的概率丢弃小分组，从而偏向于小分组。然而，这种AQM方案
is unfair to data senders generating larger packets. Data senders, malicious or otherwise, are motivated to take advantage of such an AQM scheme by transmitting smaller packets, and this could result in unsafe deployments and unhealthy transport and/or application designs.
这对生成较大数据包的数据发送方不公平。恶意或其他数据发送者通过传输较小的数据包来利用这种AQM方案，这可能导致不安全的部署和不健康的传输和/或应用程序设计。
An AQM scheme should adhere to the recommendations outlined in the Best Current Practice for dropping and marking packets [BCP41], and should not provide undue advantage to flows with smaller packets, such as discussed in Section 4.4 of the AQM recommendation document [RFC7567]. In order to evaluate if an AQM scheme is biased towards flows with smaller size packets, traffic can be generated, as defined in Section 8.2.2, where half of the flows have smaller packets (e.g., 500-byte packets) than the other half of the flow (e.g., 1500-byte packets). In this case, the metrics reported could be the same as in Section 6.3, where Category I is the set of flows with smaller packets and Category II the one with larger packets. The bidirectional scenario could also be considered (Section 9.2).
AQM方案应遵守丢弃和标记数据包的最佳现行实践[BCP41]中概述的建议，并且不应为具有较小数据包的流提供不当优势，如AQM建议文件[RFC7567]第4.4节中所述。为了评估AQM方案是否偏向于具有较小数据包的流，可以生成流量，如第8.2.2节所定义，其中一半的流具有比另一半的流（例如1500字节的数据包）更小的数据包（例如500字节的数据包）。在这种情况下，报告的指标可能与第6.3节中的指标相同，其中类别I是具有较小数据包的流集，类别II是具有较大数据包的流集。也可以考虑双向场景（第9.2节）。
ECN [RFC3168] is an alternative that allows AQM schemes to signal to receivers about network congestion that does not use packet drops. There are benefits to providing ECN support for an AQM scheme [WELZ2015].
ECN[RFC3168]是一种替代方案，它允许AQM方案向接收机发送关于不使用丢包的网络拥塞的信号。为AQM计划提供ECN支持有很多好处[WELZ2015]。
If the tested AQM scheme can support ECN, the testers must discuss and describe the support of ECN, such as discussed in the AQM recommendation document [RFC7567]. Also, the AQM's ECN support can be studied and verified by replicating tests in Section 6.2 with ECN turned ON at the TCP senders. The results can be used not only to evaluate the performance of the tested AQM with and without ECN markings, but also to quantify the interest of enabling ECN.
如果测试的AQM方案可以支持ECN，测试人员必须讨论并描述ECN的支持，如AQM建议文件[RFC7567]中所讨论的。此外，AQM的ECN支持可以通过在TCP发送方打开ECN的情况下复制第6.2节中的测试进行研究和验证。结果不仅可用于评估有无ECN标记的测试AQM的性能，还可用于量化启用ECN的兴趣。
A network device may use per-flow or per-class queuing with a scheduling algorithm to either prioritize certain applications or classes of traffic, limit the rate of transmission, or to provide isolation between different traffic flows within a common class, such as discussed in Section 2.1 of the AQM recommendation document [RFC7567].
网络设备可使用具有调度算法的每流或每类排队来对某些应用或业务类别进行优先级排序、限制传输速率或在公共类别内的不同业务流之间提供隔离，如AQM建议文件[RFC7567]第2.1节所述。
The scheduling and the AQM conjointly impact the end-to-end performance. Therefore, the AQM proposal must discuss the feasibility of adding scheduling combined with the AQM algorithm. It can be explained whether the dropping policy is applied when packets are being enqueued or dequeued.
调度和AQM共同影响端到端性能。因此，AQM方案必须结合AQM算法讨论添加调度的可行性。可以解释在分组排队或退队时是否应用丢弃策略。
These guidelines do not propose guidelines to assess the performance of scheduling algorithms. Indeed, as opposed to characterizing AQM schemes that is related to their capacity to control the queuing delay in a queue, characterizing scheduling schemes is related to the scheduling itself and its interaction with the AQM scheme. As one example, the scheduler may create sub-queues and the AQM scheme may be applied on each of the sub-queues, and/or the AQM could be applied on the whole queue. Also, schedulers might, such as FQ-CoDel [HOEI2015] or FavorQueue [ANEL2014], introduce flow prioritization. In these cases, specific scenarios should be proposed to ascertain that these scheduler schemes not only help in tackling the bufferbloat, but also are robust under a wide variety of operating conditions. This is out of the scope of this document, which focuses on dropping and/or marking AQM schemes.
这些指南没有提出评估调度算法性能的指南。事实上，与描述与其控制队列中队列延迟的能力相关的AQM方案相反，描述调度方案与调度本身及其与AQM方案的交互有关。作为一个示例，调度器可以创建子队列，并且AQM方案可以应用于每个子队列，和/或AQM可以应用于整个队列。此外，调度器可能会引入流优先级，如FQ CoDel[HOEI2015]或FavorQueue[ANEL2014]。在这些情况下，应提出具体方案，以确定这些调度器方案不仅有助于解决缓冲区膨胀问题，而且在各种各样的操作条件下都是健壮的。这超出了本文件的范围，本文件重点介绍了如何删除和/或标记AQM方案。
Network and end-devices need to be configured with a reasonable amount of buffer space to absorb transient bursts. In some situations, network providers tend to configure devices with large buffers to avoid packet drops triggered by a full buffer and to maximize the link utilization for standard loss-based TCP traffic.
网络和终端设备需要配置合理数量的缓冲空间来吸收瞬时突发。在某些情况下，网络提供商倾向于配置具有大缓冲区的设备，以避免由满缓冲区触发的数据包丢失，并最大限度地提高基于标准丢失的TCP流量的链路利用率。
AQM algorithms are often evaluated by considering the Transmission Control Protocol (TCP) [RFC793] with a limited number of applications. TCP is a widely deployed transport. It fills up available buffers until a sender transferring a bulk flow with TCP receives a signal (packet drop) that reduces the sending rate. The larger the buffer, the higher the buffer occupancy, and therefore the queuing delay. An efficient AQM scheme sends out early congestion signals to TCP to bring the queuing delay under control.
AQM算法通常通过考虑传输控制协议（TCP）[RFC793]和有限数量的应用来评估。TCP是一种广泛部署的传输协议。它会填充可用的缓冲区，直到使用TCP传输大容量流的发送方接收到降低发送速率的信号（数据包丢弃）。缓冲区越大，缓冲区占用率越高，因此排队延迟也越大。一种有效的AQM方案向TCP发送早期拥塞信号，以控制排队延迟。
Not all endpoints (or applications) using TCP use the same flavor of TCP. A variety of senders generate different classes of traffic, which may not react to congestion signals (aka non-responsive flows in Section 3 of the AQM recommendation document [RFC7567]) or may not reduce their sending rate as expected (aka Transport Flows that are less responsive than TCP, such as proposed in Section 3 of the AQM recommendation document [RFC7567], also called "aggressive flows"). In these cases, AQM schemes seek to control the queuing delay.
并非所有使用TCP的端点（或应用程序）都使用相同风格的TCP。各种发送方产生不同类别的流量，这些流量可能不会对拥塞信号做出反应（即AQM建议文件[RFC7567]第3节中的非响应流），或者可能不会如预期那样降低其发送速率（也称为响应性不如TCP的传输流，如AQM建议文件[RFC7567]第3节中提出的，也称为“主动流”）。在这些情况下，AQM方案寻求控制排队延迟。
This section provides guidelines to assess the performance of an AQM proposal for various traffic profiles -- different types of senders (with different TCP congestion control variants, unresponsive, and aggressive).
本节提供了评估不同流量配置文件（不同类型的发送方（具有不同的TCP拥塞控制变体、无响应和攻击性）的AQM方案性能的指南。
This scenario helps to evaluate how an AQM scheme reacts to a TCP-friendly transport sender. A single, long-lived, non-application-limited, TCP NewReno flow, with an Initial congestion Window (IW) set to 3 packets, transfers data between sender A and receiver B. Other TCP-friendly congestion control schemes such as TCP-Friendly Rate Control [RFC5348], etc., may also be considered.
此场景有助于评估AQM方案如何对TCP友好的传输发送方做出反应。初始拥塞窗口（IW）设置为3个数据包的单一、长寿命、非应用程序限制的TCP NewReno流在发送方A和接收方B之间传输数据。也可以考虑其他TCP友好的拥塞控制方案，如TCP友好的速率控制[RFC5348]等。
For each TCP-friendly transport considered, the graph described in Section 2.7 could be generated.
对于考虑的每个TCP友好传输，可以生成第2.7节中描述的图表。
This scenario can be used to evaluate how an AQM scheme adapts to a traffic mix consisting of TCP flows with different values of the IW.
此场景可用于评估AQM方案如何适应由具有不同IW值的TCP流组成的流量混合。
For this scenario, two types of flows must be generated between sender A and receiver B:
对于这种情况，发送方A和接收方B之间必须生成两种类型的流：
o A single, long-lived non-application-limited TCP NewReno flow;
o 一个单一的、长寿命的、不受应用程序限制的TCP NewReno流；
o A single, application-limited TCP NewReno flow, with an IW set to 3 or 10 packets. The size of the data transferred must be strictly higher than 10 packets and should be lower than 100 packets.
o 单个应用程序受限的TCP NewReno流，IW设置为3或10个数据包。传输的数据的大小必须严格大于10个数据包，并且应小于100个数据包。
The transmission of the non-application-limited flow must start first and the transmission of the application-limited flow starts after the non-application-limited flow has reached steady state. The steady state can be assumed when the goodput is stable.
必须首先开始传输非应用限制流，并且在非应用限制流达到稳定状态后开始传输应用限制流。当goodput稳定时，可以假设稳定状态。
For each of these scenarios, the graph described in Section 2.7 could be generated for each class of traffic (application-limited and non-application-limited). The completion time of the application-limited TCP flow could be measured.
对于这些场景中的每一种，第2.7节中描述的图表可以针对每一类流量（应用限制和非应用限制）生成。可以测量受应用程序限制的TCP流的完成时间。
This scenario helps testers to evaluate how an AQM scheme reacts to a transport sender that is more aggressive than a single TCP-friendly sender. We define 'aggressiveness' as a higher-than-standard increase factor upon a successful transmission and/or a lower-than-standard decrease factor upon a unsuccessful transmission (e.g., in case of congestion controls with the Additive Increase Multiplicative Decrease (AIMD) principle, a larger AI and/or MD factors). A single
此场景帮助测试人员评估AQM方案如何对比单个TCP友好发送方更具攻击性的传输发送方做出反应。我们将“积极性”定义为成功传输时高于标准的增加系数和/或不成功传输时低于标准的减少系数（例如，在采用加法增加-乘法减少（AIMD）原则的拥塞控制情况下，更大的AI和/或MD系数）。单人间
long-lived, non-application-limited, CUBIC flow transfers data between sender A and receiver B. Other aggressive congestion control schemes may also be considered.
在发送方A和接收方B之间传输数据的是长寿命、不受应用限制的立方流。也可以考虑其他积极的拥塞控制方案。
For each flavor of aggressive transports, the graph described in Section 2.7 could be generated.
对于每种风味的攻击性运输，可以生成第2.7节中描述的图表。
This scenario helps testers evaluate how an AQM scheme reacts to a transport sender that is less responsive than TCP. Note that faulty transport implementations on an end host and/or faulty network elements en route that "hide" congestion signals in packet headers may also lead to a similar situation, such that the AQM scheme needs to adapt to unresponsive traffic (see Section 3 of the AQM recommendation document [RFC7567]). To this end, these guidelines propose the two following scenarios:
此场景帮助测试人员评估AQM方案如何对响应性不如TCP的传输发送方作出反应。请注意，终端主机上的错误传输实现和/或路由中“隐藏”分组报头中拥塞信号的错误网元也可能导致类似情况，因此AQM方案需要适应无响应流量（请参阅AQM建议文件[RFC7567]第3节）。为此，这些指南提出了以下两种情况：
o The first scenario can be used to evaluate queue build up. It considers unresponsive flow(s) whose sending rate is greater than the bottleneck link capacity between routers L and R. This scenario consists of a long-lived non-application-limited UDP flow that transmits data between sender A and receiver B. The graph described in Section 2.7 could be generated.
o 第一个场景可用于评估队列构建。它考虑发送速率大于路由器L和R之间的瓶颈链路容量的无响应流。该场景包括在发送方a和接收方B之间传输数据的长期非应用程序限制UDP流。可以生成第2.7节中描述的图。
o The second scenario can be used to evaluate if the AQM scheme is able to keep the responsive fraction under control. This scenario considers a mixture of TCP-friendly and unresponsive traffic. It consists of a long-lived UDP flow from unresponsive application and a single long-lived, non-application-limited (unlimited data available to the transport sender from the application layer), TCP New Reno flow that transmit data between sender A and receiver B. As opposed to the first scenario, the rate of the UDP traffic should not be greater than the bottleneck capacity, and should be higher than half of the bottleneck capacity. For each type of traffic, the graph described in Section 2.7 could be generated.
o 第二种情况可用于评估AQM方案是否能够控制响应分数。此场景考虑TCP友好和无响应流量的混合。它由来自无响应应用程序的长寿命UDP流和单个长寿命、非应用程序限制（传输发送方可从应用层获得无限数据）、在发送方a和接收方B之间传输数据的TCP New Reno流组成。与第一种情况相反，UDP流量的速率不应大于瓶颈容量，且应高于瓶颈容量的一半。对于每种类型的交通，可以生成第2.7节中描述的图表。
This scenario helps to evaluate how an AQM scheme reacts to LBE congestion control that "results in smaller bandwidth and/or delay impact on standard TCP than standard TCP itself, when sharing a bottleneck with it" [RFC6297]. There are potential fateful interactions when AQM and LBE techniques are combined [GONG2014]; this scenario helps to evaluate whether the coexistence of the proposed AQM and LBE techniques may be possible.
此场景有助于评估AQM方案如何对LBE拥塞控制作出反应，LBE拥塞控制“在与标准TCP共享瓶颈时，对标准TCP的带宽和/或延迟影响小于标准TCP本身”[RFC6297]。当AQM和LBE技术相结合时，存在潜在的决定性相互作用[2014]；该场景有助于评估提议的AQM和LBE技术是否可能共存。
A single long-lived non-application-limited TCP NewReno flow transfers data between sender A and receiver B. Other TCP-friendly congestion control schemes may also be considered. Single long-lived non-application-limited LEDBAT [RFC6817] flows transfer data between sender A and receiver B. We recommend setting the target delay and gain values of LEDBAT to 5 ms and 10, respectively [TRAN2014]. Other LBE congestion control schemes may also be considered and are listed in the IETF survey of LBE protocols [RFC6297].
单个长寿命的非应用程序限制的TCP NewReno流在发送方A和接收方B之间传输数据。也可以考虑其他TCP友好的拥塞控制方案。单个长寿命非应用限制LEDBAT[RFC6817]在发送方A和接收方B之间传输数据。我们建议将LEDBAT的目标延迟和增益值分别设置为5 ms和10[TRAN2014]。还可以考虑其他LBE拥塞控制方案，并在IETF LBE协议调查[RFC6297]中列出。
For each of the TCP-friendly and LBE transports, the graph described in Section 2.7 could be generated.
对于每个TCP友好型和LBE传输，可以生成第2.7节中描述的图形。
An AQM scheme's congestion signals (via drops or ECN marks) must reach the transport sender so that a responsive sender can initiate its congestion control mechanism and adjust the sending rate. This procedure is thus dependent on the end-to-end path RTT. When the RTT varies, the onset of congestion control is impacted, and in turn impacts the ability of an AQM scheme to control the queue. It is therefore important to assess the AQM schemes for a set of RTTs between A and B (e.g., from 5 to 200 ms).
AQM方案的拥塞信号（通过DROP或ECN标记）必须到达传输发送方，以便响应发送方可以启动其拥塞控制机制并调整发送速率。因此，此过程取决于端到端路径RTT。当RTT变化时，拥塞控制的开始受到影响，进而影响AQM方案控制队列的能力。因此，评估a和B之间的一组RTT（例如，从5到200 ms）的AQM方案非常重要。
The asymmetry in terms of difference in intrinsic RTT between various paths sharing the same bottleneck should be considered, so that the fairness between the flows can be discussed. In this scenario, a flow traversing on a shorter RTT path may react faster to congestion and recover faster from it compared to another flow on a longer RTT path. The introduction of AQM schemes may potentially improve the RTT fairness.
应考虑共享同一瓶颈的不同路径之间内在RTT差异的不对称性，以便讨论流之间的公平性。在这种情况下，与较长RTT路径上的另一个流相比，在较短RTT路径上的流可能对拥塞做出更快的反应，并从中更快地恢复。AQM方案的引入可能会提高RTT的公平性。
Introducing an AQM scheme may cause unfairness between the flows, even if the RTTs are identical. This potential unfairness should be investigated as well.
引入AQM方案可能导致流之间的不公平，即使rtt是相同的。这种潜在的不公平现象也应该调查。
The recommended topology is detailed in Figure 1.
推荐的拓扑结构如图1所示。
To evaluate the RTT fairness, for each run, two flows are divided into two categories. Category I whose RTT between sender A and receiver B should be 100 ms. Category II, in which the RTT between sender A and receiver B should be in the range [5 ms, 560 ms] inclusive. The maximum value for the RTT represents the RTT of a satellite link [RFC2488].
为了评估RTT公平性，对于每次运行，将两个流分为两类。第一类，发送方A和接收方B之间的RTT应为100毫秒。第二类，发送方A和接收方B之间的RTT应在[5毫秒，560毫秒]范围内。RTT的最大值表示卫星链路的RTT[RFC2488]。
A set of evaluated flows must use the same congestion control algorithm: all the generated flows could be single long-lived non-application-limited TCP NewReno flows.
一组经过评估的流必须使用相同的拥塞控制算法：所有生成的流都可以是单个长寿命的非应用程序限制的TCP NewReno流。
The outputs that must be measured are: (1) the cumulative average goodput of the flow from Category I, goodput_Cat_I (see Section 2.5 for the estimation of the goodput); (2) the cumulative average goodput of the flow from Category II, goodput_Cat_II (see Section 2.5 for the estimation of the goodput); (3) the ratio goodput_Cat_II/ goodput_Cat_I; and (4) the average packet drop rate for each category (Section 2.3).
必须测量的输出为：（1）I类流量的累积平均goodput，goodput_Cat_I（goodput的估算见第2.5节）；（2） II类、II类和II类流量的累计平均投入（投入估算见第2.5节）；（3） 二类产品的有效投入/一类产品的有效投入比率；和（4）每个类别的平均分组丢弃率（第2.3节）。
"AQM mechanisms might need to control the overall queue sizes to ensure that arriving bursts can be accommodated without dropping packets" [RFC7567].
“AQM机制可能需要控制总体队列大小，以确保能够在不丢弃数据包的情况下容纳到达的突发事件”[RFC7567]。
An AQM scheme can face bursts of packet arrivals due to various reasons. Dropping one or more packets from a burst can result in performance penalties for the corresponding flows, since dropped packets have to be retransmitted. Performance penalties can result in failing to meet Service Level Agreements (SLAs) and can be a disincentive to AQM adoption.
由于各种原因，AQM方案可能面临突发的数据包到达。从突发中丢弃一个或多个数据包可能会导致相应流的性能损失，因为丢弃的数据包必须重新传输。性能惩罚可能会导致无法满足服务级别协议（SLA），并会阻碍AQM的采用。
The ability to accommodate bursts translates to larger queue length and hence more queuing delay. On the one hand, it is important that an AQM scheme quickly brings bursty traffic under control. On the other hand, a peak in the packet drop rates to bring a packet burst quickly under control could result in multiple drops per flow and severely impact transport and application performance. Therefore, an AQM scheme ought to bring bursts under control by balancing both aspects -- (1) queuing delay spikes are minimized and (2) performance penalties for ongoing flows in terms of packet drops are minimized.
适应突发的能力转化为更大的队列长度，从而产生更多的队列延迟。一方面，重要的是AQM方案能够快速控制突发流量。另一方面，数据包丢弃率的峰值会使数据包突发迅速得到控制，这可能导致每个流发生多次丢弃，并严重影响传输和应用程序性能。因此，AQM方案应该通过平衡这两个方面来控制突发--（1）最小化排队延迟峰值，以及（2）最小化正在进行的流在丢包方面的性能损失。
An AQM scheme that maintains short queues allows some remaining space in the buffer for bursts of arriving packets. The tolerance to bursts of packets depends upon the number of packets in the queue, which is directly linked to the AQM algorithm. Moreover, an AQM scheme may implement a feature controlling the maximum size of accepted bursts that can depend on the buffer occupancy or the currently estimated queuing delay. The impact of the buffer size on the burst allowance may be evaluated.
维护短队列的AQM方案允许缓冲区中的一些剩余空间用于突发到达的数据包。对数据包突发的容忍度取决于队列中数据包的数量，该数量与AQM算法直接相关。此外，AQM方案可实施控制可接受突发的最大大小的特征，该最大大小可取决于缓冲器占用或当前估计的排队延迟。可以评估缓冲器大小对突发容限的影响。
For this scenario, the tester must evaluate how the AQM performs with a traffic mix. The traffic mix could be composed of (from sender A to receiver B):
对于这种情况，测试人员必须评估AQM在流量混合中的性能。通信量组合可以由（从发送方A到接收方B）组成：
o Burst of packets at the beginning of a transmission, such as web traffic with IW10;
o 传输开始时的数据包突发，如IW10的网络流量；
o Applications that send large bursts of data, such as bursty video frames;
o 发送大量数据的应用程序，如突发视频帧；
o Background traffic, such as Constant Bit Rate (CBR) UDP traffic and/or A single non-application-limited bulk TCP flow as background traffic.
o 后台流量，例如恒定比特率（CBR）UDP流量和/或单个非应用程序限制的批量TCP流作为后台流量。
Figure 2 presents the various cases for the traffic that must be generated between sender A and receiver B.
图2显示了发送方A和接收方B之间必须生成的流量的各种情况。
+-------------------------------------------------+
|Case| Traffic Type |
| +-----+------------+----+--------------------+
| |Video|Web (IW 10)| CBR| Bulk TCP Traffic |
+----|-----|------------|----|--------------------|
|I | 0 | 1 | 1 | 0 |
+----|-----|------------|----|--------------------|
|II | 0 | 1 | 1 | 1 |
|----|-----|------------|----|--------------------|
|III | 1 | 1 | 1 | 0 |
+----|-----|------------|----|--------------------|
|IV | 1 | 1 | 1 | 1 |
+----+-----+------------+----+--------------------+
+-------------------------------------------------+
|Case| Traffic Type |
| +-----+------------+----+--------------------+
| |Video|Web (IW 10)| CBR| Bulk TCP Traffic |
+----|-----|------------|----|--------------------|
|I | 0 | 1 | 1 | 0 |
+----|-----|------------|----|--------------------|
|II | 0 | 1 | 1 | 1 |
|----|-----|------------|----|--------------------|
|III | 1 | 1 | 1 | 0 |
+----|-----|------------|----|--------------------|
|IV | 1 | 1 | 1 | 1 |
+----+-----+------------+----+--------------------+
Figure 2: Bursty Traffic Scenarios
图2：突发流量场景
A new web page download could start after the previous web page download is finished. Each web page could be composed of at least 50 objects and the size of each object should be at least 1 KB. Six TCP parallel connections should be generated to download the objects, each parallel connection having an initial congestion window set to 10 packets.
在上一个网页下载完成后，可以开始新的网页下载。每个网页可以由至少50个对象组成，每个对象的大小应至少为1KB。应生成六个TCP并行连接以下载对象，每个并行连接的初始拥塞窗口设置为10个数据包。
For each of these scenarios, the graph described in Section 2.7 could be generated for each application. Metrics such as end-to-end latency, jitter, and flow completion time may be generated. For the cases of frame generation of bursty video traffic as well as the choice of web traffic pattern, these details and their presentation are left to the testers.
对于这些场景中的每一个，可以为每个应用程序生成第2.7节中描述的图表。可以生成诸如端到端延迟、抖动和流完成时间之类的度量。对于突发视频流量的帧生成以及web流量模式的选择，这些细节及其表示留给测试人员。
The safety of an AQM scheme is directly related to its stability under varying operating conditions such as varying traffic profiles and fluctuating network conditions. Since operating conditions can vary often, the AQM needs to remain stable under these conditions without the need for additional external tuning.
AQM方案的安全性直接关系到其在不同运行条件下的稳定性，例如不同的流量分布和波动的网络条件。由于工作条件经常变化，AQM需要在这些条件下保持稳定，而无需额外的外部调谐。
Network devices can experience varying operating conditions depending on factors such as time of the day, deployment scenario, etc. For example:
网络设备可能会经历不同的操作条件，这取决于诸如时间、部署场景等因素。例如：
o Traffic and congestion levels are higher during peak hours than off-peak hours.
o 高峰时间的交通和拥挤程度高于非高峰时间。
o In the presence of a scheduler, the draining rate of a queue can vary depending on the occupancy of other queues: a low load on a high-priority queue implies a higher draining rate for the lower-priority queues.
o 在调度程序存在的情况下，队列的排放速率可能会因其他队列的占用情况而有所不同：高优先级队列上的低负载意味着低优先级队列的排放速率更高。
o The capacity available can vary over time (e.g., a lossy channel, a link supporting traffic in a higher Diffserv class).
o 可用容量可以随时间变化（例如，有损信道、支持更高Diffserv类流量的链路）。
Whether or not the target context is a stable environment, the ability of an AQM scheme to maintain its control over the queuing delay and buffer occupancy can be challenged. This document proposes guidelines to assess the behavior of AQM schemes under varying congestion levels and varying draining rates.
无论目标上下文是否为稳定环境，AQM方案保持其对排队延迟和缓冲区占用的控制能力都可能受到挑战。本文件提出了在不同拥挤程度和不同排水率下评估AQM方案行为的指南。
Note that the traffic profiles explained below comprises non-application-limited TCP flows. For each of the below scenarios, the graphs described in Section 2.7 should be generated, and the goodput of the various flows should be cumulated. For Section 8.2.5 and Section 8.2.6, they should incorporate the results in a per-phase basis as well.
注意，下面解释的流量配置文件包括非应用程序限制的TCP流。对于以下每种情况，应生成第2.7节中描述的图表，并累计各种流量的收益。对于第8.2.5节和第8.2.6节，还应将结果纳入每个阶段的基础中。
Wherever the notion of time has been explicitly mentioned in this subsection, time 0 starts from the moment all TCP flows have already reached their congestion avoidance phase.
在本小节中明确提到时间概念的地方，时间0从所有TCP流已经达到拥塞避免阶段的那一刻开始。
In these guidelines, the congestion levels are represented by the projected packet drop rate, which is determined when there is no AQM scheme (i.e., a drop-tail queue). When the bottleneck is shared among non-application-limited TCP flows, l_r (the loss rate projection) can be expressed as a function of N, the number of bulk TCP flows, and S, the sum of the bandwidth-delay product and the maximum buffer size, both expressed in packets, based on Eq. 3 of [MORR2000]:
在这些指南中，拥塞水平由预测的分组丢弃率表示，该速率在没有AQM方案（即丢弃尾队列）时确定。当瓶颈在非应用程序限制的TCP流之间共享时，l_r（丢失率投影）可以表示为N、批量TCP流的数量和S、带宽延迟乘积和最大缓冲区大小之和的函数，两者都以分组表示，基于[MORR2000]的等式3：
l_r = 0.76 * N^2 / S^2
l_r = 0.76 * N^2 / S^2
N = S * SQRT(1/0.76) * SQRT(l_r)
N = S * SQRT(1/0.76) * SQRT(l_r)
These guidelines use the loss rate to define the different congestion levels, but they do not stipulate that in other circumstances, measuring the congestion level gives you an accurate estimation of the loss rate or vice versa.
这些指南使用丢失率来定义不同的拥塞级别，但它们没有规定在其他情况下，测量拥塞级别可以准确估计丢失率，反之亦然。
This scenario can be used to evaluate how an AQM scheme reacts to a light load of incoming traffic resulting in mild congestion -- packet drop rates around 0.1%. The number of bulk flows required to achieve this congestion level, N_mild, is then:
此场景可用于评估AQM方案如何对轻负载的传入流量做出反应，从而导致轻微的拥塞——丢包率约为0.1%。达到该拥挤水平所需的大量流量N_-mild为：
N_mild = ROUND (0.036*S)
N_轻度=圆形（0.036*S）
This scenario can be used to evaluate how an AQM scheme reacts to incoming traffic resulting in medium congestion -- packet drop rates around 0.5%. The number of bulk flows required to achieve this congestion level, N_med, is then:
此场景可用于评估AQM方案如何对导致中等拥塞的传入流量作出反应——丢包率约为0.5%。达到该拥挤水平所需的批量流量N_med为：
N_med = ROUND (0.081*S)
N_med=圆形（0.081*S）
This scenario can be used to evaluate how an AQM scheme reacts to incoming traffic resulting in heavy congestion -- packet drop rates around 1%. The number of bulk flows required to achieve this congestion level, N_heavy, is then:
此场景可用于评估AQM方案如何对导致严重拥塞的传入流量做出反应——丢包率约为1%。达到该拥挤水平所需的大量流量N_heavy为：
N_heavy = ROUND (0.114*S)
N_重型=圆形（0.114*S）
This scenario can be used to evaluate how an AQM scheme reacts to incoming traffic resulting in various levels of congestion during the experiment. In this scenario, the congestion level varies within a large timescale. The following phases may be considered: phase I -- mild congestion during 0-20 s; phase II -- medium congestion during 20-40 s; phase III -- heavy congestion during 40-60 s; phase I again, and so on.
此场景可用于评估AQM方案如何对实验期间导致不同程度拥塞的传入流量作出反应。在这种情况下，拥塞水平在一个大的时间范围内变化。可考虑以下阶段：第一阶段——0-20秒期间的轻度拥堵；第二阶段——20-40秒期间中等拥堵；第三阶段——40-60秒期间严重拥堵；第一阶段又开始了，等等。
This scenario can be used to help characterize how the AQM behaves and adapts to bandwidth changes. The experiments are not meant to reflect the exact conditions of Wi-Fi environments since it is hard to design repetitive experiments or accurate simulations for such scenarios.
此场景可用于帮助描述AQM的行为以及如何适应带宽变化。这些实验并不是为了反映Wi-Fi环境的确切情况，因为很难为此类场景设计重复性实验或精确模拟。
To emulate varying draining rates, the bottleneck capacity between nodes 'Router L' and 'Router R' varies over the course of the experiment as follows:
为了模拟不同的排放速率，节点“路由器L”和“路由器R”之间的瓶颈容量在实验过程中变化如下：
o Experiment 1: The capacity varies between two values within a large timescale. As an example, the following phases may be considered: phase I -- 100 Mbps during 0-20 s; phase II -- 10 Mbps during 20-40 s; phase I again, and so on.
o 实验1：在一个大的时间尺度内，容量在两个值之间变化。例如，可考虑以下阶段：阶段I——0-20 s期间的100 Mbps；第二阶段——20-40秒期间为10 Mbps；第一阶段又开始了，等等。
o Experiment 2: The capacity varies between two values within a short timescale. As an example, the following phases may be considered: phase I -- 100 Mbps during 0-100 ms; phase II -- 10 Mbps during 100-200 ms; phase I again, and so on.
o 实验2：容量在短时间内在两个值之间变化。例如，可考虑以下阶段：阶段I——0-100 ms期间的100 Mbps；第二阶段——在100-200毫秒内达到10 Mbps；第一阶段又开始了，等等。
The tester may choose a phase time-interval value different than what is stated above, if the network's path conditions (such as bandwidth-delay product) necessitate. In this case, the choice of such a time-interval value should be stated and elaborated.
如果网络的路径条件（如带宽延迟积）需要，测试仪可以选择与上述不同的相位时间间隔值。在这种情况下，应说明并详细说明时间间隔值的选择。
The tester may additionally evaluate the two mentioned scenarios (short-term and long-term capacity variations), during and/or including the TCP slow-start phase.
在TCP慢启动阶段和/或包括TCP慢启动阶段，测试人员还可以评估上述两种情况（短期和长期容量变化）。
More realistic fluctuating capacity patterns may be considered. The tester may choose to incorporate realistic scenarios with regards to common fluctuation of bandwidth in state-of-the-art technologies.
可以考虑更现实的容量波动模式。测试人员可以选择结合与最先进技术中带宽的常见波动有关的现实场景。
The scenario consists of TCP NewReno flows between sender A and receiver B. To better assess the impact of draining rates on the AQM behavior, the tester must compare its performance with those of drop-
该场景由发送方A和接收方B之间的TCP NewReno流组成。为了更好地评估排放速率对AQM行为的影响，测试人员必须将其性能与drop的性能进行比较-
tail and should provide a reference document for their proposal discussing performance and deployment compared to those of drop-tail. Burst traffic, such as presented in Section 7.2, could also be considered to assess the impact of varying available capacity on the burst absorption of the AQM.
与drop-tail相比，tail和drop-tail应为其提案提供一份参考文件，讨论性能和部署。如第7.2节所述的突发通信量也可用于评估不同可用容量对AQM突发吸收的影响。
The control law used by an AQM is the primary means by which the queuing delay is controlled. Hence, understanding the control law is critical to understanding the behavior of the AQM scheme. The control law could include several input parameters whose values affect the AQM scheme's output behavior and its stability. Additionally, AQM schemes may auto-tune parameter values in order to maintain stability under different network conditions (such as different congestion levels, draining rates, or network environments). The stability of these auto-tuning techniques is also important to understand.
AQM使用的控制律是控制排队延迟的主要手段。因此，理解控制律对于理解AQM方案的行为至关重要。控制律可以包括几个输入参数，这些参数的值影响AQM方案的输出行为及其稳定性。此外，AQM方案可以自动调整参数值，以便在不同的网络条件下（例如不同的拥塞水平、流量或网络环境）保持稳定性。了解这些自动调谐技术的稳定性也很重要。
Transports operating under the control of AQM experience the effect of multiple control loops that react over different timescales. It is therefore important that proposed AQM schemes are seen to be stable when they are deployed at multiple points of potential congestion along an Internet path. The pattern of congestion signals (loss or ECN-marking) arising from AQM methods also needs to not adversely interact with the dynamics of the transport protocols that they control.
在AQM控制下运行的运输系统会受到多个控制回路的影响，这些回路会在不同的时间尺度上作出反应。因此，重要的是，当所提议的AQM方案部署在互联网路径上多个潜在拥塞点时，它们被认为是稳定的。AQM方法产生的拥塞信号模式（丢失或ECN标记）也不需要与它们控制的传输协议的动态产生负面影响。
AQM proposals should provide background material showing theoretical analysis of the AQM control law and the input parameter space within which the control law operates, or they should use another way to discuss the stability of the control law. For parameters that are auto-tuned, the material should include stability analysis of the auto-tuning mechanism(s) as well. Such analysis helps to understand an AQM control law better and the network conditions/deployments under which the AQM is stable.
AQM提案应提供背景材料，说明AQM控制律的理论分析和控制律运行的输入参数空间，或者应使用另一种方式讨论控制律的稳定性。对于自动调谐的参数，材料还应包括自动调谐机构的稳定性分析。此类分析有助于更好地理解AQM控制规律以及AQM稳定的网络条件/部署。
This section provides guidelines to assess the performance of an AQM proposal for various traffic profiles such as traffic with different applications or bidirectional traffic.
本节提供了评估AQM提案在各种流量配置文件（如具有不同应用程序的流量或双向流量）中的性能的指南。
This scenario can be used to evaluate how an AQM scheme reacts to a traffic mix consisting of different applications such as:
此场景可用于评估AQM方案如何对由不同应用程序组成的流量混合做出反应，例如：
o Bulk TCP transfer
o 批量TCP传输
o Web traffic
o 网络流量
o VoIP
o 网络电话
o Constant Bit Rate (CBR) UDP traffic
o 恒定比特率（CBR）UDP流量
o Adaptive video streaming (either unidirectional or bidirectional)
o 自适应视频流（单向或双向）
Various traffic mixes can be considered. These guidelines recommend examining at least the following example: 1 bidirectional VoIP; 6 web page downloads (such as those detailed in Section 7.2); 1 CBR; 1 Adaptive Video; 5 bulk TCP. Any other combinations could be considered and should be carefully documented.
可以考虑各种交通混合。这些指南建议至少检查以下示例：1双向VoIP；6个网页下载（如第7.2节所述）；1 CBR；1自适应视频；5批量TCP。可以考虑任何其他组合，并应仔细记录。
For each scenario, the graph described in Section 2.7 could be generated for each class of traffic. Metrics such as end-to-end latency, jitter, and flow completion time may be reported.
对于每种情况，可以为每类流量生成第2.7节中描述的图表。可以报告诸如端到端延迟、抖动和流完成时间之类的度量。
Control packets such as DNS requests/responses, TCP SYNs/ACKs are small, but their loss can severely impact the application performance. The scenario proposed in this section will help in assessing whether the introduction of an AQM scheme increases the loss probability of these important packets.
DNS请求/响应、TCP SYNs/ACK等控制数据包很小，但它们的丢失会严重影响应用程序的性能。本节中提出的场景将有助于评估AQM方案的引入是否会增加这些重要数据包的丢失概率。
For this scenario, traffic must be generated in both downlink and uplink, as defined in Section 3.1. The amount of asymmetry between the uplink and the downlink depends on the context. These guidelines recommend considering a mild congestion level and the traffic presented in Section 8.2.2 in both directions. In this case, the metrics reported must be the same as in Section 8.2 for each direction.
对于这种情况，必须在下行链路和上行链路中生成流量，如第3.1节所定义。上行链路和下行链路之间的不对称程度取决于上下文。这些指南建议在两个方向上考虑轻度拥堵水平和第8.2.2节中所述的交通量。在这种情况下，报告的指标必须与第8.2节中针对每个方向的指标相同。
The traffic mix presented in Section 9.1 may also be generated in both directions.
第9.1节所述的交通组合也可在两个方向上产生。
Transports operating under the control of AQM experience the effect of multiple control loops that react over different timescales. It is therefore important that proposed AQM schemes are seen to be stable when they are deployed at multiple points of potential congestion along an Internet path. The pattern of congestion signals (loss or ECN-marking) arising from AQM methods also need to not adversely interact with the dynamics of the transport protocols that they control.
在AQM控制下运行的运输系统会受到多个控制回路的影响，这些回路会在不同的时间尺度上作出反应。因此，重要的是，当所提议的AQM方案部署在互联网路径上多个潜在拥塞点时，它们被认为是稳定的。AQM方法产生的拥塞信号模式（丢失或ECN标记）也不需要与它们控制的传输协议的动态产生负面影响。
+---------+ +-----------+
|senders A|---+ +---|receivers A|
+---------+ | | +-----------+
+-----+---+ +---------+ +--+-----+
|Router L |--|Router M |--|Router R|
|AQM A | |AQM M | |No AQM |
+---------+ +--+------+ +--+-----+
+---------+ | | +-----------+
|senders B|-------------+ +---|receivers B|
+---------+ +-----------+
+---------+ +-----------+
|senders A|---+ +---|receivers A|
+---------+ | | +-----------+
+-----+---+ +---------+ +--+-----+
|Router L |--|Router M |--|Router R|
|AQM A | |AQM M | |No AQM |
+---------+ +--+------+ +--+-----+
+---------+ | | +-----------+
|senders B|-------------+ +---|receivers B|
+---------+ +-----------+
Figure 3: Topology for the Multi-AQM Scenario
图3：多AQM场景的拓扑
Figure 3 describes topology options for evaluating multi-AQM scenarios. The AQM schemes are applied in sequence and impact the induced latency reduction, the induced goodput maximization, and the trade-off between these two. Note that AQM schemes A and B introduced in Routers L and M could be (I) same scheme with identical parameter values, (ii) same scheme with different parameter values, or (iii) two different schemes. To best understand the interactions and implications, the mild congestion scenario as described in Section 8.2.2 is recommended such that the number of flows is equally shared among senders A and B. Other relevant combinations of congestion levels could also be considered. We recommend measuring the metrics presented in Section 8.2.
图3描述了用于评估多AQM场景的拓扑选项。AQM方案按顺序应用，并影响诱导延迟减少、诱导输出最大化以及两者之间的权衡。注意，在路由器L和M中引入的AQM方案A和B可以是（I）具有相同参数值的相同方案，（ii）具有不同参数值的相同方案，或者（iii）两个不同方案。为了更好地理解相互作用和影响，建议采用第8.2.2节所述的轻度拥塞情况，以便在发送方A和B之间平均分配流量数量。还可以考虑拥塞级别的其他相关组合。我们建议测量第8.2节中提出的指标。
Successful deployment of AQM is directly related to its cost of implementation. Network devices may need hardware or software implementations of the AQM mechanism. Depending on a device's capabilities and limitations, the device may or may not be able to implement some or all parts of their AQM logic.
AQM的成功部署与其实施成本直接相关。网络设备可能需要AQM机制的硬件或软件实现。取决于设备的能力和限制，设备可能或可能无法实现其AQM逻辑的部分或全部部分。
AQM proposals should provide pseudocode for the complete AQM scheme, highlighting generic implementation-specific aspects of the scheme such as "drop-tail" vs. "drop-head", inputs (e.g., current queuing delay, and queue length), computations involved, need for timers, etc. This helps to identify costs associated with implementing the AQM scheme on a particular hardware or software device. This also facilitates discussions around which kind of devices can easily support the AQM and which cannot.
AQM提案应为完整的AQM方案提供伪代码，突出该方案的通用实施特定方面，如“落差尾”与“落差头”、输入（例如，当前排队延迟和队列长度）、涉及的计算、计时器的需要、，等。这有助于确定与在特定硬件或软件设备上实施AQM方案相关的成本。这也有助于讨论哪些设备可以轻松支持AQM，哪些设备不能。
AQM proposals should highlight parts of their AQM logic that are device dependent and discuss if and how AQM behavior could be impacted by the device. For example, a queuing-delay-based AQM scheme requires current queuing delay as input from the device. If the device already maintains this value, then it can be trivial to implement the AQM logic on the device. If the device provides indirect means to estimate the queuing delay (for example, timestamps and dequeuing rate), then the AQM behavior is sensitive to the precision of the queuing delay estimations are for that device. Highlighting the sensitivity of an AQM scheme to queuing delay estimations helps implementers to identify appropriate means of implementing the mechanism on a device.
AQM提案应强调其AQM逻辑中与设备相关的部分，并讨论设备是否会影响AQM行为以及如何影响AQM行为。例如，基于排队延迟的AQM方案需要当前排队延迟作为设备的输入。如果设备已经维护了这个值，那么在设备上实现AQM逻辑就很简单了。如果设备提供间接方法来估计排队延迟（例如，时间戳和排队率），则AQM行为对该设备的排队延迟估计的精度敏感。强调AQM方案对排队延迟估计的敏感性有助于实现者确定在设备上实现该机制的适当方法。
One of the biggest hurdles of RED deployment was/is its parameter sensitivity to operating conditions -- how difficult it is to tune RED parameters for a deployment to achieve acceptable benefit from using RED. Fluctuating congestion levels and network conditions add to the complexity. Incorrect parameter values lead to poor performance.
RED部署的最大障碍之一是其参数对操作条件的敏感性——为部署调整RED参数以从使用RED中获得可接受的好处有多困难。波动的拥塞水平和网络状况增加了复杂性。参数值不正确会导致性能不佳。
Any AQM scheme is likely to have parameters whose values affect the control law and behavior of an AQM. Exposing all these parameters as control parameters to a network operator (or user) can easily result
任何AQM方案都可能具有其值影响AQM的控制律和行为的参数。将所有这些参数作为控制参数公开给网络运营商（或用户）很容易产生错误
in an unsafe AQM deployment. Unexpected AQM behavior ensues when parameter values are set improperly. A minimal number of control parameters minimizes the number of ways a user can break a system where an AQM scheme is deployed at. Fewer control parameters make the AQM scheme more user-friendly and easier to deploy and debug.
在不安全的AQM部署中。参数值设置不正确时，会出现意外的AQM行为。最少数量的控制参数可以最大限度地减少用户破坏部署AQM方案的系统的方式。更少的控制参数使AQM方案更加用户友好，更易于部署和调试。
"AQM algorithms SHOULD NOT require tuning of initial or configuration parameters in common use cases." such as stated in Section 4 of the AQM recommendation document [RFC7567]. A scheme ought to expose only those parameters that control the macroscopic AQM behavior such as queue delay threshold, queue length threshold, etc.
“AQM算法不应要求在常见用例中调整初始或配置参数。”如AQM建议文件[RFC7567]第4节所述。一个方案应该只公开那些控制宏观AQM行为的参数，如队列延迟阈值、队列长度阈值等。
Additionally, the safety of an AQM scheme is directly related to its stability under varying operating conditions such as varying traffic profiles and fluctuating network conditions, as described in Section 8. Operating conditions vary often and hence the AQM needs to remain stable under these conditions without the need for additional external tuning. If AQM parameters require tuning under these conditions, then the AQM must self-adapt necessary parameter values by employing auto-tuning techniques.
此外，如第8节所述，AQM方案的安全性直接关系到其在不同操作条件下的稳定性，例如不同的流量分布和波动的网络条件。操作条件经常变化，因此AQM需要在这些条件下保持稳定，而无需额外的外部调谐。如果AQM参数在这些条件下需要调整，那么AQM必须通过采用自动调整技术自适应必要的参数值。
In order to understand an AQM's deployment considerations and performance under a specific environment, AQM proposals should describe the parameters that control the macroscopic AQM behavior, and identify any parameters that require tuning to operational conditions. It could be interesting to also discuss that, even if an AQM scheme may not adequately auto-tune its parameters, the resulting performance may not be optimal, but close to something reasonable.
为了了解AQM在特定环境下的部署注意事项和性能，AQM提案应描述控制宏观AQM行为的参数，并确定需要调整到操作条件的任何参数。还可以有趣地讨论，即使AQM方案可能没有充分地自动调整其参数，结果性能可能不是最优的，但接近合理的。
If there are any fixed parameters within the AQM, their setting should be discussed and justified to help understand whether a fixed parameter value is applicable for a particular environment.
如果AQM中存在任何固定参数，则应讨论并证明其设置，以帮助了解固定参数值是否适用于特定环境。
If an AQM scheme is evaluated with parameter(s) that were externally tuned for optimization or other purposes, these values must be disclosed.
如果使用为优化或其他目的而进行外部调整的参数评估AQM方案，则必须披露这些值。
Figure 4 lists the scenarios for an extended characterization of an AQM scheme. This table comes along with a set of requirements to present more clearly the weight and importance of each scenario. The requirements listed here are informational and their relevance may depend on the deployment scenario.
图4列出了AQM方案的扩展特征描述的场景。此表附带了一组需求，以更清楚地显示每个场景的权重和重要性。此处列出的需求仅供参考，其相关性可能取决于部署场景。
+------------------------------------------------------------------+
|Scenario |Sec. |Informational requirement |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|Interaction with ECN | 4.5 |must be discussed if supported |
+------------------------------------------------------------------+
|Interaction with Scheduling| 4.6 |should be discussed |
+------------------------------------------------------------------+
|Transport Protocols | 5 | |
| TCP-friendly sender | 5.1 |scenario must be considered |
| Aggressive sender | 5.2 |scenario must be considered |
| Unresponsive sender | 5.3 |scenario must be considered |
| LBE sender | 5.4 |scenario may be considered |
+------------------------------------------------------------------+
|Round-Trip Time Fairness | 6.2 |scenario must be considered |
+------------------------------------------------------------------+
|Burst Absorption | 7.2 |scenario must be considered |
+------------------------------------------------------------------+
|Stability | 8 | |
| Varying congestion levels | 8.2.5|scenario must be considered |
| Varying available capacity| 8.2.6|scenario must be considered |
| Parameters and stability | 8.3 |this should be discussed |
+------------------------------------------------------------------+
|Various Traffic Profiles | 9 | |
| Traffic mix | 9.1 |scenario is recommended |
| Bidirectional traffic | 9.2 |scenario may be considered |
+------------------------------------------------------------------+
|Multi-AQM | 10.2 |scenario may be considered |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|Scenario |Sec. |Informational requirement |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|Interaction with ECN | 4.5 |must be discussed if supported |
+------------------------------------------------------------------+
|Interaction with Scheduling| 4.6 |should be discussed |
+------------------------------------------------------------------+
|Transport Protocols | 5 | |
| TCP-friendly sender | 5.1 |scenario must be considered |
| Aggressive sender | 5.2 |scenario must be considered |
| Unresponsive sender | 5.3 |scenario must be considered |
| LBE sender | 5.4 |scenario may be considered |
+------------------------------------------------------------------+
|Round-Trip Time Fairness | 6.2 |scenario must be considered |
+------------------------------------------------------------------+
|Burst Absorption | 7.2 |scenario must be considered |
+------------------------------------------------------------------+
|Stability | 8 | |
| Varying congestion levels | 8.2.5|scenario must be considered |
| Varying available capacity| 8.2.6|scenario must be considered |
| Parameters and stability | 8.3 |this should be discussed |
+------------------------------------------------------------------+
|Various Traffic Profiles | 9 | |
| Traffic mix | 9.1 |scenario is recommended |
| Bidirectional traffic | 9.2 |scenario may be considered |
+------------------------------------------------------------------+
|Multi-AQM | 10.2 |scenario may be considered |
+------------------------------------------------------------------+
Figure 4: Summary of the Scenarios and their Requirements
图4：场景及其需求摘要
Some security considerations for AQM are identified in [RFC7567]. This document, by itself, presents no new privacy or security issues.
[RFC7567]中确定了AQM的一些安全注意事项。本文件本身不存在新的隐私或安全问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, 1997.
[RFC2119]Bradner，S.，“在RFC中用于指示需求水平的关键词”，RFC 211997。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <http://www.rfc-editor.org/info/rfc2544>.
[RFC2544]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，DOI 10.17487/RFC2544，1999年3月<http://www.rfc-editor.org/info/rfc2544>.
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999, <http://www.rfc-editor.org/info/rfc2647>.
[RFC2647]Newman，D.，“防火墙性能的基准术语”，RFC 2647，DOI 10.17487/RFC2647，1999年8月<http://www.rfc-editor.org/info/rfc2647>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <http://www.rfc-editor.org/info/rfc5481>.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 5481，DOI 10.17487/RFC5481，2009年3月<http://www.rfc-editor.org/info/rfc5481>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-editor.org/info/rfc7567>.
[RFC7567]Baker，F.，Ed.和G.Fairhurst，Ed.，“IETF关于主动队列管理的建议”，BCP 197，RFC 7567，DOI 10.17487/RFC7567，2015年7月<http://www.rfc-editor.org/info/rfc7567>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-editor.org/info/rfc7679>.
[RFC7679]Almes，G.，Kalidini，S.，Zekauskas，M.，和A.Morton，Ed.，“IP性能度量（IPPM）的单向延迟度量”，STD 81，RFC 7679，DOI 10.17487/RFC7679，2016年1月<http://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <http://www.rfc-editor.org/info/rfc7680>.
[RFC7680]Almes，G.，Kalidini，S.，Zekauskas，M.，和A.Morton，Ed.，“IP性能度量（IPPM）的单向损失度量”，STD 82，RFC 7680，DOI 10.17487/RFC7680，2016年1月<http://www.rfc-editor.org/info/rfc7680>.
[ANEL2014] Anelli, P., Diana, R., and E. Lochin, "FavorQueue: a Parameterless Active Queue Management to Improve TCP Traffic Performance", Computer Networks Vol. 60, DOI 10.1016/j.bjp.2013.11.008, 2014.
[ANEL2014]Anelli，P.，Diana，R.，和E.Lochin，“FavorQueue:一种无参数的主动队列管理，以提高TCP流量性能”，计算机网络第60卷，DOI 10.1016/j.bjp.2013.11.008，2014。
[AQMPIE] Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", Work in Progress, draft-ietf-aqm-pie-08, June 2016.
[AQMPIE]Pan，R.，Natarajan，P.，Baker，F.，和G.White，“PIE：解决缓冲区膨胀问题的轻量级控制方案”，正在进行的工作，草稿-ietf-aqm-PIE-082016年6月。
[BB2011] Cerf, V., Jacobson, V., Weaver, N., and J. Gettys, "BufferBloat: what's wrong with the internet?", ACM Queue Vol. 55, DOI 10.1145/2076450.2076464, 2012.
[BB2011]Cerf，V.，Jacobson，V.，Weaver，N.，和J.Gettys，“BufferBloat:互联网怎么了？”，ACM队列第55卷，DOI 10.1145/2076450.20764642012。
[BCP41] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[BCP41]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification", BCP 41, RFC 7141, February 2014.
Briscoe，B.和J.Way，“字节和数据包拥塞通知”，BCP 41，RFC 71412014年2月。
<http://www.rfc-editor.org/info/bcp41>
<http://www.rfc-editor.org/info/bcp41>
[CODEL] Nichols, K., Jacobson, V., McGregor, A., and J. Iyengar, "Controlled Delay Active Queue Management", Work in Progress, draft-ietf-aqm-codel-04, June 2016.
[CODEL]Nichols，K.，Jacobson，V.，McGregor，A.，和J.Iyengar，“受控延迟主动队列管理”，在建工程，草案-ietf-aqm-CODEL-042016年6月。
[CUBIC] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", Work in Progress, draft-ietf-tcpm-cubic-01, January 2016.
[CUBIC]Rhee，I.，Xu，L.，Ha，S.，Zimmermann，A.，Eggert，L.，和R.Scheffenegger，“用于快速长途网络的CUBIC”，正在进行的工作，草案-ietf-tcpm-CUBIC-01，2016年1月。
[FENG2002] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE active queue management algorithms", IEEE Transactions on Networking Vol.10 Issue 4, DOI 10.1109/TNET.2002.801399, 2002, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=1026008>.
[FENG2002]Feng，W.，Shin，K.，Kandlur，D.，和D.Saha，“蓝色主动队列管理算法”，IEEE网络交易第10卷第4期，DOI 10.1109/TNET.2002.8013992002<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=1026008>。
[FLOY1993] Floyd, S. and V. Jacobson, "Random Early Detection (RED) Gateways for Congestion Avoidance", IEEE Transactions on Networking Vol. 1 Issue 4, DOI 10.1109/90.251892, 1993, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=251892>.
[FLOY1993]Floyd，S.和V.Jacobson，“用于避免拥塞的随机早期检测（RED）网关”，《IEEE网络交易》第1卷第4期，DOI 10.1109/90.251892191993<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=251892>。
[GONG2014] Gong, Y., Rossi, D., Testa, C., Valenti, S., and D. Taht, "Fighting the bufferbloat: on the coexistence of AQM and low priority congestion control", Computer Networks, Elsevier, 2014, pp.115-128 Vol. 60, DOI 10.1109/INFCOMW.2013.6562885, 2014.
[GONG2014]Gong，Y.，Rossi，D.，Testa，C.，Valenti，S.，和D.Taht，“对抗缓冲区膨胀：关于AQM和低优先级拥塞控制的共存”，计算机网络，爱思唯尔，2014年，第115-128页第60卷，DOI 10.1109/INFCOMW.2013.6562885，2014年。
[HASS2008] Hassayoun, S. and D. Ros, "Loss Synchronization and Router Buffer Sizing with High-Speed Versions of TCP", IEEE INFOCOM Workshops, DOI 10.1109/INFOCOM.2008.4544632, 2008, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=4544632>.
[Hassayun，S.和D.Ros，“TCP高速版本的丢失同步和路由器缓冲区大小”，IEEE信息通信研讨会，DOI 10.1109/INFOCOM.2008.45446322008<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=4544632>。
[HOEI2015] Hoeiland-Joergensen, T., McKenney, P., dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm", Work in Progress, draft-ietf-aqm-fq-codel-06, March 2016.
[HOEI2015]Hoeiland Joergensen，T.，McKenney，P.，dave。taht@gmail.com，d.，Gettys，J.和E.Dumazet，“FlowQueue CoDel数据包调度器和主动队列管理算法”，正在进行的工作，草稿-ietf-aqm-fq-CoDel-062016年3月。
[HOLLO2001] Hollot, C., Misra, V., Towsley, V., and W. Gong, "On Designing Improved Controller for AQM Routers Supporting TCP Flows", IEEE INFOCOM, DOI 10.1109/INFCOM.2001.916670, 2001, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=916670>.
[HOLLO2001]Hollot，C.，Misra，V.，Towsley，V.，和W.Gong，“关于为支持TCP流的AQM路由器设计改进的控制器”，IEEE INFOCOM，DOI 10.1109/INFCOM.2001.9166702001<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=916670>。
[JAY2006] Jay, P., Fu, Q., and G. Armitage, "A preliminary analysis of loss synchronisation between concurrent TCP flows", Australian Telecommunication Networks and Application Conference (ATNAC), 2006.
[JAY2006]Jay，P.，Fu，Q.，和G.Armitage，“并发TCP流之间丢失同步的初步分析”，澳大利亚电信网络和应用会议（ATNAC），2006年。
[MORR2000] Morris, R., "Scalable TCP congestion control", IEEE INFOCOM, DOI 10.1109/INFCOM.2000.832487, 2000, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=832487>.
[MORR2000]Morris，R.，“可伸缩TCP拥塞控制”，IEEE信息网，DOI 10.1109/INFCOM.2000.832487，2000<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=832487>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, <http://www.rfc-editor.org/info/rfc2309>.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，and L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，DOI 10.17487/RFC2309，1998年4月， <http://www.rfc-editor.org/info/rfc2309>.
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, <http://www.rfc-editor.org/info/rfc2488>.
[RFC2488]Allman，M.，Glover，D.，和L.Sanchez，“使用标准机制增强卫星信道上的TCP”，BCP 28，RFC 2488，DOI 10.17487/RFC2488，1999年1月<http://www.rfc-editor.org/info/rfc2488>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<http://www.rfc-editor.org/info/rfc3168>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<http://www.rfc-editor.org/info/rfc3611>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，DOI 10.17487/RFC5348，2008年9月<http://www.rfc-editor.org/info/rfc5348>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 5681，DOI 10.17487/RFC56812009年9月<http://www.rfc-editor.org/info/rfc5681>.
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 2011, <http://www.rfc-editor.org/info/rfc6297>.
[RFC6297]Welzl，M.和D.Ros，“低于最大努力传输协议的调查”，RFC 6297，DOI 10.17487/RFC6297，2011年6月<http://www.rfc-editor.org/info/rfc6297>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 6817，DOI 10.17487/RFC6817，2012年12月<http://www.rfc-editor.org/info/rfc6817>.
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141, February 2014, <http://www.rfc-editor.org/info/rfc7141>.
[RFC7141]Briscoe，B.和J.Way，“字节和数据包拥塞通知”，BCP 41，RFC 7141，DOI 10.17487/RFC7141，2014年2月<http://www.rfc-editor.org/info/rfc7141>.
[TCPEVAL] Hayes, D., Ros, D., Andrew, L., and S. Floyd, "Common TCP Evaluation Suite", Work in Progress, draft-irtf-iccrg-tcpeval-01, July 2014.
[TCPEVAL]Hayes，D.，Ros，D.，Andrew，L.，和S.Floyd，“通用TCP评估套件”，正在进行的工作，草稿-irtf-iccrg-TCPEVAL-012014年7月。
[TRAN2014] Trang, S., Kuhn, N., Lochin, E., Baudoin, C., Dubois, E., and P. Gelard, "On The Existence Of Optimal LEDBAT Parameters", IEEE ICC 2014 - Communication QoS, Reliability and Modeling Symposium, DOI 10.1109/ICC.2014.6883487, 2014, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=6883487>.
[TRAN2014]Trang，S.，Kuhn，N.，Lochin，E.，Baudoin，C.，Dubois，E.，和P.Gelard，“关于最优LEDBAT参数的存在”，IEEE ICC 2014-通信QoS，可靠性和建模研讨会，DOI 10.1109/ICC.2014.6883487，2014<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=6883487>。
[WELZ2015] Welzl, M. and G. Fairhurst, "The Benefits to Applications of using Explicit Congestion Notification (ECN)", Work in Progress, draft-welzl-ecn-benefits-02, March 2015.
[WELZ2015]Welzl，M.和G.Fairhurst，“使用显式拥塞通知（ECN）对应用程序的好处”，正在进行的工作，草稿-Welzl-ECN-Benefits-022015年3月。
[WINS2014] Winstein, K., "Transport Architectures for an Evolving Internet", PhD thesis, Massachusetts Institute of Technology, June 2014.
[WINS2014]Winstein，K.，“不断发展的互联网的传输架构”，麻省理工学院博士论文，2014年6月。
Acknowledgements
致谢
This work has been partially supported by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700).
欧洲共同体第七个框架方案通过减少互联网传输延迟（RITE）项目（ICT-317700）部分支持了这项工作。
Many thanks to S. Akhtar, A.B. Bagayoko, F. Baker, R. Bless, D. Collier-Brown, G. Fairhurst, J. Gettys, P. Goltsman, T. Hoiland-Jorgensen, K. Kilkki, C. Kulatunga, W. Lautenschlager, A.C. Morton, R. Pan, G. Skinner, D. Taht, and M. Welzl for detailed and wise feedback on this document.
非常感谢S.Akhtar、A.B.Bagayoko、F.Baker、R.Bless、D.Collier Brown、G.Fairhurst、J.Gettys、P.Goltsman、T.Hoiland Jorgensen、K.Kilkki、C.Kulatunga、W.Lautenschlager、A.C.Morton、R.Pan、G.Skinner、D.Taht和M.Welzl对本文件的详细而明智的反馈。
Authors' Addresses
作者地址
Nicolas Kuhn (editor) CNES, Telecom Bretagne 18 avenue Edouard Belin Toulouse 31400 France
Nicolas Kuhn（编辑）法国国家广播公司，法国杜卢兹爱德华贝林大道18号布雷塔尼电信31400
Phone: +33 5 61 27 32 13
Email: nicolas.kuhn@cnes.fr
Phone: +33 5 61 27 32 13
Email: nicolas.kuhn@cnes.fr
Preethi Natarajan (editor) Cisco Systems 510 McCarthy Blvd Milpitas, California United States of America
Preethi Natarajan（编辑）思科系统公司美国加利福尼亚州米尔皮塔斯麦卡锡大道510号
Email: prenatar@cisco.com
Email: prenatar@cisco.com
Naeem Khademi (editor) University of Oslo Department of Informatics, PO Box 1080 Blindern N-0316 Oslo Norway
Naeem Khademi（编辑）奥斯陆大学信息系，奥斯陆1080挪威
Phone: +47 2285 24 93
Email: naeemk@ifi.uio.no
Phone: +47 2285 24 93
Email: naeemk@ifi.uio.no
David Ros Simula Research Laboratory AS P.O. Box 134 Lysaker, 1325 Norway
David Ros Simula研究实验室，地址：挪威莱萨克134号邮政信箱
Phone: +33 299 25 21 21
Email: dros@simula.no
Phone: +33 299 25 21 21
Email: dros@simula.no