RFC2309 日本語訳
2309 Recommendations on Queue Management and Congestion Avoidance inthe Internet. B. Braden, D. Clark, J. Crowcroft, B. Davie, S.Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge,L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. April 1998. (Format: TXT=38079 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
ワーキンググループのB.ブレーデンをネットワークでつないでください、そして、USC/ISIはコメントのために以下を要求します。 2309 D.クラーク、MIT LCSカテゴリ: 情報のJ.クロウクロフト、UCL B.デイビー、シスコシステムズS.デアリング、シスコシステムズD.Estrin USC S.フロイド、LBNL V.ジェーコブソン、LBNL G.Minshall、Fiberlane C.ヤマウズラ、BBN L.ピーターソン、アリゾナ大学K.Ramakrishnan、ATT研究室はS.Shenkerについて研究します、ゼロックスPARC J.Wroclawski、MITのLCS L.チャン、UCLA1998年4月
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.
Copyright(C)インターネット協会(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.
このメモはインターネット性能を向上して、保存する測定に関して2つの推薦をインターネットコミュニティに提示します。 それは、今日のインターネットの性能を向上させるためにルータにおける、活発な待ち行列管理のテスト、標準化、および広範囲の展開のための強い推薦を提示します。 また、それは、十分敏感でない流れから混雑通知までインターネットを保護するよう研究の協力、測定、およびルータメカニズムの究極の展開に促します。
Braden, et. al. Informational [Page 1] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [1ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
1. INTRODUCTION
1. 序論
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年代の半ば[Nagle84]のインターネットの早めの成長期の間、述べられて、技術的に「混雑崩壊」と呼ばれます。
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.
インターネット炉心溶解のためのオリジナルのフィックスはヴァン・ジェーコブソンによって提供されました。 1986年から、ジェーコブソンは現在TCP実現[Jacobson88、HostReq89]で必要である輻輳回避メカニズムを開発しました。 これらのメカニズムはTCP接続が混雑の間、「引き返すこと」を引き起こすホストで動作します。 私たちは、TCP流れがネットワークから混雑信号に「敏感である」と(すなわち、パケットを落とします)言います。 それは主として今日のインターネットの混雑崩壊を防ぐこれらの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.
輻輳制御に関連する2つのクラスのルータアルゴリズムを見分けるのは役に立ちます: 「スケジューリング」アルゴリズムに対する「管理を列に並ばせてください。」概算に、待ち行列管理アルゴリズムは必要であるか、または適切であるときにパケットを落とすことによって、パケット待ち行列の長さを管理します、スケジューリングアルゴリズムが、次に、どのパケットを送ったらよいかを決定して、主として流れの中で帯域幅の配分を管理するのに使用されますが。 これらの2つのルータメカニズムが密接に関係づけられている間、それらはかなり異なった性能問題を記述します。
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
このメモは2ルータ性能冊を強調します。 創刊号は私たちが「活発な待ち行列管理」と呼ぶ進行型のルータ待ち行列管理の必要性です。 セクション2は活発な待ち行列管理がもたらすことができる利益をまとめます。 セクション3はRandom Early Detectionか「赤」と呼ばれるお勧めのアクティブな待ち行列管理メカニズムについて説明します。 私たちは、REDアルゴリズムがさまざまなスケジューリングアルゴリズムと共に使用できて、比較的効率的に実行できて、重要なインターネットを提供すると予想します。
Braden, et. al. Informational [Page 2] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [2ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
performance improvement.
性能改良。
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.
このメモのセクション4で議論した第2刷は、無反応である流れによるインターネットの今後の混雑崩壊における潜在的、または十分、敏感ではありません、混雑指摘に。 残念ながら、そのような攻撃的な流れによって引き起こされた混雑を制御するコンセンサス解決策が全くありません。 どんな解決策も利用可能になる前に重要な研究と工学が必要でしょう。 この仕事がインターネットの将来の安定性を確実にするためにエネルギッシュに追求されるのは、必須です。
Section 5 concludes the memo with a set of recommendations to the IETF concerning these topics.
セクション5は1セットの推薦でこれらの話題に関してメモを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.
このメモにおける議論は「ベストエフォート型」の交通に適用されます。 インターネット統合しているサービス構造(メカニズムを混雑から個々の流れを保護するのに提供する)はそれ自身の待ち行列管理とスケジューリングアルゴリズム[Shenker96、Wroclawski96]を導入します。 同様に、特異なサービスのための待ち行列管理と輻輳制御要件の議論は別個問題です。 しかしながら、私たちは、統合サービスの、そして、特異にサービスの展開がこのメモで議論したベストエフォート型交通問題の重要性をかなり減少させると予想しません。
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).
このメモの準備はインターネットResearch Task Force(IRTF)のEndから終わりへのResearch Groupで終わりから終わりへの性能、インターネット混雑、およびREDの過去の議論から生じました。
2. THE NEED FOR ACTIVE QUEUE MANAGEMENT
2. 活発な待ち行列管理の必要性
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.
ルータ待ち行列の長さを管理するための伝統的なテクニックは、待ち行列からのパケットが伝えられたので待ち行列が減少するまで、最大の長さ(パケットに関する)を各待ち行列に設定して、最大の長さに達するまで待ち行列のためにパケットを受け入れて、次に、その後の入って来るパケットを拒絶する(低下します)ことです。 このテクニックは「テール低下」として知られています、待ち行列が完全であるときに、ごく最近到着したパケット(すなわち、待ち行列のテールの上のもの)が落とされるので。 この方法は長年インターネットによく役立っていますが、それには、2つの重要な欠点があります。
1. Lock-Out
1. ロックアウト
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.
いくつかの状況で、単独結合かいくつかの流れがテール低下で待ち行列スペースを独占できます、他の接続が待ち行列で余地を手に入れるのを防いで。 しばしばこの「ロックアウト」現象は同期か他のタイミング効果の結果です。
Braden, et. al. Informational [Page 3] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [3ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
2. Full Queues
2. 完全な待ち行列
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.
ネットワークにおけるバッファリングのポイントは、データ炸裂を吸収して、沈黙の(希望をいだいて)続いている炸裂の間、それらを伝えることです。 これは、burstyデータの伝達を可能にするのに不可欠です。 私たちがなぜ通常ルータにおける小さい待ち行列が欲しいかは、明確であるはずです: 私たちは、炸裂を吸収する待ち行列能力が欲しいと思います。 直観に反している結果は通常小さい待ち行列を維持すると終わりから終わりへの下側の遅れと同様により高いスループットにもたらされることができるということです。 要するに、待ち行列限界は私たちがネットワークで維持して欲しい定常状態待ち行列を反映するべきではありません。 代わりに、彼らは私たちが吸収する必要がある炸裂のサイズを反映するべきです。
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.
テール低下以外に、待ち行列が完全になるとき適用できる2つの代替の待ち行列の規準が、「完全の無作為の低下」か「完全の落とし板」です。 待ち行列が完全であり、新しいパケットが到着するとき、完全な規律での無作為の低下の下では、ルータは待ち行列(パケット待ち行列でO(N)散歩を純真に必要とするので、高価な操作であるかもしれない)から手当たりしだいに選択されたパケットを落とします。 「完全の落とし板」規律[Lakshman96]の下では、待ち行列が完全であり、新しいパケットが到着するとき、ルータは待ち行列の前部でパケットを落とします。 これらの両方がロックアウト問題を解決しますが、どちらも上で説明された完全な待ち行列問題を解決しません。
Braden, et. al. Informational [Page 4] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [4ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
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).
一般に、私たちは「敏感な」流れ(すなわち、混雑通知に対応して減速するそれらの流れる)で完全な待ち行列問題を解決する方法を知っています。 現在のインターネットでは、低下しているパケットは混雑通知の重要なメカニズムとしてエンドノードに機能します。 完全な待ち行列問題の解決は待ち行列が完全になる前にルータがパケットを落とすことです、バッファがあふれる前にエンドノードが混雑に応じることができるように。 私たちは、そのような先を見越すアプローチを「活発な待ち行列管理」と呼びます。 バッファがあふれる前にパケットを落とすことによって、ルータは、活発な待ち行列管理からいつ、いくつのパケットを落とすかを制御できます。 次のセクションはRED、上に記載された両方の問題を解決するアクティブな待ち行列管理メカニズムを紹介します(敏感な流れを考えて)。
In summary, an active queue management mechanism can provide the following advantages for responsive flows.
概要では、アクティブな待ち行列管理メカニズムは以下の利点を敏感な流れに提供できます。
1. Reduce number of packets dropped in routers
1. ルータで落とされたパケットの数を減少させてください。
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]の避けられない局面です。 ルータにおけるすべての待ち行列スペースが既に「定常状態」交通に心がけるか、またはバッファ領域が不十分であるなら、ルータには、炸裂をバッファリングする能力が全くないでしょう。 平均した待ち行列サイズを小さく保つことによって、活発な待ち行列管理はパケットを落とさないで自然に起こっている炸裂を吸収するより大きい能力を提供するでしょう。
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.
待ち行列があふれるとき、その上、活発な待ち行列管理がなければ、より多くのパケットが落とされるでしょう。 これはいくつかの理由で望ましくありません。 まず最初に、共有された待ち行列とテール低下規律で、切れ返すのがもたらすことができる流れの不要なグローバルな同期は、平均したリンク利用を下ろして、したがって、ネットワークスループットを下げました。 2番目に、TCPはパケット滴の炸裂からの1パケット滴より多くの困難で回復します。 3番目に、不要なパケット滴は低下ポイントへの途中に帯域幅の可能な浪費を表します。
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が待ち行列の長さを管理して、終わりからエンドへの輻輳制御がないときでさえ終わりへの終わりのレイテンシを減少させることができる間REDが終わりからエンドへの輻輳制御で支配され続けている環境のパケット低下しか減少させることができないことに注意します。
2. Provide lower-delay interactive service
2. 下側の遅れ双方向サービスを提供してください。
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
平均した待ち行列サイズを小さく保つことによって、待ち行列管理は流れによって見られた遅れを減少させるでしょう。 短いウェブ転送、Telnet通信、または対話的なオーディオのビデオセッションなどの対話型アプリケーションには、これが特に重要である、だれのもの、主観的
Braden, et. al. Informational [Page 5] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [5ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
(and objective) performance is better when the end-to-end delay
is low.
(そして、目的) 終わりから終わりへの遅れが低いときに、性能は、より良いです。
3. Avoid lock-out behavior
3. ロックアウトの振舞いを避けてください。
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.
入って来るパケットに利用可能なバッファがほとんどいつもあるのを確実にすることによって、活発な待ち行列管理はロックアウトの振舞いを防ぐことができます。 同じ理由から、活発な待ち行列管理は低い帯域幅に対してルータ偏見を防ぐことができますが、非常に、burstyは流れます。
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.
流れのグループで総計の不公平を構成するのでそのロックアウトが望ましくないのは、明確です。 しかしながら、私たちは、この利益を「増加する公正」と呼ぶまでには至りません、流れの中の一般的な公正が1流れあたりの状態(待ち行列管理によって提供されない)を必要とするので。 例えば、単にいろいろな往復の時間[Floyd91]を過すので、待ち行列管理を使用するルータにもかかわらず、先入れ先出し法スケジューリングだけでは、2回のTCP流れが非常に異なった帯域幅を受けるかもしれません、そして、輻輳制御を使用しない流れはそれがする流れより多くの帯域幅を受けるかもしれません。 一般的な公正を達成する1流れあたりの状態はFair Queueing(FQ)などの1流れあたり1つのスケジューリングアルゴリズム[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などの1流れあたりのスケジューリングアルゴリズムかCBQなどのクラスベースのスケジューリングアルゴリズムを使用するルータにさえ必要です。 これは自分たちによる1流れあたりのスケジューリングアルゴリズムが総合的な待ち行列サイズか個々の待ち行列のサイズを制御するようなことを何もしないからです。 活発な待ち行列管理が総合的な平均した待ち行列サイズを制御するのが必要です、パケットを落とさないで到着炸裂を設備することができるように。 さらに、活発な待ち行列管理は各個々の流れかクラスのために待ち行列サイズを制御するのに使用されるべきです、彼らが不必要に高い遅れを経験しないように。 したがって、活発な待ち行列管理は、クラスの向こう側に適用されるべきであるか、または各クラスか流れと同じくらいよく流れます。
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に加えられる待ち行列管理の実現があって、仕事は、RED待ち行列管理をCBQに加えるために進行しています。
Braden, et. al. Informational [Page 6] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [6ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
3. THE QUEUE MANAGEMENT ALGORITHM "RED"
3. 待ち行列管理アルゴリズム「赤」
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.
無作為のEarly Detection、またはREDが前項[RED93]で引用されたインターネット性能利点を提供するルータのためのアクティブな待ち行列管理アルゴリズムです。 伝統的な待ち行列管理アルゴリズムと対照して、REDアルゴリズムはprobabilisticallyに到着パケットを落とします。バッファが完全であるときにだけ、それは、パケットを落とします。 およそ平均した待ち行列サイズが成長するのに従って、低下の確率は増加します。 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アルゴリズム自体は2つの主部から成ります: 平均した待ち行列サイズに関する見積りと入って来るパケットを落とすかどうかに関する決定。
(a) Estimation of Average Queue Size
(a) 平均した待ち行列サイズに関する見積り
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は、簡単な指数加重移動平均を使用する推進経路([Jacobson88]のAppendix 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.
以下に注意してください。 パケットかバイトの単位で待ち行列サイズを測定できます。 [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
(b) パケット低下決定
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
アルゴリズムの2番目の部分では、REDが、入って来るパケットを落とすかどうか決めます。 それは、低下するための敏感な流れのための性能改良をもたらすREDの特定のアルゴリズムです。 2つのREDパラメタ(minth(最小の敷居)とmaxth(最大の敷居))が、顕著に含みます。
Braden, et. al. Informational [Page 7] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [7ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
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.
この決定の過程。 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単位で正当な分け前が単一のパケット以下であるそれぞれ小さいです。
Braden, et. al. Informational [Page 8] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [8ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
4. MANAGING AGGRESSIVE FLOWS
4. 攻撃的な流れを管理します。
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].
インターネットの成功のキーの1つはTCPの輻輳回避メカニズムです。 TCPが混雑の間、「引き返す」ので、多くのTCP接続が帯域幅が同様に位置した流れの中で合理的に公正に共有されるような方法で単一の、そして、混雑しているリンクを共有できます。 流れの中の帯域幅の公正な共有はすべての流れが同じ輻輳回避アルゴリズム(現在のTCP仕様[HostReq89]があるconformant)を基本的に、走らせているという事実に依存します。
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.)
私たちはそれがconformant TCPが発生させた流れのように混雑で振る舞わせる流れにおける、「TCPコンパチブル」用語を紹介します。 TCPコンパチブル流れは混雑通知に敏感です、そして、定常状態では、それは匹敵する状態で実行されるconformant TCPが帯域幅でないことのようなどんな帯域幅も使用しません。(低下率、RTT、MTUなど)
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)無反応流れ、混雑が起こる場合減速しない流れ、および敏感な、しかし、TCP互換性がない(3)流れ。 最後の2つのクラスが私たちがインターネット性能含むつもりであるように多大なる脅威を引き起こすより攻撃的な流れを含みます。現在、議論します。
o Non-Responsive Flows
o 非敏感な流れ
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ベースの利用があります(i.e、流れは混雑通知を受け取り次第減速しません)。 そのような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ベースのストリーミング・アプリケーションが有効な輻輳回避メカニズムを組み込むべきです。例えば、最近の研究はパケットビデオ[McCanne96; Bolot94]などのUDPベースのストリーミング・アプリケーションの中にReceiverの駆動Layered Multicastなどの輻輳回避メカニズム(RLM)を組み込む可能性を示しました。 ストリーミング・アプリケーションのための輻輳回避を実行する方法におけるさらなる研究開発は非常に重要になるでしょう。
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
しかしながら、また、ネットワークが無反応流れに対して我が身をかばうことができるのも、重要であり、これを達成するメカニズムを開発されて、配備しなければなりません。 そのようなメカニズムの展開はあらゆるストリーミング・アプリケーションがそれ自身を取り入れることによって敏感になる誘因を提供するでしょう。
Braden, et. al. Informational [Page 9] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [9ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
congestion control.
輻輳制御。
o Non-TCP-Compatible Transport Protocols
o コンパチブル非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.
2番目の脅威は混雑通知に敏感なトランスポート・プロトコル実現で引き起こされますが、故意にか不完全な実現を通して、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」を持っていると主張できるでしょう。 そのような実現の必然的な結果はますます攻撃的な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
「流れ」の適切な粒状に関する問題があります。 いくつかの「自然な」答えがあります: 1) TCPかUDP接続(ソースアドレス/ポート、目的地アドレス/港)。 2) ソース/あて先ホスト組。 3) 与えられた送信元ホストか与えられたあて先ホスト。 私たちは、ソース/あて先ホスト組が多くの事情で最も適切な粒状を与えると推測するでしょう。 しかしながら、異なった業者/プロバイダーが流れ(自分たちのお互いからの「区別」である道としての)を定義するのに異なった粒状を設定するかもしれないか、または異なった粒状が設定できたのが可能です。
Braden, et. al. Informational [Page 10] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [10ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
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.
ネットワークにおける異なった場所に選ばれてください。 粒状が何らかの*粒状が私たちが*の、より多くの無反応流れを取扱っている事実ほど重要でないことは、事実であるかもしれません。 ふくそう管理のための流れの粒状は少なくとも一部、より広いIETF共同体に記述される必要がある方針問題です。
5. CONCLUSIONS AND RECOMMENDATIONS
5. 結論と推薦
This discussion leads us to make the following recommendations to the IETF and to the Internet community as a whole.
この議論は、私たちが全体で以下の推薦状をIETFと、そして、インターネットコミュニティにするように導きます。
o RECOMMENDATION 1:
o 推薦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.
先入れ先出し待ち行列におけるこれらの目標を達成するために待ち行列の長さを管理するためのデフォルトメカニズムはRandom Early Detection(RED)[RED93]です。 開発者に別の同等なメカニズムを提供する理由がない場合、私たちは、REDが使用されることを勧めます。
o RECOMMENDATION 2:
o 推薦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の何らかの限られた展開がインターネットに既にありましたが、私たちはその広範囲の実現を予想するかもしれません、そして、Recommendation1に従ったREDの展開は多くの工学問題を露出するでしょう。 例えば、そのような問題は以下を含むかもしれません。 実現はGigabitルータ、層2のスイッチにおける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の広範囲の実現と展開がそういうものとしてRecommendation2の目標を実現しないと再び強調します。
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
また、REDの広範囲の実現と展開は他の新しい機能性の導入をインターネットに可能にするでしょう。 可能にされた機能性に関する1つの例がインターネット構造への明白な混雑通知[Ramakrishnan97]の追加でしょう、添加における混雑通知のためのメカニズムとして
Braden, et. al. Informational [Page 11] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [11ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
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.
パケット滴に。 新しい機能性に関する2番目の例は異なった低下プライオリティのパケットがある待ち行列の実現でしょう。 パケットは、それらが到達したオーダーで伝えられるでしょうが、下側の低下優先度の混雑パケットの倍の間優先的に落とされるでしょう。
6. References
6. 参照
[Bolot94] Bolot, J.-C., Turletti, T., and Wakeman, I., Scalable Feedback Control for Multicast Video Distribution in the Internet, ACM SIGCOMM '94, Sept. 1994.
[Bolot94]Bolot、J.-C.、Turletti、T.、およびウェイクマン、I.、スケーラブルなフィードバックはマルチキャストビデオ分配のためにインターネットで制御されます、ACM SIGCOMM94年、1994年9月。
[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.
[Demers90] DemersとA.とKeshav、S.とShenkerとS.と分析と公正な待ち行列アルゴリズムのシミュレーション、インターネットワーキング: 研究とExperience、Vol.1、1990、ページ 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/.
[Floyd91] フロイド、S.、パケット交換網第1部における複数の混雑しているゲートウェイがあるコネクションズ: 一方通行の交通。 コンピュータCommunications Review、Vol.21、No.5、1991年10月、ページ 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.
[Floyd95] リンク共有と資源管理がパケット網のためにモデル化するフロイド、S.、およびジェーコブソン、V.。 Networkingの上のIEEE/ACM Transactions、Vol.3No.4、ページ 365-386と、1995年8月。
[Floyd97] Floyd, S., RED: Discussions of Byte and Packet Modes, March 1997 email, http://www-nrg.ee.lbl.gov/floyd/REDaveraging.txt.
[Floyd97] フロイド、S.、赤: ByteとPacket Modesの議論、1997年3月のメール、 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.
[Gaynor96] ゲイナー、M.、TCP Gateways、1996年10月、URL http://www.eecs.harvard.edu/~gaynor/ final.psのためのProactive Packet Dropping Methods。
[HostReq89] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[HostReq89] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、10月1989日
[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988.
[Jacobson88] V.ジェーコブソンと輻輳回避とコントロール、ACM SIGCOMM88年、1988年8月。
[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.
[Lakshman96] T.V.Lakshmanとアーニー・ナイトハルトとTeunisオットと気圧でのTCPの前の戦略からの低下と他のコントロール機能、Infocom96(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.
[Leland94] イーサネットTraffic(拡張バージョン)、Networking、2(1)、ページのIEEE/ACM TransactionsのW.リーランド、M.Taqqu、W.ウィリンジャー、およびD.ウィルソン、OnのSelf同様のネイチャー 1-15と、1994年2月。
Braden, et. al. Informational [Page 12] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [12ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
[McCanne96] McCanne, S., Jacobson, V., and M. Vetterli, Receiver- driven Layered Multicast, ACM SIGCOMM
[McCanne96] McCanneとS.とジェーコブソン、V.とM.Vetterli、Receiverの駆動Layered Multicast、ACM SIGCOMM
[Nagle84] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
[Nagle84] ネーグル、J.、「IP/TCPの輻輳制御」、RFC896、1984年1月。
[Ramakrishnan97] Ramakrishnan, K. K., and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Work in Progress.
Progressの[Ramakrishnan97]Ramakrishnan、K.K.、およびS.フロイド、「IPv6と、そして、TCPにExplicit Congestion Notification(電子証券取引ネットワーク)を加えるProposal」Work。
[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.
[RED93] Congestion Avoidance、IEEE/ACM TransactionsのためのNetworking、V.1 N.4、1993年8月、ページのフロイド、S.とジェーコブソン、V.、Random Early Detectionゲートウェイ 397-413. また、 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.
[REDWWW] フロイド、S.、赤いウェブページ、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.
[RFC2001] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日
[Shenker96] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", Work in Progress.
[Shenker96] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、「保証されたサービスの質の仕様」は進行中で働いています。
[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.
[SRM96]フロイド。 軽量のセッションとアプリケーションのためのS.、ジェーコブソン、V.、McCanne、S.、リュウ、C.、およびL.チャン、信頼できるマルチキャスト枠組みは縁どりを平らにします。 ACM SIGCOMM96年、pp342-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.
[Villamizar94] Villamizar、C.と歌、C.、ANSNETの高性能TCP。 コンピュータCommunications Review、V.24N.5、1994年10月、ページ 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.
[Willinger95]W.ウィリンジャー、M.S.Taqqu、R.シャーマン、D.V.ウィルソン、高い可変性を通した自己類似性: Source Level、ACM SIGCOMM95年、ページにおけるイーサネットLAN Trafficの統計的なAnalysis 100- 113と、1995年8月。
[Wroclawski96] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", Work in Progress.
J.、「制御負荷ネットワーク要素サービスの仕様」という[Wroclawski96]Wroclawskiは進行中で働いています。
Braden, et. al. Informational [Page 13] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [13ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
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.
セキュリティは非常に重要な問題ですが、それはこのメモで議論した性能問題と主に直交しています。 しかしながら、私たちは、サービス不能攻撃が通常の高帯域同一時間のアプリケーションからの流れから区別がつかない無反応交通の流れを引き起こすかもしれないことに注意します、そして、Recommendation2に示されたメカニズムは等しくそのような攻撃に適切になるでしょう。
Authors' Addresses
作者のアドレス
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデンUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: 310-822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 310-822-1511 メールしてください: Braden@ISI.EDU
David D. Clark MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
デヴィッドD.クラークMITコンピュータサイエンス研究所545技術平方です。 ケンブリッジ、MA 02139
Phone: 617-253-6003 EMail: DDC@lcs.mit.edu
以下に電話をしてください。 617-253-6003 メールしてください: DDC@lcs.mit.edu
Jon Crowcroft University College London Department of Computer Science Gower Street London, WC1E 6BT ENGLAND
ジョンクロウクロフトユニバーシティ・カレッジロンドンコンピュータサイエンス学部ガウアー・ストリートWC1E 6BTロンドン(イギリス)
Phone: +44 171 380 7296 EMail: Jon.Crowcroft@cs.ucl.ac.uk
以下に電話をしてください。 +44 7296年の171 380メール: Jon.Crowcroft@cs.ucl.ac.uk
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
ブルースデイビーシスコシステムズInc.250アポロDriveチェルムズフォード、MA 01824
Phone: EMail: bdavie@cisco.com
以下に電話をしてください。 メール: bdavie@cisco.com
Braden, et. al. Informational [Page 14] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [14ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
Steve Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
西タスマン・Driveサンノゼ、スティーブデアリングシスコシステムズInc.170カリフォルニア95134-1706
Phone: 408-527-8213 EMail: deering@cisco.com
以下に電話をしてください。 408-527-8213 メールしてください: deering@cisco.com
Deborah Estrin USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
デボラEstrin USC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: 310-822-1511 EMail: Estrin@usc.edu
以下に電話をしてください。 310-822-1511 メールしてください: Estrin@usc.edu
Sally Floyd Lawrence Berkeley National Laboratory, MS 50B-2239, One Cyclotron Road, Berkeley CA 94720
MS50B-2239、1つのサイクロトロン道路、バークレーカリフォルニア サリー・フロイド・ローレンス・バークレー国家の研究所、94720
Phone: 510-486-7518 EMail: Floyd@ee.lbl.gov
以下に電話をしてください。 510-486-7518 メールしてください: Floyd@ee.lbl.gov
Van Jacobson Lawrence Berkeley National Laboratory, MS 46A, One Cyclotron Road, Berkeley CA 94720
MS46A、1つのサイクロトロン道路、バークレーカリフォルニア ヴァン・ジェーコブソン・ローレンス・バークレー国家の研究所、94720
Phone: 510-486-7519 EMail: Van@ee.lbl.gov
以下に電話をしてください。 510-486-7519 メールしてください: Van@ee.lbl.gov
Greg Minshall Fiberlane Communications 1399 Charleston Road Mountain View, CA 94043
マウンテンビュー、グレッグMinshall Fiberlane Communications1399チャールストンRoadカリフォルニア 94043
Phone: +1 650 237 3164 EMail: Minshall@fiberlane.com
以下に電話をしてください。 +1 3164年の650 237メール: Minshall@fiberlane.com
Braden, et. al. Informational [Page 15] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [15ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
Craig Partridge BBN Technologies 10 Moulton St. Cambridge MA 02138
クレイグヤマウズラBBN技術10モールトン通りケンブリッジMA 02138
Phone: 510-558-8675 EMail: craig@bbn.com
以下に電話をしてください。 510-558-8675 メールしてください: craig@bbn.com
Larry Peterson Department of Computer Science University of Arizona Tucson, AZ 85721
ラリー・ピーターソン・コンピュータサイエンス学部のアリゾナ大学のツーソン、アリゾナ 85721
Phone: 520-621-4231 EMail: LLP@cs.arizona.edu
以下に電話をしてください。 520-621-4231 メールしてください: LLP@cs.arizona.edu
K. K. Ramakrishnan AT&T Labs. Research Rm. A155 180 Park Avenue Florham Park, N.J. 07932
K.K.Ramakrishnan AT&T研究室。 Rmについて研究してください。 A155 180パーク・アベニューFlorham公園、ニュージャージー州07932
Phone: 973-360-8766 EMail: KKRama@research.att.com
以下に電話をしてください。 973-360-8766 メールしてください: KKRama@research.att.com
Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304
スコットShenkerゼロックスPARC3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304
Phone: 415-812-4840 EMail: Shenker@parc.xerox.com
以下に電話をしてください。 415-812-4840 メールしてください: Shenker@parc.xerox.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139
Phone: 617-253-7885 EMail: JTW@lcs.mit.edu
以下に電話をしてください。 617-253-7885 メールしてください: JTW@lcs.mit.edu
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90024
Lixiaチャン・UCLA 4531G Boelter Hallロサンゼルス、カリフォルニア 90024
Phone: 310-825-2695 EMail: Lixia@cs.ucla.edu
以下に電話をしてください。 310-825-2695 メールしてください: Lixia@cs.ucla.edu
Braden, et. al. Informational [Page 16] RFC 2309 Internet Performance Recommendations April 1998
etブレーデン、アル。 [16ページ]情報のRFC2309インターネットパフォーマンス推薦1998年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネット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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Braden, et. al. Informational [Page 17]
etブレーデン、アル。 情報[17ページ]
一覧
スポンサーリンク
