[要約] RFC 7928は、Active Queue Management（AQM）のための特性化ガイドラインであり、AQMの目的はネットワークの遅延と輻輳を制御することです。
Internet Engineering Task Force (IETF) N. Kuhn, Ed.
Request for Comments: 7928 CNES, Telecom Bretagne
Category: Informational P. Natarajan, Ed.
ISSN: 2070-1721 Cisco Systems
N. Khademi, Ed.
University of Oslo
D. Ros
Simula Research Laboratory AS
July 2016
Characterization Guidelines for Active Queue Management (AQM)
アクティブキュー管理（AQM）の特性評価ガイドライン
Abstract
概要
Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing. This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.
今日のネットワークで管理されていない大きなバッファーが原因で、多数のパフォーマンスの問題が発生しています。これらのパフォーマンスの問題は、何らかの形のアクティブキュー管理（AQM）メカニズムによって、オプションでフェアキューイングなどのパケットスケジューリングスキームと組み合わせて対処できます。このドキュメントでは、展開前の開発中のラボテストで使用できるAQMスキームの特性評価を実行するためのさまざまな基準について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc7928.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7928で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Reducing the Latency and Maximizing the Goodput . . . . . 5
1.2. Goals of This Document . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 7
2. End-to-End Metrics . . . . . . . . . . . . . . . . . . . . . 7
2.1. Flow Completion Time . . . . . . . . . . . . . . . . . . 8
2.2. Flow Startup Time . . . . . . . . . . . . . . . . . . . . 8
2.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Packet Loss Synchronization . . . . . . . . . . . . . . . 9
2.5. Goodput . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Latency and Jitter . . . . . . . . . . . . . . . . . . . 11
2.7. Discussion on the Trade-Off between Latency and Goodput . 11
3. Generic Setup for Evaluations . . . . . . . . . . . . . . . . 12
3.1. Topology and Notations . . . . . . . . . . . . . . . . . 12
3.2. Buffer Size . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Congestion Controls . . . . . . . . . . . . . . . . . . . 14
4. Methodology, Metrics, AQM Comparisons, Packet Sizes,
Scheduling, and ECN . . . . . . . . . . . . . . . . . . . . . 14
4.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Comments on Metrics Measurement . . . . . . . . . . . . . 15
4.3. Comparing AQM Schemes . . . . . . . . . . . . . . . . . . 15
4.3.1. Performance Comparison . . . . . . . . . . . . . . . 15
4.3.2. Deployment Comparison . . . . . . . . . . . . . . . . 16
4.4. Packet Sizes and Congestion Notification . . . . . . . . 16
4.5. Interaction with ECN . . . . . . . . . . . . . . . . . . 17
4.6. Interaction with Scheduling . . . . . . . . . . . . . . . 17
5. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 18
5.1. TCP-Friendly Sender . . . . . . . . . . . . . . . . . . . 19
5.1.1. TCP-Friendly Sender with the Same Initial Congestion
Window . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2. TCP-Friendly Sender with Different Initial Congestion
Windows . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Aggressive Transport Sender . . . . . . . . . . . . . . . 19
5.3. Unresponsive Transport Sender . . . . . . . . . . . . . . 20
5.4. Less-than-Best-Effort Transport Sender . . . . . . . . . 20
6. Round-Trip Time Fairness . . . . . . . . . . . . . . . . . . 21
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 21
6.3. Metrics to Evaluate the RTT Fairness . . . . . . . . . . 22
7. Burst Absorption . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 23
8. Stability . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Recommended Tests . . . . . . . . . . . . . . . . . . . . 24
8.2.1. Definition of the Congestion Level . . . . . . . . . 25
8.2.2. Mild Congestion . . . . . . . . . . . . . . . . . . . 25
8.2.3. Medium Congestion . . . . . . . . . . . . . . . . . . 25
8.2.4. Heavy Congestion . . . . . . . . . . . . . . . . . . 25
8.2.5. Varying the Congestion Level . . . . . . . . . . . . 26
8.2.6. Varying Available Capacity . . . . . . . . . . . . . 26
8.3. Parameter Sensitivity and Stability Analysis . . . . . . 27
9. Various Traffic Profiles . . . . . . . . . . . . . . . . . . 27
9.1. Traffic Mix . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 28
10. Example of a Multi-AQM Scenario . . . . . . . . . . . . . . . 29
10.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Details on the Evaluation Scenario . . . . . . . . . . . 29
11. Implementation Cost . . . . . . . . . . . . . . . . . . . . . 30
11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 30
11.2. Recommended Discussion . . . . . . . . . . . . . . . . . 30
12. Operator Control and Auto-Tuning . . . . . . . . . . . . . . 30
12.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 30
12.2. Recommended Discussion . . . . . . . . . . . . . . . . . 31
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Security Considerations . . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Active Queue Management (AQM) addresses the concerns arising from using unnecessarily large and unmanaged buffers to improve network and application performance, such as those presented in Section 1.2 of the AQM recommendations document [RFC7567]. Several AQM algorithms have been proposed in the past years, most notably Random Early Detection (RED) [FLOY1993], BLUE [FENG2002], Proportional Integral controller (PI) [HOLLO2001], and more recently, Controlled Delay (CoDel) [CODEL] and Proportional Integral controller Enhanced (PIE) [AQMPIE]. In general, these algorithms actively interact with the Transmission Control Protocol (TCP) and any other transport protocol that deploys a congestion control scheme to manage the amount of data they keep in the network. The available buffer space in the routers and switches should be large enough to accommodate the short-term buffering requirements. AQM schemes aim at reducing buffer occupancy, and therefore the end-to-end delay. Some of these algorithms, notably RED, have also been widely implemented in some network devices. However, the potential benefits of the RED scheme have not been realized since RED is reported to be usually turned off.
Active Queue Management（AQM）は、AQM推奨ドキュメント[RFC7567]のセクション1.2に示されているような、不必要に大きく管理されていないバッファーを使用してネットワークとアプリケーションのパフォーマンスを向上させることから生じる懸念に対処します。過去数年間にいくつかのAQMアルゴリズムが提案されており、特にランダム早期検出（RED）[FLOY1993]、BLUE [FENG2002]、比例積分コントローラー（PI）[HOLLO2001]、そして最近ではControlled Delay（CoDel）[CODEL]および比例積分コントローラー拡張（PIE）[AQMPIE]。一般に、これらのアルゴリズムは、伝送制御プロトコル（TCP）や、ネットワークに保持するデータ量を管理するための輻輳制御方式を導入するその他のトランスポートプロトコルと積極的に相互作用します。ルータとスイッチで使用可能なバッファスペースは、短期間のバッファリング要件に対応できるだけの大きさが必要です。 AQMスキームは、バッファー占有率を削減することを目的としているため、エンドツーエンドの遅延が発生します。これらのアルゴリズムの一部、特にREDは、一部のネットワークデバイスに広く実装されています。ただし、REDは通常オフになっていると報告されているため、REDスキームの潜在的な利点は実現されていません。
A buffer is a physical volume of memory in which a queue or set of queues are stored. When speaking of a specific queue in this document, "buffer occupancy" refers to the amount of data (measured in bytes or packets) that are in the queue, and the "maximum buffer size" refers to the maximum buffer occupancy. In switches and routers, a global memory space is often shared between the available interfaces, and thus, the maximum buffer size for any given interface may vary over time.
バッファは、キューまたはキューのセットが格納されるメモリの物理ボリュームです。このドキュメントの特定のキューについて言えば、「バッファ占有率」はキューにあるデータの量（バイトまたはパケットで測定）を指し、「最大バッファサイズ」は最大バッファ占有率を指します。スイッチおよびルーターでは、グローバルメモリ空間が利用可能なインターフェイス間で共有されることが多いため、特定のインターフェイスの最大バッファーサイズは時間とともに変化する可能性があります。
Bufferbloat [BB2011] is the consequence of deploying large, unmanaged buffers on the Internet -- the buffering has often been measured to be ten times or a hundred times larger than needed. Large buffer sizes in combination with TCP and/or unresponsive flows increases end-to-end delay. This results in poor performance for latency-sensitive applications such as real-time multimedia (e.g., voice, video, gaming, etc.). The degree to which this affects modern networking equipment, especially consumer-grade equipment, produces problems even with commonly used web services. Active queue management is thus essential to control queuing delay and decrease network latency.
Bufferbloat [BB2011]は、インターネット上に管理されていない大きなバッファーを配置した結果です。バッファーのサイズは、必要以上に10倍または100倍と測定されることがよくあります。 TCPや応答のないフローと組み合わせて大きなバッファサイズを使用すると、エンドツーエンドの遅延が増加します。これにより、リアルタイムマルチメディア（音声、ビデオ、ゲームなど）などの遅延の影響を受けやすいアプリケーションのパフォーマンスが低下します。これが現代のネットワーキング機器、特に消費者向け機器に影響を与える度合いは、一般的に使用されているWebサービスでも問題を引き起こします。したがって、アクティブなキュー管理は、キューイング遅延を制御し、ネットワーク遅延を減らすために不可欠です。
The Active Queue Management and Packet Scheduling Working Group (AQM WG) was chartered to address the problems with large unmanaged buffers in the Internet. Specifically, the AQM WG is tasked with standardizing AQM schemes that not only address concerns with such buffers, but are also robust under a wide variety of operating conditions. This document provides characterization guidelines that can be used to assess the applicability, performance, and deployability of an AQM, whether it is a candidate for standardization at IETF or not.
アクティブキュー管理およびパケットスケジューリングワーキンググループ（AQM WG）は、インターネットで管理されていない大きなバッファーに関する問題に対処するために設立されました。具体的には、AQM WGは、そのようなバッファーに関する懸念に対処するだけでなく、さまざまな動作条件下で堅牢なAQMスキームの標準化を任されています。このドキュメントでは、IETFでの標準化の候補であるかどうかにかかわらず、AQMの適用性、パフォーマンス、および展開可能性を評価するために使用できる特性化ガイドラインを提供します。
The AQM algorithm implemented in a router can be separated from the scheduling of packets sent out by the router as discussed in the AQM recommendations document [RFC7567]. The rest of this memo refers to the AQM as a dropping/marking policy as a separate feature to any interface-scheduling scheme. This document may be complemented with another one on guidelines for assessing the combination of packet scheduling and AQM. We note that such a document will inherit all the guidelines from this document, plus any additional scenarios relevant for packet scheduling such as flow-starvation evaluation or the impact of the number of hash buckets.
AQM推奨ドキュメント[RFC7567]で説明されているように、ルーターに実装されたAQMアルゴリズムは、ルーターによって送信されるパケットのスケジューリングから分離できます。このメモの残りの部分では、AQMをドロップ/マーキングポリシーとして、任意のインターフェイススケジューリングスキームとは別の機能として参照しています。このドキュメントは、パケットスケジューリングとAQMの組み合わせを評価するためのガイドラインに関する別のドキュメントで補足される場合があります。このようなドキュメントは、このドキュメントからすべてのガイドラインを継承し、さらにフロースターベーション評価やハッシュバケット数の影響など、パケットスケジューリングに関連するその他のシナリオも継承することに注意してください。
The trade-off between reducing the latency and maximizing the goodput is intrinsically linked to each AQM scheme and is key to evaluating its performance. To ensure the safety deployment of an AQM, its behavior should be assessed in a variety of scenarios. Whenever possible, solutions ought to aim at both maximizing goodput and minimizing latency.
レイテンシの削減とグッドプットの最大化の間のトレードオフは、本質的に各AQMスキームにリンクされており、そのパフォーマンスを評価するための鍵となります。 AQMの安全な展開を保証するには、その動作をさまざまなシナリオで評価する必要があります。可能な限り、ソリューションはグッドプットの最大化とレイテンシの最小化の両方を目指す必要があります。
This document recommends a generic list of scenarios against which an AQM proposal should be evaluated, considering both potential performance gain and safety of deployment. The guidelines help to quantify performance of AQM schemes in terms of latency reduction, goodput maximization, and the trade-off between these two. The document presents central aspects of an AQM algorithm that should be considered, whatever the context, such as burst absorption capacity, RTT fairness, or resilience to fluctuating network conditions. The guidelines also discuss methods to understand the various aspects associated with safely deploying and operating the AQM scheme. Thus, one of the key objectives behind formulating the guidelines is to help ascertain whether a specific AQM is not only better than drop-tail (i.e., without AQM and with a BDP-sized buffer), but also safe to deploy: the guidelines can be used to compare several AQM proposals with each other, but should be used to compare a proposal with drop-tail.
このドキュメントでは、潜在的なパフォーマンスの向上と展開の安全性の両方を考慮して、AQMプロポーザルを評価する必要があるシナリオの一般的なリストを推奨しています。ガイドラインは、レイテンシの削減、グッドプットの最大化、およびこれら2つの間のトレードオフの観点から、AQMスキームのパフォーマンスを定量化するのに役立ちます。このドキュメントでは、バースト吸収能力、RTTの公平性、変動するネットワーク条件への回復力などのコンテキストに関係なく、考慮すべきAQMアルゴリズムの中心的な側面について説明します。ガイドラインでは、AQMスキームの安全な展開と運用に関連するさまざまな側面を理解する方法についても説明します。したがって、ガイドラインの策定の背後にある主要な目的の1つは、特定のAQMがドロップテールよりも優れている（つまり、AQMがなく、BDPサイズのバッファーがある場合）だけでなく、安全に展開できるかどうかを確認するのに役立つことです。複数のAQMプロポーザルを相互に比較するために使用できますが、ドロップテールとプロポーザルを比較するために使用する必要があります。
This memo details generic characterization scenarios against which any AQM proposal should be evaluated, irrespective of whether or not an AQM is standardized by the IETF. This document recommends the relevant scenarios and metrics to be considered. This document presents central aspects of an AQM algorithm that should be considered whatever the context, such as burst absorption capacity, RTT fairness, or resilience to fluctuating network conditions.
このメモは、AQMがIETFによって標準化されているかどうかに関係なく、AQM提案を評価する必要のある一般的な特性化シナリオについて詳しく説明しています。このドキュメントでは、関連するシナリオとメトリックを検討することを推奨しています。このドキュメントでは、バースト吸収能力、RTTの公平性、変動するネットワーク条件への回復力などのコンテキストを問わず、AQMアルゴリズムの中心的な側面について説明します。
These guidelines do not define and are not bound to a particular deployment scenario or evaluation toolset. Instead, the guidelines can be used to assert the potential gain of introducing an AQM for the particular environment, which is of interest to the testers. These guidelines do not cover every possible aspect of a particular algorithm. These guidelines do not present context-dependent scenarios (such as IEEE 802.11 WLANs, data centers, or rural broadband networks). To keep the guidelines generic, a number of potential router components and algorithms (such as Diffserv) are omitted.
これらのガイドラインは、特定の展開シナリオや評価ツールセットを定義しておらず、それらにも拘束されていません。代わりに、ガイドラインを使用して、特定の環境にAQMを導入する潜在的な利点を主張できます。これは、テスターにとって重要です。これらのガイドラインは、特定のアルゴリズムのすべての可能な側面を網羅しているわけではありません。これらのガイドラインは、コンテキストに依存したシナリオ（IEEE 802.11 WLAN、データセンター、地方のブロードバンドネットワークなど）を示していません。ガイドラインを一般的に保つために、いくつかの潜在的なルーターコンポーネントとアルゴリズム（Diffservなど）は省略されています。
The goals of this document can thus be summarized as follows:
したがって、このドキュメントの目的は次のように要約できます。
o The present characterization guidelines provide a non-exhaustive list of scenarios to help ascertain whether an AQM is not only better than drop-tail (with a BDP-sized buffer), but also safe to deploy; the guidelines can also be used to compare several AQM proposals with each other.
o 現在の特性化ガイドラインは、AQMがドロップテール（BDPサイズのバッファーを使用）よりも優れているだけでなく、安全に展開できるかどうかを確認するのに役立つシナリオの完全ではないリストを提供します。ガイドラインは、いくつかのAQM提案を相互に比較するためにも使用できます。
o The present characterization guidelines (1) are not bound to a particular evaluation toolset and (2) can be used for various deployment contexts; testers are free to select a toolset that is best suited for the environment in which their proposal will be deployed.
o 現在の特性化ガイドラインは、（1）特定の評価ツールセットにバインドされておらず、（2）さまざまなデプロイメントコンテキストに使用できます。テスターは、提案が展開される環境に最適なツールセットを自由に選択できます。
o The present characterization guidelines are intended to provide guidance for better selecting an AQM for a specific environment; it is not required that an AQM proposal is evaluated following these guidelines for its standardization.
o 現在の特性化ガイドラインは、特定の環境のAQMをより適切に選択するためのガイダンスを提供することを目的としています。 AQMプロポーザルは、標準化のためにこれらのガイドラインに従って評価される必要はありません。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
o Application-limited traffic: A type of traffic that does not have an unlimited amount of data to transmit.
o アプリケーション制限トラフィック：送信するデータの量に制限がないトラフィックのタイプ。
o AQM: The Active Queue Management (AQM) algorithm implemented in a router can be separated from the scheduling of packets sent by the router. The rest of this memo refers to the AQM as a dropping/ marking policy as a separate feature to any interface scheduling scheme [RFC7567].
o AQM：ルーターに実装されているアクティブキュー管理（AQM）アルゴリズムは、ルーターが送信するパケットのスケジューリングから分離できます。このメモの残りの部分では、AQMをドロップ/マーキングポリシーとして、任意のインターフェイススケジューリングスキーム[RFC7567]とは別の機能として参照しています。
o BDP: Bandwidth Delay Product.
o BDP：帯域幅遅延積。
o Buffer: A physical volume of memory in which a queue or set of queues are stored.
o バッファ：キューまたはキューのセットが格納されるメモリの物理ボリューム。
o Buffer Occupancy: The amount of data stored in a buffer, measured in bytes or packets.
o バッファー占有率：バッファーに格納されているデータの量（バイトまたはパケット単位）。
o Buffer Size: The maximum buffer occupancy, that is the maximum amount of data that may be stored in a buffer, measured in bytes or packets.
o バッファーサイズ：最大バッファー占有率、つまり、バッファーに格納できるデータの最大量（バイトまたはパケット単位）。
o Initial Window 10 (IW10): TCP initial congestion window set to 10 packets.
o 初期ウィンドウ10（IW10）：10パケットに設定されたTCP初期輻輳ウィンドウ。
o Latency: One-way delay of packets across Internet paths. This definition suits transport layer definition of the latency, which should not be confused with an application-layer view of the latency.
o 遅延：インターネットパス全体でのパケットの一方向の遅延。この定義は、レイテンシのトランスポート層定義に適しています。レイテンシのアプリケーション層ビューと混同しないでください。
o Goodput: Goodput is defined as the number of bits per unit of time forwarded to the correct destination, minus any bits lost or retransmitted [RFC2647]. The goodput should be determined for each flow and not for aggregates of flows.
o グッドプット：グッドプットは、正しい宛先に転送される単位時間あたりのビット数から、失われたビットまたは再送信されたビットを引いたものとして定義されます[RFC2647]。グッドプットは、フローの集約ではなく、フローごとに決定する必要があります。
o SQRT: The square root function.
o SQRT：平方根関数。
o ROUND: The round function.
o ROUND：ラウンド関数。
End-to-end delay is the result of propagation delay, serialization delay, service delay in a switch, medium-access delay, and queuing delay, summed over the network elements along the path. AQM schemes may reduce the queuing delay by providing signals to the sender on the emergence of congestion, but any impact on the goodput must be carefully considered. This section presents the metrics that could be used to better quantify (1) the reduction of latency, (2) maximization of goodput, and (3) the trade-off between these two. This section provides normative requirements for metrics that can be used to assess the performance of an AQM scheme.
エンドツーエンドの遅延は、伝搬遅延、シリアル化遅延、スイッチのサービス遅延、メディアアクセス遅延、およびキューイング遅延の結果であり、パスに沿ったネットワーク要素全体で合計されます。 AQMスキームは、輻輳の発生に関する信号を送信者に提供することにより、キューイングの遅延を減らす可能性がありますが、グッドプットへの影響は慎重に検討する必要があります。このセクションでは、（1）待ち時間の削減、（2）グッドプットの最大化、および（3）これら2つの間のトレードオフをより正確に定量化するために使用できるメトリックを示します。このセクションでは、AQMスキームのパフォーマンスを評価するために使用できるメトリックの規範的な要件を示します。
Some metrics listed in this section are not suited to every type of traffic detailed in the rest of this document. It is therefore not necessary to measure all of the following metrics: the chosen metric may not be relevant to the context of the evaluation scenario (e.g., latency vs. goodput trade-off in application-limited traffic scenarios). Guidance is provided for each metric.
このセクションにリストされているいくつかのメトリックは、このドキュメントの残りの部分で詳述されているすべてのタイプのトラフィックには適していません。したがって、次のすべての測定基準を測定する必要はありません。選択された測定基準は、評価シナリオのコンテキストに関連しない場合があります（たとえば、アプリケーション制限のあるトラフィックシナリオにおけるレイテンシとグッドプットのトレードオフ）。各メトリックについてガイダンスが提供されます。
The flow completion time is an important performance metric for the end-user when the flow size is finite. The definition of the flow size may be a source of contradictions, thus, this metric can consider a flow as a single file. Considering the fact that an AQM scheme may drop/mark packets, the flow completion time is directly linked to the dropping/marking policy of the AQM scheme. This metric helps to better assess the performance of an AQM depending on the flow size. The Flow Completion Time (FCT) is related to the flow size (Fs) and the goodput for the flow (G) as follows:
フロー完了時間がフローサイズが有限である場合、エンドユーザーにとって重要なパフォーマンスメトリックです。フローサイズの定義は矛盾の原因となる可能性があるため、このメトリックではフローを単一のファイルと見なすことができます。 AQMスキームがパケットをドロップ/マーキングする可能性があるという事実を考慮すると、フロー完了時間は、AQMスキームのドロップ/マーキングポリシーに直接リンクしています。このメトリックは、フローサイズに応じてAQMのパフォーマンスをより適切に評価するのに役立ちます。フロー完了時間（FCT）は、フローサイズ（Fs）とフローのグッドプット（G）に次のように関連しています。
FCT [s] = Fs [byte] / ( G [bit/s] / 8 [bit/byte] )
Where flow size is the size of the transport-layer payload in bits and goodput is the transport-layer payload transfer time (described in Section 2.5).
ここで、フローサイズはトランスポート層ペイロードのビット単位のサイズであり、グッドプットはトランスポート層ペイロード転送時間です（セクション2.5で説明）。
If this metric is used to evaluate the performance of web transfers, it is suggested to rather consider the time needed to download all the objects that compose the web page, as this makes more sense in terms of user experience, rather than assessing the time needed to download each object.
このメトリックを使用してWeb転送のパフォーマンスを評価する場合は、Webページを構成するすべてのオブジェクトをダウンロードするのに必要な時間を考慮することをお勧めします。これは、必要な時間を評価するのではなく、ユーザーエクスペリエンスの点でより意味があるためです。各オブジェクトをダウンロードします。
The flow startup time is the time between when the request was sent from the client and when the server starts to transmit data. The amount of packets dropped by an AQM may seriously affect the waiting period during which the data transfer has not started. This metric would specifically focus on the operations such as DNS lookups, TCP opens, and Secure Socket Layer (SSL) handshakes.
フロー開始時間は、リクエストがクライアントから送信されてからサーバーがデータの送信を開始するまでの時間です。 AQMによってドロップされたパケットの量は、データ転送が開始されていない待機期間に深刻な影響を与える可能性があります。このメトリックは、DNSルックアップ、TCPオープン、Secure Socket Layer（SSL）ハンドシェイクなどの操作に特に焦点を当てます。
Packet loss can occur en route, this can impact the end-to-end performance measured at the receiver end.
途中でパケット損失が発生する可能性があります。これは、受信側で測定されるエンドツーエンドのパフォーマンスに影響を与える可能性があります。
The tester should evaluate the loss experienced at the receiver end using one of two metrics:
テスターは、次の2つのメトリックのいずれかを使用して、受信側で発生した損失を評価する必要があります。
o The packet loss ratio: This metric is to be frequently measured during the experiment. The long-term loss ratio is of interest for steady-state scenarios only;
o パケット損失率：このメトリックは、実験中に頻繁に測定されます。長期損失率は、定常状態のシナリオでのみ重要です。
o The interval between consecutive losses: The time between two losses is to be measured.
o 連続する損失の間隔：2つの損失間の時間を測定します。
The packet loss ratio can be assessed by simply evaluating the loss ratio as a function of the number of lost packets and the total number of packets sent. This might not be easily done in laboratory testing, for which these guidelines advise the tester:
パケット損失率は、損失率を、失われたパケットの数と送信されたパケットの総数の関数として評価するだけで評価できます。これは、これらのガイドラインがテスターに助言する実験室テストでは簡単に行われないかもしれません：
o To check that for every packet, a corresponding packet was received within a reasonable time, as presented in the document that proposes a metric for one-way packet loss across Internet paths [RFC7680].
o すべてのパケットについてそれをチェックするために、対応するパケットが妥当な時間内に受信されました。インターネットパス[RFC7680]での一方向のパケット損失のメトリックを提案するドキュメントに示されています。
o To keep a count of all packets sent, and a count of the non-duplicate packets received, as discussed in [RFC2544], which presents a benchmarking methodology.
o [RFC2544]で説明されているように、送信されたすべてのパケットの数、および受信された重複していないパケットの数を保持するため。ベンチマークの方法論が提示されています。
The interval between consecutive losses, which is also called a "gap", is a metric of interest for Voice over IP (VoIP) traffic [RFC3611].
「ギャップ」とも呼ばれる連続した損失の間隔は、Voice over IP（VoIP）トラフィック[RFC3611]にとって重要な測定基準です。
One goal of an AQM algorithm is to help to avoid global synchronization of flows sharing a bottleneck buffer on which the AQM operates ([RFC2309] and [RFC7567]). The "degree" of packet-loss synchronization between flows should be assessed, with and without the AQM under consideration.
AQMアルゴリズムの1つの目標は、AQMが動作するボトルネックバッファーを共有するフローのグローバル同期を回避できるようにすることです（[RFC2309]および[RFC7567]）。検討中のAQMの有無にかかわらず、フロー間のパケット損失同期の「程度」を評価する必要があります。
Loss synchronization among flows may be quantified by several slightly different metrics that capture different aspects of the same issue [HASS2008]. However, in real-world measurements the choice of metric could be imposed by practical considerations -- e.g., whether fine-grained information on packet losses at the bottleneck is available or not. For the purpose of AQM characterization, a good candidate metric is the global synchronization ratio, measuring the proportion of flows losing packets during a loss event. This metric can be used in real-world experiments to characterize synchronization along arbitrary Internet paths [JAY2006].
フロー間の同期の損失は、同じ問題のさまざまな側面を捉えたいくつかのわずかに異なるメトリックによって定量化される場合があります[HASS2008]。ただし、実際の測定では、ボトルネックでのパケット損失に関するきめの細かい情報が利用できるかどうかなど、実際の考慮事項によってメトリックの選択が課される可能性があります。 AQM特性評価の目的で、適切な候補メトリックは、グローバル同期比であり、損失イベント中にパケットを失うフローの比率を測定します。この指標は、実際の実験で任意のインターネットパスに沿った同期を特徴付けるために使用できます[JAY2006]。
If an AQM scheme is evaluated using real-life network environments, it is worth pointing out that some network events, such as failed link restoration may cause synchronized losses between active flows, and thus confuse the meaning of this metric.
AQMスキームが実際のネットワーク環境を使用して評価される場合、リンクの復元の失敗などの一部のネットワークイベントがアクティブフロー間の同期損失を引き起こし、このメトリックの意味を混乱させる可能性があることを指摘する価値があります。
The goodput has been defined as the number of bits per the unit of time forwarded to the correct destination interface, minus any bits lost or retransmitted, such as proposed in Section 3.17 of [RFC2647], which describes the benchmarking terminology for firewall performances. This definition requires that the test setup needs to be qualified to assure that it is not generating losses on its own.
グッドプットは、[RFC2647]のセクション3.17で提案されているように、正しい宛先インターフェースに転送された単位時間あたりのビット数から、失われたり再送信されたビットを差し引いたものとして定義されています。この定義では、それ自体で損失が発生しないことを保証するために、テストセットアップを修飾する必要があります。
Measuring the end-to-end goodput provides an appreciation of how well an AQM scheme improves transport and application performance. The measured end-to-end goodput is linked to the dropping/marking policy of the AQM scheme -- e.g., the fewer the number of packet drops, the fewer packets need retransmission, minimizing the impact of AQM on transport and application performance. Additionally, an AQM scheme may resort to Explicit Congestion Notification (ECN) marking as an initial means to control delay. Again, marking packets instead of dropping them reduces the number of packet retransmissions and increases goodput. End-to-end goodput values help to evaluate the AQM scheme's effectiveness in minimizing packet drops that impact application performance and to estimate how well the AQM scheme works with ECN.
エンドツーエンドのグッドプットを測定することで、AQMスキームがトランスポートとアプリケーションのパフォーマンスをどれほど向上させるかを理解できます。測定されたエンドツーエンドのグッドプットは、AQMスキームのドロップ/マーキングポリシーにリンクされています。たとえば、パケットドロップの数が少ないほど、再送信が必要なパケットが少なくなり、トランスポートおよびアプリケーションのパフォーマンスに対するAQMの影響を最小限に抑えます。さらに、AQMスキームは、遅延を制御する最初の手段として、明示的輻輳通知（ECN）マーキングに頼ることがあります。この場合も、パケットをドロップする代わりにマークを付けると、パケットの再送信の数が減り、グッドプットが向上します。エンドツーエンドのグッドプット値は、アプリケーションのパフォーマンスに影響を与えるパケットドロップを最小限に抑えるAQMスキームの有効性を評価し、AQMスキームがECNとどの程度うまく機能するかを推定するのに役立ちます。
The measurement of the goodput allows the tester to evaluate to what extent an AQM is able to maintain a high bottleneck utilization. This metric should also be obtained frequently during an experiment, as the long-term goodput is relevant for steady-state scenarios only and may not necessarily reflect how the introduction of an AQM actually impacts the link utilization during a certain period of time. Fluctuations in the values obtained from these measurements may depend on other factors than the introduction of an AQM, such as link-layer losses due to external noise or corruption, fluctuating bandwidths (IEEE 802.11 WLANs), heavy congestion levels, or the transport layer's rate reduction by the congestion control mechanism.
グッドプットの測定により、テスターは、AQMが高いボトルネック使用率を維持できる範囲を評価できます。長期グッドプットは定常状態のシナリオにのみ関連し、AQMの導入が特定の期間のリンク使用率に実際にどのように影響するかを必ずしも反映しない可能性があるため、このメトリックは実験中にも頻繁に取得する必要があります。これらの測定から得られた値の変動は、外部ノイズまたは破損によるリンク層の損失、変動する帯域幅（IEEE 802.11 WLAN）、過密レベル、またはトランスポート層のレートなど、AQMの導入以外の他の要因に依存する場合があります輻輳制御メカニズムによる削減。
The latency, or the one-way delay metric, is discussed in [RFC7679]. There is a consensus on an adequate metric for the jitter that represents the one-way delay variations for packets from the same flow: the Packet Delay Variation (PDV) serves well in all use cases [RFC5481].
待ち時間、つまり一方向の遅延メトリックは、[RFC7679]で説明されています。同じフローからのパケットの片方向遅延変動を表すジッターの適切なメトリックについては合意があります。パケット遅延変動（PDV）は、すべてのユースケースで適切に機能します[RFC5481]。
The end-to-end latency includes components other than just the queuing delay, such as the signal-processing delay, transmission delay, and processing delay. Moreover, the jitter is caused by variations in queuing and processing delay (e.g., scheduling effects). The introduction of an AQM scheme would impact end-to-end latency and jitter, and therefore these metrics should be considered in the end-to-end evaluation of performance.
エンドツーエンドのレイテンシには、信号処理遅延、送信遅延、処理遅延など、キューイング遅延以外のコンポーネントが含まれます。さらに、ジッターはキューイングおよび処理遅延の変動（たとえば、スケジューリング効果）によって引き起こされます。 AQMスキームの導入は、エンドツーエンドのレイテンシとジッタに影響を与えるため、これらのメトリックはパフォーマンスのエンドツーエンドの評価で検討する必要があります。
The metrics presented in this section may be considered in order to discuss and quantify the trade-off between latency and goodput.
このセクションで説明するメトリックは、レイテンシとグッドプットの間のトレードオフを議論して定量化するために検討することができます。
With regards to the goodput, and in addition to the long-term stationary goodput value, it is recommended to take measurements at every multiple of the minimum RTT (minRTT) between A and B. It is suggested to take measurements at least every K * minRTT (to smooth out the fluctuations), with K=10. Higher values for K can be considered whenever it is more appropriate for the presentation of the results, since the value for K may depend on the network's path characteristics. The measurement period must be disclosed for each experiment, and when results/values are compared across different AQM schemes, the comparisons should use exactly the same measurement periods. With regards to latency, it is recommended to take the samples on a per-packet basis whenever possible, depending on the features provided by the hardware and software and the impact of sampling itself on the hardware performance.
グッドプットに関して、および長期の定常グッドプット値に加えて、AとBの間の最小RTT（minRTT）の倍数ごとに測定することをお勧めします。少なくともK *ごとに測定することをお勧めします。 minRTT（変動を滑らかにするため）、K = 10。 Kの値はネットワークのパス特性に依存する可能性があるため、結果の表示に適している場合はいつでも、Kの値を高くすることができます。測定期間は実験ごとに開示する必要があり、結果/値を異なるAQMスキーム間で比較する場合、比較ではまったく同じ測定期間を使用する必要があります。レイテンシに関しては、ハードウェアとソフトウェアが提供する機能、およびサンプリング自体がハードウェアパフォーマンスに与える影響に応じて、可能な限りパケットごとにサンプルを取得することをお勧めします。
From each of these sets of measurements, the cumulative density function (CDF) of the considered metrics should be computed. If the considered scenario introduces dynamically varying parameters, temporal evolution of the metrics could also be generated. For each scenario, the following graph may be generated: the x-axis shows a queuing delay (that is, the average per-packet delay in excess of minimum RTT), the y-axis the goodput. Ellipses are computed as detailed in [WINS2014]: "We take each individual [...] run [...] as one point, and then compute the 1-epsilon elliptic contour of the maximum-likelihood 2D Gaussian distribution that explains the points. [...] we plot the median per-sender throughput and queueing delay as a circle. [...] The orientation of an ellipse represents the covariance between the throughput and delay measured for the protocol." This graph provides part of a better understanding of (1) the delay/goodput trade-off for a given congestion control mechanism (Section 5), and (2) how the goodput and average queue delay vary as a function of the traffic load (Section 8.2).
これらの各測定セットから、考慮されるメトリックの累積密度関数（CDF）を計算する必要があります。検討中のシナリオが動的に変化するパラメーターを導入する場合、メトリックの時間的進化も生成される可能性があります。シナリオごとに、次のグラフが生成されます。x軸はキューイング遅延（つまり、最小RTTを超える平均パケットごとの遅延）、y軸はグッドプットを示します。楕円は[WINS2014]で詳述されているように計算されます。「個々の[...]実行[...]を1つの点として、次に最尤2Dガウス分布の1ε楕円輪郭を計算します。ポイント。[...]送信者ごとのスループットの中央値とキューイング遅延を円としてプロットします。[...]楕円の向きは、プロトコルで測定されたスループットと遅延の間の共分散を表します。このグラフは、（1）特定の輻輳制御メカニズムの遅延/グッドプットトレードオフ（セクション5）、および（2）トラフィック負荷の関数としてグッドプットおよび平均キュー遅延がどのように変化するかをよりよく理解するための一部を提供します（セクション8.2）。
This section presents the topology that can be used for each of the following scenarios, the corresponding notations, and discusses various assumptions that have been made in the document.
このセクションでは、以下の各シナリオで使用できるトポロジーと対応する表記を示し、ドキュメントで行われたさまざまな前提について説明します。
+--------------+ +--------------+
|sender A_i | |receive B_i |
|--------------| |--------------|
| SEN.Flow1.1 +---------+ +-----------+ REC.Flow1.1 |
| + | | | | + |
| | | | | | | |
| + | | | | + |
| SEN.Flow1.X +-----+ | | +--------+ REC.Flow1.X |
+--------------+ | | | | +--------------+
+ +-+---+---+ +--+--+---+ +
| |Router L | |Router R | |
| |---------| |---------| |
| | AQM | | | |
| | BuffSize| | BuffSize| |
| | (Bsize) +-----+ (Bsize) | |
| +-----+--++ ++-+------+ |
+ | | | | +
+--------------+ | | | | +--------------+
|sender A_n | | | | | |receive B_n |
|--------------| | | | | |--------------|
| SEN.FlowN.1 +---------+ | | +-----------+ REC.FlowN.1 |
| + | | | | + |
| | | | | | | |
| + | | | | + |
| SEN.FlowN.Y +------------+ +-------------+ REC.FlowN.Y |
+--------------+ +--------------+
Figure 1: Topology and Notations
図1：トポロジーと表記法
Figure 1 is a generic topology where:
図1は、次の一般的なトポロジです。
o The traffic profile is a set of flows with similar characteristics -- RTT, congestion control scheme, transport protocol, etc.;
o トラフィックプロファイルは、RTT、輻輳制御スキーム、トランスポートプロトコルなど、同様の特性を持つ一連のフローです。
o Senders with different traffic characteristics (i.e., traffic profiles) can be introduced;
o さまざまなトラフィック特性（つまり、トラフィックプロファイル）を持つ送信者を紹介できます。
o The timing of each flow could be different (i.e., when does each flow start and stop?);
o 各フローのタイミングは異なる場合があります（つまり、各フローがいつ開始および停止するか）。
o Each traffic profile can comprise various number of flows;
o 各トラフィックプロファイルには、さまざまな数のフローを含めることができます。
o Each link is characterized by a couple (one-way delay, capacity);
o 各リンクは、カップル（一方向の遅延、容量）によって特徴付けられます。
o Sender A_i is instantiated for each traffic profile. A corresponding receiver B_i is instantiated for receiving the flows in the profile;
o 送信者A_iは、トラフィックプロファイルごとにインスタンス化されます。プロファイル内のフローを受信するために、対応するレシーバーB_iがインスタンス化されます。
o Flows share a bottleneck (the link between routers L and R);
o フローはボトルネック（ルーターLとRの間のリンク）を共有します。
o The tester should consider both scenarios of asymmetric and symmetric bottleneck links in terms of bandwidth. In the case of an asymmetric link, the capacity from senders to receivers is higher than the one from receivers to senders; the symmetric link scenario provides a basic understanding of the operation of the AQM mechanism, whereas the asymmetric link scenario evaluates an AQM mechanism in a more realistic setup;
o テスターは、帯域幅の観点から、非対称および対称のボトルネックリンクの両方のシナリオを考慮する必要があります。非対称リンクの場合、送信側から受信側への容量は、受信側から送信側への容量よりも大きくなります。非対称リンクシナリオは、AQMメカニズムの動作の基本的な理解を提供しますが、非対称リンクシナリオは、より現実的な設定でAQMメカニズムを評価します。
o In asymmetric link scenarios, the tester should study the bidirectional traffic between A and B (downlink and uplink) with the AQM mechanism deployed in one direction only. The tester may additionally consider a scenario with the AQM mechanism being deployed in both directions. In each scenario, the tester should investigate the impact of the drop policy of the AQM on TCP ACK packets and its impact on the performance (Section 9.2).
o 非対称リンクのシナリオでは、AQMメカニズムが一方向にのみ展開された状態で、AとBの間の双方向トラフィック（ダウンリンクとアップリンク）をテストする必要があります。テスターは、AQMメカニズムが両方向に展開されているシナリオをさらに検討する場合があります。各シナリオで、テスターは、TCP ACKパケットに対するAQMのドロップポリシーの影響とパフォーマンスへの影響を調査する必要があります（セクション9.2）。
Although this topology may not perfectly reflect actual topologies, the simple topology is commonly used in the world of simulations and small testbeds. It can be considered as adequate to evaluate AQM proposals [TCPEVAL]. Testers ought to pay attention to the topology used to evaluate an AQM scheme when comparing it with a newly proposed AQM scheme.
このトポロジーは実際のトポロジーを完全に反映しているわけではありませんが、単純なトポロジーはシミュレーションと小さなテストベッドの世界で一般的に使用されています。 AQMの提案を評価することは適切であると考えることができます[TCPEVAL]。テスターは、新しく提案されたAQMスキームと比較するときに、AQMスキームの評価に使用されるトポロジに注意を払う必要があります。
The size of the buffers should be carefully chosen, and may be set to the bandwidth-delay product; the bandwidth being the bottleneck capacity and the delay being the largest RTT in the considered network. The size of the buffer can impact the AQM performance and is a dimensioning parameter that will be considered when comparing AQM proposals.
バッファのサイズは慎重に選択する必要があり、帯域幅と遅延の積に設定できます。帯域幅はボトルネック容量であり、遅延は考慮されているネットワークで最大のRTTです。バッファーのサイズはAQMのパフォーマンスに影響を与える可能性があり、AQMの提案を比較するときに考慮されるディメンションパラメーターです。
If a specific buffer size is required, the tester must justify and detail the way the maximum queue size is set. Indeed, the maximum size of the buffer may affect the AQM's performance and its choice should be elaborated for a fair comparison between AQM proposals. While comparing AQM schemes, the buffer size should remain the same across the tests.
特定のバッファーサイズが必要な場合、テスターは最大キューサイズの設定方法を正当化し、詳細に説明する必要があります。実際、バッファーの最大サイズはAQMのパフォーマンスに影響を与える可能性があるため、AQM提案間の公平な比較のために、バッファーの選択について詳しく説明する必要があります。 AQMスキームを比較している間、バッファーサイズはテスト全体で同じままである必要があります。
This document considers running three different congestion control algorithms between A and B:
このドキュメントでは、AとBの間で3つの異なる輻輳制御アルゴリズムを実行することを検討しています。
o Standard TCP congestion control: The base-line congestion control is TCP NewReno with selective acknowledgment (SACK) [RFC5681].
o 標準のTCP輻輳制御：ベースラインの輻輳制御は、選択的確認応答（SACK）を備えたTCP NewRenoです[RFC5681]。
o Aggressive congestion controls: A base-line congestion control for this category is CUBIC [CUBIC].
o 積極的な輻輳制御：このカテゴリのベースラインの輻輳制御はCUBIC [CUBIC]です。
o Less-than-Best-Effort (LBE) congestion controls: Per [RFC6297], an LBE service "results in smaller bandwidth and/or delay impact on standard TCP than standard TCP itself, when sharing a bottleneck with it." A base-line congestion control for this category is Low Extra Delay Background Transport (LEDBAT) [RFC6817].
o ベストエフォート未満（LBE）の輻輳制御：LBEサービスは[RFC6297]に従い、「ボトルネックを共有すると、標準のTCP自体よりも標準のTCPに比べて帯域幅や遅延の影響が小さくなります。」このカテゴリのベースラインの輻輳制御は、低遅延遅延バックグラウンドトランスポート（LEDBAT）[RFC6817]です。
Other transport congestion controls can OPTIONALLY be evaluated in addition. Recent transport layer protocols are not mentioned in the following sections, for the sake of simplicity.
その他のトランスポート輻輳制御は、オプションでさらに評価できます。簡潔にするために、最近のトランスポート層プロトコルについては、以降のセクションでは触れません。
4. Methodology, Metrics, AQM Comparisons, Packet Sizes, Scheduling, and ECN
4. 方法論、メトリック、AQM比較、パケットサイズ、スケジューリング、およびECN
A description of each test setup should be detailed to allow this test to be compared with other tests. This also allows others to replicate the tests if needed. This test setup should detail software and hardware versions. The tester could make its data available.
このテストを他のテストと比較できるように、各テストセットアップの詳細を説明する必要があります。これにより、必要に応じて他のユーザーがテストを複製することもできます。このテストセットアップでは、ソフトウェアとハードウェアのバージョンを詳しく説明する必要があります。テスターはそのデータを利用可能にすることができます。
The proposals should be evaluated on real-life systems, or they may be evaluated with event-driven simulations (such as ns-2, ns-3, OMNET, etc.). The proposed scenarios are not bound to a particular evaluation toolset.
提案は実際のシステムで評価する必要があります。または、イベント駆動型シミュレーション（ns-2、ns-3、OMNETなど）で評価することもできます。提案されたシナリオは、特定の評価ツールセットにバインドされていません。
The tester is encouraged to make the detailed test setup and the results publicly available.
テスターは、詳細なテスト設定と結果を公開することをお勧めします。
This document presents the end-to-end metrics that ought to be used to evaluate the trade-off between latency and goodput as described in Section 2. In addition to the end-to-end metrics, the queue-level metrics (normally collected at the device operating the AQM) provide a better understanding of the AQM behavior under study and the impact of its internal parameters. Whenever it is possible (e.g., depending on the features provided by the hardware/software), these guidelines advise considering queue-level metrics, such as link utilization, queuing delay, queue size, or packet drop/mark statistics in addition to the AQM-specific parameters. However, the evaluation must be primarily based on externally observed end-to-end metrics.
このドキュメントでは、セクション2で説明したレイテンシとグッドプットの間のトレードオフを評価するために使用する必要があるエンドツーエンドのメトリックを示します。エンドツーエンドのメトリックに加えて、キューレベルのメトリック（通常は収集されます） AQMを操作するデバイスで）、調査中のAQMの動作とその内部パラメーターの影響をよりよく理解できます。可能な場合はいつでも（たとえば、ハードウェア/ソフトウェアによって提供される機能に応じて）、これらのガイドラインは、AQMに加えて、リンク使用率、キューイング遅延、キューサイズ、パケットドロップ/マーク統計などのキューレベルのメトリックを検討することをお勧めします固有のパラメータ。ただし、評価は主に外部から観察されたエンドツーエンドのメトリックに基づく必要があります。
These guidelines do not aim to detail the way these metrics can be measured, since that is expected to depend on the evaluation toolset.
これらのガイドラインは、評価ツールセットに依存することが予想されるため、これらのメトリックを測定する方法を詳しく説明することを目的としていません。
This document recognizes that these guidelines may be used for comparing AQM schemes.
このドキュメントでは、これらのガイドラインをAQMスキームの比較に使用できることを認識しています。
AQM schemes need to be compared against both performance and deployment categories. In addition, this section details how best to achieve a fair comparison of AQM schemes by avoiding certain pitfalls.
AQMスキームは、パフォーマンスと展開の両方のカテゴリと比較する必要があります。さらに、このセクションでは、特定の落とし穴を回避することにより、AQMスキームの公正な比較を実現するための最良の方法について詳しく説明します。
AQM schemes should be compared against the generic scenarios that are summarized in Section 13. AQM schemes may be compared for specific network environments such as data centers, home networks, etc. If an AQM scheme has parameter(s) that were externally tuned for optimization or other purposes, these values must be disclosed.
AQMスキームは、セクション13で要約されている一般的なシナリオと比較する必要があります。AQMスキームは、データセンター、ホームネットワークなどの特定のネットワーク環境で比較できます。AQMスキームに最適化のために外部で調整されたパラメーターがある場合またはその他の目的で、これらの値を開示する必要があります。
AQM schemes belong to different varieties such as queue-length based schemes (for example, RED) or queuing-delay based scheme (for example, CoDel, PIE). AQM schemes expose different control knobs associated with different semantics. For example, while both PIE and CoDel are queuing-delay based schemes and each expose a knob to control the queuing delay -- PIE's "queuing delay reference" vs. CoDel's "queuing delay target", the two tuning parameters of the two schemes have different semantics, resulting in different control points. Such differences in AQM schemes can be easily overlooked while making comparisons.
AQMスキームは、キューの長さベースのスキーム（REDなど）またはキューイング遅延ベースのスキーム（CoDel、PIEなど）など、さまざまな種類に属しています。 AQMスキームは、異なるセマンティクスに関連付けられた異なる制御ノブを公開します。たとえば、PIEとCoDelはどちらもキューイング遅延ベースのスキームであり、それぞれがキューイング遅延を制御するためのノブを公開しますが、PIEの「キューイング遅延リファレンス」とCoDelの「キューイング遅延ターゲット」は、2つのスキームの2つのチューニングパラメーターにあります。意味が異なるため、結果として異なる制御点が生じます。このようなAQMスキームの違いは、比較の際に簡単に見落とされる可能性があります。
This document recommends the following procedures for a fair performance comparison between the AQM schemes:
このドキュメントでは、AQMスキーム間の公平なパフォーマンス比較のために次の手順を推奨しています。
1. Similar control parameters and implications: Testers should be aware of the control parameters of the different schemes that control similar behavior. Testers should also be aware of the input value ranges and corresponding implications. For example, consider two different schemes -- (A) queue-length based AQM scheme, and (B) queuing-delay based scheme. A and B are likely to have different kinds of control inputs to control the target delay -- the target queue length in A vs. target queuing delay in B, for example. Setting parameter values such as 100 MB for A vs. 10 ms for B will have different implications depending on evaluation context. Such context-dependent implications must be considered before drawing conclusions on performance comparisons. Also, it would be preferable if an AQM proposal listed such parameters and discussed how each relates to network characteristics such as capacity, average RTT, etc.
1. 同様の制御パラメーターとその影響：テスト担当者は、同様の動作を制御するさまざまなスキームの制御パラメーターに注意する必要があります。テスターは、入力値の範囲と対応する影響についても認識する必要があります。たとえば、（A）キュー長に基づくAQMスキームと（B）キューイング遅延に基づくスキームという2つの異なるスキームを考えてみましょう。 AとBには、ターゲット遅延を制御するための異なる種類の制御入力がある可能性があります-たとえば、Aのターゲットキューの長さ対Bのターゲットキューイング遅延。 Aの100 MB対Bの10 msなどのパラメーター値の設定は、評価コンテキストに応じて異なる意味を持ちます。このようなコンテキスト依存の影響は、パフォーマンスの比較について結論を出す前に検討する必要があります。また、AQM提案がそのようなパラメータをリストし、それぞれが容量、平均RTTなどのネットワーク特性にどのように関連するかを議論した場合、それは望ましいでしょう。
2. Compare over a range of input configurations: There could be situations when the set of control parameters that affect a specific behavior have different semantics between the two AQM schemes. As mentioned above, PIE has tuning parameters to control queue delay that have different semantics from those used in CoDel. In such situations, these schemes need to be compared over a range of input configurations. For example, compare PIE vs. CoDel over the range of target delay input configurations.
2. さまざまな入力構成を比較します。特定の動作に影響を与える一連の制御パラメーターが、2つのAQMスキーム間で異なるセマンティクスを持つ場合があります。上記のように、PIEにはCoDelで使用されるものとは異なるセマンティクスを持つキュー遅延を制御するためのチューニングパラメーターがあります。このような状況では、これらのスキームをさまざまな入力構成で比較する必要があります。たとえば、ターゲット遅延入力構成の範囲でPIEとCoDelを比較します。
AQM schemes must be compared against deployment criteria such as the parameter sensitivity (Section 8.3), auto-tuning (Section 12), or implementation cost (Section 11).
AQMスキームは、パラメーター感度（セクション8.3）、自動チューニング（セクション12）、実装コスト（セクション11）などの展開基準と比較する必要があります。
An AQM scheme may be considering packet sizes while generating congestion signals [RFC7141]. For example, control packets such as DNS requests/responses, TCP SYNs/ACKs are small, but their loss can severely impact application performance. An AQM scheme may therefore be biased towards small packets by dropping them with lower probability compared to larger packets. However, such an AQM scheme is unfair to data senders generating larger packets. Data senders, malicious or otherwise, are motivated to take advantage of such an AQM scheme by transmitting smaller packets, and this could result in unsafe deployments and unhealthy transport and/or application designs.
AQMスキームは、輻輳信号を生成する際にパケットサイズを考慮している場合があります[RFC7141]。たとえば、DNS要求/応答、TCP SYN / ACKなどの制御パケットは小さいですが、それらの損失はアプリケーションのパフォーマンスに深刻な影響を与える可能性があります。したがって、AQMスキームは、大きなパケットに比べて確率が低くなるようにドロップすることで、小さなパケットに偏らせることができます。ただし、そのようなAQMスキームは、より大きなパケットを生成するデータ送信者には不公平です。悪意のある、またはその他のデータ送信者は、より小さなパケットを送信することでそのようなAQMスキームを利用しようと動機付けられ、これは安全でない展開や不健全なトランスポートやアプリケーションの設計につながる可能性があります。
An AQM scheme should adhere to the recommendations outlined in the Best Current Practice for dropping and marking packets [BCP41], and should not provide undue advantage to flows with smaller packets, such as discussed in Section 4.4 of the AQM recommendation document [RFC7567]. In order to evaluate if an AQM scheme is biased towards flows with smaller size packets, traffic can be generated, as defined in Section 8.2.2, where half of the flows have smaller packets (e.g., 500-byte packets) than the other half of the flow (e.g., 1500-byte packets). In this case, the metrics reported could be the same as in Section 6.3, where Category I is the set of flows with smaller packets and Category II the one with larger packets. The bidirectional scenario could also be considered (Section 9.2).
AQMスキームは、パケットのドロップとマーキングに関する現在のベストプラクティス[BCP41]で概説されている推奨事項に準拠する必要があり、AQM推奨ドキュメント[RFC7567]のセクション4.4で説明されているように、パケットが小さいフローに過度の利点を提供しないでください。 AQMスキームが小さいサイズのパケットのフローに偏っているかどうかを評価するために、セクション8.2.2で定義されているようにトラフィックを生成できます。ここで、フローの半分には他の半分よりも小さいパケット（たとえば、500バイトのパケット）があります。フローのサイズ（例：1500バイトのパケット）。この場合、報告されるメトリックはセクション6.3と同じです。ここで、カテゴリIは小さなパケットのフローのセットであり、カテゴリIIは大きなパケットのフローのセットです。双方向シナリオも検討できます（セクション9.2）。
ECN [RFC3168] is an alternative that allows AQM schemes to signal to receivers about network congestion that does not use packet drops. There are benefits to providing ECN support for an AQM scheme [WELZ2015].
ECN [RFC3168]は、AQMスキームがパケットドロップを使用しないネットワーク輻輳について受信者に通知できるようにする代替手段です。 AQMスキーム[WELZ2015]にECNサポートを提供することには利点があります。
If the tested AQM scheme can support ECN, the testers must discuss and describe the support of ECN, such as discussed in the AQM recommendation document [RFC7567]. Also, the AQM's ECN support can be studied and verified by replicating tests in Section 6.2 with ECN turned ON at the TCP senders. The results can be used not only to evaluate the performance of the tested AQM with and without ECN markings, but also to quantify the interest of enabling ECN.
テストされたAQMスキームがECNをサポートできる場合、テスターは、AQM推奨ドキュメント[RFC7567]で説明されているように、ECNのサポートについて話し合い、説明する必要があります。また、TCP送信側でECNをオンにしてセクション6.2のテストを複製することにより、AQMのECNサポートを調査および検証できます。結果は、ECNマーキングを使用した場合と使用しない場合のテスト済みAQMのパフォーマンスを評価するためだけでなく、ECNを有効にすることの関心を定量化するためにも使用できます。
A network device may use per-flow or per-class queuing with a scheduling algorithm to either prioritize certain applications or classes of traffic, limit the rate of transmission, or to provide isolation between different traffic flows within a common class, such as discussed in Section 2.1 of the AQM recommendation document [RFC7567].
ネットワークデバイスは、スケジューリングアルゴリズムでフローごとまたはクラスごとのキューイングを使用して、特定のアプリケーションまたはトラフィックのクラスに優先順位を付けたり、伝送速度を制限したり、共通クラス内の異なるトラフィックフロー間の分離を提供したりできます。 AQM推奨文書[RFC7567]のセクション2.1。
The scheduling and the AQM conjointly impact the end-to-end performance. Therefore, the AQM proposal must discuss the feasibility of adding scheduling combined with the AQM algorithm. It can be explained whether the dropping policy is applied when packets are being enqueued or dequeued.
スケジューリングとAQMは相まって、エンドツーエンドのパフォーマンスに影響を与えます。したがって、AQMの提案では、AQMアルゴリズムと組み合わせたスケジューリングを追加することの実現可能性について検討する必要があります。パケットがエンキューまたはデキューされるときにドロップポリシーが適用されるかどうかを説明できます。
These guidelines do not propose guidelines to assess the performance of scheduling algorithms. Indeed, as opposed to characterizing AQM schemes that is related to their capacity to control the queuing delay in a queue, characterizing scheduling schemes is related to the scheduling itself and its interaction with the AQM scheme. As one example, the scheduler may create sub-queues and the AQM scheme may be applied on each of the sub-queues, and/or the AQM could be applied on the whole queue. Also, schedulers might, such as FQ-CoDel [HOEI2015] or FavorQueue [ANEL2014], introduce flow prioritization. In these cases, specific scenarios should be proposed to ascertain that these scheduler schemes not only help in tackling the bufferbloat, but also are robust under a wide variety of operating conditions. This is out of the scope of this document, which focuses on dropping and/or marking AQM schemes.
これらのガイドラインは、スケジューリングアルゴリズムのパフォーマンスを評価するためのガイドラインを提案していません。実際、キュー内のキューイング遅延を制御する能力に関連するAQMスキームの特徴付けとは対照的に、スケジューリングスキームの特徴付けは、スケジューリング自体とそのAQMスキームとの相互作用に関連しています。一例として、スケジューラはサブキューを作成することができ、ＡＱＭスキームは各サブキューに適用することができ、および／またはＡＱＭはキュー全体に適用することができる。また、FQ-CoDel [HOEI2015]やFavorQueue [ANEL2014]などのスケジューラーは、フローの優先順位付けを導入する場合があります。これらの場合、特定のシナリオを提案して、これらのスケジューラスキームがバッファブロートへの取り組みに役立つだけでなく、さまざまな動作条件下で堅牢であることを確認する必要があります。これは、このドキュメントの範囲外であり、AQMスキームの削除やマーキングに焦点を当てています。
Network and end-devices need to be configured with a reasonable amount of buffer space to absorb transient bursts. In some situations, network providers tend to configure devices with large buffers to avoid packet drops triggered by a full buffer and to maximize the link utilization for standard loss-based TCP traffic.
ネットワークとエンドデバイスは、一時的なバーストを吸収するために、適度な量のバッファスペースで構成する必要があります。状況によっては、ネットワークプロバイダーは、デバイスを大きなバッファーで構成して、フルバッファーによってトリガーされるパケットドロップを回避し、標準の損失ベースのTCPトラフィックのリンク使用率を最大化する傾向があります。
AQM algorithms are often evaluated by considering the Transmission Control Protocol (TCP) [RFC793] with a limited number of applications. TCP is a widely deployed transport. It fills up available buffers until a sender transferring a bulk flow with TCP receives a signal (packet drop) that reduces the sending rate. The larger the buffer, the higher the buffer occupancy, and therefore the queuing delay. An efficient AQM scheme sends out early congestion signals to TCP to bring the queuing delay under control.
多くの場合、AQMアルゴリズムは、限られた数のアプリケーションで伝送制御プロトコル（TCP）[RFC793]を検討することによって評価されます。 TCPは広く展開されているトランスポートです。 TCPでバルクフローを転送する送信者が送信レートを低下させる信号（パケットドロップ）を受信するまで、利用可能なバッファーをいっぱいにします。バッファが大きいほど、バッファの占有率が高くなるため、キューイング遅延が長くなります。効率的なAQMスキームは、早期の輻輳信号をTCPに送信して、キューイング遅延を制御します。
Not all endpoints (or applications) using TCP use the same flavor of TCP. A variety of senders generate different classes of traffic, which may not react to congestion signals (aka non-responsive flows in Section 3 of the AQM recommendation document [RFC7567]) or may not reduce their sending rate as expected (aka Transport Flows that are less responsive than TCP, such as proposed in Section 3 of the AQM recommendation document [RFC7567], also called "aggressive flows"). In these cases, AQM schemes seek to control the queuing delay.
TCPを使用するすべてのエンドポイント（またはアプリケーション）が同じ種類のTCPを使用するわけではありません。さまざまな送信者が異なるクラスのトラフィックを生成します。これは、輻輳信号（AQM推奨ドキュメント[RFC7567]のセクション3の無応答フロー）に反応しない場合や、期待どおりに送信レートを低下させない場合（別名トランスポートフローAQM推奨ドキュメント[RFC7567]のセクション3で提案されているように、TCPよりも応答性が低く、「アグレッシブフロー」とも呼ばれます。これらの場合、AQMスキームはキューイング遅延の制御を試みます。
This section provides guidelines to assess the performance of an AQM proposal for various traffic profiles -- different types of senders (with different TCP congestion control variants, unresponsive, and aggressive).
このセクションでは、さまざまなトラフィックプロファイル（さまざまなタイプの送信者（さまざまなTCP輻輳制御バリアント、無応答、攻撃的）に対するAQMプロポーザルのパフォーマンスを評価するためのガイドラインを示します。
This scenario helps to evaluate how an AQM scheme reacts to a TCP-friendly transport sender. A single, long-lived, non-application-limited, TCP NewReno flow, with an Initial congestion Window (IW) set to 3 packets, transfers data between sender A and receiver B. Other TCP-friendly congestion control schemes such as TCP-Friendly Rate Control [RFC5348], etc., may also be considered.
このシナリオは、AQMスキームがTCP対応のトランスポート送信側にどのように反応するかを評価するのに役立ちます。アプリケーションが制限されていない、単一の長期間有効なTCP NewRenoフローは、初期輻輳ウィンドウ（IW）が3パケットに設定されており、送信者Aと受信者Bの間でデータを転送します。フレンドリーレートコントロール[RFC5348]なども検討できます。
For each TCP-friendly transport considered, the graph described in Section 2.7 could be generated.
考慮される各TCP対応のトランスポートについて、セクション2.7で説明されているグラフを生成できます。
This scenario can be used to evaluate how an AQM scheme adapts to a traffic mix consisting of TCP flows with different values of the IW.
このシナリオを使用して、IQの値が異なるTCPフローで構成されるトラフィックミックスにAQMスキームがどのように適応するかを評価できます。
For this scenario, two types of flows must be generated between sender A and receiver B:
このシナリオでは、送信者Aと受信者Bの間で2種類のフローを生成する必要があります。
o A single, long-lived non-application-limited TCP NewReno flow;
o アプリケーションが制限されない単一の長期間有効なTCP NewRenoフロー。
o A single, application-limited TCP NewReno flow, with an IW set to 3 or 10 packets. The size of the data transferred must be strictly higher than 10 packets and should be lower than 100 packets.
o IWが3または10パケットに設定された単一のアプリケーション限定のTCP NewRenoフロー。転送されるデータのサイズは、厳密に10パケットより大きく、100パケットより小さくなければなりません。
The transmission of the non-application-limited flow must start first and the transmission of the application-limited flow starts after the non-application-limited flow has reached steady state. The steady state can be assumed when the goodput is stable.
非アプリケーション制限フローの送信は最初に開始する必要があり、非アプリケーション制限フローの送信は、非アプリケーション制限フローが定常状態に達した後に開始されます。安定状態は、グッドプットが安定しているときに想定できます。
For each of these scenarios, the graph described in Section 2.7 could be generated for each class of traffic (application-limited and non-application-limited). The completion time of the application-limited TCP flow could be measured.
これらのシナリオのそれぞれについて、セクション2.7で説明されているグラフは、トラフィックのクラスごと（アプリケーション制限と非アプリケーション制限）に生成できます。アプリケーション限定のTCPフローの完了時間を測定できます。
This scenario helps testers to evaluate how an AQM scheme reacts to a transport sender that is more aggressive than a single TCP-friendly sender. We define 'aggressiveness' as a higher-than-standard increase factor upon a successful transmission and/or a lower-than-standard decrease factor upon a unsuccessful transmission (e.g., in case of congestion controls with the Additive Increase Multiplicative Decrease (AIMD) principle, a larger AI and/or MD factors). A single long-lived, non-application-limited, CUBIC flow transfers data between sender A and receiver B. Other aggressive congestion control schemes may also be considered.
このシナリオは、単一のTCP対応の送信者よりも積極的なトランスポート送信者に対してAQMスキームがどのように反応するかをテスターが評価するのに役立ちます。 「攻撃性」は、送信が成功した場合の標準よりも高い増加係数および/または送信が失敗した場合の標準よりも低い減少係数として定義されます（たとえば、加法増加乗法減少（AIMD）による輻輳制御の場合）。原則、より大きなAIおよび/またはMD係数）。アプリケーション制限のない単一の長期間有効なCUBICフローが、送信者Aと受信者Bの間でデータを転送します。他の積極的な輻輳制御方式も検討できます。
For each flavor of aggressive transports, the graph described in Section 2.7 could be generated.
アグレッシブトランスポートのフレーバーごとに、セクション2.7で説明されているグラフを生成できます。
This scenario helps testers evaluate how an AQM scheme reacts to a transport sender that is less responsive than TCP. Note that faulty transport implementations on an end host and/or faulty network elements en route that "hide" congestion signals in packet headers may also lead to a similar situation, such that the AQM scheme needs to adapt to unresponsive traffic (see Section 3 of the AQM recommendation document [RFC7567]). To this end, these guidelines propose the two following scenarios:
このシナリオは、AQMスキームがTCPよりも応答性の低いトランスポート送信側にどのように反応するかをテスターが評価するのに役立ちます。エンドホストでのトランスポート実装の障害、および/またはパケットヘッダーの輻輳信号を「隠す」途中の障害のあるネットワーク要素も同様の状況につながる可能性があることに注意してください。 AQM推奨文書[RFC7567]）。このため、これらのガイドラインでは、次の2つのシナリオを提案しています。
o The first scenario can be used to evaluate queue build up. It considers unresponsive flow(s) whose sending rate is greater than the bottleneck link capacity between routers L and R. This scenario consists of a long-lived non-application-limited UDP flow that transmits data between sender A and receiver B. The graph described in Section 2.7 could be generated.
o 最初のシナリオは、キューの構築を評価するために使用できます。これは、送信速度がルーターLとRの間のボトルネックリンクキャパシティーより大きい応答のないフローを考慮します。このシナリオは、送信者Aと受信者Bの間でデータを送信する、アプリケーションが制限されない長寿命のUDPフローで構成されます。グラフセクション2.7で説明されているように生成できます。
o The second scenario can be used to evaluate if the AQM scheme is able to keep the responsive fraction under control. This scenario considers a mixture of TCP-friendly and unresponsive traffic. It consists of a long-lived UDP flow from unresponsive application and a single long-lived, non-application-limited (unlimited data available to the transport sender from the application layer), TCP New Reno flow that transmit data between sender A and receiver B. As opposed to the first scenario, the rate of the UDP traffic should not be greater than the bottleneck capacity, and should be higher than half of the bottleneck capacity. For each type of traffic, the graph described in Section 2.7 could be generated.
o 2番目のシナリオは、AQMスキームが応答部分を制御できるかどうかを評価するために使用できます。このシナリオでは、TCPに適したトラフィックと無応答のトラフィックが混在していることを考慮しています。これは、応答のないアプリケーションからの長期間のUDPフローと、アプリケーションに制限のない単一の長期間のトランスポート（アプリケーションレイヤーからトランスポートの送信者が利用できる無制限のデータ）、送信者Aと受信者の間でデータを送信するTCP New Renoフローで構成されますB.最初のシナリオとは異なり、UDPトラフィックの速度はボトルネック容量を超えてはならず、ボトルネック容量の半分を超えている必要があります。トラフィックのタイプごとに、セクション2.7で説明されているグラフを生成できます。
This scenario helps to evaluate how an AQM scheme reacts to LBE congestion control that "results in smaller bandwidth and/or delay impact on standard TCP than standard TCP itself, when sharing a bottleneck with it" [RFC6297]. There are potential fateful interactions when AQM and LBE techniques are combined [GONG2014]; this scenario helps to evaluate whether the coexistence of the proposed AQM and LBE techniques may be possible.
このシナリオは、AQMスキームがLBE輻輳制御にどのように反応するかを評価するのに役立ちます。これにより、「ボトルネックを共有すると、標準TCP自体よりも帯域幅や遅延が標準TCPに影響します」[RFC6297]。 AQMとLBEの手法を組み合わせると、運命的な相互作用が生じる可能性があります[GONG2014]。このシナリオは、提案されたAQM技術とLBE技術の共存が可能かどうかを評価するのに役立ちます。
A single long-lived non-application-limited TCP NewReno flow transfers data between sender A and receiver B. Other TCP-friendly congestion control schemes may also be considered. Single long-lived non-application-limited LEDBAT [RFC6817] flows transfer data between sender A and receiver B. We recommend setting the target delay and gain values of LEDBAT to 5 ms and 10, respectively [TRAN2014]. Other LBE congestion control schemes may also be considered and are listed in the IETF survey of LBE protocols [RFC6297].
アプリケーションが制限されていない単一の長期のTCP NewRenoフローは、送信者Aと受信者Bの間でデータを転送します。他のTCPフレンドリな輻輳制御方式も検討できます。単一の長寿命の非アプリケーション限定LEDBAT [RFC6817]フローは、送信者Aと受信者Bの間でデータを転送します。LEDBATのターゲット遅延とゲイン値をそれぞれ5 msと10に設定することをお勧めします[TRAN2014]他のLBE輻輳制御方式も考慮される場合があり、LBEプロトコルのIETF調査[RFC6297]にリストされています。
For each of the TCP-friendly and LBE transports, the graph described in Section 2.7 could be generated.
TCPに適したトランスポートとLBEトランスポートのそれぞれについて、セクション2.7で説明されているグラフを生成できます。
An AQM scheme's congestion signals (via drops or ECN marks) must reach the transport sender so that a responsive sender can initiate its congestion control mechanism and adjust the sending rate. This procedure is thus dependent on the end-to-end path RTT. When the RTT varies, the onset of congestion control is impacted, and in turn impacts the ability of an AQM scheme to control the queue. It is therefore important to assess the AQM schemes for a set of RTTs between A and B (e.g., from 5 to 200 ms).
AQMスキームの輻輳信号（ドロップまたはECNマークを介して）は、トランスポート送信側に到達する必要があります。これにより、応答する送信側は、輻輳制御メカニズムを開始して送信速度を調整できます。したがって、この手順はエンドツーエンドパスRTTに依存しています。 RTTが変化すると、輻輳制御の開始が影響を受け、キューを制御するAQMスキームの機能に影響を与えます。したがって、AとBの間のRTTのセット（たとえば、5から200 ms）のAQMスキームを評価することが重要です。
The asymmetry in terms of difference in intrinsic RTT between various paths sharing the same bottleneck should be considered, so that the fairness between the flows can be discussed. In this scenario, a flow traversing on a shorter RTT path may react faster to congestion and recover faster from it compared to another flow on a longer RTT path. The introduction of AQM schemes may potentially improve the RTT fairness.
同じボトルネックを共有するさまざまなパス間の固有のRTTの違いに関する非対称性を考慮して、フロー間の公平性を検討する必要があります。このシナリオでは、短いRTTパスを通過するフローは、長いRTTパス上の別のフローと比較して、輻輳に対してより速く反応し、輻輳からより速く回復する可能性があります。 AQMスキームの導入により、RTTの公平性が向上する可能性があります。
Introducing an AQM scheme may cause unfairness between the flows, even if the RTTs are identical. This potential unfairness should be investigated as well.
AQMスキームを導入すると、RTTが同一であっても、フロー間に不公平が生じる可能性があります。この潜在的な不公平も調査する必要があります。
The recommended topology is detailed in Figure 1.
推奨トポロジの詳細を図1に示します。
To evaluate the RTT fairness, for each run, two flows are divided into two categories. Category I whose RTT between sender A and receiver B should be 100 ms. Category II, in which the RTT between sender A and receiver B should be in the range [5 ms, 560 ms] inclusive. The maximum value for the RTT represents the RTT of a satellite link [RFC2488].
RTTの公平性を評価するために、実行ごとに2つのフローが2つのカテゴリに分類されます。送信者Aと受信者Bの間のRTTが100ミリ秒であるカテゴリI。カテゴリII。送信者Aと受信者Bの間のRTTは、[5 ms、560 ms]の範囲内である必要があります。 RTTの最大値は、衛星リンク[RFC2488]のRTTを表します。
A set of evaluated flows must use the same congestion control algorithm: all the generated flows could be single long-lived non-application-limited TCP NewReno flows.
評価されたフローのセットは、同じ輻輳制御アルゴリズムを使用する必要があります。生成されたすべてのフローは、アプリケーションが制限されていない単一の長寿命TCP NewRenoフローである可能性があります。
The outputs that must be measured are: (1) the cumulative average goodput of the flow from Category I, goodput_Cat_I (see Section 2.5 for the estimation of the goodput); (2) the cumulative average goodput of the flow from Category II, goodput_Cat_II (see Section 2.5 for the estimation of the goodput); (3) the ratio goodput_Cat_II/ goodput_Cat_I; and (4) the average packet drop rate for each category (Section 2.3).
測定する必要がある出力は次のとおりです。（1）カテゴリーIからのフローの累積平均グッドプット、goodput_Cat_I（グッドプットの推定についてはセクション2.5を参照）。 （2）カテゴリーIIからのフローの累積平均グッドプット、goodput_Cat_II（グッドプットの推定についてはセクション2.5を参照）。 （3）比率goodput_Cat_II / goodput_Cat_I; （4）各カテゴリの平均パケットドロップ率（セクション2.3）。
"AQM mechanisms might need to control the overall queue sizes to ensure that arriving bursts can be accommodated without dropping packets" [RFC7567].
「AQMメカニズムは、パケットをドロップせずに到着するバーストに対応できるように、全体的なキューサイズを制御する必要がある場合があります」[RFC7567]。
An AQM scheme can face bursts of packet arrivals due to various reasons. Dropping one or more packets from a burst can result in performance penalties for the corresponding flows, since dropped packets have to be retransmitted. Performance penalties can result in failing to meet Service Level Agreements (SLAs) and can be a disincentive to AQM adoption.
AQMスキームは、さまざまな理由により、パケット到着のバーストに直面する可能性があります。バーストから1つ以上のパケットをドロップすると、ドロップされたパケットを再送信する必要があるため、対応するフローのパフォーマンスが低下する可能性があります。パフォーマンスのペナルティは、サービスレベルアグリーメント（SLA）を満たせなくなる可能性があり、AQMの採用を阻害する可能性があります。
The ability to accommodate bursts translates to larger queue length and hence more queuing delay. On the one hand, it is important that an AQM scheme quickly brings bursty traffic under control. On the other hand, a peak in the packet drop rates to bring a packet burst quickly under control could result in multiple drops per flow and severely impact transport and application performance. Therefore, an AQM scheme ought to bring bursts under control by balancing both aspects -- (1) queuing delay spikes are minimized and (2) performance penalties for ongoing flows in terms of packet drops are minimized.
バーストに対応する機能は、キューの長さを長くし、キューイングの遅延を増やします。一方では、AQMスキームがバースト性のあるトラフィックを迅速に制御することが重要です。一方、パケットバーストをすばやく制御するためのパケットドロップレートのピークは、フローごとに複数のドロップを引き起こし、トランスポートとアプリケーションのパフォーマンスに深刻な影響を与える可能性があります。したがって、AQMスキームは、両方の側面のバランスをとることによってバーストを制御する必要があります-（1）キューイング遅延スパイクが最小限に抑えられ、（2）パケットドロップに関する進行中のフローのパフォーマンスペナルティが最小限に抑えられます。
An AQM scheme that maintains short queues allows some remaining space in the buffer for bursts of arriving packets. The tolerance to bursts of packets depends upon the number of packets in the queue, which is directly linked to the AQM algorithm. Moreover, an AQM scheme may implement a feature controlling the maximum size of accepted bursts that can depend on the buffer occupancy or the currently estimated queuing delay. The impact of the buffer size on the burst allowance may be evaluated.
短いキューを維持するAQMスキームでは、到着するパケットのバーストのために、バッファー内に残りのスペースがいくらかあります。パケットのバーストに対する許容度は、AQMアルゴリズムに直接リンクされているキュー内のパケット数によって異なります。さらに、AQMスキームは、バッファ占有率または現在推定されているキューイング遅延に依存する可能性のある、受け入れられるバーストの最大サイズを制御する機能を実装する場合があります。バッファサイズがバースト許容値に与える影響を評価できます。
For this scenario, the tester must evaluate how the AQM performs with a traffic mix. The traffic mix could be composed of (from sender A to receiver B):
このシナリオでは、テスターはAQMがトラフィックミックスでどのように実行されるかを評価する必要があります。トラフィックミックスは、（送信者Aから受信者Bまで）で構成されます。
o Burst of packets at the beginning of a transmission, such as web traffic with IW10;
o IW10でのWebトラフィックなど、送信開始時のパケットのバースト。
o Applications that send large bursts of data, such as bursty video frames;
o バースト性のビデオフレームなど、大量のデータバーストを送信するアプリケーション。
o Background traffic, such as Constant Bit Rate (CBR) UDP traffic and/or A single non-application-limited bulk TCP flow as background traffic.
o 固定ビットレート（CBR）UDPトラフィックやバックグラウンドトラフィックとしてのアプリケーションに制限されていない単一のバルクTCPフローなどのバックグラウンドトラフィック。
Figure 2 presents the various cases for the traffic that must be generated between sender A and receiver B.
図2は、送信者Aと受信者Bの間で生成される必要があるトラフィックのさまざまなケースを示しています。
+-------------------------------------------------+
|Case| Traffic Type |
| +-----+------------+----+--------------------+
| |Video|Web (IW 10)| CBR| Bulk TCP Traffic |
+----|-----|------------|----|--------------------|
|I | 0 | 1 | 1 | 0 |
+----|-----|------------|----|--------------------|
|II | 0 | 1 | 1 | 1 |
|----|-----|------------|----|--------------------|
|III | 1 | 1 | 1 | 0 |
+----|-----|------------|----|--------------------|
|IV | 1 | 1 | 1 | 1 |
+----+-----+------------+----+--------------------+
Figure 2: Bursty Traffic Scenarios
図2：バースト性のトラフィックシナリオ
A new web page download could start after the previous web page download is finished. Each web page could be composed of at least 50 objects and the size of each object should be at least 1 KB. Six TCP parallel connections should be generated to download the objects, each parallel connection having an initial congestion window set to 10 packets.
以前のWebページのダウンロードが完了した後で、新しいWebページのダウンロードが開始される場合があります。各Webページは少なくとも50のオブジェクトで構成でき、各オブジェクトのサイズは少なくとも1 KBである必要があります。オブジェクトをダウンロードするには、6つのTCP並列接続を生成する必要があります。各並列接続の初期輻輳ウィンドウは10パケットに設定されています。
For each of these scenarios, the graph described in Section 2.7 could be generated for each application. Metrics such as end-to-end latency, jitter, and flow completion time may be generated. For the cases of frame generation of bursty video traffic as well as the choice of web traffic pattern, these details and their presentation are left to the testers.
これらのシナリオのそれぞれについて、セクション2.7で説明されているグラフをアプリケーションごとに生成できます。エンドツーエンドのレイテンシ、ジッター、フロー完了時間などのメトリックが生成される場合があります。バースト性のあるビデオトラフィックのフレーム生成や、Webトラフィックパターンの選択の場合、これらの詳細とプレゼンテーションはテスターに委ねられます。
The safety of an AQM scheme is directly related to its stability under varying operating conditions such as varying traffic profiles and fluctuating network conditions. Since operating conditions can vary often, the AQM needs to remain stable under these conditions without the need for additional external tuning.
AQMスキームの安全性は、さまざまなトラフィックプロファイルや変動するネットワーク条件などのさまざまな動作条件下での安定性に直接関係しています。動作条件は頻繁に変化する可能性があるため、AQMは、追加の外部調整を必要とせずに、これらの条件下で安定した状態を維持する必要があります。
Network devices can experience varying operating conditions depending on factors such as time of the day, deployment scenario, etc. For example:
ネットワークデバイスは、時刻、導入シナリオなどの要因に応じて、さまざまな動作条件を経験する可能性があります。次に例を示します。
o Traffic and congestion levels are higher during peak hours than off-peak hours.
o トラフィックと輻輳レベルは、オフピーク時よりもピーク時の方が高くなります。
o In the presence of a scheduler, the draining rate of a queue can vary depending on the occupancy of other queues: a low load on a high-priority queue implies a higher draining rate for the lower-priority queues.
o スケジューラが存在する場合、キューの排出率は他のキューの占有率によって異なります。優先度の高いキューの負荷が低いほど、優先度の低いキューの排出率が高くなります。
o The capacity available can vary over time (e.g., a lossy channel, a link supporting traffic in a higher Diffserv class).
o 利用可能な容量は、時間の経過とともに変化する可能性があります（損失の多いチャネル、より高いDiffservクラスのトラフィックをサポートするリンクなど）。
Whether or not the target context is a stable environment, the ability of an AQM scheme to maintain its control over the queuing delay and buffer occupancy can be challenged. This document proposes guidelines to assess the behavior of AQM schemes under varying congestion levels and varying draining rates.
ターゲットコンテキストが安定した環境であるかどうかに関係なく、AQMスキームがキューイング遅延とバッファ占有率の制御を維持する能力に問題が生じる可能性があります。このドキュメントは、さまざまな輻輳レベルとさまざまな流出速度の下でのAQMスキームの動作を評価するためのガイドラインを提案します。
Note that the traffic profiles explained below comprises non-application-limited TCP flows. For each of the below scenarios, the graphs described in Section 2.7 should be generated, and the goodput of the various flows should be cumulated. For Section 8.2.5 and Section 8.2.6, they should incorporate the results in a per-phase basis as well.
以下で説明するトラフィックプロファイルは、アプリケーション制限のないTCPフローで構成されていることに注意してください。以下の各シナリオでは、セクション2.7で説明されているグラフを生成し、さまざまなフローのグッドプットを累積する必要があります。セクション8.2.5およびセクション8.2.6については、フェーズごとに結果を組み込む必要があります。
Wherever the notion of time has been explicitly mentioned in this subsection, time 0 starts from the moment all TCP flows have already reached their congestion avoidance phase.
このサブセクションで時間の概念が明示的に言及されている場合、時間0はすべてのTCPフローがすでに輻輳回避フェーズに達した瞬間から始まります。
In these guidelines, the congestion levels are represented by the projected packet drop rate, which is determined when there is no AQM scheme (i.e., a drop-tail queue). When the bottleneck is shared among non-application-limited TCP flows, l_r (the loss rate projection) can be expressed as a function of N, the number of bulk TCP flows, and S, the sum of the bandwidth-delay product and the maximum buffer size, both expressed in packets, based on Eq. 3 of [MORR2000]:
これらのガイドラインでは、輻輳レベルは予測パケットドロップ率で表されます。これは、AQMスキームがない場合（つまり、ドロップテールキュー）に決定されます。アプリケーションが制限されていないTCPフロー間でボトルネックが共有される場合、l_r（損失率予測）は、N（バルクTCPフローの数）の関数として表現でき、Sは帯域幅遅延積と式に基づいて、両方がパケットで表される最大バッファーサイズ。 [MORR2000]の3：
l_r = 0.76 * N^2 / S^2
N = S * SQRT(1/0.76) * SQRT(l_r)
These guidelines use the loss rate to define the different congestion levels, but they do not stipulate that in other circumstances, measuring the congestion level gives you an accurate estimation of the loss rate or vice versa.
これらのガイドラインでは、損失率を使用してさまざまな輻輳レベルを定義していますが、他の状況では、輻輳レベルを測定することで損失率の正確な推定が得られること、またはその逆が規定されていません。
This scenario can be used to evaluate how an AQM scheme reacts to a light load of incoming traffic resulting in mild congestion -- packet drop rates around 0.1%. The number of bulk flows required to achieve this congestion level, N_mild, is then:
このシナリオを使用して、AQMスキームが着信トラフィックの軽負荷にどのように反応し、穏やかな輻輳（パケットドロップ率が約0.1％）になるかを評価できます。この輻輳レベルを達成するために必要なバルクフローの数N_mildは、次のようになります。
N_mild = ROUND (0.036*S)
N_mild = ROUND（0.036 * S）
This scenario can be used to evaluate how an AQM scheme reacts to incoming traffic resulting in medium congestion -- packet drop rates around 0.5%. The number of bulk flows required to achieve this congestion level, N_med, is then:
このシナリオを使用して、AQMスキームが着信トラフィックにどのように反応し、中程度の輻輳（パケットドロップ率が約0.5％）になるかを評価できます。この輻輳レベルを達成するために必要なバルクフローの数N_medは、次のようになります。
N_med = ROUND (0.081*S)
N_med = ROUND（0.081 * S）
This scenario can be used to evaluate how an AQM scheme reacts to incoming traffic resulting in heavy congestion -- packet drop rates around 1%. The number of bulk flows required to achieve this congestion level, N_heavy, is then:
このシナリオを使用して、AQMスキームが着信トラフィックにどのように反応し、大きな輻輳（パケットドロップ率が約1％）になるかを評価できます。この輻輳レベルを達成するために必要なバルクフローの数、N_heavyは次のようになります。
N_heavy = ROUND (0.114*S)
N_heavy = ROUND（0.114 * S）
This scenario can be used to evaluate how an AQM scheme reacts to incoming traffic resulting in various levels of congestion during the experiment. In this scenario, the congestion level varies within a large timescale. The following phases may be considered: phase I -- mild congestion during 0-20 s; phase II -- medium congestion during 20-40 s; phase III -- heavy congestion during 40-60 s; phase I again, and so on.
このシナリオを使用して、AQMスキームが着信トラフィックにどのように反応し、実験中にさまざまなレベルの輻輳が発生するかを評価できます。このシナリオでは、混雑レベルは大きなタイムスケール内で変化します。次のフェーズを検討できます。フェーズI-0〜20秒間の軽度の混雑。フェーズII-20〜40秒間の中程度の混雑;フェーズIII-40〜60秒間の激しい混雑;フェーズIを繰り返します。
This scenario can be used to help characterize how the AQM behaves and adapts to bandwidth changes. The experiments are not meant to reflect the exact conditions of Wi-Fi environments since it is hard to design repetitive experiments or accurate simulations for such scenarios.
このシナリオは、AQMの動作と帯域幅の変化への適応を特徴付けるのに役立ちます。このようなシナリオに対して反復的な実験や正確なシミュレーションを設計することは難しいため、実験はWi-Fi環境の正確な条件を反映することを意図していません。
To emulate varying draining rates, the bottleneck capacity between nodes 'Router L' and 'Router R' varies over the course of the experiment as follows:
さまざまな排出速度をエミュレートするために、ノード「ルーターL」と「ルーターR」の間のボトルネック容量は、次のように実験の過程で変化します。
o Experiment 1: The capacity varies between two values within a large timescale. As an example, the following phases may be considered: phase I -- 100 Mbps during 0-20 s; phase II -- 10 Mbps during 20-40 s; phase I again, and so on.
o 実験1：容量は、大きなタイムスケール内で2つの値の間で変化します。例として、次のフェーズを検討できます。フェーズI-0〜20秒間で100 Mbps。フェーズII-20〜40秒間で10 Mbps;フェーズIを繰り返します。
o Experiment 2: The capacity varies between two values within a short timescale. As an example, the following phases may be considered: phase I -- 100 Mbps during 0-100 ms; phase II -- 10 Mbps during 100-200 ms; phase I again, and so on.
o 実験2：容量は、短いタイムスケール内で2つの値の間で変化します。例として、次のフェーズを検討できます。フェーズI-0〜100ミリ秒で100 Mbps。フェーズII-100〜200ミリ秒で10 Mbps;フェーズIを繰り返します。
The tester may choose a phase time-interval value different than what is stated above, if the network's path conditions (such as bandwidth-delay product) necessitate. In this case, the choice of such a time-interval value should be stated and elaborated.
ネットワークのパス条件（帯域幅遅延積など）が必要な場合、テスターは、上記とは異なるフェーズ時間間隔値を選択できます。この場合、そのような時間間隔の値の選択について述べ、詳しく説明する必要があります。
The tester may additionally evaluate the two mentioned scenarios (short-term and long-term capacity variations), during and/or including the TCP slow-start phase.
テスターは、さらに、TCPスロースタートフェーズ中および/またはそれを含めて、言及された2つのシナリオ（短期および長期の容量変動）を評価します。
More realistic fluctuating capacity patterns may be considered. The tester may choose to incorporate realistic scenarios with regards to common fluctuation of bandwidth in state-of-the-art technologies.
より現実的な変動容量パターンが考慮される場合があります。テスターは、最先端のテクノロジーにおける帯域幅の一般的な変動に関して現実的なシナリオを組み込むことを選択できます。
The scenario consists of TCP NewReno flows between sender A and receiver B. To better assess the impact of draining rates on the AQM behavior, the tester must compare its performance with those of drop- tail and should provide a reference document for their proposal discussing performance and deployment compared to those of drop-tail. Burst traffic, such as presented in Section 7.2, could also be considered to assess the impact of varying available capacity on the burst absorption of the AQM.
シナリオは、送信者Aと受信者Bの間のTCP NewRenoフローで構成されています。AQM動作へのドレインレートの影響をより適切に評価するには、テスターはそのパフォーマンスをドロップテールのパフォーマンスと比較し、パフォーマンスを議論する提案の参照ドキュメントを提供する必要がありますドロップテールのものと比較した展開。セクション7.2に示すようなバーストトラフィックも、AQMのバースト吸収に対する使用可能な容量の変化の影響を評価するために検討できます。
The control law used by an AQM is the primary means by which the queuing delay is controlled. Hence, understanding the control law is critical to understanding the behavior of the AQM scheme. The control law could include several input parameters whose values affect the AQM scheme's output behavior and its stability. Additionally, AQM schemes may auto-tune parameter values in order to maintain stability under different network conditions (such as different congestion levels, draining rates, or network environments). The stability of these auto-tuning techniques is also important to understand.
AQMで使用される制御則は、キューイング遅延を制御する主要な手段です。したがって、AQMスキームの動作を理解するには、制御法則を理解することが重要です。制御則には、AQMスキームの出力動作とその安定性に影響を与える値を持ついくつかの入力パラメーターを含めることができます。さらに、AQMスキームは、さまざまなネットワーク条件（さまざまな輻輳レベル、流出速度、ネットワーク環境など）で安定性を維持するために、パラメーター値を自動調整する場合があります。これらの自動チューニング手法の安定性も理解することが重要です。
Transports operating under the control of AQM experience the effect of multiple control loops that react over different timescales. It is therefore important that proposed AQM schemes are seen to be stable when they are deployed at multiple points of potential congestion along an Internet path. The pattern of congestion signals (loss or ECN-marking) arising from AQM methods also needs to not adversely interact with the dynamics of the transport protocols that they control.
AQMの制御下で動作するトランスポートは、異なるタイムスケールで反応する複数の制御ループの影響を受けます。したがって、提案されたAQMスキームがインターネットパスに沿って潜在的な輻輳の複数のポイントに展開されている場合、それらが安定していると見なされることが重要です。 AQMメソッドから発生する輻輳信号のパターン（損失またはECNマーキング）も、それらが制御するトランスポートプロトコルのダイナミクスと不利に相互作用しないようにする必要があります。
AQM proposals should provide background material showing theoretical analysis of the AQM control law and the input parameter space within which the control law operates, or they should use another way to discuss the stability of the control law. For parameters that are auto-tuned, the material should include stability analysis of the auto-tuning mechanism(s) as well. Such analysis helps to understand an AQM control law better and the network conditions/deployments under which the AQM is stable.
AQMの提案は、AQMの制御法則と制御法則が機能する入力パラメーター空間の理論的分析を示す背景資料を提供するか、別の方法で制御法則の安定性を議論する必要があります。自動調整されるパラメーターの場合、材料には自動調整メカニズムの安定性分析も含まれている必要があります。このような分析は、AQM制御法と、AQMが安定しているネットワークの状態/展開をよりよく理解するのに役立ちます。
This section provides guidelines to assess the performance of an AQM proposal for various traffic profiles such as traffic with different applications or bidirectional traffic.
このセクションでは、さまざまなアプリケーションのトラフィックや双方向トラフィックなど、さまざまなトラフィックプロファイルに対するAQMプロポーザルのパフォーマンスを評価するためのガイドラインを示します。
This scenario can be used to evaluate how an AQM scheme reacts to a traffic mix consisting of different applications such as:
このシナリオを使用して、AQMスキームが次のようなさまざまなアプリケーションで構成されるトラフィックミックスにどのように反応するかを評価できます。
o Bulk TCP transfer
o バルクTCP転送
o Web traffic
o Webトラフィック
o VoIP
o VoIP
o Constant Bit Rate (CBR) UDP traffic
o 固定ビットレート（CBR）UDPトラフィック
o Adaptive video streaming (either unidirectional or bidirectional)
o アダプティブビデオストリーミング（単方向または双方向）
Various traffic mixes can be considered. These guidelines recommend examining at least the following example: 1 bidirectional VoIP; 6 web page downloads (such as those detailed in Section 7.2); 1 CBR; 1 Adaptive Video; 5 bulk TCP. Any other combinations could be considered and should be carefully documented.
さまざまなトラフィックミックスを検討できます。これらのガイドラインでは、少なくとも次の例を検討することをお勧めします。1つの双方向VoIP。 6つのWebページのダウンロード（セクション7.2で詳述されているものなど）。 1 CBR; 1アダプティブビデオ; 5バルクTCP。他の組み合わせも検討でき、慎重に文書化する必要があります。
For each scenario, the graph described in Section 2.7 could be generated for each class of traffic. Metrics such as end-to-end latency, jitter, and flow completion time may be reported.
シナリオごとに、セクション2.7で説明されているグラフをトラフィックのクラスごとに生成できます。エンドツーエンドのレイテンシ、ジッター、フロー完了時間などのメトリックが報告される場合があります。
Control packets such as DNS requests/responses, TCP SYNs/ACKs are small, but their loss can severely impact the application performance. The scenario proposed in this section will help in assessing whether the introduction of an AQM scheme increases the loss probability of these important packets.
DNS要求/応答、TCP SYN / ACKなどの制御パケットは小さいですが、それらの損失はアプリケーションのパフォーマンスに深刻な影響を与える可能性があります。このセクションで提案するシナリオは、AQMスキームの導入により、これらの重要なパケットの損失確率が増加するかどうかを評価するのに役立ちます。
For this scenario, traffic must be generated in both downlink and uplink, as defined in Section 3.1. The amount of asymmetry between the uplink and the downlink depends on the context. These guidelines recommend considering a mild congestion level and the traffic presented in Section 8.2.2 in both directions. In this case, the metrics reported must be the same as in Section 8.2 for each direction.
このシナリオでは、セクション3.1で定義されているように、ダウンリンクとアップリンクの両方でトラフィックを生成する必要があります。アップリンクとダウンリンクの間の非対称性の量は、コンテキストに依存します。これらのガイドラインは、穏やかな混雑レベルと、セクション8.2.2で提示されたトラフィックを双方向で検討することを推奨しています。この場合、報告されるメトリックは、各方向についてセクション8.2と同じでなければなりません。
The traffic mix presented in Section 9.1 may also be generated in both directions.
セクション9.1に示すトラフィックミックスは、両方向でも生成される可能性があります。
Transports operating under the control of AQM experience the effect of multiple control loops that react over different timescales. It is therefore important that proposed AQM schemes are seen to be stable when they are deployed at multiple points of potential congestion along an Internet path. The pattern of congestion signals (loss or ECN-marking) arising from AQM methods also need to not adversely interact with the dynamics of the transport protocols that they control.
AQMの制御下で動作するトランスポートは、異なるタイムスケールで反応する複数の制御ループの影響を受けます。したがって、提案されたAQMスキームがインターネットパスに沿って潜在的な輻輳の複数のポイントに展開されている場合、それらが安定していると見なされることが重要です。 AQMメソッドから生じる輻輳信号のパターン（損失またはECNマーキング）も、それらが制御するトランスポートプロトコルのダイナミクスと不利に相互作用しないようにする必要があります。
+---------+ +-----------+
|senders A|---+ +---|receivers A|
+---------+ | | +-----------+
+-----+---+ +---------+ +--+-----+
|Router L |--|Router M |--|Router R|
|AQM A | |AQM M | |No AQM |
+---------+ +--+------+ +--+-----+
+---------+ | | +-----------+
|senders B|-------------+ +---|receivers B|
+---------+ +-----------+
Figure 3: Topology for the Multi-AQM Scenario
図3：マルチAQMシナリオのトポロジ
Figure 3 describes topology options for evaluating multi-AQM scenarios. The AQM schemes are applied in sequence and impact the induced latency reduction, the induced goodput maximization, and the trade-off between these two. Note that AQM schemes A and B introduced in Routers L and M could be (I) same scheme with identical parameter values, (ii) same scheme with different parameter values, or (iii) two different schemes. To best understand the interactions and implications, the mild congestion scenario as described in Section 8.2.2 is recommended such that the number of flows is equally shared among senders A and B. Other relevant combinations of congestion levels could also be considered. We recommend measuring the metrics presented in Section 8.2.
図3は、マルチAQMシナリオを評価するためのトポロジオプションを示しています。 AQMスキームは順番に適用され、誘導されるレイテンシの削減、誘導されるグッドプットの最大化、およびこれら2つの間のトレードオフに影響を与えます。ルータLおよびMに導入されたAQMスキームAおよびBは、（I）同一のパラメータ値を使用する同じスキーム、（ii）異なるパラメータ値を使用する同じスキーム、または（iii）2つの異なるスキームである可能性があることに注意してください。相互作用と影響を最もよく理解するには、フローの数が送信者AとBの間で等しく共有されるように、セクション8.2.2で説明されている軽度の輻輳シナリオをお勧めします。輻輳レベルの他の関連する組み合わせも検討できます。セクション8.2に示すメトリックを測定することをお勧めします。
Successful deployment of AQM is directly related to its cost of implementation. Network devices may need hardware or software implementations of the AQM mechanism. Depending on a device's capabilities and limitations, the device may or may not be able to implement some or all parts of their AQM logic.
AQMの展開の成功は、その実装コストに直接関係しています。ネットワークデバイスには、AQMメカニズムのハードウェアまたはソフトウェアの実装が必要な場合があります。デバイスの機能と制限に応じて、デバイスはAQMロジックの一部またはすべての部分を実装できる場合とできない場合があります。
AQM proposals should provide pseudocode for the complete AQM scheme, highlighting generic implementation-specific aspects of the scheme such as "drop-tail" vs. "drop-head", inputs (e.g., current queuing delay, and queue length), computations involved, need for timers, etc. This helps to identify costs associated with implementing the AQM scheme on a particular hardware or software device. This also facilitates discussions around which kind of devices can easily support the AQM and which cannot.
AQMの提案では、完全なAQMスキームの疑似コードを提供し、「ドロップテール」と「ドロップヘッド」の比較、入力（現在のキューイング遅延、キュー長など）、関連する計算など、スキームの一般的な実装固有の側面を強調する必要があります。 、タイマーの必要性など。これは、特定のハードウェアまたはソフトウェアデバイスにAQMスキームを実装することに関連するコストを特定するのに役立ちます。これにより、AQMを簡単にサポートできるデバイスとサポートできないデバイスについての議論も容易になります。
AQM proposals should highlight parts of their AQM logic that are device dependent and discuss if and how AQM behavior could be impacted by the device. For example, a queuing-delay-based AQM scheme requires current queuing delay as input from the device. If the device already maintains this value, then it can be trivial to implement the AQM logic on the device. If the device provides indirect means to estimate the queuing delay (for example, timestamps and dequeuing rate), then the AQM behavior is sensitive to the precision of the queuing delay estimations are for that device. Highlighting the sensitivity of an AQM scheme to queuing delay estimations helps implementers to identify appropriate means of implementing the mechanism on a device.
AQMの提案では、デバイスに依存するAQMロジックの部分を強調し、デバイスによってAQMの動作が影響を受けるかどうか、およびどのように影響を受けるかについて説明する必要があります。たとえば、キューイング遅延ベースのAQMスキームでは、デバイスからの入力として現在のキューイング遅延が必要です。デバイスがすでにこの値を維持している場合、デバイスにAQMロジックを実装することは簡単です。デバイスがキューイング遅延を推定するための間接的な手段（タイムスタンプやデキュー率など）を提供する場合、AQMの動作はそのデバイスのキューイング遅延推定の精度に影響されます。キューの遅延推定に対するAQMスキームの感度を強調表示すると、実装者がデバイスにメカニズムを実装する適切な手段を特定するのに役立ちます。
One of the biggest hurdles of RED deployment was/is its parameter sensitivity to operating conditions -- how difficult it is to tune RED parameters for a deployment to achieve acceptable benefit from using RED. Fluctuating congestion levels and network conditions add to the complexity. Incorrect parameter values lead to poor performance.
RED展開の最大のハードルの1つは、稼働条件に対するパラメーターの感度でした。これは、REDを使用することで許容できる利益を達成するために、展開のREDパラメーターを調整することがいかに難しいかです。変動する輻輳レベルとネットワーク状態により、複雑さが増します。パラメータ値が正しくないと、パフォーマンスが低下します。
Any AQM scheme is likely to have parameters whose values affect the control law and behavior of an AQM. Exposing all these parameters as control parameters to a network operator (or user) can easily result in an unsafe AQM deployment. Unexpected AQM behavior ensues when parameter values are set improperly. A minimal number of control parameters minimizes the number of ways a user can break a system where an AQM scheme is deployed at. Fewer control parameters make the AQM scheme more user-friendly and easier to deploy and debug.
どのAQMスキームにも、その値がAQMの制御則と動作に影響を与えるパラメーターがある可能性があります。これらすべてのパラメーターを制御パラメーターとしてネットワークオペレーター（またはユーザー）に公開すると、安全でないAQM展開が簡単に発生する可能性があります。パラメータ値が正しく設定されていない場合、予期しないAQM動作が発生します。最小数の制御パラメーターにより、ユーザーがAQMスキームが展開されているシステムを破壊する方法の数が最小限に抑えられます。制御パラメーターが少ないと、AQMスキームがよりユーザーフレンドリーになり、展開とデバッグが容易になります。
"AQM algorithms SHOULD NOT require tuning of initial or configuration parameters in common use cases." such as stated in Section 4 of the AQM recommendation document [RFC7567]. A scheme ought to expose only those parameters that control the macroscopic AQM behavior such as queue delay threshold, queue length threshold, etc.
「AQMアルゴリズムでは、一般的な使用例では、初期パラメーターまたは構成パラメーターの調整は必要ありません（SHOULD NOT）。」 AQM推奨ドキュメント[RFC7567]のセクション4で述べられているようなものです。スキームは、キューの遅延しきい値、キューの長さのしきい値など、巨視的なAQMの動作を制御するパラメーターのみを公開する必要があります。
Additionally, the safety of an AQM scheme is directly related to its stability under varying operating conditions such as varying traffic profiles and fluctuating network conditions, as described in Section 8. Operating conditions vary often and hence the AQM needs to remain stable under these conditions without the need for additional external tuning. If AQM parameters require tuning under these conditions, then the AQM must self-adapt necessary parameter values by employing auto-tuning techniques.
さらに、セクション8で説明されているように、AQMスキームの安全性は、さまざまなトラフィックプロファイルや変動するネットワーク条件などのさまざまな動作条件下での安定性に直接関係しています。動作条件は頻繁に変化するため、AQMは追加の外部チューニングの必要性。これらの条件下でAQMパラメーターを調整する必要がある場合、AQMは自動調整手法を使用して必要なパラメーター値を自己適応させる必要があります。
In order to understand an AQM's deployment considerations and performance under a specific environment, AQM proposals should describe the parameters that control the macroscopic AQM behavior, and identify any parameters that require tuning to operational conditions. It could be interesting to also discuss that, even if an AQM scheme may not adequately auto-tune its parameters, the resulting performance may not be optimal, but close to something reasonable.
特定の環境でのAQMの展開に関する考慮事項とパフォーマンスを理解するために、AQMの提案では、巨視的なAQMの動作を制御するパラメーターについて説明し、運用条件への調整が必要なパラメーターを特定する必要があります。 AQMスキームがそのパラメーターを適切に自動調整しない場合でも、結果として得られるパフォーマンスは最適ではないかもしれませんが、妥当なものに近い可能性があることについても議論することは興味深いかもしれません。
If there are any fixed parameters within the AQM, their setting should be discussed and justified to help understand whether a fixed parameter value is applicable for a particular environment.
AQM内に固定パラメーターがある場合は、それらの設定を検討して正当化し、固定パラメーター値が特定の環境に適用可能かどうかを理解できるようにする必要があります。
If an AQM scheme is evaluated with parameter(s) that were externally tuned for optimization or other purposes, these values must be disclosed.
AQMスキームが、最適化またはその他の目的のために外部で調整されたパラメーターを使用して評価される場合、これらの値を開示する必要があります。
Figure 4 lists the scenarios for an extended characterization of an AQM scheme. This table comes along with a set of requirements to present more clearly the weight and importance of each scenario. The requirements listed here are informational and their relevance may depend on the deployment scenario.
図4に、AQMスキームの拡張特性のシナリオを示します。この表には、各シナリオの重要性と重要性をより明確に示すための一連の要件が含まれています。ここにリストされている要件は情報提供であり、それらの関連性はデプロイメントシナリオによって異なる場合があります。
+------------------------------------------------------------------+
|Scenario |Sec. |Informational requirement |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|Interaction with ECN | 4.5 |must be discussed if supported |
+------------------------------------------------------------------+
|Interaction with Scheduling| 4.6 |should be discussed |
+------------------------------------------------------------------+
|Transport Protocols | 5 | |
| TCP-friendly sender | 5.1 |scenario must be considered |
| Aggressive sender | 5.2 |scenario must be considered |
| Unresponsive sender | 5.3 |scenario must be considered |
| LBE sender | 5.4 |scenario may be considered |
+------------------------------------------------------------------+
|Round-Trip Time Fairness | 6.2 |scenario must be considered |
+------------------------------------------------------------------+
|Burst Absorption | 7.2 |scenario must be considered |
+------------------------------------------------------------------+
|Stability | 8 | |
| Varying congestion levels | 8.2.5|scenario must be considered |
| Varying available capacity| 8.2.6|scenario must be considered |
| Parameters and stability | 8.3 |this should be discussed |
+------------------------------------------------------------------+
|Various Traffic Profiles | 9 | |
| Traffic mix | 9.1 |scenario is recommended |
| Bidirectional traffic | 9.2 |scenario may be considered |
+------------------------------------------------------------------+
|Multi-AQM | 10.2 |scenario may be considered |
+------------------------------------------------------------------+
Figure 4: Summary of the Scenarios and their Requirements
図4：シナリオとその要件の概要
Some security considerations for AQM are identified in [RFC7567]. This document, by itself, presents no new privacy or security issues.
AQMのセキュリティに関する考慮事項は、[RFC7567]で特定されています。このドキュメント自体には、プライバシーやセキュリティに関する新しい問題はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、RFC 2119、1997。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <http://www.rfc-editor.org/info/rfc2544>.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク手法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<http://www.rfc-editor.org/info/rfc2544>。
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999, <http://www.rfc-editor.org/info/rfc2647>.
[RFC2647]ニューマン、D。、「ファイアウォールパフォーマンスのベンチマーク用語」、RFC 2647、DOI 10.17487 / RFC2647、1999年8月、<http://www.rfc-editor.org/info/rfc2647>。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <http://www.rfc-editor.org/info/rfc5481>.
[RFC5481] Morton、A。およびB. Claise、「Packet Delay Variation Applicability Statement」、RFC 5481、DOI 10.17487 / RFC5481、2009年3月、<http://www.rfc-editor.org/info/rfc5481>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-editor.org/info/rfc7567>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<http://www.rfc-editor.org/info/rfc7567>。
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-editor.org/info/rfc7679>.
[RFC7679] Almes、G.、Kalidindi、S.、Zekauskas、M。、およびA. Morton、編、「A IPメトリック（IPPM）に対する一方向の遅延メトリック」、STD 81、RFC 7679、DOI 10.17487 / RFC7679、2016年1月、<http://www.rfc-editor.org/info/rfc7679>。
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <http://www.rfc-editor.org/info/rfc7680>.
[RFC7680] Almes、G.、Kalidindi、S.、Zekauskas、M。、およびA. Morton、編、「IP Performance Metrics（IPPM）の一方通行の損失メトリック」、STD 82、RFC 7680、DOI 10.17487 / RFC7680、2016年1月、<http://www.rfc-editor.org/info/rfc7680>。
[ANEL2014] Anelli, P., Diana, R., and E. Lochin, "FavorQueue: a Parameterless Active Queue Management to Improve TCP Traffic Performance", Computer Networks Vol. 60, DOI 10.1016/j.bjp.2013.11.008, 2014.
[ANEL2014] Anelli、P.、Diana、R。、およびE. Lochin、「FavorQueue：パラメータのないアクティブキュー管理によるTCPトラフィックパフォーマンスの改善」、Computer Networks Vol。 60、DOI 10.1016 / j.bjp.2013.11.008、2014。
[AQMPIE] Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", Work in Progress, draft-ietf-aqm-pie-08, June 2016.
[AQMPIE]パン、R。、ナタラジャン、P。、ベイカー、F。、およびG.ホワイト、「PIE：バッファブロート問題に対処するための軽量制御スキーム」、進行中の作業、draft-ietf-aqm-pie-08 、2016年6月。
[BB2011] Cerf, V., Jacobson, V., Weaver, N., and J. Gettys, "BufferBloat: what's wrong with the internet?", ACM Queue Vol. 55, DOI 10.1145/2076450.2076464, 2012.
[BB2011] Cerf、V.、Jacobson、V.、Weaver、N.、J。Gettys、「BufferBloat：インターネットの何が悪いの？」、ACM Queue Vol。 55、DOI 10.1145 / 2076450.2076464、2012。
[BCP41] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[BCP41]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification", BCP 41, RFC 7141, February 2014.
Briscoe、B。およびJ. Manner、「Byte and Packet Congestion Notification」、BCP 41、RFC 7141、2014年2月。
<http://www.rfc-editor.org/info/bcp41>
[CODEL] Nichols, K., Jacobson, V., McGregor, A., and J. Iyengar, "Controlled Delay Active Queue Management", Work in Progress, draft-ietf-aqm-codel-04, June 2016.
[コード] Nichols、K.、Jacobson、V.、McGregor、A.、J。Iyengar、「Controlled Delay Active Queue Management」、Work in Progress、draft-ietf-aqm-codel-04、2016年6月。
[CUBIC] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", Work in Progress, draft-ietf-tcpm-cubic-01, January 2016.
[CUBIC] Rhee、I.、Xu、L.、Ha、S.、Zimmermann、A.、Eggert、L。、およびR. Scheffenegger、「CUBIC for Fast Long-Distance Networks」、Work in Progress、draft-ietf -tcpm-cubic-01、2016年1月。
[FENG2002] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE active queue management algorithms", IEEE Transactions on Networking Vol.10 Issue 4, DOI 10.1109/TNET.2002.801399, 2002, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=1026008>.
[FENG2002] Feng、W.、Shin、K.、Kandlur、D.、and D. Saha、 "The BLUE active queue management algorithm"、IEEE Transactions on Networking Vol.10 Issue 4、DOI 10.1109 / TNET.2002.801399、2002 、<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber = 1026008>。
[FLOY1993] Floyd, S. and V. Jacobson, "Random Early Detection (RED) Gateways for Congestion Avoidance", IEEE Transactions on Networking Vol. 1 Issue 4, DOI 10.1109/90.251892, 1993, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=251892>.
[FLOY1993] Floyd、S。およびV. Jacobson、「輻輳回避のためのランダム早期検出（RED）ゲートウェイ」、IEEE Transactions on Networking Vol。 1 Issue 4、DOI 10.1109 / 90.251892、1993、<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber = 251892>。
[GONG2014] Gong, Y., Rossi, D., Testa, C., Valenti, S., and D. Taht, "Fighting the bufferbloat: on the coexistence of AQM and low priority congestion control", Computer Networks, Elsevier, 2014, pp.115-128 Vol. 60, DOI 10.1109/INFCOMW.2013.6562885, 2014.
[GONG2014] Gong、Y.、Rossi、D.、Testa、C.、Valenti、S。およびD. 2014、pp.115-128 Vol。 60、DOI 10.1109 / INFCOMW.2013.6562885、2014。
[HASS2008] Hassayoun, S. and D. Ros, "Loss Synchronization and Router Buffer Sizing with High-Speed Versions of TCP", IEEE INFOCOM Workshops, DOI 10.1109/INFOCOM.2008.4544632, 2008, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=4544632>.
[HASS2008] Hassayoun、S。およびD. Ros、「高速バージョンのTCPを使用した損失同期およびルーターバッファのサイズ設定」、IEEE INFOCOMワークショップ、DOI 10.1109 / INFOCOM.2008.4544632、2008、<http://ieeexplore.ieee。 org / xpl / articleDetails.jsp？arnumber = 4544632>。
[HOEI2015] Hoeiland-Joergensen, T., McKenney, P., dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm", Work in Progress, draft-ietf-aqm-fq-codel-06, March 2016.
[HOEI2015] Hoeiland-Joergensen、T.、McKenney、P.、dave.taht @ gmail.com、d。、Gettys、J。、およびE. Dumazet、「FlowQueue-CoDelパケットスケジューラおよびアクティブキュー管理アルゴリズム」、 Work in Progress、draft-ietf-aqm-fq-codel-06、2016年3月。
[HOLLO2001] Hollot, C., Misra, V., Towsley, V., and W. Gong, "On Designing Improved Controller for AQM Routers Supporting TCP Flows", IEEE INFOCOM, DOI 10.1109/INFCOM.2001.916670, 2001, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=916670>.
[HOLLO2001] Hollot、C.、Misra、V.、Towsley、V。、およびW. Gong、「TCPフローをサポートするAQMルーターの改善されたコントローラの設計について」、IEEE INFOCOM、DOI 10.1109 / INFCOM.2001.916670、2001、<http ：//ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber = 916670>。
[JAY2006] Jay, P., Fu, Q., and G. Armitage, "A preliminary analysis of loss synchronisation between concurrent TCP flows", Australian Telecommunication Networks and Application Conference (ATNAC), 2006.
[JAY2006] Jay、P.、Fu、Q。、およびG. Armitage、「並行TCPフロー間の損失同期の予備分析」、オーストラリア通信ネットワークおよびアプリケーション会議（ATNAC）、2006年。
[MORR2000] Morris, R., "Scalable TCP congestion control", IEEE INFOCOM, DOI 10.1109/INFCOM.2000.832487, 2000, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=832487>.
[MORR2000] Morris、R。、「Scalable TCP congestion control」、IEEE INFOCOM、DOI 10.1109 / INFCOM.2000.832487、2000、<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=832487>。
[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>。
[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>。
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, <http://www.rfc-editor.org/info/rfc2488>.
[RFC2488] Allman、M.、Glover、D。、およびL. Sanchez、「Enhancing TCP over Satellite Channels using Standard Mechanisms」、BCP 28、RFC 2488、DOI 10.17487 / RFC2488、1999年1月、<http：// www。 rfc-editor.org/info/rfc2488>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <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>。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。
[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>。
[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>。
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 2011, <http://www.rfc-editor.org/info/rfc6297>.
[RFC6297] Welzl、M。、およびD. Ros、「調査、ベストエフォート未満のトランスポートプロトコル」、RFC 6297、DOI 10.17487 / RFC6297、2011年6月、<http://www.rfc-editor.org / info / rfc6297>。
[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>。
[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 >。
[TCPEVAL] Hayes, D., Ros, D., Andrew, L., and S. Floyd, "Common TCP Evaluation Suite", Work in Progress, draft-irtf-iccrg-tcpeval-01, July 2014.
[TCPEVAL]ヘイズ、D。、ロス、D。、アンドリュー、L。、およびS.フロイド、「Common TCP Evaluation Suite」、Work in Progress、draft-irtf-iccrg-tcpeval-01、2014年7月。
[TRAN2014] Trang, S., Kuhn, N., Lochin, E., Baudoin, C., Dubois, E., and P. Gelard, "On The Existence Of Optimal LEDBAT Parameters", IEEE ICC 2014 - Communication QoS, Reliability and Modeling Symposium, DOI 10.1109/ICC.2014.6883487, 2014, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=6883487>.
[TRAN2014] Trang、S.、Kuhn、N.、Lochin、E.、Baudoin、C.、Dubois、E。、およびP. Gelard、「On the Existence of Optimal LEDBAT Parameters」、IEEE ICC 2014-Communication QoS、信頼性とモデリングのシンポジウム、DOI 10.1109 / ICC.2014.6883487、2014、<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6883487>。
[WELZ2015] Welzl, M. and G. Fairhurst, "The Benefits to Applications of using Explicit Congestion Notification (ECN)", Work in Progress, draft-welzl-ecn-benefits-02, March 2015.
[WELZ2015] Welzl、M。、およびG.フェアハースト、「明示的輻輳通知（ECN）を使用するアプリケーションの利点」、作業中、draft-welzl-ecn-benefits-02、2015年3月。
[WINS2014] Winstein, K., "Transport Architectures for an Evolving Internet", PhD thesis, Massachusetts Institute of Technology, June 2014.
[WINS2014] Winstein、K.、「進化するインターネットのためのトランスポートアーキテクチャ」、博士論文、マサチューセッツ工科大学、2014年6月。
Acknowledgements
謝辞
This work has been partially supported by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700).
この作業は、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）を通じて、第7フレームワークプログラムの下で欧州共同体によって部分的にサポートされています。
Many thanks to S. Akhtar, A.B. Bagayoko, F. Baker, R. Bless, D. Collier-Brown, G. Fairhurst, J. Gettys, P. Goltsman, T. Hoiland-Jorgensen, K. Kilkki, C. Kulatunga, W. Lautenschlager, A.C. Morton, R. Pan, G. Skinner, D. Taht, and M. Welzl for detailed and wise feedback on this document.
S. Akhtar、A.Bに感謝します。バガヨコ、F。ベイカー、R。ブレス、D。コリアーブラウン、G。フェアハースト、J。ゲティス、P。ゴルツマン、T。ホイランドヨルゲンセン、K。キルキ、C。クラタンガ、W。ローテンシュラーガー、ACモートン、R 。このドキュメントに関する詳細で賢明なフィードバックについては、Pan、G。Skinner、D。Taht、およびM. Welzl。
Authors' Addresses
著者のアドレス
Nicolas Kuhn (editor) CNES, Telecom Bretagne 18 avenue Edouard Belin Toulouse 31400 France
Nicolas Kuhn（編集者）CNES、Telecom Bretagne 18アベニューエドワールベリントゥールーズ31400フランス
Phone: +33 5 61 27 32 13
Email: nicolas.kuhn@cnes.fr
Preethi Natarajan (editor) Cisco Systems 510 McCarthy Blvd Milpitas, California United States of America
Preethi Natarajan（編集者）Cisco Systems 510 McCarthy Blvdミルピタス、カリフォルニア州アメリカ合衆国
Email: prenatar@cisco.com
Naeem Khademi (editor) University of Oslo Department of Informatics, PO Box 1080 Blindern N-0316 Oslo Norway
Naeem Khademi（編集者）オスロ大学情報学部、私書箱1080 Blindern N-0316オスロノルウェー
Phone: +47 2285 24 93
Email: naeemk@ifi.uio.no
David Ros Simula Research Laboratory AS P.O. Box 134 Lysaker, 1325 Norway
デビッドロスシムラリサーチラボラトリーAS P.O. Box 134 Lysaker、1325 Norway
Phone: +33 299 25 21 21
Email: dros@simula.no