[要約] RFC 7567は、アクティブキューマネジメント（AQM）に関するIETFの推奨事項です。その目的は、ネットワークの遅延やパケットロスを管理し、トラフィックの公平性と効率性を向上させることです。
Internet Engineering Task Force (IETF) F. Baker, Ed.
Request for Comments: 7567 Cisco Systems
BCP: 197 G. Fairhurst, Ed.
Obsoletes: 2309 University of Aberdeen
Category: Best Current Practice July 2015
ISSN: 2070-1721
IETF Recommendations Regarding Active Queue Management
アクティブキュー管理に関するIETFの推奨事項
Abstract
概要
This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.
このメモは、インターネットのパフォーマンスを改善および維持するための対策に関するインターネットコミュニティへの推奨事項を示しています。今日のインターネットのパフォーマンスを向上させるために、ネットワークデバイスでアクティブキュー管理（AQM）をテスト、標準化、および広範囲に展開することを強く推奨します。また、輻輳通知に十分に応答しないフローからインターネットを保護するために、AQMメカニズムの調査、測定、および最終的な展開の協調した取り組みを促します。
Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.
15年間の経験と新しい研究に基づいて、このドキュメントはRFC 2309の推奨を置き換えます。
Status of This Memo
本文書の状態
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc7567.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7567で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Congestion Collapse . . . . . . . . . . . . . . . . . . . 4
1.2. Active Queue Management to Manage Latency . . . . . . . . 5
1.3. Document Overview . . . . . . . . . . . . . . . . . . . . 6
1.4. Changes to the Recommendations of RFC 2309 . . . . . . . 7
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. The Need for Active Queue Management . . . . . . . . . . . . 7
2.1. AQM and Multiple Queues . . . . . . . . . . . . . . . . . 11
2.2. AQM and Explicit Congestion Marking (ECN) . . . . . . . . 12
2.3. AQM and Buffer Size . . . . . . . . . . . . . . . . . . . 12
3. Managing Aggressive Flows . . . . . . . . . . . . . . . . . . 13
4. Conclusions and Recommendations . . . . . . . . . . . . . . . 16
4.1. Operational Deployments SHOULD Use AQM Procedures . . . . 17
4.2. Signaling to the Transport Endpoints . . . . . . . . . . 17
4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 18
4.3. AQM Algorithm Deployment SHOULD NOT Require Operational
Tuning . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. AQM Algorithms SHOULD Respond to Measured Congestion, Not
Application Profiles . . . . . . . . . . . . . . . . . . 21
4.5. AQM Algorithms SHOULD NOT Be Dependent on Specific
Transport Protocol Behaviors . . . . . . . . . . . . . . 22
4.6. Interactions with Congestion Control Algorithms . . . . . 22
4.7. The Need for Further Research . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
The Internet protocol architecture is based on a connectionless end-to-end packet service using the Internet Protocol, whether IPv4 [RFC791] or IPv6 [RFC2460]. The advantages of its connectionless design -- flexibility and robustness -- have been amply demonstrated. However, these advantages are not without cost: careful design is required to provide good service under heavy load. In fact, lack of attention to the dynamics of packet forwarding can result in severe service degradation or "Internet meltdown". This phenomenon was first observed during the early growth phase of the Internet in the mid 1980s [RFC896] [RFC970]; it is technically called "congestion collapse" and was a key focus of RFC 2309.
インターネットプロトコルアーキテクチャは、IPv4 [RFC791]とIPv6 [RFC2460]のどちらでも、インターネットプロトコルを使用したコネクションレスのエンドツーエンドパケットサービスに基づいています。コネクションレス設計の利点-柔軟性と堅牢性-は十分に実証されています。ただし、これらの利点にはコストがかからないわけではありません。高負荷で良好なサービスを提供するには、慎重な設計が必要です。実際、パケット転送のダイナミクスに注意が向けられていないと、サービスが著しく低下したり、「インターネットのメルトダウン」が発生する可能性があります。この現象は、1980年代半ばのインターネットの初期の成長段階で最初に観察されました[RFC896] [RFC970]。技術的には「輻輳崩壊」と呼ばれ、RFC 2309の主要な焦点でした。
Although wide-scale congestion collapse is not common in the Internet, the presence of localized congestion collapse is by no means rare. It is therefore important to continue to avoid congestion collapse.
大規模な輻輳崩壊はインターネットでは一般的ではありませんが、局所的な輻輳崩壊の存在は決して珍しいことではありません。したがって、渋滞の崩壊を回避し続けることが重要です。
Since 1998, when RFC 2309 was written, the Internet has become used for a variety of traffic. In the current Internet, low latency is extremely important for many interactive and transaction-based applications. The same type of technology that RFC 2309 advocated for combating congestion collapse is also effective at limiting delays to reduce the interaction delay (latency) experienced by applications [Bri15]. High or unpredictable latency can impact the performance of the control loops used by end-to-end protocols (including congestion control algorithms using TCP). There is now also a focus on reducing network latency using the same technology.
RFC 2309が作成された1998年以降、インターネットはさまざまなトラフィックに使用されるようになりました。現在のインターネットでは、多くの対話型およびトランザクションベースのアプリケーションにとって低遅延が非常に重要です。 RFC 2309が輻輳の崩壊に対抗するために提唱したのと同じタイプのテクノロジーは、アプリケーションが経験する相互作用遅延（レイテンシー）を減らすために遅延を制限するのにも効果的です[Bri15]。レイテンシが高い、または予測できない場合、エンドツーエンドプロトコル（TCPを使用した輻輳制御アルゴリズムを含む）で使用される制御ループのパフォーマンスに影響を与える可能性があります。現在、同じテクノロジーを使用してネットワーク遅延を削減することに焦点が当てられています。
The mechanisms described in this document may be implemented in network devices on the path between endpoints that include routers, switches, and other network middleboxes. The methods may also be implemented in the networking stacks within endpoint devices that connect to the network.
このドキュメントで説明されているメカニズムは、ルーター、スイッチ、およびその他のネットワークミドルボックスを含むエンドポイント間のパス上のネットワークデバイスに実装できます。これらの方法は、ネットワークに接続するエンドポイントデバイス内のネットワーキングスタックにも実装できます。
The original fix for Internet meltdown was provided by Van Jacobsen. Beginning in 1986, Jacobsen developed the congestion avoidance mechanisms [Jacobson88] that are now required for implementations of the Transport Control Protocol (TCP) [RFC793] [RFC1122]. ([RFC7414] provides a roadmap to help identify TCP-related documents.) These mechanisms operate in Internet hosts to cause TCP connections to "back off" during congestion. We say that TCP flows are "responsive" to congestion signals (i.e., packets that are dropped or marked with explicit congestion notification [RFC3168]). It is primarily these TCP congestion avoidance algorithms that prevent the congestion collapse of today's Internet. Similar algorithms are specified for other non-TCP transports.
インターネットメルトダウンの元の修正は、Van Jacobsenによって提供されました。 1986年から、Jacobsenは、トランスポートコントロールプロトコル（TCP）[RFC793] [RFC1122]の実装に現在必要な輻輳回避メカニズム[Jacobson88]を開発しました。 （[RFC7414]は、TCP関連のドキュメントを識別するのに役立つロードマップを提供します。）これらのメカニズムは、インターネットホストで動作して、輻輳時にTCP接続を「バックオフ」します。 TCPフローは輻輳信号（つまり、ドロップされるか、明示的な輻輳通知[RFC3168]でマークされたパケット）に「応答」すると私たちは言います。今日のインターネットの輻輳崩壊を防ぐのは、主にこれらのTCP輻輳回避アルゴリズムです。他の非TCPトランスポートについても、同様のアルゴリズムが指定されています。
However, that is not the end of the story. Considerable research has been done on Internet dynamics since 1988, and the Internet has grown. It has become clear that the congestion avoidance mechanisms [RFC5681], while necessary and powerful, are not sufficient to provide good service in all circumstances. Basically, there is a limit to how much control can be accomplished from the edges of the network. Some mechanisms are needed in network devices to complement the endpoint congestion avoidance mechanisms. These mechanisms may be implemented in network devices.
しかし、これで話は終わりではありません。 1988年以降、インターネットのダイナミクスに関してかなりの研究が行われ、インターネットは成長しています。輻輳回避メカニズム[RFC5681]は、必要かつ強力ですが、すべての状況で適切なサービスを提供するには十分ではないことが明らかになりました。基本的に、ネットワークのエッジから実行できる制御には制限があります。エンドポイントの輻輳回避メカニズムを補完するために、ネットワークデバイスにはいくつかのメカニズムが必要です。これらのメカニズムは、ネットワークデバイスに実装できます。
Internet latency has become a focus of attention to increase the responsiveness of Internet applications and protocols. One major source of delay is the buildup of queues in network devices. Queueing occurs whenever the arrival rate of data at the ingress to a device exceeds the current egress rate. Such queueing is normal in a packet-switched network and is often necessary to absorb bursts in transmission and perform statistical multiplexing of traffic, but excessive queueing can lead to unwanted delay, reducing the performance of some Internet applications.
インターネットの待ち時間は、インターネットのアプリケーションとプロトコルの応答性を向上させるための注目の的となっています。遅延の主な原因の1つは、ネットワークデバイスでのキューの蓄積です。キューイングは、デバイスへの入口でのデータの到着率が現在の出口率を超えるたびに発生します。このようなキューイングは、パケット交換ネットワークでは正常であり、送信のバーストを吸収し、トラフィックの統計的多重化を実行するためにしばしば必要ですが、過度のキューイングは、不要な遅延につながり、一部のインターネットアプリケーションのパフォーマンスを低下させる可能性があります。
RFC 2309 introduced the concept of "Active Queue Management" (AQM), a class of technologies that, by signaling to common congestion-controlled transports such as TCP, manages the size of queues that build in network buffers. RFC 2309 also describes a specific AQM algorithm, Random Early Detection (RED), and recommends that this be widely implemented and used by default in routers.
RFC 2309は「アクティブキュー管理」（AQM）の概念を導入しました。これは、TCPなどの一般的な輻輳制御トランスポートに信号を送ることにより、ネットワークバッファーに組み込まれたキューのサイズを管理するテクノロジーのクラスです。 RFC 2309は、特定のAQMアルゴリズムであるRandom Early Detection（RED）についても説明しており、これをルーターに広く実装してデフォルトで使用することを推奨しています。
With an appropriate set of parameters, RED is an effective algorithm. However, dynamically predicting this set of parameters was found to be difficult. As a result, RED has not been enabled by default, and its present use in the Internet is limited. Other AQM algorithms have been developed since RFC 2309 was published, some of which are self-tuning within a range of applicability. Hence, while this memo continues to recommend the deployment of AQM, it no longer recommends that RED or any other specific algorithm is used by default. It instead provides recommendations on IETF processes for the selection of appropriate algorithms, and especially that a recommended algorithm is able to automate any required tuning for common deployment scenarios.
REDは適切なパラメーターセットを備えた効果的なアルゴリズムです。ただし、このパラメーターのセットを動的に予測することは困難であることがわかりました。その結果、REDはデフォルトでは有効になっておらず、インターネットでの現在の使用は制限されています。 RFC 2309が公開されてから、他のAQMアルゴリズムが開発されており、その一部は適用範囲内で自動調整されます。したがって、このメモは引き続きAQMの導入を推奨しますが、REDまたはその他の特定のアルゴリズムをデフォルトで使用することを推奨しなくなりました。代わりに、適切なアルゴリズムを選択するためのIETFプロセスに関する推奨事項を提供します。特に、推奨されるアルゴリズムは、一般的な展開シナリオに必要なチューニングを自動化できることを示しています。
Deploying AQM in the network can significantly reduce the latency across an Internet path, and, since the writing of RFC 2309, this has become a key motivation for using AQM in the Internet. In the context of AQM, it is useful to distinguish between two related classes of algorithms: "queue management" versus "scheduling" algorithms. To a rough approximation, queue management algorithms manage the length of packet queues by marking or dropping packets when necessary or appropriate, while scheduling algorithms determine which packet to send next and are used primarily to manage the allocation of bandwidth among flows. While these two mechanisms are closely related, they address different performance issues and operate on different timescales. Both may be used in combination.
ネットワークにAQMを導入すると、インターネットパス全体のレイテンシを大幅に削減できます。また、RFC 2309の作成以来、これはインターネットでAQMを使用する主要な動機となっています。 AQMのコンテキストでは、「キュー管理」アルゴリズムと「スケジューリング」アルゴリズムの2つの関連するアルゴリズムクラスを区別すると便利です。概算として、キュー管理アルゴリズムは、必要または適切な場合にパケットをマークまたはドロップすることによってパケットキューの長さを管理し、スケジューリングアルゴリズムは次に送信するパケットを決定し、主にフロー間の帯域幅の割り当てを管理するために使用されます。これら2つのメカニズムは密接に関連していますが、異なるパフォーマンスの問題に対処し、異なるタイムスケールで動作します。両方を組み合わせて使用できます。
The discussion in this memo applies to "best-effort" traffic, which is to say, traffic generated by applications that accept the occasional loss, duplication, or reordering of traffic in flight. It also applies to other traffic, such as real-time traffic that can adapt its sending rate to reduce loss and/or delay. It is most effective when the adaption occurs on timescales of a single Round-Trip Time (RTT) or a small number of RTTs, for elastic traffic [RFC1633].
このメモの説明は、「ベストエフォート」トラフィック、つまり、飛行中のトラフィックの偶発的な損失、複製、または並べ替えを受け入れるアプリケーションによって生成されたトラフィックに適用されます。また、損失や遅延を減らすために送信レートを調整できるリアルタイムトラフィックなど、他のトラフィックにも適用されます。適応性のあるトラフィックの場合、適応が単一のラウンドトリップ時間（RTT）または少数のRTTのタイムスケールで発生する場合に最も効果的です[RFC1633]。
Two performance issues are highlighted:
2つのパフォーマンスの問題が強調表示されています。
The first issue is the need for an advanced form of queue management that we call "Active Queue Management", AQM. Section 2 summarizes the benefits that active queue management can bring. A number of AQM procedures are described in the literature, with different characteristics. This document does not recommend any of them in particular, but it does make recommendations that ideally would affect the choice of procedure used in a given implementation.
最初の問題は、「アクティブキュー管理」と呼ばれるAQMと呼ばれる高度な形式のキュー管理の必要性です。セクション2では、アクティブなキュー管理がもたらすメリットをまとめています。多くのAQM手順が、さまざまな特性を備えた文献に記載されています。このドキュメントでは、これらのいずれも特に推奨していませんが、特定の実装で使用される手順の選択に理想的に影響する推奨事項を示しています。
The second issue, discussed in Section 4 of this memo, is the potential for future congestion collapse of the Internet due to flows that are unresponsive, or not sufficiently responsive, to congestion indications. Unfortunately, while scheduling can mitigate some of the side effects of sharing a network queue with an unresponsive flow, there is currently no consensus solution to controlling the congestion caused by such aggressive flows. Methods such as congestion exposure (ConEx) [RFC6789] offer a framework [CONEX] that can update network devices to alleviate these effects. Significant research and engineering will be required before any solution will be available. It is imperative that work to mitigate the impact of unresponsive flows is energetically pursued to ensure acceptable performance and the future stability of the Internet.
このメモのセクション4で説明されている2番目の問題は、輻輳の表示に応答しない、または十分に応答しないフローが原因で、将来のインターネットの輻輳崩壊の可能性です。残念ながら、スケジューリングにより、応答しないフローとネットワークキューを共有することによるいくつかの副作用を軽減できますが、現在、このような攻撃的なフローによって引き起こされる輻輳を制御するコンセンサスソリューションはありません。輻輳露出（ConEx）[RFC6789]などの方法は、ネットワークデバイスを更新してこれらの影響を軽減できるフレームワーク[CONEX]を提供します。ソリューションを利用するには、かなりの研究とエンジニアリングが必要です。インターネットの許容可能なパフォーマンスと将来の安定性を確保するために、無応答フローの影響を軽減するための作業を精力的に追求することが不可欠です。
Section 4 concludes the memo with a set of recommendations to the Internet community on the use of AQM and recommendations for defining AQM algorithms.
セクション4は、AQMの使用に関するインターネットコミュニティへの一連の推奨事項と、AQMアルゴリズムを定義するための推奨事項でメモを締めくくります。
This memo replaces the recommendations in [RFC2309], which resulted from past discussions of end-to-end performance, Internet congestion, and RED in the End-to-End Research Group of the Internet Research Task Force (IRTF). It results from experience with RED and other algorithms, and the AQM discussion within the IETF [AQM-WG].
このメモは、エンドツーエンドのパフォーマンス、インターネットの輻輳、およびインターネット研究タスクフォース（IRTF）のエンドツーエンドの研究グループにおけるREDの過去の議論から生じた[RFC2309]の推奨に取って代わります。これは、REDやその他のアルゴリズムの経験、およびIETF [AQM-WG]内でのAQMの議論の結果です。
Whereas RFC 2309 described AQM in terms of the length of a queue, this memo uses AQM to refer to any method that allows network devices to control the queue length and/or the mean time that a packet spends in a queue.
RFC 2309はAQMをキューの長さに関して記述していましたが、このメモはAQMを使用して、ネットワークデバイスがキューの長さやパケットがキューで費やす平均時間を制御できるようにする方法を示しています。
This memo also explicitly obsoletes the recommendation that Random Early Detection (RED) be used as the default AQM mechanism for the Internet. This is replaced by a detailed set of recommendations for selecting an appropriate AQM algorithm. As in RFC 2309, this memo illustrates the need for continued research. It also clarifies the research needed with examples appropriate at the time that this memo is published.
また、このメモは、ランダム早期検出（RED）をインターネットのデフォルトのAQMメカニズムとして使用することを推奨するものではありません。これは、適切なAQMアルゴリズムを選択するための詳細な推奨セットに置き換えられます。 RFC 2309と同様に、このメモは継続的な調査の必要性を示しています。また、このメモが発行された時点で適切な例を使用して、必要な研究を明らかにしています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Active Queue Management (AQM) is a method that allows network devices to control the queue length or the mean time that a packet spends in a queue. Although AQM can be applied across a range of deployment environments, the recommendations in this document are for use in the general Internet. It is expected that the principles and guidance are also applicable to a wide range of environments, but they may require tuning for specific types of links or networks (e.g., to accommodate the traffic patterns found in data centers, the challenges of wireless infrastructure, or the higher delay encountered on satellite Internet links). The remainder of this section identifies the need for AQM and the advantages of deploying AQM methods.
アクティブキュー管理（AQM）は、ネットワークデバイスがキューの長さまたはパケットがキューに費やす平均時間を制御できるようにする方法です。 AQMはさまざまな展開環境に適用できますが、このドキュメントの推奨事項は、一般的なインターネットでの使用を対象としています。原則とガイダンスはさまざまな環境にも適用できると予想されますが、特定のタイプのリンクまたはネットワークの調整が必要になる場合があります（たとえば、データセンターで見られるトラフィックパターン、ワイヤレスインフラストラクチャの課題、または衛星インターネットリンクで発生する高い遅延）。このセクションの残りの部分では、AQMの必要性と、AQMメソッドを展開する利点を示します。
The traditional technique for managing the queue length in a network device is to set a maximum length (in terms of packets) for each queue, accept packets for the queue until the maximum length is reached, then reject (drop) subsequent incoming packets until the queue decreases because a packet from the queue has been transmitted. This technique is known as "tail drop", since the packet that arrived most recently (i.e., the one on the tail of the queue) is dropped when the queue is full. This method has served the Internet well for years, but it has four important drawbacks:
ネットワークデバイスでキューの長さを管理する従来の手法は、各キューの最大長（パケット単位）を設定し、最大長に達するまでキューのパケットを受け入れ、その後、次の着信パケットを拒否（ドロップ）することです。キューからのパケットが送信されたため、キューは減少します。キューがいっぱいになると、最後に到着したパケット（つまり、キューの末尾にあるパケット）がドロップされるため、この手法は「テールドロップ」と呼ばれます。この方法は何年もの間インターネットに役立ってきましたが、4つの重要な欠点があります。
1. Full Queues
1. 完全なキュー
The "tail drop" discipline allows queues to maintain a full (or, almost full) status for long periods of time, since tail drop signals congestion (via a packet drop) only when the queue has become full. It is important to reduce the steady-state queue size, and this is perhaps the most important goal for queue management.
「テールドロップ」規則では、キューがいっぱいになった場合にのみ（パケットドロップを介して）輻輳が通知されるため、キューは長期間フル（またはほぼフル）ステータスを維持できます。定常状態のキューのサイズを減らすことが重要であり、これはおそらくキュー管理の最も重要な目標です。
The naive assumption might be that there is a simple trade-off between delay and throughput, and that the recommendation that queues be maintained in a "non-full" state essentially translates to a recommendation that low end-to-end delay is more important than high throughput. However, this does not take into account the critical role that packet bursts play in Internet performance. For example, even though TCP constrains the congestion window of a flow, packets often arrive at network devices in bursts [Leland94]. If the queue is full or almost full, an arriving burst will cause multiple packets to be dropped from the same flow. Bursts of loss can result in a global synchronization of flows throttling back, followed by a sustained period of lowered link utilization, reducing overall throughput [Flo94] [Zha90].
単純な仮定は、遅延とスループットの間に単純なトレードオフがあること、およびキューが「非満杯」状態で維持されるという推奨事項は、本質的に低いエンドツーエンドの遅延がより重要であるという推奨事項に変換されるということかもしれません高スループットより。ただし、これはインターネットパフォーマンスでパケットバーストが果たす重要な役割を考慮していません。たとえば、TCPがフローの輻輳ウィンドウを抑制していても、パケットはバーストでネットワークデバイスに到着することがよくあります[Leland94]。キューが満杯またはほぼ満杯の場合、バーストが到着すると、同じフローから複数のパケットがドロップされます。バーストの損失により、フローのグローバルな同期が抑制され、その後、リンクの使用率が低下した状態が続くため、全体的なスループットが低下します[Flo94] [Zha90]。
The goal of buffering in the network is to absorb data bursts and to transmit them during the (hopefully) ensuing bursts of silence. This is essential to permit transmission of bursts of data. Queues that are normally small are preferred in network devices, with sufficient queue capacity to absorb the bursts. The counterintuitive result is that maintaining queues that are normally small can result in higher throughput as well as lower end-to-end delay. In summary, queue limits should not reflect the steady-state queues we want to be maintained in the network; instead, they should reflect the size of bursts that a network device needs to absorb.
ネットワークでのバッファリングの目的は、データバーストを吸収し、（できれば）続く無音のバースト中にそれらを送信することです。これは、データのバーストの送信を許可するために不可欠です。バーストを吸収するのに十分なキュー容量があるネットワークデバイスでは、通常は小さいキューが推奨されます。直感に反する結果として、通常は小さいキューを維持すると、スループットが向上するだけでなく、エンドツーエンドの遅延も減少します。要約すると、キューの制限は、ネットワークで維持したい定常状態のキューを反映すべきではありません。代わりに、ネットワークデバイスが吸収する必要があるバーストのサイズを反映する必要があります。
2. Lock-Out
2. ロックアウト
In some situations tail drop allows a single connection or a few flows to monopolize the queue space, thereby starving other connections, preventing them from getting room in the queue [Flo92].
場合によっては、テールドロップにより、単一の接続またはいくつかのフローがキュースペースを独占するため、他の接続が不足し、キューにスペースが確保されなくなります[Flo92]。
3. Mitigating the Impact of Packet Bursts
3. パケットバーストの影響の軽減
A large burst of packets can delay other packets, disrupting the control loop (e.g., the pacing of flows by the TCP ACK clock), and reducing the performance of flows that share a common bottleneck.
パケットのバーストが大きいと、他のパケットが遅延し、制御ループが中断され（TCP ACKクロックによるフローのペーシングなど）、共通のボトルネックを共有するフローのパフォーマンスが低下します。
4. Control Loop Synchronization
4. 制御ループ同期
Congestion control, like other end-to-end mechanisms, introduces a control loop between hosts. Sessions that share a common network bottleneck can therefore become synchronized, introducing periodic disruption (e.g., jitter/loss). "Lock-out" is often also the result of synchronization or other timing effects
輻輳制御は、他のエンドツーエンドメカニズムと同様に、ホスト間に制御ループを導入します。したがって、共通のネットワークボトルネックを共有するセッションが同期され、定期的な中断（ジッター/損失など）が発生する可能性があります。 「ロックアウト」は、多くの場合、同期または他のタイミング効果の結果でもあります
Besides tail drop, two alternative queue management disciplines that can be applied when a queue becomes full are "random drop on full" or "head drop on full". When a new packet arrives at a full queue using the "random drop on full" discipline, the network device drops a randomly selected packet from the queue (this can be an expensive operation, since it naively requires an O(N) walk through the packet queue). When a new packet arrives at a full queue using the "head drop on full" discipline, the network device drops the packet at the front of the queue [Lakshman96]. Both of these solve the lock-out problem, but neither solves the full-queues problem described above.
テールドロップの他に、キューがいっぱいになったときに適用できる2つの代替キュー管理の専門分野は、「ランダムフルドロップ」または「ヘッドドロップフル」です。新しいパケットが「ランダムドロップオンフル」の規則を使用してフルキューに到着すると、ネットワークデバイスはランダムに選択されたパケットをキューからドロップします（これは、単純にO（N）ウォークスルーが必要なため、コストのかかる操作になる可能性があります。パケットキュー）。新しいパケットが「head drop on full」規則を使用してフルキューに到着すると、ネットワークデバイスはキューの先頭にあるパケットをドロップします[Lakshman96]。これらはどちらもロックアウトの問題を解決しますが、上記の完全なキューの問題も解決しません。
In general, we know how to solve the full-queues problem for "responsive" flows, i.e., those flows that throttle back in response to congestion notification. In the current Internet, dropped packets provide a critical mechanism indicating congestion notification to hosts. The solution to the full-queues problem is for network devices to drop or ECN-mark packets before a queue becomes full, so that hosts can respond to congestion before buffers overflow. We call such a proactive approach AQM. By dropping or ECN-marking packets before buffers overflow, AQM allows network devices to control when and how many packets to drop.
一般に、「応答」フロー、つまり、輻輳通知に応答してスロットルを戻すフローのキューがいっぱいになる問題を解決する方法はわかっています。現在のインターネットでは、ドロップされたパケットは、ホストへの輻輳通知を示す重要なメカニズムを提供します。キューがいっぱいになる問題の解決策は、キューがいっぱいになる前にネットワークデバイスがパケットをドロップするかECNマークを付けて、バッファがオーバーフローする前にホストが輻輳に対応できるようにすることです。このようなプロアクティブなアプローチをAQMと呼びます。バッファーがオーバーフローする前にパケットをドロップまたはECNマーキングすることにより、AQMはネットワークデバイスがドロップするパケットのタイミングと数を制御できるようにします。
In summary, an active queue management mechanism can provide the following advantages for responsive flows.
要約すると、アクティブなキュー管理メカニズムは、応答フローに次の利点を提供できます。
1. Reduce number of packets dropped in network devices
1. ネットワークデバイスでドロップされるパケットの数を減らす
Packet bursts are an unavoidable aspect of packet networks [Willinger95]. If all the queue space in a network device is already committed to "steady-state" traffic or if the buffer space is inadequate, then the network device will have no ability to buffer bursts. By keeping the average queue size small, AQM will provide greater capacity to absorb naturally occurring bursts without dropping packets.
パケットバーストはパケットネットワークの避けられない側面です[Willinger95]。ネットワークデバイスのすべてのキュースペースが「定常状態」トラフィックにすでにコミットされている場合、またはバッファスペースが不十分な場合、ネットワークデバイスはバーストをバッファリングすることができません。 AQMは、平均キューサイズを小さく保つことで、パケットをドロップすることなく、自然に発生するバーストを吸収する大きな容量を提供します。
Furthermore, without AQM, more packets will be dropped when a queue does overflow. This is undesirable for several reasons. First, with a shared queue and the "tail drop" discipline, this can result in unnecessary global synchronization of flows, resulting in lowered average link utilization and, hence, lowered network throughput. Second, unnecessary packet drops represent a waste of network capacity on the path before the drop point.
さらに、AQMがないと、キューがオーバーフローしたときに、より多くのパケットがドロップされます。これは、いくつかの理由で望ましくありません。まず、共有キューと「テールドロップ」規則を使用すると、フローの不要なグローバル同期が発生し、平均リンク使用率が低下するため、ネットワークスループットが低下します。第2に、不要なパケットドロップは、ドロップポイントの前のパス上のネットワーク容量の浪費を表しています。
While AQM can manage queue lengths and reduce end-to-end latency even in the absence of end-to-end congestion control, it will be able to reduce packet drops only in an environment that continues to be dominated by end-to-end congestion control.
AQMはキューの長さを管理し、エンドツーエンドの輻輳制御がない場合でもエンドツーエンドのレイテンシを削減できますが、エンドツーエンドが支配し続ける環境でのみパケットドロップを削減できます。輻輳制御。
2. Provide a lower-delay interactive service
2. 遅延の少ないインタラクティブサービスを提供する
By keeping a small average queue size, AQM will reduce the delays experienced by flows. This is particularly important for interactive applications such as short web transfers, POP/IMAP, DNS, terminal traffic (Telnet, SSH, Mosh, RDP, etc.), gaming or interactive audio-video sessions, whose subjective (and objective) performance is better when the end-to-end delay is low.
AQMは、平均キューサイズを小さく保つことで、フローで発生する遅延を減らします。これは、短いWeb転送、POP / IMAP、DNS、ターミナルトラフィック（Telnet、SSH、Mosh、RDPなど）、ゲームまたはインタラクティブオーディオビデオセッションなどの主観的（および目的）パフォーマンスがインタラクティブなアプリケーションで特に重要です。エンドツーエンドの遅延が少ない場合に適しています。
3. Avoid lock-out behavior
3. ロックアウト動作を回避する
AQM can prevent lock-out behavior by ensuring that there will almost always be a buffer available for an incoming packet. For the same reason, AQM can prevent a bias against low-capacity, but highly bursty, flows.
AQMは、ほとんどの場合、着信パケットに使用可能なバッファーがあることを保証することにより、ロックアウト動作を防止できます。同じ理由で、AQMは、低容量ではあるがバースト性の高いフローに対するバイアスを防止できます。
Lock-out is undesirable because it constitutes a gross unfairness among groups of flows. However, we stop short of calling this benefit "increased fairness", because general fairness among flows requires per-flow state, which is not provided by queue management. For example, in a network device using AQM with only FIFO scheduling, two TCP flows may receive very different shares of the network capacity simply because they have different RTTs [Floyd91], and a flow that does not use congestion control may receive more capacity than a flow that does. AQM can therefore be combined with a scheduling mechanism that divides network traffic between multiple queues (Section 2.1).
ロックアウトは、フローのグループ間で大きな不公平を構成するため、望ましくありません。ただし、フロー間の一般的な公平性にはフローごとの状態が必要であり、これはキュー管理では提供されないため、この利点を「公平性の向上」とは言い切れません。たとえば、FIFOスケジューリングのみのAQMを使用するネットワークデバイスでは、2つのTCPフローが異なるRTT [Floyd91]を持っているという理由だけで、ネットワーク容量の非常に異なるシェアを受け取り、輻輳制御を使用しないフローは、するフロー。したがって、AQMは、ネットワークトラフィックを複数のキューに分割するスケジューリングメカニズムと組み合わせることができます（セクション2.1）。
4. Reduce the probability of control loop synchronization
4. 制御ループ同期の可能性を減らす
The probability of network control loop synchronization can be reduced if network devices introduce randomness in the AQM functions that trigger congestion avoidance at the sending host.
送信側ホストで輻輳回避をトリガーするAQM機能にネットワークデバイスがランダム性を導入する場合、ネットワーク制御ループ同期の確率を減らすことができます。
A network device may use per-flow or per-class queueing with a scheduling algorithm to either prioritize certain applications or classes of traffic, limit the rate of transmission, or provide isolation between different traffic flows within a common class. For example, a router may maintain per-flow state to achieve general fairness by a per-flow scheduling algorithm such as various forms of Fair Queueing (FQ) [Dem90] [Sut99], including Weighted Fair Queueing (WFQ), Stochastic Fairness Queueing (SFQ) [McK90], Deficit Round Robin (DRR) [Shr96] [Nic12], and/or a Class-Based Queue scheduling algorithm such as CBQ [Floyd95]. Hierarchical queues may also be used, e.g., as a part of a Hierarchical Token Bucket (HTB) or Hierarchical Fair Service Curve (HFSC) [Sto97]. These methods are also used to realize a range of Quality of Service (QoS) behaviors designed to meet the need of traffic classes (e.g., using the integrated or differentiated service models).
ネットワークデバイスは、スケジューリングアルゴリズムでフローごとまたはクラスごとのキューイングを使用して、特定のアプリケーションまたはトラフィックのクラスに優先順位を付けるか、伝送速度を制限するか、または共通のクラス内の異なるトラフィックフロー間の分離を提供します。たとえば、ルーターはフローごとの状態を維持して、さまざまな形式のフェアキューイング（FQ）[Dem90] [Sut99]などのフローごとのスケジューリングアルゴリズムによって、重み付けされたフェアキューイング（WFQ）、確率的フェアネスキューイングなどの一般的な公平性を実現します。 （SFQ）[McK90]、Deficit Round Robin（DRR）[Shr96] [Nic12]、および/またはCBQ [Floyd95]などのクラスベースのキュースケジューリングアルゴリズム。階層型キューは、たとえば、階層型トークンバケット（HTB）または階層型フェアサービスカーブ（HFSC）[Sto97]の一部としても使用できます。これらの方法は、トラフィッククラスのニーズを満たすように設計された一連のサービス品質（QoS）動作を実現するためにも使用されます（統合または差別化されたサービスモデルを使用するなど）。
AQM is needed even for network devices that use per-flow or per-class queueing, because scheduling algorithms by themselves do not control the overall queue size or the sizes of individual queues. AQM mechanisms might need to control the overall queue sizes to ensure that arriving bursts can be accommodated without dropping packets. AQM should also be used to control the queue size for each individual flow or class, so that they do not experience unnecessarily high delay. Using a combination of AQM and scheduling between multiple queues has been shown to offer good results in experimental use and some types of operational use.
AQMは、フローごとまたはクラスごとのキューイングを使用するネットワークデバイスでも必要です。これは、スケジューリングアルゴリズム自体では全体のキューサイズや個々のキューのサイズを制御しないためです。 AQMメカニズムは、パケットをドロップせずに到着するバーストに対応できるように、全体的なキューサイズを制御する必要がある場合があります。また、AQMを使用して、個々のフローまたはクラスのキューサイズを制御し、不必要に大きな遅延が発生しないようにする必要があります。 AQMと複数のキュー間のスケジューリングの組み合わせを使用すると、実験的使用や一部のタイプの運用上の使用で良好な結果が得られることが示されています。
In short, scheduling algorithms and queue management should be seen as complementary, not as replacements for each other.
要するに、スケジューリングアルゴリズムとキュー管理は、互いの代替としてではなく、補完的なものとして見なされるべきです。
An AQM method may use Explicit Congestion Notification (ECN) [RFC3168] instead of dropping to mark packets under mild or moderate congestion. ECN-marking can allow a network device to signal congestion at a point before a transport experiences congestion loss or additional queueing delay [ECN-Benefit]. Section 4.2.1 describes some of the benefits of using ECN with AQM.
AQMメソッドは、ドロップする代わりに、明示的輻輳通知（ECN）[RFC3168]を使用して、軽度または中程度の輻輳の下でパケットをマークします。 ECNマーキングを使用すると、トランスポートが輻輳損失または追加のキューイング遅延を経験する前に、ネットワークデバイスが輻輳を通知できます[ECN-Benefit]。セクション4.2.1では、AQMでECNを使用する利点のいくつかについて説明します。
It is important to differentiate the choice of buffer size for a queue in a switch/router or other network device, and the threshold(s) and other parameters that determine how and when an AQM algorithm operates. The optimum buffer size is a function of operational requirements and should generally be sized to be sufficient to buffer the largest normal traffic burst that is expected. This size depends on the amount and burstiness of traffic arriving at the queue and the rate at which traffic leaves the queue.
スイッチ/ルーターまたはその他のネットワークデバイスのキューのバッファーサイズの選択、およびAQMアルゴリズムの動作方法とタイミングを決定するしきい値およびその他のパラメーターを区別することが重要です。最適なバッファサイズは運用要件の関数であり、通常、予想される最大の通常のトラフィックバーストをバッファリングするのに十分なサイズにする必要があります。このサイズは、キューに到着するトラフィックの量とバースト性、およびトラフィックがキューを出る速度によって異なります。
One objective of AQM is to minimize the effect of lock-out, where one flow prevents other flows from effectively gaining capacity. This need can be illustrated by a simple example of drop-tail queueing when a new TCP flow injects packets into a queue that happens to be almost full. A TCP flow's congestion control algorithm [RFC5681] increases the flow rate to maximize its effective window. This builds a queue in the network, inducing latency in the flow and other flows that share this queue. Once a drop-tail queue fills, there will also be loss. A new flow, sending its initial burst, has an enhanced probability of filling the remaining queue and dropping packets. As a result, the new flow can be prevented from effectively sharing the queue for a period of many RTTs. In contrast, AQM can minimize the mean queue depth and therefore reduce the probability that competing sessions can materially prevent each other from performing well.
AQMの目的の1つは、ロックアウトの影響を最小限に抑えることです。この場合、1つのフローが他のフローによる容量の効果的な獲得を妨げます。この必要性は、新しいTCPフローがたまたまほぼ満杯になっているキューにパケットを注入するときのドロップテールキューイングの簡単な例で説明できます。 TCPフローの輻輳制御アルゴリズム[RFC5681]は、フローレートを上げて有効ウィンドウを最大化します。これにより、ネットワーク内にキューが構築され、このキューを共有するフローおよびその他のフローに遅延が発生します。ドロップテールキューがいっぱいになると、損失も発生します。初期バーストを送信する新しいフローでは、残りのキューがいっぱいになり、パケットがドロップされる可能性が高くなります。その結果、新しいフローが多くのRTTの期間にわたってキューを効果的に共有することを防ぐことができます。対照的に、AQMは平均キュー深度を最小限に抑えることができるため、競合するセッションが互いに実質的なパフォーマンスを妨げる可能性を低減できます。
AQM frees a designer from having to limit the buffer space assigned to a queue to achieve acceptable performance, allowing allocation of sufficient buffering to satisfy the needs of the particular traffic pattern. Different types of traffic and deployment scenarios will lead to different requirements. The choice of AQM algorithm and associated parameters is therefore a function of the way in which congestion is experienced and the required reaction to achieve acceptable performance. The latter is the primary topic of the following sections.
AQMを使用すると、設計者はキューに割り当てられたバッファースペースを制限する必要がなくなり、許容可能なパフォーマンスを実現できるため、特定のトラフィックパターンのニーズを満たすのに十分なバッファーを割り当てることができます。トラフィックのタイプと展開シナリオが異なると、要件も異なります。したがって、AQMアルゴリズムと関連パラメーターの選択は、輻輳が発生する方法と、許容可能なパフォーマンスを達成するために必要な反応の関数です。後者は、以下のセクションの主要なトピックです。
One of the keys to the success of the Internet has been the congestion avoidance mechanisms of TCP. Because TCP "backs off" during congestion, a large number of TCP connections can share a single, congested link in such a way that link bandwidth is shared reasonably equitably among similarly situated flows. The equitable sharing of bandwidth among flows depends on all flows running compatible congestion avoidance algorithms, i.e., methods conformant with the current TCP specification [RFC5681].
インターネットの成功の鍵の1つは、TCPの輻輳回避メカニズムです。 TCPは輻輳時に「バックオフ」するので、多数のTCP接続が単一の輻輳したリンクを共有して、同様に配置されたフロー間でリンク帯域幅が公平に共有されるようにすることができます。フロー間での帯域幅の公平な共有は、互換性のある輻輳回避アルゴリズムを実行しているすべてのフロー、つまり、現在のTCP仕様[RFC5681]に準拠した方法に依存します。
In this document, a flow is known as "TCP-friendly" when it has a congestion response that approximates the average response expected of a TCP flow. One example method of a TCP-friendly scheme is the TCP-Friendly Rate Control algorithm [RFC5348]. In this document, the term is used more generally to describe this and other algorithms that meet these goals.
このドキュメントでは、TCPフローで予想される平均応答に近い輻輳応答がある場合、そのフローは「TCPフレンドリー」と呼ばれます。 TCPに適したスキームの1つの例の方法は、TCPに適したレート制御アルゴリズム[RFC5348]です。このドキュメントでは、この用語は、より一般的に、このアルゴリズムとこれらの目標を満たす他のアルゴリズムを説明するために使用されます。
There are a variety of types of network flow. Some convenient classes that describe flows are: (1) TCP-friendly flows, (2) unresponsive flows, i.e., flows that do not slow down when congestion occurs, and (3) flows that are responsive but are less responsive to congestion than TCP. The last two classes contain more aggressive flows that can pose significant threats to Internet performance.
ネットワークフローにはさまざまなタイプがあります。フローを説明する便利なクラスには、（1）TCP対応のフロー、（2）応答のないフロー、つまり、輻輳が発生してもスローダウンしないフロー、および（3）応答するが、TCPよりも輻輳に対する応答が遅いフローがあります。 。最後の2つのクラスには、インターネットのパフォーマンスに重大な脅威をもたらす可能性のある攻撃的なフローが含まれています。
1. TCP-friendly flows
1. TCPフレンドリーなフロー
A TCP-friendly flow responds to congestion notification within a small number of path RTTs, and in steady-state it uses no more capacity than a conformant TCP running under comparable conditions (drop rate, RTT, packet size, etc.). This is described in the remainder of the document.
TCPフレンドリフローは、少数のパスRTT内の輻輳通知に応答し、定常状態では、同等の条件（ドロップレート、RTT、パケットサイズなど）で実行されている適合TCPよりも多くの容量を使用しません。これはドキュメントの残りの部分で説明されています。
2. Non-responsive flows
2. 応答しないフロー
A non-responsive flow does not adjust its rate in response to congestion notification within a small number of path RTTs; it can also use more capacity than a conformant TCP running under comparable conditions. There is a growing set of applications whose congestion avoidance algorithms are inadequate or nonexistent (i.e., a flow that does not throttle its sending rate when it experiences congestion).
非応答フローは、少数のパスRTT内の輻輳通知に応答してそのレートを調整しません。また、同等の条件下で動作する適合TCPよりも多くの容量を使用できます。輻輳回避アルゴリズムが不十分または存在しないアプリケーションのセットが増えています（つまり、輻輳が発生したときに送信レートを抑制しないフロー）。
The User Datagram Protocol (UDP) [RFC768] provides a minimal, best-effort transport to applications and upper-layer protocols (both simply called "applications" in the remainder of this document) and does not itself provide mechanisms to prevent congestion collapse or establish a degree of fairness [RFC5405].
ユーザーデータグラムプロトコル（UDP）[RFC768]は、アプリケーションと上位層プロトコル（このドキュメントの残りの部分では単に "アプリケーション"と呼びます）への最小限のベストエフォート転送を提供し、それ自体は輻輳の崩壊やある程度の公平性を確立する[RFC5405]。
Examples that use UDP include some streaming applications for packet voice and video, and some multicast bulk data transport. Other traffic, when aggregated, may also become unresponsive to congestion notification. If no action is taken, such unresponsive flows could lead to a new congestion collapse [RFC2914]. Some applications can even increase their traffic volume in response to congestion (e.g., by adding Forward Error Correction when loss is experienced), with the possibility that they contribute to congestion collapse.
UDPを使用する例には、パケット音声およびビデオ用のストリーミングアプリケーション、およびマルチキャストバルクデータ転送があります。他のトラフィックも、集約されると、輻輳通知に応答しなくなる可能性があります。アクションが取られない場合、そのような応答のないフローは、新しい輻輳の崩壊につながる可能性があります[RFC2914]。一部のアプリケーションは、輻輳に対応してトラフィック量を増やすこともでき（たとえば、損失が発生したときに転送エラー訂正を追加することにより）、輻輳の崩壊に寄与する可能性があります。
In general, applications need to incorporate effective congestion avoidance mechanisms [RFC5405]. Research continues to be needed to identify and develop ways to accomplish congestion avoidance for presently unresponsive applications. Network devices need to be able to protect themselves against unresponsive flows, and mechanisms to accomplish this must be developed and deployed. Deployment of such mechanisms would provide an incentive for all applications to become responsive by either using a congestion-controlled transport (e.g., TCP, SCTP [RFC4960], and DCCP [RFC4340]) or incorporating their own congestion control in the application [RFC5405] [RFC6679].
一般に、アプリケーションは効果的な輻輳回避メカニズムを組み込む必要があります[RFC5405]。現在応答していないアプリケーションの輻輳回避を実現する方法を特定して開発するための研究が引き続き必要です。ネットワークデバイスは、応答のないフローから自分自身を保護できる必要があり、これを実現するメカニズムを開発して展開する必要があります。このようなメカニズムを導入すると、輻輳制御のトランスポート（TCP、SCTP [RFC4960]、DCCP [RFC4340]など）を使用するか、独自の輻輳制御をアプリケーションに組み込む[RFC5405]ことにより、すべてのアプリケーションが応答可能になるインセンティブが提供されます。 [RFC6679]。
3. Transport flows that are less responsive than TCP
3. TCPよりも応答が遅いトランスポートフロー
A second threat is posed by transport protocol implementations that are responsive to congestion, but, either deliberately or through faulty implementation, reduce the effective window less than a TCP flow would have done in response to congestion. This covers a spectrum of behaviors between (1) and (2). If applications are not sufficiently responsive to congestion signals, they may gain an unfair share of the available network capacity.
2番目の脅威は、輻輳に応答するトランスポートプロトコルの実装によってもたらされますが、故意にまたは誤った実装によって、輻輳に対応してTCPフローが行うよりも効果的なウィンドウを減らします。これは、（1）と（2）の間の動作のスペクトルをカバーします。アプリケーションが輻輳信号に十分に応答しない場合、アプリケーションは利用可能なネットワーク容量の不公平なシェアを獲得する可能性があります。
For example, the popularity of the Internet has caused a proliferation in the number of TCP implementations. Some of these may fail to implement the TCP congestion avoidance mechanisms correctly because of poor implementation. Others may deliberately be implemented with congestion avoidance algorithms that are more aggressive in their use of capacity than other TCP implementations; this would allow a vendor to claim to have a "faster TCP". The logical consequence of such implementations would be a spiral of increasingly aggressive TCP implementations, leading back to the point where there is effectively no congestion avoidance and the Internet is chronically congested.
たとえば、インターネットの人気により、TCP実装の数が急増しています。これらの一部は、実装が不十分なため、TCP輻輳回避メカニズムを正しく実装できない場合があります。他のものは、他のTCP実装よりも容量の使用においてより積極的な輻輳回避アルゴリズムで意図的に実装される場合があります。これにより、ベンダーは「より高速なTCP」を要求できるようになります。このような実装の論理的な結果は、ますます攻撃的なTCP実装のスパイラルとなり、輻輳回避が事実上なく、インターネットが慢性的に輻輳する点に戻ります。
Another example could be an RTP/UDP video flow that uses an adaptive codec, but responds incompletely to indications of congestion or responds over an excessively long time period.
別の例としては、アダプティブコーデックを使用するRTP / UDPビデオフローがありますが、輻輳の兆候に不完全に応答するか、過度に長い時間応答します。
Such flows are unlikely to be responsive to congestion signals in a time frame comparable to a small number of end-to-end transmission delays. However, over a longer timescale, perhaps seconds in duration, they could moderate their speed, or increase their speed if they determine capacity to be available.
このようなフローは、少数のエンドツーエンドの伝送遅延に匹敵する時間枠内の輻輳信号に応答しそうにありません。ただし、より長いタイムスケール（おそらく持続時間は数秒）で、速度を調整したり、使用可能な容量を決定した場合は速度を上げたりできます。
Tunneled traffic aggregates carrying multiple (short) TCP flows can be more aggressive than standard bulk TCP. Applications (e.g., web browsers primarily supporting HTTP 1.1 and peer-to-peer file-sharing) have exploited this by opening multiple connections to the same endpoint.
複数の（短い）TCPフローを伝送するトンネルトラフィック集約は、標準のバルクTCPよりも攻撃的である可能性があります。アプリケーション（たとえば、主にHTTP 1.1とピアツーピアファイル共有をサポートするWebブラウザー）は、同じエンドポイントへの複数の接続を開くことでこれを悪用しました。
Lastly, some applications (e.g., web browsers primarily supporting HTTP 1.1) open a large numbers of successive short TCP flows for a single session. This can lead to each individual flow spending the majority of time in the exponential TCP slow start phase, rather than in TCP congestion avoidance. The resulting traffic aggregate can therefore be much less responsive than a single standard TCP flow.
最後に、一部のアプリケーション（たとえば、主にHTTP 1.1をサポートするWebブラウザー）は、1つのセッションに対して多数の連続した短いTCPフローを開きます。これにより、個々のフローがTCPの輻輳回避ではなく、指数TCPスロースタートフェーズで大部分の時間を費やすことになります。したがって、結果のトラフィック集約は、単一の標準TCPフローよりもはるかに応答が遅くなる可能性があります。
The projected increase in the fraction of total Internet traffic for more aggressive flows in classes 2 and 3 could pose a threat to the performance of the future Internet. There is therefore an urgent need for measurements of current conditions and for further research into the ways of managing such flows. This raises many difficult issues in finding methods with an acceptable overhead cost that can identify and isolate unresponsive flows or flows that are less responsive than TCP. Finally, there is as yet little measurement or simulation evidence available about the rate at which these threats are likely to be realized or about the expected benefit of algorithms for managing such flows.
クラス2と3でより積極的なフローのためのインターネットトラフィック全体の割合の増加が予測されると、将来のインターネットのパフォーマンスに脅威をもたらす可能性があります。したがって、現在の状態を測定し、そのようなフローを管理する方法をさらに研究することが急務です。これは、応答しないフローやTCPよりも応答性の低いフローを識別して分離できる、許容できるオーバーヘッドコストを持つメソッドを見つける際に多くの困難な問題を引き起こします。最後に、これらの脅威が実現される可能性が高い割合、またはそのようなフローを管理するためのアルゴリズムの予想される利点について、利用できる測定またはシミュレーションの証拠はまだほとんどありません。
Another topic requiring consideration is the appropriate granularity of a "flow" when considering a queue management method. There are a few "natural" answers: 1) a transport (e.g., TCP or UDP) flow (source address/port, destination address/port, protocol); 2) Differentiated Services Code Point, DSCP; 3) a source/destination host pair (IP address); 4) a given source host or a given destination host, or various combinations of the above; 5) a subscriber or site receiving the Internet service (enterprise or residential).
考慮が必要な別のトピックは、キュー管理方法を検討するときの「フロー」の適切な粒度です。いくつかの「自然な」答えがあります。1）トランスポート（TCPまたはUDPなど）フロー（送信元アドレス/ポート、宛先アドレス/ポート、プロトコル）。 2）DiffServコードポイント、DSCP。 3）送信元/宛先ホストのペア（IPアドレス）。 4）特定のソースホストまたは特定の宛先ホスト、または上記のさまざまな組み合わせ。 5）インターネットサービス（企業または住宅）を受信する加入者またはサイト。
The source/destination host pair gives an appropriate granularity in many circumstances. However, different vendors/providers use different granularities for defining a flow (as a way of "distinguishing" themselves from one another), and different granularities may be chosen for different places in the network. It may be the case that the granularity is less important than the fact that a network device needs to be able to deal with more unresponsive flows at *some* granularity. The granularity of flows for congestion management is, at least in part, a question of policy that needs to be addressed in the wider IETF community.
送信元/宛先ホストのペアは、多くの状況で適切な粒度を提供します。ただし、ベンダー/プロバイダーが異なれば、フローを定義するために異なる細分性を使用し（相互に「区別」する方法として）、ネットワーク内の異なる場所に異なる細分性を選択できます。細かさは、ネットワークデバイスが*一部の*細かさでより無応答なフローを処理できる必要があるという事実よりも重要ではない場合があります。輻輳管理のフローの細分性は、少なくとも部分的には、より広いIETFコミュニティで対処する必要があるポリシーの問題です。
The IRTF, in producing [RFC2309], and the IETF in subsequent discussion, have developed a set of specific recommendations regarding the implementation and operational use of AQM procedures. The recommendations provided by this document are summarized as:
[RFC2309]を作成する際のIRTF、およびその後の議論におけるIETFは、AQM手順の実装および運用上の使用に関する一連の特定の推奨事項を開発しました。このドキュメントで提供される推奨事項は、次のように要約されます。
1. Network devices SHOULD implement some AQM mechanism to manage queue lengths, reduce end-to-end latency, and avoid lock-out phenomena within the Internet.
1. ネットワークデバイスは、キューの長さを管理し、エンドツーエンドのレイテンシを削減し、インターネット内のロックアウト現象を回避するために、いくつかのAQMメカニズムを実装する必要があります（SHOULD）。
2. Deployed AQM algorithms SHOULD support Explicit Congestion Notification (ECN) as well as loss to signal congestion to endpoints.
2. デプロイされたAQMアルゴリズムは、明示的な輻輳通知（ECN）と、エンドポイントに輻輳を通知するための損失をサポートする必要があります（SHOULD）。
3. AQM algorithms SHOULD NOT require tuning of initial or configuration parameters in common use cases.
3. AQMアルゴリズムでは、一般的な使用例で初期パラメーターまたは構成パラメーターの調整を必要としません（SHOULD NOT）。
4. AQM algorithms SHOULD respond to measured congestion, not application profiles.
4. AQMアルゴリズムは、アプリケーションプロファイルではなく、測定された輻輳に応答する必要があります（SHOULD）。
5. AQM algorithms SHOULD NOT interpret specific transport protocol behaviors.
5. AQMアルゴリズムは、特定のトランスポートプロトコルの動作を解釈すべきではありません（SHOULD NOT）。
6. Congestion control algorithms for transport protocols SHOULD maximize their use of available capacity (when there is data to send) without incurring undue loss or undue round-trip delay.
6. トランスポートプロトコルの輻輳制御アルゴリズムは、過度の損失や過度の往復遅延を招くことなく、利用可能な容量（送信するデータがある場合）の使用を最大化する必要があります（SHOULD）。
7. Research, engineering, and measurement efforts are needed regarding the design of mechanisms to deal with flows that are unresponsive to congestion notification or are responsive, but are more aggressive than present TCP.
7. 輻輳通知に応答しない、または応答するが、現在のTCPよりも積極的であるフローを処理するメカニズムの設計に関して、調査、エンジニアリング、および測定の取り組みが必要です。
These recommendations are expressed using the word "SHOULD". This is in recognition that there may be use cases that have not been envisaged in this document in which the recommendation does not apply. Therefore, care should be taken in concluding that one's use case falls in that category; during the life of the Internet, such use cases have been rarely, if ever, observed and reported. To the contrary, available research [Choi04] says that even high-speed links in network cores that are normally very stable in depth and behavior experience occasional issues that need moderation. The recommendations are detailed in the following sections.
これらの推奨事項は、「SHOULD」という単語を使用して表現されています。これは、推奨事項が適用されない、このドキュメントで想定されていないユースケースが存在する可能性があることを認識したものです。したがって、自分のユースケースがそのカテゴリに該当すると結論付ける際には注意が必要です。インターネットの存続期間中、このような使用例が観察され、報告されることはめったにありません。反対に、利用可能な調査[Choi04]によると、通常深さおよび動作が非常に安定しているネットワークコアの高速リンクでさえ、モデレートが必要な問題が時々発生するということです。推奨事項については、次のセクションで詳しく説明します。
AQM procedures are designed to minimize the delay and buffer exhaustion induced in the network by queues that have filled as a result of host behavior. Marking and loss behaviors provide a signal that buffers within network devices are becoming unnecessarily full and that the sender would do well to moderate its behavior.
AQMプロシージャは、ホストの動作の結果として満たされたキューによってネットワークで引き起こされる遅延とバッファの枯渇を最小限に抑えるように設計されています。マーキングと損失の動作は、ネットワークデバイス内のバッファが不必要にいっぱいになり、送信者がその動作を適切に制御することを示す信号を提供します。
The use of scheduling mechanisms, such as priority queueing, classful queueing, and fair queueing, is often effective in networks to help a network serve the needs of a range of applications. Network operators can use these methods to manage traffic passing a choke point. This is discussed in [RFC2474] and [RFC2475]. When scheduling is used, AQM should be applied across the classes or flows as well as within each class or flow:
プライオリティキューイング、クラスフルキューイング、フェアキューイングなどのスケジューリングメカニズムの使用は、ネットワークがさまざまなアプリケーションのニーズに対応するのを支援するために、ネットワークで効果的であることがよくあります。ネットワークオペレータは、これらの方法を使用して、チョークポイントを通過するトラフィックを管理できます。これは[RFC2474]と[RFC2475]で議論されています。スケジューリングを使用する場合、AQMはクラスまたはフロー全体だけでなく、各クラスまたはフロー内にも適用する必要があります。
o AQM mechanisms need to control the overall queue sizes to ensure that arriving bursts can be accommodated without dropping packets.
o AQMメカニズムは、全体のキューサイズを制御して、パケットをドロップせずに到着するバーストに対応できるようにする必要があります。
o AQM mechanisms need to allow combination with other mechanisms, such as scheduling, to allow implementation of policies for providing fairness between different flows.
o AQMメカニズムは、異なるフロー間の公平性を提供するためのポリシーの実装を可能にするために、スケジューリングなどの他のメカニズムとの組み合わせを可能にする必要があります。
o AQM should be used to control the queue size for each individual flow or class, so that they do not experience unnecessarily high delay.
o AQMを使用して、個々のフローまたはクラスのキューサイズを制御し、不必要に大きな遅延が発生しないようにする必要があります。
There are a number of ways a network device may signal to the endpoint that the network is becoming congested and trigger a reduction in rate. The signaling methods include:
ネットワークが輻輳しつつあることをエンドポイントに通知し、レートの低下をトリガーする方法はいくつかあります。シグナリング方法は次のとおりです。
o Delaying transport segments (packets) in flight, such as in a queue.
o キュー内など、処理中のトランスポートセグメント（パケット）の遅延。
o Dropping transport segments (packets) in transit.
o 転送中のトランスポートセグメント（パケット）の削除。
o Marking transport segments (packets), such as using Explicit Congestion Control [RFC3168] [RFC4301] [RFC4774] [RFC6040] [RFC6679].
o 明示的輻輳制御の使用などのトランスポートセグメント（パケット）のマーキング[RFC3168] [RFC4301] [RFC4774] [RFC6040] [RFC6679]。
Increased network latency is used as an implicit signal of congestion. For example, in TCP, additional delay can affect ACK clocking and has the result of reducing the rate of transmission of new data. In the Real-time Transport Protocol (RTP), network latency impacts the RTCP-reported RTT, and increased latency can trigger a sender to adjust its rate. Methods such as Low Extra Delay Background Transport (LEDBAT) [RFC6817] assume increased latency as a primary signal of congestion. Appropriate use of delay-based methods and the implications of AQM presently remain an area for further research.
増加したネットワーク遅延は、輻輳の暗黙の信号として使用されます。たとえば、TCPでは、追加の遅延がACKクロッキングに影響を与える可能性があり、新しいデータの送信速度を低下させる結果になります。リアルタイムトランスポートプロトコル（RTP）では、ネットワークレイテンシはRTCP報告のRTTに影響を与え、レイテンシが増加すると、送信者がレートを調整するようにトリガーできます。低余分遅延バックグラウンドトランスポート（LEDBAT）[RFC6817]などの方法は、輻輳の主要な信号として遅延の増加を想定しています。遅延ベースの方法の適切な使用とAQMの影響は、現在、さらなる研究の領域として残っています。
It is essential that all Internet hosts respond to loss [RFC5681] [RFC5405] [RFC4960] [RFC4340]. Packet dropping by network devices that are under load has two effects: It protects the network, which is the primary reason that network devices drop packets. The detection of loss also provides a signal to a reliable transport (e.g., TCP, SCTP) that there is incipient congestion, using a pragmatic but ambiguous heuristic. Whereas, when the network discards a message in flight, the loss may imply the presence of faulty equipment or media in a path, or it may imply the presence of congestion. To be conservative, a transport must assume it may be the latter. Applications using unreliable transports (e.g., using UDP) need to similarly react to loss [RFC5405].
すべてのインターネットホストが損失に対応することが不可欠です[RFC5681] [RFC5405] [RFC4960] [RFC4340]。負荷がかかっているネットワークデバイスによるパケットドロップには2つの影響があります。ネットワークを保護します。これが、ネットワークデバイスがパケットをドロップする主な理由です。損失の検出は、信頼性の高いトランスポート（TCP、SCTPなど）に、実用的だがあいまいなヒューリスティックを使用して、初期の輻輳があることを示す信号も提供します。一方、ネットワークが処理中のメッセージを破棄する場合、その損失は、パス内に障害のある機器またはメディアが存在することを意味するか、または輻輳が存在することを意味します。保守的であるためには、トランスポートは後者であると想定する必要があります。信頼性の低いトランスポート（UDPなど）を使用するアプリケーションも、同様に損失に対応する必要があります[RFC5405]。
Network devices SHOULD use an AQM algorithm to measure local congestion and to determine the packets to mark or drop so that the congestion is managed.
ネットワークデバイスは、AQMアルゴリズムを使用してローカルの輻輳を測定し、輻輳が管理されるようにマークまたはドロップするパケットを決定する必要があります（SHOULD）。
In general, dropping multiple packets from the same sessions in the same RTT is ineffective and can reduce throughput. Also, dropping or marking packets from multiple sessions simultaneously can have the effect of synchronizing them, resulting in increasing peaks and troughs in the subsequent traffic load. Hence, AQM algorithms SHOULD randomize dropping in time, to reduce the probability that congestion indications are only experienced by a small proportion of the active flows.
一般に、同じRTTの同じセッションから複数のパケットをドロップすることは効果がなく、スループットを低下させる可能性があります。また、複数のセッションから同時にパケットをドロップまたはマーキングすると、パケットを同期する効果があり、その後のトラフィック負荷のピークと谷が増加する可能性があります。したがって、AQMアルゴリズムは、時間の経過とともにランダムにドロップをSHOULDし、アクティブなフローのごく一部のみが輻輳の兆候を経験する可能性を減らします。
Loss due to dropping also has an effect on the efficiency of a flow and can significantly impact some classes of application. In reliable transports, the dropped data must be subsequently retransmitted. While other applications/transports may adapt to the absence of lost data, this still implies inefficient use of available capacity, and the dropped traffic can affect other flows. Hence, congestion signaling by loss is not entirely positive; it is a necessary evil.
ドロップによる損失もフローの効率に影響し、一部のクラスのアプリケーションに大きな影響を与える可能性があります。信頼性の高いトランスポートでは、ドロップされたデータを後で再送信する必要があります。他のアプリケーション/トランスポートが失われたデータがない場合に適応する可能性がありますが、これは依然として利用可能な容量の非効率的な使用を意味し、ドロップされたトラフィックは他のフローに影響を与える可能性があります。したがって、損失による輻輳シグナリングは完全に肯定的ではありません。それは必要悪です。
Explicit Congestion Notification (ECN) [RFC4301] [RFC4774] [RFC6040] [RFC6679] is a network-layer function that allows a transport to receive network congestion information from a network device without incurring the unintended consequences of loss. ECN includes both transport mechanisms and functions implemented in network devices; the latter rely upon using AQM to decide when and whether to ECN-mark.
明示的輻輳通知（ECN）[RFC4301] [RFC4774] [RFC6040] [RFC6679]は、トランスポートがネットワークデバイスからネットワーク輻輳情報を受信できるようにするネットワーク層機能で、意図しない損失の結果を招くことはありません。 ECNには、ネットワークデバイスに実装された転送メカニズムと機能の両方が含まれます。後者は、AQMを使用して、いつECNマークを付けるかを決定します。
Congestion for ECN-capable transports is signaled by a network device setting the "Congestion Experienced (CE)" codepoint in the IP header. This codepoint is noted by the remote receiving endpoint and signaled back to the sender using a transport protocol mechanism, allowing the sender to trigger timely congestion control. The decision to set the CE codepoint requires an AQM algorithm configured with a threshold. Non-ECN capable flows (the default) are dropped under congestion.
ECN対応のトランスポートの輻輳は、IPヘッダーに「Congestion Experienced（CE）」コードポイントを設定するネットワークデバイスによって通知されます。このコードポイントは、リモートの受信エンドポイントによって通知され、トランスポートプロトコルメカニズムを使用して送信者に送り返され、送信者がタイムリーな輻輳制御をトリガーできるようにします。 CEコードポイントを設定する決定には、しきい値で構成されたAQMアルゴリズムが必要です。非ECN対応フロー（デフォルト）は、輻輳下でドロップされます。
Network devices SHOULD use an AQM algorithm that marks ECN-capable traffic when making decisions about the response to congestion. Network devices need to implement this method by marking ECN-capable traffic or by dropping non-ECN-capable traffic.
ネットワークデバイスは、輻輳への応答に関する決定を行うときに、ECN対応トラフィックをマークするAQMアルゴリズムを使用する必要があります（SHOULD）。ネットワークデバイスは、ECN対応のトラフィックをマークするか、ECN非対応のトラフィックをドロップすることにより、この方法を実装する必要があります。
Safe deployment of ECN requires that network devices drop excessive traffic, even when marked as originating from an ECN-capable transport. This is a necessary safety precaution because:
ECNを安全に展開するには、ネットワークデバイスがECN対応のトランスポートから発信されているとマークされていても、過剰なトラフィックをドロップする必要があります。これは、次の理由から必要な安全対策です。
1. A non-conformant, broken, or malicious receiver could conceal an ECN mark and not report this to the sender;
1. 非準拠、破損、または悪意のある受信者は、ECNマークを隠し、送信者に報告しない可能性があります。
2. A non-conformant, broken, or malicious sender could ignore a reported ECN mark, as it could ignore a loss without using ECN;
2. ECNを使用せずに損失を無視できるため、非準拠、破損、または悪意のある送信者は、報告されたECNマークを無視できます。
3. A malfunctioning or non-conforming network device may "hide" an ECN mark (or fail to correctly set the ECN codepoint at an egress of a network tunnel).
3. 誤動作または非準拠のネットワークデバイスは、ECNマークを「隠す」ことがあります（または、ネットワークトンネルの出口でECNコードポイントを正しく設定できません）。
In normal operation, such cases should be very uncommon; however, overload protection is desirable to protect traffic from misconfigured or malicious use of ECN (e.g., a denial-of-service attack that generates ECN-capable traffic that is unresponsive to CE-marking).
通常の操作では、このようなケースは非常にまれです。ただし、ECNの誤設定や悪用からトラフィックを保護するには、過負荷保護が望ましい（たとえば、CEマーキングに応答しないECN対応トラフィックを生成するサービス拒否攻撃）。
When ECN is added to a scheme, the ECN support MAY define a separate set of parameters from those used for controlling packet drop. The AQM algorithm SHOULD still auto-tune these ECN-specific parameters. These parameters SHOULD also be manually configurable.
ECNがスキームに追加されると、ECNサポートは、パケットドロップの制御に使用されるものとは別のパラメーターのセットを定義できます（MAY）。 AQMアルゴリズムは、これらのECN固有のパラメーターを自動調整する必要があります（SHOULD）。これらのパラメーターは、手動で構成可能であるべきです（SHOULD）。
Network devices SHOULD use an algorithm to drop excessive traffic (e.g., at some level above the threshold for CE-marking), even when the packets are marked as originating from an ECN-capable transport.
ネットワークデバイスは、パケットがECN対応のトランスポートから発信されたものとしてマークされている場合でも、アルゴリズムを使用して過剰なトラフィックをドロップする必要があります（たとえば、CEマーキングのしきい値を超えるレベル）。
A number of AQM algorithms have been proposed. Many require some form of tuning or setting of parameters for initial network conditions. This can make these algorithms difficult to use in operational networks.
多くのAQMアルゴリズムが提案されています。多くの場合、ネットワークの初期状態のために、何らかの形でパラメーターを調整または設定する必要があります。これにより、これらのアルゴリズムを運用ネットワークで使用することが困難になる可能性があります。
AQM algorithms need to consider both "initial conditions" and "operational conditions". The former includes values that exist before any experience is gathered about the use of the algorithm, such as the configured speed of interface, support for full-duplex communication, interface MTU, and other properties of the link. Other properties include information observed from monitoring the size of the queue, the queueing delay experienced, rate of packet discard, etc.
AQMアルゴリズムでは、「初期条件」と「動作条件」の両方を考慮する必要があります。前者には、構成済みのインターフェース速度、全二重通信のサポート、インターフェースMTU、およびリンクの他のプロパティーなど、アルゴリズムの使用に関する経験が収集される前に存在する値が含まれます。その他のプロパティには、キューのサイズ、発生したキューイング遅延、パケット廃棄率などの監視から観察された情報が含まれます。
This document therefore specifies that AQM algorithms that are proposed for deployment in the Internet have the following properties:
したがって、このドキュメントでは、インターネットへの展開が提案されているAQMアルゴリズムに次の特性があることを明記しています。
o AQM algorithm deployment SHOULD NOT require tuning. An algorithm MUST provide a default behavior that auto-tunes to a reasonable performance for typical network operational conditions. This is expected to ease deployment and operation. Initial conditions, such as the interface rate and MTU size or other values derived from these, MAY be required by an AQM algorithm.
o AQMアルゴリズムのデプロイメントでは、チューニングは必要ありません。アルゴリズムは、通常のネットワーク運用条件に対して妥当なパフォーマンスに自動調整するデフォルトの動作を提供する必要があります。これにより、展開と操作が容易になります。インターフェイスレートやMTUサイズ、またはこれらから導出されるその他の値などの初期条件は、AQMアルゴリズムで必要になる場合があります。
o AQM algorithm deployment MAY support further manual tuning that could improve performance in a specific deployed network. Algorithms that lack such variables are acceptable, but, if such variables exist, they SHOULD be externalized (made visible to the operator). The specification should identify any cases in which auto-tuning is unlikely to achieve acceptable performance and give guidance on the parametric adjustments necessary. For example, the expected response of an algorithm may need to be configured to accommodate the largest expected Path RTT, since this value cannot be known at initialization. This guidance is expected to enable the algorithm to be deployed in networks that have specific characteristics (paths with variable or larger delay, networks where capacity is impacted by interactions with lower-layer mechanisms, etc).
o AQMアルゴリズムの配置は、特定の配置されたネットワークのパフォーマンスを向上させる可能性のある手動チューニングをさらにサポートする場合があります。そのような変数を欠くアルゴリズムは許容されますが、そのような変数が存在する場合、それらは外部化されるべきです（オペレーターに見えるようにされるべきです）。仕様では、オートチューニングが許容可能なパフォーマンスを達成する可能性が低い場合を特定し、必要なパラメトリック調整に関するガイダンスを提供する必要があります。たとえば、アルゴリズムの予想される応答は、予想される最大のパスRTTに対応するように構成する必要がある場合があります。これは、この値が初期化時にわかっていないためです。このガイダンスにより、特定の特性を持つネットワーク（遅延が可変または大きいパス、下位層のメカニズムとの相互作用によって容量が影響を受けるネットワークなど）にアルゴリズムを展開できるようになると期待されます。
o AQM algorithm deployment MAY provide logging and alarm signals to assist in identifying if an algorithm using manual or auto-tuning is functioning as expected. (For example, this could be based on an internal consistency check between input, output, and mark/drop rates over time.) This is expected to encourage deployment by default and allow operators to identify potential interactions with other network functions.
o AQMアルゴリズムの展開では、手動チューニングまたは自動チューニングを使用するアルゴリズムが期待どおりに機能しているかどうかを識別するのに役立つロギングおよびアラーム信号を提供できます（MAY）。 （たとえば、これは、時間の経過に伴う、入力、出力、およびマーク/ドロップレート間の内部整合性チェックに基づく可能性があります。）これにより、既定で展開が促進され、オペレーターが他のネットワーク機能との潜在的な相互作用を識別できるようになります。
Hence, self-tuning algorithms are to be preferred. Algorithms recommended for general Internet deployment by the IETF need to be designed so that they do not require operational (especially manual) configuration or tuning.
したがって、セルフチューニングアルゴリズムが推奨されます。 IETFによる一般的なインターネット展開に推奨されるアルゴリズムは、運用（特に手動）による構成や調整を必要としないように設計する必要があります。
4.4. AQM Algorithms SHOULD Respond to Measured Congestion, Not Application Profiles
4.4. AQMアルゴリズムは、アプリケーションプロファイルではなく、測定された輻輳に応答する必要があります（SHOULD）
Not all applications transmit packets of the same size. Although applications may be characterized by particular profiles of packet size, this should not be used as the basis for AQM (see Section 4.5). Other methods exist, e.g., Differentiated Services queueing, Pre-Congestion Notification (PCN) [RFC5559], that can be used to differentiate and police classes of application. Network devices may combine AQM with these traffic classification mechanisms and perform AQM only on specific queues within a network device.
すべてのアプリケーションが同じサイズのパケットを送信するわけではありません。アプリケーションはパケットサイズの特定のプロファイルによって特徴付けられる場合がありますが、これをAQMの基礎として使用しないでください（セクション4.5を参照）。他の方法が存在します。たとえば、差別化サービスキューイング、事前輻輳通知（PCN）[RFC5559]は、アプリケーションのクラスを区別し、ポリシングするために使用できます。ネットワークデバイスは、AQMとこれらのトラフィック分類メカニズムを組み合わせて、ネットワークデバイス内の特定のキューでのみAQMを実行できます。
An AQM algorithm should not deliberately try to prejudice the size of packet that performs best (i.e., preferentially drop/mark based only on packet size). Procedures for selecting packets to drop/mark SHOULD observe the actual or projected time that a packet is in a queue (bytes at a rate being an analog to time). When an AQM algorithm decides whether to drop (or mark) a packet, it is RECOMMENDED that the size of the particular packet not be taken into account [RFC7141].
AQMアルゴリズムは、最高のパフォーマンスを発揮するパケットのサイズを故意に損なうことを試みるべきではありません（つまり、パケットサイズのみに基づいて優先的にドロップ/マークを付けます）。ドロップ/マークするパケットを選択するための手順は、パケットがキューにある実際の時間または予測された時間を観察する必要があります（レートのバイトは時間に類似しています）。 AQMアルゴリズムがパケットをドロップ（またはマーク）するかどうかを決定する場合、特定のパケットのサイズを考慮しないことをお勧めします[RFC7141]。
Applications (or transports) generally know the packet size that they are using and can hence make their judgments about whether to use small or large packets based on the data they wish to send and the expected impact on the delay, throughput, or other performance parameter. When a transport or application responds to a dropped or marked packet, the size of the rate reduction should be proportionate to the size of the packet that was sent [RFC7141].
アプリケーション（またはトランスポート）は通常、使用しているパケットサイズを知っているため、送信したいデータと、遅延、スループット、またはその他のパフォーマンスパラメーターへの予想される影響に基づいて、小さいパケットと大きいパケットのどちらを使用するかを判断できます。トランスポートまたはアプリケーションがドロップまたはマークされたパケットに応答する場合、レート削減のサイズは送信されたパケットのサイズに比例する必要があります[RFC7141]。
An AQM-enabled system MAY instantiate different instances of an AQM algorithm to be applied within the same traffic class. Traffic classes may be differentiated based on an Access Control List (ACL), the packet DSCP [RFC5559], enabling use of the ECN field (i.e., any of ECT(0), ECT(1) or CE) [RFC3168] [RFC4774], a multi-field (MF) classifier that combines the values of a set of protocol fields (e.g., IP address, transport, ports), or an equivalent codepoint at a lower layer. This recommendation goes beyond what is defined in RFC 3168 by allowing that an implementation MAY use more than one instance of an AQM algorithm to handle both ECN-capable and non-ECN-capable packets.
AQM対応システムは、同じトラフィッククラス内で適用されるAQMアルゴリズムの異なるインスタンスをインスタンス化できます（MAY）。トラフィッククラスは、アクセス制御リスト（ACL）、パケットDSCP [RFC5559]に基づいて区別され、ECNフィールド（つまり、ECT（0）、ECT（1）またはCEのいずれか）の使用を可能にします[RFC3168] [RFC4774 ]、一連のプロトコルフィールド（IPアドレス、トランスポート、ポートなど）の値を組み合わせたマルチフィールド（MF）分類子、または下位層の同等のコードポイント。この推奨事項は、RFC 3168で定義されているものを超えて、実装がAQMアルゴリズムの複数のインスタンスを使用してECN対応パケットと非ECN対応パケットの両方を処理できるようにすることで可能になります。
4.5. AQM Algorithms SHOULD NOT Be Dependent on Specific Transport Protocol Behaviors
4.5. AQMアルゴリズムは、特定のトランスポートプロトコルの動作に依存するべきではありません
In deploying AQM, network devices need to support a range of Internet traffic and SHOULD NOT make implicit assumptions about the characteristics desired by the set of transports/applications the network supports. That is, AQM methods should be opaque to the choice of transport and application.
AQMを展開する場合、ネットワークデバイスは一連のインターネットトラフィックをサポートする必要があり、ネットワークがサポートするトランスポート/アプリケーションのセットが必要とする特性について暗黙の仮定を行わないでください。つまり、AQMメソッドは、トランスポートとアプリケーションの選択に対して不透明でなければなりません。
AQM algorithms are often evaluated by considering TCP [RFC793] with a limited number of applications. Although TCP is the predominant transport in the Internet today, this no longer represents a sufficient selection of traffic for verification. There is significant use of UDP [RFC768] in voice and video services, and some applications find utility in SCTP [RFC4960] and DCCP [RFC4340]. Hence, AQM algorithms should demonstrate operation with transports other than TCP and need to consider a variety of applications. When selecting AQM algorithms, the use of tunnel encapsulations that may carry traffic aggregates needs to be considered.
AQMアルゴリズムは、多くの場合、限られた数のアプリケーションでTCP [RFC793]を検討することによって評価されます。今日のインターネットではTCPが主流のトランスポートですが、これはもはや検証のための十分なトラフィックの選択ではありません。音声およびビデオサービスでUDP [RFC768]が大幅に使用されており、一部のアプリケーションはSCTP [RFC4960]およびDCCP [RFC4340]でユーティリティを見つけます。したがって、AQMアルゴリズムは、TCP以外のトランスポートでの動作を示す必要があり、さまざまなアプリケーションを検討する必要があります。 AQMアルゴリズムを選択するときは、トラフィック集約を運ぶ可能性のあるトンネルカプセル化の使用を考慮する必要があります。
AQM algorithms SHOULD NOT target or derive implicit assumptions about the characteristics desired by specific transports/applications. Transports and applications need to respond to the congestion signals provided by AQM (i.e., dropping or ECN-marking) in a timely manner (within a few RTTs at the latest).
AQMアルゴリズムは、特定のトランスポート/アプリケーションが必要とする特性についての暗黙の仮定を対象としたり、導出したりしないでください。トランスポートおよびアプリケーションは、AQMによって提供される輻輳信号（つまり、ドロップまたはECNマーキング）にタイムリーに（遅くともいくつかのRTT内で）応答する必要があります。
Applications and transports need to react to received implicit or explicit signals that indicate the presence of congestion. This section identifies issues that can impact the design of transport protocols when using paths that use AQM.
アプリケーションとトランスポートは、輻輳の存在を示す受信された暗黙的または明示的な信号に反応する必要があります。このセクションでは、AQMを使用するパスを使用するときにトランスポートプロトコルの設計に影響を与える可能性がある問題を特定します。
Transport protocols and applications need timely signals of congestion. The time taken to detect and respond to congestion is increased when network devices queue packets in buffers. It can be difficult to detect tail losses at a higher layer, and this may sometimes require transport timers or probe packets to detect and respond to such loss. Loss patterns may also impact timely detection, e.g., the time may be reduced when network devices do not drop long runs of packets from the same flow.
トランスポートプロトコルとアプリケーションは、輻輳のタイムリーな信号を必要とします。ネットワークデバイスがパケットをバッファにキューイングすると、輻輳の検出と応答にかかる時間が長くなります。上位層でテールロスを検出することは困難な場合があり、このようなロスを検出して応答するには、トランスポートタイマーまたはプローブパケットが必要になる場合があります。損失パターンは、タイムリーな検出にも影響を与える可能性があります。たとえば、ネットワークデバイスが同じフローからパケットの長いランをドロップしない場合、時間が短縮される可能性があります。
A common objective of an elastic transport congestion control protocol is to allow an application to deliver the maximum rate of data without inducing excessive delays when packets are queued in buffers within the network. To achieve this, a transport should try to operate at rate below the inflection point of the load/delay curve (the bend of what is sometimes called a "hockey stick" curve) [Jain94]. When the congestion window allows the load to approach this bend, the end-to-end delay starts to rise -- a result of congestion, as packets probabilistically arrive at non-overlapping times. On the one hand, a transport that operates above this point can experience congestion loss and could also trigger operator activities, such as those discussed in [RFC6057]. On the other hand, a flow may achieve both near-maximum throughput and low latency when it operates close to this knee point, with minimal contribution to router congestion. Choice of an appropriate rate/congestion window can therefore significantly impact the loss and delay experienced by a flow and will impact other flows that share a common network queue.
エラスティックトランスポート輻輳制御プロトコルの共通の目的は、パケットがネットワーク内のバッファにキューイングされるときに過度の遅延を引き起こすことなく、アプリケーションが最大レートのデータを配信できるようにすることです。これを達成するために、トランスポートは、負荷/遅延曲線の変曲点（「ホッケースティック」曲線と呼ばれることもある屈曲）[Jain94]未満の速度で動作するようにする必要があります。負荷がこの曲がりに近づくのを輻輳ウィンドウが許可すると、パケットが重複しない時間に確率的に到着するため、輻輳の結果として、エンドツーエンドの遅延が増加し始めます。一方で、このポイントより上で動作するトランスポートは、輻輳損失を経験する可能性があり、[RFC6057]で説明されているようなオペレーターのアクティビティーをトリガーする可能性もあります。一方、フローは、このニーポイントの近くで動作する場合、ルーターの輻輳への影響を最小限に抑えながら、最大に近いスループットと低遅延の両方を実現できます。したがって、適切なレート/輻輳ウィンドウの選択は、フローが経験する損失と遅延に大きな影響を与える可能性があり、共通のネットワークキューを共有する他のフローに影響を与えます。
Some applications may send data at a lower rate or keep less segments outstanding at any given time. Examples include multimedia codecs that stream at some natural rate (or set of rates) or an application that is naturally interactive (e.g., some web applications, interactive server-based gaming, transaction-based protocols). Such applications may have different objectives. They may not wish to maximize throughput, but may desire a lower loss rate or bounded delay.
一部のアプリケーションは、より低いレートでデータを送信したり、特定の時間に未処理のセグメントを少なくしたりする場合があります。例には、いくつかの自然なレート（またはレートのセット）でストリーミングするマルチメディアコーデック、または自然にインタラクティブなアプリケーション（一部のWebアプリケーション、インタラクティブなサーバーベースのゲーム、トランザクションベースのプロトコルなど）が含まれます。このようなアプリケーションには、異なる目的がある場合があります。彼らはスループットを最大化したくないかもしれませんが、より低い損失率または制限された遅延を望むかもしれません。
The correct operation of an AQM-enabled network device MUST NOT rely upon specific transport responses to congestion signals.
AQM対応ネットワークデバイスの正しい動作は、輻輳信号に対する特定のトランスポート応答に依存してはなりません。
The second recommendation of [RFC2309] called for further research into the interaction between network queues and host applications, and the means of signaling between them. This research has occurred, and we as a community have learned a lot. However, we are not done.
[RFC2309]の2番目の勧告は、ネットワークキューとホストアプリケーション間の相互作用と、それらの間のシグナリングの手段についてのさらなる研究を求めていました。この研究は行われており、コミュニティとして私たちは多くのことを学びました。しかし、私たちは完了していません。
We have learned that the problems of congestion, latency, and buffer-sizing have not gone away and are becoming more important to many users. A number of self-tuning AQM algorithms have been found that offer significant advantages for deployed networks. There is also renewed interest in deploying AQM and the potential of ECN.
輻輳、レイテンシ、バッファサイズの問題は解消されておらず、多くのユーザーにとってより重要になっていることがわかりました。デプロイされたネットワークに大きな利点をもたらす多くのセルフチューニングAQMアルゴリズムが見つかりました。また、AQMの導入とECNの可能性に対する関心が新たに高まっています。
Traffic patterns can depend on the network deployment scenario, and Internet research therefore needs to consider the implications of a diverse range of application interactions. This includes ensuring that combinations of mechanisms, as well as combinations of traffic patterns, do not interact and result in either significantly reduced flow throughput or significantly increased latency.
トラフィックパターンはネットワークの展開シナリオに依存する可能性があるため、インターネットの調査では、さまざまなアプリケーションの相互作用の影響を考慮する必要があります。これには、メカニズムの組み合わせとトラフィックパターンの組み合わせが相互に影響を与えず、フロースループットが大幅に低下するか、レイテンシが大幅に増加することを確実にすることが含まれます。
At the time of writing (in 2015), an obvious example of further research is the need to consider the many-to-one communication patterns found in data centers, known as incast [Ren12], (e.g., produced by Map/Reduce applications). Such analysis needs to study not only each application traffic type but also combinations of types of traffic.
執筆時点（2015年）で、さらなる研究の明らかな例は、インキャスト[Ren12]として知られる、データセンターで見られる多対1の通信パターンを考慮する必要があることです（たとえば、Map / Reduceアプリケーションによって生成されます）。 ）。このような分析では、各アプリケーショントラフィックタイプだけでなく、トラフィックタイプの組み合わせも調査する必要があります。
Research also needs to consider the need to extend our taxonomy of transport sessions to include not only "mice" and "elephants", but "lemmings". Here, "lemmings" are flash crowds of "mice" that the network inadvertently tries to signal to as if they were "elephant" flows, resulting in head-of-line blocking in a data center deployment scenario.
研究では、輸送セッションの分類法を拡張して「マウス」と「象」だけでなく「レミングス」も含める必要性を考慮する必要があります。ここで、「レミングス」とは、「マウス」のフラッシュクラウドであり、ネットワークが誤って「象」フローであるかのように信号を送ろうとするため、データセンターの展開シナリオで行頭ブロッキングが発生します。
Examples of other required research include:
その他の必要な研究の例は次のとおりです。
o new AQM and scheduling algorithms
o 新しいAQMおよびスケジューリングアルゴリズム
o appropriate use of delay-based methods and the implications of AQM
o 遅延ベースの方法の適切な使用とAQMの影響
o suitable algorithms for marking ECN-capable packets that do not require operational configuration or tuning for common use
o 一般的な使用のための運用構成や調整を必要としないECN対応パケットをマーキングするための適切なアルゴリズム
o experience in the deployment of ECN alongside AQM
o AQMとともにECNを導入した経験
o tools for enabling AQM (and ECN) deployment and measuring the performance
o AQM（およびECN）の展開を可能にし、パフォーマンスを測定するためのツール
o methods for mitigating the impact of non-conformant and malicious flows
o 非準拠および悪意のあるフローの影響を軽減する方法
o implications on applications of using new network and transport methods
o 新しいネットワークと転送方法を使用するアプリケーションへの影響
Hence, this document reiterates the call of RFC 2309: we need continuing research as applications develop.
したがって、このドキュメントでは、RFC 2309の呼び出しを繰り返します。アプリケーションの開発に合わせて、継続的な調査が必要です。
While security is a very important issue, it is largely orthogonal to the performance issues discussed in this memo.
セキュリティは非常に重要な問題ですが、このメモで説明されているパフォーマンスの問題とほぼ直交しています。
This recommendation requires algorithms to be independent of specific transport or application behaviors. Therefore, a network device does not require visibility or access to upper-layer protocol information to implement an AQM algorithm. This ability to operate in an application-agnostic fashion is an example of a privacy-enhancing feature.
この推奨事項では、アルゴリズムが特定のトランスポートまたはアプリケーションの動作から独立している必要があります。したがって、ネットワークデバイスは、AQMアルゴリズムを実装するために、上位層プロトコル情報への可視性またはアクセスを必要としません。アプリケーションにとらわれない方法で動作するこの機能は、プライバシー強化機能の例です。
Many deployed network devices use queueing methods that allow unresponsive traffic to capture network capacity, denying access to other traffic flows. This could potentially be used as a denial-of-service attack. This threat could be reduced in network devices that deploy AQM or some form of scheduling. We note, however, that a denial-of-service attack that results in unresponsive traffic flows may be indistinguishable from other traffic flows (e.g., tunnels carrying aggregates of short flows, high-rate isochronous applications). New methods therefore may remain vulnerable, and this document recommends that ongoing research consider ways to mitigate such attacks.
配備されたネットワークデバイスの多くは、応答しないトラフィックがネットワーク容量をキャプチャできるようにするキューイング方法を使用して、他のトラフィックフローへのアクセスを拒否します。これは、サービス拒否攻撃として使用される可能性があります。この脅威は、AQMまたは何らかの形のスケジューリングを展開するネットワークデバイスで軽減される可能性があります。ただし、応答のないトラフィックフローを引き起こすサービス拒否攻撃は、他のトラフィックフロー（たとえば、短いフローの集約を運ぶトンネル、高速のアイソクロナスアプリケーション）と区別できない場合があることに注意してください。したがって、新しい方法は脆弱なままになる可能性があり、このドキュメントでは、進行中の研究がそのような攻撃を軽減する方法を検討することを推奨しています。
This document, by itself, presents no new privacy issues.
このドキュメント自体には、プライバシーに関する新しい問題はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[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, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <http://www.rfc-editor.org/info/rfc4774>.
[RFC4774]フロイド、S。、「明示的な輻輳通知（ECN）フィールドの代替セマンティクスの指定」、BCP 124、RFC 4774、DOI 10.17487 / RFC4774、2006年11月、<http://www.rfc-editor.org/ info / rfc4774>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、DOI 10.17487 / RFC5405、2008年11月、<http://www.rfc-editor.org/info / rfc5405>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<http://www.rfc-editor.org/info/rfc6040>。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141, February 2014, <http://www.rfc-editor.org/info/rfc7141>.
[RFC7141] Briscoe、B。およびJ. Manner、「Byte and Packet Congestion Notification」、BCP 41、RFC 7141、DOI 10.17487 / RFC7141、2014年2月、<http://www.rfc-editor.org/info/rfc7141 >。
[AQM-WG] IETF, "Active Queue Management and Packet Scheduling (aqm) WG", <http://datatracker.ietf.org/wg/aqm/charter/>.
[AQM-WG] IETF、「Active Queue Management and Packet Scheduling（aqm）WG」、<http://datatracker.ietf.org/wg/aqm/charter/>。
[Bri15] Briscoe, B., Brunstrom, A., Petlund, A., Hayes, D., Ros, D., Tsang, I., Gjessing, S., Fairhurst, G., Griwodz, C., and M. Welzl, "Reducing Internet Latency: A Survey of Techniques and their Merit", IEEE Communications Surveys & Tutorials, 2015.
[Bri15] Briscoe、B.、Brunstrom、A.、Petlund、A.、Hayes、D.、Ros、D.、Tsang、I.、Gjessing、S.、Fairhurst、G.、Griwodz、C。、およびM 。Welzl、「Reduceing Internet Latency：A Survey of Techniques and their Merits」、IEEE Communications Surveys＆Tutorials、2015年。
[Choi04] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point Packet Delay In an Operational Network", March 2004.
[Choi04] Choi、B.、Moon、S.、Zhang、Z.、Papagiannaki、K。、およびC. Diot、「Analysis of Point-to-Point Packet Delay in a Operational Network」、2004年3月。
[CONEX] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements", Work in Progress, draft-ietf-conex-abstract-mech-13, October 2014.
[CONEX] Mathis、M。、およびB. Briscoe、「Congestion Exposure（ConEx）Concepts、Abstract Mechanism and Requirements」、Work in Progress、draft-ietf-conex-abstract-mech-13、2014年10月。
[Dem90] Demers, A., Keshav, S., and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience", SIGCOMM Symposium proceedings on Communications architectures and protocols, 1990.
[Dem90] Demers、A.、Keshav、S。、およびS. Shenker、「フェアキューイングアルゴリズムの分析とシミュレーション、インターネットワーキング：研究と経験」、通信アーキテクチャとプロトコルに関するSIGCOMMシンポジウム議事録、1990年。
[ECN-Benefit] Fairhurst, G. and M. Welzl, "The Benefits of using Explicit Congestion Notification (ECN)", Work in Progress, draft-ietf-aqm-ecn-benefits-05, June 2015.
[ECN-Benefit] Fairhurst、G。およびM. Welzl、「明示的な輻輳通知（ECN）を使用する利点」、作業中、draft-ietf-aqm-ecn-benefits-05、2015年6月。
[Flo92] Floyd, S. and V. Jacobsen, "On Traffic Phase Effects in Packet-Switched Gateways", 1992, <http://www.icir.org/floyd/papers/phase.pdf>.
[Flo92] Floyd、S。およびV. Jacobsen、「パケット交換ゲートウェイにおけるトラフィックフェーズの影響」、1992、<http://www.icir.org/floyd/papers/phase.pdf>。
[Flo94] Floyd, S. and V. Jacobsen, "The Synchronization of Periodic Routing Messages", 1994, <http://ee.lbl.gov/papers/sync_94.pdf>.
[Flo94] Floyd、S. and V. Jacobsen、 "The Synchronization of Periodic Routing Messages"、1994、<http://ee.lbl.gov/papers/sync_94.pdf>。
[Floyd91] Floyd, S., "Connections with Multiple Congested Gateways in Packet-Switched Networks Part 1: One-way Traffic.", Computer Communications Review , October 1991.
[Floyd91] Floyd、S.、「パケット交換ネットワークにおける複数の輻輳したゲートウェイとの接続パート1：一方向トラフィック」、コンピュータ通信レビュー、1991年10月。
[Floyd95] Floyd, S. and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, August 1995.
[Floyd95] Floyd、S.およびV. Jacobson、「パケットネットワークのリンク共有およびリソース管理モデル」、IEEE / ACM Transactions on Networking、1995年8月。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM Symposium proceedings on Communications architectures and protocols, August 1988.
[Jacobson88] Jacobson、V。、「輻輳回避および制御」、通信アーキテクチャおよびプロトコルに関するSIGCOMMシンポジウム議事録、1988年8月。
[Jain94] Jain, R., Ramakrishnan, KK., and C. Dah-Ming, "Congestion avoidance scheme for computer networks", US Patent Office 5377327, December 1994.
[Jain94] Jain、R.、Ramakrishnan、KK、およびC. Dah-Ming、「コンピュータネットワークの輻輳回避スキーム」、米国特許庁5377327、1994年12月。
[Lakshman96] Lakshman, TV., Neidhardt, A., and T. Ott, "The Drop From Front Strategy in TCP Over ATM and Its Interworking with Other Control Features", IEEE Infocomm, 1996.
[Lakshman96] Lakshman、TV。、Neihardt、A.、およびT. Ott、「TCP over ATMにおけるフロントストラテジーの低下と他の制御機能との相互作用」、IEEE Infocomm、1996年。
[Leland94] Leland, W., Taqqu, M., Willinger, W., and D. Wilson, "On the Self-Similar Nature of Ethernet Traffic (Extended Version)", IEEE/ACM Transactions on Networking, February 1994.
[Leland94] Leland、W.、Taqqu、M.、Willinger、W。、およびD. Wilson、「On the Similar Nature of Ethernet Traffic（Extended Version）」、IEEE / ACM Transactions on Networking、1994年2月。
[McK90] McKenney, PE. and G. Varghese, "Stochastic Fairness Queuing", 1990, <http://www2.rdrop.com/~paulmck/scalability/paper/ sfq.2002.06.04.pdf>.
[McK90]マッケニー、PE。 G.バルゲーゼ、「Stochastic Fairness Queuing」、1990、<http://www2.rdrop.com/~paulmck/scalability/paper/ sfq.2002.06.04.pdf>。
[Nic12] Nichols, K. and V. Jacobson, "Controlling Queue Delay", Communications of the ACM, Vol. 55, Issue 7, pp. 42-50, July 2012.
[Nic12] Nichols、K。およびV. Jacobson、「Controlling Queue Delay」、Communications of the ACM、Vol。 55、第7号、pp。42-50、2012年7月。
[Ren12] Ren, Y., Zhao, Y., and P. Liu, "A survey on TCP Incast in data center networks", International Journal of Communication Systems, Volumes 27, Issue 8, pages 116-117, 1990.
[Ren12] Ren、Y.、Zhao、Y。、およびP. Liu、「データセンターネットワークにおけるTCPインキャストに関する調査」、International Journal of Communication Systems、Volume 27、Issue 8、116〜117ページ、1990。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, <http://www.rfc-editor.org/info/rfc896>.
[RFC896] Nagle、J。、「IP / TCP Internetworksの輻輳制御」、RFC 896、DOI 10.17487 / RFC0896、1984年1月、<http://www.rfc-editor.org/info/rfc896>。
[RFC970] Nagle, J., "On Packet Switches With Infinite Storage", RFC 970, DOI 10.17487/RFC0970, December 1985, <http://www.rfc-editor.org/info/rfc970>.
[RFC970] Nagle、J。、「On Packet Switches With Infinite Storage」、RFC 970、DOI 10.17487 / RFC0970、1985年12月、<http://www.rfc-editor.org/info/rfc970>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, DOI 10.17487/RFC1633, June 1994, <http://www.rfc-editor.org/info/rfc1633>.
[RFC1633] Braden、R.、Clark、D。、およびS. Shenker、「Integrated Services in the Internet Architecture：a Overview」、RFC 1633、DOI 10.17487 / RFC1633、1994年6月、<http：//www.rfc- editor.org/info/rfc1633>。
[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, DOI 10.17487/RFC2309, April 1998, <http://www.rfc-editor.org/info/rfc2309>.
[RFC2309]ブレーデン、B。、クラーク、D。、クロウクロフト、J。、デイビー、B。、ディアリング、S。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、 C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、DOI 10.17487 / RFC2309、4月1998、<http://www.rfc-editor.org/info/rfc2309>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<http://www.rfc-editor.org/info/rfc2474>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<http://www.rfc-editor.org/info/rfc2475>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914] Floyd、S。、「Congestion Control Principles」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<http://www.rfc-editor.org/info/rfc2914>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<http：//www.rfc-editor。 org / info / rfc4340>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<http://www.rfc-editor.org/info/rfc4960>。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<http： //www.rfc-editor.org/info/rfc5348>。
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, <http://www.rfc-editor.org/info/rfc5559>.
[RFC5559] Eardley、P。、編、「Pre-Congestion Notification（PCN）Architecture」、RFC 5559、DOI 10.17487 / RFC5559、2009年6月、<http://www.rfc-editor.org/info/rfc5559> 。
[RFC6057] Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. Woundy, "Comcast's Protocol-Agnostic Congestion Management System", RFC 6057, DOI 10.17487/RFC6057, December 2010, <http://www.rfc-editor.org/info/rfc6057>.
[RFC6057]バスティアン、C。、クリーバー、T。、リビングウッド、J。、ミルズ、J。、およびR.ワウンディ、「Comcastのプロトコルにとらわれない輻輳管理システム」、RFC 6057、DOI 10.17487 / RFC6057、2010年12月、< http://www.rfc-editor.org/info/rfc6057>。
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <http://www.rfc-editor.org/info/rfc6789>.
[RFC6789] Briscoe、B。、編、Woundy、R。、編、およびA. Cooper、編、「Congestion Exposure（ConEx）Concepts and Use Cases」、RFC 6789、DOI 10.17487 / RFC6789、2012年12月、 <http://www.rfc-editor.org/info/rfc6789>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<http：// www.rfc-editor.org/info/rfc6817>。
[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, <http://www.rfc-editor.org/info/rfc7414>.
[RFC7414]デューク、M。、ブレーデン、R。、エディ、W。、ブラントン、E。、およびA.ジマーマン、「A Transmission map for Transmission Control Protocol（TCP）Specification Documents」、RFC 7414、DOI 10.17487 / RFC7414、 2015年2月、<http://www.rfc-editor.org/info/rfc7414>。
[Shr96] Shreedhar, M. and G. Varghese, "Efficient Fair Queueing Using Deficit Round Robin", IEEE/ACM Transactions on Networking, Vol. 4, No. 3, July 1996.
[Shr96] Shreedhar、M。およびG. Varghese、「赤字ラウンドロビンを使用した効率的なフェアキューイング」、IEEE / ACM Transactions on Networking、Vol。 4、No。3、1996年7月。
[Sto97] Stoica, I. and H. Zhang, "A Hierarchical Fair Service Curve algorithm for Link sharing, real-time and priority services", ACM SIGCOMM, 1997.
[Sto97] Stoica、I。およびH. Zhang、「リンク共有、リアルタイムおよび優先サービスのための階層的公正サービス曲線アルゴリズム」、ACM SIGCOMM、1997年。
[Sut99] Suter, B., "Buffer Management Schemes for Supporting TCP in Gigabit Routers with Per-flow Queueing", IEEE Journal on Selected Areas in Communications, Vol. 17, Issue 6, pp. 1159-1169, June 1999.
[Sut99] Suter、B。、「Per-flow Queueingを使用したギガビットルーターでTCPをサポートするためのバッファ管理方式」、Communications、Vol。 17、6号、1159〜1169頁、1999年6月。
[Willinger95] Willinger, W., Taqqu, M., Sherman, R., Wilson, D., and V. Jacobson, "Self-Similarity Through High-Variability: Statistical Analysis of Ethernet LAN Traffic at the Source Level", SIGCOMM Symposium proceedings on Communications architectures and protocols, August 1995.
[Willinger95] Willinger、W.、Taqqu、M.、Sherman、R.、Wilson、D.、and V. Jacobson、 "Self-Similarity through High-Variability：Statistical Analysis of Ethernet LAN Traffic at the Source Level"、SIGCOMM通信アーキテクチャとプロトコルに関するシンポジウム議事録、1995年8月。
[Zha90] Zhang, L. and D. Clark, "Oscillating Behavior of Network Traffic: A Case Study Simulation", 1990, <http://groups.csail.mit.edu/ana/Publications/Zhang-DDC-Oscillating-Behavior-of-Network-Traffic-1990.pdf>.
[Zha90] Zhang、L.およびD. Clark、「Oscilrating Behavior of Network Traffic：A Case Study Simulation」、1990、<http://groups.csail.mit.edu/ana/Publications/Zhang-DDC-Oscillating- Behavior-of-Network-Traffic-1990.pdf>。
Acknowledgements
謝辞
The original draft of this document describing best current practice was based on [RFC2309], an Informational RFC. It was written by the End-to-End Research Group, which is to say Bob Braden, Dave Clark, Jon Crowcroft, Bruce Davie, Steve Deering, Deborah Estrin, Sally Floyd, Van Jacobson, Greg Minshall, Craig Partridge, Larry Peterson, KK Ramakrishnan, Scott Shenker, John Wroclawski, and Lixia Zhang. Although there are important differences, many of the key arguments in the present document remain unchanged from those in RFC 2309.
現在のベストプラクティスを説明するこのドキュメントの元のドラフトは、情報RFCである[RFC2309]に基づいていました。エンドツーエンドの研究グループ、つまりボブブレーデン、デイブクラーク、ジョンクロウクロフト、ブルースデイビー、スティーブディアリング、デボラエストリン、サリーフロイド、ヴァンジェイコブソン、グレッグミンシャル、クレイグパートリッジ、ラリーピーターソンによって作成されました。 KK Ramakrishnan、Scott Shenker、John Wroclawski、Lixia Zhang。重要な違いはありますが、このドキュメントの主要な引数の多くは、RFC 2309の引数から変更されていません。
The need for an updated document was agreed to in the TSV area meeting at IETF 86. This document was reviewed on the aqm@ietf.org list. Comments were received from Colin Perkins, Richard Scheffenegger, Dave Taht, John Leslie, David Collier-Brown, and many others.
更新されたドキュメントの必要性は、IETF 86でのTSVエリア会議で合意されました。このドキュメントは、aqm @ ietf.orgリストでレビューされました。 Colin Perkins、Richard Scheffenegger、Dave Taht、John Leslie、David Collier-Brownなどからコメントが寄せられました。
Gorry Fairhurst was in part supported by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700).
Gorry Fairhurstは、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）を通じて、第7フレームワークプログラムの下でヨーロッパ共同体によって部分的にサポートされていました。
Authors' Addresses
著者のアドレス
Fred Baker (editor) Cisco Systems Santa Barbara, California 93117 United States
Fred Baker（編集者）Cisco Systems Santa Barbara、California 93117アメリカ合衆国
Email: fred@cisco.com
Godred Fairhurst (editor) University of Aberdeen School of Engineering Fraser Noble Building Aberdeen, Scotland AB24 3UE United Kingdom
Godred Fairhurst（編集者）アバディーン大学工学部Fraser Noble Buildingアバディーン、スコットランドAB24 3UEイギリス
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk