[要約] RFC 8836は、インタラクティブなリアルタイムメディアのための輻輳制御要件に関する規格です。このRFCの目的は、リアルタイムメディア通信における輻輳制御の重要性を強調し、適切な要件を定義することです。
Internet Engineering Task Force (IETF) R. Jesup
Request for Comments: 8836 Mozilla
Category: Informational Z. Sarker, Ed.
ISSN: 2070-1721 Ericsson AB
January 2021
Congestion Control Requirements for Interactive Real-Time Media
対話型リアルタイムメディアの輻輳制御要件
Abstract
概要
Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.
公正な使い方を促進し、輻輳崩壊を防ぐために、インターネット全体に輸送されたすべてのデータに輻輳制御が必要です。低遅延の半信頼性のあるデータ配信を必要とする対話型のポイントツーポイントリアルタイムマルチメディアの要件は、FTPやWebページのようなバースト転送のようなバルク転送の要件とは異なります。インターネット上でのRTPベースのリアルタイムメディアトラフィックの量が増えるため（例えば、Webリアルタイム通信（WEBRTC）の導入により）、この種のトラフィックが輻輳制御されていることを確認することが特に重要です。
This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique.
この文書では、この目的のための適切さを把握するために、他の輻輳制御メカニズムを評価するために使用できる一連の要件、特にリアルタイムのメディア輻輳回避技術のための一連の可能な要件を提供することが記載されています。
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/rfc8836.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8836で取得できます。
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
1.1. Requirements Language
2. Requirements
3. Deficiencies of Existing Mechanisms
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
Most of today's TCP congestion control schemes were developed with a focus on a use of the Internet for reliable bulk transfer of non-time-critical data, such as transfer of large files. They have also been used successfully to govern the reliable transfer of smaller chunks of data in as short a time as possible, such as when fetching web pages.
今日のTCP輻輳制御方式のほとんどは、大規模ファイルの転送など、無派生間のデータの信頼性の高いバルク転送のためにインターネットの使用に焦点を当てて開発されました。また、Webページを取得するときなど、できるだけ短いデータの短時間で、より短い時間内により短い時間でデータの信頼性の高い転送を支配していました。
These algorithms have also been used for transfer of media streams that are viewed in a non-interactive manner, such as "streaming" video, where having the data ready when the viewer wants it is important, but the exact timing of the delivery is not.
これらのアルゴリズムはまた、「ストリーミング」ビデオなどの非対話的な方法で表示されているメディアストリームの転送に使用されています。ビューアがそれが重要であるときにデータを準備しているが、配信の正確なタイミングはそうではない。
When handling real-time interactive media, the requirements are different. One needs to provide the data continuously, within a very limited time window (no more delay than hundreds of milliseconds end-to-end). In addition, the sources of data may be able to adapt the amount of data that needs sending within fairly wide margins, but they can be rate limited by the application -- even not always having data to send. They may tolerate some amount of packet loss, but since the data is generated in real time, sending "future" data is impossible, and since it's consumed in real time, data delivered late is commonly useless.
リアルタイムの対話型メディアを処理するとき、要件は異なります。一つは、非常に限られた時間窓内で、データを継続的に提供する必要があります（数百ミリ秒のエンドツーエンドの遅延はありません）。さらに、データのソースは、かなり広い余白の中で送信する必要があるデータ量を適応させることができますが、アプリケーションによってレート制限されている可能性があります。それらはある程度のパケット損失を許容するかもしれませんが、データはリアルタイムで生成され、 "Future"データを送信することは不可能です。
While the requirements for real-time interactive media differ from the requirements for the other flow types, these other flow types will be present in the network. The congestion control algorithm for real-time interactive media must work properly when these other flow types are present as cross traffic on the network.
リアルタイム対話型メディアの要件は他のフロータイプの要件とは異なるが、これらの他のフロータイプはネットワーク内に存在するであろう。リアルタイム対話型メディアのための輻輳制御アルゴリズムは、これらの他のフロータイプがネットワーク上のクロストラフィックとして存在するときに正しく機能する必要があります。
One particular protocol portfolio being developed for this use case is WebRTC [RFC8825], where one envisions sending multiple flows using the Real-time Transport Protocol (RTP) [RFC3550] between two peers, in conjunction with data flows, all at the same time, without having special arrangements with the intervening service providers. As RTP does not provide any congestion control mechanism, a set of circuit breakers, such as those described in [RFC8083], are required to protect the network from excessive congestion caused by non-congestion-controlled flows. When the real-time interactive media is congestion controlled, it is recommended that the congestion control mechanism operate within the constraints defined by these circuit breakers when a circuit breaker is present and that it should not cause congestion collapse when a circuit breaker is not implemented.
このユースケースで開発されている特定のプロトコルポートフォリオは、WEBRTC [RFC8825]で、データフローと組み合わせて、2つのピア間のリアルタイムトランスポートプロトコル（RFC3550]を使用して複数のフローを送信します。、介入サービスプロバイダーと特別な手配をすることなく。RTPが輻輳制御メカニズムを提供していないため、[RFC8083]に記載されているような回路ブレーカーのセットは、非輻輳制御フローによって引き起こされる過度の輻輳からネットワークを保護するために必要です。リアルタイム対話型メディアが輻輳制御されると、回路ブレーカが存在するときにこれらの回路ブレーカによって定義された制約内で輻輳制御メカニズムが動作することをお勧めします。
Given that this use case is the focus of this document, use cases involving non-interactive media such as video streaming and those using multicast/broadcast-type technologies, are out of scope.
このユースケースがこの文書の焦点であることを考えると、ビデオストリーミングなどの非対話型メディアとマルチキャスト/ブロードキャストタイプのテクノロジを使用するものは範囲外です。
The terminology defined in [RFC8825] is used in this memo.
このメモには[RFC8825]で定義されている用語が使用されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、BCP 14 [RFC2119]に記載されているように解釈されること。
1. The congestion control algorithm MUST attempt to provide as-low-as-possible-delay transit for interactive real-time traffic while still providing a useful amount of bandwidth. There may be lower limits on the amount of bandwidth that is useful, but this is largely application specific, and the application may be able to modify or remove flows in order to allow some useful flows to get enough bandwidth. For example, although there might not be enough bandwidth for low-latency video+audio, there could be enough for audio only.
1. 輻輳制御アルゴリズムは、依然として有用な量の帯域幅を提供しながら、対話型リアルタイムトラフィックのための遅延遅延トランストランジットを実行しようとしている必要があります。有用な帯域幅の量にはより低い制限があるかもしれませんが、これは主にアプリケーション固有であり、アプリケーションはいくつかの便利な流れを十分に帯域幅にすることを可能にするためにフローを変更または除去することができるかもしれません。たとえば、低遅延ビデオオーディオに十分な帯域幅がない可能性がありますが、オーディオのみが十分である可能性があります。
a. Jitter (variation in the bitrate over short timescales) is also relevant, though moderate amounts of jitter will be absorbed by jitter buffers. Transit delay should be considered to track the short-term maximums of delay, including jitter.
a. 中程度の量のジッタはジッタバッファによって吸収されますが、ジッタ（短いタイムスケールのバリエーション）も関連性があります。トランジット遅延は、ジッタを含む短期間の遅延最大遅延を追跡するように考慮されるべきです。
b. The algorithm should provide this as-low-as-possible-delay transit and minimize self-induced latency even when faced with intermediate bottlenecks and competing flows. Competing flows may limit what's possible to achieve.
b. このアルゴリズムは、中間のボトルネックと競合フローに直面しても、これを可能な限り低遅延遅延輸送と最小限に抑えるべきです。競合するフローは、達成することが可能なものを制限するかもしれません。
c. The algorithm should be resilient to the effects of events, such as routing changes, which may alter or remove bottlenecks or change the bandwidth available, especially if there is a reduction in available bandwidth or increase in observed delay. It is expected that the mechanism reacts quickly to such events to avoid delay buildup. In the context of this memo, a "quick" reaction is on the order of a few RTTs, subject to the constraints of the media codec, but is likely within a second. Reaction on the next RTT is explicitly not required, since many codecs cannot adapt their sending rate that quickly, but at the same time a response cannot be arbitrarily delayed.
c. アルゴリズムは、ボトルネックを変更または削除することができます。遅延の蓄積を回避するためにそのメカニズムがそのようなイベントに迅速に反応することが予想されます。このメモの文脈において、メディアコーデックの制約に従って、「迅速な」反応は数RTTのオーダーであるが、2秒以内になる可能性が高い。多くのコーデックが迅速にそれらの送信レートを適応させることができないので、次のRTTの反応は明示的に必要とされないが、応答を任意に遅らせることができない。
d. The algorithm should react quickly to handle both local and remote interface changes (e.g., WLAN to 3G data) that may radically change the bandwidth available or bottlenecks, especially if there is a reduction in available bandwidth or an increase in bottleneck delay. It is assumed that an interface change can generate a notification to the algorithm.
d. 特に利用可能な帯域幅の減少やボトルネック遅延の減少が遅い場合、アルゴリズムは迅速に対極とリモートのインタフェースの変化（例えば、WLANから3Gデータ）を処理する必要があります。インターフェースの変更はアルゴリズムへの通知を生成することができると仮定される。
e. The real-time interactive media applications can be rate limited. This means the offered loads can be less than the available bandwidth at any given moment and may vary dramatically over time, including dropping to no load and then resuming a high load, such as in a mute/unmute operation. Hence, the algorithm must be designed to handle such behavior from a media source or application. Note that the reaction time between a change in the bandwidth available from the algorithm and a change in the offered load is variable, and it may be different when increasing versus decreasing.
e. リアルタイム対話型メディアアプリケーションはレート制限されています。これは、提供された負荷が任意の瞬間に利用可能な帯域幅よりも小さくなる可能性があり、無負荷を落として、ミュート/未満の操作などの高負荷を再開することを含む、時間の経過とともに劇的に変化し得る。したがって、アルゴリズムは、メディアソースまたはアプリケーションからそのような動作を処理するように設計されなければなりません。なお、アルゴリズムから入手可能な帯域幅の変化とオファリング負荷の変化との間の反応時間は可変であり、減少する値が低下すると異なる場合がある。
f. The algorithm is required to avoid building up queues when competing with short-term bursts of traffic (for example, traffic generated by web browsing), which can quickly saturate a local-bottleneck router or link but clear quickly. The algorithm should also react quickly to regain its previous share of the bandwidth when the local bottleneck or link is cleared.
f. このアルゴリズムは、短期間のトラフィック（Webブラウジングによって生成されたトラフィックなど）と競合するときのキューの構築を避けるために必要です。このアルゴリズムはまた、ローカルのボトルネックまたはリンクがクリアされたときに、帯域幅の以前の共有を取り戻すために迅速に反応する必要があります。
g. Similarly, periodic bursty flows such as MPEG DASH [MPEG_DASH] or proprietary media streaming algorithms may compete in bursts with the algorithm and may not be adaptive within a burst. They are often layered on top of TCP but use TCP in a bursty manner that can interact poorly with competing flows during the bursts. The algorithm must not increase the already existing delay buildup during those bursts. Note that this competing traffic may be on a shared access link, or the traffic burst may cause a shift in the location of the bottleneck for the duration of the burst.
g. 同様に、MPEGダッシュ[MPEG_DASH]または独自のメディアストリーミングアルゴリズムなどの周期的なバーストフローは、アルゴリズムを用いてバーストで競合する可能性があり、バースト内で適応的ではない可能性がある。それらはしばしばTCPの上に層状化されますが、バーストの間に競合する流れで不十分に相互作用することができるバーストの方法でTCPを使用します。アルゴリズムは、それらのバースト中に既存の遅延ビルドアップを増やしてはいけません。この競合するトラフィックは、共有アクセスリンク上にあり、またはトラフィックバーストがバーストの間ボトルネックの位置にシフトを引き起こす可能性があることに注意してください。
2. The algorithm MUST be fair to other flows, both real-time flows (such as other instances of itself) and TCP flows, both long-lived flows and bursts such as the traffic generated by a typical web-browsing session. Note that "fair" is a rather hard-to-define term. It SHOULD be fair with itself, giving a fair share of the bandwidth to multiple flows with similar RTTs, and if possible to multiple flows with different RTTs.
2. アルゴリズムは他のフローに公平でなければなりません（他の自外のインスタランスなど）、TCPフローの両方が、典型的なWebブラウジングセッションによって生成されたトラフィックなどの長時間のフローとバーストの両方です。「公正」はかなり定義した用語です。それ自体で公正で、帯域幅の公正なシェアを同様のRTTを持つ複数のフローに公平なシェアを与え、可能であれば、さまざまなRTTSを持つ複数のフローになります。
a. Existing flows at a bottleneck must also be fair to new flows to that bottleneck and must allow new flows to ramp up to a useful share of the bottleneck bandwidth as quickly as possible. A useful share will depend on the media types involved, total bandwidth available, and the user-experience requirements of a particular service. Note that relative RTTs may affect the rate at which new flows can ramp up to a reasonable share.
a. ボトルネックの既存のフローも、そのボトルネックへの新しいフローにも公平でなければならず、新しいフローができるだけ早くボトルネック帯域幅の有用なシェアに向上することを可能にする必要があります。有用な共有は、関与するメディアタイプ、利用可能な総帯域幅、および特定のサービスのユーザーエクスペリエンス要件によって異なります。相対的なRTTは、新しいフローが合理的なシェアまで上昇する可能性がある速度に影響を与える可能性があることに注意してください。
3. The algorithm SHOULD NOT starve competing TCP flows and SHOULD, as best as possible, avoid starvation by TCP flows.
3. アルゴリズムは競合するTCPフローを飢えさせてはならず、できるだけ最良のように、TCPフローによる飢餓を避けてください。
a. The congestion control should prioritize achieving a useful share of the bandwidth depending on the media types and total available bandwidth over achieving as-low-as-possible transit delay, when these two requirements are in conflict.
a. 輻輳制御は、これら2つの要件が矛盾しているときに、メディアの種類と、可能な限り低い通過遅延の達成を達成するために、メディアタイプと合計使用可能な帯域幅の有効割合を優先する必要があります。
4. The algorithm SHOULD adapt as quickly as possible to initial network conditions at the start of a flow. This SHOULD occur whether the initial bandwidth is above or below the bottleneck bandwidth.
4. アルゴリズムは、フローの開始時に初期ネットワーク状態にできるだけ早く適応する必要があります。これは、初期帯域幅がボトルネック帯域幅の上または下にあるかどうかが起こるはずです。
a. The algorithm should allow different modes of adaptation; for example, the startup adaptation may be faster than adaptation later in a flow. It should allow for both slow-start operation (adapt up) and history-based startup (start at a point expected to be at or below channel bandwidth from historical information, which may need to adapt down quickly if the initial guess is wrong). Starting too low and/or adapting up too slowly can cause a critical point in a personal communication to be poor ("Hello!"). Starting too high above the available bandwidth causes other problems for user experience, so there's a tension here. Alternative methods to help startup, such as probing during setup with dummy data, may be useful in some applications; in some cases, there will be a considerable gap in time between flow creation and the initial flow of data. Again, a flow may need to change adaptation rates due to network conditions or changes in the provided flows (such as unmuting or sending data after a gap).
a. アルゴリズムは異なる適応モードを可能にする必要があります。例えば、起動適合は、流れの後の適応よりも速くなる可能性がある。それは、スロースタート操作（適応）と履歴ベースの起動の両方を可能にする（履歴情報からチャンネル帯域幅の下または下のチャネル帯域幅の下にあると予想されるポイントから始めてください。最初の推測が間違っている場合は迅速に適応させる必要があるかもしれません）。低すぎたり/または適応しすぎたりしすぎると、個人的なコミュニケーションの臨界点が悪くなることがあります（「こんにちは！」）。利用可能な帯域幅を上回る上では高すぎると、その他の問題が発生しますので、ここに緊張があります。ダミーデータを使用してセットアップ中のプロービングなどの起動を助けるための代替方法は、いくつかのアプリケーションで役立ちます。場合によっては、フロー作成とデータの初期フローの間に時間がかなりのギャップがあるでしょう。やはり、フローは、ネットワークの状態や提供されたフローの変化（ギャップ後のデータの解除または送信など）の変化によって適応速度を変更する必要があるかもしれません。
5. The algorithm SHOULD be stable if the RTP streams are halted or discontinuous (for example, when using Voice Activity Detection).
5. RTPストリームが停止または不連続である場合（例えば、音声アクティビティ検出を使用する場合など）、アルゴリズムは安定している必要があります。
a. After stream resumption, the algorithm should attempt to rapidly regain its previous share of the bandwidth; the aggressiveness with which this is done will decay with the length of the pause.
a. ストリーム再開後、アルゴリズムは帯域幅の以前の共有を迅速に取り戻そうとするはずです。これが行われる攻撃性は、一時停止の長さで衰弱します。
6. Where possible, the algorithm SHOULD merge information across multiple RTP streams sent between two endpoints when those RTP streams share a common bottleneck, whether or not those streams are multiplexed onto the same ports. This will allow congestion control of the set of streams together instead of as multiple independent streams. It will also allow better overall bandwidth management, faster response to changing conditions, and fairer sharing of bandwidth with other network users.
6. 可能であれば、アルゴリズムは、それらのRTPストリームが共通のボトルネックを共有したときに送信された複数のRTPストリームにわたって情報をマージする必要があります。これらのストリームが同じポートに多重化されているかどうか。これにより、複数の独立したストリームとしてはなく、ストリームセットの輻輳制御が可能になります。また、全体的な帯域幅管理、変化条件に対する応答、および他のネットワークユーザーとの帯域幅の公平な共有を可能にするでしょう。
a. The algorithm should also share information and adaptation with other non-RTP flows between the same endpoints, such as a WebRTC data channel [RFC8831], when possible.
a. このアルゴリズムはまた、可能であれば、WebRTCデータチャネル[RFC8831]などの同じエンドポイント間の他の非RTPフローとの情報と適応を共有する必要があります。
b. When there are multiple streams across the same 5-tuple coordinating their bandwidth use and congestion control, the algorithm should allow the application to control the relative split of available bandwidth. The most correlated bandwidth usage would be with other flows on the same 5-tuple, but there may be use in coordinating measurement and control of the local link(s). Use of information about previous flows, especially on the same 5-tuple, may be useful input to the algorithm, especially regarding startup performance of a new flow.
b. 帯域幅の使用と輻輳制御を調整するのと同じ5タプルにわたって複数のストリームがある場合、アルゴリズムはアプリケーションが利用可能な帯域幅の相対分割を制御できるようにします。最も相関している帯域幅の使用量は、同じ5タプル上の他の流れと共にありますが、ローカルリンクの測定と制御の調整に使用することができます。特に同じ5タプル上の前のフローに関する情報の使用は、特に新しいフローの起動性能に関して、アルゴリズムへの有用な入力であり得る。
7. The algorithm SHOULD NOT require any special support from network elements to be able to convey congestion-related information. As much as possible, it SHOULD leverage available information about the incoming flow to provide feedback to the sender. Examples of this information are the packet arrival times, acknowledgements and feedback, packet timestamps, packet losses, and Explicit Congestion Notification (ECN) [RFC3168]; all of these can provide information about the state of the path and any bottlenecks. However, the use of available information is algorithm dependent.
7. アルゴリズムは、輻輳関連情報を伝えるためにネットワーク要素からの特別なサポートを必要としないはずです。できるだけ多くの場合、送信者にフィードバックを提供するために、着信フローに関する利用可能な情報を活用する必要があります。この情報の例は、パケット到着時間、確認応答およびフィードバック、パケットのタイムスタンプ、パケット損失、および明示的輻輳通知（ECN）[RFC3168]です。これらすべては、パスの状態とボトルネックに関する情報を提供できます。ただし、利用可能な情報を使用することはアルゴリズムに依存します。
a. Extra information could be added to the packets to provide more detailed information on actual send times (as opposed to sampling times), but such information should not be required.
a. 実際の送信時間に関するより詳細な情報を提供するために追加情報を追加することができます（サンプリング時間とは対照的に）、そのような情報は必要ないはずです。
8. Since the assumption here is a set of RTP streams, the backchannel typically SHOULD be done via the RTP Control Protocol (RTCP) [RFC3550]; instead, one alternative would be to include it in a reverse-RTP channel using header extensions.
8. ここでの仮定は一連のRTPストリームであるため、バックチャネルは通常RTP制御プロトコル（RFC3550]を介して行われるべきです。代わりに、1つの代替案は、ヘッダー拡張機能を使用して逆RTPチャネルに含めることです。
a. In order to react sufficiently quickly when using RTCP for a backchannel, an RTP profile such as RTP/AVPF [RFC4585] or RTP/SAVPF [RFC5124] that allows sufficiently frequent feedback must be used. Note that in some cases, backchannel messages may be delayed until the RTCP channel can be allocated enough bandwidth, even under AVPF rules. This may also imply negotiating a higher maximum percentage for RTCP data or allowing solutions to violate or modify the rules specified for AVPF.
a. バックチャネルのRTCPを使用するときに十分に迅速に反応するには、十分に頻繁に頻繁にフィードバックを許可するRTP / AVPF [RFC4585]またはRTP / SAVPF [RFC5124]などのRTPプロファイルを使用する必要があります。場合によっては、AVPFルールの下でも、RTCPチャネルに十分な帯域幅を割り当てることができるまで、BackChannelメッセージを遅延させることができます。これはまた、RTCPデータのためのより高い最大パーセンテージを交渉することも、AVPFに指定された規則を違反または変更することを可能にすることもできます。
b. Bandwidth for the feedback messages should be minimized using techniques such as those in [RFC5506], to allow RTCP without Sender/Receiver Reports.
b. フィードバックメッセージの帯域幅は、[RFC5506]のようなテクニックを使用して、送信者/受信側レポートなしでRTCPを許可する必要があります。
c. Backchannel data should be minimized to avoid taking too much reverse-channel bandwidth (since this will often be used in a bidirectional set of flows). In areas of stability, backchannel data may be sent more infrequently so long as algorithm stability and fairness are maintained. When the channel is unstable or has not yet reached equilibrium after a change, backchannel feedback may be more frequent and use more reverse-channel bandwidth. This is an area with considerable flexibility of design, and different approaches to backchannel messages and frequency are expected to be evaluated.
c. バックチャネルデータは、逆チャネル帯域幅が多すぎるのを防ぐために最小限に抑える必要があります（これは双方向のフローに使用されることがよく使用されるため）。安定性の領域では、アルゴリズムの安定性と公平性が維持されている限り、バックチャンネルデータをよりまれに送信することができます。変化後にチャネルが不安定で平衡に達していない場合、バックチャネルフィードバックはより頻繁であり、より逆チャネル帯域幅を使用することができる。これは設計のかなりの柔軟性を持つ領域であり、バックチャネルメッセージと周波数への異なるアプローチが評価されると予想されます。
9. Flows managed by this algorithm and flows competing against each other at a bottleneck may have different Differentiated Services Code Point (DSCP) [RFC5865] markings depending on the type of traffic or may be subject to flow-based QoS. A particular bottleneck or section of the network path may or may not honor DSCP markings. The algorithm SHOULD attempt to leverage DSCP markings when they're available.
9. このアルゴリズムによって管理されたフロー、ボトルネックで互いに競合するフローは、トラフィックの種類に応じて、異なる微分サービスコードポイント（DSCP）[RFC5865]マーキングを持つか、またはフローベースのQoSの影響を受ける可能性があります。ネットワークパスの特定のボトルネックまたはセクションは、DSCPマーキングを尊重する場合があります。アルゴリズムは、利用可能なときにDSCPマーキングを活用しようとするはずです。
10. The algorithm SHOULD sense the unexpected lack of backchannel information as a possible indication of a channel-overuse problem and react accordingly to avoid burst events causing a congestion collapse.
10. このアルゴリズムは、チャネル過用問題の可能な表示の可能な表示として、バックチャネル情報の予想外の欠如を感知し、それに応じて輻輳崩壊を引き起こす破裂イベントを回避するために反応する必要があります。
11. The algorithm SHOULD be stable and maintain low delay when faced with Active Queue Management (AQM) algorithms. Also note that these algorithms may apply across multiple queues in the bottleneck or to a single queue.
11. アルゴリズムは安定し、アクティブなキュー管理（AQM）アルゴリズムに直面したときに低遅延を維持する必要があります。また、これらのアルゴリズムは、ボトルネックまたは単一キュー内の複数のキューにまたがって適用されることがあります。
Among the existing congestion control mechanisms, TCP Friendly Rate Control (TFRC) [RFC5348] is the one that claims to be suitable for real-time interactive media. TFRC is an equation-based congestion control mechanism that provides a reasonably fair share of bandwidth when competing with TCP flows and offers much lower throughput variations than TCP. This is achieved by a slower response to the available bandwidth change than TCP. TFRC is designed to perform best with applications that have a fixed packet size and do not have a fixed period between sending packets.
既存の輻輳制御メカニズムの中には、TCP対応レート制御（TFRC）[RFC5348]が、リアルタイムの対話型メディアに適していると主張するものです。TFRCは、TCPフローと競合するときに適度に公正なシェアを提供し、TCPよりもはるかに低いスループットバリエーションを提供する、方程式ベースの輻輳制御メカニズムです。これは、TCPよりも利用可能な帯域幅の変更に対する遅い応答によって達成されます。TFRCは、固定のパケットサイズを持つアプリケーションで最適化を図るように設計されており、パケットの送信間に固定期間がありません。
TFRC detects loss events and reacts to congestion-caused loss by reducing its sending rate. It allows applications to increase the sending rate until loss is observed in the flows. As noted in IAB/ IRTF report [RFC7295], large buffers are available in the network elements, which introduce additional delay in the communication. It becomes important to take all possible congestion indications into consideration. Looking at the current Internet deployment, TFRC's biggest deficiency is that it only considers loss events as a congestion indication.
TFRCは損失イベントを検出し、その送信速度を短縮することによって輻輳損失に反応します。これにより、フロー内で損失が観測されるまで、アプリケーションが送信レートを上げることができます。IAB / IRTFレポート[RFC7295]で述べたように、大規模なバッファはネットワーク要素で利用可能で、これは通信に追加の遅延を導入します。考えられない輻輳表示を考慮に入れることが重要になります。現在のインターネット展開を見ると、TFRCの最大の欠陥は、損失イベントのみを輻輳指示として考慮することです。
A typical real-time interactive communication includes live-encoded audio and video flow(s). In such a communication scenario, an audio source typically needs a fixed interval between packets and needs to vary the segment size of the packets instead of the packet rate in response to congestion; therefore, it sends smaller packets. A variant of TFRC, Small-Packet TFRC (TFRC-SP) [RFC4828], addresses the issues related to such kind of sources. A video source generally varies video frame sizes, can produce large frames that need to be further fragmented to fit into path Maximum Transmission Unit (MTU) size, and has an almost fixed interval between producing frames under a certain frame rate. TFRC is known to be less optimal when using such video sources.
典型的なリアルタイム対話型通信は、ライブエンコードされたオーディオとビデオフローを含みます。そのような通信シナリオでは、オーディオソースは通常、パケット間の固定間隔を必要とし、輻輳に応答してパケットレートの代わりにパケットのセグメントサイズを変える必要がある。したがって、小さいパケットを送信します。TFRC、小パケットTFRC（TFRC-SP）[RFC4828]の変形は、そのような種類のソースに関連する問題に対処します。ビデオソースは、一般にビデオフレームサイズを変える、経路最大送信ユニット（MTU）サイズに適合するようにさらに断片化される必要がある大きなフレームを生成することができ、あるフレームレート下でフレームを生成する間隔をほぼ一定の間隔である。このようなビデオソースを使用する場合、TFRCは最適ではないことが知られています。
There are also some mismatches between TFRC's design assumptions and how the media sources in a typical real-time interactive application work. TFRC is designed to maintain a smooth sending rate; however, media sources can change rates in steps for both rate increase and rate decrease. TFRC can operate in two modes: i) bytes per second and ii) packets per second, where typical real-time interactive media sources operate on bit per second. There are also limitations on how quickly the media sources can adapt to specific sending rates. Modern video encoders can operate in a mode in which they can vary the output bitrate a lot depending on the way they are configured, the current scene they are encoding, and more. Therefore, it is possible that the video source will not always output at an allowable bitrate. TFRC tries to increase its sending rate when transmitting at the maximum allowed rate, and it increases only twice the current transmission rate; hence, it may create issues when the video sources vary their bitrates.
TFRCの設計前提条件と典型的なリアルタイム対話型アプリケーションのメディアソースとの間には、いくつかの不一致もあります。 TFRCはスムーズな送信レートを維持するように設計されています。しかしながら、メディアソースは、レートの上昇と率の低下の両方のためにステップの速度を変えることができます。 TFRCは、1秒あたりの2つのモードで動作することができ、II）1秒あたりのパケットは1秒あたりのビット上で動作します。メディアソースが特定の送信レートに適応できるかについての制限もあります。現代のビデオエンコーダは、設定された方法、現在のシーンが符号化されている方法、およびより多くのシーンに応じて、それらが出力ビットレートを大きく変えることができるモードで動作することができます。したがって、ビデオソースが許容ビットレートで常に出力されない可能性があります。 TFRCは、最大許容レートで送信するときに送信速度を高め、現在の伝送速度の2倍のみになります。したがって、ビデオソースがビットレートを変化させたときに問題を作成することがあります。
Moreover, there are a number of studies on TFRC that show its limitations, including TFRC's unfairness to low statistically multiplexed links, oscillatory behavior, performance issues in highly dynamic loss-rate conditions, and more [CH09].
さらに、TFRCの不公平を含むTFRCに関する多くの研究が、低統計的に多重化されたリンク、振動挙動、非常に動的損失率の状態での性能の問題、そしてより多くの[CH09]を含む、その制限を示しています。
Looking at all these deficiencies, it can be concluded that the requirements for a congestion control mechanism for real-time interactive media cannot be met by TFRC as defined in the standard.
これらすべての欠陥を見て、リアルタイム対話型メディアの輻輳制御メカニズムの要件は、標準内で定義されているようにTFRCによって満たすことができないと結論付けることができます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
An attacker with the ability to delete, delay, or insert messages into the flow can fake congestion signals, unless they are passed on a tamper-proof path. Since some possible algorithms depend on the timing of packet arrival, even a traditional, protected channel does not fully mitigate such attacks.
メッセージを削除、遅延、遅延、または挿入することができる攻撃者は、改ざん防止パスに渡されない限り、輻輳信号を偽造することができます。いくつかの可能なアルゴリズムはパケット到着のタイミングに依存するので、従来の保護されたチャネルでさえもそのような攻撃を完全に軽減しない。
An attack that reduces bandwidth is not necessarily significant, since an on-path attacker could break the connection by discarding all packets. Attacks that increase the perceived available bandwidth are conceivable and need to be evaluated. Such attacks could result in starvation of competing flows and permit amplification attacks.
帯域幅を減らす攻撃は、すべてのパケットを破棄することによって接続を破る可能性があるため、必ずしも重要ではありません。認識された利用可能な帯域幅を増加させる攻撃が考えられ、評価する必要があります。そのような攻撃は競合流の飢餓と増幅攻撃を可能にする可能性があります。
Algorithm designers should consider the possibility of malicious on-path attackers.
アルゴリズム設計者は、悪意のあるオンパス攻撃者の可能性を考慮する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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>。
[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>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5124] OTT、J.およびE.Carrara、「リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバック（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<HTTPS）//www.rfc-editor.org/info/rfc5124>。
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, <https://www.rfc-editor.org/info/rfc8825>.
[RFC8825] ALVESTRAND、H。、「概要：ブラウザベースのアプリケーション用リアルタイムプロトコル」、RFC 8825、DOI 10.17487 / RFC8825、2021年1月、<https：//www.rfc-editor.org/info/rfc8825>。
[CH09] Choi, S. and M. Handley, "Designing TCP-Friendly Window-based Congestion Control for Real-time Multimedia Applications", Proceedings of PFLDNeT, May 2009.
[CH09] Choi、S.およびM.ハンドリー、「リアルタイムマルチメディアアプリケーションのためのTCPに優しいウィンドウベースの輻輳制御の設計」、2009年5月PFLDNetの議事録。
[MPEG_DASH] ISO, "Information Technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2019, December 2019, <https://www.iso.org/standard/79329.html>.
[MPEG_DASH] ISO、「情報技術 - http（Dash）の動的適応ストリーミング - 第1部：メディアプレゼンテーションの説明とセグメント形式」、ISO / IEC 23009-1：2019、2019年12月、<https：// www。iso.org/standard/79329.html>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168] Ramakrishnan、K.、Floyd、S.、およびD. Black、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。rfc-editor.org/info/rfc3168>。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, DOI 10.17487/RFC4828, April 2007, <https://www.rfc-editor.org/info/rfc4828>.
[RFC4828] Floyd、S.およびE.Kohler、「TCPに優しいレートコントロール（TFRC）：2007年4月、<https：///ww.rfc-editor.org/info/rfc4828>
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J.、およびJ.Widmer、「TCP対応Rate Control（TFRC）：プロトコル仕様」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<https：//www.rfc-editor.org/info/rfc5348>。
[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>。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <https://www.rfc-editor.org/info/rfc5865>.
[RFC5865] Baker、F.、Polk、J.、およびM. Dolly、RFC 5865、DOI 10.17487 / RFC5865、2010年5月、<https：//www.rfc-editor.org/info/rfc5865>。
[RFC7295] Tschofenig, H., Eggert, L., and Z. Sarker, "Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication", RFC 7295, DOI 10.17487/RFC7295, July 2014, <https://www.rfc-editor.org/info/rfc7295>.
[RFC7295] Tschofenig、H.、Eggert、L.、およびZ.Sarker、「IAB / IRTFワークショップからのIAB / IRTFワークショップからのレポート」、RFC 7295、DOI 10.17487 / RFC7295、2014年7月、<HTTPS//www.rfc-editor.org/info/rfc7295>。
[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>。
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.
[RFC8831] Jesup、R.、Loreto、S.、M.Tüxen、「Webrtcデータチャンネル」、RFC 8831、DOI 10.17487 / RFC8831、2021年1月、<https：//www.rfc-editor.org/info/RFC8831>。
Acknowledgements
謝辞
This document is the result of discussions in various fora of the WebRTC effort, in particular on the <rtp-congestion@alvestrand.no> mailing list. Many people contributed their thoughts to this.
この文書は、<rtp-congestion@alvestrand.no>メーリングリストのWebRTCの努力の様々なフォーラの議論の結果です。多くの人がこれに彼らの考えを貢献しました。
Authors' Addresses
著者の住所
Randell Jesup Mozilla United States of America
Randell Jesup Mozillaアメリカ合衆国
Email: randell-ietf@jesup.org
Zaheduzzaman Sarker (editor) 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