[要約] RFC 5783は、RFCシリーズにおける輻輳制御に関するガイドラインを提供するものであり、要約すると以下のようになります。1. RFCシリーズにおける輻輳制御の重要性と実装方法についてのガイドラインを提供する。 2. 輻輳制御の概念と原則を明確にし、ネットワークのパフォーマンスを向上させる。 3. RFCシリーズの輻輳制御に関連するドキュメントの整理と統一を図る。
Internet Research Task Force (IRTF) M. Welzl
Request for Comments: 5783 University of Oslo
Category: Informational W. Eddy
ISSN: 2070-1721 MTI Systems
February 2010
Congestion Control in the RFC Series
RFCシリーズの混雑制御
Abstract
概要
This document is an informational snapshot taken by the IRTF's Internet Congestion Control Research Group (ICCRG) in October 2008. It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards.
このドキュメントは、2008年10月にIRTFのInternet Commestion Control Research Group（ICCRG）が撮影した情報スナップショットです。RFCシリーズのドキュメントで説明されている混雑制御トピックの調査を提供します。これは、議論されているRFCドキュメントの仕様またはステータスを変更または更新することはありません。特に現在のIETF標準のギャップやオープンな問題に注目する際に、研究グループの将来の作業の参照または出発点として使用できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Internet Congestion Control Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のインターネット輻輳制御研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5783.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5783で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architectural Documents . . . . . . . . . . . . . . . . . . . 5
3. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 9
4. Challenging Link and Path Characteristics . . . . . . . . . . 10
5. End-Host and Router Cooperative Signaling . . . . . . . . . . 12
5.1. Explicit Congestion Notification . . . . . . . . . . . . . 13
5.2. Quick-Start . . . . . . . . . . . . . . . . . . . . . . . 15
6. Non-TCP Unicast Congestion Control . . . . . . . . . . . . . . 15
7. Multicast Congestion Control . . . . . . . . . . . . . . . . . 18
8. Guidance for Developing and Analyzing Congestion Control
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Historic Interest . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . . 22
In this document, we define congestion control as the feedback-based adjustment of the rate at which data is sent into the network. Congestion control is an indispensable set of principles and mechanisms for maintaining the stability of the Internet. Congestion control has been closely associated with TCP since 1988 [Jac88], but there has also been a great deal of congestion control work outside of TCP (e.g., for real-time multimedia applications, multicast, and router-based mechanisms). Several such proposals have been produced within the IETF and published as RFCs, along with RFCs that give architectural guidance (e.g., by pointing out the importance of performing some form of congestion control). Several of these mechanisms are in use within the Internet.
このドキュメントでは、輻輳制御を、データがネットワークに送信されるレートのフィードバックベースの調整として定義します。混雑制御は、インターネットの安定性を維持するための不可欠な原則とメカニズムのセットです。混雑制御は1988年以来TCPと密接に関連してきました[JAC88]が、TCP以外では多くの混雑制御作業もありました（例：リアルタイムマルチメディアアプリケーション、マルチキャスト、ルーターベースのメカニズムなど）。IETF内でいくつかのそのような提案が作成され、RFCSとして公開され、建築ガイダンスを提供するRFCS（たとえば、何らかの形の混雑制御を実行することの重要性を指摘することによって）。これらのメカニズムのいくつかは、インターネット内で使用されています。
When designing a new Internet transport protocol, it is therefore important to not only understand how congestion control works in TCP but also have a broader understanding of the other congestion control RFCs -- some give guidance, some of them describe mechanisms that may have a direct influence on a newly designed protocol, and some of them may only be "related work" worth knowing about. The purpose of this document is to facilitate and encourage this search for knowledge by providing an overview of RFCs related to congestion control that have been published thus far. This document is a product of the IRTF's Internet Congestion Control Research Group (ICCRG). It was developed because a strong grasp of the existing literature should benefit further ICCRG work. The ICCRG developed consensus on the content of this document during a two-year development period based on review comments and ICCRG mailing list discussions. A list of the main review contributors is contained in the Acknowledgements section of this document.
したがって、新しいインターネットトランスポートプロトコルを設計する場合、混雑制御がTCPでどのように機能するかを理解するだけでなく、他の混雑制御RFCをより広く理解することも重要です。新しく設計されたプロトコルへの影響、およびそれらのいくつかは、知る価値のある「関連する作業」のみである可能性があります。このドキュメントの目的は、これまでに公開されてきた混雑制御に関連するRFCの概要を提供することにより、知識のこの検索を促進し、奨励することです。このドキュメントは、IRTFのインターネット輻輳制御研究グループ（ICCRG）の製品です。既存の文献を強く把握することで、さらなるICCRGの作業に利益をもたらすはずなので、それは開発されました。ICCRGは、レビューコメントとICCRGメーリングリストリストの議論に基づいて、2年間の開発期間中にこのドキュメントの内容に関するコンセンサスを開発しました。メインレビュー貢献者のリストは、このドキュメントの謝辞セクションに含まれています。
While the ICCRG agreed to the document's production, any opinions expressed are the authors' own, and as this document is not an IETF publication, it does not update or modify the status of any published RFCs. The format of this document is similar to an annotated bibliography. Although host and router requirements for congestion control functions are discussed, this is only an informational document and does not contain any formal standards bearing of its own.
ICCRGはドキュメントの制作に同意しましたが、表明された意見は著者自身であり、このドキュメントはIETFの出版物ではないため、公開されているRFCのステータスを更新または変更しません。このドキュメントの形式は、注釈付き参考文献に似ています。混雑制御機能のホストおよびルーターの要件については説明しますが、これは情報文書のみであり、独自の正式な基準は含まれていません。
Congestion control is a large and active topic, and so the scope of this document is limited to published RFCs and a small number of current working group drafts. This allows the document to focus on congestion control principles and mechanisms that are among the most well-supported, well-accepted, or widely used. Significant contributions to this subject also exist in both the academic literature and in the form of Internet-Drafts; however, we exclude these from this study. In many cases the RFC describing some mechanism will contain references to relevant academic publications in journals or conference proceedings that presented the research and validation of the mechanism. For instance, RFC 2581 cites Jacobson's 1988 SIGCOMM paper that has a less standards-oriented but more illustrative treatment and explanation of some of the mechanisms in RFC 2581.
混雑制御は大規模でアクティブなトピックであるため、このドキュメントの範囲は公開されているRFCと少数の現在のワーキンググループドラフトに限定されています。これにより、ドキュメントは、最もよくサポートされている、よく受け入れられている、または広く使用されている混雑制御原則とメカニズムに焦点を当てることができます。このテーマへの重要な貢献は、学術文献とインターネットドラフトの形の両方にも存在します。ただし、この研究からこれらを除外します。多くの場合、いくつかのメカニズムを説明するRFCには、メカニズムの研究と検証を提示したジャーナルまたは会議議事録に関連する学術出版物への参照が含まれます。たとえば、RFC 2581は、RFC 2581のメカニズムのいくつかの標準指向であるが、より例示的な治療と説明を持つJacobsonの1988年のSigcomm Paperを引用しています。
The majority of the documents discussed here pertain to end-host-based congestion control. Many network-based mechanisms, such as a number of queue management algorithms, do not require any protocol exchanges between elements, but merely operate within a single host or router. Thus, network-based congestion control mechanisms have often not been described in any RFC, as they generally fall under the domain of implementation details that do not influence interoperability.
ここで説明する文書の大部分は、宿主ベースの混雑制御に関係しています。多くのキュー管理アルゴリズムなど、多くのネットワークベースのメカニズムは、要素間のプロトコル交換を必要とせず、単一のホストまたはルーター内で動作するだけです。したがって、ネットワークベースの混雑制御メカニズムは、一般に相互運用性に影響を与えない実装の詳細の領域に該当するため、どのRFCでも説明されていません。
There are many RFCs related to Quality of Service (QoS), especially within the Integrated Services and Differentiated Services frameworks [RFC1633] [RFC2475] [RFC2998]. These QoS RFCs themselves deserve a similar bibliography to the one that this document provides for congestion control. We specifically do not include the vast amount of QoS work into the scope of this document, as it is a full field in its own right, and deals with issues that are mostly orthogonal to end-host congestion control and router queue management. Although there can certainly be interactions between QoS and congestion control mechanisms, scheduling mechanisms used to implement QoS (on either a per-flow or an aggregate basis), for instance, can be used independently of the end-host congestion control and queue management functions also in use. Similar arguments can be made for traffic-shaping, admission control, and other functions that are intended for QoS and are only side-notes for congestion control.
特に統合サービスフレームワークと差別化されたサービスフレームワーク[RFC1633] [RFC2475] [RFC2998]には、サービス品質（QOS）に関連する多くのRFCがあります。これらのQoS RFC自体は、このドキュメントが混雑制御を提供するものと同様の参考文献に値します。特に、このドキュメントの範囲に膨大な量のQoS作業を含めることはありません。これは、それ自体が完全な分野であり、主に在庫の輻輳制御とルーターキュー管理を主に直交する問題を扱っています。たとえば、QoSと輻輳制御メカニズムの間には確かに相互作用がありますが、QOSを実装するために使用されるスケジューリングメカニズム（総計または集計ベース）は、宿主の輻輳制御とキュー管理機能とは独立して使用できます。使用中。交通型、入場制御、およびQoS専用のその他の機能についても同様の議論を作成できます。
A similar argument can be made for excluding consideration of the media access control (MAC) layer protocols used by the links throughout a path. Although the MAC protocols implement various forms of resolving contention for shared links (and sometimes offer QoS services), these are also distinct from end-to-end congestion control. Furthermore, MAC protocols are not typically discussed in the RFC series, but they are defined in outside documents (e.g., IEEE standards), since the IETF does not generally work on link layers themselves. Few, if any, of the RFCs that describe mappings of IP onto various link layers directly discuss congestion control.
パス全体のリンクで使用されるメディアアクセス制御（MAC）レイヤープロトコルを考慮することを除外するために、同様の引数を作成できます。MACプロトコルは、共有リンクのさまざまな形式の競合を実装していますが（QoSサービスを提供することもあります）、これらはエンドツーエンドの混雑制御とは異なります。さらに、MACプロトコルは通常、RFCシリーズでは説明されていませんが、IETFは一般にリンクレイヤー自体で機能しないため、外部ドキュメント（IEEE標準など）で定義されています。IPのマッピングをさまざまなリンクレイヤーに記述するRFCのほとんどは、混雑制御を直接説明していません。
To organize the subject matter in this document, the content is classified into several broad categories. First, we list documents relating to Internet architecture and general architectural concepts in Section 2. Next, the congestion control algorithms used in the TCP transport protocol are discussed in Section 3. Interactions between link properties and mechanisms with the kinds of algorithms and heuristics used within end-to-end congestion control are covered in Section 4. One method that has been developed by the IETF (and deployed to some extent) for allowing network-based and host-based congestion control to interact without dropping packets is the subject of Section 5.1. The congestion control algorithms used by unicast transport protocols other than TCP are described in Section 6. Work on congestion control for multicast transports and applications is listed in Section 7. RFCs that give guidance to developers of new algorithms are discussed in Section 8. Finally, documents that have historic significance, but perhaps not current direct technical application, have been classified into Section 9. Note that the use of the term "historic" here has nothing to do with the IETF's formal classification of documents as having "Historic" status.
このドキュメントで主題を整理するために、コンテンツはいくつかの広範なカテゴリに分類されます。まず、セクション2のインターネットアーキテクチャと一般的なアーキテクチャの概念に関連するドキュメントをリストします。次に、TCPトランスポートプロトコルで使用される混雑制御アルゴリズムについて、セクション3で説明します。エンドツーエンドの混雑制御は、セクション4でカバーされています。IETFによって開発された1つの方法（およびある程度展開されています）は、ネットワークベースとホストベースの混雑制御がパケットをドロップせずに相互作用できるようにすることです。5.1。TCP以外のユニキャスト輸送プロトコルで使用される混雑制御アルゴリズムは、セクション6で説明されています。マルチキャストトランスポートとアプリケーションの混雑制御に関する作業は、セクション7にリストされています。歴史的な重要性を持っているが、おそらく現在の直接的な技術アプリケーションではない文書は、セクション9に分類されています。ここでの「歴史的」という用語の使用は、IETFの文書の正式な分類と「歴史的」ステータスを持っているとは関係ありません。
Some documents in this section contain architectural guidance and concerns, while others specify congestion-control-related mechanisms that are broadly applicable and have impacts on more than a single class of congestion control techniques. Some of these documents are direct products of the Internet Architecture Board (IAB), giving their guidance on specific aspects of congestion control in the Internet.
このセクションのいくつかのドキュメントには、建築のガイダンスと懸念が含まれていますが、他の文書は、広く適用可能であり、単一のクラスの混雑制御技術に影響を与える混雑コントロール関連のメカニズムを指定しています。これらのドキュメントのいくつかは、インターネットアーキテクチャボード（IAB）の直接製品であり、インターネットの混雑制御の特定の側面に関するガイダンスを提供しています。
RFC 1122: "Requirements for Internet Hosts -- Communication Layers" (October 1989)
RFC 1122：「インターネットホストの要件 - 通信レイヤー」（1989年10月）
[RFC1122] formally mandates that hosts perform congestion control. For TCP, several congestion control features are described and listed as required elements of conforming implementations, and for UDP, RFC 1122 leaves congestion control as an issue for higher-layered protocols. Although sending and reacting to ICMP Source Quench packets is no longer recommended [RFC1812] [Gont10], the rest of the congestion control guidance in this RFC is still a basis for several current practices in TCP implementations.
[RFC1122]は、ホストが混雑制御を実行することを正式に義務付けています。TCPの場合、いくつかの混雑制御機能が、適合の実装に必要な要素として説明およびリストされています。UDPの場合、RFC 1122は、高層プロトコルの問題として混雑制御を残します。ICMPソースのクエンチパケットへの送信と反応は推奨されなくなりましたが[RFC1812] [Gont10] [Gont10]、このRFCの残りの混雑制御ガイダンスは、TCP実装におけるいくつかの現在のプラクティスの基礎となっています。
RFC 1812: "Requirements for IP Version 4 Routers" (June 1995)
RFC 1812：「IPバージョン4ルーターの要件」（1995年6月）
Numerous issues relevant to router behavior are discussed in [RFC1812], and requirements for routers to support are prescribed within the document. Portions of RFC 1812 that are particularly relevant to congestion control include the directive that routers SHOULD NOT originate ICMP Source Quench messages, discussion of precedence in queueing, and Section 5.3.6 titled "Congestion Control" that recommends sizing buffers as a function of the product of the bandwidth of the link times the path delay of the flows using the link, and advises on the implementation of active queue management techniques.
ルーターの動作に関連する多くの問題が[RFC1812]で説明されており、サポートするルーターの要件がドキュメント内で規定されています。輻輳制御に特に関連するRFC 1812の一部には、ルーターがICMPソースクエンチメッセージを発信してはならないという指令、キューイングの優先順位の議論、および製品の関数としてバッファーを推奨する「うっ血制御」というタイトルのセクション5.3.6が含まれています。リンク時間の帯域幅の場合、リンクを使用してフローのパス遅延を使用し、アクティブキュー管理手法の実装についてアドバイスします。
RFC 1958: "Architectural Principles of the Internet" (June 1996)
RFC 1958：「インターネットの建築原則」（1996年6月）
Several guidelines for network systems design that have proven useful in the evolution of the Internet are sketched in [RFC1958]. Congestion control is not specifically mentioned or alluded to, but the general principles apply to congestion control. For instance, performing end-to-end functions at end nodes, lack of centralized control, heterogeneity, scalability, simplicity, avoiding options and parameters, etc., are all valid concerns in the design and assessment of congestion control schemes for the Internet.
インターネットの進化に役立つネットワークシステム設計のいくつかのガイドラインは、[RFC1958]でスケッチされています。輻輳制御は具体的に言及されていないか、暗示されていませんが、一般原則は混雑制御に適用されます。たとえば、エンドノードでエンドツーエンド関数、集中制御の欠如、不均一性、スケーラビリティ、シンプルさ、オプションやパラメーターの回避などを実行することはすべて、インターネットの混雑制御スキームの設計と評価において有効な懸念です。
RFC 2140: "TCP Control Block Interdependence" (April 1997)
RFC 2140：「TCPコントロールブロック相互依存」（1997年4月）
[RFC2140] suggests that TCP connections between the same endpoints might share some information, including their congestion control state. To some degree, this is done in practice by a few current operating systems; for example, Linux currently has a destination cache with this information, but this behavior is not yet formally standardized or recognized as a best practice by the IETF.
[RFC2140]は、同じエンドポイント間のTCP接続が、混雑制御状態を含むいくつかの情報を共有する可能性があることを示唆しています。ある程度、これはいくつかの現在のオペレーティングシステムによって実際に行われます。たとえば、Linuxには現在、この情報を使用して宛先キャッシュがありますが、この動作はまだ正式に標準化されておらず、IETFによってベストプラクティスとして認識されていません。
RFC 2309: "Recommendations on Queue Management and Congestion Avoidance in the Internet" (April 1998)
RFC 2309：「インターネットでのキュー管理と混雑回避に関する推奨事項」（1998年4月）
[RFC2309] briefly discusses the history of congestion and the origin of congestion control in the Internet. The focus is mainly on network- or router-based queue management algorithms. This RFC recommends to test, standardize, and deploy Active Queue Management (AQM) in routers; it provides an overview of one such mechanism, Random Early Detection (RED), and explains how and why AQM mechanisms can improve the performance of the Internet. Finally, this document explains the danger of a possible "congestion collapse" from unresponsive flows and makes a strong recommendation to develop and eventually deploy router mechanisms to protect the Internet from such traffic.
[RFC2309]は、インターネットにおける混雑の歴史と混雑制御の起源について簡単に説明しています。主にネットワークまたはルーターベースのキュー管理アルゴリズムに焦点が当てられています。このRFCは、ルーターでアクティブキュー管理（AQM）をテスト、標準化、展開することを推奨しています。このようなメカニズムであるランダムアーリー検出（赤）の概要を提供し、AQMメカニズムがインターネットのパフォーマンスを改善する方法と理由を説明します。最後に、このドキュメントでは、反応のないフローからの「うっ血崩壊」の危険性を説明し、そのようなトラフィックからインターネットを保護するためにルーターメカニズムを開発し、最終的に展開するための強力な推奨事項を作成します。
Today, the advice in this document has been followed to some extent. Hardware and software vendors have been receptive, and AQM techniques are widely available in many popular dedicated commercial router products and even in more general operating systems that are sometimes used as routers. However, AQM techniques may not be enabled in default configurations of these systems, and it is often left to users and network engineers to enable and configure AQM mechanisms when desired. In some cases, enabling QoS mechanisms on a device also enables AQM mechanisms by default. The number of production routers that actually have these AQM features enabled is an open question.
今日、この文書のアドバイスはある程度従っています。ハードウェアおよびソフトウェアベンダーは受容的であり、AQMテクニックは、多くの一般的な専用の商用ルーター製品や、ルーターとして使用される場合があるより一般的なオペレーティングシステムで広く利用可能です。ただし、これらのシステムのデフォルト構成ではAQM手法が有効にならない場合があり、多くの場合、ユーザーとネットワークエンジニアに任されて、必要に応じてAQMメカニズムを有効にして構成します。場合によっては、デバイスでQoSメカニズムを有効にすることも、デフォルトでAQMメカニズムを有効にします。実際にこれらのAQM機能を有効にしている生産ルーターの数は、未解決の質問です。
RFC 2914 (BCP 41): "Congestion Control Principles" (September 2000)
RFC 2914（BCP 41）：「混雑制御原則」（2000年9月）
[RFC2914] is an explanation of the principles of congestion control, and the IETF's Best Current Practice for congestion control design. It points out that there are an increasing number of applications that do not use TCP, and elaborates on the importance of performing congestion control for such traffic in order to prevent congestion collapse. The TCP Reno congestion control mechanisms are described as an example of end-to-end congestion control within transport protocols.
[RFC2914]は、輻輳制御の原則の説明であり、IETFの混雑制御設計の最良の現在のプラクティスです。TCPを使用しないアプリケーションの数が増えており、混雑の崩壊を防ぐために、そのようなトラフィックの混雑制御を実行することの重要性について詳しく説明していることを指摘しています。TCP RENO輻輳制御メカニズムは、輸送プロトコル内のエンドツーエンドの混雑制御の例として説明されています。
SCTP is one example of a non-TCP transport protocol that implements congestion control based on these principles. The developments of TFRC [RFC3448] and DCCP [RFC4340] are attempts to provide useful tools implementing those principles for applications with needs similar to streaming media, where TCP's reactions are too fast. It would be beneficial for users and the Internet itself if these carefully designed tools become widely deployed in place of other ad hoc schemes that may not be well-grounded in the congestion control principles. This replacement process is ongoing and not yet complete. Appropriate and usable congestion control schemes for non-TCP flows continue to be an open research area.
SCTPは、これらの原則に基づいて混雑制御を実装する非TCP輸送プロトコルの一例です。TFRC [RFC3448]およびDCCP [RFC4340]の開発は、TCPの反応が速すぎるストリーミングメディアと同様のニーズを持つアプリケーションの原則を実装する有用なツールを提供しようとする試みです。これらの慎重に設計されたツールが、輻輳制御原則に根拠がない他のアドホックスキームの代わりに広く展開される場合、ユーザーとインターネット自体にとって有益です。この交換プロセスは進行中であり、まだ完了していません。非TCPフローの適切で使用可能な混雑制御スキームは、引き続き開かれた研究分野であり続けています。
RFC 3124: "The Congestion Manager" (June 2001)
RFC 3124：「混雑マネージャー」（2001年6月）
[RFC3124] specifies the Congestion Manager, an end-system service that realizes congestion control on a per-host-pair rather than a per-connection basis, which may be a more appropriate way to carry out congestion control. Using the Congestion Manager, multiple streams between two hosts (which may include TCP flows) can adapt to network congestion in a unified fashion.
[RFC3124]は、接続ごとではなく、ホストあたりのペアごとの混雑制御を実現する最終システムサービスである混雑マネージャーを指定します。これは、混雑制御を実行するためのより適切な方法である可能性があります。渋滞マネージャーを使用して、2つのホスト間の複数のストリーム（TCPフローを含む場合があります）は、統一された方法でネットワーク輻輳に適応できます。
This proposal is related to RFC 2140, discussed above, but with a wider scope than TCP. Because some pieces of its supporting architecture have not yet been specified, the Congestion Manager's techniques are not commonly used today and have not been widely implemented and deployed yet beyond experimental stacks. Sharing of congestion and path information between individual connections continues to be an open research area with branches in detecting shared bottlenecks when using multiple paths, caching of old state for faster startup, and sharing of current state and feedback.
この提案は、上記で説明したRFC 2140に関連していますが、TCPよりも広い範囲があります。サポートするアーキテクチャの一部はまだ指定されていないため、輻輳マネージャーの手法は今日一般的には使用されておらず、実験スタックを超えて広く実装および展開されていません。個々の接続間の混雑とパス情報の共有は、複数のパスを使用する際に共有されたボトルネックを検出し、古い状態のキャッシングをより高速な起動、および現在の状態とフィードバックの共有を検出する枝を持つオープンな研究領域であり続けます。
RFC 3426: "General Architectural and Policy Considerations" (November 2002)
RFC 3426：「一般的な建築と政策の考慮事項」（2002年11月）
[RFC3426] lists a number of questions that can be answered for a particular technical solution to determine its architectural impact and desirability. These are valid for congestion control mechanisms, and end-point congestion management is used as an example case-study several times in RFC 3426. Two salient questions that RFC 3426 advises asking about proposed mechanisms are why they are needed in addition to existing protocols, and why they are needed at a certain layer rather than at other layers. These are particularly relevant for congestion control mechanisms since several already exist and since they can span network, transport, and application layers.
[RFC3426]は、特定の技術的なソリューションについて回答できる多くの質問をリストして、その建築的影響と望ましさを決定します。これらは輻輳制御メカニズムに有効であり、エンドポイントの混雑管理は、RFC 3426でケーススタディの例として数回使用されます。RFC3426が提案されたメカニズムについて尋ねる2つの顕著な質問は、既存のプロトコルに加えて必要な理由です。また、他のレイヤーではなく、特定のレイヤーで必要な理由。これらは、いくつかがすでに存在し、ネットワーク、トランスポート、およびアプリケーション層をスパンすることができるため、混雑制御メカニズムに特に関連しています。
RFC 3439: "Some Internet Architectural Guidelines and Philosophy" (December 2002)
RFC 3439：「いくつかのインターネットアーキテクチャガイドラインと哲学」（2002年12月）
[RFC3439] supplements RFC 1958. Simplicity is stressed, as the unpredictable results of complexity (due to amplification and coupling) are described. Congestion control issues stemming from layering interactions between transport and lower protocols are presented, as well as other items relevant to congestion control, including asymmetry and the "myth of over-provisioning".
[RFC3439] RFC 1958をサプリメントします。複雑さの予測不可能な結果（増幅と結合による）が説明されているため、シンプルさが強調されています。輸送と低いプロトコル間の相互作用の階層化に起因する混雑制御の問題は、非対称性や「過剰なプロビジョニングの神話」を含む混雑制御に関連する他の項目と同様に提示されます。
RFC 3714: "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet" (March 2004)
RFC 3714：「インターネットでの音声トラフィックの混雑制御に関するIABの懸念」（2004年3月）
[RFC3714] can be seen as a follow-up to the concerns that were discussed in RFC 2914. It expresses the IAB's concern over the lack of effective end-to-end congestion control for best-effort voice traffic, which is noted as being a current service with growing demand. An example of a VoIP connection between Atlanta, Georgia, USA, and Nairobi, Kenya, is given, where a single VoIP call consumed more than half of the access link capacity (which is normally shared across several different users). This example is used as the basis for further discussion, making it clear that using some form of congestion control for VoIP traffic is highly recommended.
[RFC3714]は、RFC 2914で議論された懸念のフォローアップと見なすことができます。需要が高まっている現在のサービス。米国ジョージア州アトランタとケニアのナイロビ間のVOIP接続の例が与えられており、1つのVoIPコールがアクセスリンク容量の半分以上を消費しました（通常、複数の異なるユーザーで共有されます）。この例は、さらなる議論の基礎として使用されており、VoIPトラフィックに何らかの形の混雑制御を使用することを強くお勧めします。
The TCP specifications found in RFC 793 and its predecessors did not contain any discussion of using or managing a congestion window. Other than a simple retransmission timeout and flow control through the advertised receive window, TCP implementations based only on RFC 793 do not contain congestion control. As several congestion collapse events occurred on the Internet, it was later realized that congestion control was needed. The host requirements in RFC 1122 require conforming TCP implementations to implement Jacobson's slow start and congestion avoidance algorithms (later specified in RFC 2001 and then RFC 2581). RFC 1122 also recommends several other behaviors that influence congestion control like the Nagle algorithm, delayed acknowledgements, Jacobson's retransmission timeout (RTO) estimation algorithm, and exponential backoff of the retransmission timer.
RFC 793とその前任者に見つかったTCP仕様には、輻輳ウィンドウの使用または管理に関する議論は含まれていませんでした。RFC 793のみに基づくTCP実装には、広告の受信ウィンドウを介した単純な再送信タイムアウトとフロー制御を除き、混雑制御は含まれていません。インターネット上でいくつかの混雑の崩壊イベントが発生したため、後に混雑制御が必要であることが認識されました。RFC 1122のホスト要件では、Jacobsonのスロースタートおよび混雑回避アルゴリズムを実装するためにTCP実装を適合させる必要があります（後にRFC 2001およびその後RFC 2581で指定）。RFC 1122は、ナグルアルゴリズム、遅延承認、ジェイコブソンの再送信タイムアウト（RTO）推定アルゴリズム、および再送信タイマーの指数バックオフなどの混雑制御に影響を与える他のいくつかの動作も推奨しています。
Basic TCP congestion control is defined in RFC 2581, with many other RFCs that specify ancillary modifications and enhancements. RFC 2581 obsoletes the first proposed standard for TCP congestion control in RFC 2001. These two RFCs document the mechanisms that had already been in common use by TCP implementations for many years. The reader may refer to the TCP Roadmap [RFC4614] for more information on the RFCs that specifically describe TCP congestion control, as this material is not replicated here.
基本的なTCP混雑制御はRFC 2581で定義されており、補助的な変更と拡張を指定する他の多くのRFCがあります。RFC 2581は、RFC 2001でTCP混雑制御のために最初に提案された標準を廃止します。これら2つのRFCは、長年にわたってTCP実装ですでに一般的に使用されていたメカニズムを文書化しています。読者は、この材料がここで複製されていないため、TCP混雑制御を特異的に説明するRFCの詳細については、TCPロードマップ[RFC4614]を参照できます。
Recently, significant effort has been put into experimental TCP congestion control modifications for obtaining high throughput with reduced startup and recovery times. RFCs have been published on some of these modifications, including HighSpeed TCP [RFC3649], and Limited Slow-Start [RFC3742], but high-rate congestion control mechanisms are still considered an open issue in congestion control research. Other schemes have been published as Internet-Drafts or have been discussed a little by the IETF, but much of the work in this area has not been adopted within the IETF yet, so the majority of this work is outside the RFC series and may be discussed in other products of the ICCRG.
最近、スタートアップと回復の時間を短縮して高スループットを取得するための実験的なTCP混雑制御修正に多大な努力が払われています。RFCは、高速TCP [RFC3649]、および限られたスロースタート[RFC3742]を含むこれらの変更のいくつかに公開されていますが、高速の輻輳制御メカニズムは依然として混雑制御研究で開かれた問題と見なされています。他のスキームはインターネットドラフトとして公開されているか、IETFによって少し議論されていますが、この分野の作業の多くはまだIETF内で採用されていないため、この作業の大部分はRFCシリーズの外であり、ICCRGの他の製品で議論されています。
At the time of writing, the IETF's TCP Maintenance and Minor Extensions (TCPM) Working Group was developing an update to RFC 2581 to incorporate small changes from other documents and advance TCP congestion control mechanisms on the IETF Standards Track. The update also clarifies and revises some points. These include the definition of a duplicate ACK, initial congestion window and slow start threshold values, behavior in response to retransmission timeouts, the use of the limited transmit mechanism, and security with regards to misbehaving receivers that practice ACK division.
執筆時点で、IETFのTCPメンテナンスとマイナーエクステンション（TCPM）ワーキンググループは、RFC 2581の更新を開発し、他のドキュメントから小さな変更を組み込み、IETF標準トラックにTCP混雑制御メカニズムを前進させました。このアップデートは、いくつかのポイントを明確にし、修正します。これらには、重複したACKの定義、初期輻輳ウィンドウと遅いスタートしきい値値、再送信タイムアウトに応じた動作、限られた送信機構の使用、およびACK部門を練習する受信者の誤動作に関するセキュリティが含まれます。
Links with large and/or variable bandwidth-delay products have traditionally been problematic for congestion control schemes because they can distort the properties of the feedback loop. Links that either expose a high rate of packet losses to the upper layers, or use highly-persistent retransmission mechanisms to prevent losses also cause problems with some of the standard congestion control mechanisms. The documents in this section discuss challenging link characteristics; many of them were written by the Performance Implications of Link Characteristics (PILC) Working Group.
大型および/または可変の帯域幅遅延製品とのリンクは、フィードバックループの特性を歪める可能性があるため、渋滞制御スキームでは伝統的に問題がありました。上層層に高い割合のパケット損失を暴露するリンク、または非常に密接な再送信メカニズムを使用して損失を防ぐリンクも、標準的な混雑制御メカニズムのいくつかに問題を引き起こします。このセクションのドキュメントでは、挑戦的なリンク特性について説明します。それらの多くは、リンク特性（PILC）ワーキンググループのパフォーマンスへの影響によって書かれていました。
While these documents often refer to specific problems with TCP, the link characteristics that they describe can be expected to affect other congestion control mechanisms too. In particular, interactions between link properties and TCP congestion control will be shared by other protocols that use the similar congestion control behavior, such as SCTP [RFC4960] and DCCP with CCID 2 [RFC4341] (see Section 6), and should be taken into consideration by designers of congestion control mechanisms that utilize the same kind of feedback as TCP.
これらのドキュメントは、多くの場合、TCPの特定の問題を指しますが、それらが説明するリンク特性は、他の混雑制御メカニズムにも影響すると予想されます。特に、LinkプロパティとTCP混雑制御間の相互作用は、SCTP [RFC4960]やDCCPなどの同様の混雑制御挙動を使用する他のプロトコルによって共有されます（セクション6を参照）。TCPと同じ種類のフィードバックを利用する混雑制御メカニズムの設計者による考慮。
Some RFCs only make recommendations regarding the implementation and configuration of TCP based upon characteristics of special links. As these RFCs are so closely connected to the specification of TCP itself, they are not included in this document, but are listed in the TCP Roadmap [RFC4614].
一部のRFCは、特別なリンクの特性に基づいてTCPの実装と構成に関する推奨事項のみを行います。これらのRFCはTCP自体の仕様に非常に密接に接続されているため、このドキュメントには含まれていませんが、TCPロードマップ[RFC4614]にリストされています。
RFC 2488 (BCP 28): "Enhancing TCP Over Satellite Channels using Standard Mechanisms" (January 1999)
RFC 2488（BCP 28）：「標準メカニズムを使用した衛星チャネル上のTCPの強化」（1999年1月）
The summary of recommendations in [RFC2488] came from the TCP over Satellite (TCPSAT) Working Group, whose goal was to identify the performance problems that TCP may have over satellite links and suggest mitigations. The document explains several ways that existing standards can be applied to improve the performance of basic TCP congestion control over paths with characteristics similar to those involving satellite links.
[RFC2488]の推奨事項の概要は、TCPを介したTCP（TCPSAT）ワーキンググループから来ました。その目標は、TCPが衛星リンクを介して抱える可能性のあるパフォーマンスの問題を特定し、緩和を示唆することでした。このドキュメントでは、既存の標準を適用して、衛星リンクを含む特性と同様の特性を持つ基本的なTCP混雑制御のパフォーマンスを改善するいくつかの方法を説明しています。
RFC 3135: "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations" (June 2001)
RFC 3135：「リンク関連の分解を緩和することを目的としたプロキシのパフォーマンス向上」（2001年6月）
[RFC3135] is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of PEPs are described as well as the mechanisms used to improve performance. While there is a specific focus on TCP in this document, PEPs can operate on any protocol, and the performance enhancements that PEPs achieve are often closely related to congestion control.
[RFC3135]は、衛星、ワイヤレスWAN、ワイヤレスLAN環境など、特定のリンク環境の特性によって引き起こされる劣化したTCPパフォーマンスを改善するためにしばしば使用されるプロキシ（PEP）のパフォーマンスを向上させる調査です。さまざまなタイプのPEPが記述され、パフォーマンスを改善するために使用されるメカニズムが説明されています。このドキュメントではTCPに特に焦点が当てられていますが、PEPSはあらゆるプロトコルで動作することができ、PEPが達成するパフォーマンスの向上は、しばしば混雑制御に密接に関連しています。
The use of PEPs has architectural implications as they sometimes violate end-to-end assumptions and can add complexity to the inner portions of a network. Certain types of PEPs are commonly used today in satellite or long-distance networking because it is easier to insert a small number of PEPs near problematic links than to upgrade the TCP implementations on all the end hosts that might use those links. One down-side is that their deployment raises some issues when introducing new or updated congestion control (CC) methods into these deployed networks, since the PEPs may be operating with undocumented algorithms, making assumptions about the end-host CC behavior, and/or altering packet fields that will affect the end-host CC behavior.
PEPの使用は、エンドツーエンドの仮定に違反することがあり、ネットワークの内部に複雑さを加えることができるため、建築的意味を持ちます。特定のタイプのPEPは、現在、衛星または長距離ネットワーキングで一般的に使用されています。これは、これらのリンクを使用する可能性のあるすべてのエンドホストのTCP実装をアップグレードするよりも、問題のあるリンクに近い少数のPEPを挿入する方が簡単だからです。ダウンサイドの1つは、PEPが文書化されていないアルゴリズムで動作し、終了HOST CCの動作について仮定を立てる可能性があるため、これらの展開されたネットワークに新しいまたは更新された混雑制御（CC）メソッドを導入する際に、展開がいくつかの問題を引き起こすことです。エンドホストCCの動作に影響するパケットフィールドの変更。
RFC 3150 (BCP 48): "End-to-end Performance Implications of Slow Links" (July 2001)
RFC 3150（BCP 48）：「スローリンクのエンドツーエンドのパフォーマンスへの影響」（2001年7月）
[RFC3150] makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. It includes a discussion of interactions between such links and TCP congestion control.
[RFC3150]は、「非常に低いビットレート」リンクを横断するネットワークパスのユーザーに、パフォーマンス関連の推奨事項を作成します。これには、そのようなリンクとTCPの混雑制御の間の相互作用の議論が含まれています。
RFC 3155 (BCP 50): "End-to-end Performance Implications of Links with Errors" (August 2001)
RFC 3155（BCP 50）：「エラーによるリンクのエンドツーエンドのパフォーマンスへの影響」（2001年8月）
Under the premise that several types of PEP have undesirable implications, [RFC3155] recommends end-to-end alternatives for improving TCP performance over paths with error-prone links.
いくつかのタイプのPEPに望ましくない意味があるという前提の下で、[RFC3155]は、エラーが発生しやすいリンクを使用してパス上のTCPパフォーマンスを改善するためのエンドツーエンドの代替案を推奨しています。
RFC 3366 (BCP 62): "Advice to link designers on link Automatic Repeat reQuest (ARQ)" (August 2002)
RFC 3366（BCP 62）：「リンク自動リピートリクエスト（ARQ）でデザイナーをリンクするためのアドバイス」（2002年8月）
Link-layer ARQ techniques are a popular means to increase the robustness of particular links to transmission errors via retransmission and acknowledgement mechanisms. As [RFC3366] explains, ARQ techniques on a link can interact poorly with TCP's end-to-end congestion control if they lead to additional delay variation or reordering. This RFC gives some advice on limiting the extent of these types of problematic interactions. The proper balance between end-to-end and link-layer reliability mechanisms is still an open research issue that has been explored in many academic papers outside the IETF.
リンク層ARQテクニックは、再送信および承認メカニズムを介して伝送エラーへの特定のリンクの堅牢性を高めるための一般的な手段です。[RFC3366]が説明するように、リンク上のARQテクニックは、追加の遅延変動または並べ替えにつながる場合、TCPのエンドツーエンドの混雑制御とは不十分に相互作用する可能性があります。このRFCは、これらのタイプの問題のある相互作用の範囲を制限することについていくつかのアドバイスを提供します。エンドツーエンドとリンク層の信頼性メカニズムの適切なバランスは、IETF以外の多くの学術論文で調査されているオープンな研究問題です。
RFC 3449 (BCP 69): "TCP Performance Implications of Network Path Asymmetry" (December 2002)
RFC 3449（BCP 69）：「ネットワークパスの非対称性のTCPパフォーマンスの影響」（2002年12月）
[RFC3449] describes performance limitations of TCP when the capacity of the ACK path is limited. Several techniques to aid TCP in these circumstances are recommended as Best Current Practices, particularly ACK congestion control and sender pacing are relevant to other non-TCP congestion control schemes, outside the scope of this document. For instance, in the design of the Reliable Multicast Transport (RMT) protocols for multicast, preventing ACK-implosion at multicast sources can be seen as a form of ACK congestion control.
[RFC3449]は、ACKパスの容量が制限されている場合のTCPのパフォーマンス制限を説明しています。これらの状況でTCPを支援するいくつかの手法は、特にACKの輻輳制御と送信者ペーシングが、このドキュメントの範囲外の他の非TCP混雑制御スキームに関連しているため、推奨されます。たとえば、マルチキャスト用の信頼性の高いマルチキャストトランスポート（RMT）プロトコルの設計では、マルチキャストソースでのACKインプロジョンを防ぐことは、ACK混雑制御の形と見なすことができます。
RFC 3481: "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks" (February 2003)
RFC 3481：「2番目（2.5g）および3番目の（3G）世代ワイヤレスネットワークを超えるTCP」（2003年2月）
Among other issues, some mobile data systems exhibit delay spikes, handovers, and bandwidth oscillation. [RFC3481] describes the problems that these conditions cause for TCP congestion control and how some TCP extensions can be used to mitigate them.
他の問題の中でも、一部のモバイルデータシステムは、遅延スパイク、ハンドオーバー、帯域幅の振動を示しています。[RFC3481]は、これらの条件がTCP混雑制御に引き起こす問題と、それらを軽減するためにTCP拡張を使用する方法を説明しています。
RFC 3819 (BCP 89): "Advice for Internet Subnetwork Designers" (July 2004)
RFC 3819（BCP 89）：「インターネットサブネットワークデザイナーへのアドバイス」（2004年7月）
Several issues in link design and optimization for carrying IP traffic are discussed in [RFC3819], which recommends Best Current Practices. Many of these principles are motivated by properties of TCP, but most of them also apply to other transport-layer congestion control techniques as well.
IPトラフィックを運ぶためのリンク設計と最適化のいくつかの問題は、[RFC3819]で議論されています。これは、最良の現在のプラクティスを推奨しています。これらの原則の多くは、TCPの特性によって動機付けられていますが、それらのほとんどは他の輸送層の混雑制御技術にも適用されます。
Some RFCs define mechanisms that allow routers to add signaling information to packets that makes the network's congestion state less of a mystery to end-host congestion controllers. Routers supporting these can signal information about the current congestion state to flows in-band, providing faster and finer-grained information than inference-based methods. Two examples of this are discussed in this section; the first directs sources to slow down in order to avoid losses, and the other assists in determining an appropriate starting rate for new flows.
一部のRFCは、ルーターがパケットにシグナリング情報を追加できるメカニズムを定義し、ネットワークの混雑状態をエンドホストの混雑コントローラーに謎に抑えます。これらをサポートするルーターは、現在の混雑状態に関する情報を帯域内に流れるように信号を送信し、推論ベースの方法よりも速くて細かい情報を提供します。この2つの例については、このセクションで説明します。最初のものは、損失を避けるために減速するようにソースを指示し、他の人は新しいフローの適切な開始率を決定するのを支援します。
Traditionally, under congestion, IP routers enqueue packets until some limit is reached, at which point packets are dropped. TCP, and other IETF transport protocols, use a stream of acknowledgements to infer these losses and take congestion control action. This section describes a more advanced way to signal congestion to sources before packet-dropping is required.
伝統的に、混雑の下で、IPルーターは、ある程度の制限に到達するまでパケットをエンキューします。その時点でパケットがドロップされていました。TCP、およびその他のIETF輸送プロトコルは、謝辞のストリームを使用してこれらの損失を推測し、混雑制御アクションを実行します。このセクションでは、パケットドロップが必要である前に、ソースへの混雑を示すより高度な方法について説明します。
There are two Explicit Congestion Notification (ECN) bits in the IP header that enable an AQM mechanism (see [RFC2309] or Section 2) to convey congestion information to endpoints without dropping packets. This can significantly reduce the losses experienced by transport endpoints if they are responsive to ECN. While ECN is most frequently discussed in the context of TCP (and therefore included in the TCP Roadmap [RFC4614]), its applicability is broader, and ECN use has also been specified for protocols such as DCCP and SCTP.
IPヘッダーには、AQMメカニズム（[RFC2309]またはセクション2を参照）を有効にする2つの明示的な輻輳通知（ECN）ビットが、パケットをドロップせずに混雑情報をエンドポイントに伝えることができます。これにより、ECNに反応する場合、輸送エンドポイントが経験する損失を大幅に削減できます。ECNはTCPのコンテキスト（したがってTCPロードマップ[RFC4614]に含まれる）で最も頻繁に説明されていますが、その適用性はより広く、ECN使用はDCCPやSCTPなどのプロトコルにも指定されています。
RFC 2481: "A Proposal to add Explicit Congestion Notification (ECN) to IP" (January 1999) - Obsoleted by RFC 3168
RFC 2481：「明示的な混雑通知（ECN）をIPに追加する提案」（1999年1月） - RFC 3168によって廃止された
[RFC2481] introduced ECN into the RFC series, describing when the Congestion Experienced (CE) bit in the IP header should be set in routers, and what modifications are needed to TCP to make it ECN-capable. It includes a discussion of issues related to nodes and routers that are non-compliant, IPsec tunnels, and dropped or corrupted packets, as well as a summary of related work. Many of these issues will also be faced by operators trying to deploy other network-based congestion control methods. RFC 2481 has been obsoleted by RFC 3168.
[RFC2481]は、ECNをRFCシリーズに導入し、IPヘッダーでの（CE）ビットをルーターに設定する必要があること、およびECN対応にするためにTCPにどのような修正が必要なかを説明しました。これには、非準拠、IPSECトンネル、ドロップまたは破損したパケットのノードとルーターに関連する問題の議論、および関連する作業の概要が含まれています。これらの問題の多くは、他のネットワークベースの混雑制御方法を展開しようとするオペレーターが直面します。RFC 2481はRFC 3168によって廃止されました。
RFC 2884: "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks" (July 2000)
RFC 2884：「IPネットワークにおける明示的な混雑通知（ECN）のパフォーマンス評価」（2000年7月）
[RFC2884] presents a performance study of ECN as specified in [RFC2481] using an implementation on the Linux operating system. The experiments focused on ECN for both bulk and transactional transfers, showing that there is improvement in throughput over TCP without ECN in the case of bulk transfers and substantial improvement for transactional transfers. Studies like this help to build the community's confidence that extensions like ECN are both safe and valuable. Similar RFCs helped the community accept larger initial windows for TCP [RFC2414] [RFC2415] [RFC2416].
[RFC2884]は、Linuxオペレーティングシステムの実装を使用して[RFC2481]で指定されているECNのパフォーマンス調査を提示します。実験は、バルク転送とトランザクション転送の両方のECNに焦点を当てており、バルク転送の場合はECNなしでTCPを超えるスループットが改善され、トランザクション転送の大幅な改善があることを示しています。このような研究は、ECNのような拡張が安全で価値があるというコミュニティの自信を構築するのに役立ちます。同様のRFCは、コミュニティがTCP [RFC2414] [RFC2415] [RFC2416]のより大きな初期ウィンドウを受け入れるのを助けました。
RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to IP" (September 2001)
RFC 3168：「明示的な混雑通知（ECN）のIPへの追加」（2001年9月）
[RFC3168], which obsoletes [RFC2481], specifies the incorporation of ECN into TCP and IP. One notable change in this significantly extended specification is the definition of a bit combination that was not defined in [RFC2481], which can be used to realize a nonce that would prevent a receiver from falsely claiming that there was no congestion. Potential issues related to ECN are discussed at length, including those already included in [RFC2481] and backwards compatibility with implementations that would follow the specification in the obsoleted document.
[RFC3168]は、[RFC2481]を廃止し、ECNのTCPおよびIPへの取り込みを指定します。この大幅に拡張された仕様の1つの顕著な変更は、[RFC2481]で定義されていないビットの組み合わせの定義です。これは、受信者が輻輳がないと誤って主張することを妨げる非CEを実現するために使用できます。ECNに関連する潜在的な問題は、[RFC2481]にすでに含まれているものや、廃止されたドキュメントの仕様に従う実装との後方互換性を含む、長々と議論されています。
ECN, as specified in RFC 3168, is implemented in several popular router and end-host platforms. It is in active use, to at least some extent. Problems with ECN "blackholes" (Internet routers misconfigured to discard packets with ECN-capable bits set) were discovered when ECN was enabled by default in some end-host operating systems. Fears about the persisting presence of these blackholes currently may be keeping ECN from being used by default in many end-host operating systems even though it is implemented as an option within them. Some measurements on ECN support and usability are available [PF01] [MAF04] [MAF05].
RFC 3168で指定されているECNは、いくつかの一般的なルーターおよびエンドホストプラットフォームに実装されています。少なくともある程度は、積極的に使用されています。ECNの「ブラックホール」の問題（ECN対応ビットセットでパケットを破棄するために誤解されたインターネットルーター）が、一部のエンドホストオペレーティングシステムでECNがデフォルトで有効になったときに発見されました。現在、これらのブラックホールの持続的な存在についての恐怖は、それらがオプションとして実装されているにもかかわらず、多くのエンドホストオペレーティングシステムでデフォルトでECNを使用しないようにしている可能性があります。ECNサポートと使いやすさに関するいくつかの測定値が利用可能です[PF01] [MAF04] [MAF05]。
RFC 3540: "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" (June 2003)
RFC 3540：「堅牢な明示的な混雑通知（ECN）ノンセスによるシグナル伝達」（2003年6月）
[RFC3540] specifies a nonce mechanism that uses an ECN bit combination that is not used in [RFC2481], but that is specified in [RFC3168] to allow a one-bit ECN nonce. This nonce mechanism includes a Nonce Sum (NS) field in the TCP header so that senders can ensure that ACKs that do not indicate congestion are credible. The mechanism improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.
[RFC3540]は、[RFC2481]では使用されていないが[RFC3168]で指定されているECNビットの組み合わせを使用して、1ビットECN NonCEを許可するNonCEメカニズムを指定します。この非CEメカニズムには、TCPヘッダーにNonCe Sum（NS）フィールドが含まれているため、送信者は混雑を示さないACKが信頼できることを確認できます。このメカニズムは、受信機がECNを悪用してネットワーク帯域幅の不公平なシェアを獲得することを防ぐことにより、混雑制御の堅牢性を改善します。
This nonce technique is not understood to have been widely implemented or deployed, and there has been some discussion as to whether the mechanism is really effective or is the best use of these bits (see emails to the IETF Transport Area Working Group (TSVWG) mailing list, in the thread "ECN nonce snag in TCP ESTATS MIB" from December 2006 - January 2007, or [MBJ07]).
このNonCE技術は広く実装または展開されているとは理解されておらず、メカニズムが本当に効果的であるか、これらのビットの最良の使用法であるかについて議論がありました（IETFトランスポートエリアワーキンググループ（TSVWG）郵送へのメールを参照してください2006年12月から2007年1月、または[MBJ07]）のスレッド「ECN Nonce Snag in TCP Estats Mib」のリスト。
RFC 4782: "Quick-Start for TCP and IP" (January 2007)
RFC 4782：「TCPとIPのクイックスタート」（2007年1月）
Quick-Start provides a way for hosts to ask routers to help them select an initial sending rate, and use this rate rather than the traditional small initial congestion window and slow-start algorithm. [RFC4782] describes the Quick-Start mechanism and its use with TCP. In addition to discussing the benefits of Quick-Start, the document also discusses several limitations of the Quick-Start technique with respect to some types of tunnels in use over the Internet today and other potential costs of Quick-Start including those related to router design. Analysis of the effects of misbehaving entities and appendices containing design rationale and related work are also notably present in this RFC.
Quick-Startは、ホストがルーターに初期の送信率を選択するのに役立つように依頼する方法を提供し、従来の小さな初期混雑ウィンドウとスロースタートアルゴリズムではなく、このレートを使用します。[RFC4782]は、クイックスタートメカニズムとTCPでのその使用について説明しています。クイックスタートの利点について議論することに加えて、このドキュメントでは、今日のインターネットで使用されているいくつかのタイプのトンネルに関するクイックスタート手法のいくつかの制限と、ルーター設計に関連するものを含むクイックスタートのその他の潜在的なコストについても説明します。。このRFCには、設計の理論的根拠と関連する作業を含む誤動作エンティティと付録の影響の分析も顕著です。
Many of the issues discussed in RFC 4782, including router architecture, network design / tunnels, and misbehaving agents are all challenges relevant to other proposals that try to add router assistance into the network. The consideration of these issues can be illustrative for other protocol designers, even if they are not interested in Quick-Start itself.
ルーターアーキテクチャ、ネットワーク設計 /トンネル、不正行為エージェントなど、RFC 4782で議論されている問題の多くはすべて、ネットワークにルーター支援を追加しようとする他の提案に関連する課題です。これらの問題の考慮は、たとえクイックスタート自体に興味がない場合でも、他のプロトコル設計者にとって説明することができます。
In the past, TCP dominated Internet traffic, as it was used for many of the popular applications (email, web browsing, file transfer, remote login, etc.). The majority of early congestion control work focused on TCP, and the introduction of congestion control into TCP alone is often credited with saving the Internet from additional congestion collapse events. Today, TCP has been joined by other transport protocols (e.g., custom UDP-based protocols, SCTP, DCCP, RTP over UDP [RFC3550], etc.), and so having properly functioning congestion control within these other protocols is important for the Internet's health (as explained in RFC 3714, for instance, or see the discussion of the "congestion control arms race" scenario in RFC 2914). Documents that describe unicast congestion control methods for non-TCP transport protocols have been grouped into this section.
過去には、TCPは多くの一般的なアプリケーション（電子メール、Webブラウジング、ファイル転送、リモートログインなど）に使用されていたため、インターネットトラフィックを支配していました。初期の輻輳制御作業の大部分はTCPに焦点を当てており、TCP単独への輻輳制御の導入は、追加の混雑崩壊イベントからインターネットを保存したことが多いことがよくあります。今日、TCPは他の輸送プロトコル（例：カスタムUDPベースのプロトコル、SCTP、DCCP、RTPをUDPよりも[RFC3550]など）が結合しているため、これらの他のプロトコル内で適切に機能する混雑制御がインターネットにとって重要です。健康（たとえばRFC 3714で説明されているように、またはRFC 2914の「混雑制御武器競争」シナリオの議論を参照）。非TCP輸送プロトコルのユニキャスト輻輳制御方法を説明するドキュメントは、このセクションにグループ化されています。
RFC 4960: "Stream Control Transmission Protocol" (September 2007)
RFC 4960：「ストリーム制御伝送プロトコル」（2007年9月）
SCTP congestion control is very similar to TCP with Selective Acknowledgements, but there are some differences, as described in Section 7.1 of [RFC4960]. The major difference lies in the fact that SCTP supports multihoming, whereas TCP does not. Thus, SCTP keeps a different set of congestion control parameters for each destination address within an association, whereas TCP only keeps a single set of congestion control parameters per connection.
SCTPの混雑制御は、選択的な確認を伴うTCPに非常に似ていますが、[RFC4960]のセクション7.1で説明されているように、いくつかの違いがあります。主な違いは、SCTPがマルチホームをサポートしているのに対し、TCPはそうではないという事実にあります。したがって、SCTPは、関連性内の各宛先アドレスの異なる輻輳制御パラメーターのセットを保持しますが、TCPは接続ごとに1つの輻輳制御パラメーターのみを保持します。
RFC 5348: "TCP Friendly Rate Control (TFRC): Protocol Specification" (September 2008)
RFC 5348：「TCPフレンドリーレートコントロール（TFRC）：プロトコル仕様」（2008年9月）
[RFC5348], which obsoletes [RFC3448], specifies TCP-Friendly Rate Control (TFRC), a rate-based congestion control mechanism for unicast flows operating in a best-effort Internet environment where flows are competing with standard TCP traffic. TFRC ensures conformance with TCP by continuously calculating the rate that a TCP sender would obtain under similar circumstances using a slightly simplified version of the TCP Reno throughput equation in [PFTK98]. Its sending rate is smoother than the rate of TCP, making it suitable for multimedia applications. TFRC is not a wire protocol but rather a mechanism that could, for instance, be used within a UDP-based application, in a transport protocol such as RTP, or in the context of endpoint congestion management [RFC3124].
[RFC5348]は、廃止された[RFC3448]は、フローが標準的なTCPトラフィックと競合する最高のインターネット環境で動作するユニキャストフローのレートベースの混雑制御メカニズムであるTCPフレンドリーレートコントロール（TFRC）を指定しています。TFRCは、[PFTK98]のTCP RENOスループット方程式のわずかに単純化されたバージョンを使用して、TCP送信者が同様の状況下で得る速度を継続的に計算することにより、TCPへの適合を保証します。送信率はTCPのレートよりもスムーズであるため、マルチメディアアプリケーションに適しています。TFRCはワイヤプロトコルではなく、たとえば、UDPベースのアプリケーション内、RTPなどの輸送プロトコル、またはエンドポイント輻輳管理のコンテキストで使用できるメカニズムです[RFC3124]。
RFC 3550: "RTP: A Transport Protocol for Real-Time Applications" (July 2003)
RFC 3550：「RTP：リアルタイムアプリケーション用の輸送プロトコル」（2003年7月）
[RFC3550] specifies the real-time transport protocol RTP along with its control protocol RTCP. RTP/RTCP does not prescribe a specific congestion control behavior, but it is recommended that such a behavior be specified in each RTP profile (which is due to the fact that the potential for reducing the sending rate is often content dependent in the case of real-time streams). Specifically, [RFC3550] states: "For some profiles, it may be sufficient to include an applicability statement restricting the use of that profile to environments where congestion is avoided by engineering. For other profiles, specific methods such as data rate adaptation based on RTCP feedback may be required". [RFC4585], which discusses RTCP feedback and adaptation mechanisms, points out that RTCP feedback may operate on much slower timescales than transport layer feedback mechanisms, and that additional mechanisms are therefore required to perform proper congestion control. One way to make use of such additional mechanisms is to run RTP over DCCP.
[RFC3550]は、制御プロトコルRTCPとともにリアルタイムトランスポートプロトコルRTPを指定します。RTP/RTCPは特定の輻輳制御挙動を規定していませんが、各RTPプロファイルでそのような動作を指定することをお勧めします（これは、送信率を減らす可能性は、実際の場合にコンテンツに依存することが多いためです。 - タイムストリーム）。具体的には、[RFC3550]は次のように述べています。「一部のプロファイルについては、そのプロファイルの使用をエンジニアリングによって回避する環境にそのプロファイルを制限するアプリケーションステートメントを含めるだけで十分かもしれません。他のプロファイルでは、RTCPに基づくデータレート適応などの特定の方法フィードバックが必要になる場合があります」。RTCPフィードバックと適応メカニズムを議論する[RFC4585]は、RTCPフィードバックが輸送層フィードバックメカニズムよりもはるかに遅いタイムスケールで動作する可能性があり、したがって適切な混雑制御を実行するために追加のメカニズムが必要であることを指摘しています。このような追加のメカニズムを利用する1つの方法は、DCCPを介してRTPを実行することです。
RFC 4336: "Problem Statement for the Datagram Congestion Control Protocol (DCCP)" (March 2006)
RFC 4336：「データグラムの輻輳制御プロトコル（DCCP）の問題声明」（2006年3月）
[RFC4336] provides the motivation leading to the design of DCCP. In doing so, other possibilities of implementing similar functionality are discussed, including unreliable extensions of SCTP, RTP-based congestion control, and providing congestion control above or below UDP.
[RFC4336]は、DCCPの設計につながる動機を提供します。そうすることで、SCTPの信頼できない拡張、RTPベースの混雑制御、UDPの上または下の輻輳制御を提供するなど、同様の機能を実装する他の可能性について説明します。
RFC 4340: "Datagram Congestion Control Protocol" (March 2006)
RFC 4340：「データグラムの混雑制御プロトコル」（2006年3月）
[RFC4340] specifies DCCP, the Datagram Congestion Control Protocol. This protocol provides bidirectional unicast connections of congestion-controlled unreliable datagrams. It is suitable for applications that can benefit from control over the tradeoff between timeliness and reliability. The core DCCP specification does not include a specific congestion control behavior; rather, it functions as a framework for such mechanisms, which can be selected via the Congestion Control Identifier (CCID).
[RFC4340]は、データグラムの輻輳制御プロトコルであるDCCPを指定します。このプロトコルは、輻輳制御された信頼性のないデータグラムの双方向ユニキャスト接続を提供します。適時性と信頼性の間のトレードオフを制御することで利益を得ることができるアプリケーションに適しています。コアDCCP仕様には、特定の混雑制御挙動は含まれません。むしろ、それはそのようなメカニズムのフレームワークとして機能します。これは、輻輳制御識別子（CCID）を介して選択できます。
RFC 4341: "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control" (March 2006)
RFC 4341：「データグラムの輻輳制御プロトコル（DCCP）混雑制御ID 2：TCPのような混雑制御のプロファイル」（2006年3月）
[RFC4341] is the specification of TCP-like congestion control within DCCP. This should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. ECN is also supported within RFC 4341.
[RFC4341]は、DCCP内のTCP様輻輳制御の仕様です。これは、急速に変化する条件を備えた環境で利用可能な帯域幅を活用したいと考えている送信者が使用する必要があり、TCPの加法増加マルチリピア的減少（AIMD）混雑制御に典型的な輻輳ウィンドウの急激な変化に適応することができます。。ECNはRFC 4341内でもサポートされています。
RFC 4342: "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)" (March 2006)
RFC 4342：「データグラムの輻輳制御プロトコル（DCCP）混雑制御ID 3：TCPフレンドリーレートコントロール（TFRC）のプロファイル」（2006年3月）
[RFC4342] is the specification of TFRC congestion control as described in [RFC3448] for DCCP. This should be used by senders who want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.
[RFC4342]は、DCCPの[RFC3448]に記載されているTFRC混雑制御の仕様です。これは、急激なレートの変更を最小限に抑えながら、おそらく明示的な混雑通知（ECN）を使用して、TCPフレンドリーの送信率を必要とする送信者が使用する必要があります。
In the IETF, congestion control for multicast (one-to-many) communication has primarily been tackled in the Reliable Multicast Transport (RMT) Working Group. Except for [RFC2357] and [RFC3208], all the documents in this section were written by this group. Since a "one size fits all" protocol cannot meet the requirements of all possible applications in this space, the approach taken is a modular one, consisting of "protocol cores" and "building blocks". Multiple congestion control building blocks have been defined, providing both sender-driven and receiver-driven congestion control methods that differ widely in their assumptions and behavior.
IETFでは、マルチキャスト（1対多）コミュニケーションの混雑制御が、主に信頼性の高いマルチキャストトランスポート（RMT）ワーキンググループで取り組んでいます。[RFC2357]および[RFC3208]を除き、このセクションのすべての文書はこのグループによって書かれました。「1つのサイズに適合する」プロトコルは、このスペースのすべての可能なアプリケーションの要件を満たすことができないため、「プロトコルコア」と「ビルディングブロック」で構成されるアプローチはモジュール式のアプリケーションです。複数の輻輳制御ビルディングブロックが定義されており、その仮定と行動が大きく異なる、送信者主導型と受信者駆動型の混雑制御方法の両方を提供します。
RFC 2357: "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols" (June 1998)
RFC 2357：「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」（1998年6月）
Some early multicast content dissemination proposals did not incorporate proper congestion control; this is pointed out as being a severe mistake in [RFC2357], as large-scale multicast applications have the potential to do vast congestion-related damage. This document clearly makes the case that congestion control mechanisms should be developed and incorporated into multicast content dissemination protocols intended for use over the Internet.
いくつかの初期のマルチキャストコンテンツ普及提案には、適切な混雑制御が組み込まれていませんでした。これは、[RFC2357]の深刻な間違いであると指摘されています。これは、大規模なマルチキャストアプリケーションには大きな混雑関連の損害を与える可能性があるためです。このドキュメントは、混雑制御メカニズムを開発し、インターネットで使用することを目的としたマルチキャストコンテンツ普及プロトコルに組み込む必要があると明らかにしています。
RFC 2887: "The Reliable Multicast Design Space for Bulk Data Transfer" (August 2000)
RFC 2887：「バルクデータ転送用の信頼できるマルチキャスト設計スペース」（2000年8月）
Several classes of potential congestion control schemes for single-sender multicast protocols are briefly sketched as possibilities, but no specific protocols are developed or selected in [RFC2887].
シングルセンダーマルチキャストプロトコルの潜在的な混雑制御スキームのいくつかのクラスは、可能性として簡単にスケッチされていますが、[RFC2887]で特定のプロトコルが開発または選択されていません。
RFC 3048: "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer" (January 2001)
RFC 3048：「1対Many Bulk-Data転送用の信頼性の高いマルチキャスト輸送ビルディングブロック」（2001年1月）
[RFC3048] discusses the building block approach to RMT protocols and mentions that several different congestion control building blocks may be required in order to deal with different situations. Some of the possible interactions between building blocks for congestion control and those for Forward Error Correction (FEC), acknowledgement, and group management are also mentioned.
[RFC3048]は、RMTプロトコルへのビルディングブロックアプローチについて説明し、さまざまな状況に対処するためにいくつかの異なる混雑制御ビルディングブロックが必要になる場合があると述べています。混雑制御のためのビルディングブロックと前方エラー補正（FEC）、謝辞、およびグループ管理との間の可能な相互作用のいくつかも言及されています。
RFC 3208: "PGM Reliable Transport Protocol Specification" (December 2001)
RFC 3208：「PGM信頼できる輸送プロトコル仕様」（2001年12月）
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. As discussed in [RFC3208]'s Appendix B, a PGM protocol source can request congestion control feedback from both network elements (routers) and receivers (end hosts). These reports can indicate the load on the worst link in a particular path, or the load on the worst path. The actual procedure used in response to this feedback is not part of RFC 3208, but the notion of using multicast routers to assist in congestion control is significant.
実用的な一般的なマルチキャスト（PGM）は、複数のソースから複数の受信機への順序付けまたは順序のない、重複していないマルチキャストデータ配信を必要とするアプリケーション向けの信頼性の高いマルチキャストトランスポートプロトコルです。[RFC3208]の付録Bで説明したように、PGMプロトコルソースは、ネットワーク要素（ルーター）と受信機（エンドホスト）の両方からの輻輳制御フィードバックを要求できます。これらのレポートは、特定のパスの最悪のリンクの負荷、または最悪のパスの負荷を示すことができます。このフィードバックに応じて使用される実際の手順は、RFC 3208の一部ではありませんが、輻輳制御を支援するためにマルチキャストルーターを使用するという概念は重要です。
RFC 3450: "Asynchronous Layered Coding (ALC) Protocol Instantiation" (December 2002)
RFC 3450：「非同期層コーディング（ALC）プロトコルインスタンス化」（2002年12月）
[RFC3450] specifies ALC, a rough header format using the RMT building blocks, that can be used by multicast content dissemination protocols. ALC is intended to use a multi-rate congestion control building block, where the sender does not require any feedback, but where multiple multicast groups with different transmission rates are available within and ALC session, and receivers control their rates by joining or leaving groups.
[RFC3450]は、マルチキャストコンテンツ普及プロトコルで使用できるRMTビルディングブロックを使用した大まかなヘッダー形式であるALCを指定します。ALCは、送信者がフィードバックを必要とせず、さまざまな伝送レートを持つ複数のマルチキャストグループがALCセッション内で利用できる複数のマルチキャストグループを使用し、受信機がグループに参加または去ることでレートを制御する場合、多額の混雑制御制御ビルディングブロックを使用することを目的としています。
RFC 3738: "Wave and Equation Based Rate Control (WEBRC) Building Block" (April 2004)
RFC 3738：「波と方程式ベースのレートコントロール（WEBRC）ビルディングブロック」（2004年4月）
The WEBRC mechanism defined in [RFC3738] is a receiver-driven form of congestion control, where each receiver in a multicast group can determine the individual rate at which packets are delivered to it. WEBRC senders create a base channel for control information and several multicast channels for data transmission that each send packets at a varying rate in the form of a wave. The receivers dynamically join and leave channels at chosen points within the wave of sending rates to obtain the desired overall receive rate based on an equation using the estimated loss probability and round-trip time within an epoch. WEBRC is compatible for use within ALC.
[RFC3738]で定義されているWEBRCメカニズムは、受信機駆動型の混雑制御であり、マルチキャストグループの各受信機がパケットが配信される個々のレートを決定できます。WeBRC送信者は、制御情報用のベースチャネルと、各パケットを波の形でさまざまな速度で送信するデータ送信用のいくつかのマルチキャストチャネルを作成します。受信機は、エポック内の推定損失確率と往復時間を使用した方程式に基づいて、送信レートの波の中で選択されたポイントで選択されたポイントでチャネルを結合して出発します。WeBRCは、ALC内での使用に互換性があります。
RFC 4654: "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification" (August 2006)
RFC 4654：「TCPフレンドリーマルチキャスト混雑制御（TFMCC）：プロトコル仕様」（2006年8月）
TFMCC, as described in [RFC4654], is a sender-driven congestion control mechanism, where the received rate for the entire multicast group is determined by the worst-connected receiver. TFMCC builds upon TFRC, but scales down the feedback to prevent ACK-implosion effects by having receivers suppress their feedback unless they perceive it to be the worst among the reception group.
[RFC4654]に記載されているように、TFMCCは送信者主導の混雑制御メカニズムであり、マルチキャストグループ全体の受信率は最悪の接続レシーバーによって決定されます。TFMCCはTFRCに基づいていますが、受信機が受信グループの中で最悪であると認識しない限り、受信機にフィードバックを抑制させることにより、ACKインプロシオン効果を防ぐためにフィードバックを縮小します。
Some recently published RFCs discuss the properties of congestion control protocols that are "safe" for Internet deployment, as well as how to measure the properties of congestion control mechanisms and transport protocols. These documents are particularly relevant to the ICCRG as some of the group's activities involve reviewing congestion control proposals that have been brought to the IETF for publication (see http://www.ietf.org/iesg/statement/congestion-control.html).
最近公開されたRFCは、インターネットの展開に「安全」な混雑制御プロトコルの特性と、混雑制御メカニズムと輸送プロトコルの特性を測定する方法について議論しています。これらのドキュメントは、グループの活動の一部が発行のためにIETFに提起された混雑制御提案のレビューをレビューするため、ICCRGに特に関連しています（http://www.ietf.org/iesg/statement/congestion-control.htmlを参照）。
RFC 5033 (BCP 133): "Specifying New Congestion Control Algorithms" (August 2007)
RFC 5033（BCP 133）：「新しい混雑制御アルゴリズムの指定」（2007年8月）
The concurrent development of multiple TCP modifications for high-rate use and the deployments of these modifications on the Internet prompted [RFC5033] to be written. RFC 5033 comes from the Transport Area Working Group (TSVWG), and gives guidance on the classes of Experimental RFC that can be published to document algorithms that are either encouraged for investigation on the Internet, and those that are only encouraged for experimentation in less-critical environments. It has been described as a list of things for people to think about when creating new congestion control techniques that they are planning to widely deploy.
高速使用のための複数のTCP変更の同時開発とインターネット上のこれらの変更の展開により、[RFC5033]が書かれるようになりました。RFC 5033は、輸送エリアワーキンググループ（TSVWG）からのものであり、インターネット上での調査のために奨励されているアルゴリズムと、実験のみでのみ奨励されているアルゴリズムを文書化するために公開できる実験RFCのクラスに関するガイダンスを提供します。重要な環境。これは、人々が広く展開することを計画している新しい混雑制御技術を作成する際に考えるべきもののリストとして説明されています。
RFC 5166: "Metrics for the Evaluation of Congestion Control Mechanisms" (March 2008)
RFC 5166：「混雑制御メカニズムの評価のためのメトリック」（2008年3月）
The IRTF Transport Modeling Research Group (TMRG) produced [RFC5166] to describe the set of metrics and related tradeoffs between metrics that can be used to compare, contrast, and evaluate congestion control techniques. This RFC gives an overview of many such metrics, and gives references to their detailed descriptions.
IRTFトランスポートモデリング研究グループ（TMRG）は[RFC5166]を生成し、混雑制御技術を比較、対照、評価するために使用できるメトリック間のメトリックと関連するトレードオフのセットを説明しました。このRFCは、そのような多くのメトリックの概要を示し、それらの詳細な説明への参照を提供します。
Early in the RFC series, there are many documents that represent an author's thoughts on a subject or brief summaries from measurement and experimentation, rather than the result of a long formal IETF process. Some of the RFCs listed in this section have this distinction.
RFCシリーズの初期には、長い正式なIETFプロセスの結果ではなく、測定と実験からの主題または簡単な要約に関する著者の考えを表す多くのドキュメントがあります。このセクションにリストされているRFCの一部には、この区別があります。
RFC 889: "Internet Delay Experiments" (December 1983)
RFC 889：「インターネット遅延実験」（1983年12月）
Based on reported measurement experiments, changes to the TCP retransmission timeout (RTO) calculation are suggested in [RFC0889]. It is noted that the original TCP RTO calculation leads to congestion when a delay spike occurs because it takes too long for the RTO to adapt, leading to superfluous retransmissions.
報告された測定実験に基づいて、[RFC0889]では、TCP再送信タイムアウト（RTO）計算の変更が示唆されています。RTOが適応するのに時間がかかりすぎて、余分な再送信につながるため、遅延スパイクが発生すると、元のTCP RTO計算が輻輳につながることに注意してください。
RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984)
RFC 896：「IP/TCPインターネットワークスの混雑制御」（1984年1月）
[RFC0896] is the first document known to the authors where the term "congestion collapse" was used. Here, it refers to the stable state that was observed when a sudden load on the net caused the round-trip time to rise faster than the sending hosts measured round-trip time could be updated. Two problems are discussed: the "small-packet problem" (now commonly known by the name "silly window syndrome") and the "source-quench problem", which is about inappropriately deciding when to send and how to react to ICMP Source Quench messages. Solutions for these problems are presented.
[RFC0896]は、「うっ血崩壊」という用語が使用された著者に知られている最初の文書です。ここでは、ネット上の突然の負荷が往復時間を測定した往復往復時間を更新できるよりも速く上昇すると観察された安定した状態を指します。2つの問題について説明します：「小パケットの問題」（現在は「愚かなウィンドウ症候群」という名前で知られています）と「ソースクエンチの問題」。メッセージ。これらの問題の解決策が提示されています。
RFC 970: "On Packet Switches with Infinite Storage" (December 1985)
RFC 970：「無限のストレージ付きパケットスイッチ上」（1985年12月）
Using a thought experiment based on a router with infinite buffering capacity, [RFC0970] develops a different kind of congestion collapse scenario, where few useful packet transmissions occur due to the queue being longer than the time-to-live of the packets within it. As described in RFC 970, this scenario was also demonstrated using real equipment by the author.
無限バッファリング容量を持つルーターに基づく思考実験を使用して、[RFC0970]は、キューがその中のパケットの時間よりも長いために有用なパケット送信が発生しない異なる種類の混雑崩壊シナリオを開発します。RFC 970で説明されているように、このシナリオは、著者による実際の機器を使用して実証されました。
The document also includes discussion of game-theoretic analysis of congestion control and obtaining fairness between behaving and non-behaving flows, by focusing on the order of scheduling packets within the buffer rather than the actual allocation of buffer space between flows.
このドキュメントには、フロー間のバッファースペースの実際の割り当てではなく、バッファー内のパケットのスケジューリングの順序に焦点を当てることにより、輻輳制御のゲーム理論分析と動作と非避難フローの間の公平性の取得についても説明します。
RFC 1016: "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)" (July 1987)
RFC 1016：「ホストがソースクエンチでできること：ソースクエンチは遅延を導入した（squid）」（1987年7月）
[RFC1016] outlines a rate-based congestion control mechanism where end-hosts use Source Quench packets from routers to adjust their sending rates. RFC 1016 also suggests sending congestion notifications before queues are actually full, at a rate that increases with the current queue occupancy. This strategy has been used in several other AQM mechanisms, notably RED [FJ93].
[RFC1016]は、エンドホストがルーターからソースクエンチパケットを使用して送信レートを調整するレートベースの混雑制御メカニズムの概要を示します。RFC 1016は、現在のキュー占有率とともに増加するレートで、キューが実際に満たされる前に混雑通知を送信することも提案しています。この戦略は、他のいくつかのAQMメカニズム、特に赤[FJ93]で使用されています。
RFC 1254: "Gateway Congestion Control Survey" (August 1991)
RFC 1254：「Gateway comping Control Survey」（1991年8月）
[RFC1254] is a survey of congestion control approaches in routers that first discusses general congestion control performance goals (such as fairness), and then elaborates on the use of Source Quench messages (which are now discouraged, as they have been found ineffective), Random Drop (which would now be called "Active Queue Management"), Congestion Indication (DEC Bit; an early form of ECN), "Selective Feedback Congestion Indication" (one particular method for applying ECN), and Fair Queuing. Finally, end-system congestion control policies are discussed, including Jacobson's well-known algorithms [Jac88] and their predecessor -- "CUTE" [Jain86].
[RFC1254]は、一般的な混雑制御パフォーマンスの目標（公平性など）を最初に議論し、ソースクエンチメッセージの使用について詳しく説明するルーターの混雑制御アプローチの調査であり、その後、それらは今では不可能であると発見されているように）、ランダムドロップ（現在は「アクティブキュー管理」と呼ばれます）、混雑表示（DECビット、ECNの初期形式）、「選択的フィードバック鬱血指示」（ECNを適用するための特定の方法）、および公正なキューイング。最後に、ジェイコブソンのよく知られたアルゴリズム[JAC88]やその前身である「かわいい」[Jain86]など、最終システムの混雑制御ポリシーが議論されています。
This document introduces no new security considerations. Each RFC listed in this document discusses the security considerations of the specification it contains.
このドキュメントでは、新しいセキュリティ上の考慮事項は紹介されていません。このドキュメントにリストされている各RFCは、含まれる仕様のセキュリティに関する考慮事項について説明します。
Several participants in the ICCRG contributed useful comments in the development of this document, including Rex Buddenberg, Mitchell Erblichs, Lachlan Andrew, Sally Floyd, Stephen Farrell, Gorry Fairhurst, Lars Eggert, Mark Allman, and Juergen Schoenwaelder.
ICCRGの数人の参加者は、Rex Buddenberg、Mitchell Erblichs、Lachlan Andrew、Sally Floyd、Stephen Farrell、Gorry Fairhurst、Lars Eggert、Mark Allman、Juergen Schoenwaelderなど、この文書の開発に有用なコメントを提供しました。
[FJ93] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, volume 1, number 4, August 1993.
[FJ93] Floyd、S。およびV. Jacobson、「混雑回避のためのランダムな早期検出ゲートウェイ」、IEEE/ACMトランザクション、1993年8月4日、第4巻、第4巻。
[Gont10] Gont, F., "ICMP attacks against TCP", Work in Progress, January 2010.
[Gont10] Gont、F。、「TCPに対するICMP攻撃」、2010年1月、進行中の作業。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of ACM SIGCOMM 1988, in ACM Computer Communication Review, 18 (4), pp. 314-329.
[Jac88] Jacobson、V。、「混雑回避と管理」、ACM Sigcomm 1988の議事録、ACMコンピューター通信レビュー、18（4）、pp。314-329。
[Jain86] Jain, R., "A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks", IEEE Journal on Selected Areas in Communications, volume 4, number 7, October 1986.
[Jain86] Jain、R。、「ウィンドウフロー制御ネットワークのタイムアウトベースの混雑制御スキーム」、Communicationsの選択されたエリアに関するIEEEジャーナル、第4巻、1986年10月。
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proceedings of the Internet Measurement Conference 2004, August 2004.
[MAF04] Medina、A.、Allman、M。、およびS. Floyd、「輸送プロトコルとミドルボックス間の相互作用の測定」、2004年8月、インターネット測定会議の議事録。
[MAF05] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communications Review, volume 35, issue 2, April 2005.
[MAF05] Medina、A.、Allman、M。、およびS. Floyd、「インターネットでの輸送プロトコルの進化の測定」、ACM Computer Communications Review、Volume 35、Issue 2、2005年4月。
[MBJ07] Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Allow Senders to Identify Receiver Non-Compliance", Work in Progress, November 2007.
[MBJ07] Moncaster、T.、Briscoe、B。、およびA. Jacquet、「送信者が受信者の不遵守を特定できるようにするTCPテスト」、2007年11月、進行中の作業。
[PF01] Padhye, J. and S. Floyd, "On Inferring TCP Behavior", Proceedings of ACM SIGCOMM 2001, August 2001.
[PF01] Padhye、J。およびS. Floyd、「TCP行動の推測について」、ACM Sigcomm 2001の議事録、2001年8月。
[PFTK98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proceedings of ACM SIGCOMM 1998.
[PFTK98] Padhye、J.、Firoiu、V.、Towsley、D。、およびJ. Kurose、「モデリングTCPスループット：単純なモデルとその経験的検証」、ACM Sigcomm 1998の議事録。
[RFC0889] Mills, D., "Internet delay experiments", RFC 889, December 1983.
[RFC0889]ミルズ、D。、「インターネット遅延実験」、RFC 889、1983年12月。
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC0896] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
[RFC0970] Nagle, J., "On packet switches with infinite storage", RFC 970, December 1985.
[RFC0970] Nagle、J。、「無限ストレージ付きパケットスイッチ上」、RFC 970、1985年12月。
[RFC1016] Prue, W. and J. Postel, "Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)", RFC 1016, July 1987.
[RFC1016] Prue、W。and J. Postel、「ホストがソースクエンチでできること：ソースクエンチは遅延を導入した」、RFC 1016、1987年7月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control Survey", RFC 1254, August 1991.
[RFC1254] Mankin、A。およびK. Ramakrishnan、「Gateway commestion Control Survey」、RFC 1254、1991年8月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633] Braden、B.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[RFC2001] Stevens、W。、「TCPスロースタート、混雑回避、高速再送信、および高速回復アルゴリズム」、RFC 2001、1997年1月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140] Touch、J。、「TCP制御ブロック相互依存」、RFC 2140、1997年4月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309] Braden、B.、Clark、D.、Crowcroft、J.、Davie、B.、Deering、S.、Estrin、D.、Floyd、S.、Jacobson、V.、Minshall、G.、Partridge、C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357] Mankin、A.、Romanov、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月。
[RFC2415] Poduri, K., "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415] Poduri、K。、「初期TCPウィンドウサイズの増加に関するシミュレーション研究」、RFC 2415、1998年9月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416] Shepard、T。およびC. Partridge、「TCPが3つのバッファーに4つのパケットから始まるとき」、RFC 2416、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月。
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[RFC2488] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP輻輳制御」、RFC 2581、1999年4月。
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", RFC 2884, July 2000.
[RFC2884] Hadi Salim、J。およびU. Ahmed、「IPネットワークにおける明示的な混雑通知（ECN）のパフォーマンス評価」、RFC 2884、2000年7月。
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2887] Handley、M.、Floyd、S.、Whetten、B.、Kermode、R.、Vicisano、L。、およびM. Luby、「バルクデータ転送用の信頼できるマルチキャスト設計スペース」、RFC 2887、2000年8月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998] Bernet、Y.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J。、およびEFelstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、RFC 2998、2000年11月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124] Balakrishnan、H。およびS. Seshan、「ザ・ミッシェンマネージャー」、RFC 3124、2001年6月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3135] Border、J.、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の劣化を緩和することを目的としたプロキシを向上させるパフォーマンス」、RFC 3135、2001年6月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150] Dawkins、S.、Montenegro、G.、Kojo、M。、およびV. Magret、「スローリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 48、RFC 3150、2001年7月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155] Dawkins、S.、Montenegro、G.、Kojo、M.、Magret、V。、およびN. Vaidya、「エラーとリンクのエンドツーエンドのパフォーマンスの影響」、BCP 50、RFC 3155、2001年8月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208] Speakman、T.、Crowcroft、J.、Gemmell、J.、Farinacci、D.、Lin、S.、Leshchiner、D.、Luby、M.、Montgomery、T.、Rizzo、L.、Tweedly、A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R。、およびL. Vicisano、「PGM信頼できる輸送プロトコル仕様」、RFC 3208、2001年12月。
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[RFC3366] Fairhurst、G。およびL. Wood、「Link Automatic Repeat Request（ARQ）でデザイナーをリンクするアドバイス」、BCP 62、RFC 3366、2002年8月。
[RFC3426] Floyd, S., "General Architectural and Policy Considerations", RFC 3426, November 2002.
[RFC3426]フロイド、S。、「一般的な建築と政策の考慮事項」、RFC 3426、2002年11月。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439] Bush、R。およびD. Meyer、「いくつかのインターネットアーキテクチャガイドラインと哲学」、RFC 3439、2002年12月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449] Balakrishnan、H.、Padmanabhan、V.、Fairhurst、G。、およびM. Sooriyabandara、「ネットワークパス非対称性のTCPパフォーマンスの影響」、BCP 69、RFC 3449、2002年12月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 3450、2002年12月。
[RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", BCP 71, RFC 3481, February 2003.
[RFC3481]イナムラ、H。、モンテネグロ、G。、ルートヴィヒ、R.、ガルトフ、A。、およびF.カフィゾフ、「2番目（2.5g）および3番目（3g）の生成ワイヤレスネットワークを超えるTCP」、BCP 71、RFC3481、2003年2月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.
[RFC3649] Floyd、S。、「大きな渋滞窓用の高速TCP」、RFC 3649、2003年12月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714] Floyd、S。およびJ. Kempf、「IABは、インターネットでの音声トラフィックの混雑制御に関する懸念」、RFC 3714、2004年3月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738] Luby、M。およびV. Goyal、「波と方程式ベースのレート制御（WEBRC）ビルディングブロック」、RFC 3738、2004年4月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004.
[RFC3742] Floyd、S。、「大規模な混雑窓を備えたTCPの限定スロースタート」、RFC 3742、2004年3月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J.、およびL. Wood、「アドバイス」アドバイスインターネットサブネットワークデザイナー向け」、BCP 89、RFC 3819、2004年7月。
[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement for the Datagram Congestion Control Protocol (DCCP)", RFC 4336, March 2006.
[RFC4336] Floyd、S.、Handley、M。、およびE. Kohler、「Datagram輻輳制御プロトコル（DCCP）の問題ステートメント」、RFC 4336、2006年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（DCCP）混雑制御ID 2：TCP様渋滞制御」、RFC 4341、2006年3月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342] Floyd、S.、Kohler、E。、およびJ. Padhye、「データグラムの混雑制御プロトコル（DCCP）混雑制御IDのプロファイル：TCPフレンドリーレートコントロール（TFRC）」、RFC 4342、2006年3月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、2006年7月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614] Duke、M.、Braden、R.、Eddy、W。、およびE. Blanton、「伝送制御プロトコルのロードマップ（TCP）仕様文書」、RFC 4614、2006年9月。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006.
[RFC4654] Widmer、J。およびM. Handley、「TCPフレンドリーマルチキャスト輻輳制御（TFMCC）：プロトコル仕様」、RFC 4654、2006年8月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782] Floyd、S.、Allman、M.、Jain、A。、およびP. Sarolahti、「TCPとIPのクイックスタート」、RFC 4782、2007年1月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, August 2007.
[RFC5033] Floyd、S。およびM. Allman、「新しい混雑制御アルゴリズムの指定」、BCP 133、RFC 5033、2007年8月。
[RFC5166] Floyd, S., "Metrics for the Evaluation of Congestion Control Mechanisms", RFC 5166, March 2008.
[RFC5166] Floyd、S。、「混雑制御メカニズムの評価のためのメトリック」、RFC 5166、2008年3月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 5348、2008年9月。
Authors' Addresses
著者のアドレス
Michael Welzl University of Oslo Department of Informatics PO Box 1080 Blindern N-0316 Oslo, Norway
マイケル・ウェルズル・オスロ大学情報学部PO Box 1080 Blindern N-0316 OSLO、ノルウェー
Phone: +47 22 85 24 20
EMail: michawe@ifi.uio.no
Wesley M. Eddy MTI Systems NASA Glenn Research Center 21000 Brookpark Rd, MS 500-ASRC Cleveland, OH 44135
Wesley M. Eddy MTI Systems NASA Glenn Research Center 21000 Brookpark Rd、MS 500-ASRC Cleveland、OH 44135
Phone: (216) 433-6682 EMail: wes@mti-systems.com
電話：（216）433-6682メール：wes@mti-systems.com