Network Working Group S. Floyd
Request for Comments: 2914 ACIRI
BCP: 41 September 2000
Category: Best Current Practice
Congestion Control Principles
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols.
このドキュメントの目標は、インターネットにおける輻輳制御の必要性を説明するために、正しい輻輳制御を構成するものについて議論することです。一つの具体的な目標は、適切な輻輳制御を適用するために無視の危険性を説明することです。第二の目標は、新たな輻輳制御プロトコルの標準化にIETFの役割を議論することです。
This document draws heavily from earlier RFCs, in some cases reproducing entire sections of the text of earlier documents [RFC2309, RFC2357]. We have also borrowed heavily from earlier publications addressing the need for end-to-end congestion control [FF99].
この文書は、以前の文書[RFC2309、RFC2357]のテキストのセクション全体を再現するいくつかのケースでは、以前のRFCから大きく描画します。また、エンドツーエンドの輻輳制御[FF99]の必要性に対処する以前の出版物から重く借りてきました。
IETF standards concerning end-to-end congestion control focus either on specific protocols (e.g., TCP [RFC2581], reliable multicast protocols [RFC2357]) or on the syntax and semantics of communications between the end nodes and routers about congestion information (e.g., Explicit Congestion Notification [RFC2481]) or desired quality-of-service (diff-serv)). The role of end-to-end congestion control is also discussed in an Informational RFC on "Recommendations on Queue Management and Congestion Avoidance in the Internet" [RFC2309]. RFC 2309 recommends the deployment of active queue management mechanisms in routers, and the continuation of design efforts towards mechanisms in routers to deal with flows that are unresponsive to congestion notification. We freely borrow from RFC 2309 some of their general discussion of end-to-end congestion control.
特定のプロトコル（例えば、TCP [RFC2581]、信頼性の高いマルチキャストプロトコル[RFC2357]）に、または渋滞情報に関するエンドノードとルータとの間の通信の構文と意味論上のいずれかのエンドツーエンドの輻輳制御フォーカスに関するIETF規格（例えば、明示的輻輳通知[RFC2481]）または所望のサービス品質（差分-SERV））。エンドツーエンドの輻輳制御の役割はまた、「インターネットの待ち行列管理と輻輳回避の推薦」[RFC2309]に情報のRFCで説明されています。 RFC 2309は、ルータにおけるアクティブキュー管理機構の導入、および輻輳通知に応答しない流れに対処するためのルータでのメカニズムに向けた設計の努力の継続を推奨しています。私たちは自由にRFC 2309からのエンドツーエンドの輻輳制御の彼らの一般的な議論の一部を借ります。
In contrast to the RFCs discussed above, this document is a more general discussion of the principles of congestion control. One of the keys to the success of the Internet has been the congestion avoidance mechanisms of TCP. While TCP is still the dominant transport protocol in the Internet, it is not ubiquitous, and there are an increasing number of applications that, for one reason or another, choose not to use TCP. Such traffic includes not only multicast traffic, but unicast traffic such as streaming multimedia that does not require reliability; and traffic such as DNS or routing messages that consist of short transfers deemed critical to the operation of the network. Much of this traffic does not use any form of either bandwidth reservations or end-to-end congestion control. The continued use of end-to-end congestion control by best-effort traffic is critical for maintaining the stability of the Internet.
上述のRFCとは対照的に、この文書は、輻輳制御の原理のより一般的な議論です。インターネットの成功への鍵の一つは、TCPの輻輳回避メカニズムとなっています。 TCPはインターネットでまだ支配的なトランスポートプロトコルであるが、それはユビキタスではない、と、一つの理由または別のため、TCPを使用しないことを選択したアプリケーションが増えています。このようなトラフィックは、マルチキャストトラフィックが、そのような信頼性を必要としないマルチメディアストリーミングなどのユニキャストトラフィックだけでなく、。そのような短い転送で構成DNSまたはルーティングメッセージなどのトラフィックは、ネットワークの動作にとって重要とみなさ。このトラフィックの多くは、帯域幅の予約やエンドツーエンドの輻輳制御のいずれかの任意のフォームを使用していません。ベストエフォート型トラフィックによって、エンドツーエンドの輻輳制御の継続使用は、インターネットの安定性を維持するために重要です。
This document also discusses the general role of the IETF in the standardization of new congestion control protocols.
この文書はまた、新たな輻輳制御プロトコルの標準化でIETFの一般的な役割を説明します。
The discussion of congestion control principles for differentiated services or integrated services is not addressed in this document. Some categories of integrated or differentiated services include a guarantee by the network of end-to-end bandwidth, and as such do not require end-to-end congestion control mechanisms.
差別化されたサービスや統合サービスのための輻輳制御原則の議論は、この文書で扱われていません。統合または差別化サービスのいくつかのカテゴリは、エンドツーエンドの帯域幅のネットワークによる保証を含め、そのようにエンドツーエンドの輻輳制御メカニズムを必要としません。
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 [RFC896], and is technically called "congestion collapse".
インターネットプロトコルアーキテクチャは、IPプロトコルを使用してコネクションエンドツーエンドのパケットサービスに基づいています。そのコネクションレス設計、柔軟性と堅牢性の利点は、十分に実証されています。しかし、これらの利点は、コストがないわけではない。慎重な設計は、高負荷の下で良いサービスを提供するために必要とされます。実際には、パケット転送のダイナミクスへの配慮の欠如は深刻なサービス低下や「インターネットメルトダウン」につながることができます。この現象は、最初に1980年代半ば[RFC896]のインターネットの初期の成長期に観察し、技術的に「輻輳崩壊」と呼ばれています。
The original specification of TCP [RFC793] included window-based flow control as a means for the receiver to govern the amount of data sent by the sender. This flow control was used to prevent overflow of the receiver's data buffer space available for that connection. [RFC793]
受信するための手段としてTCP [RFC793]に含まウィンドウベースのフロー制御の元の仕様は、送信者によって送信されたデータの量を管理します。このフロー制御は、その接続のために利用可能な受信機のデータバッファ領域のオーバーフローを防止するために使用しました。 [RFC793]
reported that segments could be lost due either to errors or to network congestion, but did not include dynamic adjustment of the flow-control window in response to congestion.
セグメントがエラーまたはネットワークの輻輳のいずれかにより失われる可能性があることを報告したが、混雑に応じてフロー制御ウィンドウの動的な調整が含まれていませんでした。
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, RFC 2581]. 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 these TCP congestion avoidance algorithms that prevent the congestion collapse of today's Internet.
インターネットメルトダウンのために、元の修正は、バン・ジェイコブソンによって提供されました。 1986年に開始、ヤコブソンは、現在のTCP実装[Jacobson88、RFC 2581]で必要とされる輻輳回避メカニズムを開発しました。これらのメカニズムは、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 [RFC2581], while necessary and powerful, are not sufficient to provide good service in all circumstances. In addition to the development of new congestion control mechanisms [RFC2357], router-based mechanisms are in development that complement the endpoint congestion avoidance mechanisms.
しかし、それは物語の終わりではありません。かなりの研究は、1988年以来、インターネットのダイナミクスに行われている、そしてインターネットが成長してきました。これは、TCPの輻輳回避メカニズム[RFC2581]は、必要かつパワフルながら、すべての状況で良いサービスを提供するのに十分でないことが明らかになりました。新たな輻輳制御メカニズム[RFC2357]の開発に加えて、ルータ・ベースのメカニズムは、エンドポイントの輻輳回避メカニズムを補完する開発中です。
A major issue that still needs to be addressed is the potential for future congestion collapse of the Internet due to flows that do not use responsible end-to-end congestion control. RFC 896 [RFC896] suggested in 1984 that gateways should detect and `squelch' misbehaving hosts: "Failure to respond to an ICMP Source Quench message, though, should be regarded as grounds for action by a gateway to disconnect a host. Detecting such failure is non-trivial but is a worthwhile area for further research." Current papers still propose that routers detect and penalize flows that are not employing acceptable end-to-end congestion control [FF99].
まだ対処する必要がある主要な問題は、責任をエンドツーエンドの輻輳制御を使用していないフローにインターネットの将来の輻輳崩壊の可能性です。 RFC 896は、[RFC896]ゲートウェイがホストの誤動作検出および `スケルチ」べきであることを1984年に提案：「ICMPソース抑制メッセージに応答する障害が、しかし、ホストを切断するゲートウェイによって作用の根拠とみなされるべきであるそのような障害を検出します。非自明であるが、さらなる研究のために価値のあるエリアです。」現在の論文はまだルータが検出および許容可能なエンドツーエンドの輻輳制御[FF99]を用いていないフローを不利にすることを提案します。
In addition to a concern about congestion collapse, there is a concern about `fairness' for best-effort traffic. 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 compatible congestion control algorithms. For TCP, this means congestion control algorithms conformant with the current TCP specification [RFC793, RFC1122, RFC2581].
輻輳崩壊の懸念に加えて、ベストエフォート型トラフィックのための `公正が懸念されます。 TCPは輻輳時に「バックオフ」するので、TCPコネクションの多数は、帯域幅が同様の状況にフロー間合理的に公平に共有されるように、単一の、混雑リンクを共有することができます。フロー間の帯域幅の衡平な配分は、すべてのフローが互換性の輻輳制御アルゴリズムを実行しているという事実に依存します。 TCPの場合、これは現在のTCP仕様[RFC793、RFC1122、RFC2581]に準拠輻輳制御アルゴリズムを意味します。
The issue of fairness among competing flows has become increasingly important for several reasons. First, using window scaling [RFC1323], individual TCPs can use high bandwidth even over high-
競合するフロー間の公平性の問題は、いくつかの理由のためにますます重要になってきています。まず、ウィンドウスケーリング[RFC1323]を使用して、個々のTCPでも高の上に高帯域幅を使用することができます
propagation-delay paths. Second, with the growth of the web, Internet users increasingly want high-bandwidth and low-delay communications, rather than the leisurely transfer of a long file in the background. The growth of best-effort traffic that does not use TCP underscores this concern about fairness between competing best-effort traffic in times of congestion.
伝播遅延経路。第二に、ウェブの成長と、インターネットユーザーは、ますます高帯域幅と低遅延通信ではなく、バックグラウンドでの長いファイルの転送のんびりとしたいです。 TCPを使用していないベストエフォート型トラフィックの成長は、輻輳時における競合するベストエフォート型トラフィック間の公平性については、この懸念を強調しています。
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 [RFC2525]. 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, or increasingly aggressive transport protocols, leading back to the point where there is effectively no congestion avoidance and the Internet is chronically congested.
インターネットの普及は、TCP実装の数の増殖を起こしています。これらのいくつかは正確に悪いため、実装[RFC2525]のTCPの輻輳回避メカニズムを実装するために失敗することがあります。その他は、故意に他のTCP実装よりも帯域幅の利用で、より積極的で輻輳回避アルゴリズムを実装することができます。これは、ベンダーが「速くTCP」を持っていると主張することができるようになります。そのような実装の論理的帰結は、バックそこには輻輳回避が有効ではないとインターネットが慢性的に混雑している点に至る、ますます積極的なTCPの実装、又はますます積極的なトランスポートプロトコルの螺旋であろう。
There is a well-known way to achieve more aggressive performance without even changing the transport protocol, by changing the level of granularity: open multiple connections to the same place, as has been done in the past by some Web browsers. Thus, instead of a spiral of increasingly aggressive transport protocols, we would instead have a spiral of increasingly aggressive web browsers, or increasingly aggressive applications.
粒度のレベルを変更することで、でも、トランスポートプロトコルを変更することなく、より積極的な性能を達成するために、よく知られた方法があります：いくつかのWebブラウザで過去に行ってきたように、同じ場所に複数の接続を開きます。したがって、代わりにますます積極的なトランスポートプロトコルのスパイラルの、我々は代わりにますます積極的なウェブブラウザ、またはますます積極的なアプリケーションのスパイラルを持っているでしょう。
This raises the issue of the appropriate granularity of a "flow", where we define a `flow' as the level of granularity appropriate for the application of both fairness and congestion control. From RFC 2309: "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. 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."
これは、我々は公平性と輻輳制御の両方のアプリケーションのための適切な粒度のレベルとして `フロー」を定義する「フロー」、の適切な粒度の問題を提起します。 RFC 2309から：「少数 `自然の回答があります：1）、TCPまたはUDP接続（送信元アドレス/ポート、宛先アドレス/ポート）; 2）送信元/宛先ホストのペア; 3）指定された送信元ホストまたは宛先ホスト与えられた。私たちは、送信元/宛先ホストのペアは、多くの状況で最も適切な粒度を与えること。輻輳管理のためのフローの粒度は、少なくとも部分的には、より広いIETFコミュニティに対処する必要があるポリシーの問題だと思います。」
Again borrowing from RFC 2309, we use 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 uses no more bandwidth than a conformant TCP running under comparable conditions (drop rate, RTT, MTU, etc.)
再びRFC 2309からの借入、我々は準拠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 discuss below.
応答性であるが、TCP-互換性はありません（1）TCP互換フロー、（2）無反応の流れ、すなわち、輻輳が発生したときに遅くなることはありませんが流れ、および（3）のフロー：3つのクラスに流れて分割すると便利です。最後の2つのクラスが、我々は、以下の議論として、インターネットのパフォーマンスに重大な脅威をもたらす、より積極的なフローを含んでいます。
In addition to steady-state fairness, the fairness of the initial slow-start is also a concern. One concern is the transient effect on other flows of a flow with an overly-aggressive slow-start procedure. Slow-start performance is particularly important for the many flows that are short-lived, and only have a small amount of data to transfer.
定常状態の公正性に加えて、初期スロースタートの公平性も懸念されます。一つの懸念は、過度に攻撃的なスロースタート手順の流れの他のフローに過渡的な効果です。スロースタートのパフォーマンスは短命である多くのフローのために特に重要である、とだけ転送するデータ量が小さいです。
In addition to the prevention of congestion collapse and concerns about fairness, a third reason for a flow to use end-to-end congestion control can be to optimize its own performance regarding throughput, delay, and loss. In some circumstances, for example in environments of high statistical multiplexing, the delay and loss rate experienced by a flow are largely independent of its own sending rate. However, in environments with lower levels of statistical multiplexing or with per-flow scheduling, the delay and loss rate experienced by a flow is in part a function of the flow's own sending rate. Thus, a flow can use end-to-end congestion control to limit the delay or loss experienced by its own packets. We would note, however, that in an environment like the current best-effort Internet, concerns regarding congestion collapse and fairness with competing flows limit the range of congestion control behaviors available to a flow.
輻輳崩壊と公平性に関する懸念の防止に加えて、エンドツーエンドの輻輳制御を使用する流れのための第三の理由は、スループット、遅延、損失に関して、独自の性能を最適化することができます。いくつかの状況では、高い統計的多重化の環境において、例えば、フローが経験する遅延と損失率は、それ自身の送信レートの大部分は独立しています。しかし、統計的多重化の低いレベルで、またはフローごとのスケジューリングを有する環境において、フローが経験する遅延と損失率は、部分的にフロー自身の送信レートの関数です。したがって、流れは、それ自身のパケットによって経験される遅延または損失を制限するために、エンドツーエンドの輻輳制御を使用することができます。私たちは、現在のベストエフォート型のインターネットのような環境では、競合するフローで輻輳崩壊と公平性に関する懸念が流れに利用できる輻輳制御行動の範囲を制限すること、しかし、注意します。
The standardization of a transport protocol includes not only standardization of aspects of the protocol that could affect interoperability (e.g., information exchanged by the end-nodes), but also standardization of mechanisms deemed critical to performance (e.g., in TCP, reduction of the congestion window in response to a packet drop). At the same time, implementation-specific details and other aspects of the transport protocol that do not affect interoperability and do not significantly interfere with performance do not require standardization. Areas of TCP that do not require standardization include the details of TCP's Fast Recovery procedure after a Fast Retransmit [RFC2582]. The appendix uses examples from TCP to discuss in more detail the role of the standards process in the development of congestion control.
トランスポートプロトコルの標準化は相互運用性に影響を与える可能性があり、プロトコルの側面だけではなく標準化を含み（例えば、情報エンドノードによって交換）だけでなく、メカニズムの標準化は、TCPで、渋滞の削減を例えば、パフォーマンス（に重要とみなされますパケットドロップに対応してウィンドウ）。同時に、実装固有の詳細と相互運用性に影響を与えず、パフォーマンスが大幅に干渉しないトランスポートプロトコルの他の側面は、標準化を必要としません。標準化を必要としないTCPのエリアは高速再送[RFC2582]の後にTCPの高速リカバリ手順の詳細を含みます。付録では、輻輳制御の開発に、より詳細に標準化プロセスの役割を議論するためにTCPからの例を使用しています。
In addition to addressing the danger of congestion collapse, the standardization process for new transport protocols takes care to avoid a congestion control `arms race' among competing protocols. As an example, in RFC 2357 [RFC2357] the TSV Area Directors and their Directorate outline criteria for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols. From [RFC2357]: "A particular concern for the IETF is the impact of reliable multicast traffic on other traffic in the Internet in times of congestion, in particular the effect of reliable multicast traffic on competing TCP traffic.... The challenge to the IETF is to encourage research and implementations of reliable multicast, and to enable the needs of applications for reliable multicast to be met as expeditiously as possible, while at the same time protecting the Internet from the congestion disaster or collapse that could result from the widespread use of applications with inappropriate reliable multicast mechanisms."
輻輳崩壊の危険に対処することに加えて、新しいトランスポートプロトコルの標準化プロセスは、競合するプロトコル間の輻輳制御 `軍拡競争」を避けるように注意を要します。一例として、RFC 2357に[RFC2357] TSVエリア取締役および出版のためのそれらの総局輪郭基準信頼できるマルチキャストトランスポートプロトコル上でインターネットドラフトのRFCとして。 [RFC2357]から：「IETFのために特に関心が競合するTCPトラフィックの信頼性の高いマルチキャストトラフィックの特に効果、輻輳時にインターネットで他のトラフィック上の信頼性の高いマルチキャストトラフィックの影響です....への挑戦IETFは、信頼性の高いマルチキャストの研究と実装を奨励すると同時に、広く使用から生じる可能性が混雑災害や崩壊からインターネットを保護しながら、可能な限り迅速満たさなければ信頼性の高いマルチキャストのためのアプリケーションのニーズを有効にすることです不適切な信頼性の高いマルチキャストメカニズムを使用したアプリケーションの。」
The list of technical criteria that must be addressed by RFCs on new reliable multicast transport protocols include the following: "Is there a congestion control mechanism? How well does it perform? When does it fail? Note that congestion control mechanisms that operate on the network more aggressively than TCP will face a great burden of proof that they don't threaten network stability."
？新しい信頼性の高いマルチキャストトランスポートプロトコル上のRFCで取り組まなければならない技術的な基準のリストには、次のものがあります？「輻輳制御機構は、それが失敗しない場合はどのようにうまくそれが実行しないありますが、ネットワーク上で動作する輻輳制御メカニズムに注意してください。より積極的にTCPよりも、彼らはネットワークの安定性を脅かすていないことの証明の大きな負担に直面するだろう。」
It is reasonable to expect that these concerns about the effect of new transport protocols on competing traffic will apply not only to reliable multicast protocols, but to unreliable unicast, reliable unicast, and unreliable multicast traffic as well.
競合するトラフィックに新しいトランスポートプロトコルの効果に関するこれらの懸念だけでなく、信頼性の高いマルチキャストプロトコルに適用されることを期待するのは合理的であるが、信頼できないユニキャスト、信頼性の高いユニキャスト、および信頼性の低いマルチキャストトラフィックにも同様に。
The specific issue of a browser opening multiple connections to the same destination has been addressed by RFC 2616 [RFC2616], which states in Section 8.1.4 that "Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."
同じ宛先への複数の接続を開くブラウザの特定の問題は、持続的な接続を使用するクライアントは、与えられたに彼らは維持する同時接続数を制限すべきである」というセクション8.1.4で述べRFC 2616 [RFC2616]によって対処されてきましたサーバー。シングルユーザクライアントは、任意のサーバーまたはプロキシとの2つの以上の接続を維持すべきではありません。」
The most obvious developments in the IETF that could affect the evolution of congestion control are the development of integrated and differentiated services [RFC2212, RFC2475] and of Explicit Congestion Notification (ECN) [RFC2481]. However, other less dramatic developments are likely to affect congestion control as well.
輻輳制御の進化に影響を与える可能性がIETFの中で最も明白な開発は統合され、差別化サービス[RFC2212、RFC2475]のと明示的輻輳通知（ECN）[RFC2481]の開発です。しかし、他のあまり劇的な発展は、同様の輻輳制御に影響を与える可能性があります。
One such effort is that to construct Endpoint Congestion Management [BS00], to enable multiple concurrent flows from a sender to the same receiver to share congestion control state. By allowing multiple connections to the same destination to act as one flow in terms of end-to-end congestion control, a Congestion Manager could allow individual connections slow-starting to take advantage of previous information about the congestion state of the end-to-end path. Further, the use of a Congestion Manager could remove the congestion control dangers of multiple flows being opened between the same source/destination pair, and could perhaps be used to allow a browser to open many simultaneous connections to the same destination.
そのような努力は、輻輳制御状態を共有するために、同じ受信機に送信機から複数の同時の流れを可能にするために、エンドポイント輻輳管理[BS00]を構築することです。エンドツーエンドの輻輳制御の点でつの流れとして作用する同じ宛先への複数の接続を可能にすることによって、輻輳マネージャは、個々の接続はエンドツーの輻輳状態に関する以前の情報を活用する遅い開始可能性がありますエンドパス。さらに、輻輳マネージャの使用は、同じソース/宛先ペアの間に開かれている複数のフローの輻輳制御危険を取り除くことができ、そしておそらく同じ宛先への多数の同時接続を開くためにブラウザを可能にするために使用することができます。
This section discusses congestion collapse from undelivered packets in some detail, and shows how unresponsive flows could contribute to congestion collapse in the Internet. This section draws heavily on material from [FF99].
このセクションでは、いくつかの詳細に未配信のパケットから輻輳崩壊を説明し、そして無反応流れは、インターネットにおける輻輳崩壊に貢献できる方法を示しています。このセクションでは、[FF99]から材料に大きく描画します。
Informally, congestion collapse occurs when an increase in the network load results in a decrease in the useful work done by the network. As discussed in Section 3, congestion collapse was first reported in the mid 1980s [RFC896], and was largely due to TCP connections unnecessarily retransmitting packets that were either in transit or had already been received at the receiver. We call the congestion collapse that results from the unnecessary retransmission of packets classical congestion collapse. Classical congestion collapse is a stable condition that can result in throughput that is a small fraction of normal [RFC896]. Problems with classical congestion collapse have generally been corrected by the timer improvements and congestion control mechanisms in modern implementations of TCP [Jacobson88].
有益な仕事の減少でネットワーク負荷結果の増加は、ネットワークによって行われたときに非公式に、輻輳崩壊が起こります。第3節で説明したように、輻輳崩壊は、最初1980年代半ば[RFC896]で報告され、そして主として不必要に輸送中又は既に受信機で受信されたいずれかであったパケットを再送信するTCP接続にしました。私たちは、パケットの古典的な輻輳崩壊の不必要な再送信の結果で混雑崩壊を呼び出します。古典的な輻輳崩壊は、通常、[RFC896]の小部分であるスループットをもたらすことができる安定した状態です。古典輻輳崩壊の問題は、一般的にTCPの近代的な実装でタイマーの改善と輻輳制御メカニズム[Jacobson88]によって修正されました。
A second form of potential congestion collapse occurs due to undelivered packets. Congestion collapse from undelivered packets arises when bandwidth is wasted by delivering packets through the network that are dropped before reaching their ultimate destination. This is probably the largest unresolved danger with respect to congestion collapse in the Internet today. Different scenarios can result in different degrees of congestion collapse, in terms of the fraction of the congested links' bandwidth used for productive work. The danger of congestion collapse from undelivered packets is due primarily to the increasing deployment of open-loop applications not using end-to-end congestion control. Even more destructive would be best-effort applications that *increase* their sending rate in response to an increased packet drop rate (e.g., automatically using an increased level of FEC).
潜在的な輻輳崩壊の第2の形態は、未配信のパケットに起因し発生します。未配信のパケットから輻輳崩壊は帯域幅が彼らの最終目的地に到達する前に廃棄されたネットワークを介してパケットを提供することにより、無駄にされたときに発生します。これはおそらく、インターネットにおける輻輳崩壊今日に関して最大の未解決の危険です。異なるシナリオが生産的な作業に使用混雑したリンク帯域幅の分率で、輻輳崩壊の程度が異なるにつながることができます。未配信のパケットからの輻輳崩壊の危険性は、主にエンドツーエンドの輻輳制御を使用していないオープン・ループ・アプリケーションの増加展開によるものです。さらに破壊が増加し、パケットドロップ率に応じて*増加*自分の送信レート（例えば、自動的にFECのレベルの増加を使用して）ベストエフォート型のアプリケーションになります。
Table 1 gives the results from a scenario with congestion collapse from undelivered packets, where scarce bandwidth is wasted by packets that never reach their destination. The simulation uses a scenario with three TCP flows and one UDP flow competing over a congested 1.5 Mbps link. The access links for all nodes are 10 Mbps, except that the access link to the receiver of the UDP flow is 128 Kbps, only 9% of the bandwidth of shared link. When the UDP source rate exceeds 128 Kbps, most of the UDP packets will be dropped at the output port to that final link.
表1は、希少な帯域幅が彼らの目的地に到達することはありませんパケットによって浪費される未配信パケットから輻輳崩壊とシナリオからの結果を提供します。シミュレーションは、3つのTCPフローと1つのUDPフローが輻輳1.5 Mbpsのリンク上で競合するとのシナリオを使用しています。すべてのノードのアクセスリンクは、UDPフローの受信機へのアクセスリンクは128 Kbpsで、共有リンクの帯域幅のわずか9％であることを除いて10Mbpsです。 UDPのソースレートが128 Kbpsのを超えた場合、UDPパケットのほとんどは、その最終的なリンクへの出力ポートでドロップされます。
UDP
Arrival UDP TCP Total
Rate Goodput Goodput Goodput
--------------------------------------
0.7 0.7 98.5 99.2
1.8 1.7 97.3 99.1
2.6 2.6 96.0 98.6
5.3 5.2 92.7 97.9
8.8 8.4 87.1 95.5
10.5 8.4 84.8 93.2
13.1 8.4 81.4 89.8
17.5 8.4 77.3 85.7
26.3 8.4 64.5 72.8
52.6 8.4 38.1 46.4
58.4 8.4 32.8 41.2
65.7 8.4 28.5 36.8
75.1 8.4 19.7 28.1
87.6 8.4 11.3 19.7
105.2 8.4 3.4 11.8
131.5 8.4 2.4 10.7
Table 1. A simulation with three TCP flows and one UDP flow.
3つのTCPフローと1つのUDPフロー表1.シミュレーション。
Table 1 shows the UDP arrival rate from the sender, the UDP goodput (defined as the bandwidth delivered to the receiver), the TCP goodput (as delivered to the TCP receivers), and the aggregate goodput on the congested 1.5 Mbps link. Each rate is given as a fraction of the bandwidth of the congested link. As the UDP source rate increases, the TCP goodput decreases roughly linearly, and the UDP goodput is nearly constant. Thus, as the UDP flow increases its offered load, its only effect is to hurt the TCP and aggregate goodput. On the congested link, the UDP flow ultimately `wastes' the bandwidth that could have been used by the TCP flow, and reduces the goodput in the network as a whole down to a small fraction of the bandwidth of the congested link.
表1は、送信者からのUDP到着レート、（受信機に配信帯域幅として定義される）UDPのグッドプット、TCPグッドプット（TCP受信機に配信されるように）、および混雑1.5 Mbpsリンク上の集約グッドプットを示しています。それぞれの割合は、混雑したリンクの帯域幅の一部として与えられています。 UDPソースレートが増加するにつれて、略直線的に減少グッドプットTCP、UDP及びグッドプットはほぼ一定です。 UDPフローが提供され、負荷が増加するとこのように、その唯一の効果は、TCPと集計グッドプットを傷つけることです。混雑したリンクでは、UDPフロー最終的に `廃棄物TCPフローで使用され、混雑リンクの帯域幅の小部分まで全体として、ネットワーク内のグッドプットが減少されている可能性が帯域幅。
The simulations in Table 1 illustrate both unfairness and congestion collapse. As [FF99] discusses, compatible congestion control is not the only way to provide fairness; per-flow scheduling at the congested routers is an alternative mechanism at the routers that guarantees fairness. However, as discussed in [FF99], per-flow scheduling can not be relied upon to prevent congestion collapse.
表1のシミュレーションは、不公平と輻輳崩壊の両方を示します。 【FF99は】論じたように、互換性のある輻輳制御は、公平性を提供するための唯一の方法ではありません。混雑ルータでのフローごとのスケジューリングは、公平性を保証ルータで代替メカニズムです。しかし、[FF99]で議論するように、フローごとのスケジューリングは、輻輳崩壊を防止するために依拠することはできません。
There are only two alternatives for eliminating the danger of congestion collapse from undelivered packets. The first alternative for preventing congestion collapse from undelivered packets is the use of effective end-to-end congestion control by the end nodes. More specifically, the requirement would be that a flow avoid a pattern of significant losses at links downstream from the first congested link on the path. (Here, we would consider any link a `congested link' if any flow is using bandwidth that would otherwise be used by other traffic on the link.) Given that an end-node is generally unable to distinguish between a path with one congested link and a path with multiple congested links, the most reliable way for a flow to avoid a pattern of significant losses at a downstream congested link is for the flow to use end-to-end congestion control, and reduce its sending rate in the presence of loss.
未配信のパケットからの輻輳崩壊の危険性を排除するための唯一の2つの選択肢があります。未配信のパケットから輻輳崩壊を防止するための最初の選択肢は、エンド・ノードによって有効なエンドツーエンドの輻輳制御を使用することです。具体的には、要件は、フローはパス上の最初の混雑のリンクから下流のリンクでの重大な損失のパターンを避けるということでしょう。 （いずれかの流れがそうでなければ、リンク上の他のトラフィックによって使用される帯域幅を使用している場合はここで、我々は `混雑リンク」は任意のリンクを検討する。）エンド・ノードは、一般的に1混雑したリンクとパスを区別することができないことを考えますそして、複数の輻輳したリンクのパスは、下流の混雑したリンクで重大な損失のパターンを回避するためのフローのための最も確実な方法は、フローは、エンドツーエンドの輻輳制御を使用して、の存在下で、その送信速度を低下させるためであります損失。
A second alternative for preventing congestion collapse from undelivered packets would be a guarantee by the network that packets accepted at a congested link in the network will be delivered all the way to the receiver [RFC2212, RFC2475]. We note that the choice between the first alternative of end-to-end congestion control and the second alternative of end-to-end bandwidth guarantees does not have to be an either/or decision; congestion collapse can be prevented by the use of effective end-to-end congestion by some of the traffic, and the use of end-to-end bandwidth guarantees from the network for the rest of the traffic.
第二未送達パケットから輻輳崩壊を防止するための別のネットワークに輻輳リンクで受け付けパケットが受信機にすべての方法を配信するネットワークによって保証あろう[RFC2212、RFC2475]。私たちは、エンドツーエンドの輻輳制御の第一の代替とエンドツーエンドの帯域保証の第二の代替の間の選択はどちらか/または決定する必要がないことに注意してください。輻輳崩壊は、トラフィックの一部によって、効果的なエンド・ツー・エンドの輻輳の使用、およびトラフィックの残りのためのネットワークからエンド・ツー・エンドの帯域保証を利用することによって防止することができます。
This document has discussed concerns about congestion collapse and about fairness with TCP for new forms of congestion control. This does not mean, however, that concerns about congestion collapse and fairness with TCP necessitate that all best-effort traffic deploy congestion control based on TCP's Additive-Increase Multiplicative-Decrease (AIMD) algorithm of reducing the sending rate in half in response to each packet drop. This section separately discusses the implications of these two concerns of congestion collapse and fairness with TCP.
この文書では、輻輳崩壊についてと輻輳制御の新しい形態のためのTCPとの公平性についての懸念を議論しました。これは、TCPと輻輳崩壊と公平性への懸念が、それぞれに対応して半分に送信レートを低下させるTCPの添加剤-増加乗法-減少（AIMD）のアルゴリズムに基づいて、すべてのベストエフォート型トラフィックのデプロイ輻輳制御することを必要とすることを、しかし、意味するものではありませんパケットドロップ。このセクションでは、個別にTCPで輻輳崩壊と公平性のこれら二つの問題の影響を議論します。
The avoidance of congestion collapse from undelivered packets requires that flows avoid a scenario of a high sending rate, multiple congested links, and a persistent high packet drop rate at the downstream link. Because congestion collapse from undelivered packets consists of packets that waste valuable bandwidth only to be dropped downstream, this form of congestion collapse is not possible in an environment where each flow traverses only one congested link, or where only a small number of packets are dropped at links downstream of the first congested link. Thus, any form of congestion control that successfully avoids a high sending rate in the presence of a high packet drop rate should be sufficient to avoid congestion collapse from undelivered packets.
未配信のパケットからの輻輳崩壊の回避は、フローが高い送信レート、複数の輻輳したリンク、および下流のリンクで持続的に高いパケット廃棄率のシナリオを回避する必要があります。未配信のパケットから輻輳崩壊のみ下流ドロップする貴重な帯域幅を無駄にパケットで構成されているので、輻輳崩壊のこの形態は、各フローは一の輻輳リンクを横断する、またはパケットの数が少ないでドロップされる環境では不可能です最初の混雑リンクの下流にリンクしています。したがって、正常高いパケットドロップレートの存在下で高い送信レートを回避する輻輳制御の任意の形態は、未配信のパケットから輻輳崩壊を回避するのに十分であるべきです。
We would note that the addition of Explicit Congestion Notification (ECN) to the IP architecture would not, in and of itself, remove the danger of congestion collapse for best-effort traffic. ECN allows routers to set a bit in packet headers as an indication of congestion to the end-nodes, rather than being forced to rely on packet drops to indicate congestion. However, with ECN, packet-marking would replace packet-dropping only in times of moderate congestion. In particular, when congestion is heavy, and a router's buffers overflow, the router has no choice but to drop arriving packets.
私たちは、ベストエフォートトラフィックの輻輳崩壊の危険性を取り除く、IPアーキテクチャへの明示的輻輳通知（ECN）の添加は、それ自体は、ないことに注意してくださいます。 ECNはなくパケットに頼ることを余儀なくされるよりも、ルータがエンドノードに輻輳の指標としてパケットヘッダ内のビットを設定することができ、輻輳を示すために低下します。しかし、ECNと、パケットマーキングは、パケットドロップするだけで、中程度の混雑の時代にに取って代わるだろう。輻輳が重く、ルータのバッファオーバーフロー時に特に、ルータは、到着したパケットを廃棄するしかありません。
The concern expressed in [RFC2357] about fairness with TCP places a significant though not crippling constraint on the range of viable end-to-end congestion control mechanisms for best-effort traffic. An environment with per-flow scheduling at all congested links would isolate flows from each other, and eliminate the need for congestion control mechanisms to be TCP-compatible. An environment with differentiated services, where flows marked as belonging to a certain diff-serv class would be scheduled in isolation from best-effort traffic, could allow the emergence of an entire diff-serv class of traffic where congestion control was not required to be TCP-compatible. Similarly, a pricing-controlled environment, or a diff-serv class with its own pricing paradigm, could supercede the concern about fairness with TCP. However, for the current Internet environment, where other best-effort traffic could compete in a FIFO queue with TCP traffic, the absence of fairness with TCP could lead to one flow `starving out' another flow in a time of high congestion, as was illustrated in Table 1 above.
TCPとの公平性について[RFC2357]で表される懸念はベストエフォート型トラフィックのための実行可能なエンドツーエンドの輻輳制御機構の範囲にない壊滅的制約ものの大きなを配置します。すべての輻輳したリンクでのフローごとのスケジューリングと環境が相互に流れを分離し、輻輳制御機構は、TCPと互換性のあることをする必要性を排除するであろう。特定の差分-SERVクラスに属するものとしてマークされたフロー差別化されたサービスと環境が、ベストエフォートトラフィックから分離して、スケジュールされるだろう、輻輳制御があることが要求されなかったトラフィックの全体差分-SERVクラスの出現を可能性がありますTCP互換。同様に、価格設定、制御された環境、または独自の価格設定のパラダイムとのdiff-SERVクラスは、TCPとの公平性についての懸念に取って代わることができます。しかし、他のベストエフォート型トラフィックはTCPトラフィックでFIFOキューで競うことができ、現在のインターネット環境のために、TCPとの公平性の欠如があったように、高い輻輳の時に「別の流れを飢え `1つの流れにつながる可能性があります上記表1に示します。
However, the list of TCP-compatible congestion control procedures is not limited to AIMD with the same increase/ decrease parameters as TCP. Other TCP-compatible congestion control procedures include rate-based variants of AIMD; AIMD with different sets of increase/decrease parameters that give the same steady-state behavior; equation-based congestion control where the sender adjusts its sending rate in response to information about the long-term packet drop rate; layered multicast where receivers subscribe and unsubscribe from layered multicast groups; and possibly other forms that we have not yet begun to consider.
しかし、TCP互換輻輳制御手順のリストは、TCPと同じ増加/減少パラメータでAIMDに限定されるものではありません。その他のTCP互換の輻輳制御手順は、AIMDのレートベース変異体を含みます。同一の定常状態の挙動を与える増加/減少パラメータの異なる組を有するAIMD。送信者は、長期的なパケットのドロップ率に関する情報に応答して、その送信レートを調整する方程式ベースの輻輳制御。受信機は、層状マルチキャストグループから加入及び解除層状マルチキャスト。おそらく、我々はまだ始まっていない他の形態は、検討します。
Much of this document draws directly on previous RFCs addressing end-to-end congestion control. This attempts to be a summary of ideas that have been discussed for many years, and by many people. In particular, acknowledgement is due to the members of the End-to-End Research Group, the Reliable Multicast Research Group, and the Transport Area Directorate. This document has also benefited from discussion and feedback from the Transport Area Working Group. Particular thanks are due to Mark Allman for feedback on an earlier version of this document.
このドキュメントの多くは、エンドツーエンドの輻輳制御に取り組む以前のRFCに直接描画します。これは、長年にわたり、多くの人々によって議論されたアイデアの要約であることを試みます。特に、確認応答は、エンドツーエンドの研究グループ、信頼性の高いマルチキャスト研究グループ、および交通地域総局のメンバーによるものです。また、このドキュメントでは、交通エリアワーキンググループからの議論やフィードバックの恩恵を受けています。特定の感謝はこのドキュメントの以前のバージョンへのフィードバックのためにマーク・オールマンによるものです。
[BS00] Balakrishnan H. and S. Seshan, "The Congestion Manager", Work in Progress.
[BS00]バラクリシュナンH.とS. Seshan、 "輻輳管理"、進行中の作業。
[DMKM00] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", Work in Progress.
【DMKM00]ドーキンス、S.、モンテネグロ、G.、古城、M.およびV. Magret、 "低速リンクのエンドツーエンドのパフォーマンスへの影響"、ProgressのWork。
[FF99] Floyd, S. and K. Fall, "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999. URL http://www.aciri.org/floyd/end2end-paper.html
[FF99]フロイド、S.とK.秋、「インターネットにおけるエンドツーエンドの輻輳制御の利用促進」、IEEE / ACM取引ネットワーク、1999年8月URLにhttp://www.aciri.org/フロイド/ end2end-paper.html
[HPF00] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
【HPF00]ハンドレー、M.、Padhye、J.及びS.フロイド、 "TCP輻輳ウィンドウ検証"、RFC 2861、2000年6月。
[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988.
[Jacobson88] V.ヤコブソン、輻輳回避とコントロール、ACM SIGCOMM '88、1988年8月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
[RFC896]ネーグル、J.、 "IP / TCPにおける輻輳制御"、RFC 896、1984年1月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[RFC2309] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K.K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデン、R.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、KK、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RFC2357] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]マンキン、A.、Romanow、A.、ブラドナーの、S.とV.パクソン、 "信頼性の高いマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETF基準"、RFC 2357、1998年6月。
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414]オールマン、M.、フロイド、S.とC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 2414、1998年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2481] Ramakrishnan K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RFC2481]ラマクリシュナンK.及びS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[RFC2525]パクソン、V.、オールマン、M.、ドーソン、S.、フェナー、W.、Griner、J.、天、I.、レイヒー、K.、Semke、J.およびB.フォルツ、「既知のTCP実装の問題」、RFC 2525、1999年3月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.
[SCWA99] S.サヴェージ、N.カードウェル、D. Wetherall、およびT.アンダーソン、ふらちなレシーバーとのTCP輻輳制御、ACMコンピュータコミュニケーションレビュー、1999年10月。
[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan, Mark Stemm, and Randy H. Katz, TCP Behavior of a Busy Internet Server: Analysis and Improvements, IEEE Infocom, March 1998. Available from: "http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz".
[TCPB98]ハリ・バラクリシュナン、ヴェンカタN. Padmanabhan、スリニバサン・セシャン、マーク・Stemm、およびランディH.カッツ、忙しいインターネットサーバーのTCPの挙動：分析と改善、IEEEインフォコム年3月から利用可能な1998：「のhttp：// WWW .cs.berkeley.edu /〜ハリ/論文/ infocom98.ps.gz」。
[TCPF98] Dong Lin and H.T. Kung, TCP Fast Recovery Strategies: Analysis and Improvements, IEEE Infocom, March 1998. Available from: "http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf".
【TCPF98]ドンリン及びH.T.クン、TCP高速リカバリ戦略：分析と改善、IEEEインフォコム年3月から利用可能な1998年：「http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf」。
In this section we discuss some of the particulars of TCP congestion control, to illustrate a realization of the congestion control principles, including some of the details that arise when incorporating them into a production transport protocol.
このセクションでは、生産トランスポートプロトコルに組み込む際に生じる詳細の一部を含め、輻輳制御原則の実現を説明するために、TCPの輻輳制御の詳細のいくつかを議論します。
The TCP sender can not open a new connection by sending a large burst of data (e.g., a receiver's advertised window) all at once. The TCP sender is limited by a small initial value for the congestion window. During slow-start, the TCP sender can increase its sending rate by at most a factor of two in one roundtrip time. Slow-start ends when congestion is detected, or when the sender's congestion window is greater than the slow-start threshold ssthresh.
TCPの送信者は、一度にすべてのデータの大バースト（例えば、受信機の広告ウィンドウ）を送信することにより、新しい接続を開くことができません。 TCP送信側は輻輳ウィンドウの小さな初期値によって制限されています。スロースタートの間、TCPの送信者は1往復時間に2つの最大の要因によって、その送信レートを上げることができます。輻輳が検出されたとき、または送信者の輻輳ウィンドウは、スロースタートしきい値SSTHRESHよりも大きい場合にスロースタートが終了します。
An issue that potentially affects global congestion control, and therefore has been explicitly addressed in the standards process, includes an increase in the value of the initial window [RFC2414,RFC2581].
潜在的にグローバルな輻輳制御に影響を及ぼし、したがって、明示的に標準化プロセスで対処された問題は、初期ウィンドウ[RFC2414、RFC2581]の値の増加が含まれます。
Issues that have not been addressed in the standards process, and are generally considered not to require standardization, include such issues as the use (or non-use) of rate-based pacing, and mechanisms for ending slow-start early, before the congestion window reaches ssthresh. Such mechanisms result in slow-start behavior that is as conservative or more conservative than standard TCP.
混雑する前に、早期にスロースタートを終了するための標準化プロセスで対処されておらず、一般的に標準化を必要としないと考えられている、レートベースペーシングの使用（または非使用）などの問題が含まれる、とメカニズムの問題ウィンドウには、SSTHRESHに達します。そのようなメカニズムは、保存的または標準のTCPより保守的であるスロースタート動作をもたらします。
In the absence of congestion, the TCP sender increases its congestion window by at most one packet per roundtrip time. In response to a congestion indication, the TCP sender decreases its congestion window by half. (More precisely, the new congestion window is half of the minimum of the congestion window and the receiver's advertised window.)
渋滞がない場合には、TCPの送信者は、往復時間あたり最大1つのパケットによってその輻輳ウィンドウが増加します。混雑指示に応答して、TCPの送信者は半分にすることにより、その輻輳ウィンドウを減少させます。 （より正確には、新しい輻輳ウィンドウは、輻輳ウィンドウと受信機の広告ウィンドウの最小値の半分です。）
An issue that potentially affects global congestion control, and therefore would be likely to be explicitly addressed in the standards process, would include a proposed addition of congestion control for the return stream of `pure acks'.
潜在的にグローバルな輻輳制御に影響を及ぼし、したがって、明示的に標準化プロセスで対処可能性が高いだろう問題は、 `純粋のACKの戻りストリームの輻輳制御の提案追加が含まれるであろう。
An issue that has not been addressed in the standards process, and is generally not considered to require standardization, would be a change to the congestion window to apply as an upper bound on the number of bytes presumed to be in the pipe, instead of applying as a sliding window starting from the cumulative acknowledgement. (Clearly, the receiver's advertised window applies as a sliding window starting from the cumulative acknowledgement field, because packets received above the cumulative acknowledgement field are held in TCP's receive buffer, and have not been delivered to the application. However, the congestion window applies to the number of packets outstanding in the pipe, and does not necessarily have to include packets that have been received out-of-order by the TCP receiver.)
標準化プロセスで対処されておらず、一般的に標準化を必要とすると考えられていない、パイプであると推定されるバイト数の上限として適用するために輻輳ウィンドウへ変更となり、代わりに適用の問題累積確認応答から出発スライディングウィンドウとして。パケットが受信バッファTCPのに保持される累積確認応答フィールド上に受信され、アプリケーションに配信されていないため（明らかに、受信機の広告ウィンドウは、累積確認応答フィールドから出発スライディングウィンドウとして適用される。しかし、輻輳ウィンドウは、に適用されますパイプ内の未処理パケットの数は、必ずしもTCP受信機によってアウトオブオーダー受信されたパケットを含む必要はありません。）
The TCP sender sets a retransmit timer to infer that a packet has been dropped in the network. When the retransmit timer expires, the sender infers that a packet has been lost, sets ssthresh to half of the current window, and goes into slow-start, retransmitting the lost packet. If the retransmit timer expires because no acknowledgement has been received for a retransmitted packet, the retransmit timer is also "backed-off", doubling the value of the next retransmit timeout interval.
TCPの送信者は、パケットがネットワークにドロップされたことを推測するために再送信タイマーを設定します。再送信タイマーが満了すると、送信者は、パケットが失われていることを推測する現在のウィンドウの半分にSSTHRESHを設定し、スロースタートになり、失われたパケットを再送します。確認応答が再送信されたパケットのために受信されていないため、再送信タイマーが満了した場合は、再送信タイマは、次の再送信タイムアウト間隔の値を倍に、また、「バックオフ」です。
An issue that potentially affects global congestion control, and therefore would be likely to be explicitly addressed in the standards process, might include a modified mechanism for setting the retransmit timer that could significantly increase the number of retransmit timers that expire prematurely, when the acknowledgement has not yet arrived at the sender, but in fact no packets have been dropped. This could be of concern to the Internet standards process because retransmit timers that expire prematurely could lead to an increase in the number of packets unnecessarily transmitted on a congested link.
潜在的にグローバルな輻輳制御に影響を及ぼし、したがって、明示的に標準化プロセスで対処可能性が高いだろう問題、確認応答がある場合、大幅に早まって期限切れに再送信タイマーの数を増やす可能性が再送信タイマーを設定するための修正機構を含むかもしれませんまだ、送信者に到着したが、実際には何のパケットは廃棄されていないではありません。途中で期限切れに再送信タイマーが不必要に混雑したリンク上で送信されたパケットの数の増加につながる可能性があるため、これはインターネット標準化プロセスへの懸念である可能性があります。
After seeing three duplicate acknowledgements, the TCP sender infers a packet loss. The TCP sender sets ssthresh to half of the current window, reduces the congestion window to at most half of the previous window, and retransmits the lost packet.
3つの重複確認応答を見た後、TCPの送信者は、パケット損失を推定します。 TCPの送信者セットは現在のウィンドウの半分にSSTHRESH、前のウィンドウのほとんど半分での輻輳ウィンドウを減少させ、そして失われたパケットを再送します。
An issue that potentially affects global congestion control, and therefore would be likely to be explicitly addressed in the standards process, might include a proposal (if there was one) for inferring a lost packet after only one or two duplicate acknowledgements. If poorly designed, such a proposal could lead to an increase in the number of packets unnecessarily transmitted on a congested path.
1つまたは2つの重複確認応答の後に失われたパケットを推定するために（1があった場合）潜在的にグローバルな輻輳制御に影響を及ぼし、したがって、明示的に標準化プロセスで対処される可能性が高いだろう問題は、提案が含まれる場合があります。設計が不十分な場合には、このような提案は、不必要に混雑したパスに送信されたパケット数の増加につながる可能性があります。
An issue that has not been addressed in the standards process, and would not be expected to require standardization, would be a proposal to send a "new" or presumed-lost packet in response to a duplicate or partial acknowledgement, if allowed by the congestion window. An example of this would be sending a new packet in response to a single duplicate acknowledgement, to keep the `ack clock' going in case no further acknowledgements would have arrived. Such a proposal is an example of a beneficial change that does not involve interoperability and does not affect global congestion control, and that therefore could be implemented by vendors without requiring the intervention of the IETF standards process. (This issue has in fact been addressed in [DMKM00], which suggests that "researchers may wish to experiment with injecting new traffic into the network when duplicate acknowledgements are being received, as described in [TCPB98] and [TCPF98]."
標準化プロセスで対処されておらず、標準化を必要とすると予想されない、渋滞によって許可されている場合、重複または部分的確認応答に応じて、「新しい」または推定される失われたパケットを送信するための提案となり問題窓。この例には、さらに確認応答が到着しなかったであろう場合には行く `ACKクロック」を維持するために、単一重複確認応答に応じて、新たなパケットを送信することになります。このような提案は、相互運用性を必要としないとグローバル輻輳制御には影響しませんので、IETF標準化プロセスの介入を必要とせずに、ベンダーによって実装することができ、その有益な変化の一例です。 （この問題は、実際にことを示唆している[DMKM00]、で対処されている「研究者は[TCPF98] [TCPB98]で説明されているように、重複確認応答が受信されているネットワークに新しいトラフィックを注入することで実験することを望むかもしれません。」
Other aspects of TCP congestion control that have not been discussed in any of the sections above include TCP's recovery from an idle or application-limited period [HPF00].
上記セクションのいずれかで議論されていないTCP輻輳制御の他の態様は、アイドルまたはアプリケーション限られた期間[HPF00]からTCPの回復を含みます。
This document has been about the risks associated with congestion control, or with the absence of congestion control. Section 3.2 discusses the potentials for unfairness if competing flows don't use compatible congestion control mechanisms, and Section 5 considers the dangers of congestion collapse if flows don't use end-to-end congestion control.
この文書は、あるいは輻輳制御の欠如と輻輳制御に伴うリスクについてされています。競合フローが互換性の輻輳制御機構を使用しない場合は、セクション3.2は不公平のための電位を説明し、そしてフローは、エンドツーエンドの輻輳制御を使用しない場合、セクション5は、輻輳崩壊の危険性を考慮しています。
Because this document does not propose any specific congestion control mechanisms, it is also not necessary to present specific security measures associated with congestion control. However, we would note that there are a range of security considerations associated with congestion control that should be considered in IETF documents.
この文書は、特定の輻輳制御機構を提案していないので、輻輳制御に関連する特定のセキュリティ対策を提示することも必要ではありません。しかし、我々は、IETF文書に考慮すべき輻輳制御に関連するセキュリティ上の考慮事項の範囲があることに注意します。
For example, individual congestion control mechanisms should be as robust as possible to the attempts of individual end-nodes to subvert end-to-end congestion control [SCWA99]. This is a particular concern in multicast congestion control, because of the far-reaching distribution of the traffic and the greater opportunities for individual receivers to fail to report congestion.
例えば、個々の輻輳制御メカニズムは、エンドツーエンドの輻輳制御[SCWA99]を破壊するために、個々のエンドノードの試みに可能な限りロバストであるべきです。これは、トラフィックの遠大な分布と混雑を報告しないために、個々の受信機のための大きな機会を、マルチキャスト輻輳制御で特に懸念されます。
RFC 2309 also discussed the potential dangers to the Internet of unresponsive flows, that is, flows that don't reduce their sending rate in the presence of congestion, and describes the need for mechanisms in the network to deal with flows that are unresponsive to congestion notification. We would note that there is still a need for research, engineering, measurement, and deployment in these areas.
RFC 2309はまた、輻輳の存在下で、彼らの送信レートを低下させない流れである無応答フローのインターネットへの潜在的な危険性を議論し、混雑に応答しない流れに対処するため、ネットワーク内のメカニズムの必要性を説明します通知。我々はまだ、これらの分野における研究、工学、計測、および展開の必要性があることに注意します。
Because the Internet aggregates very large numbers of flows, the risk to the whole infrastructure of subverting the congestion control of a few individual flows is limited. Rather, the risk to the infrastructure would come from the widespread deployment of many end-nodes subverting end-to-end congestion control.
インターネットは流れの非常に大きな数字を集計しているため、いくつかの個々のフローの輻輳制御を破壊するのインフラ全体へのリスクは限られています。むしろ、インフラへのリスクは、エンドツーエンドの輻輳制御を破壊する多くのエンド・ノードの広範な展開から来ます。
AUTHOR'S ADDRESS
著者のアドレス
Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)
サリーフロイドAT＆T ICSIでのインターネット研究センター（ACIRI）
Phone: +1 (510) 642-4274 x189 EMail: floyd@aciri.org URL: http://www.aciri.org/floyd/
電話：+1（510）642-4274 x189メール：floyd@aciri.org URL：http://www.aciri.org/floyd/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。