[要約] RFC 9392 は、RTCP を使用しての適切な輻輳制御フィードバックの送信レートと、ユニキャスト マルチメディア アプリケーションの輻輳制御の実装における RTCP の適合性について議論しています。
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 9392 University of Glasgow
Category: Informational April 2023
ISSN: 2070-1721
This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for implementing congestion control for unicast multimedia applications.
このメモでは、RTPコントロールプロトコル（RTCP）を使用して輻輳制御フィードバックを送信できる速度と、ユニキャストマルチメディアアプリケーションの輻輳制御を実装するためのRTCPの適合性について説明します。
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/rfc9392.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9392で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. Considerations for RTCP Feedback
3. What Feedback is Achievable with RTCP?
3.1. Scenario 1: Voice Telephony
3.2. Scenario 2: Point-to-Point Video Conference
4. Discussion and Conclusions
5. Security Considerations
6. IANA Considerations
7. Normative References
8. Informative References
Acknowledgements
Author's Address
The deployment of WebRTC systems [RFC8825] has resulted in high-quality video conferencing seeing extremely wide use. To ensure the stability of the network in the face of this use, WebRTC systems need to use some form of congestion control for their RTP-based media traffic [RFC2914] [RFC8083] [RFC8085] [RFC8834], allowing them to adapt and adjust the media data they send to match changes in the available network capacity. In addition to ensuring the stable operation of the network, such adaptation is critical to ensuring a good user experience, since it allows the sender to match the media to the network capacity, rather than forcing the receiver to compensate for uncontrolled packet loss when the available capacity is exceeded.
WeBRTCシステム[RFC8825]の展開により、高品質のビデオ会議が非常に幅広く使用されています。この使用に直面してネットワークの安定性を確保するために、WeBRTCシステムは、RTPベースのメディアトラフィックに何らかの渋滞制御を使用する必要があります[RFC2914] [RFC8083] [RFC8085] [RFC8834]。利用可能なネットワーク容量の変更に合わせて送信するメディアデータ。ネットワークの安定した動作を確保することに加えて、そのような適応は、受信者が利用可能なときに制御されていないパケット損失を補償することを強制するのではなく、センダーがメディアをネットワーク容量に一致させることができるため、優れたユーザーエクスペリエンスを確保するために重要です。容量を超えています。
To develop such congestion control, it is necessary to understand the sort of congestion feedback that can be provided within the framework of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then becomes possible to determine if this is sufficient for congestion control or if some form of RTP extension is needed.
このような輻輳制御を開発するには、RTP [RFC3550]およびRTP制御プロトコル（RTCP）のフレームワーク内で提供できる種類の輻輳フィードバックを理解する必要があります。次に、これが輻輳制御に十分であるかどうか、または何らかの形のRTP拡張が必要かどうかを判断することが可能になります。
As this memo will show, if it is desired to use RTCP in something close to its current form for congestion feedback, the multimedia congestion control algorithm needs to be designed to work with detailed feedback sent every few frames, rather than per-frame acknowledgement, to match the constraints of RTCP.
このメモが示すように、混雑フィードバックのために現在のフォームに近いものでRTCPを使用することが望ましい場合、マルチメディア輻輳制御アルゴリズムは、フレームごとの認定ではなく、数フレームごとに送信される詳細なフィードバックで動作するように設計する必要があります。RTCPの制約に一致するため。
This memo considers unicast congestion feedback that can be sent using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the RTP/AVPF profile [RFC4585]). This profile was chosen because it forms the basis for media transport in WebRTC [RFC8834] systems. However, nothing in this memo is specific to the secure version of the profile or to WebRTC. It is also assumed that the congestion control feedback mechanism described in [RFC8888] and common RTCP extensions for efficient feedback [RFC5506] [RFC8108] [RFC8861] [RFC8872] are used.
このメモでは、RTP/SAVPFプロファイル[RFC5124]（RTP/AVPFプロファイルの安全なバージョン[RFC4585]）の下でRTCPを使用して送信できるユニキャスト輻輳フィードバックを考慮します。このプロファイルは、WeBRTC [RFC8834]システムのメディア輸送の基礎を形成するため、選択されました。ただし、このメモには、プロファイルの安全なバージョンまたはWebrtcに固有のものはありません。また、[RFC8888]に記載されている混雑制御フィードバックメカニズムと、効率的なフィードバック[RFC5506] [RFC8108] [RFC8861] [RFC8872]のための一般的なRTCP拡張機能が使用されるとも想定されています。
Nr:
NR：
number of frames between feedback reports
フィードバックレポート間のフレーム数
Nrs:
NRS：
number of reduced-size RTCP packets send for every compound RTCP packet
縮小サイズのrtcpパケットの数すべての化合物RTCPパケットに送信
Na:
NA：
number of audio packets per report
レポートごとのオーディオパケットの数
Nv:
NV：
number of video packets per reports
レポートごとのビデオパケットの数
Sc:
SC：
size of a compound RTCP packet
複合RTCPパケットのサイズ
Srs:
SRS：
size of a reduced-size RTCP packet
縮小サイズのRTCPパケットのサイズ
Tf:
TF：
duration of a media frame in seconds
メディアフレームの期間は数秒で
Rf:
RF：
frame rate 1/Tf
フレームレート1/tf
Several questions need to be answered when providing RTCP feedback for congestion control purposes. These include:
混雑制御目的でRTCPフィードバックを提供する際には、いくつかの質問に答える必要があります。これらには以下が含まれます：
* How often is feedback needed?
* フィードバックはどのくらいの頻度で必要ですか？
* How much overhead is acceptable?
* どのくらいのオーバーヘッドが受け入れられますか？
* How much and what data does each report contain?
* 各レポートにはどのくらいのデータが含まれていますか？
However, the key question is as follows: how often does the receiver need to send feedback on the reception quality it is experiencing and hence the congestion state of the network?
ただし、重要な質問は次のとおりです。受信者は、経験している受信の品質、したがってネットワークの混雑状態についてフィードバックを送信する必要がありますか？
Widely used transport protocols, such as TCP, send acknowledgements frequently. For example, a TCP receiver will send an acknowledgement at least once every 0.5 seconds or when new data equal to twice the maximum segment size has been received [RFC9293]. That has relatively low overhead when traffic is bidirectional and acknowledgements can be piggybacked onto return path data packets. It can also be acceptable, and can have reasonable overhead, to send separate acknowledgement packets when those packets are much smaller than data packets.
TCPなどの広く使用されている輸送プロトコルは、頻繁に謝辞を送信します。たとえば、TCPレシーバーは、少なくとも0.5秒ごとに少なくとも1回、または最大セグメントサイズの2倍に等しい新しいデータが受信された場合に確認を送信します[RFC9293]。トラフィックが双方向である場合、これは比較的低いオーバーヘッドを持ち、承認を返すパスデータパケットに礼拝することができます。また、それらのパケットがデータパケットよりもはるかに小さい場合に個別の確認パケットを送信するために、受け入れられる可能性があり、合理的なオーバーヘッドを持つことができます。
Frequent acknowledgements can become a problem, however, when there is no return traffic on which to piggyback feedback or if separate feedback and data packets are sent and the feedback is similar in size to the data being acknowledged. This can be the case for some forms of media traffic, especially for Voice over IP (VoIP) flows, leading to high overhead when using a transport protocol that sends frequent feedback. Approaches like in-network filtering of acknowledgements that have been proposed to reduce acknowledgement overheads on highly asymmetric links (e.g., as mentioned in [RFC3449]) can also reduce the feedback frequency and overhead for multimedia traffic, but this so-called "stretch-ACK" behavior is nonstandard and not guaranteed.
ただし、頻繁に謝辞が問題になる可能性がありますが、フィードバックへの収益トラフィックがない場合、または個別のフィードバックとデータパケットが送信され、フィードバックのサイズが認められているデータと同様です。これは、特に頻繁なフィードバックを送信するトランスポートプロトコルを使用する場合、特にVoice over IP（VoIP）フローの場合、特にVoice over IP（VoIP）フローの場合には当てはまります。非常に非対称リンクの承認オーバーヘッドを減らすために提案されている謝辞のネットワーク内フィルタリングのようなアプローチ（例：[RFC3449]で言及されているように）も、マルチメディアトラフィックのフィードバック頻度とオーバーヘッドを減らすことができますが、このいわゆる「ストレッチ」 - ACK "動作は非標準であり、保証されていません。
Accordingly, when implementing congestion control for RTP-based multimedia traffic, it might make sense to give the option of sending congestion feedback less often than TCP does. For example, it might be possible to send a feedback packet once per video frame, every few frames, or once per network round-trip time (RTT). This could still give sufficiently frequent feedback for the congestion control loop to be stable and responsive while keeping the overhead reasonable when the feedback cannot be piggybacked onto returning data. In this case, it is important to note that RTCP can send much more detailed feedback than simple acknowledgements. For example, if it were useful, it could be possible to use an RTCP extended report (XR) packet [RFC3611] to send feedback once per RTT; the feedback could comprise a bitmap of lost and received packets, with reception times, over that RTT. As long as feedback is sent frequently enough that the control loop is stable and the sender is kept informed when data leaves the network (to provide an equivalent to acknowledgement (ACK) clocking in TCP), it is not necessary to report on every packet at the instant it is received. Indeed, it is unlikely that a video codec can react instantly to a rate change, and there is little point in providing feedback more often than the codec can adapt. This suggests that an RTP receiver needs to be configured to provide feedback at a rate that matches the rate of adaptation of the sender. In the best case, this will match the media frame rate but might often be slower.
したがって、RTPベースのマルチメディアトラフィックの輻輳制御を実装する場合、TCPよりも頻繁に渋滞フィードバックを送信するオプションを提供することは理にかなっているかもしれません。たとえば、ビデオフレーム、数フレームごと、またはネットワークの往復時間（RTT）ごとに1回のフィードバックパケットを1回送信することが可能かもしれません。これにより、フィードバックを返信データにピギーバックすることができない場合、オーバーヘッドを妥当な状態に保ちながら、輻輳制御ループが安定して応答性を高めるための十分に頻繁なフィードバックを提供できます。この場合、RTCPは単純な謝辞よりもはるかに詳細なフィードバックを送信できることに注意することが重要です。たとえば、有用であれば、RTCP拡張レポート（XR）パケット[RFC3611]を使用して、RTTごとにフィードバックを送信することが可能です。フィードバックは、そのRTTを介して、受信時間を備えた紛失および受信パケットのビットマップを含む可能性があります。フィードバックが頻繁に送信される限り、コントロールループが安定しており、データがネットワークを離れるときに送信者に通知を受け続ける限り（TCPでの確認（ACK）クロックに相当する）、すべてのパケットについて報告する必要はありません受け取られた瞬間。確かに、ビデオコーデックがレートの変化に即座に反応する可能性は低く、コーデックが適応できるよりも頻繁にフィードバックを提供することはほとんど意味がありません。これは、送信者の適応率に一致するレートでフィードバックを提供するようにRTPレシーバーを構成する必要があることを示唆しています。最良の場合、これはメディアフレームレートと一致しますが、しばしば遅くなる可能性があります。
Reducing the feedback frequency compared to TCP will reduce feedback overhead but will lead multimedia flows to adapt to congestion more slowly than TCP, raising concerns about inter-flow fairness. Similar concerns are noted in [RFC5348], and accordingly, the congestion control algorithm described therein aims for "reasonable" fairness and a sending rate that is "generally within a factor of two" of what TCP would achieve under the same conditions. It is to be noted, however, that TCP exhibits inter-flow unfairness when flows with differing round-trip times compete, and stretch acknowledgements due to in-network traffic manipulation are not uncommon and also raise fairness concerns. Implementations need to balance potential unfairness against feedback overhead.
TCPと比較してフィードバック頻度を減らすと、フィードバックのオーバーヘッドが減少しますが、マルチメディアフローをTCPよりもゆっくりと混雑に適応させ、流れ間の公平性に関する懸念を引き起こします。同様の懸念は[RFC5348]で認められており、それに応じて、そこに記載されている輻輳制御アルゴリズムは、「合理的な」公平性と、同じ条件下でTCPが達成するものの「一般に2倍」で「一般に2倍」である送信率を目指しています。ただし、異なる往復時間を持つフローが競合する場合、TCPはフロー間不公平を示すことに注意してください。また、ネットワーク内の交通操作によるストレッチの謝辞は珍しくなく、公平性の懸念を引き起こします。実装は、潜在的な不公平のフィードバックオーバーヘッドとのバランスをとる必要があります。
Generating and processing feedback consumes resources at the sender and receiver. The feedback packets also incur forwarding costs, contribute to link utilization, and can affect the timing of other traffic on the network. This can affect performance on some types of networks that can be impacted by the rate, timing, and size of feedback packets, as well as the overall volume of feedback bytes.
フィードバックの生成と処理は、送信者と受信機でリソースを消費します。フィードバックパケットは、転送コストも負担し、リンクの使用率に貢献し、ネットワーク上の他のトラフィックのタイミングに影響を与える可能性があります。これは、フィードバックパケットのレート、タイミング、サイズ、およびフィードバックバイトの全体容積によって影響を受ける可能性のあるいくつかのタイプのネットワークのパフォーマンスに影響を与える可能性があります。
The amount of overhead due to congestion control feedback that is considered acceptable has to be determined. RTCP feedback is sent in separate packets to RTP data, and this has some cost in terms of additional header overhead compared to protocols that piggyback feedback on return path data packets. The RTP standards have long said that a 5% overhead for RTCP traffic is generally acceptable. Is this still the case for congestion control feedback? Is there a desire to provide more responsive feedback and congestion control, possibly with a higher overhead? Or is lower overhead wanted, accepting that this might reduce responsiveness of the congestion control algorithm?
許容可能と見なされる輻輳制御フィードバックによるオーバーヘッドの量を決定する必要があります。RTCPフィードバックはRTPデータに個別のパケットで送信されます。これは、リターンパスデータパケットに対するフィードバックがピギーバックするプロトコルと比較して、追加のヘッダーオーバーヘッドに関してある程度のコストがあります。RTPの基準は、RTCPトラフィックの5％のオーバーヘッドが一般的に許容できると長い間言ってきました。これはまだ混雑制御フィードバックの場合ですか？おそらくより高いオーバーヘッドを備えた、より多くの応答性の高いフィードバックと輻輳制御を提供したいという願望はありますか？それとも、より低いオーバーヘッドが必要であり、これにより輻輳制御アルゴリズムの応答性が低下する可能性があることを受け入れますか？
Finally, the details of how much and what data is to be sent in each report will affect the frequency and/or overhead of feedback. There is a fundamental trade-off that the more frequently feedback packets are sent, the less data can be included in each packet to keep the overhead constant. Does the congestion control need a high rate but simple feedback (e.g., like TCP acknowledgements), or is it acceptable to send more complex feedback less often? Is it useful for the congestion control to receive frequent feedback, perhaps to provide more accurate round-trip time estimates, or to provide robustness in case feedback packets are lost, even if the media sending rate cannot quickly be changed? Or is low-rate feedback, resulting in slowly responsive changes to the sending rate, acceptable? Different combinations of the congestion control algorithm and media codec might require different trade-offs, and the correct trade-off for interactive, self-paced, real-time multimedia traffic might not be the same as that for TCP congestion control.
最後に、各レポートで送信されるデータの量とどのデータが送信されるかの詳細は、フィードバックの頻度および/またはオーバーヘッドに影響します。より頻繁にフィードバックパケットが送信されるほど、オーバーヘッドを一定に保つために各パケットに含まれるデータが少ないという基本的なトレードオフがあります。混雑制御には、高いレートだが単純なフィードバック（たとえば、TCP謝辞のように）が必要ですか、それとも、より複雑なフィードバックを頻繁に送信することは許容されますか？メディアの送信率をすぐに変更できなくても、渋滞制御が頻繁なフィードバックを受け取ること、おそらくより正確な往復時間の推定値を提供すること、またはフィードバックパケットが失われた場合の堅牢性を提供することは有用ですか？または、低料金のフィードバックは、送信率にゆっくりと反応する変更をもたらしますか？混雑制御アルゴリズムとメディアコーデックのさまざまな組み合わせには、異なるトレードオフが必要になる場合があり、インタラクティブでセルフペースのリアルタイムマルチメディアトラフィックの正しいトレードオフは、TCP輻輳制御と同じではない場合があります。
The following sections illustrate how the RTCP congestion control feedback report [RFC8888] can be used in different scenarios and illustrate the overheads of this approach.
次のセクションでは、RTCPの混雑制御フィードバックレポート[RFC8888]をさまざまなシナリオで使用し、このアプローチのオーバーヘッドを説明する方法を示しています。
In many ways, point-to-point voice telephony is the simplest scenario for congestion control, since there is only a single media stream to control. It's complicated, however, by severe bandwidth constraints on the feedback, to keep the overhead manageable.
多くの点で、ポイントツーポイントの音声テレフォニーは、制御するメディアストリームが1つしかないため、混雑制御の最も簡単なシナリオです。ただし、オーバーヘッドを管理しやすくするために、フィードバックに対する深刻な帯域幅の制約により複雑です。
Assume a two-party, point-to-point VoIP call, using RTP over UDP/IP. A rate-adaptive speech codec, such as Opus, is used, encoded into RTP packets in frames of a duration of Tf seconds (Tf = 0.020 s in many cases, but values up to 0.060 s are not uncommon). The congestion control algorithm requires feedback every Nr frames, i.e., every Nr * Tf seconds, to ensure effective control. Both parties in the call send speech data or comfort noise with sufficient frequency that they are counted as senders for the purpose of the RTCP reporting interval calculation.
UDP/IPを介してRTPを使用して、2パーティのポイントツーポイントVoIPコールを仮定します。OPUSなどのレート適応スピーチコーデックが使用され、TF秒のフレームでRTPパケットにエンコードされます（多くの場合、TF = 0.020秒ですが、最大0.060秒の値は珍しいことではありません）。輻輳制御アルゴリズムは、効果的な制御を確保するために、すべてのNRフレーム、つまりすべてのNR * TF秒をフィードバックする必要があります。コールの両当事者は、RTCPレポート間隔計算の目的で送信者としてカウントされるほど十分な頻度で音声データまたはコンフォートノイズを送信します。
RTCP feedback packets can be full (compound) RTCP feedback packets or reduced-size RTCP packets [RFC5506]. A compound RTCP packet is sent once for every Nrs reduced-size RTCP packets.
RTCPフィードバックパケットは、完全な（化合物）RTCPフィードバックパケットまたは減少サイズのRTCPパケット[RFC5506]にすることができます。化合物RTCPパケットは、すべてのNRS縮小サイズのRTCPパケットに対して1回送信されます。
Compound RTCP packets contain a Sender Report (SR) packet, a Source Description (SDES) packet, and an RTP Congestion Control Feedback (CCFB) packet [RFC8888]. Reduced-size RTCP packets contain only the CCFB packet. Since each participant sends only a single RTP media stream, the extensions for RTCP report aggregation [RFC8108] and reporting group optimization [RFC8861] are not used.
化合物RTCPパケットには、送信者レポート（SR）パケット、ソース説明（SDES）パケット、RTP輻輳制御フィードバック（CCFB）パケット[RFC8888]が含まれています。縮小サイズのRTCPパケットには、CCFBパケットのみが含まれています。各参加者は単一のRTPメディアストリームのみを送信するため、RTCPレポート集約[RFC8108]およびレポートグループ最適化[RFC8861]の拡張は使用されません。
Within each compound RTCP packet, the SR packet will contain a sender information block (28 octets) and a single reception report block (24 octets), for a total of 52 octets. A minimal SDES packet will contain a header (4 octets), a single chunk containing a synchronization source (SSRC) (4 octets), and a CNAME item, and if the recommendations for choosing the CNAME [RFC7022] are followed, the CNAME item will comprise a 2-octet header, 16 octets of data, and 2 octets of padding, for a total SDES packet size of 28 octets. The CCFB packets contain an RTCP header and SSRC (8 octets), a report timestamp (4 octets), the other party's SSRC, beginning and ending sequence numbers (8 octets), and 2 * Nr octets of reports, for a total of 20 + (2 * Nr) octets. The compound Secure RTCP (SRTCP) packet will include 4 octets of trailer, followed by an 80-bit (10-octet) authentication tag if HMAC-SHA1 authentication is used. If IPv4 is used, with no IP options, the UDP/IP header will be 28 octets in size. This gives a total compound RTCP packet size of Sc = 142 + (2 * Nr) octets.
各化合物RTCPパケット内で、SRパケットには、合計52オクテットで、送信者情報ブロック（28オクテット）と単一の受信レポートブロック（24オクテット）が含まれます。最小限のSDEパケットには、ヘッダー（4オクテット）、同期ソース（SSRC）（4オクテット）を含む単一のチャンク、およびCNAMEアイテムが含まれ、CNAME [RFC7022]を選択するための推奨事項が続く場合は、CNAMEアイテムが続きます。合計SDESパケットサイズの28オクテットの2オクテットヘッダー、16オクテットのデータ、および2オクツのパディングを含みます。CCFBパケットには、RTCPヘッダーとSSRC（8オクテット）、レポートタイムスタンプ（4オクテット）、相手のSSRC、シーケンス番号の開始および終了シーケンス番号（8オクテット）、およびレポートの2 * NRオクテットが含まれています。（2 * nr）オクテット。Compound Secure RTCP（SRTCP）パケットには、HMAC-Sha1認証が使用される場合、4オクテットのトレーラーが含まれ、80ビット（10-OCTET）認証タグが含まれます。IPv4が使用されている場合、IPオプションがない場合、UDP/IPヘッダーはサイズが28オクテットになります。これにより、sc = 142（2 * nr）オクテットの合計複合RTCPパケットサイズが得られます。
The reduced-size RTCP packets will comprise just the CCFB packet, SRTCP trailer and authentication tag, and a UDP/IP header. It can be seen that these packets will be Srs = 62 + (2 * Nr) octets in size.
縮小サイズのRTCPパケットは、CCFBパケット、SRTCPトレーラーと認証タグ、およびUDP/IPヘッダーのみを含みます。これらのパケットは、サイズがSRS = 62（2 * nr）オクテットになることがわかります。
The RTCP reporting interval calculation (Sections 6.2 and 6.3 of [RFC3550] and [RFC4585]) for a two-party session where both participants are senders reduces to:
両方の参加者が送信者である2パーティセッションのRTCPレポート間隔計算（[RFC3550]および[RFC4585]のセクション6.2および6.3）は、次のように減少します。
Trtcp = n * Srtcp / Brtcp
where Srtcp = (Sc + Nrs * Srs) / (1 + Nrs) is the average RTCP packet size in octets, Brtcp is the bandwidth allocated to RTCP in octets per second, and n is the number of participants in the RTP session (in this scenario, n = 2).
srtcp =（sc nrs * srs） /（1 nrs）はオクテットの平均RTCPパケットサイズであり、BRTCPは1秒あたりのオクテットのRTCPに割り当てられた帯域幅であり、NはRTPセッションの参加者数です（このシナリオで、n = 2）。
To ensure an RTCP report containing congestion control feedback is sent after every Nr frames of audio, it is necessary to set the RTCP reporting interval to Trtcp = Nr * Tf, which when substituted into the previous, gives Nr * Tf = n * Srtcp / Brtcp. Solving this to give the RTCP bandwidth (Brtcp) and expanding the definition of Srtcp gives:
輻輳制御フィードバックを含むRTCPレポートがオーディオのNRフレームごとに送信されることを確認するには、RTCPレポート間隔をTRTCP = NR * TFに設定する必要があります。BRTCP。これを解決してRTCP帯域幅（BRTCP）を与え、SRTCPの定義を拡大すると：
Brtcp = (n * (Sc + Nrs * Srs)) / (Nr * Tf * (1 + Nrs))
If we assume every report is a compound RTCP packet (i.e., Nrs = 0), the frame duration is Tf = 20 ms, and an RTCP report is sent for every second frame (i.e., 25 RTCP reports per second), this gives an RTCP feedback bandwidth of Brtcp = 57 kbps. Increasing the frame duration or reducing the frequency of reports will reduce the RTCP bandwidth, as shown in Table 1.
すべてのレポートが化合物RTCPパケット（つまり、NRS = 0）であると仮定した場合、フレーム持続時間はTF = 20 msで、RTCPレポートは2秒ごとに送信されます（つまり、1秒あたり25 RTCPレポート）。RTCPフィードバックBRTCP = 57 kbpsの帯域幅。表1に示すように、フレームの持続時間を増やすか、レポートの頻度を減らすと、RTCP帯域幅が減少します。
+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020 | 2 | 57.0 |
+--------------+-------------+----------------+
| 0.020 | 4 | 29.3 |
+--------------+-------------+----------------+
| 0.020 | 8 | 15.4 |
+--------------+-------------+----------------+
| 0.020 | 16 | 8.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 19.0 |
+--------------+-------------+----------------+
| 0.060 | 4 | 9.8 |
+--------------+-------------+----------------+
| 0.060 | 8 | 5.1 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.8 |
+--------------+-------------+----------------+
Table 1: RTCP Bandwidth Needed for VoIP Feedback (Compound Reports Only)
表1：VoIPフィードバックに必要なRTCP帯域幅（複合レポートのみ）
The final row of Table 1 (60 ms frames, reporting every 16 frames) sends RTCP reports once per second, giving an RTCP bandwidth overhead of 2.8 kbps.
表1の最終行（16フレームごとに60ミリ秒のフレーム）では、RTCPレポートが1秒あたり1回送信され、2.8 kbpsのRTCP帯域幅のオーバーヘッドが得られます。
The overhead can be reduced by sending some reports in reduced-size RTCP packets [RFC5506]. For example, if we alternate compound and reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the results shown in Table 2.
オーバーヘッドは、縮小サイズのRTCPパケット[RFC5506]でいくつかのレポートを送信することで削減できます。たとえば、化合物と減少したRTCPパケット、つまりNRS = 1を交互にする場合、計算は表2に示す結果を示します。
+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020 | 2 | 41.4 |
+--------------+-------------+----------------+
| 0.020 | 4 | 21.5 |
+--------------+-------------+----------------+
| 0.020 | 8 | 11.5 |
+--------------+-------------+----------------+
| 0.020 | 16 | 6.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 13.8 |
+--------------+-------------+----------------+
| 0.060 | 4 | 7.2 |
+--------------+-------------+----------------+
| 0.060 | 8 | 3.8 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.2 |
+--------------+-------------+----------------+
Table 2: Required RTCP Bandwidth for VoIP Feedback (Alternating Compound and Reduced-Size Reports)
表2：VoIPフィードバックに必要なRTCP帯域幅（交互の化合物と減少レポート）
The RTCP bandwidth needed for 60 ms frames, reporting every 16 frames (once per second), can be seen to drop to 2.2 kbps. This calculation can be repeated for other patterns of compound and reduced-size RTCP packets, feedback frequency, and frame duration, as needed.
60ミリ秒のフレームに必要なRTCP帯域幅は、16フレームごと（1秒あたり1回）を報告することで、2.2 kbpsに低下することがわかります。この計算は、必要に応じて、化合物および縮小サイズのRTCPパケット、フィードバック頻度、フレーム期間の他のパターンで繰り返すことができます。
Note: To achieve the RTCP transmission intervals above, the RTP/SAVPF profile with T_rr_interval=0 is used, since even when using the reduced minimal transmission interval, the RTP/SAVP profile would only allow sending RTCP at most every 0.11 s (every third frame of video). Using RTP/SAVPF with T_rr_interval=0, however, enables full utilization of the configured 5% RTCP bandwidth fraction.
注：上記のRTCP伝送間隔を達成するために、T_RR_INTERVAL = 0のRTP/SAVPFプロファイルが使用されます。なぜなら、RTP/SAVPプロファイルは、最大0.11秒ごとにRTCPのみを送信できるため、3分の1ごとにRTCPのみを送信できるためビデオのフレーム）。ただし、T_RR_INTERVAL = 0でRTP/SAVPFを使用すると、構成された5％RTCP帯域幅画分を完全に利用できます。
The use of IPv6 will increase the overhead by 20 octets per packet, due to the increased size of the IPv6 header compared to IPv4, assuming no IP options in either case. This increases the size of compound packets to Sc = 162 + (2 * Nr) octets and reduced-size packets to Srs = 82 + (2 * Nr). Rerunning the calculations from Table 1 with these packet sizes gives the results shown in Table 3. As can be seen, there is a significant increase in overhead due to the use of IPv6.
IPv6を使用すると、IPv4ヘッダーのサイズが増加しているため、どちらの場合もIPオプションがないと想定しているため、パケットあたり20オクテットがオーバーヘッドを増加させます。これにより、複合パケットのサイズがSC = 162（2 * nr）オクテットになり、SRS = 82（2 * nr）に縮小サイズのパケットが増加します。これらのパケットサイズを使用した表1からの計算を再実行すると、表3に示されている結果が得られます。見られるように、IPv6の使用によりオーバーヘッドが大幅に増加しています。
+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020 | 2 | 64.8 |
+--------------+-------------+----------------+
| 0.020 | 4 | 33.2 |
+--------------+-------------+----------------+
| 0.020 | 8 | 17.4 |
+--------------+-------------+----------------+
| 0.020 | 16 | 9.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 21.6 |
+--------------+-------------+----------------+
| 0.060 | 4 | 11.1 |
+--------------+-------------+----------------+
| 0.060 | 8 | 5.8 |
+--------------+-------------+----------------+
| 0.060 | 16 | 3.2 |
+--------------+-------------+----------------+
Table 3: RTCP Bandwidth Needed for VoIP Feedback (Compound Reports Only) Using IPv6
表3：VoIPフィードバックに必要なRTCP帯域幅（IPv6を使用した化合物レポートのみ）
Repeating the calculations from Table 2 using IPv6 gives the results shown in Table 4. As can be seen, the overhead still increases with IPv6 when a mix of compound and reduced-size reports is used, but the effect is less pronounced than with compound reports only.
IPv6を使用して表2からの計算を繰り返すと、表4に示す結果が得られます。見られるように、化合物と減少したレポートの混合が使用されるとIPv6とともにオーバーヘッドが増加しますが、効果は複合レポートよりも顕著ではありません。のみ。
+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020 | 2 | 49.2 |
+--------------+-------------+----------------+
| 0.020 | 4 | 25.4 |
+--------------+-------------+----------------+
| 0.020 | 8 | 13.5 |
+--------------+-------------+----------------+
| 0.020 | 16 | 7.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 16.4 |
+--------------+-------------+----------------+
| 0.060 | 4 | 8.5 |
+--------------+-------------+----------------+
| 0.060 | 8 | 4.5 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.5 |
+--------------+-------------+----------------+
Table 4: Required RTCP Bandwidth for VoIP Feedback (Alternating Compound and Reduced-Size Reports) Using IPv6
表4：IPv6を使用したVoIPフィードバック（交互の化合物と縮小サイズのレポート）に必要なRTCP帯域幅
Consider a point-to-point video call between two end systems. There will be four RTP flows in this scenario (two audio and two video), with all four flows being active for essentially all the time (the audio flows will likely use voice activity detection and comfort noise to reduce the packet rate during silent periods, but this does not cause the transmissions to stop).
2つのエンドシステム間のポイントツーポイントビデオ通話を検討してください。このシナリオには4つのRTPフロー（2つのオーディオと2つのビデオ）があり、4つのフローすべてが基本的に常にアクティブになります（オーディオフローは、音声アクティビティ検出とコンフォートノイズを使用して、サイレント期間中のパケットレートを低下させる可能性があります。しかし、これは送信を停止させません）。
Assume all four flows are sent in a single RTP session, each using a separate SSRC. The RTCP reports from the co-located audio and video SSRCs at each end point are aggregated [RFC8108], the optimizations in [RFC8861] are used, and RTCP congestion control feedback is sent [RFC8888].
4つのフローすべてが単一のRTPセッションで送信され、それぞれが個別のSSRCを使用して送信されると仮定します。各エンドポイントでの共同配置オーディオおよびビデオSSRCからのRTCPのレポートは集約され[RFC8108]、[RFC8861]の最適化が使用され、RTCPの混雑制御フィードバックが送信されます[RFC8888]。
As in Section 3.1, when all members are senders, the RTCP reporting interval calculation in Sections 6.2 and 6.3 [RFC3550] and in [RFC4585] reduces to:
セクション3.1のように、すべてのメンバーが送信者である場合、セクション6.2および6.3 [RFC3550]および[RFC4585]のRTCP報告間隔の計算は次のようになります。
Trtcp = n * Srtcp / Brtcp
where n is the number of members in the session, Srtcp is the average RTCP packet size in octets, and Brtcp is the RTCP bandwidth in octets per second.
ここで、nはセッションのメンバーの数であり、SRTCPはオクテットの平均RTCPパケットサイズであり、BRTCPは1秒あたりのオクテットのRTCP帯域幅です。
The average RTCP packet size (Srtcp) depends on the amount of feedback sent in each RTCP packet, the number of members in the session, the size of source description (RTCP SDES) information sent, and the amount of congestion control feedback sent in each packet.
平均RTCPパケットサイズ（SRTCP）は、各RTCPパケットで送信されたフィードバックの量、セッションのメンバー数、送信されたソース説明（RTCP SDE）情報のサイズ、およびそれぞれで送信される渋滞制御フィードバックの量に依存します。パケット。
As a baseline, each RTCP packet will be a compound RTCP packet that contains an aggregate of a compound RTCP packet generated by the video SSRC and a compound RTCP packet generated by the audio SSRC. When the RTCP reporting group extensions are used, one of these SSRCs will be a reporting SSRC, to which the other SSRC will have delegated its reports. No reduced-size RTCP packets are sent.
ベースラインとして、各RTCPパケットは、ビデオSSRCによって生成された化合物RTCPパケットの集計と、Audio SSRCによって生成された化合物RTCPパケットを含む化合物RTCPパケットになります。RTCPレポートグループ拡張機能を使用すると、これらのSSRCの1つはレポートSSRCになり、他のSSRCがレポートを委任します。縮小サイズのRTCPパケットは送信されません。
The aggregated compound RTCP packet from the non-reporting SSRC will contain an RTCP SR packet, an RTCP SDES packet, and an RTCP Reporting Group Reporting Sources (RGRS) packet. The RTCP SR packet contains the 28-octet UDP/IP header (assuming IPv4 with no options) and sender information but no report blocks (since the reporting is delegated). The RTCP SDES packet will comprise a header (4 octets), the originating SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. If the CNAME follows [RFC7022] and [RFC8834], the CNAME chunk will be 18 octets in size and will be followed by one octet of padding and one terminating null octet to align the SDES packet to a 32-bit boundary ([RFC3550], Section 6.5), making the SDES packet 28 octets in size. The RTCP RGRS packet will be 12 octets in size. This gives a total of 28 + 28 + 12 = 68 octets.
非報告SSRCからの集約化された化合物RTCPパケットには、RTCP SRパケット、RTCP SDESパケット、およびRTCPレポートグループレポートソース（RGRS）パケットが含まれます。RTCP SRパケットには、28オクテットのUDP/IPヘッダー（オプションがないIPv4を想定）と送信者情報が含まれていますが、レポートブロックはありません（レポートは委任されているため）。RTCP SDESパケットには、ヘッダー（4オクテット）、発生するSSRC（4オクテット）、CNAMEチャンク、終了チャンク、およびパディングが含まれます。CNAMEが[RFC7022]と[RFC8834]に続く場合、CNAMEチャンクのサイズは18オクテットで、1オクテットのパディングと1つの終了NULLオクテットが続き、SDESパケットを32ビット境界に合わせます（[RFC3550]、セクション6.5）、SDESパケットの28オクテットをサイズにします。RTCP RGRSパケットのサイズは12オクテットになります。これにより、合計28 28 12 = 68オクテットが得られます。
The aggregated compound RTCP packet from the reporting SSRC will contain an RTCP SR packet, an RTCP SDES packet, and an RTCP congestion control feedback packet. The RTCP SR packet will contain two report blocks, one for each of the remote SSRCs (the report for the other local SSRC is suppressed by the reporting group extension), for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will comprise a header (4 octets), originating SSRC (4 octets), a CNAME chunk, a Reporting Group (RGRP) chunk, a terminating chunk, and any padding. If the CNAME follows [RFC7022] and [RFC8834], it will be 18 octets in size. The RGRP chunk similarly comprises 18 octets, the terminating chunk is comprised of 1 octet, and 3 octets of padding are needed, for a total of 48 octets. The RTCP congestion control feedback (CCFB) report comprises an 8-octet RTCP header and SSRC, a 4-octet report timestamp, and for each of the remote audio and video SSRCs, an 8-octet report header, 2 octets per packet reported upon, and padding to a 4-octet boundary if needed; that is, 8 + 4 + 8 + (2 * Nv) + 8 + (2 * Na), where Nv is the number of video packets per report and Na is the number of audio packets per report.
レポートSSRCからの集約化された化合物RTCPパケットには、RTCP SRパケット、RTCP SDESパケット、およびRTCP輻輳制御フィードバックパケットが含まれます。RTCP SRパケットには、リモートSSRCのそれぞれ（他のローカルSSRCのレポートはレポートグループ拡張によって抑制されます）の2つのレポートブロックが含まれ、合計28（2 * 24）= 76オクテットです。RTCP SDESパケットは、ヘッダー（4オクテット）、SSRC（4オクテット）、CNAMEチャンク、レポートグループ（RGRP）チャンク、終了チャンク、およびパディングを構成します。CNAMEが[RFC7022]と[RFC8834]に従うと、サイズが18オクターになります。同様に、RGRPチャンクは18オクテットで構成され、終端チャンクは1オクテットで構成され、合計48オクテットのために3オクツのパディングが必要です。RTCP混雑制御フィードバック（CCFB）レポートは、8オクテットのRTCPヘッダーとSSRC、4オクテットレポートタイムスタンプ、およびリモートオーディオおよびビデオSSRC、8オクテットレポートヘッダーの各リモートオーディオおよびビデオSSRCの各パケットごとに報告されたパケットあたり2オクテットあたり2オクテットで構成されています。、必要に応じて4オクテットの境界へのパディング。つまり、8 4 8（2 * nv）8（2 * na）。ここで、NVはレポートごとのビデオパケットの数、NAはレポートごとのオーディオパケットの数です。
The complete compound RTCP packet contains the RTCP packets from both the reporting and non-reporting SSRCs, an SRTCP trailer and authentication tag, and a UDP/IPv4 header. The size of this RTCP packet is therefore 262 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet contains reports from two SSRCs, the RTCP packet size is halved before use [RFC8108]. Accordingly, the size of the RTCP packets is:
完全な化合物RTCPパケットには、レポートと非報告のSSRC、SRTCPトレーラーと認証タグ、およびUDP/IPv4ヘッダーの両方からのRTCPパケットが含まれています。したがって、このRTCPパケットのサイズは262（2 * nv）（2 * na）オクテットです。集計RTCPパケットには2つのSSRCからのレポートが含まれているため、RTCPパケットサイズは使用する前に半分になります[RFC8108]。したがって、RTCPパケットのサイズは次のとおりです。
Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2
How many RTP packets does the RTCP XR congestion control feedback packet, included in these compound RTCP packets, report on? That is, what are the values of Nv and Na? This depends on the RTCP reporting interval (Trtcp), the video bit rate and frame rate (Rf), the audio bit rate and framing interval, and whether the receiver chooses to send congestion control feedback in each RTCP packet it sends.
これらの化合物RTCPパケットに含まれるRTCP XR輻輳制御フィードバックパケットは、いくつのRTPパケットが報告されていますか？つまり、NVとNAの値は何ですか？これは、RTCPレポート間隔（TRTCP）、ビデオビットレートとフレームレート（RF）、オーディオビットレートとフレーミング間隔、および受信者が送信する各RTCPパケットでうっ血制御フィードバックを送信することを選択するかどうかに依存します。
To simplify the calculation, assume it is desired to send one RTCP report for each frame of video received (i.e., Trtcp = 1 / Rf) and to include a congestion control feedback packet in each report. Assume that video has a constant bit rate and frame rate and that each frame of video has to fit into a 1500-octet MTU. Further, assume that the audio takes negligible bandwidth and that the audio framing interval can be varied within reasonable bounds, so that an integral number of audio frames align with video frame boundaries.
計算を簡素化するには、受信したビデオのフレームごとに1つのRTCPレポート（つまり、TRTCP = 1 / RF）に1つのRTCPレポートを送信し、各レポートに輻輳制御フィードバックパケットを含めることが望ましいと仮定します。ビデオには一定のビットレートとフレームレートがあり、ビデオの各フレームが1500オクテットのMTUに収まる必要があると仮定します。さらに、オーディオには帯域幅が無視できると、オーディオフレーミング間隔が合理的な境界内で変化し、ビデオフレームの境界に合わせたオーディオフレームが整列するようにすることができると仮定します。
Table 5 shows the resulting values of Nv and Na (the number of video and audio packets covered by each congestion control feedback report) for a range of data rates and video frame rates, assuming congestion control feedback is sent once per video frame. The table also shows the result of inverting the RTCP reporting interval calculation to find the corresponding RTCP bandwidth (Brtcp). The RTCP bandwidth is given in kbps and as a fraction of the data rate.
表5は、さまざまなデータレートとビデオフレームレートのNVとNA（各輻輳制御フィードバックレポートでカバーされているビデオおよびオーディオパケットの数）の結果の値を示しています。この表は、RTCP報告間隔計算を反転して、対応するRTCP帯域幅（BRTCP）を見つける結果を示しています。RTCP帯域幅は、KBPSおよびデータレートの一部として与えられます。
It can be seen that, for example, with a data rate of 1024 kbps and a video sent at 30 frames per second, the RTCP congestion control feedback report sent for each video frame will include reports on 3 video packets and 2 audio packets. The RTCP bandwidth needed to sustain this reporting rate is 127.5 kbps (12% of the data rate). This assumes an audio framing interval of 16.67 ms, so that 2 audio packets are sent for each video frame.
たとえば、1024 kbpsのデータレートと1秒あたり30フレームで送信されたビデオでは、各ビデオフレームに送信されるRTCP輻輳制御フィードバックレポートには、3つのビデオパケットと2つのオーディオパケットに関するレポートが含まれています。このレポートレートを維持するために必要なRTCP帯域幅は127.5 kbps（データレートの12％）です。これは、16.67ミリ秒のオーディオフレーミング間隔を想定しているため、各ビデオフレームに2つのオーディオパケットが送信されます。
+===========+==========+=============+=============+===============+
| Data Rate | Video | Video | Audio | Required RTCP |
| (kbps) | Frame | Packets per | Packets per | Bandwidth: |
| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
+===========+==========+=============+=============+===============+
| 100 | 8 | 1 | 6 | 34.5 (34%) |
+-----------+----------+-------------+-------------+---------------+
| 200 | 16 | 1 | 3 | 67.5 (33%) |
+-----------+----------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 125.6 (35%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 30 | 2 | 2 | 126.6 (18%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 249.4 (35%) |
+-----------+----------+-------------+-------------+---------------+
| 1024 | 30 | 3 | 2 | 127.5 (12%) |
+-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 251.2 (17%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 130.3 ( 6%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 253.1 (12%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 135.9 ( 3%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 258.8 ( 6%) |
+-----------+----------+-------------+-------------+---------------+
Table 5: Required RTCP Bandwidth, Reporting on Every Frame
表5：必要なRTCP帯域幅、すべてのフレームに関する報告
Use of reduced-size RTCP [RFC5506] would allow the SR and SDES packets to be omitted from some reports. These reduced-size RTCP packets would contain an RTCP RGRS packet from the non-reporting SSRC and an RTCP SDES RGRP packet and a congestion control feedback packet from the reporting SSRC. This will be 12 + 28 + 12 + 8 + (2 * Nv) + 8 + (2 * Na) octets, plus the SRTCP trailer and authentication tag and a UDP/IP header. That is, the size of the reduced-size packets would be (110 + (2 * Nv) + (2 * Na)) / 2 octets. Repeating the analysis above, but alternating compound and reduced-size reports, gives the results shown in Table 6.
縮小サイズのRTCP [RFC5506]を使用すると、SRおよびSDESパケットをいくつかのレポートから省略できます。これらの縮小サイズのRTCPパケットには、非報告SSRCからのRTCP RGRSパケットとRTCP SDES RGRPパケット、およびレポートSSRCからのうっ血制御フィードバックパケットが含まれます。これは、12 28 12 8（2 * nv）8（2 * na）オクテットに加えて、SRTCPトレーラーと認証タグとUDP/IPヘッダーになります。つまり、縮小サイズのパケットのサイズは（110（2 * nv）（2 * na）） / 2オクテットです。上記の分析を繰り返しますが、交互の化合物と縮小サイズのレポートでは、表6に示す結果が得られます。
+===========+==========+=============+=============+===============+
| Data Rate | Video | Video | Audio | Required RTCP |
| (kbps) | Frame | Packets per | Packets per | Bandwidth: |
| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
+===========+==========+=============+=============+===============+
| 100 | 8 | 1 | 6 | 25.0 (25%) |
+-----------+----------+-------------+-------------+---------------+
| 200 | 16 | 1 | 3 | 48.5 (24%) |
+-----------+----------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 90.0 (25%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 30 | 2 | 2 | 90.9 (12%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 178.1 (25%) |
+-----------+----------+-------------+-------------+---------------+
| 1024 | 30 | 3 | 2 | 91.9 ( 8%) |
+-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 180.0 (12%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 94.7 ( 4%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 181.9 ( 8%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 100.3 ( 2%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 187.5 ( 4%) |
+-----------+----------+-------------+-------------+---------------+
Table 6: Required RTCP Bandwidth, Reporting on Every Frame, with Reduced-Size Reports
表6：必要なRTCP帯域幅、すべてのフレームに関するレポート、縮小サイズのレポート付き
The use of reduced-size RTCP gives a noticeable reduction in the needed RTCP bandwidth and can be combined with reporting every few frames, rather than every frame. Overall, it is clear that the RTCP overhead can be reasonable across the range of data and frame rates if RTCP is configured carefully.
縮小サイズのRTCPを使用すると、必要なRTCP帯域幅が顕著に減少し、すべてのフレームではなく、数枚のフレームごとに報告することができます。全体として、RTCPが慎重に構成されている場合、RTCPオーバーヘッドがデータの範囲とフレームレート全体で合理的になる可能性があることは明らかです。
As discussed in Section 3.1, the reporting overhead will increase if IPv6 is used, due to the increased size of the IPv6 header. Table 7 shows the overhead in this case, compared to Table 6. As can be seen, the increase in overhead due to IPv6 rapidly becomes less significant as the data rate increases.
セクション3.1で説明したように、IPv6ヘッダーのサイズが増加するため、IPv6を使用するとレポートオーバーヘッドが増加します。表6は、表6と比較して、この場合のオーバーヘッドを示しています。見ているように、IPv6によるオーバーヘッドの増加は、データレートの増加に伴い急速に有意になります。
+===========+==========+=============+=============+===============+
| Data Rate | Video | Video | Audio | Required RTCP |
| (kbps) | Frame | Packets per | Packets per | Bandwidth: |
| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
+===========+==========+=============+=============+===============+
| 100 | 8 | 1 | 6 | 27.5 (27%) |
+-----------+----------+-------------+-------------+---------------+
| 200 | 16 | 1 | 3 | 53.5 (26%) |
+-----------+----------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 99.4 (28%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 30 | 2 | 2 | 100.3 (14%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 196.9 (28%) |
+-----------+----------+-------------+-------------+---------------+
| 1024 | 30 | 3 | 2 | 101.2 ( 9%) |
+-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 198.8 (14%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 104.1 ( 5%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 200.6 ( 9%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 109.7 ( 2%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 206.2 ( 5%) |
+-----------+----------+-------------+-------------+---------------+
Table 7: Required RTCP Bandwidth, Reporting on Every Frame, with Reduced-Size Reports, Using IPv6
表7：IPv6を使用して、すべてのフレームに関するレポート、すべてのフレームに関するレポートが必要なRTCP帯域幅が必要です
Practical systems will generally send some non-media traffic on the same path as the media traffic. This can include Session Traversal Utilities for NAT (STUN) / Traversal Using Relays around NAT (TURN) packets to keep alive NAT bindings [RFC8445], WebRTC data channel packets [RFC8831], etc. Such traffic also needs congestion control, but the means by which this is achieved is out of the scope of this memo.
実用的なシステムは、通常、メディアトラフィックと同じパスでメディア以外のトラフィックを送信します。これには、NAT（ターン）パケットの周りのリレーを使用したNAT（STUN） /トラバーサルのセッショントラバーサルユーティリティを使用して、NATバインディング[RFC8445]、WeBRTCデータチャネルパケット[RFC8831]などを維持することが含まれます。これが達成されることは、このメモの範囲外です。
RTCP, as it is currently specified, cannot be used to send per-packet congestion feedback with reasonable overhead.
RTCPは現在指定されているように、合理的なオーバーヘッドでパケットごとの混雑フィードバックを送信するために使用することはできません。
RTCP can, however, be used to send congestion feedback on each frame of video sent, provided the session bandwidth exceeds a couple of megabits per second (the exact rate depends on the number of session participants, the RTCP bandwidth fraction, what RTCP extensions are enabled, and how much detail of feedback is needed). For lower-rate sessions, the overhead of reporting on every frame becomes high but can be reduced to something reasonable by sending reports once per N frames (e.g., every second frame) or by sending reduced-size RTCP reports in between the regular reports. The improved compression of new video codecs exacerbates the reporting overhead for a given video quality level, although this is to some extent countered by the use of higher-quality video over time.
ただし、RTCPは、セッションの帯域幅が1秒あたり数メガビットを超えている場合、送信されたビデオの各フレームに関する混雑フィードバックを送信するために使用できます（正確なレートは、セッション参加者数、RTCP帯域幅の分数、RTCP拡張機能に依存します。有効になり、フィードバックの詳細が必要です）。低いレートセッションの場合、すべてのフレームでのレポートのオーバーヘッドは高くなりますが、Nフレームごとに1回レポートを送信するか、通常のレポートの間に縮小サイズのRTCPレポートを送信することで、合理的なものに削減できます。新しいビデオコーデックの改善された圧縮は、特定のビデオ品質レベルのレポートオーバーヘッドを悪化させますが、これはある程度高品質のビデオを使用することで対抗します。
If it is desired to use RTCP in something close to its current form for congestion feedback in WebRTC, the multimedia congestion control algorithm needs to be designed to work with feedback sent every few frames, since that fits within the limitations of RTCP. The provided feedback will be more detailed than just an acknowledgement, however, and will provide a loss bitmap, relative arrival time, and received Explicit Congestion Notification (ECN) marks for each packet sent. This will allow congestion control that is effective, if slowly responsive, to be implemented (there is guidance on providing effective congestion control in Section 3.1 of [RFC8085]).
WeBRTCの混雑フィードバックのために現在の形式に近いものでRTCPを使用することが望ましい場合は、RTCPの制限内に収まるため、数フレームごとに送信されるフィードバックで動作するようにマルチメディア輻輳制御アルゴリズムを設計する必要があります。ただし、提供されたフィードバックは、単なる承認よりも詳細であり、損失ビットマップ、相対的な到着時間を提供し、送信される各パケットの明示的な混雑通知（ECN）マークを受け取ります。これにより、ゆっくりと反応する場合、ゆっくりと対応することを実装するための渋滞制御が可能になります（[RFC8085]のセクション3.1で効果的な混雑制御を提供するガイダンスがあります）。
The format described in [RFC8888] seems sufficient for the needs of congestion control feedback. There is little point optimizing this format; the main overhead comes from the UDP/IP headers and the other RTCP packets included in the compound packets and can be lowered by using the extensions described in [RFC5506] and sending reports less frequently. The use of header compression [RFC2508] [RFC3545] [RFC5795] can also be beneficial.
[RFC8888]で説明されている形式は、輻輳制御フィードバックのニーズに十分であると思われます。この形式を最適化するポイントはほとんどありません。メインのオーバーヘッドは、UDP/IPヘッダーと複合パケットに含まれる他のRTCPパケットからのものであり、[RFC5506]で説明されている拡張機能を使用して低下させることができ、レポートを頻繁に送信できます。ヘッダー圧縮[RFC2508] [RFC3545] [RFC5795]の使用も有益です。
Further study of the scenarios of interest is needed to ensure that the analysis presented is applicable to other media topologies [RFC7667] and to sessions with different data rates and sizes of membership.
提示された分析が他のメディアトポロジー[RFC7667]およびさまざまなデータレートとメンバーシップのサイズのセッションに適用できるようにするために、関心のシナリオのさらなる研究が必要です。
An attacker that can modify or spoof RTCP congestion control feedback packets can manipulate the sender behavior to cause denial of service. This can be prevented by authentication and integrity protection of RTCP packets, for example, using the secure RTP profile [RFC3711] [RFC5124] or other means as discussed in [RFC7201].
RTCP混雑制御フィードバックパケットを変更またはスプーフィングできる攻撃者は、送信者の動作を操作してサービスの拒否を引き起こす可能性があります。これは、[RFC3711] [RFC5124]または[RFC7201]で説明されている他の手段を使用して、RTCPパケットの認証と整合性の保護によって防止できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[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>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[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>.
[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>.
[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>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <https://www.rfc-editor.org/info/rfc7022>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session",
RFC 8108, DOI 10.17487/RFC8108, March 2017,
<https://www.rfc-editor.org/info/rfc8108>.
[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>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session:
Grouping RTP Control Protocol (RTCP) Reception Statistics
and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
January 2021, <https://www.rfc-editor.org/info/rfc8861>.
[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
and R. Even, "Guidelines for Using the Multiplexing
Features of RTP to Support Multiple Media Streams",
RFC 8872, DOI 10.17487/RFC8872, January 2021,
<https://www.rfc-editor.org/info/rfc8872>.
[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control",
RFC 8888, DOI 10.17487/RFC8888, January 2021,
<https://www.rfc-editor.org/info/rfc8888>.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508,
DOI 10.17487/RFC2508, February 1999,
<https://www.rfc-editor.org/info/rfc2508>.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545,
DOI 10.17487/RFC3545, July 2003,
<https://www.rfc-editor.org/info/rfc3545>.
[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>.
[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>.
[RFC5795] Sandlund, K., Pelletier, G., and L. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<https://www.rfc-editor.org/info/rfc7667>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[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>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
Thanks to Bernard Aboba, Martin Duke, Linda Dunbar, Gorry Fairhurst, Ingemar Johansson, Shuping Peng, Alvaro Retana, Zahed Sarker, John Scudder, Éric Vyncke, Magnus Westerlund, and the members of the RMCAT feedback design team for their feedback.
バーナード・アボバ、マーティン・デューク、リンダ・ダンバー、ゴーリー・フェアハースト、インゲマー・ヨハンソン、シュピング・ペン、アルバロ・レターナ、ザヘド・サルカー、ジョン・スカダー、エリック・ヴィンケ、マグナス・ウェスターランド、およびRMCATフィードバックデザインチームのメンバーに感謝します。
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow
G12 8QQ
United Kingdom
Email: csp@csperkins.org