Network Working Group A. Kuzmanovic
Request for Comments: 5562 A. Mondal
Category: Experimental Northwestern University
S. Floyd
ICSI
K. Ramakrishnan
AT&T Labs Research
June 2009
Network Working Group A. Kuzmanovic
Request for Comments: 5562 A. Mondal
Category: Experimental Northwestern University
S. Floyd
ICSI
K. Ramakrishnan
AT&T Labs Research
June 2009
Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets
向TCP的SYN/ACK数据包添加显式拥塞通知（ECN）功能
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.
本文件中的建议是实验性的。虽然它可以部署在当前的Internet上，但它并不代表这是在TCP SYN/ACK数据包中使用显式拥塞通知（ECN）的最佳可能机制的共识。
This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer).
本文档描述了对RFC 3168的可选实验性修改，以允许TCP SYN/ACK数据包支持ECN。对于TCP，RFC 3168指定在数据包上设置支持ECN的代码点，但不在SYN和SYN/ACK数据包上设置。然而，由于丢弃SYN/ACK数据包的TCP传输成本很高，导致重新传输超时，因此本文档描述了当响应在TCP报头中设置了两个ECN标志的SYN数据包发送时，对SYN/ACK数据包本身使用ECN的情况，这表示愿意使用ECN。将初始TCP SYN/ACK数据包设置为具有ECN功能的数据包对TCP连接有很大的好处，可以避免对尚未开始在网络上加载的连接造成重传超时的严重惩罚。TCP响应程序（SYN/ACK数据包的发送方）必须通过重新发送不支持ECN的SYN/ACK数据包来回复带有ECN标记的SYN/ACK数据包的报告。如果重新发送SYN/ACK数据包得到确认，则TCP响应程序将其初始拥塞窗口从两段、三段或四段减少到一段，从而减少网络上该连接的后续负载。相反，如果SYN/ACK数据包被丢弃，或者由于某些其他原因，TCP响应程序在指定的时间内没有收到确认，则TCP响应程序遵循丢弃的SYN/ACK数据包的TCP标准（设置重传计时器）。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Terminology .....................................5
3. Specification ...................................................6
3.1. SYN/ACK Packets Dropped in the Network ....................7
3.2. SYN/ACK Packets ECN-Marked in the Network .................8
3.3. Management Interface .....................................10
4. Discussion .....................................................11
4.1. Flooding Attacks .........................................11
4.2. The TCP SYN Packet .......................................11
4.3. SYN/ACK Packets and Packet Size ..........................12
4.4. Response to ECN-Marking of SYN/ACK Packets ...............12
5. Related Work ...................................................14
6. Performance Evaluation .........................................15
6.1. The Costs and Benefits of Adding ECN-Capability ..........15
6.2. An Evaluation of Different Responses to ECN-Marked
SYN/ACK Packets ..........................................16
6.3. Experiments ..............................................17
7. Security Considerations ........................................18
7.1. "Bad" Routers or Middleboxes .............................18
7.2. Congestion Collapse ......................................18
8. Conclusions ....................................................19
9. Acknowledgements ...............................................19
Appendix A. Report on Simulations .................................20
A.1. Simulations with RED in Packet Mode .......................20
A.2. Simulations with RED in Byte Mode .........................25
Appendix B. Issues of Incremental Deployment ......................28
Normative References ..............................................30
Informative References ............................................30
1. Introduction ....................................................3
2. Conventions and Terminology .....................................5
3. Specification ...................................................6
3.1. SYN/ACK Packets Dropped in the Network ....................7
3.2. SYN/ACK Packets ECN-Marked in the Network .................8
3.3. Management Interface .....................................10
4. Discussion .....................................................11
4.1. Flooding Attacks .........................................11
4.2. The TCP SYN Packet .......................................11
4.3. SYN/ACK Packets and Packet Size ..........................12
4.4. Response to ECN-Marking of SYN/ACK Packets ...............12
5. Related Work ...................................................14
6. Performance Evaluation .........................................15
6.1. The Costs and Benefits of Adding ECN-Capability ..........15
6.2. An Evaluation of Different Responses to ECN-Marked
SYN/ACK Packets ..........................................16
6.3. Experiments ..............................................17
7. Security Considerations ........................................18
7.1. "Bad" Routers or Middleboxes .............................18
7.2. Congestion Collapse ......................................18
8. Conclusions ....................................................19
9. Acknowledgements ...............................................19
Appendix A. Report on Simulations .................................20
A.1. Simulations with RED in Packet Mode .......................20
A.2. Simulations with RED in Byte Mode .........................25
Appendix B. Issues of Incremental Deployment ......................28
Normative References ..............................................30
Informative References ............................................30
TCP's congestion control mechanism has primarily used packet loss as the congestion indication, with packets dropped when buffers overflow. With such tail-drop mechanisms, the packet delay can be high, as the queue at bottleneck routers can be fairly large. Dropping packets only when the queue overflows, and having TCP react only to such losses, results in:
TCP的拥塞控制机制主要使用丢包作为拥塞指示，当缓冲区溢出时丢包。使用这种尾部丢弃机制，数据包延迟可能很高，因为瓶颈路由器上的队列可能相当大。仅当队列溢出时丢弃数据包，并且让TCP仅对此类丢失作出反应，会导致：
1) significantly higher packet delay;
1) 显著更高的数据包延迟；
2) unnecessarily many packet losses; and
2) 不必要的大量数据包丢失；和
3) unfairness due to synchronization effects.
3) 同步效应导致的不公平。
The adoption of Active Queue Management (AQM) mechanisms allows better control of bottleneck queues [RFC2309]. This use of AQM has the following potential benefits:
采用主动队列管理（AQM）机制可以更好地控制瓶颈队列[RFC2309]。使用AQM有以下潜在好处：
1) better control of the queue, with reduced queuing delay;
1) 更好地控制队列，减少排队延迟；
2) fewer packet drops; and
2) 更少的丢包；和
3) better fairness because of fewer synchronization effects.
3) 由于同步效果较少，因此具有更好的公平性。
With the adoption of ECN, performance may be further improved. When the router detects congestion before buffer overflow, the router can provide a congestion indication either by dropping a packet or by setting the Congestion Experienced (CE) codepoint in the Explicit Congestion Notification (ECN) field in the IP header [RFC3168]. The IETF has standardized the use of the Congestion Experienced (CE) codepoint in the IP header for routers to indicate congestion. For incremental deployment and backwards compatibility, the RFC on ECN [RFC3168] specifies that routers may mark ECN-Capable packets that would otherwise have been dropped, using the Congestion Experienced codepoint in the ECN field. The use of ECN allows TCP to react to congestion while avoiding unnecessary retransmission timeouts. Thus, using ECN has several benefits:
随着ECN的采用，性能可能会进一步提高。当路由器在缓冲区溢出之前检测到拥塞时，路由器可以通过丢弃数据包或在IP报头[RFC3168]的显式拥塞通知（ECN）字段中设置拥塞经历（CE）码点来提供拥塞指示。IETF标准化了路由器IP报头中拥塞体验（CE）码点的使用，以指示拥塞。对于增量部署和向后兼容性，ECN[RFC3168]上的RFC指定路由器可以使用ECN字段中的拥塞经历码点标记原本会丢弃的支持ECN的数据包。ECN的使用允许TCP对拥塞做出反应，同时避免不必要的重传超时。因此，使用ECN有几个好处：
1) For short transfers, a TCP connection's congestion window may be small. For example, if the current window contains only one packet, and that packet is dropped, TCP will have to wait for a retransmission timeout to recover, reducing its overall throughput. Similarly, if the current window contains only a few packets and one of those packets is dropped, there might not be enough duplicate acknowledgements for a fast retransmission, and the sender of the data packet might have to wait for a delay of several round-trip times (RTT) using Limited Transmit [RFC3042]. With the use of ECN, short flows are less likely to have packets dropped, sometimes avoiding unnecessary delays or costly retransmission timeouts.
1) 对于短传输，TCP连接的拥塞窗口可能很小。例如，如果当前窗口仅包含一个数据包，并且该数据包被丢弃，TCP将不得不等待重传超时恢复，从而降低其总体吞吐量。类似地，如果当前窗口仅包含几个数据包，并且其中一个数据包被丢弃，则可能没有足够的重复确认用于快速重传，并且数据包的发送方可能必须使用有限的传输[RFC3042]等待几次往返时间（RTT）的延迟。通过使用ECN，短流丢弃数据包的可能性较小，有时可以避免不必要的延迟或代价高昂的重新传输超时。
2) While longer flows may not see substantially improved throughput with the use of ECN, they may experience lower loss. This may benefit TCP applications that are latency- and loss-sensitive, because of the avoidance of retransmissions.
2) 虽然使用ECN时，较长的流可能不会显著提高吞吐量，但它们可能会经历较低的损失。这可能有利于对延迟和丢失敏感的TCP应用程序，因为可以避免重传。
RFC 3168 [RFC3168] specifies setting the ECN-Capable codepoint on TCP data packets, but not on TCP SYN and SYN/ACK packets. RFC 3168 [RFC3168] specifies the negotiation of the use of ECN between the two TCP endpoints in the TCP SYN and SYN-ACK exchange, using flags in the TCP header. Erring on the side of being conservative, RFC 3168 [RFC3168] does not specify the use of ECN for the first SYN/ACK
RFC 3168[RFC3168]指定在TCP数据包上设置支持ECN的代码点，但不在TCP SYN和SYN/ACK数据包上设置。RFC 3168[RFC3168]使用TCP报头中的标志指定TCP SYN和SYN-ACK交换中两个TCP端点之间使用ECN的协商。出于保守的考虑，RFC 3168[RFC3168]没有为第一个SYN/ACK指定ECN的使用
packet itself. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document specifies the use of ECN for the SYN/ACK packet itself. This can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK packet, and by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network.
包本身。然而，由于丢弃SYN/ACK数据包的TCP传输成本很高，导致重新传输超时，因此本文档规定了对SYN/ACK数据包本身使用ECN。这对TCP连接非常有益，避免了对尚未开始在网络上加载的连接重新传输超时的严重惩罚。SYN/ACK数据包的发送方必须通过发送不支持ECN的SYN/ACK数据包，并通过将其初始拥塞窗口从两段、三段或四段减少到一段，来响应带有ECN标记的SYN/ACK数据包（在IP报头的ECN字段中设置了CE码点的SYN/ACK数据包）的报告，减少网络上该连接的后续负载。
The use of ECN for SYN/ACK packets has the following potential benefits:
将ECN用于SYN/ACK数据包具有以下潜在好处：
1) Avoidance of a retransmission timeout;
1) 避免重传超时；
2) Improvement in the throughput of short connections.
2) 提高短连接的吞吐量。
This document specifies a modification to RFC 3168 [RFC3168] to allow TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the specification of the change, while Section 4 discusses some of the issues, and Section 5 discusses related work. Section 6 contains an evaluation of the specified change.
本文件规定了对RFC 3168[RFC3168]的修改，以允许TCP SYN/ACK数据包支持ECN。第3节包含变更规范，第4节讨论一些问题，第5节讨论相关工作。第6节包含对指定变更的评估。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
We use the following terminology from RFC 3168 [RFC3168]:
我们使用RFC 3168[RFC3168]中的以下术语：
The ECN field in the IP header:
IP标头中的ECN字段：
o CE: the Congestion Experienced codepoint; and
o CE：拥塞经历的码点；和
o ECT: either one of the two ECN-Capable Transport codepoints.
o ECT：两个支持ECN的传输代码点之一。
The ECN flags in the TCP header:
TCP标头中的ECN标志：
o CWR: the Congestion Window Reduced flag; and
o CWR：拥塞窗口减少标志；和
o ECE: the ECN-Echo flag.
o ECE：ECN回波标志。
ECN-setup packets:
ECN设置数据包：
o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags;
o ECN设置SYN包：带有ECE和CWR标志的SYN包；
o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR.
o ECN设置SYN-ACK数据包：具有ECE但不具有CWR的SYN-ACK数据包。
In this document, we use the terms "initiator" and "responder" to refer to the sender of the SYN packet and of the SYN-ACK packet, respectively.
在本文档中，我们使用术语“发起方”和“响应方”分别指SYN数据包和SYN-ACK数据包的发送方。
This section specifies the modification to RFC 3168 [RFC3168] to allow TCP SYN/ACK packets to be ECN-Capable.
本节规定了对RFC 3168[RFC3168]的修改，以允许TCP SYN/ACK数据包支持ECN。
Section 6.1.1 of RFC 3168 [RFC3168] states that "A host MUST NOT set ECT on SYN or SYN-ACK packets". In this section, we specify that a TCP node may respond to an initial ECN-setup SYN packet by setting ECT in the responding ECN-setup SYN/ACK packet, indicating to routers that the SYN/ACK packet is ECN-Capable. This allows a congested router along the path to mark the packet instead of dropping the packet as an indication of congestion.
RFC 3168[RFC3168]第6.1.1节规定“主机不得在SYN或SYN-ACK数据包上设置ECT”。在本节中，我们指定TCP节点可以通过在响应的ECN设置SYN/ACK数据包中设置ECT来响应初始ECN设置SYN数据包，从而向路由器指示SYN/ACK数据包具有ECN能力。这允许拥塞路由器沿着路径标记数据包，而不是丢弃数据包作为拥塞指示。
Assume that TCP node A transmits to TCP node B an ECN-setup SYN packet, indicating willingness to use ECN for this connection. As specified by RFC 3168 [RFC3168], if TCP node B is willing to use ECN, node B responds with an ECN-setup SYN-ACK packet.
假设TCP节点A向TCP节点B发送一个ECN setup SYN数据包，表示愿意为此连接使用ECN。按照RFC 3168[RFC3168]的规定，如果TCP节点B愿意使用ECN，则节点B将使用ECN setup SYN-ACK数据包进行响应。
Figure 1 shows an interchange with the SYN/ACK packet dropped by a congested router. Node B waits for a retransmission timeout, and then retransmits the SYN/ACK packet.
图1显示了与拥塞路由器丢弃的SYN/ACK数据包的交换。节点B等待重新传输超时，然后重新传输SYN/ACK数据包。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, possibly ECT
3-second timer set
SYN/ACK dropped .
.
.
3-second timer expires
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK
Data/ACK --->
Data/ACK --->
<--- Data (one to four segments)
---------------------------------------------------------------
<--- ECN-setup SYN/ACK, possibly ECT
3-second timer set
SYN/ACK dropped .
.
.
3-second timer expires
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK
Data/ACK --->
Data/ACK --->
<--- Data (one to four segments)
---------------------------------------------------------------
Figure 1: SYN exchange with the SYN/ACK packet dropped
图1：丢弃SYN/ACK数据包的SYN交换
If the SYN/ACK packet is dropped in the network, the responder (node B) responds by waiting three seconds for the retransmission timer to expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is dropped, the responder should resend the SYN/ACK packet without the ECN-Capable codepoint. (Although we are not aware of any middleboxes that drop SYN/ACK packets that contain an ECN-Capable codepoint in the IP header, we have learned to design our protocols defensively in this regard [RFC3360].)
如果SYN/ACK数据包在网络中被丢弃，响应程序（节点B）将等待三秒，等待重传计时器过期[RFC2988]。如果带有ECT码点的SYN/ACK数据包被丢弃，响应者应重新发送不带ECN码点的SYN/ACK数据包。（虽然我们不知道有任何中间盒丢弃在IP报头中包含支持ECN的代码点的SYN/ACK数据包，但我们已经学会了在这方面设计防御协议[RFC3360]。）
We note that if syn-cookies were used by the responder (node B) in the exchange in Figure 1, the responder wouldn't set a timer upon transmission of the SYN/ACK packet [SYN-COOK] [RFC4987]. In this case, if the SYN/ACK packet was lost, the initiator (node A) would have to timeout and retransmit the SYN packet in order to trigger another SYN-ACK.
我们注意到，如果syn Cookie由图1中交换中的响应者（节点B）使用，响应者在传输syn/ACK数据包[syn-COOK][RFC4987]时不会设置计时器。在这种情况下，如果SYN/ACK数据包丢失，则发起方（节点A）必须超时并重新传输SYN数据包，以便触发另一个SYN-ACK。
Figure 2 shows an interchange with the SYN/ACK packet sent as ECN-Capable, and ECN-marked instead of dropped at the congested router. This document specifies ECN+/TryOnce, which differs from the original proposal for ECN+ in [ECN+]; with ECN+/TryOnce, if the TCP responder is informed that the SYN/ACK was ECN-marked, the TCP responder immediately sends a SYN/ACK packet that is not ECN-Capable. The TCP responder is only allowed to send data packets after the TCP initiator reports the receipt of a SYN/ACK packet that is not ECN-marked.
图2显示了与SYN/ACK数据包的交换，SYN/ACK数据包被发送为支持ECN，ECN被标记而不是丢弃在拥塞的路由器上。本文件规定了ECN+/TryOnce，这与[ECN+]中ECN+的原始提案不同；使用ECN+/TryOnce，如果TCP响应程序被告知SYN/ACK已标记为ECN，则TCP响应程序立即发送不支持ECN的SYN/ACK数据包。TCP响应程序仅允许在TCP启动器报告收到未标记ECN的SYN/ACK数据包后发送数据包。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT
3-second timer set
<--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE
<--- ECN-setup SYN/ACK, ECT
3-second timer set
<--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE
ACK, ECN-Echo --->
ACK, ECN-Echo --->
Window reduced to one segment.
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK
ACK, ECN-Echo --->
ACK, ECN-Echo --->
Window reduced to one segment.
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK
Data/ACK, ECT --->
Data/ACK, ECT --->
<--- Data, ECT (one segment only)
---------------------------------------------------------------
Data/ACK, ECT --->
Data/ACK, ECT --->
<--- Data, ECT (one segment only)
---------------------------------------------------------------
Figure 2: SYN exchange with the SYN/ACK packet marked -
ECN+/TryOnce
Figure 2: SYN exchange with the SYN/ACK packet marked -
ECN+/TryOnce
If the initiator (node A) receives a SYN/ACK packet that has been ECN-marked by the congested router, with the CE codepoint set, the initiator restarts the retransmission timer. The initiator responds to the ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the TCP header of the responding ACK packet. The initiator uses the standard rules in setting the cumulative acknowledgement field in the responding ACK packet.
如果启动器（节点A）接收到已由拥塞路由器ECN标记的SYN/ACK数据包，并且设置了CE码点，则启动器重新启动重传计时器。启动器通过在响应的ACK数据包的TCP报头中设置ECN Echo标志来响应ECN标记的SYN/ACK数据包。发起方使用标准规则设置响应ACK数据包中的累积确认字段。
The initiator does not advance from the "SYN-Sent" to the "Established" state until it receives a SYN/ACK packet that is not ECN-marked.
在收到未标记ECN的SYN/ACK数据包之前，启动器不会从“已发送SYN”状态前进到“已建立”状态。
When the responder (node B) receives the ECN-Echo packet reporting the Congestion Experienced indication in the SYN/ACK packet, the responder sets the initial congestion window to one segment, instead of two segments as allowed by [RFC2581], or three or four segments allowed by [RFC3390]. As illustrated in Figure 2, if the responder (node B) receives an ECN-Echo packet informing it of a Congestion Experienced indication on its SYN/ACK packet, the responder sends a SYN/ACK packet that is not ECN-Capable, in addition to setting the initial window to one segment. The responder does not advance the send sequence number. The responder also sets the retransmission timer. The responder follows RFC 2988 [RFC2988] in setting the RTO (retransmission timeout).
当响应者（节点B）接收到报告SYN/ACK数据包中的拥塞经历指示的ECN回波数据包时，响应者将初始拥塞窗口设置为一个数据段，而不是[RFC2581]允许的两个数据段，或[RFC3390]允许的三个或四个数据段。如图2所示，如果响应者（节点B）接收到ECN回波数据包，通知其SYN/ACK数据包上出现拥塞指示，则响应者除了将初始窗口设置为一个段外，还发送不支持ECN的SYN/ACK数据包。响应程序不提前发送序列号。应答器还设置重传计时器。响应程序按照RFC 2988[RFC2988]设置RTO（重传超时）。
The TCP hosts follow the standard specification for the response to duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793 [RFC793]).
TCP主机遵循重复SYN/ACK数据包响应的标准规范（例如，RFC 793[RFC793]第3.4节）。
We note that the mechanism in this document differs from RFC 3168 [RFC3168], which specifies that "the sending TCP MUST restart the retransmission timer on receiving the ECN-Echo packet when the congestion window is one". RFC 3168 [RFC3168] does not allow SYN/ACK packets to be ECN-Capable. RFC 3168 [RFC3168] specifies that in response to an ECN-Echo packet, the TCP responder also sets the CWR flag in the TCP header of the next data packet sent, to acknowledge its receipt of and reaction to the ECN-Echo flag. In contrast, in response to an ECN-Echo packet acknowledging the receipt of an ECN-Capable SYN/ACK packet, the TCP responder doesn't set the CWR flag, but simply sends a SYN/ACK packet that is not ECN-Capable. On receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator clears the ECN-Echo flag on replying packets.
我们注意到，本文中的机制不同于RFC 3168[RFC3168]，RFC 3168[RFC3168]规定“当拥塞窗口为1时，发送TCP必须在接收ECN回波数据包时重新启动重传计时器”。RFC 3168[RFC3168]不允许SYN/ACK数据包支持ECN。RFC 3168[RFC3168]规定，为了响应ECN回波数据包，TCP响应程序还将在发送的下一个数据包的TCP报头中设置CWR标志，以确认其接收到ECN回波标志并对其作出反应。相反，为了响应ECN Echo数据包确认接收到支持ECN的SYN/ACK数据包，TCP响应程序不设置CWR标志，只发送不支持ECN的SYN/ACK数据包。在接收到不支持ECN的SYN/ACK数据包时，TCP启动器清除应答数据包上的ECN Echo标志。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT
<--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE
<--- ECN-setup SYN/ACK, ECT
<--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE
ACK, ECN-Echo --->
ACK, ECN-Echo --->
Window reduced to one segment.
ACK, ECN-Echo --->
ACK, ECN-Echo --->
Window reduced to one segment.
<--- ECN-setup SYN/ACK, not ECT
3-second timer set
SYN/ACK dropped .
.
.
3-second timer expires
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK, not ECT
Data/ACK, ECT --->
Data/ACK, ECT --->
<--- Data, ECT (one segment only)
---------------------------------------------------------------
<--- ECN-setup SYN/ACK, not ECT
3-second timer set
SYN/ACK dropped .
.
.
3-second timer expires
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK, not ECT
Data/ACK, ECT --->
Data/ACK, ECT --->
<--- Data, ECT (one segment only)
---------------------------------------------------------------
Figure 3: SYN exchange with the first SYN/ACK packet marked
and the second SYN/ACK packet dropped - ECN+/TryOnce
Figure 3: SYN exchange with the first SYN/ACK packet marked
and the second SYN/ACK packet dropped - ECN+/TryOnce
In contrast to Figure 2, Figure 3 shows an interchange where the first SYN/ACK packet is ECN-marked and the second SYN/ACK packet is dropped in the network. As in Figure 2, the TCP responder sets a timer when the second SYN/ACK packet is sent. Figure 3 shows that if the timer expires before the TCP responder receives an acknowledgement for the other end, the TCP responder resends the SYN/ACK packet, following the TCP standards.
与图2相反，图3显示了一个交换，其中第一个SYN/ACK数据包被ECN标记，第二个SYN/ACK数据包被丢弃在网络中。如图2所示，TCP响应程序在发送第二个SYN/ACK数据包时设置计时器。图3显示，如果在TCP响应程序接收到另一端的确认之前计时器过期，TCP响应程序将按照TCP标准重新发送SYN/ACK数据包。
The TCP implementation using ECN-Capable SYN/ACK packets should include a management interface to allow the use of ECN to be turned off for SYN/ACK packets. This is to deal with possible backwards compatibility problems such as those discussed in Appendix B.
使用支持ECN的SYN/ACK数据包的TCP实现应包括一个管理接口，以允许对SYN/ACK数据包关闭ECN的使用。这是为了处理可能的向后兼容性问题，如附录B中讨论的问题。
The rationale for the specification in this document is the following. When node B receives a TCP SYN packet with ECN-Echo bit set in the TCP header, this indicates that node A is ECN-Capable. If node B is also ECN-Capable, there are no obstacles to immediately setting one of the ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK packet.
本文件中规范的基本原理如下。当节点B接收到TCP头中设置了ECN回显位的TCP SYN数据包时，这表示节点a支持ECN。如果节点B也支持ECN，则在响应TCP SYN/ACK数据包的IP报头中立即设置一个支持ECN的代码点不会有任何障碍。
There can be a great benefit in setting an ECN-Capable codepoint in SYN/ACK packets, as is discussed further in [ECN+], and reported briefly in Section 5 below. Congestion is most likely to occur in the server-to-client direction. As a result, setting an ECN-Capable codepoint in SYN/ACK packets can reduce the occurrence of three-second retransmission timeouts resulting from the drop of SYN/ACK packets.
在SYN/ACK数据包中设置支持ECN的代码点会有很大的好处，如[ECN+]中进一步讨论的，并在下面的第5节中简要报告。拥塞最有可能发生在服务器到客户端的方向。因此，在SYN/ACK分组中设置支持ECN的码点可以减少由于SYN/ACK分组的丢弃而导致的三秒重传超时的发生。
Setting an ECN-Capable codepoint in the responding TCP SYN/ACK packets does not raise any new or additional security vulnerabilities. For example, provoking servers or hosts to send SYN/ACK packets to a third party in order to perform a "SYN/ACK flood" attack would be highly inefficient. Third parties would immediately drop such packets, since they would know that they didn't generate the TCP SYN packets in the first place. Moreover, such SYN/ACK attacks would have the same signatures as the existing TCP SYN attacks. Provoking servers or hosts to reply with SYN/ACK packets in order to congest a certain link would also be highly inefficient because SYN/ACK packets are small in size.
在响应的TCP SYN/ACK数据包中设置支持ECN的代码点不会引发任何新的或额外的安全漏洞。例如，激发服务器或主机向第三方发送SYN/ACK数据包以执行“SYN/ACK洪水”攻击将是非常低效的。第三方会立即丢弃这样的数据包，因为他们知道他们最初并没有生成TCP SYN数据包。此外，此类SYN/ACK攻击将具有与现有TCP SYN攻击相同的特征码。激发服务器或主机使用SYN/ACK数据包进行应答以阻塞特定链路也将是非常低效的，因为SYN/ACK数据包的大小很小。
However, the addition of ECN-Capability to SYN/ACK packets could allow SYN/ACK packets to persist for more hops along a network path before being dropped, thus adding somewhat to the ability of a SYN/ACK attack to flood a network link.
然而，将ECN能力添加到SYN/ACK数据包可允许SYN/ACK数据包在丢弃之前沿网络路径持续更多跳数，从而在一定程度上增加SYN/ACK攻击淹没网络链路的能力。
There are several reasons why an ECN-Capable codepoint must not be set in the IP header of the initiating TCP SYN packet. First, when the TCP SYN packet is sent, there are no guarantees that the other TCP endpoint (node B in Figure 2) is ECN-Capable, or that it would be able to understand and react if the ECN CE codepoint was set by a congested router.
为什么不能在启动TCP SYN数据包的IP报头中设置支持ECN的代码点，有几个原因。首先，当发送TCP SYN数据包时，无法保证另一个TCP端点（图2中的节点B）具有ECN能力，或者如果ECN CE码点是由拥塞的路由器设置的，则无法保证它能够理解并做出反应。
Second, the ECN-Capable codepoint in TCP SYN packets could be misused by malicious clients to "improve" the well-known TCP SYN attack. By setting an ECN-Capable codepoint in TCP SYN packets, a malicious host might be able to inject a large number of TCP SYN packets through a potentially congested ECN-enabled router, congesting it even further.
其次，TCP SYN数据包中支持ECN的代码点可能被恶意客户端滥用，以“改进”众所周知的TCP SYN攻击。通过在TCP SYN数据包中设置支持ECN的代码点，恶意主机可能能够通过可能拥塞的启用ECN的路由器注入大量TCP SYN数据包，从而进一步拥塞路由器。
For both these reasons, we continue the restriction that the TCP SYN packet must not have the ECN-Capable codepoint in the IP header set.
出于这两个原因，我们继续限制TCP SYN数据包在IP头集中不能有支持ECN的代码点。
There are a number of router buffer architectures that have smaller dropping rates for small (SYN) packets than for large (data) packets. For example, for a Drop-Tail queue in units of packets, where each packet takes a single slot in the buffer regardless of packet size, small and large packets are equally likely to be dropped. However, for a Drop-Tail queue in units of bytes, small packets are less likely to be dropped than are large ones. Similarly, for Random Early Detection (RED) in packet mode, small and large packets are equally likely to be dropped or marked, while for RED in byte mode, a packet's chance of being dropped or marked is proportional to the packet size in bytes.
有许多路由器缓冲区体系结构对小（SYN）数据包的丢弃率小于对大（数据）数据包的丢弃率。例如，对于以数据包为单位的丢弃尾队列，其中每个数据包在缓冲区中占用单个时隙，而不管数据包大小，小数据包和大数据包被丢弃的可能性相同。然而，对于以字节为单位的丢弃尾队列，小数据包比大数据包更不可能被丢弃。类似地，对于数据包模式下的随机早期检测（RED），大小数据包被丢弃或标记的可能性相同，而对于字节模式下的RED，数据包被丢弃或标记的可能性与数据包大小（以字节为单位）成正比。
For a congested router with an AQM mechanism in byte mode, where a packet's chance of being dropped or marked is proportional to the packet size in bytes, the drop or marking rate for TCP SYN/ACK packets should generally be low. In this case, the benefit of making SYN/ACK packets ECN-Capable should be similarly moderate. However, for a congested router with a Drop-Tail queue in units of packets or with an AQM mechanism in packet mode, and with no priority queuing for smaller packets, small and large packets should have the same probability of being dropped or marked. In such a case, making SYN/ACK packets ECN-Capable should be of significant benefit.
对于在字节模式下具有AQM机制的拥塞路由器，其中数据包被丢弃或标记的机会与数据包大小（以字节为单位）成比例，TCP SYN/ACK数据包的丢弃或标记率通常应较低。在这种情况下，使SYN/ACK数据包具有ECN能力的好处应该同样适度。然而，对于以分组为单位具有丢弃尾队列或以分组模式具有AQM机制且对于较小分组没有优先级队列的拥塞路由器，小分组和大分组应当具有相同的丢弃或标记概率。在这种情况下，使SYN/ACK数据包具有ECN能力应该是非常有益的。
We believe that there are a wide range of behaviors in the real world in terms of the drop or mark behavior at routers as a function of packet size (see Section 10 of [Tools]). We note that all of these alternatives listed above are available in the NS simulator (Drop-Tail queues are by default in units of packets, while the default for RED queue management has been changed from packet mode to byte mode).
我们相信，在现实世界中，路由器上的丢弃或标记行为作为数据包大小的函数，存在着广泛的行为（参见[Tools]第10节）。我们注意到，上面列出的所有替代方案都可以在NS模拟器中使用（默认情况下，掉尾队列以数据包为单位，而红色队列管理的默认值已从数据包模式更改为字节模式）。
One question is why TCP SYN/ACK packets should be treated differently from other packets in terms of the end node's response to an ECN-marked packet. Section 5 of RFC 3168 [RFC3168] specifies the following:
一个问题是，为什么在终端节点对带有ECN标记的数据包的响应方面，TCP SYN/ACK数据包应该与其他数据包区别对待。RFC 3168[RFC3168]第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. For example, for ECN-Capable TCP the source TCP is required to halve its congestion window for any window of data containing either a packet drop or an ECN indication.
当具有ECN能力的传输接收到单个CE分组时，终端系统遵循的拥塞控制算法必须与对*单个*丢弃分组的拥塞控制响应基本相同。例如，对于支持ECN的TCP，源TCP需要将包含丢包或ECN指示的任何数据窗口的拥塞窗口减半。
In particular, Section 6.1.2 of RFC 3168 [RFC3168] specifies that when the TCP congestion window consists of a single packet and that packet is ECN-marked in the network, then the data sender must reduce the sending rate below one packet per round-trip time, by waiting for one RTO before sending another packet. If the RTO was set to the average round-trip time, this would result in halving the sending rate; because the RTO is in fact larger than the average round-trip time, the sending rate is reduced to less than half of its previous value.
具体而言，RFC 3168[RFC3168]第6.1.2节规定，当TCP拥塞窗口由单个数据包组成且该数据包在网络中标记为ECN时，数据发送方必须通过在发送另一个数据包之前等待一个RTO，将发送速率降低到每往返时间一个数据包以下。如果RTO设置为平均往返时间，这将导致发送速率减半；由于RTO实际上大于平均往返时间，因此发送速率降低到不到其先前值的一半。
TCP's congestion control response to the *dropping* of a SYN/ACK packet is to wait a default time before sending another packet. This document argues that ECN gives end-systems a wider range of possible responses to the *marking* of a SYN/ACK packet, and that waiting a default time before sending another packet is not the desired response.
TCP对SYN/ACK数据包*丢弃*的拥塞控制响应是在发送另一个数据包之前等待默认时间。本文件认为，ECN为终端系统提供了对SYN/ACK数据包*标记*的更广泛的可能响应，并且在发送另一个数据包之前等待默认时间不是期望的响应。
On the conservative end, one could assume an effective congestion window of one packet for the SYN/ACK packet, and respond to an ECN-marked SYN/ACK packet by reducing the sending rate to one packet every two round-trip times. As an approximation, the TCP end node could measure the round-trip time T between the sending of the SYN/ACK packet and the receipt of the acknowledgement, and reply to the acknowledgement of the ECN-marked SYN/ACK packet by waiting T seconds before sending a data packet.
在保守端，可以假设SYN/ACK分组的一个分组的有效拥塞窗口，并且通过将发送速率降低到每两个往返时间一个分组来响应带有ECN标记的SYN/ACK分组。作为近似值，TCP终端节点可以测量SYN/ACK分组的发送和确认的接收之间的往返时间T，并且通过在发送数据分组之前等待T秒来回复标记为ECN的SYN/ACK分组的确认。
However, we note that for an ECN-marked SYN/ACK packet, halving the *congestion window* is not the same as halving the *sending rate*; there is no "sending rate" associated with an ECN-Capable SYN/ACK packet, as such packets are only sent as the first packet in a connection from that host. Further, a router's marking of a SYN/ACK packet is not affected by any past history of that connection.
然而，我们注意到，对于ECN标记的SYN/ACK分组，将*拥塞窗口*减半与将*发送速率*减半不同；没有与支持ECN的SYN/ACK分组相关联的“发送速率”，因为这样的分组仅作为来自该主机的连接中的第一个分组发送。此外，路由器对SYN/ACK分组的标记不受该连接的任何过去历史的影响。
Adding ECN-Capability to SYN/ACK packets allows the response of the responder setting the initial congestion window to one packet, instead of its allowed default value of two, three, or four packets. The responder sends a non-ECN-Capable SYN/ACK packet, and proceeds
向SYN/ACK数据包添加ECN功能允许响应者将初始拥塞窗口设置为一个数据包，而不是其允许的默认值两个、三个或四个数据包。响应者发送不支持ECN的SYN/ACK数据包，然后继续
with a cautious sending rate of one data packet per round-trip time after that SYN/ACK packet is acknowledged. This document argues that this approach is useful to users, with no dangers of congestion collapse or of starvation of competing traffic. This is discussed in more detail below in Section 6.2.
在确认SYN/ACK数据包后，谨慎地以每往返时间一个数据包的发送速率发送。本文认为，这种方法对用户很有用，不会出现拥塞崩溃或竞争流量不足的危险。下文第6.2节将对此进行更详细的讨论。
We note that if the data transfer is entirely from node A to node B, there is still a difference in performance between the original mechanism ECN+ and the mechanism ECN+/TryOnce specified in this document. In particular, with ECN+/TryOnce, the TCP originator does not send data packets until it has received a non-ECN-marked SYN/ACK packet from the other end.
我们注意到，如果数据传输完全从节点A传输到节点B，则原始机制ECN+和本文档中指定的机制ECN+/t之间的性能仍然存在差异。特别是，使用ECN+/TryOnce，TCP发起方在从另一端接收到未标记ECN的SYN/ACK数据包之前不会发送数据包。
The addition of ECN-Capability to TCP's SYN/ACK packets was initially proposed in [ECN+]. The paper includes an extensive set of simulation and testbed experiments to evaluate the effects of the proposal, using several Active Queue Management (AQM) mechanisms, including Random Early Detection (RED) [RED], Random Exponential Marking (REM) [REM], and Proportional Integrator (PI) [PI]. The performance measures were the end-to-end response times for each request/response pair, and the aggregate throughput on the bottleneck link. The end-to-end response time was computed as the time from the moment when the request for the file is sent to the server, until that file is successfully downloaded by the client.
在TCP的SYN/ACK数据包中添加ECN功能最初是在[ECN+]中提出的。本文包括一组广泛的模拟和试验台实验，以评估该方案的效果，使用了几种主动队列管理（AQM）机制，包括随机早期检测（RED）[RED]、随机指数标记（REM）[REM]和比例积分器（PI）[PI]。性能度量是每个请求/响应对的端到端响应时间，以及瓶颈链路上的总吞吐量。端到端响应时间计算为从文件请求发送到服务器到客户端成功下载该文件的时间。
The measurements from [ECN+] show that setting an ECN-Capable codepoint in the IP packet header in TCP SYN/ACK packets systematically improves performance with all evaluated AQM schemes. When SYN/ACK packets at a congested router are ECN-marked instead of dropped, this can avoid a long initial retransmission timeout, improving the response time for the affected flow dramatically.
[ECN+]的测量结果表明，在TCP SYN/ACK数据包的IP数据包报头中设置一个支持ECN的代码点可以系统地提高所有评估的AQM方案的性能。当拥塞路由器上的SYN/ACK数据包被ECN标记而不是丢弃时，这可以避免较长的初始重传超时，从而显著提高受影响流的响应时间。
[ECN+] shows that the impact on aggregate throughput can also be quite significant, because marking SYN ACK packets can prevent larger flows from suffering long timeouts before being "admitted" into the network. In addition, the testbed measurements from [ECN+] show that web servers setting the ECN-Capable codepoint in TCP SYN/ACK packets could serve more requests.
[ECN+]表明，对聚合吞吐量的影响也可能非常显著，因为标记SYN ACK数据包可以防止较大的流在“允许”进入网络之前经历长时间超时。此外，来自[ECN+]的测试台测量结果表明，在TCP SYN/ACK数据包中设置支持ECN的代码点的web服务器可以服务更多请求。
As a final step, [ECN+] explores the coexistence of flows that do and don't set the ECN-Capable codepoint in TCP SYN/ACK packets. The results in [ECN+] show that both types of flows can coexist, with some performance degradation for flows that don't use ECN+. Flows
作为最后一步，[ECN+]探索在TCP SYN/ACK数据包中设置和不设置支持ECN的代码点的流的共存。[ECN+]中的结果表明，这两种类型的流可以共存，不使用ECN+的流的性能会有所下降。流动
that do use ECN+ improve their end-to-end performance. At the same time, the performance degradation for flows that don't use ECN+, as a result of the flows that do use ECN+, increases as a greater fraction of flows use ECN+.
使用ECN+可以提高端到端性能。同时，不使用ECN+的流的性能下降（由于使用ECN+的流）随着使用ECN+的流的比例增加而增加。
[ECN+] explores the costs and benefits of adding ECN-Capability to SYN/ACK packets with both simulations and experiments. The addition of ECN-Capability to SYN/ACK packets could be of significant benefit for those ECN connections that would have had the SYN/ACK packet dropped in the network, and for which the ECN-Capability would allow the SYN/ACK to be marked rather than dropped.
[ECN+]通过模拟和实验探索了将ECN功能添加到SYN/ACK数据包的成本和收益。将ECN能力添加到SYN/ACK数据包可能对那些将在网络中丢弃SYN/ACK数据包的ECN连接有重大好处，并且对于这些ECN连接，ECN能力将允许标记SYN/ACK而不是丢弃SYN/ACK。
The percent of SYN/ACK packets on a link can be quite high. In particular, measurements on links dominated by web traffic indicate that 15-20% of the packets can be SYN/ACK packets [SCJO01].
链路上SYN/ACK数据包的百分比可能相当高。特别是，对网络流量占主导地位的链路的测量表明，15-20%的数据包可以是SYN/ACK数据包[SCJO01]。
The benefit of adding ECN-Capability to SYN/ACK packets depends in part on the size of the data transfer. The drop of a SYN/ACK packet can increase the download time of a short file by an order of magnitude, by requiring a three-second retransmission timeout. For longer-lived flows, the effect of a dropped SYN/ACK packet on file download time is less dramatic. However, even for longer-lived flows, the addition of ECN-Capability to SYN/ACK packets can improve the fairness among long-lived flows, as newly arriving flows would be less likely to have to wait for retransmission timeouts.
向SYN/ACK数据包添加ECN功能的好处部分取决于数据传输的大小。SYN/ACK数据包的丢弃可以通过要求三秒钟的重新传输超时将短文件的下载时间增加一个数量级。对于寿命较长的流，丢弃的SYN/ACK数据包对文件下载时间的影响较小。然而，即使对于寿命较长的流，向SYN/ACK分组添加ECN能力也可以提高寿命较长的流之间的公平性，因为新到达的流不太可能必须等待重传超时。
One question that arises is what fraction of connections would see the benefit from making SYN/ACK packets ECN-Capable in a particular scenario. Specifically:
出现的一个问题是，在特定场景中，使SYN/ACK数据包具有ECN功能的好处在连接中占多大比例。明确地：
(1) What fraction of arriving SYN/ACK packets are dropped at the congested router when the SYN/ACK packets are not ECN-Capable?
(1) 当SYN/ACK数据包不支持ECN时，到达的SYN/ACK数据包中有多少会在拥塞的路由器上丢弃？
(2) Of those SYN/ACK packets that are dropped, what fraction would have been ECN-marked instead of dropped if the SYN/ACK packets had been ECN-Capable?
(2) 在被丢弃的那些SYN/ACK数据包中，如果SYN/ACK数据包具有ECN功能，哪些部分会被ECN标记而不是丢弃？
To answer (1), it is necessary to consider not only the level of congestion but also the queue architecture at the congested link. As described in Section 4 above, for some queue architectures, small packets are less likely to be dropped than large ones. In such an environment, SYN/ACK packets would have lower packet drop rates; question (1) could not necessarily be inferred from the overall packet drop rate, but could be answered by measuring the drop rate
要回答（1），不仅要考虑拥塞程度，还要考虑拥塞链路上的队列结构。如上文第4节所述，对于某些队列体系结构，小数据包比大数据包更不可能被丢弃。在这样的环境中，SYN/ACK分组将具有较低的分组丢弃率；问题（1）不一定可以从总体数据包丢弃率推断出来，但可以通过测量丢弃率来回答
for SYN/ACK packets directly. In such an environment, adding ECN-Capability to SYN/ACK packets would be of less dramatic benefit than in environments where all packets are equally likely to be dropped regardless of packet size.
直接用于SYN/ACK数据包。在这样的环境中，将ECN能力添加到SYN/ACK数据包中的好处不如在所有数据包都有可能被丢弃的环境中（无论数据包大小）那么显著。
As question (2) implies, even if all of the SYN/ACK packets were ECN-Capable, there could still be some SYN/ACK packets dropped instead of marked at the congested link; the full answer to question (2) depends on the details of the queue management mechanism at the router. If congestion is sufficiently bad, and the queue management mechanism cannot prevent the buffer from overflowing, then SYN/ACK packets will be dropped rather than marked upon buffer overflow whether or not they are ECN-Capable.
正如问题（2）所暗示的，即使所有SYN/ACK分组都能够进行ECN，仍然可能有一些SYN/ACK分组被丢弃，而不是在拥塞链路上被标记；问题（2）的完整答案取决于路由器上队列管理机制的细节。如果拥塞严重，且队列管理机制无法防止缓冲区溢出，则SYN/ACK数据包将被丢弃，而不是在缓冲区溢出时标记，无论它们是否支持ECN。
For some AQM mechanisms, ECN-Capable packets are marked instead of dropped any time this is possible, that is, any time the buffer is not yet full. For other AQM mechanisms however, such as the RED mechanism as recommended in [RED], packets are dropped rather than marked when the packet drop/mark rate exceeds a certain threshold, e.g., 10%, even if the packets are ECN-Capable. For a router with such an AQM mechanism, when congestion is sufficiently severe to cause a high drop/mark rate, some SYN/ACK packets would be dropped instead of marked whether or not they were ECN-Capable.
对于某些AQM机制，在可能的任何时候，即缓冲区尚未满时，都会标记支持ECN的数据包，而不是丢弃数据包。然而，对于其他AQM机制，例如[RED]中建议的RED机制，当分组丢弃/标记速率超过某个阈值（例如10%）时，分组被丢弃而不是被标记，即使分组具有ECN能力。对于具有这种AQM机制的路由器，当拥塞严重到足以导致高丢弃/标记速率时，一些SYN/ACK数据包将被丢弃，而不是标记它们是否具有ECN能力。
Thus, the degree of benefit of adding ECN-Capability to SYN/ACK packets depends not only on the overall packet drop rate in the network, but also on the queue management architecture at the congested link.
因此，向SYN/ACK分组添加ECN能力的益处程度不仅取决于网络中的总体分组丢弃率，而且还取决于拥塞链路处的队列管理体系结构。
This document specifies that the end node responds to the report of an ECN-marked SYN/ACK packet by setting the initial congestion window to one segment, instead of its possible default value of two to four segments, and resending a SYN/ACK packet that is not ECN-Capable. We call this ECN+/TryOnce.
本文档规定，终端节点通过将初始拥塞窗口设置为一个段（而不是其可能的默认值为两到四个段）并重新发送不支持ECN的SYN/ACK数据包，来响应带有ECN标记的SYN/ACK数据包的报告。我们称之为ECN+/TryOnce。
However, Section 4 discussed two other possible responses to an ECN-marked SYN/ACK packet. In ECN+, the original proposal from [ECN+], the end node responds to the report of an ECN-marked SYN/ACK packet by setting the initial congestion window to one segment and immediately sending a data packet, if it has one to send. In ECN+/Wait, the end node responds to the report of an ECN-marked SYN/ACK packet by setting the initial congestion window to one segment and waiting an RTT before sending a data packet.
然而，第4节讨论了对带有ECN标记的SYN/ACK数据包的另外两种可能的响应。在[ECN+]的原始提案ECN+中，终端节点通过将初始拥塞窗口设置为一个段并立即发送数据包（如果有数据包要发送）来响应标记为ECN的SYN/ACK数据包的报告。在ECN+/Wait中，终端节点通过将初始拥塞窗口设置为一个段并在发送数据包之前等待RTT来响应标记为ECN的SYN/ACK包的报告。
Simulations comparing the performance with Standard ECN (without ECN-marked SYN/ACK packets), ECN+, ECN+/Wait, and ECN/TryOnce show little difference, in terms of aggregate congestion, between ECN+ and ECN+/Wait. However, for some scenarios with queues that are packet-based rather than byte-based, and with packet drop rates above 25% without ECN+, the use of ECN+ or of ECN+/Wait can more than double the packet drop rates to greater than 50%. The details are given in Tables 1 and 3 of Appendix A below. ECN+/TryOnce does not increase the packet drop rate in scenarios of high congestion. Therefore, ECN+/TryOnce is superior to ECN+ or to ECN+/Wait, which both significantly increase the packet drop rate in scenarios of high congestion. At the same time, ECN+/TryOnce gives a performance improvement similar to that of ECN+ or ECN+/Wait (Tables 2 and 4 of Appendix A).
将性能与标准ECN（没有ECN标记的SYN/ACK数据包）、ECN+、ECN+/Wait和ECN/TryOnce进行比较的仿真结果表明，ECN+和ECN+/Wait在聚合拥塞方面几乎没有差异。但是，对于一些队列基于数据包而不是基于字节的情况，并且在没有ECN+的情况下数据包丢弃率高于25%的情况下，使用ECN+或ECN+/Wait可以使数据包丢弃率增加一倍以上，达到50%以上。详情见下文附录A表1和表3。ECN+/TryOnce在高拥塞情况下不会增加丢包率。因此，ECN+/TryOnce优于ECN+或ECN+/Wait，这两种方法都显著提高了高拥塞情况下的丢包率。同时，ECN+/TryOnce提供了与ECN+或ECN+/Wait类似的性能改进（附录a的表2和表4）。
Our conclusions are that ECN+/TryOnce is safe, and has significant benefits to the user, and avoids the problems of ECN+ or ECN+/Wait under extreme levels of congestion. As a consequence, this document specifies the use of ECN+/TryOnce.
我们的结论是，ECN+/TryOnce是安全的，对用户有显著的好处，并且避免了在极端拥塞水平下ECN+或ECN+/Wait的问题。因此，本文件规定了ECN+/TryOnce的使用。
Note: We only discovered the occasional congestion-related problems of ECN+ and of ECN+/Wait when re-running the simulations with an updated version of the ns-2 simulator, after the document had almost completed the standardization process.
注：在文件几乎完成标准化过程后，我们仅在使用更新版本的ns-2模拟器重新运行模拟时，才发现ECN+和ECN+/Wait偶尔出现与拥塞相关的问题。
This section discusses experiments that would be useful before a widespread deployment of ECN-Capability for TCP SYN/ACK packets.
本节讨论在广泛部署TCP SYN/ACK数据包的ECN功能之前有用的实验。
Section 7.1 below discusses some of the known deployment problems of ECN, in terms of routers or middleboxes that react inappropriately to packets that use ECN codepoints in the IP or TCP packet headers. One goal of a measurement study of ECN-Capability for TCP SYN/ACK packets would be to determine if there were any routers or middleboxes that react inappropriately to TCP SYN/ACK packets containing an ECN-Capable or CE codepoint in the IP header. A second goal of a measurement study would be to check the deployment status of older TCP implementations that are ECN-Capable, but that don't respond to ECN-Capability for SYN/ACK packets. (This is discussed in more detail in Appendix B below.)
下面的第7.1节讨论了ECN的一些已知部署问题，即路由器或中间盒对IP或TCP数据包头中使用ECN代码点的数据包做出不适当反应。TCP SYN/ACK数据包的ECN能力测量研究的一个目标是确定是否有任何路由器或中间盒对IP报头中包含ECN能力或CE码点的TCP SYN/ACK数据包做出不适当的反应。测量研究的第二个目标是检查支持ECN但不响应SYN/ACK数据包的ECN功能的旧TCP实现的部署状态。（下文附录B对此进行了更详细的讨论。）
Following the discussion in Section 6.2, an experimental study could explore the use of ECN-Capability for TCP SYN/ACK packets in highly congested environments with ECN-Capable routers.
根据第6.2节中的讨论，一项实验研究可以探索在具有ECN功能的路由器的高度拥挤环境中对TCP SYN/ACK数据包使用ECN功能。
TCP packets carrying the ECT codepoint in IP headers can be marked rather than dropped by ECN-Capable routers. This raises several security concerns that we discuss below.
支持ECN的路由器可以标记而不是丢弃IP报头中携带ECT代码点的TCP数据包。这引起了我们下面讨论的几个安全问题。
There are a number of known deployment problems from using ECN with TCP traffic in the Internet. The first reported problem, dating back to 2000, is of a small but decreasing number of routers or middleboxes that reset a TCP connection in response to TCP SYN packets using flags in the TCP header to negotiate ECN-Capability [Kelson00] [RFC3360] [MAF05]. Dave Thaler reported at the March 2007 IETF of two new problems encountered by TCP connections using ECN; the first of the two problems concerns routers that crash when a TCP data packet arrives with the ECN field in the IP header with the codepoint ECT(0) or ECT(1), indicating that an ECN-Capable connection has been established [SBT07].
在Internet中将ECN与TCP通信一起使用会产生许多已知的部署问题。第一个报告的问题可以追溯到2000年，它是一个数量较少但数量不断减少的路由器或中间盒，这些路由器或中间盒使用TCP报头中的标志来协商ECN能力[Kelson00][RFC3360][MAF05]，以响应TCP SYN包而重置TCP连接。Dave Thaler在2007年3月的IETF上报告了使用ECN的TCP连接遇到的两个新问题；两个问题中的第一个问题涉及当TCP数据包到达IP报头中带有ECN字段且代码点为ECT（0）或ECT（1）时路由器崩溃，这表明已建立了支持ECN的连接[SBT07]。
While there is no evidence that any routers or middleboxes drop SYN/ACK packets that contain an ECN-Capable or CE codepoint in the IP header, such behavior cannot be excluded. (There seems to be a number of routers or middleboxes that drop TCP SYN packets that contain known or unknown IP options (see figure 1 of [MAF05].) Thus, as specified in Section 3, if a SYN/ACK packet with the ECT or CE codepoint is dropped, the TCP node should resend the SYN/ACK packet without the ECN-Capable codepoint. There is also no evidence that any routers or middleboxes crash when a SYN/ACK arrives with an ECN-Capable or CE codepoint in the IP header (over and above the routers already known to crash when a data packet arrives with either ECT(0) or ECT(1)), but we have not conducted any measurement studies of this [F07].
虽然没有证据表明任何路由器或中间盒丢弃在IP报头中包含支持ECN或CE码点的SYN/ACK数据包，但不能排除此类行为。（似乎有许多路由器或中间盒丢弃包含已知或未知IP选项的TCP SYN数据包（参见[MAF05]的图1）因此，如第3节所述，如果带有ECT或CE码点的SYN/ACK数据包被丢弃，TCP节点应在没有ECN码点的情况下重新发送SYN/ACK数据包。也没有证据表明，当IP报头中带有ECN码点或CE码点的SYN/ACK数据包到达时，任何路由器或中间盒都会崩溃（在已知的路由器之上，当数据包以ECT（0）或ECT（1）到达时会崩溃），但我们尚未对此进行任何测量研究[F07]。
Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN-marked instead of dropped at an ECN-Capable router, the concern is whether this can either invoke congestion or worsen performance in highly congested scenarios. However, after learning that a SYN/ACK packet was ECN-marked, the responder sends a SYN/ACK packet that is not ECN-Capable; if this SYN/ACK packet is dropped, the responder then waits for a retransmission timeout, as specified in the TCP standards. In addition, routers are free to drop rather than mark arriving packets in times of high congestion, regardless of whether the packets are ECN-Capable. When congestion is very high and a router's buffer is full, the router has no choice but to drop rather than to mark an arriving packet.
由于携带ECT代码点的TCP SYN/ACK数据包可以在具有ECN功能的路由器上进行ECN标记，而不是丢弃，因此需要考虑的是，在高度拥挤的情况下，这是否会引发拥塞或恶化性能。然而，在获悉SYN/ACK分组被ECN标记之后，响应者发送不支持ECN的SYN/ACK分组；如果此SYN/ACK数据包被丢弃，则响应程序将按照TCP标准的规定等待重新传输超时。此外，路由器在高拥塞时可以自由丢弃而不是标记到达的数据包，无论数据包是否支持ECN。当拥塞非常严重且路由器的缓冲区已满时，路由器别无选择，只能丢弃而不是标记到达的数据包。
The simulations reported in Appendix A show that even with demanding traffic mixes dominated by short flows and high levels of congestion, the aggregate packet dropping rates are not significantly different with Standard ECN or with ECN+/TryOnce. However, in our simulations, we have one scenario where ECN+ or ECN+/Wait results in a significantly higher packet drop rate than ECN or ECN+/TryOnce (Tables 1 and 3 in Appendix A below).
附录A中报告的模拟表明，即使在短流量和高拥塞水平的高要求流量混合情况下，与标准ECN或ECN+/TryOnce相比，总分组丢弃率也没有显著差异。然而，在我们的模拟中，我们有一个场景，其中ECN+或ECN+/Wait导致显著高于ECN或ECN+/TryOnce的丢包率（下面附录a中的表1和表3）。
This document specifies a modification to RFC 3168 [RFC3168] to allow TCP nodes to send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK packet is dropped by a congested router, by avoiding the resulting retransmission timeout. This improves the throughput of short connections. This document specifies the ECN+/TryOnce mechanism for ECN-Capability for SYN/ACK packets, where the sender of the SYN/ACK packet responds to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, and sending a SYN/ACK packet that is not ECN-Capable. The addition of ECN-Capability to SYN/ACK packets is particularly beneficial in the server-to-client direction, where congestion is more likely to occur. In this case, the initial information provided by the ECN marking in the SYN/ACK packet enables the server to appropriately adjust the initial load it places on the network, while avoiding the delay of a retransmission timeout.
本文档指定了对RFC 3168[RFC3168]的修改，以允许TCP节点发送支持ECN的SYN/ACK数据包。使SYN/ACK数据包具有ECN功能，可避免因拥塞路由器丢弃SYN/ACK数据包而导致的重传超时，从而避免TCP传输的高成本。这提高了短连接的吞吐量。本文件规定了SYN/ACK数据包ECN功能的ECN+/TryOnce机制，其中SYN/ACK数据包的发送方通过将其初始拥塞窗口从两段、三段或四段减少为一段，并发送不支持ECN的SYN/ACK数据包来响应ECN标记。将ECN功能添加到SYN/ACK数据包中在服务器到客户端的方向上尤其有益，因为在这种方向上更可能发生拥塞。在这种情况下，由SYN/ACK分组中的ECN标记提供的初始信息使得服务器能够适当地调整其在网络上施加的初始负载，同时避免重传超时的延迟。
We thank Anil Agarwal, Mark Allman, Remi Denis-Courmont, Wesley Eddy, Lars Eggert, Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for feedback on earlier working drafts of this document. We thank Adam Langley [L08] for contributing a patch for ECN+/TryOnce for the Linux development tree.
我们感谢Anil Agarwal、Mark Allman、Remi Denis Courmon、Wesley Eddy、Lars Eggert、Alfred Hoenes、Janardhan Iyengar和Pasi Sarolahti对本文件早期工作草案的反馈。我们感谢Adam Langley[L08]为Linux开发树提供了ECN+/TryOnce补丁。
This section reports on simulations showing the costs of adding ECN+ in highly congested scenarios. This section also reports on simulations for a comparative evaluation between ECN, ECN+, ECN+/Wait, and ECN+/TryOnce.
本节报告模拟结果，显示在高度拥挤的场景中添加ECN+的成本。本节还报告了ECN、ECN+、ECN+/Wait和ECN+/TryOnce之间的比较评估模拟。
The simulations are run with a range of file-size distributions, using the PackMime traffic generator in the ns-2 simulator. They all use a heavy-tailed distribution of file sizes. The simulations reported in the tables below use a mean file size of 3 Kbytes, to show the results with a traffic mix with a large number of small transfers. Other simulations were run with mean file sizes of 5 Kbytes, 7 Kbytes, 14 Kbytes, and 17 Kbytes. The title of each chart gives the targeted average load from the traffic generator. Because the simulations use a heavy-tailed distribution of file sizes, and run for only 85 seconds (including ten seconds of warm-up time), the actual load is often much smaller than the targeted load. The congested link is 100 Mbps. RED is run in gentle mode, and arriving ECN-Capable packets are only dropped instead of marked if the buffer is full (and the router has no choice).
使用ns-2模拟器中的PackMime流量生成器，使用一系列文件大小分布运行模拟。它们都使用文件大小的重尾分布。下表中报告的模拟使用3KB的平均文件大小，以显示具有大量小传输的流量混合的结果。其他模拟以5 KB、7 KB、14 KB和17 KB的平均文件大小运行。每个图表的标题给出了来自流量生成器的目标平均负载。由于模拟使用文件大小的厚尾分布，并且仅运行85秒（包括10秒的预热时间），因此实际负载通常比目标负载小得多。拥挤的链路是100 Mbps。RED在温和模式下运行，只有在缓冲区已满（路由器没有选择）的情况下，到达的支持ECN的数据包才会丢弃而不是标记。
We explore three possible mechanisms for a TCP node's response to a report of an ECN-marked SYN/ACK packet. With ECN+, the TCP node sends a data packet immediately (with an initial congestion window of one segment). With ECN+/Wait, the TCP node waits a round-trip time before sending a data packet; the responder already has one measurement of the round-trip time when the acknowledgement for the SYN/ACK packet is received. With ECN+/TryOnce, the mechanism standardized in this document, the TCP responder replies to a report of an ECN-marked SYN/ACK packet by sending a SYN/ACK packet that is not ECN-Capable, and reducing the initial congestion window to one segment.
我们探讨了TCP节点响应带有ECN标记的SYN/ACK数据包报告的三种可能机制。使用ECN+，TCP节点立即发送数据包（初始拥塞窗口为一段）。使用ECN+/Wait，TCP节点在发送数据包之前等待往返时间；当接收到SYN/ACK分组的确认时，应答器已经具有一个往返时间的测量。使用本文档中标准化的机制ECN+/TryOnce，TCP响应程序通过发送不支持ECN的SYN/ACK数据包，并将初始拥塞窗口减少到一个段，来响应带有ECN标记的SYN/ACK数据包的报告。
The simulation scripts are available on [ECN-SYN], along with graphs showing the distribution of response times for the TCP connections.
[ECN-SYN]上提供了模拟脚本，以及显示TCP连接响应时间分布的图表。
The simulations with RED in packet mode and with the queue in packets show that ECN+ is useful in times of moderate or high congestion. However, for the simulations with a target load of 125%, with a packet loss rate of over 25% for ECN, ECN+ and ECN+/Wait both result in a packet loss rate of over 50%. (In contrast, the packet loss rate with ECN+/TryOnce is less than that of ECN alone.) For the distribution of response times, the simulations show that ECN+, ECN+/Wait, and ECN+/TryOnce all significantly improve the response times, when compared to the response times with Standard ECN.
在数据包模式下使用RED和在数据包中使用队列进行的仿真表明，ECN+在中等或高拥塞时是有用的。然而，对于目标负载为125%的模拟，ECN的丢包率超过25%，ECN+和ECN+/Wait都会导致丢包率超过50%。（相比之下，使用ECN+/TryOnce的丢包率低于单独使用ECN的丢包率。）对于响应时间的分布，仿真表明，与使用标准ECN的响应时间相比，ECN+、ECN+/Wait和ECN+/TryOnce都显著提高了响应时间。
Table 1 shows the congestion levels for simulations with RED in packet mode, with a queue in packets. To explore a worst-case scenario, these simulations use a traffic mix with an unrealistically small flow size distribution, with a mean flow size of 3 Kbytes. For each table showing a particular traffic load, the four rows show the number of packets dropped, the number of packets ECN-marked, the aggregate packet drop rate, and the aggregate throughput. The four columns show the simulations with Standard ECN, ECN+, ECN+/Wait, and ECN+/TryOnce.
表1显示了分组模式下RED模拟的拥塞级别，分组中有队列。为了探索最坏情况，这些模拟使用了流量混合，流量大小分布非常小，平均流量大小为3 KB。对于显示特定流量负载的每个表，这四行显示丢弃的数据包数量、标记为ECN的数据包数量、聚合数据包丢弃率和聚合吞吐量。这四列显示了使用标准ECN、ECN+、ECN+/Wait和ECN+/TryOnce进行的模拟。
These simulations were run with RED set to mark instead of drop packets any time that the queue is not full. This is a worst-case scenario for ECN+ and its variants. For the default implementation of RED in the ns-2 simulator, when the average queue size exceeds a configured threshold, the router drops all arriving packets. For scenarios with this RED mechanism, it is less likely that ECN+ or one of its variants would increase the average queue size above the configured threshold.
这些模拟在队列未满时以红色标记而不是丢弃数据包的方式运行。这是ECN+及其变体的最坏情况。对于ns-2模拟器中RED的默认实现，当平均队列大小超过配置的阈值时，路由器丢弃所有到达的数据包。对于使用此RED机制的场景，ECN+或其变体将平均队列大小增加到配置的阈值以上的可能性较小。
The usefulness of ECN+: The first thing to observe is that for all of the simulations, the use of ECN+ or ECN+/Wait significantly increases the number of packets marked. In contrast, the use of ECN+/TryOnce significantly increases the number of packets marked in the simulations with moderate congestion, and gives a more moderate increase in the number of packets marked for the simulations with higher levels of congestion. However, the cumulative distribution function (CDF) in Table 2 shows that ECN+, ECN+/Wait, and ECN+/TryOnce all improve response times for all of the simulations, with moderate or with larger levels of congestion.
ECN+的有用性：首先要注意的是，对于所有模拟，使用ECN+或ECN+/Wait会显著增加标记的数据包数量。相比之下，ECN+/TryOnce的使用显著增加了中度拥塞模拟中标记的数据包数量，并使拥塞级别较高的模拟中标记的数据包数量有了更适度的增加。然而，表2中的累积分布函数（CDF）表明，ECN+、ECN+/Wait和ECN+/TryOnce都能改善所有模拟的响应时间，无论是中度还是重度拥塞。
Little increase in congestion, sometimes: The second thing to observe is that for the simulations with low or moderate levels of congestion (that is, with packet drop rates less than 10%), the use of ECN+, ECN+/Wait, and ECN+/TryOnce all decrease the aggregate packet drop rate relative to the simulations with ECN. This makes sense, since with low or moderate levels of congestion, ECN+ allows SYN/ACK packets to be marked instead of dropped, and the use of ECN+ doesn't add to the aggregate congestion. However, for the simulations with packet drop rates of 15% or higher with ECN, the use of ECN+ or ECN+/Wait increases the aggregate packet drop rate, sometimes even doubling it.
有时拥塞几乎没有增加：第二件要观察的事情是，对于具有低或中等拥塞水平的模拟（即丢包率小于10%），使用ECN+、ECN+/Wait和ECN+/TryOnce都会降低相对于使用ECN的模拟的总丢包率。这是有意义的，因为对于低或中等程度的拥塞，ECN+允许标记SYN/ACK数据包而不是丢弃，并且使用ECN+不会增加聚合拥塞。然而，对于使用ECN的丢包率为15%或更高的模拟，使用ECN+或ECN+/Wait会增加总丢包率，有时甚至会使其加倍。
Comparing ECN+, ECN+/Wait, and ECN+/TryOnce: The aggregate packet drop rate is generally higher with ECN+/Wait than with ECN+. Thus, there is no congestion-related reason to prefer ECN+/Wait over ECN+. In contrast, the aggregate packet drop rate with ECN+/TryOnce is often significantly lower than the aggregate packet drop rate with either ECN, ECN+, or ECN+/Wait.
比较ECN+、ECN+/Wait和ECN+/TryOnce：ECN+/Wait的总丢包率通常高于ECN+。因此，没有任何与拥塞相关的理由选择ECN+/Wait而不是ECN+。相反，使用ECN+/TryOnce的聚合数据包丢弃率通常显著低于使用ECN、ECN+或ECN+/Wait的聚合数据包丢弃率。
Target Load = 95%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 20,516 11,226 11,735 16,755`
Marked 30,586 37,741 37,425 40,764
Loss rate 1.41% 0.78% 0.81% 1.02%
Throughput 81% 81% 81% 81%
Target Load = 95%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 20,516 11,226 11,735 16,755`
Marked 30,586 37,741 37,425 40,764
Loss rate 1.41% 0.78% 0.81% 1.02%
Throughput 81% 81% 81% 81%
Target Load = 110%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 165,566 106,083 147,180 208,422
Marked 179,735 281,306 308,473 235,483
Loss rate 9.01% 6.12% 8.02% 6.89%
Throughput 92% 92% 92% 94%
Target Load = 110%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 165,566 106,083 147,180 208,422
Marked 179,735 281,306 308,473 235,483
Loss rate 9.01% 6.12% 8.02% 6.89%
Throughput 92% 92% 92% 94%
Target Load = 125%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 600,628 1,746,768 2,176,530 625,552
Marked 418,433 1,166,450 1,164,932 439,847
Loss rate 25.45% 51.73% 56.87% 18.31%
Throughput 94% 98% 97% 95%
Target Load = 125%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 600,628 1,746,768 2,176,530 625,552
Marked 418,433 1,166,450 1,164,932 439,847
Loss rate 25.45% 51.73% 56.87% 18.31%
Throughput 94% 98% 97% 95%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637
Marked 669,840 583,378 591,315 684,715
Loss rate 46.7% 59.0% 59.0% 32.7%
Throughput 88% 94% 94% 92%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637
Marked 669,840 583,378 591,315 684,715
Loss rate 46.7% 59.0% 59.0% 32.7%
Throughput 88% 94% 94% 92%
Table 1: Simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in packet mode, queue in packets
表1：平均流量大小为3kbytes、100Mbps链路、分组模式下为红色、分组中为队列的模拟
Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.07 0.26 0.51 0.82 0.96 0.97 0.97 0.97 1.00 1.00
ECN+: 0.00 0.07 0.27 0.53 0.85 0.99 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.07 0.26 0.51 0.83 0.97 1.00 1.00 1.00 1.00 1.00
Once: 0.00 0.07 0.24 0.49 0.83 0.97 1.00 1.00 1.00 1.00 1.00
Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.07 0.26 0.51 0.82 0.96 0.97 0.97 0.97 1.00 1.00
ECN+: 0.00 0.07 0.27 0.53 0.85 0.99 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.07 0.26 0.51 0.83 0.97 1.00 1.00 1.00 1.00 1.00
Once: 0.00 0.07 0.24 0.49 0.83 0.97 1.00 1.00 1.00 1.00 1.00
Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.05 0.19 0.41 0.67 0.79 0.80 0.80 0.80 0.96 0.96
ECN+: 0.00 0.07 0.22 0.48 0.81 0.96 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.05 0.18 0.38 0.64 0.77 0.95 1.00 1.00 1.00 1.00
Once: 0.00 0.06 0.19 0.42 0.70 0.86 0.95 0.96 0.96 0.99 0.99
Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.05 0.19 0.41 0.67 0.79 0.80 0.80 0.80 0.96 0.96
ECN+: 0.00 0.07 0.22 0.48 0.81 0.96 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.05 0.18 0.38 0.64 0.77 0.95 1.00 1.00 1.00 1.00
Once: 0.00 0.06 0.19 0.42 0.70 0.86 0.95 0.96 0.96 0.99 0.99
Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.04 0.13 0.27 0.46 0.56 0.58 0.59 0.59 0.82 0.82
ECN+: 0.00 0.06 0.18 0.33 0.58 0.76 0.97 0.99 0.99 1.00 1.00
Wait: 0.00 0.01 0.06 0.13 0.21 0.27 0.68 0.98 0.99 1.00 1.00
Once: 0.00 0.05 0.16 0.34 0.58 0.73 0.85 0.87 0.87 0.95 0.96
Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.04 0.13 0.27 0.46 0.56 0.58 0.59 0.59 0.82 0.82
ECN+: 0.00 0.06 0.18 0.33 0.58 0.76 0.97 0.99 0.99 1.00 1.00
Wait: 0.00 0.01 0.06 0.13 0.21 0.27 0.68 0.98 0.99 1.00 1.00
Once: 0.00 0.05 0.16 0.34 0.58 0.73 0.85 0.87 0.87 0.95 0.96
Target Load = 150%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.08 0.18 0.31 0.39 0.42 0.42 0.43 0.68 0.68
ECN+: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.93
Wait: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.94
Once: 0.00 0.04 0.13 0.27 0.46 0.59 0.72 0.75 0.75 0.88 0.88
Target Load = 150%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.08 0.18 0.31 0.39 0.42 0.42 0.43 0.68 0.68
ECN+: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.93
Wait: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.94
Once: 0.00 0.04 0.13 0.27 0.46 0.59 0.72 0.75 0.75 0.88 0.88
Table 2: The cumulative distribution function (CDF) for transfer
times, for simulations with an average flow size of 3
Kbytes, a 100 Mbps link, RED in packet mode, queue in
packets (the graphs are available from
"http://www.icir.org/floyd/ecn-syn/")
Table 2: The cumulative distribution function (CDF) for transfer
times, for simulations with an average flow size of 3
Kbytes, a 100 Mbps link, RED in packet mode, queue in
packets (the graphs are available from
"http://www.icir.org/floyd/ecn-syn/")
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 8,448 6,362 7,740 14,107
Marked 9,891 16,787 17,456 16,132
Loss rate 5.5% 4.3% 5.0% 5.0%
Throughput 78% 78% 78% 81%
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 8,448 6,362 7,740 14,107
Marked 9,891 16,787 17,456 16,132
Loss rate 5.5% 4.3% 5.0% 5.0%
Throughput 78% 78% 78% 81%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 31,284 29,773 49,297 45,277
Marked 28,429 54,729 60,383 34,622
Loss rate 15.3% 15.2% 21.9% 13.6%
Throughput 97% 96% 96% 94%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 31,284 29,773 49,297 45,277
Marked 28,429 54,729 60,383 34,622
Loss rate 15.3% 15.2% 21.9% 13.6%
Throughput 97% 96% 96% 94%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 61,433 176,682 214,096 75,612
Marked 44,408 119,728 117,301 49,442
Loss rate 25.4% 51.9% 56.0% 22.3%
Throughput 97% 98% 98% 96%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 61,433 176,682 214,096 75,612
Marked 44,408 119,728 117,301 49,442
Loss rate 25.4% 51.9% 56.0% 22.3%
Throughput 97% 98% 98% 96%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 130,007 251,856 326,845 133,603
Marked 63,066 146,757 147,239 66,444
Loss rate 42.5% 61.3% 67.3% 31.7%
Throughput 93% 99% 99% 94%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 130,007 251,856 326,845 133,603
Marked 63,066 146,757 147,239 66,444
Loss rate 42.5% 61.3% 67.3% 31.7%
Throughput 93% 99% 99% 94%
Table 3: Simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in packet mode, queue in packets
表3：平均流量大小为3KB、10Mbps链路、数据包模式为红色、数据包模式为队列的模拟
Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.05 0.18 0.42 0.70 0.86 0.88 0.88 0.88 0.98 0.98
ECN+: 0.00 0.06 0.20 0.45 0.78 0.96 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.05 0.18 0.40 0.68 0.84 0.96 1.00 1.00 1.00 1.00
Once: 0.00 0.05 0.18 0.40 0.71 0.88 0.96 0.97 0.97 0.99 0.99
Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.05 0.18 0.42 0.70 0.86 0.88 0.88 0.88 0.98 0.98
ECN+: 0.00 0.06 0.20 0.45 0.78 0.96 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.05 0.18 0.40 0.68 0.84 0.96 1.00 1.00 1.00 1.00
Once: 0.00 0.05 0.18 0.40 0.71 0.88 0.96 0.97 0.97 0.99 0.99
Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.13 0.29 0.52 0.66 0.69 0.69 0.69 0.91 0.91
ECN+: 0.00 0.05 0.17 0.36 0.66 0.88 0.98 0.99 1.00 1.00 1.00
Wait: 0.00 0.02 0.08 0.20 0.35 0.47 0.76 0.98 1.00 1.00 1.00
Once: 0.00 0.05 0.15 0.32 0.58 0.75 0.88 0.90 0.90 0.97 0.97
Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.13 0.29 0.52 0.66 0.69 0.69 0.69 0.91 0.91
ECN+: 0.00 0.05 0.17 0.36 0.66 0.88 0.98 0.99 1.00 1.00 1.00
Wait: 0.00 0.02 0.08 0.20 0.35 0.47 0.76 0.98 1.00 1.00 1.00
Once: 0.00 0.05 0.15 0.32 0.58 0.75 0.88 0.90 0.90 0.97 0.97
Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.10 0.22 0.40 0.52 0.56 0.56 0.57 0.82 0.82
ECN+: 0.00 0.03 0.14 0.27 0.49 0.70 0.96 0.99 0.99 0.99 1.00
Wait: 0.00 0.00 0.03 0.07 0.12 0.18 0.50 0.94 0.99 0.99 1.00
Once: 0.00 0.04 0.13 0.28 0.51 0.66 0.81 0.84 0.84 0.94 0.94
Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.10 0.22 0.40 0.52 0.56 0.56 0.57 0.82 0.82
ECN+: 0.00 0.03 0.14 0.27 0.49 0.70 0.96 0.99 0.99 0.99 1.00
Wait: 0.00 0.00 0.03 0.07 0.12 0.18 0.50 0.94 0.99 0.99 1.00
Once: 0.00 0.04 0.13 0.28 0.51 0.66 0.81 0.84 0.84 0.94 0.94
Target Load = 150%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.02 0.07 0.15 0.28 0.38 0.42 0.42 0.43 0.67 0.68
ECN+: 0.00 0.00 0.00 0.00 0.01 0.05 0.68 0.83 0.95 0.97 0.98
Wait: 0.00 0.00 0.00 0.00 0.00 0.00 0.10 0.62 0.83 0.93 0.97
Once: 0.00 0.03 0.11 0.24 0.42 0.56 0.71 0.75 0.75 0.88 0.88
Target Load = 150%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.02 0.07 0.15 0.28 0.38 0.42 0.42 0.43 0.67 0.68
ECN+: 0.00 0.00 0.00 0.00 0.01 0.05 0.68 0.83 0.95 0.97 0.98
Wait: 0.00 0.00 0.00 0.00 0.00 0.00 0.10 0.62 0.83 0.93 0.97
Once: 0.00 0.03 0.11 0.24 0.42 0.56 0.71 0.75 0.75 0.88 0.88
Table 4: The cumulative distribution function (CDF) for transfer
times, for simulations with an average flow size of 3
Kbytes, a 10 Mbps link, RED in packet mode, queue in
packets (the graphs are available from
"http://www.icir.org/floyd/ecn-syn/")
Table 4: The cumulative distribution function (CDF) for transfer
times, for simulations with an average flow size of 3
Kbytes, a 10 Mbps link, RED in packet mode, queue in
packets (the graphs are available from
"http://www.icir.org/floyd/ecn-syn/")
Table 5 below shows simulations with RED in byte mode and the queue in bytes. There is no significant increase in aggregate congestion with the use of ECN+, ECN+/Wait, or ECN+/TryOnce.
下表5显示了以字节模式显示红色和以字节为单位显示队列的模拟。使用ECN+、ECN+/Wait或ECN+/TryOnce不会显著增加总拥塞。
However, unlike the simulations with RED in packet mode, the simulations with RED in byte mode show little benefit from the use of ECN+ or ECN+/Wait, in that the packet marking rate with ECN+ or
然而，与数据包模式下使用红色的模拟不同，字节模式下使用红色的模拟显示使用ECN+或ECN+/Wait的好处不大，因为使用ECN+或ECN+的数据包标记率
ECN+/Wait is not much different than the packet marking rate with Standard ECN. This is because with RED in byte mode, small packets like SYN/ACK packets are rarely dropped or marked -- that is, there is no drawback from the use of ECN+ in these scenarios, but not much need for ECN+ either, in a scenario where small packets are unlikely to be dropped or marked.
ECN+/Wait与标准ECN的数据包标记率差别不大。这是因为在字节模式下使用RED时，像SYN/ACK数据包这样的小数据包很少被丢弃或标记——也就是说，在这些场景中使用ECN+没有缺点，但在小数据包不太可能被丢弃或标记的场景中，也不太需要ECN+。
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 766 446 427 408
Marked 32,683 34,289 33,412 31,892
Loss rate 0.05% 0.03% 0.03% 0.03%
Throughput 81% 81% 81% 81%
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 766 446 427 408
Marked 32,683 34,289 33,412 31,892
Loss rate 0.05% 0.03% 0.03% 0.03%
Throughput 81% 81% 81% 81%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 2,496 2,110 1,733 2,020
Marked 220,573 258,696 230,955 214,604
Loss rate 0.15% 0.13% 0.11% 0.11%
Throughput 92% 91% 92% 92%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 2,496 2,110 1,733 2,020
Marked 220,573 258,696 230,955 214,604
Loss rate 0.15% 0.13% 0.11% 0.11%
Throughput 92% 91% 92% 92%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 20,032 13,555 13,979 16,918
Marked 725,165 726,992 726,823 615,235
Loss rate 1.11% 0.76% 0.78% 0.66%
Throughput 95% 95% 95% 96%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 20,032 13,555 13,979 16,918
Marked 725,165 726,992 726,823 615,235
Loss rate 1.11% 0.76% 0.78% 0.66%
Throughput 95% 95% 95% 96%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 484,251 483,847 507,727 600,737
Marked 865,905 872,254 873,317 818,451
Loss rate 19.09% 19.13% 19.71% 12.66%
Throughput 99% 98% 99% 99%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 484,251 483,847 507,727 600,737
Marked 865,905 872,254 873,317 818,451
Loss rate 19.09% 19.13% 19.71% 12.66%
Throughput 99% 98% 99% 99%
Table 5: Simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in byte mode, queue in bytes
表5：平均流量大小为3kbytes、100Mbps链路、字节模式为红色、队列为字节的模拟
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 142 77 103 99
Marked 11,694 11,387 11,604 12,129
Loss rate 0.1% 0.1% 0.1% 0.1%
Throughput 78% 78% 78% 78%
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 142 77 103 99
Marked 11,694 11,387 11,604 12,129
Loss rate 0.1% 0.1% 0.1% 0.1%
Throughput 78% 78% 78% 78%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 338 210 247 274
Marked 41,676 40,412 44,173 36,265
Loss rate 0.2% 0.1% 0.1% 0.1%
Throughput 94% 94% 94% 96%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 338 210 247 274
Marked 41,676 40,412 44,173 36,265
Loss rate 0.2% 0.1% 0.1% 0.1%
Throughput 94% 94% 94% 96%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 1,559 951 978 1,723
Marked 74,933 75,499 75,481 59,670
Loss rate 0.8% 0.5% 0.5% 0.6%
Throughput 99% 99% 99% 96%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 1,559 951 978 1,723
Marked 74,933 75,499 75,481 59,670
Loss rate 0.8% 0.5% 0.5% 0.6%
Throughput 99% 99% 99% 96%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 2,374 1,528 1,515 4,848
Marked 85,739 86,428 86,144 81,350
Loss rate 1.2% 0.8% 0.8% 1.4%
Throughput 99% 98% 98% 98%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 2,374 1,528 1,515 4,848
Marked 85,739 86,428 86,144 81,350
Loss rate 1.2% 0.8% 0.8% 1.4%
Throughput 99% 98% 98% 98%
Table 6: Simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in byte mode, queue in bytes
表6：平均流量大小为3kbytes、10Mbps链路、字节模式为红色、队列为字节的模拟
In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node B must have received an ECN-setup SYN packet from node A. However, it is possible that node A supports ECN, but either ignores the CE codepoint on received SYN/ACK packets, or ignores SYN/ACK packets with the ECT or CE codepoint set. If the TCP initiator ignores the CE codepoint on received SYN/ACK packets, this would mean that the TCP responder would not respond to this congestion indication. However, this seems to us an acceptable cost to pay in the incremental deployment of ECN-Capability for TCP's SYN/ACK packets. It would mean that the responder would not reduce the initial congestion window from two, three, or four segments down to one segment, as it should, and would not sent a non-ECN-Capable SYN/ACK packet to complete the SYN exchange. However, the TCP end nodes would still respond correctly to any subsequent CE indications on data packets later on in the connection.
为了使TCP节点B将SYN/ACK数据包作为ECN功能发送，节点B必须已从节点a接收到ECN setup SYN数据包。但是，节点a可能支持ECN，但忽略接收到的SYN/ACK数据包上的CE码点，或者忽略带有ECT或CE码点集的SYN/ACK数据包。如果TCP启动器忽略接收到的SYN/ACK数据包上的CE代码点，这将意味着TCP响应程序不会响应此拥塞指示。然而，在我们看来，为TCP的SYN/ACK数据包增量部署ECN功能所付出的成本是可以接受的。这意味着响应者不会像应该的那样将初始拥塞窗口从两个、三个或四个段减少到一个段，并且不会发送不支持ECN的SYN/ACK数据包来完成SYN交换。但是，TCP端节点仍将正确响应连接中稍后数据包上的任何后续CE指示。
Figure 4 shows an interchange with the SYN/ACK packet ECN-marked, but with the ECN mark ignored by the TCP originator.
图4显示了带有SYN/ACK数据包ECN标记的交换，但TCP发起人忽略了ECN标记。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT
<--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE
<--- ECN-setup SYN/ACK, ECT
<--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE
Data/ACK, No ECN-Echo --->
Data/ACK --->
<--- Data (up to four packets)
---------------------------------------------------------------
Data/ACK, No ECN-Echo --->
Data/ACK --->
<--- Data (up to four packets)
---------------------------------------------------------------
Figure 4: SYN exchange with the SYN/ACK packet marked, but with the ECN mark ignored by the TCP initiator
图4：标记了SYN/ACK数据包但TCP启动器忽略了ECN标记的SYN交换
Thus, to be explicit, when a TCP connection includes an initiator that supports ECN but *does not* support ECN-Capability for SYN/ACK packets, in combination with a responder that *does* support ECN-Capability for SYN/ACK packets, it is possible that the ECN-Capable SYN/ACK packets will be marked rather than dropped in the network, and that the responder will not learn about the ECN mark on the SYN/ACK packet. This would not be a problem if most packets from the
因此，明确地说，当TCP连接包括支持ECN但*不*支持SYN/ACK数据包的ECN能力的启动器时，结合*不*支持SYN/ACK数据包的ECN能力的响应器，有可能在网络中标记而不是丢弃支持ECN的SYN/ACK数据包，并且响应者不会了解SYN/ACK数据包上的ECN标记。如果大多数数据包来自
responder supporting ECN for SYN/ACK packets were in long-lived TCP connections, but it would be more problematic if most of the packets were from TCP connections consisting of four data packets, and the TCP responder for these connections was ready to send its data packets immediately after the SYN/ACK exchange. Of course, with *severe* congestion, the SYN/ACK packets would likely be dropped rather than ECN-marked at the congested router, preventing the TCP responder from adding to the congestion by sending its initial window of four data packets.
支持用于SYN/ACK数据包的ECN的响应程序位于长寿命TCP连接中，但如果大多数数据包来自由四个数据包组成的TCP连接，并且这些连接的TCP响应程序在SYN/ACK交换后立即准备发送其数据包，则问题会更大。当然，在*严重*拥塞的情况下，SYN/ACK数据包可能会被丢弃，而不是在拥塞的路由器上标记ECN，从而防止TCP响应程序通过发送其四个数据包的初始窗口来增加拥塞。
It is also possible that in some older TCP implementation, the initiator would ignore arriving SYN/ACK packets that had the ECT or CE codepoint set. This would result in a delay in connection setup for that TCP connection, with the initiator re-sending the SYN packet after a retransmission timeout. We are not aware of any TCP implementations with this behavior.
在一些较旧的TCP实现中，启动器也可能忽略已设置ECT或CE码点的到达SYN/ACK数据包。这将导致TCP连接的连接设置延迟，在重新传输超时后，启动器将重新发送SYN数据包。我们不知道有任何TCP实现具有这种行为。
One possibility for coping with problems of backwards compatibility would be for TCP initiators to use a TCP flag that means "I understand ECN-Capable SYN/ACK packets". If this document were to standardize the use of such an "ECN-SYN" flag, then the TCP responder would only send a SYN/ACK packet as ECN-Capable if the incoming SYN packet had the "ECN-SYN" flag set. An ECN-SYN flag would prevent the backwards compatibility problems described in the paragraphs above.
解决向后兼容性问题的一种可能性是TCP启动器使用TCP标志，表示“我了解支持ECN的SYN/ACK数据包”。如果本文件旨在标准化此类“ECN-SYN”标志的使用，则如果传入SYN数据包设置了“ECN-SYN”标志，则TCP响应程序仅将SYN/ACK数据包作为ECN功能发送。ECN-SYN标志将防止上述段落中描述的向后兼容性问题。
One drawback to the use of an ECN-SYN flag is that it would use one of the four remaining reserved bits in the TCP header for a transient backwards compatibility problem. This drawback is limited by the fact that the "ECN-SYN" flag would be defined only for use with ECN-setup SYN packets; that bit in the TCP header could be defined to have other uses for other kinds of TCP packets.
使用ECN-SYN标志的一个缺点是，它会使用TCP报头中剩余的四个保留位中的一个来解决暂时的向后兼容性问题。这一缺点受到以下事实的限制：“ECN-SYN”标志将被定义为仅用于ECN setup SYN数据包；TCP报头中的该位可以定义为对其他类型的TCP数据包具有其他用途。
Factors in deciding not to use an ECN-SYN flag include the following:
决定不使用ECN-SYN标志的因素包括：
(1) The limited installed base: At the time that this document was written, the TCP implementations in Microsoft Vista and Mac OS X included ECN, but ECN was not enabled by default [SBT07]. Thus, there was not a large deployed base of ECN-Capable TCP implementations. This limits the scope of any backwards compatibility problems.
(1) 有限的安装基数：在编写本文档时，Microsoft Vista和Mac OS X中的TCP实现包括ECN，但默认情况下未启用ECN[SBT07]。因此，支持ECN的TCP实现的部署基数不大。这限制了任何向后兼容性问题的范围。
(2) Limits to the scope of the problem: The backwards compatibility problem would not be serious enough to cause congestion collapse; with severe congestion, the buffer at the congested router will overflow, and the congested router will drop rather than ECN-mark
(2) 问题范围的限制：向后兼容性问题不会严重到导致拥塞崩溃；严重拥塞时，拥塞路由器处的缓冲区将溢出，拥塞路由器将下降而不是ECN标记
arriving SYN packets. Some active queue management mechanisms might switch from packet-marking to packet-dropping in times of high congestion before buffer overflow, as recommended in Section 19.1 of RFC 3168 [RFC3168]. This helps to prevent congestion collapse problems with the use of ECN.
到达SYN数据包。如RFC 3168[RFC3168]第19.1节所建议的，在缓冲区溢出之前出现高拥塞时，一些主动队列管理机制可能会从数据包标记切换到数据包丢弃。这有助于防止使用ECN时出现拥塞崩溃问题。
(3) Detection of and response to backwards-compatibility problems: A TCP responder such as a web server can't differentiate between a SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK packet that is ECN-marked, but where the ECN mark is ignored by the TCP initiator. However, a TCP responder *can* detect if a SYN/ACK packet is sent as ECN-capable and not reported as ECN-marked, but data packets are dropped or marked from the initial window of data. We will call this scenario "initial-window-congestion". If a web server frequently experienced initial-window-congestion (without SYN/ACK congestion), then the web server *might* be experiencing backwards compatibility problems with ECN-Capable SYN/ACK packets, and could respond by not sending SYN/ACK packets as ECN-Capable.
(3) 向后兼容性问题的检测和响应：TCP响应程序（如web服务器）无法区分网络中未标记ECN的SYN/ACK数据包和标记为ECN但TCP启动器忽略ECN标记的SYN/ACK数据包。然而，TCP响应程序*可以*检测SYN/ACK数据包是否作为ECN功能发送，而不是报告为ECN标记，但数据包是否从初始数据窗口丢弃或标记。我们将此场景称为“初始窗口拥塞”。如果web服务器经常遇到初始窗口拥塞（没有SYN/ACK拥塞），则web服务器*可能*遇到与支持ECN的SYN/ACK数据包的向后兼容性问题，并且可能通过不将SYN/ACK数据包作为支持ECN的数据包发送来响应。
Normative References
规范性引用文件
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[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月。
Informative References
资料性引用
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, SIGCOMM 2005.
[ECN+]A.Kuzmanovic，《明确拥塞通知的力量》，SIGCOMM 2005。
[ECN-SYN] ECN-SYN web page with simulation scripts, http://www.icir.org/floyd/ecn-syn.
[ECN-SYN]带有模拟脚本的ECN-SYN网页，http://www.icir.org/floyd/ecn-syn.
[F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to TCP SYN packets that are ECN-Capable?", August 2, 2007, email to the BEHAVE mailing list, http://www1.ietf.org/ mail-archive/web/behave/current/msg02644.html.
[F07]S.Floyd，“[BEHAVE]防火墙和中间盒对支持ECN的TCP SYN数据包的响应？”，2007年8月2日，通过电子邮件发送至BEHAVE邮件列表，http://www1.ietf.org/ 邮件存档/web/behave/current/msg02644.html。
[Kelson00] Dax Kelson, "8% of the Internet unreachable!", September 10, 2000, email to the Linux kernel mailing list, http://lkml.indiana.edu/hypermail/linux/kernel/ 0009.1/0329.html.
[Kelson00]Dax Kelson，“8%的互联网无法访问！”，2000年9月10日，电子邮件至Linux内核邮件列表，http://lkml.indiana.edu/hypermail/linux/kernel/ 0009.1/0329.html。
[L08] A. Landley, "Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-06.txt", August 24, 2008, email to the tcpm mailing list, http://www.ietf.org/ mail-archive/web/tcpm/current/msg03988.html.
[L08]A.Landley，“Re:[tcpm]I-D行动：草稿-ietf-tcpm-ecnsyn-06.txt”，2008年8月24日，通过电子邮件发送至tcpm邮件列表，http://www.ietf.org/ 邮件存档/web/tcpm/current/msg03988.html。
[MAF05] A. Medina, M. Allman, and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM CCR, April 2005.
[MAF05]A.Medina，M.Allman和S.Floyd，“测量互联网中传输协议的演变”，ACM CCR，2005年4月。
[PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, "On Designing Improved Controllers for AQM Routers Supporting TCP Flows", April 1998.
[PI]C.Hollot，V.Misra，W.Gong和D.Towsley，“关于为支持TCP流的AQM路由器设计改进的控制器”，1998年4月。
[RED] Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993.
[红色]Floyd，S.和Jacobson，V.，“用于避免拥塞的随机早期检测网关”，IEEE/ACM网络交易，第1卷第4期，1993年8月。
[REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, "REM: Active Queue Management", IEEE Network, May 2001.
[REM]S.Athuraliya，V.H.Li，S.H.Low和Q.Yin，“REM：主动队列管理”，IEEE网络，2001年5月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[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月。
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H.，和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]Floyd，S.，“不适当的TCP重置被认为是有害的”，BCP 60，RFC 3360，2002年8月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, "What TCP/IP Protocol Headers Can Tell us about the Web", SIGMETRICS, June 2001.
[SCJO01]F.Smith、F.Campos、K.Jeffay和D.Ott，“什么样的TCP/IP协议头可以告诉我们有关Web的信息”，SIGMETRICS，2001年6月。
[SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also <http://cr.yp.to/syncookies.html>.
[SYN-COOK]Dan J.Bernstein，SYN cookies，1997年，另见<http://cr.yp.to/syncookies.html>.
[SBT07] M. Sridharan, D. Bansal, and D. Thaler, "Implementation Report on Experiences with Various TCP RFCs", Presentation in the TSVAREA, IETF 68, March 2007. http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm.
[SBT07]M.Sridharan，D.Bansal和D.Thaler，“关于各种TCP RFC经验的实施报告”，在TSVAREA发表，IETF 68，2007年3月。http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm.
[Tools] S. Floyd, Ed., and E. Kohler, Ed., "Tools for the Evaluation of Simulation and Testbed Scenarios", Work in Progress, February 2008.
[工具]S.Floyd，Ed.和E.Kohler，Ed.，“模拟和试验台场景评估工具”，正在进行的工作，2008年2月。
Authors' Addresses
作者地址
Aleksandar Kuzmanovic Northwestern University
亚历山达尔·库兹曼诺维奇西北大学
Phone: +1 (847) 467-5519
EMail: akuzma@northwestern.edu
URL: http://cs.northwestern.edu/~akuzma
Phone: +1 (847) 467-5519
EMail: akuzma@northwestern.edu
URL: http://cs.northwestern.edu/~akuzma
Amit Mondal Northwestern University
Amit Mondal西北大学
Phone: +1 (847) 467-6455
EMail: a-mondal@northwestern.edu
URL: http://www.cs.northwestern.edu/~akm175/
Phone: +1 (847) 467-6455
EMail: a-mondal@northwestern.edu
URL: http://www.cs.northwestern.edu/~akm175/
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/
K. K. Ramakrishnan AT&T Labs Research Rm. A161 180 Park Ave. Florham Park, NJ 07932
罗摩克里希南AT&T实验室研究室。新泽西州弗洛勒姆公园公园大道180号A161 07932
Phone: +1 (973) 360-8764
EMail: kkrama@research.att.com
URL: http://www.research.att.com/info/kkrama
Phone: +1 (973) 360-8764
EMail: kkrama@research.att.com
URL: http://www.research.att.com/info/kkrama