[要約] RFC 2914は、インターネットの混雑制御の原則を定義しており、ネットワークの適切な動作を確保するためのガイドラインを提供しています。このRFCの目的は、ネットワークの過負荷を防ぎ、公平なリソースの共有を促進することです。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントの目標は、インターネットでの混雑制御の必要性を説明し、正しい混雑制御を構成するものを議論することです。特定の目標の1つは、適切な混雑制御を適用することを怠るという危険を説明することです。2番目の目標は、新しい混雑制御プロトコルの標準化における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].
このドキュメントは、以前のRFCから大きく描かれています。場合によっては、以前のドキュメントのテキストのセクション全体を再現しています[RFC2309、RFC2357]。また、エンドツーエンドの輻輳制御の必要性に対処する以前の出版物からも大幅に借りてきました[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.
エンドツーエンドの混雑制御に関するIETF標準は、特定のプロトコル（TCP [RFC2581]など、信頼性の高いマルチキャストプロトコル[RFC2357]）、または膨大なノードと混雑情報に関するルーターとルーターの間の通信の構文とセマンティクスのいずれかに焦点を当てています（E.G.、明示的な混雑通知[RFC2481]）または望ましいサービス品質（DIFF-SERV））。エンドツーエンドの輻輳制御の役割については、「インターネットでのキュー管理と混雑回避に関する推奨事項」に関する情報RFCでも説明されています[RFC2309]。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とは対照的に、このドキュメントは、混雑制御の原則に関するより一般的な議論です。インターネットの成功の鍵の1つは、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.
このドキュメントでは、差別化されたサービスまたは統合サービスの輻輳制御原則の議論は扱われていません。統合または差別化されたサービスのいくつかのカテゴリには、エンドツーエンドの帯域幅のネットワークによる保証が含まれているため、エンドツーエンドの混雑制御メカニズムは必要ありません。
3. The development of end-to-end congestion control.
3. エンドツーエンドの混雑制御の開発。
3.1. Preventing congestion collapse.
3.1. うっ血の崩壊を防ぐ。
The Internet protocol architecture is based on a connectionless end-to-end packet service using the IP protocol. The advantages of its connectionless design, flexibility and robustness, have been amply demonstrated. However, these advantages are not without cost: careful design is required to provide good service under heavy load. In fact, lack of attention to the dynamics of packet forwarding can result in severe service degradation or "Internet meltdown". This phenomenon was first observed during the early growth phase of the Internet of the mid 1980s [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] 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.
TCP [RFC793]の元の仕様には、受信者が送信者から送信されたデータの量を管理する手段として、ウィンドウベースのフロー制御が含まれていました。このフロー制御は、その接続に利用可能なレシーバーのデータバッファースペースのオーバーフローを防ぐために使用されました。[RFC793]は、エラーまたはネットワーク輻輳のいずれかのためにセグメントが失われる可能性があると報告しましたが、混雑に応じてフローコントロールウィンドウの動的調整は含まれていませんでした。
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年から、Jacobsonは、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年に、ゲートウェイがホストを「スクルチ」と誤動作する「スケルチ」を検出し、「scmpソースクエンチメッセージに応答できないことが、ホストを外すためのゲートウェイによるアクションの根拠と見なされるべきである」と提案しました。そのような障害の検出自明ではありませんが、さらなる研究には価値のある分野です。」現在の論文では、ルーターが許容可能なエンドツーエンドの混雑制御を使用していないフローを検出および罰することを提案しています[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- 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.
競合する流れの間の公平性の問題は、いくつかの理由でますます重要になっています。まず、ウィンドウスケーリング[RFC1323]を使用して、個々のTCPは、高伝播遅延パスでも高い帯域幅を使用できます。第二に、Webの成長に伴い、インターネットユーザーは、バックグラウンドで長いファイルをゆっくりと転送するのではなく、ますます高帯域幅と低遅延の通信を望んでいます。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実装の数が急増しています。これらのいくつかは、実装が不十分であるため、TCPの混雑回避メカニズムを正しく実装できない可能性があります[RFC2525]。他の人は、他の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ブラウザーが行ったように、複数の接続を同じ場所に開きます。したがって、ますます積極的な輸送プロトコルのスパイラルの代わりに、ますます攻撃的な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.) 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.
再びRFC 2309から借用すると、コンフォーマントTCPによって生成されるフローのように輻輳の下で動作するフローに「TCP互換」という用語を使用します。TCP互換の流れは輻輳通知に反応します。また、定常状態では、同等の条件（ドロップレート、RTT、MTUなど）で実行されるコンフォーマントTCPよりも帯域幅を使用しません。フローを3つのクラスに分割すると便利です。1）TCP互換の流れ、（2）無反応の流れ、つまり、うっ血が発生したときに減速しない流れ、および（3）応答性があるがTCP互換ではない流れ。最後の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.
定常状態の公平性に加えて、最初のスロースタートの公平性も懸念事項です。1つの懸念は、過度に攻撃的なスロースタート手順を備えたフローの他の流れに対する一時的な影響です。スロースタートのパフォーマンスは、短命の多くのフローにとって特に重要であり、転送するデータは少ないデータしかありません。
3.3. Optimizing performance regarding throughput, delay, and loss.
3.3. スループット、遅延、損失に関するパフォーマンスの最適化。
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.
混雑の崩壊の防止と公平性に関する懸念に加えて、エンドツーエンドの混雑制御を使用するフローの3番目の理由は、スループット、遅延、および損失に関する独自のパフォーマンスを最適化することです。たとえば、高い統計的多重化の環境では、フローが経験する遅延と損失率は、それ自体の送信率に大きく依存しています。ただし、統計的多重化のレベルが低い、またはフローごとのスケジューリングを伴う環境では、フローが経験する遅延と損失率は、フロー自身の送信速度の一部です。したがって、フローはエンドツーエンドの混雑制御を使用して、独自のパケットが経験する遅延または損失を制限できます。ただし、現在のベストエフォルトインターネットのような環境では、混雑の崩壊と競合するフローとの公平性に関する懸念は、流れが利用できる混雑制御行動の範囲を制限することに注意してください。
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の領域には、急速な再送信後のTCPの高速回復手順の詳細が含まれます[RFC2582]。付録では、TCPの例を使用して、輻輳制御の開発における標準プロセスの役割についてさらに詳しく説明します。
4.1. The development of new transport protocols.
4.1. 新しい輸送プロトコルの開発。
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."
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."
同じ宛先への複数の接続を開くブラウザの特定の問題は、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.
そのような努力の1つは、エンドポイントの混雑管理[BS00]を構築し、送信者から同じレシーバーへの複数の同時フローを可能にして、混雑制御状態を共有できることです。エンドツーエンドの混雑制御の観点から同じ宛先への複数の接続が1つのフローとして機能するようにすることにより、輻輳マネージャーは、個々の接続がゆっくりとスタートすることが、エンドツーツートゥ - の輻輳状態に関する以前の情報を利用できるようにすることができます。エンドパス。さらに、混雑マネージャーを使用すると、同じソース/宛先ペアの間に開かれている複数のフローの混雑制御危険を削除し、ブラウザが同じ宛先への多くの同時接続を開くことができるようにするために使用できます。
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リンクで競合するシナリオを使用します。すべてのノードのアクセスリンクは10 Mbpsですが、UDPフローの受信機へのアクセスリンクは128 kbpsであり、共有リンクの帯域幅の9％のみです。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.
表1. 3つのTCPフローと1つのUDPフローを備えたシミュレーション。
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 Goodput（受信機に配信される帯域幅として定義）、TCP Goodput（TCPレシーバーに配信される）、および混雑した1.5 Mbpsリンクの集合体Goodputを示しています。各レートは、混雑したリンクの帯域幅の一部として与えられます。UDPソースレートが増加すると、TCP Goodputはほぼ直線的に減少し、UDP Goodputはほぼ一定です。したがって、UDPフローが提供される負荷を増加させると、その唯一の効果はTCPを傷つけ、Goodputを集計することです。混雑したリンクでは、UDPフローは最終的にTCPフローで使用された可能性のある帯域幅を「廃棄して」、ネットワークのGoodputを、混雑したリンクの帯域幅のごく一部に減らします。
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]に配信されるというネットワークによる渋滞の崩壊を防ぐための2番目の選択肢は、ネットワークによる保証です。エンドツーエンドの混雑制御の最初の代替手段と、エンドツーエンドの帯域幅保証の2番目の代替手段の選択は、どちらかまたは決定である必要はないことに注意してください。いくつかのトラフィックによる効果的なエンドツーエンドの混雑の使用、および残りのトラフィックのためにネットワークからのエンドツーエンドの帯域幅保証の使用により、混雑の崩壊を防ぐことができます。
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）アルゴリズムに基づいて混雑制御を展開することを必要とすることを意味しません。パケットドロップ。このセクションでは、これらの2つの輻輳崩壊とTCPとの公平性のこれらの懸念の意味について個別に説明します。
6.1. End-to-end congestion control for avoiding congestion collapse.
6.1. 混雑崩壊を回避するためのエンドツーエンドの混雑制御。
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.
配達されていないパケットからの輻輳崩壊の回避には、フローが下流リンクでの高い送信速度、複数の混雑リンク、および持続的な高パケットドロップレートのシナリオを回避する必要があります。居住していないパケットからのうっ血の崩壊は、下流にのみ落とすために貴重な帯域幅を無駄にするパケットで構成されているため、各フローが1つの混雑したリンクのみを通過する環境、または少数のパケットのみがで落とされる環境では、この形式の混雑崩壊は不可能です。最初の混雑したリンクの下流のリンク。したがって、高パケットドロップレートの存在下での高い送信率を正常に回避する渋滞制御は、居住していないパケットからの混雑の崩壊を避けるのに十分なはずです。
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を使用すると、パケットマークは、中程度の混雑の時にのみパケットドロップを置き換えます。特に、混雑が重い場合、ルーターのバッファがオーバーフローする場合、ルーターは到着パケットをドロップする以外に選択肢がありません。
6.2. End-to-end congestion control for fairness with TCP.
6.2. TCPを使用した公平性のためのエンドツーエンドの混雑制御。
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.
[RFC2357]でTCPとの公平性について表明された懸念は、ベストエフォルトトラフィックのための実行可能なエンドツーエンドの混雑制御メカニズムの範囲に不自由な制約ではありませんが、重要な制約ではありません。すべての混雑したリンクでフローあたりのスケジューリングを備えた環境は、互いに流れを隔離し、渋滞制御メカニズムがTCP互換である必要性を排除します。特定のDiff-Servクラスに属しているとマークされたフローが、最良のエフォルトトラフィックから単独でスケジュールされる差別化されたサービスを備えた環境は、混雑制御が必要であった場合に、Diff-Servクラスのトラフィック全体の出現を可能にする可能性があります。TCP互換。同様に、価格制御された環境、または独自の価格設定パラダイムを備えたDiffServクラスは、TCPの公平性に関する懸念を超える可能性があります。ただし、他のベストエフォルトトラフィックがTCPトラフィックを備えたFIFOキューで競合できる現在のインターネット環境の場合、TCPとの公平性がないため、高い輻輳の時代に1つの流れを「飢star」することができます。上記の表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に直接描かれています。これは、長年、そして多くの人々によって議論されてきたアイデアの要約になることを試みています。特に、謝辞は、エンドツーエンドの研究グループ、信頼できるマルチキャスト研究グループ、および輸送エリア局のメンバーによるものです。この文書は、輸送エリアワーキンググループからの議論とフィードバックの恩恵も受けています。このドキュメントの以前のバージョンに関するフィードバックについて、Mark Allmanに特に感謝しています。
[BS00] Balakrishnan H. and S. Seshan, "The Congestion Manager", Work in Progress.
[BS00] Balakrishnan 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] Dawkins、S.、Montenegro、G.、Kojo、M。、およびV. Magret、「スローリンクのエンドツーエンドのパフォーマンスへの影響」、進行中の作業。
[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] Floyd、S。およびK. Fall、「インターネットでのエンドツーエンドの混雑制御の使用を促進する」、1999年8月、ネットワーキングに関するIEEE/ACMトランザクション。Floyd/end2end-paper.html
[HPF00] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[HPF00] Handley、M.、Padhye、J。and S. Floyd、「TCP輻輳ウィンドウの検証」、RFC 2861、2000年6月。
[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988.
[Jacobson88] V. Jacobson、混雑回避と制御、ACM Sigcomm '88、1988年8月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
[RFC896] Nagle、J。、「IP/TCPの混雑制御」、RFC 896、1984年1月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のための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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、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] 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。、およびL. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、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] Mankin、A.、Romanow、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャスト輸送およびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414] Allman、M.、Floyd、S。、およびC. Partridge、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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] Ramakrishnan K.およびS. Floyd、「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] Paxson、V.、Allman、M.、Dawson、S.、Fenner、W.、Griner、J.、Heavens、I.、Lahey、K.、Semke、J. and B. Volz、 "既知のTCP実装の問題」、RFC 2525、1999年3月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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] Floyd、S。およびT. Henderson、「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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-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. Savage、N。Cardwell、D。Wetherall、およびT. Anderson、TCP輻輳制御による誤った受信機、ACM Computer Communications Review、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] Hari Balakrishnan、Venkata N. Padmanabhan、Srinivasan Seshan、Mark Stemm、およびRandy H. Katz、忙しいインターネットサーバーのTCP動作：分析と改善、IEEE Infocom、1998年3月.cs.berkeley.edu/〜hari/papers/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.Kung、TCP高速回復戦略：分析と改善、IEEE Infocom、1998年3月。
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輻輳制御の詳細のいくつかについて説明し、それらを生産輸送プロトコルに組み込む際に発生する詳細の一部を含む、混雑制御原則の実現を説明します。
9.1. Slow-start.
9.1. スロースタート。
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よりも保守的または保守的なスロースタート動作をもたらします。
9.2. Additive Increase, Multiplicative Decrease.
9.2. 加法の増加、乗法減少。
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'.
グローバルな輻輳制御に潜在的に影響を与える可能性があるため、標準プロセスで明示的に対処される可能性が高い問題には、「純粋なアック」のリターンストリームに対する輻輳制御の提案された追加が含まれます。
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レシーバーによって注文不能なパケットを含める必要はありません。）
9.3. Retransmit timers.
9.3. タイマーを再送信します。
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を設定し、スロースタートになり、失われたパケットを再送信します。再送信パケットの謝辞が受け取られていないために再送信タイマーが期限切れになった場合、再送信タイマーも「バックオフ」され、次の再送信タイムアウト間隔の値が2倍になります。
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.
グローバルな輻輳制御に潜在的に影響を与える可能性があるため、標準プロセスで明示的に対処される可能性が高い問題には、確認が時期尚早に期限切れになった場合に、再送信タイマーの数を大幅に増やす可能性のある再送信タイマーを設定するための変更されたメカニズムが含まれる場合があります。まだ送信者に到着していませんが、実際にはパケットは削除されていません。これは、時期尚早に期限切れになるタイマーを再送信して、混雑したリンクで不必要に送信されるパケットの数の増加につながる可能性があるため、インターネット標準プロセスにとって懸念される可能性があります。
9.4. Fast Retransmit and Fast Recovery.
9.4. 迅速な再送信と迅速な回復。
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]で対処されています。これは、[TCPB98]および[TCPF98]で説明されているように、「研究者がネットワークに新しいトラフィックを注入することを試してみたいと思うかもしれません。」
9.5. Other aspects of TCP congestion control.
9.5. TCP混雑制御の他の側面。
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混雑制御の他の側面には、アイドルまたはアプリケーションに制限された期間からのTCPの回復[HPF00]が含まれます。
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)
ICSIのインターネット研究のためのSally Floyd AT＆Tセンター（Aciri）
Phone: +1 (510) 642-4274 x189
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。