[要約] RFC 8867は、インタラクティブなリアルタイムメディアの輻輳制御を評価するためのテストケースを提供しています。このRFCの目的は、異なるネットワーク条件下での輻輳制御アルゴリズムの効果を評価し、実装の品質を向上させることです。
Internet Engineering Task Force (IETF) Z. Sarker
Request for Comments: 8867 Ericsson AB
Category: Informational V. Singh
ISSN: 2070-1721 callstats.io
X. Zhu
Cisco Systems
M. Ramalho
AcousticComms
January 2021
Test Cases for Evaluating Congestion Control for Interactive Real-Time Media
対話型リアルタイムメディアの輻輳制御を評価するためのテストケース
Abstract
概要
The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment.
リアルタイムトランスポートプロトコル（RTP）は、マルチメディアテレフォニーアプリケーションでメディアを送信するために使用されます。これらのアプリケーションは通常、輻輳制御を実装するために必要です。この文書では、管理環境におけるそのような輻輳制御アルゴリズムの性能評価に使用されるテストケースについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet 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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。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 https://www.rfc-editor.org/info/rfc8867.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8867で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Structure of Test Cases
4. Recommended Evaluation Settings
4.1. Evaluation Metrics
4.2. Path Characteristics
4.3. Media Source
5. Basic Test Cases
5.1. Variable Available Capacity with a Single Flow
5.2. Variable Available Capacity with Multiple Flows
5.3. Congested Feedback Link with Bi-directional Media Flows
5.4. Competing Media Flows with the Same Congestion Control
Algorithm
5.5. Round Trip Time Fairness
5.6. Media Flow Competing with a Long TCP Flow
5.7. Media Flow Competing with Short TCP Flows
5.8. Media Pause and Resume
6. Other Potential Test Cases
6.1. Media Flows with Priority
6.2. Explicit Congestion Notification Usage
6.3. Multiple Bottlenecks
7. Wireless Access Links
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
This memo describes a set of test cases for evaluating congestion control algorithm proposals in controlled environments for real-time interactive media. It is based on the guidelines enumerated in [RFC8868] and the requirements discussed in [RFC8836]. The test cases cover basic usage scenarios and are described using a common structure, which allows for additional test cases to be added to those described herein to accommodate other topologies and/or the modeling of different path characteristics. The described test cases in this memo should be used to evaluate any proposed congestion control algorithm for real-time interactive media.
このメモは、リアルタイム対話型メディアのための制御環境における輻輳制御アルゴリズム提案を評価するための一連のテストケースを表しています。それは[RFC8868]で列挙されたガイドラインと[RFC8836]で説明した要件に基づいています。テストケースは基本的な使用シナリオをカバーしており、共通の構造を使用して説明されています。これにより、他のトポロジーの他のトポロジや異なるパス特性のモデリングに対応するために、本明細書に記載されているものに追加のテストケースを追加することができます。このメモの記載されたテストケースは、リアルタイムインタラクティブメディアのための提案された輻輳制御アルゴリズムを評価するために使用されるべきです。
The terminology defined in RTP [RFC3550], RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], RTCP Extended Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) [RFC4585], and Support for Reduced-Size RTCP [RFC5506] applies.
RTP [RFC3550]で定義されている用語（RFC3551]、RTCP拡張レポート（XR）[RFC3611]、RTCPベースのフィードバックの拡張RTPプロファイル（RTP / AVPF）[RFC4585]、SIZE RTCP [RFC5506]のサポートが適用されます。
All the test cases in this document follow a basic structure allowing implementers to describe a new test scenario without repeatedly explaining common attributes. The structure includes a general description section that describes the test case and its motivation. Additionally the test case defines a set of attributes that characterize the testbed, for example, the network path between communicating peers and the diverse traffic sources.
このドキュメントのすべてのテストケースは、一般的な属性を繰り返し説明することなく、実装者が新しいテストシナリオを記述することを可能にする基本的な構造に従います。この構造は、テストケースとその動機とを説明する一般的な説明セクションを含む。さらに、テストケースは、テストベッドを特徴付ける一連の属性、たとえば通信ピアと多様なトラフィックソース間のネットワークパスを定義します。
Define the test case:
テストケースを定義します。
General description: describes the motivation and the goals of the test case.
一般的な説明：テストケースの動機と目標について説明します。
Expected behavior: describes the desired rate adaptation behavior.
予想される動作：希望のレート適応行動を記述します。
List of metrics to evaluate the desired behavior: this indicates the minimum set of metrics (e.g., link utilization, media sending rate) that a proposed algorithm needs to measure to validate the expected rate adaptation behavior. It should also indicate the time granularity (e.g., averaged over 10 ms, 100 ms, or 1 s) for measuring certain metrics. Typical measurement interval is 200 ms.
目的の動作を評価するためのメトリックのリスト望ましい動作を評価する：提案されたアルゴリズムが予想されるレート適応行動を検証するために測定する必要があるメトリックの最小メトリック（例えば、リンク使用率、メディア送信レート）を示します。それはまた、特定の測定基準を測定するための時間の粒度（例えば、10ms、100ms、または1秒間平均化された）を示すべきである。典型的な測定間隔は200msです。
Define testbed topology:
テストベッドトポロジを定義します。
Every test case needs to define an evaluation testbed topology. Figure 1 shows such an evaluation topology. In this evaluation topology, S1..Sn are traffic sources. These sources generate media traffic and use the congestion control algorithm(s) under investigation. R1..Rn are the corresponding receivers. A test case can have one or more such traffic sources (S) and their corresponding receivers (R). The path from the source to destination is denoted as "forward", and the path from a destination to a source is denoted as "backward". The following basic structure of the test case has been described from the perspective of media-generating endpoints attached on the left-hand side of Figure 1. In this setup, the media flows are transported in the forward direction, and the corresponding feedback/control messages are transported in the backward direction. However, it is also possible to set up the test with media in both forward and backward directions. In that case, unless otherwise specified by the test case, it is expected that the backward path does not introduce any congestion-related impairments and has enough capacity to accommodate both media and feedback/control messages. It should be noted that, depending on the test cases, it is possible to have different path characteristics in either of the directions.
すべてのテストケースは、評価テストベッドトポロジを定義する必要があります。図1はそのような評価トポロジを示す。この評価トポロジでは、S1..Nはトラフィックソースです。これらの情報源はメディアトラフィックを生成し、調査中の輻輳制御アルゴリズムを使用します。 R1..RNは対応する受信機です。テストケースは、1つ以上のそのようなトラフィックソースとそれらの対応する受信機（R）を有することができる。ソースから宛先へのパスは「Forward」として表され、宛先からソースへのパスは「後方」と表記されます。次のテストケースの基本構造は、図1の左側に取り付けられたメディア生成エンドポイントの観点から説明されています。この設定では、メディアフローは順方向に搬送され、対応するフィードバック/コントロールが搬送されます。メッセージは後方に輸送されます。ただし、順方向と後方方向の両方のメディアでテストを設定することも可能です。その場合、テストケースによって特に指定がない限り、逆方向経路が渋滞に関連した障害を導入しないと予想され、メディアとフィードバック/制御メッセージの両方に収容するのに十分な容量があると予想されます。なお、テストケースに応じて、どちらの方向にも異なる経路特性を有することが可能であることに留意されたい。
+---+ +---+
|S1 |====== \ Forward --> / =======|R1 |
+---+ \\ // +---+
\\ //
+---+ +-----+ +-----+ +---+
|S2 |=======| A |--------------------------->| B |=======|R2 |
+---+ | |<---------------------------| | +---+
+-----+ +-----+
(...) // \\ (...)
// <-- Backward \\
+---+ // \\ +---+
|Sn |====== / \ ======|Rn |
+---+ +---+
Figure 1: Example of a Testbed Topology
図1：テストベッドトポロジの例
In a testbed environment with real equipment, there may exist a significant amount of unwanted traffic on the portions of the network path between the endpoints. Some of this traffic may be generated by other processes on the endpoints themselves (e.g., discovery protocols) or by other endpoints not presently under test. Such unwanted traffic should be removed or avoided to the greatest extent possible.
実装置を備えたテストベッド環境では、エンドポイント間のネットワーク経路の部分にはかなりの量の不要なトラフィックが存在する可能性があります。このトラフィックのいくつかは、エンドポイント自体（例えば、発見プロトコル）または現在テスト中の他のエンドポイントによって、他のプロセスによって生成されてもよい。そのような望ましくないトラフィックは、可能な限り最大限に削除または回避されるべきです。
Define testbed attributes:
テストベッド属性を定義します。
Duration: defines the duration of the test in seconds.
期間：テストの期間を秒単位で定義します。
Path characteristics: defines the end-to-end transport level path characteristics of the testbed for a particular test case. Two sets of attributes describe the path characteristics, one for the forward path and the other for the backward path. The path characteristics for a particular path direction are applicable to all the sources "S" sending traffic on that path. If only one attribute is specified, it is used for both path directions; however, unless specified the reverse path has no capacity restrictions and no path loss.
パス特性：特定のテストケースのテストベッドのエンドツーエンドのトランスポートレベルのパス特性を定義します。2組の属性は、パスの特性を表すパス特性を表します。特定のパス方向のパス特性は、そのパス上のトラフィックを送信するすべてのソース "S"に適用できます。属性が1つだけ指定されていれば、両方のパス方向に使用されます。ただし、指定されていない限り、リバースパスには容量の制限がなく、パスが失われません。
Path direction: forward or backward.
パス方向：前後または後方。
Minimum bottleneck-link capacity: defines the minimum capacity of the end-to-end path.
最小限のボトルネックリンク容量：エンドツーエンドパスの最小容量を定義します。
Reference bottleneck capacity: defines a reference value for the bottleneck capacity for test cases with time-varying bottleneck capacities. All bottleneck capacities will be specified as a ratio with respect to the reference capacity value.
参照ボトルネックの容量：時々のボトルネック容量を持つテストケースのボトルネック容量の基準値を定義します。すべてのボトルネック容量は、基準容量値に対する比率として指定されます。
One-way propagation delay: describes the end-to-end latency along the path when network queues are empty, i.e., the time it takes for a packet to go from the sender to the receiver without encountering any queuing delay.
一方向の伝播遅延：ネットワークキューが空のとき、すなわち、待ち行列遅延に遭遇することなく、送信者から受信機への送信者から受信機への送信者から受信機への受信機への送信者から受信機への受信機への通信にかかる時間を記述する。
Maximum end-to-end jitter: defines the maximum jitter that can be observed along the path.
最大エンドツーエンドジッタ：パスに沿って観察できる最大ジッタを定義します。
Bottleneck queue type: for example, "tail drop" [RFC7567], Flow Queue Controlled Delay (FQ-CoDel) [RFC8290], or Proportional Integral controller Enhanced (PIE) [RFC8033].
ボトルネックキューの種類：たとえば、「テールドロップ」[RFC7567]、フローキュー制御遅延（FQ-CODEL）[RFC8290]、または比例積分コントローラ拡張（PIE）[RFC8033]。
Bottleneck queue size: defines the size of queue in terms of queuing time when the queue is full (in milliseconds).
ボトルネックキューサイズ：キューがいっぱいになったときのキューの項でキューのサイズを定義します（ミリ秒）。
Path loss ratio: characterizes the non-congested, additive losses to be generated on the end-to-end path. This must describe the loss pattern or loss model used to generate the losses.
経路損失率：エンドツーエンドパスで生成される非輻輳の非損失損失を特徴付けます。これは損失を生成するために使用される損失パターンまたは損失モデルを記述しなければなりません。
Application-related: defines the traffic source behavior for implementing the test case:
アプリケーション関連：テストケースを実装するためのトラフィックソースの動作を定義します。
Media traffic source: defines the characteristics of the media sources. When using more than one media source, the different attributes are enumerated separately for each different media source.
メディアトラフィックソース：メディアソースの特性を定義します。複数のメディアソースを使用する場合、さまざまな属性は、さまざまなメディアソースごとに個別に列挙されます。
Media type: Video/Voice.
メディアタイプ：ビデオ/音声。
Media flow direction: forward, backward, or both.
メディアフロー方向：前方、後方、またはその両方。
Number of media sources: defines the total number of media sources.
メディアソース数：メディアソースの総数を定義します。
Media codec: Constant Bit Rate (CBR) or Variable Bit Rate (VBR).
メディアコーデック：一定ビットレート（CBR）または可変ビットレート（VBR）。
Media source behavior: describes the media encoder behavior. It defines the main parameters that affect the adaptation behavior. This may include but is not limited to the following:
メディアソースの動作：メディアエンコーダの動作について説明します。適応行動に影響を与える主なパラメータを定義します。これには以下のものが含まれるがこれらに限定されない。
Adaptability: describes the adaptation options. For example, in the case of video, it defines the following ranges of adaptation: bit rate, frame rate, and video resolution. Similarly, in the case of voice, it defines the range of bit rate adaptation, the sampling rate variation, and the variation in packetization interval.
適応性：適応オプションを説明します。例えば、ビデオの場合、それは以下の範囲の適応範囲を定義する：ビットレート、フレームレート、およびビデオ解像度。同様に、音声の場合、それはビットレート適応の範囲、サンプリングレートの変動、およびパケット化間隔の変動を定義する。
Output variation: for a VBR encoder, it defines the encoder output variation from the average target rate over a particular measurement interval. For example, on average the encoder output may vary between 5% to 15% above or below the average target bit rate when measured over a 100 ms time window. The time interval over which the variation is specified must be provided.
Responsiveness to a new bit rate request: the lag in time between a new bit rate request from the congestion control algorithm and actual rate changes in encoder output. Depending on the encoder, this value may be specified in absolute time (e.g., 10 ms to 1000 ms) or other appropriate metric (e.g., next frame interval time).
新しいビットレート要求に対する応答性：輻輳制御アルゴリズムからの新しいビットレート要求とエンコーダ出力の実際のレート変化の間のLAG。エンコーダによっては、この値は絶対時間（例えば、10msから1000ms）または他の適切なメトリック（例えば、次のフレーム間隔時間）で指定することができる。
More detailed discussions on expected media source behavior, including those from synthetic video traffic sources, can be found in [RFC8593].
合成ビデオトラフィックソースからのものを含む、予想されるメディアソースの動作に関するより詳細な説明は[RFC8593]にあります。
Media content: describes the chosen video scenario. For example, video test sequences are available at [xiph-seq] and [HEVC-seq]. Different video scenarios give different distributions of video frames produced by the video encoder. Hence, it is important to specify the media content used in a particular test. If a synthetic video traffic source [RFC8593] is used, then the synthetic video traffic source needs to be configured according to the characteristics of the media content specified.
メディアコンテンツ：選択されたビデオシナリオについて説明します。例えば、ビデオテストシーケンスは[XIPH-SEQ]および[HEVC-SEQ]で入手可能である。異なるビデオシナリオは、ビデオエンコーダによって生成されたビデオフレームの異なる分布を与える。したがって、特定のテストで使用されるメディアコンテンツを指定することが重要です。合成ビデオトラフィックソース[RFC8593]が使用されている場合、合成ビデオトラフィックソースは指定されたメディアコンテンツの特性に従って設定する必要があります。
Media timeline: describes the point when the media source is introduced and removed from the testbed. For example, the media source may start transmitting immediately when the test case begins, or after a few seconds.
メディアタイムライン：メディアソースがテストベッドから導入され削除されたときのポイントを説明します。例えば、メディアソースは、テストケースが始まるとき、または数秒後にすぐに送信を開始することができる。
Startup behavior: the media starts at a defined bit rate, which may be the minimum, maximum bit rate, or a value in between (in Kbps).
起動動作：メディアは定義されたビットレートで始まり、これは最小、最大ビットレート、または間の値（Kbps）であり得る。
Competing traffic source: describes the characteristics of the competing traffic source, the different types of competing flows are enumerated in [RFC8868].
競合するトラフィック源：競合するトラフィック源の特性を説明している、競合する種類の競合フローは[RFC8868]で列挙されています。
Traffic direction: forward, backward, or both.
交通方向：前方、後方、またはその両方。
Type of sources: defines the types of competing traffic sources. Types of competing traffic flows are listed in [RFC8868]. For example, the number of TCP flows connected to a web browser, the mean size and distribution of the content downloaded.
ソースの種類：競合するトラフィックソースの種類を定義します。競合するトラフィックフローの種類は[RFC8868]にリストされています。たとえば、Webブラウザに接続されているTCPフローの数、ダウンロードされたコンテンツの平均サイズと配布。
Number of sources: defines the total number of competing sources of each media type per traffic direction.
ソース数：トラフィック方向ごとの各メディアタイプの競合元の総数を定義します。
Congestion control: enumerates the congestion control used by each type of competing traffic.
輻輳制御：各タイプの競合トラフィックによって使用される輻輳制御を列挙します。
Traffic timeline: describes when the competing traffic starts and ends in the test case.
トラフィックタイムライン：競合するトラフィックがいつ始まり、テストケースで終了するかを説明します。
Additional attributes: describes attributes essential for implementing a test case that are not included in the above structure. These attributes must be well defined, so that the other implementers of that particular test case are able to implement it easily.
追加の属性：上記の構造に含まれていないテストケースを実装するための属性を説明します。これらの属性は明確に定義されている必要がありますので、その特定のテストケースの他の実装者は簡単に実装できます。
Any attribute can have a set of values (enclosed within "[]"). Each member value of such a set must be treated as different value for the same attribute. It is desired to run separate tests for each such attribute value.
任意の属性は一連の値を持つことができます（ "[]"内に囲まれています）。そのようなセットの各メンバー値は、同じ属性に対して異なる値として扱われなければなりません。そのような属性値ごとに別々のテストを実行することが望ましい。
The test cases described in this document follow the above structure.
この文書に記載されているテストケースは、上記の構造に従います。
This section describes recommended test case settings and could be overwritten by the respective test cases.
このセクションでは、推奨されるテストケース設定について説明し、それぞれのテストケースで上書きすることができます。
To evaluate the performance of the candidate algorithms, the implementers must log enough information to visualize the following metrics at a fine enough time granularity:
候補アルゴリズムのパフォーマンスを評価するためには、実装者は十分な情報を十分に細かく視覚的に視覚化するのに十分な情報を記録する必要があります。
1. Flow level:
1. フローレベル：
A. End-to-end delay for the congestion-controlled media flow(s). For example, end-to-end delay observed on the IP packet level and the video frame level.
A.輻輳制御メディアフローのエンドツーエンドの遅延。たとえば、エンドツーエンドの遅延は、IPパケットレベルとビデオフレームレベルで観察されました。
B. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations.
B.送信ビットレートとスループットの変動。振動の周波数と大きさを主に観察します。
C. Packet losses observed at the receiving endpoint.
C.受信エンドポイントでパケット損失が観察されました。
D. Feedback message overhead.
D.フィードバックメッセージオーバーヘッド。
E. Convergence time. Time to reach steady state for the congestion-controlled media flow(s). Each occurrence of convergence during the test period needs to be presented.
E.コンバージェンス時間。輻輳制御メディアフローの定常状態に達する時間。試験期間中の収束の発生がそれぞれ提示される必要がある。
2. Transport level:
2. トランスポートレベル：
A. Bandwidth utilization.
A.帯域幅利用
B. Queue length (milliseconds at specified path capacity).
B.キューの長さ（指定されたパス容量でミリ秒）。
Each path between a sender and receiver as described in Figure 1 has the following characteristics unless otherwise specified in the test case:
図1に記載されている送信者と受信機との間の各経路は、テストケースで特に指定されていない限り、以下の特性を有する。
Path direction: forward and backward.
パス方向：前後と後方。
Reference bottleneck capacity: 1 Mbps.
参照ボトルネック容量：1 Mbps。
One-way propagation delay: 50 ms. Implementers are encouraged to run the experiment with additional propagation delays mentioned in [RFC8868].
一方向伝搬遅延：50ミリ秒実装者は、[RFC8868]に記載されている追加の伝播遅延で実験を実行することをお勧めします。
Maximum end-to-end jitter: 30 ms. Jitter models are described in [RFC8868].
最大エンドツーエンドジッタ：30ミリ秒。ジッタモデルは[RFC8868]に記載されています。
Bottleneck queue type: "tail drop". Implementers are encouraged to run the experiment with other Active Queue Management (AQM) schemes, such as FQ-CoDel and PIE.
ボトルネックキュータイプ： "テールドロップ"。実装者は、FQ-CodelやPieなどの他のアクティブキュー管理（AQM）方式を使用して実験を実行することが奨励されています。
Bottleneck queue size: 300 ms.
ボトルネックキューサイズ：300ミリ秒
Path loss ratio: 0%.
Examples of additional network parameters are discussed in [RFC8868].
追加のネットワークパラメータの例は[RFC8868]で説明されています。
For test cases involving time-varying bottleneck capacity, all capacity values are specified as a ratio with respect to a reference capacity value, so as to allow flexible scaling of capacity values along with media source rate range. There exist two different mechanisms for inducing path capacity variation: a) by explicitly modifying the value of physical link capacity, or b) by introducing background non-adaptive UDP traffic with time-varying traffic rate. Implementers are encouraged to run the experiments with both mechanisms for test cases specified in Section 5.1, Section 5.2, and Section 5.3.
時変ボトルネック容量を含むテストケースの場合、メディアソースレート範囲と共に容量値の柔軟なスケーリングを可能にするために、すべての容量値が基準容量値に対する比として指定されます。経路容量の変動を誘発するための2つの異なるメカニズムが存在しています。実装者は、セクション5.1、5.2節、セクション5.3で指定されたテストケースの両方のメカニズムを使用して実験を実行することが奨励されています。
Unless otherwise specified, each test case will include one or more media sources as described below:
特に明記しない限り、各テストケースは以下のように1つ以上のメディアソースを含む。
Media type: Video
メディアタイプ：ビデオ
Media codec: VBR
メディアコーデック：VBR.
Media source behavior:
メディアソースの動作：
Adaptability:
適応性：
Bit rate range: 150 Kbps - 1.5 Mbps. In real-life applications, the bit rate range can vary a lot depending on the provided service; for example, the maximum bit rate can be up to 4 Mbps. However, for running tests to evaluate the congestion control algorithms, it is more important to have a look at how they react to a certain amount of bandwidth change. Also it is possible that the media traffic generator used in a particular simulator or testbed is not capable of generating a higher bit rate. Hence, we have selected a suitable bit rate range typical of consumer-grade video conferencing applications in designing the test case. If a different bit rate range is used in the test cases, then the end-to-end path capacity values will also need to be scaled accordingly.
ビットレート範囲：150 kbps - 1.5 Mbps。実際のアプリケーションでは、提供されたサービスに応じてビットレートの範囲は大きく異なります。たとえば、最大ビットレートは最大4 Mbpsです。ただし、輻輳制御アルゴリズムを評価するためのテストを実行するためには、それらがある程度の帯域幅の変化にどのように反応するかを調べることがより重要です。特定のシミュレータまたはテストベッドで使用されるメディアトラフィックジェネレータがより高いビットレートを生成することができないことも可能である。したがって、我々は、テストケースを設計する際に、消費者グレードのビデオ会議アプリケーションに典型的な適切なビットレート範囲を選択した。テストケースで異なるビットレート範囲が使用されている場合、エンドツーエンドのパス容量値もそれに応じて拡大縮小する必要があります。
Frame resolution: 144p - 720p (or 1080p). This resolution range is selected based on the bit rate range. If a different bit rate range is used in the test cases, then a suitable frame resolution range also needs to be selected.
フレーム解像度：144p - 720p（または1080p）。この解像度範囲は、ビットレート範囲に基づいて選択されます。テストケースで異なるビットレート範囲が使用されている場合は、適切なフレーム解像度範囲を選択する必要があります。
Frame rate: 10 fps - 30 fps. This frame rate range is selected based on the bit rate range. If a different bit rate range is used in the test cases, then the frame rate range also needs to be suitably adjusted.
フレームレート：10 fps - 30 fps。このフレームレート範囲は、ビットレート範囲に基づいて選択される。テストケースで異なるビットレート範囲が使用されている場合、フレームレート範囲も適切に調整される必要があります。
Variation from target bit rate: +/-5%. Unless otherwise specified in the test case(s), bit rate variation should be calculated over a one (1) second period of time.
Responsiveness to new bit rate request: 100 ms
新しいビットレート要求に対する応答性：100さん
Media content: The media content should represent a typical video conversational scenario with head and shoulder movement. We recommend using the Foreman video sequence [xiph-seq].
メディアコンテンツ：メディアコンテンツは、ヘッドと肩の動きを持つ典型的なビデオ会話シナリオを表すべきです。職長ビデオシーケンス[XIPH-SEQ]を使用することをお勧めします。
Media startup behavior: 150 Kbps. It should be noted that applications can use smart ways to select an optimal startup bit rate value for a certain network condition. In such cases, the candidate proposals may show the effectiveness of such a smart approach as additional information for the evaluation process.
メディアスタートアップ動作：150 kbpsアプリケーションは、あるネットワーク状態に最適な起動ビットレート値を選択するためのスマート方法を使用することができることに注意してください。そのような場合、候補提案は、評価プロセスのための追加情報としてそのようなスマートアプローチの有効性を示すことができる。
Media type: Audio
メディアタイプ：オーディオ
Media codec: CBR
メディアコーデック：CBR.
Media bit rate: 20 Kbps
メディアビットレート：20 kbps
In this test case, the minimum bottleneck-link capacity between the two endpoints varies over time. This test is designed to measure the responsiveness of the candidate algorithm. This test tries to address the requirements in [RFC8836], which requires the algorithm to adapt the flow(s) and provide lower end-to-end latency when there exists:
このテストケースでは、2つのエンドポイント間の最小のボトルネックリンク容量が経時的に変化します。このテストは候補アルゴリズムの応答性を測定するように設計されています。このテストは[RFC8836]の要件に対処しようとしています。これは、フローを適応させるためのアルゴリズムが必要であり、存在するときに低いエンドツーエンドの待ち時間を提供する必要があります。
* an intermediate bottleneck
* 中間のボトルネック
* change in available capacity (e.g., due to interface change, routing change, abrupt arrival/departure of background non-adaptive traffic)
* 利用可能な容量の変化（例えば、インタフェースの変更、ルーティングの変更、急激な到着/バックグラウンド以外の非適応トラフィックの出発）
* maximum media bit rate is greater than link capacity. In this case, when the application tries to ramp up to its maximum bit rate, since the link capacity is limited to a lower value, the congestion control scheme is expected to stabilize the sending bit rate close to the available bottleneck capacity.
* 最大メディアビットレートはリンク容量よりも大きい。この場合、アプリケーションが最大ビットレートまで上昇しようとすると、リンク容量は低い値に制限されているため、輻輳制御方式は使用可能なボトルネック容量に近い送信ビットレートを安定させることが期待されています。
It should be noted that the exact variation in available capacity due to any of the above depends on the underlying technologies. Hence, we describe a set of known factors, which may be extended to devise a more specific test case targeting certain behaviors in a certain network environment.
上記の技術による利用可能な容量の正確な変動は、基礎となる技術に依存することに留意されたい。したがって、特定のネットワーク環境で特定の行動をターゲットにしているより具体的なテストケースを考案するために拡張され得る既知の要因のセットについて説明します。
Expected behavior: The candidate algorithm is expected to detect the path capacity constraint, converge to the bottleneck link's capacity, and adapt the flow to avoid unwanted media rate oscillation when the sending bit rate is approaching the bottleneck link's capacity. Such oscillations might occur when the media flow(s) attempts to reach its maximum bit rate but overshoots the usage of the available bottleneck capacity, then to rectify, it reduces the bit rate and starts to ramp up again.
予想される動作：候補アルゴリズムは、パス容量制約を検出し、ボトルネックリンクの容量に収束し、送信ビットレートがボトルネックリンクの容量に近づいているときに不要なメディアレートの振動を回避するようにフローを適応させます。このような振動は、メディアフローが最大ビットレートに達するが、利用可能なボトルネック容量の使用をオーバーシュートしてから、整流すると、ビットレートを縮小し、再度ランプアップし始めることがあります。
Evaluation metrics: As described in Section 4.1.
評価メトリクス：4.1節に記載されているように。
Testbed topology: One media source S1 is connected to the corresponding R1. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path.
テストベッドトポロジー：1つのメディアソースS1が対応するR1に接続されている。メディアトラフィックは順方向パスを介して転送され、対応するフィードバック/制御トラフィックは後方パスを介して転送されます。
Forward -->
+---+ +-----+ +-----+ +---+
|S1 |=======| A |------------------------------>| B |=======|R1 |
+---+ | |<------------------------------| | +---+
+-----+ +-----+
<-- Backward
Figure 2: Testbed Topology for Limited Link Capacity
図2：限られたリンク容量のためのテストベッドトポロジー
Testbed attributes:
テスト属性：
Test duration: 100 s
テスト期間：100 S
Path characteristics: as described in Section 4.2
パス特性：セクション4.2に記載されているように
Application-related:
アプリケーション関連：
Media Traffic:
メディアトラフィック：
Media type: Video
メディアタイプ：ビデオ
Media direction: forward
メディアの方向：前方
Number of media sources: one (1)
メディアソース数：1（1）
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 99 s
終了時間：99 S
Media type: Audio
メディアタイプ：オーディオ
Media direction: forward
メディアの方向：前方
Number of media sources: one (1)
メディアソース数：1（1）
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 99 s
終了時間：99 S
Competing traffic:
競合するトラフィック：
Number of sources: zero (0)
ソース数：ゼロ（0）
Test-specific information:
テスト固有の情報：
One-way propagation delay: [50 ms, 100 ms]. On the forward path direction.
一方向の伝播遅延：[50ミリ秒、100ミリ秒]。順方向経路方向に。
This test uses bottleneck path capacity variation as listed in Table 1.
このテストでは、表1にリストされているようにボトルネックパス容量の変動を使用します。
When using background non-adaptive UDP traffic to induce a time-varying bottleneck, the physical path capacity remains at 4 Mbps, and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity in Mbps, and Y is the path capacity ratio specified in Table 1.
バックグラウンド以外のUDPトラフィックを使用して時変ボトルネックを誘発するとき、物理パス容量は4 Mbpsのままであり、UDPトラフィックソースレートは時間とともに時間とともに変化します（4 - （y xr））、Rは参照ボトルネックです。Mbpsの容量、およびyは表1に指定されているパス容量比です。
+=========================+================+=======+===============+
| Variation pattern index | Path direction | Start | Path capacity |
| | | time | ratio |
+=========================+================+=======+===============+
| One | Forward | 0 s | 1.0 |
+-------------------------+----------------+-------+---------------+
| Two | Forward | 40 s | 2.5 |
+-------------------------+----------------+-------+---------------+
| Three | Forward | 60 s | 0.6 |
+-------------------------+----------------+-------+---------------+
| Four | Forward | 80 s | 1.0 |
+-------------------------+----------------+-------+---------------+
Table 1: Path Capacity Variation Pattern for the Forward Direction
表1：前方方向の経路容量変動パターン
This test case is similar to Section 5.1. However, this test will also consider persistent network load due to competing traffic.
このテストケースはセクション5.1と同様です。ただし、このテストでは、競合するトラフィックによる永続的なネットワーク負荷も検討します。
Expected behavior: The candidate algorithm is expected to detect the variation in available capacity and adapt the media stream(s) accordingly. The flows stabilize around their maximum bit rate as the maximum link capacity is large enough to accommodate the flows. When the available capacity drops, the flows adapt by decreasing their sending bit rate, and when congestion disappears, the flows are again expected to ramp up.
予想される動作：候補アルゴリズムは、利用可能な容量の変動を検出し、それに応じてメディアストリームを適応させると予想される。最大リンク容量がフローを収容するのに十分な大きさであるため、フローは最大ビットレートを中心に安定します。利用可能な容量が低下すると、送信ビットレートを下げることによってフローが適応し、輻輳が消えると、フローが再び上昇すると予想されます。
Evaluation metrics: As described in Section 4.1.
評価メトリクス：4.1節に記載されているように。
Testbed topology: Two (2) media sources S1 and S2 are connected to their corresponding destinations R1 and R2. The media traffic is transported over the forward path and corresponding feedback/ control traffic is transported over the backward path.
テストベッドトポロジー：2つのメディアソースS1およびS2は、対応する目的地R1およびR2に接続されている。メディアトラフィックは順方向パスを介して転送され、対応するフィードバック/制御トラフィックは後方パスを介して転送されます。
+---+ +---+
|S1 |===== \ / =======|R1 |
+---+ \\ Forward --> // +---+
\\ //
+-----+ +-----+
| A |------------------------------>| B |
| |<------------------------------| |
+-----+ +-----+
// \\
// <-- Backward \\
+---+ // \\ +---+
|S2 |====== / \ ======|R2 |
+---+ +---+
Figure 3: Testbed Topology for Variable Available Capacity
図3：可変容量のためのテストベッドトポロジー
Testbed attributes: Testbed attributes are similar to those described in Section 5.1, except for the test-specific capacity variation setup.
テストベッド属性：テストベッド属性は、テスト固有の容量のバリエーション設定を除いて、セクション5.1で説明されているものと似ています。
Test-specific information: This test uses path capacity variation as listed in Table 2 with a corresponding end time of 125 seconds. The reference bottleneck capacity is 2 Mbps. When using background non-adaptive UDP traffic to induce time-varying bottleneck for congestion-controlled media flows, the physical path capacity is 4 Mbps, and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity in Mbps, and Y is the path capacity ratio specified in Table 2.
テスト固有の情報：このテストでは、対応する終了時刻が125秒で表2に示すように、パス容量の変動を使用します。参照ボトルネックの容量は2 Mbpsです。輻輳制御メディアフローのための時変ボトルネックを誘導するためにバックグラウンド以外のUDPトラフィックを使用する場合、物理パス容量は4 Mbps、そしてUDPトラフィックソースレートは時間とともに時間とともに変化します（4 - （y xr））。MBPSの参照ボトルネック容量、yは表2に指定されているパス容量比です。
+=========================+================+=======+===============+
| Variation pattern index | Path direction | Start | Path capacity |
| | | time | ratio |
+=========================+================+=======+===============+
| One | Forward | 0 s | 2.0 |
+-------------------------+----------------+-------+---------------+
| Two | Forward | 25 s | 1.0 |
+-------------------------+----------------+-------+---------------+
| Three | Forward | 50 s | 1.75 |
+-------------------------+----------------+-------+---------------+
| Four | Forward | 75 s | 0.5 |
+-------------------------+----------------+-------+---------------+
| Five | Forward | 100 s | 1.0 |
+-------------------------+----------------+-------+---------------+
Table 2: Path Capacity Variation Pattern for the Forward Direction
表2：順方向の経路容量変動パターン
Real-time interactive media uses RTP; hence it is assumed that RTCP, RTP header extension, or such would be used by the congestion control algorithm in the back channel. Due to the asymmetric nature of the link between communicating peers, it is possible for a participating peer to not receive such feedback information due to an impaired or congested back channel (even when the forward channel might not be impaired). This test case is designed to observe the candidate congestion control behavior in such an event.
リアルタイム対話型メディアはRTPを使用します。したがって、RTCP、RTPヘッダ拡張子、またはそのようなものがバックチャネル内の輻輳制御アルゴリズムによって使用されると仮定される。通信ピア間のリンクの非対称性のために、参加しているピアは、障害のあるまたは輻輳したバックチャネルのために（順方向チャネルが損なわれていない場合であっても）そのようなフィードバック情報を受信しないことが可能である。このテストケースは、そのようなイベントで候補輻輳制御動作を観察するように設計されています。
Expected behavior: It is expected that the candidate algorithms are able to cope with the lack of feedback information and to adapt to minimize the performance degradation of media flows in the forward channel.
予想される行動：候補アルゴリズムはフィードバック情報の欠如に対処し、順方向チャネル内のメディアフローの性能劣化を最小限に抑えることができると予想される。
It should be noted that for this test case, logs are compared with the reference case, i.e., when the backward channel has no impairments.
このテストケースでは、ログは参照ケース、すなわち後方チャネルが障害がない場合に比較されることに留意されたい。
Evaluation metrics: As described in Section 4.1.
評価メトリクス：4.1節に記載されているように。
Testbed topology: One (1) media source S1 is connected to corresponding R1, but both endpoints are additionally receiving and sending data, respectively. The media traffic (S1->R1) is transported over the forward path, and the corresponding feedback/ control traffic is transported over the backward path. Likewise, media traffic (S2->R2) is transported over the backward path, and the corresponding feedback/control traffic is transported over the forward path.
テストベッドトポロジー：1つのメディアソースS1が対応するR1に接続されていますが、どちらのエンドポイントはそれぞれ追加的にデータを送受信しています。メディアトラフィック（S1-> R1）は順方向経路を介して搬送され、対応するフィードバック/制御トラフィックは逆方向経路を介して転送される。同様に、メディアトラフィック（S2-> R2）は逆方向経路を介して搬送され、対応するフィードバック/制御トラフィックは順方向経路を介して転送される。
+---+ +---+
|S1 |====== \ Forward --> / =======|R1 |
+---+ \\ // +---+
\\ //
+-----+ +-----+
| A |------------------------------>| B |
| |<------------------------------| |
+-----+ +-----+
// \\
// <-- Backward \\
+---+ // \\ +---+
|R2 |===== / \ ======|S2 |
+---+ +---+
Figure 4: Testbed Topology for Congested Feedback Link
図4：混雑フィードバックリンクのテストベッドトポロジー
Testbed attributes:
テスト属性：
Test duration: 100 s
テスト期間：100 S
Path characteristics:
パスの特性：
Reference bottleneck capacity: 1 Mbps
参照ボトルネック容量：1 Mbps
Application-related:
アプリケーション関連：
Media source:
メディアソース：
Media type: Video
メディアタイプ：ビデオ
Media direction: forward and backward
メディアの方向：前後の前後
Number of media sources: two (2)
メディアソース数：2（2）
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 99 s
終了時間：99 S
Media type: Audio
メディアタイプ：オーディオ
Media direction: forward and backward
メディアの方向：前後の前後
Number of media sources: two (2)
メディアソース数：2（2）
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 99 s
終了時間：99 S
Competing traffic:
競合するトラフィック：
Number of sources: zero (0)
ソース数：ゼロ（0）
Test-specific information: This test uses path capacity variations to create a congested feedback link. Table 3 lists the variation patterns applied to the forward path, and Table 4 lists the variation patterns applied to the backward path. When using background non-adaptive UDP traffic to induce a time-varying bottleneck for congestion-controlled media flows, the physical path capacity is 4 Mbps for both directions, and the UDP traffic source rate changes over time as (4-x) Mbps in each direction, where x is the bottleneck capacity specified in Table 4.
テスト固有の情報：このテストはパス容量のバリエーションを使用して混雑フィードバックリンクを作成します。表3は、順方向経路に適用される変動パターンを示し、表4に逆方向経路に適用される変動パターンを列挙する。輻輳制御メディアフローに対して時変なボトルネックを誘発するためにバックグラウンドでないUDPトラフィックを使用する場合、物理パス容量は両方向に対して4 Mbps、およびUDPトラフィックソースレートは時間とともに時間とともに変化します（4-X）Mbpsここで、xは表4で指定されたボトルネック容量です。
+=========================+================+=======+===============+
| Variation pattern index | Path direction | Start | Path capacity |
| | | time | ratio |
+=========================+================+=======+===============+
| One | Forward | 0 s | 2.0 |
+-------------------------+----------------+-------+---------------+
| Two | Forward | 20 s | 1.0 |
+-------------------------+----------------+-------+---------------+
| Three | Forward | 40 s | 0.5 |
+-------------------------+----------------+-------+---------------+
| Four | Forward | 60 s | 2.0 |
+-------------------------+----------------+-------+---------------+
Table 3: Path Capacity Variation Pattern for the Forward Direction
表3：順方向の経路容量変動パターン
+=========================+================+=======+===============+
| Variation pattern index | Path direction | Start | Path capacity |
| | | time | ratio |
+=========================+================+=======+===============+
| One | Backward | 0 s | 2.0 |
+-------------------------+----------------+-------+---------------+
| Two | Backward | 35 s | 0.8 |
+-------------------------+----------------+-------+---------------+
| Three | Backward | 70 s | 2.0 |
+-------------------------+----------------+-------+---------------+
Table 4: Path Capacity Variation Pattern for the Backward Direction
表4：後方方向の経路容量変動パターン
In this test case, more than one media flow share the bottleneck link, and each of them uses the same congestion control algorithm. This is a typical scenario where a real-time interactive application sends more than one media flow to the same destination, and these flows are multiplexed over the same port. In such a scenario, it is likely that the flows will be routed via the same path and need to share the available bandwidth amongst themselves. For the sake of simplicity, it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows individually. While this appears to be a variant of the test case defined in Section 5.2, it focuses on the capacity-sharing aspect of the candidate algorithm. The previous test case, on the other hand, measures adaptability, stability, and responsiveness of the candidate algorithm.
このテストケースでは、複数のメディアフローがボトルネックリンクを共有し、それらのそれぞれは同じ輻輳制御アルゴリズムを使用します。これは、リアルタイムの対話型アプリケーションが同じ宛先に複数のメディアフローを送信し、これらのフローは同じポートを介して多重化されている典型的なシナリオです。このようなシナリオでは、フローは同じパスを介してルーティングされ、自分で利用可能な帯域幅を共有する必要がある可能性があります。簡単にするために、ボトルネックリンク内に他の競合するトラフィックソースがないと仮定されており、全てのフローに個別に収容するのに十分な容量があると仮定する。これはセクション5.2で定義されているテストケースの変形であるように見えますが、候補アルゴリズムの容量共有の側面に焦点を当てています。一方、前のテストケースは、候補アルゴリズムの適応性、安定性、および応答性を測定する。
Expected behavior: It is expected that the competing flows will converge to an optimum bit rate to accommodate all the flows with minimum possible latency and loss. Specifically, the test introduces three media flows at different time instances. When the second flow appears, there should still be room to accommodate another flow on the bottleneck link. Lastly, when the third flow appears, the bottleneck link should be saturated.
予想される行動：競合するフローはすべての流れに対応するために最適な待ち時間と損失を収容するために最適なビットレートに収束することが予想されます。具体的には、テストには異なる時点で3つのメディアフローが導入されています。2番目の流れが現れると、ボトルネックリンク上の別の流れに対応するための部屋があるはずです。最後に、3番目の流れが現れると、ボトルネックリンクは飽和しているはずです。
Evaluation metrics: As described in Section 4.1.
評価メトリクス：4.1節に記載されているように。
Testbed topology: Three media sources S1, S2, and S3 are connected to R1, R2, and R3, respectively. The media traffic is transported over the forward path, and the corresponding feedback/control traffic is transported over the backward path.
テストベッドトポロジー：3つのメディアソースS1、S2、S3は、それぞれR1、R2、R3に接続されています。メディアトラフィックは順方向パスを介して転送され、対応するフィードバック/制御トラフィックは逆方向パスを介して転送されます。
+---+ +---+
|S1 |===== \ Forward --> / =======|R1 |
+---+ \\ // +---+
\\ //
+---+ +-----+ +-----+ +---+
|S2 |=======| A |------------------------------>| B |=======|R2 |
+---+ | |<------------------------------| | +---+
+-----+ +-----+
// <-- Backward \\
+---+ // \\ +---+
|S3 |===== / \ ======|R3 |
+---+ +---+
Figure 5: Testbed Topology for Multiple Congestion-Controlled Media Flows
図5：複数の輻輳制御メディアフローのテストベッドトポロジー
Testbed attributes:
テスト属性：
Test duration: 120 s
テスト期間：120 S.
Path characteristics:
パスの特性：
Reference bottleneck capacity: 3.5 Mbps
参照ボトルネック容量：3.5 Mbps
Path capacity ratio: 1.0
経路容量比：1.0
Application-related:
アプリケーション関連：
Media Source:
メディアソース：
Media type: Video
メディアタイプ：ビデオ
Media direction: forward
メディアの方向：前方
Number of media sources: three (3)
メディアソース数：3（3）
Media timeline: New media flows are added sequentially, at short time intervals. See the test-specific setup below.
メディアタイムライン：新しいメディアフローが短時間間隔で順次追加されます。以下のテスト固有の設定を参照してください。
Media type: Audio
メディアタイプ：オーディオ
Media direction: forward
メディアの方向：前方
Number of media sources: three (3)
メディアソース数：3（3）
Media timeline: New media flows are added sequentially, at short time intervals. See the test-specific setup below.
メディアタイムライン：新しいメディアフローが短時間間隔で順次追加されます。以下のテスト固有の設定を参照してください。
Competing traffic:
競合するトラフィック：
Number of sources: zero (0)
ソース数：ゼロ（0）
Test-specific information: Table 5 defines the media timeline for both media types.
テスト固有の情報：表5両方のメディアタイプのメディアタイムラインを定義します。
+=========+============+============+==========+
| Flow ID | Media type | Start time | End time |
+=========+============+============+==========+
| 1 | Video | 0 s | 119 s |
+---------+------------+------------+----------+
| 2 | Video | 20 s | 119 s |
+---------+------------+------------+----------+
| 3 | Video | 40 s | 119 s |
+---------+------------+------------+----------+
| 4 | Audio | 0 s | 119 s |
+---------+------------+------------+----------+
| 5 | Audio | 20 s | 119 s |
+---------+------------+------------+----------+
| 6 | Audio | 40 s | 119 s |
+---------+------------+------------+----------+
Table 5: Media Timelines for Video and Audio Media Sources
表5：ビデオおよびオーディオメディアソースのメディアタイムライン
In this test case, multiple media flows share the bottleneck link, but the one-way propagation delay for each flow is different. For the sake of simplicity, it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows. While this appears to be a variant of test case 5.2 (Section 5.2), it focuses on the capacity-sharing aspect of the candidate algorithm under different RTTs.
このテストケースでは、複数のメディアフローがボトルネックリンクを共有しますが、各フローに対する一方向の伝播遅延は異なります。簡単にするために、ボトルネックリンク内に他の競合するトラフィックソースがなく、すべてのフローに収容するのに十分な容量があると仮定されます。これはテストケース5.2（5.2項）の変形であるように見えます（セクション5.2）、それは異なるRTTの下での候補アルゴリズムの容量共有の側面に焦点を合わせます。
Expected behavior: It is expected that the competing flows will converge to bit rates to accommodate all the flows with minimum possible latency and loss. The effectiveness of the algorithm depends on how fast and fairly the competing flows converge to their steady states irrespective of the RTT observed.
予想される行動：競合するフローは、可能な限り最小の待ち時間と損失ですべての流れを収容するためにビットレートに収束することが予想されます。アルゴリズムの有効性は、競合フローがどのようにして競合するかが、観察されたRTTに関係なく、定常状態にどのくらい速く収束するかによって異なります。
Evaluation metrics: As described in Section 4.1.
評価メトリクス：4.1節に記載されているように。
Testbed topology: Five (5) media sources S1..S5 are connected to their corresponding media sinks R1..R5. The media traffic is transported over the forward path, and the corresponding feedback/ control traffic is transported over the backward path. The topology is the same as in Section 5.4.
テストベッドトポロジー：5つのメディアソースS1..5は、対応するメディアシンクR1以_に接続されています。メディアトラフィックは順方向パスを介して転送され、対応するフィードバック/制御トラフィックは逆方向パスを介して転送されます。トポロジはセクション5.4と同じです。
Testbed attributes:
テスト属性：
Test duration: 300 s
テスト期間：300 S
Path characteristics:
パスの特性：
Reference bottleneck capacity: 4 Mbps
参照ボトルネック容量：4 Mbps
Path capacity ratio: 1.0
経路容量比：1.0
One-way propagation delay for each flow: 10 ms for S1-R1, 25 ms for S2-R2, 50 ms for S3-R3, 100 ms for S4-R4, and 150 ms S5-R5.
各流量に対する一方向伝搬遅延：S1~R1について、S2 - R2については25ms、S3 - R3について50ms、S4 - R4、および150msのS5 - R5の場合は50ms。
Application-related:
アプリケーション関連：
Media source:
メディアソース：
Media type: Video
メディアタイプ：ビデオ
Media direction: forward
メディアの方向：前方
Number of media sources: five (5)
メディアソース数：5（5）
Media timeline: New media flows are added sequentially, at short time intervals. See the test-specific setup below.
メディアタイムライン：新しいメディアフローが短時間間隔で順次追加されます。以下のテスト固有の設定を参照してください。
Media type: Audio
メディアタイプ：オーディオ
Media direction: forward
メディアの方向：前方
Number of media sources: five (5)
メディアソース数：5（5）
Media timeline: New media flows are added sequentially, at short time intervals. See the test-specific setup below.
メディアタイムライン：新しいメディアフローが短時間間隔で順次追加されます。以下のテスト固有の設定を参照してください。
Competing traffic:
競合するトラフィック：
Number of sources: zero (0)
ソース数：ゼロ（0）
Test-specific information: Table 6 defines the media timeline for both media types.
テスト固有の情報：表6は、両方のメディアタイプのメディアタイムラインを定義します。
+=========+============+============+==========+
| Flow ID | Media type | Start time | End time |
+=========+============+============+==========+
| 1 | Video | 0 s | 299 s |
+---------+------------+------------+----------+
| 2 | Video | 10 s | 299 s |
+---------+------------+------------+----------+
| 3 | Video | 20 s | 299 s |
+---------+------------+------------+----------+
| 4 | Video | 30 s | 299 s |
+---------+------------+------------+----------+
| 5 | Video | 40 s | 299 s |
+---------+------------+------------+----------+
| 6 | Audio | 0 s | 299 s |
+---------+------------+------------+----------+
| 7 | Audio | 10 s | 299 s |
+---------+------------+------------+----------+
| 8 | Audio | 20 s | 299 s |
+---------+------------+------------+----------+
| 9 | Audio | 30 s | 299 s |
+---------+------------+------------+----------+
| 10 | Audio | 40 s | 299 s |
+---------+------------+------------+----------+
Table 6: Media Timeline for Video and Audio Media Sources
表6：ビデオおよびオーディオメディアソースのメディアタイムライン
In this test case, one or more media flows share the bottleneck link with at least one long-lived TCP flow. Long-lived TCP flows download data throughout the session and are expected to have infinite amount of data to send and receive. This is a scenario where a multimedia application coexists with a large file download. The test case measures the adaptivity of the candidate algorithm to competing traffic. It addresses requirement 3 in Section 2 of [RFC8836].
このテストケースでは、1つ以上のメディアフローが少なくとも1つの長寿命のTCPフローとボトルネックリンクを共有します。長寿命のTCPフローはセッションを通してデータをダウンロードし、送受信する無限のデータを持つことが期待されています。これは、マルチメディアアプリケーションが大規模なファイルのダウンロードと共存するシナリオです。テストケースは、競合するトラフィックに対する候補アルゴリズムの適応性を測定します。[RFC8836]のセクション2の要件3に対処します。
Expected behavior: Depending on the convergence observed in test cases 5.1 and 5.2, the candidate algorithm may be able to avoid congestion collapse. In the worst case, the media stream will fall to the minimum media bit rate.
予想される行動：テストケース5.1と5.2で観察された収束に応じて、候補アルゴリズムは輻輳崩壊を避けることができます。最悪の場合、メディアストリームは最小メディアビットレートになります。
Evaluation metrics: Includes the following metrics in addition to those described in Section 4.1:
評価メトリクス：セクション4.1に記載されているものに加えて、以下のメトリックを含みます。
1. Flow level:
1. フローレベル：
a. TCP throughput
a. TCPスループット
b. Loss for the TCP flow
b. TCPフローのための損失
Testbed topology: One (1) media source S1 is connected to the corresponding media sink, R1. In addition, there is a long-lived TCP flow sharing the same bottleneck link. The media traffic is transported over the forward path, and the corresponding feedback/ control traffic is transported over the backward path. The TCP traffic goes over the forward path from S_tcp with acknowledgment packets going over the backward path from R_tcp.
テストベッドトポロジー：1つのメディアソースS1が対応するメディアシンクR1に接続されています。さらに、同じボトルネックリンクを共有する長寿命のTCPフローがあります。メディアトラフィックは順方向パスを介して転送され、対応するフィードバック/制御トラフィックは逆方向パスを介して転送されます。TCPトラフィックは、R_TCPからの逆方向パスを介して肯定応答パケットを介してS_TCPからの順方向パスを越えて行われます。
+--+ +--+
|S1|===== \ Forward --> / =====|R1|
+--+ \\ // +--+
\\ //
+-----+ +-----+
| A |---------------------------->| B |
| |<----------------------------| |
+-----+ +-----+
// <-- Backward \\
+-----+ // \\ +-----+
|S_tcp|=== / \ ===|R_tcp|
+-----+ +-----+
Figure 6: Testbed Topology for TCP vs Congestion-Controlled Media Flows
図6：TCP対輻輳制御メディアフローのためのテストベッドトポロジー
Testbed attributes:
テスト属性：
Test duration: 120 s
テスト期間：120 S.
Path characteristics:
パスの特性：
Reference bottleneck capacity: 2 Mbps
参照ボトルネック容量：2 Mbps
Path capacity ratio: 1.0
経路容量比：1.0
Bottleneck queue size: [300 ms, 1000 ms]
ボトルネックキューサイズ：[300ミリ秒、1000ミリ秒]
Application-related:
アプリケーション関連：
Media source:
メディアソース：
Media type: Video
メディアタイプ：ビデオ
Media direction: forward
メディアの方向：前方
Number of media sources: one (1)
メディアソース数：1（1）
Media timeline:
メディアタイムライン：
Start time: 5 s
開始時間：5 S
End time: 119 s
終了時間：119 S
Media type: Audio
メディアタイプ：オーディオ
Media direction: forward
メディアの方向：前方
Number of media sources: one (1)
メディアソース数：1（1）
Media timeline:
メディアタイムライン：
Start time: 5 s
開始時間：5 S
End time: 119 s
終了時間：119 S
Additionally, implementers are encouraged to run the experiment with multiple media sources.
さらに、実装者は複数のメディアソースで実験を実行することをお勧めします。
Competing traffic:
競合するトラフィック：
Number and types of sources: one (1) and long-lived TCP
ソースの数と種類：1つ（1）と長期的なTCP
Traffic direction: forward
交通方向：前方に
Congestion control: default TCP congestion control [RFC5681]. Implementers are also encouraged to run the experiment with alternative TCP congestion control algorithms.
輻輳制御：デフォルトのTCP輻輳制御[RFC5681]。実装者はまた、代替TCP輻輳制御アルゴリズムを用いて実験を実行することも奨励されている。
Traffic timeline:
トラフィックタイムライン：
Start time: 0 s
開始時間：0 S
End time: 119 s
終了時間：119 S
Test-specific information: none
テスト固有の情報：なし
In this test case, one or more congestion-controlled media flows share the bottleneck link with multiple short-lived TCP flows. Short-lived TCP flows resemble the on/off pattern observed in web traffic, wherein clients (for example, browsers) connect to a server and download a resource (typically a web page, few images, text files, etc.) using several TCP connections. This scenario shows the performance of a multimedia application when several browser windows are active. The test case measures the adaptivity of the candidate algorithm to competing web traffic, and it addresses requirement 1.E in Section 2 of [RFC8836].
このテストケースでは、1つ以上の輻輳制御メディアフローがボトルネックリンクを複数の短命のTCPフローと共有します。短命のTCPフローは、Webトラフィックで観察されたオン/オフパターンに似ています。ここで、クライアント（たとえば、ブラウザ）はサーバーに接続し、複数のTCPを使用してリソース（通常はWebページ、画像、テキストファイルなど）をダウンロードします。接続このシナリオは、いくつかのブラウザウィンドウがアクティブなときのマルチメディアアプリケーションのパフォーマンスを示しています。テストケースは、候補アルゴリズムの競合するWebトラフィックの適応性を測定し、[RFC8836]のセクション2の要件1.eに対処します。
Depending on the number of short TCP flows, the cross traffic either appears as a short burst flow or resembles a long-lived TCP flow. The intention of this test is to observe the impact of a short-term burst on the behavior of the candidate algorithm.
短いTCPフローの数に応じて、クロストラフィックは短いバーストフローとして表示されるか、長期間のTCPフローに似ています。このテストの意図は、候補アルゴリズムの挙動に及ぼす短期間のバーストの影響を観察することです。
Expected behavior: The candidate algorithm is expected to avoid flow starvation during the presence of short and bursty competing TCP flows, streaming at least at the minimum media bit rate. After competing TCP flows terminate, the media streams are expected to be robust enough to eventually recover to previous steady state behavior, and at the very least, avoid persistent starvation.
予想される行動：候補アルゴリズムは、少なくとも最小メディアビットレートでストリーミングされた短くてバーストの競合するTCPフローの存在中の流れの飢餓を回避すると予想されます。TCPフローを終了した後、メディアストリームは最終的に以前の定常状態の行動に回復するのに十分堅牢であると予想され、少なくとも持続的な飢餓を避けます。
Evaluation metrics: Includes the following metrics in addition to those described in Section 4.1:
評価メトリクス：セクション4.1に記載されているものに加えて、以下のメトリックを含みます。
1. Flow level:
1. フローレベル：
A. Variation in the sending rate of the TCP flow
A. TCPフローの送信速度の変動
B. TCP throughput
B. TCPスループット
Testbed topology: The topology described here is the same as the one described in Figure 6.
TESTBEDトポロジー：ここで説明されているトポロジは、図6に記載されているものと同じです。
Testbed attributes:
テスト属性：
Test duration: 300 s
テスト期間：300 S
Path characteristics:
パスの特性：
Reference bottleneck capacity: 2.0 Mbps
参照ボトルネック容量：2.0 Mbps
Path capacity ratio: 1.0
経路容量比：1.0
Application-related:
アプリケーション関連：
Media source:
メディアソース：
Media type: Video
メディアタイプ：ビデオ
Media direction: forward
メディアの方向：前方
Number of media sources: two (2)
メディアソース数：2（2）
Media timeline:
メディアタイムライン：
Start time: 5 s
開始時間：5 S
End time: 299 s
終了時間：299 S
Media type: Audio
メディアタイプ：オーディオ
Media direction: forward
メディアの方向：前方
Number of media sources: two (2)
メディアソース数：2（2）
Media timeline:
メディアタイムライン：
Start time: 5 s
開始時間：5 S
End time: 299 s
終了時間：299 S
Competing traffic:
競合するトラフィック：
Number and types of sources: ten (10), short-lived TCP flows.
ソースの数と種類：10（10）、短命のTCPフロー。
Traffic direction: forward
交通方向：前方に
Congestion algorithm: default TCP congestion control [RFC5681]. Implementers are also encouraged to run the experiment with an alternative TCP congestion control algorithm.
輻輳アルゴリズム：デフォルトのTCP輻輳制御[RFC5681]。実装者はまた、代替TCP輻輳制御アルゴリズムを用いて実験を実行することも奨励されている。
Traffic timeline: Each short TCP flow is modeled as a sequence of file downloads interleaved with idle periods. Not all short TCP flows start at the same time, two of them start in the ON state, while rest of the eight flows start in an OFF state. For a description of the short TCP flow model, see test-specific information below.
トラフィックタイムライン：各短いTCPフローは、アイドル期間でインターリーブされたファイルのダウンロードのシーケンスとしてモデル化されています。すべての短いTCPフローが同時に起動したわけではなく、2つの2つがオン状態で起動しますが、8つのフローの残りの部分はオフ状態で始まります。短いTCPフローモデルの説明については、以下のテスト固有の情報を参照してください。
Test-specific information:
テスト固有の情報：
Short TCP traffic model: The short TCP model to be used in this test is described in [RFC8868].
ショートTCPトラフィックモデル：このテストで使用される短いTCPモデルは[RFC8868]に記載されています。
In this test case, more than one real-time interactive media flow share the link bandwidth, and all flows reach to a steady state by utilizing the link capacity in an optimum way. At this stage, one of the media flows is paused for a moment. This event will result in more available bandwidth for the rest of the flows as they are on a shared link. When the paused media flow resumes, it no longer has the same bandwidth share on the link. It has to make its way through the other existing flows in the link to achieve a fair share of the link capacity. This test case is important specially for real-time interactive media, which consists of more than one media flows and can pause/resume media flows at any point of time during the session. This test case directly addresses requirement 5 in Section 2 of [RFC8836]. One can think of it as a variation of the test case defined in Section 5.4. However, it is different as the candidate algorithms can use different strategies to increase efficiency, for example, in terms of fairness, convergence time, oscillation reduction, etc., by capitalizing on the fact that they have previous information of the link.
このテストケースでは、複数のリアルタイムの対話型メディアフローがリンク帯域幅を共有し、すべてのフローは最適な方法でリンク容量を利用することによって定常状態に達します。この段階では、メディアフローの1つが一瞬一時停止されます。このイベントは、それらが共有リンク上にあるときに、残りのフローのためのより利用可能な帯域幅をもたらすでしょう。一時停止したメディアフローが再開されると、リンク上の同じ帯域幅を共有しなくなりました。リンク内の他の既存のフローを通過する必要があり、リンク容量の公正なシェアを達成する必要があります。このテストケースは、リアルタイムの対話型メディアのために特別に重要です。これは、複数のメディアフローからなる、セッション中の任意の時点でメディアフローを一時停止/再開できます。このテストケースは[RFC8836]のセクション2の要件5に直接取り組みます。セクション5.4で定義されているテストケースの変動として考えることができます。しかしながら、候補アルゴリズムが異なる戦略を使用して、例えば、リンクの以前の情報を持つという事実を利用することによって、効率を高めることができる。
Expected behavior: During the period where the third stream is paused, the two remaining flows are expected to increase their rates and reach the maximum media bit rate. When the third stream resumes, all three flows are expected to converge to the same original fair share of rates prior to the media pause/resume event.
予想される動作：3番目のストリームが一時停止されている間、2つの残りのフローはレートを増加させ、最大メディアビットレートに達すると予想されます。3番目のストリームが再開されると、3つのフローすべてがメディアの一時停止/再開イベントの前に同じ元のレートの公正な割合に収束すると予想されます。
Evaluation metrics: Includes the following metrics in addition to those described in Section 4.1:
評価メトリクス：セクション4.1に記載されているものに加えて、以下のメトリックを含みます。
1. Flow level:
1. フローレベル：
A. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations.
A.ビットレートとスループットのバリエーション。振動の周波数と大きさを主に観察します。
Testbed topology: Same as the test case defined in Section 5.4.
TESTBEDトポロジー：セクション5.4で定義されているテストケースと同じです。
Testbed attributes: The general description of the testbed parameters are the same as Section 5.4 with changes in the test-specific setup as below:
テストベッド属性：テストベッドパラメータの一般的な説明は、以下のようにテスト固有のセットアップの変更を伴うセクション5.4と同じです。
Other test-specific setup:
その他のテスト固有の設定：
Media flow timeline:
メディアフロータイムライン：
Flow ID: one (1)
フローID：1（1）
Start time: 0 s
開始時間：0 S
Flow duration: 119 s
流量期間：119 S
Pause time: not required
一時停止時間：必須ではありません
Resume time: not required
再開時間：必須ではありません
Media flow timeline:
メディアフロータイムライン：
Flow ID: two (2)
フローID：2（2）
Start time: 0 s
開始時間：0 S
Flow duration: 119 s
流量期間：119 S
Pause time: at 40 s
休止時間：40 S
Resume time: at 60 s
再開時間：60秒で
Media flow timeline:
メディアフロータイムライン：
Flow ID: three (3)
フローID：3（3）
Start time: 0 s
開始時間：0 S
Flow duration: 119 s
流量期間：119 S
Pause time: not required
一時停止時間：必須ではありません
Resume time: not required
再開時間：必須ではありません
It has been noticed that there are other interesting test cases besides the basic test cases listed above. In many aspects, these additional test cases can help further evaluation of the candidate algorithm. They are listed below.
上記の基本的なテストケース以外に、他に興味深いテストケースがあることが注目されています。多くの態様では、これらの追加のテストケースは候補アルゴリズムのさらなる評価を助けることができる。それらは以下のとおりです。
In this test case, media flows will have different priority levels. This is an extension of Section 5.4 where the same test is run with different priority levels imposed on each of the media flows. For example, the first flow (S1) is assigned a priority of 2, whereas the remaining two flows (S2 and S3) are assigned a priority of 1. The candidate algorithm must reflect the relative priorities assigned to each media flow. In this case, the first flow (S1) must arrive at a steady-state rate approximately twice that of the other two flows (S2 and S3).
このテストケースでは、メディアフローは異なる優先順位レベルを持ちます。これはセクション5.4の拡張です。ここで、同じテストが各メディアフローに課された異なる優先順位レベルで実行されます。例えば、第1のフロー（S1）には2の優先順位が割り当てられ、残りの2つのフロー（S2、S3）には1の優先度が割り当てられている。候補アルゴリズムは、各メディアフローに割り当てられた相対優先度を反映しなければならない。この場合、第1のフロー（S1）は、他の2つのフローの約2倍の定常レートに到着しなければならない（S2、S3）。
The candidate algorithm can use a coupled congestion control mechanism [RFC8699] or use a weighted priority scheduler for the bandwidth distribution according to the respective media flow priority or use.
候補アルゴリズムは、結合輻輳制御機構[RFC8699]を使用することも、それぞれのメディアフロー優先順位または使用に応じて帯域幅分布の重み付き優先スケジューラを使用することができる。
This test case requires running all the basic test cases with the availability of Explicit Congestion Notification (ECN) [RFC6679] feature enabled. The goal of this test is to exhibit that the candidate algorithms do not fail when ECN signals are available. With ECN signals enabled, the algorithms are expected to perform better than their delay-based variants.
このテストケースでは、明示的輻輳通知（ECN）[RFC6679]機能が有効になっているため、すべての基本テストケースを実行する必要があります。このテストの目的は、ECN信号が利用可能なときに候補アルゴリズムが失敗しないことを示すことです。ECN信号が有効になっていると、アルゴリズムは遅延ベースのバリエーションよりも優れていると予想されます。
In this test case, one congestion-controlled media flow, S1->R1, traverses a path with multiple bottlenecks. As illustrated in Figure 7, the first flow (S1->R1) competes with the second congestion-controlled media flow (S2->R2) over the link between A and B, which is close to the sender side. Again, that flow (S1->R1) competes with the third congestion-controlled media flow (S3->R3) over the link between C and D, which is close to the receiver side. The goal of this test is to ensure that the candidate algorithms work properly in the presence of multiple bottleneck links on the end-to-end path.
このテストケースでは、1つの輻輳制御メディアフローS1-> R1が複数のボトルネックを含むパスを横断します。図7に示すように、第1のフロー（S1-> R1）は、送信側に近いAとBの間のリンクを介して、第2の輻輳制御メディアフロー（S2-> R2）と競合する。やはり、その流れ（S1-> R1）は、受信機側に近いCとDとの間のリンクを介して第3の輻輳制御メディアフロー（S3-> R3）と競合する。このテストの目的は、エンドツーエンドパス上の複数のボトルネックリンクの存在下で候補アルゴリズムが正しく機能するようにすることです。
Expected behavior: The candidate algorithm is expected to achieve full utilization at both bottleneck links without starving any of the three congestion-controlled media flows and ensuring fair share of the available bandwidth at each bottleneck.
予想される動作：候補アルゴリズムは、3つの輻輳制御メディアフローを飢えず、各ボトルネックで利用可能な帯域幅の公正なシェアを確保することなく、ボトルネックリンクの両方で全利用を達成すると予想されます。
Forward ---->
+---+ +---+ +---+ +---+
|S2 | |R2 | |S3 | |R3 |
+---+ +---+ +---+ +---+
| | | |
| | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+
|S1 |======| A |------>| B |----->| C |---->| D |======|R1 |
+---+ | |<------| |<-----| |<----| | +---+
+-----+ +-----+ +-----+ +-----+
1st 2nd Bottleneck (A->B) Bottleneck (C->D)
第1回2番目のボトルネック（A-> B）ボトルネック（C→D）
<------ Backward
Figure 7: Testbed Topology for Multiple Bottlenecks
図7：複数のボトルネックのためのテストベッドトポロジー
Testbed topology: Three media sources S1, S2, and S3 are connected to respective destinations R1, R2, and R3. For all three flows, the media traffic is transported over the forward path, and the corresponding feedback/control traffic is transported over the backward path.
テストベッドトポロジー：3つのメディアソースS1、S2、S3は、それぞれの宛先R1、R2、R3に接続されています。3つのフローすべてについて、メディアトラフィックは順方向パスを介して転送され、対応するフィードバック/制御トラフィックは逆方向パスを介して転送されます。
Testbed attributes:
テスト属性：
Test duration: 300 s
テスト期間：300 S
Path characteristics:
パスの特性：
Reference bottleneck capacity: 2 Mbps
参照ボトルネック容量：2 Mbps
Path capacity ratio between A and B: 1.0
AとB：1.0の経路容量比
Path capacity ratio between B and C: 4.0
BとC：4.0の経路容量比
Path capacity ratio between C and D: 0.75
CとD：0.75の間の経路容量比
One-way propagation delay:
一方向伝搬遅延
Between S1 and R1: 100 ms
S1とR1：100さんの間
Between S2 and R2: 40 ms
S2とR2の間：40 ms
Between S3 and R3: 40 ms
S3とR3：40ミリ秒の間
Application-related:
アプリケーション関連：
Media source:
メディアソース：
Media type: Video
メディアタイプ：ビデオ
Media direction: Forward
メディアの方向：前方
Number of media sources: Three (3)
メディアソース数：3（3）
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 299 s
終了時間：299 S
Media type: Audio
メディアタイプ：オーディオ
Media direction: Forward
メディアの方向：前方
Number of media sources: Three (3)
メディアソース数：3（3）
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 299 s
終了時間：299 S
Competing traffic:
競合するトラフィック：
Number of sources: Zero (0)
ソース数：ゼロ（0）
Additional wireless network (both cellular network and Wi-Fi network) specific test cases are defined in [RFC8869].
追加の無線ネットワーク（セルラネットワークとWi-Fiネットワークの両方）固有のテストケースは[RFC8869]で定義されています。
The security considerations in Section 6 of [RFC8868] and the relevant congestion control algorithms apply. The principles for congestion control are described in [RFC2914], and in particular any new method must implement safeguards to avoid congestion collapse of the Internet.
[RFC8868]のセクション6のセキュリティ上の考慮事項と関連する輻輳制御アルゴリズムが適用されます。輻輳制御の原理は[RFC2914]に記載されており、特に新しい方法ではインターネットの輻輳崩壊を防ぐために保護措置を実装する必要があります。
The evaluation of the test cases are intended to be run in a controlled lab environment. Hence, the applications, simulators, and network nodes ought to be well-behaved and should not impact the desired results. Moreover, proper measures must be taken to avoid leaking nonresponsive traffic from unproven congestion avoidance techniques onto the open Internet.
テストケースの評価は、制御されたラボ環境で実行されることを意図しています。したがって、アプリケーション、シミュレータ、およびネットワークノードは、行儀が良くなるべきであり、所望の結果に影響を与えるべきではありません。さらに、開封されていない輻輳回避技術からオープンインターネットへの非応答性のトラフィックを漏らすのを避けるために適切な対策を講じる必要があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H.およびS.Casner、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<https：///www.rfc-編集者。ORG / INFO / RFC3551>。
[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, <https://www.rfc-editor.org/info/rfc3611>.
[RFC3611] Friedman、T.、Ed。、Caceres、R.、Ed。、およびA. Clark、Ed。、「RTP Control Protocol Extended Reports（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、<https://www.rfc-editor.org/info/rfc3611>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] OTT、J.、Wenger、S.、Sato、N.、Burmeister、C.、J.REY、「リアルタイムトランスポート制御プロトコルのための拡張RTPプロファイル（RTCP）ベースのフィードバック（RTP / AVPF）"、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC5506] Johansson、I.およびM. Westerlund、「サイズのリアルタイムトランスポートコントロールプロトコル（RTCP）のサポート：機会と結果」、RFC 5506、DOI 10.17487 / RFC5506、2009年4月、<HTTPS：// WWW.rfc-editor.org / info / rfc5506>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.およびE.Blanton、「TCP輻輳制御」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https：//www.rfc-editor.org/info/RFC5681>。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I。、Perkins、C.、O'Hanlon、P.、K. Carlberg、「UDP上のRTPのための明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC66792012年8月、<https://www.rfc-editor.org/info/rfc6679>。
[RFC8593] Zhu, X., Mena, S., and Z. Sarker, "Video Traffic Models for RTP Congestion Control Evaluations", RFC 8593, DOI 10.17487/RFC8593, May 2019, <https://www.rfc-editor.org/info/rfc8593>.
[RFC8593] Zhu、X.、Mena、S.、およびZ.Sarker、RFC 8593、DOI 10.17487 / RFC8593、2019年5月、<https：///www.rfc-編集者.ORG / INFO / RFC8593>。
[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control Requirements for Interactive Real-Time Media", RFC 8836, DOI 10.17487/RFC8836, January 2021, <https://www.rfc-editor.org/info/rfc8836>.
[RFC8836] Jesup、R.およびZ.Sarker、Ed。、「インタラクティブリアルタイムメディアの輻輳制御要件」、RFC 8836、DOI 10.17487 / RFC8836、2021年1月、<https://www.rfc-editor.org/ info / rfc8836>。
[RFC8868] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion Control for Interactive Real-Time Media", RFC 8868, DOI 10.17487/RFC8868, January 2021, <https://www.rfc-editor.org/info/rfc8868>.
[RFC8868] Singh、V.、OTT、J.、およびS. Holmer、「インタラクティブリアルタイムメディアのための輻輳制御の評価」、RFC 8868、DOI 10.17487 / RFC8868、<https：///www.rfc-editor.org/info/rfc8868>。
[RFC8869] Sarker, Z., Zhu, X., and J. Fu, "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", RFC 8869, DOI 10.17487/RFC8869, January 2021, <https://www.rfc-editor.org/info/rfc8869>.
[RFC8869] Sarker、Z.、Zhu、X、およびJ.FU、「無線ネットワーク上の対話型リアルタイムメディアの評価テストケース」、RFC 8869、DOI 10.17487 / RFC8869、2021年1月、<https：// www.rfc-editor.org / info / rfc8869>。
[HEVC-seq] HEVC, "Test Sequences", <http://www.netlab.tkk.fi/~varun/test_sequences/>.
[HEVC-SEQ] HEVC、「テストシーケンス」、<http://www.netlab.tkk.fi/~varun/test_sequences/>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914] Floyd、S.、「輻輳制御原理」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<https：//www.rfc-editor.org/info/rfc2914>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.
[RFC7567] Baker、F.、ED。G. FairHurst、Ed。、「アクティブキュー管理に関するIETF勧告」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<https：//www.rfc-editor.org/info/rfc7567>。
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.
[RFC8033] Pan、R.、Natarajan、P.、Baker、F.、およびG. White、 "比例積分コントローラ拡張（パイ）：バッファブロートの問題に対処するための軽量制御方式"、RFC 8033、DOI 10.17487 / RFC8033、2017年2月、<https：//www.rfc-editor.org/info/rfc8033>。
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm", RFC 8290, DOI 10.17487/RFC8290, January 2018, <https://www.rfc-editor.org/info/rfc8290>.
[RFC8290] Hoeiland-Joergensen、T.、McKenney、P.、Taht、D.、GetTys、J.、E.Dumazet、「フローキューコーデルパケットスケジューラとアクティブキュー管理アルゴリズム」、RFC 8290、DOI 10.17487 /RFC8290、2018年1月、<https：//www.rfc-editor.org/info/rfc8290>。
[RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, January 2020, <https://www.rfc-editor.org/info/rfc8699>.
[RFC8699]イスラム教、S、WELZL、M.およびS.Gjessing、「RTPメディアの結合輻輳制御」、RFC 8699、DOI 10.17487 / RFC8699、2020年1月、<https：//www.rfc-editor.org/ info / rfc8699>。
[xiph-seq] Xiph.org, "Video Test Media", <http://media.xiph.org/video/derf/>.
[XIPH-SEQ] Xiph.org、「ビデオテストメディア」、<http://media.xiph.org/video/derf/>。
Acknowledgments
謝辞
Much of this document is derived from previous work on congestion control at the IETF.
この文書の多くは、IETFの輻輳制御に関する前の作業から導き出されます。
The content and concepts within this document are a product of the discussion carried out within the Design Team.
この文書内の内容と概念は、デザインチーム内で行われた議論の産物です。
Authors' Addresses
著者の住所
Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 SE-164 83 Stockholm Sweden
Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 SE-164 83ストックホルムスウェーデン
Phone: +46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com
Varun Singh CALLSTATS I/O Oy Rauhankatu 11 C FI-00100 Helsinki Finland
Varun Singh Callstats I / O OY Rauhankatu 11 C FI-00100ヘルシンキフィンランド
Email: varun.singh@iki.fi
URI: http://www.callstats.io/
Xiaoqing Zhu Cisco Systems 12515 Research Blvd Austin, TX 78759 United States of America
Xiaoqing Zhu Cisco Systems 12515 Research Blvd Austin、TX 78759アメリカ合衆国
Email: xiaoqzhu@cisco.com
Michael A. Ramalho AcousticComms Consulting 6310 Watercrest Way Unit 203 Lakewood Ranch, FL 34202-5211 United States of America
Michael A. Ramalho AcousticCommsコンサルティング6310 Watercrest Wait 203 Lakewood Ranch、FL 34202-5211アメリカ合衆国
Phone: +1 732 832 9723
Email: mar42@cornell.edu
URI: http://ramalho.webhop.info/