Network Working Group S. Floyd
Request for Comments: 4774 ICIR
BCP: 124 November 2006
Category: Best Current Practice
Network Working Group S. Floyd
Request for Comments: 4774 ICIR
BCP: 124 November 2006
Category: Best Current Practice
Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
为显式拥塞通知（ECN）字段指定替代语义
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics.
对于IP报头RFC 3168中的显式拥塞通知（ECN）字段的替代语义，有许多建议。本文档讨论了为ECN字段定义替代语义时的一些问题，并指定了Internet中安全共存的要求，其中可能包括不理解已定义替代语义的路由器。本文档是与最近一项关于这种替代语义的建议的作者讨论的结果。
Table of Contents
目录
1. Introduction ....................................................2
2. An Overview of the Issues .......................................3
3. Signalling the Use of Alternate ECN Semantics ...................4
3.1. Using the Diffserv Field for Signalling ....................5
4. Issues of Incremental Deployment ................................6
4.1. Option 1: Unsafe for Deployment in the Internet ...........7
4.2. Option 2: Verification that Routers Understand the
Alternate ..................................................8
4.3. Option 3: Friendly Coexistence with Competing Traffic .....8
5. Evaluation of the Alternate ECN Semantics ......................10
5.1. Verification of Feedback from the Router ..................10
5.2. Coexistence with Competing Traffic ........................11
5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics ...12
5.4. Encapsulated Packets ......................................12
5.5. A General Evaluation of the Alternate ECN Semantics .......12
6. Security Considerations ........................................12
7. Conclusions ....................................................13
8. Acknowledgements ...............................................13
9. Normative References ...........................................13
10. Informative References ........................................13
1. Introduction ....................................................2
2. An Overview of the Issues .......................................3
3. Signalling the Use of Alternate ECN Semantics ...................4
3.1. Using the Diffserv Field for Signalling ....................5
4. Issues of Incremental Deployment ................................6
4.1. Option 1: Unsafe for Deployment in the Internet ...........7
4.2. Option 2: Verification that Routers Understand the
Alternate ..................................................8
4.3. Option 3: Friendly Coexistence with Competing Traffic .....8
5. Evaluation of the Alternate ECN Semantics ......................10
5.1. Verification of Feedback from the Router ..................10
5.2. Coexistence with Competing Traffic ........................11
5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics ...12
5.4. Encapsulated Packets ......................................12
5.5. A General Evaluation of the Alternate ECN Semantics .......12
6. Security Considerations ........................................12
7. Conclusions ....................................................13
8. Acknowledgements ...............................................13
9. Normative References ...........................................13
10. Informative References ........................................13
[RFC3168], a Proposed Standard document, defines the ECN field in the IP header, and specifies the semantics for the codepoints for the ECN field. However, end nodes could specify the use of alternate semantics for the ECN field, e.g., using codepoints in the diffserv field of the IP header.
[RFC3168]是一个建议的标准文档，它定义了IP头中的ECN字段，并指定了ECN字段的代码点的语义。然而，终端节点可以指定ECN字段的替代语义的使用，例如，使用IP报头的diffserv字段中的代码点。
There have been a number of proposals in the IETF and in the research community for alternate semantics for the ECN codepoint. One such proposal, [BCF05], proposes alternate ECN semantics for real-time inelastic traffic such as voice, video conferencing, and multimedia streaming in DiffServ networks. In this proposal, the alternate ECN semantics would provide information about two levels of congestion experienced along the path [BCF05]. Another research proposal, [XSSK05], proposes a low-complexity protocol, Variable-structure congestion Control Protocol (VCP), that uses the two bits in the ECN field to indicate low-load, high-load, and overload (congestion), where transport protocols can increase more rapidly during the low-load regime. Some of the proposals for alternate ECN semantics are for when ECN is used in an edge-to-edge context between gateways at the edge of a network region, e.g., for pre-congestion notification for admissions control [BESFC06]. Other proposals for alternate ECN semantics are listed on the ECN Web Page [ECN].
IETF和研究界已经提出了许多关于ECN代码点的替代语义的建议。其中一个方案[BCF05]提出了实时非弹性流量（如DiffServ网络中的语音、视频会议和多媒体流）的替代ECN语义。在该方案中，备用ECN语义将提供沿路径[BCF05]经历的两级拥塞的信息。另一项研究提案[XSSK05]提出了一种低复杂性协议，即可变结构拥塞控制协议（VCP），该协议使用ECN字段中的两个位来指示低负载、高负载和过载（拥塞），其中传输协议在低负载状态下可以更快地增加。关于备用ECN语义的一些建议适用于在网络区域边缘的网关之间的边到边上下文中使用ECN的情况，例如，用于准入控制的拥塞前通知[BESFC06]。ECN网页[ECN]上列出了其他关于替代ECN语义的建议。
The definition of multiple semantics for the ECN field could have significant implications on both host and router implementations. There is a huge base of installed hosts and routers in the Internet, and in other IP networks, and updating these is an enormous and potentially expensive undertaking. Some existing devices might be able to support the new ECN semantics with only a software upgrade and without significant degradation in performance. Some other equipment might be able to support the new semantics, but with a degradation in performance -- which could range from trivial to catastrophic. Some other deployed equipment might be able to support the new ECN semantics only with a hardware upgrade, which, in some cases, could be prohibitively expensive to deploy on a very wide scale. For these reasons, it would be difficult and would take a significant amount of time to universally deploy any new ECN semantics. In particular, routers can be difficult to upgrade, since small routers sometimes are not updated frequently, and large routers commonly have specialized forwarding paths to facilitate high performance.
ECN字段的多语义定义可能对主机和路由器实现都有重大影响。互联网和其他IP网络中有大量已安装的主机和路由器，更新这些主机和路由器是一项巨大且可能昂贵的任务。一些现有设备可能只需软件升级即可支持新的ECN语义，且性能不会显著下降。其他一些设备可能能够支持新的语义，但性能会下降——从微不足道到灾难性。其他一些部署的设备可能仅通过硬件升级就能够支持新的ECN语义，在某些情况下，大规模部署的成本可能会高得令人望而却步。由于这些原因，要普遍部署任何新的ECN语义都是困难的，而且需要花费大量的时间。特别是，路由器可能很难升级，因为小型路由器有时不经常更新，而大型路由器通常具有专用的转发路径以促进高性能。
This document describes some of the technical issues that arise in specifying alternate semantics for the ECN field, and gives requirements for a safe coexistence in a world using the default ECN semantics (or using no ECN at all).
本文档描述了在为ECN字段指定替代语义时出现的一些技术问题，并给出了在使用默认ECN语义（或根本不使用ECN）的世界中安全共存的要求。
In this section, we discuss some of the issues that arise if some of the traffic in a network consists of alternate-ECN traffic (i.e., traffic using alternate semantics for the ECN field). The issues include the following: (1) how routers know which ECN semantics to use with which packets; (2) incremental deployment in a network where some routers use only the default ECN semantics or do not use ECN at all; (3) coexistence of alternate-ECN traffic with competing traffic on the path; and (4) a general evaluation of the alternate ECN semantics.
在本节中，我们将讨论如果网络中的某些流量由备用ECN流量（即，使用ECN字段的备用语义的流量）组成时出现的一些问题。这些问题包括：（1）路由器如何知道哪些ECN语义用于哪些数据包；（2） 在某些路由器仅使用默认ECN语义或根本不使用ECN的网络中进行增量部署；（3） 交替ECN流量与路径上的竞争流量共存；（4）对备用ECN语义的一般评估。
(1) The first issue concerns how routers know which ECN semantics to use with which packets in the network:
(1) 第一个问题涉及路由器如何知道网络中的哪些数据包使用哪些ECN语义：
How does the connection indicate to the router that its packets are using alternate ECN semantics? Is the specification of alternate-ECN semantics robust and unambiguous? If not, is this a problem?
连接如何向路由器表明其数据包正在使用备用ECN语义？备用ECN语义的规范是否健壮且明确？如果不是，这是否一个问题？
As an example, in most of the proposals for alternate ECN semantics, a diffserv field is used to specify the use of alternate ECN semantics. Do all routers that understand this diffserv codepoint understand that it uses alternate ECN
例如，在大多数关于备用ECN语义的建议中，diffserv字段用于指定备用ECN语义的使用。所有了解此diffserv代码点的路由器都知道它使用备用ECN吗
semantics, or not? Diffserv allows routers to re-mark DiffServ Code Point (DSCP) values within the network; what is the effect of this on the alternate ECN semantics?
语义，还是不？Diffserv允许路由器在网络内重新标记Diffserv代码点（DSCP）值；这对备用ECN语义有什么影响？
This is discussed in more detail in Section 3 below.
下文第3节将对此进行更详细的讨论。
(2) A second issue is that of incremental deployment in a network where some routers only use the default ECN semantics, and other routers might not use ECN at all. In this document, we use the phrase "new routers" to refer to the routers that understand the alternate ECN semantics, and "old routers" to refer to routers that don't understand or aren't willing to use the alternate ECN semantics.
(2) 第二个问题是网络中的增量部署，其中一些路由器仅使用默认的ECN语义，而其他路由器可能根本不使用ECN。在本文档中，我们使用短语“新路由器”表示理解备用ECN语义的路由器，“旧路由器”表示不理解或不愿意使用备用ECN语义的路由器。
The possible existence of old routers raises the following question: How does the possible presence of old routers affect the performance of the alternate-ECN connections?
旧路由器的可能存在引发了以下问题：旧路由器的可能存在如何影响备用ECN连接的性能？
(3) The possible existence of old routers also raises the question of how the presence of old routers affects the coexistence of the alternate-ECN traffic with competing traffic on the path.
(3) 旧路由器的可能存在也提出了一个问题，即旧路由器的存在如何影响备用ECN流量与路径上竞争流量的共存。
Issues (2) and (3) are discussed in Section 4 below.
下文第4节讨论了问题（2）和（3）。
(4) A final issue is that of the general evaluation of the alternate ECN semantics:
(4) 最后一个问题是对备用ECN语义的一般评估：
How well does the alternate-ECN traffic perform, and how well does it coexist with competing traffic on the path, in a "clean" environment with new routers and with the unambiguous specification of the use of alternate ECN semantics?
在有新路由器的“干净”环境中，在使用备用ECN语义的明确规范下，备用ECN通信的性能如何，以及它与路径上的竞争通信共存的情况如何？
These issues are discussed in Section 5.
第5节讨论了这些问题。
This section discusses question (1) from Section 2:
本节讨论第2节中的问题（1）：
(1) How does the connection indicate to the router that its packets are using alternate ECN semantics? Is the specification of alternate ECN semantics robust and unambiguous? If not, is this a problem?
(1) 连接如何向路由器表明其数据包正在使用备用ECN语义？备用ECN语义的规范是否健壮且明确？如果不是，这是否一个问题？
The assumption of this document is that when alternate semantics are defined for the ECN field, a codepoint in the diffserv field is used to signal the use of these alternate ECN semantics to the router. That is, the end host sets the codepoint in the diffserv field to indicate to routers that alternate semantics to the ECN field are
本文档的假设是，当为ECN字段定义替代语义时，diffserv字段中的一个代码点用于向路由器发送使用这些替代ECN语义的信号。也就是说，终端主机在diffserv字段中设置代码点，以向路由器指示ECN字段的替代语义是
being used. Routers that understand this diffserv codepoint would know to use the alternate semantics for interpreting and setting the ECN field. Old ECN-capable routers that do not understand this diffserv codepoint would use the default ECN semantics in interpreting and setting the ECN field.
正在使用中。理解此diffserv代码点的路由器将知道使用替代语义来解释和设置ECN字段。不理解此diffserv代码点的支持ECN的旧路由器将在解释和设置ECN字段时使用默认ECN语义。
In general, the diffserv codepoints are used to signal the per-hop behavior at router queues. One possibility would be to use one diffserv codepoint to signal a per-hop behavior with the default ECN semantics, and a separate diffserv codepoint to signal a similar per-hop behavior with the alternate ECN semantics. Another possibility would be to use a diffserv codepoint to signal the use of best-effort per-hop queueing and scheduling behavior, but with alternate ECN semantics. A detailed discussion of these issues is beyond the scope of this document.
一般来说，diffserv码点用于在路由器队列中表示每跳行为。一种可能是使用一个diffserv代码点以默认ECN语义表示每跳行为，使用一个单独的diffserv代码点以备用ECN语义表示类似的每跳行为。另一种可能是使用diffserv代码点来表示使用了每跳最大努力排队和调度行为，但使用了其他ECN语义。对这些问题的详细讨论超出了本文件的范围。
We note that this discussion does not exclude the possibility of using other methods, including out-of-band mechanisms, for signalling the use of alternate semantics for the ECN field. The considerations in the rest of this document apply regardless of the method used to signal the use of alternate semantics for the ECN field.
我们注意到，本讨论并不排除使用其他方法（包括带外机制）来表示ECN字段使用替代语义的可能性。无论使用何种方法来表示ECN字段使用了替代语义，本文档其余部分中的注意事项都适用。
We note that the default ECN semantics defined in RFC 3168 are the current default semantics for the ECN field, regardless of the contents of any other fields in the IP header. In particular, the default ECN semantics apply for more than best-effort traffic with a codepoint of '000000' for the diffserv field - the default ECN semantics currently apply regardless of the contents of the diffserv field.
我们注意到，RFC 3168中定义的默认ECN语义是ECN字段的当前默认语义，与IP头中任何其他字段的内容无关。特别是，默认ECN语义适用于diffserv字段的代码点为“000000”的多个尽力而为的流量-无论diffserv字段的内容如何，默认ECN语义当前都适用。
There are two ways to use the diffserv field to signal the use of alternate ECN semantics. One way is to use an existing diffserv codepoint, and to modify the current definition of that codepoint, through approved IETF processes, to specify the use of alternate ECN semantics with that codepoint. A second way is to define a new diffserv codepoint, and to specify the use of alternate ECN semantics with that codepoint. We note that the first of these two mechanisms raises the possibility that some routers along the path will understand the diffserv codepoint but will use the default ECN semantics with this diffserv codepoint, or won't use ECN at all, and that other routers will use the alternate ECN semantics with this diffserv codepoint.
有两种方法可以使用diffserv字段来表示使用备用ECN语义。一种方法是使用现有的diffserv代码点，并通过批准的IETF流程修改该代码点的当前定义，以指定使用该代码点的备用ECN语义。第二种方法是定义一个新的diffserv代码点，并指定使用该代码点的备用ECN语义。我们注意到，这两种机制中的第一种机制提出了这样的可能性：路径上的一些路由器将理解diffserv代码点，但将使用默认ECN语义与此diffserv代码点，或者根本不使用ECN，而其他路由器将使用此diffserv代码点的备用ECN语义。
This section discusses questions (2) and (3) posed in Section 2:
本节讨论第2节中提出的问题（2）和（3）：
(2) How does the possible presence of old routers affect the performance of the alternate-ECN connections?
(2) 旧路由器的可能存在如何影响备用ECN连接的性能？
(3) How does the possible presence of old routers affect the coexistence of the alternate-ECN traffic with competing traffic on the path?
(3) 旧路由器的可能存在如何影响备用ECN流量与路径上竞争流量的共存？
When alternate semantics are defined for the ECN field, it is necessary to ensure that there are no problems caused by old routers along the path that don't understand the alternate ECN semantics.
当为ECN字段定义替代语义时，有必要确保路径上的旧路由器不理解替代ECN语义不会导致任何问题。
One possible problem is that of poor performance for the alternate-ECN traffic. Is it essential to the performance of the alternate-ECN traffic that all routers along the path understand the alternate ECN semantics? If not, what are the possible consequences, for the alternate-ECN traffic itself, when some old routers along the path don't understand the alternate ECN semantics? These issues have to be answered in the context of each specific proposal for alternate ECN semantics.
一个可能的问题是备用ECN流量的性能差。路径上的所有路由器都理解备用ECN语义，这对备用ECN流量的性能至关重要吗？如果不是，当路径上的一些旧路由器不理解备用ECN语义时，对于备用ECN流量本身，可能产生什么后果？这些问题必须在每一个关于替代ECN语义的具体建议的上下文中得到回答。
A second specific problem is that of possible unfair competition with other traffic along the path. If there is an old router along the path that doesn't use ECN, that old router could drop packets from the alternate-ECN traffic, and expect the alternate-ECN traffic to reduce its sending rate as a result. Does the alternate-ECN traffic respond to packet drops as an indication of congestion?
第二个具体问题是可能与道路沿线的其他交通进行不公平竞争。如果路径上有一个旧路由器不使用ECN，则该旧路由器可能会从备用ECN流量中丢弃数据包，并期望备用ECN流量因此降低其发送速率。备用ECN流量是否响应数据包丢弃，作为拥塞的指示？
|--------|
Alternate-ECN traffic ----> | | ---> CE-marked packet
| Old |
Non-ECN traffic ----------> | Router | ---> dropped packet
| |
RFC-3168 ECN traffic -----> | | ---> CE-marked packet
|--------|
|--------|
Alternate-ECN traffic ----> | | ---> CE-marked packet
| Old |
Non-ECN traffic ----------> | Router | ---> dropped packet
| |
RFC-3168 ECN traffic -----> | | ---> CE-marked packet
|--------|
Figure 1: Alternate-ECN traffic, an old router, using RFC-3168 ECN, that is congested and ready to drop or mark the arriving packet.
图1：备用ECN流量，一个旧路由器，使用RFC-3168 ECN，拥塞，准备丢弃或标记到达的数据包。
Similarly, what if there is an old router along the path that understands only the default ECN semantics from RFC 3168, as in Figure 1 above? In times of congestion, the old default-ECN router could see an alternate-ECN packet with one of the ECN-Capable Transport (ECT) codepoints set in the ECN field in the IP header, as defined in RFC 3168, and set the Congestion Experienced (CE)
类似地，如果路径上有一个只理解RFC3168中默认ECN语义的旧路由器（如上图1所示），该怎么办？在拥塞时，旧的默认ECN路由器可以看到一个备用ECN数据包，该数据包在IP报头的ECN字段中设置了一个支持ECN的传输（ECT）代码点，如RFC 3168中所定义，并设置所经历的拥塞（CE）
codepoint in the ECN field as an alternative to dropping the packet. The router in this case would expect the alternate-ECN connection to respond, in terms of congestion control, as it would if the packet has been dropped. If the alternate-ECN traffic fails to respond appropriately to the CE codepoint being set by an old router, this could increase the aggregate traffic arriving at the old router, resulting in an increase in the packet-marking and packet-dropping rates at that router, further resulting in the alternate-ECN traffic crowding out the other traffic competing for bandwidth on that link.
ECN字段中的代码点，作为丢弃数据包的替代方案。在这种情况下，路由器期望备用ECN连接在拥塞控制方面做出响应，就像丢包时一样。如果备用ECN通信量未能适当响应由旧路由器设置的CE码点，这可能会增加到达旧路由器的总通信量，导致该路由器上的分组标记和分组丢弃率增加，进一步导致备用ECN流量挤占了该链路上竞争带宽的其他流量。
Basically, there are three possibilities for avoiding scenarios where the presence of old routers along the path results in the alternate-ECN traffic competing unfairly with other traffic along the path:
基本上，有三种可能性可以避免路径上存在旧路由器导致备用ECN流量与路径上的其他流量不公平竞争的情况：
Option 1: Alternate-ECN traffic is clearly understood as unsafe for deployment in the global Internet; or
备选方案1：备用ECN流量显然不安全，无法在全球互联网上部署；或
Option 2: All alternate-ECN traffic deploys some mechanism for verifying that all routers on the path understand and agree to use the alternate ECN semantics for this traffic; or
选项2：所有备用ECN流量部署一些机制，用于验证路径上的所有路由器是否理解并同意对此流量使用备用ECN语义；或
Option 3: The alternate ECN semantics are defined in such a way as to ensure the fair and peaceful coexistence of the alternate-ECN traffic with best-effort and other traffic, even in environments that include old routers that do not understand the alternate ECN semantics.
选项3：备用ECN语义的定义应确保备用ECN通信与尽最大努力的其他通信公平和平共处，即使在包括不理解备用ECN语义的旧路由器的环境中也是如此。
Each of these alternatives is explored in more detail below.
下面将对每种备选方案进行更详细的探讨。
The first option specified above is for the alternate-ECN traffic to be clearly understood as only suitable for enclosed environments, and as unsafe for deployment in the global Internet. Specifically, this would mean that it would be unsafe for packets using the alternate ECN semantics to be unleashed in the global Internet. This restriction would prevent the alternate-ECN traffic from traversing an old router outside of the enclosed environment that didn't understand the alternate semantics. This document doesn't comment on whether a mechanism would be required to ensure that the alternate ECN semantics would not be let loose on the global Internet. This document also doesn't comment on the chances that this scenario would be considered acceptable for standardization by the IETF community.
上面指定的第一个选项是，将备用ECN通信清楚地理解为仅适用于封闭环境，并且对于在全球互联网中部署不安全。具体来说，这意味着在全球互联网上释放使用备用ECN语义的数据包是不安全的。此限制将防止备用ECN通信量在封闭环境之外穿越不理解备用语义的旧路由器。本文档没有评论是否需要一种机制来确保备用ECN语义不会在全球互联网上泄露。本文件也未对IETF社区认为该场景可接受标准化的可能性进行评论。
4.2. Option 2: Verification that Routers Understand the Alternate Semantics
4.2. 选项2：验证路由器是否理解备用语义
The second option specified above is for the alternate-ECN traffic to include a mechanism for ensuring that all routers along the path understand and agree to the use of the alternate ECN semantics for this traffic. As an example, such a mechanism could consist of a field in an IP option that all routers along the path decrement if they agree to use the alternate ECN semantics with this traffic. (A similar mechanism is proposed for Quick-Start, for verifying that all of the routers along the path understand the Quick-Start IP Option [QuickStart].) Using such a mechanism, a sender could have reasonable assurance that the packets that are sent specifying the use of alternate ECN semantics only traverse routers that, in fact, understand and agree to use these alternate semantics for these packets. Note, however, that most existing routers are optimized for IP packets with no options, or with only some very well-known and simple IP options. Thus, the definition and use of any new IP option may have a serious detrimental effect on the performance of many existing IP routers.
上面指定的第二个选项是，备用ECN流量包括一种机制，用于确保路径上的所有路由器理解并同意使用备用ECN语义来处理此流量。例如，这种机制可以由IP选项中的一个字段组成，如果路径上的所有路由器同意对该流量使用备用ECN语义，则该字段将递减。（提出了一种类似的快速启动机制，用于验证路径上的所有路由器是否理解快速启动IP选项[QuickStart]）使用这种机制，发送方可以合理地保证发送的指定使用备用ECN语义的数据包只会穿过实际上：，理解并同意对这些数据包使用这些替代语义。然而，请注意，大多数现有路由器都是针对IP数据包进行优化的，没有任何选项，或者只有一些非常知名和简单的IP选项。因此，任何新IP选项的定义和使用都可能对许多现有IP路由器的性能产生严重的不利影响。
Such a mechanism should be robust in the presence of paths with multi-path routing, and in the presence of routing or configuration changes along the path while the connection is in use. In particular, if this option is used, connections could include some form of monitoring for changes in path behavior and/or periodic monitoring that all routers along the path continue to understand the alternate ECN semantics.
这种机制在存在具有多路径路由的路径时，以及在使用连接时存在沿路径的路由或配置更改时，应该是健壮的。特别是，如果使用此选项，连接可能包括某种形式的路径行为变化监测和/或定期监测，以使路径上的所有路由器继续理解备用ECN语义。
The third option specified above is for the alternate ECN semantics to be defined so that traffic using the alternate semantics would coexist safely in the Internet on a path with one or more old routers that use only the default ECN semantics. In this scenario, a connection sending alternate-ECN traffic would have to respond appropriately to a CE packet (a packet with the ECN codepoint "11") received at the receiver, using a conformant congestion control response. Hopefully, the connection sending alternate-ECN traffic would also respond appropriately to a dropped packet, which could be a congestion indication from a router that doesn't use ECN.
上面指定的第三个选项是定义备用ECN语义，以便使用备用语义的流量可以在Internet上与仅使用默认ECN语义的一个或多个旧路由器的路径上安全共存。在这种情况下，发送备用ECN业务的连接必须使用一致的拥塞控制响应来适当地响应在接收器处接收的CE分组（具有ECN码点“11”的分组）。希望发送备用ECN流量的连接也能适当地响应丢弃的数据包，这可能是来自不使用ECN的路由器的拥塞指示。
RFC 3168 defines the default ECN semantics as follows:
RFC 3168将默认ECN语义定义如下：
"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
“对于ECN，传输端的拥塞控制算法必须与接收端的TCP*拥塞控制算法相同。对于ECN，传输端的拥塞控制算法必须与接收端的TCP*拥塞控制算法相同。”
required to halve its congestion window for any window of data containing either a packet drop or an ECN indication."
需要将包含丢包或ECN指示的任何数据窗口的拥塞窗口减半。”
The only conformant congestion control mechanisms currently standardized in the IETF are TCP [RFC2581] and protocols using TCP-like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 ([RFC4340], [RFC4341])), and TCP-Friendly Rate Control (TFRC) [RFC3448], and protocols with TFRC-like congestion control (e.g., DCCP using CCID-3 [RFC4342]). TCP uses Additive-Increase Multiplicative-Decrease congestion control, and responds to the loss or ECN-marking of a single packet by halving its congestion window. In contrast, the equation-based congestion control mechanism in TFRC estimates the loss event rate over some period of time, and uses a sending rate that would be comparable, in packets per round-trip-time, to that of a TCP connection experiencing the same loss event rate.
IETF中目前标准化的唯一一致的拥塞控制机制是TCP[RFC2581]和使用类似TCP的拥塞控制的协议（例如，SCTP[RFC2960]、带有CCID-2的DCCP（[RFC4340]、[RFC4341]）、TCP友好速率控制（TFRC）[RFC3448]，以及带有类似TFRC的拥塞控制的协议（例如，使用CCID-3的DCCP[RFC4342]）。TCP使用加性增加乘性减少拥塞控制，并通过将拥塞窗口减半来响应单个数据包的丢失或ECN标记。相比之下，TFRC中基于等式的拥塞控制机制估计某段时间内的丢失事件率，并使用与经历相同丢失事件率的TCP连接相当的发送速率（以每个往返时间的数据包为单位）。
So what are the requirements for alternate-ECN traffic to compete appropriately with other traffic on a path through an old router that doesn't understand the alternate ECN semantics (and therefore might be using the default ECN semantics)? The first and second requirements below concern compatibility between traffic using alternate ECN semantics and routers using default ECN semantics.
那么，对于备用ECN通信量，在通过不理解备用ECN语义（因此可能使用默认ECN语义）的旧路由器的路径上与其他通信量进行适当竞争，有什么要求呢？下面的第一个和第二个要求涉及使用备用ECN语义的流量与使用默认ECN语义的路由器之间的兼容性。
The first requirement for compatibility with routers using default ECN is that if a packet is marked with the ECN codepoint "11" in the network, this marking is not changed on the packet's way to the receiver (unless the packet is dropped before it reaches the receiver). This requirement is necessary to ensure that congestion indications from a default-ECN router make it to the transport receiver.
与使用默认ECN的路由器兼容的第一个要求是，如果数据包在网络中被标记为ECN代码点“11”，则该标记在数据包到达接收器的过程中不会改变（除非数据包在到达接收器之前被丢弃）。这一要求对于确保来自默认ECN路由器的拥塞指示到达传输接收器是必要的。
A second requirement for compatibility with routers using default ECN is that the end-nodes respond to packets that are marked with the ECN codepoint "11" in a way that is friendly to flows using IETF-conformant congestion control. This requirement is needed because the "11"-marked packets might have come from a congested router that understands only the default ECN semantics, and that expects that end-nodes will respond appropriately to CE packets. This requirement would ensure that the traffic using the alternate semantics does not `bully' competing traffic that it might encounter along the path, and that it does not drive up congestion on the shared link inappropriately.
与使用默认ECN的路由器兼容的第二个要求是，终端节点以一种对使用符合IETF的拥塞控制的流友好的方式响应标有ECN代码点“11”的数据包。之所以需要此要求，是因为标记为“11”的数据包可能来自拥塞的路由器，该路由器只理解默认的ECN语义，并且期望终端节点将适当地响应CE数据包。这一要求将确保使用替代语义的流量不会“欺负”路径上可能遇到的竞争流量，并且不会不适当地加剧共享链路上的拥塞。
Additional requirements concern compatibility between traffic using default ECN semantics and routers using alternate ECN semantics. This situation could occur if a diffserv codepoint using default ECN semantics is redefined to use alternate ECN semantics, and traffic
其他要求涉及使用默认ECN语义的流量和使用备用ECN语义的路由器之间的兼容性。如果使用默认ECN语义的diffserv代码点被重新定义为使用备用ECN语义，并且流量
from an "old" source traverses a "new" router. If the router "knows" that a packet is from a sender using alternate semantics (e.g., because the packet is using a certain diffserv codepoint, and all packets with that diffserv codepoint use alternate semantics for the ECN field), then the requirements below are not necessary, and the rules for the alternate semantics apply.
从“旧”源遍历“新”路由器。如果路由器“知道”某个数据包来自使用替代语义的发送方（例如，因为该数据包使用某个区分服务码点，且所有具有该区分服务码点的数据包使用ECN字段的替代语义），则不需要满足以下要求，且替代语义的规则适用。
A requirement for compatibility with end-nodes using default ECN is that if a packet that *could* be using default semantics is marked with the ECN codepoint "00", this marking must not be changed to "01", "10", or "11" in the network. This prevents the packet from being represented incorrectly to a default-ECN router downstream as ECN-Capable. Similarly, if a packet that *could* be using default semantics is marked with the ECN codepoint "01", then this codepoint should not be changed to "10" in the network (and a "10" codepoint should not be changed to "01"). This requirement is necessary to avoid interference with the transport protocol's use of the ECN nonce [RFC3540].
与使用默认ECN的终端节点的兼容性要求是，如果*可能*使用默认语义的数据包被标记为ECN代码点“00”，则该标记在网络中不得更改为“01”、“10”或“11”。这可以防止数据包被错误地表示为支持ECN的默认ECN路由器下游。类似地，如果*可能*使用默认语义的数据包被标记为ECN代码点“01”，则该代码点不应在网络中更改为“10”（并且“10”代码点不应更改为“01”）。这一要求对于避免干扰传输协议使用ECN nonce[RFC3540]是必要的。
As discussed earlier, the current conformant congestion control responses to a dropped or default-ECN-marked packet consist of TCP and TCP-like congestion control, and of TFRC (TCP-Friendly Rate Control). Another possible response considered in RFC 3714, but not standardized in a standards-track document, is that of simply terminating an alternate-ECN connection for a period of time if the long-term sending rate is higher than would be that of a TCP connection experiencing the same packet dropping or marking rates [RFC3714]. We note that the use of such a congestion control response to CE-marked packets would require specification of time constants for measuring the loss rates and for stopping transmission, and would require a consideration of issues of packet size.
如前所述，对丢弃或默认ECN标记的数据包的当前一致拥塞控制响应由TCP和类似TCP的拥塞控制以及TFRC（TCP友好速率控制）组成。RFC 3714中考虑的另一种可能的响应，但在标准跟踪文件中未标准化，是如果长期发送速率高于经历相同丢包或标记速率的TCP连接的速率，则简单地终止一段时间的备用ECN连接[RFC3714]。我们注意到，对CE标记的数据包使用这种拥塞控制响应需要指定时间常数来测量丢失率和停止传输，并且需要考虑数据包大小的问题。
This section discusses question (4) posed in Section 2:
本节讨论第2节中提出的问题（4）：
(4) How well does the alternate-ECN traffic perform, and how well does it coexist with competing traffic on the path, in a "clean" environment with new routers and with the unambiguous specification of the use of alternate ECN semantics?
(4) 在有新路由器的“干净”环境中，在使用备用ECN语义的明确规范下，备用ECN通信的性能如何，以及它与路径上的竞争通信共存的情况如何？
One issue in evaluating the alternate ECN semantics concerns mechanisms to discourage lying from the transport receiver to the transport sender. In many cases, the sender is a server that has an interest in using the alternate ECN semantics correctly, while the
评估备用ECN语义的一个问题涉及阻止传输接收方向传输发送方撒谎的机制。在许多情况下，发送方是对正确使用备用ECN语义感兴趣的服务器，而
receiver has more incentive to lie about the congestion experienced along the path.
接收者有更多的动机对沿途经历的拥堵撒谎。
In the default ECN semantics, two of the four ECN codepoints are used for ECN-Capable(0) and ECN-Capable(1). The use of two codepoints for ECN-Capable, instead of one, permits the data sender to verify the receiver's reports that packets were actually received unmarked at the receiver. In particular, the sender can specify that the receiver report to the sender whether each unmarked packet was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 3540 [RFC3540]. This use of ECN-Capable(0) and ECN-Capable(1) is independent of the semantics of the other ECN codepoints, and could be used, if desired, with alternate semantics for the other codepoints.
在默认ECN语义中，四个ECN代码点中的两个用于支持ECN（0）和支持ECN（1）。使用两个代码点（而不是一个）来支持ECN，允许数据发送方验证接收方的报告，即数据包实际上在接收方未标记地接收到。具体地，发送方可以指定接收方向发送方报告每个未标记的分组是接收到支持ECN（0）还是接收到支持ECN（1），如RFC 3540[RFC3540]中所述。支持ECN（0）和支持ECN（1）的使用独立于其他ECN代码点的语义，并且如果需要，可以与其他代码点的替代语义一起使用。
If alternate semantics for the ECN codepoint don't include the use of two separate codepoints to indicate ECN-Capable, then the connections using those semantics have lost the ability to verify that the data receiver is accurately reporting the received ECN codepoint to the data sender. In this case, it might be necessary for the alternate-ECN framework to include alternate mechanisms for ensuring that the data receiver is reporting feedback appropriately to the sender. As one possibility, policers could be used in routers to ensure that end nodes are responding appropriately to marked packets.
如果ECN代码点的替代语义不包括使用两个单独的代码点来指示ECN能力，则使用这些语义的连接已失去验证数据接收方是否向数据发送方准确报告接收到的ECN代码点的能力。在这种情况下，备用ECN框架可能需要包括备用机制，以确保数据接收方适当地向发送方报告反馈。作为一种可能性，可以在路由器中使用策略来确保终端节点正确响应标记的数据包。
A second general issue concerns the coexistence of alternate-ECN traffic with competing traffic along the path, in a clean environment where all routers understand and are willing to use the alternate ECN semantics for the traffic that specifies its use.
第二个一般性问题是，在一个干净的环境中，所有路由器都理解并愿意为指定其使用的流量使用备用ECN语义，备用ECN流量与路径上的竞争流量共存。
If the traffic using the alternate ECN semantics is best-effort traffic, then it is subject to the general requirement of fair competition with TCP and other traffic along the path [RFC2914].
如果使用备用ECN语义的通信量是尽力而为的通信量，则它受与TCP和路径上其他通信量公平竞争的一般要求的约束[RFC2914]。
If the traffic using the alternate ECN semantics is diffserv traffic, then the requirements are governed by the overall guidelines for that class of diffserv traffic. It is beyond the scope of this document to specify the requirements, if any, for the coexistence of diffserv traffic with other traffic on the link; this should be addressed in the specification of the diffserv codepoint itself.
如果使用备用ECN语义的流量是diffserv流量，则需求受该类diffserv流量的总体指导原则管辖。规定区分服务流量与链路上其他流量共存的要求（如有）超出了本文件的范围；这应该在diffserv代码点本身的规范中加以说明。
RFC 3168 specifies the use of the default ECN semantics by an end-to-end transport protocol, with the requirement that "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" ([RFC3168], Section 5). In contrast, some of the proposals for alternate ECN semantics are for ECN used in an edge-to-edge context between gateways at the edge of a network region, e.g., [BESFC06].
RFC 3168规定了端到端传输协议对默认ECN语义的使用，要求“在能够传输ECN的传输接收到单个CE数据包时，终端系统遵循的拥塞控制算法必须与对*单个*丢弃数据包的拥塞控制响应基本相同”([RFC3168]，第5节）。相比之下，关于备用ECN语义的一些建议适用于网络区域边缘网关之间的边到边上下文中使用的ECN，例如[BESFC06]。
When alternate ECN is defined with edge-to-edge semantics, this definition needs to ensure that the edge-to-edge semantics do not conflict with a connection using other ECN semantics end-to-end. One way to avoid conflict would be for the edge-to-edge ECN proposal to include some mechanism to ensure that the edge-to-edge ECN is not used for connections that are using other ECN semantics (standard or otherwise) end-to-end. Alternately, the edge-to-edge semantics could be defined so that they do not conflict with a connection using other ECN semantics end-to-end.
当使用边到边语义定义备用ECN时，此定义需要确保边到边语义不会与使用其他ECN语义的端到端连接冲突。避免冲突的一种方法是，边缘到边缘ECN建议包含一些机制，以确保边缘到边缘ECN不用于使用其他ECN语义（标准或其他）端到端的连接。或者，可以定义边到边语义，以便它们不会与使用其他ECN语义的端到端连接冲突。
RFC 3168 has an extensive discussion of the interactions between ECN and IP tunnels, including IPsec and IP in IP. Proposals for alternate ECN semantics might interact with IP tunnels differently than default ECN. As a result, proposals for alternate ECN semantics must explicitly consider the issue of interactions with IP tunnels.
RFC3168广泛讨论了ECN和IP隧道之间的交互，包括IPsec和IP中的IP。关于备用ECN语义的建议可能与IP隧道的交互方式不同于默认ECN。因此，替代ECN语义的建议必须明确地考虑与IP隧道的交互问题。
A third general issue concerns the evaluation of the general merits of the proposed alternate ECN semantics. Again, it would be beyond the scope of this document to specify requirements for the general evaluation of alternate ECN semantics.
第三个一般性问题涉及对所提出的备选ECN语义的一般优点的评估。同样，指定替代ECN语义的一般评估要求超出了本文档的范围。
This document doesn't propose any new mechanisms for the Internet protocol, and therefore doesn't introduce any new security considerations.
本文档没有为Internet协议提出任何新的机制，因此没有引入任何新的安全注意事项。
This document has discussed some of the issues to be considered in the specification of alternate semantics for the ECN field in the IP header.
本文讨论了IP报头中ECN字段的替代语义规范中需要考虑的一些问题。
Specifications of alternate ECN semantics must clearly state how they address the issues raised in this document, particularly the issues discussed in Section 2. In addition, specifications for alternate ECN semantics must meet the requirements in Section 5.2 for coexistence with competing traffic.
备用ECN语义规范必须明确说明如何解决本文档中提出的问题，特别是第2节中讨论的问题。此外，备用ECN语义规范必须满足第5.2节中关于与竞争流量共存的要求。
This document is based in part on conversations with Jozef Babiarz, Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate use of the ECN field in DiffServ environments. Many thanks to Francois Le Faucheur for feedback recommending that the document include a section at the beginning discussing the potential issues that need to be addressed. Thanks also to Mark Allman, Fred Baker, David Black, Gorry Fairhurst, and to members of the TSVWG working group for feedback on these issues.
本文件部分基于与Jozef Babiarz、郭浩灿和Victor Firoiu就在DiffServ环境中替代使用ECN字段的建议进行的对话。非常感谢Francois Le Faucheur的反馈意见，建议在文件开头包含一节，讨论需要解决的潜在问题。还要感谢马克·奥尔曼、弗雷德·贝克、大卫·布莱克、戈里·费尔赫斯特以及TSVWG工作组成员对这些问题的反馈。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[BCF05] Babiarz, J., Chan, K., and V. Firoiu, "Congestion Notification Process for Real-Time Traffic", Work in Progress, July 2005.
[BCF05]Babiarz，J.，Chan，K.，和V.Firoiu，“实时交通拥堵通知流程”，正在进行的工作，2005年7月。
[BESFC06] Briscoe, B., et al., "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region", Work in Progress, June 2006.
[BESFC06]Briscoe，B.，等人，“拥塞前通知的边到边部署模型：区分服务区域的准入控制”，正在进行的工作，2006年6月。
[ECN] ECN Web Page, URL <www.icir.org/floyd/ecn.html>.
[ECN]ECN网页，URL<www.icir.org/floyd/ECN.html>。
[QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, "Quick-Start for TCP and IP", Work in Progress, October 2006.
[QuickStart]S.Floyd、M.Allman、A.Jain和P.Sarolahti，“TCP和IP的快速启动”，正在进行的工作，2006年10月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]Floyd，S.和J.Kempf，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，RFC 43412006年3月。
[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, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman, One More Bit Is Enough, SIGCOMM 2005, September 2005.
[XSSK05]Y.Xia、L.Subramanian、I.Stoica和S.Kalyanaraman，《多一点就够了》，SIGCOMM 2005，2005年9月。
Author's Address
作者地址
Sally Floyd ICIR (ICSI Center for Internet Research)
Sally Floyd ICIR（ICSI互联网研究中心）
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。