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]。私たちは、バルクおよびトランザクションの転送の両方のための電子証券取引ネットワークの挙動を研究します。我々の実験は、バルク転送およびトランザクションを転送するための実質的な改善の場合には（リノ、SACK / FACKまたはNewRenoの輻輳制御のいずれかを使用するTCP）NON ECN上スループットの改善があることを示しています。
A more complete pdf version of this document is available at: http://www7.nortel.com:8080/CTL/ecnperf.pdf
http://www7.nortel.com:8080/CTL/ecnperf.pdf：このドキュメントのより完全な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 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.
現在のIPネットワークでは、輻輳管理は、IP上で動作するプロトコルに委ねられています。混雑IPルータは、単純にパケットを廃棄します。 TCPは、支配的なトランスポートプロトコル今日[26]です。 TCPは、パケットドロップ（RFC 2581）を検出することにより、ネットワークの輻輳があると推定します。輻輳制御アルゴリズムは、[11] [15] [21]次に、混雑を緩和するために呼び出されます。 TCPは、最初はそれがパケットロスを検出するまで高いレート（スロースタート）で送信します。パケット損失は3個の重複ACKの受信によって推測またはタイムアウトによって検出されます。送信側TCPは、それは慎重に（別のパケットロスが検出されるまで上がる）より遅い速度で送信することによって、ネットワークをプローブ輻輳回避状態に移行します。伝統的に、ルータは、バッファスペースが存在しない場合にパケットをドロップすることにより、輻輳に反応します。これは、テールドロップと呼ばれています。この方法は、（セクション2に概説）多くの欠点を有しています。エンドツーエンドの輻輳制御の制限と相まってこれらの欠点は、ルータで賢く輻輳制御メカニズムを導入への関心につながっています。一つのそのような機構は、ランダム早期検出（RED）[9]初期輻輳を検出し、暗黙的にそのパケットをドロップすることによって遅くする混雑をフローを信号です。 RED対応ルータは、実行中の平均キューサイズに基づいて、バッファオーバーフローの前に輻輳を検出し、キューが実際にいっぱいになる前に、確率的にパケットを廃棄します。新しい到着パケットを落とす確率が高いウォータマークmaxthに向かって低水位マークminth上記平均キューサイズが大きくなる、として増加します。平均キューサイズが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 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]に含まれています。キュー管理アルゴリズムは、伝統的に、バッファがオーバーフローした場合にのみ、パケットをドロップすることにより、ルータのパケットキューの長さを管理します。各キューの最大長は構成されています。この最大サイズを超えるまで、ルータは、着信パケットをドロップしますその時点で、パケットを受け入れます。バッファスペースが許すときに、新しいパケットを受け入れています。この技法は、テールドロップとして知られています。このメソッドは、年のためだけでなく、インターネットを務めたが、いくつかの欠点がありました。 （すべてのフローの）全ての到着パケットは時にバッファオーバーフローを落としているので、これは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は、輻輳の指標としてのみバッファオーバーフローに依存する必要はありません。そのようなアクティブな管理手法REDです。
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 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.
ランダム早期検出（RED）[9]アクティブキュー管理に基づいて動作するルータに実装輻輳回避メカニズムです。 REDはテールドロップの欠点に対処します。キューがバッファ容量が不足する前に、確率的にパケットをドロップすることにより、TCPにREDルータ信号初期の混雑。このドロップ確率はバースト性トラフィックに対して任意の偏りを避けるために、実行中の平均キューサイズに依存しています。 REDルータは、ランダムに特定のフローに属するパケットをドロップする確率は帯域幅の流れのシェアにほぼ比例する結果と、到着パケットを廃棄します。送信者が比較的多くの帯域幅を使用している場合はこのように、それがドロップされたそのパケットの多くを持っていることによって罰せられます。 REDは、二つの閾値の最小値（minth）のレベルおよび最大（maxth）を維持することによって動作します。これは、パケットをドロップ確率であれば、平均キューサイズがminthとmaxthのしきい値の間にある場合にのみ。平均キューサイズが最大しきい値を超えている場合は、到着したパケットは、常にドロップされます。平均キューサイズが最小値と最大閾値の間にあるとき、各到着するパケットは、PAは、平均キューサイズの関数である確率PAと滴下します。平均キュー長は、直線的に設定された最大のドロップ確率をmaxP向かっminthとmaxth、PAの増加との間に変化します。 maxthを超えて、ドロップ確率は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).
明示的輻輳通知は、平均キューサイズがminthとmaxthの間にあるときに拡張がそれを落とすのではなく、パケットをマークREDすることが提案されている[7]。輻輳が実際に発生する前に、ECNがパケットをマークしているので、これは、単一のパケット損失を均等に敏感なTCPなどのプロトコルに便利です。渋滞マークされたパケットを受信すると、TCPの受信機は、順番に、送信側で輻輳回避アルゴリズムをトリガーする初期の混雑について（その後のACKで）送信者に通知します。 ECN、すなわちエンドホストのTCPスタックを変更する必要があり、ルータならびにエンドホストの両方からのサポートを必要とします。 （ECN前にそうであったように）可能ECNされていないフローからのパケットは、REDによってドロップされ続けます。
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.
ECNのルータ側のサポートは、現在のREDの実装を変更することによって加えることができます。 （平均キューサイズがminthとmaxthの間にある場合）ECN可能なホストからのパケットの場合、ルータは、それらを落とすのではなく、パケットをマークします。ルータは、パケットがECN可能であることを識別し、ECN可能なホストからのパケットをマークするだけべきであることが必要です。これは、IPヘッダ内の2ビットを使用します。両方のエンドシステムは、（両方のエンドシステムは、ECN-可能である場合にのみ、ユニキャストトランスポートのために）可能なECNいる場合ECN可能なトランスポート（ECT）ビットは、送信側エンドシステムによって設定されています。 TCPでは、これは（3.2節で説明）接続設定フェーズ中に事前交渉で確認されています。 （平均キューサイズがminthとmaxthの間にある場合）、輻輳が発生したパケットは、平均に比例した確率で、（送信側エンドシステムから）受信側システムへの途中に輻輳経験（CE）を使用して、ルータによってマークされています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 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.
TCPにECNを追加するための提案は、TCPヘッダーの予約フィールドに二つの新しいフラグを指定します。 TCPヘッダの予備フィールドのビット9は、ECN-エコー（ECE）フラグとして指定され、ビット8は、輻輳ウィンドウの減少（CWR）フラグとして指定されます。これら2つのビットの両方が送信者と受信者は、能力と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.
エンドシステムとREDを実行しているルータに1つの拡張子にTCPにECNを追加するためになされる必要がある2つの主な変更点があります。
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は自分の欲望と/またはECNを使用する機能についての情報を交換する必要があります。これは、送信者による初期接続フェーズのSYNパケットにECN-エコーフラグとCWRフラグの両方を設定することによって行われます。このSYNパケットの受信時に、受信機は、SYN-ACK応答でECN-エコーフラグをセットします。この合意に達した後、送信側は、その上に、それが可能とECNに参加する意思があるネットワークに示すために、そのフローのデータパケットのIPヘッダ内のECTビットをセットします。 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で（TCPヘッダ内）ECN-エコーフラグを設定することによって応答します。それは、送信者から（送信者）が輻輳通知に応答したという指示を受信するまで受信機は、後続の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.
このACKを受信すると3.は、送信者は、その輻輳ウィンドウを半分にすることにより、その輻輳回避アルゴリズムをトリガに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.
NON-ECNにおける（輻輳損失がある場合）（これは、ECN-エコーフラグが設定されているACKパケットを受信した場合）、ネットワークの輻輳の指示に送信元反応は高速再送信/回復アルゴリズムと同等であることに注意してください送信者すなわち-capable TCPは輻輳ウィンドウのcwndを半分にし、スロースタートしきい値SSTHRESHを低減します。高速再送信/回復は3つの重複確認応答に対応するため、まだ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.
テスト目的のために我々は、LinuxのTCP / IPスタック、カーネルバージョン2.0.32にECNを追加しました。 2.2.5、2.3.43（試験された2.3の以前のリビジョンもありました）。 2.0.32実装[7]エンド・システムのための唯一のRFC 2481に準拠します。我々はまた、RFCに準拠するようにルータ部分の2.1,2.2及び2.3例のコードと同様に、エンドシステムを変更しました。 2.0コードの古いバージョン[18]で入手可能です。 Linuxバージョン2.0.32は、新リノにしばらくカーネル> = 2.2.0デフォルトTCPリノの輻輳制御を実装していますが、リモートエンドが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.
私たちは、SACKと新リノに対してテストを反映するために、このメモのリリースを更新しました。
----- ----
| 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 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.
すべての物理リンクは、10Mbpsのイーサネットです。クラスベースのキューイング（CBQ）[22]を用いて、データ・サーバからのパケットは、ルータR1で1.5Mbpsで管にくびれています。データは常にラベルのクライアントへのサーバーから取得され、「ECN ON」、「ECN OFF」、および「C」。サーバーからのパイプが10Mbpsのであるので、これは、競合フローのクライアントへのルータからの出口で渋滞を作成します。 「ECN ON」と「ECN OFF」と表示されたマシンは、Linuxの同じバージョンを実行していて、まったく同じハードウェア構成を持っています。サーバは常にECN可能である（非ECNを扱うことができる標準的な輻輳アルゴリズムを使用しても流れます）。 「C」と表示されたマシンは、ネットワーク内の輻輳を作成するために使用されます。ルータR2は、パス遅延制御部として機能します。それによって、私たちは、クライアントが見RTTを調整します。ルータR1はREDはそれで実装され、ECNフローをサポートするための機能を備えていました。パス遅延ルータは、Linuxプラットフォーム上でNISTnetの[16]パッケージを実行しているPCです。実験のためのリンクの待ち時間は20 millisecsとしました。
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.
私たちは、マークされたパケットを表示するように変更された[24]実装は、この、人気のtcpdumpスニファを行うにはRFC 2481.に仕様に準拠したことを検証した時間を過ごしました。我々は、視覚的に異なるシナリオの多くの下でRFCへの適合性を検証するためにtcpdumpのトレースを視察しました。また、可視化と分析のためにマークされたパケットをプロットするために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.
*輻輳フロー：これらは、R2へのR1から混雑を作成するために、バックグラウンドで起動されているTCPフローです。私たちは、輻輳の流れを紹介する「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.
*低、中等度および高輻輳：我々はバックグラウンドで2つの輻輳フローを開始し、低混雑の場合には、適度の混雑のために、我々は5つの輻輳フローを開始し、高い混雑の場合のために、我々はバックグラウンドで10の輻輳フローを開始します。
* 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 TCPは、「ECN ON」またはNON ECN TCPへ/から流れのどちらかであることは、「ECN OFF」へ/から流れ。
* 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.
*最大ドロップ率：これはルータでマークされたパケットの最大確率を設定し、REDのパラメータです。これはセクション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.
*低、中、高ドロップ確率：我々は、0.5のドロップ確率0.02をmaxP、媒体確率0.2および高い確率を意味する用語低い確率を使用します。また、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.
*グッドプット：我々は、我々はそれらの二つのパケットが再送された4つのデータパケットを送信した場合、すなわち、ユーザにより観察される実効データ速度、効率が50％であるようにグッドプットを定義し、得られたグッドプットは、*パケットサイズ/時間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.
* RED地域：ルータの平均キューサイズが月と月の間にあるとき、我々はRED領域で動作していることを示します。
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.
私たちの最初のテストでは、我々は我々が増えるよう輻輳の数はREDキューはシンプルなテールドロップキューに退化流れていることに気づきました。すなわち、平均キューは、時間のほとんどの最大しきい値を超えています。この現象はまたによって観察されていることに注意してください[5]平均キューサイズの過去の履歴に基づいてパケットのドロップ確率「をmaxP」を調整することによって、それを軽減するための動的なソリューションを提案している人。したがって、私たちの実験の過程で、ルータは、我々は平均キューがminthとmaxthの間で維持されていることを確認する必要があり、すなわち、RED領域で動作することが必要です。これが維持されていない場合、キューはテールドロップキューとECNの減少の利点のような役割を果たします。私たちの目標は、ルータでREDで使用した場合ECNのメリットを検証することです。我々はRED領域で動作していることを確実にするために、我々は実行する前に、低、中程度および高輻輳時に平均キューサイズと実際のキューサイズを監視し、REDのパラメータは、このような赤の領域の周りの平均キューゾーンという微調整します適切な実験。我々の結果は、それゆえ、間違った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で最初にいくつかのテストを行い、背景が流れとしてNON ECNが流れます。我々は、さまざまなドロップ確率のための実験を繰り返し、公平性指標[12]を算出しました。我々はまた、パケットの数に等しかったパケットの数が非ECNフローのためにドロップされた（ECNとNON ECNフローの等しい数が存在した場合）に気づいREDアルゴリズムの両方に公正であったことをそれにより示すECNフローのためにマーク流れのようなもの。
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]に記載の性能測定基準です。ジェイン[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）=正方形（（和[I = 1..nの】XI））/（N *和[I = 1..nの]平方（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.
公平性指標は、常に1の値は、すべてのフローがまったく同じスループットを得たことを示して0と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つのNON ECN FTPセッションを開始します。時刻tは、我々は2つの競合フローを開始し、20秒を=。私たちは、ネットワーク内のすべてのフローのスループットに注意し、公平性指標を計算します。実験は、種々の最大ドロップ確率および種々の輻輳レベルを行いました。同じ手順がECNとして背景フローを繰り返します。背景フローがECNと背景フローがECNまたは非ECNのいずれかであった偏りがなかったことを示すNON ECNた場合公平性指数は、両方の場合においてほぼ一定でした。
Max Fairness Fairness Drop With BG With BG Prob flows ECN flows NON ECN
BG度ProbとBGで最大フェアネスフェアネスドロップECNはNON 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
０。０２ ０。９９６８８８ ０。９９１９４６ ０。０５ ０。９９５９８７ ０。９８８２８６ ０。１ ０。９８５４０３ ０。９８９７２６ ０。２ ０。９７９３６８ ０。９８３３４２
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.
背景フローの性質が結果を変えていない観察と、私たちはバックグラウンドを使用して進めるが、実験の残りのためNON 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です。低混雑の場合のために我々は2 FTPはその後、約20秒後に我々は競争が流れ、一つのデータECNマシンに転送し、NON ECNマシンに2番目を開始時刻0で、バックグラウンドで流れ始めます。使用されるファイルのサイズは20MBです。適度な混雑の場合のために我々は5 FTPがバックグラウンドで流れ始めると、高い混雑の場合のために、私たちは10 FTPをバックグラウンドで流れ始めます。私たちは、それぞれがセットの数だけ繰り返さ様々な最大ドロップ率のための実験を繰り返します。
Observation and Analysis:
観察と分析：
We make three key observations:
我々は3つの主要な観測を行います。
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はまだ高くても混雑下NON ECNよりも優れてい。収集された結果からサンプルをInfering：0.1の最大ドロップ確率で、例えば、ECNの相対的な利点は、ローからハイへの輻輳レベルが増加すると50％に23％から増加します。
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の相対的な利点は、60％、10％から増加します。
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 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).
私たちは、tcptraceの助けを借りて、NON ECNのためのtcpdumpトレースを分析し、タイムアウトによる任意の再送がほとんどなかったことを観察しました。 （3 DUPACKS再送信の数を計数し、再送の総記録数からそれらを減算することによって推測されるによるタイムアウトに再送）。これは、（長いバルク転送の場合のように）長期間にわたって、高速再送信/回復アルゴリズムのデータ駆動損失回復機構は非常に有効であることを意味します。 ECEからの輻輳通知のECNのためのアルゴリズムは、NON ECNのための高速再送信のためのものと同じです。両方が赤色領域で動作しているため、ECNはかろうじてシグナリング（マーキング対パケットドロップ）からNON 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の主な利点は、（NON ECNは再送信時間を費やしているのに対し）少ない時間が回復費やされ、そしてタイムアウトが完全に回避されていることであると信じています。 [23] TCP RENOは、複数のパケットに苦しむ可能性があり、REDが展開も有することが示されている（これらの問題はECNによって緩和される）複数の輻輳反応またはタイムアウトにつながる可能性、データの同じウィンドウ内で低下します。 TCPリノがありながら、しかし、複数のパケットでのパフォーマンスの問題は、データのウィンドウにドロップされた、新リノと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.
したがって、輻輳の非常に高レベルのシナリオのために、TCPリノフローのECNの利点は、NewRenoのまたはSACKフローのECNの利点はより劇的であり得ます。我々の結果から作るための重要な観察は、我々は、データの単一のウィンドウ内で複数のドロップを気づかないということです。このように、我々は我々の結果は重くデータの窓から落とさ複数のパケットとリノのパフォーマンスの問題に影響されないことを期待します。私たちは、新しいLinuxカーネルにパッチを当てECNでこれらのテストを繰り返しました。先に述べたように、これらのカーネルは新しいリノへのフォールバックでSACK / FACKコンボを使用します。 SACKは、選択的に（新リノをデフォルト）オフにすることができます。我々の結果は、ECNはまだバルク転送のパフォーマンスを改善することを示しています。以上の結果は、PDF版[27]で入手可能です。 、0.1の最大廃棄確率を維持し、輻輳レベルを増加させる上記1）のように、ECN-SACKが高い混雑で約15％まで低い混雑で約5％〜性能を改善することが観察されます。高輻輳が維持され、最大のドロップ確率が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 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.
私たちは、小さな要求を送信し、次の要求を送信する前に、サーバーからの応答を取得することにより、トランザクションの転送をモデル化します。トランザクションの転送トラフィックを生成するために、我々はCRR（要求応答を接続）オプションを使用してのNetperf [17]を使用します。例として、私たちは、私たちが言う5の小さなファイル検索していると仮定しましょう - 20キロバイトを、そして実際に、私たちは、サーバーと、サーバーに小さな要求を送信し、私たちにファイルを送信して応答します。我々は完全なファイルを受信したときにトランザクションが完了しています。我々の結果の信頼性を得るために、私たちは約1時間のシミュレーションを運びます。各テストのための場所を取って、これらの要求と応答の数千があります。正確にいくつかの同時セッションが開かれているHTTP 1.0トラフィックを、モデル化していないものの、のNetperf - CRRは、それにもかかわらず、近似値です。ためのNetperf-CRRは、単一の接続が開か同時セッション（HTTPで）のセットで最も遅い応答とみなすことができることを次の（0思考時間）、開く前に完了するために一つの接続を待ちます。トランザクションデータサイズ[2]平均Webトランザクションは約8であったことを示しているに基づいて選択された - 10キロバイト。小さい（5キロバイト）サイズは、DiffServの[4]の文脈におけるポリシー管理スキームと普及できるトランザクション処理のサイズをguestimateように選択されました。 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.
*として、トランザクション・レートを定義します。私たちは毎秒行うことができます特定の要求されたサイズの要求と完全な応答の数。たとえば、私たちの要求は、1キロバイトのものであり、応答が5キロバイトである我々は、我々は毎秒達成することができ、このような完全なトランザクションの数などのトランザクション・レートを定義した場合。
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は約20秒後に私たちはトランザクションの転送を開始し、3分間各テストを実行する時刻0で、ネットワークの輻輳を導入する流れ背景を開始バルク転送の場合と同様。私たちは完了している秒あたりのトランザクションを記録します。私たちは約1時間のテストを繰り返し、毎秒様々な取引をプロットし、実行にわたって平均しました。実験は、種々の最大ドロップ確率、ファイルサイズと輻輳のさまざまなレベルについて繰り返されます。
Observation and Analysis
観察と分析
There are three key observations:
3つの主要な観測があります。
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増加に対する相対的利点（より多くのフローが同じ帯域幅を共有しているので、再び絶対的な優位性が増加しない）など。結果から、例えば、我々は0.1の最大廃棄確率からECN増加に対する相対利得を高い混雑（10の輻輳フロー）に培地輻輳（5つの輻輳フロー）から輻輳を増加すると、我々は、5キロバイトのトランザクションの流れを考慮した場合62％の42％。
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 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%.
2）最大廃棄確率を調整しながら輻輳レベルを維持することは、ECNのための相対的利点は、増加して流れることを示しています。 5キロバイトフローの高い混雑の場合から、我々は観察し、その140％まで20％のECNに対する相対ゲインの増加に対応する0.8から2.2への第2の上昇あたりのトランザクションの数。
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は、TCP-ECEフラグに主に依存するのに対し、短いフローのNON ECNは、再送信タイマの満了によって3個の重複ACK、または悪化を受信介してシグナリング輻輳に、回復のために、依存します。これが私たちの実験の設計によるものです。 [3]実際にはTCPの損失回復のほとんどは短いフローのタイムアウトで起こることを示しています。高速再送信/回復アルゴリズムの有効性は3つの重複ACKを誘発するパイプ内の十分なデータがないかもしれないという事実によって制限されています。 TCP RENOはタイムアウトに行かずに損失から回復するには、少なくとも4未処理のパケットを必要とします。 5キロバイトのために（1500BytesのMTUのための4つのパケット）NON ECNの流れは、常にそのパケットのいずれかが失われた場合は再送タイムアウトを待つ必要があります。 （フローは4つのパケットの初期ウィンドウを使用していた場合は、このタイムアウトは、唯一の回避されている可能性があり、4つのパケットの最初のパケットがドロップされました）。私たちは、SACK / FACKと新リノアルゴリズムを実装するカーネルでこれらの実験を繰り返しました。私たちの観察は、我々がリノで見たものとほとんど差がなかったということでした。 SACK-ECNがイネーブルの場合には、例えば：0.1に最大廃棄確率を維持し、ECNの相対ゲインが有効にすることを、我々は気づい5キロバイトトランザクションの輻輳レベルを増加させる47から80パーセントの増加を流れます。我々は5キロバイトトランザクションの輻輳レベルを維持し、代わりに最大ドロップ確率を増加させる場合、我々は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トラフィックの両方を改善します。改善は、（一般にマウスと呼ばれる）フローの短いトランザクションタイプでより明白です。
* 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 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で発生するので、ネットワーク上のトラフィックが少ないことを意味します。我々の場合には再送データの相対的な量は小さいが、より寄与エンドシステムがある場合、効果が高くなる可能性があります。再送の不在はまた、グッドプットの改善を意味しています。これは、帯域幅は、このような低帯域幅リンクのように高価なシナリオのために非常に重要になってきます。これは、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または、からの伝統的なパケット廃棄推論とは反対に、タイムアウト）より速い通知を取得することにより、タイムアウトを回避しているという事実が意味するより少ない時間は、エラーリカバリ中に費やされている - これはまた、グッドプットが向上します。
* 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ワーキンググループで保証転送[1]は、サービス差別化機構としてドロップ確率を変化させてREDを使用して提案しています。 [23] TCP RENOで単一のウィンドウ内で複数のパケットの可能性が高いタイムアウトにつながるさえREDの存在下で廃棄される可能性があります。 ECNエンドシステムは、改善されたグッドプットをもたらすこのシナリオに対処するのに役立つ複数の通知を無視します。 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.
私たちは彼らの有益なフィードバックと貴重な提案のためにアラン・チャップマン、イオアニスLambadaris、トーマス・クンツ、Biswajit Nandy、ナビルSeddigh、サリーフロイド、および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.、ベイカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[2] B.A. Mat. "An empirical model of HTTP network traffic." In proceedings INFOCOMM'97.
[2] B.A.マット。 「HTTPネットワークトラフィックの経験的モデル。」議事INFOCOMM'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]バラクリシュナンH.、Padmanabhan V.、Seshan S.、Stemn M.とランディH.カッツ、 "忙しいインターネットサーバのTCPの挙動：分析と改善"、IEEEインフォコム、サンフランシスコ、CA、USAの議事録、月'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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年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] W.風水、D. Kandlur、D.サハ、K.新、 "渋滞TCP / IPネットワークにおけるパケット損失を排除するための技術"、U.ミシガンCSE-TR-349から97、1997年11月。
[6] S. Floyd. "TCP and Explicit Congestion Notification." ACM Computer Communications Review, 24, October 1994.
[6] S.フロイド。 「TCPおよび明示的輻輳通知。」 ACMコンピュータコミュニケーションレビュー、24、1994年10月。
[7] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[7]ラマクリシュナン、K.およびS.フロイド、 "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]ケビン秋、サリーフロイド、 "タホ、RENOと袋TCPの比較"、コンピュータコミュニケーションレビュー、V. 26 N. 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] S.フロイドとV.ヤコブソン。 「輻輳回避のためのランダム早期検出ゲートウェイ」。ネットワーク上の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、ラヴ。 FOT Comput。 SCI。、M.I.T.、1989。
[11] V. Jacobson. "Congestion Avoidance and Control." In Proceedings of SIGCOMM '88, Stanford, CA, August 1988.
[11] V.ヤコブソン。 「輻輳回避とコントロール。」 SIGCOMM '88の議事録、スタンフォード大学、カリフォルニア州、1988年8月に。
[12] Raj Jain, "The art of computer systems performance analysis", John Wiley and sons QA76.9.E94J32, 1991.
[12]ラジ・ジャイン、「コンピュータ・システムの性能解析の技術」、ジョンワイリーアンドサンズ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.ラクシュマン、アーニーナイトハルト、Teunisオット、「その他の制御機能を持つTCP以上のATMとそのインターワーキングにおけるフロント戦略からドロップ」、インフォコム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.ミシュラ及び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]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[16] The NIST Network Emulation Tool http://www.antd.nist.gov/itg/nistnet/
[16] NISTネットワークエミュレーションツールhttp://www.antd.nist.gov/itg/nistnet/
[17] The network performance tool http://www.netperf.org/netperf/NetperfPage.html
[17]ネットワークパフォーマンスツールhttp://www.netperf.org/netperf/NetperfPage.html
[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]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、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] K. K.ラマクリシュナン及びR.ジェイン。 「コンピュータネットワークにおける輻輳回避のためのバイナリフィードバック方式。」 ACMトランス。 Comput。 SYST、8（2）：158から181、1990。
[21] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[21]マティス、M.、Mahdavi、J.、フロイド、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.フロイドと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]プラサドBagal、Shivkumar Kalyanaraman、ボブ・パッカー、 "RED、ECNおよびTCPレート制御の比較研究"。 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、プロトコル・パケット・キャプチャ・ダンパプログラム。 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ダンプファイルの分析ツール：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]トンプソンK.、ミラー、G.J.、ワイルダーR.、「広域インターネットトラフィックパターンと特徴」。 IEEEネットワークマガジン、11月/ 1997年12月。
[27] http://www7.nortel.com:8080/CTL/ecnperf.pdf
「２７」 ｈっｔｐ：／／ｗっｗ７。のｒてｌ。こｍ：８０８０／ＣＴＬ／えｃんぺｒｆ。ｐｄｆ
Jamal Hadi Salim Nortel Networks 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
ジャマル・ハディサリムNortel Networksの3500カーリングアベニューオタワ、ON、K2H 8E9カナダ
EMail: hadi@nortelnetworks.com
メールアドレス：hadi@nortelnetworks.com
Uvaiz Ahmed Dept. of Systems and Computer Engineering Carleton University Ottawa Canada
システムのUvaizアーメド部門およびコンピュータ工学カールトン大学オタワカナダ
EMail: ahmed@sce.carleton.ca
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。