Internet Engineering Task Force (IETF) D. Black
Request for Comments: 8311 Dell EMC
Updates: 3168, 4341, 4342, 5622, 6679 January 2018
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Black
Request for Comments: 8311 Dell EMC
Updates: 3168, 4341, 4342, 5622, 6679 January 2018
Category: Standards Track
ISSN: 2070-1721
Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation
放宽对显式拥塞通知（ECN）实验的限制
Abstract
摘要
This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.
此备忘录更新了RFC 3168，它指定显式拥塞通知（ECN）作为向端点指示网络拥塞的数据包丢弃的替代方案。它放宽了RFC 3168中的限制，这些限制阻碍了试验，使其不仅仅是消除损失，还能带来好处。本备忘录总结了预期的试验领域，并更新了RFC 3168，以便在这些领域进行试验。IETF文档流中的实验性RFC需要利用这些使能更新中的任何一个。此外，本备忘录还对RFC 6679中RTP和RFC 4341、4342和5622中数据报拥塞控制协议（DCCP）的ECN规范进行了相关更新。本备忘录还记录了RFC 3540中ECN nonce实验的结论，并提供了将RFC 3540从实验性重新分类为历史性的基本原理；这种重新分类使ECT（1）码点的新实验使用成为可能。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8311.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8311.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 5
2.1. Effective Congestion Control is Required . . . . . . . . 6
2.2. Network Considerations for ECN Experimentation . . . . . 6
2.3. Operational and Management Considerations . . . . . . . . 7
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 8
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 9
4.1. Congestion Response Differences . . . . . . . . . . . . . 9
4.2. Congestion Marking Differences . . . . . . . . . . . . . 10
4.3. TCP Control Packets and Retransmissions . . . . . . . . . 13
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 14
6. ECN for DCCP Updates to RFCs 4341, 4342, and 5622 . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 5
2.1. Effective Congestion Control is Required . . . . . . . . 6
2.2. Network Considerations for ECN Experimentation . . . . . 6
2.3. Operational and Management Considerations . . . . . . . . 7
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 8
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 9
4.1. Congestion Response Differences . . . . . . . . . . . . . 9
4.2. Congestion Marking Differences . . . . . . . . . . . . . 10
4.3. TCP Control Packets and Retransmissions . . . . . . . . . 13
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 14
6. ECN for DCCP Updates to RFCs 4341, 4342, and 5622 . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
This memo updates RFC 3168 [RFC3168], which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the proposed areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream [RFC4844] is required to take advantage of any of these enabling updates. Putting all of these updates into a single document enables experimentation to proceed without requiring a standards process exception for each Experimental RFC that needs changes to RFC 3168, a Proposed Standard RFC.
此备忘录更新了RFC 3168[RFC3168]，其中指定了显式拥塞通知（ECN）作为向端点指示网络拥塞的数据包丢弃的替代方案。它放宽了RFC 3168中的限制，这些限制阻碍了试验，使其不仅仅是消除损失，还能带来好处。本备忘录总结了拟议的试验领域，并更新了RFC 3168，以实现这些领域的试验。IETF文档流[RFC4844]中的实验性RFC需要利用这些启用更新中的任何一个。将所有这些更新放在一个文档中，可以使实验继续进行，而不需要对每个实验性RFC（需要更改RFC 3168，一种建议的标准RFC）进行标准过程异常。
There is no need for this memo to update RFC 3168 to simplify standardization of protocols and mechanisms that are documented in Standards Track RFCs, as any Standards Track RFC can update RFC 3168 directly without either relying on updates in this memo or using a standards process exception.
本备忘录无需更新RFC 3168以简化标准跟踪RFC中记录的协议和机制的标准化，因为任何标准跟踪RFC都可以直接更新RFC 3168，而无需依赖本备忘录中的更新或使用标准流程例外。
In addition, this memo makes related updates to the ECN specification for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342], and [RFC5622]) for the same reason. Each experiment is still required to be documented in one or more separate RFCs, but use of Experimental RFCs for this purpose does not require a process exception to modify any of these Proposed Standard RFCs when the modification falls within the bounds established by this memo (RFC 5622 is an Experimental RFC; it is modified by this memo for consistency with modifications to the other two DCCP RFCs).
此外，出于同样的原因，本备忘录对RTP[RFC6679]和三个DCCP配置文件（[RFC4341]、[RFC4342]和[RFC5622]）的ECN规范进行了相关更新。每项实验仍需记录在一个或多个单独的RFC中，但当修改在本备忘录规定的范围内时，出于此目的使用实验RFC不需要流程例外来修改任何建议的标准RFC（RFC 5622是一个实验性RFC；本备忘录对其进行了修改，以与其他两个DCCP RFC的修改保持一致）。
Some of the anticipated experimentation includes use of the ECT(1) codepoint that was dedicated to the ECN nonce experiment in RFC 3540 [RFC3540]. This memo records the conclusion of the ECN nonce experiment and provides the explanation for reclassification of RFC 3540 from Experimental to Historic in order to enable new experimental use of the ECT(1) codepoint.
一些预期的实验包括使用ECT（1）代码点，该代码点专用于RFC 3540[RFC3540]中的ECN nonce实验。本备忘录记录了ECN nonce实验的结论，并解释了RFC 3540从实验性重新分类到历史性的原因，以便能够在新的实验中使用ECT（1）代码点。
ECT: ECN-Capable Transport. One of the two codepoints, ECT(0) or ECT(1), in the ECN field [RFC3168] of the IP header (v4 or v6). An ECN-capable sender sets one of these to indicate that both transport endpoints support ECN.
ECT：支持ECN的传输。IP报头（v4或v6）的ECN字段[RFC3168]中的两个代码点之一，ECT（0）或ECT（1）。支持ECN的发送方设置其中一个，以指示两个传输端点都支持ECN。
Not-ECT: The ECN codepoint set by senders that indicates that the transport is not ECN capable.
Not ECT：发送方设置的ECN代码点，表示传输不支持ECN。
CE: Congestion Experienced. The ECN codepoint that an intermediate node sets to indicate congestion. A node sets an increasing proportion of ECT packets to Congestion Experienced (CE) as the level of congestion increases.
行政长官：交通挤塞。中间节点为指示拥塞而设置的ECN码点。随着拥塞级别的增加，节点将ECT数据包的比例设置为拥塞体验（CE）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Three areas of ECN experimentation are covered by this memo; the cited documents should be consulted for the detailed goals and rationale of each proposed experiment:
本备忘录涵盖了ECN试验的三个领域；应参考引用的文件，了解每个拟议实验的详细目标和基本原理：
Congestion Response Differences: An ECN congestion indication communicates a higher likelihood than a dropped packet that a short queue exists at the network bottleneck node [TCP-ABE]. This difference suggests that for congestion indicated by ECN, a different sender congestion response (e.g., sender backs off by a smaller amount) may be appropriate by comparison to the sender response to congestion indicated by loss. Two examples of proposed sender congestion response changes are described in [TCP-ABE] and [ECN-L4S] -- the proposal in the latter document couples the sender congestion response change to Congestion Marking Differences functionality (see next paragraph). These changes are at variance with the requirement in RFC 3168 that a sender's congestion control response to ECN congestion indications be the same as to drops. IETF approval, e.g., via an Experimental RFC in the IETF document stream, is required for any sender congestion response used in this area of experimentation. See Section 4.1 for further discussion.
拥塞响应差异：与丢弃的数据包相比，ECN拥塞指示传达的网络瓶颈节点[TCP-ABE]存在短队列的可能性更高。这种差异表明，对于ECN指示的拥塞，与丢失指示的发送方对拥塞的响应相比，不同的发送方拥塞响应（例如，发送方退避较小的量）可能是合适的。[TCP-ABE]和[ECN-L4S]中描述了两个提议的发送方拥塞响应更改示例——后一文档中的提议将发送方拥塞响应更改与拥塞标记差异功能相结合（见下一段）。这些变更不符合RFC 3168中的要求，即发送方对ECN拥塞指示的拥塞控制响应与对drops的响应相同。IETF批准（例如，通过IETF文档流中的实验RFC）是该实验领域中使用的任何发送方拥塞响应所必需的。进一步讨论见第4.1节。
Congestion Marking Differences: Congestion marking at network nodes can be configured to maintain very shallow queues in conjunction with a different sender response to congestion indications (CE marks), e.g., as proposed in [ECN-L4S]. The traffic involved needs to be identified by the senders to the network nodes in order to avoid damage to other network traffic whose senders do not expect the more frequent congestion marking used to maintain very shallow queues. Use of different ECN codepoints, specifically ECT(0) and ECT(1), is a promising means of traffic identification for this purpose, but that technique is at variance with the requirement in RFC 3168 that traffic marked as ECT(0) not receive different treatment in the network by comparison to traffic marked as ECT(1). IETF approval, e.g., via an Experimental RFC in the IETF document stream, is required for any differences in congestion marking or sender congestion response used in this area of experimentation. See Section 4.2 for further discussion.
拥塞标记差异：网络节点上的拥塞标记可配置为与不同的发送方对拥塞指示的响应（CE标记）一起维持非常浅的队列，如[ECN-L4S]中所建议的。所涉及的流量需要由网络节点的发送方识别，以避免对其他网络流量造成损害，因为发送方不希望使用更频繁的拥塞标记来维护非常浅的队列。使用不同的ECN码点，特别是ECT（0）和ECT（1），是用于此目的的一种很有希望的流量识别方法，但该技术与RFC 3168中的要求不一致，即标记为ECT（0）的流量与标记为ECT（1）的流量相比，不会在网络中受到不同的处理。IETF批准，例如，通过IETF文档流中的实验RFC，对于该实验领域中使用的拥塞标记或发送方拥塞响应的任何差异都是必需的。进一步讨论见第4.2节。
TCP Control Packets and Retransmissions: RFC 3168 limits the use of ECN with TCP to data packets, excluding retransmissions. With the successful deployment of ECN in large portions of the Internet, there is interest in extending the benefits of ECN to TCP control packets (e.g., SYNs) and retransmitted packets, e.g., as proposed in [ECN-TCP]. This is at variance with RFC 3168's prohibition of ECN for TCP control packets and retransmitted packets. See Section 4.3 for further discussion.
TCP控制数据包和重传：RFC 3168将ECN与TCP的使用限制为数据包，不包括重传。随着ECN在互联网大部分地区的成功部署，人们有兴趣将ECN的好处扩展到TCP控制数据包（例如SYN）和重传数据包，例如[ECN-TCP]中提出的。这与RFC 3168禁止TCP控制数据包和重传数据包使用ECN的规定不符。进一步讨论见第4.3节。
The scope of this memo is limited to these three areas of experimentation. This memo expresses no view on the likely outcomes of the proposed experiments and does not specify the experiments in detail. Additional experiments in these areas are possible, e.g., on use of ECN to support deployment of a protocol similar to Data Center TCP (DCTCP) [RFC8257] beyond DCTCP's current applicability that is limited to data center environments. The purpose of this memo is to remove constraints in Standards Track RFCs that stand in the way of these areas of experimentation.
本备忘录的范围仅限于这三个试验领域。本备忘录未对拟议实验的可能结果发表意见，也未详细说明实验。可以在这些领域进行其他实验，例如，使用ECN支持部署类似于数据中心TCP（DCTCP）[RFC8257]的协议，该协议超出了DCTCP目前仅限于数据中心环境的适用性。本备忘录的目的是消除标准跟踪RFC中阻碍这些试验领域的限制。
Congestion control remains an important aspect of the Internet architecture [RFC2914]. Any Experimental RFC in the IETF document stream that takes advantage of this memo's updates to any RFC is required to discuss the congestion control implications of the experiment(s) in order to provide assurance that deployment of the experiment(s) does not pose a congestion-based threat to the operation of the Internet.
拥塞控制仍然是互联网体系结构的一个重要方面[RFC2914]。IETF文档流中的任何实验性RFC，如果利用了本备忘录对任何RFC的更新，则需要讨论实验的拥塞控制影响，以确保实验的部署不会对互联网的运行造成基于拥塞的威胁。
ECN functionality [RFC3168] is becoming widely deployed in the Internet and is being designed into additional protocols such as Transparent Interconnection of Lots of Links (TRILL) [ECN-TRILL]. ECN experiments are expected to coexist with deployed ECN functionality, with the responsibility for that coexistence falling primarily upon designers of experimental changes to ECN. In addition, protocol designers and implementers, as well as network operators, may desire to anticipate and/or support ECN experiments. The following guidelines will help avoid conflicts with the areas of ECN experimentation enabled by this memo:
ECN功能[RFC3168]正在互联网上广泛部署，并被设计成附加协议，如大量链路的透明互连（TRILL）[ECN-TRILL]。ECN实验预计将与部署的ECN功能共存，共存的责任主要落在对ECN进行实验性更改的设计师身上。此外，协议设计者和实现者以及网络运营商可能希望预测和/或支持ECN实验。以下指导原则将有助于避免与本备忘录启用的ECN试验领域发生冲突：
1. Forwarding behavior as described in RFC 3168 remains the preferred approach for routers that are not involved in ECN experiments, in particular continuing to treat the ECT(0) and ECT(1) codepoints as equivalent, as specified in Section 4.2 below.
1. RFC 3168中描述的转发行为仍然是不涉及ECN实验的路由器的首选方法，特别是继续将ECT（0）和ECT（1）码点视为等效的，如下面第4.2节所述。
2. Network nodes that forward packets SHOULD NOT assume that the ECN CE codepoint indicates that the packet would have been dropped if ECN were not in use. This is because Congestion Response Differences experiments employ different congestion responses to dropped packets by comparison to receipt of CE-marked packets (see Section 4.1 below), so CE-marked packets SHOULD NOT be arbitrarily dropped. A corresponding difference in congestion responses already occurs when the ECN field is used for Pre-Congestion Notification (PCN) [RFC6660].
2. 转发数据包的网络节点不应假定ECN CE代码点指示如果ECN未被使用，数据包将被丢弃。这是因为拥塞响应差异实验通过与CE标记的数据包的接收进行比较，对丢弃的数据包采用不同的拥塞响应（见下文第4.1节），因此CE标记的数据包不应被任意丢弃。当ECN字段用于拥塞前通知（PCN）[RFC6660]时，拥塞响应中已出现相应的差异。
3. A network node MUST NOT originate traffic marked with ECT(1) unless the network node is participating in a Congestion Marking Differences experiment that uses ECT(1), as specified in Section 4.2 below.
3. 网络节点不得发起标有ECT（1）的流量，除非该网络节点正在参与使用ECT（1）的拥塞标记差异试验，如下文第4.2节所述。
Some ECN experiments use ECN with packets where ECN has not been used previously, specifically TCP control packets and retransmissions; see Section 4.3 below. The new middlebox behavior requirements in that section are of particular importance. In general, any system or protocol that inspects or monitors network traffic SHOULD be prepared to encounter ECN usage on packets and traffic that currently do not use ECN.
一些ECN实验将ECN用于以前未使用ECN的数据包，特别是TCP控制数据包和重传；见下文第4.3节。该部分中新的中间盒行为要求特别重要。一般来说，任何检查或监视网络流量的系统或协议都应该准备好在当前不使用ECN的数据包和流量上遇到ECN使用情况。
ECN field handling requirements for tunnel encapsulation and decapsulation are specified in [RFC6040], which is in the process of being updated by [ECN-SHIM]. Related guidance for encapsulations whose outer headers are not IP headers can be found in [ECN-ENCAP]. These requirements and guidance apply to all traffic, including traffic that is part of any ECN experiment.
[RFC6040]中规定了隧道封装和去封装的ECN现场处理要求，该要求正在由[ECN-SHIM]更新。有关外部头不是IP头的封装的相关指南，请参见[ECN-ENCAP]。这些要求和指导适用于所有流量，包括作为任何ECN试验一部分的流量。
Changes in network traffic behavior that result from ECN experimentation are likely to impact network operations and management. Designers of ECN experiments are expected to anticipate possible impacts and consider how they may be dealt with. Specific topics to consider include possible network management changes or extensions, monitoring of the experimental deployment, collection of data for evaluation of the experiment, and possible interactions with other protocols, particularly protocols that encapsulate network traffic.
ECN实验导致的网络流量行为变化可能会影响网络运营和管理。ECN实验的设计者预计会预见到可能的影响并考虑它们可能如何处理。要考虑的特定主题包括可能的网络管理变化或扩展、监测实验部署、收集数据以评估实验，以及可能与其他协议的交互，特别是封装网络流量的协议。
For further discussion, see [RFC5706]; the questions in Appendix A of RFC 5706 provide a concise survey of some important aspects to consider.
有关进一步讨论，请参见[RFC5706]；RFC 5706附录A中的问题提供了一些要考虑的重要方面的简明调查。
As specified in RFC 3168, ECN uses two ECN-Capable Transport (ECT) codepoints, ECT(0) and ECT(1), to indicate that a packet supports ECN. RFC 3168 assigned the second codepoint, ECT(1), to support ECN nonce functionality that discourages receivers from exploiting ECN to improve their throughput at the expense of other network users. That ECN nonce functionality is fully specified in RFC 3540 [RFC3540]. This section explains why RFC 3540 has been reclassified from Experimental to Historic and makes associated updates to RFC 3168.
如RFC 3168中所述，ECN使用两个支持ECN的传输（ECT）代码点ECT（0）和ECT（1），以指示数据包支持ECN。RFC 3168分配了第二个代码点ECT（1），以支持ECN nonce功能，该功能阻止接收机利用ECN提高吞吐量，而牺牲其他网络用户的利益。RFC 3540[RFC3540]中完全规定了ECN当前功能。本节解释了为什么RFC 3540已从实验性重新分类为历史性，并对RFC 3168进行了相关更新。
While the ECN nonce works as specified, and has been deployed in limited environments, widespread usage in the Internet has not materialized. A study of the ECN behavior of the top one million web servers using 2014 data [Trammell15] found that after ECN was negotiated, none of the 581,711 IPv4 servers tested were using both ECT codepoints, which would have been a possible sign of ECN nonce usage. Of the 17,028 IPv6 servers tested, four set both ECT(0) and ECT(1) on data packets. This might have been evidence of use of the ECN nonce by these four servers, but it might equally have been due to erroneous re-marking of the ECN field by a middlebox or router.
虽然ECN nonce按规定工作，并已部署在有限的环境中，但尚未在Internet上广泛使用。使用2014年数据[Trammell15]对排名前100万的web服务器的ECN行为进行的研究发现，在协商ECN后，测试的581711台IPv4服务器中没有一台同时使用两个ECT代码点，这可能是ECN暂时使用的迹象。在测试的17028台IPv6服务器中，有四台在数据包上同时设置了ECT（0）和ECT（1）。这可能是这四台服务器使用ECN nonce的证据，但同样也可能是由于中间盒或路由器错误地重新标记了ECN字段。
With the emergence of new experimental functionality that depends on use of the ECT(1) codepoint for other purposes, continuing to reserve that codepoint for the ECN nonce experiment is no longer justified. In addition, other approaches to discouraging receivers from exploiting ECN have emerged; see Appendix B.1 of [ECN-L4S]. Therefore, in support of ECN experimentation with the ECT(1) codepoint, this memo:
随着依赖于将ECT（1）码点用于其他目的的新实验功能的出现，继续为ECN nonce实验保留该码点已不再合理。此外，还出现了其他阻止接收者利用ECN的方法；见[ECN-L4S]的附录B.1。因此，为了支持ECT（1）代码点的ECN试验，本备忘录：
o Declares that the ECN nonce experiment [RFC3540] has concluded and notes the absence of widespread deployment.
o 声明ECN nonce实验[RFC3540]已结束，并注意到没有广泛部署。
o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce and use of ECT(1) for that nonce.
o 更新RFC 3168[RFC3168]以删除对ECN nonce的讨论以及对该nonce使用ECT（1）。
The four primary updates to RFC 3168 that remove discussion of the ECN nonce and use of ECT(1) for that nonce are as follows:
RFC 3168的四个主要更新删除了对ECN nonce的讨论以及对该nonce使用ECT（1）的情况，如下所示：
1. The removal of the paragraph in Section 5 that immediately follows Figure 1; this paragraph discusses the ECN nonce as the motivation for two ECT codepoints.
1. 删除第5节中紧跟图1的段落；本段讨论ECN nonce作为两个ECT代码点的动机。
2. The removal of Section 11.2, "A Discussion of the ECN nonce", in its entirety.
2. 全部删除第11.2节“ECN当前讨论”。
3. The removal of the last paragraph of Section 12, which states that ECT(1) may be used as part of the implementation of the ECN nonce.
3. 删除第12节最后一段，该段规定ECT（1）可作为ECN nonce实施的一部分。
4. The removal of the first two paragraphs of Section 20.2, which discuss the ECN nonce and alternatives. No changes are made to the rest of Section 20.2, which discusses alternative uses for the fourth ECN codepoint.
4. 删除第20.2节的前两段，其中讨论了ECN当前和备选方案。第20.2节讨论了第四个ECN代码点的替代用途，其余部分未作任何更改。
In addition, other less-substantive changes to RFC 3168 are required to remove all other mentions of the ECN nonce and to remove implications that ECT(1) is intended for use by the ECN nonce; these specific text updates are omitted for brevity.
此外，需要对RFC 3168进行其他不太实质性的更改，以删除所有其他提及的ECN nonce，并删除ECT（1）拟由ECN nonce使用的含义；为了简洁起见，省略了这些特定的文本更新。
The following subsections specify updates to RFC 3168 to enable the three areas of experimentation summarized in Section 2.
以下小节指定了RFC 3168的更新，以实现第2节中总结的三个实验领域。
RFC 3168 specifies that senders respond identically to packet drops and ECN congestion indications. ECN congestion indications are predominately originated by Active Queue Management (AQM) mechanisms in intermediate buffers. AQM mechanisms are usually configured to maintain shorter queue lengths than non-AQM-based mechanisms, particularly non-AQM drop-based mechanisms such as tail-drop, as AQM mechanisms indicate congestion before the queue overflows. While the occurrence of loss does not easily enable the receiver to determine if AQM is used, the receipt of an ECN CE mark conveys a strong likelihood that AQM was used to manage the bottleneck queue. Hence, an ECN congestion indication communicates a higher likelihood than a dropped packet that a short queue exists at the network bottleneck node [TCP-ABE]. This difference suggests that for congestion indicated by ECN, a different sender congestion response (e.g., sender backs off by a smaller amount) may be appropriate by comparison to the sender response to congestion indicated by loss. However, Section 5 of RFC 3168 specifies that:
RFC 3168规定发送方对丢包和ECN拥塞指示的响应相同。ECN拥塞指示主要由中间缓冲区中的主动队列管理（AQM）机制引起。AQM机制通常配置为保持比非AQM机制更短的队列长度，特别是非AQM丢弃机制，如尾部丢弃，因为AQM机制在队列溢出之前指示拥塞。虽然丢失的发生不容易使接收者确定是否使用了AQM，但接收到ECN CE标记表示AQM被用于管理瓶颈队列的可能性很大。因此，与丢弃的数据包相比，ECN拥塞指示在网络瓶颈节点[TCP-ABE]处传递存在短队列的可能性更高。这种差异表明，对于ECN指示的拥塞，与丢失指示的发送方对拥塞的响应相比，不同的发送方拥塞响应（例如，发送方退避较小的量）可能是合适的。但是，RFC 3168第5节规定：
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.
当具有ECN能力的传输接收到单个CE分组时，终端系统遵循的拥塞控制算法必须与对*单个*丢弃分组的拥塞控制响应基本相同。
This memo updates this text from RFC 3168 to allow the congestion control response (including the TCP Sender's congestion control response) to a CE-marked packet to differ from the response to a dropped packet, provided that the changes from RFC 3168 are
此备忘录从RFC 3168更新此文本，以允许对CE标记数据包的拥塞控制响应（包括TCP发送方的拥塞控制响应）与对丢弃数据包的响应不同，前提是RFC 3168的更改是
documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of the sentence quoted above.
记录在IETF文档流中的实验RFC中。对RFC 3168的具体修改是在上面引用的句子末尾插入“除非IETF文档流中的实验RFC另有规定”。
RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, but it does not impose requirements based on that text. Therefore, no update to RFC 4774 is required to enable this area of experimentation.
RFC 4774[RFC4774]引用RFC 3168中的上述文本作为背景，但它没有基于该文本提出要求。因此，无需对RFC 4774进行更新即可启用此实验领域。
Section 6.1.2 of RFC 3168 specifies that:
RFC 3168第6.1.2节规定：
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".
如果发送方收到ECN Echo（ECE）ACK数据包（即TCP报头中设置了ECN Echo标志的ACK数据包），则发送方知道在从发送方到接收方的路径上的网络中遇到了拥塞。拥塞指示应被视为不支持ECN的TCP中的拥塞丢失。也就是说，TCP源将拥塞窗口“cwnd”减半，并降低慢启动阈值“ssthresh”。
This memo also updates this text from RFC 3168 to allow the congestion control response (including the TCP Sender's congestion control response) to a CE-marked packet to differ from the response to a dropped packet, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "Unless otherwise specified by an Experimental RFC in the IETF document stream" at the beginning of the second sentence quoted above.
本备忘录还更新了RFC 3168中的文本，以允许对CE标记数据包的拥塞控制响应（包括TCP发送方的拥塞控制响应）与对丢弃数据包的响应不同，前提是在IETF文档流中的实验RFC中记录了对RFC 3168的更改。RFC 3168的具体更改是在上面引用的第二句开头插入“除非IETF文件流中的实验RFC另有规定”。
Taken to its limit, an AQM algorithm that uses ECN congestion indications can be configured to maintain very shallow queues, thereby reducing network latency by comparison to maintaining a larger queue. Significantly more aggressive sender responses to ECN are needed to make effective use of such very shallow queues; "Datacenter TCP (DCTCP)" [RFC8257] provides an example. In this case, separate network node treatments are essential, both to prevent the aggressive low-latency traffic from starving conventional traffic (if present) and to prevent any conventional traffic disruption to any lower-latency service that uses the very shallow queues. Use of different ECN codepoints is a promising means of identifying these two classes of traffic to network nodes; hence, this area of experimentation is based on the use of the ECT(1) codepoint to request ECN congestion marking behavior in the network that differs from ECT(0). It is essential that any such change in ECN congestion marking behavior be counterbalanced by use of a different IETF-
受限于此，使用ECN拥塞指示的AQM算法可以配置为维护非常浅的队列，从而与维护较大的队列相比减少网络延迟。为了有效利用这种非常浅的队列，需要对ECN做出更积极的发送方响应；“数据中心TCP（DCTCP）”[RFC8257]提供了一个示例。在这种情况下，单独的网络节点处理是必不可少的，既可以防止侵略性的低延迟流量耗尽常规流量（如果存在），也可以防止对使用非常浅队列的任何低延迟服务的任何常规流量中断。使用不同的ECN码点是识别网络节点的这两类流量的有希望的方法；因此，该实验领域基于使用ECT（1）码点来请求网络中不同于ECT（0）的ECN拥塞标记行为。ECN拥塞标记行为的任何此类变化都必须通过使用不同的IETF来平衡-
approved congestion response to CE marks at the sender, e.g., as proposed in [ECN-L4S].
经批准的对发送方CE标志的拥塞响应，如[ECN-L4S]中建议的。
Section 5 of RFC 3168 specifies that "Routers treat the ECT(0) and ECT(1) codepoints as equivalent."
RFC3168的第5节规定“路由器将ECT（0）和ECT（1）代码点视为等效的。”
This memo updates RFC 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints differently, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of the above sentence.
本备忘录更新了RFC 3168，以允许路由器以不同方式处理ECT（0）和ECT（1）代码点，前提是RFC 3168的更改记录在IETF文档流中的实验RFC中。RFC 3168的具体更改是在上述句子末尾插入“除非IETF文档流中的实验RFC另有规定”。
When an AQM is configured to use ECN congestion indications to maintain a very shallow queue, congestion indications are marked on packets that would not have been dropped if ECN was not in use. Section 5 of RFC 3168 specifies that:
当AQM被配置为使用ECN拥塞指示来维持非常浅的队列时，拥塞指示被标记在如果ECN未被使用则不会被丢弃的数据包上。RFC 3168第5节规定：
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码点，而不是丢弃分组。
This memo updates RFC 3168 to allow congestion indications that are not equivalent to drops, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change is to change "For a router" to "Unless otherwise specified by an Experimental RFC in the IETF document stream" at the beginning of the first sentence of the above paragraph.
本备忘录对RFC 3168进行了更新，以允许不等同于DROP的拥塞指示，前提是RFC 3168的更改记录在IETF文档流中的实验RFC中。具体更改是将上述段落第一句开头的“路由器”更改为“除非IETF文件流中的实验RFC另有规定”。
A larger update to RFC 3168 is necessary to enable sender usage of ECT(1) to request network congestion marking behavior that maintains very shallow queues at network nodes. When using loss as a congestion signal, the number of signals provided should be reduced to a minimum; hence, only the presence or absence of congestion is communicated. In contrast, ECN can provide a richer signal, e.g., to indicate the current level of congestion, without the disadvantage of a larger number of packet losses. A proposed experiment in this area, Low Latency Low Loss Scalable throughput (L4S) [ECN-L4S], significantly increases the CE marking probability for traffic marked as ECT(1) in a fashion that would interact badly with existing sender congestion response functionality because that functionality assumes that the network marks ECT packets as frequently as it would drop Not-ECT packets. If network traffic that uses such a conventional
有必要对RFC 3168进行更大的更新，以使发送方能够使用ECT（1）请求网络拥塞标记行为，从而在网络节点上保持非常浅的队列。当使用损耗作为拥塞信号时，应将提供的信号数量减少到最小；因此，仅通信拥塞的存在或不存在。相反，ECN可以提供更丰富的信号，例如，指示当前的拥塞水平，而不存在大量分组丢失的缺点。在该领域提出的一项实验，即低延迟低损失可扩展吞吐量（L4S）[ECN-L4S]，显著提高了标记为ECT（1）的流量的CE标记概率以一种与现有发送方拥塞响应功能严重交互的方式，因为该功能假定网络标记ECT数据包的频率与丢弃Not ECT数据包的频率相同。如果网络流量使用这种传统的
sender congestion response were to encounter L4S's increased marking probability (and hence rate) at a network bottleneck queue, the resulting traffic throughput is likely to be much less than intended for the level of congestion at the bottleneck queue.
如果发送方拥塞响应在网络瓶颈队列中遇到L4S增加的标记概率（以及因此而增加的速率），则产生的流量吞吐量可能远小于瓶颈队列中拥塞级别的预期吞吐量。
This memo updates RFC 3168 to remove that interaction for ECT(1). The specific update to Section 5 of RFC 3168 is to replace the following two paragraphs:
此备忘录更新RFC 3168，以删除ECT（1）的交互。RFC 3168第5节的具体更新将替换以下两段：
Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.
发送方可自由使用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）。
with this paragraph:
在本段中：
Protocols and senders MUST use the ECT(0) codepoint to indicate ECT unless otherwise specified by an Experimental RFC in the IETF document stream. Protocols and senders MUST NOT use the ECT(1) codepoint to indicate ECT unless otherwise specified by an Experimental RFC in the IETF document stream. Guidelines for 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.
协议和发送方必须使用ECT（0）码点指示ECT，除非IETF文档流中的实验RFC另有规定。协议和发送方不得使用ECT（1）码点指示ECT，除非IETF文件流中的实验RFC另有规定。对于每个传输协议，发送方和接收方区分ECT（0）和ECT（1）码点的指南将在单独的文件中说明。特别是，本文档不介绍TCP端节点区分ECT（0）和ECT（1）代码点的机制。
Congestion Marking Differences experiments SHOULD modify the network behavior for traffic marked as ECT(1) rather than ECT(0) if network behavior for only one ECT codepoint is modified. Congestion Marking Differences experiments MUST NOT modify the network behavior for traffic marked as ECT(0) in a fashion that requires changes to the sender congestion response to obtain desired network behavior. If a Congestion Marking Differences experiment modifies the network behavior for traffic marked as ECT(1), e.g., CE-marking behavior, in
如果只修改了一个ECT码点的网络行为，则拥塞标记差异实验应修改标记为ECT（1）而不是ECT（0）的流量的网络行为。拥塞标记差异实验不得修改标记为ECT（0）的流量的网络行为，这种方式要求更改发送方拥塞响应以获得所需的网络行为。如果拥塞标记差异实验修改了标记为ECT（1）的流量的网络行为，例如CE标记行为
a fashion that requires changes to the sender congestion response to obtain desired network behavior, then the Experimental RFC in the IETF document stream for that experiment MUST specify:
一种需要更改发送方拥塞响应以获得所需网络行为的方式，则该实验的IETF文档流中的实验RFC必须指定：
o The sender congestion response to CE marking in the network, and
o 发送方对网络中CE标记的拥塞响应，以及
o Router behavior changes, or the absence thereof, in forwarding CE-marked packets that are part of the experiment.
o 路由器行为的改变，或不存在，在转发CE标记的数据包，这是实验的一部分。
In addition, this memo updates RFC 3168 to remove discussion of the ECN nonce, as noted in Section 3 above.
此外，如上文第3节所述，本备忘录更新了RFC 3168，以删除对ECN的讨论。
With the successful use of ECN for traffic in large portions of the Internet, there is interest in extending the benefits of ECN to TCP control packets (e.g., SYNs) and retransmitted packets, e.g., as proposed by ECN++ [ECN-TCP].
随着ECN在互联网的大部分流量中的成功使用，人们有兴趣将ECN的好处扩展到TCP控制数据包（如SYN）和重传数据包，如ECN++[ECN-TCP]提出的。
RFC 3168 prohibits use of ECN for TCP control packets and retransmitted packets in a number of places:
RFC 3168禁止在许多地方对TCP控制数据包和重传数据包使用ECN：
o Section 5.2: "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."
o 第5.2节：“为确保CE码点拥塞指示的可靠传递，不得在数据包中设置ECT码点，除非终端节点检测到网络中该数据包的丢失并将其解释为拥塞指示。”
o Section 6.1.1: "A host MUST NOT set ECT on SYN or SYN-ACK packets"
o 第6.1.1节：“主机不得在SYN或SYN-ACK数据包上设置ECT”
o Section 6.1.4: "...pure acknowledgement packets (e.g., packets that do not contain any accompanying data) MUST be sent with the not-ECT codepoint."
o 第6.1.4节：“……纯确认数据包（例如，不包含任何伴随数据的数据包）必须与非ECT码点一起发送。”
o Section 6.1.5: "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."
o 第6.1.5节：“本文件规定，支持ECN的TCP实现不得在IP报头中为重新传输的数据包设置ECT码点（ECT（0）或ECT（1）），并且TCP数据接收器应忽略到达接收器当前窗口之外的数据包的ECN字段。”
o Section 6.1.6: "...the TCP data sender MUST NOT set either an ECT codepoint or the CWR bit on window probe packets.
o 第6.1.6节：“……TCP数据发送方不得在窗口探测数据包上设置ECT码点或CWR位。
This memo updates RFC 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, pure acknowledgement packets, window probe packets, and retransmissions of packets that were originally sent with an ECT codepoint, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The
本备忘录更新了RFC 3168，以允许在SYN和SYN-ACK数据包、纯确认数据包、窗口探测数据包上使用ECT码点，并重新传输最初使用ECT码点发送的数据包，前提是RFC 3168的更改记录在IETF文档流中的实验RFC中。这个
specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of each sentence quoted above.
对RFC 3168的具体修改是在上面引用的每个句子末尾插入“除非IETF文档流中的实验RFC另有规定”。
In addition, beyond requiring TCP senders not to set ECT on TCP control packets and retransmitted packets, RFC 3168 is silent on whether it is appropriate for a network element, e.g., a firewall, to discard such a packet as invalid. For this area of ECN experimentation to be useful, middleboxes ought not to do that; therefore, RFC 3168 is updated by adding the following text to the end of Section 6.1.1.1 on Middlebox Issues:
此外，除了要求TCP发送方不在TCP控制数据包和重传数据包上设置ECT之外，RFC 3168对网络元件（例如防火墙）是否适合丢弃无效数据包保持沉默。为了让ECN实验的这一领域变得有用，中间商不应该这样做；因此，RFC 3168通过在第6.1.1.1节关于中间箱问题的末尾添加以下文本进行更新：
Unless otherwise specified by an Experimental RFC in the IETF document stream, middleboxes SHOULD NOT discard TCP control packets and retransmitted TCP packets solely because the ECN field in the IP header does not contain Not-ECT. An exception to this requirement occurs in responding to an attack that uses ECN codepoints other than Not-ECT. For example, as part of the response, it may be appropriate to drop ECT-marked TCP SYN packets with higher probability than TCP SYN packets marked with Not-ECT. Any such exceptional discarding of TCP control packets and retransmitted TCP packets in response to an attack MUST NOT be done routinely in the absence of an attack and SHOULD only be done if it is determined that the use of ECN is contributing to the attack.
除非IETF文档流中的实验RFC另有规定，否则中间盒不应仅因为IP报头中的ECN字段不包含NOT ECT而丢弃TCP控制数据包和重新传输的TCP数据包。在响应使用ECN代码点而非ECT的攻击时，会出现此要求的例外情况。例如，作为响应的一部分，丢弃带有ECT标记的TCP SYN数据包可能比丢弃带有Not ECT标记的TCP SYN数据包的概率更高。在没有攻击的情况下，不得定期丢弃TCP控制数据包和响应攻击而重新传输的TCP数据包，只有在确定使用ECN导致攻击时，才应这样做。
RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows use of both the ECT(0) and ECT(1) codepoints and provides the following guidance on use of these codepoints in Section 7.3.1:
RFC 6679[RFC6679]规定了对RTP通信使用ECN；它允许使用ECT（0）和ECT（1）代码点，并在第7.3.1节中提供了关于使用这些代码点的以下指南：
The sender SHOULD mark packets as ECT(0) unless the receiver expresses a preference for ECT(1) or for a random ECT value using the "ect" parameter in the "a=ecn-capable-rtp:" attribute.
发送方应将数据包标记为ECT（0），除非接收方使用“a=ecn-capable rtp:”属性中的“ECT”参数表示偏好ECT（1）或随机ECT值。
The Congestion Marking Differences area of experimentation increases the potential consequences of using ECT(1) instead of ECT(0); hence, the above guidance is updated by adding the following two sentences:
实验的拥塞标记差异区域增加了使用ECT（1）而不是ECT（0）的潜在后果；因此，在上述指南中增加了以下两句话：
Random ECT values MUST NOT be used, as that may expose RTP to differences in network treatment of traffic marked with ECT(1) and ECT(0) and differences in associated endpoint congestion responses. In addition, ECT(0) MUST be used unless otherwise specified in an Experimental RFC in the IETF document stream.
不得使用随机ECT值，因为这可能会使RTP暴露于使用ECT（1）和ECT（0）标记的流量的网络处理的差异以及相关端点拥塞响应的差异。此外，除非在IETF文档流中的实验RFC中另有规定，否则必须使用ECT（0）。
Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE-marked packets as being identical to the response to dropped packets:
RFC 6679第7.3.3节规定RTP对接收CE标记数据包的响应与对丢弃数据包的响应相同：
The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred. There should be no difference in congestion response if ECN-CE marks or packet drops are detected.
在IP报头中接收带有ECN-CE标记的RTP数据包是一种正在经历拥塞的通知。接收到这些ECN CE标记的数据包时的默认反应必须是向拥塞控制算法提供拥塞通知，该通知触发算法作出反应，就好像发生了数据包丢失一样。如果检测到ECN-CE标记或数据包丢失，则拥塞响应应该没有差异。
In support of Congestion Response Differences experimentation, this memo updates this text in a fashion similar to RFC 3168 to allow the RTP congestion control response to a CE-marked packet to differ from the response to a dropped packet, provided that the changes from RFC 6679 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 6679 is to insert the words "Unless otherwise specified by an Experimental RFC in the IETF document stream" and reformat the last two sentences to be subject to that condition; that is:
为了支持拥塞响应差异实验，本备忘录以类似于RFC 3168的方式更新本文本，以允许对CE标记数据包的RTP拥塞控制响应不同于对丢弃数据包的响应，前提是在IETF文档流中的实验RFC中记录了RFC 6679的更改。RFC 6679的具体更改是插入“除非IETF文件流中的实验RFC另有规定”，并根据该条件重新格式化最后两句话；即:
The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. Unless otherwise specified by an Experimental RFC in the IETF document stream:
在IP报头中接收带有ECN-CE标记的RTP数据包是一种正在经历拥塞的通知。除非IETF文件流中的实验RFC另有规定：
* The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred.
* 接收到这些ECN CE标记的数据包时的默认反应必须是向拥塞控制算法提供拥塞通知，该通知触发算法作出反应，就好像发生了数据包丢失一样。
* There should be no difference in congestion response if ECN-CE marks or packet drops are detected.
* 如果检测到ECN-CE标记或数据包丢失，则拥塞响应应该没有差异。
The second sentence of the immediately following paragraph in Section 7.3.3 of RFC 6679 requires a related update:
RFC 6679第7.3.3节下一段的第二句要求进行相关更新：
Other reactions to ECN-CE may be specified in the future, following IETF Review. Detailed designs of such alternative reactions MUST be specified in a Standards Track RFC and be reviewed to ensure they are safe for deployment under any restrictions specified.
对ECN-CE的其他反应可能在未来的IETF审查后指定。此类替代反应的详细设计必须在标准跟踪RFC中规定，并进行审查，以确保在规定的任何限制条件下安全部署。
The update is to change "Standards Track RFC" to "Standards Track RFC or Experimental RFC in the IETF document stream" for consistency with the first update.
更新将“标准跟踪RFC”更改为“IETF文档流中的标准跟踪RFC或实验RFC”，以与第一次更新保持一致。
The specifications of the three DCCP Congestion Control IDs (CCIDs), 2 [RFC4341], 3 [RFC4342], and 4 [RFC5622], contain broadly the same wording as follows:
三个DCCP拥塞控制ID（CCID）、2[RFC4341]、3[RFC4342]和4[RFC5622]的规范包含大致相同的措辞，如下所示：
each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with either the ECT(0) or the ECT(1) codepoint set.
每个DCCP数据和DCCP DataAck数据包作为具有ECT（0）或ECT（1）码点集的ECN发送。
This memo updates these sentences in each of the three RFCs as follows:
本备忘录对三个RFC中的每一个句子更新如下：
each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. Unless otherwise specified by an Experimental RFC in the IETF document stream, such DCCP senders MUST set the ECT(0) codepoint.
每个DCCP数据和DCCP数据包都以支持ECN的方式发送。除非IETF文档流中的实验RFC另有规定，否则此类DCCP发送者必须设置ECT（0）码点。
In support of Congestion Marking Differences experimentation (as noted in Section 3), this memo also updates all three of these RFCs to remove discussion of the ECN nonce. The specific text updates are omitted for brevity.
为了支持拥塞标记差异实验（如第3节所述），本备忘录还更新了所有三个RFC，以消除对ECN时间的讨论。为简洁起见，省略了特定的文本更新。
To reflect the reclassification of RFC 3540 as Historic, IANA has updated the "Transmission Control Protocol (TCP) Header Flags" registry <https://www.iana.org/assignments/tcp-header-flags> to remove the registration of bit 7 as the NS (Nonce Sum) bit and add an annotation to the registry to state that bit 7 was used by Historic RFC 3540 as the NS (Nonce Sum) bit but is now Reserved.
为了反映将RFC 3540重新分类为历史，IANA更新了“传输控制协议（TCP）头标志”注册表<https://www.iana.org/assignments/tcp-header-flags>删除位7作为NS（Nonce Sum）的注册位，并向注册表添加注释，以说明位7曾被历史RFC 3540用作NS（Nonce Sum）位，但现在保留。
As a process memo that only relaxes restrictions on experimentation, there are no protocol security considerations, as security considerations for any experiments that take advantage of the relaxed restrictions are discussed in the documents that propose the experiments.
作为一个只放松实验限制的过程备忘录，没有协议安全考虑，因为在提出实验的文档中讨论了利用放松限制的任何实验的安全考虑。
However, effective congestion control is crucial to the continued operation of the Internet; hence, this memo places the responsibility for not breaking Internet congestion control on the experiments and the experimenters who propose them. This responsibility includes the requirement to discuss congestion control implications in an Experimental RFC in the IETF document stream for each experiment, as stated in Section 2.1; review of that discussion by the IETF community and the IESG prior to RFC publication is intended to provide assurance that each experiment does not break Internet congestion control.
然而，有效的拥塞控制对互联网的持续运行至关重要；因此，这份备忘录将不破坏互联网拥塞控制的责任放在实验和提出实验的实验者身上。如第2.1节所述，该责任包括在IETF文件流中讨论每个实验的实验RFC中的拥塞控制影响的要求；在RFC发布之前，IETF社区和IESG对该讨论的审查旨在确保每个实验不会破坏互联网拥塞控制。
See Appendix C.1 of [ECN-L4S] for discussion of alternatives to the ECN nonce.
参见[ECN-L4S]附录C.1，了解ECN替代方案的讨论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，DOI 10.17487/RFC2914，2000年9月<https://www.rfc-editor.org/info/rfc2914>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, DOI 10.17487/RFC3540, June 2003, <https://www.rfc-editor.org/info/rfc3540>.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“具有非同步信号的鲁棒显式拥塞通知（ECN）信令”，RFC 3540，DOI 10.17487/RFC3540，2003年6月<https://www.rfc-editor.org/info/rfc3540>.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, <https://www.rfc-editor.org/info/rfc4341>.
[RFC4341]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，RFC 4341，DOI 10.17487/RFC4341，2006年3月<https://www.rfc-editor.org/info/rfc4341>.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, <https://www.rfc-editor.org/info/rfc4342>.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 4342，DOI 10.17487/RFC4342，2006年3月<https://www.rfc-editor.org/info/rfc4342>.
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, <https://www.rfc-editor.org/info/rfc5622>.
[RFC5622]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞ID 4的配置文件：小数据包的TCP友好速率控制（TFRC-SP）”，RFC 5622，DOI 10.17487/RFC5622，2009年8月<https://www.rfc-editor.org/info/rfc5622>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC6679]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，DOI 10.17487/RFC66792012年8月<https://www.rfc-editor.org/info/rfc6679>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[ECN-ENCAP] Briscoe, B., Kaippallimalil, J., and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Work in Progress, draft-ietf-tsvwg-ecn-encap-guidelines-09, July 2017.
[ECN-ENCAP]Briscoe，B.，Kaippallimalil，J.，和P.Thaler，“向封装IP的协议添加拥塞通知的指南”，正在进行的工作，草稿-ietf-tsvwg-ECN-ENCAP-Guidelines-092017年7月。
[ECN-EXPERIMENT] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "Updating the Explicit Congestion Notification (ECN) Specification to Allow IETF Experimentation", Work in Progress, draft-khademi-tsvwg-ecn-response-01, July 2016.
[ECN-实验]Khademi，N.，Welzl，M.，Armitage，G.，和G.Fairhurst，“更新显式拥塞通知（ECN）规范以允许IETF实验”，正在进行的工作，草稿-Khademi-tsvwg-ECN-response-01，2016年7月。
[ECN-L4S] Schepper, K. and B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay", Work in Progress, draft-ietf-tsvwg-ecn-l4s-id-01, October 2017.
[ECN-L4S]Schepper，K.和B.Briscoe，“识别超低排队延迟的修改的显式拥塞通知（ECN）语义”，正在进行的工作，草稿-ietf-tsvwg-ECN-L4S-id-01，2017年10月。
[ECN-SHIM] Briscoe, B., "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim", Work in Progress, draft-ietf-tsvwg-rfc6040update-shim-05, November 2017.
[ECN-SHIM]Briscoe，B.，“在由SHIM分隔的IP隧道头之间传播显式拥塞通知”，正在进行的工作，草稿-ietf-tsvwg-rfc6040update-SHIM-05，2017年11月。
[ECN-TCP] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", Work in Progress, draft-ietf-tcpm-generalized-ecn-02, October 2017.
[ECN-TCP]Bagnulo，M.和B.Briscoe，“ECN++：向TCP控制数据包添加显式拥塞通知（ECN）”，正在进行的工作，草稿-ietf-tcpm-generalized-ECN-022017年10月。
[ECN-TRILL] Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit Congestion Notification) Support", Work in Progress, draft-ietf-trill-ecn-support-04, November 2017.
[ECN-TRILL]Eastlake，D.和B.Briscoe，“TRILL:ECN（显式拥塞通知）支持”，正在进行的工作，草稿-ietf-TRILL-ECN-Support-042017年11月。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <https://www.rfc-editor.org/info/rfc4774>.
[RFC4774]Floyd，S.，“为显式拥塞通知（ECN）字段指定替代语义”，BCP 124，RFC 4774，DOI 10.17487/RFC4774，2006年11月<https://www.rfc-editor.org/info/rfc4774>.
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, <https://www.rfc-editor.org/info/rfc4844>.
[RFC4844]Daigle，L.，Ed.和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 4844，DOI 10.17487/RFC4844，2007年7月<https://www.rfc-editor.org/info/rfc4844>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，DOI 10.17487/RFC5706，2009年11月<https://www.rfc-editor.org/info/rfc5706>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 6040，DOI 10.17487/RFC6040，2010年11月<https://www.rfc-editor.org/info/rfc6040>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, <https://www.rfc-editor.org/info/rfc6660>.
[RFC6660]Briscoe，B.，Moncaster，T.，和M.Meth，“使用单个区分服务码点（DSCP）在IP报头中编码三种拥塞前通知（PCN）状态”，RFC 6660，DOI 10.17487/RFC6660，2012年7月<https://www.rfc-editor.org/info/rfc6660>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8257]Bensley，S.，Thaler，D.，Balasubramanian，P.，Eggert，L.，和G.Judd，“数据中心TCP（DCTCP）：数据中心的TCP拥塞控制”，RFC 8257，DOI 10.17487/RFC8257，2017年10月<https://www.rfc-editor.org/info/rfc8257>.
[TCP-ABE] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", Work in Progress, draft-ietf-tcpm-alternativebackoff-ecn-05, December 2017.
[TCP-ABE]Khademi，N.，Welzl，M.，Armitage，G.，和G.Fairhurst，“采用ECN（ABE）的TCP替代性退避”，正在进行的工作，草案-ietf-tcpm-Alternative Backoff-ECN-052017年12月。
[Trammell15] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., Fairhurst, G., and R. Scheffenegger, "Enabling Internet-Wide Deployment of Explicit Congestion Notification", In Conference Proceedings of Passive and Active Measurement (PAM), pp. 193-205, March 2015, <https://doi.org/10.1007/978-3-319-15509-8_15>.
[Trammell 15]Trammell，B.，Kuehlewind，M.，Boppart，D.，LearnMonth，I.，Fairhurst，G.，和R.Scheffenegger，“在互联网范围内部署明确的拥塞通知”，载于《被动和主动测量会议录》（PAM），第193-205页，2015年3月<https://doi.org/10.1007/978-3-319-15509-8_15>.
Acknowledgements
致谢
The content of this specification, including the specific portions of RFC 3168 that are updated, draws heavily from [ECN-EXPERIMENT], whose authors are gratefully acknowledged. The authors of the documents describing the experiments have motivated the production of this memo -- their interest in innovation is welcome and heartily acknowledged. Colin Perkins suggested updating RFC 6679 on RTP and provided guidance on where to make the updates.
本规范的内容，包括更新的RFC 3168的特定部分，大量借鉴了[ECN-ERFESSION]，感谢其作者。描述这些实验的文件的作者激发了这份备忘录的制作——他们对创新的兴趣是受欢迎的，并得到了衷心的认可。Colin Perkins建议在RTP上更新RFC 6679，并提供了在何处进行更新的指导。
This specification improved as a result of comments from a number of reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise, Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric Rescorla, Adam Roach, and Michael Welzl. Bob Briscoe's thorough review of multiple draft versions of this memo resulted in numerous improvements including addition of the updates to the DCCP RFCs.
本规范的改进得益于众多评审员的评论，包括本·坎贝尔、布赖恩·卡彭特、贝诺特·克莱斯、斯宾塞·道金斯、戈里·费尔赫斯特、休·哈尔斯、英格玛·约翰逊、内姆·哈代米、米尔贾·库勒温德、卡伦·尼尔森、希拉里·奥曼、埃里克·雷科拉、亚当·罗奇和迈克尔·韦尔兹尔。鲍勃·布里斯科（Bob Briscoe）对本备忘录的多个草案版本进行了彻底的审查，结果做出了许多改进，包括增加了DCCP RFC的更新。
Author's Address
作者地址
David Black Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
David Black Dell EMC美国马萨诸塞州霍普金顿南街176号01748
Email: david.black@dell.com
Email: david.black@dell.com