Internet Engineering Task Force (IETF) M. Mathis
Request for Comments: 7713 Google, Inc.
Category: Informational B. Briscoe
ISSN: 2070-1721 BT
December 2015
Internet Engineering Task Force (IETF) M. Mathis
Request for Comments: 7713 Google, Inc.
Category: Informational B. Briscoe
ISSN: 2070-1721 BT
December 2015
Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements
拥塞暴露（ConEx）概念、抽象机制和要求
Abstract
摘要
This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.
本文档描述了一种抽象机制，发送方通过该机制将同一流中的数据包最近遇到的拥塞通知网络。今天，任何层的网络元件都可以通过丢弃分组或通过显式拥塞通知（ECN）标记向接收器发送拥塞信号，并且接收器在传输层反馈中将该信息传递回发送者。这里描述的机制使得发送方也能够在IP层将该拥塞信息中继回带内网络，使得来自路径上的所有元素的拥塞总量被揭示给路径上的所有IP元素，其中它可以例如用于向流量管理提供输入。这种机制称为拥塞暴露（ConEx）。配套文档“拥塞暴露（ConEx）概念和用例”（RFC 6789）提供了ConEx文档集的入口点。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc7713.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7713.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements for the ConEx Abstract Mechanism . . . . . . . . 7
3.1. Requirements for ConEx Signals . . . . . . . . . . . . . 7
3.2. Constraints on the Audit Function . . . . . . . . . . . . 8
3.3. Requirements for Non-abstract ConEx Specifications . . . 9
4. Encoding Congestion Exposure . . . . . . . . . . . . . . . . 12
4.1. Naive Encoding . . . . . . . . . . . . . . . . . . . . . 12
4.2. Null Encoding . . . . . . . . . . . . . . . . . . . . . . 13
4.3. ECN-Based Encoding . . . . . . . . . . . . . . . . . . . 13
4.4. Independent Bits . . . . . . . . . . . . . . . . . . . . 14
4.5. Codepoint Encoding . . . . . . . . . . . . . . . . . . . 14
4.6. Units Implied by an Encoding . . . . . . . . . . . . . . 15
5. Congestion Exposure Components . . . . . . . . . . . . . . . 16
5.1. Network Devices (Not Modified) . . . . . . . . . . . . . 16
5.2. Modified Senders . . . . . . . . . . . . . . . . . . . . 16
5.3. Receivers (Optionally Modified) . . . . . . . . . . . . . 17
5.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Congestion Monitoring Devices . . . . . . . . . . . . 18
5.4.2. Rest-of-Path Congestion Monitoring . . . . . . . . . 18
5.4.3. Congestion Policers . . . . . . . . . . . . . . . . . 18
5.5. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Support for Incremental Deployment . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements for the ConEx Abstract Mechanism . . . . . . . . 7
3.1. Requirements for ConEx Signals . . . . . . . . . . . . . 7
3.2. Constraints on the Audit Function . . . . . . . . . . . . 8
3.3. Requirements for Non-abstract ConEx Specifications . . . 9
4. Encoding Congestion Exposure . . . . . . . . . . . . . . . . 12
4.1. Naive Encoding . . . . . . . . . . . . . . . . . . . . . 12
4.2. Null Encoding . . . . . . . . . . . . . . . . . . . . . . 13
4.3. ECN-Based Encoding . . . . . . . . . . . . . . . . . . . 13
4.4. Independent Bits . . . . . . . . . . . . . . . . . . . . 14
4.5. Codepoint Encoding . . . . . . . . . . . . . . . . . . . 14
4.6. Units Implied by an Encoding . . . . . . . . . . . . . . 15
5. Congestion Exposure Components . . . . . . . . . . . . . . . 16
5.1. Network Devices (Not Modified) . . . . . . . . . . . . . 16
5.2. Modified Senders . . . . . . . . . . . . . . . . . . . . 16
5.3. Receivers (Optionally Modified) . . . . . . . . . . . . . 17
5.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Congestion Monitoring Devices . . . . . . . . . . . . 18
5.4.2. Rest-of-Path Congestion Monitoring . . . . . . . . . 18
5.4.3. Congestion Policers . . . . . . . . . . . . . . . . . 18
5.5. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Support for Incremental Deployment . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
This document describes an abstract mechanism by which, to a first approximation, senders inform the network about the congestion encountered by packets earlier in the same flow. It is not a complete protocol specification because it is known that designing an encoding (e.g., packet formats, codepoint allocations, etc.) is likely to entail compromises that preclude some uses of the protocol. The goal of this document is to provide a framework for developing and testing algorithms to evaluate the benefits of the ConEx protocol and to evaluate the consequences of the compromises in various different encoding designs. This document lays out requirements for concrete protocol specifications.
本文档描述了一种抽象机制，通过该机制，发送方可以第一次近似地向网络通知相同流中较早时数据包遇到的拥塞。它不是一个完整的协议规范，因为众所周知，设计编码（例如，数据包格式、码点分配等）可能会带来一些妥协，从而妨碍协议的某些使用。本文件的目标是提供一个开发和测试算法的框架，以评估ConEx协议的好处，并评估各种不同编码设计中妥协的后果。本文件规定了具体协议规范的要求。
A companion document [RFC6789] provides the entry point to the set of ConEx documentation. It outlines concepts that are prerequisites to understanding why ConEx is useful, and it outlines various ways that ConEx might be used.
附带文档[RFC6789]提供了ConEx文档集的入口点。它概述了理解ConEx为何有用的先决条件概念，并概述了使用ConEx的各种方式。
As typical end-to-end transport protocols continually seek out more network capacity, network elements signal whenever congestion results, and the transports are responsible for controlling this network congestion [RFC5681]. The more a transport tries to use capacity that others want to use, the more congestion signals will be attributable to that transport. Likewise, the more transport sessions sustained by a user and the longer the user sustains them, the more congestion signals will be attributable to that user. The goal of ConEx is to ensure that the resulting congestion signals are sufficiently visible and robust, because they are an ideal metric for networks to use as the basis of traffic management or other related functions.
由于典型的端到端传输协议不断寻求更多的网络容量，因此每当出现拥塞时，网络元素就会发出信号，而传输负责控制这种网络拥塞[RFC5681]。一种交通工具越是试图使用其他交通工具想要使用的通行能力，该交通工具发出的拥堵信号就越多。类似地，用户持续的传输会话越多，用户持续的时间越长，该用户发出的拥塞信号就越多。ConEx的目标是确保产生的拥塞信号足够明显和稳健，因为它们是网络用作流量管理或其他相关功能基础的理想指标。
Networks indicate congestion by three possible signals: packet loss, ECN marking, or queueing delay. ECN marking and some packet loss may be the outcome of Active Queue Management (AQM), which the network uses to warn senders to reduce their rates. Packet loss is also the natural consequence of complete exhaustion of a buffer or other network resource. Some experimental transport protocols and TCP variants infer impending congestion from increasing queuing delay. However, delay is too amorphous to use as a congestion metric. In this and other ConEx documents, the term 'congestion signals' is generally used solely for ECN markings and packet losses because they are unambiguous signals of congestion.
网络通过三种可能的信号表示拥塞：数据包丢失、ECN标记或排队延迟。ECN标记和一些数据包丢失可能是主动队列管理（AQM）的结果，网络使用主动队列管理来警告发送方降低速率。数据包丢失也是缓冲区或其他网络资源完全耗尽的自然结果。一些实验性传输协议和TCP变体通过增加排队延迟推断即将发生的拥塞。然而，延迟太不固定，无法用作拥塞度量。在本文件和其他ConEx文件中，“拥塞信号”一词通常仅用于ECN标记和数据包丢失，因为它们是明确的拥塞信号。
In both cases, the congestion signals follow the route indicated in Figure 1. A congested network device sends a signal in the data stream on the forward path to the transport receiver, the receiver passes it back to the sender through transport-level feedback, and the sender makes some congestion control adjustment.
在这两种情况下，拥堵信号都遵循图1所示的路线。拥塞的网络设备通过前向路径将数据流中的信号发送给传输接收器，接收器通过传输级反馈将信号传回发送方，发送方进行一些拥塞控制调整。
This document extends the capabilities of the Internet protocol suite with the addition of a new Congestion Exposure signal. To a first approximation, this signal (also shown in Figure 1) relays the congestion information from the transport sender back through the internetwork layer where it is visible to any interested internetwork-layer devices along the forward path. This document frames the engineering problem of designing the ConEx Signal. The requirements are described in Section 3 and some example encodings are presented in Section 4. Section 5 describes all of the protocol components.
本文档通过添加新的拥塞暴露信号扩展了Internet协议套件的功能。第一个近似值是，该信号（也如图1所示）将来自传输发送方的拥塞信息通过网络层中继回来，在网络层中，任何感兴趣的网络层设备都可以沿着前向路径看到该信息。本文件阐述了设计ConEx信号的工程问题。第3节描述了这些要求，第4节给出了一些示例编码。第5节描述了所有协议组件。
This new signal is expressly designed to support a variety of new policy mechanisms that might be used to instrument, monitor, or manage traffic. The policy devices are not shown in Figure 1 but might be placed anywhere along the forward data path (see Section 5.4).
此新信号专门设计用于支持各种新策略机制，这些机制可用于检测、监控或管理流量。策略设备未显示在图1中，但可以放置在转发数据路径的任何位置（参见第5.4节）。
,---------. ,---------.
|Transport| |Transport|
| Sender | . |Receiver |
| | /|___________________________________________| |
| ,-<---------------Congestion-Feedback-Signals--<--------. |
| | |/ | | |
| | |\ Transport Layer Feedback Flow | | |
| | | \ ___________________________________________| | |
| | | \| | | |
| | | ' ,-----------. . | | |
| | |_____________| |_______________|\ | | |
| | | IP Layer | | Data Flow \ | | |
| | | |(Congested)| \ | | |
| | | | Network |--Congestion-Signals--->-' |
| | | | Device | \| |
| | | | | /| |
| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
| | | | / | |
| |_____________| |_______________ / | |
| | | | |/ | |
`---------' `-----------' ' `---------'
,---------. ,---------.
|Transport| |Transport|
| Sender | . |Receiver |
| | /|___________________________________________| |
| ,-<---------------Congestion-Feedback-Signals--<--------. |
| | |/ | | |
| | |\ Transport Layer Feedback Flow | | |
| | | \ ___________________________________________| | |
| | | \| | | |
| | | ' ,-----------. . | | |
| | |_____________| |_______________|\ | | |
| | | IP Layer | | Data Flow \ | | |
| | | |(Congested)| \ | | |
| | | | Network |--Congestion-Signals--->-' |
| | | | Device | \| |
| | | | | /| |
| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
| | | | / | |
| |_____________| |_______________ / | |
| | | | |/ | |
`---------' `-----------' ' `---------'
Figure 1: The Flow of Congestion and ConEx Signals
图1：拥塞和ConEx信号流
Since the policy devices can affect how traffic is treated, it is assumed that there is an intrinsic motivation for users, applications, or operating systems to understate the congestion that they are causing. Therefore, it is important to be able to audit ConEx Signals and to be able to apply sufficient sanction to discourage cheating of congestion policies. The general approach to auditing is to count signals on the forward path to confirm that there are never fewer ConEx Signals than congestion signals. Many ConEx design constraints come from the need to assure that the audit function is sufficiently robust. The audit function is described in Section 5.5; however, significant portions of this document (and prior research [Refb-dis]) are motivated by issues relating to the audit function and making it robust.
由于策略设备会影响流量的处理方式，因此假设用户、应用程序或操作系统有一种内在动机来低估它们造成的拥塞。因此，重要的是能够审计ConEx信号，并能够实施足够的制裁，以阻止对拥塞策略的欺骗。审计的一般方法是对前向路径上的信号进行计数，以确认ConEx信号绝不少于拥塞信号。许多ConEx设计约束来自于确保审计功能足够稳健的需要。第5.5节描述了审计职能；然而，本文件的重要部分（以及先前的研究[Refb dis]）是由与审计职能相关的问题和使其稳健的问题驱动的。
The congestion and ConEx Signals shown in Figure 1 represent a series of discrete events: ECN marks or lost packets, carried by the forward data stream and fed back into the internetwork layer. The policy and audit functions are most likely to act on the accumulated values of these signals, for which we use the term "volume". For example, "traffic volume" is the total number of bytes delivered optionally over a specified time interval and over some aggregate of traffic (e.g., all traffic from a site), while "loss volume" is the total amount of bytes discarded from some aggregate over an interval. The term "congestion-volume" is defined precisely in [RFC6789]. Note that volume per unit time is average rate.
图1所示的拥塞和ConEx信号表示一系列离散事件：ECN标记或丢失的数据包，由前向数据流携带并反馈回互联网层。政策和审计职能最有可能对这些信号的累积值起作用，我们使用术语“数量”。例如，“traffic volume”是指在指定的时间间隔内和某个流量聚合（例如，来自站点的所有流量）上可选地交付的字节总数，而“loss volume”是指在某个时间间隔内从某个聚合丢弃的字节总数。术语“拥堵量”在[RFC6789]中有明确定义。请注意，单位时间的体积是平均速率。
A design goal of the ConEx protocol is that the important policy mechanisms can be implemented per logical link without per-flow state (see Section 5.4). However, the trade-off is that per-flow state could be needed to audit ConEx Signals (Section 5.5). This is justified in that i) auditing at the edges, with a limited number of flows, enables policy elsewhere, including in the core, without any per-flow state; ii) auditing can use soft flow state, which does not require route pinning.
ConEx协议的一个设计目标是，重要的策略机制可以在每个逻辑链路上实现，而不需要每个流状态（见第5.4节）。然而，折衷是可能需要每个流量状态来审计ConEx信号（第5.5节）。这是合理的，因为i）在边缘进行审计，流量数量有限，可以在其他地方（包括核心）启用策略，而无需任何每个流状态；ii）审计可以使用软流状态，不需要路由固定。
There is a long standing argument over units of congestion: bytes vs packets (see [RFC7141] and its references). Section 4.6 explains why this problem must be addressed carefully. However, this document does not take a strong position on this issue. Nonetheless, it does require that the units of congestion must be an explicitly stated property of any proposed encoding, and the consequences of that design decision must be evaluated along with other aspects of the design.
关于拥塞的单位有一个长期存在的争论：字节与数据包（参见[RFC7141]及其参考文献）。第4.6节解释了为什么必须仔细解决这个问题。然而，本文件在这一问题上的立场并不强硬。尽管如此，它确实要求拥塞单元必须是任何拟议编码的明确规定属性，并且该设计决策的后果必须与设计的其他方面一起评估。
To be successful, the ConEx protocol needs to have the property that the relevant stakeholders each have the incentive to unilaterally start on each stage of partial deployment, which in turn creates
为了取得成功，ConEx协议需要具有相关利益相关者各自有动机在部分部署的每个阶段单方面开始的属性，这反过来会产生
incentives for further deployment. Furthermore, legacy systems that will never be upgraded do not become a barrier to deploying ConEx. Issues relating to partial deployment are described in Section 6.
鼓励进一步部署。此外，永远不会升级的遗留系统不会成为部署ConEx的障碍。第6节描述了与部分部署相关的问题。
Note that ConEx Signals are not intended to be used for fine-grained congestion control. They are anticipated to be most useful at longer time scales and/or at coarser granularity than single microflows. For example, the total congestion caused by a user might serve as an input to higher-level policy or accountability functions designed to create incentives for improving user behavior, such as choosing to send large quantities of data at off-peak times, at lower data rates, or with less aggressive protocols such as Low Extra Delay Background Transport (LEDBAT) [RFC6817]; see [RFC6789].
请注意，ConEx信号不用于细粒度拥塞控制。预计它们在更长的时间尺度和/或比单个微流更粗的粒度上最有用。例如，用户造成的总拥塞可以作为更高级别的策略或责任函数的输入，这些策略或责任函数旨在为改善用户行为创造激励，例如选择在非高峰时间以更低的数据速率发送大量数据，或者使用攻击性较小的协议，如低额外延迟后台传输（LEDBAT）[RFC6817]；见[RFC6789]。
Ultimately, ConEx Signals have the potential to provide a mechanism to regulate global Internet congestion. From the earliest days of research on congestion control, there has been a concern that there is no mechanism to prevent transport designers from incrementally making protocols more aggressive without bound and spiraling to a "tragedy of the commons" Internet congestion collapse. The "TCP friendly" paradigm was created in part to forestall this failure. However, it no longer commands any authority because it has little to say about the Internet of today, which has moved beyond the scaling range of standard TCP. As a consequence, many transports and applications are opening arbitrarily large numbers of connections or using arbitrary levels of aggressiveness. ConEx represents a recognition that the IETF cannot regulate this space directly because it concerns the behaviour of users and applications, not individual transport protocols. Instead, the IETF can give network operators the protocol tools to arbitrate the space themselves with better bulk traffic management. This, in turn, should create incentives for users and designers of applications and of transport protocols to be more mindful about contributing to congestion.
最终，ConEx信号有可能提供一种机制来调节全球互联网拥塞。从最早的拥塞控制研究开始，就有一种担忧，即没有任何机制可以阻止传输设计者在不受约束的情况下，逐步提高协议的攻击性，并最终导致“公地悲剧”互联网拥塞崩溃。“TCP友好”范例的创建部分是为了防止这种失败。然而，它不再拥有任何权威，因为它对今天的互联网几乎没有什么可说的，它已经超越了标准TCP的扩展范围。因此，许多传输和应用程序正在打开任意数量的连接或使用任意级别的攻击性。ConEx代表了一种认识，即IETF不能直接管理该空间，因为它涉及用户和应用程序的行为，而不是单个传输协议。相反，IETF可以为网络运营商提供协议工具，通过更好的批量流量管理自行仲裁空间。反过来，这应该鼓励应用程序和传输协议的用户和设计者更加注意造成拥塞的因素。
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]中所述进行解释。
ConEx Signals in IP packet headers from the sender to the network:
从发送方到网络的IP数据包头中的ConEx信号：
Not-ConEx: The transport (or at least this packet) is not using ConEx.
Not ConEx：传输（或至少此数据包）未使用ConEx。
ConEx-Capable: The transport is using ConEx. This is the opposite of Not-ConEx.
ConEx功能：传输使用ConEx。这与非ConEx相反。
ConEx Signal: A signal in a packet sent by a ConEx-capable transport. It carries at least one of the following signals:
ConEx信号：由具有ConEx功能的传输设备发送的数据包中的信号。它至少携带以下一种信号：
Re-Echo-Loss: The transport has experienced a loss.
重新回波丢失：传输发生丢失。
Re-Echo-ECN: The transport has detected an ECN Congestion Experienced (CE) mark.
重新回显ECN：传输已检测到ECN拥塞（CE）标记。
Credit: The transport is building up credit to signal advance notice of the risk of packets contributing to congestion, in contrast to signalling only after inherently delayed feedback of actual congestion.
信用：与仅在实际拥塞的固有延迟反馈之后才发送信号相比，传输正在建立信用，以提前通知导致拥塞的数据包的风险。
ConEx-Not-Marked: The transport is ConEx-capable but is not signaling Re-Echo-Loss, Re-Echo-ECN, or Credit.
ConEx未标记：传输具有ConEx功能，但未发出重新回波丢失、重新回波ECN或信用的信号。
ConEx-Marked: At least one of Re-Echo-Loss, Re-Echo-ECN, or Credit.
ConEx标记：至少一个重新回波丢失、重新回波ECN或信用。
ConEx-Re-Echo: At least one of Re-Echo-Loss or Re-Echo-ECN.
ConEx重新回波：至少一个重新回波丢失或重新回波ECN。
First-time readers may wish to skim this section, since it is more understandable having read the entire document.
第一次阅读的读者可能希望浏览本节，因为阅读了整个文档后会更容易理解。
Ideally, all the following requirements would be met by a Congestion Exposure Signal:
理想情况下，拥堵暴露信号将满足以下所有要求：
a. The ConEx Signal SHOULD be visible to internetwork-layer devices along the entire path from the transport sender to the transport receiver. Equivalently, it SHOULD be present in the IPv4 or IPv6 header and in the outermost IP header if using IP-in-IP tunneling. It MAY need to be visible if other encapsulating headers are used to interconnect networks. The ConEx Signal SHOULD be immutable once set by the transport sender. A corollary of these requirements is that the chosen ConEx encoding SHOULD pass silently without modification through preexisting networking gear.
a. ConEx信号应在从传输发送方到传输接收方的整个路径上对网络层设备可见。同样，如果在IP隧道中使用IP，则它应该出现在IPv4或IPv6头中，以及最外层的IP头中。如果使用其他封装头互连网络，则可能需要使其可见。一旦由传输发送方设置，ConEx信号应该是不可变的。这些要求的一个推论是，所选择的ConEx编码应该在没有修改的情况下通过预先存在的网络设备进行静默传递。
b. The ConEx Signal SHOULD be useful under only partial deployment. A minimal deployment SHOULD only require changes to transport senders. Furthermore, partial deployment SHOULD create incentives for additional deployment, both in terms of enabling ConEx on more devices and adding richer features to existing devices. Nonetheless, ConEx deployment need never be universal,
b. ConEx信号仅在部分部署情况下有用。最低限度的部署应该只需要更改传输发件人。此外，部分部署应鼓励额外部署，包括在更多设备上启用ConEx和为现有设备添加更丰富的功能。尽管如此，ConEx的部署永远不需要普及，
and it is anticipated that some hosts and some transports may never support the ConEx protocol and some networks may never use the ConEx Signals.
预计一些主机和一些传输可能永远不支持ConEx协议，一些网络可能永远不使用ConEx信号。
c. The ConEx Signal SHOULD be timely. There will be a minimum delay of one RTT and often longer if the transport protocol sends infrequent feedback (consider Real-time Transport Control Protocol (RTCP) [RFC3550] [RFC6679], for example).
c. ConEx信号应及时发出。如果传输协议发送不频繁的反馈（例如，考虑实时传输控制协议（RTCP）[RFC3550][RFC6679]），则最小延迟为一个RTT，并且通常更长。
d. The ConEx Signal SHOULD be accurate and auditable. The general approach for auditing is to observe the volume of congestion signals and ConEx Signals on the forward data path and verify that the ConEx Signals do not underrepresent the congestion signals (see Section 5.5).
d. ConEx信号应准确且可审计。审计的一般方法是观察前向数据路径上的拥塞信号和ConEx信号的数量，并验证ConEx信号不会低估拥塞信号（见第5.5节）。
e. The ConEx Signals for packet loss and ECN marking SHOULD have distinct encodings because they are likely to require different auditing techniques.
e. 用于数据包丢失和ECN标记的ConEx信号应具有不同的编码，因为它们可能需要不同的审计技术。
f. Additionally, there SHOULD be an auditable ConEx Credit signal. A sender can use Credit to indicate potential future congestion, for example, as is often seen during startup. ConEx Credit is intended to overestimate congestion actually experienced across the network.
f. 此外，应该有一个可审计的ConEx信用信号。发送方可以使用信用来指示未来可能出现的拥塞，例如，在启动过程中经常会看到这种情况。ConEx Credit旨在高估整个网络实际经历的拥塞。
It is already known that implementing ConEx Signals is likely to entail some compromises, and therefore, all the requirements above are expressed with the keyword "SHOULD" rather than "MUST". The only mandatory requirement is that a concrete protocol description MUST give sound reasoning if it chooses not to meet some requirement.
众所周知，实施ConEx信号可能会带来一些折衷，因此，上述所有要求都用关键字“应该”而不是“必须”表示。唯一的强制性要求是，如果选择不满足某些要求，则具体的协议描述必须给出合理的推理。
The role of the audit function and constraints on it are described in Section 5.5. There is no intention to standardise the audit function. However, it is necessary to lay down the following normative constraints on audit behaviour so that transport designers will know what to design against and implementers of audit devices will know what pitfalls to avoid:
第5.5节描述了审计职能的作用和约束条件。我们无意将审计职能标准化。然而，有必要对审计行为规定以下规范性约束，以便交通设计师知道应针对什么进行设计，审计设备的实施者知道应避免什么陷阱：
Minimal False Hits: Audit SHOULD introduce minimal false hits for honest flows.
最小错误点击：审计应该为诚实的流引入最小错误点击。
Minimal False Misses: Audit SHOULD quickly detect and sanction dishonest flows, ideally on the first dishonest packet.
最小错误遗漏：审计应快速检测和制裁不诚实的流，最好是在第一个不诚实的数据包上。
Transport Oblivious: Audit SHOULD NOT be designed around one particular rate response, such as any particular TCP congestion control algorithm or one particular resource-sharing regime such as TCP friendliness [RFC5348]. An important goal is to give ingress networks the freedom to unilaterally allow different rate responses to congestion and different resource sharing regimes [Evol_cc] without having to coordinate with other networks over details of individual flow behaviour.
不考虑传输：审计不应围绕一个特定的速率响应进行设计，如任何特定的TCP拥塞控制算法或一个特定的资源共享机制，如TCP友好性[RFC5348]。一个重要的目标是让入口网络可以自由地单方面允许对拥塞和不同的资源共享机制做出不同的速率响应[Evol_cc]，而无需与其他网络就单个流量行为的细节进行协调。
Sufficient Sanction: Audit SHOULD introduce sufficient sanction (e.g., loss in goodput) such that senders cannot gain from understating congestion.
足够的制裁：审计应引入足够的制裁（例如，goodput中的损失），使发送方无法从低估拥塞中获益。
Proportionate Sanction: To the extent that the audit might be subject to false hits, the sanction SHOULD be proportionate to the degree to which congestion is understated. If the audit over-punishes, attackers will find ways to harness it into amplifying attacks on others. Ideally the audit should, in the long run, cause the user to get no better performance than they would get by being accurate.
比例制裁：在审计可能受到错误点击的程度上，制裁应与低估的拥挤程度成比例。如果审计惩罚过度，攻击者将找到方法利用审计来放大对他人的攻击。理想情况下，从长远来看，审计应该不会让用户获得比准确审计更好的性能。
Manage Memory Exhaustion: Audit SHOULD be able to counter state-exhaustion attacks. For instance, if the audit function uses flow state, it should not be possible for senders to exhaust its memory capacity by gratuitously sending numerous packets, each with a different flow ID.
管理内存耗尽：Audit应该能够对抗状态耗尽攻击。例如，如果审计函数使用流状态，发送方不可能通过无偿发送多个数据包（每个数据包具有不同的流ID）来耗尽其内存容量。
Identifier Accountability: Audit SHOULD NOT be vulnerable to 'identity whitewashing', where a transport can label a flow with a new ID more cheaply than paying the cost of continuing to use its current ID [CheapPseud].
标识符责任：审计不应容易受到“身份粉饰”的影响，在这种情况下，传输使用新ID标记流的成本比继续使用其当前ID[CheapPseud]的成本更低。
An experimental ConEx specification SHOULD describe the following protocol details:
实验性ConEx规范应描述以下协议细节：
Network Layer:
网络层：
A. the specific ConEx Signal encodings with packet formats, bit fields, and/or codepoints;
A.具有分组格式、位字段和/或码点的特定ConEx信号编码；
B. an inventory of invalid combinations of flags or invalid codepoints in the encoding, as well as whether security gateways should normalise, discard, or ignore such invalid encodings, and what values they should be considered equivalent to by ConEx-aware elements;
B.编码中标志或无效代码点的无效组合清单，以及安全网关是否应正常化、丢弃或忽略此类无效编码，以及ConEx感知元素应将其视为等同于哪些值；
C. an inventory of any conflated signals or any other effects that are known to compromise signal integrity;
C.任何合并信号或已知会损害信号完整性的任何其他影响的清单；
D. whether the source is responsible for allowing for the round-trip delay in ConEx Signals (e.g., using a Credit marking), and if so, whether Credit is maintained for the duration of a flow or degrades over time, and what defines the end of the duration of a flow;
D.来源是否负责允许ConEx信号中的往返延迟（例如，使用信用标记），如果是，信用是否在流量持续时间内保持或随时间降低，以及什么定义流量持续时间的结束；
E. a specification for signal units (bytes vs. packets, etc.), any approximations allowed, and the algorithms to do any implied conversions or accounting;
E.信号单位规范（字节与数据包等）、允许的任何近似值以及进行任何隐含转换或记帐的算法；
F. if the units are bytes, a definition of which headers are included in the size of the packet;
F.如果单位为字节，则定义数据包的大小中包含哪些报头；
G. how tunnels should propagate the ConEx encoding;
G.隧道应如何传播ConEx编码；
H. whether the encoding fields are mutable or not, to ensure that header authentication, checksum calculation, etc., process them correctly; a ConEx encoding field SHOULD be immutable end-to-end, then endpoints can detect if it has been tampered with in transit;
H.编码字段是否可变，以确保报头认证、校验和计算等正确处理；ConEx编码字段应该是不可变的端到端，然后端点可以检测它是否在传输过程中被篡改；
I. if a specific encoding allows mutability (e.g., at proxies),
then an inventory of invalid transitions between codepoints;
in all encodings, transitions from any ConEx marking to Not-
ConEx MUST be invalid;
I. if a specific encoding allows mutability (e.g., at proxies),
then an inventory of invalid transitions between codepoints;
in all encodings, transitions from any ConEx marking to Not-
ConEx MUST be invalid;
J. a statement that the ConEx encoding is only applicable to unicast and anycast and that forwarding elements should silently ignore any ConEx signalling on multicast packets (they should be forwarded unchanged);
J.ConEx编码仅适用于单播和选播的声明，转发元素应默默忽略多播数据包上的任何ConEx信令（它们应不加更改地转发）；
K. the definition of any extensibility;
K.任何可扩展性的定义；
L. backward and forward compatibility and potential migration strategies; in all cases, a ConEx encoding MUST be arranged so that legacy transport senders implicitly send Not-ConEx;
L.前后兼容和潜在迁移策略；在所有情况下，必须安排ConEx编码，以便传统传输发送方隐式发送而不是ConEx；
M. any (optional) modification to data-plane forwarding dependent on the encoding (e.g., preferential discard, interaction with Diffserv, ECN, etc.); and
M.根据编码对数据平面转发进行的任何（可选）修改（例如，优先丢弃、与Diffserv、ECN的交互等）；和
N. any warning or error messages relevant to the encoding.
N.与编码相关的任何警告或错误消息。
Note regarding item J on multicast: A multicast tree may involve different levels of congestion on each leg. Any traffic management can only monitor or control multicast congestion at or near each receiver. It would make no sense for the sender to try to expose "whole-path congestion" in sent packets because it cannot hope to describe all the differing congestion levels on every leg of the tree.
关于多播上的项目J的注意：多播树可能在每个分支上涉及不同程度的拥塞。任何流量管理只能监视或控制每个接收器处或附近的多播拥塞。发送方试图在发送的数据包中暴露“全路径拥塞”是没有意义的，因为它不能希望描述树的每一段上所有不同的拥塞级别。
Transport Layer:
传输层：
A. a specification of any required changes to congestion feedback in particular transport protocols;
A.特定传输协议中拥塞反馈的任何所需更改的规范；
B. a specification (or, minimally, a recommendation) for how a transport should estimate credits at the beginning of a connection and while it is in progress;
B.一份规范（或最低限度的建议），说明在连接开始时和连接进行中，运输应如何估计信用；
C. a specification of whether any other protocol options should (or must) be enabled along with an implementation of ConEx (e.g., at least attempting to negotiate ECN and Selective Acknowledgement (SACK) capability);
C.关于是否应（或必须）在实施ConEx的同时启用任何其他协议选项的规范（例如，至少尝试协商ECN和选择性确认（SACK）能力）；
D. a specification of any configuration that a ConEx stack may require (or, preferably, confirmation that it requires no configuration); and
D.ConEx堆栈可能需要的任何配置规范（或者，最好是确认其不需要配置）；和
E. a specification of the statistics that a protocol stack should log for each type of marking on a per-flow or aggregate basis.
E.协议栈应在每个流或聚合基础上记录每种类型标记的统计信息规范。
Security:
安全：
A. an example of a strong audit algorithm suitable for detecting if a single flow is misstating congestion; this algorithm should present minimal false results but need not have optimal scaling properties (e.g., may need per-flow state).
A.适用于检测单个流是否误报拥塞的强审计算法示例；该算法应提供最小的错误结果，但不需要具有最佳缩放特性（例如，可能需要每个流状态）。
B. an example of an audit algorithm suitable for detecting misstated congestion in a large aggregate (e.g., no per-flow state).
B.一种审计算法的示例，适用于检测大聚合中的误报拥塞（例如，每个流状态都没有）。
C. a definition of the level of ConEx-Re-Echo and ConEx-Credit signals that will be sufficient to pass audit (see Section 5.5).
C.定义足以通过审计的ConEx重新回波和ConEx信用信号的级别（见第5.5节）。
The possibility exists that these specifications overconstrain the ConEx design and can not be fully satisfied. An important part of the evaluation of any particular design will be a thorough inventory of all ways in which it might fail to satisfy these specifications.
这些规范可能过度约束了ConEx设计，无法完全满足。对任何特定设计进行评估的一个重要部分是对其可能无法满足这些规范的所有方式进行彻底清查。
Most protocol specifications start with a description of packet formats and codepoints with their associated meanings. This document does not: It is already known that choosing the encoding for ConEx is likely to entail some engineering compromises that have the potential to reduce the protocol's usefulness in some settings. For instance, the experimental ConEx encoding chosen for IPv6 [CONEX-DESTOPT] had to make compromises on tunnelling. Rather than making these engineering choices prematurely, this document sidesteps the encoding problem by making it abstract. It describes several different representations of ConEx Signals, none of which are specified to the level of specific bits or codepoints.
大多数协议规范都从数据包格式和代码点及其相关含义的描述开始。本文件没有：众所周知，选择ConEx编码可能会带来一些工程上的折衷，在某些情况下可能会降低协议的实用性。例如，为IPv6选择的实验性ConEx编码[ConEx-DESTOPT]必须在隧道上做出妥协。本文档没有过早地做出这些工程选择，而是通过将其抽象化来回避编码问题。它描述了ConEx信号的几种不同表示形式，其中没有一种指定为特定位或码点的级别。
The goal of this approach is to be as complete as possible for discovering the potential usage and capabilities of the ConEx protocol, so we have some hope of making optimal design decisions when choosing the encoding. Even if experiments reveal particular problems due to the encoding, then this document will still serve as a reference model.
该方法的目标是尽可能完整地发现ConEx协议的潜在用途和功能，因此我们有希望在选择编码时做出最佳设计决策。即使实验揭示了由于编码而产生的特殊问题，那么本文仍然可以作为参考模型。
For tutorial purposes, it is helpful to describe a naive encoding of the ConEx protocol for TCP and similar protocols: set a bit (not specified here) in the IP header on each retransmission and on each ECN-signalled window reduction. Network devices along the forward path can see this bit and act on it. For example, any device along the path might limit the rate of all traffic if the rate of marked (congested) packets exceeds a threshold.
出于教程目的，有助于描述TCP和类似协议的ConEx协议的原始编码：在每次重传和每次ECN信号窗口缩减时在IP报头中设置一个位（此处未指定）。沿转发路径的网络设备可以看到该位并对其进行操作。例如，如果标记（拥塞）数据包的速率超过阈值，则路径上的任何设备都可能限制所有流量的速率。
This simple encoding is sufficient to illustrate many of the benefits envisioned for ConEx. At first glance, it looks like it might motivate people to deploy and use it. It is a one-line code change that a small number of OS developers and content providers could unilaterally deploy across a significant fraction of all Internet traffic. However, this encoding does not support auditing so it would also motivate users and/or applications to misrepresent the congestion that they are causing [RFC3514]. As a consequence, the naive encoding is not likely to be trusted and thus creates its own disincentives for deployment.
这种简单的编码足以说明ConEx的许多好处。乍一看，它似乎可以激励人们部署和使用它。这是一个单行代码更改，少数操作系统开发人员和内容提供商可以在所有互联网流量的很大一部分中单方面部署。然而，这种编码不支持审计，因此它也会激励用户和/或应用程序误报他们造成的拥塞[RFC3514]。因此，朴素的编码不太可能被信任，因此会对部署产生不利影响。
Nonetheless, this Naive encoding does present a clear mental model of how the ConEx protocol might function under various uses. It is useful for thought experiments where it can be stipulated that all participants are honest and it does illustrate some of the incentives that might be introduced by ConEx.
尽管如此，这种幼稚的编码确实为ConEx协议在各种用途下的功能提供了一个清晰的心智模型。这对于可以规定所有参与者都是诚实的思维实验是有用的，并且它确实说明了ConEx可能引入的一些激励。
In limited contexts, it is possible to implement ConEx-like functions without any signals at all by measuring rest-of-path congestion directly from TCP headers. The algorithm is to keep at least one RTT of past TCP headers and match each new header against the history to count duplicate data.
在有限的上下文中，通过直接从TCP头测量剩余的路径拥塞，可以在没有任何信号的情况下实现类似ConEx的函数。该算法至少保留一个过去TCP报头的RTT，并将每个新报头与历史相匹配，以统计重复数据。
This could implement many ConEx policies, without any explicit protocol. It is fairly easy to implement, at least at low rate (e.g., in a software-based edge router). However, it would only be useful in cases where the network operator can see the TCP headers. At the time of writing (2014), those cases are the majority of traffic because UDP, IPsec, and VPN tunnels are used far less than Secure Socket Layer (SSL) or Transport Layer Security (TLS) over TCP/IP, which do not hide TCP sequence numbers from network devices. However, anyone specifically intending to avoid the attention of a congestion policy device would only have to hide their TCP headers from the network operator (e.g., by using a VPN tunnel).
这可以实现许多ConEx策略，而无需任何明确的协议。它相当容易实现，至少在低速率下（例如，在基于软件的边缘路由器中）。但是，它仅在网络运营商可以看到TCP头的情况下才有用。在撰写本文时（2014年），这些情况占流量的大多数，因为UDP、IPsec和VPN隧道的使用远远少于TCP/IP上的安全套接字层（SSL）或传输层安全性（TLS），后者不会对网络设备隐藏TCP序列号。但是，任何人只要对网络运营商隐藏他们的TCP报头（例如，通过使用VPN隧道），就可以避免拥塞策略设备的注意。
The re-ECN specification [RE-ECN-TCP] presents an encoding of ConEx in IPv4 and IPv6 that was tightly integrated with ECN encoding in order to fit into the IPv4 header. Any individual packet may need to represent any ECN codepoint and any ConEx Signal value independently. So, ideally, their encoding should be entirely independent. However, given the limited number of header bits and/or codepoints, re-ECN chooses to partially share codepoints and to re-echo both losses and ECN with just one codepoint.
re ECN规范[re-ECN-TCP]介绍了IPv4和IPv6中的ConEx编码，该编码与ECN编码紧密集成，以适合IPv4报头。任何单个数据包可能需要独立地表示任何ECN码点和任何ConEx信号值。因此，理想情况下，它们的编码应该是完全独立的。然而，鉴于报头比特和/或码点的数量有限，re-ECN选择部分共享码点，并仅使用一个码点来重新回波丢失和ECN。
The central theme of the re-ECN work is an audit mechanism that provides sufficient disincentives against misrepresenting congestion [RE-ECN-MOTIVATION]. It is analyzed extensively in Briscoe's PhD dissertation [Refb-dis]. For a tutorial background on re-ECN motivation and techniques, see [Re-fb] and [FairerFaster].
re-ECN工作的中心主题是一个审计机制，该机制提供足够的抑制措施，防止误报拥塞[re-ECN-MOTIVATION]。布里斯科博士论文[Refb dis]对此进行了广泛分析。有关re ECN动机和技术的教程背景，请参阅[re fb]和[FairerFaster]。
Re-ECN is an example of one chosen set of compromises attempting to meet the requirements of Section 3. The present document takes a step back, aiming to state the ideal requirements in order to allow the Internet community to assess whether different compromises might be better.
Re ECN是一组选择的折衷方案的示例，试图满足第3节的要求。本文件后退一步，旨在说明理想的要求，以便让互联网社区评估不同的折衷方案是否更好。
The problem with re-ECN is that it requires that receivers be ECN enabled in addition to sender changes. Newer encodings [CONEX-DESTOPT] overcome this problem by being able to represent loss and ECN-based congestion separately.
re ECN的问题在于，除了发送方更改外，还需要启用接收方ECN。较新的编码[CONEX-DESTOP]能够分别表示丢失和基于ECN的拥塞，从而克服了这个问题。
This encoding involves flag bits, each of which the sender can set independently to indicate to the network one of the following four signals:
该编码涉及标志位，发送方可独立设置每个标志位，以向网络指示以下四个信号之一：
ConEx (Not-ConEx): The transport is (or is not) using ConEx with this packet (network-layer encoding requirement L in Section 3.3 says the protocol must be arranged so that legacy transport senders implicitly send Not-ConEx).
ConEx（非ConEx）：传输使用（或未使用）此数据包的ConEx（第3.3节中的网络层编码要求L表示，协议的安排必须确保传统传输发送方隐式发送非ConEx）。
Re-Echo-Loss (Not-Re-Echo-Loss): The transport has (or has not) experienced a loss.
重新回波丢失（非重新回波丢失）：传输已（或未）经历丢失。
Re-Echo-ECN (Not-Re-Echo-ECN): The transport has (or has not) experienced ECN-signalled congestion.
重新回显ECN（非重新回显ECN）：传输已（或未）经历ECN信号拥塞。
Credit (Not-Credit): The transport is (or is not) building up congestion credit (see Section 5.5 on the audit function).
信用（非信用）：交通正在（或没有）建立拥堵信用（见第5.5节“审计功能”）。
A packet with ConEx set, combined with all the three other flags cleared, implies ConEx-Not-Marked.
设置了ConEx的数据包，再加上清除的所有其他三个标志，意味着ConEx未标记。
This encoding does not imply any exclusion property among the signals. Multiple types of congestion (ECN, loss) can be signalled on the same ACK. So, ideally, a ConEx sender would be able to reflect these in the next packet. However, there will be many invalid combinations of flags (e.g., Not-ConEx combined with any of the ConEx-Marked flags), which a malicious sender could use to advantage against naive policy devices that only check each flag separately.
这种编码并不意味着信号之间存在任何排除特性。在同一个ACK上可以发出多种类型的拥塞（ECN、丢失）信号。因此，理想情况下，ConEx发送方能够在下一个数据包中反映这些信息。但是，将存在许多无效的标志组合（例如，未将ConEx与任何ConEx标记的标志组合），恶意发送方可利用这些组合来对抗仅单独检查每个标志的幼稚策略设备。
As long as the packets in a flow have uniform sizes, it does not matter whether the units of congestion are packets or bytes. However, if an application sends very irregular packet sizes, it may be necessary for the sender to mark multiple packets to avoid being in technical violation of an audit function measuring in bytes (see Section 4.6).
只要流中的数据包大小一致，拥塞的单位是数据包还是字节就无关紧要。但是，如果应用程序发送的数据包大小非常不规则，则发送方可能需要标记多个数据包，以避免在技术上违反以字节为单位的审核功能（参见第4.6节）。
This encoding involves signaling one of the following five codepoints:
此编码涉及向以下五个代码点之一发送信号：
ENUM {Not-ConEx, ConEx-Not-Marked, Re-Echo-Loss, Re-Echo-ECN, Credit}
枚举{Not ConEx，ConEx未标记，重新回显丢失，重新回显ECN，信用}
Each named codepoint has the same meaning as in the encoding using independent bits in the previous section. The use of any one codepoint implies the negative of all the others.
每个命名码点的含义与上一节中使用独立位进行编码时的含义相同。任何一个代码点的使用都意味着所有其他代码点的否定。
Inherently, the semantics of most of the enumerated codepoints are mutually exclusive. 'Credit' is the only one that might need to be used in combination with either Re-Echo-Loss or Re-Echo-ECN, but even that requirement is questionable. It must not be forgotten that the enumerated encoding loses the flexibility to signal these two combinations, whereas the encoding with four independent bits is not so limited. Alternatively, two extra codepoints could be assigned to these two combinations of semantics. The comment in the previous section about units also applies.
本质上，大多数枚举代码点的语义是相互排斥的。”“信用”是唯一一个可能需要与重新回波丢失或重新回波ECN结合使用的信用，但即使是这一要求也值得怀疑。不可忘记，枚举编码失去了向这两种组合发送信号的灵活性，而使用四个独立位的编码则没有这样的限制。或者，可以为这两种语义组合分配两个额外的代码点。上一节中有关单位的评论也适用。
The following comments apply generally to all the other encodings.
以下注释通常适用于所有其他编码。
Congestion can be due to exhaustion of bit-carrying capacity or exhaustion of packet-processing power. When a packet is discarded or marked to indicate congestion, there is no easy way to know whether the lost or marked packet signifies bit congestion or packet congestion. The above ConEx encodings that rely on marking packets suffer from the same ambiguity.
拥塞可能是由于比特承载能力耗尽或数据包处理能力耗尽所致。当一个数据包被丢弃或标记以表示拥塞时，没有简单的方法知道丢失或标记的数据包是表示比特拥塞还是表示数据包拥塞。上述依赖于标记数据包的ConEx编码也存在同样的歧义。
This problem is most acute when audit needs to check that one count of markings matches another. For example, if there are ConEx markings on three large (1500 B) packets, is that sufficient to match the loss of five small (60 B) packets? If a packet marking is defined to mean all the bytes in the packet are marked, then we have 4500 B of ConEx-Marked data against 300 B of lost data, which is easily sufficient. If instead we are counting packets, then we have three ConEx packets against five lost packets, which is not sufficient. This problem will not arise when all the packets in a flow are the same size, but a choice needs to be made for flows in which packet sizes vary, such as BGP, SPDY, and some variable-rate video encoding schemes.
当审计需要检查一个标记计数是否与另一个匹配时，这个问题最为严重。例如，如果三个大（1500 B）数据包上有ConEx标记，是否足以匹配五个小（60 B）数据包的丢失？如果包标记被定义为意味着包中的所有字节都被标记，那么我们有4500 B的ConEx标记数据和300 B的丢失数据，这很容易就足够了。相反，如果我们计算数据包，那么我们有三个ConEx数据包和五个丢失的数据包，这是不够的。当一个流中的所有数据包大小相同时，不会出现此问题，但需要选择数据包大小不同的流，例如BGP、SPDY和一些可变速率视频编码方案。
Whether to use bytes or packets is not obvious. For instance, the most expensive links in the Internet, in terms of cost per bit, are all at lower data rates, where transmission times are large and packet sizes are important. In order for a policy to consider wire time, it needs to know the number of congested bytes. However, high speed networking equipment and the transport protocols themselves sometimes gauge resource consumption and congestion in terms of packets.
是否使用字节或数据包并不明显。例如，就每比特成本而言，互联网上最昂贵的链路都是较低的数据速率，传输时间较长，数据包大小很重要。为了考虑考虑有线时间的策略，需要知道拥塞的字节数。然而，高速网络设备和传输协议本身有时会根据数据包来衡量资源消耗和拥塞。
[RFC7141] advises that congestion indications should be interpreted in units of bytes when responding to congestion, at least on today's Internet. [RFC6789] takes the same view in its definition of congestion-volume, again, for today's Internet.
[RFC7141]建议在响应拥塞时，至少在当今的互联网上，拥塞指示应以字节为单位进行解释。[RFC6789]对当今互联网的拥塞量的定义也持相同观点。
In any TCP implementation, this is simple to achieve for varying size packets given that TCP SACK tracks losses in bytes. If an encoding is specified in units of bytes, the encoding should also specify which headers to include in the size of a packet (see network-layer requirement F in Section 3.3).
在任何TCP实现中，如果TCP SACK以字节为单位跟踪丢失，那么对于不同大小的数据包，这是很容易实现的。如果以字节为单位指定编码，则编码还应指定在数据包大小中包含哪些头（参见第3.3节中的网络层要求F）。
RFC 7141 constructs an argument for why equipment tends to be built so that the bottleneck will be the bit-carrying capacity of its interfaces, not its packet-processing capacity. However, RFC 7141 acknowledges that the position may change in future and notes that new techniques will need to be developed to distinguish packet and bit congestion.
RFC 7141构建了一个论点，说明为什么设备倾向于建造成瓶颈是其接口的比特承载能力，而不是其数据包处理能力。然而，RFC 7141承认未来位置可能会改变，并指出需要开发新技术来区分分组和比特拥塞。
Given this document describes an abstract ConEx mechanism, it is intended to be timeless. Therefore, it does not take a strong position on this issue. However, a ConEx encoding will need to explicitly specify whether it assumes units of bytes or packets consistently for both congestion indications and ConEx markings (see network-layer requirement E in Section 3.3). It may help to refer to the guidance in [RFC7141].
鉴于本文档描述了一种抽象的ConEx机制，因此它是永恒的。因此，它在这个问题上没有采取强硬立场。然而，ConEx编码需要明确规定其是否假定拥塞指示和ConEx标记的字节或数据包单位一致（见第3.3节中的网络层要求E）。参考[RFC7141]中的指南可能会有所帮助。
The components shown in Figure 1 as well as policy and audit are described in more detail.
图1中所示的组件以及策略和审计将得到更详细的描述。
Congestion signals originate from network devices as they do today. A congested router, switch, or other network device can discard or ECN-mark packets when it is congested.
拥塞信号像今天一样来自网络设备。拥塞的路由器、交换机或其他网络设备在拥塞时可以丢弃或ECN标记数据包。
The sending transport needs to be modified to send Congestion Exposure signals in response to congestion feedback signals (e.g., for the case of a TCP transport, see [TCP-MODIFICATION]). We want to permit ConEx without ECN (e.g., if the receiver does not support ECN). However, we want to encourage a ConEx sender to at least attempt to negotiate ECN (a ConEx transport protocol specification may require this) because it is believed that ConEx without ECN is harder to audit and thus potentially exposed to cheating. Since honest users have the potential to benefit from stronger mechanisms
需要修改发送传输以发送拥塞暴露信号，以响应拥塞反馈信号（例如，对于TCP传输的情况，请参阅[TCP-MODIFICATION]）。我们希望允许ConEx不带ECN（例如，如果接收器不支持ECN）。然而，我们希望鼓励ConEx发送方至少尝试协商ECN（ConEx传输协议规范可能需要协商ECN），因为据信，没有ECN的ConEx更难审计，因此可能会受到欺骗。因为诚实的用户有可能从更强大的机制中获益
to manage traffic, they have an incentive to deploy ConEx and ECN together. This incentive is not sufficient to prevent a dishonest user from constructing (or configuring) a sender that enables ConEx after choosing not to negotiate ECN, but it should be sufficient to prevent this from being the sustained default case for any significant pool of users.
为了管理流量，他们有动力一起部署ConEx和ECN。这种激励不足以防止不诚实的用户在选择不协商ECN后构建（或配置）允许ConEx的发送方，但足以防止这成为任何重要用户群的持续默认情况。
Permitting ConEx without ECN is necessary to facilitate bootstrapping other parts of ConEx deployment.
为了便于引导ConEx部署的其他部分，有必要在没有ECN的情况下允许ConEx。
Any receiving transport may already feedback sufficiently useful signals to the sender so that it does not need to be altered.
任何接收传输可能已经将足够有用的信号反馈给发送方，因此不需要对其进行更改。
The native loss or ECN signaling mechanism required for compliance with existing congestion control standards (e.g., RTCP, Stream Control Transmission Protocol (SCTP)) will typically be sufficient for the Sender to generate ConEx Signals.
符合现有拥塞控制标准（例如，RTCP、流控制传输协议（SCTP））所需的本机丢失或ECN信令机制通常足以让发送方生成ConEx信号。
TCP's loss feedback is sufficient for ConEx if SACK is used [RFC2018]. However, the original specification for ECN in TCP [RFC3168] signals congestion no more than once per round trip. The sender may require more precise feedback from the receiver otherwise it is at risk of appearing to be understating its ConEx Signals.
如果使用SACK，TCP的丢失反馈对于ConEx来说是足够的[RFC2018]。然而，TCP[RFC3168]中ECN的原始规范在每次往返中发出拥塞信号不超过一次。发送方可能要求接收方提供更精确的反馈，否则可能会出现低估其ConEx信号的风险。
Ideally, ConEx should be added to a transport like TCP without mandatory modifications to the receiver. But in the TCP-ECN case, an optional modification to the receiver could be recommended for precision (see [RFC7560], which is based on the approach originally taken when adding re-ECN to TCP [RE-ECN-TCP]).
理想情况下，ConEx应该添加到像TCP这样的传输中，而不必强制修改接收方。但在TCP-ECN的情况下，可以建议对接收器进行可选的精度修改（参见[RFC7560]，该修改基于最初将re-ECN添加到TCP[re-ECN-TCP]时采用的方法）。
Policy devices are characterised by a need to be configured with a policy related to the users or neighboring networks being served. In contrast, auditing devices solely enforce compliance with the ConEx protocol and do not need to be configured with any client-specific policy.
策略设备的特点是需要配置与所服务的用户或相邻网络相关的策略。相比之下，审计设备仅强制遵守ConEx协议，不需要配置任何特定于客户端的策略。
One of the design goals of the ConEx protocol is that none of the important policy mechanisms requires per-flow state and that policy mechanisms can even be implemented for heavily aggregated traffic in the core of the Internet with complexity akin to accumulating marking volumes per logical link. Of course, policy mechanisms may sometimes choose to focus down on individual flows, but ConEx aims to make aggregate policy devices feasible.
ConEx协议的设计目标之一是，没有任何重要的策略机制需要每个流状态，甚至可以为互联网核心中的高度聚合流量实施策略机制，其复杂性类似于每个逻辑链路累积标记卷。当然，政策机制有时可能会选择将重点放在个别资金流上，但ConEx的目标是使总体政策手段可行。
Policy devices can typically be decomposed into two functions: i) monitoring the ConEx Signal to compare it with a policy; then ii) acting in some way on the result. Various actions might be invoked against 'out of contract' traffic, such as policing (see Section 5.4.3), re-routing, or downgrading the class of service.
策略设备通常可以分解为两个功能：i）监视ConEx信号以将其与策略进行比较；然后ii）以某种方式作用于结果。可能会针对“合同外”流量调用各种操作，例如：维持治安（见第5.4.3节）、重新路由或降低服务级别。
Alternatively, a policy device might not act directly on the traffic, but instead report to management systems that are designed to control congestion indirectly. For instance, the reports might trigger capacity upgrades, penalty clauses in contracts, levy charges based on congestion, or merely send warnings to clients who are causing excessive congestion.
或者，策略设备可能不会直接作用于流量，而是向设计用于间接控制拥塞的管理系统报告。例如，这些报告可能会触发容量升级、合同中的惩罚条款、根据拥堵情况征收费用，或者仅仅向造成过度拥堵的客户发出警告。
Nonetheless, whatever action is invoked, the congestion monitoring function will always be a necessary part of any policy device.
尽管如此，无论调用什么操作，拥塞监控功能始终是任何策略设备的必要部分。
ConEx Signals indicate the level of congestion along a whole path from source to destination. In contrast, ECN signals monitored in the middle of a network indicate the level of congestion experienced so far on the path (of course, only in ECN-capable traffic).
ConEx信号指示从源到目的地的整个路径上的拥挤程度。相反，在网络中间监测的ECN信号指示迄今为止在路径上经历的拥塞程度（当然，仅在ECN有能力的业务中）。
If a monitor in the middle of a network (e.g., at a network border) measures both of these signals, it can subtract the level of ECN (path so far) from the level of ConEx (whole path) to derive a measure of the congestion that packets are likely to experience between the monitoring point and their destination (rest-of-path congestion).
如果在网络中间（例如，在网络边界处）的监视器测量这两个信号，则它可以从CONEX（整个路径）的水平减去ECN（路径）的水平，以获得数据包在监控点和它们的目的地之间可能经历的拥塞（剩余路径拥塞）的度量。
It will often be preferable for policy devices to monitor rest-of-path congestion if they can, because it is a measure of the downstream congestion that the policy device can directly influence by controlling the traffic passing through it.
如果可以的话，策略设备通常最好监控其余的路径拥塞，因为策略设备可以通过控制通过它的流量直接影响下游拥塞的度量。
A congestion policer can be implemented in a very similar way to a bit-rate policer, but its effect can be focused solely on traffic of users causing congestion downstream, which ConEx Signals make visible. Without ConEx Signals, the only way to mitigate congestion is to blindly limit the traffic bit-rate on the assumption that high bit-rate is more likely to cause congestion.
拥塞策略可以以与比特率策略非常相似的方式实现，但其效果可以仅集中在导致下游拥塞的用户流量上，这是ConEx信号所显示的。在没有ConEx信号的情况下，缓解拥塞的唯一方法是在假设高比特率更有可能导致拥塞的情况下，盲目限制流量比特率。
A congestion policer monitors all ConEx traffic entering a network or some identifiable subset. Using ConEx Signals and/or Credit signals (and preferably subtracting ECN signals to yield rest-of-path congestion), it measures the amount of congestion that this traffic is contributing somewhere downstream. If this persistently exceeds a policy-configured 'congestion-bit-rate', the congestion policer can limit all the monitored ConEx traffic.
拥塞策略监控所有进入网络或某个可识别子集的ConEx流量。使用ConEx信号和/或信用信号（最好减去ECN信号以产生剩余的路径拥塞），它测量该流量在下游某处造成的拥塞量。如果持续超过策略配置的“拥塞比特率”，则拥塞策略器可以限制所有受监控的ConEx流量。
A congestion policer can be implemented by a simple token bucket applied to an aggregate. But unlike a bit-rate policer, it removes tokens only when it forwards packets that are ConEx-Marked, effectively treating Not-ConEx-Marked packets as invisible. Consequently, because tokens give the right to send congested bits, the fill rate of the token bucket will represent the allowed congestion-bit-rate. This should provide sufficient traffic management without having to additionally constrain the straight bit-rate at all. See [ISOLATION-POLICING] for details.
拥塞策略可以通过应用于聚合的简单令牌桶来实现。但与比特率策略不同，它仅在转发带有ConEx标记的数据包时才删除令牌，有效地将未带有ConEx标记的数据包视为不可见。因此，由于令牌赋予发送拥塞比特的权利，令牌桶的填充率将表示允许的拥塞比特率。这应该提供足够的流量管理，而不必额外限制直接比特率。有关详细信息，请参见[ISOLATION-POLICING]。
Note that the policing action could be to introduce a throttle (discard some traffic) immediately upstream of the congestion monitor. Alternatively, this throttle could introduce delay using a queue with its own AQM, which potentially increases the whole path congestion. In effect, the congestion policer has moved the congestion earlier in the path and focused it on one user to protect downstream resources by reducing the congestion in the rest of the path.
请注意，监管行动可能是在拥塞监视器的上游立即引入节流阀（丢弃一些流量）。或者，这种节流可能会使用具有自己的AQM的队列引入延迟，这可能会增加整个路径的拥塞。实际上，拥塞策略将拥塞提前转移到路径中，并将其集中在一个用户身上，通过减少路径其余部分的拥塞来保护下游资源。
The most critical aspect of ConEx is the capability to support robust auditing. It can be assumed that sanctions based on ConEx Signals will create an intrinsic motivation for users to understate the congestion that they are causing. So, without strong audit functions, the ConEx Signal would become understated to the point of being useless. Therefore, the most important feature of an encoding design is likely to be the robustness of the auditing it supports.
ConEx最关键的方面是支持稳健审计的能力。可以假设，基于ConEx信号的制裁将产生一种内在动机，让用户低估他们造成的拥堵。因此，如果没有强大的审计功能，ConEx信号将被低估到毫无用处的地步。因此，编码设计最重要的特征可能是它所支持的审计的健壮性。
The general goal of an auditor is to make sure that any ConEx-enabled traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit signals. A concrete definition of the ConEx protocol MUST define what sufficient means.
审核员的总体目标是确保发送任何启用ConEx的流量时带有足够的ConEx重新回送和ConEx信用信号。ConEx协议的具体定义必须定义充分的含义。
If a ConEx-enabled transport does not carry sufficient ConEx Signals, then an auditor is likely to apply some sanction to that traffic. Although sanctions are beyond the scope of this document, an example sanction might be to throttle the traffic immediately upstream of the
如果启用ConEx的传输没有传输足够的ConEx信号，则审计员可能会对该通信量实施一些制裁。虽然制裁不在本文件的范围内，但制裁的一个例子可能是限制网络上游的流量
auditor to prevent the user from getting any advantage by understating congestion. Such a throttle would likely include some combination of delaying or dropping traffic.
审计员通过低估拥塞情况来防止用户获得任何好处。这样的节流可能包括延迟或减少流量的一些组合。
A ConEx auditor might use one of the following techniques:
ConEx审核员可以使用以下技术之一：
Generic loss auditing: For congestion signalled by loss, totally accurate auditing is not believed to be possible in the general case because it involves a network node detecting the absence of some packets when it cannot always necessarily identify retransmissions or missing packets. The missing packet might simply be taking a different route, or the IP payload may be encrypted.
通用丢失审计：对于丢失发出的拥塞信号，一般情况下不可能进行完全准确的审计，因为它涉及到网络节点在无法始终识别重传或丢失的数据包时检测到某些数据包的缺失。丢失的数据包可能只是采用不同的路由，或者IP有效负载可能被加密。
It is for this reason that it is desirable to motivate the deploying of ECN, even though ECN is not strictly required for ConEx.
正是出于这个原因，尽管ConEx并不严格要求ECN，但还是需要激励ECN的部署。
ECN auditing: Directly observe and compare the volume of ECN and ConEx marks. Since the volume of ECN marks rises monotonically along a path, ECN auditing is most accurate when located near the transport receiver. For this reason, ECN should be monitored downstream of the predominant bottleneck.
ECN审计：直接观察和比较ECN和ConEx标记的数量。由于ECN标记的数量沿路径单调增加，因此当位于传输接收器附近时，ECN审核最为准确。因此，应在主要瓶颈的下游监测ECN。
TCP-specific loss auditing: For non-encrypted standard TCP traffic on a single path, a tactical audit approach could be to measure losses by detecting retransmissions, which appear as duplicate sequence numbers upstream of the loss and out of order data downstream of the loss. Since some reordering is present in the Internet, such a loss estimator would be most accurate near the sender. Such an audit device should treat non-ECN-capable packets with encrypted IP payload as Not-ConEx, even if they claim to be ConEx-capable, unless the operator is also using one of the other two techniques below that can audit such packets against losses.
特定于TCP的丢失审计：对于单个路径上的非加密标准TCP流量，战术审计方法可以是通过检测重传来测量丢失，重传在丢失上游显示为重复序列号，在丢失下游显示为无序数据。由于互联网上存在一些重新排序，这样的损失估计在发送方附近最准确。这种审计设备应将具有加密IP有效载荷的不支持ECN的数据包视为非ConEx，即使它们声称具有ConEx能力，除非运营商也在使用下面另外两种技术中的一种来审计这种数据包以防止丢失。
Predominant bottleneck loss auditing: For networks designed so that losses predominantly occur under the control of one IP-aware bottleneck node on the path, the auditor could be located at this bottleneck. It could simply compare ConEx Signals with actual local packet discards (and ECN marks). This is a good model for most consumer access networks where audit accuracy could well be sufficient even if losses occasionally occur elsewhere in the network.
主要瓶颈损失审计：对于设计为主要在路径上的一个IP感知瓶颈节点控制下发生损失的网络，审计人员可以位于该瓶颈处。它可以简单地将ConEx信号与实际的本地数据包丢弃（和ECN标记）进行比较。对于大多数消费者接入网络来说，这是一个很好的模型，即使网络中的其他地方偶尔发生损失，审计的准确性也足以满足要求。
Although the auditor at the predominant bottleneck would not be able to count losses at other nodes, transports would not know where losses were occurring either. Therefore, a transport would
尽管处于主要瓶颈的审核员无法计算其他节点的损失，但传输也不知道损失发生在何处。因此，运输将
not know which losses it could cheat and which ones it couldn't without getting caught.
不知道哪些损失可以被欺骗，哪些损失不可能被抓住。
ECN tunnel loss auditing: A network operator can arrange IP-in-IP tunnels (or IP-in-MPLS, etc.) so that any losses within the tunnels are deferred until the tunnel egress. Then, the audit function can be deployed at the egress and be aware of all losses. This is possible by enabling ECN marking on switches and routers within a tunnel, irrespective of whether end systems support ECN, by exploiting a side effect of the way tunnels handle the ECN field. After encapsulation at the tunnel ingress, the network should arrange for any non-ECN packets (with '00' in the ECN field of the outer) to be set to the ECN-capable transport (ECT(0)) codepoint. Then, if they experience congestion at one of the ECN-capable switches or routers within the tunnel, some will be ECN-marked rather than immediately dropped. However, when the tunnel decapsulator strips the outer from such an ECN-marked packet, if it finds the inner header has '00' in the ECN field (meaning that the endpoints do not support ECN), it will automatically drop the packet, assuming it complies with [RFC6040]. Thus, an audit function at the decapsulator can know which packets would have been dropped within the tunnel (and even which are genuinely ECN-marked for the end-to-end protocol). Non-ECN end systems outside the tunnel see no sign of the use of ECN internally.
ECN隧道损失审计：网络运营商可以在IP隧道中安排IP（或在MPLS中安排IP等），以便将隧道内的任何损失推迟到隧道出口。然后，可以在出口处部署审计功能，并了解所有损失。这可以通过利用隧道处理ECN字段的方式的副作用，在隧道内的交换机和路由器上启用ECN标记，而不管终端系统是否支持ECN。在隧道入口封装后，网络应安排将任何非ECN数据包（外部ECN字段中的“00”）设置为支持ECN的传输（ECT（0））码点。然后，如果它们在隧道内的一个支持ECN的交换机或路由器上遇到拥塞，则一些交换机或路由器将被标记为ECN，而不是立即丢弃。但是，当隧道解封装器从这样一个带有ECN标记的数据包中剥离外部数据包时，如果它发现内部报头在ECN字段中有“00”（意味着端点不支持ECN），它将自动丢弃该数据包，假设它符合[RFC6040]。因此，decapsulator的审计功能可以知道哪些数据包会在隧道中被丢弃（甚至哪些数据包是真正为端到端协议标记的ECN）。隧道外的非ECN端系统未发现内部使用ECN的迹象。
In addition, other audit techniques may be identified in the future.
此外，将来可能会确定其他审计技术。
[Refb-dis] gives a comprehensive inventory of attacks against audit proposed by various people. It includes pseudocode for both deterministic and statistical audit functions designed to thwart these attacks and analyses the effectiveness of an implementation. Although this work is specific to the re-ECN protocol, most of the material is useful for designing and assessing audit of other specific ConEx encodings, against both ECN and loss.
[Refb dis]提供了各种人提出的针对审计的攻击的全面清单。它包括用于确定性和统计审计功能的伪代码，旨在阻止这些攻击，并分析实现的有效性。尽管这项工作是针对re ECN协议的，但大多数材料对于设计和评估针对ECN和损失的其他特定ConEx编码的审计是有用的。
The auditing function should be able to trigger sufficient sanction to discourage understating congestion [Salvatori05]. This seems to require designing the sanction in concert with the policy functions, even though they might be implemented in different parts of the network. However, [Refb-dis] proves audit and policy functions can be independent as long as audit drops sufficient traffic to 'normalise' actual congestion signals to be no greater than ConEx Signals.
审计职能部门应能够触发足够的制裁，以阻止少报拥挤[Salvatory05]。这似乎需要设计与政策职能一致的制裁措施，即使它们可能在网络的不同部分实施。然而，[Refb dis]证明了审计和策略功能可以是独立的，只要审计减少足够的流量，使实际拥塞信号“正常化”为不大于ConEx信号。
Similarly, the job of incentivising the sending of ConEx-enabled packets is proper solely to policy devices independent of the audit function. The audit function's job is policy neutral, so it should be solely confined to checking for correctness within those packets
类似地，激励发送启用ConEx的数据包的工作仅适用于独立于审核功能的策略设备。审计功能的工作与策略无关，因此它应该仅限于检查这些数据包中的正确性
that have been marked as ConEx-capable. Even if there are Not-ConEx packets mixed with ConEx packets within a flow, audit will not need to monitor any Not-ConEx packets.
已标记为具有ConEx能力的。即使流中没有ConEx数据包与ConEx数据包混合，audit也不需要监视任何非ConEx数据包。
Note that in the future it might prove to be desirable to provide advice on uniformly implementing sanctions, because otherwise insufficient sanctions could impair the ability to implement policy elsewhere in the network.
请注意，今后可能需要就统一实施制裁提供咨询意见，因为否则，制裁不足可能会损害网络其他地方实施政策的能力。
Some of the audit algorithms require per-flow state. This cost is expected to be tolerable because these techniques are most apropos near the edges of the network where traffic is generally much less aggregated so the state need not overwhelm any one device. The flow state required for the audit creates itself as it detects new flows. Therefore, a flow will not fail if it is re-routed away from the audit box currently holding its flow state, so auditing does not require route pinning and works fine with multipath flows.
一些审计算法需要每个流状态。这一成本预计是可以容忍的，因为这些技术最适合靠近网络边缘，而网络边缘的流量通常聚合程度较低，因此状态不需要压倒任何一个设备。审计所需的流状态会在检测到新流时自行创建。因此，如果流从当前保持其流状态的审核框中重新路由，则该流不会失败，因此审核不需要路由固定，并且可以很好地处理多路径流。
Holding flow state seems to create a vulnerability to attacks that exhaust the auditor's memory by opening numerous new short flows. The audit function can protect itself from this attack by not allocating new flow state unless a ConEx-Marked packet arrives (e.g., credit at the start of a flow). Because policy devices rate limit ConEx-Marked packets, this sets a natural limit to the rate at which a source can create flow state in audit devices. The auditor would treat all the remaining flows without any ConEx-Marked packets as a single misbehaving aggregate.
保持流状态似乎会创建一个漏洞，以防攻击通过打开大量新的短流耗尽审计员的内存。审计功能可以通过不分配新的流状态来保护自己免受此攻击，除非ConEx标记的数据包到达（例如，流开始时的信用）。因为策略设备限制ConEx标记的数据包的速率，所以这会对源可以在审核设备中创建流状态的速率设置一个自然限制。审计员将把没有任何ConEx标记的数据包的所有剩余流视为一个行为异常的聚合。
Auditing can be distributed and redundant. One flow may be audited in multiple places, using multiple techniques. Some audit techniques do not require any per-flow state and can be applied to aggregate traffic. These might be able to detect the presence of understated congestion at large scale and support recursively hunting for individual flows that are understating their congestion. Even at large scales, flows can be randomly selected for individual auditing.
审计可以是分布式的和冗余的。一个流程可以在多个地方使用多种技术进行审核。有些审计技术不需要任何每流状态，可以应用于聚合流量。这些系统可能能够大规模检测到低估拥塞的存在，并支持递归搜索低估其拥塞的单个流。即使在大范围内，也可以随机选择流进行单独审计。
Sampling techniques can also be used to bound the total auditing memory footprint, although the implementer needs to counter the tactic where a source cheats until caught by sampling, then simply discards that flow ID and starts cheating with a new one (termed 'identifier whitewashing when caught').
采样技术也可以用来限制总的审计内存占用，尽管实现者需要对抗一种策略，即源欺骗直到被采样捕获，然后简单地丢弃该流ID并开始用新ID欺骗（称为“捕获时的标识符粉饰”）。
For the concrete ConEx protocol encoding defined in [CONEX-DESTOPT], ConEx Credit and ConEx-Re-Echo signals are intended to be audited separately. The Credit signal can be audited directly against actual congestion (loss and ECN). However, there will be an inherent delay of at least one round trip between a congestion signal and the subsequent ConEx-Re-Echo signal it triggers, as shown in Figure 1.
对于[ConEx-DESTOP]中定义的具体ConEx协议编码，ConEx信用和ConEx重新回波信号应单独审计。信用信号可以直接根据实际拥挤情况（损失和ECN）进行审核。然而，如图1所示，拥塞信号与随后触发的ConEx重新回波信号之间至少存在一次往返的固有延迟。
Therefore, ConEx-Re-Echo signals will need to be audited with some allowance for this delay. Further discussion of design and implementation choices for functions intended to audit this concrete ConEx encoding can be found in [CONEX-AUDIT].
因此，需要对ConEx重新回波信号进行审计，并考虑到该延迟。有关审计此具体ConEx编码的功能的设计和实现选择的进一步讨论，请参见[ConEx-audit]。
The ConEx abstract protocol described so far is intended to support incremental deployment in every possible respect. For convenience, the following list collects together all the features that support incremental deployment in the concrete ConEx specifications and points to further information on each:
到目前为止所描述的ConEx抽象协议旨在从各个方面支持增量部署。为方便起见，以下列表汇总了具体ConEx规范中支持增量部署的所有功能，并指出了每个功能的更多信息：
Packets: The wire protocol encoding allows each packet to indicate whether it is using ConEx or not (see Section 4 on Encoding Congestion Exposure).
数据包：有线协议编码允许每个数据包指示是否使用ConEx（参见第4节编码拥塞暴露）。
Senders: ConEx requires a modification to the source in order to send ConEx packet markings (see Section 5.2). Although ConEx support can be indicated on a packet-by-packet basis, it is likely that all the packets in a flow will either consistently support ConEx or consistently not. It is also likely that, if the implementation of a transport protocol supports ConEx, all the packets sent from that host using that protocol will be ConEx-Capable.
发送方：ConEx要求修改源，以便发送ConEx数据包标记（见第5.2节）。尽管ConEx支持可以在分组的基础上指示，但是流中的所有分组很可能会一致地支持ConEx或不一致地支持ConEx。如果传输协议的实现支持ConEx，则使用该协议从该主机发送的所有数据包也可能支持ConEx。
The implementations of some of the transport protocols on a host might not support ConEx (e.g., the implementation of DNS over UDP might not support ConEx, while perhaps RTP over UDP and TCP will). Any non-upgraded transports and non-upgraded hosts will simply continue to send regular Not-ConEx packets as always.
主机上某些传输协议的实现可能不支持ConEx（例如，通过UDP实现DNS可能不支持ConEx，而通过UDP和TCP实现RTP可能会支持ConEx）。任何未升级的传输和未升级的主机都将一如既往地继续发送常规Not ConEx数据包。
A network operator can create incentives for senders to voluntarily reveal ConEx information (see the item on incremental deployment by 'Networks' below).
网络运营商可以鼓励发送方自愿披露ConEx信息（请参见下面“网络”增量部署的项目）。
Receivers: A ConEx source should be able to work with the regular receiver for the transport in question without requiring any ConEx-specific modifications. This is true for modern transport protocols (RTCP, SCTP, etc.) and it is even true for TCP, as long as the receiver supports SACK, which is widely deployed anyway. However, it is not true for ECN feedback in TCP. The need for more precise ECN feedback in TCP is not exclusive to ConEx; for instance, Data Centre TCP [DCTCP] uses precise feedback to good effect. Therefore, if a receiver offers precise feedback, [RFC7560] it will be best if ConEx uses it (see Section 5.3).
接收器：ConEx源应能够在不需要任何ConEx特定修改的情况下，与相关运输的常规接收器一起工作。这适用于现代传输协议（RTCP、SCTP等），甚至适用于TCP，只要接收器支持广泛部署的SACK。然而，TCP中的ECN反馈并非如此。在TCP中需要更精确的ECN反馈并非ConEx独有；例如，数据中心TCP[DCTCP]使用精确反馈以获得良好效果。因此，如果接收器提供精确反馈，[RFC7560]最好由ConEx使用（见第5.3节）。
Alternatively, without sufficiently precise congestion feedback from the receiver, the source may have to conservatively send extra ConEx markings in order to avoid understating congestion.
或者，如果没有来自接收器的足够精确的拥塞反馈，则源可能必须保守地发送额外的ConEx标记，以避免低估拥塞。
Proxies: Although it was stated above that ConEx requires a modification to the source, ConEx Signals could theoretically be introduced by a proxy for the source as long as it can intercept feedback from the receiver. Similarly, more precise feedback could theoretically be provided by a proxy for the receiver rather than modifying the receiver itself.
代理：尽管上面提到ConEx需要对源进行修改，但理论上，ConEx信号可以由源的代理引入，只要它能够截获来自接收器的反馈。类似地，理论上更精确的反馈可以由接收器的代理提供，而不是修改接收器本身。
Forwarding: No modification to forwarding or queuing is needed for ConEx.
转发：ConEx无需修改转发或排队。
However, once some ConEx is deployed, it is possible that a queue implementation could optionally take advantage of the ConEx information in packets. For instance, it has been suggested [CONEX-DESTOPT] that a queue would be more robust against flooding if it preferentially discarded Not-ConEx packets then Not-Marked ConEx packets.
然而，一旦部署了一些ConEx，队列实现就可以选择性地利用数据包中的ConEx信息。例如，有人建议[CONEX-DESTOPT]，如果队列优先丢弃非CONEX数据包而不是标记的CONEX数据包，那么队列将更能抵抗洪水。
A ConEx sender re-echoes congestion whether the queues signaling congestion are ECN enabled or not. Nonetheless, an operator relying on ConEx Signals is recommended to enable ECN in queues wherever possible. This is because auditing works best if most congestion is indicated by ECN rather than loss (see Section 3). Also, monitoring rest-of-path congestion is not accurate if there are congested non-ECN queues upstream of the monitoring point (Section 5.4.2).
无论队列是否启用ECN，ConEx发送方都会重新回显拥塞。尽管如此，建议依赖ConEx信号的操作员尽可能在队列中启用ECN。这是因为，如果大多数拥塞是由ECN指示的，而不是由丢失指示的，那么审计效果最好（参见第3节）。此外，如果监测点上游存在拥塞的非ECN队列，则监测剩余路径拥塞是不准确的（第5.4.2节）。
Networks: If a subset of traffic sources (or proxies) use ConEx Signals to reveal congestion in the internetwork layer, a network operator can choose (or not) to use this information for traffic management. As long as the end-to-end ConEx Signals are present, each network can unilaterally choose to use them -- independently of whether other networks do.
网络：如果流量源（或代理）的子集使用ConEx信号来显示网络层中的拥塞，则网络运营商可以选择（或不选择）将此信息用于流量管理。只要存在端到端的ConEx信号，每个网络都可以单方面选择使用它们，而与其他网络是否使用它们无关。
ConEx marked packets may safely traverse a network that ignores them. ConEx Signals are defined to remain unchanged once set by the sender, but some encodings may allow changes in transit (e.g., by proxies). In no circumstances will a network node change ConEx-Capable packets to Not-ConEx (network-layer encoding requirement I in Section 3.3). If necessary, endpoints should be able to detect if a network is removing ConEx Signals (network-layer encoding requirement H in Section 3.3).
ConEx标记的数据包可以安全地穿越忽略它们的网络。ConEx信号定义为在发送方设置后保持不变，但某些编码可能允许在传输过程中进行更改（例如，通过代理）。在任何情况下，网络节点都不会将支持ConEx的数据包更改为非ConEx（第3.3节中的网络层编码要求I）。如有必要，端点应能够检测网络是否正在移除ConEx信号（第3.3节中的网络层编码要求H）。
An operator can deploy policy devices (Section 5.4) wherever traffic enters its network in order to monitor the downstream congestion that incoming traffic contributes to and control it if necessary. A network operator can create incentives for the developers of sending applications and transports to voluntarily reveal ConEx information. Without ConEx information, a network operator tends to have to limit the bit-rate or volume from a site more than is necessary, just in case it might congest others. With ConEx information, the operator can solely limit congestion-causing traffic and otherwise allow complete freedom. This greater freedom acts as an inducement for the source to volunteer ConEx information. An operator may also monitor whether a source transport has sent ConEx packets and treat the same transport with greater suspicion (e.g., a more stringent rate limit) whenever it selectively sends packets without ConEx support. See [RFC6789] for further discussion of deployment incentives for networks and references to scenarios where some networks use ConEx-based policy devices and others don't.
运营商可以在流量进入其网络的任何地方部署策略设备（第5.4节），以监控流入流量造成的下游拥塞，并在必要时对其进行控制。网络运营商可以为发送应用程序和传输的开发者创造激励，以自愿披露ConEx信息。如果没有ConEx信息，网络运营商往往不得不对站点的比特率或容量进行超出必要的限制，以防它可能会阻塞其他站点。有了ConEx信息，运营商可以单独限制造成拥堵的交通量，并允许完全自由。这一更大的自由促使信息来源自愿提供ConEx信息。运营商还可以监控源传输是否发送了ConEx数据包，并在没有ConEx支持的情况下有选择地发送数据包时，以更大的怀疑对待同一传输（例如，更严格的速率限制）。请参阅[RFC6789]了解有关网络部署激励的进一步讨论，以及一些网络使用基于ConEx的策略设备而其他网络不使用的场景的参考。
An operator can deploy audit devices (Section 5.5) unilaterally within its own network to verify that traffic sources are not understating ConEx information. From the viewpoint of one network operator (say N_a), it only cares that the level of ConEx signaling is sufficient to cover congestion in its own network. If traffic continues into a congested downstream network (say N_b), it is of no concern to the first network (N_a) if the end-to-end ConEx signaling is insufficient to cover the congestion in N_b as well. This is N_b's concern, and N_b can both detect such anomalous traffic and deal with it using ConEx-based audit devices itself.
运营商可以在其自己的网络内单方面部署审计设备（第5.5节），以验证流量源是否未低估ConEx信息。从一家网络运营商（比如N_a）的角度来看，它只关心ConEx信令的水平是否足以覆盖其自身网络中的拥塞。如果流量继续进入拥塞的下游网络（例如N_b），那么如果端到端ConEx信令也不足以覆盖N_b中的拥塞，则第一个网络（N_a）不必担心。这是N_b关心的问题，N_b既可以检测到这种异常流量，也可以使用基于ConEx的审计设备来处理它。
The only known risk associated with ConEx is that users and applications are very likely to be motivated to underrepresent the congestion that they are causing. Significant portions of this document are about mechanisms to audit the ConEx Signals and create sufficient sanction to inhibit such underrepresentation. In particular, see Section 5.5.
与ConEx相关的唯一已知风险是，用户和应用程序很可能被激励低估他们造成的拥塞。本文件的重要部分是关于审计ConEx信号的机制，并制定足够的制裁措施以抑制此类代表性不足。具体见第5.5节。
Security attacks and their defences are best discussed against a concrete protocol specification, not the abstract mechanism of this document. A concrete ConEx protocol will need to be accompanied by a document describing how the protocol and its audit mechanisms defend against likely attacks. [Refb-dis] will be a useful source for such a document. It gives a comprehensive inventory of attacks against audit that have been proposed by various parties. It includes
安全攻击及其防御最好针对具体的协议规范进行讨论，而不是本文档的抽象机制。具体的ConEx协议需要附带一份文档，描述协议及其审计机制如何抵御可能的攻击。[Refb dis]将是此类文件的有用来源。它提供了各方提出的针对审计的攻击的全面清单。它包括
pseudocode for both deterministic and statistical audit functions designed to thwart these attacks and analyses the effectiveness of an implementation.
用于确定性和统计审计功能的伪代码，旨在阻止这些攻击，并分析实现的有效性。
However, [Refb-dis] is specific to the re-ECN protocol, which signalled ECN and loss together, whereas the concrete ConEx protocol defined in [CONEX-DESTOPT] signals them separately. Therefore, although likely attacks will be similar, there will be more combinations of attacks to worry about, and defences and their analysis are likely to be a little different for ConEx.
然而，[Refb dis]特定于re ECN协议，该协议同时表示ECN和丢失，而[ConEx-DESTOP]中定义的具体ConEx协议分别表示ECN和丢失。因此，尽管可能的攻击会相似，但会有更多的攻击组合需要担心，而ConEx的防御措施及其分析可能会略有不同。
The main known attacks that a security document for a concrete ConEx protocol will need to address are listed below and [Refb-dis] should be referred to for how re-ECN was designed to defend against similar attacks:
具体ConEx协议的安全文件需要解决的主要已知攻击如下所示，关于re-ECN如何设计以抵御类似攻击，请参考[Refb dis]：
o Attacks on the audit function (see Section 7.5 of [Refb-dis]):
o 对审计功能的攻击（见[Refb dis]第7.5节）：
Flow ID Whitewashing: Designing the audit function so that a source cannot gain from starting a new flow once audit has detected cheating in a previous flow.
流ID粉饰：设计审计功能，以便在审计检测到前一个流中存在欺骗时，源无法从启动新流中获益。
Dragging Down an Aggregate: Avoiding audit discarding packets from all flows within an aggregate, which would allow one flow to pull down the average so that the audit function would discard packets from all flows, not just the offending flow.
拖拽聚合：避免审核丢弃聚合中所有流中的数据包，这将允许一个流拉低平均值，以便审核函数丢弃所有流中的数据包，而不仅仅是违规流中的数据包。
Dragging Down a Spoofed Flow ID: An attacker understates ConEx markings in packets that spoof another flow, which fools the audit function into dropping the genuine user's packets.
拖下伪造的流ID：攻击者低估数据包中伪造另一个流的ConEx标记，从而欺骗审计功能丢弃真正用户的数据包。
o Attacks by networks on other networks (see Section 8.2 of [Refb-dis]):
o 网络对其他网络的攻击（见[Refb dis]第8.2节）：
Dummy Traffic: Sending dummy traffic across a border with understated ConEx markings to bring down the average ConEx markings in the aggregate of border traffic. This attack can be combined with a TTL that expires before the packets reach an audit function.
虚拟交通：发送虚拟交通穿越边境，使用低调的ConEx标记，以降低边境交通总量中的平均ConEx标记。此攻击可与在数据包到达审核功能之前过期的TTL结合使用。
Signal Poisoning with 'Cancelled' Marking: Sending high volumes of valid packets that are both ConEx-Marked and ECN-marked, which seems to represent congestion upstream, but it makes these packets immune to being further ECN-marked downstream.
带有“取消”标记的信号中毒：发送大量带有ConEx标记和ECN标记的有效数据包，这似乎表示上游拥塞，但它使这些数据包不受下游ECN标记的影响。
It is planned to document all known attacks and their defences (including all of the above) in the RFC series against a concrete ConEx protocol specification. In the interim, [Refb-dis] and its references should be referred to for details and ways to address these attacks in the case of re-ECN.
计划根据具体的ConEx协议规范记录RFC系列中的所有已知攻击及其防御（包括上述所有攻击）。在此期间，应参考[Refb dis]及其参考文献，以了解在re ECN情况下解决这些攻击的详细信息和方法。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[CheapPseud] Friedman, E. and P. Resnick, "The Social Cost of Cheap Pseudonyms", Journal of Economics and Management Strategy, Volume 10, Issue 2, pp. 173-199, DOI 10.1111/j.1430-9134.2001.00173.x, Summer 2001.
[Cheapseud]Friedman，E.和P.Resnick，“廉价笔名的社会成本”，《经济与管理战略杂志》，第10卷，第2期，第173-199页，DOI 10.1111/j.1430-9134.2001.00173.x，2001年夏季。
[CONEX-AUDIT] Wagner, D. and M. Kuehlewind, "Auditing of Congestion Exposure (ConEx) signals", Work in Progress, draft-wagner-conex-audit-01, February 2014.
[CONEX-AUDIT]Wagner，D.和M.Kuehlewind，“拥堵暴露（CONEX）信号的审计”，正在进行的工作，草稿-Wagner-CONEX-AUDIT-012014年2月。
[CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 Destination Option for Congestion Exposure (ConEx)", Work in Progress, draft-ietf-conex-destopt-11, October 2015.
[CONEX-DESTOPT]Krishnan，S.，Kuehlewind，M.，和C.Ucendo，“拥塞暴露的IPv6目的地选项（CONEX）”，正在进行的工作，草案-ietf-CONEX-DESTOPT-11，2015年10月。
[DCTCP] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data Center TCP (DCTCP)", ACM SIGCOMM Computer Communication Review, Volume 40, Issue 4, pages 63-74, DOI 10.1145/1851182.1851192, October 2010, <http://portal.acm.org/citation.cfm?id=1851192>.
[DCTCP]Alizadeh，M.，Greenberg，A.，Maltz，D.，Padhye，J.，Patel，P.，Prabhakar，B.，Sengupta，S.，和M.Sridharan，“数据中心TCP（DCTCP）”，ACM SIGCOMM计算机通信评论，第40卷，第4期，第63-74页，DOI 10.1145/1851182.1851192，2010年10月<http://portal.acm.org/citation.cfm?id=1851192>.
[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and the evolution of congestion control", Automatica, Volume 35, Issue 12, pages 1969-1985, DOI 10.1016/S0005-1098(99)00135-1, December 1999, <http://www.sciencedirect.com/science/article/pii/ S0005109899001351>.
[Evol_cc]Gibbens，R.和F.Kelly，“资源定价和拥塞控制的演变”，Automatica，第35卷，第12期，1969-1985页，DOI 10.1016/S0005-1098（99）00135-11999年12月<http://www.sciencedirect.com/science/article/pii/ S0005109899001351>。
[FairerFaster] Briscoe, B., "A Fairer, Faster Internet Protocol", IEEE Spectrum, pages 38-43, DOI 10.1109/MSPEC.2008.4687368, December 2008, <http://spectrum.ieee.org/telecom/standards/ a-fairer-faster-internet-protocol>.
[FairerFaster]Briscoe，B.，“更公平、更快的互联网协议”，IEEE Spectrum，第38-43页，DOI 10.1109/MSPEC.2008.4687368，2008年12月<http://spectrum.ieee.org/telecom/standards/ a-fairer-faster-internet-protocol>。
[ISOLATION-POLICING] Briscoe, B., "Network Performance Isolation using Congestion Policing", Work in Progress, draft-briscoe-conex-policing-01, February 2014.
[ISOLATION-POLICING]Briscoe，B.，“使用拥塞管理的网络性能隔离”，正在进行的工作，草稿-Briscoe-conex-POLICING-01，2014年2月。
[RE-ECN-MOTIVATION] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, "Re-ECN: A Framework for adding Congestion Accountability to TCP/IP", Work in Progress, draft-briscoe-conex-re-ecn-motiv-03, March 2014.
[RE-ECN-动机]Briscoe，B.，Jacquet，A.，Moncaster，T.，和A.Smith，“RE-ECN：向TCP/IP添加拥塞责任的框架”，正在进行的工作，草稿-Briscoe-conex-RE-ECN-motiv-032014年3月。
[RE-ECN-TCP] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Work in Progress, draft-briscoe-conex-re-ecn-tcp-04, July 2014.
[RE-ECN-TCP]Briscoe，B.，Jacquet，A.，Moncaster，T.，和A.Smith，“RE-ECN：增加导致TCP/IP拥塞的责任”，正在进行的工作，草稿-Briscoe-conex-RE-ECN-TCP-042014年7月。
[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion Response in an Internetwork Using Re-Feedback", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 4, pages 277--288, DOI 10.1145/1090191.1080124, August 2005, <http://portal.acm.org/citation.cfm?id=1080091.1080124>.
[Re fb]Briscoe，B.，Jacquet，A.，Di Cairano Gilfedder，C.，Salvatori，A.，Soppera，A.，和M.Koyabe，“使用再反馈在互联网中管理拥塞响应”，《ACM SIGCOMM计算机通信评论》，第35卷，第4期，第277-288页，DOI 10.1145/1090191.1080124，2005年8月<http://portal.acm.org/citation.cfm?id=1080091.1080124>.
[Refb-dis] Briscoe, B., "Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork", PhD Dissertation, University College London, May 2009, <http://discovery.ucl.ac.uk/16274/>.
[参考文献dis]Briscoe，B.“再反馈：在无连接的互联网中造成拥塞的责任自由”，伦敦大学学院博士论文，2009年5月<http://discovery.ucl.ac.uk/16274/>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <http://www.rfc-editor.org/info/rfc2018>.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，DOI 10.17487/RFC2018，1996年10月<http://www.rfc-editor.org/info/rfc2018>.
[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>.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, DOI 10.17487/RFC3514, April 2003, <http://www.rfc-editor.org/info/rfc3514>.
[RFC3514]Bellovin，S.，“IPv4报头中的安全标志”，RFC 3514，DOI 10.17487/RFC3514，2003年4月<http://www.rfc-editor.org/info/rfc3514>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[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>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 6040，DOI 10.17487/RFC6040，2010年11月<http://www.rfc-editor.org/info/rfc6040>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，DOI 10.17487/RFC66792012年8月<http://www.rfc-editor.org/info/rfc6679>.
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <http://www.rfc-editor.org/info/rfc6789>.
[RFC6789]Briscoe，B.，Ed.，Woundy，R.，Ed.，和A.Cooper，Ed.，“拥塞暴露（ConEx）概念和用例”，RFC 6789，DOI 10.17487/RFC6789，2012年12月<http://www.rfc-editor.org/info/rfc6789>.
[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>.
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, "Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback", RFC 7560, DOI 10.17487/RFC7560, August 2015, <http://www.rfc-editor.org/info/rfc7560>.
[RFC7560]Kuehlewind，M.，Ed.，Scheffenegger，R.，和B.Briscoe，“明确拥塞通知（ECN）反馈中提高准确性的问题陈述和要求”，RFC 7560，DOI 10.17487/RFC7560，2015年8月<http://www.rfc-editor.org/info/rfc7560>.
[Salvatori05] Salvatori, A., "Closed Loop Traffic Policing", Politecnico Torino and Institut Eurecom Masters Thesis, September 2005.
[Salvatori 05]Salvatori，A.，“闭环交通警察”，都灵理工大学和欧洲经济学研究所硕士论文，2005年9月。
[TCP-MODIFICATION] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", Work in Progress, draft-ietf-conex-tcp-modifications-10, October 2015.
[TCP-修改]Kuehlewind，M.和R.Scheffenegger，“拥塞暴露的TCP修改”，正在进行的工作，草案-ietf-conex-TCP-modifications-102015年10月。
Acknowledgments
致谢
This document was improved by review comments from Toby Moncaster, Nandita Dukkipati, Mirja Kuehlewind, Caitlin Bestler, Marcelo Bagnulo Braun, John Leslie, Ingemar Johansson, and David Wagner.
本文件通过Toby Moncaster、Nandita Dukkipati、Mirja Kuehlewind、Caitlin Bestler、Marcelo Bagnulo Braun、John Leslie、Ingemar Johansson和David Wagner的评审意见进行了改进。
Bob Briscoe's work on this specification received part-funding from the European Union's Seventh Framework Programme FP7/2007-2013 under the Trilogy 2 project, grant agreement no. 317756. The views expressed here are solely those of the authors.
Bob Briscoe在本规范方面的工作获得了欧盟第七个框架计划FP7/2007-2013的部分资助，该计划由Trilogy 2项目资助，批准协议编号317756。这里表达的观点仅是作者的观点。
Authors' Addresses
作者地址
Matt Mathis Google, Inc. 1600 Amphitheater Parkway Mountain View, California 93117 United States
Matt Mathis Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编：93117
Email: mattmathis@google.com
Email: mattmathis@google.com
Bob Briscoe BT (now at Simula Research Laboratory)
鲍勃·布里斯科英国电信公司（现供职于Simula研究实验室）
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/