RFC2884 日本語訳
2884 Performance Evaluation of Explicit Congestion Notification (ECN)in IP Networks. J. Hadi Salim, U. Ahmed. July 2000. (Format: TXT=44647 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Hadi Salim
Request for Comments: 2884 Nortel Networks
Category: Informational U. Ahmed
Carleton University
July 2000
コメントを求めるワーキンググループJ.ハディのサリムの要求をネットワークでつないでください: 2884 ノーテルはカテゴリをネットワークでつなぎます: 情報のU.アフマドカールトン大学2000年7月
Performance Evaluation of Explicit Congestion Notification (ECN)
in IP Networks
IPネットワークにおける、明白な混雑通知(電子証券取引ネットワーク)の業績評価
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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.
このメモは、リナックスOperating Systemで私たちの実現を使用することでTCP/IPプロトコルにおける、Explicit Congestion Notification(電子証券取引ネットワーク)メカニズムの性能研究を発表します。 電子証券取引ネットワークは終わりから終わりへの輻輳回避[6]によって提案されて、RFC 2481[7]に組み入れられたメカニズムです。 私たちは大量と取引の転送の両方のために電子証券取引ネットワークの振舞いを研究します。 私たちの実験は、NON ECN(リノのどれか、SACK/ファークまたは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バージョンで見つけられた視覚表現と実験結果でさらになくなっています。
1. Introduction
1. 序論
In current IP networks, congestion management is left to the protocols running on top of IP. An IP router when congested simply drops packets. TCP is the dominant transport protocol today [26]. TCP infers that there is congestion in the network by detecting packet drops (RFC 2581). Congestion control algorithms [11] [15] [21] are then invoked to alleviate congestion. TCP initially sends at a higher rate (slow start) until it detects a packet loss. A packet loss is inferred by the receipt of 3 duplicate ACKs or detected by a
現在のIPネットワークでは、ふくそう管理はIPの上を走るプロトコルに出られます。 単に充血すると、IPルータはパケットを落とします。 TCPによる優位な輸送が今日[26]について議定書の中で述べるということです。 TCPは、パケット滴(RFC2581)を検出するのによるネットワークには混雑があると推論します。 そして、輻輳制御アルゴリズム[11][15][21]は、混雑を軽減するために呼び出されます。 パケット損失を検出するまで、TCPは初めは、より高いレート(遅れた出発)で発信します。 パケット損失は、3写しACKsの領収書で推論されるか、またはaによって検出されます。
Salim & Ahmed Informational [Page 1] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[1ページ]のRFC2884電子証券取引ネットワーク
timeout. The sending TCP then moves into a congestion avoidance state where it carefully probes the network by sending at a slower rate (which goes up until another packet loss is detected). Traditionally a router reacts to congestion by dropping a packet in the absence of buffer space. This is referred to as Tail Drop. This method has a number of drawbacks (outlined in Section 2). These drawbacks coupled with the limitations of end-to-end congestion control have led to interest in introducing smarter congestion control mechanisms in routers. One such mechanism is Random Early Detection (RED) [9] which detects incipient congestion and implicitly signals the oversubscribing flow to slow down by dropping its packets. A RED- enabled router detects congestion before the buffer overflows, based on a running average queue size, and drops packets probabilistically before the queue actually fills up. The probability of dropping a new arriving packet increases as the average queue size increases above a low water mark minth, towards higher water mark maxth. When the average queue size exceeds maxth all arriving packets are dropped.
タイムアウト。 輻輳回避への送付のTCPの当時の移動は、それがどこで、より遅いレートで発信することによって慎重にネットワークを調べるか(どれが別のパケット損失まで行くかは検出される)を述べます。 伝統的に、ルータは、混雑にバッファ領域がないときパケットを落とすことによって、反応します。 これはTail Dropと呼ばれます。 この方法には、多くの欠点(セクション2では、概説されている)があります。 終わりからエンドへの輻輳制御の制限に結びつけられたこれらの欠点はルータで、より賢い混雑制御機構を紹介することへの関心につながりました。 そのようなメカニズムの1つは始まりの混雑を検出して、パケットを落とすことによって減速するようにそれとなく「過剰-申し込」み流動に合図するRandom Early Detection(RED)[9]です。 バッファがあふれる前にREDの可能にされたルータは混雑を検出します、移動平均待ち行列サイズ、および待ち行列の前のパケットprobabilisticallyが実際に満たす低下に基づいて。 平均した待ち行列サイズが干潮標minthの上で増加するのに従って、新しい到着パケットを落とすという確率は増加します、より高いウォーター・マークmaxthに向かって。 平均した待ち行列サイズがmaxthを超えているとき、すべて到着しているパケットは落とされます。
An extension to RED is to mark the IP header instead of dropping packets (when the average queue size is between minth and maxth; above maxth arriving packets are dropped as before). Cooperating end systems would then use this as a signal that the network is congested and slow down. This is known as Explicit Congestion Notification (ECN). In this paper we study an ECN implementation on Linux for both the router and the end systems in a live network. The memo is organized as follows. In Section 2 we give an overview of queue management in routers. Section 3 gives an overview of ECN and the changes required at the router and the end hosts to support ECN. Section 4 defines the experimental testbed and the terminologies used throughout this memo. Section 5 introduces the experiments that are carried out, outlines the results and presents an analysis of the results obtained. Section 6 concludes the paper.
REDへの拡大はパケットを落とすことの代わりにIPヘッダーをマークする(平均した待ち行列であるときに、minthとmaxthの間には、サイズがあります; 従来と同様maxth到着パケットの上に落とされます)ことです。 協力して、エンドシステムは、次に、ネットワークが混雑しているという信号としてこれを使用して、減速するでしょう。 これはExplicit Congestion Notification(電子証券取引ネットワーク)として知られています。 この紙では、私たちはルータとエンドシステムの両方のためにリナックスでライブネットワークで電子証券取引ネットワークの実現を研究します。 メモは以下の通りまとめられます。 セクション2では、私たちはルータにおける、待ち行列管理の概観を与えます。 セクション3は電子証券取引ネットワークの概観を与えます、そして、変化がルータと終わりのホストで電子証券取引ネットワークを支持するのが必要です。 セクション4は実験的なテストベッドとこのメモ中で使用される用語を定義します。 セクション5は、行われる実験を紹介して、結果について概説して、得られた結果の分析を提示します。 セクション6は紙を結論づけます。
2. Queue Management in routers
2. ルータでManagementを列に並ばせてください。
TCP's congestion control and avoidance algorithms are necessary and powerful but are not enough to provide good service in all circumstances since they treat the network as a black box. Some sort of control is required from the routers to complement the end system congestion control mechanisms. More detailed analysis is contained in [19]. Queue management algorithms traditionally manage the length of packet queues in the router by dropping packets only when the buffer overflows. A maximum length for each queue is configured. The router will accept packets till this maximum size is exceeded, at which point it will drop incoming packets. New packets are accepted when buffer space allows. This technique is known as Tail Drop. This method has served the Internet well for years, but has the several drawbacks. Since all arriving packets (from all flows) are dropped
TCPの輻輳制御と回避アルゴリズムは、必要であって、強力ですが、彼らがブラックボックスとしてネットワークを扱うので良いサービスをすべての事情に提供するために十分ではありません。 ある種のコントロールが、終わりのシステム混雑制御機構の補足となるのにルータから必要です。より詳細な分析は[19]に含まれています。 キュー管理アルゴリズムは、バッファがあふれる場合にだけパケットを落とすことによって、ルータにおける、パケット待ち行列の長さを伝統的に管理します。 各待ち行列のための最大の長さは構成されます。 それがそうするどのポイントが入って来るパケットを落とすかでこの最大サイズが超えられるまで、ルータはパケットを受け入れるでしょう。 バッファ領域であるときに、新しいパケットを受け入れます。許容します。 このテクニックはTail Dropとして知られています。 この方法には、長年インターネットによく役立っていますが、いくつかの欠点があります。 すべて到着しているパケット(すべての流れからの)が落とされるので
Salim & Ahmed Informational [Page 2] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[2ページ]のRFC2884電子証券取引ネットワーク
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の混雑制御機構と対話します。 最大の待ち行列サイズが超えられた後に1サイクルは低下の炸裂で形成されます、エンドシステムが引き返すのに従って過少利用の期間までにルータで続かれて。 そして、エンドシステムは同時に、低下の炸裂が再び起こるところでそれらの窓をある程度増加させます。 この現象はGlobal Synchronizationと呼ばれます。 それはそれが単独結合であるかいくつかの流れが待ち行列スペースを独占するかもしれないというTail Dropに関する別の問題を不十分なリンク利用と低い総合的なスループット[19]に導きます、いくつかの事情で。 これは同期につながるロックアウト現象か他のタイミング効果[19]をもたらします。 最後に、Tail Dropの主要な欠点の1つは待ち行列が長期間の間完全なままで残っているということです。 待ち行列管理の主要な目標の1つは定常状態待ち行列サイズ[19]を減少させることです。 他の待ち行列管理技術は完全の無作為の低下と完全な[13]の落とし板を含んでいます。
2.1. Active Queue Management
2.1. 活発な待ち行列管理
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つはREDです。
2.1.1. Random Early Detection
2.1.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
無作為のEarly Detection(RED)[9]はルータで実行された輻輳回避メカニズムです(活発な待ち行列管理に基づいて働いています)。 REDはTail Dropの短所を記述します。 REDルータは、待ち行列がバッファ領域を使い果たす前にパケットprobabilisticallyを落とすことによって、始まりの混雑をTCPに示します。 この低下確率はbursty交通に対してどんな偏見も避ける移動平均待ち行列サイズに依存しています。 REDルータは手当たりしだいに到着パケットを落とします、その結果、特定の流れに属すパケットを落とすという確率が流れの帯域幅のシェアにほとんど比例しています。 したがって、送付者が比較的多くの帯域幅を使用しているなら、一層のパケットが落とされることによって、それは罰せられます。 REDは、最小(minth)で最大に(maxth)2つのレベルの敷居を維持することによって、作動します。 そして、probabilisticallyにパケットが低下する、minthとmaxth敷居の間には、平均した待ち行列サイズがある場合にだけ。 平均した待ち行列サイズが最大の敷居を超えているなら、到着パケットはいつも落とされます。 最小の敷居と最大の敷居の間に平均した待ち行列サイズがあるとき、それぞれの到着パケットは確率paで落とされます。そこでは、paが平均した待ち行列サイズの関数です。 平均した待ち行列の長さがminthとmaxthの間で異なるのに従って、paは直線的に構成された最大の低下確率、maxpに向かって増加します。 maxth、低下を超えて
Salim & Ahmed Informational [Page 3] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[3ページ]のRFC2884電子証券取引ネットワーク
probability is 100%. Dropping packets in this way ensures that when some subset of the source TCP packets get dropped and they invoke congestion avoidance algorithms that will ease the congestion at the gateway. Since the dropping is distributed across flows, the problem of global synchronization is avoided.
確率は100%です。 TCPパケットが得るソースの何らかの部分集合が低下して、ゲートウェイで混雑を緩和する輻輳回避アルゴリズムを呼び出すとき、このようにパケットを落とすと、それは確実にされます。 低下が流れの向こう側に分配されるので、グローバルな同期の問題は避けられます。
3. Explicit Congestion Notification
3. 明白な混雑通知
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).
明白なCongestion Notificationはminthとmaxth[7]の間に平均した待ち行列サイズがあるときそれを落とすことの代わりにパケットをマークするREDに提案された拡大です。 混雑が実際に起こる前に電子証券取引ネットワークがパケットをマークするので、これは単一のパケット損失にさえ敏感なTCPのようなプロトコルの役に立ちます。 パケットであるとマークされた混雑を受け取り次第、TCP受信機は、どれが送付者で順番に輻輳回避アルゴリズムの引き金となるかを始まりの混雑に関する送付者(その後のACKの)に知らせます。 電子証券取引ネットワークはルータと終わりのホストの両方(すなわち、TCPスタックが変更される必要がある終わりのホスト)から支持を要します。 できる電子証券取引ネットワークでない流れからのパケットは、REDによって落とされ続けるでしょう(電子証券取引ネットワークの前でそうであったように)。
3.1. Changes at the router
3.1. ルータにおける変化
Router side support for ECN can be added by modifying current RED implementations. For packets from ECN capable hosts, the router marks the packets rather than dropping them (if the average queue size is between minth and maxth). It is necessary that the router identifies that a packet is ECN capable, and should only mark packets that are from ECN capable hosts. This uses two bits in the IP header. The ECN Capable Transport (ECT) bit is set by the sender end system if both the end systems are ECN capable (for a unicast transport, only if both end systems are ECN-capable). In TCP this is confirmed in the pre-negotiation during the connection setup phase (explained in Section 3.2). Packets encountering congestion are marked by the router using the Congestion Experienced (CE) (if the average queue size is between minth and maxth) on their way to the receiver end system (from the sender end system), with a probability proportional to the average queue size following the procedure used in RED (RFC2309) routers. Bits 10 and 11 in the IPV6 header are proposed respectively for the ECT and CE bits. Bits 6 and 7 of the IPV4 header DSCP field are also specified for experimental purposes for the ECT and CE bits respectively.
現在のRED実現を変更することによって、電子証券取引ネットワークのルータサイドサポートを加えることができます。 電子証券取引ネットワークの有能なホストからのパケットに関しては、ルータはそれらを落とすよりむしろパケットをマークします(minthとmaxthの間には、平均した待ち行列サイズがあるなら)。 ルータがパケットができる電子証券取引ネットワークであることを特定して、電子証券取引ネットワークの有能なホストから来ているパケットをマークするだけであるのが必要です。 これはIPヘッダーで2ビットを使用します。 電子証券取引ネットワークCapable Transport(ECT)ビットは両方のエンドシステムができる電子証券取引ネットワーク(ユニキャスト輸送において、両方が終わる場合にだけ、システムは電子証券取引ネットワークできる)であるなら送付者エンドシステムによって設定されます。 接続設定段階(セクション3.2では、説明される)の間、TCPでは、これはプレ交渉で確認されます。 混雑に遭遇するパケットがルータによって受信端末システム(送付者エンドシステムからの)への途中でCongestion Experienced(CE)(minthとmaxthの間には、平均した待ち行列サイズがあるなら)を使用することでマークされます、手順に従うのがRED(RFC2309)ルータに使用した平均した待ち行列サイズに比例している確率で。 IPV6ヘッダーのビット10と11はそれぞれECTとCEビット提案されます。 また、IPV4ヘッダーDSCP分野のビット6と7はECTとCEビットとしてそれぞれ実験目的に指定されます。
3.2. Changes at the TCP Host side
3.2. TCP Host側の変化
The proposal to add ECN to TCP specifies two new flags in the reserved field of the TCP header. Bit 9 in the reserved field of the TCP header is designated as the ECN-Echo (ECE) flag and Bit 8 is
TCPに電子証券取引ネットワークを加えるという提案はTCPヘッダーの予約された分野の2個の新しい旗を指定します。 電子証券取引ネットワーク-エコー(ECE)が弛むとき、TCPヘッダーの予約された分野のビット9は指定されます、そして、Bit8は指定されます。
Salim & Ahmed Informational [Page 4] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[4ページ]のRFC2884電子証券取引ネットワーク
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.
Congestion Window Reduced(CWR)旗を任じました。 設立された状態の間にネットワークで経験された混雑があるといけないので、これらの2ビットは送付者と受信機が能力を交渉する初期値設定フェーズと電子証券取引ネットワークを使用して、その後の行動が取られる願望に使用されます。
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を走らせながらエンドシステムへのTCPとルータへの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が彼らの願望、そして/または、電子証券取引ネットワークを使用する能力に関して情報交換しなければなりません。 これが初期の接続フェーズのSYNパケットに電子証券取引ネットワーク-エコー旗とCWR旗の両方を設定することによって、送付者によって行われます。 このSYNパケットを受け取り次第、受信機は電子証券取引ネットワーク-エコー旗をSYN-ACK応答にはめ込むでしょう。 この合意にいったん達すると、送付者は、できて電子証券取引ネットワークに参加しても構わないと思っているのをネットワークに示すためにその上にその流れのためのデータ・パケットの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ヘッダーで)、受信機は応じます。 受信機は、送付者から混雑通知に応じたという指示を受けるまでその後のACKsでこれをし続けるでしょう。
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.
ネットワーク(電子証券取引ネットワーク-エコー旗を設定するACKパケットを受けるとき)における、混雑のしるしへの送付者反応ができるNON電子証券取引ネットワークTCPのFast Retransmit/回復アルゴリズム(混雑の損失があるとき)に同等であり、すなわち、送付者が混雑ウィンドウcwndを半分にして、遅れた出発敷居ssthreshを減少させることに、注意してください。 速く、3つの写し承認まで応じるには、Retransmit/回復は電子証券取引ネットワークのできるスタックにまだ利用可能です。
Salim & Ahmed Informational [Page 5] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[5ページ]のRFC2884電子証券取引ネットワーク
4. Experimental setup
4. 実験装置
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.
テスト目的のために、私たちはリナックスTCP/IPスタックに電子証券取引ネットワークを加えて、カーネルはバージョン2.0.32です。 2.2.5 2.3 .43(より早くも、テストされた2.3の改正がありました) 2.0.32実現はエンドシステムだけのためのRFC2481[7]に従います。 また、私たちは2.1におけるコードを変更しました、エンドシステムと同様にルータ部分がRFCに従わせる2.2と2.3のケース。 2.0コードの時代遅れのバージョンは[18]で利用可能です。 注意リナックスバージョン2.0.32は、カーネル>=2.2.0がNewリノをデフォルトとしますが、TCPリノ輻輳制御を実行しますが、リモートエンドがSACKを理解していると、SACK/ファークコンボを選ぶでしょう。 2.0カーネルがエンドシステムにあって、2.1が(前2.2)で私たちの初期のテストがルータ部分に行われました。 ここの試験の成績の大部分が2.0のテストに適用します。 私たちが2.2と2.3のカーネルのために異なったテストベッド(PentiumからPentium IIクラスマシンまで動く)の上で、より速いマシンでこれらのテストを繰り返したので、2.0と2.2/3における比較は相対的ではありません。
We have updated this memo release to reflect the tests against SACK and New Reno.
私たちは、SACKとNewリノに対してテストを反映するためにこのメモリリースをアップデートしました。
4.1. Testbed setup
4.1. テストベッドセットアップ
----- ----
| ECN | | ECN |
| ON | | OFF |
data direction ---->> ----- ----
| |
server | |
---- ------ ------ | |
| | | R1 | | R2 | | |
| | -----| | ---- | | ----------------------
---- ------ ^ ------ |
^ |
| -----
congestion point ___| | C |
| |
-----
----- ---- | 電子証券取引ネットワーク| | 電子証券取引ネットワーク| | オン| | オフ| データ指示---->>。----- ---- | | サーバ| | ---- ------ ------ | | | | | R1| | R2| | | | | -----| | ---- | | ---------------------- ---- ------ ^ ------ | ^ | | ----- 混雑ポイント___| | C| | | -----
The figure above shows our test setup.
上の図形は私たちのテストセットアップを示しています。
All the physical links are 10Mbps ethernet. Using Class Based Queuing (CBQ) [22], packets from the data server are constricted to a 1.5Mbps pipe at the router R1. Data is always retrieved from the server towards the clients labelled , "ECN ON", "ECN OFF", and "C". Since the pipe from the server is 10Mbps, this creates congestion at the exit from the router towards the clients for competing flows. The machines labeled "ECN ON" and "ECN OFF" are running the same version
すべての物理的なリンクが10Mbpsイーサネットです。 Class Based Queuing(CBQ)[22]を使用して、データサーバからのパケットはルータR1の1.5Mbpsパイプに締めつけられます。 データがサーバからレッテルを貼られたクライアントに向かっていつも検索される、「電子証券取引ネットワーク、オンである、」、「」 「C」の電子証券取引ネットワーク。 サーバからのパイプが10Mbpsであるので、これは競争している流れのために出口でルータから混雑をクライアントに向かって作成します。 マシンがラベルした、「電子証券取引ネットワーク、オンである、」、「電子証券取引ネットワーク、下に」、同じバージョンを走らせています。
Salim & Ahmed Informational [Page 6] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[6ページ]のRFC2884電子証券取引ネットワーク
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.
そして、リナックス、まさに同じハードウェア・コンフィギュレーションを持ってください。 いつもサーバはできるのである(そして、また、標準の混雑アルゴリズムを使用することでNON ECN流れを扱うことができる)電子証券取引ネットワークです。 「C」とラベルされたマシンは、ネットワークで混雑を作成するのに使用されます。 ルータR2は経路遅れコントローラとして務めます。 それで、私たちはクライアントが見るRTTを調整します。 ルータR1はそれでREDを実行させて、電子証券取引ネットワーク流れを支持するための能力を持っています。 経路遅れルータはリナックスプラットホームでのNistnet[16]パッケージを動かすPCです。 実験のためのリンクの潜在は20millisecsであるように設定されました。
4.2. Validating the Implementation
4.2. 実現を有効にします。
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.
私たちはそれを有効にして、実現がconformantであった時間をRFC2481の仕様で、過ごしました。 これをするなら、ポピュラーなtcpdump麻薬を吸う人[24]は、パケットがマークされるのを示すように変更されました。 私たちは、順応を多くの異なったシナリオの下におけるRFCに有効にするために目視によりtcpdump跡を点検しました。 また、私たちは、[25] 想像と分析のために著しいパケットを企むようにtcptraceを変更しました。
Both tcpdump and tcptrace revealed that the implementation was conformant to the RFC.
tcpdumpとtcptraceの両方が、実現がRFCへのconformantであることを明らかにしました。
4.3. Terminology used
4.3. 使用される用語
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.
* 安値、Moderate、およびHigh混雑: 低い混雑に関するケースのために、私たちはバックグラウンドにおける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".
* 競争は流れます: これらは私たちが興味を持っている流れです。 それらが電子証券取引ネットワークTCPが/から流れるどちらか、「」 非電子証券取引ネットワーク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.
* 最大の低下率: これはルータでマークされるパケットの最大の確率を設定するREDパラメタです。 これはセクション2.1で説明されるようにmaxpに対応しています。
Salim & Ahmed Informational [Page 7] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[7ページ]のRFC2884電子証券取引ネットワーク
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.
* 低く、MediumとHighは確率を落とします: 私たちは、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.
* 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.
* 赤い領域: minthとmaxthの間にルータの平均した待ち行列サイズがあるとき、私たちは、RED領域で働いているのを指示します。
4.4. RED parameter selection
4.4. 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が列に並ばせる充血流れの数を増加させるのに従ってそれが簡単なTail Drop待ち行列に陥るのに気付きました。すなわち、平均した待ち行列は現代について最大の敷居を最も超えています。 また、[5] だれが平均した待ち行列サイズの過去の歴史に基づくパケット低下確率"maxp"を調整することによってそれを軽減するためにダイナミックな解決策を提案するかがこの現象が観測されたことに注意してください。 したがって、私たちの実験の間のルータがRED領域で作動するのが必要である、すなわち、私たちは平均した待ち行列がminthとmaxthの間で維持されるのを確実にしなければなりません。 これが維持されないなら、待ち行列はTail Drop待ち行列のように行動します、そして、電子証券取引ネットワークの利点は減少します。 私たちの目標はルータにおけるREDと共に使用されると電子証券取引ネットワークの利益を有効にすることです。 私たちが私たちがRED領域で働いていたのを保証するために、低くて、適度の、そして、高い混雑の時代に平均した待ち行列サイズと実際の待ち行列サイズをモニターして、REDパラメタについて微調整したので、実験自体を走らせる前に、平均はRED領域の周りのゾーンを列に並ばせます。 したがって、間違ったRED領域で作動することによって、私たちの結果は影響を及ぼされません。
5. The Experiments
5. 実験
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]で実験結果に関するその他の詳細を見つけることができます。
Salim & Ahmed Informational [Page 8] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[8ページ]のRFC2884電子証券取引ネットワーク
5.1. Fairness
5.1. 公正
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.
実験の間に、私たちは、私たちのバックグラウンド流れのタイプの選択が私たちが集まるという結果に偏らないのを確実にしたかったです。 したがって、バックグラウンドが流れるのに従って、私たちは初めは、電子証券取引ネットワークとNON ECN流れの両方でいくつかのテストを行いました。 私たちは、異なった低下確率のための実験を繰り返して、公正インデックス[12]について計算しました。 また、私たちは、NON ECNが流れるので落とされたパケットの数が電子証券取引ネットワークのためにマークされたパケットの数への同輩が流れて、その結果、REDアルゴリズムが両方に公正であったのを示すのがちょっと流れるということであるのに気付きました(等しい数の電子証券取引ネットワークとNON 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]は、ネットワークがマルチユーザーシステムであることを仮定して、各ユーザがどれくらい公正に扱われるかを確認するためにはメートル法のaを引き出します。 彼はユーザの向こう側にスループットの可変性の関数と公正を定義します。 与えられたセットのユーザスループット(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]ξ))/(n*合計[i=1..n]正方形(ξ))
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つのNON ECN FTPセッションを始めます。 20t=秒の時に、私たちは2つの競争している流れを始めます。 私たちは、ネットワークのすべての流れに関するスループットに注意して、公正インデックスについて計算します。 実験が様々な最大の低下確率と様々な混雑レベルのために行われました。 同じ手順は電子証券取引ネットワークとしてバックグラウンド流れで繰り返されます。 バックグラウンドが流れるとき、偏見が全くなかったのを示すNON ECNはバックグラウンド流れが電子証券取引ネットワークであったときに、公正インデックスが両方の場合でかなり一定であり、電子証券取引ネットワークかNON ECNのどちらかです。
Max Fairness Fairness Drop With BG With BG Prob flows ECN flows NON ECN
マックスFairness Fairness Drop With BG With BG Prob流れ電子証券取引ネットワーク流れ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
0.02 0.996888 0.991946 0.05 0.995987 0.988286 0.1 0.985403 0.989726 0.2 0.979368 0.983342
Salim & Ahmed Informational [Page 9] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[9ページ]のRFC2884電子証券取引ネットワーク
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としてバックグラウンド流れを使用することによって、続きます。
5.2. Bulk transfers
5.2. バルク転送
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秒以降、私たちは競争している流れ、電子証券取引ネットワークマシンへの1つのデータ転送、およびNON 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) 混雑レベルが増加するのに従って、電子証券取引ネットワークのための相対的な利点は増加しますが、絶対利点は減少します(同じリンクリソースを競争するより多くの流れがあるので、予想されます)。 電子証券取引ネットワークはまだそうしているほうがよいです。 集まるのからのサンプルをInferingするのは結果として生じます: 0.1の最大の低下確率では、例えば、混雑レベルが安値から高値に増加するのに従って、電子証券取引ネットワークの相対的な利点は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と共に増加するのを明らかにします。 例として、高い混雑に関するケースのために、私たちが低下確率を0.02〜0.5に変えるのに従って、電子証券取引ネットワークの相対的な利点は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) 電子証券取引ネットワーク流れ(高い混雑と低最大の低下確率に関するケースのためのテストの少数の時々のパケット滴を除いた)のためのほとんどいくらかの「再-トランスミッション」があります。
We analyzed tcpdump traces for NON ECN with the help of tcptrace and observed that there were hardly any retransmits due to timeouts. (Retransmit due to timeouts are inferred by counting the number of 3 DUPACKS retransmit and subtracting them from the total recorded number of retransmits). This means that over a long period of time (as is the case of long bulk transfers), the data-driven loss recovery mechanism of the Fast Retransmit/Recovery algorithm is very effective. The algorithm for ECN on congestion notification from ECE
いずれも辛くもあったtcptraceであって観測されることの助けがあるNON ECNがタイムアウトのため再送するので、私たちはtcpdump跡を分析しました。 (再送、3DUPACKSの数が再送する勘定で推論されて、合計から彼らを引き算すると数が記録されたタイムアウトへの支払われるべきものが再送される、) これは、長日月(長いバルク転送に関するケースのような)の間Fast Retransmit/回復アルゴリズムのデータ駆動型損失回収機構が非常に効果的であることを意味します。 ECEからの混雑通知での電子証券取引ネットワークのためのアルゴリズム
Salim & Ahmed Informational [Page 10] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[10ページ]のRFC2884電子証券取引ネットワーク
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).
それと同じくらいはNON ECNのためのFast Retransmitのためのものですか? 両方がRED領域で作動しているので、電子証券取引ネットワークはシグナリング(パケット滴対マーク)から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.
しかしながら、電子証券取引ネットワークが流れるという結果から、大量の利益が移されるのは、明確です。 私たちは、バルク転送のための電子証券取引ネットワークの主な利点が、より少ない時間が回復するのに費やされて(NON ECNは時間を再送するのに費やします)、タイムアウトが全体で避けられるということであると信じています。 [23]は、REDさえ配備されている状態で、TCP RENOがデータの同じ窓の中の複数のパケット滴を欠点であることができたことを示しました、複数の混雑反応かタイムアウトに通じそうです(これらの問題は電子証券取引ネットワークによって軽減されます)。 しかしながら、TCPリノにはデータの窓で落とされる複数のパケットに関する性能問題がある間、Newリノと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リノが流れるので、非常に高いレベルの混雑があるシナリオのために、NewRenoには、電子証券取引ネットワークの利点が電子証券取引ネットワークの利点より劇的であるかもしれませんか、またはSACKは流れます。 私たちの結果からする重要な観測は私たちがデータの単一の窓の中で複数の低下に気付かないということです。 したがって、私たちは、私たちの結果がデータの窓から落とされる複数のパケットに関するリノの性能問題によって大いに影響を及ぼされないと予想するでしょう。 電子証券取引ネットワークが、より新しい状態で修理されている状態で、私たちはこれらのテストを繰り返しました。リナックスカーネル。 先に述べたようにこれらのカーネルは後退があるSACK/ファークコンボをNewリノに使用するでしょう。 選択的にSACKをオフにすることができます(Newリノをデフォルトとして)。 私たちの結果は、電子証券取引ネットワークがバルク転送のために性能をまだ向上させているのを示します。 より多くの結果がpdfバージョン[27]で利用可能です。 0.1と混雑レベルを増加させるという最大の低下確率を維持する上の1のように、)電子証券取引ネットワーク-SACKが高い混雑で性能を低い混雑におけるおよそ5%からおよそ15%まで向上させると認められます。 高い混雑が維持されて、最大の低下確率が0.02〜0.5まで動かされるシナリオでは、電子証券取引ネットワーク-SACKの相対的な利点は10%から40%に向上します。 これですが、数がものがリノのそばで展示会に出品されたより下位である、それらは電子証券取引ネットワークがSACKなどの強健な回収機構があるときさえ提供する改良を反映します。
5.3. Transactional transfers
5.3. 取引の転送
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
私たちは、次の要求を送る前に小さい要求を送って、サーバから返事をもらうことによって、取引の転送をモデル化します。 取引の転送交通を発生させるように、私たちはCRR(Request Responseを接続する)オプションと共にNetperf[17]を使用します。 例でそれを仮定できたので、私たちはたとえば、5の小さいファイルを取っています--20KB、次に、事実上、私たちは小さい要求をサーバに送ります、そして、サーバはファイルを私たちに送ることによって、反応します。 私たちが完全なファイルを受け取るとき、取引は完全です。 私たちの結果で自信を得るために、私たちはおよそ1時間シミュレーションを運びます。 各テストを支持して、数1,000があります。
Salim & Ahmed Informational [Page 11] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[11ページ]のRFC2884電子証券取引ネットワーク
of these requests and responses taking place. Although not exactly modeling HTTP 1.0 traffic, where several concurrent sessions are opened, Netperf-CRR is nevertheless a close approximation. Since Netperf-CRR waits for one connection to complete before opening the next one (0 think time), that single connection could be viewed as the slowest response in the set of the opened concurrent sessions (in HTTP). The transactional data sizes were selected based on [2] which indicates that the average web transaction was around 8 - 10 KB; The smaller (5KB) size was selected to guestimate the size of transactional processing that may become prevalent with policy management schemes in the diffserv [4] context. Using Netperf we are able to initiate these kind of transactional transfers for a variable length of time. The main metric of interest in this case is the transaction rate, which is recorded by Netperf.
これらの要求と応答が行われるのについて。 まさにHTTPをモデル化しませんが、1.0交通、いくつかの同時発生のセッションのどこが開かれるか、それにもかかわらず、Netperf-CRRは厳密な近似です。 Netperf-CRRが次のものを開く前に終了する1つの接続を待っているので(0は時間を考えます)、開かれた同時発生のセッション(HTTPにおける)のセットで最も遅い応答としてその単独結合を見なすことができました。 取引のデータサイズは平均したウェブ取引はおよそ8でした--10KBを示す[2]に基づいて選択されました。 (5KB)の、より小さいサイズが政策管理計画がdiffserv[4]文脈である状態で一般的になるかもしれない取引の処理のサイズを当て推量するのが選択されました。 Netperfを使用して、私たちはこれらの種類の可変長の時間の取引の転送を起こすことができます。 この場合、関心におけるメートル法のメインは取引率です。(その率はNetperfによって記録されます)。
* Define Transaction rate as: The number of requests and complete responses for a particular requested size that we are able to do per second. For example if our request is of 1KB and the response is 5KB then we define the transaction rate as the number of such complete transactions that we can accomplish per second.
* Transactionレートを以下と定義してください。 私たちが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) 混雑が増加するのに従って(固定低下確率で)、電子証券取引ネットワークのための相対的な利点は増加します(より多くの流れが同じ帯域幅を共有しているので、一方、絶対利点は増加しません)。 例えば、結果から、私たちが、5KBが取引の流れであると考えるなら、私たちが0.1の最大の低下確率のための中型の混雑(5回の充血流れ)から高い混雑(10回の充血流れ)までの混雑を増加させるのに応じて、電子証券取引ネットワークのための相対的な利得は42%から62%まで上がります。
2) Maintaining the congestion level while adjusting the maximum drop probability indicates that the relative advantage for ECN flows increase. From the case of high congestion for the 5KB flow we
2) 混雑レベルが、最大の低下確率を調整している間電子証券取引ネットワークのための相対的な利点が流れるのを示すと主張して、増加してください。 5KBのための高い混雑に関するケースから、私たちは流れています。
Salim & Ahmed Informational [Page 12] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[12ページ]のRFC2884電子証券取引ネットワーク
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番目の0.8〜2.2までの増加あたりの取引の数が20%から140%の電子証券取引ネットワークのために獲得されるのを観測してください。
3) As the transactional data size increases, ECN's advantage diminishes because the probability of recovering from a Fast Retransmit increases for NON ECN. ECN, therefore, has a huge advantage as the transactional data size gets smaller as is observed in the results. This can be explained by looking at TCP recovery mechanisms. NON ECN in the short flows depends, for recovery, on congestion signaling via receiving 3 duplicate ACKs, or worse by a retransmit timer expiration, whereas ECN depends mostly on the TCP- ECE flag. This is by design in our experimental setup. [3] shows that most of the TCP loss recovery in fact happens in timeouts for short flows. The effectiveness of the Fast Retransmit/Recovery algorithm is limited by the fact that there might not be enough data in the pipe to elicit 3 duplicate ACKs. TCP RENO needs at least 4 outstanding packets to recover from losses without going into a timeout. For 5KB (4 packets for MTU of 1500Bytes) a NON ECN flow will always have to wait for a retransmit timeout if any of its packets are lost. ( This timeout could only have been avoided if the flow had used an initial window of four packets, and the first of the four packets was the packet dropped). We repeated these experiments with the kernels implementing SACK/FACK and New Reno algorithms. Our observation was that there was hardly any difference with what we saw with Reno. For example in the case of SACK-ECN enabling: maintaining the maximum drop probability to 0.1 and increasing the congestion level for the 5KB transaction we noticed that the relative gain for the ECN enabled flows increases from 47-80%. If we maintain the congestion level for the 5KB transactions and increase the maximum drop probabilities instead, we notice that SACKs performance increases from 15%-120%. It is fair to comment that the difference in the testbeds (different machines, same topology) might have contributed to the results; however, it is worth noting that the relative advantage of the SACK-ECN is obvious.
3) 取引のデータサイズが増加するのに従って、Fast Retransmitから回復するという確率がNON ECNのために増加するので、電子証券取引ネットワークの利点は減少します。 したがって、結果で観測されて、取引のデータサイズがそのままでより小さくなるとき、電子証券取引ネットワークには巨大な利点があります。 TCP回収機構を見ることによって、これについて説明できます。短い流れにおけるNON ECNはよります、回復のために、電子証券取引ネットワークがほとんどTCP- ECE旗によって3写しACKsを受けることを通した混雑シグナリング、再送信タイマ満了で、より悪いところで。 これは私たちの実験装置で意図的です。 [3]は、事実上、TCP損失回復の大部分が短い流れのためのタイムアウトで起こるのを示します。 データがパイプに十分ないかもしれないという事実によってFast Retransmit/回復アルゴリズムの有効性は制限されて、3写しACKsを引き出します。 TCP RENOは、損失からタイムアウトに入らないで回復するために少なくとも4つの傑出しているパケットを必要とします。 パケットのどれかが無くなるなら、NON ECN流動がaを待つためにいつも持っている5KB(1500BytesのMTUのための4つのパケット)、タイムアウトを再送してください。 (流れが4つのパケットの初期の窓を使用した場合にだけ、このタイムアウトを避けることができたでしょうに、そして、4つのパケットの1番目は落とされたパケットでした。) 私たちはカーネルがSACK/ファークとNewリノアルゴリズムを実行しているこれらの実験を繰り返しました。私たちの観測は私たちがリノと共に見たものがあるほとんど少しの違いもなかったということでした。 例えば、SACK-電子証券取引ネットワークの可能にすることの場合で: 0.1と私たちが気付いた5KBの取引のために混雑レベルを増加させることへの電子証券取引ネットワークのための相対的な利得が可能にした最大の低下確率が流れると主張するのが47-80%から増えます。 代わりに5KBの取引と増加のための混雑レベルが最大の低下確率であることを支持するなら、私たちは、SACKs性能が15%から120%から増えるのに気付きます。 テストベッド(異なったマシン、同じトポロジー)の違いが結果に貢献したかもしれないと論評するのは公正です。 しかしながら、SACK-電子証券取引ネットワークの相対的な利点が明白であることに注意する価値があります。
6. Conclusion
6. 結論
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).
電子証券取引ネットワークの増進は嵩と取引の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
* 以下が再送されるので、電子証券取引ネットワークと共に起こってください、そして、それはネットワークにおけるより少ない交通を意味します。 私たちの場合で再送された相対的なデータ量はわずかですが、効果は、より高く、いつにエンドシステム不在をさらに寄付するのがあるかに再送されるということであるかもしれません。また、goodputで改良を含意します。 これはシナリオに非常に重要になります。
Salim & Ahmed Informational [Page 13] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[13ページ]のRFC2884電子証券取引ネットワーク
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.
帯域幅が安値などのように高価であるところでは、帯域幅はリンクされます。 これは、また、電子証券取引ネットワークが信頼性を必要とするアプリケーションにそれ自体をよく与えるのを含意しますが、不要な「再-トランスミッション」を避けるのを好むでしょう。
* 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.
* 電子証券取引ネットワークが、より速い通知(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.
* エンドユーザがそれらの目標金利のために、より速く「調べることができるところ」で使用中の分化を助けるのに電子証券取引ネットワークを使用できました。 IETFのdiffservワーキンググループにおける相対的優先転送[1]は、サービス分化メカニズムとして異なった低下確率でREDを使用するよう提案します。 REDの面前でさえTCP RENOの単一の窓の中の複数のパケットを落とすことができたのは可能です、タイムアウト[23]へのありそうな先導。 電子証券取引ネットワークエンドシステムは複数の通知を無視します。(通知は改良されたgoodputをもたらすこのシナリオを打ち返すのを手伝います)。 また、電子証券取引ネットワークエンドシステムは結局、より多くの速さ(最適の帯域幅に達する)にネットワークを調べます。 [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.
政策管理計画の到来が非常に短い質問といくつかのパケットの注文における応答を構成する取引のタイプのアプリケーションのための新しい要件を導入するのは、明確です。 私たちが実験で示したように電子証券取引ネットワークは取引の交通の利点を提供します。
7. Acknowledgements
7. 承認
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ナンディ、Nabil Seddigh、サリー・フロイド、およびRupinder Makkarに感謝申し上げます。
8. Security Considerations
8. セキュリティ問題
Security considerations are as discussed in section 9 of RFC 2481.
セキュリティ問題がRFC2481のセクション9で議論するようにあります。
9. References
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は分類する」RFC2597、1999年6月。
[2] B.A. Mat. "An empirical model of HTTP network traffic." In
proceedings INFOCOMM'97.
[2] 学士マット。 「HTTPネットワークトラフィックの経験的モデル。」 議事INFOCOMM97年に。
Salim & Ahmed Informational [Page 14] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[14ページ]のRFC2884電子証券取引ネットワーク
[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.、およびランディ・H.キャッツ、「aのTCP BehaviorはインターネットServerと忙しくします」。 「分析と改良」(IEEE Infocom、サンフランシスコ(カリフォルニア)(米国)の議事)は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.ウィス、「微分されたサービスのための構造」、RFC2475、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コンピュータコミュニケーションレビュー、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.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481、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] ケビンFall、サリー・フロイド、「タホ、リノ、および袋のTCPの比較」、コンピュータCommunications Review、V.26N.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.ジェーコブソン。 「輻輳回避のための無作為の早期発見ゲートウェイ。」 1993年8月のネットワーク、3(1)におけるIEEE/ACM取引。
[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.Hashem。 「ゲートウェイ輻輳制御のための無作為の低下の分析。」 Lcs tr-465下院議員、Lav。 Fot Comput。 Sci、マサチューセッツ工科大学、1989
[11] V. Jacobson. "Congestion Avoidance and Control." In Proceedings
of SIGCOMM '88, Stanford, CA, August 1988.
[11] V.ジェーコブソン。 「輻輳回避とコントロール。」 SIGCOMM88年、スタンフォード、カリフォルニア、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.Lakshman、アーニー・ナイトハルト、Teunisオット、「気圧でのTCPの前の戦略と他のコントロール機能とのその織り込むのからの低下」、Infocom96(MA28.1)。
[14] P. Mishra and H. Kanakia. "A hop by hop rate based congestion
control scheme." Proc. SIGCOMM '92, pp. 112-123, August 1992.
[14] P.MishraとH.Kanakia。 「ホップレートに従ったホップは輻輳制御計画を基礎づけました。」 Proc。 SIGCOMM92年、ページ 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変更」、RFC2582、1999年4月。
Salim & Ahmed Informational [Page 15] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[15ページ]のRFC2884電子証券取引ネットワーク
[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] ブレーデンとB.とクラークとD.とクロウクロフトとJ.とデイビーとB.とデアリングとS.とEstrinとD.とフロイドとS.とジェーコブソンとV.とMinshallとG.とヤマウズラとC.とピーターソンとL.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(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.RamakrishnanとR.ジャイナ教徒。 「コンピュータネットワークにおける輻輳回避のBinaryフィードバック計画。」 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の選択している承認オプション」、RFC2018、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.ジェーコブソン、「パケットNetworksのために共有とResource Management Modelsをリンクしてください」、Networkingの上のIEEE/ACM Transactions、Vol.3No.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、ボブPacker、「RED、電子証券取引ネットワーク、およびTCP Rate Controlの比較研究」、 http://www.packeteer.com/technology/Pdf/packeteer-final.pdf
[24] tcpdump, the protocol packet capture & dumper program.
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
ごみ捨て人夫プログラムプロトコルの[24]tcpdump、パケット捕獲、および 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は雑誌、1997年11月/12月をネットワークでつなぎます。
[27] http://www7.nortel.com:8080/CTL/ecnperf.pdf
[27] http://www7.nortel.com:8080/CTL/ecnperf.pdf
Salim & Ahmed Informational [Page 16] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[16ページ]のRFC2884電子証券取引ネットワーク
10. Authors' Addresses
10. 作者のアドレス
Jamal Hadi Salim Nortel Networks 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
ジャマルハディサリムノーテルはK2H8の9Eのオン3500縦梁Aveオタワ(カナダ)をネットワークでつなぎます。
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
Salim & Ahmed Informational [Page 17] RFC 2884 ECN in IP Networks July 2000
IPネットワーク2000年7月におけるサリムとアフマド情報[17ページ]のRFC2884電子証券取引ネットワーク
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Salim & Ahmed Informational [Page 18]
サリムとアフマドInformationalです。[18ページ]
一覧
スポンサーリンク
