[要約] RFC 2309は、インターネットにおけるキュー管理と過負荷回避に関する推奨事項を提供しています。その目的は、ネットワークのパフォーマンスを向上させ、適切なトラフィック制御を実現することです。
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.
Copyright（C）The Internet Society（1998）。全著作権所有。
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つの推奨事項を示しています。今日のインターネットのパフォーマンスを向上させるために、ルーターでのアクティブキュー管理のテスト、標準化、および広範な展開についての強力な推奨事項を示しています。また、輻輳通知に十分に反応しないフローからインターネットを保護するために、ルーターメカニズムの調査、測定、および最終的な展開という協調した取り組みも求められます。
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.
インターネットメルトダウンの元の修正は、Van Jacobsonによって提供されました。 1986年から、Jacobsonは、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 performance improvement.
このメモは、2つのルーターのパフォーマンスの問題を強調しています。最初の問題は、「アクティブキュー管理」と呼ばれる高度なルーターキュー管理の必要性です。セクション2では、アクティブなキュー管理がもたらすメリットをまとめています。セクション3では、ランダム早期検出または「RED」と呼ばれる、推奨されるアクティブキュー管理メカニズムについて説明します。 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.
このメモのセクション4で説明されている2番目の問題は、輻輳の表示に応答しない、または十分に応答しないフローが原因で、将来のインターネットの輻輳崩壊の可能性です。残念ながら、このような攻撃的なフローによって引き起こされる輻輳を制御するためのコンセンサスソリューションはありません。ソリューションが利用可能になる前に、重要な研究とエンジニアリングが必要になります。インターネットの将来の安定性を確保するために、この作業を精力的に追求することが不可欠です。
Section 5 concludes the memo with a set of recommendations to the IETF concerning these topics.
セクション5は、これらのトピックに関する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).
このメモの作成は、エンドツーエンドのパフォーマンス、インターネットの輻輳、およびインターネットリサーチタスクフォース（IRTF）のエンドツーエンドの研究グループにおけるREDの過去の議論から生じました。
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.
状況によっては、テールドロップにより、単一の接続またはいくつかのフローがキュースペースを独占し、他の接続がキューにスペースを確保できないようにすることができます。この「ロックアウト」現象は、多くの場合、同期または他のタイミング効果の結果です。
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.
ネットワーク内のバッファリングのポイントは、データバーストを吸収し、（できれば）続く無音のバースト中にそれらを送信することです。これは、バーストデータの送信を許可するために不可欠です。ルーターに通常は小さいキューが必要な理由は明らかです。バーストを吸収するキュー容量が必要です。直感に反する結果として、通常は小さいキューを維持すると、スループットが向上するだけでなく、エンドツーエンドの遅延も減少します。つまり、キュー制限は、ネットワークで維持したい定常状態のキューを反映すべきではありません。代わりに、吸収する必要があるバーストのサイズを反映する必要があります。
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]では、キューがいっぱいになり、新しいパケットが到着すると、ルーターはキューの先頭にあるパケットをドロップします。これらはどちらもロックアウトの問題を解決しますが、上記の完全なキューの問題も解決しません。
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を紹介します。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.
さらに、アクティブなキュー管理がない場合、キューがオーバーフローすると、より多くのパケットがドロップされます。これは、いくつかの理由で望ましくありません。第1に、共有キューとテールドロップの分野では、フローの不要なグローバル同期により、平均リンク使用率が低下し、ネットワークスループットが低下する可能性があります。第2に、TCPは、単一のパケットドロップからよりも、パケットドロップのバーストからより困難に回復します。第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 (and objective) performance is better when the end-to-end delay is low.
キューの平均サイズを小さく保つことにより、キュー管理はフローで見られる遅延を減らします。これは、エンドツーエンドの遅延が小さい場合に主観的（および客観的）パフォーマンスが優れている、短いWeb転送、Telnetトラフィック、またはインタラクティブオーディオビデオセッションなどのインタラクティブアプリケーションにとって特に重要です。
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.
アクティブなキュー管理は、ほとんどの場合、着信パケットに使用可能なバッファが存在することを保証することにより、ロックアウト動作を防止できます。同じ理由で、アクティブなキュー管理は、低帯域幅でバースト性の高いフローに対するルーターのバイアスを防ぐことができます。
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.
ロックアウトはフローのグループ間で大きな不公平を構成するため、ロックアウトは望ましくないことは明らかです。ただし、フロー間の一般的な公平性にはフローごとの状態が必要であり、キュー管理では提供されないため、この利点を「公平性の向上」とは言い切れません。たとえば、キュー管理を使用していてもFIFOスケジューリングのみを使用しているルーターでは、2つのTCPフローは、ラウンドトリップ時間が異なるために非常に異なる帯域幅を受信する可能性があり[Floyd91]、輻輳制御を使用しないフローは、その流れ。一般的な公平性を実現するためのフローごとの状態は、たとえば、Fair Queuing（FQ）[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に追加されたキュー管理の実装があり、REDキュー管理をCBQに追加する作業が進行中です。
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）は、前のセクション[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アルゴリズム自体は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]の付録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 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.
アルゴリズムの2番目の部分では、REDは着信パケットをドロップするかどうかを決定します。応答フローのパフォーマンスが向上するのは、REDの特定のドロップアルゴリズムです。この決定プロセスでは、minth（最小しきい値）とmaxth（最大しきい値）の2つのREDパラメーターが顕著に表れます。 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 Webページ[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が害を及ぼすことはなく、依然として役立つ可能性はありますが、REDが解決しない極端なシナリオがいくつかあることに注意してください。このようなシナリオの例としては、非常に多数のフローがあり、それぞれのフローが非常に小さいため、RTTごとの単一のパケットよりもフェアシェアが少なくなります。
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]に準拠して、基本的に同じ輻輳回避アルゴリズムを実行しているという事実に依存します。
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互換フローは輻輳通知に応答し、定常状態では、同等の条件（ドロップレート、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互換ではないフロー。後で説明するように、最後の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ベースのアプリケーションのセットが増えています。このような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）などの輻輳回避メカニズムを組み込む可能性が示されています[McCanne96; Bolot94]。ストリーミングアプリケーションの輻輳回避を実現する方法に関するさらなる研究開発が非常に重要になります。
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
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.
一部のWebブラウザーで行われているように、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コミュニティで対処する必要があるポリシーの問題です。
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.
FIFOキューでこれらの目標を達成するためにキューの長さを管理するデフォルトのメカニズムは、ランダム早期検出（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のインターネットへの導入はすでに制限されていますが、推奨事項1に従ってREDを広範囲に導入および導入すると、多くのエンジニアリング上の問題が明らかになると予想されます。たとえば、このような問題には、ギガビットルーターの実装に関する質問、レイヤー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の広範な実装と展開は、それ自体では勧告2の目標を達成しないことを再度強調します。
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の広範な実装と展開により、他の新機能をインターネットに導入することも可能になります。有効化された機能の一例は、パケットドロップに加えて輻輳通知のメカニズムとして、明示的な輻輳通知[Ramakrishnan97]をインターネットアーキテクチャに追加することです。新しい機能の2番目の例は、異なるドロップ優先度のパケットを持つキューの実装です。パケットは到着した順に送信されますが、輻輳時には、ドロッププライオリティの低いパケットが優先的にドロップされます。
[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。、およびWakeman、I。、インターネットでのマルチキャストビデオ配信のためのスケーラブルなフィードバック制御、ACM SIGCOMM '94、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.、Kesav、S。、およびShenker、S。、分析およびフェアキューイングアルゴリズムのシミュレーション、Internetworking：Research and Experience、Vol。 1、1990年、pp。
[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部：一方向のトラフィック。 Computer 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] Floyd、S。、およびJacobson、V。、パケットネットワークのリンク共有およびリソース管理モデル。 IEEE / ACM Transactions on Networking、Vol。 3 No. 4、pp。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] Floyd、S.、RED：ディスカッションのバイトモードとパケットモード、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] Gaynor、M.、TCPゲートウェイ用のプロアクティブパケットドロップメソッド、1996年10月、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.
[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.
[Jacobson88] V. Jacobson、輻輳回避および制御、ACM SIGCOMM '88、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、Arnie Neidhardt、Teunis Ott、TCP over ATMにおけるドロップフロムフロントストラテジーと他の制御機能との相互作用、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.
[Leland94] W. Leland、M。Taqqu、W。Willinger、およびD. Wilson、イーサネットトラフィックの自己相似性（拡張バージョン）、ネットワーキングにおけるIEEE / ACMトランザクション、2（1）、pp。1- 1994年2月15日。
[McCanne96] McCanne, S., Jacobson, V., and M. Vetterli, Receiver-driven Layered Multicast, ACM SIGCOMM
[McCanne96] McCanne、S.、Jacobson、V。、およびM. Vetterli、受信者駆動型レイヤードマルチキャスト、ACM SIGCOMM
[Nagle84] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
[Nagle84] Nagle、J。、「IP / TCPの輻輳制御」、RFC 896、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.
[Ramakrishnan97] Ramakrishnan、K。K.、およびS. Floyd、「明示的な輻輳通知（ECN）をIPv6およびTCPに追加するための提案」、作業中。
[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] Floyd、S。、およびJacobson、V。、輻輳回避のためのランダム早期検出ゲートウェイ、IEEE / ACM Transactions on Networking、V.1 N.4、1993年8月、pp。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] 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.
[RFC 2001] Stevens、W。、「TCPスロースタート、輻輳回避、高速再送信、および高速回復アルゴリズム」、RFC 2001、1997年1月。
[Shenker96] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", Work in Progress.
[Shenker96] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、進行中。
[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.、Jacobson、V.、McCanne、S.、Liu、C.、and L. Zhang、A Reliable Multicast Framework 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.
[Villamizar94] ANSNETの高性能TCP、Villamizar、およびC. Computer Communications Review、V. 24 N. 5、1994年10月、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.
[Willinger95] W. Willinger、M。S. Taqqu、R。Sherman、D。V. Wilson、高可変性による自己相似性：ソースレベルでのイーサネットLANトラフィックの統計分析、ACM SIGCOMM '95、pp。100-113、1995年8月。
[Wroclawski96] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", Work in Progress.
[Wroclawski96] Wroclawski、J。、「Controlled-Load Network Element Serviceの仕様」、進行中の作業。
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.
セキュリティは非常に重要な問題ですが、このメモで説明されているパフォーマンスの問題とほぼ直交しています。ただし、サービス拒否攻撃は、通常の高帯域アイソクロナスアプリケーションからのフローと区別がつかない無応答のトラフィックフローを作成する可能性があることに注意してください。推奨2で提案されたメカニズムは、このような攻撃にも同様に適用できます。
Authors' Addresses
著者のアドレス
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデンUSC情報科学研究所4676アドミラルティウェイマリーナデルレイ、カリフォルニア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
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
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
電話：Eメール：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
電話：408-527-8213メール：deering@cisco.com
Deborah Estrin USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
デボラエストリンUSC情報科学研究所4676アドミラルティウェイマリーナデルレイ、カリフォルニア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
Sally Floyd Lawrence Berkeley National Laboratory、MS 50B-2239、One Cyclotron Road、Berkeley CA 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
Van Jacobson Lawrence Berkeley National Laboratory、MS 46A、One Cyclotron Road、Berkeley CA 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
Greg Minshall Fibrelane 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
電話：+1 650 237 3164メール：Minshall@fiberlane.com Craig Partridge BBN Technologies 10 Moulton St. Cambridge 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.ラマクリシュナンAT＆Tラボ。研究室A155 180 Park Avenueフォーハムパーク、ニュージャージー州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
Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto、CA 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
ジョンブロツラフスキーMITコンピュータサイエンス研究所545テクノロジースクエアケンブリッジ、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
lチャンUCLA 4531GB OE老人ホールロサンゼルス、カリフォルニア90024をダウンロード
Phone: 310-825-2695 EMail: Lixia@cs.ucla.edu
電話：310-825-2695メール：Lixia@cs.ucla.edu
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。