[要約] 要約： RFC 2884は、IPネットワークでの明示的な輻輳通知（ECN）の性能評価に関するものであり、ECNの有効性と効果を調査しています。目的： このRFCの目的は、ECNの実装と使用に関する情報を提供し、ネットワークのパフォーマンス向上に役立つガイドラインを提供することです。
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.
Copyright（c）The Internet Society（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（RENO、sack/fack、またはnewreno輻輳制御のいずれかを採用しているTCP）上のスループットに改善され、トランザクション転送の大幅な改善が改善されることを示しています。
A more complete pdf version of this document is available at: http://www7.nortel.com:8080/CTL/ecnperf.pdf
このドキュメントのより完全なPDFバージョンは、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 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つの重複したAcksの受領によって推測されるか、タイムアウトで検出されます。その後、TCPの送信は渋滞回避状態に移動し、そこでより遅い速度で送信することでネットワークを慎重にプローブします（別のパケット損失が検出されるまで上昇します）。伝統的に、ルーターはバッファースペースがない場合にパケットを落とすことにより、混雑に反応します。これはテールドロップと呼ばれます。この方法には多くの欠点があります（セクション2で概説されています）。これらの欠点は、エンドツーエンドの混雑制御の制限と相まって、ルーターによりスマートな輻輳制御メカニズムを導入することに関心をもたらしました。そのようなメカニズムの1つは、初期の輻輳を検出し、パケットを落とすことで速度を落とすためにオーバーサブスクライティングの流れを暗黙的に信号するランダム早期検出（RED）[9]です。赤い対応のルーターは、実行中の平均キューサイズに基づいて、バッファーオーバーフローの前に混雑を検出し、キューが実際にいっぱいになる前にパケットを確率的にドロップします。新しい到着パケットをドロップする確率は、平均キューサイズが低水マークミニを超えて増加するにつれて、より高いウォーターマークマックスに向かって増加します。平均キューサイズが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.
赤の拡張機能は、パケットをドロップする代わりにIPヘッダーをマークすることです（平均キューサイズがMinthとMaxthの間にある場合、Maxth上の到着パケットは以前のように削除されます）。協力するエンドシステムは、これをネットワークが混雑しており、減速しているという信号として使用します。これは、明示的な混雑通知（ECN）として知られています。このホワイトペーパーでは、ライブネットワーク内のルーターシステムとエンドシステムの両方のLinuxに関するECN実装を研究します。メモは次のように整理されています。セクション2では、ルーターのキュー管理の概要について説明します。セクション3では、ECNの概要と、RouterとENDホストで必要な変更が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]テールドロップのもう1つの問題は、単一の接続またはいくつかのフローが、状況によってはキュー空間を独占する可能性があることです。これにより、同期またはその他のタイミング効果につながるロックアウト現象が生じます[19]。最後に、テールドロップの主要な欠点の1つは、長期にわたってキューがいっぱいのままであることです。キュー管理の主要な目標の1つは、定常状態のキューサイズを縮小することです[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は、深刻なうっ血が発生する前に通知が発生するため、輻輳の兆候としてバッファオーバーフローにのみ依存する必要はありません。そのようなアクティブな管理手法の1つは赤です。
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]は、アクティブキュー管理に基づいて機能するルーターに実装されたうっ血回避メカニズムです。赤は、テールドロップの欠点に対処します。赤いルーターは、キューがバッファースペースがなくなる前に確率的にパケットをドロップすることにより、TCPへの初期の混雑を信号します。このドロップ確率は、破裂したトラフィックに対するバイアスを回避するために、実行中の平均キューサイズに依存します。赤いルーターは到着パケットをランダムにドロップし、その結果、特定のフローに属するパケットをドロップする可能性は、帯域幅のフローのシェアにほぼ比例します。したがって、送信者が比較的多くの帯域幅を使用している場合、パケットをより多く削除することで罰せられます。赤は、2つのレベルのしきい値の最小（Minth）と最大（Maxth）を維持することにより動作します。平均キューサイズがミンチとマックスのしきい値の間にある場合にのみ、パケットを確率的にドロップします。平均キューサイズが最大しきい値を上回っている場合、到着するパケットは常に削除されます。平均キューサイズが最小閾値と最大しきい値の間にある場合、到着する各パケットは確率PAで削除されます。PAは平均キューサイズの関数です。平均キューの長さがMinthとMaxthの間で変化するため、PAは構成された最大液滴MAXPに向かって直線的に増加します。マックスを超えて、低下確率は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の間にあるときにドロップする代わりにパケットをマークする赤に提案された拡張です[7]。ECNは輻輳が実際に発生する前にパケットをマークするため、これは単一のパケット損失に敏感なTCPのようなプロトコルに役立ちます。渋滞がマークされたパケットを受け取ると、TCPレシーバーは、送信者（後続のACK）に、送信者での輻輳回避アルゴリズムをトリガーする初期のうっ血について通知します。ECNは、ルーターとエンドホストの両方からのサポートを必要とします。つまり、ENDホストTCPスタックを変更する必要があります。ECNが能力を持っていないフローからのパケットは、引き続き赤で削除されます（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.
ECNのルーターサイドサポートは、現在の赤い実装を変更することで追加できます。ECN対応ホストのパケットの場合、ルーターはパケットをドロップするのではなくマークします（平均キューサイズがMinthとMaxthの間にある場合）。ルーターは、パケットがECN対応であることを識別し、ECN対応ホストからのパケットのみをマークする必要があります。これは、IPヘッダーに2つのビットを使用します。両方のエンドシステムがECN能力である場合、ECN対応輸送（ECT）ビットは、送信者エンドシステムによって設定されます（両方のエンドシステムがECN対応である場合にのみ、ユニキャスト輸送用）。TCPでは、これは接続セットアップフェーズ（セクション3.2で説明されている）中の前交渉で確認されています。渋滞に遭遇するパケットは、レシーバーエンドシステムに向かう途中で経験豊富な（CE）（CE）（平均キューサイズがMinthとMaxthの間にある場合）を使用してルーターによってマークされます（送信者エンドシステムから）。レッド（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ヘッダーの予約済みフィールドに2つの新しいフラグを指定します。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.
TCPにECNをエンドシステムに追加し、赤を走るルーターに1つの拡張機能を追加するために必要な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. 接続セットアップフェーズでは、ソースと宛先TCPSは、ECNを使用する希望および/または機能に関する情報を交換する必要があります。これは、送信者による初期接続フェーズのsynパケットにECN-ECHOフラグとCWRフラグの両方を設定することによって行われます。このsynパケットを受け取ると、受信機はsyn-ack応答にECNエコーフラグを設定します。この契約に達すると、送信者はそのフローのデータパケットの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エコーフラグ（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エコーフラグセットを持つACKパケットを受信した場合）は、非ECNの高速再送信/回復アルゴリズム（輻輳損失がある場合）と同等であることに注意してください。-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の実装は、最終システムのみでRFC 2481 [7]に適合します。また、ルーター部分の2.1,2.2および2.3ケースのコードと、RFCに準拠するためのエンドシステムも変更しました。2.0コードの古いバージョンは[18]で利用できます。Linuxバージョン2.0.32はTCP RENOの混雑制御を実装し、カーネル> = 2.2.0デフォルトで新しいRenoになりますが、リモートエンドがサックを理解しているときにサック/ファックコンボを選択します。最初のテストは、エンドシステムの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とNew Renoに対するテストを反映しています。
----- ----
| 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を調整します。Router R1には赤が実装されており、ECNフローをサポートする機能があります。Path-Delayルーターは、Linuxプラットフォーム上でNistNet [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.
実装がRFC 2481の仕様に適合していることを検証するのに時間を費やしました。これを行うために、人気のあるTCPDUMP Sniffer [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.
* 混雑フロー：これらは、R1からR2への混雑を作成するために、背景から開始される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 ON」から/TCPへの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.
* 低、中、高滴の確率：低確率という用語を使用して、0.02の低下確率MAXP、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をユーザーが観察した効果的なデータレートとして定義します。つまり、2つが再送信されたパケットである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.
* 赤い領域：ルーターの平均キューサイズが月と月の間にある場合、赤い領域で動作していることを示します。
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.
最初のテストでは、混雑の流れの数を増やすと、赤いキューが単純なテールドロップキューに退化することに気付きました。つまり、平均キューはほとんどの場合最大のしきい値を超えています。この現象は、平均キューサイズの過去の歴史に基づいてパケットドロップの確率「MAXP」を調整することにより、それを軽減する動的なソリューションを提案する[5]によっても観察されていることに注意してください。したがって、実験の過程で、ルーターが赤い領域で動作することが必要です。つまり、MinthとMaxthの間に平均キューが維持されることを確認する必要があります。これが維持されていない場合、キューはテールドロップキューのように機能し、ECNの利点が減少します。私たちの目標は、ルーターで赤で使用する場合のECNの利点を検証することです。赤い領域で動作していることを確認するために、平均キューサイズと実際のキューサイズを低、中程度、高い輻輳、高い混雑の時期に監視し、赤いパラメーターを微調整して、赤い領域の周りの平均キューゾーンを実行する前に微調整しました。適切な実験。したがって、私たちの結果は、間違った赤い地域での操作の影響を受けません。
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フローがあります）。一種のフロー。
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))
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秒で、2つの競合するフローを開始します。ネットワーク内のすべてのフローのスループットに注意し、公平性インデックスを計算します。この実験は、さまざまな最大滴の確率とさまざまな混雑レベルで実施されました。同じ手順は、ECNとしてバックグラウンドフローで繰り返されます。バックグラウンドフローがECNと非ECNであった場合、バックグラウンドフローがECNまたは非ECNのいずれかである場合にバイアスがなかったことを示す場合、公平性インデックスはかなり一定でした。
Max Fairness Fairness
Drop With BG With BG
Prob flows ECN flows 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.
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マシンに1つのデータ転送を開始し、2番目はECNマシンに2番目になります。使用されるファイルのサイズは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は、渋滞が高い場合でも、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）を変えることは、MDPの増加とともにECNの相対的な利点が増加することを明らかにしています。例として、液滴の場合が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 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の助けを借りて、非ECNのtcpdumpトレースを分析し、タイムアウトによる再送信はほとんどないことを観察しました。（タイムアウトによる再送信は、3つのデュパックの数をカウントして再送信し、記録された再送信の合計数からそれらを減算することにより推測されます）。これは、長期間にわたって（長いバルク転送の場合と同様）、高速再送信/回復アルゴリズムのデータ駆動型損失回復メカニズムが非常に効果的であることを意味します。ECEからの混雑通知に関するECNのアルゴリズムは、非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]は、赤い展開があったとしても、TCP Renoが同じデータウィンドウ内の複数のパケットドロップに苦しむ可能性があり、複数の混雑反応またはタイムアウトにつながる可能性が高いことを示しています（これらの問題はECNによって緩和されます）。ただし、TCP RENOにはデータのウィンドウにドロップされた複数のパケットでパフォーマンスの問題がありますが、新しいリノとサックにはそのような問題はありません。
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 RENOフローのECNの利点は、NewRenoまたはSackフローのECNの利点よりも劇的である可能性があります。結果から生じる重要な観察は、単一のデータウィンドウ内で複数のドロップに気付かないことです。したがって、私たちの結果は、データのウィンドウからドロップされた複数のパケットでRenoのパフォーマンスの問題に大きく影響されないと予想されます。これらのテストを、ECNパッチを適用した新しいLinuxカーネルで繰り返しました。前述のように、これらのカーネルは、新しいリノへのフォールバックを備えたサック/ファックコンボを使用します。サックは選択的にオフにすることができます（デフォルトの新しいリノになります）。私たちの結果は、ECNがバルク転送のパフォーマンスを改善することを示しています。PDFバージョン[27]でさらに結果が得られます。上記のように、0.1の最大低下確率を維持し、輻輳レベルを上げると、ECNサックは、低輻輳での約5％から高輻輳で約15％にパフォーマンスを向上させることが観察されます。高い輻輳が維持され、最大液滴が0.02から0.5に移動されるシナリオでは、ECNサックの相対的な利点は10％から40％に向上します。この数値はRENOが示すものよりも低いですが、SACKなどの堅牢な回復メカニズムが存在する場合でもECNが提供する改善を反映しています。
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（Connect Request Response）オプションを使用してNetPerf [17]を使用します。例として、5-20 kbの小さなファイルを取得していると仮定します。実際には、サーバーに小さなリクエストを送信し、ファイルを送信してサーバーが応答します。完全なファイルを受信すると、トランザクションが完了します。結果に自信を持つために、シミュレーションを約1時間保存します。各テストについて、これらのリクエストと回答が数千個あります。HTTP 1.0のトラフィックを正確にモデリングしているわけではありませんが、いくつかの同時セッションが開かれている場合、NetPerf-CRRは密接な近似です。NetPerf-CRRは、次のものを開く前に1つの接続が完了するのを待っているため、その単一の接続は、開いた同時セッション（HTTP）のセットで最も遅い応答と見なすことができます。[2]に基づいてトランザクションデータサイズが選択されました。これは、平均Webトランザクションが約8〜10 kbであったことを示しています。DiffServ [4]コンテキストのポリシー管理スキームで一般的になる可能性のあるトランザクション処理のサイズをゲスト化するために、より小さな（5kb）サイズが選択されました。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秒あたりの特定の要求されたサイズの完全な応答。たとえば、リクエストが1kbで、応答が5kbの場合、トランザクション率を1秒あたりの完全なトランザクションの数として定義します。
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秒後にトランザクション転送を開始し、各テストを3分間実行します。完了した1秒あたりのトランザクションを記録します。約1時間テストを繰り返し、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の相対的な利点は増加します（再び、より多くのフローが同じ帯域幅を共有しているため、絶対的な利点は増加しません）。たとえば、結果から、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 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フローの相対的な利点が増加することを示しています。5kbフローの高い輻輳の場合から、20％から140％のECNの相対的なゲインの増加に対応する0.8から2.2に1秒あたりのトランザクション数が増加することがわかります。
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つの重複アクセスを受信または再送信タイマーの有効期限によってさらに悪いことを介した輻輳シグナルに依存しますが、ECNは主にTCP-ECEフラグに依存します。これは、実験セットアップの設計によるものです。[3]は、TCP損失回復のほとんどが実際に短いフローのタイムアウトで発生することを示しています。高速再送信/回復アルゴリズムの有効性は、3つの重複ACKを誘発するのに十分なデータがパイプにない可能性があるという事実によって制限されています。TCP RENOは、タイムアウトに入ることなく損失から回復するために、少なくとも4つの未解決のパケットを必要とします。5kb（1500バイトのMTU用の4つのパケット）の場合、非ECNフローは、パケットのいずれかが失われた場合、常に再送信タイムアウトを待つ必要があります。（このタイムアウトは、フローが4つのパケットの初期ウィンドウを使用していた場合にのみ回避できたはずであり、4つのパケットのうち最初のパケットがドロップされた場合にのみ避けることができました）。これらの実験を、sack/fackと新しいリノアルゴリズムを実装するカーネルで繰り返しました。私たちの観察は、リノで見たものとほとんど違いがなかったということでした。たとえば、SACK-ECN有効化の場合：最大低下確率を0.1に維持し、5KBトランザクションのうっ血レベルを上げると、ECN対応フローの相対的なゲインが47-80％に増加することに気付きました。5kbトランザクションの輻輳レベルを維持し、代わりに最大ドロップの確率を増やすと、サックのパフォーマンスが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つの重複Acksからの従来のパケットのドロップ推論とは対照的に、さらに悪いことにタイムアウト）は、エラー回復中に費やされる時間が短くなります - これは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ワーキンググループの保証[1]は、サービス差別化メカニズムとしてさまざまなドロップ確率で赤を使用することを提案しています。TCP RENOの単一のウィンドウ内の複数のパケットが赤の存在下でもドロップされ、タイムアウトにつながる可能性がある[23]。ECN End Systemsは複数の通知を無視します。これは、このシナリオに対抗するのに役立ち、Goodputが改善されます。また、ECNエンドシステムは、ネットワークをより速く調査することになります（最適な帯域幅に到達するため）。[23]は、リノが今日最も広く展開されている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.
アラン・チャップマン、イオアニス・ランバダリス、トーマス・クンツ、ビスワジット・ナンディ、ナビル・セッディー、サリー・フロイド、およびルピンダー・マッカルの有益なフィードバックと貴重な提案に感謝します。
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.、Finland、T.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[2] B.A. Mat. "An empirical model of HTTP network traffic." In proceedings INFOCOMM'97.
[2] b.a.マット。「HTTPネットワークトラフィックの経験的モデル。」Proceedings 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] Balakrishnan H.、Padmanabhan V.、Seshan S.、Stemn M.、Randy H. Katz、「忙しいインターネットサーバーのTCP動作：分析と改善」、IEEE Infocom、サンフランシスコ、カリフォルニア州、米国、98年3月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 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. Feng、D。Kandlur、D。Saha、K。Shin、「混雑したTCP/IPネットワークのパケット損失を排除するための技術」、U。MichiganCSE-TR-349-97、1997年11月。
[6] S. Floyd. "TCP and Explicit Congestion Notification." ACM Computer Communications Review, 24, October 1994.
[6] S.フロイド。「TCPおよび明示的な混雑通知。」ACM Computer Communications Review、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] ケビンフォール、サリーフロイド、「タホ、リノ、サックTCPの比較」、コンピューターコミュニケーションレビュー、V。26N. 3、1996年7月、pp。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、LAV。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.ジェイコブソン。「混雑の回避と制御。」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、「The Art of Computer Systems Performance Analysis」、John Wiley and 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、「ATMを介したTCPのフロント戦略からのドロップと、他の制御機能との相互作用」、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.ミシュラとH.カナキア。「ホップによるホップレートベースの混雑制御スキーム。」Proc。Sigcomm '92、pp。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] 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
[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。and 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] K. K.ラマクリシュナンとR.ジャイン。「コンピューターネットワークにおける混雑回避のためのバイナリフィードバックスキーム。」ACMトランス。コンピューター。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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Auncoundage Options」、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.ジェイコブソン、「パケットネットワークのリンク共有およびリソース管理モデル」、IEEE/ACMトランザクションオンネットワーク、Vol。3 No.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、「赤、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] Thompson K.、Miller、G.J.、Wilder R.、「広い地域のインターネットトラフィックパターンと特性」。IEEE Networks Magazine、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 Carling Ave Ottawa、ON、K2H 8E9カナダ
EMail: hadi@nortelnetworks.com
Uvaiz Ahmed Dept. of Systems and Computer Engineering Carleton University Ottawa Canada
Uvaiz Ahmed Dept. of Systems and Computer Engineering Carleton University Ottawa Canada
EMail: ahmed@sce.carleton.ca
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。