Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8087 University of Aberdeen
Category: Informational M. Welzl
ISSN: 2070-1721 University of Oslo
March 2017
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8087 University of Aberdeen
Category: Informational M. Welzl
ISSN: 2070-1721 University of Oslo
March 2017
The Benefits of Using Explicit Congestion Notification (ECN)
使用显式拥塞通知（ECN）的好处
Abstract
摘要
The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.
本文档的目标是描述使用支持显式拥塞通知（ECN）的传输的应用程序的潜在好处。该文件概述了ECN在网络路径（包括支持拥塞体验（CE）标记的设备）上使用时在提高吞吐量、减少延迟和其他好处方面的主要收益。本文还讨论了成功部署ECN所面临的挑战。它没有提出使用ECN的新算法，也没有描述在端点设备（Internet主机）、路由器或其他网络设备中实现ECN的细节。
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/rfc8087.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8087.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Benefit of Using ECN to Avoid Congestion Loss . . . . . . . . 5
2.1. Improved Throughput . . . . . . . . . . . . . . . . . . . 5
2.2. Reduced Head-of-Line Blocking . . . . . . . . . . . . . . 6
2.3. Reduced Probability of RTO Expiry . . . . . . . . . . . . 6
2.4. Applications That Do Not Retransmit Lost Packets . . . . 7
2.5. Making Incipient Congestion Visible . . . . . . . . . . . 8
2.6. Opportunities for New Transport Mechanisms . . . . . . . 8
3. Network Support for ECN . . . . . . . . . . . . . . . . . . . 9
3.1. The ECN Field . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Forwarding ECN-Capable IP Packets . . . . . . . . . . . . 10
3.3. Enabling ECN in Network Devices . . . . . . . . . . . . . 11
3.4. Coexistence of ECN and Non-ECN Flows . . . . . . . . . . 11
3.5. Bleaching and Middlebox Requirements to Deploy ECN . . . 11
3.6. Tunneling ECN and the Use of ECN by Lower-Layer Networks 12
4. Using ECN across the Internet . . . . . . . . . . . . . . . . 12
4.1. Partial Deployment . . . . . . . . . . . . . . . . . . . 13
4.2. Detecting Whether a Path Really Supports ECN . . . . . . 13
4.3. Detecting ECN-Receiver Feedback Cheating . . . . . . . . 14
5. Summary: Enabling ECN in Network Devices and Hosts . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Benefit of Using ECN to Avoid Congestion Loss . . . . . . . . 5
2.1. Improved Throughput . . . . . . . . . . . . . . . . . . . 5
2.2. Reduced Head-of-Line Blocking . . . . . . . . . . . . . . 6
2.3. Reduced Probability of RTO Expiry . . . . . . . . . . . . 6
2.4. Applications That Do Not Retransmit Lost Packets . . . . 7
2.5. Making Incipient Congestion Visible . . . . . . . . . . . 8
2.6. Opportunities for New Transport Mechanisms . . . . . . . 8
3. Network Support for ECN . . . . . . . . . . . . . . . . . . . 9
3.1. The ECN Field . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Forwarding ECN-Capable IP Packets . . . . . . . . . . . . 10
3.3. Enabling ECN in Network Devices . . . . . . . . . . . . . 11
3.4. Coexistence of ECN and Non-ECN Flows . . . . . . . . . . 11
3.5. Bleaching and Middlebox Requirements to Deploy ECN . . . 11
3.6. Tunneling ECN and the Use of ECN by Lower-Layer Networks 12
4. Using ECN across the Internet . . . . . . . . . . . . . . . . 12
4.1. Partial Deployment . . . . . . . . . . . . . . . . . . . 13
4.2. Detecting Whether a Path Really Supports ECN . . . . . . 13
4.3. Detecting ECN-Receiver Feedback Cheating . . . . . . . . 14
5. Summary: Enabling ECN in Network Devices and Hosts . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Internet transports (such as TCP and Stream Control Transmission Protocol (SCTP)) are implemented in endpoints (Internet hosts) and are designed to detect and react to network congestion. Congestion may be detected by loss of an IP packet or, if Explicit Congestion Notification (ECN) [RFC3168] is enabled, by the reception of a packet with a Congestion Experienced (CE) marking in the IP header. Both of these are treated by transports as indications of congestion. ECN may also be enabled by other transports: UDP applications that provide congestion control may enable ECN when they are able to correctly process the ECN signals [RFC8085] (e.g., ECN with RTP [RFC6679]).
Internet传输（如TCP和流控制传输协议（SCTP））在端点（Internet主机）中实现，用于检测和响应网络拥塞。拥塞可以通过丢失IP数据包来检测，或者，如果启用了显式拥塞通知（ECN）[RFC3168]，则可以通过接收IP报头中带有拥塞经历（CE）标记的数据包来检测。运输部门将这两种情况视为交通拥堵的迹象。ECN也可以由其他传输启用：提供拥塞控制的UDP应用程序可以在能够正确处理ECN信号[RFC8085]（例如，带有RTP的ECN[RFC6679]）时启用ECN。
Active Queue Management (AQM) [RFC7567] is a class of techniques that can be used by network devices (a router, middlebox, or other device that forwards packets through the network) to manage the size of queues in network buffers.
主动队列管理（AQM）[RFC7567]是一类可由网络设备（路由器、中间箱或通过网络转发数据包的其他设备）用于管理网络缓冲区中队列大小的技术。
A network device that does not support AQM typically uses a drop-tail policy to drop excess IP packets when its queue becomes full. The discard of packets is treated by transport protocols as a signal that indicates congestion on the end-to-end network path. End-to-end transports, such as TCP, can cause a low level of loss while seeking to share capacity with other flows. Although losses are not always due to congestion (loss may be due to link corruption, receiver overrun, etc.), endpoints have to conservatively presume that all loss is potentially due to congestion and reduce their rate. Observed loss therefore results in a congestion control reaction by the transport to reduce the maximum rate permitted by the sending endpoint.
不支持AQM的网络设备通常在其队列已满时使用丢弃尾策略丢弃多余的IP数据包。数据包的丢弃被传输协议视为指示端到端网络路径上拥塞的信号。端到端传输（如TCP）在寻求与其他流共享容量时可能会导致较低级别的损失。虽然损失并不总是由拥塞引起（损失可能是由链路损坏、接收器溢出等引起），但端点必须保守地假定所有损失都可能是由拥塞引起的，并降低其速率。因此，观察到的丢失会导致传输做出拥塞控制反应，以降低发送端点允许的最大速率。
ECN makes it possible for the network to signal the presence of incipient congestion without incurring packet loss; it lets the network deliver some packets to an application that would otherwise have been dropped if the application or transport did not support ECN. This packet-loss reduction is the most obvious benefit of ECN, but it is often relatively modest. However, enabling ECN can also result in a number of beneficial side effects, some of which may be much more significant than the immediate packet-loss reduction from receiving a CE marking instead of dropping packets. Several benefits reduce latency (e.g., reduced head-of-line blocking).
ECN使得网络能够在不引起分组丢失的情况下发出存在初期拥塞的信号；它允许网络向应用程序发送一些数据包，如果应用程序或传输不支持ECN，这些数据包本来会被丢弃。这种数据包丢失的减少是ECN最明显的好处，但它通常是相对温和的。然而，启用ECN还可能导致许多有益的副作用，其中一些副作用可能比通过接收CE标记而不是丢弃数据包而立即减少数据包丢失更为显著。有几个好处可以减少延迟（例如，减少线头阻塞）。
The use of ECN is indicated in the ECN field [RFC3168], which is carried in the packet header of all IPv4 and IPv6 packets. This field may be set to one of the four values shown in Figure 1. The Not-ECT codepoint '00' indicates a packet that is not using ECN. The ECT(0) codepoint '01' and the ECT(1) codepoint '10' both indicate
ECN的使用在ECN字段[RFC3168]中指示，该字段包含在所有IPv4和IPv6数据包的数据包头中。该字段可以设置为图1所示的四个值之一。Not ECT代码点“00”表示未使用ECN的数据包。ECT（0）代码点“01”和ECT（1）代码点“10”都指示
that the transport protocol using the IP layer supports the use of ECN. The CE codepoint '11' is set by an ECN-capable network device to indicate congestion to the transport endpoint.
使用IP层的传输协议支持使用ECN。CE代码点“11”由支持ECN的网络设备设置，以指示传输端点的拥塞。
+-----+-----+---------+
| ECN FIELD | Name |
+-----+-----+---------+
| 0 | 0 | Not-ECT |
| 0 | 1 | ECT(1) |
| 1 | 0 | ECT(0) |
| 1 | 1 | CE |
+-----+-----+---------+
+-----+-----+---------+
| ECN FIELD | Name |
+-----+-----+---------+
| 0 | 0 | Not-ECT |
| 0 | 1 | ECT(1) |
| 1 | 0 | ECT(0) |
| 1 | 1 | CE |
+-----+-----+---------+
Figure 1: The ECN Field in the IP Packet Header (based on [RFC3168])
图1:IP数据包头中的ECN字段（基于[RFC3168]）
When an application uses a transport that enables use of ECN [RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in the IP header of packets that it sends. This indicates to network devices that they may mark, rather than drop, the ECN-capable IP packets. An ECN-capable network device can then signal incipient congestion (network queuing) at a point before a transport experiences congestion loss or high queuing delay. The marking is generally performed as the result of various AQM algorithms [RFC7567] where the exact combination of AQM/ECN algorithms does not need to be known by the transport endpoints.
当应用程序使用能够使用ECN[RFC3168]的传输时，传输层在其发送的数据包的IP报头中设置ECT（0）或ECT（1）码点。这向网络设备表明，它们可以标记而不是丢弃支持ECN的IP数据包。然后，支持ECN的网络设备可以在传输经历拥塞丢失或高排队延迟之前的某个点发出初始拥塞（网络排队）信号。标记通常作为各种AQM算法[RFC7567]的结果执行，其中传输端点不需要知道AQM/ECN算法的精确组合。
The focus of the document is on usage of ECN by transport- and application-layer flows, not its implementation in endpoint hosts, routers, and other network devices.
本文档的重点是通过传输层和应用层流使用ECN，而不是在端点主机、路由器和其他网络设备中实现ECN。
The following terms are used:
使用以下术语：
AQM: Active Queue Management.
主动队列管理。
CE: Congestion Experienced; a codepoint value '11' marked in the ECN field of the IP packet header.
行政长官:交通挤塞;；在IP数据包头的ECN字段中标记的代码点值“11”。
ECN-capable IP Packet: A packet where the ECN field is set to a non-zero ECN value (i.e., with ECT(0), ECT(1), or the CE codepoint).
支持ECN的IP数据包：ECN字段设置为非零ECN值的数据包（即，使用ECT（0）、ECT（1）或CE代码点）。
ECN-capable network device: An ECN-capable network device may forward, drop, or queue an ECN-capable packet and may choose to CE mark this packet when there is incipient congestion.
支持ECN的网络设备：支持ECN的网络设备可转发、丢弃或排队支持ECN的数据包，并可在出现初期拥塞时选择CE标记该数据包。
ECN-capable transport/application: A transport that sends ECN-capable IP Packets, monitors reception of the ECN field, and generates appropriate feedback to control the rate of the sending endpoint to provide end-to-end congestion control.
支持ECN的传输/应用：发送支持ECN的IP数据包、监视ECN字段的接收并生成适当反馈以控制发送端点的速率以提供端到端拥塞控制的传输。
ECN field: A 2-bit field specified for use with explicit congestion signaling in the IPv4 and IPv6 packet headers.
ECN字段：指定用于IPv4和IPv6数据包头中显式拥塞信令的2位字段。
Endpoint: An Internet host that terminates a transport protocol connection across an Internet path.
端点：通过Internet路径终止传输协议连接的Internet主机。
Incipient Congestion: The detection of congestion when it is starting, perhaps by a network device noting that the arrival rate exceeds the forwarding rate.
初期拥塞：在拥塞开始时检测拥塞，可能是由网络设备注意到到达速率超过转发速率。
Network device: A router, middlebox, or other device that forwards IP packets through the network.
网络设备：路由器、中间盒或其他通过网络转发IP数据包的设备。
non-ECN-capable: A network device or endpoint that does not interpret the ECN field. Such a device is not permitted to change the ECN codepoint.
不支持ECN：不解释ECN字段的网络设备或端点。不允许此类设备更改ECN代码点。
not-ECN-capable IP Packet: An IP packet with the ECN field set to a value of zero ('00'). A not-ECN-capable packet may be forwarded, dropped, or queued by a network device.
不支持ECN的IP数据包：ECN字段设置为零值（'00'）的IP数据包。不支持ECN的数据包可由网络设备转发、丢弃或排队。
An ECN-capable network device is expected to CE mark an ECN-capable IP packet as a CE when an AQM method detects incipient congestion rather than drop the packet [RFC7567]. An application can benefit from this marking in several ways, which are detailed in the rest of this section.
当AQM方法检测到初始拥塞而不是丢弃数据包时，支持ECN的网络设备期望CE将支持ECN的IP数据包标记为CE[RFC7567]。应用程序可以通过多种方式受益于此标记，本节其余部分将对此进行详细介绍。
ECN seeks to avoid the inefficiency of dropping data that has already made it across at least part of the network path.
ECN寻求避免丢弃已经通过至少部分网络路径传输的数据的低效性。
ECN can improve the throughput of an application, although this increase in throughput is often not the most significant gain. When an application uses a lightly to moderately loaded network path, the number of packets that are dropped due to congestion is small. Using an example from Table 1 of [RFC3649], for a standard TCP sender with an RTT of 0.1 seconds, a packet size of 1500 bytes, and an average throughput of 1 Mbps, the average packet-drop ratio would be 0.02 (i.e., 1 in 50 packets). This translates into an approximate 2%
ECN可以提高应用程序的吞吐量，尽管吞吐量的增加通常不是最显著的收益。当应用程序使用轻负载到中等负载的网络路径时，由于拥塞而丢弃的数据包数量很少。使用[RFC3649]表1中的示例，对于RTT为0.1秒、数据包大小为1500字节、平均吞吐量为1Mbps的标准TCP发送器，平均数据包丢弃率为0.02（即，50个数据包中的1个）。这意味着大约2%
throughput gain if ECN is enabled. (Note that in heavy congestion, packet loss may be unavoidable with or without ECN.)
启用ECN时的吞吐量增益。（请注意，在严重拥塞情况下，无论是否使用ECN，数据包丢失都是不可避免的。）
Many Internet transports provide in-order delivery of received data segments to the applications they support. For these applications, use of ECN can reduce the delay that can result when these applications experience packet loss.
许多Internet传输提供接收到的数据段到它们支持的应用程序的顺序传送。对于这些应用程序，使用ECN可以减少当这些应用程序经历数据包丢失时可能导致的延迟。
Packet loss may occur for various reasons. One cause arises when an AQM scheme drops a packet as a signal of incipient congestion. Whatever the cause of loss, a missing packet needs to trigger a congestion control response. A reliable transport also triggers retransmission to recover the lost data. For a transport providing in-order delivery, this requires that the transport receiver stall (or wait) for all data that was sent ahead of a lost segment to be correctly received before it can forward any later data to the application. A loss therefore creates a delay of at least one RTT after a loss event before data can be delivered to an application. We call this head-of-line blocking. This is the usual requirement for TCP and SCTP. Partially Reliable SCTP (PR-SCTP) [RFC3758], UDP [RFC768] [RFC8085], and the Datagram Congestion Control Protocol (DCCP) [RFC4340] provide a transport that does not provide reordering.
由于各种原因，可能会发生数据包丢失。当AQM方案丢弃作为初始拥塞信号的分组时，会出现一个原因。无论丢失的原因是什么，丢失的数据包都需要触发拥塞控制响应。可靠的传输也会触发重新传输以恢复丢失的数据。对于按订单交付的传输，这要求传输接收器暂停（或等待）以正确接收在丢失段之前发送的所有数据，然后才能将任何后续数据转发给应用程序。因此，丢失会在丢失事件发生后，在数据可以传递到应用程序之前，造成至少一个RTT的延迟。我们称之为线头阻塞。这是TCP和SCTP的通常要求。部分可靠的SCTP（PR-SCTP）[RFC3758]、UDP[RFC768][RFC8085]和数据报拥塞控制协议（DCCP）[RFC4340]提供不提供重新排序的传输。
By enabling ECN, a transport continues to receive in-order data when there is incipient congestion and can pass this data to the receiving application. Use of ECN avoids the additional reordering delay in a reliable transport. The sender still needs to make an appropriate congestion response to reduce the maximum transmission rate for future traffic, which usually will require a reduction in the sending rate [RFC8085].
通过启用ECN，当出现初期拥塞时，传输继续接收顺序数据，并可以将该数据传递给接收应用程序。使用ECN避免了可靠传输中额外的重新排序延迟。发送方仍然需要做出适当的拥塞响应，以降低未来流量的最大传输速率，这通常需要降低发送速率[RFC8085]。
Some patterns of packet loss can result in a Retransmission Timeout (RTO), which causes a sudden and significant change in the allowed rate at which a transport/application can forward packets. Because ECN provides an alternative to drop for network devices to signal incipient congestion, this can reduce the probability of loss and hence reduce the likelihood of RTO expiry.
某些数据包丢失模式可能会导致重传超时（RTO），从而导致传输/应用程序转发数据包的允许速率突然发生显著变化。因为ECN为网络设备提供了一种替代drop的方法来发出初期拥塞的信号，这可以降低丢失的概率，从而降低RTO失效的可能性。
Internet transports/applications generally use an RTO timer as a last resort to detect and recover loss [RFC8085] [RFC5681]. Specifically, an RTO timer detects loss of a packet that is not followed by other packets, such as at the end of a burst of data segments or when an application becomes idle (either because the application has no
Internet传输/应用程序通常使用RTO定时器作为检测和恢复丢失的最后手段[RFC8085][RFC5681]。具体地说，RTO定时器检测未跟随其他分组的分组的丢失，例如在数据段突发结束时或当应用程序变为空闲时（或者因为应用程序没有数据段）
further data to send or the network prevents sending further data, e.g., flow or congestion control at the transport layer). This loss of the last segment (or last few segments) of a traffic burst is also known as a "tail loss". Standard transport recovery methods, such as Fast Recovery [RFC5681], are often unable to recover from a tail loss. This is because the endpoint receiver is unaware that the lost segments were actually sent and therefore generates no feedback [Fla13]. Retransmission of these segments relies on expiry of a transport retransmission timer. This timer is also used to detect a lack of forwarding along a path. Expiry of the RTO results in the consequent loss of state about the network path being used. This typically includes resetting path estimates such as the RTT, reinitializing the congestion window, and possibly making updates to other transport state. This can reduce the performance of the transport until it again adapts to the path.
要发送的进一步数据或网络阻止发送进一步数据（例如，传输层的流量或拥塞控制）。流量突发的最后一段（或最后几段）丢失也称为“尾部丢失”。标准传输恢复方法，如快速恢复[RFC5681]，通常无法从尾部丢失中恢复。这是因为端点接收器不知道丢失的段实际上已发送，因此不会生成反馈[Fla13]。这些段的重新传输依赖于传输重新传输计时器的到期。此计时器还用于检测路径上缺少转发。RTO的到期会导致所用网络路径的状态丢失。这通常包括重置路径估计，如RTT，重新初始化拥塞窗口，以及可能对其他传输状态进行更新。这会降低传输的性能，直到它再次适应路径。
An ECN-capable network device cannot eliminate the possibility of tail loss because a drop may occur due to a traffic burst exceeding the instantaneous available capacity of a network buffer or as a result of the AQM algorithm (e.g., overload protection mechanisms [RFC7567]). However, an ECN-capable network device that observes incipient congestion may be expected to buffer the IP packets of an ECN-capable flow and set a CE mark in one or more packet(s) rather than triggering packet drop. Setting a CE mark signals incipient congestion without forcing the transport/application to enter retransmission timeout. This reduces application-level latency and can improve the throughput for applications that send intermittent bursts of data.
支持ECN的网络设备无法消除尾部丢失的可能性，因为由于流量突发超过网络缓冲区的瞬时可用容量或由于AQM算法（例如过载保护机制[RFC7567]），可能会发生丢弃。然而，可以期望观察到初始拥塞的支持ECN的网络设备缓冲支持ECN的流的IP分组并在一个或多个分组中设置CE标记，而不是触发分组丢弃。设置CE标记表示初期拥塞，而不强制传输/应用程序进入重传超时。这减少了应用程序级延迟，并可以提高发送间歇性数据突发的应用程序的吞吐量。
The benefit of avoiding retransmission loss is expected to be significant when ECN is used on TCP SYN/ACK packets [RFC5562] where the RTO interval may be large because TCP cannot base the timeout period on prior RTT measurements from the same connection.
当ECN用于TCP SYN/ACK数据包[RFC5562]时，避免重传丢失的好处是显著的，其中RTO间隔可能很大，因为TCP不能基于来自同一连接的先前RTT测量值来确定超时时间。
A transport that enables ECN can receive timely congestion signals without the need to retransmit packets each time it receives a congestion signal.
使ECN能够及时接收拥塞信号的传输，而无需在每次接收到拥塞信号时重新传输数据包。
Some latency-critical applications do not retransmit lost packets, yet they may be able to adjust their sending rate following detection of incipient congestion. Examples of such applications include UDP-based services that carry Voice over IP (VoIP), interactive video, or real-time data. The performance of many such applications degrades rapidly with increasing packet loss, and the transport/application may therefore employ mechanisms (e.g., packet forward error correction, data duplication, or media codec error concealment) to
一些延迟关键型应用程序不会重新传输丢失的数据包，但它们可能能够在检测到初期拥塞后调整发送速率。此类应用程序的示例包括基于UDP的服务，这些服务承载IP语音（VoIP）、交互式视频或实时数据。许多这样的应用程序的性能随着分组丢失的增加而迅速降低，因此传输/应用程序可以采用机制（例如，分组前向纠错、数据复制或媒体编解码器错误隐藏）来实现
mitigate the immediate effect of congestion loss on the application. Some mechanisms consume additional network capacity, some require additional processing, and some contribute additional path latency when congestion is experienced. By decoupling congestion control from loss, ECN can allow transports that support these applications to reduce their rate before the application experiences loss from congestion. This can reduce the negative impact of triggering loss-hiding mechanisms with a direct positive impact on the quality experienced by the users of these applications.
减轻拥塞丢失对应用程序的直接影响。有些机制消耗额外的网络容量，有些需要额外的处理，有些机制在遇到拥塞时会造成额外的路径延迟。通过将拥塞控制与丢失分离，ECN可以允许支持这些应用程序的传输在应用程序因拥塞而丢失之前降低速率。这可以减少触发丢失隐藏机制的负面影响，并对这些应用程序的用户体验到的质量产生直接的积极影响。
A characteristic of using ECN is that it exposes the presence of congestion on a network path to the transport and network layers, thus allowing information to be collected about the presence of incipient congestion.
使用ECN的一个特点是，它向传输层和网络层暴露网络路径上的拥塞，从而允许收集关于初始拥塞存在的信息。
Recording the presence of CE-marked packets can provide information about the current congestion level experienced on a network path. A network flow that only experiences CE marking and no loss implies that the sending endpoint is experiencing only congestion. A network flow may also experience loss (e.g., due to queue overflow, AQM methods that protect other flows, link corruption, or loss in middleboxes). When a mixture of CE marking and packet loss is experienced, transports and measurements need to assume there is congestion [RFC7567]. Therefore, an absence of CE marks does not indicate a path has not experienced congestion.
记录CE标记的数据包的存在可以提供关于网络路径上经历的当前拥塞级别的信息。仅经历CE标记且无丢失的网络流意味着发送端点仅经历拥塞。网络流也可能会丢失（例如，由于队列溢出、保护其他流的AQM方法、链路损坏或中间盒丢失）。当遇到CE标记和数据包丢失的混合情况时，传输和测量需要假设存在拥塞[RFC7567]。因此，没有CE标记并不表示路径没有经历拥塞。
The reception of CE-marked packets can be used to monitor the level of congestion by a transport/application or a network operator. For example, ECN measurements are used by Congestion Exposure (ConEx) [RFC6789]. In contrast, metering packet loss is harder.
接收CE标记的数据包可用于监控传输/应用程序或网络运营商的拥塞水平。例如，拥塞暴露（ConEx）[RFC6789]使用ECN测量值。相比之下，测量数据包丢失更困难。
ECN can enable design and deployment of new algorithms in network devices and Internet transports. Internet transports need to regard both loss and CE marking as an indication of congestion. However, while the amount of feedback provided by drop ought naturally be minimized, this is not the case for ECN. In contrast, an ECN-capable network device could provide richer (more frequent and fine-grained) indication of its congestion state to the transport.
ECN可以在网络设备和互联网传输中设计和部署新算法。互联网传输需要将丢失和CE标记视为拥塞的指示。然而，虽然drop提供的反馈量自然应该最小化，但ECN的情况并非如此。相反，支持ECN的网络设备可以向传输提供更丰富（更频繁、更细粒度）的拥塞状态指示。
For any ECN-capable transport (ECT), the receiving endpoint needs to provide feedback to the transport sender to indicate that CE marks have been received. [RFC3168] provides one method that signals once each round-trip time (RTT) that CE-marked packets have been received.
对于任何支持ECN的传输（ECT），接收端点需要向传输发送方提供反馈，以指示已接收到CE标记。[RFC3168]提供了一种方法，该方法在收到CE标记的数据包的每个往返时间（RTT）时发出一次信号。
A receiving endpoint may provide more detailed feedback to the congestion controller at the sender (e.g., describing the set of received ECN codepoints or indicating each received CE-marked packet). Precise feedback about the number of CE marks encountered is supported by RTP when used over UDP [RFC6679] and has been proposed for SCTP [ST14] and TCP [ECN-FEEDBACK].
接收端点可以向发送方的拥塞控制器提供更详细的反馈（例如，描述接收到的ECN码点集或指示每个接收到的CE标记的分组）。当通过UDP[RFC6679]使用时，RTP支持对遇到的CE标记数量的精确反馈，并且已针对SCTP[ST14]和TCP[ECN-feedback]提出了建议。
More detailed feedback is expected to enable evolution of transport protocols allowing the congestion control mechanism to make a more appropriate decision on how to react to congestion. Designers of transport protocols need to consider not only how network devices CE-mark packets but also how the control loop in the application/ transport reacts to reception of these CE-marked packets.
更详细的反馈有望促进传输协议的发展，使拥塞控制机制能够就如何应对拥塞做出更适当的决定。传输协议的设计者不仅需要考虑网络设备CE标记分组的方式，还需要考虑应用程序/传输中的控制环路如何响应这些CE标记分组的接收。
Benefit has been noted when packets are CE marked early using an instantaneous queue, and if the receiving endpoint provides feedback about the number of packet marks encountered, an improved sender behavior has been shown to be possible, e.g, Data Center TCP (DCTCP) [AL10]. DCTCP is targeted at controlled environments such as a data center. This is a work in progress, and it is currently unknown whether or how such behavior could be safely introduced into the Internet. Any update to an Internet transport protocol requires careful consideration of the robustness of the behavior when working with endpoints or network devices that were not designed for the new congestion reaction.
已经注意到当使用瞬时队列提前对数据包进行CE标记时的益处，并且如果接收端点提供关于遇到的数据包标记数量的反馈，则已经证明改进的发送者行为是可能的，例如，数据中心TCP（DCTCP）[AL10]。DCTCP的目标是受控环境，如数据中心。这是一项正在进行的工作，目前尚不清楚这种行为是否或如何安全地引入互联网。对Internet传输协议的任何更新都需要在处理端点或网络设备时仔细考虑行为的健壮性，这些端点或网络设备不是为新的拥塞反应而设计的。
For an application to use ECN requires that the endpoints enable ECN within the transport being used. It also requires that all network devices along the path at least forward IP packets that set a non-zero ECN codepoint.
应用程序要使用ECN，需要端点在所使用的传输中启用ECN。它还要求路径上的所有网络设备至少转发设置非零ECN码点的IP数据包。
ECN can be deployed both in the general Internet and in controlled environments:
ECN可以部署在通用Internet和受控环境中：
o ECN can be incrementally deployed in the general Internet. The IETF has provided guidance on configuration and usage in [RFC7567].
o ECN可以增量地部署在通用Internet中。IETF在[RFC7567]中提供了配置和使用指南。
o ECN may be deployed within a controlled environment, for example, within a data center or within a well-managed private network. This use of ECN may be tuned to the specific use case. An example is DCTCP [AL10] [DCTCP].
o ECN可以部署在受控环境中，例如，数据中心或管理良好的专用网络中。ECN的这种使用可以根据特定的用例进行调整。例如，DCTCP[AL10][DCTCP]。
Early experience of using ECN across the general Internet encountered a number of operational difficulties when the network path either failed to transfer ECN-capable packets or inappropriately changed the ECN codepoints [BA11]. A recent survey reported a growing support for network paths to pass ECN codepoints [TR15].
当网络路径未能传输支持ECN的数据包或不适当地更改ECN代码点时，在通用互联网上使用ECN的早期经验遇到了许多操作困难[BA11]。最近的一项调查报告称，越来越多的人支持通过网络路径来传递ECN码点[TR15]。
The remainder of this section identifies what is needed for network devices to effectively support ECN.
本节的其余部分确定了网络设备有效支持ECN所需的内容。
The current IPv4 and IPv6 specifications assign usage of 2 bits in the IP header to carry the ECN codepoint. This 2-bit field was reserved in [RFC2474] and assigned in [RFC3168].
当前的IPv4和IPv6规范分配了IP报头中2位的使用，以承载ECN码点。此2位字段在[RFC2474]中保留，并在[RFC3168]中分配。
[RFC4774] discusses some of the issues in defining alternate semantics for the ECN field and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics.
[RFC4774]讨论了为ECN字段定义替代语义时的一些问题，并指定了Internet中安全共存的要求，其中可能包括不理解已定义替代语义的路由器。
Some network devices were configured to use a routing hash that included the set of 8 bits forming the now deprecated Type of Service (TOS) field [RFC1349]. The present use of this field assigns 2 of these bits to carry the ECN field. This is incompatible with use in a routing hash because it could lead to IP packets that carry a CE mark being routed over a different path to those packets that carried an ECT mark. The resultant reordering would impact the performance of transport protocols (such as TCP or SCTP) and UDP-based applications that are sensitive to reordering. A network device that conforms to this older specification needs to be updated to the current specifications [RFC2474] to support ECN. Configuration of network devices must note that the ECN field may be updated by any ECN-capable network device along a path.
一些网络设备被配置为使用路由散列，该散列包括8位的集合，该集合构成了现在不推荐使用的服务类型（TOS）字段[RFC1349]。该字段的当前使用分配了其中2个位来携带ECN字段。这与在路由散列中的使用不兼容，因为它可能导致携带CE标记的IP数据包通过与携带ECT标记的数据包不同的路径进行路由。由此产生的重新排序将影响对重新排序敏感的传输协议（如TCP或SCTP）和基于UDP的应用程序的性能。符合此旧规范的网络设备需要更新为当前规范[RFC2474]，以支持ECN。网络设备的配置必须注意，ECN字段可以由任何支持ECN的网络设备沿路径更新。
Not all network devices along a path need to be ECN-capable (i.e., perform CE marking). However, all network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used.
并非一条路径上的所有网络设备都需要具备ECN功能（即，执行CE标记）。但是，所有网络设备都需要配置为不丢弃数据包，这仅仅是因为使用了ECT（0）或ECT（1）码点。
Any network device that does not perform CE marking of an ECN-capable packet can be expected to drop these packets under congestion. Applications that experience congestion at these network devices do not see any benefit from enabling ECN. However, they may see benefit if the congestion were to occur within a network device that did support ECN.
任何不执行支持ECN的数据包的CE标记的网络设备都可能在拥塞情况下丢弃这些数据包。在这些网络设备上遇到拥塞的应用程序看不到启用ECN的任何好处。然而，如果拥塞发生在支持ECN的网络设备内，他们可能会看到好处。
Network devices should use an AQM algorithm that CE-marks ECN-capable traffic when making decisions about the response to congestion [RFC7567]. An ECN method should set a CE mark on ECN-capable packets in the presence of incipient congestion. A CE-marked packet will be interpreted as an indication of incipient congestion by the transport endpoints.
网络设备应使用AQM算法，在做出拥塞响应决策时，CE标记支持ECN的流量[RFC7567]。在出现初期拥塞时，ECN方法应在支持ECN的数据包上设置CE标记。CE标记的数据包将被解释为传输端点的初始拥塞指示。
There is an opportunity to design an AQM method for an ECN-capable network device that differs from an AQM method designed to drop packets. [RFC7567] states that the network device should allow this behavior to be configurable.
有机会为支持ECN的网络设备设计不同于设计用于丢弃数据包的AQM方法的AQM方法。[RFC7567]声明网络设备应允许配置此行为。
[RFC3168] describes a method in which a network device sets the CE mark at the time that the network device would otherwise have dropped the packet. While it has often been assumed that network devices should CE-mark packets at the same level of congestion at which they would otherwise have dropped them, [RFC7567] recommends that network devices allow independent configuration of the settings for AQM dropping and ECN marking. Such separate configuration of the drop and mark policies is supported in some network devices.
[RFC3168]描述了一种方法，其中网络设备在网络设备本应丢弃数据包时设置CE标记。虽然通常认为网络设备应在其原本丢弃数据包的相同拥塞水平上对数据包进行CE标记，但RFC7567建议网络设备允许独立配置AQM丢弃和ECN标记的设置。某些网络设备支持这种删除和标记策略的单独配置。
Network devices need to be able to forward all IP flows and provide appropriate treatment for both ECN and non-ECN traffic.
网络设备需要能够转发所有IP流，并为ECN和非ECN流量提供适当的处理。
The design considerations for an AQM scheme supporting ECN needs to consider the impact of queueing during incipient congestion. For example, a simple AQM scheme could choose to queue ECN-capable and non-ECN-capable flows in the same queue with an ECN scheme that CE-marks packets during incipient congestion. The CE-marked packets that remain in the queue during congestion can continue to contribute to queueing delay. In contrast, non-ECN-capable packets would normally be dropped by an AQM scheme under incipient congestion. This difference in queueing is one motivation for consideration of more advanced AQM schemes and may provide an incentive for enabling flow isolation using scheduling [RFC7567]. The IETF is defining methods to evaluate the suitability of AQM schemes for deployment in the general Internet [RFC7928].
支持ECN的AQM方案的设计考虑需要考虑在初始拥塞期间排队的影响。例如，一个简单的AQM方案可以选择将支持ECN的流和不支持ECN的流在同一队列中排队，而ECN方案在初始拥塞期间对数据包进行CE标记。拥塞期间留在队列中的带有CE标记的数据包可能会继续导致排队延迟。相反，在初期拥塞情况下，AQM方案通常会丢弃不支持ECN的数据包。排队中的这种差异是考虑更高级AQM方案的一个动机，并可能为使用调度实现流隔离提供激励[RFC7567]。IETF正在定义评估AQM方案在通用互联网中部署的适用性的方法[RFC7928]。
Network devices should not be configured to change the ECN codepoint in the packets that they forward, except to set the CE codepoint to signal incipient congestion.
不应将网络设备配置为更改其转发的数据包中的ECN码点，除非将CE码点设置为信号初始拥塞。
Cases have been noted where an endpoint sends a packet with a non-zero ECN mark, but the packet is received by the remote endpoint with a zero ECN codepoint [TR15]. This could be a result of a policy that erases or "bleaches" the ECN codepoint values at a network edge (resetting the codepoint to zero). Bleaching may occur for various reasons (including normalizing packets to hide which equipment supports ECN). This policy prevents use of ECN by applications.
已经注意到端点发送具有非零ECN标记的分组，但该分组由具有零ECN码点的远程端点接收的情况[TR15]。这可能是在网络边缘擦除或“漂白”ECN代码点值（将代码点重置为零）的策略的结果。漂白可能由于各种原因发生（包括规范化数据包以隐藏支持ECN的设备）。此策略防止应用程序使用ECN。
When ECN-capable IP packets, marked as ECT(0) or ECT(1), are re-marked to non-ECN-capable (i.e., the ECN field is set to the zero codepoint), this could result in the packets being dropped by ECN-capable network devices further along the path. This eliminates the advantage of using of ECN.
当标记为ECT（0）或ECT（1）的支持ECN的IP数据包被重新标记为不支持ECN（即，ECN字段被设置为零代码点）时，这可能导致支持ECN的网络设备沿着路径进一步丢弃数据包。这消除了使用ECN的优势。
A network device must not change a packet with a CE mark to a zero codepoint; if the network device decides not to forward the packet with the CE mark, it has to instead drop the packet and not bleach the marking. This is because a CE-marked packet has already received ECN treatment in the network, and re-marking it would then hide the congestion signal from the receiving endpoint. This eliminates the benefits of ECN. It can also slow down the response to congestion compared to using AQM because the transport will only react if it later discovers congestion by some other mechanism.
网络设备不得将带有CE标记的数据包更改为零码点；如果网络设备决定不转发带有CE标记的数据包，则必须丢弃该数据包，并且不漂白该标记。这是因为CE标记的数据包已经在网络中接收到ECN处理，重新标记它将隐藏来自接收端点的拥塞信号。这消除了ECN的好处。与使用AQM相比，它还可以减慢对拥塞的响应速度，因为只有在稍后通过其他机制发现拥塞时，传输才会做出反应。
Prior to [RFC2474], a previous usage assigned the bits now forming the ECN field as a part of the now deprecated TOS field [RFC1349]. A network device that conforms to this older specification was allowed to re-mark or erase the ECN codepoints, and such equipment needs to be updated to the current specifications in order to support ECN.
在[RFC2474]之前，先前的用法将现在形成ECN字段的位分配为现在已弃用的TOS字段[RFC1349]的一部分。允许符合此旧规范的网络设备重新标记或擦除ECN代码点，并且需要将此类设备更新为当前规范以支持ECN。
Some networks may use ECN internally or tunnel ECN (e.g., for traffic engineering or security). These methods need to ensure that the ECN field of the tunnel packets is handled correctly at the ingress and egress of the tunnel. Guidance on the correct use of ECN is provided in [RFC6040].
一些网络可能在内部使用ECN或隧道ECN（例如，用于流量工程或安全）。这些方法需要确保在隧道的入口和出口处正确处理隧道分组的ECN字段。[RFC6040]中提供了正确使用ECN的指南。
Further guidance on the encapsulation and use of ECN by non-IP network devices is provided in [ECN-ENCAP].
[ECN-ENCAP]中提供了关于非IP网络设备封装和使用ECN的进一步指导。
A receiving endpoint needs to report the loss it experiences when it uses loss-based congestion control. So also, when ECN is enabled, a receiving endpoint must correctly report the presence of CE marks by providing a mechanism to feed this congestion information back to the sending endpoint [RFC3168] [RFC8085], thus enabling the sender to
接收端点需要报告在使用基于丢失的拥塞控制时所经历的丢失。因此，当启用ECN时，接收端点必须通过提供一种机制将拥塞信息反馈给发送端点[RFC3168][RFC8085]，从而使发送方能够正确报告CE标记的存在
react to experienced congestion. This mechanism needs to be designed to operate robustly across a wide range of Internet path characteristics. This section describes partial deployment, that is, how ECN-enabled endpoints can continue to work effectively over a path that experiences misbehaving network devices or when an endpoint does not correctly provide feedback of ECN information.
对遇到的拥堵做出反应。该机制需要设计为在广泛的互联网路径特征中稳健运行。本节描述部分部署，即启用ECN的端点如何在遇到网络设备行为异常或端点未正确提供ECN信息反馈的路径上继续有效工作。
Use of ECN is negotiated between the endpoints prior to using the mechanism.
ECN的使用在使用该机制之前在端点之间进行协商。
ECN has been designed to allow incremental partial deployment [RFC3168]. Any network device can choose to use either ECN or some other loss-based policy to manage its traffic. Similarly, transport/ application negotiation allows sending and receiving endpoints to choose whether ECN will be used to manage congestion for a particular network flow.
ECN的设计允许增量部分部署[RFC3168]。任何网络设备都可以选择使用ECN或其他基于丢失的策略来管理其流量。类似地，传输/应用程序协商允许发送和接收端点选择是否使用ECN来管理特定网络流的拥塞。
Internet transports and applications need to be robust to the variety and sometimes varying path characteristics that are encountered in the general Internet. They need to monitor correct forwarding of ECN over the entire path and duration of a session.
Internet传输和应用程序需要对一般Internet中遇到的各种路径特征（有时是变化的路径特征）具有鲁棒性。他们需要在会话的整个路径和持续时间内监控ECN的正确转发。
To be robust, applications and transports need to be designed with the expectation of heterogeneous forwarding (e.g., where some IP packets are CE marked by one network device and some by another, possibly using a different AQM algorithm, or when a combination of CE marking and loss-based congestion indications are used). Note that [RFC7928] describes methodologies for evaluating AQM schemes.
为了具有健壮性，应用程序和传输需要在设计时考虑到异构转发（例如，一些IP数据包由一个网络设备进行CE标记，另一些由另一个设备进行CE标记，可能使用不同的AQM算法，或者当使用CE标记和基于丢失的拥塞指示的组合时）。请注意，[RFC7928]描述了评估AQM方案的方法。
A transport/application also needs to be robust to path changes. A change in the set of network devices along a path could impact the ability to effectively signal or use ECN across the path, e.g., when a path changes to use a middlebox that bleaches ECN codepoints (see Section 3.5).
传输/应用程序还需要对路径更改具有鲁棒性。沿路径的网络设备组的变化可能会影响在路径上有效发送信号或使用ECN的能力，例如，当路径改变为使用漂白ECN代码点的中间盒时（参见第3.5节）。
A sending endpoint can check that any CE marks applied to packets received over the path are indeed delivered to the remote receiving endpoint and that appropriate feedback is provided. (This could be done by a sender setting a known CE codepoint for specific packets in a network flow and then checking whether the remote endpoint correctly reports these marks [ECN-FALLBACK] [TR15].) If a sender detects persistent misuse of ECN, it needs to fall back to using loss-based recovery and congestion control. Guidance on a suitable transport reaction is provided in [ECN-FALLBACK].
发送端点可以检查应用于通过路径接收的分组的任何CE标记是否确实被传递到远程接收端点，并且是否提供了适当的反馈。（这可以通过发送方为网络流中的特定数据包设置已知的CE代码点，然后检查远程端点是否正确报告这些标记[ECN-FALLBACK][TR15]来完成）。如果发送方检测到持续滥用ECN，则需要使用基于丢失的恢复和拥塞控制。[ECN-FALLBACK]中提供了有关适当运输反应的指南。
Appropriate feedback requires that the endpoint receiver not try to conceal reception of CE-marked packets in the ECN feedback information provided to the sending endpoint [RFC7567]. Designers of applications/transports are therefore encouraged to include mechanisms that can detect this misbehavior. If a sending endpoint detects that a receiver is not correctly providing this feedback, it needs to fall back to using loss-based recovery instead of ECN.
适当的反馈要求端点接收器不要试图在提供给发送端点的ECN反馈信息中隐藏CE标记数据包的接收[RFC7567]。因此，我们鼓励应用程序/传输的设计者加入能够检测这种错误行为的机制。如果发送端点检测到接收器未正确提供此反馈，则需要使用基于丢失的恢复而不是ECN。
This section summarizes the benefits of deploying and using ECN within the Internet. It also provides a list of prerequisites to achieve ECN deployment.
本节总结了在Internet中部署和使用ECN的好处。它还提供了实现ECN部署的先决条件列表。
Application developers should, where possible, use transports that enable ECN. Applications that directly use UDP need to provide support to implement the functions required for ECN [RFC8085]. Once enabled, an application that uses a transport that supports ECN will experience the benefits of ECN as network deployment starts to enable ECN. The application does not need to be rewritten to gain these benefits. Figure 2 summarizes the key benefits.
在可能的情况下，应用程序开发人员应该使用支持ECN的传输。直接使用UDP的应用程序需要提供支持，以实现ECN[RFC8085]所需的功能。一旦启用，当网络部署开始启用ECN时，使用支持ECN的传输的应用程序将体验到ECN的好处。应用程序无需重写即可获得这些好处。图2总结了关键好处。
+---------+-----------------------------------------------------+
| Section | Benefit |
+---------+-----------------------------------------------------+
| 2.1 | Improved Throughput |
| 2.2 | Reduced Head-of-Line Blocking |
| 2.3 | Reduced Probability of RTO Expiry |
| 2.4 | Applications that do not Retransmit Lost Packets |
| 2.5 | Making Incipient Congestion Visible |
| 2.6 | Opportunities for New Transport Mechanisms |
+---------+-----------------------------------------------------+
+---------+-----------------------------------------------------+
| Section | Benefit |
+---------+-----------------------------------------------------+
| 2.1 | Improved Throughput |
| 2.2 | Reduced Head-of-Line Blocking |
| 2.3 | Reduced Probability of RTO Expiry |
| 2.4 | Applications that do not Retransmit Lost Packets |
| 2.5 | Making Incipient Congestion Visible |
| 2.6 | Opportunities for New Transport Mechanisms |
+---------+-----------------------------------------------------+
Figure 2: Summary of Key Benefits
图2：主要好处摘要
Network operators and people configuring network devices should enable ECN [RFC7567].
网络运营商和配置网络设备的人员应启用ECN[RFC7567]。
Prerequisites for network devices (including IP routers) to enable use of ECN include:
网络设备（包括IP路由器）启用ECN的先决条件包括：
o A network device that updates the ECN field in IP packets must use IETF-specified methods (see Section 3.1).
o 更新IP数据包中ECN字段的网络设备必须使用IETF指定的方法（见第3.1节）。
o A network device may support alternate ECN semantics (see Section 3.1).
o 网络设备可支持备用ECN语义（见第3.1节）。
o A network device must not choose a different network path solely because a packet carries a CE-codepoint set in the ECN Field; CE-marked packets need to follow the same path as packets with an ECT(0) or ECT(1) codepoint (see Section 3.1). Network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used (see Section 3.2).
o 网络设备不得仅因为分组携带ECN字段中设置的CE码点而选择不同的网络路径；CE标记的数据包需要遵循与具有ECT（0）或ECT（1）码点的数据包相同的路径（参见第3.1节）。网络设备需要配置为不丢弃数据包，这仅仅是因为使用了ECT（0）或ECT（1）码点（参见第3.2节）。
o An ECN-capable network device should correctly update the ECN codepoint of ECN-capable packets in the presence of incipient congestion (see Section 3.3).
o 支持ECN的网络设备应在出现初期拥塞时正确更新支持ECN的数据包的ECN码点（见第3.3节）。
o Network devices need to be able to forward both ECN-capable and not-ECN-capable flows (see Section 3.4).
o 网络设备需要能够转发支持ECN和不支持ECN的流（参见第3.4节）。
o A network device must not change a packet with a CE mark to a not-ECN-capable codepoint ('00'); if the network device decides not to forward the packet with the CE mark, it has to instead drop the packet and not bleach the marking (see Section 3.5).
o 网络设备不得将带有CE标记的数据包更改为不支持ECN的代码点（“00”）；如果网络设备决定不转发带有CE标记的数据包，则必须丢弃该数据包，并且不漂白该标记（参见第3.5节）。
Prerequisites for network endpoints to enable use of ECN include the following:
网络端点启用ECN的先决条件包括：
o An application should use an Internet transport that can set and receive ECN marks (see Section 4).
o 应用程序应该使用可以设置和接收ECN标记的Internet传输（参见第4节）。
o An ECN-capable transport/application must return feedback indicating congestion to the sending endpoint and perform an appropriate congestion response (see Section 4).
o 支持ECN的传输/应用程序必须向发送端点返回指示拥塞的反馈，并执行适当的拥塞响应（参见第4节）。
o An ECN-capable transport/application should detect paths where there is persistent misuse of ECN and fall back to not sending ECT(0) or ECT(1) (see Section 4.2).
o 支持ECN的传输/应用程序应检测持续误用ECN的路径，并退回到不发送ECT（0）或ECT（1）（参见第4.2节）。
o Designers of applications/transports are encouraged to include mechanisms that can detect and react appropriately to misbehaving receivers that fail to report CE-marked packets (see Section 4.3).
o 鼓励应用程序/传输的设计人员包括能够检测并适当响应未能报告CE标记数据包的行为不端的接收器的机制（见第4.3节）。
This document introduces no new security considerations. Each RFC listed in this document discusses the security considerations of the specification it contains.
本文档没有引入新的安全注意事项。本文档中列出的每个RFC都讨论了其包含的规范的安全注意事项。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<http://www.rfc-editor.org/info/rfc2474>.
[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>.
[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>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，DOI 10.17487/RFC8085，2017年3月<http://www.rfc-editor.org/info/rfc8085>.
[AL10] 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.
[AL10]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月。
[BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, "Measuring the State of ECN Readiness in Servers, Clients, and Routers", Proceedings of the 2011 ACM SIGCOMM Conference on ICM, pages 171-180, DOI 10.1145/2068816.2068833, November 2011.
[BA11]鲍尔、史蒂文、贝弗利、罗伯特和亚瑟。Berger，“测量服务器、客户端和路由器的ECN就绪状态”，2011年ACM SIGCOMM ICM会议记录，第171-180页，DOI 10.1145/2068816.2068833，2011年11月。
[DCTCP] Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., and G. Judd, "Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", Work in Progress, draft-bensley-tcpm-dctcp-05, July 2015.
[DCTCP]Bensley，S.，Eggert，L.，Thaler，D.，Balasubramanian，P.，和G.Judd，“微软的数据中心TCP（DCTCP）：数据中心的TCP拥塞控制”，正在进行的工作，草稿-Bensley-tcpm-DCTCP-052015年7月。
[ECN-ENCAP] Briscoe, B., Kaippallimalil, J., and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Work in Progress, draft-ietf-tsvwg-ecn-encap-guidelines-07, July 2016.
[ECN-ENCAP]Briscoe，B.，Kaippallimalil，J.，和P.Thaler，“向封装IP的协议中添加拥塞通知的指南”，正在进行的工作，草稿-ietf-tsvwg-ECN-ENCAP-Guidelines-072016年7月。
[ECN-FALLBACK] Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path Probing and Fallback", Work in Progress, draft-kuehlewind-tcpm-ecn-fallback-01, September 2013.
[ECN-FALLBACK]Kuehlewind，M.和B.Trammell，“ECN路径探测和回退机制”，正在进行的工作，草稿-Kuehlewind-tcpm-ECN-FALLBACK-012013年9月。
[ECN-FEEDBACK] Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, draft-ietf-tcpm-accurate-ecn-02, October 2016.
[ECN-反馈]Briscoe，B.，Kuehlewind，M.，和R.Scheffenegger，“TCP中更准确的ECN反馈”，正在进行的工作，草稿-ietf-tcpm-Accurate-ECN-022016年10月。
[Fla13] Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas., Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain, Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh. Govindan, "Reducing web latency: the virtue of gentle aggression", ACM SIGCOMM Computer Communication Review, Volume 43, Issue 4, pages 159-170, DOI 10.1145/2534169.2486014, October 2013.
[Flach、Tobias、Dukkipati、Nandita、Terzis、Andreas、Raghavan、Barath、Cardwell、Neal、Cheng、Yuchong、Jain、Ankur、Hao、Shuai、Katz Bassett、Ethan和Ramesh。Govindan，“减少网络延迟：温和攻击的优点”，《ACM SIGCOMM计算机通信评论》，第43卷，第4期，第159-170页，DOI 10.1145/2534169.2486014，2013年10月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, <http://www.rfc-editor.org/info/rfc1349>.
[RFC1349]Almquist，P.，“互联网协议套件中的服务类型”，RFC 1349，DOI 10.17487/RFC1349，1992年7月<http://www.rfc-editor.org/info/rfc1349>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, <http://www.rfc-editor.org/info/rfc3649>.
[RFC3649]Floyd，S.，“用于大拥塞窗口的高速TCP”，RFC 3649，DOI 10.17487/RFC3649，2003年12月<http://www.rfc-editor.org/info/rfc3649>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <http://www.rfc-editor.org/info/rfc3758>.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，DOI 10.17487/RFC3758，2004年5月<http://www.rfc-editor.org/info/rfc3758>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 4340，DOI 10.17487/RFC4340，2006年3月<http://www.rfc-editor.org/info/rfc4340>.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <http://www.rfc-editor.org/info/rfc4774>.
[RFC4774]Floyd，S.，“为显式拥塞通知（ECN）字段指定替代语义”，BCP 124，RFC 4774，DOI 10.17487/RFC4774，2006年11月<http://www.rfc-editor.org/info/rfc4774>.
[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. Ramakrishnan, "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, DOI 10.17487/RFC5562, June 2009, <http://www.rfc-editor.org/info/rfc5562>.
[RFC5562]Kuzmanovic，A.，Mondal，A.，Floyd，S.，和K.Ramakrishnan，“向TCP的SYN/ACK数据包添加显式拥塞通知（ECN）功能”，RFC 5562，DOI 10.17487/RFC5562，2009年6月<http://www.rfc-editor.org/info/rfc5562>.
[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>.
[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>.
[RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and D. Ros, "Characterization Guidelines for Active Queue Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 2016, <http://www.rfc-editor.org/info/rfc7928>.
[RFC7928]Kuhn，N.，Ed.，Natarajan，P.，Ed.，Khademi，N.，Ed.，和D.Ros，“主动队列管理（AQM）的特征化指南”，RFC 7928，DOI 10.17487/RFC7928，2016年7月<http://www.rfc-editor.org/info/rfc7928>.
[ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Control Transmission Protocol (SCTP)", Work in Progress, draft-stewart-tsvwg-sctpecn-05, January 2014.
[ST14]Stewart，R.，Tuexen，M.，和X.Dong，“用于流控制传输协议（SCTP）的ECN”，正在进行的工作，草稿-Stewart-tsvwg-sctpecn-052014年1月。
[TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, Learmonth, Iain., and Gorry. Fairhurst, "Enabling Internet-Wide Deployment of Explicit Congestion Notification", Lecture Notes in Computer Science, Volume 8995, pp 193-205, DOI 10.1007/978-3-319-15509-8_15, March 2015.
[TR15]特兰梅尔、布赖恩、库勒温德、米尔贾、波帕、达米亚诺、利尔蒙、伊恩和戈里。Fairhurst，“实现显式拥塞通知在互联网范围内的部署”，《计算机科学》第8995卷，第193-205页，DOI 10.1007/978-3-319-15509-8_15，2015年3月。
Acknowledgements
致谢
The authors were partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the authors.
欧洲共同体通过减少互联网传输延迟（RITE）项目（ICT-317700）在其第七个框架方案下为作者提供了部分资金。所表达的观点仅为作者的观点。
The authors would like to thank the following people for their comments on prior draft versions of this document: Bob Briscoe, David Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie, and other members of the TSVWG and AQM working groups.
作者要感谢以下人士对本文件先前草稿的评论：鲍勃·布里斯科、大卫·科利尔·布朗、科林·珀金斯、理查德·谢弗内格、戴夫·塔特、韦斯·埃迪、弗雷德·贝克、米凯尔·亚伯拉罕·哈姆松、米利亚·库勒温德、约翰·莱斯利以及TSVWG和AQM工作组的其他成员。
Authors' Addresses
作者地址
Godred Fairhurst University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE United Kingdom
GoRead FelHurt阿伯丁大学工程学院，弗雷泽贵族大厦阿伯丁Ab24 3UE英国
Email: gorry@erg.abdn.ac.uk
Email: gorry@erg.abdn.ac.uk
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
米迦勒WelZl奥斯陆大学邮政信箱1080盲人奥斯陆N-0316挪威
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no