RFC 8888 - RTP Control Protocol (RTCP) Feedback for Congestion Control 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8888.html
タイトル : RFC 8888 - 輻輳制御のためのRTP制御プロトコル（RTCP）フィードバック
翻訳編集 : 自動生成

[要約] RFC 8888は、RTP制御プロトコル（RTCP）フィードバックを通じた過負荷制御に関する標準です。このRFCの目的は、リアルタイム通信セッションにおける適切な過負荷制御を実現するための仕組みを提供することです。

Internet Engineering Task Force (IETF)                         Z. Sarker
Request for Comments: 8888                                   Ericsson AB
Category: Standards Track                                     C. Perkins
ISSN: 2070-1721                                    University of Glasgow
                                                                V. Singh
                                                            callstats.io
                                                              M. Ramalho
                                                           AcousticComms
                                                            January 2021

RTP Control Protocol (RTCP) Feedback for Congestion Control

輻輳制御のためのRTP制御プロトコル（RTCP）フィードバック

Abstract

概要

An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control.

効果的なRTP輻輳制御アルゴリズムは、標準RTP制御プロトコル（RTCP）送信側レポート（SR）および受信側レポート（RR）パケットによって提供されるパケット損失、タイミング、および明示的輻輳通知（ECN）マークに関するよりきめ細かいフィードバックを必要とする。。このドキュメントでは、RTPを使用して対話型リアルタイムトラフィックの輻輳制御を可能にするように意図されたRTCPフィードバックメッセージについて説明します。フィードバックメッセージは、送信側の受信機が送信者が輻輳制御を実行するために必要な情報を含む送信者RTCPフィードバックパケットに送信される送信者ベースの輻輳制御アルゴリズムで使用するように設計されています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8888.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8888で入手できます。

著作権表示

著作権（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.

このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  RTCP Feedback for Congestion Control
     3.1.  RTCP Congestion Control Feedback Report
   4.  Feedback Frequency and Overhead
   5.  Response to Loss of Feedback Packets
   6.  SDP Signaling
   7.  Relationship to RFC 6679
   8.  Design Rationale
   9.  IANA Considerations
   10. Security Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

For interactive real-time traffic, such as video conferencing flows, the typical protocol choice is the Real-time Transport Protocol (RTP) [RFC3550] running over the User Datagram Protocol (UDP). RTP does not provide any guarantee of Quality of Service (QoS), reliability, or timely delivery, and expects the underlying transport protocol to do so. UDP alone certainly does not meet that expectation. However, the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by which the receiver of an RTP flow can periodically send transport and media quality metrics to the sender of that RTP flow. This information can be used by the sender to perform congestion control. In the absence of standardized messages for this purpose, designers of congestion control algorithms have developed proprietary RTCP messages that convey only those parameters needed for their respective designs. As a direct result, the different congestion control designs are not interoperable. To enable algorithm evolution as well as interoperability across designs (e.g., different rate adaptation algorithms), it is highly desirable to have a generic congestion control feedback format.

ビデオ会議フローなどの対話型リアルタイムトラフィックの場合、典型的なプロトコル選択は、ユーザーデータグラムプロトコル（UDP）を介して実行されているリアルタイムトランスポートプロトコル（RFC3550]です。 RTPは、サービス品質（QoS）、信頼性、またはタイムリーな配達を保証するものではなく、基礎となるトランスポートプロトコルがそうすることを期待しています。 UDPだけでは確かにその期待を満たしていません。ただし、RTP制御プロトコル（RFC3550]は、RTPフローの受信側が定期的にトランスポートおよびメディア品質メトリックをそのRTPフローの送信者に周期的に送信できるメカニズムを提供します。この情報は、送信者が輻輳制御を実行するために使用できます。この目的のための標準化されたメッセージがない場合、輻輳制御アルゴリズムの設計者は、それぞれの設計に必要なパラメータのみを伝える独自のRTCPメッセージを開発しました。直接的な結果として、異なる輻輳制御設計は相互運用可能ではありません。デザイン（例えば、異なるレート適応アルゴリズム）にわたる相互運用性と同様にアルゴリズムの進化を可能にするために、一般的な輻輳制御フィードバックフォーマットを有することが非常に望ましい。

To help achieve interoperability for unicast RTP congestion control, this memo specifies a common RTCP feedback packet format that can be used by Network-Assisted Dynamic Adaptation (NADA) [RFC8698], Self-Clocked Rate Adaptation for Multimedia (SCReAM) [RFC8298], Google Congestion Control [Google-GCC], and Shared Bottleneck Detection [RFC8382], and, hopefully, also by future RTP congestion control algorithms.

ユニキャストRTP輻輳制御の相互運用性を達成するのに役立つために、このメモはネットワーク支援動的適応（NADA）[RFC8698]、マルチメディアの自己クロックレート適応（Scream）[RFC8298]、一般的なRTCPフィードバックパケット形式を指定します。Googleの輻輳制御[Google-GCC]と共有ボトルネック検出[RFC8382]、ならびに将来のRTP輻輳制御アルゴリズムによっても、

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

In addition, the terminology defined in [RFC3550], [RFC4585], and [RFC5506] applies.

また、[RFC3550]、[RFC4585]、[RFC5506]で定義されている用語が適用されます。

3. RTCP Feedback for Congestion Control

3. 輻輳制御のためのRTCPフィードバック

Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control [Google-GCC], and Shared Bottleneck Detection [RFC8382], the following per-RTP packet congestion control feedback information has been determined to be necessary:

NADA [RFC8698]の分析、Scream [RFC8298]、Google輻輳制御[Google-GCC]、および共有ボトルネック検出[RFC8382]の分析に基づいて、以下のRTPごとのパケット輻輳制御フィードバック情報が必要であると判断されました。

RTP Sequence Number: The receiver of an RTP flow needs to feed the sequence numbers of the received RTP packets back to the sender, so the sender can determine which packets were received and which were lost. Packet loss is used as an indication of congestion by many congestion control algorithms.

RTPシーケンス番号：RTPフローの受信機は、受信したRTPパケットのシーケンス番号を送信者に送り返す必要があるため、送信者はどのパケットを受信して失われたかを判断できます。パケット損失は、多くの輻輳制御アルゴリズムによる輻輳の指標として使用されます。

Packet Arrival Time: The receiver of an RTP flow needs to feed the arrival time of each RTP packet back to the sender. Packet delay and/or delay variation (jitter) is used as a congestion signal by some congestion control algorithms.

パケット到着時間：RTPフローの受信機は、各RTPパケットの到着時間を送信者に返す必要があります。パケット遅延および/または遅延変動（ジッタ）は、いくつかの輻輳制御アルゴリズムによって輻輳信号として使用されます。

Packet Explicit Congestion Notification (ECN) Marking: If ECN [RFC3168] [RFC6679] is used, it is necessary to feed back the 2-bit ECN mark in received RTP packets, indicating for each RTP packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN Congestion Experienced (ECN-CE). ("ECT" stands for "ECN-Capable Transport".) If the path used by the RTP traffic is ECN capable, the sender can use ECN-CE marking information as a congestion control signal.

Packet Explicit輻輳通知（ECN）マーキング：ECN [RFC3168] [RFC6679]が使用されている場合は、受信したRTPパケット内の2ビットECNマークをフィードバックする必要があります。ECT（0）、ECT（1）、またはECNの輻輳経験（ECN-CE）。（「ECT」はECN対応輸送」を表します。）RTPトラフィックで使用されるパスがECNが可能な場合、送信者はECN-CEマーキング情報を輻輳制御信号として使用できます。

Every RTP flow is identified by its Synchronization Source (SSRC) identifier. Accordingly, the RTCP feedback format needs to group its reports by SSRC, sending one report block per received SSRC.

すべてのRTPフローは、その同期ソース（SSRC）識別子によって識別されます。したがって、RTCPフィードバックフォーマットはSSRCによってそのレポートをグループ化する必要があり、受信したSSRCごとに1つのレポートブロックを送信します。

As a practical matter, we note that host operating system (OS) process interruptions can occur at inopportune times. Accordingly, recording RTP packet send times at the sender, and the corresponding RTP packet arrival times at the receiver, needs to be done with deliberate care. This is because the time duration of host OS interruptions can be significant relative to the precision desired in the one-way delay estimates. Specifically, the send time needs to be recorded at the last opportunity prior to transmitting the RTP packet at the sender, and the arrival time at the receiver needs to be recorded at the earliest available opportunity.

実際的な問題として、ホストオペレーティングシステム（OS）プロセスの中断が不適切な時間で発生する可能性があることに注意してください。したがって、送信側でRTPパケットの送信時間を記録し、受信機での対応するRTPパケット到着時間を慎重にする必要があります。これは、一方向遅延推定値に望まれる精度に対してホストOSの中断の期間が大きくなる可能性があるためです。具体的には、送信時間は、送信者にRTPパケットを送信する前に最後の機会に記録される必要があり、受信者の到着時間は利用可能な早い機会に記録される必要がある。

3.1. RTCP Congestion Control Feedback Report

3.1. RTCP輻輳制御フィードバックレポート

Congestion control feedback can be sent as part of a regular scheduled RTCP report or in an RTP/AVPF early feedback packet. If sent as early feedback, congestion control feedback MAY be sent in a non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] is used.

輻輳制御フィードバックは、通常のスケジュールされたRTCPレポートまたはRTP / AVPF早期フィードバックパケットの一部として送信できます。早期フィードバックとして送信された場合、RTP / AVPFプロファイル[RFC4585]またはRTP / SAVPFプロファイル[RFC5124]が使用されている場合は、非複合RTCPパケット[RFC5506]で輻輳制御フィードバックを送信できます。

Irrespective of how it is transported, the congestion control feedback is sent as a Transport-Layer Feedback Message (RTCP packet type 205). The format of this RTCP packet is shown in Figure 1:

それがどのように輸送されるかにかかわらず、輻輳制御フィードバックはトランスポート層フィードバックメッセージとして送信される（RTCPパケットタイプ205）。このRTCPパケットの形式を図1に示します。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P| FMT=11  |   PT = 205    |          length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 SSRC of RTCP packet sender                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   SSRC of 1st RTP Stream                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          begin_seq            |          num_reports          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|ECN|  Arrival time offset    | ...                           .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   SSRC of nth RTP Stream                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          begin_seq            |          num_reports          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|ECN|  Arrival time offset    | ...                           |
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Report Timestamp (32 bits)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: RTCP Congestion Control Feedback Packet Format

図1：RTCP輻輳制御フィードバックパケットフォーマット

The first 8 octets comprise a standard RTCP header, with PT=205 and FMT=11 indicating that this is a congestion control feedback packet, and with the SSRC set to that of the sender of the RTCP packet.

最初の8オクテットは、PT = 205、およびFMT = 11で、これが輻輳制御フィードバックパケットであり、SSRCがRTCPパケットの送信側に設定されていることを示しています。

Section 6.1 of [RFC4585] requires the RTCP header to be followed by the SSRC of the RTP flow being reported upon. Accordingly, the RTCP header is followed by a report block for each SSRC from which RTP packets have been received, followed by a Report Timestamp.

[RFC4585]のセクション6.1には、RTCPヘッダーの後にRTPフローのSSRCが報告されている必要があります。したがって、RTCPヘッダの後には、RTPパケットが受信された各SSRCについてレポートブロックが続き、その後にレポートタイムスタンプが続きます。

Each report block begins with the SSRC of the received RTP stream on which it is reporting. Following this, the report block contains a 16-bit packet metric block for each RTP packet that has a sequence number in the range begin_seq to begin_seq+num_reports inclusive (calculated using arithmetic modulo 65536 to account for possible sequence number wrap-around). If the number of 16-bit packet metric blocks included in the report block is not a multiple of two, then 16 bits of zero padding MUST be added after the last packet metric block, to align the end of the packet metric blocks with the next 32-bit boundary. The value of num_reports MAY be 0, indicating that there are no packet metric blocks included for that SSRC. Each report block MUST NOT include more than 16384 packet metric blocks (i.e., it MUST NOT report on more than one quarter of the sequence number space in a single report).

各レポートブロックは、それが報告している受信したRTPストリームのSSRCから始まります。これに続いて、レポートブロックは、範囲begin_seqからbegin_seq num_reportsへのシーケンス番号を持つ16ビットパケットメトリックブロックを含みます（算術モジュロ65536を使用して計算されたシーケンス番号ラップアラートを考慮して計算）。レポートブロックに含まれる16ビットパケットメトリックブロックの数が2つの倍数ではない場合は、最後のパケットメトリックブロックの後に16ビットのゼロパディングを追加する必要があります。パケットメトリックブロックの末尾を次に揃えます。32ビット境界num_reportsの値は0になり、そのSSRCのパケットメトリックブロックが含まれていないことを示します。各レポートブロックには、16384を超えるパケットメトリックブロックを含めてはなりません（すなわち、単一のレポート内のシーケンス番号スペースの1分の1つ以上の四半期に報告してはいけません）。

The contents of each 16-bit packet metric block comprise the R, ECN, and ATO fields as follows:

各16ビットパケットメトリックブロックの内容は、次のようにR、ECN、およびATOフィールドを構成します。

Received (R, 1 bit): A boolean that indicates whether the packet was received. 0 indicates that the packet was not yet received and the subsequent 15 bits (ECN and ATO) in this 16-bit packet metric block are also set to 0 and MUST be ignored. 1 indicates that the packet was received and the subsequent bits in the block need to be parsed.

受信（R、1ビット）：パケットが受信されたかどうかを示すブール値。0は、この16ビットパケットメトリックブロック内のその後の15ビット（ECNとATO）も0に設定されており、無視する必要があります。1は、パケットが受信され、ブロック内の後続ビットを解析する必要があることを示します。

ECN (2 bits): The echoed ECN mark of the packet. These bits are set to 00 if not received or if ECN is not used.

ECN（2ビット）：パケットのエコーECNマーク。これらのビットは、受信していない場合、またはECNが使用されていない場合は00に設定されます。

Arrival time offset (ATO, 13 bits): The arrival time of the RTP packet at the receiver, as an offset before the time represented by the Report Timestamp (RTS) field of this RTCP congestion control feedback report. The ATO field is in units of 1/1024 seconds (this unit is chosen to give exact offsets from the RTS field) so, for example, an ATO value of 512 indicates that the corresponding RTP packet arrived exactly half a second before the time instant represented by the RTS field. If the measured value is greater than 8189/1024 seconds (the value that would be coded as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over-range measurement. If the measurement is unavailable or if the arrival time of the RTP packet is after the time represented by the RTS field, then an ATO value of 0x1FFF MUST be reported for the packet.

到着時間オフセット（ATO、13ビット）：受信機でのRTPパケットの到着時間（RTCP輻輳制御フィードバックレポート）のレポートタイムスタンプ（RTS）フィードバックレポート。ATOフィールドは1/1024秒単位です（このユニットはRTSフィールドから正確なオフセットを与えるように選択されています）。RTSフィールドによって表されます。測定値が8189/1024秒より大きい場合（0x1FFDとして符号化される値）場合、値0x1FFEは、過距離測定を示すために報告されなければなりません。測定が利用できない場合、またはRTPパケットの到着時間がRTSフィールドで表される時間の後に、ATO値の0x1FFFのATO値をパケットに報告する必要があります。

The RTCP congestion control feedback report packet concludes with the Report Timestamp field (RTS, 32 bits). This denotes the time instant on which this packet is reporting and is the instant from which the arrival time offset values are calculated. The value of the RTS field is derived from the same clock used to generate the NTP timestamp field in RTCP Sender Report (SR) packets. It is formatted as the middle 32 bits of an NTP format timestamp, as described in Section 4 of [RFC3550].

RTCP輻輳制御フィードバックレポートパケットは、レポートタイムスタンプフィールド（RTS、32ビット）で終了します。これは、このパケットが報告している時刻を表し、到着時間オフセット値が計算される瞬間です。RTSフィールドの値は、RTCP Sender Report（SR）パケットのNTP TimesTampフィールドを生成するために使用されるのと同じクロックから導出されます。[RFC3550]のセクション4で説明されているように、NTPフォーマットのタイムスタンプの中央32ビットとしてフォーマットされています。

RTCP Congestion Control Feedback Packets SHOULD include a report block for every active SSRC. The sequence number ranges reported on in consecutive reports for a given SSRC will generally be contiguous, but overlapping reports MAY be sent (and need to be sent in cases where RTP packet reordering occurs across the boundary between consecutive reports). If an RTP packet was reported as received in one report, that packet MUST also be reported as received in any overlapping reports sent later that cover its sequence number range. If feedback reports covering overlapping sequence number ranges are sent, information in later feedback reports may update any data sent in previous reports for RTP packets included in both feedback reports.

RTCP輻輳制御フィードバックパケットには、Active SSRCごとにレポートブロックを含める必要があります。特定のSSRCの連続レポートで報告されたシーケンス番号範囲は、一般に連続していますが、重複するレポートを送信することができます（そしてRTPパケットの並べ替えが連続したレポート間の境界を越えて行われる場合には送信する必要があります）。RTPパケットが1つのレポートで受信されたとおりに報告された場合、そのパケットは、そのシーケンス番号の範囲をカバーしているすべての重複レポートで受信されたとおりに報告されなければなりません。オーバーラップシーケンス番号範囲をカバーするフィードバックレポートが送信されると、後のフィードバックレポートの情報は、両方のフィードバックレポートに含まれるRTPパケットの前のレポートで送信されたデータを更新できます。

RTCP Congestion Control Feedback Packets can be large if they are sent infrequently relative to the number of RTP data packets. If an RTCP Congestion Control Feedback Packet is too large to fit within the path MTU, its sender SHOULD split it into multiple feedback packets. The RTCP reporting interval SHOULD be chosen such that feedback packets are sent often enough that they are small enough to fit within the path MTU. ([RTCP-Multimedia-Feedback] discusses how to choose the reporting interval; specifications for RTP congestion control algorithms can also provide guidance.)

RTCP輻輳制御フィードバックパケットは、RTPデータパケットの数を基準にして頻繁に送信される場合は大きくなる可能性があります。RTCP輻輳制御フィードバックパケットがパスMTU内に収まるように大きすぎる場合、その送信側はそれを複数のフィードバックパケットに分割する必要があります。RTCP報告間隔は、フィードバックパケットが経路MTU内に収まるのに十分小さいほど十分に頻繁に送信されるように選択されるべきである。（[RTCPマルチメディアフィードバック]レポート間隔の選択方法について説明します。RTP輻輳制御アルゴリズムの仕様もガイダンスを提供できます。）

If duplicate copies of a particular RTP packet are received, then the arrival time of the first copy to arrive MUST be reported. If any of the copies of the duplicated packet are ECN-CE marked, then an ECN-CE mark MUST be reported for that packet; otherwise, the ECN mark of the first copy to arrive is reported.

特定のRTPパケットの複製コピーが受信された場合は、最初のコピーの到着時間が報告されなければなりません。複製されたパケットのコピーのいずれかがECN-CEマークされている場合は、そのパケットについてECN-CEマークを報告する必要があります。それ以外の場合は、最初のコピーのECNマークが到着します。

If no packets are received from an SSRC in a reporting interval, a report block MAY be sent with begin_seq set to the highest sequence number previously received from that SSRC and num_reports set to 0 (or the report can simply be omitted). The corresponding Sender Report / Receiver Report (SR/RR) packet will have a non-increased extended highest sequence number received field that will inform the sender that no packets have been received, but it can ease processing to have that information available in the congestion control feedback reports too.

報告期間内のSSRCからパケットを受信しない場合、そのSSRCから以前に受信された最上位シーケンス番号にSETSをSETSEQと送信し、NUM_REPORTSが0に設定された最上位シーケンス番号（またはレポートを単に省略することができます）に応答します。対応する送信者レポート/受信者レポート（SR / RR）パケットには、送信者にパケットが受信されていないことを送信者に通知するための増加した拡張上級シーケンス番号受信フィールドがありますが、その情報を輻輳で利用できるようにする処理を簡単にすることができます。フィードバックレポートを制御します。

A report block indicating that certain RTP packets were lost is not to be interpreted as a request to retransmit the lost packets. The receiver of such a report might choose to retransmit such packets, provided a retransmission payload format has been negotiated, but there is no requirement that it do so.

特定のRTPパケットが失われたことを示すレポートブロックは、失われたパケットを再送信する要求として解釈されるべきではありません。そのようなレポートの受信者は、再送信ペイロードフォーマットがネゴシエートされている場合に、そのようなパケットを再送信することを選択するかもしれませんが、そうする必要はありません。

4. Feedback Frequency and Overhead

4. フィードバック周波数とオーバーヘッド

There is a trade-off between speed and accuracy of reporting, and the overhead of the reports. [RTCP-Multimedia-Feedback] discusses this trade-off, suggests desirable RTCP feedback rates, and provides guidance on how to configure, for example, the RTCP bandwidth fraction to make appropriate use of the reporting block described in this memo. Specifications for RTP congestion control algorithms can also provide guidance.

レポートのスピードと正確さとレポートのオーバーヘッドの間にトレードオフがあります。[RTCP-MULTIMEDIA-FEEDBACK]このトレードオフを議論し、望ましいRTCPフィードバック率を提案し、例えばこのメモに記述されているレポートブロックを適切に使用するためのRTCP帯域幅分数を構成する方法についてのガイダンスを提供します。RTP輻輳制御アルゴリズムの仕様もガイダンスを提供できます。

It is generally understood that congestion control algorithms work better with more frequent feedback. However, RTCP bandwidth and transmission rules put some upper limits on how frequently the RTCP feedback messages can be sent from an RTP receiver to the RTP sender. In many cases, sending feedback once per frame is an upper bound before the reporting overhead becomes excessive, although this will depend on the media rate and more frequent feedback might be needed with high-rate media flows [RTCP-Multimedia-Feedback]. Analysis [feedback-requirements] has also shown that some candidate congestion control algorithms can operate with less frequent feedback, using a feedback interval range of 50-200 ms. Applications need to negotiate an appropriate congestion control feedback interval at session setup time, based on the choice of congestion control algorithm, the expected media bitrate, and the acceptable feedback overhead.

輻輳制御アルゴリズムがより頻繁なフィードバックでよりよく機能することが一般的に理解されています。ただし、RTCP帯域幅と送信ルールはRTCPフィードバックメッセージをRTP受信者からRTP送信者に送信できる程度の上限を設定します。多くの場合、フレームごとにフィードバックを送信することは、報告のオーバーヘッドが過剰になる前の上限になりますが、これはメディアレートによって異なりますが、高速メディアフロー[RTCP-MULTIMEDIA-FEEDBACK]では、より頻繁なフィードバックが必要になる可能性があります。分析[フィードバック要件]はまた、50~200ミリ秒のフィードバック間隔範囲を使用して、いくつかの候補輻輳制御アルゴリズムがより少ない頻度のフィードバックで動作できることを示しています。アプリケーションは、輻輳制御アルゴリズムの選択、予想メディアビットレート、および許容フィードバックオーバーヘッドの選択に基づいて、セッションセットアップ時に適切な輻輳制御フィードバック間隔をネゴシエートする必要があります。

5. Response to Loss of Feedback Packets

5. フィードバックパケットの損失に対する対応

Like all RTCP packets, RTCP Congestion Control Feedback Packets might be lost. All RTP congestion control algorithms MUST specify how they respond to the loss of feedback packets.

すべてのRTCPパケットと同様に、RTCP輻輳制御フィードバックパケットが失われる可能性があります。すべてのRTP輻輳制御アルゴリズムは、フィードバックパケットの損失にどのように応答するかを指定する必要があります。

RTCP packets do not contain a sequence number, so loss of feedback packets has to be inferred based on the time since the last feedback packet. If only a single congestion control feedback packet is lost, an appropriate response is to assume that the level of congestion has remained roughly the same as the previous report. However, if multiple consecutive congestion control feedback packets are lost, then the media sender SHOULD rapidly reduce its sending rate as this likely indicates a path failure. The RTP circuit breaker specification [RFC8083] provides further guidance.

RTCPパケットにシーケンス番号が含まれていないため、最後のフィードバックパケット以降の時間に基づいてフィードバックパケットの損失を推測する必要があります。単一の輻輳制御フィードバックパケットのみが失われた場合、適切な応答は、輻輳のレベルが前のレポートとほぼ同じままであると仮定することです。しかしながら、複数の連続した輻輳制御フィードバックパケットが失われると、メディア送信者はその送信速度を迅速に減少させるはずであるので、これは経路失敗を示す可能性が高い。RTPサーキットブレーカ仕様[RFC8083]はさらなるガイダンスを提供します。

6. SDP Signaling

6. SDPシグナリング

A new "ack" feedback parameter, "ccfb", is defined for use with the "a=rtcp-fb:" Session Description Protocol (SDP) extension to indicate the use of the RTP Congestion Control Feedback Packet format defined in Section 3. The ABNF definition [RFC5234] of this SDP parameter extension is:

新しい「ACK」フィードバックパラメータ「CCFB」は、セクション3で定義されているRTP輻輳制御フィードバックパケットフォーマットの使用を示すために、「A = RTCP-FB：」セッション記述プロトコル（SDP）拡張子と共に使用するために定義されています。このSDPパラメータ拡張のABNF定義[RFC5234]は次のとおりです。

           rtcp-fb-ack-param = <See Section 4.2 of [RFC4585]>
           rtcp-fb-ack-param =/ ccfb-par
           ccfb-par          = SP "ccfb"

The payload type used with "ccfb" feedback MUST be the wildcard type ("*"). This implies that the congestion control feedback is sent for all payload types in use in the session, including any Forward Error Correction (FEC) and retransmission payload types. An example of the resulting SDP attribute is:

「CCFB」フィードバックで使用されるペイロードタイプは、ワイルドカードタイプ（ "*"）でなければなりません。これは、順方向誤り訂正（FEC）および再送ペイロードタイプを含む、セッションで使用されているすべてのペイロードタイプに対して輻輳制御フィードバックが送信されることを意味します。結果のSDP属性の例は次のとおりです。

           a=rtcp-fb:* ack ccfb

The offer/answer rules for these SDP feedback parameters are specified in Section 4.2 of the RTP/AVPF profile [RFC4585].

これらのSDPフィードバックパラメータのオファー/アンサールールは、RTP / AVPFプロファイル[RFC4585]のセクション4.2で指定されています。

An SDP offer might indicate support for both the congestion control feedback mechanism specified in this memo and one or more alternative congestion control feedback mechanisms that offer substantially the same semantics. In this case, the answering party SHOULD include only one of the offered congestion control feedback mechanisms in its answer. If a subsequent offer containing the same set of congestion control feedback mechanisms is received, the generated answer SHOULD choose the same congestion control feedback mechanism as in the original answer where possible.

SDPオファーは、このメモで指定されている輻輳制御フィードバックメカニズムと、実質的に同じ意味論を提供する1つ以上の代替輻輳制御フィードバックメカニズムの両方のサポートを示している可能性があります。この場合、留守パーティには、答えの輻輳制御フィードバックメカニズムのうちの1つだけを含める必要があります。同じ輻輳制御フィードバックメカニズムを含む後続のオファーが受信された場合、生成された回答は可能な限り元の答えのように同じ輻輳制御フィードバックメカニズムを選択する必要があります。

When the SDP BUNDLE extension [RFC8843] is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT [RFC8859].

SDPバンドル拡張[RFC8843]が多重化に使用される場合は、「a = rtcp-fb：」属性に属性が同一のPT [RFC8859]を多重化しています。

7. Relationship to RFC 6679

7. RFC 6679との関係

The use of Explicit Congestion Notification (ECN) with RTP is described in [RFC6679], which specifies how to negotiate the use of ECN with RTP and defines an RTCP ECN Feedback Packet to carry ECN feedback reports. It uses an SDP "a=ecn-capable-rtp:" attribute to negotiate the use of ECN, and the "a=rtcp-fb:" attribute with the "nack" parameter "ecn" to negotiate the use of RTCP ECN Feedback Packets.

RTPを使用した明示的な輻輳通知（ECN）の使用は[RFC6679]で説明されています。これは、RTPを使用してECNの使用をネゴシエートする方法を指定し、ECNフィードバックレポートを搬送するためのRTCP ECNフィードバックパケットを定義します。ECNの使用をネゴシエートするためのSDP "A = ECN-abe-rtp："属性を使用し、RTCP ECNフィードバックの使用をネゴシエートするための "a = rtcp-fb："属性を "a = rtcp-fb："属性にネゴシエートします。パケット

The RTCP ECN Feedback Packet is not useful when ECN is used with the RTP Congestion Control Feedback Packet defined in this memo, since it provides duplicate information. When congestion control feedback is to be used with RTP and ECN, the SDP offer generated MUST include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" to indicate that the RTP Congestion Control Feedback Packet can be used. The "a=rtcp-fb:" attribute MAY also include the "nack" parameter "ecn" to indicate that the RTCP ECN Feedback Packet is also supported. If an SDP offer signals support for both RTP Congestion Control Feedback Packets and the RTCP ECN Feedback Packet, the answering party SHOULD signal support for one, but not both, formats in its SDP answer to avoid sending duplicate feedback.

RTCP ECNフィードバックパケットは、このメモに定義されたRTP輻輳制御フィードバックパケットとともに、重複した情報を提供するため、ECNが使用されている場合には役立ちません。輻輳制御フィードバックをRTPとECNで使用する場合、生成されたSDPオファーには、「A = RTCP-FB：」属性とともに、ECNサポートをネゴシエートするための「a = ecn-abe-rtp：」属性を含める必要があります。RTP輻輳制御フィードバックパケットを使用できることを示す「ACK」パラメータ「CCFB」。「a = rtcp-fb：」属性には、RTCP ECNフィードバックパケットもサポートされていることを示すために「NACK」パラメータ「ECN」を含み得る。SDPがRTP輻輳制御フィードバックパケットとRTCP ECNフィードバックパケットの両方に対してSDPをサポートしている場合、応答側は1つのサポートをサポートする必要がありますが、重複フィードバックの送信を避けるために、SDP回答の両方のフォーマットではありません。

When using ECN with RTP, the guidelines in Section 7.2 of [RFC6679] MUST be followed to initiate the use of ECN in an RTP session. The guidelines in Section 7.3 of [RFC6679] regarding the ongoing use of ECN within an RTP session MUST also be followed, with the exception that feedback is sent using the RTCP Congestion Control Feedback Packets described in this memo rather than using RTP ECN Feedback Packets. Similarly, the guidance in Section 7.4 of [RFC6679] related to detecting failures MUST be followed, with the exception that the necessary information is retrieved from the RTCP Congestion Control Feedback Packets rather than from RTP ECN Feedback Packets.

ECNをRTPで使用する場合、[RFC6679]のセクション7.2のガイドラインに従って、RTPセッションでのECNの使用を開始する必要があります。RTPセッション内のECNの継続的なECNの使用に関して、[RFC6679]のセクション7.3のガイドラインにも従う必要があります。これに従う必要があります。これを除いて、RTP ECNフィードバックパケットを使用するのではなく、このメモに記述されているRTCP輻輳制御フィードバックパケットを使用して送信されます。同様に、障害の検出に関連する[RFC6679]のセクション7.4のガイダンスに従う必要があり、RTP ECNフィードバックパケットからではなくRTCP輻輳制御フィードバックパケットから取得されることを除いて。

8. Design Rationale

8. デザイン根拠

The primary function of RTCP SR/RR packets is to report statistics on the reception of RTP packets. The reception report blocks sent in these packets contain information about observed jitter, fractional packet loss, and cumulative packet loss. It was intended that this information could be used to support congestion control algorithms, but experience has shown that it is not sufficient for that purpose. An efficient congestion control algorithm requires more fine-grained information on per-packet reception quality than is provided by SR/RR packets to react effectively. The feedback format defined in this memo provides such fine-grained feedback.

RTCP SR / RRパケットの主な機能は、RTPパケットの受信に関する統計を報告することです。これらのパケットで送信された受信レポートブロックには、観測されたジッタ、小数パケット損失、および累積パケット損失に関する情報が含まれています。この情報は輻輳制御アルゴリズムをサポートするために使用され得るが、経験はその目的には十分ではないことを示している。効率的な輻輳制御アルゴリズムは、効果的に反応するようにSR / RRパケットによって提供されるよりもパケットごとの受信品質に関するよりきめ細かい情報を必要とする。このメモに定義されているフィードバックフォーマットは、そのような精密なフィードバックを提供します。

Several other RTCP extensions also provide more detailed feedback than SR/RR packets:

他のいくつかのRTCP拡張機能は、SR / RRパケットよりも詳細なフィードバックを提供します。

TMMBR: The codec control messages for the RTP/AVPF profile [RFC5104] include a Temporary Maximum Media Stream Bit Rate Request (TMMBR) message. This is used to convey a temporary maximum bitrate limitation from a receiver of RTP packets to their sender. Even though it was not designed to replace congestion control, TMMBR has been used as a means to do receiver-based congestion control where the session bandwidth is high enough to send frequent TMMBR messages, especially when used with non-compound RTCP packets [RFC5506]. This approach requires the receiver of the RTP packets to monitor their reception, determine the level of congestion, and recommend a maximum bitrate suitable for current available bandwidth on the path; it also assumes that the RTP sender can/will respect that bitrate. This is the opposite of the sender-based congestion control approach suggested in this memo, so TMMBR cannot be used to convey the information needed for sender-based congestion control. TMMBR could, however, be viewed as a complementary mechanism that can inform the sender of the receiver's current view of an acceptable maximum bitrate. Mechanisms that convey the receiver's estimate of the maximum available bitrate provide similar feedback.

TMMBR：RTP / AVPFプロファイル[RFC5104]のコーデック制御メッセージには、一時最大メディアストリームビットレート要求（TMMBR）メッセージが含まれています。これは、RTPパケットの受信機から送信者に一時的な最大ビットレート制限を伝達するために使用されます。輻輳制御を置き換えるように設計されていなかったとしても、TMMBRは、セッション帯域幅が頻繁なTMMBRメッセージを送信するのに十分高い受信ベースの輻輳制御を行うための手段として使用されています[RFC5506] 。このアプローチでは、RTPパケットの受信機が受信を監視し、輻輳のレベルを決定し、パス上の現在の使用可能な帯域幅に適した最大ビットレートを推奨します。また、RTP送信者がそのビットレートを尊重できることを前提としています。これは、このメモで提案されている送信者ベースの輻輳制御アプローチの反対ですので、TMMBRを使用して送信者ベースの輻輳制御に必要な情報を伝えることはできません。しかしながら、TMMBRは、許容可能な最大ビットレートの受信機の現在のビューの送信者に知らせることができる補完的なメカニズムとして見られることができる。使用可能な最大ビットレートの受信機の推定値を伝えるメカニズムは、同様のフィードバックを提供します。

RTCP Extended Reports (XRs): Numerous RTCP XR blocks have been defined to report details of packet loss, arrival times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It is possible to combine several such XR blocks into a compound RTCP packet, to report the detailed loss, arrival time, and ECN marking information needed for effective sender-based congestion control. However, the result has high overhead in terms of both bandwidth and complexity, due to the need to stack multiple reports.

RTCP拡張レポート（XRS）：パケット損失、到着時間[RFC3611]、遅延[RFC6843]、およびECNマーキングの詳細を報告するために、数多くのRTCP XRブロックが定義されています。いくつかのそのようなXRブロックを複合RTCPパケットに組み合わせることができ、詳細な損失、到着時間、および効果的な送信者ベースの輻輳制御に必要なECNマーキング情報を報告することが可能である。ただし、複数のレポートを積み重ねる必要があるため、帯域幅と複雑さの両方に関して、結果は高いオーバーヘッドを持ちます。

Transport-wide Congestion Control: The format defined in this memo provides individual feedback on each SSRC. An alternative is to add a header extension to each RTP packet, containing a single, transport-wide, packet sequence number, then have the receiver send RTCP reports giving feedback on these additional sequence numbers [RTP-Ext-for-CC]. Such an approach increases the size of each RTP packet by 8 octets, due to the header extension, but reduces the size of the RTCP feedback packets, and can simplify the rate calculation at the sender if it maintains a single rate limit that applies to all RTP packets sent, irrespective of their SSRC. Equally, the use of transport-wide feedback makes it more difficult to adapt the sending rate, or respond to lost packets, based on the reception and/or loss patterns observed on a per-SSRC basis (for example, to perform differential rate control and repair for audio and video flows, based on knowledge of what packets from each flow were lost). Transport-wide feedback is also a less natural fit with the wider RTP framework, which makes extensive use of per-SSRC sequence numbers and feedback.

トランスポート全体の輻輳制御：このメモに定義されているフォーマットは、各SSRCに個々のフィードバックを提供します。代わりに、単一のトランスポート全体のパケットシーケンス番号を含む各RTPパケットにヘッダ拡張を追加し、次にRTCPを送信するRTCPレポートがこれらの追加のシーケンス番号[rtp-ext-for-cc]にフィードバックを送信させることです。そのようなアプローチは、ヘッダ拡張のために各RTPパケットのサイズを8オクテットで増加させますが、RTCPフィードバックパケットのサイズを縮小し、それがすべてに適用される単一のレート制限を維持する場合、送信者のレート計算を単純化することができます。 SSRCに関係なく、送信されたRTPパケット。同様に、輸送全体のフィードバックの使用は、SSRCごとの基準で観察された受信および/または損失のパターンに基づいて、送信速度を適用すること、または失われたパケットに応答することをより困難にする（例えば、差動速度制御を実行するための）。各フローからのパケットが失われたのかの知識に基づいて、オーディオおよびビデオの流れの修理）。トランスポート全体のフィードバックも、幅広いRTPフレームワークにも当然のものではありません。これは、SSRCごとのシーケンス番号とフィードバックを広く使用します。

Considering these issues, we believe it appropriate to design a new RTCP feedback mechanism to convey information for sender-based congestion control algorithms. The new congestion control feedback RTCP packet described in Section 3 provides such a mechanism.

これらの問題を考慮すると、送信者ベースの輻輳制御アルゴリズムの情報を伝えるための新しいRTCPフィードバックメカニズムを設計することが適切であると考えています。セクション3に記載されている新しい輻輳制御フィードバックRTCPパケットはそのようなメカニズムを提供する。

9. IANA Considerations

9. IANAの考慮事項

The IANA has registered one new RTP/AVPF Transport-Layer Feedback Message in the "FMT Values for RTPFB Payload Types" table [RFC4585] as defined in Section 3.1:

IANAは、セクション3.1で定義されているように、「RTPFBペイロードタイプのFMT値」テーブル[RFC4585]に1つの新しいRTP / AVPFトランスポート層フィードバックメッセージを登録しています。

Name: CCFB Long name: RTP Congestion Control Feedback Value: 11 Reference: RFC 8888

名前：CCFBロング名：RTP輻輳制御フィードバック値：11参照：RFC 8888

The IANA has also registered one new SDP "rtcp-fb" attribute "ack" parameter, "ccfb", in the SDP '"ack" and "nack" Attribute Values' registry:

IANAは、SDP 'の「ACK」および「NACK」属性値のレジストリに、新しいSDP "RTCP-FB"属性 "ACK"パラメータ "ack"パラメータ "" "" "" "ackb"を登録しました。

Value name: ccfb Long name: Congestion Control Feedback Usable with: ack Mux: IDENTICAL-PER-PT Reference: RFC 8888

値の名前：CCFBロング名：輻輳制御フィードバックで使用可能：ACK MUX：同一PER-PTリファレンス：RFC 8888

10. Security Considerations

10. セキュリティに関する考慮事項

The security considerations of the RTP specification [RFC3550], the applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), and the RTP congestion control algorithm being used (e.g., [RFC8698], [RFC8298], [Google-GCC], or [RFC8382]) apply.

RTP仕様[RFC3550]、該当するRTPプロファイル（例えば、[RFC3551]、[RFC3711]、[RFC4585]）のセキュリティ上の考慮事項、および使用されているRTP輻輳制御アルゴリズム（[RFC8698]、[RFC8298]）、[Google-GCC]、または[RFC8382]）が適用されます。

A receiver that intentionally generates inaccurate RTCP congestion control feedback reports might be able to trick the sender into sending at a greater rate than the path can support, thereby causing congestion on the path. This scenario will negatively impact the quality of experience of that receiver, potentially causing both denial of service to other traffic sharing the path and excessively increased resource usage at the media sender. Since RTP is an unreliable transport, a sender can intentionally drop a packet, leaving a gap in the RTP sequence number space without causing serious harm, to check that the receiver is correctly reporting losses. (This needs to be done with care and some awareness of the media data being sent, to limit impact on the user experience.)

不正確なRTCP輻輳制御フィードバックレポートを意図的に生成する受信機は、パスがサポートすることができるよりも高い速度で送信者を送信することができ、それによってパス上の輻輳を引き起こす可能性がある。このシナリオはその受信機の経験の質に悪影響を及ぼす、潜在的には、経路を共有する他のトラフィックとメディア送信者でのリソース使用量が過度に増加している可能性があります。RTPは信頼性の低いトランスポートであるため、送信者は意図的にパケットを削除し、深刻な害を及ぼすことなくRTPシーケンス番号スペースにギャップを残して、受信機が正しく報告されていることを確認します。（これは、送信されているメディアデータの注意と意識を持つ必要があります。ユーザーエクスペリエンスへの影響を制限します。）

An on-path attacker that can modify RTCP Congestion Control Feedback Packets can change the reports to trick the sender into sending at either an excessively high or excessively low rate, leading to denial of service. The secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack.

RTCP輻輳制御フィードバックパケットを変更できるオンパス攻撃者は、レポートを変更して送信者を過度に高くまたは過度に低速で送信し、サービス拒否につながります。セキュアRTCPプロファイル[RFC3711]は、この攻撃から保護するためにRTCPパケットを認証するために使用できます。

An off-path attacker that can spoof RTCP Congestion Control Feedback Packets can similarly trick a sender into sending at an incorrect rate, leading to denial of service. This attack is difficult, since the attacker needs to guess the SSRC and sequence number in addition to the destination transport address. As with on-path attacks, the secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack.

RTCP輻輳制御フィードバックパケットを偽造することができるオフパス攻撃者は、同様に送信者を誤ったレートで送信し、サービス拒否を引き起こすことができます。攻撃者は宛先トランスポートアドレスに加えてSSRCとシーケンス番号を推測する必要があるため、この攻撃は困難です。オンパス攻撃と同様に、Secure RTCPプロファイル[RFC3711]を使用して、この攻撃から保護するためにRTCPパケットを認証できます。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[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>。

[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>。

[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>。

[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>.

[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月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>.

[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>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。

[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>。

[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.

[RFC6679] Westerlund、M.、Johansson、I。、Perkins、C.、O'Hanlon、P.、K. Carlberg、「UDP上のRTPのための明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC66792012年8月、<https://www.rfc-editor.org/info/rfc6679>。

[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>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.

[RFC8843] Holmberg、C、Alvestrand、H.、およびC.ジェンニング、「セッション記述プロトコル（SDP）」、RFC 8843、DOI 10.17487 / RFC8843、<https：// www。rfc-editor.org/info/rfc8843>。

[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.

[RFC8859] Nandakumar、S。、「マルチプレクシング時のセッション記述プロトコル（SDP）属性のフレームワーク」、RFC 8859、DOI 10.17487 / RFC8859、2021年1月、<https：//www.rfc-editor.org/info/rfc8859>。

11.2. Informative References

11.2. 参考引用

[feedback-requirements] "RMCAT Feedback Requirements", IETF 95, April 2016, <https://www.ietf.org/proceedings/95/slides/slides-95- rmcat-1.pdf>.

[フィードバック要件]「RMCATフィードバック要件」、IETF 95、2016年4月、<https://www.ietf.org/proceedings/95/slides/slides-95- rmcat-1 - 1.pdf>。

[Google-GCC] Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real-Time Communication", Work in Progress, Internet-Draft, draft-ietf-rmcat-gcc-02, 8 July 2016, <https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02>.

[Google-GCC] Holmer、S.、Lundin、H.、Carlucci、G.、De Cicco、L.、およびS.マスコロ、「リアルタイム通信のためのGoogle Comgention Controlアルゴリズム」、進行中、インターネット - ドラフト、ドラフト - IETF-RMCAT-GCC-02,2016,7月8日、<https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02>。

[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>。

[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <https://www.rfc-editor.org/info/rfc5104>.

[RFC5104] Wenger、S、Chandra、U.、Westerlund、M.、およびB.Burman、「フィードバック付きRTPオーディオビジュアルプロファイル（AVPF）」、RFC 5104、DOI 10.17487 / RFC5104、2月2008年、<https://www.rfc-editor.org/info/rfc5104>。

[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, <https://www.rfc-editor.org/info/rfc6843>.

[RFC6843]クラーク、A。、GROSS、K。、およびQ. WU、「RTP制御プロトコル（RTCP）拡張レポート（RFC 6843、DOI 10.17487 / RFC6843、2013年1月、<https//www.rfc-editor.org/info/rfc6843>。

[RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 2017, <https://www.rfc-editor.org/info/rfc8298>.

[RFC8298]ヨハンスソン、I.およびZ.Sarker、RFC 8298、DOI 10.17487 / RFC8298、2017年12月、<https：//www.rfc-editor.org/info/rfc8298>。

[RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, "Shared Bottleneck Detection for Coupled Congestion Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, June 2018, <https://www.rfc-editor.org/info/rfc8382>.

[RFC8382]ヘイズ、D.、ED。、フェルリン、S、WELZL、M.、K.Hhirorth、「RTPメディアの結合輻輳制御のための共有ボトルネック検出」、RFC 8382、DOI 10.17487 / RFC8382、2018年6月、<https://www.rfc-editor.org/info/rfc8382>。

[RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media", RFC 8698, DOI 10.17487/RFC8698, February 2020, <https://www.rfc-editor.org/info/rfc8698>.

[RFC8698] Zhu、X.、Pan、R.、Ramalho、M.、およびS。Mena、「ネットワーク支援動的適応（灘）：リアルタイムメディアのための統一輻輳制御方式」、RFC 8698、DOI 10.17487/ RFC8698、2020年2月、<https://www.rfc-editor.org/info/rfc8698>。

[RTCP-Multimedia-Feedback] Perkins, C., "RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences", Work in Progress, Internet-Draft, draft-ietf-rmcat-rtp-cc-feedback-05, 4 November 2019, <https://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-05>.

[RTCPマルチメディアフィードバック] Perkins、C、 "RTP制御プロトコル（RTCP）インタラクティブマルチメディア会議における輻輳制御のためのフィードバック"、進行中の作業、インターネットドラフト、ドラフトIETF-RMCAT-RTP-CC-FEEDBACK-05、2019年11月4日、<https：//tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-05>。

[RTP-Ext-for-CC] Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions for Transport-wide Congestion Control", Work in Progress, Internet-Draft, draft-holmer-rmcat-transport-wide-cc-extensions-01, 19 October 2015, <https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01>.

[RTP-EXT-FOR-CC]ホルマー、S、フロドマン、M.、およびE. Sprang、「輸送幅輻輳制御のためのRTP拡張」、進行中の作業、インターネットドラフト、ドラフト - rmcat-transport - <https：//tools.ietf.org/html/draft-holmer-rmcat-transport-jax-jcc-extensions-01>。

Acknowledgements

謝辞

This document is based on the outcome of a design team discussion in the RTP Media Congestion Avoidance Techniques (RMCAT) Working Group. The authors would like to thank David Hayes, Stefan Holmer, Randell Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable feedback.

この文書は、RTPメディア輻輳回避技術（RMCAT）ワーキンググループにおける設計チームディスカッションの結果に基づいています。著者らは、David Hayes、Stefan Holmer、Randell Jesell、Jonathan Lennox、Sergio Mena、Nils Ohlmeier、Magnus Westerlund、および貴重なフィードバックのためのXiaoqing Zhuに感謝します。

Authors' Addresses

著者の住所

Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 SE-164 83 Stockholm Sweden

Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 SE-164 83ストックホルムスウェーデン

   Phone: +46 10 717 37 43
   Email: zaheduzzaman.sarker@ericsson.com

Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom

Colin Perkins Glasgow大学コンピューティングサイエンスグラスゴーG12 8QQイギリス

   Email: csp@csperkins.org

Varun Singh CALLSTATS I/O Oy Annankatu 31-33 C 42 FI-00100 Helsinki Finland

ヴァルチンシングシュススタットI / O OY Annankatu 31-33 C 42 FI-00100ヘルシンキフィンランド

   Email: varun.singh@iki.fi
   URI:   https://www.callstats.io/

Michael A. Ramalho AcousticComms Consulting 6310 Watercrest Way Unit 203 Lakewood Ranch, FL 34202-5122 United States of America

Michael A. Ramalho AcousticCommsコンサルティング6310 Watercrest Wait 203 Lakewood Ranch、FL 34202-5122アメリカ合衆国

   Phone: +1 732 832 9723
   Email: mar42@cornell.edu
   URI:   http://ramalho.webhop.info/