Network Working Group B. Braden, USC/ISI Request for Comments: 2309 D. Clark, MIT LCS Category: Informational J. Crowcroft, UCL B. Davie, Cisco Systems S. Deering, Cisco Systems D. Estrin, USC S. Floyd, LBNL V. Jacobson, LBNL G. Minshall, Fiberlane C. Partridge, BBN L. Peterson, University of Arizona K. Ramakrishnan, ATT Labs Research S. Shenker, Xerox PARC J. Wroclawski, MIT LCS L. Zhang, UCLA April 1998 Recommendations on Queue Management and Congestion Avoidance in the Internet ｜インターネットにおけるキューマネージメント及び輻輳回避の推奨 Status of 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 (1998). All Rights Reserved. Abstract ｜概要 This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. ｜このメモは、インターネットのパフォーマンスを改善し維持するための ｜手段について、２つの推奨をインターネットコミュニティに対し与える ｜ものである。これは今日のインターネットのパフォーマンスを改善する ｜ための、ルータにおけるアクティブキューマネージメントの、試験、標 ｜準化、及び広範囲な普及についての強い推奨である。更にこれは、輻輳 ｜通知に十分に反応しないフローからインターネットを保護するための、 ｜ルータのメカニズムの研究、実験、及び最終的な展開に関して、その努 ｜力を促すものである。 1. INTRODUCTION ｜はじめに The Internet protocol architecture is based on a connectionless end- to-end packet service using the IP protocol. The advantages of its connectionless design, flexibility and robustness, have been amply demonstrated. However, these advantages are not without cost: careful design is required to provide good service under heavy load. In fact, lack of attention to the dynamics of packet forwarding can result in severe service degradation or "Internet meltdown". This phenomenon was first observed during the early growth phase of the Internet of the mid 1980s [Nagle84], and is technically called "congestion collapse". ｜インターネットプロトコルのアーキテクチャは、IPプロトコルを使用した ｜コネクションレスのエンドツーエンドのパケットサービスに基づいている。 ｜コネクションレスの設計の利点、弾力性及び強靭性は、広く証明されている。 ｜しかし、これらの利点に対するコストが存在しないわけではない：慎重な ｜設計が高負荷の下で良好なサービスを提供するために必要である。実際、 ｜パケット転送のダイナミクス【訳注：トラフィックの変動】への注意の欠如 ｜は、著しいサービス効率の低下や、「インターネットメルトダウン」と呼ば ｜れる結果を生む。この現象は1980年代半ばのインターネットの初期の成長 ｜段階の時に初めて観測され、専門的には「輻輳崩壊(congestion collapse)」 ｜と呼ばれている。 The original fix for Internet meltdown was provided by Van Jacobson. Beginning in 1986, Jacobson developed the congestion avoidance mechanisms that are now required in TCP implementations [Jacobson88, HostReq89]. These mechanisms operate in the hosts to cause TCP connections to "back off" during congestion. We say that TCP flows are "responsive" to congestion signals (i.e., dropped packets) from the network. It is primarily these TCP congestion avoidance algorithms that prevent the congestion collapse of today's Internet. ｜インターネットメルトダウンに対する対処の原型は、Van Jacobson によって ｜提供された。1986年初めジャコブソンはTCPの実装に、今現在も必要とされて ｜いる輻輳回避メカニズム[Jacobson88, HostReq89]を開発した。このメカニズ ｜ムは、輻輳の間、ホストでTCPコネクションを「バックオフ(back off)」させ ｜るよう動作する。TCPのフローはネットワークからの輻輳信号(パケットが落ち ｜ること)に対し「敏感である(responsible)」。これが今日のインターネットの ｜輻輳崩壊を防ぐ、TCP輻輳回避アルゴリズムの始まりである。 However, that is not the end of the story. Considerable research has been done on Internet dynamics since 1988, and the Internet has grown. It has become clear that the TCP congestion avoidance mechanisms [RFC2001], while necessary and powerful, are not sufficient to provide good service in all circumstances. Basically, there is a limit to how much control can be accomplished from the edges of the network. Some mechanisms are needed in the routers to complement the endpoint congestion avoidance mechanisms. ｜しかしながら話しはこれで終らない。1988年からインターネットダイナミクス ｜に関する多くの調査が行われ、またインターネットも更に成長した。TCP輻輳 ｜回避アルゴリズム[RFC2001]は必要かつ効果的であるとはいえ、全ての状況に ｜おいて良好なサービスを提供するのには不十分であることが明らかになって ｜きた。基本的に、ネットワークのエッジから、どうにかして制御を成し遂げ ｜ようとしても限界がある。ルータにエンドポイントでの輻輳回避メカニズムを ｜補間するための何らかのメカニズムが必要とされている。 It is useful to distinguish between two classes of router algorithms related to congestion control: "queue management" versus "scheduling" algorithms. To a rough approximation, queue management algorithms manage the length of packet queues by dropping packets when necessary or appropriate, while scheduling algorithms determine which packet to send next and are used primarily to manage the allocation of bandwidth among flows. While these two router mechanisms are closely related, they address rather different performance issues. ｜輻輳制御に関するルータアルゴリズムを２つのクラス：「キューマネージ ｜メント(queue management)」と「スケジューリング(scheduling)」アルゴ ｜リズムに区別することは有効である。おおまかには、キューマネージメント ｜アルゴリズムは、必要時に適切にパケットを落とすことによってパケット ｜キューの長さを管理し、一方、スケジューリングアルゴリズムは次にどの ｜パケットを送信するかを決定し、フロー間の帯域幅の割当を管理することを ｜第一の目的に使用される。これら２つのルータメカニズムは密接に関連づけ ｜られ、異なるパフォーマンスの問題を扱う。 This memo highlights two router performance issues. The first issue is the need for an advanced form of router queue management that we call "active queue management." Section 2 summarizes the benefits that active queue management can bring. Section 3 describes a recommended active queue management mechanism, called Random Early Detection or "RED". We expect that the RED algorithm can be used with a wide variety of scheduling algorithms, can be implemented relatively efficiently, and will provide significant Internet performance improvement. ｜このメモはルータのパフォーマンスに関する２つの問題に焦点をあてる。 ｜最初の問題は、我々が「アクティブキューマネージメント(active queue ｜management)」と呼ぶ、ルーターキューマネージメントの進化した形の必要 ｜性である。セクション２ではアクティブキューマネージメントがもたらす ｜恩恵について要約する。セクション３ではRED(Random Early Detection)と ｜呼ばれる、我々が推奨するアクティブキューマネージメントのメカニズムに ｜ついて記述する。我々はREDアルゴリズムがスケジューリングのアルゴリズム ｜として広く様々なところで使用することができ、しかも比較的容易に実装す ｜ることができると考えていて、これによりインターネットのパフォーマンス ｜をかなり改善することができるであろう。 The second issue, discussed in Section 4 of this memo, is the potential for future congestion collapse of the Internet due to flows that are unresponsive, or not sufficiently responsive, to congestion indications. Unfortunately, there is no consensus solution to controlling congestion caused by such aggressive flows; significant research and engineering will be required before any solution will be available. It is imperative that this work be energetically pursued, to ensure the future stability of the Internet. ｜このメモのセクション４で議論している２つ目の問題は、輻輳表示に対して ｜敏感でない又は不十分な反応をするフローによって生じるインターネットの ｜今後の輻輳崩壊の可能性である。不幸にも、アクティブなフローによって起 ｜こされる輻輳の制御についての統一見解がない；問題の解決を可能にするま ｜でに、かなりの研究と技術が要求されるであろう。インターネットの将来の ｜安定性を確実にするために、急いでこの作業を精力的に追い求めるべきである。 Section 5 concludes the memo with a set of recommendations to the IETF concerning these topics. ｜セクション５で、これらのトピックに関するIETFが推奨するセットを ｜示してこのメモを終える。 The discussion in this memo applies to "best-effort" traffic. The Internet integrated services architecture, which provides a mechanism for protecting individual flows from congestion, introduces its own queue management and scheduling algorithms [Shenker96, Wroclawski96]. Similarly, the discussion of queue management and congestion control requirements for differential services is a separate issue. However, we do not expect the deployment of integrated services and differential services to significantly diminish the importance of the best-effort traffic issues discussed in this memo. ｜このメモの議論はベストエフォートのトラフィックに適用する。個々のフロー ｜を輻輳から防止するメカニズムを提供する、インターネットのイントサーブ ｜(intergrated service)アーキテクチャは、それ自身でキューマネージメントと ｜スケジューリングアルゴリズムを取り入れている[Shenker96, Wroclawski96]。 ｜同様に、ディフサーブ(differential service)へのキューマネージント及び ｜輻輳制御の実装に関する議論は別の問題である。しかしながら、このメモの ｜議論では、ベストエフォートトラフィックの問題を軽減させる、イントサーブ ｜及びディフサーブの展開は、期待していない。 Preparation of this memo resulted from past discussions of end-to-end performance, Internet congestion, and RED in the End-to-End Research Group of the Internet Research Task Force (IRTF). ｜このメモの下地は、IRTF(Internet Research Task Force)のエンド ｜ツーエンドリサーチグループ(End-to-End Research Group) での、 ｜過去のエンドツーエンドの、パフォーマンス、インターネットの輻輳 ｜及びREDに関する議論の結果、生じたものである。 2. THE NEED FOR ACTIVE QUEUE MANAGEMENT ｜アクティブキューマネージメントの必要性 The traditional technique for managing router queue lengths is to set a maximum length (in terms of packets) for each queue, accept packets for the queue until the maximum length is reached, then reject (drop) subsequent incoming packets until the queue decreases because a packet from the queue has been transmitted. This technique is known as "tail drop", since the packet that arrived most recently (i.e., the one on the tail of the queue) is dropped when the queue is full. This method has served the Internet well for years, but it has two important drawbacks. ｜ルータのキュー長管理の伝統的なテクニックは、各々のキューに(パケット ｜の観点から)最大長を設定し、最大長に到達するまでキューにパケットを ｜受けいれ、その後、キューからパケットが送信されてキューが減少するま ｜で、続いてやって来るパケットを拒否する(落とす)。 このテクニックは ｜「テールドロップ(tail drop)」として知られていて、キューがフル状態 ｜の時は、最も最近に到達したパケット(すなわち、キューの最後のもの)を ｜脱落させる。この方法は、何年もの間インターネットでよく使われたが、 ｜これには２つの重大な欠陥がある。 1. Lock-Out ｜ロックアウト In some situations tail drop allows a single connection or a few flows to monopolize queue space, preventing other connections from getting room in the queue. This "lock-out" phenomenon is often the result of synchronization or other timing effects. ｜ある状況において、テールドロップは、１つのコネクション又は少数の ｜フローによるキューのスペースの独占を可能にし、他のコネクションが ｜キューの中に入ろうとするのを妨げる。この「ロックアウト(lock-out)」 ｜の現象は、しばしば同期や他のタイミングの影響の結果として発生する。 2. Full Queues ｜フルキュー The tail drop discipline allows queues to maintain a full (or, almost full) status for long periods of time, since tail drop signals congestion (via a packet drop) only when the queue has become full. It is important to reduce the steady-state queue size, and this is perhaps queue management's most important goal. ｜テールドロップのルールでは、キューがフル状態になった時にテール ｜ドロップは(パケットを落とすことをもって)輻輳を合図するだけで ｜あるので、長い間キューがフルの状態(又は、ほとんどフルの状態) ｜で続くことがある。定常状態でのキュー長を減少させることは重要 ｜であり、これはおそらくキューマネージメントの重要な目標である。 The naive assumption might be that there is a simple tradeoff between delay and throughput, and that the recommendation that queues be maintained in a "non-full" state essentially translates to a recommendation that low end-to-end delay is more important than high throughput. However, this does not take into account the critical role that packet bursts play in Internet performance. Even though TCP constrains a flow's window size, packets often arrive at routers in bursts [Leland94]. If the queue is full or almost full, an arriving burst will cause multiple packets to be dropped. This can result in a global synchronization of flows throttling back, followed by a sustained period of lowered link utilization, reducing overall throughput. ｜単純に考えると、遅延とスループットとの間には単純なトレードオフが ｜存在し、キューに「フル状態でない」状態を続けさせることを推奨す ｜ることは、本質的には、高いスループットよりも低いエンドツーエンド ｜の遅延の方がより重要だと推奨することである。しかしながら、これは ｜インターネットのパフォーマンスにおける、パケットのバースト的な ｜振舞いという重大な性質を考慮にいれていない。TCPがフローをウィン ｜ドウサイズに強制したとしても、パケットはしばしばバーストでルータ ｜に到達する[Leland94]。もしキューがフル状態又はほとんどフルの状態 ｜であるならば、バーストによる到着は複数のパケットを落とすことを強 ｜いるであろう。これはフロー全体の同期を減速させ、リンク利用率が低 ｜い時間を継続させるので、全体的なスループットを減少させる結果とな ｜る。 The point of buffering in the network is to absorb data bursts and to transmit them during the (hopefully) ensuing bursts of silence. This is essential to permit the transmission of bursty data. It should be clear why we would like to have normally- small queues in routers: we want to have queue capacity to absorb the bursts. The counter-intuitive result is that maintaining normally-small queues can result in higher throughput as well as lower end-to-end delay. In short, queue limits should not reflect the steady state queues we want maintained in the network; instead, they should reflect the size of bursts we need to absorb. ｜ネットワークにおけるバッファリングのポイントは、データのバースト ｜を吸収することと、それを(期待される)連続する静かな【訳注：パケッ ｜トのない】バーストの間に転送することである。これは、バースト的な ｜データの送信を可能にするために不可欠である。これは、ルーターに ｜定常時には小さいキューを持たせたいと我々が考えていることを明確に ｜している：キューの容量はバーストを吸収するために持っていたいので ｜ある。この反直観的な結果は、定常時に小さいキューを保持することが、 ｜低いエンドツーエンドの遅延を得るのと共に、高いスループットを結果 ｜として得るということである。要するに、ネットワーク上で維持すべき ｜キューのリミットは、定常状態のキューを反映する必要はない；代わり ｜に、バーストを吸収するのに必要なサイズを反映すべきである。 Besides tail drop, two alternative queue disciplines that can be applied when the queue becomes full are "random drop on full" or "drop front on full". Under the random drop on full discipline, a router drops a randomly selected packet from the queue (which can be an expensive operation, since it naively requires an O(N) walk through the packet queue) when the queue is full and a new packet arrives. Under the "drop front on full" discipline [Lakshman96], the router drops the packet at the front of the queue when the queue is full and a new packet arrives. Both of these solve the lock-out problem, but neither solves the full-queues problem described above. ｜テールドロップの他に、キューがフル状態になった時にとりうる２つの ｜代わりのキューのルールは、「フル状態時におけるランダムドロップ ｜(random drop on full)」又は「フル状態時におけるドロップフロント ｜(drop front on full)」である。フル状態の際、ランダムドロップの ｜ルールでは、ルータはキューがフルになり、そして新たにパケットが ｜到着した際に、キューからランダムにパケットを選択して落とす。 ｜(これは、パケットキューを通して O(N)動作を単純に要求するため、高 ｜価なオペレーションである)。「フル状態時におけるドロップフロント」 ｜[Lakshman96]では、ルーターは、キューがフル状態でパケットが到着し ｜た際に、キューの先頭のパケットを落とす。これらは共にロックアウト ｜の問題を解決するが、これらは共に上に示したフルキューの問題を解決 ｜していない。 We know in general how to solve the full-queues problem for "responsive" flows, i.e., those flows that throttle back in response to congestion notification. In the current Internet, dropped packets serve as a critical mechanism of congestion notification to end nodes. The solution to the full-queues problem is for routers to drop packets before a queue becomes full, so that end nodes can respond to congestion before buffers overflow. We call such a proactive approach "active queue management". By dropping packets before buffers overflow, active queue management allows routers to control when and how many packets to drop. The next section introduces RED, an active queue management mechanism that solves both problems listed above (given responsive flows). ｜「敏感な(responsive)」フローに対してフルキューの問題を解決する方法 ｜として、輻輳通知の応答によってフローを減速させることが一般に知られ ｜ている。現在のインターネットでは、落とされたパケットが終端ノードに ｜輻輳を注意する重要なメカニズムとして役立っている。フルキューの問題 ｜の解決は、ルータに、キューがフル状態になる前にパケットを落とさせて ｜しまうことであり、これによってバッファがオーバーフローする前に終端 ｜ノードで輻輳に反応することが可能になる。我々はこのようなアクティブな ｜アプローチを「アクティブキューマネージメント(aqutive queue management)」 ｜と呼ぶ。バッファがオーバーフローする前にパケットを落とすことによって、 ｜アクティブキューマネージメントはいつ、どれだけのパケットを落とすかを ｜ルータに制御させることを可能にする。次のセクションで(敏感なフローが ｜与えられた際に)上にあげた両方の問題を解決するアクティブキューマネー ｜ジメントすなわちREDを紹介する。 In summary, an active queue management mechanism can provide the following advantages for responsive flows. ｜要約すると、アクティブキューマネージメントメカニズムは、敏感なフロー ｜に対し、進化したフローを提供するものである。 1. Reduce number of packets dropped in routers ｜ルータで落ちるパケット数の削減 Packet bursts are an unavoidable aspect of packet networks [Willinger95]. If all the queue space in a router is already committed to "steady state" traffic or if the buffer space is inadequate, then the router will have no ability to buffer bursts. By keeping the average queue size small, active queue management will provide greater capacity to absorb naturally- occurring bursts without dropping packets. ｜パケットネットワークにおいては、パケットのバーストは避けられ ｜ない[Willinger95]。 もしルータ内の全てのキュースペースが既に ｜「定常状態(steady state)」のトラフィックに占められ、バッファ ｜スペースが不足しているならば、ルータはバーストをバッファリング ｜する余裕がない。アクティブキューマネージメントは、キューサイズ ｜の平均を小さく保つことによって、パケットを落とすこと無く、自然 ｜に発生するバーストを吸収するためのより大きな能力を提供する。 Furthermore, without active queue management, more packets will be dropped when a queue does overflow. This is undesirable for several reasons. First, with a shared queue and the tail drop discipline, an unnecessary global synchronization of flows cutting back can result in lowered average link utilization, and hence lowered network throughput. Second, TCP recovers with more difficulty from a burst of packet drops than from a single packet drop. Third, unnecessary packet drops represent a possible waste of bandwidth on the way to the drop point. ｜さらに、アクティブキューマネージメントが無い場合では、キューが ｜オーバフローを起こした際により多くのパケットが脱落するであろう。 ｜これには望ましくないいくつかの理由がある。まず最初に、共有されて ｜いるキューとテールドロップによって抑制される、不必要な全フローに ｜対するカットバックの同期は、低い平均リンク使用率を結果としてもた ｜らし、より低いネットワークスループットとなる。２つめに、１つの ｜パケットが落ちることよりも、バースト的にパケットが落ちることの ｜方が、TCPを修復することはより困難であろう。３つめに、パケットを ｜不要に落とすことは、落ちた時点においての帯域を無駄にしている ｜可能性がある。 We note that while RED can manage queue lengths and reduce end- to-end latency even in the absence of end-to-end congestion control, RED will be able to reduce packet dropping only in an environment that continues to be dominated by end-to-end congestion control. ｜我々は、REDがキュー長を管理し、エンドツーエンドで輻輳制御がない ｜場合でさえもエンドツーエンドでの潜在を減らすことが可能であると ｜同時に、エンドツーエンドの輻輳制御によって制御され続ける環境では、 ｜落ちるパケットの数を減らすことが可能であることを示す。 2. Provide lower-delay interactive service ｜低遅延双方向サービスの提供 By keeping the average queue size small, queue management will reduce the delays seen by flows. This is particularly important for interactive applications such as short Web transfers, Telnet traffic, or interactive audio-video sessions, whose subjective (and objective) performance is better when the end-to-end delay is low. ｜平均キュー長を短く保つことによって、キューマネージメントは ｜フローに見られる遅延を減らすことが可能である。これは、短い ｜Web転送、Telnetトラフィック、双方向(interactive)オーディオ ｜ビデオのセッションのような、エンドツーエンドの遅延が低い場 ｜合に、主観的(かつ客観的)にパフォーマンスがより良くなるよう ｜な、双方向アプリケーションには特に重要である。 3. Avoid lock-out behavior ｜ロックアウトの挙動の回避 Active queue management can prevent lock-out behavior by ensuring that there will almost always be a buffer available for an incoming packet. For the same reason, active queue management can prevent a router bias against low bandwidth but highly bursty flows. ｜アクティブキューマネージメントは常に入力パケットをバッファする ｜ことを保障することによってロックアウトの挙動を防止する。いくつ ｜かの理由で、アクティブキューマネージメントは、低帯域だが高バー ｜スト性を持つフローにルータが偏よることを防止する。 It is clear that lock-out is undesirable because it constitutes a gross unfairness among groups of flows. However, we stop short of calling this benefit "increased fairness", because general fairness among flows requires per-flow state, which is not provided by queue management. For example, in a router using queue management but only FIFO scheduling, two TCP flows may receive very different bandwidths simply because they have different round-trip times [Floyd91], and a flow that does not use congestion control may receive more bandwidth than a flow that does. Per-flow state to achieve general fairness might be maintained by a per-flow scheduling algorithm such as Fair Queueing (FQ) [Demers90], or a class-based scheduling algorithm such as CBQ [Floyd95], for example. ｜ロックアウトは著しい不公平をフローのグループ間で生み出すので、 ｜望ましくないことは明確である。しかしながら、我々はこの効果を ｜もって「公平性が増加した(increased fairness)」と言うにはいたっ ｜ていない。なぜならフロー間における一般的な公平性には、フロー毎 ｜の状態(state)が必要とされ、これをキューマネージメントは提供し ｜ないからである。例えばキューマネージメントを使用するがFIFOスケ ｜ジューリングだけのルータでは、単純に、ラウンドトリップ(round- ｜trip)時間だけが異なる２つのTCPのフローは非常に異なる帯域幅を ｜取り[Floyd91]、輻輳制御を使用しないフローはそれを行うフロー ｜よりも、より多くの帯域幅を受け取るであろう。一般的な公平性を ｜達成するためのフロー毎の状態は、例えば、FQ(Fair Queueing) ｜[Demers90]のようなフロー毎のスケジューリングアルゴリズムか、 ｜CBQ [Floyd95]のようなクラスベースのスケジューリングアルゴリズム ｜によって維持されるべきである。 On the other hand, active queue management is needed even for routers that use per-flow scheduling algorithms such as FQ or class-based scheduling algorithms such as CBQ. This is because per-flow scheduling algorithms by themselves do nothing to control the overall queue size or the size of individual queues. Active queue management is needed to control the overall average queue sizes, so that arriving bursts can be accommodated without dropping packets. In addition, active queue management should be used to control the queue size for each individual flow or class, so that they do not experience unnecessarily high delays. Therefore, active queue management should be applied across the classes or flows as well as within each class or flow. ｜一方、アクティブキューマネージメントはFQのようなフロー毎の ｜スケジューリングアルゴリズム又はCBQのようなクラスベースの ｜スケジューリングアルゴリズムにさえ必要とされる。この理由は、 ｜フロー毎スケジューリングアルゴリズムは自分自身によって全体 ｜のキュー長又は個々のキューの長さの制御ができないからである。 ｜アクティブキューマネージメントは全体の平均キュー長を制御する ｜のに必要とされ、バーストで到着するパケットを落とすことなく ｜収めることができる。加えて、アクティブキューマネージメントは ｜個々のフロー又はクラスのキュー長制御に使用され、彼らに不要に ｜高い遅延を経験させない。それゆえ、アクティブキューマネージ ｜メントはクラス又はフロー毎のそれぞれと同様に、クラス又はフロー ｜にまたがって適用することもできる。 In short, scheduling algorithms and queue management should be seen as complementary, not as replacements for each other. In particular, there have been implementations of queue management added to FQ, and work is in progress to add RED queue management to CBQ. ｜要約すると、スケジューリングアルゴリズムとキューマネージメント ｜は補間しあい、もう一方を置き換えるものではない。とりわけ、FQに ｜キューマネージメントを追加した実装は既に存在し、CBQにREDキュー ｜マネージメントを追加することは、現在作業中である。 3. THE QUEUE MANAGEMENT ALGORITHM "RED" ｜キューマネージメントアルゴリズム「RED」 Random Early Detection, or RED, is an active queue management algorithm for routers that will provide the Internet performance advantages cited in the previous section [RED93]. In contrast to traditional queue management algorithms, which drop packets only when the buffer is full, the RED algorithm drops arriving packets probabilistically. The probability of drop increases as the estimated average queue size grows. Note that RED responds to a time-averaged queue length, not an instantaneous one. Thus, if the queue has been mostly empty in the "recent past", RED won't tend to drop packets (unless the queue overflows, of course!). On the other hand, if the queue has recently been relatively full, indicating persistent congestion, newly arriving packets are more likely to be dropped. ｜RED(Random Early Detection)は、ルータのためのアクティブキューマネージ ｜メントアルゴリズムで、前のセクション[RED93]で引用したインターネットの ｜パフォーマンスの改善を提供する。バッファがフルになった時にだけパケット ｜を落とす伝統的なキューマネージメントアルゴリズムと対象的に、REDアルゴリ ｜ズムは確率的である。落とす確率は見積もられた平均キュー長の成長に伴って ｜増加する。REDは時間平均のキュー長に反応し、瞬間の値にではないことに注 ｜意。それゆえ、もし「直前で」キューがほとんど空であれば、REDはパケット ｜を落そうとはしない(もちろん！ キューがオーバフローしない条件で)。一方、 ｜キューが直前で相対的にフルであれば、持続的な輻輳が示される間は、新しく ｜到着したパケットはほとんど落とされる。 The RED algorithm itself consists of two main parts: estimation of the average queue size and the decision of whether or not to drop an incoming packet. ｜REDアルゴリズム自身は２つの主要な部分で構成される：平均キュー長の ｜評価と、入力パケットを落とすかどうかの決定である。 (a) Estimation of Average Queue Size ｜平均キュー長の評価 RED estimates the average queue size, either in the forwarding path using a simple exponentially weighted moving average (such as presented in Appendix A of [Jacobson88]), or in the background (i.e., not in the forwarding path) using a similar mechanism. ｜REDは、転送パスで単純指数的加重遷移平均(simple expponentially ｜weighted moving average) ([Jacobson88] の付録Aで示されるような) ｜を使用するか、又はバックグランド(すなわち転送パスでないところ) ｜で同様のメカニズムを使用して平均キュー長を評価する。 Note: The queue size can be measured either in units of packets or of bytes. This issue is discussed briefly in [RED93] in the "Future Work" section. ｜注意：キュー長はパケット又はバイトの単位のどちらかで測定 ｜することができる。この問題は「将来の作業(Future Work)」 ｜セクション[RED93]の中で、簡単に議論している。 Note: when the average queue size is computed in the forwarding path, there is a special case when a packet arrives and the queue is empty. In this case, the computation of the average queue size must take into account how much time has passed since the queue went empty. This is discussed further in [RED93]. ｜注意：転送パスで平均キュー長を計算する場合で、パケットが ｜到着した際にキューが空の場合は特別な場合である。この場合 ｜の平均キュー長は、キューが空になった時からの時間がどの ｜くらいであるかを計算しなければならない。これは[RED93]で ｜将来議論される。 (b) Packet Drop Decision ｜パケットを落とすことの判定 In the second portion of the algorithm, RED decides whether or not to drop an incoming packet. It is RED's particular algorithm for dropping that results in performance improvement for responsive flows. Two RED parameters, minth (minimum threshold) and maxth (maximum threshold), figure prominently in this decision process. Minth specifies the average queue size *below which* no packets will be dropped, while maxth specifies the average queue size *above which* all packets will be dropped. As the average queue size varies from minth to maxth, packets will be dropped with a probability that varies linearly from 0 to maxp. ｜アルゴリズムの２つめの部分で、REDは入力パケットを落とすかどうか ｜を決定する。落とすためのREDの個々のアルゴリズムは、敏感なフロー ｜のパフォーマンスを改善させる。２つのREDパラメータminth(最小閾値) ｜とmaxth(最大閾値)はこの決定プロセスを顕著に示す。minthはパケット ｜を落とさない＊までの＊平均キュー長を示し、maxthは全てのパケット ｜を落とし＊はじめる＊平均キュー長を示す。平均キュー長はminthから ｜maxthまで変化するので、パケットが落される確率は0からmaxpまで ｜直線的に変化する。 Note: a simplistic method of implementing this would be to calculate a new random number at each packet arrival, then compare that number with the above probability which varies from 0 to maxp. A more efficient implementation, described in [RED93], computes a random number *once* for each dropped packet. ｜注意：単純な実装の方法は、各パケットが到着した際に新しい ｜乱数を計算して、それを 0 から maxp まで変化する上の確率と ｜比較する。[RED93]で記述されたより効果的な実装は、落とす ｜各パケットのために、乱数を＊１度だけ＊計算する。 Note: the decision whether or not to drop an incoming packet can be made in "packet mode", ignoring packet sizes, or in "byte mode", taking into account the size of the incoming packet. The performance implications of the choice between packet mode or byte mode is discussed further in [Floyd97]. ｜注意：入力パケットを落とすか否かの決定は、パケット長を ｜無視した「パケットモード」で行うことも、入力パケット長を ｜数える「バイトモード」でもできる。パケットモードとバイト ｜モードの選択とパフォーマンスの関係は、[Floyd97]で将来議論 ｜される。 RED effectively controls the average queue size while still accommodating bursts of packets without loss. RED's use of randomness breaks up synchronized processes that lead to lock-out phenomena. ｜REDはパケットを失なうことなく、バーストが収まるまで平均キュー長を ｜効果的に制御する。REDでの乱数の使用は、同期プロセスがロックアウト ｜現象を導こうとするのを破壊する。 There have been several implementations of RED in routers, and papers have been published reporting on experience with these implementations ([Villamizar94], [Gaynor96]). Additional reports of implementation experience would be welcome, and will be posted on the RED web page [REDWWW]. ｜ルータにREDを実装するいくつかの方法が既にあり、これらの実装経験は ｜公開レポートとして文書化されている([Villamizar94]、[Gaynor96])。 ｜実装実験の追加レポートは歓迎されていて、これらはREDウェーブページ ｜[REDWWW]にポストされるであろう。 All available empirical evidence shows that the deployment of active queue management mechanisms in the Internet would have substantial performance benefits. There are seemingly no disadvantages to using the RED algorithm, and numerous advantages. Consequently, we believe that the RED active queue management algorithm should be widely deployed. ｜全ての有効な実験の結果では、インターネットでのアクティブキューマネー ｜ジメントメカニズムの開発は、相当なパフォーマンスの恩恵があることを ｜示している。REDアルゴリズムを使用することによる短所は表面上あらわれ ｜ていない。この結果から、我々はREDアクティブキューマネージメントアル ｜ゴリズムが広く展開されることを信じている。 We should note that there are some extreme scenarios for which RED will not be a cure, although it won't hurt and may still help. An example of such a scenario would be a very large number of flows, each so tiny that its fair share would be less than a single packet per RTT. ｜実害がなく補助することも可能とはいえ、REDで矯正できないいくらかの ｜極端なシナリオが存在することに我々は気づいている。このようなシナリオ ｜の例は、個々がとても小さい非常に多数のフローの場合で、これの公平な ｜割り当てはRTT毎の１パケットの場合よりも失われる。 4. MANAGING AGGRESSIVE FLOWS ｜アグレッシブなフローの管理 One of the keys to the success of the Internet has been the congestion avoidance mechanisms of TCP. Because TCP "backs off" during congestion, a large number of TCP connections can share a single, congested link in such a way that bandwidth is shared reasonably equitably among similarly situated flows. The equitable sharing of bandwidth among flows depends on the fact that all flows are running basically the same congestion avoidance algorithms, conformant with the current TCP specification [HostReq89]. ｜インターネットで成功するための鍵のひとつはTCPの輻輳回避メカニズム ｜である。輻輳している間、TCPの「バックオフ」によって多数のTCP接続 ｜は同じ状況のフロー間で帯域を合理的に公平に分配し、輻輳したリンク１ ｜つを共有することができる。フロー間の帯域の供給の公平さは、現在のTCP ｜の仕様[HostReq89]に従って、全てのフローで同じ輻輳回避アルゴリズムが ｜実行されているという事実による。 We introduce the term "TCP-compatible" for a flow that behaves under congestion like a flow produced by a conformant TCP. A TCP- compatible flow is responsive to congestion notification, and in steady-state it uses no more bandwidth than a conformant TCP running under comparable conditions (drop rate, RTT, MTU, etc.) ｜我々は、TCPの形で生み出されるフローと同じ様に輻輳時に振舞うフローを ｜示す「TCP互換(TCP-compatible)」という用語を紹介する。TCP互換フロー ｜は輻輳の検出に敏感であり、定常状態において同じ環境(廃棄率、RTT、MTU ｜等)下でTCPに従って実行するのと、同じだけの帯域を使用する。 It is convenient to divide flows into three classes: (1) TCP- compatible flows, (2) unresponsive flows, i.e., flows that do not slow down when congestion occurs, and (3) flows that are responsive but are not TCP-compatible. The last two classes contain more aggressive flows that pose significant threats to Internet performance, as we will now discuss. ｜フローを3つのクラスに分けることは便利である：(1)TCP互換フロー、 ｜(2)敏感でないフロー、すなわち輻輳発生時にスローダウンしないフロー ｜及び(3)敏感だがTCP互換でないフロー。後の２クラスのアグレッシブな ｜フローには、今から議論するような重要なインターネットのパフォーマンス ｜に対する脅威が含まれている。 o Non-Responsive Flows ｜敏感でないフロー There is a growing set of UDP-based applications whose congestion avoidance algorithms are inadequate or nonexistent (i.e, the flow does not throttle back upon receipt of congestion notification). Such UDP applications include streaming applications like packet voice and video, and also multicast bulk data transport [SRM96]. If no action is taken, such unresponsive flows could lead to a new congestion collapse. ｜輻輳回避アルゴリズムが不十分又は存在しない(すなわち輻輳通知を受け ｜取ってもフローは減速しない)UDPベースのアプリケーションセットが増 ｜加している。このようなUDPアプリケーションには、ストリーミングアプ ｜リケーションのようなデータや、マルチキャストのバルクデータ転送 ｜[SRM96]もまた含まれる。もし何のアクションも取らなければ、このよう ｜な敏感でないフローは、新たな輻輳崩壊を引き起こすであろう。 In general, all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms. For example, recent research has shown the possibility of incorporating congestion avoidance mechanisms such as Receiver- driven Layered Multicast (RLM) within UDP-based streaming applications such as packet video [McCanne96; Bolot94]. Further research and development on ways to accomplish congestion avoidance for streaming applications will be very important. ｜一般に、全てのUDPベースのストリーミングアプリケーションは効果的 ｜な輻輳回避メカニズムを組み入れるべきである。最近の研究では、例え ｜ばパケットビデオのようなUDPベースのストリーミングアプリケーション ｜でのRLM(Receiver-driven Layered Multicast)のような、統合輻輳回避 ｜アルゴリズムの可能性を示している。それゆえ、ストリーミングアプ ｜リケーションに対して輻輳回避を達成するための方法の研究と開発は非常 ｜に重要である。 However, it will also be important for the network to be able to protect itself against unresponsive flows, and mechanisms to accomplish this must be developed and deployed. Deployment of such mechanisms would provide incentive for every streaming application to become responsive by incorporating its own congestion control. ｜しかしながら、ネットワークに対し敏感でないフローから自分自身を ｜守ることや、それを達成させるためのメカニズムの開発と展開も重要 ｜である。このようなメカニズムの展開は、全てのストリーミングアプ ｜リケーションに、それ自身の輻輳制御の統合による、敏感になる動機 ｜を与える。 o Non-TCP-Compatible Transport Protocols ｜TCP互換でないトランスポートプロトコル The second threat is posed by transport protocol implementations that are responsive to congestion notification but, either deliberately or through faulty implementations, are not TCP- compatible. Such applications can grab an unfair share of the network bandwidth. ｜２つめの脅威は、輻輳通知に反応するが、故意あるいは欠陥のある ｜実装のいずれかによる、TCP互換でないトランスポートプロトコル ｜の実装によって起こされる。このようなアプリケーションはネット ｜ワーク帯域の割り当てを不公平に取得することができる。 For example, the popularity of the Internet has caused a proliferation in the number of TCP implementations. Some of these may fail to implement the TCP congestion avoidance mechanisms correctly because of poor implementation. Others may deliberately be implemented with congestion avoidance algorithms that are more aggressive in their use of bandwidth than other TCP implementations; this would allow a vendor to claim to have a "faster TCP". The logical consequence of such implementations would be a spiral of increasingly aggressive TCP implementations, leading back to the point where there is effectively no congestion avoidance and the Internet is chronically congested. ｜例えば、インターネットの流行は、TCP実装数の急増の要因となった。 ｜これらのいくつかはまずい実装をしていて、TCP輻輳回避メカニズムを ｜正確に実装することに失敗している。他にも、故意により積極的に他 ｜のTCPアルゴリズムよりもより多くの帯域幅を使用するような輻輳回避 ｜アルゴリズムも実装されている；これはベンダーによる「高速TCP ｜(faster TCP)」の要求を可能にする。このような実装による理論的な ｜結果は、積極的なTCPの実装をますます広め、これは輻輳回避の効果が ｜ない地点に引き戻し、インターネットを慢性的に輻輳させる。 Note that there is a well-known way to achieve more aggressive TCP performance without even changing TCP: open multiple connections to the same place, as has been done in some Web browsers. ｜TCPの変更がなくても、よりTCPのパフォーマンスをアグレッシブにする ｜ことは、よく知られた方法であることに注意：複数コネクションを同時 ｜に開くことは、いくつかのウェーブブラウザで既に行われている。 The projected increase in more aggressive flows of both these classes, as a fraction of total Internet traffic, clearly poses a threat to the future Internet. There is an urgent need for measurements of current conditions and for further research into the various ways of managing such flows. There are many difficult issues in identifying and isolating unresponsive or non-TCP-compatible flows at an acceptable router overhead cost. Finally, there is little measurement or simulation evidence available about the rate at which these threats are likely to be realized, or about the expected benefit of router algorithms for managing such flows. ｜インターネットのトラフック全体の一部で、予測されるこれら両方のクラスの ｜よりアグレッシブなフローの増加は、インターネットの将来の方向を明らかに ｜している。現在の状態の実測と、このようなフローを管理する様々な手法に ｜関する今日の研究は火急を要する。ルータへのオーバヘッドのコストが許容 ｜できる範囲での、敏感でない又はTCP互換でないフローの識別と分離に関して ｜は多くの異なる議論がある。いまだ、これらの脅威が実現する割合について、 ｜又はこのようなフローの管理のアルゴリズムで期待される恩恵についての、 ｜有効な実測又はシミュレーションでの証明は少ししかない。 There is an issue about the appropriate granularity of a "flow". There are a few "natural" answers: 1) a TCP or UDP connection (source address/port, destination address/port); 2) a source/destination host pair; 3) a given source host or a given destination host. We would guess that the source/destination host pair gives the most appropriate granularity in many circumstances. However, it is possible that different vendors/providers could set different granularities for defining a flow (as a way of "distinguishing" themselves from one another), or that different granularities could be chosen for different places in the network. It may be the case that the granularity is less important than the fact that we are dealing with more unresponsive flows at *some* granularity. The granularity of flows for congestion management is, at least in part, a policy question that needs to be addressed in the wider IETF community. ｜「フロー」の適切な分解度に関する議論がある。これらに関する「自然な」 ｜答えは少ししかない：1) TCP又はUDP接続(送信元アドレス／ポート、宛先 ｜アドレス／ポート)； 2) 送信元／宛先ホストのペア； 3)与えられた送信 ｜元ホスト又は与えられた宛先ホスト。我々は送信元／宛先ホストのペアが ｜多くの状況において最も適切な分解度であると考えている。しかしながら ｜異なるベンダ／プロバイダは(他から自分自身を「識別する」方法によって) ｜定義するフローに異なる分解度を設定することが可能で、あるいは、異なる ｜分解度をネットワークの異なる場所で選択することができる。分解度は＊なん ｜らかの＊分解度で敏感でないフローを扱うことよりも、重要でない場合があり、 ｜少なくとも部分的に、必要なポリシー問題はより大きなIETFコミュニティでの ｜問題である。 5. CONCLUSIONS AND RECOMMENDATIONS ｜終結と推奨 This discussion leads us to make the following recommendations to the IETF and to the Internet community as a whole. ｜この議論は、全体としてIETFとインターネットコミュニティに対し、以下の ｜推奨を我々に作成させる。 o RECOMMENDATION 1: ｜推奨１： Internet routers should implement some active queue management mechanism to manage queue lengths, reduce end-to-end latency, reduce packet dropping, and avoid lock-out phenomena within the Internet. ｜インターネットルータはインターネット内でのキュー長を管理し、 ｜エンドツーエンドの遅れを減らし、パケットが落ちることを減らし、 ｜ロックアウト現象を避けるために、なんらかのアクティブキュー ｜マネージメントメカニズムを実装するべきである。 The default mechanism for managing queue lengths to meet these goals in FIFO queues is Random Early Detection (RED) [RED93]. Unless a developer has reasons to provide another equivalent mechanism, we recommend that RED be used. ｜FIFOキューでのこれらの目的にあうキュー長管理のためのデフォルトの ｜メカニズムはREDである[RED93]。他の同等のメカニズムを開発し提供す ｜るための理由がないので、我々はREDが使用されることを推奨する。 o RECOMMENDATION 2: ｜推奨２： It is urgent to begin or continue research, engineering, and measurement efforts contributing to the design of mechanisms to deal with flows that are unresponsive to congestion notification or are responsive but more aggressive than TCP. ｜与えられる輻輳通知に鈍感又は敏感だがTCPよりアグレッシブなフローを ｜扱うメカニズムの設計に貢献する研究、エンジニアリング、及び実測の ｜努力を開始し続けることは急を要する。 Although there has already been some limited deployment of RED in the Internet, we may expect that widespread implementation and deployment of RED in accordance with Recommendation 1 will expose a number of engineering issues. For example, such issues may include: implementation questions for Gigabit routers, the use of RED in layer 2 switches, and the possible use of additional considerations, such as priority, in deciding which packets to drop. ｜インターネットにおいて、制限のあるREDの実装はいくらか既に存在するが、 ｜我々は推奨１によって、REDの実装と展開が広がることで、多数の技術的な ｜問題が明らかにされることを期待している。例えばこのような問題が含ま ｜れるであろう：ギガビットルータへの実装の問題で、レイヤ２スイッチでの ｜REDの使用は、パケットを落とすことを決定するにあたって、プライオリティ ｜のような考慮を追加して、使用することが可能である。 We again emphasize that the widespread implementation and deployment of RED would not, in and of itself, achieve the goals of Recommendation 2. ｜我々は 広範囲に及ぶREDの実装と展開は、それ自身は、推奨２の目的を ｜達成していないことを、再度強調する。 Widespread implementation and deployment of RED will also enable the introduction of other new functionality into the Internet. One example of an enabled functionality would be the addition of explicit congestion notification [Ramakrishnan97] to the Internet architecture, as a mechanism for congestion notification in addition to packet drops. A second example of new functionality would be implementation of queues with packets of different drop priorities; packets would be transmitted in the order in which they arrived, but during times of congestion packets of the lower drop priority would be preferentially dropped. ｜REDの開発と実装が広く行きわたることは、インターネット内に他の新しい ｜機能を導入することも可能にする。可能な機能の例の１つは、パケットを ｜落とすことに加えて新たな輻輳通知メカニズム、インターネットアーキテ ｜クチャでの、明確な輻輳通知(explicit congestion notification)の追加 ｜[Remakrishnan97]である。２つめ新しい機能の例は、異なる廃棄プライオ ｜リティをもつパケットのキューの実装；パケットは到着順に転送されるが、 ｜輻輳の間は、より低い廃棄プライオリティのパケットが優先的に落とされる。 6. References ｜参照 [Bolot94] Bolot, J.-C., Turletti, T., and Wakeman, I., Scalable Feedback Control for Multicast Video Distribution in the Internet, ACM SIGCOMM '94, Sept. 1994. [Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience, Vol. 1, 1990, pp. 3-26. [Floyd91] Floyd, S., Connections with Multiple Congested Gateways in Packet-Switched Networks Part 1: One-way Traffic. Computer Communications Review, Vol.21, No.5, October 1991, pp. 30-47. URL http://ftp.ee.lbl.gov/floyd/. [Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995. [Floyd97] Floyd, S., RED: Discussions of Byte and Packet Modes, March 1997 email, http://www-nrg.ee.lbl.gov/floyd/REDaveraging.txt. [Gaynor96] Gaynor, M., Proactive Packet Dropping Methods for TCP Gateways, October 1996, URL http://www.eecs.harvard.edu/~gaynor/ final.ps. [HostReq89] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. [Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988. [Lakshman96] 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. [Leland94] W. Leland, M. Taqqu, W. Willinger, and D. Wilson, On the Self-Similar Nature of Ethernet Traffic (Extended Version), IEEE/ACM Transactions on Networking, 2(1), pp. 1-15, February 1994. [McCanne96] McCanne, S., Jacobson, V., and M. Vetterli, Receiver- driven Layered Multicast, ACM SIGCOMM [Nagle84] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984. [Ramakrishnan97] Ramakrishnan, K. K., and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Work in Progress. [RED93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, pp. 397-413. Also available from http://ftp.ee.lbl.gov/floyd/red.html. [REDWWW] Floyd, S., The RED Web Page, 1997, URL http://ftp.ee.lbl.gov/floyd/red.html. [RFC 2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. [Shenker96] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", Work in Progress. [SRM96] Floyd. S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang, A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. ACM SIGCOMM '96, pp 342-355. [Villamizar94] Villamizar, C., and Song, C., High Performance TCP in ANSNET. Computer Communications Review, V. 24 N. 5, October 1994, pp. 45-60. URL http://ftp.ans.net/pub/papers/tcp-performance.ps. [Willinger95] W. Willinger, M. S. Taqqu, R. Sherman, D. V. Wilson, Self-Similarity Through High-Variability: Statistical Analysis of Ethernet LAN Traffic at the Source Level, ACM SIGCOMM '95, pp. 100- 113, August 1995. [Wroclawski96] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", Work in Progress. Security Considerations ｜セキュリティに関する考察 While security is a very important issue, it is largely orthogonal to the performance issues discussed in this memo. We note, however, that denial-of-service attacks may create unresponsive traffic flows that are indistinguishable from flows from normal high-bandwidth isochronous applications, and the mechanism suggested in Recommendation 2 will be equally applicable to such attacks. ｜セキュリティはとても重要な問題であり、このメモで議論されるパフォー ｜マンスの問題と直接にかかわる大きなものである。我々は、サービス拒否 ｜アタック(denial-of-service)は、敏感でないトラフィックフローを作成し、 ｜これは通常の広帯域幅の非同期アプリケーションとフローの区別ができな ｜いが、推奨２で提案するメカニズムはこのようなアタックにも適用できる ｜であろう。 Authors' Addresses ｜著者のアドレス Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 310-822-1511 EMail: Braden@ISI.EDU David D. Clark MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 Phone: 617-253-6003 EMail: DDC@lcs.mit.edu Jon Crowcroft University College London Department of Computer Science Gower Street London, WC1E 6BT ENGLAND Phone: +44 171 380 7296 EMail: Jon.Crowcroft@cs.ucl.ac.uk Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Phone: EMail: bdavie@cisco.com Steve Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-527-8213 EMail: deering@cisco.com Deborah Estrin USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 310-822-1511 EMail: Estrin@usc.edu Sally Floyd Lawrence Berkeley National Laboratory, MS 50B-2239, One Cyclotron Road, Berkeley CA 94720 Phone: 510-486-7518 EMail: Floyd@ee.lbl.gov Van Jacobson Lawrence Berkeley National Laboratory, MS 46A, One Cyclotron Road, Berkeley CA 94720 Phone: 510-486-7519 EMail: Van@ee.lbl.gov Greg Minshall Fiberlane Communications 1399 Charleston Road Mountain View, CA 94043 Phone: +1 650 237 3164 EMail: Minshall@fiberlane.com Craig Partridge BBN Technologies 10 Moulton St. Cambridge MA 02138 Phone: 510-558-8675 EMail: craig@bbn.com Larry Peterson Department of Computer Science University of Arizona Tucson, AZ 85721 Phone: 520-621-4231 EMail: LLP@cs.arizona.edu K. K. Ramakrishnan AT&T Labs. Research Rm. A155 180 Park Avenue Florham Park, N.J. 07932 Phone: 973-360-8766 EMail: KKRama@research.att.com Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: 415-812-4840 EMail: Shenker@parc.xerox.com John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 Phone: 617-253-7885 EMail: JTW@lcs.mit.edu Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90024 Phone: 310-825-2695 EMail: Lixia@cs.ucla.edu Full Copyright Statement ｜著作件全文 Copyright (C) The Internet Society (1998). 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. 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. -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。