Network Working Group K. Ramakrishnan
Request for Comments: 3168 TeraOptic Networks
Updates: 2474, 2401, 793 S. Floyd
Obsoletes: 2481 ACIRI
Category: Standards Track D. Black
EMC
September 2001
Network Working Group K. Ramakrishnan
Request for Comments: 3168 TeraOptic Networks
Updates: 2474, 2401, 793 S. Floyd
Obsoletes: 2481 ACIRI
Category: Standards Track D. Black
EMC
September 2001
The Addition of Explicit Congestion Notification (ECN) to IP
向IP添加显式拥塞通知（ECN）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header.
此备忘录规定将ECN（显式拥塞通知）并入TCP和IP，包括ECN在IP报头中使用两位。
Table of Contents
目录
1. Introduction.................................................. 3
2. Conventions and Acronyms...................................... 5
3. Assumptions and General Principles............................ 5
4. Active Queue Management (AQM)................................. 6
5. Explicit Congestion Notification in IP........................ 6
5.1. ECN as an Indication of Persistent Congestion............... 10
5.2. Dropped or Corrupted Packets................................ 11
5.3. Fragmentation............................................... 11
6. Support from the Transport Protocol........................... 12
6.1. TCP......................................................... 13
6.1.1 TCP Initialization......................................... 14
6.1.1.1. Middlebox Issues........................................ 16
6.1.1.2. Robust TCP Initialization with an Echoed Reserved Field. 17
6.1.2. The TCP Sender............................................ 18
6.1.3. The TCP Receiver.......................................... 19
6.1.4. Congestion on the ACK-path................................ 20
6.1.5. Retransmitted TCP packets................................. 20
1. Introduction.................................................. 3
2. Conventions and Acronyms...................................... 5
3. Assumptions and General Principles............................ 5
4. Active Queue Management (AQM)................................. 6
5. Explicit Congestion Notification in IP........................ 6
5.1. ECN as an Indication of Persistent Congestion............... 10
5.2. Dropped or Corrupted Packets................................ 11
5.3. Fragmentation............................................... 11
6. Support from the Transport Protocol........................... 12
6.1. TCP......................................................... 13
6.1.1 TCP Initialization......................................... 14
6.1.1.1. Middlebox Issues........................................ 16
6.1.1.2. Robust TCP Initialization with an Echoed Reserved Field. 17
6.1.2. The TCP Sender............................................ 18
6.1.3. The TCP Receiver.......................................... 19
6.1.4. Congestion on the ACK-path................................ 20
6.1.5. Retransmitted TCP packets................................. 20
6.1.6. TCP Window Probes......................................... 22
7. Non-compliance by the End Nodes............................... 22
8. Non-compliance in the Network................................. 24
8.1. Complications Introduced by Split Paths..................... 25
9. Encapsulated Packets.......................................... 25
9.1. IP packets encapsulated in IP............................... 25
9.1.1. The Limited-functionality and Full-functionality Options.. 27
9.1.2. Changes to the ECN Field within an IP Tunnel.............. 28
9.2. IPsec Tunnels............................................... 29
9.2.1. Negotiation between Tunnel Endpoints...................... 31
9.2.1.1. ECN Tunnel Security Association Database Field.......... 32
9.2.1.2. ECN Tunnel Security Association Attribute............... 32
9.2.1.3. Changes to IPsec Tunnel Header Processing............... 33
9.2.2. Changes to the ECN Field within an IPsec Tunnel........... 35
9.2.3. Comments for IPsec Support................................ 35
9.3. IP packets encapsulated in non-IP Packet Headers............ 36
10. Issues Raised by Monitoring and Policing Devices............. 36
11. Evaluations of ECN........................................... 37
11.1. Related Work Evaluating ECN................................ 37
11.2. A Discussion of the ECN nonce.............................. 37
11.2.1. The Incremental Deployment of ECT(1) in Routers.......... 38
12. Summary of changes required in IP and TCP.................... 38
13. Conclusions.................................................. 40
14. Acknowledgements............................................. 41
15. References................................................... 41
16. Security Considerations...................................... 45
17. IPv4 Header Checksum Recalculation........................... 45
18. Possible Changes to the ECN Field in the Network............. 45
18.1. Possible Changes to the IP Header.......................... 46
18.1.1. Erasing the Congestion Indication........................ 46
18.1.2. Falsely Reporting Congestion............................. 47
18.1.3. Disabling ECN-Capability................................. 47
18.1.4. Falsely Indicating ECN-Capability........................ 47
18.2. Information carried in the Transport Header................ 48
18.3. Split Paths................................................ 49
19. Implications of Subverting End-to-End Congestion Control..... 50
19.1. Implications for the Network and for Competing Flows....... 50
19.2. Implications for the Subverted Flow........................ 53
19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion
Control.................................................... 54
20. The Motivation for the ECT Codepoints........................ 54
20.1. The Motivation for an ECT Codepoint........................ 54
20.2. The Motivation for two ECT Codepoints...................... 55
21. Why use Two Bits in the IP Header?........................... 57
22. Historical Definitions for the IPv4 TOS Octet................ 58
23. IANA Considerations.......................................... 60
23.1. IPv4 TOS Byte and IPv6 Traffic Class Octet................. 60
23.2. TCP Header Flags........................................... 61
6.1.6. TCP Window Probes......................................... 22
7. Non-compliance by the End Nodes............................... 22
8. Non-compliance in the Network................................. 24
8.1. Complications Introduced by Split Paths..................... 25
9. Encapsulated Packets.......................................... 25
9.1. IP packets encapsulated in IP............................... 25
9.1.1. The Limited-functionality and Full-functionality Options.. 27
9.1.2. Changes to the ECN Field within an IP Tunnel.............. 28
9.2. IPsec Tunnels............................................... 29
9.2.1. Negotiation between Tunnel Endpoints...................... 31
9.2.1.1. ECN Tunnel Security Association Database Field.......... 32
9.2.1.2. ECN Tunnel Security Association Attribute............... 32
9.2.1.3. Changes to IPsec Tunnel Header Processing............... 33
9.2.2. Changes to the ECN Field within an IPsec Tunnel........... 35
9.2.3. Comments for IPsec Support................................ 35
9.3. IP packets encapsulated in non-IP Packet Headers............ 36
10. Issues Raised by Monitoring and Policing Devices............. 36
11. Evaluations of ECN........................................... 37
11.1. Related Work Evaluating ECN................................ 37
11.2. A Discussion of the ECN nonce.............................. 37
11.2.1. The Incremental Deployment of ECT(1) in Routers.......... 38
12. Summary of changes required in IP and TCP.................... 38
13. Conclusions.................................................. 40
14. Acknowledgements............................................. 41
15. References................................................... 41
16. Security Considerations...................................... 45
17. IPv4 Header Checksum Recalculation........................... 45
18. Possible Changes to the ECN Field in the Network............. 45
18.1. Possible Changes to the IP Header.......................... 46
18.1.1. Erasing the Congestion Indication........................ 46
18.1.2. Falsely Reporting Congestion............................. 47
18.1.3. Disabling ECN-Capability................................. 47
18.1.4. Falsely Indicating ECN-Capability........................ 47
18.2. Information carried in the Transport Header................ 48
18.3. Split Paths................................................ 49
19. Implications of Subverting End-to-End Congestion Control..... 50
19.1. Implications for the Network and for Competing Flows....... 50
19.2. Implications for the Subverted Flow........................ 53
19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion
Control.................................................... 54
20. The Motivation for the ECT Codepoints........................ 54
20.1. The Motivation for an ECT Codepoint........................ 54
20.2. The Motivation for two ECT Codepoints...................... 55
21. Why use Two Bits in the IP Header?........................... 57
22. Historical Definitions for the IPv4 TOS Octet................ 58
23. IANA Considerations.......................................... 60
23.1. IPv4 TOS Byte and IPv6 Traffic Class Octet................. 60
23.2. TCP Header Flags........................................... 61
23.3. IPSEC Security Association Attributes....................... 62
24. Authors' Addresses........................................... 62
25. Full Copyright Statement..................................... 63
23.3. IPSEC Security Association Attributes....................... 62
24. Authors' Addresses........................................... 62
25. Full Copyright Statement..................................... 63
We begin by describing TCP's use of packet drops as an indication of congestion. Next we explain that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers can instead set the Congestion Experienced (CE) codepoint in the IP header of packets from ECN-capable transports. We describe when the CE codepoint is to be set in routers, and describe modifications needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. We also describe in this document the issues involving the use of ECN within IP tunnels, and within IPsec tunnels in particular.
我们首先描述TCP使用丢包作为拥塞指示。接下来，我们将解释，随着在Internet基础设施中添加主动队列管理（例如RED），路由器在队列溢出之前检测到拥塞，路由器不再局限于作为拥塞指示的数据包丢弃。路由器可以在支持ECN传输的数据包的IP报头中设置拥塞体验（CE）码点。我们描述了在路由器中何时设置CE码点，并描述了使其具有ECN功能所需的TCP修改。可以考虑对其他传输协议（例如，不可靠的单播或多播、可靠的多播、其他可靠的单播传输协议）的修改，因为这些协议是通过标准过程开发和推进的。在本文档中，我们还描述了涉及在IP隧道中使用ECN的问题，特别是在IPsec隧道中。
One of the guiding principles for this document is that, to the extent possible, the mechanisms specified here be incrementally deployable. One challenge to the principle of incremental deployment has been the prior existence of some IP tunnels that were not compatible with the use of ECN. As ECN becomes deployed, non-compatible IP tunnels will have to be upgraded to conform to this document.
本文件的指导原则之一是，在可能的情况下，此处指定的机制可以增量部署。增量部署原则面临的一个挑战是之前存在一些与ECN的使用不兼容的IP隧道。随着ECN的部署，不兼容的IP隧道必须升级以符合本文件的要求。
This document obsoletes RFC 2481, "A Proposal to add Explicit Congestion Notification (ECN) to IP", which defined ECN as an Experimental Protocol for the Internet Community. This document also updates RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", in defining the ECN field in the IP header, RFC 2401, "Security Architecture for the Internet Protocol" to change the handling of IPv4 TOS Byte and IPv6 Traffic Class Octet in tunnel mode header construction to be compatible with the use of ECN, and RFC 793, "Transmission Control Protocol", in defining two new flags in the TCP header.
本文件废除了RFC2481，“向IP添加显式拥塞通知（ECN）的提案”，该提案将ECN定义为互联网社区的实验协议。本文档还更新了RFC 2474“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，在定义IP报头中的ECN字段RFC 2401“Internet协议的安全体系结构”中更改隧道模式标头构造中IPv4 TOS字节和IPv6通信类八位字节的处理，以兼容在定义TCP标头中的两个新标志时使用ECN和RFC 793“传输控制协议”。
TCP's congestion control and avoidance algorithms are based on the notion that the network is a black-box [Jacobson88, Jacobson90]. The network's state of congestion or otherwise is determined by end-systems probing for the network state, by gradually increasing the load on the network (by increasing the window of packets that are outstanding in the network) until the network becomes congested and a packet is lost. Treating the network as a "black-box" and treating
TCP的拥塞控制和避免算法基于网络是一个黑箱的概念[Jacobson88，Jacobson90]。网络的拥塞状态或其他状态由终端系统通过逐渐增加网络上的负载（通过增加网络中未完成的数据包的窗口）来探测网络状态来确定，直到网络变得拥塞并且数据包丢失。将网络视为“黑箱”并处理
loss as an indication of congestion in the network is appropriate for pure best-effort data carried by TCP, with little or no sensitivity to delay or loss of individual packets. In addition, TCP's congestion management algorithms have techniques built-in (such as Fast Retransmit and Fast Recovery) to minimize the impact of losses, from a throughput perspective. However, these mechanisms are not intended to help applications that are in fact sensitive to the delay or loss of one or more individual packets. Interactive traffic such as telnet, web-browsing, and transfer of audio and video data can be sensitive to packet losses (especially when using an unreliable data delivery transport such as UDP) or to the increased latency of the packet caused by the need to retransmit the packet after a loss (with the reliable data delivery semantics provided by TCP).
作为网络拥塞指示的丢失适用于TCP承载的纯尽力而为数据，对单个数据包的延迟或丢失几乎不敏感或不敏感。此外，TCP的拥塞管理算法具有内置技术（如快速重传和快速恢复），以从吞吐量角度最小化丢失的影响。然而，这些机制并不旨在帮助那些实际上对一个或多个单独数据包的延迟或丢失敏感的应用程序。诸如telnet、web浏览以及音频和视频数据的传输等交互流量可能对数据包丢失（尤其是在使用不可靠的数据传输传输（如UDP）时）或由于丢失后需要重新传输数据包而导致的数据包延迟增加敏感（使用TCP提供的可靠数据交付语义）。
Since TCP determines the appropriate congestion window to use by gradually increasing the window size until it experiences a dropped packet, this causes the queues at the bottleneck router to build up. With most packet drop policies at the router that are not sensitive to the load placed by each individual flow (e.g., tail-drop on queue overflow), this means that some of the packets of latency-sensitive flows may be dropped. In addition, such drop policies lead to synchronization of loss across multiple flows.
由于TCP通过逐渐增加窗口大小直到遇到丢弃的数据包来确定要使用的适当拥塞窗口，这会导致瓶颈路由器上的队列增加。由于路由器上的大多数数据包丢弃策略对每个单独流放置的负载不敏感（例如，队列溢出上的尾部丢弃），这意味着延迟敏感流的一些数据包可能会被丢弃。此外，这种丢弃策略会导致多个流之间的丢失同步。
Active queue management mechanisms detect congestion before the queue overflows, and provide an indication of this congestion to the end nodes. Thus, active queue management can reduce unnecessary queuing delay for all traffic sharing that queue. The advantages of active queue management are discussed in RFC 2309 [RFC2309]. Active queue management avoids some of the bad properties of dropping on queue overflow, including the undesirable synchronization of loss across multiple flows. More importantly, active queue management means that transport protocols with mechanisms for congestion control (e.g., TCP) do not have to rely on buffer overflow as the only indication of congestion.
主动队列管理机制在队列溢出之前检测拥塞，并向终端节点提供该拥塞的指示。因此，主动队列管理可以减少共享该队列的所有流量不必要的排队延迟。RFC2309中讨论了主动队列管理的优点。主动队列管理避免了队列溢出时丢弃的一些不良属性，包括跨多个流的丢失同步。更重要的是，主动队列管理意味着具有拥塞控制机制（例如TCP）的传输协议不必依赖缓冲区溢出作为拥塞的唯一指示。
Active queue management mechanisms may use one of several methods for indicating congestion to end-nodes. One is to use packet drops, as is currently done. However, active queue management allows the router to separate policies of queuing or dropping packets from the policies for indicating congestion. Thus, active queue management allows routers to use the Congestion Experienced (CE) codepoint in a packet header as an indication of congestion, instead of relying solely on packet drops. This has the potential of reducing the impact of loss on latency-sensitive flows.
主动队列管理机制可以使用几种方法中的一种来指示终端节点的拥塞。一种是使用数据包丢弃，就像目前所做的那样。然而，主动队列管理允许路由器将排队或丢弃数据包的策略与指示拥塞的策略分开。因此，主动队列管理允许路由器使用分组报头中的拥塞经历（CE）码点作为拥塞指示，而不是仅仅依赖分组丢弃。这有可能减少丢失对延迟敏感流的影响。
There exist some middleboxes (firewalls, load balancers, or intrusion detection systems) in the Internet that either drop a TCP SYN packet configured to negotiate ECN, or respond with a RST. This document specifies procedures that TCP implementations may use to provide robust connectivity even in the presence of such equipment.
Internet上存在一些中间盒（防火墙、负载平衡器或入侵检测系统），它们要么丢弃配置为协商ECN的TCP SYN数据包，要么使用RST进行响应。本文件规定了TCP实施可用于提供可靠连接的程序，即使在存在此类设备的情况下。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释。
In this section, we describe some of the important design principles and assumptions that guided the design choices in this proposal.
在本节中，我们将介绍一些重要的设计原则和假设，这些原则和假设指导了本建议书中的设计选择。
* Because ECN is likely to be adopted gradually, accommodating migration is essential. Some routers may still only drop packets to indicate congestion, and some end-systems may not be ECN-capable. The most viable strategy is one that accommodates incremental deployment without having to resort to "islands" of ECN-capable and non-ECN-capable environments.
* 由于ECN可能会逐渐被采用，因此适应移民至关重要。一些路由器可能仍然只丢弃数据包以指示拥塞，而一些终端系统可能不支持ECN。最可行的策略是一种适应增量部署的策略，而不必求助于支持ECN和不支持ECN的环境的“孤岛”。
* New mechanisms for congestion control and avoidance need to co-exist and cooperate with existing mechanisms for congestion control. In particular, new mechanisms have to co-exist with TCP's current methods of adapting to congestion and with routers' current practice of dropping packets in periods of congestion.
* 新的拥塞控制和避免机制需要与现有的拥塞控制机制共存和合作。特别是，新机制必须与TCP当前适应拥塞的方法以及路由器当前在拥塞期间丢弃数据包的实践共存。
* Congestion may persist over different time-scales. The time scales that we are concerned with are congestion events that may last longer than a round-trip time.
* 拥堵可能会在不同的时间尺度上持续。我们关注的时间尺度是拥堵事件，其持续时间可能超过往返时间。
* The number of packets in an individual flow (e.g., TCP connection or an exchange using UDP) may range from a small number of packets to quite a large number. We are interested in managing the congestion caused by flows that send enough packets so that they are still active when network feedback reaches them.
* 单个流中的数据包数量（例如，TCP连接或使用UDP的交换）可能从少量数据包到相当大的数据包数量不等。我们感兴趣的是管理由发送足够数据包的流引起的拥塞，以便当网络反馈到达它们时它们仍然处于活动状态。
* Asymmetric routing is likely to be a normal occurrence in the Internet. The path (sequence of links and routers) followed by data packets may be different from the path followed by the acknowledgment packets in the reverse direction.
* 不对称路由很可能是互联网中的正常现象。数据包后面的路径（链路和路由器的序列）可能与反向确认包后面的路径不同。
* Many routers process the "regular" headers in IP packets more efficiently than they process the header information in IP options. This suggests keeping congestion experienced information in the regular headers of an IP packet.
* 许多路由器处理IP数据包中的“常规”报头比处理IP选项中的报头信息更有效。这建议在IP数据包的常规报头中保留拥塞信息。
* It must be recognized that not all end-systems will cooperate in mechanisms for congestion control. However, new mechanisms shouldn't make it easier for TCP applications to disable TCP congestion control. The benefit of lying about participating in new mechanisms such as ECN-capability should be small.
* 必须认识到，并非所有终端系统都会在拥塞控制机制中进行合作。然而，新的机制不应该使TCP应用程序更容易禁用TCP拥塞控制。谎称参与新机制（如ECN能力）的好处应该很小。
Random Early Detection (RED) is one mechanism for Active Queue Management (AQM) that has been proposed to detect incipient congestion [FJ93], and is currently being deployed in the Internet [RFC2309]. AQM is meant to be a general mechanism using one of several alternatives for congestion indication, but in the absence of ECN, AQM is restricted to using packet drops as a mechanism for congestion indication. AQM drops packets based on the average queue length exceeding a threshold, rather than only when the queue overflows. However, because AQM may drop packets before the queue actually overflows, AQM is not always forced by memory limitations to discard the packet.
随机早期检测（RED）是主动队列管理（AQM）的一种机制，已被提出用于检测初期拥塞[FJ93]，目前正在互联网上部署[RFC2309]。AQM是一种通用机制，使用几种拥塞指示替代方案之一，但在没有ECN的情况下，AQM仅限于使用分组丢弃作为拥塞指示机制。AQM根据超过阈值的平均队列长度丢弃数据包，而不仅仅是在队列溢出时。然而，由于AQM可能在队列实际溢出之前丢弃数据包，因此AQM并不总是因为内存限制而被迫丢弃数据包。
AQM can set a Congestion Experienced (CE) codepoint in the packet header instead of dropping the packet, when such a field is provided in the IP header and understood by the transport protocol. The use of the CE codepoint with ECN allows the receiver(s) to receive the packet, avoiding the potential for excessive delays due to retransmissions after packet losses. We use the term 'CE packet' to denote a packet that has the CE codepoint set.
当在IP报头中提供并被传输协议理解时，AQM可以在分组报头中设置拥塞体验（CE）码点而不是丢弃分组。将CE码点与ECN一起使用允许接收机接收分组，避免由于分组丢失后的重新传输而导致过度延迟的可能性。我们使用术语“CE数据包”来表示具有CE码点集的数据包。
This document specifies that the Internet provide a congestion indication for incipient congestion (as in RED and earlier work [RJ90]) where the notification can sometimes be through marking packets rather than dropping them. This uses an ECN field in the IP header with two bits, making four ECN codepoints, '00' to '11'. The ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the data sender to indicate that the end-points of the transport protocol are ECN-capable; we call them ECT(0) and ECT(1) respectively. The phrase "the ECT codepoint" in this documents refers to either of the two ECT codepoints. Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.
本文件规定，互联网为初期拥塞提供拥塞指示（如RED和早期工作[RJ90]），通知有时可以通过标记数据包而不是丢弃数据包。这在IP报头中使用一个带有两位的ECN字段，形成四个ECN代码点，“00”到“11”。数据发送方设置支持ECN的传输（ECT）代码点“10”和“01”，以指示传输协议的端点支持ECN；我们分别称之为ECT（0）和ECT（1）。本文件中的短语“ECT代码点”指两个ECT代码点中的任一个。路由器将ECT（0）和ECT（1）代码点视为等效的。发送方可自由使用ECT（0）或ECT（1）码点，以分组为基础指示ECT。
The use of both the two codepoints for ECT, ECT(0) and ECT(1), is motivated primarily by the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol. Guidelines for the senders and receivers to differentiate between the ECT(0) and ECT(1) codepoints will be addressed in separate documents, for each transport protocol. In particular, this document does not address mechanisms for TCP end-nodes to differentiate between the ECT(0) and ECT(1) codepoints. Protocols and senders that only require a single ECT codepoint SHOULD use ECT(0).
ECT（0）和ECT（1）两个代码点的使用主要是为了允许数据发送方的机制验证网络元素没有擦除CE代码点，并且数据接收方正确地向发送方报告接收到带有CE代码点集的数据包，按照传输协议的要求。对于每个传输协议，发送方和接收方区分ECT（0）和ECT（1）码点的指南将在单独的文件中说明。特别是，本文档不介绍TCP端节点区分ECT（0）和ECT（1）代码点的机制。仅需要单个ECT码点的协议和发送方应使用ECT（0）。
The not-ECT codepoint '00' indicates a packet that is not using ECN. The CE codepoint '11' is set by a router to indicate congestion to the end nodes. Routers that have a packet arriving at a full queue drop the packet, just as they do in the absence of ECN.
not ECT代码点“00”表示未使用ECN的数据包。CE码点“11”由路由器设置，以指示终端节点的拥塞。有数据包到达完整队列的路由器丢弃数据包，就像在没有ECN的情况下一样。
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 1: The ECN Field in IP.
图1:IP中的ECN字段。
The use of two ECT codepoints essentially gives a one-bit ECN nonce in packet headers, and routers necessarily "erase" the nonce when they set the CE codepoint [SCWA99]. For example, routers that erased the CE codepoint would face additional difficulty in reconstructing the original nonce, and thus repeated erasure of the CE codepoint would be more likely to be detected by the end-nodes. The ECN nonce also can address the problem of misbehaving transport receivers lying to the transport sender about whether or not the CE codepoint was set in a packet. The motivations for the use of two ECT codepoints is discussed in more detail in Section 20, along with some discussion of alternate possibilities for the fourth ECT codepoint (that is, the codepoint '01'). Backwards compatibility with earlier ECN implementations that do not understand the ECT(1) codepoint is discussed in Section 11.
使用两个ECT码点基本上会在包头中产生一位ECN nonce，路由器在设置CE码点时必须“擦除”该nonce[SCWA99]。例如，擦除CE码点的路由器在重建原始nonce时将面临额外的困难，因此，终端节点更有可能检测到对CE码点的重复擦除。ECN nonce还可以解决传输接收方向传输发送方谎报CE码点是否在数据包中设置的问题。第20节更详细地讨论了使用两个ECT代码点的动机，同时还讨论了第四个ECT代码点（即代码点“01”）的替代可能性。第11节讨论了与不理解ECT（1）代码点的早期ECN实现的向后兼容性。
In RFC 2481 [RFC2481], the ECN field was divided into the ECN-Capable Transport (ECT) bit and the CE bit. The ECN field with only the ECN-Capable Transport (ECT) bit set in RFC 2481 corresponds to the ECT(0) codepoint in this document, and the ECN field with both the
在RFC22481[RFC2481]中，ECN字段被划分为支持ECN的传输（ECT）位和CE位。RFC 2481中仅设置了ECN可传输（ECT）位的ECN字段对应于本文档中的ECT（0）码点，ECN字段同时具有
ECT and CE bit in RFC 2481 corresponds to the CE codepoint in this document. The '01' codepoint was left undefined in RFC 2481, and this is the reason for recommending the use of ECT(0) when only a single ECT codepoint is needed.
RFC 2481中的ECT和CE位对应于本文档中的CE代码点。RFC 2481中未定义“01”代码点，因此建议在只需要一个ECT代码点时使用ECT（0）。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint ECN: Explicit Congestion Notification
DSCP:区分服务代码点ECN:显式拥塞通知
Figure 2: The Differentiated Services and ECN Fields in IP.
图2:IP中的区分服务和ECN字段。
Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field. The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6, and the ECN field is defined identically in both cases. The definitions for the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet have been superseded by the six-bit DS (Differentiated Services) Field [RFC2474, RFC2780]. Bits 6 and 7 are listed in [RFC2474] as Currently Unused, and are specified in RFC 2780 as approved for experimental use for ECN. Section 22 gives a brief history of the TOS octet.
IPv4 TOS八位字节中的第6位和第7位被指定为ECN字段。IPv4 TOS八位字节对应于IPv6中的流量类八位字节，在这两种情况下，ECN字段的定义相同。IPv4 TOS八位字节[RFC791]和IPv6流量类八位字节的定义已被六位DS（区分服务）字段[RFC2474，RFC2780]取代。位6和位7在[RFC2474]中列出为当前未使用，并在RFC 2780中指定为经批准用于ECN的实验用途。第22节给出了TOS八重奏的简要历史。
Because of the unstable history of the TOS octet, the use of the ECN field as specified in this document cannot be guaranteed to be backwards compatible with those past uses of these two bits that pre-date ECN. The potential dangers of this lack of backwards compatibility are discussed in Section 22.
由于TOS八位字节的历史不稳定，本文件中规定的ECN字段的使用不能保证与ECN之前这两个位的过去使用向后兼容。第22节讨论了缺乏向后兼容性的潜在危险。
Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet. For example, for ECN-Capable TCP the source TCP is required to halve its congestion window for any window of data containing either a packet drop or an ECN indication.
当具有ECN能力的传输接收到单个CE分组时，终端系统遵循的拥塞控制算法必须与对*单个*丢弃分组的拥塞控制响应基本相同。例如，对于支持ECN的TCP，源TCP需要将包含丢包或ECN指示的任何数据窗口的拥塞窗口减半。
One reason for requiring that the congestion-control response to the CE packet be essentially the same as the response to a dropped packet is to accommodate the incremental deployment of ECN in both end-systems and in routers. Some routers may drop ECN-Capable packets (e.g., using the same AQM policies for congestion detection) while other routers set the CE codepoint, for equivalent levels of congestion. Similarly, a router might drop a non-ECN-Capable packet but set the CE codepoint in an ECN-Capable packet, for equivalent
要求对CE分组的拥塞控制响应基本上与对丢弃分组的响应相同的一个原因是为了适应终端系统和路由器中ECN的增量部署。一些路由器可能丢弃支持ECN的数据包（例如，使用相同的AQM策略进行拥塞检测），而其他路由器则设置CE码点，以实现同等级别的拥塞。类似地，路由器可能会丢弃不支持ECN的数据包，但会在支持ECN的数据包中设置CE码点，以实现等效
levels of congestion. If there were different congestion control responses to a CE codepoint than to a packet drop, this could result in unfair treatment for different flows.
拥挤程度。如果对CE码点的拥塞控制响应与对分组丢弃的拥塞控制响应不同，则可能导致对不同流的不公平处理。
An additional goal is that the end-systems should react to congestion at most once per window of data (i.e., at most once per round-trip time), to avoid reacting multiple times to multiple indications of congestion within a round-trip time.
另一个目标是，终端系统应在每个数据窗口最多对拥塞做出一次反应（即，在每个往返时间最多一次），以避免在往返时间内对多个拥塞指示做出多次反应。
For a router, the CE codepoint of an ECN-Capable packet SHOULD only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes. When the router's buffer is not yet full and the router is prepared to drop a packet to inform end nodes of incipient congestion, the router should first check to see if the ECT codepoint is set in that packet's IP header. If so, then instead of dropping the packet, the router MAY instead set the CE codepoint in the IP header.
对于路由器而言，只有当路由器以其他方式丢弃数据包作为对终端节点的拥塞指示时，才应设置支持ECN的数据包的CE码点。当路由器的缓冲区尚未满且路由器准备丢弃数据包以通知终端节点初始拥塞时，路由器应首先检查该数据包的IP报头中是否设置了ECT码点。如果是这样，那么路由器可以代替在IP报头中设置CE码点，而不是丢弃分组。
An environment where all end nodes were ECN-Capable could allow new criteria to be developed for setting the CE codepoint, and new congestion control mechanisms for end-node reaction to CE packets. However, this is a research issue, and as such is not addressed in this document.
在一个所有终端节点都支持ECN的环境中，可以为设置CE码点制定新的标准，并为终端节点对CE数据包的反应制定新的拥塞控制机制。然而，这是一个研究问题，因此，本文件未涉及。
When a CE packet (i.e., a packet that has the CE codepoint set) is received by a router, the CE codepoint is left unchanged, and the packet is transmitted as usual. When severe congestion has occurred and the router's queue is full, then the router has no choice but to drop some packet when a new packet arrives. We anticipate that such packet losses will become relatively infrequent when a majority of end-systems become ECN-Capable and participate in TCP or other compatible congestion control mechanisms. In an ECN-Capable environment that is adequately-provisioned, packet losses should occur primarily during transients or in the presence of non-cooperating sources.
当路由器接收到CE分组（即，具有CE码点集的分组）时，CE码点保持不变，并且分组照常发送。当发生严重拥塞且路由器队列已满时，路由器别无选择，只能在新数据包到达时丢弃一些数据包。我们预计，当大多数终端系统具备ECN能力并参与TCP或其他兼容的拥塞控制机制时，此类数据包丢失将相对较少。在充分配置的支持ECN的环境中，数据包丢失应主要发生在瞬变期间或存在非合作源的情况下。
The above discussion of when CE may be set instead of dropping a packet applies by default to all Differentiated Services Per-Hop Behaviors (PHBs) [RFC 2475]. Specifications for PHBs MAY provide more specifics on how a compliant implementation is to choose between setting CE and dropping a packet, but this is NOT REQUIRED. A router MUST NOT set CE instead of dropping a packet when the drop that would occur is caused by reasons other than congestion or the desire to indicate incipient congestion to end nodes (e.g., a diffserv edge node may be configured to unconditionally drop certain classes of traffic to prevent them from entering its diffserv domain).
上述关于何时可以设置CE而不是丢弃分组的讨论默认情况下适用于所有区分服务每跳行为（phb）[RFC 2475]。PHB规范可以提供更多关于兼容实现如何在设置CE和丢弃数据包之间进行选择的细节，但这不是必需的。当可能发生的丢包是由拥塞以外的原因或向终端节点指示初始拥塞的愿望引起时，路由器不得设置CE而不是丢包（例如，区分服务边缘节点可被配置为无条件丢包某些类别的流量，以防止它们进入其区分服务域）。
We expect that routers will set the CE codepoint in response to incipient congestion as indicated by the average queue size, using the RED algorithms suggested in [FJ93, RFC2309]. To the best of our knowledge, this is the only proposal currently under discussion in the IETF for routers to drop packets proactively, before the buffer overflows. However, this document does not attempt to specify a particular mechanism for active queue management, leaving that endeavor, if needed, to other areas of the IETF. While ECN is inextricably tied up with the need to have a reasonable active queue management mechanism at the router, the reverse does not hold; active queue management mechanisms have been developed and deployed independent of ECN, using packet drops as indications of congestion in the absence of ECN in the IP architecture.
我们预计路由器将使用[FJ93，RFC2309]中建议的RED算法设置CE码点，以响应平均队列大小指示的初始拥塞。据我们所知，这是IETF中目前讨论的唯一一个建议，即路由器在缓冲区溢出之前主动丢弃数据包。然而，本文档并不试图为主动队列管理指定特定的机制，如果需要，将此工作留给IETF的其他领域。虽然ECN与在路由器上需要一个合理的主动队列管理机制密不可分，但反过来就不行了；主动队列管理机制的开发和部署独立于ECN，在IP体系结构中使用丢包作为没有ECN的拥塞指示。
We emphasize that a *single* packet with the CE codepoint set in an IP packet causes the transport layer to respond, in terms of congestion control, as it would to a packet drop. The instantaneous queue size is likely to see considerable variations even when the router does not experience persistent congestion. As such, it is important that transient congestion at a router, reflected by the instantaneous queue size reaching a threshold much smaller than the capacity of the queue, not trigger a reaction at the transport layer. Therefore, the CE codepoint should not be set by a router based on the instantaneous queue size.
我们强调，在IP数据包中设置CE码点的*单个*数据包会导致传输层在拥塞控制方面做出响应，就像对数据包丢弃做出响应一样。即使在路由器没有经历持续拥塞的情况下，瞬时队列大小也可能会出现相当大的变化。因此，重要的是，路由器上的瞬时拥塞（由达到远小于队列容量的阈值的瞬时队列大小反映）不会触发传输层的反应。因此，不应由路由器基于瞬时队列大小设置CE码点。
For example, since the ATM and Frame Relay mechanisms for congestion indication have typically been defined without an associated notion of average queue size as the basis for determining that an intermediate node is congested, we believe that they provide a very noisy signal. The TCP-sender reaction specified in this document for ECN is NOT the appropriate reaction for such a noisy signal of congestion notification. However, if the routers that interface to the ATM network have a way of maintaining the average queue at the interface, and use it to come to a reliable determination that the ATM subnet is congested, they may use the ECN notification that is defined here.
例如，由于用于拥塞指示的ATM和帧中继机制通常是在没有平均队列大小的相关概念作为确定中间节点拥塞的基础的情况下定义的，因此我们认为它们提供了非常嘈杂的信号。本文档中针对ECN指定的TCP发送方反应不是针对此类拥塞通知的嘈杂信号的适当反应。然而，如果与ATM网络连接的路由器有办法维持接口处的平均队列，并使用它来可靠地确定ATM子网拥塞，则它们可以使用此处定义的ECN通知。
We continue to encourage experiments in techniques at layer 2 (e.g., in ATM switches or Frame Relay switches) to take advantage of ECN. For example, using a scheme such as RED (where packet marking is based on the average queue length exceeding a threshold), layer 2 devices could provide a reasonably reliable indication of congestion. When all the layer 2 devices in a path set that layer's own Congestion Experienced codepoint (e.g., the EFCI bit for ATM, the FECN bit in Frame Relay) in this reliable manner, then the interface router to the layer 2 network could copy the state of that layer 2
我们继续鼓励在第2层（如ATM交换机或帧中继交换机）进行技术实验，以利用ECN。例如，使用诸如RED的方案（其中分组标记基于超过阈值的平均队列长度），第2层设备可以提供合理可靠的拥塞指示。当路径中的所有第2层设备设置该层自身的拥塞以这种可靠方式经历码点（例如，ATM的EFCI位、帧中继中的FECN位）时，则到第2层网络的接口路由器可以复制该第2层的状态
Congestion Experienced codepoint into the CE codepoint in the IP header. We recognize that this is not the current practice, nor is it in current standards. However, encouraging experimentation in this manner may provide the information needed to enable evolution of existing layer 2 mechanisms to provide a more reliable means of congestion indication, when they use a single bit for indicating congestion.
IP报头中的CE代码点发生拥塞。我们认识到，这不是当前的做法，也不是当前的标准。然而，以这种方式鼓励实验可以提供所需的信息，以使现有的第2层机制在使用单个比特指示拥塞时能够进化，从而提供更可靠的拥塞指示方法。
For the proposed use for ECN in this document (that is, for a transport protocol such as TCP for which a dropped data packet is an indication of congestion), end nodes detect dropped data packets, and the congestion response of the end nodes to a dropped data packet is at least as strong as the congestion response to a received CE packet. To ensure the reliable delivery of the congestion indication of the CE codepoint, an ECT codepoint MUST NOT be set in a packet unless the loss of that packet in the network would be detected by the end nodes and interpreted as an indication of congestion.
对于本文中对ECN的提议使用（即，对于诸如TCP之类的传输协议，丢弃的数据分组是拥塞的指示），终端节点检测丢弃的数据分组，并且终端节点对丢弃的数据分组的拥塞响应至少与对接收到的CE分组的拥塞响应一样强。为了确保CE码点的拥塞指示的可靠传递，除非终端节点将检测到网络中该分组的丢失并将其解释为拥塞指示，否则不得在分组中设置ECT码点。
Transport protocols such as TCP do not necessarily detect all packet drops, such as the drop of a "pure" ACK packet; for example, TCP does not reduce the arrival rate of subsequent ACK packets in response to an earlier dropped ACK packet. Any proposal for extending ECN-Capability to such packets would have to address issues such as the case of an ACK packet that was marked with the CE codepoint but was later dropped in the network. We believe that this aspect is still the subject of research, so this document specifies that at this time, "pure" ACK packets MUST NOT indicate ECN-Capability.
TCP等传输协议不一定检测所有丢包，例如“纯”ACK数据包的丢包；例如，TCP不会降低后续ACK数据包的到达率，以响应先前丢弃的ACK数据包。任何将ECN能力扩展到此类数据包的建议都必须解决诸如用CE码点标记但后来在网络中丢弃的ACK数据包的情况等问题。我们认为这方面仍然是研究的主题，因此本文件规定，此时，“纯”ACK数据包不得表示ECN能力。
Similarly, if a CE packet is dropped later in the network due to corruption (bit errors), the end nodes should still invoke congestion control, just as TCP would today in response to a dropped data packet. This issue of corrupted CE packets would have to be considered in any proposal for the network to distinguish between packets dropped due to corruption, and packets dropped due to congestion or buffer overflow. In particular, the ubiquitous deployment of ECN would not, in and of itself, be a sufficient development to allow end-nodes to interpret packet drops as indications of corruption rather than congestion.
类似地，如果CE数据包稍后由于损坏（位错误）而在网络中被丢弃，则终端节点仍应调用拥塞控制，就像TCP今天响应丢弃的数据包一样。在任何关于网络的提案中，都必须考虑损坏CE数据包的问题，以区分由于损坏而丢弃的数据包和由于拥塞或缓冲区溢出而丢弃的数据包。特别是，无处不在的ECN部署本身并不足以让终端节点将丢包解释为损坏而不是拥塞的迹象。
ECN-capable packets MAY have the DF (Don't Fragment) bit set. Reassembly of a fragmented packet MUST NOT lose indications of congestion. In other words, if any fragment of an IP packet to be reassembled has the CE codepoint set, then one of two actions MUST be taken:
支持ECN的数据包可以设置DF（不分段）位。碎片数据包的重新组装不得丢失拥塞指示。换句话说，如果要重新组装的IP数据包的任何片段具有CE码点集，则必须采取以下两种操作之一：
* Set the CE codepoint on the reassembled packet. However, this MUST NOT occur if any of the other fragments contributing to this reassembly carries the Not-ECT codepoint.
* 在重新组装的数据包上设置CE代码点。但是，如果参与重新组装的任何其他片段携带NOT ECT代码点，则不得发生这种情况。
* The packet is dropped, instead of being reassembled, for any other reason.
* 由于任何其他原因，数据包被丢弃，而不是重新组装。
If both actions are applicable, either MAY be chosen. Reassembly of a fragmented packet MUST NOT change the ECN codepoint when all of the fragments carry the same codepoint.
如果两种操作都适用，则可以选择其中一种。当所有片段携带相同的代码点时，碎片数据包的重新组装不得改变ECN代码点。
We would note that because RFC 2481 did not specify reassembly behavior, older ECN implementations conformant with that Experimental RFC do not necessarily perform reassembly correctly, in terms of preserving the CE codepoint in a fragment. The sender could avoid the consequences of this behavior by setting the DF bit in ECN-Capable packets.
我们会注意到，因为RFC2481没有指定重组行为，所以与实验性RFC一致的旧ECN实现不一定能够正确地执行重组，即在片段中保留CE代码点。发送方可以通过在支持ECN的数据包中设置DF位来避免这种行为的后果。
Situations may arise in which the above reassembly specification is insufficiently precise. For example, if there is a malicious or broken entity in the path at or after the fragmentation point, packet fragments could carry a mixture of ECT(0), ECT(1), and/or Not-ECT codepoints. The reassembly specification above does not place requirements on reassembly of fragments in this case. In situations where more precise reassembly behavior would be required, protocol specifications SHOULD instead specify that DF MUST be set in all ECN-capable packets sent by the protocol.
可能出现上述重新组装规范不够精确的情况。例如，如果在碎片点处或之后的路径中存在恶意或已破坏的实体，则数据包碎片可能携带ECT（0）、ECT（1）和/或非ECT代码点的混合物。上述重新组装规范并未对这种情况下的碎片重新组装提出要求。在需要更精确的重新组装行为的情况下，协议规范应规定必须在协议发送的所有支持ECN的数据包中设置DF。
ECN requires support from the transport protocol, in addition to the functionality given by the ECN field in the IP packet header. The transport protocol might require negotiation between the endpoints during setup to determine that all of the endpoints are ECN-capable, so that the sender can set the ECT codepoint in transmitted packets. Second, the transport protocol must be capable of reacting appropriately to the receipt of CE packets. This reaction could be in the form of the data receiver informing the data sender of the received CE packet (e.g., TCP), of the data receiver unsubscribing to a layered multicast group (e.g., RLM [MJV96]), or of some other action that ultimately reduces the arrival rate of that flow on that congested link. CE packets indicate persistent rather than transient congestion (see Section 5.1), and hence reactions to the receipt of CE packets should be those appropriate for persistent congestion.
除了IP数据包头中的ECN字段提供的功能外，ECN还需要传输协议的支持。传输协议可能需要在设置期间在端点之间进行协商，以确定所有端点都支持ECN，以便发送方可以在传输的数据包中设置ECT码点。第二，传输协议必须能够对CE数据包的接收做出适当的反应。该反应可以是数据接收器通知数据发送者所接收的CE分组（例如，TCP）、数据接收器取消订阅分层多播组（例如，RLM[MJV96]）或最终降低该流在该拥塞链路上的到达率的一些其他动作的形式。CE数据包表示持续拥塞而非暂时拥塞（见第5.1节），因此，对接收CE数据包的反应应适用于持续拥塞。
This document only addresses the addition of ECN Capability to TCP, leaving issues of ECN in other transport protocols to further research. For TCP, ECN requires three new pieces of functionality:
本文档仅讨论TCP中添加的ECN功能，其他传输协议中的ECN问题有待进一步研究。对于TCP，ECN需要三项新功能：
negotiation between the endpoints during connection setup to determine if they are both ECN-capable; an ECN-Echo (ECE) flag in the TCP header so that the data receiver can inform the data sender when a CE packet has been received; and a Congestion Window Reduced (CWR) flag in the TCP header so that the data sender can inform the data receiver that the congestion window has been reduced. The support required from other transport protocols is likely to be different, particularly for unreliable or reliable multicast transport protocols, and will have to be determined as other transport protocols are brought to the IETF for standardization.
连接设置期间端点之间的协商，以确定它们是否都支持ECN；TCP报头中的ECN Echo（ECE）标志，以便数据接收器可以在接收到CE数据包时通知数据发送者；以及TCP报头中的拥塞窗口缩减（CWR）标志，以便数据发送方可以通知数据接收方拥塞窗口已经缩减。其他传输协议所需的支持可能会有所不同，特别是对于不可靠或可靠的多播传输协议，并且必须在其他传输协议被提交给IETF进行标准化时确定。
In a mild abuse of terminology, in this document we refer to `TCP packets' instead of `TCP segments'.
在轻度滥用术语的情况下，在本文档中，我们指的是“TCP数据包”，而不是“TCP段”。
The following sections describe in detail the proposed use of ECN in TCP. This proposal is described in essentially the same form in [Floyd94]. We assume that the source TCP uses the standard congestion control algorithms of Slow-start, Fast Retransmit and Fast Recovery [RFC2581].
以下各节详细介绍了在TCP中使用ECN的建议。该提案在[Floyd94]中的描述形式基本相同。我们假设源TCP使用标准的拥塞控制算法，即慢启动、快速重传和快速恢复[RFC2581]。
This proposal specifies two new flags in the Reserved field of the TCP header. The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 4 of RFC 793 [RFC793] (and is reproduced below for completeness). This specification of the ECN Field leaves the Reserved field as a 4-bit field using bits 4-7.
此建议在TCP标头的保留字段中指定两个新标志。协商ECN能力的TCP机制使用TCP报头中的ECN Echo（ECE）标志。TCP报头保留字段中的第9位被指定为ECN Echo标志。TCP报头中6位保留字段的位置如RFC 793[RFC793]的图4所示（为了完整起见，在下面复制）。ECN字段的此规范将保留字段保留为使用位4-7的4位字段。
To enable the TCP receiver to determine when to stop setting the ECN-Echo flag, we introduce a second new flag in the TCP header, the CWR flag. The CWR flag is assigned to Bit 8 in the Reserved field of the TCP header.
为了使TCP接收器能够确定何时停止设置ECN Echo标志，我们在TCP报头中引入了第二个新标志，即CWR标志。CWR标志分配给TCP标头保留字段中的位8。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: The old definition of bytes 13 and 14 of the TCP header.
图3:TCP头字节13和14的旧定义。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: The new definition of bytes 13 and 14 of the TCP Header.
图4:TCP头字节13和14的新定义。
Thus, ECN uses the ECT and CE flags in the IP header (as shown in Figure 1) for signaling between routers and connection endpoints, and uses the ECN-Echo and CWR flags in the TCP header (as shown in Figure 4) for TCP-endpoint to TCP-endpoint signaling. For a TCP connection, a typical sequence of events in an ECN-based reaction to congestion is as follows:
因此，ECN使用IP报头中的ECT和CE标志（如图1所示）在路由器和连接端点之间发送信号，并使用TCP报头中的ECN Echo和CWR标志（如图4所示）在TCP端点到TCP端点之间发送信号。对于TCP连接，基于ECN的拥塞反应中的典型事件序列如下：
* An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is supported by the transport entities for these packets.
* 在发送方传输的数据包中设置ECT码点，以指示传输实体对这些数据包支持ECN。
* An ECN-capable router detects impending congestion and detects that an ECT codepoint is set in the packet it is about to drop. Instead of dropping the packet, the router chooses to set the CE codepoint in the IP header and forwards the packet.
* 支持ECN的路由器检测即将发生的拥塞，并检测到将要丢弃的数据包中设置了ECT码点。路由器选择在IP报头中设置CE码点并转发数据包，而不是丢弃数据包。
* The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender.
* 接收方接收到设置了CE码点的数据包，并在发送给发送方的下一个TCP ACK中设置ECN Echo标志。
* The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion as if a packet had been dropped.
* 发送方接收设置了ECN Echo的TCP ACK，并对拥塞做出反应，就像丢包一样。
* The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag.
* 发送方在发送给接收方的下一个数据包的TCP报头中设置CWR标志，以确认其收到ECN回波标志并对其作出反应。
The negotiation for using ECN by the TCP transport entities and the use of the ECN-Echo and CWR flags is described in more detail in the sections below.
TCP传输实体使用ECN的协商以及ECN Echo和CWR标志的使用将在以下各节中进行更详细的描述。
In the TCP connection setup phase, the source and destination TCPs exchange information about their willingness to use ECN. Subsequent to the completion of this negotiation, the TCP sender sets an ECT codepoint in the IP header of data packets to indicate to the network that the transport is capable and willing to participate in ECN for this packet. This indicates to the routers that they may mark this
在TCP连接设置阶段，源TCP和目标TCP交换有关其使用ECN意愿的信息。在完成该协商之后，TCP发送方在数据分组的IP报头中设置ECT码点，以向网络指示传输能够并且愿意参与该分组的ECN。这向路由器表明，它们可能会标记这一点
packet with the CE codepoint, if they would like to use that as a method of congestion notification. If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet.
带有CE代码点的数据包，如果他们想将其用作拥塞通知的方法。如果TCP连接不希望对特定数据包使用ECN通知，则发送TCP将ECN代码点设置为not ECT，并且TCP接收器忽略接收数据包中的CE代码点。
For this discussion, we designate the initiating host as Host A and the responding host as Host B. We call a SYN packet with the ECE and CWR flags set an "ECN-setup SYN packet", and we call a SYN packet with at least one of the ECE and CWR flags not set a "non-ECN-setup SYN packet". Similarly, we call a SYN-ACK packet with only the ECE flag set but the CWR flag not set an "ECN-setup SYN-ACK packet", and we call a SYN-ACK packet with any other configuration of the ECE and CWR flags a "non-ECN-setup SYN-ACK packet".
对于本讨论，我们将发起主机指定为主机A，将响应主机指定为主机B。我们将ECE和CWR标志设置为“ECN设置SYN包”的SYN包称为“ECN设置SYN包”，并将至少一个ECE和CWR标志未设置为“非ECN设置SYN包”的SYN包称为“非ECN设置SYN包”。类似地，我们将仅设置ECE标志但未设置CWR标志的SYN-ACK数据包称为“ECN设置SYN-ACK数据包”，并将具有ECE和CWR标志的任何其他配置的SYN-ACK数据包称为“非ECN设置SYN-ACK数据包”。
Before a TCP connection can use ECN, Host A sends an ECN-setup SYN packet, and Host B sends an ECN-setup SYN-ACK packet. For a SYN packet, the setting of both ECE and CWR in the ECN-setup SYN packet is defined as an indication that the sending TCP is ECN-Capable, rather than as an indication of congestion or of response to congestion. More precisely, an ECN-setup SYN packet indicates that the TCP implementation transmitting the SYN packet will participate in ECN as both a sender and receiver. Specifically, as a receiver, it will respond to incoming data packets that have the CE codepoint set in the IP header by setting ECE in outgoing TCP Acknowledgement (ACK) packets. As a sender, it will respond to incoming packets that have ECE set by reducing the congestion window and setting CWR when appropriate. An ECN-setup SYN packet does not commit the TCP sender to setting the ECT codepoint in any or all of the packets it may transmit. However, the commitment to respond appropriately to incoming packets with the CE codepoint set remains even if the TCP sender in a later transmission, within this TCP connection, sends a SYN packet without ECE and CWR set.
在TCP连接可以使用ECN之前，主机a发送ECN setup SYN数据包，主机B发送ECN setup SYN-ACK数据包。对于SYN分组，ECN setup SYN分组中ECE和CWR的设置被定义为发送TCP具有ECN能力的指示，而不是拥塞或拥塞响应的指示。更准确地说，ECN setup SYN数据包表示传输SYN数据包的TCP实现将作为发送方和接收方参与ECN。具体地说，作为接收器，它将通过在传出TCP确认（ACK）数据包中设置ECE来响应在IP报头中设置了CE码点的传入数据包。作为发送方，它将通过减少拥塞窗口并在适当时设置CWR来响应设置了ECE的传入数据包。ECN setup SYN数据包不会让TCP发送方在其可能传输的任何或所有数据包中设置ECT码点。然而，即使稍后传输中的TCP发送方在该TCP连接内发送不带ECE和CWR集的SYN数据包，也仍然承诺使用CE码点集适当响应传入数据包。
When Host B sends an ECN-setup SYN-ACK packet, it sets the ECE flag but not the CWR flag. An ECN-setup SYN-ACK packet is defined as an indication that the TCP transmitting the SYN-ACK packet is ECN-Capable. As with the SYN packet, an ECN-setup SYN-ACK packet does not commit the TCP host to setting the ECT codepoint in transmitted packets.
当主机B发送ECN setup SYN-ACK数据包时，它设置ECE标志，但不设置CWR标志。ECN设置SYN-ACK数据包被定义为传输SYN-ACK数据包的TCP具有ECN能力的指示。与SYN数据包一样，ECN setup SYN-ACK数据包不会让TCP主机在传输的数据包中设置ECT代码点。
The following rules apply to the sending of ECN-setup packets within a TCP connection, where a TCP connection is defined by the standard rules for TCP connection establishment and termination.
以下规则适用于在TCP连接内发送ECN设置数据包，其中TCP连接由TCP连接建立和终止的标准规则定义。
* If a host has received an ECN-setup SYN packet, then it MAY send an ECN-setup SYN-ACK packet. Otherwise, it MUST NOT send an ECN-setup SYN-ACK packet.
* 如果主机已收到ECN setup SYN数据包，则可能会发送ECN setup SYN-ACK数据包。否则，它不能发送ECN setup SYN-ACK数据包。
* A host MUST NOT set ECT on data packets unless it has sent at least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has received at least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has sent no non-ECN-setup SYN or non-ECN-setup SYN-ACK packet. If a host has received at least one non-ECN-setup SYN or non-ECN-setup SYN-ACK packet, then it SHOULD NOT set ECT on data packets.
* 除非主机已发送至少一个ECN setup SYN或ECN setup SYN-ACK数据包，且已接收至少一个ECN setup SYN或ECN setup SYN-ACK数据包，且未发送任何非ECN setup SYN或非ECN setup SYN-ACK数据包，否则不得在数据包上设置ECT。如果主机至少收到一个非ECN setup SYN或非ECN setup SYN-ACK数据包，则不应在数据包上设置ECT。
* If a host ever sets the ECT codepoint on a data packet, then that host MUST correctly set/clear the CWR TCP bit on all subsequent packets in the connection.
* 如果主机在数据包上设置过ECT代码点，则该主机必须在连接中的所有后续数据包上正确设置/清除CWR TCP位。
* If a host has sent at least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has received no non-ECN-setup SYN or non-ECN-setup SYN-ACK packet, then if that host receives TCP data packets with ECT and CE codepoints set in the IP header, then that host MUST process these packets as specified for an ECN-capable connection.
* 如果主机已发送至少一个ECN setup SYN或ECN setup SYN-ACK数据包，且未收到任何非ECN setup SYN或非ECN setup SYN-ACK数据包，则如果该主机收到IP报头中设置了ECT和CE代码点的TCP数据包，则该主机必须按照为支持ECN的连接指定的方式处理这些数据包。
* A host that is not willing to use ECN on a TCP connection SHOULD clear both the ECE and CWR flags in all non-ECN-setup SYN and/or SYN-ACK packets that it sends to indicate this unwillingness. Receivers MUST correctly handle all forms of the non-ECN-setup SYN and SYN-ACK packets.
* 不愿意在TCP连接上使用ECN的主机应清除其发送的所有非ECN设置SYN和/或SYN-ACK数据包中的ECE和CWR标志，以表示不愿意。接收机必须正确处理所有形式的非ECN设置SYN和SYN-ACK数据包。
* A host MUST NOT set ECT on SYN or SYN-ACK packets.
* 主机不得在SYN或SYN-ACK数据包上设置ECT。
A TCP client enters TIME-WAIT state after receiving a FIN-ACK, and transitions to CLOSED state after a timeout. Many TCP implementations create a new TCP connection if they receive an in-window SYN packet during TIME-WAIT state. When a TCP host enters TIME-WAIT or CLOSED state, it should ignore any previous state about the negotiation of ECN for that connection.
TCP客户端在接收到FIN-ACK后进入TIME-WAIT状态，并在超时后转换为CLOSED状态。如果许多TCP实现在等待时间状态下接收到窗口内SYN数据包，则会创建新的TCP连接。当TCP主机进入TIME-WAIT（等待）或CLOSED（关闭）状态时，它应该忽略关于该连接的ECN协商的任何先前状态。
ECN introduces the use of the ECN-Echo and CWR flags in the TCP header (as shown in Figure 3) for initialization. There exist some faulty firewalls, load balancers, and intrusion detection systems in the Internet that either drop an ECN-setup SYN packet or respond with a RST, in the belief that such a packet (with these bits set) is a signature for a port-scanning tool that could be used in a denial-of-service attack. Some of the offending equipment has been identified, and a web page [FIXES] contains a list of non-compliant products and the fixes posted by the vendors, where these are available. The TBIT web page [TBIT] lists some of the web servers affected by this faulty equipment. We mention this in this document as a warning to the community of this problem.
ECN引入了在TCP头中使用ECN Echo和CWR标志进行初始化（如图3所示）。Internet上存在一些有故障的防火墙、负载平衡器和入侵检测系统，它们丢弃ECN setup SYN数据包或使用RST响应，认为这样的数据包（设置了这些位）是端口扫描工具的特征码，可用于拒绝服务攻击。一些违规设备已经被识别，并且一个网页[FIXES]包含一个不符合标准的产品列表和供应商发布的修复程序（如果有）。TBIT网页[TBIT]列出了受此故障设备影响的一些web服务器。我们在本文件中提到这一点，是为了警告社区这个问题。
To provide robust connectivity even in the presence of such faulty equipment, a host that receives a RST in response to the transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. This could result in a TCP connection being established without using ECN.
为了即使在存在此类故障设备的情况下也提供健壮的连接，响应于ECN设置SYN分组的传输而接收RST的主机可以在CWR和ECE被清除的情况下重新发送SYN。这可能导致在不使用ECN的情况下建立TCP连接。
A host that receives no reply to an ECN-setup SYN within the normal SYN retransmission timeout interval MAY resend the SYN and any subsequent SYN retransmissions with CWR and ECE cleared. To overcome normal packet loss that results in the original SYN being lost, the originating host may retransmit one or more ECN-setup SYN packets before giving up and retransmitting the SYN with the CWR and ECE bits cleared.
在正常SYN重传超时间隔内未收到对ECN设置SYN的回复的主机可以在清除CWR和ECE的情况下重新发送SYN和任何后续SYN重传。为了克服导致原始SYN丢失的正常分组丢失，发起主机可以在放弃并在清除CWR和ECE位的情况下重新传输SYN之前重新传输一个或多个ECN setup SYN分组。
We note that in this case, the following example scenario is possible:
我们注意到，在这种情况下，以下示例场景是可能的：
(1) Host A: Sends an ECN-setup SYN. (2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped or delayed. (3) Host A: Sends a non-ECN-setup SYN. (4) Host B: Sends a non-ECN-setup SYN/ACK.
(1) 主机A：发送ECN设置SYN。（2） 主机B：发送ECN设置SYN/ACK，数据包被丢弃或延迟。（3） 主机A：发送非ECN设置SYN。（4） 主机B：发送非ECN设置SYN/ACK。
We note that in this case, following the procedures above, neither Host A nor Host B may set the ECT bit on data packets. Further, an important consequence of the rules for ECN setup and usage in Section 6.1.1 is that a host is forbidden from using the reception of ECT data packets as an implicit signal that the other host is ECN-capable.
我们注意到，在这种情况下，按照上述步骤，主机A和主机B都不能在数据包上设置ECT位。此外，第6.1.1节中ECN设置和使用规则的一个重要结果是，禁止主机将ECT数据包的接收用作另一主机具有ECN能力的隐式信号。
There is the question of why we chose to have the TCP sending the SYN set two ECN-related flags in the Reserved field of the TCP header for the SYN packet, while the responding TCP sending the SYN-ACK sets only one ECN-related flag in the SYN-ACK packet. This asymmetry is necessary for the robust negotiation of ECN-capability with some deployed TCP implementations. There exists at least one faulty TCP implementation in which TCP receivers set the Reserved field of the TCP header in ACK packets (and hence the SYN-ACK) simply to reflect the Reserved field of the TCP header in the received data packet. Because the TCP SYN packet sets the ECN-Echo and CWR flags to indicate ECN-capability, while the SYN-ACK packet sets only the ECN-Echo flag, the sending TCP correctly interprets a receiver's reflection of its own flags in the Reserved field as an indication that the receiver is not ECN-capable. The sending TCP is not mislead by a faulty TCP implementation sending a SYN-ACK packet that simply reflects the Reserved field of the incoming SYN packet.
问题是，为什么我们选择让发送SYN的TCP在SYN数据包的TCP头的保留字段中设置两个ECN相关标志，而发送SYN-ACK的响应TCP在SYN-ACK数据包中仅设置一个ECN相关标志。这种不对称性对于ECN能力与一些已部署的TCP实现的健壮协商是必要的。至少存在一种错误的TCP实现，其中TCP接收器在ACK数据包中设置TCP报头的保留字段（因此SYN-ACK）只是为了在接收到的数据包中反映TCP报头的保留字段。由于TCP SYN数据包设置ECN Echo和CWR标志以指示ECN能力，而SYN-ACK数据包仅设置ECN Echo标志，因此发送TCP正确地将接收机自身标志在保留字段中的反映解释为接收机不具备ECN能力的指示。发送TCP不会被错误的TCP实现误导，该TCP实现发送的SYN-ACK数据包只是反映了传入SYN数据包的保留字段。
For a TCP connection using ECN, new data packets are transmitted with an ECT codepoint set in the IP header. When only one ECT codepoint is needed by a sender for all packets sent on a TCP connection, ECT(0) SHOULD be used. If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh". The sending TCP SHOULD NOT increase the congestion window in response to the receipt of an ECN-Echo ACK packet.
对于使用ECN的TCP连接，使用IP报头中设置的ECT码点传输新数据包。当发送方在TCP连接上发送的所有数据包只需要一个ECT码点时，应使用ECT（0）。如果发送方收到ECN Echo（ECE）ACK数据包（即TCP报头中设置了ECN Echo标志的ACK数据包），则发送方知道在从发送方到接收方的路径上的网络中遇到了拥塞。拥塞指示应被视为不支持ECN的TCP中的拥塞丢失。也就是说，TCP源将拥塞窗口“cwnd”减半，并降低慢启动阈值“ssthresh”。发送TCP不应增加拥塞窗口以响应接收到ECN Echo ACK数据包。
TCP should not react to congestion indications more than once every window of data (or more loosely, more than once every round-trip time). That is, the TCP sender's congestion window should be reduced only once in response to a series of dropped and/or CE packets from a single window of data. In addition, the TCP source should not decrease the slow-start threshold, ssthresh, if it has been decreased within the last round trip time. However, if any retransmitted packets are dropped, then this is interpreted by the source TCP as a new instance of congestion.
TCP对拥塞指示的反应不应在每个数据窗口出现一次以上（或者更宽松地说，在每个往返时间出现一次以上）。也就是说，TCP发送方的拥塞窗口应该只减少一次，以响应来自单个数据窗口的一系列丢弃和/或CE数据包。此外，如果慢启动阈值ssthresh在上一次往返时间内已降低，则TCP源不应降低该阈值。但是，如果任何重新传输的数据包被丢弃，则源TCP会将其解释为新的拥塞实例。
After the source TCP reduces its congestion window in response to a CE packet, incoming acknowledgments that continue to arrive can "clock out" outgoing packets as allowed by the reduced congestion window. If the congestion window consists of only one MSS (maximum segment size), and the sending TCP receives an ECN-Echo ACK packet, then the sending TCP should in principle still reduce its congestion window in half. However, the value of the congestion window is bounded below by a value of one MSS. If the sending TCP were to continue to send, using a congestion window of 1 MSS, this results in the transmission of one packet per round-trip time. It is necessary to still reduce the sending rate of the TCP sender even further, on receipt of an ECN-Echo packet when the congestion window is one. We use the retransmit timer as a means of reducing the rate further in this circumstance. Therefore, the sending TCP MUST reset the retransmit timer on receiving the ECN-Echo packet when the congestion window is one. The sending TCP will then be able to send a new packet only when the retransmit timer expires.
在源TCP响应CE数据包而减少其拥塞窗口后，继续到达的传入确认可以按照减少的拥塞窗口所允许的方式“打卡”传出数据包。如果拥塞窗口仅由一个MSS（最大段大小）组成，并且发送TCP接收到ECN Echo ACK数据包，则发送TCP原则上仍应将其拥塞窗口减少一半。但是，拥塞窗口的值以一个MSS的值为界。如果发送TCP继续发送，使用1 ms的拥塞窗口，这将导致每个往返时间传输一个数据包。当拥塞窗口为1时，在接收到ECN回波数据包时，仍有必要进一步降低TCP发送方的发送速率。在这种情况下，我们使用重传计时器作为进一步降低速率的手段。因此，当拥塞窗口为1时，发送TCP必须在接收ECN回波数据包时重置重传计时器。然后，发送TCP只能在重传计时器过期时发送新数据包。
When an ECN-Capable TCP sender reduces its congestion window for any reason (because of a retransmit timeout, a Fast Retransmit, or in response to an ECN Notification), the TCP sender sets the CWR flag in the TCP header of the first new data packet sent after the window reduction. If that data packet is dropped in the network, then the
当支持ECN的TCP发送方出于任何原因（由于重传超时、快速重传或响应ECN通知）减少其拥塞窗口时，TCP发送方在窗口减少后发送的第一个新数据包的TCP报头中设置CWR标志。如果该数据包在网络中被丢弃，则
sending TCP will have to reduce the congestion window again and retransmit the dropped packet.
发送TCP必须再次减少拥塞窗口并重新传输丢弃的数据包。
We ensure that the "Congestion Window Reduced" information is reliably delivered to the TCP receiver. This comes about from the fact that if the new data packet carrying the CWR flag is dropped, then the TCP sender will have to again reduce its congestion window, and send another new data packet with the CWR flag set. Thus, the CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
我们确保“拥塞窗口减少”信息可靠地传递给TCP接收器。这是因为如果携带CWR标志的新数据包被丢弃，那么TCP发送方将不得不再次减少其拥塞窗口，并发送另一个设置了CWR标志的新数据包。因此，TCP报头中的CWR位不应在重新传输的数据包上设置。
When the TCP data sender is ready to set the CWR bit after reducing the congestion window, it SHOULD set the CWR bit only on the first new data packet that it transmits.
当TCP数据发送方在减少拥塞窗口后准备好设置CWR位时，它应仅在其传输的第一个新数据包上设置CWR位。
[Floyd94] discusses TCP's response to ECN in more detail. [Floyd98] discusses the validation test in the ns simulator, which illustrates a wide range of ECN scenarios. These scenarios include the following: an ECN followed by another ECN, a Fast Retransmit, or a Retransmit Timeout; a Retransmit Timeout or a Fast Retransmit followed by an ECN; and a congestion window of one packet followed by an ECN.
[Floyd94]更详细地讨论了TCP对ECN的响应。[Floyd98]讨论了ns模拟器中的验证测试，该模拟器演示了广泛的ECN场景。这些场景包括：一个ECN后跟另一个ECN、快速重传或重传超时；重传超时或紧接着ECN的快速重传；以及一个拥塞窗口，该拥塞窗口是一个数据包后跟一个ECN。
TCP follows existing algorithms for sending data packets in response to incoming ACKs, multiple duplicate acknowledgments, or retransmit timeouts [RFC2581]. TCP also follows the normal procedures for increasing the congestion window when it receives ACK packets without the ECN-Echo bit set [RFC2581].
TCP遵循现有算法发送数据包以响应传入的确认、多个重复确认或重新传输超时[RFC2581]。当TCP接收到没有ECN回波位设置的ACK数据包[RFC2581]时，它也遵循增加拥塞窗口的正常过程。
When TCP receives a CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. If there is any ACK withholding implemented, as in current "delayed-ACK" TCP implementations where the TCP receiver can send an ACK for two arriving data packets, then the ECN-Echo flag in the ACK packet will be set to '1' if the CE codepoint is set in any of the data packets being acknowledged. That is, if any of the received data packets are CE packets, then the returning ACK has the ECN-Echo flag set.
当TCP在目的端系统接收到CE数据包时，TCP数据接收器在后续ACK数据包的TCP报头中设置ECN Echo标志。如果实施了任何ACK预扣，如在当前的“延迟ACK”TCP实施中，TCP接收器可以发送两个到达数据包的ACK，则如果在任何正在确认的数据包中设置了CE码点，则ACK包中的ECN Echo标志将设置为“1”。也就是说，如果任何接收到的数据分组是CE分组，则返回的ACK设置了ECN Echo标志。
To provide robustness against the possibility of a dropped ACK packet carrying an ECN-Echo flag, the TCP receiver sets the ECN-Echo flag in a series of ACK packets sent subsequently. The TCP receiver uses the CWR flag received from the TCP sender to determine when to stop setting the ECN-Echo flag.
为了提供抗丢失的ACK分组携带ECN Echo标志的可能性的鲁棒性，TCP接收机在随后发送的一系列ACK分组中设置ECN Echo标志。TCP接收方使用从TCP发送方接收的CWR标志来确定何时停止设置ECN Echo标志。
After a TCP receiver sends an ACK packet with the ECN-Echo bit set, that TCP receiver continues to set the ECN-Echo flag in all the ACK packets it sends (whether they acknowledge CE data packets or non-CE
TCP接收器发送设置了ECN Echo位的ACK数据包后，该TCP接收器继续在其发送的所有ACK数据包中设置ECN Echo标志（无论是确认CE数据包还是非CE数据包）
data packets) until it receives a CWR packet (a packet with the CWR flag set). After the receipt of the CWR packet, acknowledgments for subsequent non-CE data packets do not have the ECN-Echo flag set. If another CE packet is received by the data receiver, the receiver would once again send ACK packets with the ECN-Echo flag set. While the receipt of a CWR packet does not guarantee that the data sender received the ECN-Echo message, this does suggest that the data sender reduced its congestion window at some point *after* it sent the data packet for which the CE codepoint was set.
数据包），直到收到CWR数据包（设置了CWR标志的数据包）。在接收到CWR数据包之后，后续非CE数据包的确认没有设置ECN Echo标志。如果数据接收器接收到另一个CE数据包，接收器将再次发送设置了ECN Echo标志的ACK数据包。虽然CWR数据包的接收不保证数据发送方收到ECN回显消息，但这确实表明，数据发送方在发送设置了CE代码点的数据包后的某个时间点*减少了拥塞窗口。
We have already specified that a TCP sender is not required to reduce its congestion window more than once per window of data. Some care is required if the TCP sender is to avoid unnecessary reductions of the congestion window when a window of data includes both dropped packets and (marked) CE packets. This is illustrated in [Floyd98].
我们已经指定，TCP发送方不需要在每个数据窗口中多次减少其拥塞窗口。当一个数据窗口同时包含丢弃的数据包和（标记的）CE数据包时，如果TCP发送方要避免不必要地减少拥塞窗口，则需要特别小心。这在[Floyd98]中有说明。
For the current generation of TCP congestion control algorithms, pure acknowledgement packets (e.g., packets that do not contain any accompanying data) MUST be sent with the not-ECT codepoint. Current TCP receivers have no mechanisms for reducing traffic on the ACK-path in response to congestion notification. Mechanisms for responding to congestion on the ACK-path are areas for current and future research. (One simple possibility would be for the sender to reduce its congestion window when it receives a pure ACK packet with the CE codepoint set). For current TCP implementations, a single dropped ACK generally has only a very small effect on the TCP's sending rate.
对于当前一代TCP拥塞控制算法，必须使用not ECT码点发送纯确认数据包（例如，不包含任何伴随数据的数据包）。当前TCP接收器没有响应拥塞通知而减少ACK路径上流量的机制。应答ACK路径上拥塞的机制是当前和未来研究的领域。（一种简单的可能性是发送方在接收到带有CE码点集的纯ACK数据包时减少其拥塞窗口）。对于当前的TCP实现，单个丢弃的ACK通常对TCP的发送速率影响很小。
This document specifies ECN-capable TCP implementations MUST NOT set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for retransmitted data packets, and that the TCP data receiver SHOULD ignore the ECN field on arriving data packets that are outside of the receiver's current window. This is for greater security against denial-of-service attacks, as well as for robustness of the ECN congestion indication with packets that are dropped later in the network.
本文档规定，支持ECN的TCP实现不得在IP报头中为重新传输的数据包设置ECT码点（ECT（0）或ECT（1）），并且TCP数据接收器应忽略到达接收器当前窗口之外的数据包的ECN字段。这是为了更好地防止拒绝服务攻击，以及针对稍后在网络中丢弃的数据包的ECN拥塞指示的健壮性。
First, we note that if the TCP sender were to set an ECT codepoint on a retransmitted packet, then if an unnecessarily-retransmitted packet was later dropped in the network, the end nodes would never receive the indication of congestion from the router setting the CE codepoint. Thus, setting an ECT codepoint on retransmitted data packets is not consistent with the robust delivery of the congestion indication even for packets that are later dropped in the network.
首先，我们注意到，如果TCP发送方在重新传输的数据包上设置ECT码点，那么如果不必要的重新传输数据包后来在网络中被丢弃，则终端节点将永远不会从设置CE码点的路由器接收拥塞指示。因此，在重传的数据分组上设置ECT码点与拥塞指示的健壮传递不一致，即使对于稍后在网络中丢弃的分组也是如此。
In addition, an attacker capable of spoofing the IP source address of the TCP sender could send data packets with arbitrary sequence numbers, with the CE codepoint set in the IP header. On receiving this spoofed data packet, the TCP data receiver would determine that the data does not lie in the current receive window, and return a duplicate acknowledgement. We define an out-of-window packet at the TCP data receiver as a data packet that lies outside the receiver's current window. On receiving an out-of-window packet, the TCP data receiver has to decide whether or not to treat the CE codepoint in the packet header as a valid indication of congestion, and therefore whether to return ECN-Echo indications to the TCP data sender. If the TCP data receiver ignored the CE codepoint in an out-of-window packet, then the TCP data sender would not receive this possibly-legitimate indication of congestion from the network, resulting in a violation of end-to-end congestion control. On the other hand, if the TCP data receiver honors the CE indication in the out-of-window packet, and reports the indication of congestion to the TCP data sender, then the malicious node that created the spoofed, out-of-window packet has successfully "attacked" the TCP connection by forcing the data sender to unnecessarily reduce (halve) its congestion window. To prevent such a denial-of-service attack, we specify that a legitimate TCP data sender MUST NOT set an ECT codepoint on retransmitted data packets, and that the TCP data receiver SHOULD ignore the CE codepoint on out-of-window packets.
此外，能够欺骗TCP发送方IP源地址的攻击者可以发送具有任意序列号的数据包，并在IP报头中设置CE代码点。在接收到这个伪造的数据包时，TCP数据接收器将确定数据不在当前接收窗口中，并返回一个重复的确认。我们将TCP数据接收器处的窗口外数据包定义为位于接收器当前窗口之外的数据包。在接收到窗口外数据包时，TCP数据接收器必须决定是否将数据包头中的CE代码点视为拥塞的有效指示，从而决定是否向TCP数据发送方返回ECN回波指示。如果TCP数据接收方忽略了窗口外数据包中的CE码点，则TCP数据发送方将无法从网络接收到可能合法的拥塞指示，从而导致违反端到端拥塞控制。另一方面，如果TCP数据接收方遵守窗口外数据包中的CE指示，并向TCP数据发送方报告拥塞指示，则创建伪造窗口外数据包的恶意节点已通过强制数据发送方不必要地减少（减半）成功“攻击”TCP连接它的拥挤窗口。为了防止这种拒绝服务攻击，我们规定合法的TCP数据发送方不得在重新传输的数据包上设置ECT代码点，并且TCP数据接收方应忽略窗口外数据包上的CE代码点。
One drawback of not setting ECT(0) or ECT(1) on retransmitted packets is that it denies ECN protection for retransmitted packets. However, for an ECN-capable TCP connection in a fully-ECN-capable environment with mild congestion, packets should rarely be dropped due to congestion in the first place, and so instances of retransmitted packets should rarely arise. If packets are being retransmitted, then there are already packet losses (from corruption or from congestion) that ECN has been unable to prevent.
不在重传数据包上设置ECT（0）或ECT（1）的一个缺点是它拒绝对重传数据包的ECN保护。但是，对于完全支持ECN且拥塞较轻的环境中支持ECN的TCP连接，数据包应该很少首先因为拥塞而丢弃，因此很少出现重传数据包的情况。如果正在重新传输数据包，则已经存在ECN无法防止的数据包丢失（由于损坏或拥塞）。
We note that if the router sets the CE codepoint for an ECN-capable data packet within a TCP connection, then the TCP connection is guaranteed to receive that indication of congestion, or to receive some other indication of congestion within the same window of data, even if this packet is dropped or reordered in the network. We consider two cases, when the packet is later retransmitted, and when the packet is not later retransmitted.
我们注意到，如果路由器在TCP连接内为支持ECN的数据包设置CE码点，则TCP连接保证接收该拥塞指示，或在相同的数据窗口内接收一些其他拥塞指示，即使该数据包在网络中被丢弃或重新排序。我们考虑两种情况，当包被重传时，以及当包不再被重传时。
In the first case, if the packet is either dropped or delayed, and at some point retransmitted by the data sender, then the retransmission is a result of a Fast Retransmit or a Retransmit Timeout for either that packet or for some prior packet in the same window of data. In this case, because the data sender already has retransmitted this packet, we know that the data sender has already responded to an
在第一种情况下，如果数据包被丢弃或延迟，并且在某个点被数据发送方重新传输，则重新传输是该数据包或同一数据窗口中的某个先前数据包的快速重新传输或重新传输超时的结果。在这种情况下，因为数据发送方已经重新传输了这个数据包，所以我们知道数据发送方已经响应了一个请求
indication of congestion for some packet within the same window of data as the original packet. Thus, even if the first transmission of the packet is dropped in the network, or is delayed, if it had the CE codepoint set, and is later ignored by the data receiver as an out-of-window packet, this is not a problem, because the sender has already responded to an indication of congestion for that window of data.
在与原始数据包相同的数据窗口内指示某些数据包的拥塞。因此，即使分组的第一次传输在网络中被丢弃，或者如果其具有CE码点设置而被延迟，并且随后被数据接收器作为窗口外分组而忽略，这也不是问题，因为发送方已经响应该数据窗口的拥塞指示。
In the second case, if the packet is never retransmitted by the data sender, then this data packet is the only copy of this data received by the data receiver, and therefore arrives at the data receiver as an in-window packet, regardless of how much the packet might be delayed or reordered. In this case, if the CE codepoint is set on the packet within the network, this will be treated by the data receiver as a valid indication of congestion.
在第二种情况下，如果数据发送方从未重新传输该数据包，则该数据包是数据接收方接收的该数据的唯一副本，因此作为窗口内数据包到达数据接收方，而不管该数据包可能被延迟或重新排序的程度如何。在这种情况下，如果在网络内的分组上设置CE码点，则数据接收器将其视为拥塞的有效指示。
6.1.6. TCP Window Probes.
6.1.6. TCP窗口探测。
When the TCP data receiver advertises a zero window, the TCP data sender sends window probes to determine if the receiver's window has increased. Window probe packets do not contain any user data except for the sequence number, which is a byte. If a window probe packet is dropped in the network, this loss is not detected by the receiver. Therefore, the TCP data sender MUST NOT set either an ECT codepoint or the CWR bit on window probe packets.
当TCP数据接收器播发零窗口时，TCP数据发送器发送窗口探测以确定接收器的窗口是否增加。窗口探测数据包不包含任何用户数据，但序列号除外，序列号是一个字节。如果窗口探测数据包在网络中丢失，则接收器不会检测到该丢失。因此，TCP数据发送方不得在窗口探测数据包上设置ECT码点或CWR位。
However, because window probes use exact sequence numbers, they cannot be easily spoofed in denial-of-service attacks. Therefore, if a window probe arrives with the CE codepoint set, then the receiver SHOULD respond to the ECN indications.
但是，由于窗口探测使用精确的序列号，因此在拒绝服务攻击中无法轻易欺骗它们。因此，如果窗口探测器到达时设置了CE码点，则接收器应响应ECN指示。
This section discusses concerns about the vulnerability of ECN to non-compliant end-nodes (i.e., end nodes that set the ECT codepoint in transmitted packets but do not respond to received CE packets). We argue that the addition of ECN to the IP architecture will not significantly increase the current vulnerability of the architecture to unresponsive flows.
本节讨论了ECN对不合规终端节点（即，在传输的数据包中设置ECT码点但不响应接收到的CE数据包的终端节点）的漏洞。我们认为，将ECN添加到IP体系结构不会显著增加体系结构当前对无响应流的脆弱性。
Even for non-ECN environments, there are serious concerns about the damage that can be done by non-compliant or unresponsive flows (that is, flows that do not respond to congestion control indications by reducing their arrival rate at the congested link). For example, an end-node could "turn off congestion control" by not reducing its congestion window in response to packet drops. This is a concern for the current Internet. It has been argued that routers will have to deploy mechanisms to detect and differentially treat packets from
即使对于非ECN环境，也存在严重的问题，即不符合或无响应的流（即，不通过降低其在拥塞链路的到达率来响应拥塞控制指示的流）可能造成的损害。例如，终端节点可以通过不减少其拥塞窗口来“关闭拥塞控制”，以响应数据包丢失。这是当前互联网关注的问题。有人认为，路由器必须部署机制来检测和区别处理来自路由器的数据包
non-compliant flows [RFC2309,FF99]. It has also been suggested that techniques such as end-to-end per-flow scheduling and isolation of one flow from another, differentiated services, or end-to-end reservations could remove some of the more damaging effects of unresponsive flows.
不符合要求的流[RFC2309，FF99]。也有人提出，诸如端到端每流调度和一个流与另一个流隔离、区分服务或端到端保留等技术可以消除无响应流的一些更具破坏性的影响。
It might seem that dropping packets in itself is an adequate deterrent for non-compliance, and that the use of ECN removes this deterrent. We would argue in response that (1) ECN-capable routers preserve packet-dropping behavior in times of high congestion; and (2) even in times of high congestion, dropping packets in itself is not an adequate deterrent for non-compliance.
丢弃数据包本身似乎对违规行为具有足够的威慑作用，而使用ECN消除了这种威慑作用。作为回应，我们认为（1）支持ECN的路由器在高拥塞时保持丢包行为；（2）即使在高度拥挤的情况下，丢弃数据包本身也不能充分阻止违规行为。
First, ECN-Capable routers will only mark packets (as opposed to dropping them) when the packet marking rate is reasonably low. During periods where the average queue size exceeds an upper threshold, and therefore the potential packet marking rate would be high, our recommendation is that routers drop packets rather then set the CE codepoint in packet headers.
首先，支持ECN的路由器只有在包标记率相当低时才会标记包（而不是丢弃它们）。在平均队列大小超过上限阈值的期间，因此潜在的数据包标记率将很高，我们建议路由器丢弃数据包，而不是在数据包头中设置CE码点。
During the periods of low or moderate packet marking rates when ECN would be deployed, there would be little deterrent effect on unresponsive flows of dropping rather than marking those packets. For example, delay-insensitive flows using reliable delivery might have an incentive to increase rather than to decrease their sending rate in the presence of dropped packets. Similarly, delay-sensitive flows using unreliable delivery might increase their use of FEC in response to an increased packet drop rate, increasing rather than decreasing their sending rate. For the same reasons, we do not believe that packet dropping itself is an effective deterrent for non-compliance even in an environment of high packet drop rates, when all flows are sharing the same packet drop rate.
在部署ECN的低或中等数据包标记率期间，对无响应的丢弃流（而不是标记这些数据包）几乎没有威慑作用。例如，使用可靠传递的延迟不敏感流在存在丢包的情况下可能有增加而不是降低其发送速率的动机。类似地，使用不可靠传递的延迟敏感流可能会增加其FEC的使用，以响应增加的分组丢弃率，从而增加而不是降低其发送速率。出于同样的原因，我们认为，即使在高丢包率的环境中，当所有流共享相同的丢包率时，丢包本身也不能有效阻止违规行为。
Several methods have been proposed to identify and restrict non-compliant or unresponsive flows. The addition of ECN to the network environment would not in any way increase the difficulty of designing and deploying such mechanisms. If anything, the addition of ECN to the architecture would make the job of identifying unresponsive flows slightly easier. For example, in an ECN-Capable environment routers are not limited to information about packets that are dropped or have the CE codepoint set at that router itself; in such an environment, routers could also take note of arriving CE packets that indicate congestion encountered by that packet earlier in the path.
已经提出了几种方法来识别和限制不合规或无响应的流。将ECN添加到网络环境中不会以任何方式增加设计和部署此类机制的难度。如果说有什么区别的话，那么在体系结构中添加ECN将使识别无响应流的工作稍微容易一些。例如，在支持ECN的环境中，路由器不限于关于丢弃的分组的信息或在该路由器本身设置了CE码点的分组的信息；在这样的环境中，路由器还可以注意到到达的CE数据包，这些数据包指示该数据包在路径的早期遇到的拥塞。
This section considers the issues when a router is operating, possibly maliciously, to modify either of the bits in the ECN field. We note that in IPv4, the IP header is protected from bit errors by a header checksum; this is not the case in IPv6. Thus for IPv6 the ECN field can be accidentally modified by bit errors on links or in routers without being detected by an IP header checksum.
本节考虑路由器可能恶意操作以修改ECN字段中的任一位时的问题。我们注意到，在IPv4中，IP报头通过报头校验和受到位错误的保护；IPv6中并非如此。因此，对于IPv6，ECN字段可能会被链路或路由器上的位错误意外修改，而不会被IP报头校验和检测到。
By tampering with the bits in the ECN field, an adversary (or a broken router) could do one or more of the following: falsely report congestion, disable ECN-Capability for an individual packet, erase the ECN congestion indication, or falsely indicate ECN-Capability. Section 18 systematically examines the various cases by which the ECN field could be modified. The important criterion considered in determining the consequences of such modifications is whether it is likely to lead to poorer behavior in any dimension (throughput, delay, fairness or functionality) than if a router were to drop a packet.
通过篡改ECN字段中的位，对手（或损坏的路由器）可以执行以下一项或多项操作：错误报告拥塞、禁用单个数据包的ECN功能、擦除ECN拥塞指示或错误指示ECN功能。第18节系统地研究了可以修改ECN字段的各种情况。在确定这种修改的后果时考虑的重要标准是，与路由器丢弃数据包相比，它是否可能导致任何方面（吞吐量、延迟、公平性或功能性）的较差行为。
The first two possible changes, falsely reporting congestion or disabling ECN-Capability for an individual packet, are no worse than if the router were to simply drop the packet. From a congestion control point of view, setting the CE codepoint in the absence of congestion by a non-compliant router would be no worse than a router dropping a packet unnecessarily. By "erasing" an ECT codepoint of a packet that is later dropped in the network, a router's actions could result in an unnecessary packet drop for that packet later in the network.
前两种可能的变化，错误地报告拥塞或禁用单个数据包的ECN功能，并不比路由器简单地丢弃数据包更糟糕。从拥塞控制的角度来看，在不兼容路由器没有拥塞的情况下设置CE码点并不比路由器不必要地丢弃数据包更糟糕。通过“擦除”稍后在网络中丢弃的数据包的ECT码点，路由器的操作可能导致该数据包稍后在网络中不必要的数据包丢弃。
However, as discussed in Section 18, a router that erases the ECN congestion indication or falsely indicates ECN-Capability could potentially do more damage to the flow that if it has simply dropped the packet. A rogue or broken router that "erased" the CE codepoint in arriving CE packets would prevent that indication of congestion from reaching downstream receivers. This could result in the failure of congestion control for that flow and a resulting increase in congestion in the network, ultimately resulting in subsequent packets dropped for this flow as the average queue size increased at the congested gateway.
然而，如第18节中所讨论的，如果路由器删除ECN拥塞指示或错误指示ECN能力，则可能会对流量造成更大的损害，而这可能是因为它只是丢弃了数据包。恶意或损坏的路由器“擦除”到达的CE数据包中的CE代码点将阻止拥塞指示到达下游接收器。这可能导致该流的拥塞控制失败，并导致网络中的拥塞增加，最终导致随着拥塞网关处的平均队列大小增加，该流的后续数据包被丢弃。
Section 19 considers the potential repercussions of subverting end-to-end congestion control by either falsely indicating ECN-Capability, or by erasing the congestion indication in ECN (the CE-codepoint). We observe in Section 19 that the consequence of subverting ECN-based congestion control may lead to potential unfairness, but this is likely to be no worse than the subversion of either ECN-based or packet-based congestion control by the end nodes.
第19节考虑了通过错误指示ECN能力或通过擦除ECN（CE码点）中的拥塞指示来破坏端到端拥塞控制的潜在影响。我们在第19节中观察到，颠覆基于ECN的拥塞控制的结果可能会导致潜在的不公平，但这可能不会比终端节点颠覆基于ECN或基于分组的拥塞控制更糟糕。
If a router or other network element has access to all of the packets of a flow, then that router could do no more damage to a flow by altering the ECN field than it could by simply dropping all of the packets from that flow. However, in some cases, a malicious or broken router might have access to only a subset of the packets from a flow. The question is as follows: can this router, by altering the ECN field in this subset of the packets, do more damage to that flow than if it has simply dropped that set of the packets?
如果路由器或其他网络元素可以访问流的所有数据包，那么该路由器通过改变ECN字段不会对流造成比从该流中删除所有数据包更大的损害。然而，在某些情况下，恶意或损坏的路由器可能只能访问来自流的数据包的子集。问题如下：通过改变数据包子集中的ECN字段，该路由器是否会对该流造成比丢弃该数据包集更大的损害？
This is also discussed in detail in Section 18, which concludes as follows: It is true that the adversary that has access only to a subset of packets in an aggregate might, by subverting ECN-based congestion control, be able to deny the benefits of ECN to the other packets in the aggregate. While this is undesirable, this is not a sufficient concern to result in disabling ECN.
第18节也详细讨论了这一点，其结论如下：确实，通过破坏基于ECN的拥塞控制，仅访问聚合中的数据包子集的对手可能会拒绝向聚合中的其他数据包提供ECN的好处。虽然这是不可取的，但这还不足以导致禁用ECN。
The encapsulation of IP packet headers in tunnels is used in many places, including IPsec and IP in IP [RFC2003]. This section considers issues related to interactions between ECN and IP tunnels, and specifies two alternative solutions. This discussion is complemented by RFC 2983's discussion of interactions between Differentiated Services and IP tunnels of various forms [RFC 2983], as Differentiated Services uses the remaining six bits of the IP header octet that is used by ECN (see Figure 2 in Section 5).
隧道中IP数据包头的封装在许多地方使用，包括IPsec和IP中的IP[RFC2003]。本节考虑与ECN和IP隧道之间的交互相关的问题，并指定两种备选解决方案。RFC 2983对差异化服务和各种形式的IP隧道之间的交互的讨论[RFC 2983]补充了这一讨论，因为差异化服务使用ECN使用的IP头八位组的剩余六位（参见第5节中的图2）。
Some IP tunnel modes are based on adding a new "outer" IP header that encapsulates the original, or "inner" IP header and its associated packet. In many cases, the new "outer" IP header may be added and removed at intermediate points along a connection, enabling the network to establish a tunnel without requiring endpoint participation. We denote tunnels that specify that the outer header be discarded at tunnel egress as "simple tunnels".
一些IP隧道模式基于添加一个新的“外部”IP报头，该报头封装原始或“内部”IP报头及其相关数据包。在许多情况下，可以在连接的中间点添加和删除新的“外部”IP报头，从而使网络能够在不需要端点参与的情况下建立隧道。我们将指定在隧道出口处丢弃外部集管的隧道称为“简单隧道”。
ECN uses the ECN field in the IP header for signaling between routers and connection endpoints. ECN interacts with IP tunnels based on the treatment of the ECN field in the IP header. In simple IP tunnels the octet containing the ECN field is copied or mapped from the inner IP header to the outer IP header at IP tunnel ingress, and the outer header's copy of this field is discarded at IP tunnel egress. If the outer header were to be simply discarded without taking care to deal with the ECN field, and an ECN-capable router were to set the CE
ECN使用IP报头中的ECN字段在路由器和连接端点之间发送信令。ECN根据IP报头中ECN字段的处理与IP隧道交互。在简单IP隧道中，包含ECN字段的八位字节在IP隧道入口从内部IP报头复制或映射到外部IP报头，并且在IP隧道出口处丢弃该字段的外部报头副本。如果只是丢弃外部报头而不注意处理ECN字段，则需要一个支持ECN的路由器来设置CE
(Congestion Experienced) codepoint within a packet in a simple IP tunnel, this indication would be discarded at tunnel egress, losing the indication of congestion.
（遇到拥塞）简单IP隧道中数据包内的代码点，此指示将在隧道出口处被丢弃，丢失拥塞指示。
Thus, the use of ECN over simple IP tunnels would result in routers attempting to use the outer IP header to signal congestion to endpoints, but those congestion warnings never arriving because the outer header is discarded at the tunnel egress point. This problem was encountered with ECN and IPsec in tunnel mode, and RFC 2481 recommended that ECN not be used with the older simple IPsec tunnels in order to avoid this behavior and its consequences. When ECN becomes widely deployed, then simple tunnels likely to carry ECN-capable traffic will have to be changed. If ECN-capable traffic is carried by a simple tunnel through a congested, ECN-capable router, this could result in subsequent packets being dropped for this flow as the average queue size increases at the congested router, as discussed in Section 8 above.
因此，在简单IP隧道上使用ECN将导致路由器尝试使用外部IP报头向端点发送拥塞信号，但这些拥塞警告永远不会到达，因为外部报头在隧道出口点被丢弃。ECN和IPsec在隧道模式下遇到此问题，RFC 2481建议不要将ECN用于较旧的简单IPsec隧道，以避免此行为及其后果。当ECN得到广泛部署时，可能承载ECN流量的简单隧道将不得不改变。如果支持ECN的流量由一个简单的隧道通过一个拥挤的、支持ECN的路由器进行传输，这可能会导致随着拥塞路由器处平均队列大小的增加，该流量的后续数据包被丢弃，如上文第8节所述。
From a security point of view, the use of ECN in the outer header of an IP tunnel might raise security concerns because an adversary could tamper with the ECN information that propagates beyond the tunnel endpoint. Based on an analysis in Sections 18 and 19 of these concerns and the resultant risks, our overall approach is to make support for ECN an option for IP tunnels, so that an IP tunnel can be specified or configured either to use ECN or not to use ECN in the outer header of the tunnel. Thus, in environments or tunneling protocols where the risks of using ECN are judged to outweigh its benefits, the tunnel can simply not use ECN in the outer header. Then the only indication of congestion experienced at routers within the tunnel would be through packet loss.
从安全角度来看，在IP隧道的外部报头中使用ECN可能会引起安全问题，因为对手可能会篡改传播到隧道端点之外的ECN信息。根据第18节和第19节中对这些问题的分析以及由此产生的风险，我们的总体方法是将对ECN的支持作为IP隧道的一个选项，以便可以指定或配置IP隧道，以便在隧道的外部标头中使用ECN或不使用ECN。因此，在使用ECN的风险大于其好处的环境或隧道协议中，隧道不能在外部报头中使用ECN。那么，隧道内路由器发生拥塞的唯一迹象就是丢包。
The result is that there are two viable options for the behavior of ECN-capable connections over an IP tunnel, including IPsec tunnels:
结果是，对于IP隧道（包括IPsec隧道）上支持ECN的连接的行为，有两种可行的选择：
* A limited-functionality option in which ECN is preserved in the inner header, but disabled in the outer header. The only mechanism available for signaling congestion occurring within the tunnel in this case is dropped packets.
* 一种有限功能选项，其中ECN保留在内部标头中，但在外部标头中禁用。在这种情况下，隧道内发生拥塞的唯一可用机制是丢弃的数据包。
* A full-functionality option that supports ECN in both the inner and outer headers, and propagates congestion warnings from nodes within the tunnel to endpoints.
* 一个完整的功能选项，在内部和外部标头中都支持ECN，并将拥塞警告从隧道内的节点传播到端点。
Support for these options requires varying amounts of changes to IP header processing at tunnel ingress and egress. A small subset of these changes sufficient to support only the limited-functionality option would be sufficient to eliminate any incompatibility between ECN and IP tunnels.
支持这些选项需要在隧道入口和出口对IP报头处理进行不同程度的更改。这些更改的一小部分足以支持有限的功能选项，就足以消除ECN和IP隧道之间的任何不兼容性。
One goal of this document is to give guidance about the tradeoffs between the limited-functionality and full-functionality options. A full discussion of the potential effects of an adversary's modifications of the ECN field is given in Sections 18 and 19.
本文档的一个目标是为有限功能选项和完整功能选项之间的权衡提供指导。第18节和第19节对敌方修改ECN场的潜在影响进行了全面讨论。
The limited-functionality option for ECN encapsulation in IP tunnels is for the not-ECT codepoint to be set in the outside (encapsulating) header regardless of the value of the ECN field in the inside (encapsulated) header. With this option, the ECN field in the inner header is not altered upon de-capsulation. The disadvantage of this approach is that the flow does not have ECN support for that part of the path that is using IP tunneling, even if the encapsulated packet (from the original TCP sender) is ECN-Capable. That is, if the encapsulated packet arrives at a congested router that is ECN-capable, and the router can decide to drop or mark the packet as an indication of congestion to the end nodes, the router will not be permitted to set the CE codepoint in the packet header, but instead will have to drop the packet.
IP隧道中ECN封装的有限功能选项用于在外部（封装）报头中设置not ECT代码点，而不管内部（封装）报头中ECN字段的值如何。使用此选项，在解除封装后，内部标头中的ECN字段不会更改。这种方法的缺点是，即使封装的数据包（来自原始TCP发送方）支持ECN，流也不支持使用IP隧道的路径部分的ECN。也就是说，如果封装的分组到达具有ECN能力的拥塞路由器，并且路由器可以决定丢弃该分组或将该分组标记为对终端节点的拥塞指示，则不允许路由器在分组报头中设置CE码点，而是必须丢弃该分组。
The full-functionality option for ECN encapsulation is to copy the ECN codepoint of the inside header to the outside header on encapsulation if the inside header is not-ECT or ECT, and to set the ECN codepoint of the outside header to ECT(0) if the ECN codepoint of the inside header is CE. On decapsulation, if the CE codepoint is set on the outside header, then the CE codepoint is also set in the inner header. Otherwise, the ECN codepoint on the inner header is left unchanged. That is, for full ECN support the encapsulation and decapsulation processing involves the following: At tunnel ingress, the full-functionality option sets the ECN codepoint in the outer header. If the ECN codepoint in the inner header is not-ECT or ECT, then it is copied to the ECN codepoint in the outer header. If the ECN codepoint in the inner header is CE, then the ECN codepoint in the outer header is set to ECT(0). Upon decapsulation at the tunnel egress, the full-functionality option sets the CE codepoint in the inner header if the CE codepoint is set in the outer header. Otherwise, no change is made to this field of the inner header.
ECN封装的完整功能选项是，如果内部头不是ECT或ECT，则在封装时将内部头的ECN代码点复制到外部头，如果内部头的ECN代码点是CE，则将外部头的ECN代码点设置为ECT（0）。在解除封装时，如果CE代码点设置在外部标头上，则CE代码点也设置在内部标头中。否则，内部报头上的ECN代码点保持不变。也就是说，对于完整的ECN支持，封装和去封装处理涉及以下内容：在隧道入口，完整功能选项在外部报头中设置ECN代码点。如果内部标头中的ECN代码点不是ECT或ECT，则会将其复制到外部标头中的ECN代码点。如果内部报头中的ECN代码点为CE，则外部报头中的ECN代码点设置为ECT（0）。在隧道出口处解除封装后，如果CE代码点设置在外部标头中，则完整功能选项将在内部标头中设置CE代码点。否则，不会更改内部标题的此字段。
With the full-functionality option, a flow can take advantage of ECN in those parts of the path that might use IP tunneling. The disadvantage of the full-functionality option from a security perspective is that the IP tunnel cannot protect the flow from certain modifications to the ECN bits in the IP header within the tunnel. The potential dangers from modifications to the ECN bits in the IP header are described in detail in Sections 18 and 19.
使用完整功能选项，流可以利用路径中可能使用IP隧道的部分中的ECN。从安全角度来看，全功能选项的缺点是，IP隧道无法保护流，使其免受对隧道内IP报头中ECN位的某些修改的影响。第18和19节详细描述了修改IP报头中的ECN位的潜在危险。
(1) An IP tunnel MUST modify the handling of the DS field octet at IP tunnel endpoints by implementing either the limited-functionality or the full-functionality option.
(1) IP隧道必须通过实现受限功能或完整功能选项来修改IP隧道端点处DS字段八位字节的处理。
(2) Optionally, an IP tunnel MAY enable the endpoints of an IP tunnel to negotiate the choice between the limited-functionality and the full-functionality option for ECN in the tunnel.
(2) 可选地，IP隧道可以使IP隧道的端点能够协商隧道中ECN的有限功能和完全功能选项之间的选择。
The minimum required to make ECN usable with IP tunnels is the limited-functionality option, which prevents ECN from being enabled in the outer header of the tunnel. Full support for ECN requires the use of the full-functionality option. If there are no optional mechanisms for the tunnel endpoints to negotiate a choice between the limited-functionality or full-functionality option, there can be a pre-existing agreement between the tunnel endpoints about whether to support the limited-functionality or the full-functionality ECN option.
使ECN可用于IP隧道的最低要求是有限功能选项，该选项可防止在隧道的外部标头中启用ECN。完全支持ECN需要使用完整功能选项。如果没有可选机制供隧道端点协商有限功能选项或完全功能选项之间的选择，则隧道端点之间可能存在关于是否支持有限功能或完全功能ECN选项的预先存在的协议。
All IP tunnels MUST implement the limited-functionality option, and SHOULD support the full-functionality option.
所有IP隧道必须实现有限功能选项，并应支持完整功能选项。
In addition, it is RECOMMENDED that packets with the CE codepoint in the outer header be dropped if they arrive at the tunnel egress point for a tunnel that uses the limited-functionality option, or for a tunnel that uses the full-functionality option but for which the not-ECT codepoint is set in the inner header. This is motivated by backwards compatibility and to ensure that no unauthorized modifications of the ECN field take place, and is discussed further in the next Section (9.1.2).
此外，对于使用受限功能选项的隧道，或者对于使用完整功能选项但未在内部报头中设置ECT代码点的隧道，如果到达隧道出口点，则建议丢弃外部报头中具有CE代码点的数据包。这是出于向后兼容性，并确保不会对ECN字段进行未经授权的修改，下一节（9.1.2）将对此进行进一步讨论。
9.1.2. Changes to the ECN Field within an IP Tunnel.
9.1.2. IP隧道内ECN字段的更改。
The presence of a copy of the ECN field in the inner header of an IP tunnel mode packet provides an opportunity for detection of unauthorized modifications to the ECN field in the outer header. Comparison of the ECT fields in the inner and outer headers falls into two categories for implementations that conform to this document:
IP隧道模式分组的内部报头中存在ECN字段的副本提供了检测外部报头中ECN字段的未经授权修改的机会。对于符合本文档的实现，内部和外部标题中ECT字段的比较分为两类：
* If the IP tunnel uses the full-functionality option, then the not-ECT codepoint should be set in the outer header if and only if it is also set in the inner header.
* 如果IP隧道使用完整功能选项，则当且仅当not ECT代码点也在内部标头中设置时，才应在外部标头中设置not ECT代码点。
* If the tunnel uses the limited-functionality option, then the not-ECT codepoint should be set in the outer header.
* 如果隧道使用受限功能选项，则应在外部标头中设置not ECT代码点。
Receipt of a packet not satisfying the appropriate condition could be a cause of concern.
收到不符合适当条件的数据包可能会引起关注。
Consider the case of an IP tunnel where the tunnel ingress point has not been updated to this document's requirements, while the tunnel egress point has been updated to support ECN. In this case, the IP tunnel is not explicitly configured to support the full-functionality ECN option. However, the tunnel ingress point is behaving identically to a tunnel ingress point that supports the full-functionality option. If packets from an ECN-capable connection use this tunnel, the ECT codepoint will be set in the outer header at the tunnel ingress point. Congestion within the tunnel may then result in ECN-capable routers setting CE in the outer header. Because the tunnel has not been explicitly configured to support the full-functionality option, the tunnel egress point expects the not-ECT codepoint to be set in the outer header. When an ECN-capable tunnel egress point receives a packet with the ECT or CE codepoint in the outer header, in a tunnel that has not been configured to support the full-functionality option, that packet should be processed, according to whether the CE codepoint was set, as follows. It is RECOMMENDED that on a tunnel that has not been configured to support the full-functionality option, packets should be dropped at the egress point if the CE codepoint is set in the outer header but not in the inner header, and should be forwarded otherwise.
考虑IP隧道的情况，其中隧道入口点尚未更新到该文档的要求，而隧道出口点已被更新以支持ECN。在这种情况下，IP隧道没有明确配置为支持完整功能ECN选项。但是，隧道入口点的行为与支持完整功能选项的隧道入口点相同。如果来自支持ECN的连接的数据包使用此隧道，则ECT代码点将在隧道入口点的外部报头中设置。隧道内的拥塞可能会导致支持ECN的路由器在外部报头中设置CE。由于隧道尚未明确配置为支持完整功能选项，因此隧道出口点希望在外部标头中设置not ECT代码点。当支持ECN的隧道出口点在尚未配置为支持完整功能选项的隧道中接收到外部报头中具有ECT或CE代码点的分组时，应根据是否设置了CE代码点来处理该分组，如下所示。建议在尚未配置为支持完整功能选项的隧道上，如果CE代码点设置在外部报头中而不是内部报头中，则应在出口点丢弃数据包，否则应转发数据包。
An IP tunnel cannot provide protection against erasure of congestion indications based on changing the ECN codepoint from CE to ECT. The erasure of congestion indications may impact the network and other flows in ways that would not be possible in the absence of ECN. It is important to note that erasure of congestion indications can only be performed to congestion indications placed by nodes within the tunnel; the copy of the ECN field in the inner header preserves congestion notifications from nodes upstream of the tunnel ingress (unless the inner header is also erased). If erasure of congestion notifications is judged to be a security risk that exceeds the congestion management benefits of ECN, then tunnels could be specified or configured to use the limited-functionality option.
IP隧道无法提供保护，防止因将ECN代码点从CE更改为ECT而擦除拥塞指示。消除拥塞指示可能会以在没有ECN的情况下不可能的方式影响网络和其他流。需要注意的是，拥塞指示的擦除只能对隧道内节点放置的拥塞指示执行；内部报头中ECN字段的副本保留来自隧道入口上游节点的拥塞通知（除非内部报头也被擦除）。如果判断擦除拥塞通知的安全风险超过了ECN的拥塞管理优势，则可以指定或配置隧道以使用受限功能选项。
IPsec supports secure communication over potentially insecure network components such as intermediate routers. IPsec protocols support two operating modes, transport mode and tunnel mode, that span a wide range of security requirements and operating environments. Transport mode security protocol header(s) are inserted between the IP (IPv4 or IPv6) header and higher layer protocol headers (e.g., TCP), and hence transport mode can only be used for end-to-end security on a connection. IPsec tunnel mode is based on adding a new "outer" IP header that encapsulates the original, or "inner" IP header and its associated packet. Tunnel mode security headers are inserted between these two IP headers. In contrast to transport mode, the new "outer"
IPsec支持通过可能不安全的网络组件（如中间路由器）进行安全通信。IPsec协议支持两种操作模式，即传输模式和隧道模式，它们跨越了广泛的安全需求和操作环境。传输模式安全协议头插入IP（IPv4或IPv6）头和更高层协议头（例如TCP）之间，因此传输模式只能用于连接上的端到端安全。IPsec隧道模式基于添加新的“外部”IP报头，该报头封装原始或“内部”IP报头及其相关数据包。隧道模式安全标头插入这两个IP标头之间。与运输方式相比，新的“外部”
IP header and tunnel mode security headers can be added and removed at intermediate points along a connection, enabling security gateways to secure vulnerable portions of a connection without requiring endpoint participation in the security protocols. An important aspect of tunnel mode security is that in the original specification, the outer header is discarded at tunnel egress, ensuring that security threats based on modifying the IP header do not propagate beyond that tunnel endpoint. Further discussion of IPsec can be found in [RFC2401].
可以在连接的中间点添加和删除IP头和隧道模式安全头，使安全网关能够保护连接的易受攻击部分，而无需端点参与安全协议。隧道模式安全性的一个重要方面是，在原始规范中，在隧道出口处丢弃外部报头，以确保基于修改IP报头的安全威胁不会传播到该隧道端点之外。有关IPsec的进一步讨论，请参见[RFC2401]。
The IPsec protocol as originally defined in [ESP, AH] required that the inner header's ECN field not be changed by IPsec decapsulation processing at a tunnel egress node; this would have ruled out the possibility of full-functionality mode for ECN. At the same time, this would ensure that an adversary's modifications to the ECN field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint, as any such modifications will be discarded at the tunnel endpoint.
[ESP，AH]中最初定义的IPsec协议要求内部报头的ECN字段不通过隧道出口节点处的IPsec解封装处理而改变；这就排除了ECN采用全功能模式的可能性。同时，这将确保对手对ECN字段的修改不能用于跨IPsec隧道端点发起盗窃或拒绝服务攻击，因为任何此类修改都将在隧道端点处被丢弃。
In principle, permitting the use of ECN functionality in the outer header of an IPsec tunnel raises security concerns because an adversary could tamper with the information that propagates beyond the tunnel endpoint. Based on an analysis (included in Sections 18 and 19) of these concerns and the associated risks, our overall approach has been to provide configuration support for IPsec changes to remove the conflict with ECN.
原则上，允许在IPsec隧道的外部头中使用ECN功能会引起安全问题，因为对手可能会篡改传播到隧道端点之外的信息。基于对这些问题和相关风险的分析（包括在第18节和第19节），我们的总体方法是为IPsec更改提供配置支持，以消除与ECN的冲突。
In particular, in tunnel mode the IPsec tunnel MUST support the limited-functionality option outlined in Section 9.1.1, and SHOULD support the full-functionality option outlined in Section 9.1.1.
特别是，在隧道模式下，IPsec隧道必须支持第9.1.1节中概述的受限功能选项，并且应支持第9.1.1节中概述的完整功能选项。
This makes permission to use ECN functionality in the outer header of an IPsec tunnel a configurable part of the corresponding IPsec Security Association (SA), so that it can be disabled in situations where the risks are judged to outweigh the benefits. The result is that an IPsec security administrator is presented with two alternatives for the behavior of ECN-capable connections within an IPsec tunnel, the limited-functionality alternative and full-functionality alternative described earlier.
这使得在IPsec隧道的外部报头中使用ECN功能的权限成为相应IPsec安全关联（SA）的可配置部分，以便在判断风险大于好处的情况下禁用该功能。结果是，对于IPsec隧道中支持ECN的连接的行为，IPsec安全管理员可以看到两种备选方案，即前面描述的有限功能备选方案和完全功能备选方案。
In addition, this document specifies how the endpoints of an IPsec tunnel could negotiate enabling ECN functionality in the outer headers of that tunnel based on security policy. The ability to negotiate ECN usage between tunnel endpoints would enable a security administrator to disable ECN in situations where she believes the risks (e.g., of lost congestion notifications) outweigh the benefits of ECN.
此外，本文档还指定了IPsec隧道的端点如何根据安全策略协商在该隧道的外部头中启用ECN功能。在隧道端点之间协商ECN使用的能力将使安全管理员能够在她认为风险（例如丢失拥塞通知）超过ECN好处的情况下禁用ECN。
The IPsec protocol, as defined in [ESP, AH], does not include the IP header's ECN field in any of its cryptographic calculations (in the case of tunnel mode, the outer IP header's ECN field is not included). Hence modification of the ECN field by a network node has no effect on IPsec's end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the ECN field (i.e., a man-in-the-middle attack), as the adversary's modification will also have no effect on IPsec's end-to-end security. In some environments, the ability to modify the ECN field without affecting IPsec integrity checks may constitute a covert channel; if it is necessary to eliminate such a channel or reduce its bandwidth, then the IPsec tunnel should be run in limited-functionality mode.
[ESP，AH]中定义的IPsec协议在其任何加密计算中不包括IP头的ECN字段（在隧道模式下，不包括外部IP头的ECN字段）。因此，网络节点对ECN字段的修改不会影响IPsec的端到端安全性，因为它不会导致任何IPsec完整性检查失败。因此，IPsec不会针对对手修改ECN字段（即中间人攻击）提供任何防御，因为对手的修改也不会影响IPsec的端到端安全。在某些环境中，在不影响IPsec完整性检查的情况下修改ECN字段的能力可能构成隐蔽通道；如果需要消除此类通道或减少其带宽，则IPsec隧道应在有限功能模式下运行。
This section describes the detailed changes to enable usage of ECN over IPsec tunnels, including the negotiation of ECN support between tunnel endpoints. This is supported by three changes to IPsec:
本节描述了支持通过IPsec隧道使用ECN的详细更改，包括隧道端点之间ECN支持的协商。IPsec的三个更改支持这一点：
* An optional Security Association Database (SAD) field indicating whether tunnel encapsulation and decapsulation processing allows or forbids ECN usage in the outer IP header.
* 可选的安全关联数据库（SAD）字段，指示隧道封装和去封装处理是否允许或禁止在外部IP标头中使用ECN。
* An optional Security Association Attribute that enables negotiation of this SAD field between the two endpoints of an SA that supports tunnel mode.
* 可选的安全关联属性，支持在支持隧道模式的SA的两个端点之间协商此SAD字段。
* Changes to tunnel mode encapsulation and decapsulation processing to allow or forbid ECN usage in the outer IP header based on the value of the SAD field. When ECN usage is allowed in the outer IP header, the ECT codepoint is set in the outer header for ECN-capable connections and congestion notifications (indicated by the CE codepoint) from such connections are propagated to the inner header at tunnel egress.
* 根据SAD字段的值更改隧道模式封装和去封装处理，以允许或禁止在外部IP标头中使用ECN。当外部IP报头中允许使用ECN时，在外部报头中为支持ECN的连接设置ECT代码点，并且来自此类连接的拥塞通知（由CE代码点指示）在隧道出口处传播到内部报头。
If negotiation of ECN usage is implemented, then the SAD field SHOULD also be implemented. On the other hand, negotiation of ECN usage is OPTIONAL in all cases, even for implementations that support the SAD field. The encapsulation and decapsulation processing changes are REQUIRED, but MAY be implemented without the other two changes by assuming that ECN usage is always forbidden. The full-functionality alternative for ECN usage over IPsec tunnels consists of the SAD field and the full version of encapsulation and decapsulation processing changes, with or without the OPTIONAL negotiation support. The limited-functionality alternative consists of a subset of the encapsulation and decapsulation changes that always forbids ECN usage.
如果实现了ECN使用的协商，那么还应该实现SAD字段。另一方面，ECN使用的协商在所有情况下都是可选的，即使对于支持SAD字段的实现也是如此。封装和去封装处理更改是必需的，但可以在不进行其他两项更改的情况下实施，前提是始终禁止使用ECN。通过IPsec隧道使用ECN的完整功能替代方案包括SAD字段和完整版本的封装和去封装处理更改，包括或不包括可选的协商支持。有限功能替代方案由封装和去封装更改的子集组成，这些更改始终禁止使用ECN。
These changes are covered further in the following three subsections.
以下三个小节将进一步介绍这些更改。
Full ECN functionality adds a new field to the SAD (see [RFC2401]):
完整的ECN功能将一个新字段添加到SAD（请参见[RFC2401]）：
ECN Tunnel: allowed or forbidden.
ECN隧道：允许或禁止。
Indicates whether ECN-capable connections using this SA in tunnel mode are permitted to receive ECN congestion notifications for congestion occurring within the tunnel. The allowed value enables ECN congestion notifications. The forbidden value disables such notifications, causing all congestion to be indicated via dropped packets.
指示是否允许在隧道模式下使用此SA的支持ECN的连接接收隧道内发生拥塞的ECN拥塞通知。允许的值启用ECN拥塞通知。禁止值禁用此类通知，导致通过丢弃的数据包指示所有拥塞。
[OPTIONAL. The value of this field SHOULD be assumed to be "forbidden" in implementations that do not support it.]
[可选。在不支持此字段的实现中，应假定此字段的值为“禁止”。]
If this attribute is implemented, then the SA specification in a Security Policy Database (SPD) entry MUST support a corresponding attribute, and this SPD attribute MUST be covered by the SPD administrative interface (currently described in Section 4.4.1 of [RFC2401]).
如果实现了该属性，则安全策略数据库（SPD）条目中的SA规范必须支持相应的属性，并且SPD管理接口必须涵盖该SPD属性（目前在[RFC2401]第4.4.1节中描述）。
A new IPsec Security Association Attribute is defined to enable the support for ECN congestion notifications based on the outer IP header to be negotiated for IPsec tunnels (see [RFC2407]). This attribute is OPTIONAL, although implementations that support it SHOULD also support the SAD field defined in Section 9.2.1.1.
定义了一个新的IPsec安全关联属性，以支持基于IPsec隧道要协商的外部IP头的ECN拥塞通知（请参阅[RFC2407]）。该属性是可选的，尽管支持该属性的实现也应该支持第9.2.1.1节中定义的SAD字段。
Attribute Type
属性类型
class value type
-------------------------------------------------
ECN Tunnel 10 Basic
class value type
-------------------------------------------------
ECN Tunnel 10 Basic
The IPsec SA Attribute value 10 has been allocated by IANA to indicate that the ECN Tunnel SA Attribute is being negotiated; the type of this attribute is Basic (see Section 4.5 of [RFC2407]). The Class Values are used to conduct the negotiation. See [RFC2407, RFC2408, RFC2409] for further information including encoding formats and requirements for negotiating this SA attribute.
IANA已分配IPsec SA属性值10，以指示正在协商ECN隧道SA属性；该属性的类型为基本属性（见[RFC2407]第4.5节）。类值用于进行协商。请参阅[RFC2407、RFC2408、RFC2409]了解更多信息，包括协商此SA属性的编码格式和要求。
Class Values
阶级价值观
ECN Tunnel
ECN隧道
Specifies whether ECN functionality is allowed to be used with Tunnel Encapsulation Mode. This affects tunnel encapsulation and decapsulation processing - see Section 9.2.1.3.
指定是否允许ECN功能与隧道封装模式一起使用。这会影响隧道封装和脱封处理-见第9.2.1.3节。
RESERVED 0 Allowed 1 Forbidden 2
允许保留0 1禁止2
Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use.
值3-61439保留给IANA。值61440-65535仅供私人使用。
If unspecified, the default shall be assumed to be Forbidden.
如果未指定，则应假定默认为禁止。
ECN Tunnel is a new SA attribute, and hence initiators that use it can expect to encounter responders that do not understand it, and therefore reject proposals containing it. For backwards compatibility with such implementations initiators SHOULD always also include a proposal without the ECN Tunnel attribute to enable such a responder to select a transform or proposal that does not contain the ECN Tunnel attribute. RFC 2407 currently requires responders to reject all proposals if any proposal contains an unknown attribute; this requirement is expected to be changed to require a responder not to select proposals or transforms containing unknown attributes.
ECN Tunnel是一个新的SA属性，因此使用它的发起人可能会遇到不理解它的响应者，从而拒绝包含它的提案。为了与此类实现向后兼容，发起人还应始终包括不带ECN隧道属性的提案，以使此类响应者能够选择不包含ECN隧道属性的转换或提案。RFC 2407目前要求响应者拒绝所有提案，如果任何提案包含未知属性；这一要求预计将更改为要求响应者不选择包含未知属性的提议或转换。
For full ECN support, the encapsulation and decapsulation processing for the IPv4 TOS field and the IPv6 Traffic Class field are changed from that specified in [RFC2401] to the following:
为了完全支持ECN，IPv4 TOS字段和IPv6通信量类别字段的封装和解除封装处理将从[RFC2401]中指定的更改为以下内容：
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
DS Field copied from inner hdr (5) no change
ECN Field constructed (7) constructed (8)
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
DS Field copied from inner hdr (5) no change
ECN Field constructed (7) constructed (8)
IPv6 Header fields: DS Field copied from inner hdr (6) no change ECN Field constructed (7) constructed (8)
IPv6标头字段：从内部hdr复制的DS字段（6）构造的未更改ECN字段（7）构造的（8）
(5)(6) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [RFC 2474]. Also see [RFC 2475] for further information.
（5） （6）如果数据包将立即进入外部报头中的DSCP值不适用的域，则该值必须映射到该域的适当值[RFC 2474]。有关更多信息，请参见[RFC 2475]。
(7) If the value of the ECN Tunnel field in the SAD entry for this SA is "allowed" and the ECN field in the inner header is set to any value other than CE, copy this ECN field to the outer header. If the ECN field in the inner header is set to CE, then set the ECN field in the outer header to ECT(0).
(7) 如果此SA的SAD条目中的ECN隧道字段值为“允许”，且内部标头中的ECN字段设置为CE以外的任何值，则将此ECN字段复制到外部标头。如果内部标题中的ECN字段设置为CE，则将外部标题中的ECN字段设置为ECT（0）。
(8) If the value of the ECN tunnel field in the SAD entry for this SA is "allowed" and the ECN field in the inner header is set to ECT(0) or ECT(1) and the ECN field in the outer header is set to CE, then copy the ECN field from the outer header to the inner header. Otherwise, make no change to the ECN field in the inner header.
(8) 如果此SA的SAD条目中的ECN隧道字段值为“允许”，且内部标头中的ECN字段设置为ECT（0）或ECT（1），且外部标头中的ECN字段设置为CE，则将ECN字段从外部标头复制到内部标头。否则，不要更改内部标题中的ECN字段。
(5) and (6) are identical to match usage in [RFC2401], although they are different in [RFC2401].
(5) 和（6）与[RFC2401]中的匹配用法相同，尽管它们在[RFC2401]中有所不同。
The above description applies to implementations that support the ECN Tunnel field in the SAD; such implementations MUST implement this processing instead of the processing of the IPv4 TOS octet and IPv6 Traffic Class octet defined in [RFC2401]. This constitutes the full-functionality alternative for ECN usage with IPsec tunnels.
上述描述适用于支持SAD中的ECN隧道字段的实现；此类实现必须实现此处理，而不是[RFC2401]中定义的IPv4 TOS八位字节和IPv6流量类八位字节的处理。这构成了使用IPsec隧道的ECN的完整功能替代方案。
An implementation that does not support the ECN Tunnel field in the SAD MUST implement this processing by assuming that the value of the ECN Tunnel field of the SAD is "forbidden" for every SA. In this case, the processing of the ECN field reduces to:
不支持SAD中的ECN Tunnel字段的实现必须通过假设SAD的ECN Tunnel字段的值对于每个SA是“禁止的”来实现该处理。在这种情况下，ECN字段的处理减少到：
(7) Set the ECN field to not-ECT in the outer header. (8) Make no change to the ECN field in the inner header.
(7) 在外部标题中将ECN字段设置为not ECT。（8） 不要更改内部标题中的ECN字段。
This constitutes the limited functionality alternative for ECN usage with IPsec tunnels.
这构成了使用IPsec隧道的ECN的有限功能替代方案。
For backwards compatibility, packets with the CE codepoint set in the outer header SHOULD be dropped if they arrive on an SA that is using the limited-functionality option, or that is using the full-functionality option with the not-ECN codepoint set in the inner header.
为了向后兼容，如果数据包到达使用受限功能选项的SA上，或者在使用完整功能选项且内部报头中未设置ECN代码点，则应丢弃在外部报头中设置CE代码点的数据包。
9.2.2. Changes to the ECN Field within an IPsec Tunnel.
9.2.2. 对IPsec隧道内ECN字段的更改。
If the ECN Field is changed inappropriately within an IPsec tunnel, and this change is detected at the tunnel egress, then the receipt of a packet not satisfying the appropriate condition for its SA is an auditable event. An implementation MAY create audit records with per-SA counts of incorrect packets over some time period rather than creating an audit record for each erroneous packet. Any such audit record SHOULD contain the headers from at least one erroneous packet, but need not contain the headers from every packet represented by the entry.
如果在IPsec隧道内不适当地更改了ECN字段，并且在隧道出口处检测到该更改，则接收不满足其SA的适当条件的数据包是可审核事件。一个实现可以创建审计记录，其中包含某个时间段内每SA不正确数据包的计数，而不是为每个错误数据包创建审计记录。任何此类审计记录都应包含至少一个错误数据包的头，但不必包含条目表示的每个数据包的头。
Substantial comments were received on two areas of this document during review by the IPsec working group. This section describes these comments and explains why the proposed changes were not incorporated.
在IPsec工作组审查期间，收到了关于本文件两个方面的实质性意见。本节描述了这些意见，并解释了未纳入拟议变更的原因。
The first comment indicated that per-node configuration is easier to implement than per-SA configuration. After serious thought and despite some initial encouragement of per-node configuration, it no longer seems to be a good idea. The concern is that as ECN-awareness is progressively deployed in IPsec, many ECN-aware IPsec implementations will find themselves communicating with a mixture of ECN-aware and ECN-unaware IPsec tunnel endpoints. In such an environment with per-node configuration, the only reasonable thing to do is forbid ECN usage for all IPsec tunnels, which is not the desired outcome.
第一条注释指出，每个节点配置比每个SA配置更易于实现。经过认真思考，尽管最初鼓励每个节点配置，但这似乎不再是一个好主意。问题在于，随着ECN感知逐渐部署到IPsec中，许多ECN感知IPsec实现将发现自己与ECN感知和ECN感知IPsec隧道端点的混合通信。在这种具有每个节点配置的环境中，唯一合理的做法是禁止所有IPsec隧道使用ECN，这不是期望的结果。
In the second area, several reviewers noted that SA negotiation is complex, and adding to it is non-trivial. One reviewer suggested using ICMP after tunnel setup as a possible alternative. The addition to SA negotiation in this document is OPTIONAL and will remain so; implementers are free to ignore it. The authors believe that the assurance it provides can be useful in a number of situations. In practice, if this is not implemented, it can be deleted at a subsequent stage in the standards process. Extending ICMP to negotiate ECN after tunnel setup is more complex than extending SA attribute negotiation. Some tunnels do not permit traffic to be addressed to the tunnel egress endpoint, hence the ICMP packet would have to be addressed to somewhere else, scanned for by the egress endpoint, and discarded there or at its actual destination. In addition, ICMP delivery is unreliable, and hence there is a possibility of an ICMP packet being dropped, entailing the invention of yet another ack/retransmit mechanism. It seems better simply to specify an OPTIONAL extension to the existing SA negotiation mechanism.
在第二个领域，几位评审员指出，SA协商是复杂的，添加到SA协商中是非常重要的。一位评审员建议在隧道设置后使用ICMP作为可能的替代方案。本文件中对SA谈判的补充是可选的，并将继续如此；实现者可以随意忽略它。作者认为，它提供的保证在许多情况下都是有用的。在实践中，如果没有实施，可以在标准流程的后续阶段删除。在隧道设置后扩展ICMP以协商ECN比扩展SA属性协商更复杂。一些隧道不允许将流量寻址到隧道出口端点，因此ICMP数据包必须寻址到其他地方，由出口端点扫描，并在那里或其实际目的地丢弃。此外，ICMP传递不可靠，因此存在ICMP分组被丢弃的可能性，这意味着发明了另一种ack/重传机制。简单地指定对现有SA协商机制的可选扩展似乎更好。
9.3. IP packets encapsulated in non-IP Packet Headers.
9.3. 封装在非IP数据包头中的IP数据包。
A different set of issues are raised, relative to ECN, when IP packets are encapsulated in tunnels with non-IP packet headers. This occurs with MPLS [MPLS], GRE [GRE], L2TP [L2TP], and PPTP [PPTP]. For these protocols, there is no conflict with ECN; it is just that ECN cannot be used within the tunnel unless an ECN codepoint can be specified for the header of the encapsulating protocol. Earlier work considered a preliminary proposal for incorporating ECN into MPLS, and proposals for incorporating ECN into GRE, L2TP, or PPTP will be considered as the need arises.
当IP数据包被封装在带有非IP数据包头的隧道中时，与ECN相关的另一组问题被提出。这发生在MPLS[MPLS]、GRE[GRE]、L2TP[L2TP]和PPTP[PPTP]中。对于这些协议，与ECN没有冲突；只是ECN不能在隧道中使用，除非可以为封装协议的头指定ECN代码点。早期的工作考虑了将ECN纳入MPLS的初步提案，并将根据需要考虑将ECN纳入GRE、L2TP或PPTP的提案。
One possibility is that monitoring and policing devices (or more informally, "penalty boxes") will be installed in the network to monitor whether best-effort flows are appropriately responding to congestion, and to preferentially drop packets from flows determined not to be using adequate end-to-end congestion control procedures.
一种可能性是，将在网络中安装监控和监管设备（或更非正式地称为“惩罚盒”），以监控尽力而为的流是否适当地响应拥塞，并优先从确定未使用适当的端到端拥塞控制程序的流中丢弃数据包。
We recommend that any "penalty box" that detects a flow or an aggregate of flows that is not responding to end-to-end congestion control first change from marking to dropping packets from that flow, before taking any additional action to restrict the bandwidth available to that flow. Thus, initially, the router may drop packets in which the router would otherwise would have set the CE codepoint. This could include dropping those arriving packets for that flow that are ECN-Capable and that already have the CE codepoint set. In this way, any congestion indications seen by that router for that flow will be guaranteed to also be seen by the end nodes, even in the presence of malicious or broken routers elsewhere in the path. If we assume that the first action taken at any "penalty box" for an ECN-capable flow will be to drop packets instead of marking them, then there is no way that an adversary that subverts ECN-based end-to-end congestion control can cause a flow to be characterized as being non-cooperative and placed into a more severe action within the "penalty box".
我们建议，在采取任何额外措施限制该流的可用带宽之前，检测到未响应端到端拥塞控制的流或流集合的任何“惩罚框”都应首先从标记流更改为丢弃该流中的数据包。因此，最初，路由器可以丢弃路由器本来会在其中设置CE码点的分组。这可能包括丢弃该流中具有ECN功能且已设置CE码点的到达数据包。这样，即使在路径中的其他地方存在恶意或损坏的路由器，该路由器针对该流看到的任何拥塞指示也将保证终端节点也能看到。如果我们假设，对于支持ECN的流，在任何“惩罚框”处采取的第一个行动将是丢弃数据包，而不是标记数据包，那么颠覆基于ECN的端到端拥塞控制的对手就不可能导致流被描述为不合作，并在网络中被置于更严重的行动中“罚款箱”。
The monitoring and policing devices that are actually deployed could fall short of the `ideal' monitoring device described above, in that the monitoring is applied not to a single flow, but to an aggregate of flows (e.g., those sharing a single IPsec tunnel). In this case, the switch from marking to dropping would apply to all of the flows in that aggregate, denying the benefits of ECN to the other flows in the aggregate also. At the highest level of aggregation, another form of the disabling of ECN happens even in the absence of
实际部署的监视和监控设备可能无法达到上述“理想”监视设备，因为监视不是应用于单个流，而是应用于流的集合（例如，共享单个IPsec隧道的流）。在这种情况下，从标记到删除的切换将适用于该聚合中的所有流，从而也将ECN的好处剥夺给聚合中的其他流。在聚合的最高级别上，即使在没有
monitoring and policing devices, when ECN-Capable RED queues switch from marking to dropping packets as an indication of congestion when the average queue size has exceeded some threshold.
当平均队列大小超过某个阈值时，当支持ECN的红色队列从标记切换到丢弃数据包，作为拥塞指示时，监视和监控设备。
This section discusses some of the related work evaluating the use of ECN. The ECN Web Page [ECN] has pointers to other papers, as well as to implementations of ECN.
本节讨论评估ECN使用的一些相关工作。ECN网页[ECN]有指向其他论文以及ECN实现的指针。
[Floyd94] considers the advantages and drawbacks of adding ECN to the TCP/IP architecture. As shown in the simulation-based comparisons, one advantage of ECN is to avoid unnecessary packet drops for short or delay-sensitive TCP connections. A second advantage of ECN is in avoiding some unnecessary retransmit timeouts in TCP. This paper discusses in detail the integration of ECN into TCP's congestion control mechanisms. The possible disadvantages of ECN discussed in the paper are that a non-compliant TCP connection could falsely advertise itself as ECN-capable, and that a TCP ACK packet carrying an ECN-Echo message could itself be dropped in the network. The first of these two issues is discussed in the appendix of this document, and the second is addressed by the addition of the CWR flag in the TCP header.
[Floyd94]考虑了将ECN添加到TCP/IP体系结构的优点和缺点。如基于模拟的比较所示，ECN的一个优点是避免了对短或延迟敏感的TCP连接不必要的丢包。ECN的第二个优点是避免了TCP中一些不必要的重传超时。本文详细讨论了ECN与TCP拥塞控制机制的集成。本文中讨论的ECN可能存在的缺点是，不兼容的TCP连接可能会错误地将自身宣传为具有ECN功能，并且携带ECN回显消息的TCP ACK数据包本身可能会在网络中丢弃。这两个问题中的第一个在本文档的附录中讨论，第二个问题通过在TCP标头中添加CWR标志来解决。
Experimental evaluations of ECN include [RFC2884,K98]. The conclusions of [K98] and [RFC2884] are that ECN TCP gets moderately better throughput than non-ECN TCP; that ECN TCP flows are fair towards non-ECN TCP flows; and that ECN TCP is robust with two-way traffic (with congestion in both directions) and with multiple congested gateways. Experiments with many short web transfers show that, while most of the short connections have similar transfer times with or without ECN, a small percentage of the short connections have very long transfer times for the non-ECN experiments as compared to the ECN experiments.
ECN的实验评估包括[RFC2884，K98]。[K98]和[RFC2884]的结论是，ECN TCP的吞吐量略好于非ECN TCP；ECN TCP流对非ECN TCP流是公平的；ECN TCP对双向流量（双向拥塞）和多个拥塞网关都很健壮。对许多短web传输的实验表明，尽管大多数短连接在有或没有ECN的情况下具有相似的传输时间，但与ECN实验相比，非ECN实验中有一小部分短连接具有很长的传输时间。
11.2. A Discussion of the ECN nonce.
11.2. 关于ECN的讨论。
The use of two ECT codepoints, ECT(0) and ECT(1), can provide a one-bit ECN nonce in packet headers [SCWA99]. The primary motivation for this is the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol. This section discusses issues of backwards compatibility with IP ECN implementations in routers conformant with RFC 2481, in which only one ECT codepoint was defined. We do not believe that the
使用两个ECT码点，ECT（0）和ECT（1），可以在数据包头[SCWA99]中提供一位ECN nonce。这样做的主要动机是希望允许数据发送方的机制验证网络元素没有擦除CE码点，并且数据接收方按照传输协议的要求正确地向发送方报告接收到具有CE码点集的数据包。本节讨论符合RFC 2481的路由器中IP ECN实现的向后兼容性问题，其中仅定义了一个ECT码点。我们不相信
incremental deployment of ECN implementations that understand the ECT(1) codepoint will cause significant operational problems. This is particularly likely to be the case when the deployment of the ECT(1) codepoint begins with routers, before the ECT(1) codepoint starts to be used by end-nodes.
理解ECT（1）代码点的ECN实现的增量部署将导致严重的操作问题。当终端节点开始使用ECT（1）码点之前，ECT（1）码点的部署从路由器开始时，这种情况尤其可能发生。
11.2.1. The Incremental Deployment of ECT(1) in Routers.
11.2.1. 路由器中ECT（1）的增量部署。
ECN has been an Experimental standard since January 1999, and there are already implementations of ECN in routers that do not understand the ECT(1) codepoint. When the use of the ECT(1) codepoint is standardized for TCP or for other transport protocols, this could mean that a data sender is using the ECT(1) codepoint, but that this codepoint is not understood by a congested router on the path.
ECN自1999年1月以来一直是一个实验性标准，并且已经有不理解ECT（1）码点的路由器实现了ECN。当针对TCP或其他传输协议对ECT（1）码点的使用进行标准化时，这可能意味着数据发送方正在使用ECT（1）码点，但路径上的拥塞路由器无法理解该码点。
If allowed by the transport protocol, a data sender would be free not to make use of ECT(1) at all, and to send all ECN-capable packets with the codepoint ECT(0). However, if an ECN-capable sender is using ECT(1), and the congested router on the path did not understand the ECT(1) codepoint, then the router would end up marking some of the ECT(0) packets, and dropping some of the ECT(1) packets, as indications of congestion. Since TCP is required to react to both marked and dropped packets, this behavior of dropping packets that could have been marked poses no significant threat to the network, and is consistent with the overall approach to ECN that allows routers to determine when and whether to mark packets as they see fit (see Section 5).
如果传输协议允许，数据发送方将完全可以不使用ECT（1），并且可以使用代码点ECT（0）发送所有支持ECN的数据包。然而，如果具有ECN能力的发送方正在使用ECT（1），并且路径上的拥塞路由器不理解ECT（1）码点，则路由器最终将标记一些ECT（0）数据包，并丢弃一些ECT（1）数据包，作为拥塞指示。由于TCP需要对标记的数据包和丢弃的数据包做出反应，这种丢弃可能已标记的数据包的行为不会对网络造成重大威胁，并且与ECN的总体方法一致，该方法允许路由器确定何时以及是否标记其认为合适的数据包（参见第5节）。
This document specified two bits in the IP header to be used for ECN. The not-ECT codepoint indicates that the transport protocol will ignore the CE codepoint. This is the default value for the ECN codepoint. The ECT codepoints indicate that the transport protocol is willing and able to participate in ECN.
本文档在IP头中指定了两位用于ECN。not ECT代码点表示传输协议将忽略CE代码点。这是ECN代码点的默认值。ECT码点表明传输协议愿意并且能够参与ECN。
The router sets the CE codepoint to indicate congestion to the end nodes. The CE codepoint in a packet header MUST NOT be reset by a router.
路由器设置CE码点以指示终端节点的拥塞。路由器不得重置数据包头中的CE码点。
TCP requires three changes for ECN, a setup phase and two new flags in the TCP header. The ECN-Echo flag is used by the data receiver to inform the data sender of a received CE packet. The Congestion Window Reduced (CWR) flag is used by the data sender to inform the data receiver that the congestion window has been reduced.
TCP需要对ECN进行三次更改，一个设置阶段和TCP头中的两个新标志。数据接收器使用ECN Echo标志通知数据发送者接收到的CE数据包。数据发送方使用拥塞窗口缩减（CWR）标志通知数据接收方拥塞窗口已缩减。
When ECN (Explicit Congestion Notification) is used, it is required that congestion indications generated within an IP tunnel not be lost at the tunnel egress. We specified a minor modification to the IP protocol's handling of the ECN field during encapsulation and de-capsulation to allow flows that will undergo IP tunneling to use ECN.
当使用ECN（显式拥塞通知）时，要求IP隧道内生成的拥塞指示不会在隧道出口丢失。我们指定在封装和反封装期间对IP协议的ECN字段处理进行一次小的修改，以允许将经历IP隧道的流使用ECN。
Two options for ECN in tunnels were specified:
规定了隧道中ECN的两个选项：
1) A limited-functionality option that does not use ECN inside the IP tunnel, by setting the ECN field in the outer header to not-ECT, and not altering the inner header at the time of decapsulation.
1) 通过将外部标头中的ECN字段设置为not ECT，并且在解除封装时不更改内部标头，在IP隧道内不使用ECN的有限功能选项。
2) The full-functionality option, which sets the ECN field in the outer header to either not-ECT or to one of the ECT codepoints, depending on the ECN field in the inner header. At decapsulation, if the CE codepoint is set in the outer header, and the inner header is set to one of the ECT codepoints, then the CE codepoint is copied to the inner header.
2) 完整功能选项，根据内部标题中的ECN字段，将外部标题中的ECN字段设置为not ECT或其中一个ECT代码点。在解除封装时，如果CE码点设置在外部报头中，而内部报头设置为ECT码点之一，则CE码点复制到内部报头。
For IPsec tunnels, this document also defines an optional IPsec Security Association (SA) attribute that enables negotiation of ECN usage within IPsec tunnels and an optional field in the Security Association Database to indicate whether ECN is permitted in tunnel mode on a SA. The required changes to IPsec tunnels for ECN usage modify RFC 2401 [RFC2401], which defines the IPsec architecture and specifies some aspects of its implementation. The new IPsec SA attribute is in addition to those already defined in Section 4.5 of [RFC2407].
对于IPsec隧道，本文档还定义了一个可选的IPsec安全关联（SA）属性，该属性允许在IPsec隧道内协商ECN使用情况，并在安全关联数据库中定义了一个可选字段，以指示是否允许在SA的隧道模式下使用ECN。ECN使用对IPsec隧道所需的更改修改了RFC 2401[RFC2401]，它定义了IPsec体系结构并指定了其实现的一些方面。新的IPsec SA属性是对[RFC2407]第4.5节中已经定义的属性的补充。
This document obsoletes RFC 2481, "A Proposal to add Explicit Congestion Notification (ECN) to IP", which defined ECN as an Experimental Protocol for the Internet Community. The rest of this section describes the relationship between this document and its predecessor.
本文件废除了RFC2481，“向IP添加显式拥塞通知（ECN）的提案”，该提案将ECN定义为互联网社区的实验协议。本节的其余部分描述了本文档与其前身之间的关系。
RFC 2481 included a brief discussion of the use of ECN with encapsulated packets, and noted that for the IPsec specifications at the time (January 1999), flows could not safely use ECN if they were to traverse IPsec tunnels. RFC 2481 also described the changes that could be made to IPsec tunnel specifications to made them compatible with ECN.
RFC 2481简要讨论了ECN在封装数据包中的使用，并指出，对于当时的IPsec规范（1999年1月），如果流要穿越IPsec隧道，则无法安全使用ECN。RFC2481还描述了可以对IPsec隧道规范进行的更改，以使其与ECN兼容。
This document also incorporates work that was done after RFC 2481. First was to describe the changes to IPsec tunnels in detail, and extensively discuss the security implications of ECN (now included as Sections 18 and 19 of this document). Second was to extend the discussion of IPsec tunnels to include all IP tunnels. Because older IP tunnels are not compatible with a flow's use of ECN, the
本文件还包含RFC 2481之后完成的工作。首先是详细描述IPsec隧道的更改，并广泛讨论ECN的安全影响（现在包含在本文档的第18和19节中）。第二是将IPsec隧道的讨论扩展到包括所有IP隧道。由于较旧的IP隧道与流对ECN的使用不兼容
deployment of ECN in the Internet will create strong pressure for older IP tunnels to be updated to an ECN-compatible version, using either the limited-functionality or the full-functionality option.
在互联网上部署ECN将给旧的IP隧道带来强大的压力，需要使用有限功能或全功能选项将其更新为与ECN兼容的版本。
This document does not address the issue of including ECN in non-IP tunnels such as MPLS, GRE, L2TP, or PPTP. An earlier preliminary document about adding ECN support to MPLS was not advanced.
本文档不涉及在MPLS、GRE、L2TP或PPTP等非IP隧道中包含ECN的问题。早期关于向MPLS添加ECN支持的初步文件没有提出。
A third new piece of work after RFC2481 was to describe the ECN procedure with retransmitted data packets, that an ECT codepoint should not be set on retransmitted data packets. The motivation for this additional specification is to eliminate a possible avenue for denial-of-service attacks on an existing TCP connection. Some prior deployments of ECN-capable TCP might not conform to the (new) requirement not to set an ECT codepoint on retransmitted packets; we do not believe this will cause significant problems in practice.
RFC2481之后的第三项新工作是描述具有重传数据包的ECN过程，即不应在重传数据包上设置ECT码点。此附加规范的目的是消除对现有TCP连接进行拒绝服务攻击的可能途径。一些先前部署的支持ECN的TCP可能不符合（新）要求，即不在重新传输的数据包上设置ECT码点；我们认为这不会在实践中造成重大问题。
This document also expands slightly on the specification of the use of SYN packets for the negotiation of ECN. While some prior deployments of ECN-capable TCP might not conform to the requirements specified in this document, we do not believe that this will lead to any performance or compatibility problems for TCP connections with a combination of TCP implementations at the endpoints.
本文档还略微扩展了用于ECN协商的SYN数据包的使用规范。虽然以前的一些支持ECN的TCP部署可能不符合本文档中指定的要求，但我们不认为这会导致TCP连接在端点上结合使用TCP实现时出现任何性能或兼容性问题。
This document also includes the specification of the ECT(1) codepoint, which may be used by TCP as part of the implementation of an ECN nonce.
本文档还包括ECT（1）代码点的规范，TCP可将其用作ECN nonce实现的一部分。
Given the current effort to implement AQM, we believe this is the right time to deploy congestion avoidance mechanisms that do not depend on packet drops alone. With the increased deployment of applications and transports sensitive to the delay and loss of a single packet (e.g., realtime traffic, short web transfers), depending on packet loss as a normal congestion notification mechanism appears to be insufficient (or at the very least, non-optimal).
鉴于目前实施AQM的努力，我们认为现在正是部署拥塞避免机制的适当时机，这些机制不单独依赖于丢包。随着对单个数据包的延迟和丢失（例如，实时流量、短web传输）敏感的应用程序和传输部署的增加，依靠数据包丢失作为正常的拥塞通知机制似乎是不够的（或者至少是非最佳的）。
We examined the consequence of modifications of the ECN field within the network, analyzing all the opportunities for an adversary to change the ECN field. In many cases, the change to the ECN field is no worse than dropping a packet. However, we noted that some changes have the more serious consequence of subverting end-to-end congestion control. However, we point out that even then the potential damage is limited, and is similar to the threat posed by end-systems intentionally failing to cooperate with end-to-end congestion control.
我们检查了网络内ECN场修改的结果，分析了对手改变ECN场的所有机会。在许多情况下，对ECN字段的更改并不比丢弃数据包更糟糕。但是，我们注意到，某些更改会破坏端到端拥塞控制，从而产生更严重的后果。然而，我们指出，即使这样，潜在的损害也是有限的，类似于端系统故意不配合端到端拥塞控制所造成的威胁。
Many people have made contributions to this work and this document, including many that we have not managed to directly acknowledge in this document. In addition, we would like to thank Kenjiro Cho for the proposal for the TCP mechanism for negotiating ECN-Capability, Kevin Fall for the proposal of the CWR bit, Steve Blake for material on IPv4 Header Checksum Recalculation, Jamal Hadi-Salim for discussions of ECN issues, and Steve Bellovin, Jim Bound, Brian Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall, and Vern Paxson for discussions of security issues. We also thank the Internet End-to-End Research Group for ongoing discussions of these issues.
许多人对这项工作和本文件作出了贡献，包括我们在本文件中没有直接承认的许多人。此外，我们要感谢Kenjiro Cho关于协商ECN能力的TCP机制的提议，Kevin Fall关于CWR bit的提议，Steve Blake关于IPv4报头校验和重新计算的材料，Jamal Hadi Salim关于ECN问题的讨论，以及Steve Bellovin，Jim Bound，Brian Carpenter，Paul Ferguson，斯蒂芬·肯特、格雷格·明索尔和弗恩·帕克森讨论了安全问题。我们还感谢互联网端到端研究小组对这些问题的持续讨论。
Email discussions with a number of people, including Dax Kelson, Alexey Kuznetsov, Jamal Hadi-Salim, and Venkat Venkatsubra, have addressed the issues raised by non-conformant equipment in the Internet that does not respond to TCP SYN packets with the ECE and CWR flags set. We thank Mark Handley, Jitentra Padhye, and others for discussions on the TCP initialization procedures.
与一些人（包括Dax Kelson、Alexey Kuznetsov、Jamal Hadi Salim和Venkat Venkatsubra）的电子邮件讨论解决了互联网上不符合要求的设备所引发的问题，这些设备不响应设置ECE和CWR标志的TCP SYN数据包。我们感谢Mark Handley、Jitentra Padhye和其他人对TCP初始化过程的讨论。
The discussion of ECN and IP tunnel considerations draws heavily on related discussions and documents from the Differentiated Services Working Group. We thank Tabassum Bint Haque from Dhaka, Bangladesh, for feedback on IP tunnels. We thank Derrell Piper and Kero Tivinen for proposing modifications to RFC 2407 that improve the usability of negotiating the ECN Tunnel SA attribute.
关于ECN和IP隧道考虑事项的讨论大量借鉴了差异化服务工作组的相关讨论和文件。我们感谢来自孟加拉国达卡的Tabassum Bint Haque对IP隧道的反馈。我们感谢Derrell Piper和Kero Tivinen提议对RFC 2407进行修改，以提高协商ECN隧道SA属性的可用性。
We thank David Wetherall, David Ely, and Neil Spring for the proposal for the ECN nonce. We also thank Stefan Savage for discussions on this issue. We thank Bob Briscoe and Jon Crowcroft for raising the issue of fragmentation in IP, on alternate semantics for the fourth ECN codepoint, and several other topics. We thank Richard Wendland for feedback on several issues in the document.
我们感谢David Wetheral、David Ely和Neil Spring为ECN提出的建议。我们还感谢斯特凡·萨维奇就此问题进行的讨论。我们感谢Bob Briscoe和Jon Crowcroft提出了IP中的碎片问题、第四个ECN代码点的替代语义以及其他一些主题。我们感谢Richard Wendland对文件中几个问题的反馈。
We also thank the IESG, and in particular the Transport Area Directors over the years, for their feedback and their work towards the standardization of ECN.
我们还感谢IESG，特别是多年来运输部门主管的反馈意见以及他们为ECN标准化所做的工作。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[ECN] "The ECN Web Page", URL "http://www.aciri.org/floyd/ecn.html". Reference for informational purposes only.
[ECN]“ECN网页”，URLhttp://www.aciri.org/floyd/ecn.html". 仅供参考。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效载荷”，RFC 2406，1998年11月。
[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL "http://gtf.org/garzik/ecn/". Reference for informational purposes only.
[FIXES]Linux下的ECN非官方供应商支持页面，URL“http://gtf.org/garzik/ecn/". 仅供参考。
[FJ93] Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
[FJ93]Floyd，S.和Jacobson，V.，“避免拥塞的随机早期检测网关”，IEEE/ACM网络交易，第1卷第4期，1993年8月，第页。397-413.
[Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23.
[Floyd94]Floyd，S.，“TCP和显式拥塞通知”，《ACM计算机通信评论》，第24卷第5期，1994年10月，第页。10-23.
[Floyd98] Floyd, S., "The ECN Validation Test in the NS Simulator", URL "http://www-mash.cs.berkeley.edu/ns/", test tcl/test/test-all- ecn. Reference for informational purposes only.
[Floyd98]Floyd，S.，“NS模拟器中的ECN验证测试”，URL“http://www-mash.cs.berkeley.edu/ns/，test tcl/test/test all-ecn。仅供参考。
[FF99] Floyd, S., and Fall, K., "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF99]Floyd，S.，和Fall，K.，“促进互联网中端到端拥塞控制的使用”，IEEE/ACM网络交易，1999年8月。
[FRED] Lin, D., and Morris, R., "Dynamics of Random Early Detection", SIGCOMM '97, September 1997.
[FRED]Lin，D.和Morris，R.，“随机早期检测的动力学”，SIGCOMM'971997年9月。
[GRE] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[GRE]Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[Jacobson88] V. Jacobson, "Congestion Avoidance and Control", Proc. ACM SIGCOMM '88, pp. 314-329.
[Jacobson88]V.Jacobson，“拥塞避免和控制”，程序。ACM SIGCOMM'88，第314-329页。
[Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", Message to end2end-interest mailing list, April 1990. URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt".
[Jacobson90]V.Jacobson，“改进的TCP拥塞避免算法”，发送至End2的邮件列表，1990年4月。URL“ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt".
[K98] Krishnan, H., "Analyzing Explicit Congestion Notification (ECN) benefits for TCP", Master's thesis, UCLA, 1998. Citation for acknowledgement purposes only.
[K98]Krishnan，H.，“分析显式拥塞通知（ECN）对TCP的好处”，硕士论文，加州大学洛杉矶分校，1998年。引文仅供确认之用。
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[L2TP]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议”L2TP“，RFC 26611999年8月。
[MJV96] S. McCanne, V. Jacobson, and M. Vetterli, "Receiver-driven Layered Multicast", SIGCOMM '96, August 1996, pp. 117-130.
[MJV96]S.McCanne、V.Jacobson和M.Vetterli，“接收器驱动分层多播”，SIGCOMM'961996年8月，第117-130页。
[MPLS] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, Requirements for Traffic Engineering Over MPLS, RFC 2702, September 1999.
[MPLS]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，MPLS流量工程要求，RFC 2702，1999年9月。
[PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[PPTP]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1141] Mallory, T. and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, January 1990.
[RFC1141]Mallory，T.和A.Kullberg，“互联网校验和的增量更新”，RFC 114119990年1月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349]Almquist，P.，“互联网协议套件中的服务类型”，RFC1349，1992年7月。
[RFC1455] Eastlake, D., "Physical Link Security Type of Service", RFC 1455, May 1993.
[RFC1455]Eastlake，D.，“物理链路安全服务类型”，RFC 1455，1993年5月。
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
[RFC1702]Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“IPv4网络上的通用路由封装”，RFC 1702，1994年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2309] Braden, B., et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]Braden，B.，等人，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC2401] Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，互联网协议的安全架构，RFC 2401，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2409, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2409，1998年11月。
[RFC2409] Harkins D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[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, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2481] Ramakrishnan K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RFC2481]Ramakrishnan K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[RFC2581] Alman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Alman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", RFC 2884, July 2000.
[RFC2884]Hadi Salim，J.和U.Ahmed，“IP网络中显式拥塞通知（ECN）的性能评估”，RFC 2884，2000年7月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC2983，2000年10月。
[RFC2780] Bradner S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RJ90] K. K. Ramakrishnan and Raj Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions on Computer Systems, Vol.8, No.2, pp. 158-181, May 1990.
[RJ90]K.K.Ramakrishnan和Raj Jain，“计算机网络中避免拥塞的二进制反馈方案”，ACM计算机系统交易，第8卷，第2期，第158-181页，1990年5月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.
[SCWA99]Stefan Savage、Neal Cardwell、David Wetheral和Tom Anderson，TCP拥塞控制与行为不端的接收器，ACM计算机通信评论，1999年10月。
[TBIT] Jitendra Padhye and Sally Floyd, "Identifying the TCP Behavior of Web Servers", ICSI TR-01-002, February 2001. URL "http://www.aciri.org/tbit/".
[TBIT]Jitendra Padhye和Sally Floyd，“识别Web服务器的TCP行为”，ICSI TR-01-002，2001年2月。URL“http://www.aciri.org/tbit/".
Security considerations have been discussed in Sections 7, 8, 18, and 19.
第7、8、18和19节讨论了安全考虑。
IPv4 header checksum recalculation is an issue with some high-end router architectures using an output-buffered switch, since most if not all of the header manipulation is performed on the input side of the switch, while the ECN decision would need to be made local to the output buffer. This is not an issue for IPv6, since there is no IPv6 header checksum. The IPv4 TOS octet is the last byte of a 16-bit half-word.
IPv4报头校验和重新计算是一些使用输出缓冲交换机的高端路由器体系结构的一个问题，因为大部分（如果不是全部的话）报头操作都是在交换机的输入端执行的，而ECN决策需要在输出缓冲区的本地进行。这不是IPv6的问题，因为没有IPv6标头校验和。IPv4 TOS八位字节是16位半字的最后一个字节。
RFC 1141 [RFC1141] discusses the incremental updating of the IPv4 checksum after the TTL field is decremented. The incremental updating of the IPv4 checksum after the CE codepoint was set would work as follows: Let HC be the original header checksum for an ECT(0) packet, and let HC' be the new header checksum after the CE bit has been set. That is, the ECN field has changed from '10' to '11'. Then for header checksums calculated with one's complement subtraction, HC' would be recalculated as follows:
RFC 1141[RFC1141]讨论了TTL字段递减后IPv4校验和的增量更新。在设置CE代码点后，IPv4校验和的增量更新将按如下方式进行：让HC为ECT（0）数据包的原始报头校验和，让HC'为设置CE位后的新报头校验和。也就是说，ECN字段已从“10”更改为“11”。然后，对于使用补码减法计算的报头校验和，HC'将重新计算如下：
HC' = { HC - 1 HC > 1
{ 0x0000 HC = 1
HC' = { HC - 1 HC > 1
{ 0x0000 HC = 1
For header checksums calculated on two's complement machines, HC' would be recalculated as follows after the CE bit was set:
对于在两个补码机器上计算的报头校验和，在设置CE位后，HC'将按如下方式重新计算：
HC' = { HC - 1 HC > 0
{ 0xFFFE HC = 0
HC' = { HC - 1 HC > 0
{ 0xFFFE HC = 0
A similar incremental updating of the IPv4 checksum can be carried out when the ECN field is changed from ECT(1) to CE, that is, from ' 01' to '11'.
当ECN字段从ECT（1）更改为CE（即从“01”更改为“11”）时，可以执行IPv4校验和的类似增量更新。
This section discusses in detail possible changes to the ECN field in the network, such as falsely reporting congestion, disabling ECN-Capability for an individual packet, erasing the ECN congestion indication, or falsely indicating ECN-Capability.
本节详细讨论网络中ECN字段的可能更改，例如错误报告拥塞、禁用单个数据包的ECN能力、擦除ECN拥塞指示或错误指示ECN能力。
First, we consider the changes that a router could make that would result in effectively erasing the congestion indication after it had been set by a router upstream. The convention followed is: ECN codepoint of received packet -> ECN codepoint of packet transmitted.
首先，我们考虑路由器可以做出的更改，这将导致路由器在上游设置路由器后有效地清除拥塞指示。遵循的约定是：接收数据包的ECN码点->发送数据包的ECN码点。
Replacing the CE codepoint with the ECT(0) or ECT(1) codepoint effectively erases the congestion indication. However, with the use of two ECT codepoints, a router erasing the CE codepoint has no way to know whether the original ECT codepoint was ECT(0) or ECT(1). Thus, it is possible for the transport protocol to deploy mechanisms to detect such erasures of the CE codepoint.
用ECT（0）或ECT（1）代码点替换CE代码点可以有效地清除拥塞指示。然而，使用两个ECT码点时，清除CE码点的路由器无法知道原始ECT码点是ECT（0）还是ECT（1）。因此，传输协议可以部署机制来检测CE码点的这种擦除。
The consequence of the erasure of the CE codepoint for the upstream router is that there is a potential for congestion to build for a time, because the congestion indication does not reach the source. However, the packet would be received and acknowledged.
擦除上游路由器的CE码点的结果是，由于拥塞指示没有到达源，因此有可能在一段时间内建立拥塞。然而，数据包将被接收和确认。
The potential effect of erasing the congestion indication is complex, and is discussed in depth in Section 19 below. Note that the effect of erasing the congestion indication is different from dropping a packet in the network. When a data packet is dropped, the drop is detected by the TCP sender, and interpreted as an indication of congestion. Similarly, if a sufficient number of consecutive acknowledgement packets are dropped, causing the cumulative acknowledgement field not to be advanced at the sender, the sender is limited by the congestion window from sending additional packets, and ultimately the retransmit timer expires.
消除拥塞指示的潜在影响是复杂的，下文第19节将对此进行深入讨论。注意，擦除拥塞指示的效果不同于在网络中丢弃分组。当数据包丢失时，TCP发送方会检测到丢失，并将其解释为拥塞指示。类似地，如果丢弃了足够数量的连续确认分组，导致累积确认字段在发送方处不前进，则发送方受到拥塞窗口的限制，不能发送额外分组，并且最终重传计时器过期。
In contrast, a systematic erasure of the CE bit by a downstream router can have the effect of causing a queue buildup at an upstream router, including the possible loss of packets due to buffer overflow. There is a potential of unfairness in that another flow that goes through the congested router could react to the CE bit set while the flow that has the CE bit erased could see better performance. The limitations on this potential unfairness are discussed in more detail in Section 19 below.
相反，由下游路由器对CE位的系统擦除可具有导致上游路由器处的队列累积的效果，包括由于缓冲区溢出而可能的分组丢失。通过拥塞路由器的另一个流可能会对CE位集做出反应，而删除CE位的流可能会看到更好的性能，这可能存在不公平性。下文第19节将更详细地讨论这种潜在不公平的限制。
The last of the three changes is to replace the CE codepoint with the not-ECT codepoint, thus erasing the congestion indication and disabling ECN-Capability at the same time.
三个更改中的最后一个更改是将CE代码点替换为非ECT代码点，从而消除拥塞指示并同时禁用ECN功能。
The `erasure' of the congestion indication is only effective if the packet does not end up being marked or dropped again by a downstream router. If the CE codepoint is replaced by an ECT codepoint, the
拥塞指示的“擦除”仅在数据包没有被下游路由器再次标记或丢弃时有效。如果CE代码点被ECT代码点替换，则
packet remains ECN-Capable, and could be either marked or dropped by a downstream router as an indication of congestion. If the CE codepoint is replaced by the not-ECT codepoint, the packet is no longer ECN-capable, and can therefore be dropped but not marked by a downstream router as an indication of congestion.
数据包保持ECN功能，并且可以由下游路由器标记或丢弃，作为拥塞的指示。如果CE码点被not ECT码点替换，则数据包不再具有ECN能力，因此可以丢弃，但不会被下游路由器标记为拥塞指示。
This change is to set the CE codepoint when an ECT codepoint was already set, even though there was no congestion. This change does not affect the treatment of that packet along the rest of the path. In particular, a router does not examine the CE codepoint in deciding whether to drop or mark an arriving packet.
此更改是在已设置ECT代码点时设置CE代码点，即使没有拥塞。此更改不会影响沿路径其余部分对该数据包的处理。特别是，路由器在决定是否丢弃或标记到达的数据包时不检查CE码点。
However, this could result in the application unnecessarily invoking end-to-end congestion control, and reducing its arrival rate. By itself, this is no worse (for the application or for the network) than if the tampering router had actually dropped the packet.
然而，这可能导致应用程序不必要地调用端到端拥塞控制，并降低其到达率。就其本身而言，这并不比篡改路由器实际丢弃数据包更糟糕（对于应用程序或网络而言）。
This change is to turn off the ECT codepoint of a packet. This means that if the packet later encounters congestion (e.g., by arriving to a RED queue with a moderate average queue size), it will be dropped instead of being marked. By itself, this is no worse (for the application) than if the tampering router had actually dropped the packet. The saving grace in this particular case is that there is no congested router upstream expecting a reaction from setting the CE bit.
此更改用于关闭数据包的ECT代码点。这意味着，如果数据包稍后遇到拥塞（例如，通过到达具有中等平均队列大小的红色队列），它将被丢弃而不是被标记。就其本身而言，这并不比篡改路由器实际丢弃数据包更糟糕（对于应用程序而言）。在这种特殊情况下，节省的优势在于上游没有拥塞的路由器期望通过设置CE位做出反应。
This change would incorrectly label a packet as ECN-Capable. The packet may have been sent either by an ECN-Capable transport or a transport that is not ECN-Capable.
此更改将错误地将数据包标记为支持ECN。数据包可能已由支持ECN的传输或不支持ECN的传输发送。
If the packet later encounters moderate congestion at an ECN-Capable router, the router could set the CE codepoint instead of dropping the packet. If the transport protocol in fact is not ECN-Capable, then the transport will never receive this indication of congestion, and will not reduce its sending rate in response. The potential consequences of falsely indicating ECN-capability are discussed further in Section 19 below.
如果数据包后来在支持ECN的路由器上遇到中度拥塞，路由器可以设置CE码点，而不是丢弃数据包。如果传输协议实际上不支持ECN，则传输将永远不会收到拥塞指示，并且不会降低其发送速率作为响应。下文第19节将进一步讨论错误指示ECN能力的潜在后果。
If the packet never later encounters congestion at an ECN-Capable router, then the first of these two changes would have no effect, other than possibly interfering with the use of the ECN nonce by the transport protocol. The last change, however, would have the effect
如果数据包以后再也不会在支持ECN的路由器上遇到拥塞，那么这两个更改中的第一个将不会有任何影响，除了可能干扰传输协议对ECN nonce的使用。然而，最后一个变化将产生影响
of giving false reports of congestion to a monitoring device along the path. If the transport protocol is ECN-Capable, then this change could also have an effect at the transport level, by combining falsely indicating ECN-Capability with falsely reporting congestion. For an ECN-capable transport, this would cause the transport to unnecessarily react to congestion. In this particular case, the router that is incorrectly changing the ECN field could have dropped the packet. Thus for this case of an ECN-capable transport, the consequence of this change to the ECN field is no worse than dropping the packet.
向沿途的监控设备提供拥塞的虚假报告。如果传输协议支持ECN，则此更改也可能在传输级别产生影响，将错误指示ECN能力与错误报告拥塞相结合。对于支持ECN的传输，这将导致传输对拥塞做出不必要的反应。在这种特殊情况下，不正确更改ECN字段的路由器可能会丢弃数据包。因此，对于支持ECN的传输的这种情况，对ECN字段的这种更改的结果并不比丢弃分组更糟糕。
For TCP, an ECN-capable TCP receiver informs its TCP peer that it is ECN-capable at the TCP level, conveying this information in the TCP header at the time the connection is setup. This document does not consider potential dangers introduced by changes in the transport header within the network. We note that when IPsec is used, the transport header is protected both in tunnel and transport modes [ESP, AH].
对于TCP，支持ECN的TCP接收器通知其TCP对等方它在TCP级别支持ECN，并在建立连接时在TCP报头中传输此信息。本文档不考虑网络中传输头的更改引入的潜在危险。我们注意到，当使用IPsec时，传输头在隧道和传输模式下都受到保护[ESP，AH]。
Another issue concerns TCP packets with a spoofed IP source address carrying invalid ECN information in the transport header. For completeness, we examine here some possible ways that a node spoofing the IP source address of another node could use the two ECN flags in the TCP header to launch a denial-of-service attack. However, these attacks would require an ability for the attacker to use valid TCP sequence numbers, and any attacker with this ability and with the ability to spoof IP source addresses could damage the TCP connection without using the ECN flags. Therefore, ECN does not add any new vulnerabilities in this respect.
另一个问题涉及TCP数据包，其伪造的IP源地址在传输报头中携带无效的ECN信息。为了完整性，我们在这里研究了欺骗另一个节点的IP源地址的节点可以使用TCP报头中的两个ECN标志来发起拒绝服务攻击的一些可能方式。但是，这些攻击需要攻击者能够使用有效的TCP序列号，任何具有此能力以及能够欺骗IP源地址的攻击者都可能在不使用ECN标志的情况下损坏TCP连接。因此，ECN在这方面没有添加任何新的漏洞。
An acknowledgement packet with a spoofed IP source address of the TCP data receiver could include the ECE bit set. If accepted by the TCP data sender as a valid packet, this spoofed acknowledgement packet could result in the TCP data sender unnecessarily halving its congestion window. However, to be accepted by the data sender, such a spoofed acknowledgement packet would have to have the correct 32- bit sequence number as well as a valid acknowledgement number. An attacker that could successfully send such a spoofed acknowledgement packet could also send a spoofed RST packet, or do other equally damaging operations to the TCP connection.
具有TCP数据接收器的伪造IP源地址的确认数据包可能包括ECE位集。如果TCP数据发送方接受此伪造确认数据包作为有效数据包，则此伪造确认数据包可能会导致TCP数据发送方不必要地将其拥塞窗口减半。然而，要被数据发送方接受，这种伪造的确认数据包必须具有正确的32位序列号以及有效的确认号。成功发送此类伪造确认数据包的攻击者还可以发送伪造RST数据包，或对TCP连接执行其他同样具有破坏性的操作。
Packets with a spoofed IP source address of the TCP data sender could include the CWR bit set. Again, to be accepted, such a packet would have to have a valid sequence number. In addition, such a spoofed packet would have a limited performance impact. Spoofing a data packet with the CWR bit set could result in the TCP data receiver
具有TCP数据发送方伪造IP源地址的数据包可能包含CWR位集。同样，要被接受，这样的数据包必须有一个有效的序列号。此外，这种伪造的数据包对性能的影响有限。使用CWR位集欺骗数据包可能导致TCP数据接收器失效
sending fewer ECE packets than it would otherwise, if the data receiver was sending ECE packets when it received the spoofed CWR packet.
如果数据接收器在接收到伪造的CWR数据包时正在发送ECE数据包，则发送的ECE数据包将少于其他情况。
In some cases, a malicious or broken router might have access to only a subset of the packets from a flow. The question is as follows: can this router, by altering the ECN field in this subset of the packets, do more damage to that flow than if it had simply dropped that set of packets?
在某些情况下，恶意或损坏的路由器可能只能访问来自流的数据包的子集。问题如下：通过改变数据包子集中的ECN字段，该路由器是否会对该流造成比丢弃该数据包组更大的损害？
We will classify the packets in the flow as A packets and B packets, and assume that the adversary only has access to A packets. Assume that the adversary is subverting end-to-end congestion control along the path traveled by A packets only, by either falsely indicating ECN-Capability upstream of the point where congestion occurs, or erasing the congestion indication downstream. Consider also that there exists a monitoring device that sees both the A and B packets, and will "punish" both the A and B packets if the total flow is determined not to be properly responding to indications of congestion. Another key characteristic that we believe is likely to be true is that the monitoring device, before `punishing' the A&B flow, will first drop packets instead of setting the CE codepoint, and will drop arriving packets of that flow that already have the CE codepoint set. If the end nodes are in fact using end-to-end congestion control, they will see all of the indications of congestion seen by the monitoring device, and will begin to respond to these indications of congestion. Thus, the monitoring device is successful in providing the indications to the flow at an early stage.
我们将流中的数据包分为A数据包和B数据包，并假设对手只能访问A数据包。假设对手通过错误地指示拥塞发生点上游的ECN能力，或删除下游的拥塞指示，正在破坏仅沿数据包移动的路径的端到端拥塞控制。还考虑到存在一个监视设备，它既能看到A和B分组，又将“惩罚”A和B分组，如果确定总流量不正确响应拥塞指示。我们认为可能成立的另一个关键特征是，在“惩罚”A&B流之前，监控设备将首先丢弃数据包，而不是设置CE码点，并且将丢弃已经设置了CE码点的该流的到达数据包。如果终端节点实际上正在使用端到端拥塞控制，它们将看到监控设备看到的所有拥塞指示，并将开始响应这些拥塞指示。因此，监测装置成功地在早期阶段向流量提供指示。
It is true that the adversary that has access only to the A packets might, by subverting ECN-based congestion control, be able to deny the benefits of ECN to the other packets in the A&B aggregate. While this is unfortunate, this is not a reason to disable ECN.
的确，通过破坏基于ECN的拥塞控制，仅访问A数据包的对手可能会拒绝将ECN的好处提供给A&B聚合中的其他数据包。虽然这很不幸，但这并不是禁用ECN的理由。
A variant of falsely reporting congestion occurs when there are two adversaries along a path, where the first adversary falsely reports congestion, and the second adversary `erases' those reports. (Unlike packet drops, ECN congestion reports can be `reversed' later in the network by a malicious or broken router. However, the use of the ECN nonce could help the transport to detect this behavior.) While this would be transparent to the end node, it is possible that a monitoring device between the first and second adversaries would see the false indications of congestion. Keep in mind our recommendation in this document, that before `punishing' a flow for not responding appropriately to congestion, the router will first switch to dropping
当一条路径上有两个对手，第一个对手错误地报告拥塞，第二个对手“删除”这些报告时，就会出现错误报告拥塞的变体。（与丢包不同，ECN拥塞报告可在网络中稍后由恶意或损坏的路由器“反转”。但是，使用ECN nonce可帮助传输检测此行为。）虽然这对终端节点是透明的，第一和第二对手之间的监控设备可能会看到拥塞的错误指示。请记住我们在本文档中的建议，即在“惩罚”未正确响应拥塞的流之前，路由器将首先切换到丢弃
rather than marking as an indication of congestion, for that flow. When this includes dropping arriving packets from that flow that have the CE codepoint set, this ensures that these indications of congestion are being seen by the end nodes. Thus, there is no additional harm that we are able to postulate as a result of multiple conflicting adversaries.
而不是标记为该流量的拥塞指示。当这包括从具有CE码点集的流丢弃到达的分组时，这确保终端节点看到这些拥塞指示。因此，我们无法假设多个冲突对手会造成额外的伤害。
This section focuses on the potential repercussions of subverting end-to-end congestion control by either falsely indicating ECN-Capability, or by erasing the congestion indication in ECN (the CE codepoint). Subverting end-to-end congestion control by either of these two methods can have consequences both for the application and for the network. We discuss these separately below.
本节重点讨论通过错误指示ECN能力或删除ECN（CE码点）中的拥塞指示来破坏端到端拥塞控制的潜在影响。通过这两种方法中的任何一种破坏端到端拥塞控制都可能对应用程序和网络产生影响。下面我们将分别讨论这些问题。
The first method to subvert end-to-end congestion control, that of falsely indicating ECN-Capability, effectively subverts end-to-end congestion control only if the packet later encounters congestion that results in the setting of the CE codepoint. In this case, the transport protocol (which may not be ECN-capable) does not receive the indication of congestion from these downstream congested routers.
第一种颠覆端到端拥塞控制的方法，即错误指示ECN能力的方法，仅当数据包随后遇到导致CE码点设置的拥塞时，才有效颠覆端到端拥塞控制。在这种情况下，传输协议（可能不支持ECN）不会从这些下游拥塞路由器接收拥塞指示。
The second method to subvert end-to-end congestion control, `erasing' the CE codepoint in a packet, effectively subverts end-to-end congestion control only when the CE codepoint in the packet was set earlier by a congested router. In this case, the transport protocol does not receive the indication of congestion from the upstream congested routers.
第二种颠覆端到端拥塞控制的方法，即“擦除”数据包中的CE码点，仅当数据包中的CE码点被拥塞路由器提前设置时，才有效颠覆端到端拥塞控制。在这种情况下，传输协议不接收来自上游拥塞路由器的拥塞指示。
Either of these two methods of subverting end-to-end congestion control can potentially introduce more damage to the network (and possibly to the flow itself) than if the adversary had simply dropped packets from that flow. However, as we discuss later in this section and in Section 7, this potential damage is limited.
这两种破坏端到端拥塞控制的方法中的任何一种都可能对网络（可能对流本身）造成比对手从该流中丢弃数据包更大的损害。然而，正如我们在本节后面和第7节中所讨论的，这种潜在损害是有限的。
The CE codepoint of the ECN field is only used by routers as an indication of congestion during periods of *moderate* congestion. ECN-capable routers should drop rather than mark packets during heavy congestion even if the router's queue is not yet full. For example, for routers using active queue management based on RED, the router should drop rather than mark packets that arrive while the average queue sizes exceed the RED queue's maximum threshold.
ECN字段的CE代码点仅由路由器用作*中等*拥塞期间的拥塞指示。支持ECN的路由器应该在严重拥塞期间丢弃而不是标记数据包，即使路由器的队列尚未满。例如，对于使用基于RED的主动队列管理的路由器，当平均队列大小超过RED队列的最大阈值时，路由器应该丢弃而不是标记到达的数据包。
One consequence for the network of subverting end-to-end congestion control is that flows that do not receive the congestion indications from the network might increase their sending rate until they drive the network into heavier congestion. Then, the congested router could begin to drop rather than mark arriving packets. For flows that are not isolated by some form of per-flow scheduling or other per-flow mechanisms, but are instead aggregated with other flows in a single queue in an undifferentiated fashion, this packet-dropping at the congested router would apply to all flows that share that queue. Thus, the consequences would be to increase the level of congestion in the network.
颠覆端到端拥塞控制的网络的一个后果是，没有从网络接收到拥塞指示的流可能会增加其发送速率，直到它们将网络推向更严重的拥塞。然后，拥塞的路由器可能开始丢弃而不是标记到达的数据包。对于不是通过某种形式的每流调度或其他每流机制隔离的流，而是以无差别的方式与单个队列中的其他流聚合的流，拥塞路由器上的丢包将应用于共享该队列的所有流。因此，其后果将是增加网络的拥塞程度。
In some cases, the increase in the level of congestion will lead to a substantial buffer buildup at the congested queue that will be sufficient to drive the congested queue from the packet-marking to the packet-dropping regime. This transition could occur either because of buffer overflow, or because of the active queue management policy described above that drops packets when the average queue is above RED's maximum threshold. At this point, all flows, including the subverted flow, will begin to see packet drops instead of packet marks, and a malicious or broken router will no longer be able to ` erase' these indications of congestion in the network. If the end nodes are deploying appropriate end-to-end congestion control, then the subverted flow will reduce its arrival rate in response to congestion. When the level of congestion is sufficiently reduced, the congested queue can return from the packet-dropping regime to the packet-marking regime. The steady-state pattern could be one of the congested queue oscillating between these two regimes.
在某些情况下，拥塞级别的增加将导致拥塞队列中大量的缓冲区累积，这将足以将拥塞队列从分组标记驱动到分组丢弃机制。发生这种转换的原因可能是缓冲区溢出，也可能是因为上面描述的活动队列管理策略，该策略在平均队列高于RED的最大阈值时丢弃数据包。此时，所有流（包括被破坏的流）将开始看到数据包丢失而不是数据包标记，恶意或损坏的路由器将不再能够“擦除”网络中的这些拥塞指示。如果终端节点正在部署适当的端到端拥塞控制，则被颠覆的流将降低其到达率以响应拥塞。当拥塞水平充分降低时，拥塞队列可以从分组丢弃机制返回到分组标记机制。稳态模式可能是在这两种状态之间振荡的拥挤队列之一。
In other cases, the consequences of subverting end-to-end congestion control will not be severe enough to drive the congested link into sufficiently-heavy congestion that packets are dropped instead of being marked. In this case, the implications for competing flows in the network will be a slightly-increased rate of packet marking or dropping, and a corresponding decrease in the bandwidth available to those flows. This can be a stable state if the arrival rate of the subverted flow is sufficiently small, relative to the link bandwidth, that the average queue size at the congested router remains under control. In particular, the subverted flow could have a limited bandwidth demand on the link at this router, while still getting more than its "fair" share of the link. This limited demand could be due to a limited demand from the data source; a limitation from the TCP advertised window; a lower-bandwidth access pipe; or other factors. Thus the subversion of ECN-based congestion control can still lead to unfairness, which we believe is appropriate to note here.
在其他情况下，破坏端到端拥塞控制的后果将不会严重到足以将拥塞的链路推入足够严重的拥塞中，从而丢弃而不是标记数据包。在这种情况下，网络中竞争流的影响将是分组标记或丢弃的速率略微增加，并且这些流可用的带宽相应减少。如果被破坏流的到达率相对于链路带宽足够小，使得拥塞路由器处的平均队列大小保持在控制之下，则这可能是一种稳定状态。特别是，被颠覆的流可能在该路由器的链路上具有有限的带宽需求，同时仍然获得超过其链路“公平”份额的带宽。这种有限的需求可能是由于数据源的需求有限；来自TCP播发窗口的限制；低带宽接入管；或其他因素。因此，对基于ECN的拥塞控制的颠覆仍然可能导致不公平，我们认为在这里值得注意。
The threat to the network posed by the subversion of ECN-based congestion control in the network is essentially the same as the threat posed by an end-system that intentionally fails to cooperate with end-to-end congestion control. The deployment of mechanisms in routers to address this threat is an open research question, and is discussed further in Section 10.
网络中基于ECN的拥塞控制的颠覆对网络造成的威胁与故意不配合端到端拥塞控制的端系统造成的威胁基本相同。在路由器中部署机制以应对这种威胁是一个开放的研究问题，第10节将进一步讨论。
Let us take the example described in Section 18.1.1, where the CE codepoint that was set in a packet is erased: {'11' -> '10' or '11' -> '01'}. The consequence for the congested upstream router that set the CE codepoint is that this congestion indication does not reach the end nodes for that flow. The source (even one which is completely cooperative and not malicious) is thus allowed to continue to increase its sending rate (if it is a TCP flow, by increasing its congestion window). The flow potentially achieves better throughput than the other flows that also share the congested router, especially if there are no policing mechanisms or per-flow queuing mechanisms at that router. Consider the behavior of the other flows, especially if they are cooperative: that is, the flows that do not experience subverted end-to-end congestion control. They are likely to reduce their load (e.g., by reducing their window size) on the congested router, thus benefiting our subverted flow. This results in unfairness. As we discussed above, this unfairness could either be transient (because the congested queue is driven into the packet-marking regime), oscillatory (because the congested queue oscillates between the packet marking and the packet dropping regime), or more moderate but a persistent stable state (because the congested queue is never driven to the packet dropping regime).
让我们以第18.1.1节中描述的示例为例，其中数据包中设置的CE代码点被擦除：{'11'->'10'或'11'->'01'}。设置CE码点的拥塞上游路由器的结果是，该拥塞指示不会到达该流的终端节点。因此，允许源（即使是完全合作且非恶意的源）继续增加其发送速率（如果是TCP流，则通过增加其拥塞窗口）。与共享拥塞路由器的其他流相比，该流可能实现更好的吞吐量，尤其是在该路由器上没有任何策略机制或每流排队机制的情况下。考虑其他流的行为，特别是如果它们是协作的：即不经历颠覆的端到端拥塞控制的流。它们可能会减少拥塞路由器上的负载（例如，通过减少窗口大小），从而使我们的被破坏流受益。这导致了不公平。如上所述，这种不公平可能是暂时的（因为拥塞队列被驱动到分组标记区域）、振荡的（因为拥塞队列在分组标记和分组丢弃区域之间振荡），或者更温和但持续稳定的状态（因为拥塞队列永远不会被驱动到分组丢弃机制）。
The results would be similar if the subverted flow was intentionally avoiding end-to-end congestion control. One difference is that a flow that is intentionally avoiding end-to-end congestion control at the end nodes can avoid end-to-end congestion control even when the congested queue is in packet-dropping mode, by refusing to reduce its sending rate in response to packet drops in the network. Thus the problems for the network from the subversion of ECN-based congestion control are less severe than the problems caused by the intentional avoidance of end-to-end congestion control in the end nodes. It is also the case that it is considerably more difficult to control the behavior of the end nodes than it is to control the behavior of the infrastructure itself. This is not to say that the problems for the network posed by the network's subversion of ECN-based congestion control are small; just that they are dwarfed by the problems for the network posed by the subversion of either ECN-based or other currently known packet-based congestion control mechanisms by the end nodes.
如果被颠覆的流有意避免端到端拥塞控制，则结果将类似。一个区别是，有意避免端节点处的端到端拥塞控制的流可以通过拒绝降低其发送速率以响应网络中的分组丢弃而避免端到端拥塞控制，即使当拥塞队列处于分组丢弃模式时也是如此。因此，颠覆基于ECN的拥塞控制对网络造成的问题不如故意避免端节点中的端到端拥塞控制所造成的问题严重。同样，控制终端节点的行为比控制基础设施本身的行为要困难得多。这并不是说网络颠覆基于ECN的拥塞控制对网络造成的问题很小；只是，由于终端节点对基于ECN或其他当前已知的基于分组的拥塞控制机制的颠覆，网络所面临的问题使它们相形见绌。
When a source indicates that it is ECN-capable, there is an expectation that the routers in the network that are capable of participating in ECN will use the CE codepoint for indication of congestion. There is the potential benefit of using ECN in reducing the amount of packet loss (in addition to the reduced queuing delays because of active queue management policies). When the packet flows through an IPsec tunnel where the nodes that the tunneled packets traverse are untrusted in some way, the expectation is that IPsec will protect the flow from subversion that results in undesirable consequences.
当源指示其具有ECN能力时，期望网络中能够参与ECN的路由器将使用CE码点指示拥塞。使用ECN在减少数据包丢失量方面有潜在的好处（除了由于主动队列管理策略而减少的排队延迟之外）。当数据包流经IPsec隧道时，隧道数据包通过的节点在某种程度上不受信任，人们期望IPsec将保护数据流不受破坏，从而导致不良后果。
In many cases, a subverted flow will benefit from the subversion of end-to-end congestion control for that flow in the network, by receiving more bandwidth than it would have otherwise, relative to competing non-subverted flows. If the congested queue reaches the packet-dropping stage, then the subversion of end-to-end congestion control might or might not be of overall benefit to the subverted flow, depending on that flow's relative tradeoffs between throughput, loss, and delay.
在许多情况下，相对于竞争的非颠覆流，颠覆流将通过接收比其他情况下更多的带宽，从网络中该流的端到端拥塞控制颠覆中获益。如果拥塞队列到达数据包丢弃阶段，则端到端拥塞控制的颠覆可能对被颠覆的流有总体好处，也可能没有，这取决于该流在吞吐量、丢失和延迟之间的相对权衡。
One form of subverting end-to-end congestion control is to falsely indicate ECN-capability by setting the ECT codepoint. This has the consequence of downstream congested routers setting the CE codepoint in vain. However, as described in Section 9.1.2, if an ECT codepoint is changed in an IP tunnel, this can be detected at the egress point of the tunnel, as long as the inner header was not changed within the tunnel.
颠覆端到端拥塞控制的一种形式是通过设置ECT码点来错误指示ECN能力。这会导致下游拥塞路由器徒劳地设置CE码点。然而，如第9.1.2节所述，如果IP隧道中的ECT代码点发生变化，只要隧道内的内部报头未发生变化，就可以在隧道出口处检测到。
The second form of subverting end-to-end congestion control is to erase the congestion indication by erasing the CE codepoint. In this case, it is the upstream congested routers that set the CE codepoint in vain.
颠覆端到端拥塞控制的第二种形式是通过擦除CE码点来擦除拥塞指示。在这种情况下，上游拥塞的路由器设置CE码点是徒劳的。
If an ECT codepoint is erased within an IP tunnel, then this can be detected at the egress point of the tunnel, as long as the inner header was not changed within the tunnel. If the CE codepoint is set upstream of the IP tunnel, then any erasure of the outer header's CE codepoint within the tunnel will have no effect because the inner header preserves the set value of the CE codepoint. However, if the CE codepoint is set within the tunnel, and erased either within or downstream of the tunnel, this is not necessarily detected at the egress point of the tunnel.
如果在IP隧道内擦除了ECT代码点，则只要在隧道内未更改内部报头，就可以在隧道的出口点处检测到这一点。如果CE代码点设置在IP隧道的上游，则隧道内对外部报头的CE代码点的任何擦除都将无效，因为内部报头保留CE代码点的设置值。然而，如果CE码点被设置在隧道内，并且在隧道内或隧道下游被擦除，则这不一定在隧道的出口点处被检测到。
With this subversion of end-to-end congestion control, an end-system transport does not respond to the congestion indication. Along with the increased unfairness for the non-subverted flows described in the
通过对端到端拥塞控制的这种颠覆，端系统传输不会响应拥塞指示。随着对非颠覆流的不公平性的增加
previous section, the congested router's queue could continue to build, resulting in packet loss at the congested router - which is a means for indicating congestion to the transport in any case. In the interim, the flow might experience higher queuing delays, possibly along with an increased bandwidth relative to other non-subverted flows. But transports do not inherently make assumptions of consistently experiencing carefully managed queuing in the path. We believe that these forms of subverting end-to-end congestion control are no worse for the subverted flow than if the adversary had simply dropped the packets of that flow itself.
在前面的部分中，拥塞路由器的队列可能会继续构建，导致拥塞路由器上的数据包丢失——这是在任何情况下指示传输拥塞的一种方法。在此期间，该流可能会经历更高的排队延迟，可能伴随着相对于其他非颠覆流的带宽增加。但是，交通工具并不固有地假设在路径中始终经历精心管理的排队。我们相信，这些颠覆性的端到端拥塞控制形式对于被颠覆流来说并不比对手仅仅丢弃该流本身的数据包更糟糕。
We have shown that, in many cases, a malicious or broken router that is able to change the bits in the ECN field can do no more damage than if it had simply dropped the packet in question. However, this is not true in all cases, in particular in the cases where the broken router subverted end-to-end congestion control by either falsely indicating ECN-Capability or by erasing the ECN congestion indication (in the CE codepoint). While there are many ways that a router can harm a flow by dropping packets, a router cannot subvert end-to-end congestion control by dropping packets. As an example, a router cannot subvert TCP congestion control by dropping data packets, acknowledgement packets, or control packets.
我们已经证明，在许多情况下，能够更改ECN字段中位的恶意或损坏的路由器所造成的损害不会比仅仅丢弃相关数据包所造成的损害更大。然而，并非所有情况下都是如此，特别是在断开的路由器通过错误指示ECN能力或通过擦除ECN拥塞指示（在CE代码点中）破坏端到端拥塞控制的情况下。虽然路由器通过丢弃数据包可以通过多种方式破坏流，但路由器不能通过丢弃数据包破坏端到端的拥塞控制。例如，路由器不能通过丢弃数据包、确认包或控制包来破坏TCP拥塞控制。
Even though packet-dropping cannot be used to subvert end-to-end congestion control, there *are* non-ECN-based methods for subverting end-to-end congestion control that a broken or malicious router could use. For example, a broken router could duplicate data packets, thus effectively negating the effects of end-to-end congestion control along some portion of the path. (For a router that duplicated packets within an IPsec tunnel, the security administrator can cause the duplicate packets to be discarded by configuring anti-replay protection for the tunnel.) This duplication of packets within the network would have similar implications for the network and for the subverted flow as those described in Sections 18.1.1 and 18.1.4 above.
即使不能使用数据包丢弃来破坏端到端的拥塞控制，也有一些非基于ECN的方法来破坏端到端的拥塞控制，而坏掉的或恶意的路由器可能会使用这些方法。例如，一个坏掉的路由器可能会复制数据包，从而有效地抵消沿路径某个部分的端到端拥塞控制的影响。（对于在IPsec隧道内复制数据包的路由器，安全管理员可以通过为隧道配置防重放保护来丢弃重复数据包。）网络内数据包的这种复制将对网络和被颠覆流产生类似的影响，如上文第18.1.1和18.1.4节所述。
20. The Motivation for the ECT Codepoints.
20. ECT代码点的动机。
20.1. The Motivation for an ECT Codepoint.
20.1. ECT代码点的动机。
The need for an ECT codepoint is motivated by the fact that ECN will be deployed incrementally in an Internet where some transport protocols and routers understand ECN and some do not. With an ECT codepoint, the router can drop packets from flows that are not ECN-capable, but can *instead* set the CE codepoint in packets that *are*
对ECT码点的需求是由这样一个事实驱动的，即ECN将在一些传输协议和路由器理解ECN而一些不理解ECN的Internet中以增量方式部署。使用ECT码点，路由器可以从不支持ECN的流中丢弃数据包，但可以*改为*在*支持ECN的数据包中设置CE码点*
ECN-capable. Because an ECT codepoint allows an end node to have the CE codepoint set in a packet *instead* of having the packet dropped, an end node might have some incentive to deploy ECN.
具有ECN功能。由于ECT码点允许终端节点在数据包*中设置CE码点，而不是丢弃数据包，因此终端节点可能有一些动机来部署ECN。
If there was no ECT codepoint, then the router would have to set the CE codepoint for packets from both ECN-capable and non-ECN-capable flows. In this case, there would be no incentive for end-nodes to deploy ECN, and no viable path of incremental deployment from a non-ECN world to an ECN-capable world. Consider the first stages of such an incremental deployment, where a subset of the flows are ECN-capable. At the onset of congestion, when the packet dropping/marking rate would be low, routers would only set CE codepoints, rather than dropping packets. However, only those flows that are ECN-capable would understand and respond to CE packets. The result is that the ECN-capable flows would back off, and the non-ECN-capable flows would be unaware of the ECN signals and would continue to open their congestion windows.
如果没有ECT码点，那么路由器必须为来自支持ECN和不支持ECN的流的数据包设置CE码点。在这种情况下，终端节点没有动力部署ECN，也没有从非ECN世界到支持ECN世界的增量部署的可行路径。考虑这样的增量部署的第一阶段，其中流的子集是ECN能力的。在拥塞开始时，当数据包丢弃/标记率较低时，路由器将只设置CE码点，而不是丢弃数据包。然而，只有那些支持ECN的流才能理解和响应CE数据包。结果是，支持ECN的流将后退，而不支持ECN的流将不知道ECN信号，并将继续打开其拥塞窗口。
In this case, there are two possible outcomes: (1) the ECN-capable flows back off, the non-ECN-capable flows get all of the bandwidth, and congestion remains mild, or (2) the ECN-capable flows back off, the non-ECN-capable flows don't, and congestion increases until the router transitions from setting the CE codepoint to dropping packets. While this second outcome evens out the fairness, the ECN-capable flows would still receive little benefit from being ECN-capable, because the increased congestion would drive the router to packet-dropping behavior.
在这种情况下，有两种可能的结果：（1）支持ECN的流回退，不支持ECN的流获得所有带宽，拥塞保持轻微，或者（2）支持ECN的流回退，不支持ECN的流不回退，拥塞增加，直到路由器从设置CE码点过渡到丢弃数据包。虽然这第二个结果平衡了公平性，但支持ECN的流仍然不会从支持ECN中获得什么好处，因为增加的拥塞会促使路由器出现丢包行为。
A flow that advertised itself as ECN-Capable but does not respond to CE codepoints is functionally equivalent to a flow that turns off congestion control, as discussed earlier in this document.
如本文档前面所讨论的，宣称自己具有ECN功能但不响应CE代码点的流在功能上等同于关闭拥塞控制的流。
Thus, in a world when a subset of the flows are ECN-capable, but where ECN-capable flows have no mechanism for indicating that fact to the routers, there would be less effective and less fair congestion control in the Internet, resulting in a strong incentive for end nodes not to deploy ECN.
因此，在一个流的子集具有ECN能力，但具有ECN能力的流没有向路由器指示这一事实的机制的世界中，互联网中的拥塞控制将不那么有效和公平，导致终端节点不部署ECN的强烈激励。
20.2. The Motivation for two ECT Codepoints.
20.2. 两个ECT代码点的动机。
The primary motivation for the two ECT codepoints is to provide a one-bit ECN nonce. The ECN nonce allows the development of mechanisms for the sender to probabilistically verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set.
两个ECT码点的主要动机是提供一位ECN nonce。ECN nonce允许为发送方开发机制，以概率地验证网络元素没有擦除CE码点，并且数据接收方正确地向发送方报告接收到具有CE码点集的分组。
Another possibility for senders to detect misbehaving network elements or receivers would be for the data sender to occasionally send a data packet with the CE codepoint set, to see if the receiver reports receiving the CE codepoint. Of course, if these packets encountered congestion in the network, the router might make no change in the packets, because the CE codepoint would already be set. Thus, for packets sent with the CE codepoint set, the TCP end-nodes could not determine if some router intended to set the CE codepoint in these packets. For this reason, sending packets with the CE codepoint would have to be done sparingly, and would be a less effective check against misbehaving network elements and receivers than would be the ECN nonce.
发送方检测行为不当的网络元件或接收方的另一种可能性是数据发送方偶尔发送具有CE码点集的数据分组，以查看接收方是否报告接收到CE码点。当然，如果这些数据包在网络中遇到拥塞，路由器可能不会对数据包进行更改，因为CE码点已经设置好了。因此，对于使用CE码点集发送的数据包，TCP端节点无法确定某些路由器是否打算在这些数据包中设置CE码点。出于这个原因，使用CE码点发送数据包将不得不谨慎地进行，并且与ECN nonce相比，对于行为不端的网络元件和接收器的检查效率较低。
The assignment of the fourth ECN codepoint to ECT(1) precludes the use of this codepoint for some other purposes. For clarity, we briefly list other possible purposes here.
将第四个ECN码点分配给ECT（1）会妨碍将该码点用于其他目的。为清楚起见，我们在此简要列出其他可能的用途。
One possibility might have been for the data sender to use the fourth ECN codepoint to indicate an alternate semantics for ECN. However, this seems to us more appropriate to be signaled using a differentiated services codepoint in the DS field.
一种可能是数据发送方使用第四个ECN代码点来指示ECN的另一种语义。然而，在我们看来，这似乎更适合在DS字段中使用差异化服务代码点来表示。
A second possible use for the fourth ECN codepoint would have been to give the router two separate codepoints for the indication of congestion, CE(0) and CE(1), for mild and severe congestion respectively. While this could be useful in some cases, this certainly does not seem a compelling requirement at this point. If there was judged to be a compelling need for this, the complications of incremental deployment would most likely necessitate more that just one codepoint for this function.
第四个ECN代码点的第二个可能用途是为路由器提供两个单独的代码点，分别表示轻度和重度拥塞，即CE（0）和CE（1）。虽然这在某些情况下可能有用，但在这一点上，这显然不是一个迫切的要求。如果认为有迫切的需求，那么增量部署的复杂性很可能需要更多的代码点来实现此功能。
A third use that has been informally proposed for the ECN codepoint is for use in some forms of multicast congestion control, based on randomized procedures for duplicating marked packets at routers. Some proposed multicast packet duplication procedures are based on a new ECN codepoint that (1) conveys the fact that congestion occurred upstream of the duplication point that marked the packet with this codepoint and (2) can detect congestion downstream of that duplication point. ECT(1) can serve this purpose because it is both distinct from ECT(0) and is replaced by CE when ECN marking occurs in response to congestion or incipient congestion. Explanation of how this enhanced version of ECN would be used by multicast congestion control is beyond the scope of this document, as are ECN-aware multicast packet duplication procedures and the processing of the ECN field at multicast receivers in all cases (i.e., irrespective of the multicast packet duplication procedure(s) used).
ECN码点的第三个非正式用途是用于某些形式的多播拥塞控制，基于在路由器上复制标记包的随机过程。一些建议的多播分组复制过程基于一个新的ECN码点，该码点（1）表示拥塞发生在用该码点标记分组的复制点的上游，并且（2）可以检测该复制点下游的拥塞。ECT（1）可用于此目的，因为它既不同于ECT（0），又在ECN标记响应拥塞或初期拥塞时被CE替代。多播拥塞控制将如何使用此增强版ECN的解释超出了本文档的范围，在所有情况下（即，无论使用何种多播数据包复制程序），ECN感知多播数据包复制程序以及多播接收器对ECN字段的处理也超出了本文档的范围。
The specification of IP tunnel modifications for ECN in this document assumes that the only change made to the outer IP header's ECN field between tunnel endpoints is to set the CE codepoint to indicate congestion. This is not consistent with some of the proposed uses of ECT(1) by the multicast duplication procedures in the previous paragraph, and such procedures SHOULD NOT be deployed unless this inconsistency between multicast duplication procedures and IP tunnels with full ECN functionality is resolved. Limited ECN functionality may be used instead, although in practice many tunnel protocols (including IPsec) will not work correctly if multicast traffic duplication occurs within the tunnel
本文档中针对ECN的IP隧道修改规范假设对隧道端点之间的外部IP报头的ECN字段所做的唯一更改是设置CE代码点以指示拥塞。这与上一段中的多播复制程序对ECT（1）的某些建议使用不一致，除非解决了多播复制程序和具有完整ECN功能的IP隧道之间的不一致性，否则不应部署此类程序。尽管在实践中，许多隧道协议（包括IPsec）在隧道内发生多播通信量复制时无法正常工作，但可以使用有限的ECN功能
Given the need for an ECT indication in the IP header, there still remains the question of whether the ECT (ECN-Capable Transport) and CE (Congestion Experienced) codepoints should have been overloaded on a single bit. This overloaded-one-bit alternative, explored in [Floyd94], would have involved a single bit with two values. One value, "ECT and not CE", would represent an ECN-Capable Transport, and the other value, "CE or not ECT", would represent either Congestion Experienced or a non-ECN-Capable transport.
鉴于IP报头中需要ECT指示，仍然存在ECT（支持ECN的传输）和CE（经历拥塞）码点是否应在单个位上过载的问题。[Floyd94]中探讨的这种重载的一位替代方案将涉及一个具有两个值的位。一个值“ECT和非CE”表示支持ECN的传输，另一个值“CE或非ECT”表示经历的拥塞或不支持ECN的传输。
One difference between the one-bit and two-bit implementations concerns packets that traverse multiple congested routers. Consider a CE packet that arrives at a second congested router, and is selected by the active queue management at that router for either marking or dropping. In the one-bit implementation, the second congested router has no choice but to drop the CE packet, because it cannot distinguish between a CE packet and a non-ECT packet. In the two-bit implementation, the second congested router has the choice of either dropping the CE packet, or of leaving it alone with the CE codepoint set.
一位和两位实现之间的一个区别涉及穿越多个拥塞路由器的数据包。考虑到达第二拥塞路由器的CE分组，并通过该路由器上的主动队列管理来选择标记或丢弃。在一位实现中，第二拥塞路由器别无选择，只能丢弃CE分组，因为它无法区分CE分组和非ECT分组。在两位实现中，第二个拥塞路由器可以选择丢弃CE数据包，或者将其单独留给CE码点集。
Another difference between the one-bit and two-bit implementations comes from the fact that with the one-bit implementation, receivers in a single flow cannot distinguish between CE and non-ECT packets. Thus, in the one-bit implementation an ECN-capable data sender would have to unambiguously indicate to the receiver or receivers whether each packet had been sent as ECN-Capable or as non-ECN-Capable. One possibility would be for the sender to indicate in the transport header whether the packet was sent as ECN-Capable. A second possibility that would involve a functional limitation for the one-bit implementation would be for the sender to unambiguously indicate that it was going to send *all* of its packets as ECN-Capable or as non-ECN-Capable. For a multicast transport protocol, this unambiguous indication would have to be apparent to receivers joining an on-going multicast session.
一位和两位实现之间的另一个区别在于，使用一位实现时，单个流中的接收器无法区分CE和非ECT数据包。因此，在一位实现中，支持ECN的数据发送方必须明确地向接收机指示每个分组是作为支持ECN的还是不支持ECN的发送。一种可能性是发送方在传输报头中指示数据包是否以支持ECN的方式发送。涉及一位实现的功能限制的第二种可能性是发送方明确表示它将发送*其所有*数据包作为支持ECN或不支持ECN。对于多播传输协议，对于加入正在进行的多播会话的接收器来说，这种明确的指示必须是显而易见的。
Another concern that was described earlier (and recommended in this document) is that transports (particularly TCP) should not mark pure ACK packets or retransmitted packets as being ECN-Capable. A pure ACK packet from a non-ECN-capable transport could be dropped, without necessarily having an impact on the transport from a congestion control perspective (because subsequent ACKs are cumulative). An ECN-capable transport reacting to the CE codepoint in a pure ACK packet by reducing the window would be at a disadvantage in comparison to a non-ECN-capable transport. For this reason (and for reasons described earlier in relation to retransmitted packets), it is desirable to have the ECT codepoint set on a per-packet basis.
前面描述的另一个问题（并在本文档中推荐）是，传输（特别是TCP）不应将纯ACK数据包或重新传输的数据包标记为具有ECN能力。可以丢弃来自不支持ECN的传输的纯ACK数据包，而不必从拥塞控制的角度对传输产生影响（因为后续ACK是累积的）。与不支持ECN的传输相比，通过减少窗口来对纯ACK分组中的CE码点作出反应的支持ECN的传输将处于劣势。出于这个原因（以及出于前面描述的与重传分组相关的原因），期望在每个分组的基础上设置ECT码点。
Another advantage of the two-bit approach is that it is somewhat more robust. The most critical issue, discussed in Section 8, is that the default indication should be that of a non-ECN-Capable transport. In a two-bit implementation, this requirement for the default value simply means that the not-ECT codepoint should be the default. In the one-bit implementation, this means that the single overloaded bit should by default be in the "CE or not ECT" position. This is less clear and straightforward, and possibly more open to incorrect implementations either in the end nodes or in the routers.
两位方法的另一个优点是它在某种程度上更加健壮。第8节讨论的最关键的问题是，默认指示应该是不支持ECN的传输。在两位实现中，对默认值的要求仅仅意味着not ECT代码点应该是默认值。在一位实现中，这意味着单个重载位在默认情况下应处于“CE或not ECT”位置。这是不太清楚和直接的，并且可能更容易在终端节点或路由器中进行错误的实现。
In summary, while the one-bit implementation could be a possible implementation, it has the following significant limitations relative to the two-bit implementation. First, the one-bit implementation has more limited functionality for the treatment of CE packets at a second congested router. Second, the one-bit implementation requires either that extra information be carried in the transport header of packets from ECN-Capable flows (to convey the functionality of the second bit elsewhere, namely in the transport header), or that senders in ECN-Capable flows accept the limitation that receivers must be able to determine a priori which packets are ECN-Capable and which are not ECN-Capable. Third, the one-bit implementation is possibly more open to errors from faulty implementations that choose the wrong default value for the ECN bit. We believe that the use of the extra bit in the IP header for the ECT-bit is extremely valuable to overcome these limitations.
总之，虽然一位实现可能是一种可能的实现，但相对于两位实现，它有以下重大限制。首先，一位实现对于在第二拥塞路由器处处理CE分组具有更有限的功能。第二，一位实现要求在来自支持ECN的流的分组的传输报头中携带额外信息（以将第二位的功能传送到别处，即传送报头中），或者，支持ECN的流中的发送方接受这样的限制，即接收方必须能够事先确定哪些包支持ECN，哪些包不支持ECN。第三，一位实现可能更容易出错，因为错误的实现为ECN位选择了错误的默认值。我们认为，在IP报头中为ECT位使用额外的位对于克服这些限制非常有价值。
RFC 791 [RFC791] defined the ToS (Type of Service) octet in the IP header. In RFC 791, bits 6 and 7 of the ToS octet are listed as "Reserved for Future Use", and are shown set to zero. The first two fields of the ToS octet were defined as the Precedence and Type of Service (TOS) fields.
RFC 791[RFC791]在IP头中定义了ToS（服务类型）八位字节。在RFC 791中，ToS八位字节的第6位和第7位列为“保留供将来使用”，并显示为设置为零。ToS八位字节的前两个字段被定义为优先级和服务类型（ToS）字段。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 included bits 6 and 7 in the TOS field, though it did not discuss any specific use for those two bits:
RFC 1122在TOS字段中包括第6位和第7位，但没有讨论这两位的任何具体用途：
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:
在RFC 1349[RFC1349]中，IPv4 TOS八位字节被重新定义如下：
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit 6 in the TOS field was defined in RFC 1349 for "Minimize Monetary Cost". In addition to the Precedence and Type of Service (TOS) fields, the last field, MBZ (for "must be zero") was defined as currently unused. RFC 1349 stated that "The originator of a datagram sets [the MBZ] field to zero (unless participating in an Internet protocol experiment which makes use of that bit)."
TOS字段中的第6位在RFC 1349中定义为“最小化货币成本”。除了优先级和服务类型（TOS）字段外，最后一个字段MBZ（表示“必须为零”）被定义为当前未使用的字段。RFC 1349指出，“数据报的发起者将[MBZ]字段设置为零（除非参与使用该位的互联网协议实验）。”
RFC 1455 [RFC 1455] defined an experimental standard that used all four bits in the TOS field to request a guaranteed level of link security.
RFC 1455[RFC 1455]定义了一个实验标准，该标准使用TOS字段中的所有四位来请求链路安全的保证级别。
RFC 1349 and RFC 1455 have been obsoleted by "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] in which bits 6 and 7 of the DS field are listed as Currently Unused (CU). RFC 2780 [RFC2780] specified ECN as an experimental use of the two-bit CU field. RFC 2780 updated the definition of the DS Field to only encompass the first six bits of this octet rather than all eight bits; these first six bits are defined as the Differentiated Services CodePoint (DSCP):
RFC 1349和RFC 1455已被“IPv4和IPv6标头中差异化服务字段（DS字段）的定义”[RFC2474]淘汰，其中DS字段的第6位和第7位被列为当前未使用（CU）。RFC 2780[RFC2780]将ECN指定为两位CU场的实验用途。RFC 2780更新了DS字段的定义，使其仅包含该八位字节的前六位，而不是全部八位；前六位定义为区分服务码点（DSCP）：
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | CU | RFCs 2474,
+-----+-----+-----+-----+-----+-----+-----+-----+ 2780
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | CU | RFCs 2474,
+-----+-----+-----+-----+-----+-----+-----+-----+ 2780
Because of this unstable history, the definition of the ECN field in this document cannot be guaranteed to be backwards compatible with all past uses of these two bits.
由于这种不稳定的历史，本文档中ECN字段的定义不能保证与这两个位的所有过去使用向后兼容。
Prior to RFC 2474, routers were not permitted to modify bits in either the DSCP or ECN field of packets forwarded through them, and hence routers that comply only with RFCs prior to 2474 should have no effect on ECN. For end nodes, bit 7 (the second ECN bit) must be transmitted as zero for any implementation compliant only with RFCs prior to 2474. Such nodes may transmit bit 6 (the first ECN bit) as one for the "Minimize Monetary Cost" provision of RFC 1349 or the experiment authorized by RFC 1455; neither this aspect of RFC 1349 nor the experiment in RFC 1455 were widely implemented or used. The damage that could be done by a broken, non-conformant router would include "erasing" the CE codepoint for an ECN-capable packet that arrived at the router with the CE codepoint set, or setting the CE codepoint even in the absence of congestion. This has been discussed in the section on "Non-compliance in the Network".
在RFC 2474之前，不允许路由器修改通过其转发的数据包的DSCP或ECN字段中的位，因此仅符合RFC 2474之前的路由器对ECN没有影响。对于终端节点，对于2474之前仅符合RFCs的任何实现，位7（第二个ECN位）必须传输为零。这些节点可以发送比特6（第一ECN比特），作为RFC 1349的“最小化货币成本”规定或RFC 1455授权的实验的比特；RFC 1349的这一方面和RFC 1455中的实验均未得到广泛实施或使用。损坏的、不一致的路由器可能造成的损害包括“擦除”使用CE码点集到达路由器的支持ECN的数据包的CE码点，或者即使在没有拥塞的情况下也设置CE码点。“网络中的违规行为”一节对此进行了讨论。
The damage that could be done in an ECN-capable environment by a non-ECN-capable end-node transmitting packets with the ECT codepoint set has been discussed in the section on "Non-compliance by the End Nodes".
在支持ECN的环境中，不支持ECN的终端节点使用ECT码点集传输数据包可能造成的损害已在“终端节点不符合性”一节中讨论。
This section contains the namespaces that have either been created in this specification, or the values assigned in existing namespaces managed by IANA.
本节包含在本规范中创建的名称空间，或在IANA管理的现有名称空间中分配的值。
The codepoints for the ECN Field of the IP header are specified by the Standards Action of this RFC, as is required by RFC 2780.
根据RFC 2780的要求，IP报头的ECN字段的代码点由该RFC的标准操作指定。
When this document is published as an RFC, IANA should create a new registry, "IPv4 TOS Byte and IPv6 Traffic Class Octet", with the namespace as follows:
当本文档作为RFC发布时，IANA应创建一个新的注册表“IPv4 TOS字节和IPv6通信类八位字节”，其命名空间如下：
IPv4 TOS Byte and IPv6 Traffic Class Octet
IPv4 TOS字节和IPv6通信类八位字节
Description: The registrations are identical for IPv4 and IPv6.
说明：IPv4和IPv6的注册相同。
Bits 0-5: see Differentiated Services Field Codepoints Registry
(http://www.iana.org/assignments/dscp-registry)
Bits 0-5: see Differentiated Services Field Codepoints Registry
(http://www.iana.org/assignments/dscp-registry)
Bits 6-7, ECN Field:
第6-7位，ECN字段：
Binary Keyword References
------ ------- ----------
00 Not-ECT (Not ECN-Capable Transport) [RFC 3168]
01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168]
10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168]
11 CE (Congestion Experienced) [RFC 3168]
Binary Keyword References
------ ------- ----------
00 Not-ECT (Not ECN-Capable Transport) [RFC 3168]
01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168]
10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168]
11 CE (Congestion Experienced) [RFC 3168]
The codepoints for the CWR and ECE flags in the TCP header are specified by the Standards Action of this RFC, as is required by RFC 2780.
根据RFC 2780的要求，TCP报头中CWR和ECE标志的代码点由本RFC的标准操作指定。
When this document is published as an RFC, IANA should create a new registry, "TCP Header Flags", with the namespace as follows:
当本文档作为RFC发布时，IANA应创建一个新的注册表“TCP头标志”，其命名空间如下：
TCP Header Flags
TCP头标志
The Transmission Control Protocol (TCP) included a 6-bit Reserved field defined in RFC 793, reserved for future use, in bytes 13 and 14 of the TCP header, as illustrated below. The other six Control bits are defined separately by RFC 793.
传输控制协议（TCP）包括RFC 793中定义的6位保留字段，保留供将来使用，位于TCP报头的字节13和14中，如下所示。其他六个控制位由RFC 793单独定义。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RFC 3168 defines two of the six bits from the Reserved field to be used for ECN, as follows:
RFC 3168定义了用于ECN的保留字段中六位中的两位，如下所示：
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TCP Header Flags
TCP头标志
Bit Name Reference
--- ---- ---------
8 CWR (Congestion Window Reduced) [RFC 3168]
9 ECE (ECN-Echo) [RFC 3168]
Bit Name Reference
--- ---- ---------
8 CWR (Congestion Window Reduced) [RFC 3168]
9 ECE (ECN-Echo) [RFC 3168]
IANA allocated the IPSEC Security Association Attribute value 10 for the ECN Tunnel use described in Section 9.2.1.2 above at the request of David Black in November 1999. The IANA has changed the Reference for this allocation from David Black's request to this RFC.
1999年11月，应David Black的请求，IANA为上文第9.2.1.2节所述的ECN隧道使用分配了IPSEC安全关联属性值10。IANA已将此分配的参考从David Black的请求更改为此RFC。
K. K. Ramakrishnan TeraOptic Networks, Inc.
K.K.罗摩克里希南Terapologic Networks公司。
Phone: +1 (408) 666-8650
EMail: kk@teraoptic.com
Phone: +1 (408) 666-8650
EMail: kk@teraoptic.com
Sally Floyd ACIRI
萨莉·弗洛伊德·阿西里
Phone: +1 (510) 666-2989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
Phone: +1 (510) 666-2989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748
David L.Black EMC公司马萨诸塞州霍普金顿南大街42号01748
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.com
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.translate error, please retry
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。