[要約] RFC 8868は、インタラクティブなリアルタイムメディアのための輻輳制御を評価するための標準です。このRFCの目的は、異なる輻輳制御アルゴリズムの性能を比較し、最適な選択肢を提供することです。
Internet Engineering Task Force (IETF) V. Singh
Request for Comments: 8868 callstats.io
Category: Informational J. Ott
ISSN: 2070-1721 Technical University of Munich
S. Holmer
Google
January 2021
Evaluating Congestion Control for Interactive Real-Time Media
対話型リアルタイムメディアの輻輳制御の評価
Abstract
概要
The Real-Time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media.
リアルタイムトランスポートプロトコル（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/rfc8868.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8868で入手できます。
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. Metrics
3.1. RTP Log Format
4. List of Network Parameters
4.1. One-Way Propagation Delay
4.2. End-to-End Loss
4.3. Drop-Tail Router Queue Length
4.4. Loss Generation Model
4.5. Jitter Models
4.5.1. Random Bounded PDV (RBPDV)
4.5.2. Approximately Random Subject to No-Reordering Bounded
PDV (NR-BPDV)
4.5.3. Recommended Distribution
5. Traffic Models
5.1. TCP Traffic Model
5.2. RTP Video Model
5.3. Background UDP
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Contributors
Acknowledgments
Authors' Addresses
This memo describes the guidelines to help with evaluating new congestion control algorithms for interactive point-to-point real-time media. The requirements for the congestion control algorithm are outlined in [RFC8836]. This document builds upon previous work at the IETF: Specifying New Congestion Control Algorithms [RFC5033] and Metrics for the Evaluation of Congestion Control Algorithms [RFC5166].
このメモは、対話型ポイントツーポイントリアルタイムメディアのための新しい輻輳制御アルゴリズムの評価を支援するためのガイドラインについて説明しています。輻輳制御アルゴリズムの要件は[RFC8836]に概説されています。このドキュメントはIETFで前の作業に基づいて構築されています。
The guidelines proposed in the document are intended to help prevent a congestion collapse, to promote fair capacity usage, and to optimize the media flow's throughput. Furthermore, the proposed congestion control algorithms are expected to operate within the envelope of the circuit breakers defined in RFC 8083 [RFC8083].
この文書で提案されているガイドラインは、渋滞の崩壊を防ぎ、公正な容量の使用を促進し、メディアフローのスループットを最適化するのに役立ちます。さらに、提案された輻輳制御アルゴリズムは、RFC 8083 [RFC8083]で定義されている遮断器の包絡線内で動作すると予想されます。
This document only provides the broad set of network parameters and traffic models for evaluating a new congestion control algorithm. The minimal requirement for congestion control proposals is to produce or present results for the test scenarios described in [RFC8867] (Basic Test Cases), which also defines the specifics for the test cases. Additionally, proponents may produce evaluation results for the wireless test scenarios [RFC8869].
この文書は、新しい輻輳制御アルゴリズムを評価するための幅広いネットワークパラメータとトラフィックモデルのみを提供します。輻輳制御の提案の最小限の要件は、[RFC8867]（基本テストケース）に記載されているテストシナリオの結果を作成または表示することです。これもテストケースの詳細を定義します。さらに、推奨事項は、無線テストシナリオ[RFC8869]の評価結果を生み出すことがあります。
This document does not cover application-specific implications of congestion control algorithms and how those could be evaluated. Therefore, no quality metrics are defined for performance evaluation; quality metrics and the algorithms to infer those vary between media types. Metrics and algorithms to assess, e.g., the quality of experience, evolve continuously so that determining suitable choices is left for future work. However, there is consensus that each congestion control algorithm should be able to show that it is useful for interactive video by performing analysis using real codecs and video sequences and state-of-the-art quality metrics.
この文書は、輻輳制御アルゴリズムのアプリケーション固有の影響とそれらがどのように評価できるかをカバーしていません。したがって、性能評価には品質測定基準は定義されていません。メディアタイプの間で異なるものを推測するための品質測定基準とアルゴリズム。評価される測定基準とアルゴリズム、例えば経験の質は継続的に進化し、適切な選択を決定することが将来の作業に残されるように進化します。しかしながら、各輻輳制御アルゴリズムは、実際のコーデックおよびビデオシーケンスおよび最先端の品質メトリックを使用して分析を実行することによってインタラクティブビデオに役立つことを示すコンセンサスがある。
Beyond optimizing individual metrics, real-time applications may have further options to trade off performance, e.g., across multiple media; refer to the RMCAT requirements [RFC8836] document. Such trade-offs may be defined in the future.
個々のメトリックの最適化を超えて、リアルタイムアプリケーションは、例えば複数のメディアを越えて、パフォーマンスを軽減するためのさらなるオプションを持つことができます。RMCATの要件[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]Reced-Size RTCP [RFC5506]のサポートが適用されます。
This document specifies testing criteria for evaluating congestion control algorithms for RTP media flows. Proposed algorithms are to prove their performance by means of simulation and/or emulation experiments for all the cases described.
このドキュメントは、RTPメディアフローの輻輳制御アルゴリズムを評価するためのテスト基準を指定します。提案されたアルゴリズムは、記載されているすべての場合についてのシミュレーションおよび/またはエミュレーション実験によってそれらの性能を証明することである。
Each experiment is expected to log every incoming and outgoing packet (the RTP logging format is described in Section 3.1). The logging can be done inside the application or at the endpoints using PCAP (packet capture, e.g., tcpdump [tcpdump], Wireshark [wireshark]). The following metrics are calculated based on the information in the packet logs:
各実験は、各着信パケットと発信パケットごとに記録されると予想されます（RTPロギング形式はセクション3.1で説明されています）。ロギングは、PCAP（パケットキャプチャ、例えばTCPDUMP [TCPDUMP]、WIRESHARK [WIRESHARK]）を使用して、アプリケーションの内部またはエンドポイントで行うことができます。以下のメトリックは、パケットログ内の情報に基づいて計算されます。
1. Sending rate, receiver rate, goodput (measured at 200ms intervals)
1. 送付率、受信率、グッドプット（200ms間隔で測定）
2. Packets sent, packets received
2. 送信されたパケット、受信したパケット
3. Bytes sent, bytes received
3. 送信されたバイト、受信したバイト
4. Packet delay
4. パケット遅延
5. Packets lost, packets discarded (from the playout or de-jitter buffer)
5. 紛失したパケット、パケットが破棄された（プレイアウトまたはデジッタバッファから）
6. If using retransmission or FEC: post-repair loss
6. 再送信またはFECを使用する場合：修理後損失
7. Self-fairness and fairness with respect to cross traffic: Experiments testing a given congestion control proposal must report on relative ratios of the average throughput (measured at coarser time intervals) obtained by each RTP media stream. In the presence of background cross-traffic such as TCP, the report must also include the relative ratio between average throughput of RTP media streams and cross-traffic streams.
7. 交通交通渋滞に関する自己公平性と公平性：所与の輻輳制御の提案をテストする実験は、各RTPメディアストリームによって得られた平均スループット（より粗い時間間隔で測定される）の相対的な比率について報告しなければならない。TCPのような背景クロストラフィックの存在下では、レポートには、RTPメディアストリームの平均スループットとクロストラフィックストリームの間の相対比を含める必要があります。
During static periods of a test (i.e., when bottleneck bandwidth is constant and no arrival/departure of streams), these reports on relative ratios serve as an indicator of how fairly the RTP streams share bandwidth amongst themselves and against cross-traffic streams. The throughput measurement interval should be set at a few values (for example, at 1 s, 5 s, and 20 s) in order to measure fairness across different timescales.
テストの静的期間中（すなわち、ボトルネック帯域幅が一定でストリームの到着/到着/出発）の間、相対比率に関するこれらの報告は、RTPストリームがそれ自体と交差交通ストリームに対して帯域幅をどの程度共有するかの指標として機能する。スループット測定間隔は、異なるタイムスケールにわたる公平性を測定するために、いくつかの値（例えば、1秒、5秒、20秒）に設定する必要があります。
As a general guideline, the relative ratio between congestion-controlled RTP flows with the same priority level and similar path RTT should be bounded between 0.333 and 3. For example, see the test scenarios described in [RFC8867].
一般的なガイドラインとして、同じ優先度レベルと類似の経路RTTを有する輻輳制御RTPフロー間の相対比は、0.333から3の間の境界を囲む必要があります。たとえば、[RFC8867]に記載されているテストシナリオを参照してください。
8. Convergence time: The time taken to reach a stable rate at startup, after the available link capacity changes, or when new flows get added to the bottleneck link.
8. 収束時間：利用可能なリンク容量が変化した後、または新しいフローがボトルネックリンクに追加されたときに、起動時に安定したレートに達するのにかかる時間。
9. Instability or oscillation in the sending rate: The frequency or number of instances when the sending rate oscillates between an high watermark level and a low watermark level, or vice-versa in a defined time window. For example, the watermarks can be set at 4x interval: 500 Kbps, 2 Mbps, and a time window of 500 ms.
9. 送信速度の不安定性または発振：送信速度が高い透かしレベルと低透かしレベルとの間で発振するときの頻度または数は、定義されたタイムウィンドウで。たとえば、透かしは4倍間隔：500 kbps、2 Mbps、および500 msの時間窓に設定できます。
10. Bandwidth utilization, defined as the ratio of the instantaneous sending rate to the instantaneous bottleneck capacity: This metric is useful only when a congestion-controlled RTP flow is by itself or is competing with similar cross-traffic.
10. 瞬間的なボトルネック容量に対する瞬時送信レートの比として定義される帯域幅使用率：このメトリックは、輻輳制御されたRTPフローがそれ自体であるか、または同様のクロストラフィックと競合している場合にのみ有用です。
Note that the above metrics are all objective application-independent metrics. Refer to Section 3 of [netvc-testing] for objective metrics for evaluating codecs.
上記の測定基準は、すべての客観的なアプリケーションに依存しないメトリックです。コーデックを評価するための客観的メトリックの[NetVCテスト]のセクション3を参照してください。
From the logs, the statistical measures (min, max, mean, standard deviation, and variance) for the whole duration or any specific part of the session can be calculated. Also the metrics (sending rate, receiver rate, goodput, latency) can be visualized in graphs as variation over time; the measurements in the plot are at one-second intervals. Additionally, from the logs, it is possible to plot the histogram or cumulative distribution function (CDF) of packet delay.
ログから、期間全体またはセッションの特定の部分の統計的尺度（最小、最大、平均、標準偏差、および分散）を計算することができます。また、メトリック（送信速度、受信率、グッドアップ、待ち時間）は、時間の経過とともに、グラフで視覚化することができます。プロット内の測定は1秒間隔である。さらに、ログから、パケット遅延のヒストグラムまたは累積分布関数（CDF）をプロットすることが可能です。
Having a common log format simplifies running analyses across different measurement setups and comparing their results.
一般的なログ形式を持つと、さまざまな測定設定にまたがって、それらの結果を比較すると、実行中の分析が簡単になります。
Send or receive timestamp (Unix): <int>.<int> -- sec.usec decimal
RTP payload type <int> -- decimal
SSRC <int> -- hexadecimal
RTP sequence no <int> -- decimal
RTP timestamp <int> -- decimal
marker bit 0|1 -- character
Payload size <int> -- # bytes, decimal
Each line of the log file should be terminated with CRLF, CR, or LF characters. Empty lines are disregarded.
ログファイルの各行は、CRLF、CR、またはLF文字で終了する必要があります。空の行は無視されます。
If the congestion control implements retransmissions or Forward Error Correction (FEC), the evaluation should report both packet loss (before applying error resilience) and residual packet loss (after applying error resilience).
輻輳制御が再送信または前方誤り訂正（FEC）を実装する場合、評価は（エラー回復力を適用する前に）パケット損失（エラー回復力を適用する前）と（エラー回復力を適用した後）の両方を報告する必要があります。
These data should suffice to compute the media-encoding independent metrics described above. Use of a common log will allow simplified post-processing and analysis across different implementations.
これらのデータは、上記のメディアエンコード独立メトリックを計算するのに十分です。共通のログの使用は、異なる実装にわたる簡単な後処理と分析を可能にします。
The implementors are encouraged to choose evaluation settings from the following values initially:
実装者は、最初は以下の値から評価設定を選択することをお勧めします。
Experiments are expected to verify that the congestion control is able to work across a broad range of path characteristics, including challenging situations, for example, over transcontinental and/or satellite links. Tests thus account for the following different latencies:
実験は、輻輳制御が、例えばトランスコンティネチティブリンクおよび/または衛星リンクを超える困難な状況を含む、幅広い経路特性を横切って働くことができることを検証することが期待される。したがって、テストは次のような異なる待ち時間を説明します。
1. Very low latency: 0-1 ms
1. 非常に低い待ち時間：0~1
2. Low latency: 50 ms
2. 低レイテンシ：50ミリ秒
3. High latency: 150 ms
3. 高度な待ち時間：150ミリ秒
4. Extreme latency: 300 ms
4. 極端な待ち時間：300ミリ秒
Many paths in the Internet today are largely lossless; however, in scenarios featuring interference in wireless networks, sending to and receiving from remote regions, or high/fast mobility, media flows may exhibit substantial packet loss. This variety needs to be reflected appropriately by the tests.
今日のインターネット内の多くの道はほとんど無損失です。しかしながら、無線ネットワークにおける干渉を特徴とするシナリオでは、遠隔地域、または高/高速移動度から送受信することで、メディアフローはかなりのパケット損失を示してもよい。この品種はテストによって適切に反映される必要があります。
To model a wide range of lossy links, the experiments can choose one of the following loss rates; the fractional loss is the ratio of packets lost and packets sent:
広範囲の損失の多いリンクをモデル化するために、実験は以下の損失率のいずれかを選択することができます。分数損失は、紛失したパケットと送信されたパケットの比率です。
1. no loss: 0%
1.
2. 1%
2.
3. 5%
3.
4. 10%
4.
5. 20%
5.
Routers should be configured to use drop-tail queues in the experiments due to their (still) prevalent nature. Experimentation with Active Queue Management (AQM) schemes is encouraged but not mandatory.
ルータは、その（静止させた）一般的な性質のために実験でドロップテールキューを使用するように構成されるべきです。アクティブキュー管理（AQM）スキームを用いた実験は奨励されているが必須ではありません。
The router queue length is measured as the time taken to drain the FIFO queue. It has been noted in various discussions that the queue length in the currently deployed Internet varies significantly. While the core backbone network has very short queue length, the home gateways usually have larger queue length. Those various queue lengths can be categorized in the following way:
ルータキューの長さは、FIFOキューを排出するのにかかる時間として測定されます。現在展開されているインターネットのキュー長が大きく異なることはさまざまなディスカッションで注目されています。コアバックボーンネットワークには非常に短いキューの長さがありますが、ホームゲートウェイは通常、キューの長さが大きいです。これらのさまざまなキュー長は、次のように分類できます。
1. QoS-aware (or short): 70 ms
1. QoS対応（または短い）：70ミリ秒
2. Nominal: 300-500 ms
2. 公称：300-500ミリ秒
3. Buffer-bloated: 1000-2000 ms
3. バッファブルー化：1000~2000ミリ秒
Here the size of the queue is measured in bytes or packets. To convert the queue length measured in seconds to queue length in bytes:
ここでキューのサイズはバイトまたはパケットで測定されます。数秒で測定されたキュー長をバイト単位でキューの長さに変換するには
QueueSize (in bytes) = QueueSize (in sec) x Throughput (in bps)/8
キューイベント（バイト単位）=キューイベント（秒）Xスループット（BPS）/ 8
Many models for generating packet loss are available: some generate correlated packet losses, others generate independent packet losses. In addition, packet losses can also be extracted from packet traces. As a (simple) minimum loss model with minimal parameterization (i.e., the loss rate), independent random losses must be used in the evaluation.
パケット損失を生成するための多くのモデルが利用可能です：いくつかの相関パケット損失を生成すると、他のものは独立したパケット損失を生成します。さらに、パケット損失もパケットトレースから抽出することができます。最小限のパラメータ化（すなわち、損失率）を有する（単純な）最小損失モデルとして、独立したランダム損失を評価に使用する必要があります。
It is known that independent loss models may reflect reality poorly, and hence more sophisticated loss models could be considered. Suitable models for correlated losses include the Gilbert-Elliot model [gilbert-elliott] and models that generate losses by modeling a queue with its (different) drop behaviors.
独立した損失モデルが現実を不十分に反映している可能性があることが知られており、したがってより洗練された損失モデルを考慮することができます。相関損失のための適切なモデルには、Gilbert-Elliotモデル[Gilbert-Elliott]、およびそのキューをその（異なる）ドロップ行動でモデル化することによって損失を発生させるモデルが含まれます。
This section defines jitter models for the purposes of this document. When jitter is to be applied to both the congestion-controlled RTP flow and any competing flow (such as a TCP competing flow), the competing flow will use the jitter definition below that does not allow for reordering of packets on the competing flow (see NR-BPDV definition below).
このセクションでは、この文書の目的のためのジッタモデルを定義します。輻輳制御RTPフローと競合フローの両方（TCP競合フローなど）にジッタを適用する場合、競合したフローは競合フローでのパケットの並べ替えを許可しないJitter定義を使用します（参照）。NR-BPDV定義以下）
Jitter is an overloaded term in communications. It is typically used to refer to the variation of a metric (e.g., delay) with respect to some reference metric (e.g., average delay or minimum delay). For example in RFC 3550, jitter is computed as the smoothed difference in packet arrival times relative to their respective expected arrival times, which is particularly meaningful if the underlying packet delay variation was caused by a Gaussian random process.
ジッタは通信の過負荷の用語です。通常、いくつかの基準メトリック（例えば、平均遅延または最小遅延）に関して、メトリック（例えば、遅延）の変動を指すために使用される。例えば、RFC 3550において、ジッタは、それぞれの予想される到着時間に対するパケット到着時間の平滑化差として計算され、それは基礎となるパケット遅延変動がガウスランダムプロセスによって引き起こされた場合に特に意味がある。
Because jitter is an overloaded term, we use the term Packet Delay Variation (PDV) instead to describe the variation of delay of individual packets in the same sense as the IETF IP Performance Metrics (IPPM) working group has defined PDV in their documents (e.g., RFC 3393) and as the ITU-T SG16 has defined IP Packet Delay Variation (IPDV) in their documents (e.g., Y.1540).
Jitterは過負荷の用語であるため、IETF IPパフォーマンスメトリック（IPPM）ワーキンググループと同じ意味で個々のパケットの遅延の変動を文書内で定義したものと同じ意味で、パケット遅延バリエーション（PDV）という用語を使用します（例：、RFC3393）およびITU-T SG16は、それらの文書内のIPパケット遅延変動（IPDV）を定義している（例えば、Y.1540）。
Most PDV distributions in packet network systems are one-sided distributions, the measurement of which with a finite number of measurement samples results in one-sided histograms. In the usual packet network transport case, there is typically one packet that transited the network with the minimum delay; a (large) number of packets transit the network within some (smaller) positive variation from this minimum delay, and a (small) number of the packets transit the network with delays higher than the median or average transit time (these are outliers). Although infrequent, outliers can cause significant deleterious operation in adaptive systems and should be considered in rate adaptation designs for RTP congestion control.
パケットネットワークシステムにおけるほとんどのPDV分布は片面分布であり、その測定は有限数の測定サンプルで片面ヒストグラムをもたらす。通常のパケットネットワークトランスポートケースでは、通常、ネットワークを最小限の遅延で遷移させた1つのパケットがあります。この最小遅延からの数の正のバリエーション内でネットワークを（大きい）数のパケットを遷移させ、パケットの（小）数のパケットが中央値または平均通過時間（これらは異常値です）でネットワークを遷移させます。まれではないが、異常値は適応システムで有意な有害な動作を引き起こし、RTP輻輳制御のためのレート適応設計で考慮されるべきです。
In this section we define two different bounded PDV characteristics, 1) Random Bounded PDV and 2) Approximately Random Subject to No-Reordering Bounded PDV.
このセクションでは、2つの異なる境界付きPDV特性1）ランダム境界PDVと2）を定義します。
The former, 1) Random Bounded PDV, is presented for information only, while the latter, 2) Approximately Random Subject to No-Reordering Bounded PDV, must be used in the evaluation.
前者の1）ランダム境界PDVが情報のみ提示され、後者は、並べ替えられていないPDVを並べ替えられないPDVのほぼランダムに、評価に使用する必要があります。
The RBPDV probability distribution function (PDF) is specified to be of some mathematically describable function that includes some practical minimum and maximum discrete values suitable for testing. For example, the minimum value, x_min, might be specified as the minimum transit time packet, and the maximum value, x_max, might be defined to be two standard deviations higher than the mean.
RBPDV確率分布関数（PDF）は、テストに適したいくつかの実用的な最小値と最大の個別値を含むいくつかの数学的記述可能関数のものであるように指定されています。たとえば、最小値X_minは、最小トランジット時刻パケットとして指定されている可能性があり、最大値X_maxは、平均値よりも大きい2つの標準偏差であると定義されます。
Since we are typically interested in the distribution relative to the mean delay packet, we define the zero mean PDV sample, z(n), to be z(n) = x(n) - x_mean, where x(n) is a sample of the RBPDV random variable x and x_mean is the mean of x.
私たちは通常平均遅延パケットに対する分布に関心があるので、ゼロ平均PDVサンプル、Z（n）をz（n）= x（n） - x_meanに定義します。ここで、x（n）はサンプルですRBPDVランダム変数xとx_meanのxの平均値はxです。
We assume here that s(n) is the original source time of packet n and the post-jitter induced emission time, j(n), for packet n is:
ここでは、S（n）がパケットNの元のソース時間と、パケットNのジッタ後の誘導放射時間j（n）であると仮定する。
j(n) = {[z(n) + x_mean] + s(n)}.
It follows that the separation in the post-jitter time of packets n and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since the first term is always a positive quantity, we note that packet reordering at the receiver is possible whenever the second term is greater than the first. Said another way, whenever the difference in possible zero mean PDV sample delays (i.e., [x_max-x_min]) exceeds the inter-departure time of any two sent packets, we have the possibility of packet reordering.
したがって、パケットN、N 1のジッタ後の時間の間隔は{[S（n 1）-s（n）] - [z（n）-z（n 1）]}であることになる。最初の項は常に正の量であるため、2番目の用語が最初よりも大きいときはいつでも受信機でのパケット並べ替えが可能です。他の方法では、可能なゼロ平均PDVサンプル遅延（すなわち[X_MAX - X_MIN]）の差が2つの送信されたパケットの出発時間を超えているときはいつでも、パケット並べ替えの可能性を有する。
There are important use cases in real networks where packets can become reordered, such as in load-balancing topologies and during route changes. However, for the vast majority of cases, there is no packet reordering because most of the time packets follow the same path. Due to this, if a packet becomes overly delayed, the packets after it on that flow are also delayed. This is especially true for mobile wireless links where there are per-flow queues prior to base station scheduling. Owing to this important use case, we define another PDV profile similar to the above, but one that does not allow for reordering within a flow.
リアルネットワークでは、ロードバランシングトポロジなど、およびルートの変更中など、パケットが並べ替えることができる実際のネットワークがあります。ただし、大部分のケースの場合、ほとんどの時間パケットは同じパスに従うため、パケットの並べ替えはありません。このため、パケットが過度に遅れると、その流れの後のパケットも遅延されます。これは、基地局スケジューリングの前にフローごとのキューがあるモバイル無線リンクに特に当てはまります。この重要なユースケースのおかげで、上記と同様の別のPDVプロファイルを定義しますが、フロー内で並べ替えを許可しないもの。
4.5.2. Approximately Random Subject to No-Reordering Bounded PDV (NR-BPDV)
4.5.2. 並べ替えられたPDV（NR-BPDV）の並べ替えの対象
No Reordering BPDV, NR-BPDV, is defined similarly to the above with one important exception. Let serial(n) be defined as the serialization delay of packet n at the lowest bottleneck link rate (or other appropriate rate) in a given test. Then we produce all the post-jitter values for j(n) for n = 1, 2, ... N, where N is the length of the source sequence s to be offset. The exception can be stated as follows: We revisit all j(n) beginning from index n=2, and if j(n) is determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to be equal to [j(n-1)+serial(n-1)] and continue for all remaining n (i.e., n = 3, 4, .. N). This models the case where the packet n is sent immediately after packet (n-1) at the bottleneck link rate. Although this is generally the theoretical minimum in that it assumes that no other packets from other flows are in between packet n and n+1 at the bottleneck link, it is a reasonable assumption for per-flow queuing.
並べ替えBPDV、NR-BPDVは、1つの重要な例外と同じように定義されています。シリアル（n）を、特定のテストで最低ボトルネックリンクレート（または他の適切なレート）でパケットNのシリアル化遅延として定義することができます。次に、N = 1,2、... NのJ（N）のすべてのジッタ後の値を生成します。ここで、nはオフセットするソースシーケンスsの長さです。例外は次のように述べられています。Redefine j（n）は[j（n-1）シリアル（n-1）]と等しく、残りのすべてのn（つまり、n = 3,4 ,.n）を続けます。これにより、パケットNがボトルネックリンクレートでパケット（N - 1）の直後に送信される場合をモデル化する。これは一般に、他のフローからの他のパケットがボトルネックリンクでパケットNとN 1の間にあると仮定しているという点で、一般的な最小値ですが、フローごとのキューイングの合理的な仮定です。
We note that this assumption holds for some important exception cases, such as packets immediately following outliers. There are a multitude of software-controlled elements common on end-to-end Internet paths (such as firewalls, application-layer gateways, and other middleboxes) that stop processing packets while servicing other functions (e.g., garbage collection). Often these devices do not drop packets, but rather queue them for later processing and cause many of the outliers. Thus NR-BPDV models this particular use case (assuming serial(n+1) is defined appropriately for the device causing the outlier) and is believed to be important for adaptation development for congestion-controlled RTP streams.
この仮定は、外れ値の直後のパケットなど、いくつかの重要な例外ケースを保持していることに注意してください。エンドツーエンドのインターネットパス（ファイアウォール、アプリケーション層ゲートウェイ、およびその他のミドルボックスなど）には、他の機能（例えば、ガベージコレクション）を処理するのを停止する、多数のソフトウェア制御要素が共通の多数のソフトウェア制御要素があります。多くの場合、これらのデバイスはパケットをドロップしませんが、後で処理するためにそれらをキューに入れ、その外れ値の多くを引き起こします。したがって、NR - BPDVモデルはこの特定のユースケース（シリアル（N 1）が異常値を引き起こすデバイスに対して適切に定義され、輻輳制御RTPストリームの適応開発にとって重要であると考えられている。
Whether Random Bounded PDV or Approximately Random Subject to No-Reordering Bounded PDV, it is recommended that z(n) is distributed according to a truncated Gaussian for the above jitter models:
ランダムに制限されたPDVまたはほぼランダムな並べ替えられたPDVの場合、z（n）が上記のジッタモデルのための切り捨てられたガウスに従って分布することを推奨する。
z(n) ~ |max(min(N(0, std^(2)), N_STD * std), -N_STD * std)|
where N(0, std^(2)) is the Gaussian distribution with zero mean and std is standard deviation. Recommended values:
ここで、n（0、std ^（2））は、ゼロ平均値を持つガウス分布であり、STDは標準偏差です。推奨値：
std = 5 ms
N_STD = 3
Long-lived TCP flows will download data throughout the session and are expected to have infinite amount of data to send or receive. This roughly applies, for example, when downloading software distributions.
長期的なTCPフローはセッション全体を通してデータをダウンロードし、送受信するために無限のデータを持つことが期待されます。これは、例えばソフトウェアディストリビューションをダウンロードするときに大まかに当てはまる。
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, i.e., some start in the ON state while others start in the OFF state.
各短いTCPフローは、アイドル期間でインターリーブされたファイルのダウンロードのシーケンスとしてモデル化されています。すべての短いTCPフローが同時に開始されるわけではない、すなわちON状態で起動しても、OFF状態で起動します。
The short TCP flows can be modeled as follows: 30 connections start simultaneously fetching small (30-50 KB) amounts of data, evenly distributed. This covers the case where the short TCP flows are fetching web page resources rather than video files.
短いTCPフローは次のようにモデル化できます.30接続は、小（30~50kb）のデータを同時に取り込み、均等に分散されます。これにより、短いTCPフローがビデオファイルではなくWebページリソースを取得している場合について説明します。
The idle period between bursts of starting a group of TCP flows is typically derived from an exponential distribution with the mean value of 10 seconds.
TCPフローのグループを開始するバースト間のアイドル期間は、通常、10秒の平均値を持つ指数関数分布から導き出されます。
| These values were picked based on the data available at
| <https://httparchive.org/reports/state-of-the-
| web?start=2015_10_01&end=2015_11_01&view=list> as of October
| 2015.
Many different TCP congestion control schemes are deployed today. Therefore, experimentation with a range of different schemes, especially including CUBIC [RFC8312], is encouraged. Experiments must document in detail which congestion control schemes they tested against and which parameters were used.
さまざまなTCP輻輳制御方式が今日展開されています。したがって、特に立方体[RFC8312]を含む、さまざまなスキームの範囲の実験が推奨されています。実験は、それらが試験し、どのパラメータを使用したのかを詳細に文書化しなければならない。
[RFC8593] describes two types of video traffic models for evaluating candidate algorithms for RTP congestion control. The first model statistically characterizes the behavior of a video encoder, whereas the second model uses video traces.
[RFC8593] RTP輻輳制御の候補アルゴリズムを評価するための2種類のビデオトラフィックモデルを説明しています。最初のモデルはビデオエンコーダの動作を統計的に特徴付けますが、2番目のモデルはビデオトレースを使用します。
Sample video test sequences are available at [xiph-seq]. The following two video streams are the recommended minimum for testing: Foreman (CIF sequence) and FourPeople (720p); both come as raw video data to be encoded dynamically. As these video sequences are short (300 and 600 frames, respectively), they shall be stitched together repeatedly until the desired length is reached.
サンプルビデオテストシーケンスは[XIPH-SEQ]で入手できます。次の2つのビデオストリームはテストのための最小値を推奨します：職長（CIFシーケンス）とFour People（720p）;どちらも動的にエンコードされるために生のビデオデータとして来ます。これらのビデオシーケンスが短い（それぞれ300フレームと600フレーム）、それらは所望の長さに達するまで繰り返しステッチされるものとする。
Background UDP flow is modeled as a constant bit rate (CBR) flow. It will download data at a particular CBR for the complete session, or will change to particular CBR at predefined intervals. The inter-packet interval is calculated based on the CBR and the packet size (typically set to the path MTU size, the default value can be 1500 bytes).
バックグラウンドUDPフローは、一定ビットレート（CBR）フローとしてモデル化されています。それは完全なセッションのために特定のCBRでデータをダウンロードするか、または事前定義された間隔で特定のCBRに変更されます。パケット間間隔は、CBRとパケットサイズ（通常はパスMTUサイズに設定されているため、デフォルト値は1500バイト）に基づいて計算されます。
Note that new transport protocols such as QUIC may use UDP; however, due to their congestion control algorithms, they will exhibit behavior conceptually similar in nature to TCP flows above and can thus be subsumed by the above, including the division into short-lived and long-lived flows. As QUIC evolves independently of TCP congestion control algorithms, its future congestion control should be considered as competing traffic as appropriate.
QUICなどの新しいトランスポートプロトコルはUDPを使用することがあります。しかしながら、それらの輻輳制御アルゴリズムのために、それらは上記のTCPフローに対して本質的に概念的に類似している行動を示し、したがって、短寿命および長寿命の流れへの分割を含めて上記によって課すことができる。QUICがTCP輻輳制御アルゴリズムとは無関係に進化するにつれて、その将来の輻輳制御は必要に応じて競合するトラフィックと見なされるべきです。
This document specifies evaluation criteria and parameters for assessing and comparing the performance of congestion control protocols and algorithms for real-time communication. This memo itself is thus not subject to security considerations but the protocols and algorithms evaluated may be. In particular, successful operation under all tests defined in this document may suffice for a comparative evaluation but must not be interpreted that the protocol is free of risks when deployed on the Internet as briefly described in the following by example.
このドキュメントは、輻輳制御プロトコルの性能とリアルタイム通信のためのアルゴリズムの評価と比較のための評価基準とパラメータを指定します。したがって、このメモ自体はセキュリティ上の考慮の対象とはならないが、評価されたプロトコルおよびアルゴリズムはあるかもしれない。特に、この文書で定義されているすべてのテストの下での成功した操作は、比較評価に十分ですが、次のように簡単に説明したようにプロトコルにはリスクがないと解釈されてはなりません。
Such evaluations are expected to be carried out in controlled environments for limited numbers of parallel flows. As such, these evaluations are by definition limited and will not be able to systematically consider possible interactions or very large groups of communicating nodes under all possible circumstances, so that careful protocol design is advised to avoid incidentally contributing traffic that could lead to unstable networks, e.g., (local) congestion collapse.
そのような評価は、限られた数の並列フローについて制御された環境で実行されると予想される。このように、これらの評価は定義限定であり、すべての可能な状況下で可能な対話または非常に大きなグループの通信ノードのグループを体系的に検討することはできません。例えば、（局所）輻輳崩壊。
This specification focuses on assessing the regular operation of the protocols and algorithms under consideration. It does not suggest checks against malicious use of the protocols -- by the sender, the receiver, or intermediate parties, e.g., through faked, dropped, replicated, or modified congestion signals. It is up to the protocol specifications themselves to ensure that authenticity, integrity, and/or plausibility of received signals are checked, and the appropriate actions (or non-actions) are taken.
この仕様は、検討中のプロトコルとアルゴリズムの定期的な動作を評価することに焦点を当てています。それは、送信者、受信機、または中間党、例えば、偽の、落とし、複製された、または修正された輻輳信号によって、プロトコルの悪意のある使用に対するチェックを示唆していません。受信信号の信頼性、整合性、および/または妥当性が確認され、適切な行動（または非アクション）が取られるようにするのは、プロトコル仕様自体の推定です。
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>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C、V.Singh、 "マルチメディア輻輳制御：ユニキャストRTPセッションのためのサーキットブレーカー"、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<https：//www.rfc-editor.org/info/ RFC8083>。
[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>。
[gilbert-elliott] Hasslinger, G. and O. Hohlfeld, "The Gilbert-Elliott Model for Packet Loss in Real Time Services on the Internet", 14th GI/ITG Conference - Measurement, Modelling and Evalutation [sic] of Computer and Communication Systems, March 2008, <https://ieeexplore.ieee.org/document/5755057>.
[Gilbert-Elliott] Hasslinger、G.およびO.Hohlfeld、「インターネット上のリアルタイムサービスにおけるパケット損失のためのGilbert-Elliottモデル」、14社/ ITG会議 - 計測、モデリング、評価[SIC]のコンピュータとコミュニケーションシステム、2008年3月、<https：//ieeexplore.ieee.org/document/5755057>。
[netvc-testing] Daede, T., Norkin, A., and I. Brailovskiy, "Video Codec Testing and Quality Measurement", Work in Progress, Internet-Draft, draft-ietf-netvc-testing-09, 31 January 2020, <https://tools.ietf.org/html/draft-ietf-netvc-testing-09>.
[NETVCテスト] Daede、T.、Norkin、A.、I. Brailovskiy、「ビデオコーデックテストと品質測定」、進行中の作業、インターネットドラフト、ドラフト-IETF-NETVCテスト-09,2020、<https://tools.ietf.org/html/draft-ietf-netvc-testing-09>。
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.
[RFC5033] Floyd、S.およびM. Allman、「新しい輻輳制御アルゴリズムの指定」、BCP 133、RFC 5033、DOI 10.17487 / RFC5033、2007年8月、<https：//www.rfc-editor.org/info/rfc5033>。
[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March 2008, <https://www.rfc-editor.org/info/rfc5166>.
[RFC5166] Floyd、S.、ED。、「輻輳制御メカニズムの評価のための測定基準」、RFC 5166、DOI 10.17487 / RFC5166、2008年3月、<https：//www.rfc-editor.org/info/rfc5166>。
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.
[RFC8312] Rhee、I.、Xu、L.、HA、S・、Zimmermann、A.、Heghert、L.、およびR.ScheffeNgger、RFC 8312、DOI 10.17487 / RFC83122018年2月、<https：//www.rfc-editor.org/info/rfc8312>。
[RFC8867] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating Congestion Control for Interactive Real-Time Media", RFC 8867, DOI 10.17487/RFC8867, January 2021, <https://www.rfc-editor.org/info/rfc8867>.
[RFC8867] Sarker、Z.、Singh、V.、Zhu、X.、およびM. Ramalho、「インタラクティブリアルタイムメディアの輻輳制御を評価するためのテストケース」、RFC 8867、DOI 10.17487 / RFC8867、2021年1月、<https://www.rfc-editor.org/info/rfc8867>。
[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>。
[tcpdump] "Homepage of tcpdump and libpcap", <https://www.tcpdump.org/index.html>.
[TCPDUMP] "TCPDUMPとlibpcapのホームページ"、<https://www.tcpdump.org/index.html>。
[wireshark] "Homepage of Wireshark", <https://www.wireshark.org>.
[Wireshark]「Wiresharkのホームページ」、<https：//www.wireshark.org>。
[xiph-seq] Daede, T., "Video Test Media Set", <https://media.xiph.org/video/derf/>.
[XIPH-SEQ] DAEDE、T.、「ビデオテストメディアセット」、<https://media.xiph.org/video/derf/>。
Contributors
貢献者
The content and concepts within this document are a product of the discussion carried out in the Design Team.
この文書内の内容と概念は、デザインチームで行われた議論の産物です。
Michael Ramalho provided the text for the jitter models (Section 4.5).
Michael Ramalhoはジッタモデルのテキストを提供しました（セクション4.5）。
Acknowledgments
謝辞
Much of this document is derived from previous work on congestion control at the IETF.
この文書の多くは、IETFの輻輳制御に関する前の作業から導き出されます。
The authors would like to thank Harald Alvestrand, Anna Brunstrom, Luca De Cicco, Wesley Eddy, Lars Eggert, Kevin Gross, Vinayak Hegde, Randell Jesup, Mirja Kühlewind, Karen Nielsen, Piers O'Hanlon, Colin Perkins, Michael Ramalho, Zaheduzzaman Sarker, Timothy B. Terriberry, Michael Welzl, Mo Zanaty, and Xiaoqing Zhu for providing valuable feedback on draft versions of this document. Additionally, thanks to the participants of the Design Team for their comments and discussion related to the evaluation criteria.
著者らは、Harald Alvestrand、Anna Brunstrom、Luca De Cicco、Wesley Eddy、Lars Egger、Lars Egger、Lars Egger、vinayak hegde、ヴィナヤックヘッツ、MirjaKühlewind、Karen Nielsen、Colin Perkins、Michael Ramalho、Zaheduzzaman Sarker、Timothy B. Treiberry、Michael Welzl、Mo Zanaty、およびXiaoqing Zhuこの文書のドラフトバージョンに関する貴重なフィードバックを提供します。さらに、デザインチームの参加者のおかげで、その評価基準に関連したコメントや議論。
Authors' Addresses
著者の住所
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: https://www.callstats.io/
Jörg Ott Technical University of Munich Department of Informatics Chair of Connected Mobility Boltzmannstrasse 3 85748 Garching Germany
JörgOttミュンヘン学科大学コネクションモビリティボルツマンストラスス385748ガーチドイツ
Email: ott@in.tum.de
Stefan Holmer Google Kungsbron 2 SE-11122 Stockholm Sweden
Stefan Holmer Google Kungsbron 2 SE-11122ストックホルムスウェーデン
Email: holmer@google.com