Network Working Group J. Hadi Salim
Request for Comments: 2884 Nortel Networks
Category: Informational U. Ahmed
Carleton University
July 2000
Network Working Group J. Hadi Salim
Request for Comments: 2884 Nortel Networks
Category: Informational U. Ahmed
Carleton University
July 2000
Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks
IP网络中显式拥塞通知（ECN）的性能评估
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. ECN is an end-to-end congestion avoidance mechanism proposed by [6] and incorporated into RFC 2481[7]. We study the behavior of ECN for both bulk and transactional transfers. Our experiments show that there is improvement in throughput over NON ECN (TCP employing any of Reno, SACK/FACK or NewReno congestion control) in the case of bulk transfers and substantial improvement for transactional transfers.
本备忘录介绍了使用我们在Linux操作系统上的实现对TCP/IP协议中的显式拥塞通知（ECN）机制的性能研究。ECN是[6]提出的端到端拥塞避免机制，并纳入RFC 2481[7]。我们研究了批量传输和事务传输的ECN行为。我们的实验表明，在批量传输的情况下，与非ECN（TCP采用任何Reno、SACK/FACK或NewReno拥塞控制）相比，吞吐量有了提高，而事务传输的吞吐量有了实质性的提高。
A more complete pdf version of this document is available at:
http://www7.nortel.com:8080/CTL/ecnperf.pdf
A more complete pdf version of this document is available at:
http://www7.nortel.com:8080/CTL/ecnperf.pdf
This memo in its current revision is missing a lot of the visual representations and experimental results found in the pdf version.
这份备忘录在当前版本中缺少了很多pdf版本中的视觉表现和实验结果。
In current IP networks, congestion management is left to the protocols running on top of IP. An IP router when congested simply drops packets. TCP is the dominant transport protocol today [26]. TCP infers that there is congestion in the network by detecting packet drops (RFC 2581). Congestion control algorithms [11] [15] [21] are then invoked to alleviate congestion. TCP initially sends at a higher rate (slow start) until it detects a packet loss. A packet loss is inferred by the receipt of 3 duplicate ACKs or detected by a
在当前的IP网络中，拥塞管理由运行在IP之上的协议来完成。IP路由器在拥塞时只是丢弃数据包。TCP是当今主要的传输协议[26]。TCP通过检测数据包丢失来推断网络中存在拥塞（RFC 2581）。然后调用拥塞控制算法[11][15][21]来缓解拥塞。TCP最初以更高的速率（慢启动）发送，直到检测到数据包丢失。通过接收到3个重复的ack或通过
timeout. The sending TCP then moves into a congestion avoidance state where it carefully probes the network by sending at a slower rate (which goes up until another packet loss is detected). Traditionally a router reacts to congestion by dropping a packet in the absence of buffer space. This is referred to as Tail Drop. This method has a number of drawbacks (outlined in Section 2). These drawbacks coupled with the limitations of end-to-end congestion control have led to interest in introducing smarter congestion control mechanisms in routers. One such mechanism is Random Early Detection (RED) [9] which detects incipient congestion and implicitly signals the oversubscribing flow to slow down by dropping its packets. A RED-enabled router detects congestion before the buffer overflows, based on a running average queue size, and drops packets probabilistically before the queue actually fills up. The probability of dropping a new arriving packet increases as the average queue size increases above a low water mark minth, towards higher water mark maxth. When the average queue size exceeds maxth all arriving packets are dropped.
超时。然后，发送TCP进入拥塞避免状态，在该状态下，它通过以较慢的速率发送（直到检测到另一个数据包丢失为止）仔细地探测网络。传统上，路由器通过在没有缓冲空间的情况下丢弃数据包来应对拥塞。这被称为尾部下降。这种方法有许多缺点（在第2节中概述）。这些缺点加上端到端拥塞控制的局限性，使得人们有兴趣在路由器中引入更智能的拥塞控制机制。一种这样的机制是随机早期检测（RED）[9]，它检测初始拥塞，并通过丢弃数据包隐式地向超额订阅流发送信号，使其减速。启用RED的路由器根据运行的平均队列大小在缓冲区溢出之前检测拥塞，并在队列实际填满之前概率地丢弃数据包。丢弃新到达的数据包的概率随着平均队列大小增加而增加，超过低水位线minth，接近高水位线maxth。当平均队列大小超过maxth时，将丢弃所有到达的数据包。
An extension to RED is to mark the IP header instead of dropping packets (when the average queue size is between minth and maxth; above maxth arriving packets are dropped as before). Cooperating end systems would then use this as a signal that the network is congested and slow down. This is known as Explicit Congestion Notification (ECN). In this paper we study an ECN implementation on Linux for both the router and the end systems in a live network. The memo is organized as follows. In Section 2 we give an overview of queue management in routers. Section 3 gives an overview of ECN and the changes required at the router and the end hosts to support ECN. Section 4 defines the experimental testbed and the terminologies used throughout this memo. Section 5 introduces the experiments that are carried out, outlines the results and presents an analysis of the results obtained. Section 6 concludes the paper.
RED的扩展是标记IP头，而不是丢弃数据包（当平均队列大小介于minth和maxth之间时；超过maxth的到达数据包会像以前一样丢弃）。合作的终端系统将利用这一点作为网络拥塞和减速的信号。这称为显式拥塞通知（ECN）。在本文中，我们研究了在Linux上为实时网络中的路由器和终端系统实现ECN。备忘录的结构如下。在第2节中，我们将概述路由器中的队列管理。第3节概述了ECN以及路由器和终端主机支持ECN所需的更改。第4节定义了实验测试台和本备忘录中使用的术语。第5节介绍了进行的实验，概述了结果，并对获得的结果进行了分析。第6节总结全文。
TCP's congestion control and avoidance algorithms are necessary and powerful but are not enough to provide good service in all circumstances since they treat the network as a black box. Some sort of control is required from the routers to complement the end system congestion control mechanisms. More detailed analysis is contained in [19]. Queue management algorithms traditionally manage the length of packet queues in the router by dropping packets only when the buffer overflows. A maximum length for each queue is configured. The router will accept packets till this maximum size is exceeded, at which point it will drop incoming packets. New packets are accepted when buffer space allows. This technique is known as Tail Drop. This method has served the Internet well for years, but has the several drawbacks. Since all arriving packets (from all flows) are dropped
TCP的拥塞控制和避免算法是必要和强大的，但不足以在所有情况下提供良好的服务，因为它们将网络视为一个黑箱。路由器需要某种控制来补充终端系统拥塞控制机制。更详细的分析见[19]。队列管理算法传统上只在缓冲区溢出时丢弃数据包，从而管理路由器中数据包队列的长度。配置了每个队列的最大长度。路由器将接受数据包，直到超过此最大大小，此时它将丢弃传入的数据包。当缓冲区空间允许时，接受新数据包。这种技术被称为尾部下降。这种方法在互联网上应用多年，但也有一些缺点。因为所有到达的数据包（来自所有流）都被丢弃
when the buffer overflows, this interacts badly with the congestion control mechanism of TCP. A cycle is formed with a burst of drops after the maximum queue size is exceeded, followed by a period of underutilization at the router as end systems back off. End systems then increase their windows simultaneously up to a point where a burst of drops happens again. This phenomenon is called Global Synchronization. It leads to poor link utilization and lower overall throughput [19] Another problem with Tail Drop is that a single connection or a few flows could monopolize the queue space, in some circumstances. This results in a lock out phenomenon leading to synchronization or other timing effects [19]. Lastly, one of the major drawbacks of Tail Drop is that queues remain full for long periods of time. One of the major goals of queue management is to reduce the steady state queue size[19]. Other queue management techniques include random drop on full and drop front on full [13].
当缓冲区溢出时，这会与TCP的拥塞控制机制产生严重的交互作用。在超过最大队列大小后，会形成一个中断周期，然后随着终端系统的退出，路由器会出现一段时间的利用率不足。然后，终端系统同时增加其窗口，直到再次发生液滴爆发。这种现象称为全局同步。这会导致链路利用率低下和总体吞吐量降低[19]尾部下降的另一个问题是，在某些情况下，单个连接或几个流可能会垄断队列空间。这导致锁定现象，导致同步或其他计时效应[19]。最后，尾部下降的一个主要缺点是队列在很长一段时间内都是满的。队列管理的主要目标之一是减少稳态队列大小[19]。其他队列管理技术包括完全随机丢弃和完全正面丢弃[13]。
Active queue management mechanisms detect congestion before the queue overflows and provide an indication of this congestion to the end nodes [7]. With this approach TCP does not have to rely only on buffer overflow as the indication of congestion since notification happens before serious congestion occurs. One such active management technique is RED.
主动队列管理机制在队列溢出之前检测拥塞，并向终端节点提供该拥塞的指示[7]。使用这种方法，TCP不必仅依赖缓冲区溢出作为拥塞指示，因为通知发生在严重拥塞发生之前。红色就是这样一种主动管理技术。
Random Early Detection (RED) [9] is a congestion avoidance mechanism implemented in routers which works on the basis of active queue management. RED addresses the shortcomings of Tail Drop. A RED router signals incipient congestion to TCP by dropping packets probabilistically before the queue runs out of buffer space. This drop probability is dependent on a running average queue size to avoid any bias against bursty traffic. A RED router randomly drops arriving packets, with the result that the probability of dropping a packet belonging to a particular flow is approximately proportional to the flow's share of bandwidth. Thus, if the sender is using relatively more bandwidth it gets penalized by having more of its packets dropped. RED operates by maintaining two levels of thresholds minimum (minth) and maximum (maxth). It drops a packet probabilistically if and only if the average queue size lies between the minth and maxth thresholds. If the average queue size is above the maximum threshold, the arriving packet is always dropped. When the average queue size is between the minimum and the maximum threshold, each arriving packet is dropped with probability pa, where pa is a function of the average queue size. As the average queue length varies between minth and maxth, pa increases linearly towards a configured maximum drop probability, maxp. Beyond maxth, the drop
随机早期检测（RED）[9]是路由器中实现的一种拥塞避免机制，它基于主动队列管理。红色解决了尾部下降的缺点。红色路由器通过在队列耗尽缓冲区空间之前概率地丢弃数据包，向TCP发出初始拥塞信号。此丢弃概率取决于运行平均队列大小，以避免对突发流量的任何偏见。红色路由器随机丢弃到达的数据包，其结果是丢弃属于特定流的数据包的概率与该流的带宽份额近似成比例。因此，如果发送方使用了相对更多的带宽，那么它就会被丢弃更多的数据包。RED通过维持两级阈值最小值（minth）和最大值（maxth）来运行。当且仅当平均队列大小介于minth和maxth阈值之间时，它才有可能丢弃数据包。如果平均队列大小高于最大阈值，则到达的数据包总是被丢弃。当平均队列大小在最小和最大阈值之间时，每个到达的分组以概率pa丢弃，其中pa是平均队列大小的函数。当平均队列长度在minth和maxth之间变化时，pa会向配置的最大丢弃概率maxp线性增加。在maxth之外，下降
probability is 100%. Dropping packets in this way ensures that when some subset of the source TCP packets get dropped and they invoke congestion avoidance algorithms that will ease the congestion at the gateway. Since the dropping is distributed across flows, the problem of global synchronization is avoided.
概率是100%。以这种方式丢弃数据包可确保当源TCP数据包的某些子集被丢弃时，它们会调用拥塞避免算法，以缓解网关的拥塞。由于丢弃是跨流分布的，因此避免了全局同步问题。
Explicit Congestion Notification is an extension proposed to RED which marks a packet instead of dropping it when the average queue size is between minth and maxth [7]. Since ECN marks packets before congestion actually occurs, this is useful for protocols like TCP that are sensitive to even a single packet loss. Upon receipt of a congestion marked packet, the TCP receiver informs the sender (in the subsequent ACK) about incipient congestion which will in turn trigger the congestion avoidance algorithm at the sender. ECN requires support from both the router as well as the end hosts, i.e. the end hosts TCP stack needs to be modified. Packets from flows that are not ECN capable will continue to be dropped by RED (as was the case before ECN).
显式拥塞通知是向RED提出的一个扩展，当平均队列大小介于minth和maxth之间时，它标记数据包而不是丢弃数据包[7]。由于ECN在拥塞实际发生之前标记数据包，这对于像TCP这样对单个数据包丢失敏感的协议非常有用。在收到拥塞标记的数据包后，TCP接收方（在随后的ACK中）通知发送方初始拥塞，这将反过来触发发送方的拥塞避免算法。ECN需要路由器和终端主机的支持，即终端主机TCP堆栈需要修改。来自不支持ECN的流的数据包将继续被RED丢弃（与ECN之前的情况相同）。
Router side support for ECN can be added by modifying current RED implementations. For packets from ECN capable hosts, the router marks the packets rather than dropping them (if the average queue size is between minth and maxth). It is necessary that the router identifies that a packet is ECN capable, and should only mark packets that are from ECN capable hosts. This uses two bits in the IP header. The ECN Capable Transport (ECT) bit is set by the sender end system if both the end systems are ECN capable (for a unicast transport, only if both end systems are ECN-capable). In TCP this is confirmed in the pre-negotiation during the connection setup phase (explained in Section 3.2). Packets encountering congestion are marked by the router using the Congestion Experienced (CE) (if the average queue size is between minth and maxth) on their way to the receiver end system (from the sender end system), with a probability proportional to the average queue size following the procedure used in RED (RFC2309) routers. Bits 10 and 11 in the IPV6 header are proposed respectively for the ECT and CE bits. Bits 6 and 7 of the IPV4 header DSCP field are also specified for experimental purposes for the ECT and CE bits respectively.
通过修改当前的RED实现，可以添加对ECN的路由器端支持。对于来自支持ECN的主机的数据包，路由器标记数据包而不是丢弃它们（如果平均队列大小介于minth和maxth之间）。路由器必须识别具有ECN能力的数据包，并且只标记来自具有ECN能力的主机的数据包。这在IP报头中使用两位。如果两个端系统都支持ECN（对于单播传输，仅当两个端系统都支持ECN时），则发送方端系统将设置支持ECN的传输（ECT）位。在TCP中，这在连接设置阶段的预协商中得到确认（在第3.2节中解释）。遇到拥塞的数据包由路由器在到达接收端系统（从发送方端系统）的途中使用所经历的拥塞（CE）（如果平均队列大小在minth和maxth之间）进行标记，概率与RED（RFC2309）路由器中使用的过程后的平均队列大小成比例。IPV6报头中的比特10和11分别用于ECT和CE比特。IPV4报头DSCP字段的第6位和第7位也分别指定用于ECT和CE位的实验目的。
The proposal to add ECN to TCP specifies two new flags in the reserved field of the TCP header. Bit 9 in the reserved field of the TCP header is designated as the ECN-Echo (ECE) flag and Bit 8 is
向TCP添加ECN的建议在TCP头的保留字段中指定了两个新标志。TCP报头保留字段中的位9被指定为ECN Echo（ECE）标志，位8被指定为
designated as the Congestion Window Reduced (CWR) flag. These two bits are used both for the initializing phase in which the sender and the receiver negotiate the capability and the desire to use ECN, as well as for the subsequent actions to be taken in case there is congestion experienced in the network during the established state.
指定为拥塞窗口减少（CWR）标志。这两个比特既用于发送方和接收方协商使用ECN的能力和愿望的初始化阶段，也用于在建立状态期间网络发生拥塞时采取的后续行动。
There are two main changes that need to be made to add ECN to TCP to an end system and one extension to a router running RED.
要将ECN添加到终端系统的TCP和运行RED的路由器的一个扩展，需要进行两个主要更改。
1. In the connection setup phase, the source and destination TCPs have to exchange information about their desire and/or capability to use ECN. This is done by setting both the ECN-Echo flag and the CWR flag in the SYN packet of the initial connection phase by the sender; on receipt of this SYN packet, the receiver will set the ECN-Echo flag in the SYN-ACK response. Once this agreement has been reached, the sender will thereon set the ECT bit in the IP header of data packets for that flow, to indicate to the network that it is capable and willing to participate in ECN. The ECT bit is set on all packets other than pure ACK's.
1. 在连接设置阶段，源TCP和目标TCP必须交换有关其使用ECN的愿望和/或能力的信息。这是通过发送方在初始连接阶段的SYN分组中设置ECN Echo标志和CWR标志来实现的；在接收到此SYN数据包时，接收器将在SYN-ACK响应中设置ECN Echo标志。一旦达成该协议，发送方将在该流的数据包的IP报头中设置ECT位，以向网络表明其能够并愿意参与ECN。ECT位设置在除纯ACK之外的所有数据包上。
2. When a router has decided from its active queue management mechanism, to drop or mark a packet, it checks the IP-ECT bit in the packet header. It sets the CE bit in the IP header if the IP-ECT bit is set. When such a packet reaches the receiver, the receiver responds by setting the ECN-Echo flag (in the TCP header) in the next outgoing ACK for the flow. The receiver will continue to do this in subsequent ACKs until it receives from the sender an indication that it (the sender) has responded to the congestion notification.
2. 当路由器根据其主动队列管理机制决定丢弃或标记数据包时，它会检查数据包头中的IP-ECT位。如果设置了IP-ECT位，则在IP报头中设置CE位。当这样的数据包到达接收方时，接收方通过在流的下一个传出ACK中设置ECN Echo标志（在TCP报头中）进行响应。接收方将在随后的ack中继续执行此操作，直到从发送方收到其（发送方）已响应拥塞通知的指示为止。
3. Upon receipt of this ACK, the sender triggers its congestion avoidance algorithm by halving its congestion window, cwnd, and updating its congestion window threshold value ssthresh. Once it has taken these appropriate steps, the sender sets the CWR bit on the next data outgoing packet to tell the receiver that it has reacted to the (receiver's) notification of congestion. The receiver reacts to the CWR by halting the sending of the congestion notifications (ECE) to the sender if there is no new congestion in the network.
3. 在收到该ACK后，发送方通过将其拥塞窗口cwnd减半并更新其拥塞窗口阈值ssthresh来触发其拥塞避免算法。一旦采取了这些适当的步骤，发送方就在下一个数据传出包上设置CWR位，以告诉接收方它已经对（接收方的）拥塞通知做出了反应。如果网络中没有新的拥塞，则接收方通过停止向发送方发送拥塞通知（ECE）来对CWR作出反应。
Note that the sender reaction to the indication of congestion in the network (when it receives an ACK packet that has the ECN-Echo flag set) is equivalent to the Fast Retransmit/Recovery algorithm (when there is a congestion loss) in NON-ECN-capable TCP i.e. the sender halves the congestion window cwnd and reduces the slow start threshold ssthresh. Fast Retransmit/Recovery is still available for ECN capable stacks for responding to three duplicate acknowledgments.
注意，发送方对网络拥塞指示的反应（当其接收到设置了ECN Echo标志的ACK数据包时）等同于快速重传/恢复算法（当存在拥塞丢失时）在不支持ECN的TCP中，即发送方将拥塞窗口cwnd减半，并降低慢启动阈值ssthresh。对于能够响应三个重复确认的ECN堆栈，仍然可以使用快速重传/恢复。
For testing purposes we have added ECN to the Linux TCP/IP stack, kernels version 2.0.32. 2.2.5, 2.3.43 (there were also earlier revisions of 2.3 which were tested). The 2.0.32 implementation conforms to RFC 2481 [7] for the end systems only. We have also modified the code in the 2.1,2.2 and 2.3 cases for the router portion as well as end system to conform to the RFC. An outdated version of the 2.0 code is available at [18]. Note Linux version 2.0.32 implements TCP Reno congestion control while kernels >= 2.2.0 default to New Reno but will opt for a SACK/FACK combo when the remote end understands SACK. Our initial tests were carried out with the 2.0 kernel at the end system and 2.1 (pre 2.2) for the router part. The majority of the test results here apply to the 2.0 tests. We did repeat these tests on a different testbed (move from Pentium to Pentium-II class machines)with faster machines for the 2.2 and 2.3 kernels, so the comparisons on the 2.0 and 2.2/3 are not relative.
出于测试目的，我们将ECN添加到Linux TCP/IP堆栈内核版本2.0.32中。2.2.5、2.3.43（还测试了2.3的早期版本）。2.0.32实施仅符合终端系统的RFC 2481[7]。我们还修改了路由器部分以及终端系统的2.1、2.2和2.3案例中的代码，以符合RFC。[18]提供了2.0代码的过时版本。注意：Linux版本2.0.32实现TCP Reno拥塞控制，而内核>=2.2.0默认为New Reno，但当远程端理解SACK时，将选择SACK/FACK组合。我们的初始测试是在终端系统使用2.0内核，路由器部分使用2.1（2.2之前）进行的。此处的大多数测试结果适用于2.0测试。对于2.2和2.3内核，我们在不同的测试平台（从奔腾到奔腾II类机器）上使用更快的机器重复了这些测试，因此2.0和2.2/3的比较不是相对的。
We have updated this memo release to reflect the tests against SACK and New Reno.
我们已经更新了这份备忘录，以反映对萨克和新雷诺的测试。
----- ----
| ECN | | ECN |
| ON | | OFF |
data direction ---->> ----- ----
| |
server | |
---- ------ ------ | |
| | | R1 | | R2 | | |
| | -----| | ---- | | ----------------------
---- ------ ^ ------ |
^ |
| -----
congestion point ___| | C |
| |
-----
----- ----
| ECN | | ECN |
| ON | | OFF |
data direction ---->> ----- ----
| |
server | |
---- ------ ------ | |
| | | R1 | | R2 | | |
| | -----| | ---- | | ----------------------
---- ------ ^ ------ |
^ |
| -----
congestion point ___| | C |
| |
-----
The figure above shows our test setup.
上图显示了我们的测试设置。
All the physical links are 10Mbps ethernet. Using Class Based Queuing (CBQ) [22], packets from the data server are constricted to a 1.5Mbps pipe at the router R1. Data is always retrieved from the server towards the clients labelled , "ECN ON", "ECN OFF", and "C". Since the pipe from the server is 10Mbps, this creates congestion at the exit from the router towards the clients for competing flows. The machines labeled "ECN ON" and "ECN OFF" are running the same version
所有物理链路均为10Mbps以太网。使用基于类的队列（CBQ）[22]，来自数据服务器的数据包被压缩到路由器R1处的1.5Mbps管道。数据总是从服务器向标有“ECN ON”、“ECN OFF”和“C”的客户端检索。由于来自服务器的管道为10Mbps，这会在从路由器到客户端的出口处造成拥塞，从而产生竞争流。标有“ECN ON”和“ECN OFF”的机器运行的是同一版本
of Linux and have exactly the same hardware configuration. The server is always ECN capable (and can handle NON ECN flows as well using the standard congestion algorithms). The machine labeled "C" is used to create congestion in the network. Router R2 acts as a path-delay controller. With it we adjust the RTT the clients see. Router R1 has RED implemented in it and has capability for supporting ECN flows. The path-delay router is a PC running the Nistnet [16] package on a Linux platform. The latency of the link for the experiments was set to be 20 millisecs.
具有完全相同的硬件配置。服务器始终支持ECN（并且可以使用标准拥塞算法处理非ECN流）。标记为“C”的机器用于在网络中造成拥塞。路由器R2充当路径延迟控制器。通过它，我们可以调整客户看到的RTT。路由器R1中实现了RED，并具有支持ECN流的能力。路径延迟路由器是一台在Linux平台上运行NISNET[16]包的PC。实验链路的延迟设置为20毫秒。
We spent time validating that the implementation was conformant to the specification in RFC 2481. To do this, the popular tcpdump sniffer [24] was modified to show the packets being marked. We visually inspected tcpdump traces to validate the conformance to the RFC under a lot of different scenarios. We also modified tcptrace [25] in order to plot the marked packets for visualization and analysis.
我们花时间验证实现是否符合RFC2481中的规范。为此，对流行的tcpdump嗅探器[24]进行了修改，以显示标记的数据包。我们目视检查了tcpdump跟踪，以验证在许多不同场景下与RFC的一致性。我们还修改了tcptrace[25]，以便绘制标记的数据包，以便可视化和分析。
Both tcpdump and tcptrace revealed that the implementation was conformant to the RFC.
tcpdump和tcptrace都表明实现符合RFC。
This section presents background terminology used in the next few sections.
本节介绍了接下来几节中使用的背景术语。
* Congesting flows: These are TCP flows that are started in the background so as to create congestion from R1 towards R2. We use the laptop labeled "C" to introduce congesting flows. Note that "C" as is the case with the other clients retrieves data from the server.
* 拥塞流：这些是在后台启动的TCP流，用于创建从R1到R2的拥塞。我们使用标有“C”的笔记本电脑来引入拥挤的流量。请注意，“C”与其他客户端一样，从服务器检索数据。
* Low, Moderate and High congestion: For the case of low congestion we start two congesting flows in the background, for moderate congestion we start five congesting flows and for the case of high congestion we start ten congesting flows in the background.
* 低、中、高拥塞：对于低拥塞，我们在后台启动两个拥塞流；对于中等拥塞，我们启动五个拥塞流；对于高拥塞，我们在后台启动十个拥塞流。
* Competing flows: These are the flows that we are interested in. They are either ECN TCP flows from/to "ECN ON" or NON ECN TCP flows from/to "ECN OFF".
* 竞争流：这些是我们感兴趣的流。它们是从/到“ECN ON”的ECN TCP流或从/到“ECN OFF”的非ECN TCP流。
* Maximum drop rate: This is the RED parameter that sets the maximum probability of a packet being marked at the router. This corresponds to maxp as explained in Section 2.1.
* 最大丢弃率：这是红色参数，用于设置在路由器上标记数据包的最大概率。这对应于第2.1节中解释的maxp。
Our tests were repeated for varying levels of congestion with varying maximum drop rates. The results are presented in the subsequent sections.
我们对不同程度的拥堵和不同的最大下降率进行了重复测试。结果将在后续章节中介绍。
* Low, Medium and High drop probability: We use the term low probability to mean a drop probability maxp of 0.02, medium probability for 0.2 and high probability for 0.5. We also experimented with drop probabilities of 0.05, 0.1 and 0.3.
* 低、中、高跌落概率：我们使用术语“低概率”表示跌落概率maxp为0.02，中概率为0.2，高概率为0.5。我们还试验了0.05、0.1和0.3的下降概率。
* Goodput: We define goodput as the effective data rate as observed by the user, i.e., if we transmitted 4 data packets in which two of them were retransmitted packets, the efficiency is 50% and the resulting goodput is 2*packet size/time taken to transmit.
* Goodput：我们将Goodput定义为用户观察到的有效数据速率，即，如果我们发送了4个数据包，其中两个数据包是重传的，则效率为50%，产生的Goodput为2*数据包大小/传输时间。
* RED Region: When the router's average queue size is between minth and maxth we denote that we are operating in the RED region.
* 红色区域：当路由器的平均队列大小介于minth和maxth之间时，表示我们在红色区域中运行。
In our initial testing we noticed that as we increase the number of congesting flows the RED queue degenerates into a simple Tail Drop queue. i.e. the average queue exceeds the maximum threshold most of the times. Note that this phenomena has also been observed by [5] who proposes a dynamic solution to alleviate it by adjusting the packet dropping probability "maxp" based on the past history of the average queue size. Hence, it is necessary that in the course of our experiments the router operate in the RED region, i.e., we have to make sure that the average queue is maintained between minth and maxth. If this is not maintained, then the queue acts like a Tail Drop queue and the advantages of ECN diminish. Our goal is to validate ECN's benefits when used with RED at the router. To ensure that we were operating in the RED region we monitored the average queue size and the actual queue size in times of low, moderate and high congestion and fine-tuned the RED parameters such that the average queue zones around the RED region before running the experiment proper. Our results are, therefore, not influenced by operating in the wrong RED region.
在我们的初始测试中，我们注意到，随着拥塞流数量的增加，红色队列退化为一个简单的尾部丢弃队列。i、 e.平均队列在大多数情况下超过最大阈值。请注意，[5]也观察到了这种现象，他提出了一种动态解决方案，通过基于平均队列大小的过去历史调整分组丢弃概率“maxp”来缓解这种现象。因此，在我们的实验过程中，路由器必须在红色区域运行，也就是说，我们必须确保平均队列保持在minth和maxth之间。如果不保持这一点，那么队列就像尾部丢弃队列一样，ECN的优势就会减弱。我们的目标是验证ECN在路由器上与RED一起使用时的优势。为了确保我们在红色区域内运行，我们在低、中、高拥塞情况下监控平均队列大小和实际队列大小，并微调红色参数，以便在正常运行实验之前，红色区域周围的平均队列区域。因此，我们的结果不受错误红色区域操作的影响。
We start by making sure that the background flows do not bias our results by computing the fairness index [12] in Section 5.1. We proceed to carry out the experiments for bulk transfer presenting the results and analysis in Section 5.2. In Section 5.3 the results for transactional transfers along with analysis is presented. More details on the experimental results can be found in [27].
我们首先通过计算第5.1节中的公平性指数[12]，确保背景流不会影响我们的结果。我们继续进行批量转移实验，结果和分析见第5.2节。第5.3节介绍了事务传输的结果和分析。有关实验结果的更多详细信息，请参见[27]。
In the course of the experiments we wanted to make sure that our choice of the type of background flows does not bias the results that we collect. Hence we carried out some tests initially with both ECN and NON ECN flows as the background flows. We repeated the experiments for different drop probabilities and calculated the fairness index [12]. We also noticed (when there were equal number of ECN and NON ECN flows) that the number of packets dropped for the NON ECN flows was equal to the number of packets marked for the ECN flows, showing thereby that the RED algorithm was fair to both kind of flows.
在实验过程中，我们希望确保我们对背景流类型的选择不会影响我们收集的结果。因此，我们最初使用ECN和非ECN流作为背景流进行了一些测试。我们针对不同的丢弃概率重复了实验，并计算了公平性指数[12]。我们还注意到（当ECN流和非ECN流的数量相等时），非ECN流丢弃的数据包数量等于为ECN流标记的数据包数量，从而表明RED算法对这两种流都是公平的。
Fairness index: The fairness index is a performance metric described in [12]. Jain [12] postulates that the network is a multi-user system, and derives a metric to see how fairly each user is treated. He defines fairness as a function of the variability of throughput across users. For a given set of user throughputs (x1, x2...xn), the fairness index to the set is defined as follows:
公平性指数：公平性指数是[12]中描述的性能指标。Jain[12]假设网络是一个多用户系统，并推导出一个衡量标准，以了解如何公平对待每个用户。他将公平性定义为用户吞吐量变化的函数。对于给定的一组用户吞吐量（x1、x2…xn），该组的公平性指数定义如下：
f(x1,x2,.....,xn) = square((sum[i=1..n]xi))/(n*sum[i=1..n]square(xi))
f(x1,x2,.....,xn) = square((sum[i=1..n]xi))/(n*sum[i=1..n]square(xi))
The fairness index always lies between 0 and 1. A value of 1 indicates that all flows got exactly the same throughput. Each of the tests was carried out 10 times to gain confidence in our results. To compute the fairness index we used FTP to generate traffic.
公平性指数始终介于0和1之间。值为1表示所有流的吞吐量完全相同。每项测试都进行了10次，以获得对我们结果的信心。为了计算公平性指数，我们使用FTP生成流量。
Experiment details: At time t = 0 we start 2 NON ECN FTP sessions in the background to create congestion. At time t=20 seconds we start two competing flows. We note the throughput of all the flows in the network and calculate the fairness index. The experiment was carried out for various maximum drop probabilities and for various congestion levels. The same procedure is repeated with the background flows as ECN. The fairness index was fairly constant in both the cases when the background flows were ECN and NON ECN indicating that there was no bias when the background flows were either ECN or NON ECN.
实验细节：在时间t=0时，我们在后台启动2个非ECN FTP会话以创建拥塞。在时间t=20秒时，我们开始两个竞争流。我们记录网络中所有流的吞吐量，并计算公平性指数。实验针对不同的最大掉线概率和不同的拥塞水平进行。对背景流重复相同的过程，如ECN。当背景流为ECN和非ECN时，公平性指数在这两种情况下都相当恒定，这表明当背景流为ECN或非ECN时没有偏差。
Max Fairness Fairness Drop With BG With BG Prob flows ECN flows NON ECN
具有BG Prob的BG的最大公平性下降流ECN流非ECN
0.02 0.996888 0.991946 0.05 0.995987 0.988286 0.1 0.985403 0.989726 0.2 0.979368 0.983342
0.02 0.996888 0.991946 0.05 0.995987 0.988286 0.1 0.985403 0.989726 0.2 0.979368 0.983342
With the observation that the nature of background flows does not alter the results, we proceed by using the background flows as NON ECN for the rest of the experiments.
在观察到背景流的性质不会改变结果的情况下，我们继续使用背景流作为非ECN进行其余实验。
The metric we chose for bulk transfer is end user throughput.
我们为批量传输选择的指标是最终用户吞吐量。
Experiment Details: All TCP flows used are RENO TCP. For the case of low congestion we start 2 FTP flows in the background at time 0. Then after about 20 seconds we start the competing flows, one data transfer to the ECN machine and the second to the NON ECN machine. The size of the file used is 20MB. For the case of moderate congestion we start 5 FTP flows in the background and for the case of high congestion we start 10 FTP flows in the background. We repeat the experiments for various maximum drop rates each repeated for a number of sets.
实验细节：使用的所有TCP流都是RENO TCP。对于低拥塞的情况，我们在时间0时在后台启动2个FTP流。然后大约20秒后，我们开始竞争流，一个数据传输到ECN机器，另一个传输到非ECN机器。使用的文件大小为20MB。对于中等拥塞的情况，我们在后台启动5个FTP流；对于高拥塞的情况，我们在后台启动10个FTP流。我们对不同的最大跌落率重复实验，每次重复多次。
Observation and Analysis:
观察和分析：
We make three key observations:
我们提出了三个关键意见：
1) As the congestion level increases, the relative advantage for ECN increases but the absolute advantage decreases (expected, since there are more flows competing for the same link resource). ECN still does better than NON ECN even under high congestion. Infering a sample from the collected results: at maximum drop probability of 0.1, for example, the relative advantage of ECN increases from 23% to 50% as the congestion level increases from low to high.
1) 随着拥塞级别的增加，ECN的相对优势增加，但绝对优势减少（预期，因为有更多的流竞争相同的链路资源）。即使在高拥塞情况下，ECN仍然比非ECN做得更好。从收集的结果推断样本：例如，在最大下降概率为0.1的情况下，随着拥堵程度从低到高的增加，ECN的相对优势从23%增加到50%。
2) Maintaining congestion levels and varying the maximum drop probability (MDP) reveals that the relative advantage of ECN increases with increasing MDP. As an example, for the case of high congestion as we vary the drop probability from 0.02 to 0.5 the relative advantage of ECN increases from 10% to 60%.
2) 维持拥塞水平和改变最大丢弃概率（MDP）表明，ECN的相对优势随着MDP的增加而增加。例如，对于高拥塞情况，当我们将丢弃概率从0.02更改为0.5时，ECN的相对优势从10%增加到60%。
3) There were hardly any retransmissions for ECN flows (except the occasional packet drop in a minority of the tests for the case of high congestion and low maximum drop probability).
3) ECN流几乎没有任何重传（除了少数测试中在高拥塞和低最大丢包概率的情况下偶尔丢包）。
We analyzed tcpdump traces for NON ECN with the help of tcptrace and observed that there were hardly any retransmits due to timeouts. (Retransmit due to timeouts are inferred by counting the number of 3 DUPACKS retransmit and subtracting them from the total recorded number of retransmits). This means that over a long period of time (as is the case of long bulk transfers), the data-driven loss recovery mechanism of the Fast Retransmit/Recovery algorithm is very effective. The algorithm for ECN on congestion notification from ECE
我们在tcptrace的帮助下分析了非ECN的tcpdump跟踪，发现由于超时几乎没有任何重传。（由于超时而导致的重新传输是通过计算3个重复包的重新传输次数并从记录的总重新传输次数中减去它们来推断的）。这意味着在很长一段时间内（如长批量传输），快速重传/恢复算法的数据驱动的丢失恢复机制非常有效。ECE拥塞通知的ECN算法
is the same as that for a Fast Retransmit for NON ECN. Since both are operating in the RED region, ECN barely gets any advantage over NON ECN from the signaling (packet drop vs. marking).
与非ECN的快速重传相同。由于两者都在红色区域运行，因此ECN几乎没有从信令（丢包与标记）中获得任何优于非ECN的优势。
It is clear, however, from the results that ECN flows benefit in bulk transfers. We believe that the main advantage of ECN for bulk transfers is that less time is spent recovering (whereas NON ECN spends time retransmitting), and timeouts are avoided altogether. [23] has shown that even with RED deployed, TCP RENO could suffer from multiple packet drops within the same window of data, likely to lead to multiple congestion reactions or timeouts (these problems are alleviated by ECN). However, while TCP Reno has performance problems with multiple packets dropped in a window of data, New Reno and SACK have no such problems.
然而，从结果中可以清楚地看出，ECN流在批量传输中受益。我们认为，ECN用于批量传输的主要优点是，恢复所花费的时间更少（而非ECN用于重新传输），并且完全避免了超时。[23]已经表明，即使部署了RED，TCP RENO也可能在同一数据窗口内遭受多个数据包丢失，可能导致多个拥塞反应或超时（这些问题通过ECN得到缓解）。然而，尽管TCP Reno在一个数据窗口中丢弃多个数据包时存在性能问题，但New Reno和SACK没有此类问题。
Thus, for scenarios with very high levels of congestion, the advantages of ECN for TCP Reno flows could be more dramatic than the advantages of ECN for NewReno or SACK flows. An important observation to make from our results is that we do not notice multiple drops within a single window of data. Thus, we would expect that our results are not heavily influenced by Reno's performance problems with multiple packets dropped from a window of data. We repeated these tests with ECN patched newer Linux kernels. As mentioned earlier these kernels would use a SACK/FACK combo with a fallback to New Reno. SACK can be selectively turned off (defaulting to New Reno). Our results indicate that ECN still improves performance for the bulk transfers. More results are available in the pdf version[27]. As in 1) above, maintaining a maximum drop probability of 0.1 and increasing the congestion level, it is observed that ECN-SACK improves performance from about 5% at low congestion to about 15% at high congestion. In the scenario where high congestion is maintained and the maximum drop probability is moved from 0.02 to 0.5, the relative advantage of ECN-SACK improves from 10% to 40%. Although this numbers are lower than the ones exhibited by Reno, they do reflect the improvement that ECN offers even in the presence of robust recovery mechanisms such as SACK.
因此，对于拥塞水平非常高的场景，ECN对于TCP Reno流的优势可能比ECN对于NewReno或SACK流的优势更为显著。从我们的结果中可以观察到的一个重要现象是，我们没有注意到在单个数据窗口中出现多个液滴。因此，我们希望我们的结果不会受到Reno的性能问题的严重影响，即从一个数据窗口丢弃多个数据包。我们使用经过ECN修补的较新Linux内核重复了这些测试。如前所述，这些内核将使用SACK/FACK组合，并返回到New Reno。可以有选择地关闭SACK（默认为New Reno）。我们的结果表明，ECN仍然可以提高批量传输的性能。更多结果见pdf版本[27]。如上1）所述，保持最大丢弃概率为0.1并提高拥塞水平，可以观察到ECN-SACK将性能从低拥塞时的约5%提高到高拥塞时的约15%。在维持高拥塞且最大丢弃概率从0.02移动到0.5的情况下，ECN-SACK的相对优势从10%提高到40%。尽管这一数字低于雷诺公司所展示的数字，但它们确实反映了ECN即使在存在SACK等稳健恢复机制的情况下所提供的改进。
We model transactional transfers by sending a small request and getting a response from a server before sending the next request. To generate transactional transfer traffic we use Netperf [17] with the CRR (Connect Request Response) option. As an example let us assume that we are retrieving a small file of say 5 - 20 KB, then in effect we send a small request to the server and the server responds by sending us the file. The transaction is complete when we receive the complete file. To gain confidence in our results we carry the simulation for about one hour. For each test there are a few thousand
我们通过发送一个小请求并在发送下一个请求之前从服务器获得响应来模拟事务传输。为了生成事务传输流量，我们使用Netperf[17]和CRR（连接请求-响应）选项。作为一个例子，让我们假设我们正在检索一个5-20KB的小文件，然后实际上我们向服务器发送一个小请求，服务器通过向我们发送该文件进行响应。当我们收到完整的文件时，交易完成。为了对我们的结果有信心，我们进行了大约一个小时的模拟。每个测试有几千个
of these requests and responses taking place. Although not exactly modeling HTTP 1.0 traffic, where several concurrent sessions are opened, Netperf-CRR is nevertheless a close approximation. Since Netperf-CRR waits for one connection to complete before opening the next one (0 think time), that single connection could be viewed as the slowest response in the set of the opened concurrent sessions (in HTTP). The transactional data sizes were selected based on [2] which indicates that the average web transaction was around 8 - 10 KB; The smaller (5KB) size was selected to guestimate the size of transactional processing that may become prevalent with policy management schemes in the diffserv [4] context. Using Netperf we are able to initiate these kind of transactional transfers for a variable length of time. The main metric of interest in this case is the transaction rate, which is recorded by Netperf.
这些请求和响应中的一部分正在发生。虽然不能精确地建模HTTP 1.0流量，其中打开了多个并发会话，但Netperf CRR仍然是一个近似值。由于Netperf CRR在打开下一个连接（0思考时间）之前等待一个连接完成，因此可以将该连接视为已打开的并发会话集中（HTTP中）响应最慢的连接。事务数据大小是根据[2]选择的，这表明平均web事务大小约为8-10KB；选择较小的（5KB）大小是为了对事务处理的大小进行量化，这可能在diffserv[4]上下文中的策略管理方案中很普遍。使用Netperf，我们能够在可变的时间长度内启动此类事务传输。在这种情况下，主要的利率指标是交易率，由Netperf记录。
* Define Transaction rate as: The number of requests and complete responses for a particular requested size that we are able to do per second. For example if our request is of 1KB and the response is 5KB then we define the transaction rate as the number of such complete transactions that we can accomplish per second.
* 将事务速率定义为：我们每秒能够完成的特定请求大小的请求数和完整响应数。例如，如果我们的请求为1KB，响应为5KB，那么我们将事务速率定义为每秒可以完成的完整事务数。
Experiment Details: Similar to the case of bulk transfers we start the background FTP flows to introduce the congestion in the network at time 0. About 20 seconds later we start the transactional transfers and run each test for three minutes. We record the transactions per second that are complete. We repeat the test for about an hour and plot the various transactions per second, averaged out over the runs. The experiment is repeated for various maximum drop probabilities, file sizes and various levels of congestion.
实验细节：与批量传输的情况类似，我们启动后台FTP流以在时间0时引入网络拥塞。大约20秒后，我们开始事务传输，并运行每个测试三分钟。我们记录每秒完成的事务。我们重复测试大约一个小时，并绘制每秒的各种事务，在运行过程中求出平均值。对于不同的最大丢弃概率、文件大小和不同程度的拥塞，重复该实验。
Observation and Analysis
观察与分析
There are three key observations:
有三个关键的观察结果：
1) As congestion increases (with fixed drop probability) the relative advantage for ECN increases (again the absolute advantage does not increase since more flows are sharing the same bandwidth). For example, from the results, if we consider the 5KB transactional flow, as we increase the congestion from medium congestion (5 congesting flows) to high congestion (10 congesting flows) for a maximum drop probability of 0.1 the relative gain for ECN increases from 42% to 62%.
1) 随着拥塞的增加（具有固定的丢包概率），ECN的相对优势增加（同样，绝对优势不会增加，因为更多的流共享相同的带宽）。例如，从结果来看，如果我们考虑5kb交易流，当我们将拥塞从中等拥塞（5拥塞流）增加到高拥塞（10拥塞流）时，最大丢弃概率为0.1，ECN的相对增益从42%增加到62%。
2) Maintaining the congestion level while adjusting the maximum drop probability indicates that the relative advantage for ECN flows increase. From the case of high congestion for the 5KB flow we
2) 在调整最大丢包概率的同时维持拥塞水平表明ECN流的相对优势增加。根据5KB流量的高拥堵情况，我们
observe that the number of transactions per second increases from 0.8 to 2.2 which corresponds to an increase in relative gain for ECN of 20% to 140%.
观察到每秒事务数从0.8增加到2.2，这对应于ECN的相对收益增加20%到140%。
3) As the transactional data size increases, ECN's advantage diminishes because the probability of recovering from a Fast Retransmit increases for NON ECN. ECN, therefore, has a huge advantage as the transactional data size gets smaller as is observed in the results. This can be explained by looking at TCP recovery mechanisms. NON ECN in the short flows depends, for recovery, on congestion signaling via receiving 3 duplicate ACKs, or worse by a retransmit timer expiration, whereas ECN depends mostly on the TCP-ECE flag. This is by design in our experimental setup. [3] shows that most of the TCP loss recovery in fact happens in timeouts for short flows. The effectiveness of the Fast Retransmit/Recovery algorithm is limited by the fact that there might not be enough data in the pipe to elicit 3 duplicate ACKs. TCP RENO needs at least 4 outstanding packets to recover from losses without going into a timeout. For 5KB (4 packets for MTU of 1500Bytes) a NON ECN flow will always have to wait for a retransmit timeout if any of its packets are lost. ( This timeout could only have been avoided if the flow had used an initial window of four packets, and the first of the four packets was the packet dropped). We repeated these experiments with the kernels implementing SACK/FACK and New Reno algorithms. Our observation was that there was hardly any difference with what we saw with Reno. For example in the case of SACK-ECN enabling: maintaining the maximum drop probability to 0.1 and increasing the congestion level for the 5KB transaction we noticed that the relative gain for the ECN enabled flows increases from 47-80%. If we maintain the congestion level for the 5KB transactions and increase the maximum drop probabilities instead, we notice that SACKs performance increases from 15%-120%. It is fair to comment that the difference in the testbeds (different machines, same topology) might have contributed to the results; however, it is worth noting that the relative advantage of the SACK-ECN is obvious.
3) 随着事务数据大小的增加，ECN的优势会减弱，因为对于非ECN，从快速重传中恢复的概率会增加。因此，ECN具有巨大的优势，因为从结果中可以看出，事务数据的大小越来越小。这可以通过查看TCP恢复机制来解释。对于恢复，短流中的非ECN取决于通过接收3个重复ACK发出的拥塞信号，或者更糟的是，取决于重传计时器过期，而ECN主要取决于TCP-ECE标志。这是在我们的实验装置中设计的。[3] 显示大多数TCP丢失恢复实际上发生在短流的超时中。快速重传/恢复算法的有效性受到以下事实的限制：管道中可能没有足够的数据来引出3个重复的ack。TCP RENO需要至少4个未完成的数据包才能在不超时的情况下从丢失中恢复。对于5KB（4个数据包用于1500字节的MTU），如果任何数据包丢失，非ECN流将始终必须等待重新传输超时。（只有当流使用了四个数据包的初始窗口，并且四个数据包中的第一个是丢弃的数据包时，才能避免此超时）。我们用实现SACK/FACK和新雷诺算法的内核重复了这些实验。我们的观察结果是，与我们在雷诺身上看到的几乎没有任何区别。例如，在启用SACK-ECN的情况下：将最大丢弃概率保持在0.1，并增加5KB事务的拥塞级别。我们注意到，启用ECN的流的相对增益从47-80%增加。如果我们维持5KB事务的拥塞水平并增加最大丢弃概率，我们会注意到SACKs的性能从15%提高到120%。公平地说，试验台（不同的机器，相同的拓扑）的差异可能是导致结果的原因；然而，值得注意的是，SACK-ECN的相对优势是显而易见的。
ECN enhancements improve on both bulk and transactional TCP traffic. The improvement is more obvious in short transactional type of flows (popularly referred to as mice).
ECN增强功能可以改善批量和事务性TCP流量。这种改进在短事务类型的流（通常称为mice）中更为明显。
* Because less retransmits happen with ECN, it means less traffic on the network. Although the relative amount of data retransmitted in our case is small, the effect could be higher when there are more contributing end systems. The absence of retransmits also implies an improvement in the goodput. This becomes very important for scenarios
* 由于ECN的重传次数较少，这意味着网络上的通信量较少。虽然在我们的例子中，重新传输的相对数据量很小，但当有更多贡献端系统时，影响可能更大。没有重发也意味着goodput的改进。这对于场景来说变得非常重要
where bandwidth is expensive such as in low bandwidth links. This implies also that ECN lends itself well to applications that require reliability but would prefer to avoid unnecessary retransmissions.
带宽昂贵的地方，例如在低带宽链路中。这也意味着ECN很适合需要可靠性但更愿意避免不必要的重新传输的应用程序。
* The fact that ECN avoids timeouts by getting faster notification (as opposed to traditional packet dropping inference from 3 duplicate ACKs or, even worse, timeouts) implies less time is spent during error recovery - this also improves goodput.
* ECN通过获得更快的通知来避免超时（与传统的从3个重复的ACK或更糟糕的超时推断数据包丢弃相反），这意味着错误恢复过程中花费的时间更少——这也提高了goodput。
* ECN could be used to help in service differentiation where the end user is able to "probe" for their target rate faster. Assured forwarding [1] in the diffserv working group at the IETF proposes using RED with varying drop probabilities as a service differentiation mechanism. It is possible that multiple packets within a single window in TCP RENO could be dropped even in the presence of RED, likely leading into timeouts [23]. ECN end systems ignore multiple notifications, which help in countering this scenario resulting in improved goodput. The ECN end system also ends up probing the network faster (to reach an optimal bandwidth). [23] also notes that RENO is the most widely deployed TCP implementation today.
* ECN可用于帮助最终用户更快地“探测”其目标速率的服务差异化。IETF的diffserv工作组中的Assured forwarding[1]建议使用具有不同丢弃概率的RED作为服务区分机制。TCP RENO中单个窗口内的多个数据包可能会在出现RED的情况下被丢弃，这可能导致超时[23]。ECN终端系统会忽略多个通知，这有助于应对这种情况，从而提高goodput。ECN终端系统还可以更快地探测网络（以达到最佳带宽）。[23]还注意到RENO是当今部署最广泛的TCP实现。
It is clear that the advent of policy management schemes introduces new requirements for transactional type of applications, which constitute a very short query and a response in the order of a few packets. ECN provides advantages to transactional traffic as we have shown in the experiments.
很明显，策略管理方案的出现为事务类型的应用程序引入了新的需求，这些应用程序构成了一个非常短的查询和一个以几个数据包为顺序的响应。正如我们在实验中所展示的，ECN为事务性流量提供了优势。
We would like to thank Alan Chapman, Ioannis Lambadaris, Thomas Kunz, Biswajit Nandy, Nabil Seddigh, Sally Floyd, and Rupinder Makkar for their helpful feedback and valuable suggestions.
我们要感谢Alan Chapman、Ioannis Lambadaris、Thomas Kunz、Biswajit Nandy、Nabil Seddigh、Sally Floyd和Rupinder Makkar提供的有用反馈和宝贵建议。
Security considerations are as discussed in section 9 of RFC 2481.
安全注意事项如RFC 2481第9节所述。
[1] Heinanen, J., Finland, T., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[1] Heinanen，J.，芬兰，T.，Baker，F.，Weiss，W.和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[2] B.A. Mat. "An empirical model of HTTP network traffic." In proceedings INFOCOMM'97.
[2] B.A.垫子。“HTTP网络流量的经验模型”，《信息通信学报》97。
[3] Balakrishnan H., Padmanabhan V., Seshan S., Stemn M. and Randy
H. Katz, "TCP Behavior of a busy Internet Server: Analysis and
Improvements", Proceedings of IEEE Infocom, San Francisco, CA,
USA, March '98
http://nms.lcs.mit.edu/~hari/papers/infocom98.ps.gz
[3] Balakrishnan H., Padmanabhan V., Seshan S., Stemn M. and Randy
H. Katz, "TCP Behavior of a busy Internet Server: Analysis and
Improvements", Proceedings of IEEE Infocom, San Francisco, CA,
USA, March '98
http://nms.lcs.mit.edu/~hari/papers/infocom98.ps.gz
[4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[4] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[5] W. Feng, D. Kandlur, D. Saha, K. Shin, "Techniques for Eliminating Packet Loss in Congested TCP/IP Networks", U. Michigan CSE-TR-349-97, November 1997.
[5] 冯伟，D.坎德鲁，D.萨哈，K.申，“拥塞TCP/IP网络中消除数据包丢失的技术”，美国密歇根州CSE-TR-349-97，1997年11月。
[6] S. Floyd. "TCP and Explicit Congestion Notification." ACM Computer Communications Review, 24, October 1994.
[6] 弗洛伊德。“TCP和显式拥塞通知”，《ACM计算机通信评论》，1994年10月24日。
[7] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[7] Ramakrishnan，K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[8] Kevin Fall, Sally Floyd, "Comparisons of Tahoe, RENO and Sack TCP", Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21
[8] Kevin Fall，Sally Floyd，“塔霍、雷诺和萨克TCP的比较”，《计算机通信评论》，第26卷第3期，1996年7月，第5-21页
[9] S. Floyd and V. Jacobson. "Random Early Detection Gateways for Congestion Avoidance". IEEE/ACM Transactions on Networking, 3(1), August 1993.
[9] 弗洛伊德和雅各布森。“用于避免拥塞的随机早期检测网关”。IEEE/ACM网络交易，3（1），1993年8月。
[10] E. Hashem. "Analysis of random drop for gateway congestion control." Rep. Lcs tr-465, Lav. Fot Comput. Sci., M.I.T., 1989.
[10] E.哈希姆。“网关拥塞控制的随机丢弃分析”，代表Lcs tr-465，Lav。Fot计算机。科学，麻省理工学院，1989年。
[11] V. Jacobson. "Congestion Avoidance and Control." In Proceedings of SIGCOMM '88, Stanford, CA, August 1988.
[11] V.雅各布森。《拥塞避免和控制》，载于1988年8月于加利福尼亚州斯坦福的SIGCOMM'88会议录。
[12] Raj Jain, "The art of computer systems performance analysis", John Wiley and sons QA76.9.E94J32, 1991.
[12] Raj Jain，“计算机系统性能分析的艺术”，John Wiley和sons QA76.9.E94J32，1991年。
[13] T. V. Lakshman, Arnie Neidhardt, Teunis Ott, "The Drop From Front Strategy in TCP Over ATM and Its Interworking with Other Control Features", Infocom 96, MA28.1.
[13] T.V.Lakshman，Arnie Neidhardt，Teunis Ott，“TCP Over ATM的前端下降策略及其与其他控制功能的交互”，Infocom 96，MA28.1。
[14] P. Mishra and H. Kanakia. "A hop by hop rate based congestion control scheme." Proc. SIGCOMM '92, pp. 112-123, August 1992.
[14] P.Mishra和H.Kanakia。“基于逐跳速率的拥塞控制方案。”Proc。SIGCOMM'92，第112-123页，1992年8月。
[15] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[15] Floyd，S.和T.Henderson，“TCP快速恢复算法的NewReno修改”，RFC 2582，1999年4月。
[16] The NIST Network Emulation Tool
http://www.antd.nist.gov/itg/nistnet/
[16] The NIST Network Emulation Tool
http://www.antd.nist.gov/itg/nistnet/
[17] The network performance tool
http://www.netperf.org/netperf/NetperfPage.html
[17] The network performance tool
http://www.netperf.org/netperf/NetperfPage.html
[18] ftp://ftp.ee.lbl.gov/ECN/ECN-package.tgz
[18] ftp://ftp.ee.lbl.gov/ECN/ECN-package.tgz
[19] 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.
[19] 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月。
[20] K. K. Ramakrishnan and R. Jain. "A Binary feedback scheme for congestion avoidance in computer networks." ACM Trans. Comput. Syst.,8(2):158-181, 1990.
[20] 罗摩克里希南和杰恩。“计算机网络中避免拥塞的二进制反馈方案。”ACM Trans。计算机。系统，8（2）：158-1811990年。
[21] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[21] Mathis，M.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[22] S. Floyd and V. Jacobson, "Link sharing and Resource Management Models for packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 No.4, August 1995.
[22] S.Floyd和V.Jacobson，“分组网络的链路共享和资源管理模型”，IEEE/ACM网络事务，第3卷第4期，1995年8月。
[23] Prasad Bagal, Shivkumar Kalyanaraman, Bob Packer, "Comparative
study of RED, ECN and TCP Rate Control".
http://www.packeteer.com/technology/Pdf/packeteer-final.pdf
[23] Prasad Bagal, Shivkumar Kalyanaraman, Bob Packer, "Comparative
study of RED, ECN and TCP Rate Control".
http://www.packeteer.com/technology/Pdf/packeteer-final.pdf
[24] tcpdump, the protocol packet capture & dumper program.
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
[24] tcpdump, the protocol packet capture & dumper program.
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
[25] TCP dump file analysis tool:
http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html
[25] TCP dump file analysis tool:
http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html
[26] Thompson K., Miller, G.J., Wilder R., "Wide-Area Internet Traffic Patterns and Characteristics". IEEE Networks Magazine, November/December 1997.
[26] Thompson K.，Miller，G.J.，Wilder R.，“广域互联网流量模式和特征”。IEEE网络杂志，1997年11月/12月。
[27] http://www7.nortel.com:8080/CTL/ecnperf.pdf
[27] http://www7.nortel.com:8080/CTL/ecnperf.pdf
Jamal Hadi Salim Nortel Networks 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
Jamal Hadi Salim Nortel Networks 3500加拿大渥太华卡林大道，K2H 8E9
EMail: hadi@nortelnetworks.com
EMail: hadi@nortelnetworks.com
Uvaiz Ahmed Dept. of Systems and Computer Engineering Carleton University Ottawa Canada
加拿大渥太华卡尔顿大学系统与计算机工程系
EMail: ahmed@sce.carleton.ca
EMail: ahmed@sce.carleton.ca
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。