Internet Engineering Task Force (IETF) M. Duke, Ed.
Request for Comments: 9743 Google LLC
BCP: 133 G. Fairhurst, Ed.
Obsoletes: 5033 University of Aberdeen
Category: Best Current Practice March 2025
ISSN: 2070-1721
RFC 5033 discusses the principles and guidelines for standardizing new congestion control algorithms. This document obsoletes RFC 5033 to reflect changes in the congestion control landscape by providing a framework for the development and assessment of congestion control mechanisms, promoting stability across diverse network paths. This document seeks to ensure that proposed congestion control algorithms operate efficiently and without harm when used in the global Internet. It emphasizes the need for comprehensive testing and validation to prevent adverse interactions with existing flows.
RFC 5033は、新しい混雑制御アルゴリズムを標準化するための原則とガイドラインについて説明します。このドキュメントは、RFC 5033を廃止して、混雑制御メカニズムの開発と評価のためのフレームワークを提供し、多様なネットワークパス全体の安定性を促進することにより、混雑制御環境の変化を反映しています。このドキュメントは、提案された輻輳制御アルゴリズムが、グローバルなインターネットで使用すると効率的に、そして危害を受けないように動作するようにすることを目指しています。既存のフローとの不利な相互作用を防ぐための包括的なテストと検証の必要性を強調しています。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9743.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9743で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Specification of Requirements
3. Guidelines for Authors
3.1. Evaluation Guidelines
3.2. Document-Status Guidelines
4. Specifying Algorithms for Use in Controlled Environments
5. Evaluation Criteria
5.1. Single Algorithm Behavior
5.1.1. Protection Against Congestion Collapse
5.1.2. Protection Against Bufferbloat
5.1.3. Protection Against High Packet Loss
5.1.4. Fairness Within the Proposed Congestion Control
Algorithm
5.1.5. Short Flows
5.2. Mixed Algorithm Behavior
5.2.1. Existing General-Purpose Congestion Control
5.2.2. Real-Time Congestion Control
5.2.3. Short and Long Flows
5.3. Other Criteria
5.3.1. Differences with Congestion Control Principles
5.3.2. Incremental Deployment
6. General Use
6.1. Paths with Tail-Drop Queues
6.2. Tunnel Behavior
6.3. Wired Paths
6.4. Wireless Paths
7. Special Cases
7.1. Active Queue Management (AQM)
7.2. Operation with the Envelope Set by Network Circuit Breakers
7.3. Paths with Varying Delay
7.4. Internet of Things and Constrained Nodes
7.5. Paths with High Delay
7.6. Misbehaving Nodes
7.7. Extreme Packet Reordering
7.8. Transient Events
7.9. Sudden Changes in the Path
7.10. Multipath Transport
7.11. Data Centers
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Changes Since RFC 5033
Acknowledgments
Contributors
Authors' Addresses
This document provides guidelines for the IETF to use when evaluating a proposed congestion control algorithm that differs from the general congestion control principles outlined in [RFC2914]. The guidance is intended to be useful to authors proposing congestion control algorithms and for the IETF community when evaluating whether a proposal is appropriate for publication in the RFC Series and for deployment in the Internet.
このドキュメントは、[RFC2914]で概説されている一般的な輻輳制御原則とは異なる提案された輻輳制御アルゴリズムを評価するときに使用するIETFのガイドラインを提供します。このガイダンスは、RFCシリーズでの公開やインターネットでの展開に提案が適切かどうかを評価する際に、混雑制御アルゴリズムを提案する著者やIETFコミュニティにとって有用であることを目的としています。
This document obsoletes [RFC5033], which was published in 2007 as a Best Current Practice for evaluating proposed congestion control algorithms for publication in Experimental or Proposed Standard RFCs.
このドキュメントは、実験または提案された標準RFCで公開するための提案された輻輳制御アルゴリズムを評価するための最良の現在の慣行として2007年に公開されました。
The IETF specifies standard Internet congestion control algorithms in the RFC Series. These congestion control algorithms can suffer performance challenges when used in differing environments (e.g., high-speed networks, cellular and Wi-Fi wireless technologies, and long-distance satellite links), and also when flows carry specific workloads (e.g., Voice over IP (VoIP), gaming, and videoconferencing).
IETFは、RFCシリーズの標準的なインターネット輻輳制御アルゴリズムを指定します。これらの混雑制御アルゴリズムは、異なる環境（例えば、高速ネットワーク、セルラーおよびWi-Fiワイヤレステクノロジー、長距離衛星リンク）で使用されると、パフォーマンスの課題に苦しむ可能性があります。
When [RFC5033] was published, TCP [RFC9293] was the primary focus of IETF congestion control efforts, with proposals typically discussed within the Internet Congestion Control Research Group (ICCRG). Concurrently, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was developed to define new congestion control algorithms for datagram traffic, while the Stream Control Transmission Protocol (SCTP) [RFC9260] reused TCP congestion control algorithms.
[RFC5033]が公開されたとき、TCP [RFC9293]はIETFの混雑管理努力の主要な焦点であり、インターネット輻輳制御研究グループ（ICCRG）で通常議論されている提案がありました。同時に、データグラムの混雑制御プロトコル（DCCP）[RFC4340]は、データグラムトラフィックの新しい輻輳制御アルゴリズムを定義するために開発されました。
Since then, several changes have occurred. The range of protocols utilizing congestion control algorithms has expanded to include QUIC [RFC9000] and RTP Media Congestion Avoidance Techniques (RMCAT) (e.g., [RFC8836]). Additionally, some alternative congestion control algorithms have been tested and deployed at scale without full IETF review. There is increased interest in specialized use cases, such as data centers (e.g., [RFC8257]), and in supporting a variety of upper-layer protocols and applications, such as real-time protocols. Moreover, the community has gained significant experience with congestion indications beyond packet loss.
それ以来、いくつかの変更が発生しています。うっ血制御アルゴリズムを利用しているプロトコルの範囲は、QUIC [RFC9000]およびRTPメディアの混雑回避技術（RMCAT）を含むように拡張されています（例：[RFC8836]）。さらに、いくつかの代替輻輳制御アルゴリズムがテストされ、完全なIETFレビューなしで規模で展開されています。データセンターなどの専門化されたユースケース（[RFC8257]など）や、リアルタイムプロトコルなどのさまざまな上層層プロトコルとアプリケーションのサポートに関心が高まっています。さらに、コミュニティは、パケットの損失を超えた混雑の適応症の重要な経験を積んでいます。
Multicast congestion control is a considerably less mature field of study and is not in the scope of this document. However, Section 4 of [RFC8085] provides additional guidelines for multicast and broadcast usage of UDP.
マルチキャストの混雑制御は、成熟した研究分野ではなく、この文書の範囲内ではありません。ただし、[RFC8085]のセクション4では、UDPのマルチキャストおよびブロードキャスト使用に関する追加のガイドラインを提供しています。
Congestion control algorithms have been developed outside of the IETF, including at least two that saw large scale deployment. These include CUBIC [HRX08] and Bottleneck Bandwidth and Round-trip propagation time (BBR) [BBR].
大規模な展開を見た少なくとも2つを含む、IETFの外側に輻輳制御アルゴリズムが開発されました。これらには、Cubic [HRX08]とボトルネックの帯域幅と往復伝播時間（BBR）[BBR]が含まれます。
CUBIC was documented in a research publication in 2008 [HRX08], and was then adopted as the default congestion control algorithm for the TCP implementation in Linux. It was already used in a significant fraction of TCP connections over the Internet before being documented in an Internet-Draft in 2015, and published as an Informational RFC in 2017 as [RFC8312] and then as a Proposed Standard in 2023 [RFC9438].
Cubicは2008年の研究出版物[HRX08]に文書化され、その後、LinuxでのTCP実装のデフォルトの混雑制御アルゴリズムとして採用されました。2015年にインターネットドラフトで文書化される前に、インターネット上のTCP接続のかなりの部分ですでに使用されており、2017年に[RFC8312]として情報RFCとして公開され、2023年に提案された基準[RFC9438]として公開されていました。
At the time of writing, BBR is being developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016. BBR was described in an Internet-Draft in 2018 and was first presented in the IRTF Internet Congestion Control Research Group. It has since been regularly updated to document the evolving versions of the algorithm [BBR]. BBR is currently widely used for Google services using either TCP or QUIC and is also widely deployed outside of Google.
執筆時点で、BBRはGoogleによって内部研究プロジェクトとして開発されており、最初の実装は2016年にLinux Kernel 4.19に貢献しました。BBRは2018年にインターネットドラフトで説明され、IRTFインターネット渋滞管理研究グループで最初に発表されました。それ以来、アルゴリズム[BBR]の進化するバージョンを文書化するために定期的に更新されています。BBRは現在、TCPまたはQUICを使用してGoogleサービスに広く使用されており、Google以外でも広く展開されています。
We cannot say whether the original authors of [RFC5033] expected that developers would be waiting for IETF review before widely deploying a new congestion control algorithm over the Internet, but the examples of CUBIC and BBR illustrate that deployment of new algorithms is not, in fact, gated by the publication of the algorithm as an RFC.
[RFC5033]の元の著者が、開発者がインターネット上に新しい混雑制御アルゴリズムを広く展開する前にIETFのレビューを待っていると予想しているかどうかは言えませんが、キュービックとBBRの例は、新しいアルゴリズムの展開が実際にRFCとしてのアルゴリズムの出版によって認められていないことを示しています。
Nevertheless, a specification for a congestion control algorithm provides a number of advantages:
それにもかかわらず、輻輳制御アルゴリズムの仕様は、多くの利点を提供します。
* It can help implementers, operators, and other interested parties develop a shared understanding of how the algorithm works and how it is expected to behave in various scenarios and configurations.
* 実装者、オペレーター、およびその他の利害関係者が、アルゴリズムの仕組みと、さまざまなシナリオや構成でどのように動作するかについての共通の理解を開発するのに役立ちます。
* It can help potential contributors understand the algorithm, which can make it easier for them to suggest improvements and/or identify limitations. Furthermore, the specification can help multiple contributors align on a consensus change to the algorithm.
* 潜在的な貢献者がアルゴリズムを理解するのに役立ちます。これにより、改善を示唆したり、制限を特定したりすることが容易になります。さらに、この仕様は、複数の貢献者がアルゴリズムへのコンセンサスの変更に合わせて整合するのに役立ちます。
* It can help (by being accessible to anyone) to circumvent the issue that some implementers may be unable to read open-source reference implementations due to the constraints of some open-source licenses.
* 一部のオープンソースライセンスの制約のために、一部の実装者がオープンソースの参照実装を読み取れない可能性があるという問題を回避するのに役立ちます（誰でもアクセスできます。
Beyond helping develop specific algorithm proposals, guidelines can also serve as a reminder to potential inventors and developers of the multiple facets of the congestion control problem.
特定のアルゴリズムの提案の開発を支援するだけでなく、ガイドラインは、混雑制御問題の複数の側面の潜在的な発明者や開発者へのリマインダーとしても役立ちます。
The evaluation guidelines in this document are intended to be consistent with the congestion control principles from [RFC2914] related to preventing congestion collapse, considering fairness, and optimizing a flow's own performance in terms of throughput, delay, and loss. [RFC2914] also discusses the goal of avoiding a congestion control "arms race" among competing transport protocols.
このドキュメントの評価ガイドラインは、混雑の崩壊の防止、公平性を考慮し、スループット、遅延、および損失の観点からフローのパフォーマンスを最適化することに関連する[RFC2914]の輻輳制御原則と一致することを目的としています。[RFC2914]は、競合する輸送プロトコルの間での混雑制御「武器競争」を回避するという目標についても説明しています。
This document does not give hard-and-fast requirements for an appropriate congestion control algorithm. Rather, the document provides a set of criteria that should be considered and weighed by the developers of alternative algorithms and by the IETF in the context of each proposal.
このドキュメントでは、適切な輻輳制御アルゴリズムに関するハードとファストの要件は提供されません。むしろ、このドキュメントは、各提案のコンテキストで、代替アルゴリズムの開発者とIETFによって考慮され、計量する必要がある一連の基準を提供します。
The high-order criterion for advancing any proposal within the IETF is a serious scientific study of the pros and cons that occur when the proposal is considered for publication by the IETF or before it is deployed at a large scale.
IETF内で提案を進めるための高次の基準は、提案がIETFによって公開されることとみなされたときまたは大規模に展開される前に発生する長所と短所の深刻な科学的研究です。
After initial studies, authors are encouraged to write a specification of their proposal for publication in the RFC Series. This allows others to understand and investigate the wealth of proposals in this space.
最初の研究の後、著者はRFCシリーズに掲載する提案の仕様を書くことをお勧めします。これにより、他の人はこの分野での豊富な提案を理解し、調査することができます。
This document is intended to reduce the barriers to entry for new congestion control work to the IETF. As such, proponents of new congestion control algorithms ought not to interpret these criteria as a checklist of requirements before approaching the IETF. Instead, proponents are encouraged to think about these issues beforehand and have the willingness to do the work implied by the remainder of this document.
このドキュメントは、IETFへの新しい混雑制御作業のエントリへの障壁を減らすことを目的としています。そのため、新しい輻輳制御アルゴリズムの支持者は、IETFにアプローチする前に、これらの基準を要件のチェックリストとして解釈するべきではありません。代わりに、支持者はこれらの問題について事前に考え、この文書の残りの部分で暗示される仕事をする意欲を持っていることが奨励されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document does not provide specific evaluation methods, short of Internet-scale deployment and measurement, to test the criteria described below. There are multiple possible approaches to evaluation. Each has a role, and the most appropriate approach depends on the criteria being evaluated and the maturity of the specification.
このドキュメントでは、以下に説明する基準をテストするために、インターネット規模の展開と測定に及ぶ特定の評価方法を提供しません。評価には複数の可能なアプローチがあります。それぞれに役割があり、最も適切なアプローチは、評価される基準と仕様の成熟度に依存します。
For many algorithms, an initial evaluation will consider individual protocol mechanisms in a simulator to analyze their stability and safety across a wide range of conditions, including overload. For example, [RFC8869] describes evaluation test cases for interactive real-time media over wireless networks. Such results could also be published or discussed in IRTF research groups, such as ICCRG and MAPRG.
多くのアルゴリズムでは、初期評価では、シミュレータ内の個々のプロトコルメカニズムを考慮して、過負荷を含む幅広い条件にわたって安定性と安全性を分析します。たとえば、[RFC8869]は、ワイヤレスネットワークを介したインタラクティブなリアルタイムメディアの評価テストケースについて説明しています。このような結果は、ICCRGやMAPRGなどのIRTF研究グループで公開または議論することもできます。
Before a proposed congestion control algorithm is published as an Experimental or Standards Track RFC, the community SHOULD gain practical experience with implementations and experience using the algorithm. Implementations by independent teams can help provide assurance that a specification has avoided assumptions or ambiguity. An independent evaluation by multiple teams helps provide assurance that the design meets the evaluation criteria and can assess typical interactions with other traffic. This evaluation could use an emulated laboratory environment or a controlled experiment (within a limited domain or at Internet scale). When a working group is trying to decide if a proposed specification is ready for publication, it will normally consider evidence of results. This ought to be documented in any request from the working group to publish the specification.
提案された輻輳制御アルゴリズムがRFCを追跡する実験的または標準的なアルゴリズムとして公開される前に、コミュニティはアルゴリズムを使用して実装と経験の実践的な経験を積む必要があります。独立したチームによる実装は、仕様が仮定または曖昧さを回避したという保証を提供するのに役立ちます。複数のチームによる独立した評価は、設計が評価基準を満たし、他のトラフィックとの典型的な相互作用を評価できるという保証を提供するのに役立ちます。この評価では、エミュレートされた実験室環境または制御された実験を使用できます（限られたドメイン内またはインターネットスケール内）。ワーキンググループが、提案された仕様が公開の準備ができているかどうかを決定しようとしている場合、通常、結果の証拠を検討します。これは、仕様を公開するために、ワーキンググループからのリクエストに文書化する必要があります。
A congestion control algorithm without multiple implementations might still be published as an RFC if a single implementation is widely used, open source, and shown to have a positive impact on the Internet, particularly if the target status is Experimental.
単一の実装が広く使用され、オープンソースであり、特にターゲットステータスが実験的である場合、インターネットにプラスの影響を与えることが示されている場合、複数の実装のない混雑制御アルゴリズムがRFCとして公開される場合があります。
The guidelines in this document apply to specifications of congestion control algorithms that seek publication as an RFC via the IETF Stream with an Experimental or Standards Track status. The evaluation of either status involves the same questions, but with different expectations for both the answers and the degree of certainty of those answers.
このドキュメントのガイドラインは、実験または標準のトラックステータスを備えたIETFストリームを介してRFCとして公開を求める輻輳制御アルゴリズムの仕様に適用されます。いずれかのステータスの評価には、同じ質問が含まれますが、答えとそれらの回答の確実性の程度の両方に異なる期待があります。
Specifications of congestion control algorithms without empirical evidence of Internet-scale deployment MUST seek Experimental status, unless they are not targeted for general use. Algorithms not targeted at general use do not require Internet-scale data.
インターネット規模の展開の経験的証拠のない輻輳制御アルゴリズムの仕様は、一般的な使用をターゲットにされていない限り、実験的なステータスを求める必要があります。一般的に使用されないアルゴリズムは、インターネットスケールのデータを必要としません。
Specifications that seek to be published as Experimental IETF Stream RFCs ought to explain the reason for the status and what further information would be required to progress to a Standards Track RFC. For example, Section 12 of [RFC6928] provides "Usage and Deployment Recommendations" that describe the experiments expected by the TCPM Working Group. Section 4 of [RFC7414] provides other examples of extensions that were considered experimental when the specification was published.
実験的なIETFストリームRFCとして公開されようとする仕様は、ステータスの理由と、RFCを追跡する標準の進行に必要なさらなる情報を説明する必要があります。たとえば、[RFC6928]のセクション12は、TCPMワーキンググループが期待する実験を説明する「使用と展開の推奨」を提供します。[RFC7414]のセクション4では、仕様が公開されたときに実験的と見なされた拡張機能の他の例を示します。
Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being actively measured and where it is possible to deactivate them if there are signs of pathological behavior.
実験仕様をデフォルトとして展開しないでください。それらは、積極的に測定されている状況でのみ展開され、病理学的行動の兆候がある場合はそれらを無効にすることができる場合にのみ展開する必要があります。
Specifications of congestion control algorithms with a record of measured Internet-scale deployment MAY directly seek Standards Track status if there is solid data that reflects that the algorithm is safe and the design is stable, guided by the considerations in Section 6. However, the existence of this data does not waive the other considerations in this document.
測定されたインターネットスケールの展開のレコードを使用した輻輳制御アルゴリズムの仕様は、アルゴリズムが安全であり、セクション6の考慮事項によって導かれていることを反映している強固なデータがある場合、標準追跡状態を直接探すことができます。ただし、このデータの存在はこの文書の他の考慮事項を放棄しません。
Each specification submitted for publication as an RFC is REQUIRED to include a statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is considered safe for use on the Internet. Each such specification is also REQUIRED to include a statement in the abstract describing environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorithm is deemed safe for use, but it is still not recommended for use because it does not perform well for the user.
RFCとして公開のために提出された各仕様は、提案された輻輳制御アルゴリズムがインターネットでの使用に安全であると見なされるというIETFコンセンサスがあるかどうかを示す抽象に声明を含める必要があります。そのような各仕様は、プロトコルが展開に推奨されない環境を説明する抽象的な声明にステートメントを含める必要があります。輻輳制御アルゴリズムが安全であるとみなされる環境がある場合がありますが、ユーザーにとってはうまく機能しないため、使用することは推奨されません。
Examples of such statements exist in [RFC3649], which specifies HighSpeed TCP and includes a statement in the abstract stating that the proposed congestion control algorithm is experimental but may be deployed in the Internet. In contrast, the Quick-Start document [RFC4782] includes a paragraph in the abstract stating that the mechanism is only being proposed for use in controlled environments. The abstract specifies environments where the Quick-Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward but do not process the option). The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment is not recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start. The Quick-Start method is discussed as an example in [RFC9049].
このようなステートメントの例は[RFC3649]に存在します。これは、高速TCPを指定し、提案された輻輳制御アルゴリズムは実験的であるがインターネットに展開される可能性があることを示す抽象的な声明を含んでいます。対照的に、クイックスタートドキュメント[RFC4782]には、メカニズムが制御された環境でのみ使用するためにのみ提案されていることを示す抽象的な段落が含まれています。要約は、クイックスタートリクエストが誤検知を与える可能性がある環境を指定します（したがって、いくつかのルーターが前方に進むがオプションを処理しない場合、増分展開には安全ではありません）。要約は、クイックスタートリクエストを含むパケットをネットワークで削除できる環境も指定しています。このような環境では、クイックスタートは展開するのに安全ではありませんが、クイックスタートを使用しようとする接続の不必要な遅延につながる可能性があるため、展開は推奨されません。クイックスタートメソッドは、[RFC9049]の例として説明されています。
Strictly speaking, documents for publication as Informational RFCs from the IETF Stream need not meet all of the criteria in this document, as they do not carry a formal recommendation from the IETF community. Instead, the community judges the publication of these Informational RFCs based on the value of their addition to the information captured by the RFC Series.
厳密に言えば、IETFストリームの情報RFCとしての公開のドキュメントは、IETFコミュニティからの正式な推奨事項を掲載していないため、このドキュメントのすべての基準を満たす必要はありません。代わりに、コミュニティは、RFCシリーズによってキャプチャされた情報への追加の価値に基づいて、これらの情報RFCの公開を判断します。
Although it is out of scope for this document, proponents of a new algorithm could alternatively seek publication of their specification as an Informational or Experimental RFC via the Internet Research Task Force (IRTF) Stream. In general, these algorithms are expected to be less mature than ones that follow the procedures in this document for publication via the IETF Stream. Authors documenting deployed congestion control algorithms that cannot be changed by IETF or IRTF review are invited to seek publication of their specification as an Informational RFC via the Independent Submission Stream.
このドキュメントの範囲外ですが、新しいアルゴリズムの支持者は、インターネットリサーチタスクフォース（IRTF）ストリームを介して、情報または実験的RFCとしての仕様の公開を代わりに求めることができます。一般に、これらのアルゴリズムは、IETFストリームを介して公開するためにこのドキュメントの手順に従っているアルゴリズムよりも成熟度が低いと予想されます。IETFまたはIRTFレビューで変更できない展開された混雑制御アルゴリズムを文書化する著者は、独立した提出ストリームを介して情報RFCとしての仕様の公開を求めるように招待されています。
Algorithms can be designed for general Internet deployment or for use in controlled environments [RFC8799]. Within a controlled environment, an operator can ensure that flows are isolated from other Internet flows or they might allow these flows to share resources with other Internet flows. A data center is an example of a controlled environment that often deploys fabrics with rich signaling from switches to endpoints.
アルゴリズムは、一般的なインターネット展開または制御された環境での使用のために設計できます[RFC8799]。制御された環境内で、オペレーターは、フローが他のインターネットフローから分離されていることを確認するか、これらのフローが他のインターネットフローとリソースを共有できるようにすることができます。データセンターは、スイッチからエンドポイントへの豊富なシグナリングを備えたファブリックを展開することが多い制御された環境の例です。
Algorithms that rely on specific functions or configurations in the network need to provide a reference or specification for these functions (such as an RFC or another stable specification). For publication of a specification of one of these algorithms to proceed, the IETF will need to consider whether a working group exists that can properly assess the network-layer aspects and their interaction with the congestion control.
ネットワーク内の特定の関数または構成に依存するアルゴリズムは、これらの機能（RFCまたは別の安定した仕様など）の参照または仕様を提供する必要があります。これらのアルゴリズムのいずれかの仕様を続行するために、IETFは、ネットワーク層の側面を適切に評価できるワーキンググループが存在するかどうかを検討する必要があります。
In evaluating a new proposal for use in a controlled environment, the IETF community needs to understand the usage (e.g., how the usage is scoped to the controlled environment), whether the algorithm will share resources with Internet traffic, and what could happen if used in a protocol that is bridged across an Internet path. Algorithms that are designed to be confined to a controlled environment and are not intended for use in the general Internet might instead seek real-world data for those environments. In such cases, the evaluation criteria in the remainder of this document might not apply.
制御された環境で使用する新しい提案を評価する際に、IETFコミュニティは、アルゴリズムがインターネットトラフィックとリソースを共有するかどうか、およびインターネットパスに橋渡しされたプロトコルで使用される場合に起こる可能性のある使用（例えば、使用方法が制御された環境にスコープされる方法）を理解する必要があります。制御された環境に限定され、一般的なインターネットでの使用を目的としていないアルゴリズムは、代わりにそれらの環境の実際のデータを探すことができます。そのような場合、このドキュメントの残りの部分の評価基準は適用されない場合があります。
As previously noted, authors of a specification on a congestion control algorithm are expected to conduct a comprehensive evaluation of the advantages and disadvantages of any congestion control algorithms presented to the IETF community. The following guidelines are intended to assist authors and the community in this endeavor. While these guidelines provide a helpful framework, they should not be regarded as an exhaustive checklist as concerns beyond the scope of these guidelines may also arise.
前述のように、輻輳制御アルゴリズムの仕様の著者は、IETFコミュニティに提示された混雑制御アルゴリズムの利点と短所の包括的な評価を実施することが期待されています。次のガイドラインは、この努力の著者とコミュニティを支援することを目的としています。これらのガイドラインは有用なフレームワークを提供しますが、これらのガイドラインの範囲を超えた懸念も発生する可能性があるため、徹底的なチェックリストと見なされるべきではありません。
When considering a proposed congestion control algorithm, the community MUST consider the criteria in the following sections. These criteria will be evaluated in various domains (see Sections 6 and 7).
提案された輻輳制御アルゴリズムを検討する場合、コミュニティは次のセクションで基準を考慮する必要があります。これらの基準は、さまざまなドメインで評価されます（セクション6および7を参照）。
Some of the sections below will list criteria that SHOULD be met. It could happen that these criteria are not, in fact, met by the proposal. In such cases, the community MUST document whether not meeting the criteria is acceptable, for example, if there are practical limitations on carrying out an evaluation of the criteria.
以下のセクションの一部には、満たすべき基準がリストされています。実際、これらの基準が提案によって満たされていないことが起こります。そのような場合、コミュニティは、基準の評価を実施する際に実際的な制限がある場合、基準を満たしていないことが許容できるかどうかを文書化する必要があります。
The requirement that the community consider a criterion does not imply that the result needs to be described in an RFC: there is no formal requirement to document the results, although normal IETF policies for archiving proceedings will provide a record.
コミュニティが基準を考慮する要件は、結果をRFCで説明する必要があることを意味するものではありません。結果を文書化するための正式な要件はありませんが、手続きのアーカイブのための通常のIETFポリシーは記録を提供します。
This document, except where otherwise noted, does not provide normative guidance on the acceptable thresholds for any of these criteria. Instead, the community will use these evaluations as an input when considering whether to progress the proposed algorithm specification in the publication process.
このドキュメントは、それ以外の場合を除き、これらの基準のいずれかの許容されるしきい値に関する規範的なガイダンスを提供しません。代わりに、コミュニティは、公開プロセスで提案されたアルゴリズム仕様を進めるかどうかを検討する際に、これらの評価を入力として使用します。
The criteria in the following subsections evaluate the congestion control algorithm when one or more flows using that algorithm share a bottleneck link (i.e., with no flows using a differing congestion control algorithm).
次のサブセクションの基準は、そのアルゴリズムを使用して1つ以上のフローがボトルネックリンクを共有するときに輻輳制御アルゴリズムを評価します（つまり、異なる混雑制御アルゴリズムを使用してフローはありません）。
A congestion control algorithm should either stop sending when the packet drop rate exceeds some threshold [RFC3714] or include some notion of "full backoff". For "full backoff", at some point, the algorithm would reduce the sending rate to one packet per round-trip time; then, it would exponentially back off the time between single packet transmissions if the congestion persists. Exactly when either "full backoff" or a pause in sending comes into play will be algorithm specific. However, as discussed in [RFC2914] and [RFC8961], this requirement is crucial to protect the network in times of extreme (and persistent) congestion.
混雑制御アルゴリズムは、パケットドロップレートがある程度のしきい値を超えた場合に送信を停止するか、「完全なバックオフ」の概念を含める必要があります。「フルバックオフ」の場合、ある時点で、アルゴリズムは送信率を往復時間ごとに1つのパケットに引き下げます。その後、輻輳が続く場合、単一のパケット送信の間の時間を指数関数的に戻します。正確に「フルバックオフ」または送信中の一時停止が登場する場合、アルゴリズムに固有のものになります。ただし、[RFC2914]および[RFC8961]で説明したように、この要件は、極端な（そして持続的な）混雑の時代にネットワークを保護するために重要です。
If full backoff is used, this test does not require that the mechanism be identical to that of TCP (see [RFC6298] and [RFC8961]). For example, this does not preclude full backoff mechanisms that would give flows with different round-trip times comparable capacity during backoff.
完全なバックオフを使用する場合、このテストでは、メカニズムがTCPのメカニズムと同一であることを必要としません（[RFC6298]および[RFC8961]を参照）。たとえば、これは、バックオフ中に異なる往復時間の同等の容量でフローを与える完全なバックオフメカニズムを排除するものではありません。
A congestion control algorithm ought to try to avoid maintaining excessive queues in the network. Exactly how the algorithm achieves this is algorithm specific; see [RFC8961] and [RFC8085] for requirements.
混雑制御アルゴリズムは、ネットワーク内の過度のキューの維持を避けようとする必要があります。アルゴリズムがこれを達成する方法は、これがアルゴリズム固有のものです。要件については、[RFC8961]および[RFC8085]を参照してください。
"Bufferbloat" refers to the building of excessive queues in the network [BUFFERBLOAT]. Many network routers are configured with very large buffers. The Standards Track RFCs [RFC5681] and [RFC9438] describe the Reno and CUBIC congestion control algorithms (respectively), which send at progressively higher rates until a First In, First Out (FIFO) buffer completely fills; then packet losses occur. Every connection passing through that bottleneck experiences increased latency due to the high buffer occupancy. This adds unwanted latency that negatively impacts highly interactive applications such as videoconferencing or games, but it also affects routine web browsing and video playing.
「bufferbloat」とは、ネットワークに過剰なキューの構築を指します[bufferbloat]。多くのネットワークルーターは、非常に大きなバッファーで構成されています。RFCS [RFC5681]および[RFC9438]は、RFCS [RFC5681]と[RFC9438]を追跡し、リノとキュービックの混雑制御アルゴリズム（それぞれ）を説明します。その後、パケット損失が発生します。そのボトルネックを通過するすべての接続は、バッファー占有率が高いため、遅延が増加します。これにより、ビデオ会議やゲームなどの非常にインタラクティブなアプリケーションに悪影響を与える不要なレイテンシーが追加されますが、日常的なWebブラウジングやビデオプレイにも影響します。
This problem has been widely discussed since 2011 [BUFFERBLOAT], but was not discussed in the congestion control principles published in September 2002 [RFC2914]. The Reno and CUBIC congestion control algorithms do not address this problem, but a new congestion control algorithm has the opportunity to improve the state of the art.
この問題は2011年[BufferBloat]から広く議論されてきましたが、2002年9月に公開された渋滞制御原則[RFC2914]では議論されていません。リノとキュービックの混雑制御アルゴリズムはこの問題に対処していませんが、新しい混雑制御アルゴリズムは最先端を改善する機会があります。
A congestion control algorithm needs to avoid causing excessively high rates of packet loss. To accomplish this, it should avoid excessive increases in sending rate and reduce its sending rate if experiencing high packet loss.
混雑制御アルゴリズムは、パケット損失の過度に高い割合を引き起こすことを避ける必要があります。これを達成するために、送信率の過度の増加を避け、高いパケット損失を経験した場合、送信率を下げる必要があります。
The first version of the BBR algorithm [BBRv1] failed this requirement. Experimental evaluation [BBRv1-EVALUATION] showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and a half times the Bandwidth Delay Product (BDP). This was unsatisfactory, and, indeed, further versions provided a fix for this aspect of BBR [BBR].
BBRアルゴリズム[BBRV1]の最初のバージョンは、この要件に失敗しました。実験的評価[BBRV1評価]により、複数のBBRV1フローがボトルネックを共有し、バッファサイズが帯域幅遅延積（BDP）の約1.5倍未満であった場合、パケット損失の持続率を引き起こすことが示されました。これは不十分であり、実際、さらなるバージョンは、BBR [BBR]のこの側面の修正を提供しました。
This requirement does not imply that the algorithm should react to packet losses in exactly the same way as congestion control algorithms described in current Standards Track RFCs (e.g., [RFC5681]).
この要件は、アルゴリズムが現在の標準を追跡したRFC（例：[RFC5681]）で説明した混雑制御アルゴリズムとまったく同じ方法でパケット損失に反応することを意味するものではありません。
When multiple competing flows all use the same proposed congestion control algorithm, the evaluation should explore how the capacity is shared among the competing flows. Capacity fairness can be important when a small number of similar flows compete to fill a bottleneck. However, it can also not be useful, for example, when comparing flows that seek to send at different rates or if some of the flows do not last sufficiently long to approach asymptotic behavior.
複数の競合フローがすべて同じ提案された輻輳制御アルゴリズムを使用する場合、評価は競合するフローの間で容量がどのように共有されるかを探る必要があります。容量の公平性は、少数の同様のフローがボトルネックを埋めるために競合する場合に重要です。ただし、たとえば、異なるレートで送信しようとするフローを比較する場合、または一部のフローが漸近挙動に近づくのに十分な長さが続かない場合にも役立ちません。
A great deal of congestion control analysis concerns the steady-state behavior of long flows. However, many Internet flows are relatively short lived. Many short-lived flows today remain in the "slow start" mode of operation [RFC5681] that commonly features exponential congestion window growth because the flow never experiences congestion (e.g., packet loss).
多くの混雑制御分析は、長い流れの定常状態の挙動に関係しています。ただし、多くのインターネットフローは比較的短命です。今日の多くの短命のフローは、流れがうなりを起こさないため（パケット損失など）、一般的に指数関数的なうっ血窓の成長を特徴とする「スロースタート」動作モード[RFC5681]に残っています。
A proposal for a congestion control algorithm MUST consider how new and short-lived flows affect long-lived flows, and vice versa.
輻輳制御アルゴリズムの提案は、新しい短命のフローと短命のフローが長寿命のフローにどのように影響するかを検討する必要があり、その逆も同様です。
The mixed algorithm behavior criteria evaluate the interaction of the proposed congestion control algorithms being specified with commonly deployed congestion control algorithms.
混合アルゴリズムの動作基準は、一般的に展開されている混雑制御アルゴリズムで指定されている提案された輻輳制御アルゴリズムの相互作用を評価します。
In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control algorithm could result in more harm than algorithms published in previous Standards Track RFCs (e.g., [RFC5681], [RFC9002], and [RFC9438]) to flows sharing a common bottleneck. The measure of harm is not restricted to unequal capacity, but also ought to consider metrics such as the introduced latency or an increase in packet loss. An evaluation MUST assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff.
異なる輻輳制御アルゴリズムが使用されるコンテキストでは、提案された輻輳制御アルゴリズムが以前の標準を追跡したアルゴリズムよりも害をもたらす可能性があるかどうかを理解することが重要です（例：[RFC9002]、[RFC9002]、[RFC9438]）。危害の尺度は不平等な能力に限定されていませんが、導入されたレイテンシやパケット損失の増加などのメトリックを考慮する必要があります。評価は、すべてのフィードバックの損失（たとえば、再送信タイムの有効期限によって検出された）がバックオフをもたらすという保証など、飢starを引き起こす可能性を評価する必要があります。
A proposed congestion control algorithm MUST be evaluated when competing against standard IETF congestion controls (e.g., [RFC5681], [RFC9002], and [RFC9438]). A proposed congestion control algorithm that has a significantly negative impact on flows using standard congestion control might be suspect, and this aspect should be part of the community's decision making with regards to the suitability of the proposed congestion control algorithm. The community should also consider other non-standard congestion control algorithms that are known to be widely deployed.
提案された輻輳制御アルゴリズムは、標準のIETF混雑コントロールと競合するときに評価する必要があります（例：[RFC5681]、[RFC9002]、および[RFC9438]）。標準的な輻輳制御を使用したフローに大きな悪影響を与える提案された輻輳制御アルゴリズムは疑われる可能性があり、この側面は、提案された輻輳制御アルゴリズムの適合性に関してコミュニティの意思決定の一部であるべきです。また、コミュニティは、広く展開されていることが知られている他の非標準の混雑制御アルゴリズムを考慮する必要があります。
Note that this guideline is not a requirement for strict Reno or CUBIC friendliness as a prerequisite for a proposed congestion control mechanism to advance to Experimental or Standards Track status. As an example, HighSpeed TCP is a congestion control mechanism that is specified in an Experimental RFC and is not Reno friendly in all environments. When a new congestion control algorithm is deployed, the existing major algorithm deployments need to be considered to avoid severe performance degradation. Note that this guideline does not constrain the interaction with flows that are not best effort.
このガイドラインは、実験的または標準的な追跡ステータスに進むための提案された輻輳制御メカニズムの前提条件としての厳格なリノまたは立方体の親しみやすさの要件ではないことに注意してください。例として、高速TCPは、実験的なRFCで指定されており、すべての環境でリノに優しいものではない混雑制御メカニズムです。新しい混雑制御アルゴリズムが展開される場合、既存の主要なアルゴリズムの展開を考慮する必要があります。このガイドラインは、最善の努力ではないフローとの相互作用を制約しないことに注意してください。
As an example from an Experimental RFC, fairness with standard TCP is discussed in Sections 4 and 6 of [RFC3649], and using spare capacity is discussed in Sections 6, 11.1, and 12 of [RFC3649].
実験RFCの例として、標準TCPの公平性については[RFC3649]のセクション4および6で説明し、予備容量の使用については[RFC3649]のセクション6、11.1、および12で説明します。
General-purpose algorithms need to coexist in the Internet with real-time congestion control algorithms, which in general have finite throughput requirements (i.e., they do not seek to utilize all available capacity) and more strict latency bounds. See [RFC8836] for a description of the characteristics of this use case and the resulting requirements.
汎用アルゴリズムは、一般的に有限のスループット要件を持っているリアルタイムの輻輳制御アルゴリズムとインターネットで共存する必要があります（つまり、利用可能なすべての容量を利用しようとしません）。このユースケースの特性と結果の要件の説明については、[RFC8836]を参照してください。
[RFC8868] provides suggestions for real-time congestion control design and [RFC8867] suggests test cases. [RFC9392] describes some considerations for the RTP Control Protocol (RTCP). In particular, real-time flows can use less frequent feedback (acknowledgment) than that provided by reliable transports. This document does not change the Informational status of those RFCs.
[RFC8868]は、リアルタイムの混雑制御設計の提案を提供し、[RFC8867]はテストケースを提案します。[RFC9392]は、RTP制御プロトコル（RTCP）に関するいくつかの考慮事項について説明しています。特に、リアルタイムのフローは、信頼できる輸送によって提供されるものよりも少ない頻度のフィードバック（承認）を使用できます。このドキュメントは、これらのRFCの情報状況を変更しません。
A proposal for a congestion control algorithm SHOULD consider coexistence with widely deployed real-time congestion control algorithms. Regrettably, at the time of writing (2024), many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications. It is hoped that this situation will change.
輻輳制御アルゴリズムの提案では、広く展開されているリアルタイム輻輳制御アルゴリズムとの共存を考慮する必要があります。残念ながら、執筆時点（2024）では、詳細な公開仕様を備えた多くのアルゴリズムは広く展開されていませんが、広く展開されている多くのリアルタイムの混雑制御アルゴリズムには不完全な公開仕様があります。この状況が変わることが期待されています。
To the extent that behavior of widely deployed algorithms is understood, proponents of a proposed congestion control algorithm can analyze and simulate a proposal's interaction with those algorithms. To the extent that they are not, experiments can be conducted where possible.
広く展開されたアルゴリズムの動作が理解される限り、提案された輻輳制御アルゴリズムの支持者は、これらのアルゴリズムとの提案の相互作用を分析およびシミュレートできます。そうでない限り、可能な場合は実験を実施できます。
Real-time flows can be directed into distinct queues via Differentiated Services Code Points (DSCPs) or other mechanisms, which can substantially reduce the interplay with other traffic. However, a proposal targeting general Internet use cannot assume this is always the case.
リアルタイムフローは、差別化されたサービスコードポイント（DSCP）または他のメカニズムを介して異なるキューに向けられ、他のトラフィックとの相互作用を大幅に削減できます。ただし、一般的なインターネットの使用をターゲットにした提案は、これが常にそうであると仮定することはできません。
Section 7.2 describes the impact of network transport circuit breaker algorithms. [RFC8083] also defines a minimal set of RTP circuit breakers that operate end-to-end across a path. This identifies conditions under which a sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers.
セクション7.2では、ネットワークトランスポート回路ブレーカーアルゴリズムの影響について説明します。[RFC8083]は、パス全体でエンドツーエンドを動作させるRTP回路ブレーカーの最小限のセットも定義します。これは、送信者がメディアデータの送信を停止して、ネットワークを過度の渋滞から保護する必要がある条件を特定します。長寿命の過剰な輻輳がない場合、Best-Effort IPネットワークで実行されるRTPアプリケーションは、これらの回路ブレーカーをトリガーすることなく動作できるようになると予想されます。
The effect on short-lived and long-lived flows using other common congestion control algorithms MUST be evaluated, as in Section 5.1.5.
セクション5.1.5のように、他の一般的な輻輳制御アルゴリズムを使用した短命および長寿命の流れに対する影響を評価する必要があります。
A proposal for a congestion control algorithm MUST clearly explain any deviations from [RFC2914] and [RFC7141].
輻輳制御アルゴリズムの提案は、[RFC2914]および[RFC7141]からの逸脱を明確に説明する必要があります。
A congestion control algorithm proposal MUST discuss whether it allows for incremental deployment in the targeted environment. For a mechanism targeted for deployment in the current Internet, the proposal SHOULD discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet (e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like).
輻輳制御アルゴリズムの提案は、ターゲット環境での増分展開を可能にするかどうかを議論する必要があります。現在のインターネットでの展開を目的としたメカニズムの場合、提案は、現在のインターネット内のいくつかの機器を使用したメカニズムの正しい動作（例えば、ルーター、透明プロキシ、WANオプティマイザー、侵入検知システム、ホームルーターなど）について、既知のこと（もしあれば）を議論する必要があります。
Similarly, if the proposed congestion control algorithm is intended only for specific environments (and not the global Internet), the proposal SHOULD consider how this intention is to be realized. The IETF community will have to address the question of whether the scope can be enforced by stating the restrictions or whether additional protocol mechanisms are required to enforce this scoping. The answer will necessarily depend on the proposed change.
同様に、提案された輻輳制御アルゴリズムが特定の環境のみ（グローバルインターネットではない）のみである場合、提案はこの意図がどのように実現されるかを考慮する必要があります。IETFコミュニティは、このスコープを実施するために制限を記載することにより、範囲を実施できるかどうかの問題に対処する必要があります。答えは必然的に提案された変更に依存します。
As an example from an Experimental RFC, deployment issues of Quick-Start are discussed in Sections 10.3 and 10.4 of [RFC4782].
実験RFCの例として、クイックスタートの展開の問題については、[RFC4782]のセクション10.3および10.4で説明します。
The criteria in Section 5 will be evaluated in the scenarios described in the following subsections. Unless a proposed congestion control algorithm specification of the IETF Stream explicitly forbids use on the public Internet, there MUST be IETF consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress.
セクション5の基準は、以下のサブセクションで説明されているシナリオで評価されます。提案された輻輳制御アルゴリズムのIETFストリームの仕様が、パブリックインターネットでの使用を明示的に禁止している場合、提案された輻輳制御アルゴリズムのこれらのシナリオの基準を満たしているというIETFのコンセンサスがなければなりません。
The evaluation of each scenario SHOULD occur over a representative range of bandwidths, delays, and queue depths. Of course, the set of parameters representative of the public Internet will change over time.
各シナリオの評価は、帯域幅、遅延、キューの深さの代表的な範囲で発生する必要があります。もちろん、パブリックインターネットを代表する一連のパラメーターは、時間とともに変化します。
These criteria are intended to capture a statistically dominant set of Internet conditions. In the case that a proposed congestion control algorithm has been tested at Internet scale, the results from that deployment are often useful for answering these questions.
これらの基準は、統計的に支配的なインターネット条件セットをキャプチャすることを目的としています。In the case that a proposed congestion control algorithm has been tested at Internet scale, the results from that deployment are often useful for answering these questions.
The performance of a congestion control algorithm is affected by the queue discipline applied at the bottleneck link. The drop-tail queue discipline (using a FIFO buffer) MUST be evaluated. See Section 7.1 for evaluation of other queue disciplines.
輻輳制御アルゴリズムのパフォーマンスは、ボトルネックリンクに適用されるキューの分野の影響を受けます。ドロップテールキューの規律（FIFOバッファーを使用）を評価する必要があります。他のキューの分野の評価については、セクション7.1を参照してください。
When a proposed congestion control algorithm relies on explicit signals from the path, the proposal MUST consider the effect of traffic passing through a tunnel, where routers may not be aware of the flow.
提案された輻輳制御アルゴリズムがパスからの明示的な信号に依存している場合、提案は、ルーターが流れを認識しない可能性のあるトンネルを通過するトラフィックの影響を考慮する必要があります。
Designers of tunnels and similar encapsulations might need to consider nested congestion control interactions, for example, when the Explicit Congestion Notification (ECN) is used by both an IP and lower-layer technology [ECN-ENCAPS].
トンネルおよび同様のカプセルの設計者は、たとえば、明示的な渋滞通知（ECN）がIPと低層技術の両方で使用される場合、ネストされた輻輳制御相互作用を検討する必要がある場合があります[ECN-ENCAPS]。
Wired networks are usually characterized by extremely low rates of packet loss except for those due to queue drops. They tend to have stable aggregate capacity, usually higher than other types of links, and low non-queueing delay. Because the properties are relatively simple, wired links are typically used as a "baseline" case even if they are not always the bottleneck link in the modern Internet.
有線ネットワークは通常、キュードロップによるものを除き、非常に低いパケット損失率によって特徴付けられます。それらは、通常、他のタイプのリンクよりも高い安定した骨材容量を持つ傾向があり、低い非キューリング遅延よりも高い。プロパティは比較的単純であるため、有線リンクは通常、最新のインターネットのボトルネックリンクではない場合でも、「ベースライン」ケースとして使用されます。
While the early Internet was dominated by wired links, the properties of wireless links have become important to Internet performance. In particular, a proposed congestion control algorithm should be evaluated in situations where some packet losses are due to radio effects rather than router queue drops. The link capacity varies over time due to changing link conditions, and media-access delays and link-layer retransmission lead to increased jitter in round-trip times. See [RFC3819] and Section 16 of [TOOLS] for further discussion of wireless properties.
初期のインターネットは有線リンクによって支配されていましたが、ワイヤレスリンクのプロパティがインターネットのパフォーマンスにとって重要になっています。特に、提案された輻輳制御アルゴリズムは、ルーターキュードロップではなく無線効果による一部のパケット損失が原因である状況で評価する必要があります。リンク容量は、リンク条件の変化により時間とともに異なり、メディアアクセスの遅延とリンク層の再送信は、往復時間でジッターの増加につながります。ワイヤレスプロパティのさらなる議論については、[ツール]の[RFC3819]およびセクション16を参照してください。
The criteria in Section 5 will be evaluated in the scenarios described in the following subsections, unless the proposed congestion control algorithm specifically excludes its use in a scenario. For these specific use cases, the IETF community MAY allow a proposal to progress even if the criteria indicate an unsatisfactory result for these scenarios.
セクション5の基準は、提案された渋滞制御アルゴリズムがシナリオでの使用を具体的に除外しない限り、以下のサブセクションで説明されているシナリオで評価されます。これらの特定のユースケースでは、IETFコミュニティは、基準がこれらのシナリオの不十分な結果を示していても、提案を進めることを許可する場合があります。
In general, measurements from Internet-scale deployments might not expose the properties of operation in each of these scenarios because they are not as ubiquitous as the general-use scenarios.
一般に、インターネット規模の展開からの測定は、一般的なシナリオほど遍在していないため、これらの各シナリオで動作のプロパティを公開しない可能性があります。
The proposed congestion control algorithm SHOULD be evaluated under a variety of bottleneck-queue disciplines. The effect of an AQM discipline can be hard to detect by Internet evaluation. At a minimum, a proposal should reason about an algorithm's response to various AQM disciplines. Simulation or empirical results are, of course, valuable.
提案されている輻輳制御アルゴリズムは、さまざまなボトルネックキューの分野で評価する必要があります。AQMの規律の効果は、インターネット評価によって検出するのが難しい場合があります。少なくとも、提案は、さまざまなAQM分野に対するアルゴリズムの応答について推論する必要があります。もちろん、シミュレーションまたは経験的結果は価値があります。
Some of the AQM techniques that might have an impact on a proposed congestion control algorithm include:
提案されている輻輳制御アルゴリズムに影響を与える可能性のあるAQM技術のいくつかは次のとおりです。
* Flow Queue CoDel (FQ-CoDel) [RFC8290];
* フローキューコード（FQコデル）[RFC8290];
* Proportional Integral controller Enhanced (PIE) [RFC8033]; and
* 比例積分コントローラー強化（PIE）[RFC8033];そして
* Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].
* 低レイテンシー、低損失、スケーラブルスループット（L4S）[RFC9332]。
A proposed congestion control algorithm that sets one of the two ECN-Capable Transport (ECT) codepoints in the IP header can gain the benefits of receiving Explicit Congestion Notification-Congestion Experienced (ECN-CE) signals from an on-path AQM [RFC8087]. Use of ECN (see [RFC3168] and [RFC9332]) requires the congestion control algorithm to react when it receives a packet with an ECN-CE marking. This reaction needs to be evaluated to confirm that the algorithm conforms with the requirements of the ECT codepoint that was used.
IPヘッダー内の2つのECN対応トランスポート（ECT）コードポイントのいずれかを設定する提案された輻輳制御アルゴリズムは、オンパスAQM [RFC8087]から経験された（ECN-CE）シグナルを受信することの利点を得ることができます。ECNの使用（[RFC3168]および[RFC9332]を参照）では、ECN-CEマーキングでパケットを受け取ったときに反応するための輻輳制御アルゴリズムが必要です。この反応は、アルゴリズムが使用されたECT CodePointの要件に準拠していることを確認するために評価する必要があります。
Note that evaluation of AQM techniques -- as opposed to their impact on a specific proposed congestion control algorithm -- is out of scope of this document. [RFC7567] describes design considerations for AQMs.
特定の提案された輻輳制御アルゴリズムへの影響とは対照的に、AQM技術の評価はこのドキュメントの範囲外であることに注意してください。[RFC7567]は、AQMSの設計上の考慮事項について説明しています。
Some equipment in the network uses an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set of flows [RFC8084]. Such a network transport circuit breaker can automatically detect excessive congestion; when detected, it can terminate (or significantly reduce the rate of) the flow(s). A well-designed congestion control algorithm ought to react before the flow uses excessive resources; therefore, it will operate within the envelope set by network transport circuit breaker algorithms.
ネットワーク内の一部の機器は、自動メカニズムを使用して、フローまたは集計のフローセットによってリソースの使用を継続的に監視します[RFC8084]。このようなネットワーク輸送回路ブレーカーは、過度の輻輳を自動的に検出できます。検出されると、流れを終了（または速度を大幅に減らす）ことができます。適切に設計された混雑制御アルゴリズムは、フローが過剰なリソースを使用する前に反応する必要があります。したがって、ネットワークトランスポート回路ブレーカーアルゴリズムによって設定されたエンベロープ内で動作します。
An Internet path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. This cannot be assumed. An Internet path can also include complex subnetworks where the minimum delay changes over various time scales, resulting in a minimum delay that is not stationary.
インターネットパスには、最小遅延が伝播遅延であり、追加の遅延がリンクバッファリングに起因する単純なリンクを含めることができます。これは想定できません。インターネットパスには、さまざまな時間スケールで最小の遅延が変化する複雑なサブネットワークを含めることもできます。
Varying delay occurs when a subnet changes the forwarding path to optimize capacity, resilience, etc. It could also arise when a subnet uses a capacity-management method where the available resource is periodically distributed among the active nodes. A node might then have to buffer data until an assigned transmission opportunity or until the physical path changes (e.g., when the length of a wireless path changes or when the physical layer changes its mode of operation). Variation also arises when traffic with a higher priority DSCP preempts transmission of traffic with a lower class. In these cases, the delay varies as a function of external factors, and attempting to infer congestion from an increase in the delay results in reduced throughput. This variation in the delay over short timescales (jitter) might not be distinguishable from jitter that results from other effects.
サブネットが転送パスを変更して容量、回復力などを最適化すると、さまざまな遅延が発生します。サブネットが、利用可能なリソースがアクティブなノード間に定期的に配布される容量管理方法を使用すると発生する可能性があります。その後、ノードは、割り当てられた送信機会まで、または物理的なパスが変わるまでデータをバッファする必要があります（たとえば、ワイヤレスパスの長さが変更された場合、または物理層が動作モードを変更する場合）。優先度の高いDSCPを備えたトラフィックが低いクラスでトラフィックの送信を先取りする場合にも変動が生じます。これらの場合、遅延は外部要因の関数として異なり、遅延の増加から輻輳を推測しようとすると、スループットが減少します。短いタイムスケール（ジッター）での遅延のこの変動は、他の効果から生じるジッターと区別できない場合があります。
A proposed congestion control algorithm SHOULD be evaluated to ensure its operation is robust when there is a significant change in the minimum delay.
提案された輻輳制御アルゴリズムを評価して、最小遅延に大きな変化がある場合、その動作が堅牢であることを確認する必要があります。
The "Internet of Things" (IoT) is a broad concept, but when evaluating a proposed congestion control algorithm, it is often associated with unique characteristics. For example, IoT nodes might be more constrained in power, CPU, or other parameters than conventional Internet hosts. This might place limits on the complexity of any given algorithm. These power and radio constraints might make the volume of control packets in a given algorithm a key evaluation metric.
「モノのインターネット」（IoT）は幅広い概念ですが、提案された輻輳制御アルゴリズムを評価する場合、しばしば一意の特性に関連付けられています。たとえば、IoTノードは、従来のインターネットホストよりも電力、CPU、またはその他のパラメーターにより制約がある場合があります。これにより、特定のアルゴリズムの複雑さに制限が置かれる可能性があります。これらのパワーと無線の制約により、特定のアルゴリズム内の制御パケットの量が重要な評価メトリックになる可能性があります。
Extremely low-power links can lead to very low throughput and a low bandwidth-delay product, which is well below the standard operating range of most Internet flows.
非常に低電力リンクは、非常に低いスループットと低い帯域幅遅延製品につながる可能性があり、これはほとんどのインターネットフローの標準動作範囲をはるかに下回っています。
Furthermore, many IoT applications do not a have a human in the loop; therefore, they might have weaker latency constraints because they do not relate to a user experience. Congestion control algorithms still might need to share the path with other flows with different constraints.
さらに、多くのIoTアプリケーションには、ループに人間がいるわけではありません。したがって、ユーザーエクスペリエンスに関連していないため、レイテンシの制約が弱い場合があります。輻輳制御アルゴリズムは、異なる制約で他のフローとパスを共有する必要がある場合があります。
Authors of a proposed congestion control algorithm ought not to presume that all general Internet paths have a low delay. Some paths include links that contribute much more delay than for a typical Internet path. Satellite links often have delays longer than is typical for wired paths [RFC2488] and high-delay-bandwidth products [RFC3649].
提案されている輻輳制御アルゴリズムの著者は、すべての一般的なインターネットパスが低い遅延を持っていると推測するべきではありません。一部のパスには、典型的なインターネットパスよりもはるかに遅れを与えるリンクが含まれます。衛星リンクは、多くの場合、有線パス[RFC2488]および高耐性帯域幅[RFC3649]で典型的なものよりも長く遅延があります。
Paths can also present a variable delay as described in Section 7.3.
パスは、セクション7.3で説明されているように、可変遅延を提示することもできます。
A proposal for a congestion control algorithm SHOULD explore how the algorithm performs with non-compliant senders, receivers, or routers. In addition, the proposal should explore how a proposed congestion control algorithm performs with outside attackers. This can be particularly important for proposed congestion control algorithms that involve explicit feedback from routers along the path.
輻輳制御アルゴリズムの提案では、非準拠の送信者、受信機、またはルーターでアルゴリズムがどのように機能するかを調査する必要があります。さらに、提案は、提案された輻輳制御アルゴリズムが外部の攻撃者とどのように機能するかを探る必要があります。これは、パスに沿ったルーターからの明示的なフィードバックを含む、提案された混雑制御アルゴリズムにとって特に重要です。
As an example from an Experimental RFC, performance with misbehaving nodes and outside attackers is discussed in Sections 9.4, 9.5, and 9.6 of [RFC4782]. This includes discussion of:
実験RFCの例として、[RFC4782]のセクション9.4、9.5、および9.6で、誤動作ノードと外部攻撃者のパフォーマンスについて説明します。これには、次の議論が含まれます。
* misbehaving senders and receivers;
* 送信者と受信者を誤動作する。
* collusion between misbehaving routers;
* 不正行為ルーター間の共謀;
* misbehaving middleboxes; and
* ミドルボックスを誤動作します。そして
* the potential use of Quick-Start to attack routers or to tie up available Quick-Start bandwidth.
* ルーターを攻撃したり、利用可能なクイックスタート帯域幅を縛ったりするためのクイックスタートの潜在的な使用。
Authors of a proposed congestion control algorithm ought not to presume that all general Internet paths reliably deliver packets in order. [RFC4653] discusses the effect of extreme packet reordering.
提案されている輻輳制御アルゴリズムの著者は、すべての一般的なインターネットパスがパケットを順番に確実に配信すると推測するべきではありません。[RFC4653]は、極端なパケットの並べ替えの効果について説明しています。
A proposal for a congestion control algorithm SHOULD consider how it would perform in the presence of transient events such as a sudden onset of congestion, a routing change, or a mobility event. Routing changes, link disconnections, intermittent link connectivity, and mobility are discussed in more detail in Section 16 of [TOOLS].
輻輳制御アルゴリズムの提案では、混雑の突然の発症、ルーティングの変更、モビリティイベントなどの一時的なイベントの存在下でどのように機能するかを検討する必要があります。ルーティングの変更、リンク切断、断続的なリンク接続、およびモビリティについては、[ツール]のセクション16で詳しく説明します。
As an example from an Experimental RFC, a response to transient events is discussed in Section 9.2 of [RFC4782].
実験RFCの例として、一時的なイベントへの応答について[RFC4782]のセクション9.2で説明します。
An IETF transport is not tied to a specific Internet path or type of path. The set of routers that form a path can and do change with time. This will cause the properties of the path to change with respect to time. A proposal for a congestion control algorithm MUST evaluate the impact of changes in the path and be robust to changes in path characteristics on the interval of common Internet rerouting intervals.
IETFトランスポートは、特定のインターネットパスまたはパスの種類に結び付けられていません。パスを形成するルーターのセットは、時間とともに変化することができ、変化します。これにより、経路のプロパティが時間に対して変化します。輻輳制御アルゴリズムの提案は、パスの変化の影響を評価し、一般的なインターネット再ルーティング間隔の間隔でのパス特性の変化に堅牢でなければなりません。
Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender. A multipath sender can schedule which packets travel on which of its active paths. This enables a trade-off in timeliness and reliability. There are various ways that multipath techniques can be used.
MultiPath Transport Protocolは、送信者の単一の接続によって複数のパスを区別および使用することを可能にします。マルチパス送信者は、アクティブパスのどのパケットを移動するかをスケジュールできます。これにより、適時性と信頼性のトレードオフが可能になります。マルチパステクニックを使用できるさまざまな方法があります。
One example use is to provide failover from one path to another when the original path is no longer viable or provides inferior performance. Designs need to independently track the congestion state of each path and demonstrate independent congestion control for each path being used. Authors of a proposed multipath congestion control algorithm that implements path failover MUST evaluate the harm to performance resulting from a change in the path and show that this does not result in flow starvation. Synchronization of failover (e.g., where multiple flows change their path on similar time frames) can also contribute to harm and/or reduce fairness. These effects also ought to be evaluated.
1つの例は、元のパスが実行可能でないか、パフォーマンスが劣っている場合に、あるパスから別のパスにフェールオーバーを提供することです。設計は、各パスの輻輳状態を独立して追跡し、使用されている各パスの独立した輻輳制御を実証する必要があります。パスフェールオーバーを実装する提案されているマルチパス輻輳制御アルゴリズムの著者は、パスの変化に起因するパフォーマンスへの害を評価し、これが流れの飢vをもたらさないことを示す必要があります。フェールオーバーの同期（たとえば、複数のフローが同様の時間枠でパスを変更する場合）は、害や公平性を低下させることにも寄与する可能性があります。これらの効果も評価する必要があります。
Another example use is concurrent multipath, where the transport protocol simultaneously schedules a flow to aggregate the capacity across multiple paths. The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint. This introduces additional implications. A congestion control algorithm proposal MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck or share resources that are coupled between different paths, such as an overall capacity limit. A proposal SHOULD consider the potential for harm to other flows. Synchronization of congestion control mechanisms (e.g., where multiple flows change their behavior on similar time frames) can also contribute to harm and/or reduce fairness. These effects also ought to be evaluated.
別の例の使用は、同時のマルチパスであり、輸送プロトコルは同時にフローをスケジュールして、複数のパスにわたって容量を集約します。インターネットは、異なるパス（例えば、異なるエンドポイントアドレスを使用する）がばらばらであるという保証を提供しません。これは追加の意味をもたらします。混雑制御アルゴリズムの提案は、複数のパスが共通の混雑したボトルネックを共有する場合、または全体の容量制限などの異なるパス間で結合されたリソースを共有する場合、他のフローへの潜在的な害を評価する必要があります。提案は、他のフローへの害の可能性を考慮する必要があります。輻輳制御メカニズムの同期（たとえば、複数のフローが同様の時間枠で動作を変える場合）は、害や公平性を低下させることもできます。これらの効果も評価する必要があります。
At the time of writing (2024), there are currently no Standards Track RFCs for concurrent multipath, but there is an Experimental RFC [RFC6356] that specifies a concurrent multipath congestion control algorithm for Multipath TCP (MPTCP) [RFC8684].
執筆時点（2024）では、現在、同時マルチパスのRFCを追跡する標準はありませんが、マルチパスTCP（MPTCP）[RFC8684]の同時マルチパス輻輳制御コントロールアルゴリズムを指定する実験的なRFC [RFC6356]があります。
Data centers are characterized by very low latencies (< 2 ms). Many workloads involve bursty traffic where many nodes complete a task at the same time. As a controlled environment, data centers often deploy fabrics that employ rich signaling from switches to endpoints. Furthermore, the operator can often limit the number of operating congestion control algorithms.
データセンターは、非常に低いレイテンシ（<2 ms）によって特徴付けられます。多くのワークロードには、多くのノードが同時にタスクを完了するバーストトラフィックが含まれます。制御された環境として、データセンターは多くの場合、スイッチからエンドポイントへのリッチシグナリングを使用するファブリックを展開します。さらに、オペレーターは、多くの場合、動作渋滞制御アルゴリズムの数を制限できます。
For these reasons, data center congestion controls are often distinct from those running elsewhere on the Internet (see Section 4). A proposed congestion control algorithm need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it.
これらの理由により、データセンターの混雑コントロールは、多くの場合、インターネット上の他の場所で実行されているものとは異なります（セクション4を参照）。提案された輻輳制御アルゴリズムは、データセンターを対象としている場合、他のすべてのアルゴリズムとうまく共存する必要はありませんが、提案は、それと安全に共存すると予想されるものを示す必要があります。
This document does not represent a change to any aspect of the TCP/IP protocol suite; therefore, it does not directly impact Internet security. The implementation of various facets of the Internet's current congestion control algorithms do have security implications (e.g., as outlined in [RFC5681]).
このドキュメントは、TCP/IPプロトコルスイートのいずれの側面への変更を表していません。したがって、インターネットのセキュリティに直接影響しません。インターネットの現在の混雑制御アルゴリズムのさまざまなファセットの実装には、セキュリティの意味があります（たとえば、[RFC5681]で概説されているように）。
A proposal for a congestion control algorithm MUST examine any potential security or privacy issues that may arise from their design.
輻輳制御アルゴリズムの提案は、設計から生じる可能性のある潜在的なセキュリティまたはプライバシーの問題を調査する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion
Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
February 2014, <https://www.rfc-editor.org/info/rfc7141>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8961] Allman, M., "Requirements for Time-Based Loss Detection",
BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020,
<https://www.rfc-editor.org/info/rfc8961>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.
[BBR] Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-02, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-02>.
[BBRv1] Cardwell, N., Cheng, Y., Yeganeh, S. H., and V. Jacobson,
"BBR Congestion Control", Work in Progress, Internet-
Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3
July 2017, <https://datatracker.ietf.org/doc/html/draft-
cardwell-iccrg-bbr-congestion-control-00>.
[BBRv1-EVALUATION]
Hock, M., Bless, R., and M. Zitterbart, "Experimental
evaluation of BBR congestion control", 2017 IEEE 25th
International Conference on Network Protocols (ICNP),
DOI 10.1109/ICNP.2017.8117540, 2017,
<https://ieeexplore.ieee.org/document/8117540>.
[BUFFERBLOAT]
Nichols, K. and J. Gettys, "Bufferbloat: Dark Buffers in
the Internet", ACM Queue Volume 9, Issue 11,
DOI 10.1145/2063166.2071893, November 2011,
<https://dl.acm.org/doi/10.1145/2063166.2071893>.
[ECN-ENCAPS]
Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP",
BCP 89, RFC 9599, DOI 10.17487/RFC9599, August 2024,
<https://www.rfc-editor.org/info/rfc9599>.
[HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly
high-speed TCP variant", ACM SIGOPS Operating Systems
Review, vol. 42, no. 5, pp. 64-74,
DOI 10.1145/1400097.1400105, July 2008,
<https://doi.org/10.1145/1400097.1400105>.
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms",
BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999,
<https://www.rfc-editor.org/info/rfc2488>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, DOI 10.17487/RFC3649, December 2003,
<https://www.rfc-editor.org/info/rfc3649>.
[RFC3714] Floyd, S., Ed. and J. Kempf, Ed., "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet",
RFC 3714, DOI 10.17487/RFC3714, March 2004,
<https://www.rfc-editor.org/info/rfc3714>.
[RFC3819] Karn, P., Ed., 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, DOI 10.17487/RFC3819, July 2004,
<https://www.rfc-editor.org/info/rfc3819>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4653] Bhandarkar, S., Reddy, A. L. N., Allman, M., and E.
Blanton, "Improving the Robustness of TCP to Non-
Congestion Events", RFC 4653, DOI 10.17487/RFC4653, August
2006, <https://www.rfc-editor.org/info/rfc4653>.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", BCP 133, RFC 5033,
DOI 10.17487/RFC5033, August 2007,
<https://www.rfc-editor.org/info/rfc5033>.
[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion
Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March
2008, <https://www.rfc-editor.org/info/rfc5166>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols",
RFC 6356, DOI 10.17487/RFC6356, October 2011,
<https://www.rfc-editor.org/info/rfc6356>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015,
<https://www.rfc-editor.org/info/rfc7414>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/info/rfc8312>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control
Requirements for Interactive Real-Time Media", RFC 8836,
DOI 10.17487/RFC8836, January 2021,
<https://www.rfc-editor.org/info/rfc8836>.
[RFC8867] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating Congestion Control for Interactive
Real-Time Media", RFC 8867, DOI 10.17487/RFC8867, January
2021, <https://www.rfc-editor.org/info/rfc8867>.
[RFC8868] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion
Control for Interactive Real-Time Media", RFC 8868,
DOI 10.17487/RFC8868, January 2021,
<https://www.rfc-editor.org/info/rfc8868>.
[RFC8869] Sarker, Z., Zhu, X., and J. Fu, "Evaluation Test Cases for
Interactive Real-Time Media over Wireless Networks",
RFC 8869, DOI 10.17487/RFC8869, January 2021,
<https://www.rfc-editor.org/info/rfc8869>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-
Queue Coupled Active Queue Management (AQM) for Low
Latency, Low Loss, and Scalable Throughput (L4S)",
RFC 9332, DOI 10.17487/RFC9332, January 2023,
<https://www.rfc-editor.org/info/rfc9332>.
[RFC9392] Perkins, C., "Sending RTP Control Protocol (RTCP) Feedback
for Congestion Control in Interactive Multimedia
Conferences", RFC 9392, DOI 10.17487/RFC9392, April 2023,
<https://www.rfc-editor.org/info/rfc9392>.
[TOOLS] Floyd, S. and E. Kohler, "Tools for the Evaluation of
Simulation and Testbed Scenarios", Work in Progress,
Internet-Draft, draft-irtf-tmrg-tools-05, 23 February
2008, <https://datatracker.ietf.org/doc/html/draft-irtf-
tmrg-tools-05>.
* Examined BCP 14 keywords and consistency with other RFCs
* BCP 14のキーワードと他のRFCとの一貫性を調べました
* Rewrote the "Document Status" section
* 「ドキュメントステータス」セクションを書き直します
* Added QUIC and other more recent congestion control standards
* QUICおよびその他の最近の混雑制御基準を追加しました
* Aligned motivation for this work with the CCWG charter
* CCWGチャーターとのこの作業の動機付け
* Refined discussion of Quick-Start
* クイックスタートの洗練された議論
* Added criterion for bufferbloat
* bufferbloatの基準を追加しました
* Added text on constrained environments/limited domains and circuit breakers and aligned with other RFCs
* 制約付き環境/限定ドメインと回路ブレーカーにテキストを追加し、他のRFCと整列させた
* Added discussion of real-time protocols, short flows, AQM response, and multipath transports
* リアルタイムプロトコル、短いフロー、AQM応答、およびマルチパストランスポートの議論を追加しました
* Listed properties of wired and wireless networks
* 有線およびワイヤレスネットワークのリストされたプロパティ
* Added sections addressing IoT and Multicast (noting this is out of scope)
* IoTおよびMulticastに対処するセクションを追加しました（これは範囲外であることに注意してください）
Sally Floyd and Mark Allman were the authors of this document's predecessor, [RFC5033], which served the community well for over a decade.
サリー・フロイドとマーク・オールマンは、この文書の前任者である[RFC5033]の著者であり、10年以上にわたってコミュニティに役立っていました。
Thanks to Richard Scheffenegger for helping to get this revision process started.
この改訂プロセスの開始を支援してくれたリチャードシェフェンガーに感謝します。
The editors would like to thank Mohamed Boucadair, Neal Cardwell, Reese Enghardt, Jonathan Lennox, Matt Mathis, Zahed Sarker, Juergen Schoenwaelder, Dave Taht, Sean Turner, Michael Welzl, Magnus Westerlund, and Greg White for suggesting improvements to this document.
編集者は、Mohamed Boucadair、Neal Cardwell、Reese Enghardt、Jonathan Lennox、Matt Mathis、Zahed Sarker、Juergen Schoenwaelder、Dave Taht、Sean Turner、Michael Welzl、Magnus Westerlund、Greg Whiteに、この文書を改善してくれたことに感謝します。
Discussions with Lars Eggert and Aaron Falk seeded the original [RFC5033]. Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Colin Perkins, Pekka Savola, members of TSVWG, and participants at the TCP Workshop at Microsoft Research all provided feedback and contributions to that document. It also drew from [RFC5166].
Lars EggertとAaron Falkとの議論は、元の[RFC5033]をシードしました。ボブ・ブリスコ、ゴリー・フェアハースト、ダグ・リース、ジテンドラ・パディエ、コリン・パーキンス、ペッカ・サヴォラ、TSVWGのメンバー、およびMicrosoft ResearchのTCPワークショップの参加者はすべて、その文書にフィードバックと貢献を提供しました。また、[RFC5166]から引き出されました。
Christian Huitema
Private Octopus, Inc.
Email: huitema@huitema.net
Martin Duke (editor)
Google LLC
Email: martin.h.duke@gmail.com
Godred Fairhurst (editor)
University of Aberdeen
Email: gorry@erg.abdn.ac.uk