[要約] RFC 8083は、Unicast RTPセッションのためのマルチメディア輻輳制御のための回路ブレーカーに関する規格です。このRFCの目的は、ネットワークの輻輳を制御し、セッションの品質を維持するために、回路ブレーカーの使用方法を提案することです。
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 8083 University of Glasgow
Updates: 3550 V. Singh
Category: Standards Track callstats.io
ISSN: 2070-1721 March 2017
Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
マルチメディア輻輳制御：ユニキャストRTPセッションのサーキットブレーカー
Abstract
概要
The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.
リアルタイムトランスポートプロトコル（RTP）は、テレフォニー、ビデオ会議、およびテレプレゼンスアプリケーションで広く使用されています。このようなアプリケーションは、多くの場合、ベストエフォートのUDP / IPネットワークで実行されます。これらのアプリケーションに輻輳制御が実装されていない場合、ネットワークの輻輳により、制御されないパケット損失が発生し、ユーザーのマルチメディアエクスペリエンスが低下する可能性があります。輻輳制御アルゴリズムは、RTPフローによる過剰なリソースの使用を停止し、ネットワークを過負荷から保護することにより、安全対策として機能します。ただし、この記事の執筆時点では、独自のソリューションがいくつかありますが、対話型RTPフローの輻輳制御のための標準アルゴリズムはありません。
This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.
このドキュメントは、輻輳制御アルゴリズムを提案していません。代わりに、RTPサーキットブレーカーの最小セットを定義します。これは、RTP送信者が過度の輻輳からネットワークを保護するためにメディアデータの送信を停止する必要がある条件です。長期間にわたる過度の輻輳がない場合、ベストエフォートIPネットワークで実行されているRTPアプリケーションは、これらの回路ブレーカーをトリガーせずに動作できることが期待されます。 RTP回路ブレーカーのトリガーを回避するために、RTPに対して定義された標準トラックの輻輳制御アルゴリズムは、これらのRTP回路ブレーカーアルゴリズムによって設定されたエンベロープ内で動作する必要があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8083.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8083で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 8
4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout . . . . . . . . 10
4.2. RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . . 11
4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 12
4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 16
4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 17
5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 18
6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 19
7. Impact of Explicit Congestion Notification (ECN) . . . . . . 19
8. Impact of Bundled Media and Layered Coding . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
The Real-time Transport Protocol (RTP) [RFC3550] is widely used in voice-over-IP, video teleconferencing, and telepresence systems. Many of these systems run over best-effort UDP/IP networks and can suffer from packet loss and increased latency if network congestion occurs. Designing effective RTP congestion control algorithms to adapt the transmission of RTP-based media to match the available network capacity while also maintaining the user experience is a difficult but important problem. Many such congestion control and media adaptation algorithms have been proposed, but to date there is no consensus on the correct approach or even that a single standard algorithm is desirable.
リアルタイム転送プロトコル（RTP）[RFC3550]は、Voice-over-IP、ビデオ電話会議、およびテレプレゼンスシステムで広く使用されています。これらのシステムの多くは、ベストエフォートのUDP / IPネットワーク上で実行され、ネットワークの輻輳が発生した場合、パケットの損失や遅延の増加に悩まされる可能性があります。有効なRTP輻輳制御アルゴリズムを設計して、RTPベースのメディアの送信を利用可能なネットワーク容量に合わせるように適合させると同時に、ユーザーエクスペリエンスを維持することは困難ですが重要な問題です。多くのそのような輻輳制御とメディア適応アルゴリズムが提案されていますが、現在までのところ、正しいアプローチ、または単一の標準アルゴリズムが望ましいというコンセンサスはありません。
This memo does not attempt to propose a new RTP congestion control algorithm. Instead, we propose a small set of RTP circuit breakers: mechanisms that terminate RTP flows in conditions under which there is general agreement that serious network congestion is occurring. The RTP circuit breakers proposed in this memo are a specific instance of the general class of network transport circuit breakers [RFC8084] designed to act as a protection mechanism of last resort to avoid persistent excessive congestion. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by the RTP circuit breaker algorithms defined by this memo.
このメモは、新しいRTP輻輳制御アルゴリズムを提案することを試みません。代わりに、RTP回路ブレーカーの小さなセットを提案します。これは、深刻なネットワークの輻輳が発生しているという一般的な合意がある状況でRTPフローを終了するメカニズムです。このメモで提案されているRTP回路ブレーカーは、永続的な過度の輻輳を回避するための最後の手段の保護メカニズムとして機能するように設計されたネットワークトランスポート回路ブレーカー[RFC8084]の一般的なクラスの特定のインスタンスです。 RTPサーキットブレーカーのトリガーを回避するために、RTPに対して定義された標準トラックの輻輳制御アルゴリズムは、このメモによって定義されたRTPサーキットブレーカーアルゴリズムによって設定されたエンベロープ内で動作する必要があります。
We consider congestion control for unicast RTP traffic flows. This is the problem of adapting the transmission of an audio/visual data flow, encapsulated within an RTP transport session, from one sender to one receiver so that it does not use more capacity than is available along the network path. Such adaptation needs to be done in a way that limits the disruption to the user experience caused by both packet loss and excessive rate changes. Congestion control for multicast flows is outside the scope of this memo. Multicast traffic needs different solutions since the available capacity estimator for a group of receivers will differ from that for a single receiver, and because multicast congestion control has to consider issues of fairness across groups of receivers that do not apply to unicast flows.
ユニキャストRTPトラフィックフローの輻輳制御を検討します。これは、RTPトランスポートセッション内にカプセル化されたオーディオ/ビジュアルデータフローの送信を1つの送信者から1つの受信者に適応させ、ネットワークパスで利用可能な容量を超えないようにする問題です。このような適応は、パケット損失と過度のレート変更の両方によって引き起こされるユーザーエクスペリエンスの中断を制限する方法で行う必要があります。マルチキャストフローの輻輳制御は、このメモの範囲外です。マルチキャストトラフィックには、さまざまなソリューションが必要です。これは、レシーバーのグループで利用可能なキャパシティーエスティメーターが単一のレシーバーのキャパシティーエスティメーターとは異なり、マルチキャストの輻輳制御では、ユニキャストフローに適用されないレシーバーグループ全体の公平性の問題を考慮する必要があるためです。
Congestion control for unicast RTP traffic can be implemented in one of two places in the protocol stack. One approach is to run the RTP traffic over a congestion-controlled transport protocol (for example, over TCP), and to adapt the media encoding to match the dictates of the transport-layer congestion control algorithm. This is safe for the network but can be suboptimal for the media quality unless the transport protocol is designed to support real-time media flows. We do not consider this class of applications further in this memo, as their network safety is guaranteed by the underlying transport.
ユニキャストRTPトラフィックの輻輳制御は、プロトコルスタックの2つの場所のいずれかに実装できます。 1つのアプローチは、輻輳制御のトランスポートプロトコル（TCPなど）を介してRTPトラフィックを実行し、トランスポート層の輻輳制御アルゴリズムの命令に一致するようにメディアエンコーディングを適合させることです。これはネットワークにとって安全ですが、トランスポートプロトコルがリアルタイムのメディアフローをサポートするように設計されていない限り、メディア品質にとって最適ではない可能性があります。このメモでは、このクラスのアプリケーションについては考慮しません。それらのネットワークの安全性は、基盤となるトランスポートによって保証されているためです。
Alternatively, RTP flows can be run over a non-congestion-controlled transport protocol (for example, UDP) performing rate adaptation at the application layer based on RTP Control Protocol (RTCP) feedback. With a well-designed, network-aware application, this allows highly effective media quality adaptation, but there is potential to cause persistent congestion in the network if the application does not adapt its sending rate in a timely and effective manner. We consider this class of applications in this memo.
または、RTPフローは、RTP制御プロトコル（RTCP）フィードバックに基づいて、アプリケーション層でレート適応を実行する非輻輳制御トランスポートプロトコル（UDPなど）で実行できます。適切に設計されたネットワーク対応アプリケーションを使用すると、非常に効果的なメディア品質の適応が可能になりますが、アプリケーションがタイムリーかつ効果的な方法で送信レートを適合させないと、ネットワークで永続的な輻輳が発生する可能性があります。このメモでは、このクラスのアプリケーションを検討します。
Congestion control relies on monitoring the delivery of a media flow and responding to adapt the transmission of that flow when there are signs that the network path is congested. Network congestion can be detected in one of three ways:
輻輳制御は、メディアフローの配信を監視し、ネットワークパスが輻輳している兆候がある場合に応答して、そのフローの送信を調整します。ネットワークの輻輳は、次の3つの方法のいずれかで検出できます。
1) a receiver can infer the onset of congestion by observing an increase in one-way delay caused by queue build-up within the network;
1）受信者は、ネットワーク内でのキューの構築によって引き起こされる一方向の遅延の増加を観察することで、輻輳の発生を推測できます。
2) if Explicit Congestion Notification (ECN) [RFC3168] is supported, the network can signal the presence of congestion by marking packets using ECN Congestion Experienced (CE) marks (this could potentially be augmented by mechanisms such as Congestion Exposure (ConEx) [RFC7713] or other future protocol extensions for network signaling of congestion); or
2）明示的輻輳通知（ECN）[RFC3168]がサポートされている場合、ネットワークはECN Congestion Experienced（CE）マークを使用してパケットにマークを付けることにより、輻輳の存在を通知できます（これはCongestion Exposure（ConEx）などのメカニズムによって増強される可能性があります）[ RFC7713]または他の将来の輻輳のネットワークシグナリングのためのプロトコル拡張）;または
3) in the extreme case, congestion will cause packet loss that can be detected by observing a gap in the received RTP sequence numbers.
3）極端な場合、輻輳により、パケット損失が発生します。これは、受信したRTPシーケンス番号のギャップを観察することで検出できます。
Once the onset of congestion is observed, the receiver has to send feedback to the sender to indicate that the transmission rate needs to be reduced. How the sender reduces the transmission rate is highly dependent on the media codec being used and is outside the scope of this memo.
輻輳の開始が観察されると、受信側は送信側にフィードバックを送信して、伝送速度を下げる必要があることを示す必要があります。送信者がどのように伝送速度を低下させるかは、使用されているメディアコーデックに大きく依存し、このメモの範囲外です。
There are several ways in which a receiver can send feedback to a media sender within the RTP framework:
RTPフレームワーク内で、受信者がメディア送信者にフィードバックを送信する方法はいくつかあります。
o The base RTP specification [RFC3550] defines RTCP Receiver Report (RR) packets to convey reception quality feedback information and Sender Report (SR) packets to convey information about the media transmission. RTCP SR packets contain data that can be used to reconstruct media timing at a receiver along with a count of the total number of octets and packets sent. RTCP RR packets report on the fraction of packets lost in the last reporting interval, the cumulative number of packets lost, the highest sequence number received, and the inter-arrival jitter. The RTCP RR packets also contain timing information that allows the sender to estimate the network Round-Trip Time (RTT) to the receivers. RTCP reports are sent periodically, with the reporting interval being determined by the number of Synchronization Sources (SSRCs) used in the session and a configured session bandwidth estimate (the number of SSRCs) used is usually two in a unicast session, one for each participant, but can be greater if the participants send multiple media streams). The interval between reports sent from each receiver is on the order of a few seconds on average; although it varies with the session bandwidth, it is randomized to avoid synchronization of reports from multiple receivers. The interval can be less than a second in a high-bandwidth session. RTCP RR packets allow a receiver to report ongoing network congestion to the sender. However, if a receiver detects the onset of congestion part way through a reporting interval, the base RTP specification contains no provision for sending the RTCP RR packet early, and the receiver has to wait until the next scheduled reporting interval.
o基本RTP仕様[RFC3550]は、受信品質フィードバック情報を伝達するRTCP受信者レポート（RR）パケットと、メディア送信に関する情報を伝達する送信者レポート（SR）パケットを定義しています。 RTCP SRパケットには、送信されたオクテットとパケットの総数のカウントとともに、レシーバーでメディアタイミングを再構築するために使用できるデータが含まれています。 RTCP RRパケットは、最後のレポート間隔で失われたパケットの割合、失われたパケットの累積数、受信された最大のシーケンス番号、および到着間ジッタについてレポートします。 RTCP RRパケットには、送信者が受信者へのネットワークラウンドトリップ時間（RTT）を推定できるようにするタイミング情報も含まれています。 RTCPレポートは定期的に送信されます。レポート間隔は、セッションで使用される同期ソース（SSRC）の数によって決定され、使用される構成済みのセッション帯域幅推定（SSRCの数）は通常、ユニキャストセッションでは2つで、参加者ごとに1つです。 、ただし、参加者が複数のメディアストリームを送信する場合はさらに大きくなります）。各レシーバーから送信されるレポートの間隔は、平均で数秒程度です。セッションの帯域幅によって異なりますが、複数の受信者からのレポートの同期を回避するためにランダム化されます。高帯域幅セッションでは、間隔を1秒未満にすることができます。 RTCP RRパケットにより、受信者は進行中のネットワーク輻輳を送信者に報告できます。ただし、受信者がレポート間隔の途中で輻輳の開始を検出した場合、基本RTP仕様にはRTCP RRパケットを早期に送信するための規定が含まれておらず、受信機は次のスケジュールされたレポート間隔まで待機する必要があります。
o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more complex and sophisticated reception quality metrics but do not change the RTCP timing rules. RTCP extended reports of potential interest for congestion control purposes are the extended packet loss, discard, and burst metrics [RFC3611] [RFC7002] [RFC7097] [RFC7003] [RFC6958] as well as the extended delay metrics [RFC6843] [RFC6798]. Other RTCP Extended Reports that could be helpful for congestion control purposes might be developed in future.
o RTCP拡張レポート（XR）[RFC3611]では、より複雑で洗練された受信品質メトリックのレポートが可能ですが、RTCPタイミングルールは変更されません。輻輳制御を目的とする可能性のあるRTCP拡張レポートは、拡張パケット損失、破棄、バーストメトリック[RFC3611] [RFC7002] [RFC7097] [RFC7003] [RFC6958]と拡張遅延メトリック[RFC6843] [RFC6798]です。輻輳制御の目的に役立つ可能性がある他のRTCP拡張レポートが将来開発される可能性があります。
o Rapid feedback about the occurrence of congestion events can be achieved using the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] (or its secure variant, RTP/SAVPF [RFC5124]) in place of the RTP/AVP profile [RFC3551]. This modifies the RTCP timing rules to allow RTCP reports to be sent early, in some cases immediately, provided the RTCP transmission rate keeps within its bandwidth allocation. It also defines transport-layer feedback messages, including Negative Acknowledgements (NACKs), that can be used to report on specific congestion events. RTP Codec Control Messages [RFC5104] extend the RTP/AVPF profile with additional feedback messages that can be used to influence the way in which rate adaptation occurs but do not further change the dynamics of how rapidly feedback can be sent. Use of the RTP/AVPF profile is dependent on signaling.
o RTP / AVPプロファイルの代わりに、RTCPベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）[RFC4585]（またはその安全なバリアント、RTP / SAVPF [RFC5124]）を使用して、輻輳イベントの発生に関する迅速なフィードバックを実現できます。 [RFC3551]。これにより、RTCPタイミングルールが変更され、RTCP送信レートが帯域幅割り当て内に保たれる場合に、RTCPレポートを早期に、場合によってはすぐに送信できるようになります。また、特定の輻輳イベントのレポートに使用できる、否定応答（NACK）を含むトランスポート層フィードバックメッセージも定義します。 RTPコーデック制御メッセージ[RFC5104]は、RTP / AVPFプロファイルを追加のフィードバックメッセージで拡張します。これを使用して、レートアダプテーションが発生する方法に影響を与えることができますが、フィードバックの送信速度のダイナミクスはこれ以上変更されません。 RTP / AVPFプロファイルの使用は、シグナリングに依存します。
o Finally, ECN for RTP over UDP [RFC6679] can be used to provide feedback on the number of packets that received an ECN-CE mark. This RTCP extension builds on the RTP/AVPF profile to allow rapid congestion feedback when ECN is supported.
o 最後に、RTP over UDP [RFC6679]のECNを使用して、ECN-CEマークを受信したパケット数に関するフィードバックを提供できます。このRTCP拡張機能は、RTP / AVPFプロファイルに基づいて構築され、ECNがサポートされている場合に迅速な輻輳フィードバックを可能にします。
In addition to these mechanisms for providing feedback, the sender can include an RTP header extension in each packet to record packet transmission times [RFC5450]. Accurate transmission timestamps can be helpful for estimating queuing delays to get an early indication of the onset of congestion.
フィードバックを提供するこれらのメカニズムに加えて、送信者は各パケットにRTPヘッダー拡張を含めて、パケット送信時間を記録できます[RFC5450]。正確な送信タイムスタンプは、キューイング遅延を推定して、輻輳の発生を早期に示すのに役立ちます。
Taken together, these various mechanisms allow receivers to provide feedback on the senders when congestion events occur, with varying degrees of timeliness and accuracy. The key distinction is between systems that use only the basic RTCP mechanisms, without RTP/AVPF rapid feedback, and those that use the RTP/AVPF extensions to respond to congestion more rapidly.
まとめると、これらのさまざまなメカニズムにより、輻輳イベントが発生したときに、受信者は送信者にさまざまなタイミングと正確さでフィードバックを提供できます。主な違いは、RTP / AVPF高速フィードバックなしで基本的なRTCPメカニズムのみを使用するシステムと、RTP / AVPF拡張を使用して輻輳により迅速に応答するシステムとの違いです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This interpretation of these key words applies only when written in ALL CAPS. Mixed- or lower-case uses of these key words are not to be interpreted as carrying special significance in this memo.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。これらのキーワードのこの解釈は、すべて大文字で書かれた場合にのみ適用されます。これらのキーワードの混合または小文字の使用は、このメモで特別な意味を持っていると解釈されるべきではありません。
The definition of the RTP circuit breaker is specified in terms of the following variables:
RTP回路ブレーカーの定義は、次の変数で指定されます。
o Td is the deterministic RTCP reporting interval, as defined in Section 6.3.1 of [RFC3550].
o Tdは、[RFC3550]のセクション6.3.1で定義されているように、確定的なRTCPレポート間隔です。
o Tdr is the sender's estimate of the deterministic RTCP reporting interval, Td, calculated by a receiver of the data it is sending. Tdr is not known at the sender but can be estimated by executing the algorithm in Section 6.2 of [RFC3550] using the average RTCP packet size seen at the sender, the number of members reported in the receiver's SR/RR report blocks, and whether the receiver is sending SR or RR packets. Tdr is recalculated when each new RTCP SR/RR report is received, but the media timeout circuit breaker (see Section 4.2) is only reconsidered when Tdr increases.
o Tdrは、送信データの受信側が計算した、決定論的RTCPレポート間隔Tdの送信側の推定値です。 Tdrは送信側では不明ですが、[RFC3550]のセクション6.2のアルゴリズムを実行して、送信側で見られる平均RTCPパケットサイズ、受信側のSR / RRレポートブロックで報告されるメンバー数、および受信者がSRまたはRRパケットを送信しています。 Tdrは、新しいRTCP SR / RRレポートが受信されるたびに再計算されますが、メディアタイムアウト回路ブレーカー（セクション4.2を参照）は、Tdrが増加したときにのみ再検討されます。
o Tr is the network round-trip time, which is calculated by the sender using the algorithm in Section 6.4.1 of [RFC3550] and is smoothed using an exponentially weighted moving average as Tr = (0.8 * Tr) + (0.2 * Tr_new) where Tr_new is the latest RTT estimate obtained from an RTCP report. The weight is chosen so old estimates decay over k intervals.
o Trはネットワークラウンドトリップ時間で、[RFC3550]のセクション6.4.1のアルゴリズムを使用して送信者が計算し、Tr =（0.8 * Tr）+（0.2 * Tr_new）として指数加重移動平均を使用して平滑化されます。ここで、Tr_newは、RTCPレポートから取得した最新のRTT見積もりです。重みは、古い推定がk間隔で減衰するように選択されます。
o k is the non-reporting threshold (see Section 4.2).
o kは非報告しきい値です（セクション4.2を参照）。
o Tf is the media framing interval at the sender. For applications sending at a constant frame rate, Tf is the inter-frame interval. For applications that switch between a small set of possible frame rates (for example, when sending speech with comfort noise, such that comfort noise frames are sent less often than speech frames), Tf is set to the longest of the inter-frame intervals of the different frame rates. For applications that send periodic frames but dynamically vary their frame rate, Tf is set to the largest inter-frame interval used in the last 10 seconds. For applications that send less than one frame every 10 seconds, or that have no concept of periodic frames (e.g., text conversation [RFC4103], or pointer events [RFC2862]), when each frame is sent, Tf is set to the time interval since the previous frame.
o Tfは、送信側のメディアフレーミング間隔です。一定のフレームレートで送信するアプリケーションの場合、Tfはフレーム間の間隔です。可能なフレームレートの小さなセットを切り替えるアプリケーションの場合（たとえば、コンフォートノイズフレームがスピーチフレームよりも少ない頻度で送信されるように、コンフォートノイズを含むスピーチを送信する場合）、Tfは、フレーム間インターバルの最も長い間隔に設定されます。異なるフレームレート。定期的なフレームを送信するがフレームレートを動的に変化させるアプリケーションの場合、Tfは最後の10秒間に使用された最大のフレーム間間隔に設定されます。 10秒ごとに1フレーム未満を送信するアプリケーション、または定期的なフレームの概念がないアプリケーション（たとえば、テキストカンバセーション[RFC4103]、またはポインターイベント[RFC2862]）の場合、各フレームが送信されるとき、Tfは時間間隔に設定されます。前のフレームから。
o G is the frame group size. That is, the number of frames that are coded together based on a particular sending rate setting. If the codec used by the sender can change its rate on each frame, then G = 1; otherwise, G is set to the number of frames before the codec can adjust to the new rate. For codecs that have the concept of a Group of Pictures (GOP), G is likely the GOP length.
o Gはフレームグループのサイズです。つまり、特定の送信レート設定に基づいて一緒にコード化されるフレームの数。送信者が使用するコーデックが各フレームでレートを変更できる場合、G = 1。それ以外の場合、Gは、コーデックが新しいレートに調整できるようになるまでのフレーム数に設定されます。 Group of Pictures（GOP）の概念を持つコーデックの場合、GはおそらくGOPの長さです。
o T_rr_interval is the minimal interval between RTCP reports, as defined in Section 3.4 of [RFC4585]; it is only meaningful for implementations of RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124].
o T_rr_intervalは、[RFC4585]のセクション3.4で定義されている、RTCPレポート間の最小間隔です。 RTP / AVPFプロファイル[RFC4585]またはRTP / SAVPFプロファイル[RFC5124]の実装でのみ意味があります。
o X is the estimated throughput a TCP connection would achieve over a path, in bytes per second.
o Xは、TCP接続がパス上で達成する推定スループットで、1秒あたりのバイト数です。
o s is the size of RTP packets being sent, in bytes. If the RTP packets being sent vary in size, then the average size over the packet comprising the last 4 * G frames MUST be used (this is intended to be comparable to the four loss intervals used in [RFC5348]).
o sは、バイト単位の送信されるRTPパケットのサイズです。送信されるRTPパケットのサイズが異なる場合、最後の4 * Gフレームを構成するパケットの平均サイズを使用する必要があります（これは、[RFC5348]で使用される4つの損失間隔に相当することを意図しています）。
o p is the loss event rate, between 0.0 and 1.0, that would be seen by a TCP connection over a particular path. When used in the RTP congestion circuit breaker, this is approximated as described in Section 4.3.
o pは、特定のパス上のTCP接続で認識される、0.0〜1.0の損失イベントレートです。 RTP輻輳回路ブレーカーで使用する場合、これはセクション4.3で説明されているように概算されます。
o t_RTO is the retransmission timeout value that would be used by a TCP connection over a particular path, in seconds. This MUST be approximated using t_RTO = 4 * Tr when used as part of the RTP congestion circuit breaker.
o t_RTOは、特定のパスを介したTCP接続で使用される再送信タイムアウト値（秒単位）です。これは、RTP輻輳回路ブレーカーの一部として使用される場合、t_RTO = 4 * Trを使用して概算する必要があります。
o b is the number of packets that are acknowledged by a single TCP acknowledgement. Following [RFC5348], it is RECOMMENDED that the value b = 1 is used as part of the RTP congestion circuit breaker.
o bは、単一のTCP確認応答によって確認応答されたパケットの数です。 [RFC5348]に従って、RTP輻輳回路ブレーカーの一部として値b = 1を使用することをお勧めします。
The feedback mechanisms defined in [RFC3550] and available under the RTP/AVP profile [RFC3551] are the minimum that can be assumed for a baseline circuit breaker mechanism that is suitable for all unicast applications of RTP. Accordingly, for an RTP circuit breaker to be useful, it needs to be able to detect that an RTP flow is causing excessive congestion using only basic RTCP features without needing RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports.
[RFC3550]で定義され、RTP / AVPプロファイル[RFC3551]で利用可能なフィードバックメカニズムは、RTPのすべてのユニキャストアプリケーションに適したベースラインサーキットブレーカーメカニズムとして想定できる最小のものです。したがって、RTP回路ブレーカーが役立つためには、RTP XRフィードバックや迅速なRTCPレポートのRTP / AVPFプロファイルを必要とせずに、RTPフローが基本的なRTCP機能のみを使用して過度の輻輳を引き起こしていることを検出できる必要があります。
RTCP is a fundamental part of the RTP protocol, and the mechanisms described here rely on the implementation of RTCP. Implementations that claim to support RTP, but that do not implement RTCP, will be unable to use the circuit breaker mechanisms described in this memo. Such implementations SHOULD NOT be used on networks that might be subject to congestion unless equivalent mechanisms are defined using some non-RTCP feedback channel to report congestion and signal circuit breaker conditions.
RTCPはRTPプロトコルの基本的な部分であり、ここで説明するメカニズムはRTCPの実装に依存しています。 RTPをサポートしていると主張しているがRTCPを実装していない実装は、このメモに記載されている回路ブレーカーメカニズムを使用できません。このような実装は、非RTCPフィードバックチャネルを使用して同等のメカニズムを定義し、輻輳と信号回路ブレーカーの状態を報告しない限り、輻輳の可能性があるネットワークでは使用しないでください。
The RTCP timeout circuit breaker (Section 4.1) will trigger if an implementation of this memo attempts to interwork with an endpoint that does not support RTCP. Implementations that sometimes need to interwork with endpoints that do not support RTCP need to disable the RTP circuit breakers if they don't receive some confirmation via signaling that the remote endpoint implements RTCP (the presence of a Session Description Protocol (SDP) "a=rtcp:" attribute in an answer might be such an indication). The RTP circuit breaker SHOULD NOT be disabled on networks that might be subject to congestion unless equivalent mechanisms are defined using some non-RTCP feedback channel to report congestion and signal circuit breaker conditions [RFC8084].
このメモの実装がRTCPをサポートしていないエンドポイントと相互作用しようとすると、RTCPタイムアウト回路ブレーカー（セクション4.1）がトリガーされます。 RTCPをサポートしていないエンドポイントと相互に作用する必要がある実装では、リモートエンドポイントがRTCP（セッション記述プロトコル（SDP）の存在）を実装しているというシグナリングを介して確認を受け取らない場合、RTP回路ブレーカーを無効にする必要があります。回答のrtcp： "属性は、そのような兆候である可能性があります）。 RTP回路ブレーカーは、非RTCPフィードバックチャネルを使用して同等のメカニズムを定義し、輻輳と信号回路ブレーカーの状態を報告しない限り、輻輳の可能性があるネットワークでは無効にすべきではありません[RFC8084]。
Three potential congestion signals are available from the basic RTCP SR/RR packets and are reported for each SSRC in the RTP session:
基本的なRTCP SR / RRパケットから3つの潜在的な輻輳信号が利用可能であり、RTPセッションの各SSRCについて報告されます。
1. The sender can estimate the network round-trip time once per RTCP reporting interval based on the contents and timing of RTCP SR and RR packets.
1. 送信者は、RTCP SRおよびRRパケットの内容とタイミングに基づいて、RTCPレポート間隔ごとに1回、ネットワーク往復時間を推定できます。
2. Receivers report a jitter estimate (the statistical variance of the RTP data packet inter-arrival time) calculated over the RTCP reporting interval. Due to the nature of the jitter calculation (Section 6.4.4. of [RFC3550]), the jitter is only meaningful for RTP flows that send a single data packet for each RTP timestamp value (i.e., audio flows, or video flows where each packet comprises one video frame).
2. レシーバーは、RTCPレポート間隔で計算されたジッター推定値（RTPデータパケットの到着間時間の統計的変動）を報告します。ジッタ計算の性質（[RFC3550]のセクション6.4.4。）により、ジッタは、RTPタイムスタンプ値ごとに単一のデータパケットを送信するRTPフロー（つまり、オーディオフロー、またはパケットは1つのビデオフレームで構成されます）。
3. Receivers report the fraction of RTP data packets lost during the RTCP reporting interval and the cumulative number of RTP packets lost over the entire RTP session.
3. レシーバーは、RTCPレポート間隔中に失われたRTPデータパケットの割合と、RTPセッション全体で失われたRTPパケットの累積数を報告します。
These congestion signals limit the possible circuit breakers since they give only limited visibility into the behavior of the network.
これらの輻輳信号は、ネットワークの動作の可視性を制限するだけなので、可能な回路ブレーカーを制限します。
RTT estimates are widely used in congestion control algorithms as a proxy for queuing delay measures in delay-based congestion control or to determine connection timeouts. RTT estimates derived from RTCP SR and RR packets sent according to the RTP/AVP timing rules are too infrequent to be useful for congestion control and don't give enough information to distinguish a delay change due to routing updates from queuing delay caused by congestion. Accordingly, we cannot use the RTT estimate alone as an RTP circuit breaker.
RTT推定は、遅延ベースの輻輳制御で遅延測定値をキューイングするためのプロキシとして、または接続タイムアウトを決定するためのプロキシとして、輻輳制御アルゴリズムで広く使用されています。 RTP / AVPタイミングルールに従って送信されたRTCP SRおよびRRパケットから導出されたRTT推定は、頻度が高すぎて輻輳制御に役立たず、ルーティングアップデートによる遅延の変化と輻輳によるキューイングの遅延を区別するための十分な情報がありません。したがって、RTT推定値だけをRTP回路ブレーカーとして使用することはできません。
Increased jitter can be a signal of transient network congestion, but in the highly aggregated form reported in RTCP RR packets, it offers insufficient information to estimate the extent or persistence of congestion. Jitter reports are a useful early warning of potential network congestion but provide an insufficiently strong signal to be used as a circuit breaker.
ジッタの増加は、一時的なネットワークの輻輳の信号である可能性がありますが、RTCP RRパケットで報告される高度に集約された形式では、輻輳の程度または持続性を推定するための情報が不十分です。ジッタレポートは、ネットワークの輻輳の可能性を早期に警告するのに役立ちますが、回路ブレーカーとして使用するには強度が不十分です。
The remaining congestion signals are the packet loss fraction and the cumulative number of packets lost. If considered carefully, and over an appropriate time frame to distinguish transient problems from long term issues [RFC8084], these can be effective indicators that persistent excessive congestion is occurring in networks where packet loss is primarily due to queue overflows, although loss caused by non-congestive packet corruption can distort the result in some networks. TCP congestion control [RFC5681] intentionally tries to fill the router queues and uses the resulting packet loss as congestion feedback. An RTP flow competing with TCP traffic will therefore expect to see a non-zero packet loss fraction, and some variation in queuing latency, in normal operation when sharing a path with other flows, which needs to be accounted for when determining the circuit breaker threshold [RFC8084]. This behavior of TCP is reflected in the congestion circuit breaker below and will affect the design of any RTP congestion control protocol.
残りの輻輳信号は、パケット損失率と失われたパケットの累積数です。注意深く検討し、一時的な問題と長期的な問題を区別する適切な時間枠[RFC8084]を使用すると、パケット損失が主にキューのオーバーフローによるものであるネットワークで永続的な過度の輻輳が発生しているが、 -輻輳パケットの破損は、一部のネットワークで結果を歪める可能性があります。 TCP輻輳制御[RFC5681]は意図的にルーターキューをいっぱいにしようとし、結果として生じるパケット損失を輻輳フィードバックとして使用します。したがって、TCPトラフィックと競合するRTPフローは、通常の動作で他のフローとパスを共有するときに、ゼロ以外のパケット損失率とキューイングレイテンシの変動が予想されます。これは、回路ブレーカーのしきい値を決定する際に考慮する必要があります。 [RFC8084]。このTCPの動作は、以下の輻輳サーキットブレーカーに反映され、RTP輻輳制御プロトコルの設計に影響します。
Two packet loss regimes can be observed: 1) RTCP RR packets show a non-zero packet loss fraction while the extended highest sequence number received continues to increment; and 2) RR packets show a loss fraction of zero, but the extended highest sequence number received does not increment even though the sender has been transmitting RTP data packets. The former corresponds to the TCP congestion avoidance state and indicates a congested path that is still delivering data; the latter corresponds to a TCP timeout and is most likely due to a path failure. A third condition is that data is being sent but no RTCP feedback is received at all, corresponding to a failure of the reverse path. We derive circuit breaker conditions for these loss regimes in the following.
次の2つのパケット損失状況が観察されます。1）RTCP RRパケットは、ゼロ以外のパケット損失率を示しますが、受信された拡張最大シーケンス番号は増加し続けます。 2）RRパケットの損失率はゼロですが、送信側がRTPデータパケットを送信している場合でも、受信した拡張最大シーケンス番号は増加しません。前者はTCPの輻輳回避状態に対応し、まだデータを配信している輻輳したパスを示します。後者はTCPタイムアウトに対応し、パス障害が原因である可能性が最も高いです。 3番目の条件は、データが送信されているがRTCPフィードバックがまったく受信されていないことです。これは、リバースパスの障害に対応しています。以下では、これらの損失状況に対する回路遮断器の条件を導き出します。
An RTCP timeout can occur when RTP data packets are being sent, but there are no RTCP reports returned from the receiver. This is either due to a failure of the receiver to send RTCP reports or a failure of the return path that is preventing those RTCP reporting from being delivered. In either case, it is not safe to continue transmission since the sender has no way of knowing if it is causing congestion.
RTCPデータパケットが送信されているときにRTCPタイムアウトが発生する可能性がありますが、受信側から返されたRTCPレポートはありません。これは、RTCPレポートを送信するレシーバーの障害、またはこれらのRTCPレポートの配信を妨げているリターンパスの障害が原因です。どちらの場合も、送信者が輻輳を引き起こしているかどうかを知る方法がないため、送信を続行するのは安全ではありません。
An RTP sender that has not received any RTCP SR or RTCP RR packets reporting on the SSRC it is using, for a time period of at least three times its deterministic RTCP reporting interval, Td (where Td is calculated without the randomization factor and using the fixed minimum interval of Tmin=5 seconds), SHOULD cease transmission (see Section 4.5). The rationale for this choice of timeout is as described in Section 6.2 of [RFC3550] ("so that implementations which do not use the reduced value for transmitting RTCP packets are not timed out by other participants prematurely") and has been updated by Section 6.1.4 of [RFC8108] to account for the use of the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124].
使用しているSSRCでレポートしているRTCP SRまたはRTCP RRパケットを受信していないRTP送信者は、その決定論的RTCPレポート間隔の少なくとも3倍の期間Td（Tdはランダム化係数なしで計算され、 Tmin = 5秒の固定最小間隔）、送信を停止する必要があります（セクション4.5を参照）。このタイムアウトの選択の根拠は、[RFC3550]のセクション6.2で説明されており（「RTCPパケットの送信に削減された値を使用しない実装が、他の参加者によって途中でタイムアウトしないようにするため」）、セクション6.1で更新されています。 RTP / AVPFプロファイル[RFC4585]またはRTP / SAVPFプロファイル[RFC5124]の使用を説明する[RFC8108]の.4。
To reduce the risk of premature timeout, implementations SHOULD NOT configure the RTCP bandwidth such that Td is larger than 5 seconds. Similarly, implementations that use the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to values larger than 4 seconds (the reduced limit for T_rr_interval follows Section 6.1.3 of [RFC8108]).
早期タイムアウトのリスクを減らすために、実装では、Tdが5秒を超えるようにRTCP帯域幅を構成しないでください。同様に、RTP / AVPFプロファイル[RFC4585]またはRTP / SAVPFプロファイル[RFC5124]を使用する実装では、T_rr_intervalを4秒より大きい値に設定しないでください（T_rr_intervalの制限の削減は、[RFC8108]のセクション6.1.3に従います）。
The choice of three RTCP reporting intervals as the timeout is made following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that participants in an RTP session will timeout and remove an RTP sender from the list of active RTP senders if no RTP data packets have been received from that RTP sender within the last two RTCP reporting intervals. Using a timeout of three RTCP reporting intervals is therefore large enough that the other participants will have timed out the sender if a network problem stops the data packets it is sending from reaching the receivers, even allowing for loss of some RTCP packets.
タイムアウトとしての3つのRTCPレポート間隔の選択は、RFC 3550 [RFC3550]のセクション6.3.5に従って行われます。これは、RTPセッションの参加者がタイムアウトし、RTPデータパケットが最後の2つのRTCPレポート間隔内にそのRTP送信者から受信されなかった場合、アクティブなRTP送信者のリストから削除することを指定します。したがって、3つのRTCPレポート間隔のタイムアウトを使用すると、ネットワークの問題により送信中のデータパケットが受信者に到達できなくなった場合、他の参加者が送信者をタイムアウトにして、一部のRTCPパケットが失われる可能性があります。
If a sender is transmitting a large number of RTP media streams, such that the corresponding RTCP SR or RR packets are too large to fit into the network MTU, the receiver will generate RTCP SR or RR packets in a round-robin manner. In this case, the sender SHOULD treat receipt of an RTCP SR or RR packet corresponding to any SSRC it sent on the same 5-tuple of source and destination IP address, port, and protocol as an indication that the receiver and return path are working and thus preventing the RTCP timeout circuit breaker from triggering.
送信者が多数のRTPメディアストリームを送信していて、対応するRTCP SRまたはRRパケットが大きすぎてネットワークMTUに収まらない場合、受信者はラウンドロビン方式でRTCP SRまたはRRパケットを生成します。この場合、送信者は、送信元と宛先のIPアドレス、ポート、およびプロトコルの同じ5タプルで送信したSSRCに対応するRTCP SRまたはRRパケットの受信を、受信者とリターンパスが機能していることを示すものとして扱う必要があります（SHOULD）。したがって、RTCPタイムアウト回路ブレーカーがトリガーされるのを防ぎます。
If RTP data packets are being sent but the RTCP SR or RR packets reporting on that SSRC indicate a non-increasing extended highest sequence number received, this is an indication that those RTP data packets are not reaching the receiver. This could be a short-term issue affecting only a few RTP packets, perhaps caused by a slow-to-open firewall or a transient connectivity problem, but if the issue persists, it is a sign of a more ongoing and significant problem (a "media timeout").
RTPデータパケットが送信されているが、そのSSRCを報告するRTCP SRまたはRRパケットが、受信した増加していない拡張最大シーケンス番号を示している場合、これらのRTPデータパケットがレシーバーに到達していないことを示しています。これはいくつかのRTPパケットのみに影響を与える短期的な問題である可能性があります。おそらく、ファイアウォールのオープンが遅いか、一時的な接続の問題が原因ですが、問題が解決しない場合は、より継続的で重大な問題（a 「メディアタイムアウト」）。
The time needed to declare a media timeout depends on the parameters Tdr, Tr, Tf, and on the non-reporting threshold k. The value of k is chosen so that when Tdr is large compared to Tr and Tf, receipt of at least k RTCP reports with non-increasing extended highest sequence number received gives reasonable assurance that the forward path has failed and that the RTP data packets have not been lost by chance. The RECOMMENDED value for k is 5 reports.
メディアタイムアウトの宣言に必要な時間は、パラメーターTdr、Tr、Tf、および非報告しきい値kによって異なります。 kの値は、TdrがTrおよびTfと比較して大きい場合に、受信した増加しない最大のシーケンス番号で少なくともk個のRTCPレポートを受信すると、フォワードパスが失敗し、RTPデータパケットに偶然失われたわけではない。 kの推奨値は5レポートです。
When Tdr < Tf, then RTP data packets are being sent at a rate less than one per RTCP reporting interval of the receiver, so the extended highest sequence number received can be expected to be non-increasing for some receiver RTCP reporting intervals. Similarly, when Tdr < Tr, some receiver RTCP reporting intervals might pass before the RTP data packets arrive at the receiver, also leading to reports where the extended highest sequence number received is non-increasing. Both issues require the media timeout interval to be scaled relative to the threshold, k.
Tdr <Tfの場合、RTPデータパケットは受信者のRTCPレポート間隔ごとに1未満の速度で送信されるため、受信した拡張最大シーケンス番号は、一部の受信者RTCPレポート間隔で増加しないことが期待できます。同様に、Tdr <Trの場合、RTPデータパケットがレシーバーに到着する前に一部のレシーバーRTCPレポート間隔が経過する可能性があり、これにより、受信した拡張最大シーケンス番号が増加しないレポートが作成されます。どちらの問題でも、メディアタイムアウト間隔をしきい値kに比例してスケーリングする必要があります。
The media timeout RTP circuit breaker is therefore as follows. When starting sending, calculate MEDIA_TIMEOUT using:
したがって、メディアタイムアウトRTP回路ブレーカーは次のとおりです。送信を開始するときに、以下を使用してMEDIA_TIMEOUTを計算します。
MEDIA_TIMEOUT = ceil(k * max(Tf, Tr, Tdr) / Tdr)
When a sender receives an RTCP packet that indicates reception of the media it has been sending, then it cancels the media timeout circuit breaker. If it is still sending, then it MUST calculate a new value for MEDIA_TIMEOUT and set a new media timeout circuit breaker.
送信側は、送信したメディアの受信を示すRTCPパケットを受信すると、メディアタイムアウト回路ブレーカーをキャンセルします。それがまだ送信している場合は、MEDIA_TIMEOUTの新しい値を計算し、新しいメディアタイムアウト回路ブレーカーを設定する必要があります。
If a sender receives an RTCP packet indicating that its media was not received, it MUST calculate a new value for MEDIA_TIMEOUT. If the new value is larger than the previous, it replaces MEDIA_TIMEOUT with the new value, extending the media timeout circuit breaker; otherwise, it keeps the original value of MEDIA_TIMEOUT. This process is known as reconsidering the media timeout circuit breaker.
送信者がメディアが受信されなかったことを示すRTCPパケットを受信した場合は、MEDIA_TIMEOUTの新しい値を計算する必要があります。新しい値が以前の値より大きい場合、MEDIA_TIMEOUTが新しい値に置き換えられ、メディアタイムアウト回路ブレーカーが拡張されます。それ以外の場合は、MEDIA_TIMEOUTの元の値を保持します。このプロセスは、メディアタイムアウト回路ブレーカーの再検討と呼ばれます。
If MEDIA_TIMEOUT consecutive RTCP packets are received indicating that the media being sent was not received, and the media timeout circuit breaker has not been canceled, then the media timeout circuit breaker triggers. When the media timeout circuit breaker triggers, the sender SHOULD cease transmission (see Section 4.5).
送信されているメディアが受信されなかったことを示すMEDIA_TIMEOUT連続RTCPパケットが受信され、メディアタイムアウト回路ブレーカーがキャンセルされていない場合、メディアタイムアウト回路ブレーカーがトリガーされます。メディアタイムアウト回路ブレーカーがトリガーされると、送信者は送信を停止する必要があります（セクション4.5を参照）。
When stopping sending an RTP stream, a sender MUST cancel the corresponding media timeout circuit breaker.
RTPストリームの送信を停止する場合、送信者は対応するメディアタイムアウト回路ブレーカーをキャンセルする必要があります。
If RTP data packets are being sent and the corresponding RTCP SR or RR packets show non-zero packet loss fraction and increasing extended highest sequence number received, then those RTP data packets are arriving at the receiver, but some degree of congestion is occurring. The RTP/AVP profile [RFC3551] states that:
RTPデータパケットが送信されており、対応するRTCP SRまたはRRパケットがゼロ以外のパケット損失率と受信した拡張最大シーケンス番号の増加を示している場合、それらのRTPデータパケットは受信側に到着していますが、ある程度の輻輳が発生しています。 RTP / AVPプロファイル[RFC3551]は次のように述べています。
If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than [the throughput] the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
ベストエフォートサービスが使用されている場合、RTPレシーバーはパケット損失を監視して、パケット損失率が許容パラメーター内であることを確認する必要があります（SHOULD）。同じネットワークパス全体で同じネットワーク条件が発生するTCPフローが、RTPフローが達成している[スループット]以上の平均スループットを妥当なタイムスケールで測定する場合、パケット損失は許容できると見なされます。この条件は、輻輳制御メカニズムを実装して伝送速度（またはレイヤードマルチキャストセッションにサブスクライブするレイヤーの数）を適合させるか、または損失率が許容できないほど高い場合にレシーバーがセッションを離れるようにすることで満たすことができます。
The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude.
TCPとの比較を正確に指定することはできませんが、タイムスケールとスループットの「桁違い」の比較を目的としています。 TCPスループットが測定されるタイムスケールは、接続の往復時間です。本質的に、この要件は、任意の帯域幅を消費し、1桁以内でTCPと公平に競合しないベストエフォートインターネット上に（RTPまたは他のトランスポートプロトコルを使用して）アプリケーションを展開することは受け入れられないことを述べています。
The phase "order of magnitude" in the above means within a factor of ten, approximately. In order to implement this, it is necessary to estimate the throughput a bulk TCP connection would achieve over the path. For a long-lived TCP Reno connection, it has been shown that the TCP throughput, X, in bytes per second, can be estimated as follows [Padhye]:
上記の「大きさのオーダー」とは、およそ10倍以内を意味します。これを実装するには、バルクTCP接続がパス上で達成するスループットを見積もる必要があります。長期間有効なTCP Reno接続の場合、TCPスループットX（1秒あたりのバイト数）は次のように見積もることができることが示されています[Padhye]：
s
X = -------------------------------------------------------------
Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p)))
This is the same approach to estimated TCP throughput that is used in [RFC5348]. Under conditions of low packet loss, the second term on the denominator is small, so this formula can be approximated with reasonable accuracy as follows [Mathis]:
これは、[RFC5348]で使用されている推定TCPスループットへのアプローチと同じです。パケット損失が少ない状況では、分母の第2項が小さいため、この式は妥当な精度で次のように近似できます[Mathis]：
s
X = ----------------
Tr*sqrt(2*b*p/3)
It is RECOMMENDED that this simplified throughput equation be used since the reduction in accuracy is small, and it is much simpler to calculate than the full equation. Measurements have shown that the simplified TCP throughput equation is effective as an RTP circuit breaker for multimedia flows sent to hosts on residential networks using Asymmetric Digital Subscriber Line (ADSL) and cable modem links [Singh]. The data shows that the full TCP throughput equation tends to be more sensitive to packet loss and triggers the RTP circuit breaker earlier than the simplified equation. Implementations that desire this extra sensitivity MAY use the full TCP throughput equation in the RTP circuit breaker. Initial measurements in LTE networks have shown that the extra sensitivity is helpful in that environment, with the full TCP throughput equation giving a more balanced circuit breaker response than the simplified TCP equation [Sarker]; other networks might see similar behavior.
精度の低下が小さく、完全な方程式より計算がはるかに簡単であるため、この簡略化されたスループット方程式を使用することをお勧めします。測定の結果、簡略化されたTCPスループット方程式は、非対称デジタル加入者線（ADSL）とケーブルモデムリンクを使用して住宅ネットワークのホストに送信されるマルチメディアフローのRTP回路ブレーカーとして有効であることが示されています[Singh]。データは、完全なTCPスループットの式は、パケット損失の影響を受けやすく、簡略化された式よりも早くRTP回路ブレーカーをトリガーすることを示しています。この追加の感度を必要とする実装は、RTP回路ブレーカーで完全なTCPスループット方程式を使用する場合があります。 LTEネットワークの初期測定では、その環境で追加の感度が役立つことが示されています。完全なTCPスループット方程式は、簡略化されたTCP方程式[サーカー]よりもバランスのとれた回路ブレーカー応答を提供します。他のネットワークでも同様の動作が見られる場合があります。
No matter what TCP throughput equation is chosen, two parameters need to be estimated and reported to the sender in order to calculate the throughput: the round-trip time, Tr, and the loss event rate, p (the packet size, s, is known to the sender). The round-trip time can be estimated from RTCP SR and RR packets. This is done too infrequently for accurate statistics but is the best that can be done with the standard RTCP mechanisms.
どのTCPスループット方程式を選択した場合でも、スループットを計算するには、2つのパラメーターを推定して送信者に報告する必要があります。往復時間Tr、および損失イベントレートp（パケットサイズsは、送信者に知られている）。ラウンドトリップ時間は、RTCP SRおよびRRパケットから推定できます。これは正確な統計にはあまり頻繁に行われませんが、標準のRTCPメカニズムで実行できる最高の方法です。
Report blocks in RTCP SR or RR packets contain the packet loss fraction, rather than the loss event rate, so p cannot be reported (TCP typically treats the loss of multiple packets within a single RTT as one loss event, but RTCP RR packets report the overall fraction of packets lost and do not report when the packet losses occurred). Using the loss fraction in place of the loss event rate can overestimate the loss. We believe that this overestimate will not be significant given that we are only interested in order of magnitude comparison (Section 3.2.1 of [Floyd] shows that the difference is small for steady-state conditions and random loss, but using the loss fraction is more conservative in the case of bursty loss).
RTCP SRまたはRRパケットのレポートブロックには、損失イベントレートではなく、パケット損失率が含まれているため、pは報告できません（TCPは通常、単一のRTT内の複数のパケットの損失を1つの損失イベントとして扱いますが、RTCP RRパケットは、パケット損失の全体的な割合。パケット損失が発生した場合は報告しません）。損失イベント率の代わりに損失率を使用すると、損失を過大評価する可能性があります。大きさの比較のみに関心があるので、この過大評価は重要ではないと考えます（[Floyd]のセクション3.2.1は、定常状態とランダム損失の違いが小さいことを示していますが、損失率の使用はバースト損失の場合はより保守的です）。
The congestion circuit breaker is therefore as follows. When a sender that is transmitting at least one RTP packet every max(Tdr, Tr) seconds receives an RTCP SR or RR packet that contains a report block for an SSRC it is using, the sender MUST record the value of the fraction lost field from the report block, and the time since the last report block was received, for that SSRC. If more than CB_INTERVAL (see below) report blocks have been received for that SSRC, the sender MUST calculate the average fraction lost over the last CB_INTERVAL reporting intervals and then estimate the TCP throughput that would be achieved over the path using the chosen TCP throughput equation and the measured values of the round-trip time, Tr, the loss event rate, p (approximated by the average fraction lost, as is described below), and the packet size, s. The estimate of the TCP throughput, X, is then compared with the actual sending rate of the RTP stream. If the actual sending rate of the RTP stream is more than 10 * X, then the congestion circuit breaker is triggered.
したがって、輻輳回路ブレーカーは次のようになります。 max（Tdr、Tr）秒ごとに少なくとも1つのRTPパケットを送信している送信者が、使用しているSSRCのレポートブロックを含むRTCP SRまたはRRパケットを受信する場合、送信者はから失われた割合フィールドの値を記録する必要がありますそのSSRCのレポートブロック、および最後のレポートブロックが受信されてからの時間。そのSSRCについてCB_INTERVAL（以下を参照）を超えるレポートブロックが受信された場合、送信者は最後のCB_INTERVALレポート間隔で失われた平均割合を計算し、選択したTCPスループット方程式を使用してパス上で達成されるTCPスループットを推定する必要があります往復時間Tr、損失イベント率p（以下で説明するように、平均損失率で近似）、およびパケットサイズsの測定値。次に、TCPスループットの推定値Xが、RTPストリームの実際の送信レートと比較されます。 RTPストリームの実際の送信レートが10 * Xを超える場合、輻輳回路ブレーカーがトリガーされます。
The average fraction lost is calculated based on the sum (over the last CB_INTERVAL reporting intervals) of the fraction lost in each reporting interval that is then multiplied by the duration of the corresponding reporting interval and then divided by the total duration of the last CB_INTERVAL reporting intervals. The CB_INTERVAL parameter is set to:
失われた平均の割合は、各レポート間隔で失われた割合の合計（最後のCB_INTERVALレポート間隔で）に基づいて計算され、対応するレポート間隔の継続時間で乗算され、最後のCB_INTERVALレポートの合計継続時間で除算されます。間隔。 CB_INTERVALパラメータは次のように設定されます。
CB_INTERVAL =
ceil(3*min(max(10*G*Tf, 10*Tr, 3*Tdr), max(15, 3*Td))/(3*Tdr))
The parameters that feed into CB_INTERVAL are chosen to give the congestion control algorithm time to react to congestion. They give at least three RTCP reports, ten round trip times, and ten groups of frames to adjust the rate to reduce the congestion to a reasonable level. It is expected that a responsive congestion control algorithm will begin to respond with the next group of frames after it receives indication of congestion, so CB_INTERVAL ought to be a much longer interval than the congestion response.
CB_INTERVALにフィードするパラメーターは、輻輳制御アルゴリズムが輻輳に反応する時間を与えるように選択されます。それらは、少なくとも3つのRTCPレポート、10のラウンドトリップ時間、および10グループのフレームを提供して、輻輳を合理的なレベルに低減するようにレートを調整します。輻輳の指示を受け取った後、応答する輻輳制御アルゴリズムが次のフレームグループで応答し始めることが予想されるため、CB_INTERVALは輻輳応答よりもはるかに長い間隔である必要があります。
If the RTP/AVPF profile [RFC4585] or the RTP/SAVPF [RFC5124] is used, and the T_rr_interval parameter is used to reduce the frequency of regular RTCP reports, then the value of Tdr in the above expression for the CB_INTERVAL parameter MUST be replaced by max(T_rr_interval, Tdr).
RTP / AVPFプロファイル[RFC4585]またはRTP / SAVPF [RFC5124]を使用し、T_rr_intervalパラメーターを使用して通常のRTCPレポートの頻度を減らす場合、上記のCB_INTERVALパラメーターの式のTdrの値はmax（T_rr_interval、Tdr）に置き換えられました。
The CB_INTERVAL parameter is calculated on joining the session, and recalculated on receipt of each RTCP packet, after checking whether the media timeout circuit breaker or the congestion circuit breaker has been triggered.
CB_INTERVALパラメータは、セッションへの参加時に計算され、メディアタイムアウト回路ブレーカーまたは輻輳回路ブレーカーがトリガーされたかどうかを確認した後、各RTCPパケットの受信時に再計算されます。
To ensure a timely response to persistent congestion, implementations SHOULD NOT configure the RTCP bandwidth such that Tdr is larger than 5 seconds. Similarly, implementations that use the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to values larger than 4 seconds (the reduced limit for T_rr_interval follows Section 6.1.3 of [RFC8108]).
持続的な輻輳に対するタイムリーな応答を保証するために、実装では、Tdrが5秒よりも大きくなるようにRTCP帯域幅を構成しないでください。同様に、RTP / AVPFプロファイル[RFC4585]またはRTP / SAVPFプロファイル[RFC5124]を使用する実装では、T_rr_intervalを4秒より大きい値に設定しないでください（T_rr_intervalの制限の削減は、[RFC8108]のセクション6.1.3に従います）。
The rationale for enforcing a minimum sending rate below which the congestion circuit breaker will not trigger is to avoid spurious circuit breaker triggers when the number of packets sent per RTCP reporting interval is small, and hence, the fraction lost samples are subject to measurement artifacts. The bound of at least one packet every max(Tdr, Tr) seconds is derived from the one packet per RTT minimum sending rate of TCP [RFC8085], which is adapted for use with RTP where the RTCP reporting interval is decoupled from the network RTT.
輻輳サーキットブレーカーがトリガーしない最低送信レートを適用する根拠は、RTCPレポート間隔ごとに送信されるパケット数が少ない場合に偽のサーキットブレーカートリガーを回避することです。そのため、失われたサンプルの割合は測定アーティファクトの影響を受けます。 max（Tdr、Tr）秒ごとに少なくとも1つのパケットの境界は、TCP [RFC8085]のRTT最小送信レートあたり1つのパケットから導出されます。これは、RTCPレポート間隔がネットワークRTTから切り離されているRTPでの使用に適合しています。 。
When the congestion circuit breaker is triggered, the sender SHOULD cease transmission (see Section 4.5). However, if the sender is able to reduce its sending rate by a factor of (approximately) ten, then it MAY first reduce its sending rate by this factor (or some larger amount) to see if that resolves the congestion. If the sending rate is reduced in this way and the congestion circuit breaker triggers again after the next CB_INTERVAL RTCP reporting intervals, the sender MUST then cease transmission. An example of such a rate reduction might be a video conferencing system that backs off to sending audio only before completely dropping the call. If such a reduction in sending rate resolves the congestion problem, the sender MAY gradually increase the rate at which it sends data after a reasonable amount of time has passed, provided it takes care not to cause the problem to recur ("reasonable" is intentionally not defined here since it depends on the application, media codec, and congestion control algorithm).
輻輳回路ブレーカーがトリガーされると、送信者は送信を停止する必要があります（セクション4.5を参照）。ただし、送信者が送信レートを（約）10倍に減らすことができる場合は、まずこの係数（またはそれよりも大きい量）だけ送信レートを減らして、輻輳が解決するかどうかを確認できます（MAY）。送信レートがこの方法で低下し、次のCB_INTERVAL RTCPレポート間隔の後に輻輳サーキットブレーカーが再びトリガーする場合、送信者は送信を停止しなければなりません（MUST）。そのようなレート削減の例としては、コールを完全に切断する前にのみオーディオの送信にバックオフするビデオ会議システムがあります。このような送信速度の低下により輻輳の問題が解決した場合、問題が再発しないように注意して（「合理的」に意図的に）、送信者は妥当な時間が経過した後、データを送信する速度を徐々に上げてもよい（MAY）。アプリケーション、メディアコーデック、および輻輳制御アルゴリズムに依存するため、ここでは定義しません。
The RTCP reporting interval of the media sender does not affect how quickly the congestion circuit breaker can trigger. The timing is based on the RTCP reporting interval of the receiver that generates the SR/RR packets from which the loss rate and RTT estimate are derived (note that RTCP requires all participants in a session to have similar reporting intervals, else the participant timeout rules in [RFC3550] will not work, so this interval is likely similar to that of the sender). If the incoming RTCP SR or RR packets are using a reduced minimum RTCP reporting interval (as specified in Section 6.2 of RFC 3550 [RFC3550] or the RTP/AVPF profile [RFC4585]), then that reduced RTCP reporting interval is used when determining if the circuit breaker is triggered.
メディアセンダーのRTCPレポート間隔は、輻輳サーキットブレーカーがトリガーできる速さに影響しません。タイミングは、SR / RRパケットを生成するレシーバーのRTCPレポート間隔に基づいており、そこから損失率とRTT推定値が導出されます（RTCPは、セッションのすべての参加者が同様のレポート間隔を持つ必要があることに注意してください。それ以外の場合、参加者タイムアウトルール[RFC3550]では機能しません。そのため、この間隔は送信者の間隔とほぼ同じです）。着信RTCP SRまたはRRパケットが短縮された最小RTCPレポート間隔（RFC 3550 [RFC3550]のセクション6.2またはRTP / AVPFプロファイル[RFC4585]で指定）を使用している場合、その短縮されたRTCPレポート間隔は、回路ブレーカーがトリガーされます。
If there are more media streams that can be reported in a single RTCP SR or RR packet, or if the size of a complete RTCP SR or RR packet exceeds the network MTU, then the receiver will report on a subset of sources in each reporting interval with the subsets selected round-robin across multiple intervals so that all sources are eventually reported [RFC3550]. When generating such round-robin RTCP reports, priority SHOULD be given to reports on sources that have high packet loss rates to ensure that senders are aware of network congestion they are causing (this is an update to [RFC3550]).
単一のRTCP SRまたはRRパケットでレポートできるメディアストリームがさらにある場合、または完全なRTCP SRまたはRRパケットのサイズがネットワークMTUを超える場合、受信者は各レポート間隔でソースのサブセットについてレポートしますすべてのソースが最終的に報告されるように、サブセットを複数の間隔でラウンドロビンで選択します[RFC3550]。このようなラウンドロビンRTCPレポートを生成する場合、パケット損失率が高いソースに関するレポートを優先して、送信者が発生しているネットワークの輻輳を確実に認識できるようにする必要があります（これは[RFC3550]の更新です）。
Applications that use RTP are generally tolerant to some amount of packet loss. How much packet loss can be tolerated will depend on the application, media codec, and the amount of error correction and packet loss concealment that is applied. There is an upper bound on the amount of loss that can be corrected, however, beyond which the media becomes unusable. Similarly, many applications have some upper bound on the media capture to play-out latency that can be tolerated before the application becomes unusable. The latency bound will depend on the application, but typical values can range from the order of a few hundred milliseconds for voice telephony and interactive conferencing applications up to several seconds for some video-on-demand systems.
RTPを使用するアプリケーションは、一般に、ある程度のパケット損失を許容します。許容されるパケット損失の許容量は、アプリケーション、メディアコーデック、および適用されるエラー訂正とパケット損失隠蔽の量によって異なります。ただし、修正できる損失の量には上限があり、それを超えるとメディアは使用できなくなります。同様に、多くのアプリケーションは、アプリケーションが使用できなくなる前に許容できる再生待ち時間に対するメディアキャプチャにある程度の上限があります。レイテンシの限界はアプリケーションによって異なりますが、一般的な値は、音声テレフォニーやインタラクティブ会議アプリケーションの場合は数百ミリ秒程度から、一部のビデオオンデマンドシステムの場合は数秒までの範囲になります。
As a final circuit breaker, RTP senders SHOULD monitor the reported packet loss and delay to estimate whether the media is likely to be suitable for the intended purpose. If the packet loss rate and/or latency is such that the media has become unusable and has remained unusable for a significant time period, then the application SHOULD cease transmission. Similarly, receivers SHOULD monitor the quality of the media they receive, and if the quality is unusable for a significant time period, they SHOULD terminate the session. This memo intentionally does not define a bound on the packet loss rate or latency that will result in unusable media, as these are highly application dependent. Similarly, the time period that is considered significant is application dependent but is likely on the order of seconds, or tens of seconds.
最終的なサーキットブレーカーとして、RTP送信者は、報告されたパケット損失と遅延を監視して、メディアが意図した目的に適しているかどうかを推定する必要があります（SHOULD）。パケット損失率や遅延が原因で、メディアが使用できなくなり、長期間にわたって使用できなくなった場合、アプリケーションは送信を停止する必要があります（SHOULD）。同様に、受信者は受信したメディアの品質を監視する必要があり（SHOULD）、品質が長期間使用できない場合は、セッションを終了する必要があります（SHOULD）。これらのメモは、アプリケーションに大きく依存しているため、使用できないメディアになるパケット損失率または遅延の上限を意図的に定義していません。同様に、重要と見なされる期間はアプリケーションに依存しますが、おそらく数秒または数十秒程度です。
Sending media that suffers from such high packet loss or latency that it is unusable at the receiver is both wasteful of resources and is of no benefit to the user of the application. It also is highly likely to be congesting the network and disrupting other applications. As such, the congestion circuit breaker will almost certainly trigger to stop flows where the media would be unusable due to high packet loss or latency. However, in pathological scenarios where the congestion circuit breaker does not stop the flow, it is desirable to prevent the application sending unnecessary traffic that might disrupt other uses of the network. The role of the media usability circuit breaker is to protect the network in such cases.
非常に高いパケット損失または遅延のためにレシーバーで使用できないメディアを送信することは、リソースを浪費するだけでなく、アプリケーションのユーザーにとってもメリットがありません。また、ネットワークが混雑し、他のアプリケーションが中断される可能性が高くなります。そのため、輻輳サーキットブレーカーは、ほぼ確実にトリガーして、高いパケット損失や遅延のためにメディアが使用できなくなるフローを停止します。ただし、輻輳回路ブレーカーがフローを停止しない病理学的シナリオでは、ネットワークの他の使用を妨害する可能性のある不要なトラフィックをアプリケーションが送信しないようにすることが望ましいです。メディアユーザビリティ回路ブレーカーの役割は、このような場合にネットワークを保護することです。
What it means to cease transmission depends on the application. This could mean stopping a single RTP flow or it could mean that multiple bundled RTP flows are stopped. The intention is that the application will stop sending RTP data packets on a particular 5-tuple (transport protocol, source and destination ports, source and destination IP addresses) until whatever network problem that triggered the RTP circuit breaker has dissipated. RTP flows halted by the circuit breaker SHOULD NOT be restarted automatically unless the sender has received information that the congestion has dissipated or can reasonably be expected to have dissipated. What could trigger this expectation is necessarily application dependent, but could be, for example, an indication that a competing flow has finished and freed up some capacity, or for an application running on a mobile device it could indicate that the device moved to a new location so the flow would traverse a different path if it were restarted. Ideally, a human user will be involved in the decision to try to restart the flow since that user will eventually give up if the flows repeatedly trigger the circuit breaker. This will help avoid problems with automatic redial systems from congesting the network.
送信を停止することの意味は、アプリケーションによって異なります。これは、単一のRTPフローを停止することを意味する場合と、複数のバンドルされたRTPフローが停止することを意味する場合があります。 RTPサーキットブレーカーをトリガーしたネットワークの問題が散逸するまで、アプリケーションは特定の5タプル（トランスポートプロトコル、送信元と宛先のポート、送信元と宛先のIPアドレス）でのRTPデータパケットの送信を停止します。サーキットブレーカーによって停止されたRTPフローは、輻輳が消散したか、または消散すると合理的に予想できるという情報を送信者が受信しない限り、自動的に再起動しないでください。この期待を引き起こす可能性のあるものは、必ずアプリケーションに依存しますが、たとえば、競合するフローが終了し、一部の容量が解放されたことを示す場合や、モバイルデバイスで実行されているアプリケーションの場合、デバイスが新しいものに移動したことを示す場合があります。再起動した場合にフローが別のパスを通過するようにするため。理想的には、人間のユーザーは、フローが繰り返し回路ブレーカーをトリガーする場合、最終的にあきらめるので、フローを再開しようとする決定に関与します。これにより、自動リダイヤルシステムの問題がネットワークを混雑させることを回避できます。
It is recognized that the RTP implementation in some systems might not be able to determine if a flow setup request was initiated by a human user or automatically by some scripted higher-level component of the system. These implementations MUST rate limit attempts to restart a flow on the same 5-tuple as used by a flow that triggered the circuit breaker so that the reaction to a triggered circuit breaker lasts for at least the triggering interval [RFC8084].
一部のシステムのRTP実装では、フローのセットアップ要求が人間のユーザーによって開始されたのか、システムのスクリプト化された高レベルのコンポーネントによって自動的に開始されたのかを判断できない場合があることが認識されています。これらの実装は、サーキットブレーカーをトリガーしたフローで使用されているのと同じ5タプルでフローを再開する試みをレート制限する必要があります。これにより、トリガーされたサーキットブレーカーへの反応が少なくともトリガー間隔[RFC8084]の間持続します。
The RTP circuit breaker will only trigger, and cease transmission, for media flows subject to long-term persistent congestion. Such flows are likely to have poor quality and usability for some time before the circuit breaker triggers. Implementations can monitor RTCP Receiver Report blocks being returned for their media flows and might find it beneficial to use this information to provide a user interface cue that problems are occurring in advance of the circuit breaker triggering.
RTPサーキットブレーカーは、長期間持続する輻輳の影響を受けるメディアフローに対してのみトリガーし、送信を停止します。このようなフローは、回路遮断器が作動する前のしばらくの間、品質と使い勝手が悪い可能性があります。実装は、メディアフローに対して返されるRTCPレシーバーレポートブロックを監視できます。この情報を使用して、回路ブレーカーがトリガーする前に問題が発生しているというユーザーインターフェースの手がかりを提供することが有益である場合があります。
Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) [RFC4585] allows receivers to send early RTCP reports, in some cases, to inform the sender about particular events in the media stream. There are several use cases for such early RTCP reports, including providing rapid feedback to a sender about the onset of congestion. The RTP/SAVPF Profile [RFC5124] is a secure variant of the RTP/AVPF profile that is treated the same in the context of the RTP circuit breaker. These feedback profiles are often used with non-compound RTCP reports [RFC5506] to reduce the reporting overhead.
RTCPベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）[RFC4585]を使用すると、受信者は初期のRTCPレポートを送信でき、場合によっては、メディアストリーム内の特定のイベントについて送信者に通知できます。このような初期のRTCPレポートには、輻輳の発生について送信者に迅速なフィードバックを提供するなど、いくつかの使用例があります。 RTP / SAVPFプロファイル[RFC5124]は、RTP / AVPFプロファイルの安全なバリアントであり、RTP回路ブレーカーのコンテキストでは同じように扱われます。これらのフィードバックプロファイルは、非複合RTCPレポート[RFC5506]でよく使用され、レポートのオーバーヘッドを削減します。
Receiving rapid feedback about congestion events potentially allows congestion control algorithms to be more responsive and to better adapt the media transmission to the limitations of the network. It is expected that many RTP congestion control algorithms will adopt the RTP/AVPF profile or the RTP/SAVPF profile for this reason and thus define new transport-layer feedback reports that suit their requirements. Since these reports are not yet defined, and likely very specific to the details of the congestion control algorithm chosen, they cannot be used as part of the generic RTP circuit breaker.
輻輳イベントに関する迅速なフィードバックを受信することで、輻輳制御アルゴリズムの応答性を高め、メディア送信をネットワークの制限に適合させることができます。このため、多くのRTP輻輳制御アルゴリズムはRTP / AVPFプロファイルまたはRTP / SAVPFプロファイルを採用し、要件に合った新しいトランスポート層フィードバックレポートを定義することが期待されています。これらのレポートはまだ定義されておらず、選択された輻輳制御アルゴリズムの詳細に非常に固有である可能性が高いため、一般的なRTP回路ブレーカーの一部として使用することはできません。
Reduced-size RTCP reports sent under the RTP/AVPF early feedback rules that do not contain an RTCP SR or RR packet MUST be ignored by the congestion circuit breaker (they do not contain the information needed by the congestion circuit breaker algorithm) but MUST be counted as received packets for the RTCP timeout circuit breaker. Reduced-size RTCP reports sent under the RTP/AVPF early feedback rules that contain RTCP SR or RR packets MUST be processed by the congestion circuit breaker as if they were sent as regular RTCP reports and counted towards the circuit breaker conditions specified in Section 4 of this memo. This will potentially make the RTP circuit breaker trigger earlier than it would if the RTP/AVPF profile was not used.
RTCP SRまたはRRパケットを含まないRTP / AVPFアーリーフィードバックルールで送信された縮小サイズのRTCPレポートは、輻輳回路ブレーカーによって無視される必要があります（輻輳回路ブレーカーアルゴリズムが必要とする情報は含まれません）。 RTCPタイムアウト回路ブレーカーの受信パケットとしてカウントされます。 RTCP SRまたはRRパケットを含むRTP / AVPFアーリーフィードバックルールで送信される縮小サイズのRTCPレポートは、あたかも通常のRTCPレポートとして送信され、セクション4で指定された回路ブレーカーの条件にカウントされるかのように、輻輳回路ブレーカーによって処理される必要があります。このメモ。これにより、RTP / AVPFプロファイルが使用されなかった場合よりも、RTP回路ブレーカーのトリガーが早くなる可能性があります。
When using ECN with RTP (see Section 7), early RTCP feedback packets can contain ECN feedback reports. The count of ECN-CE-marked packets contained in those ECN feedback reports is counted towards the number of lost packets reported if the ECN Feedback Report is sent in a compound RTCP packet along with an RTCP SR/RR report packet. Reports of ECN-CE packets sent as reduced-size RTCP ECN feedback packets without an RTCP SR/RR packet MUST be ignored.
RTPでECNを使用する場合（セクション7を参照）、初期のRTCPフィードバックパケットにはECNフィードバックレポートを含めることができます。これらのECNフィードバックレポートに含まれるECN-CEマーク付きパケットの数は、ECNフィードバックレポートがRTCP SR / RRレポートパケットと共に複合RTCPパケットで送信された場合に報告される失われたパケットの数にカウントされます。 RTCP SR / RRパケットなしで縮小サイズのRTCP ECNフィードバックパケットとして送信されたECN-CEパケットのレポートは無視する必要があります。
These rules are intended to allow the use of low-overhead RTP/AVPF feedback for generic NACK messages without triggering the RTP circuit breaker. This is expected to make such feedback suitable for RTP congestion control algorithms that need to quickly report loss events in between regular RTCP reports. The reaction to reduced-size RTCP SR/RR packets is to allow such algorithms to send feedback that can trigger the circuit breaker when desired.
これらのルールは、RTP回路ブレーカーをトリガーすることなく、一般的なNACKメッセージにオーバーヘッドの少ないRTP / AVPFフィードバックを使用できるようにすることを目的としています。これにより、そのようなフィードバックが、通常のRTCPレポート間で損失イベントを迅速に報告する必要があるRTP輻輳制御アルゴリズムに適したものになることが期待されています。縮小サイズのRTCP SR / RRパケットに対する反応は、そのようなアルゴリズムが必要に応じて回路ブレーカーをトリガーできるフィードバックを送信できるようにすることです。
The RTP/AVPF and RTP/SAVPF profiles include the T_rr_interval parameter that can be used to adjust the regular RTCP reporting interval. The use of the T_rr_interval parameter changes the behavior of the RTP circuit breaker, as described in Section 4.
RTP / AVPFおよびRTP / SAVPFプロファイルには、通常のRTCPレポート間隔を調整するために使用できるT_rr_intervalパラメーターが含まれています。 T_rr_intervalパラメータを使用すると、セクション4で説明されているように、RTP回路ブレーカーの動作が変更されます。
RTCP Extended Report (XR) blocks provide additional reception quality metrics, but do not change the RTCP timing rules. Some of the RTCP XR blocks provide information that might be useful for congestion control purposes, others provide non-congestion-related metrics. With the exception of RTCP XR ECN Summary Reports (see Section 7), the presence of RTCP XR blocks in a compound RTCP packet does not affect the RTP circuit breaker algorithm. For consistency and ease of implementation, only the receiver report blocks contained in RTCP SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets are used by the RTP circuit breaker algorithm.
RTCP拡張レポート（XR）ブロックは、追加の受信品質メトリックを提供しますが、RTCPタイミングルールを変更しません。 RTCP XRブロックには、輻輳制御の目的に役立つ情報を提供するものもあれば、非輻輳関連のメトリックを提供するものもあります。 RTCP XR ECNサマリーレポート（セクション7を参照）を除いて、複合RTCPパケットにRTCP XRブロックが存在しても、RTP回路ブレーカーアルゴリズムには影響しません。 RTPサーキットブレーカーアルゴリズムでは、一貫性と実装の容易さのために、RTCP SRパケット、RTCP RRパケット、またはRTCP XR ECNサマリーレポートパケットに含まれているレシーバーレポートブロックのみが使用されます。
The use of ECN for RTP flows does not affect the RTCP timeout circuit breaker (Section 4.1) or the media timeout circuit breaker (Section 4.2) since these are both connectivity checks that simply determinate if any packets are being received.
RTPフローにECNを使用しても、RTCPタイムアウトサーキットブレーカー（セクション4.1）またはメディアタイムアウトサーキットブレーカー（セクション4.2）には影響しません。これらは両方とも、パケットが受信されているかどうかを判断するだけの接続チェックです。
At the time of this writing, there's no consensus on how the receipt of ECN feedback will impact the congestion circuit breaker (Section 4.3) or indeed whether the congestion circuit breaker ought to take ECN feedback into account. A future replacement of this memo is expected to provide guidance for implementers.
この記事の執筆時点では、ECNフィードバックの受信が輻輳回路ブレーカーにどのように影響するか（セクション4.3）、または実際に輻輳回路ブレーカーがECNフィードバックを考慮する必要があるかどうかについての合意はありません。このメモの将来の置き換えは、実装者にガイダンスを提供することが期待されています。
For the media usability circuit breaker (Section 4.4), ECN-CE-marked packets arrive at the receiver, and if they arrive in time, they will be decoded and rendered as normal. Accordingly, receipt of such packets ought not affect the usability of the media, and the arrival of RTCP feedback indicating their receipt is not expected to impact the operation of the media usability circuit breaker.
メディアユーザビリティ回路ブレーカー（セクション4.4）の場合、ECN-CEでマークされたパケットは受信機に到着し、時間内に到着した場合、通常どおりにデコードおよびレンダリングされます。したがって、そのようなパケットの受信は、メディアのユーザビリティに影響を与えるべきではなく、それらの受信を示すRTCPフィードバックの到着は、メディアのユーザビリティ回路ブレーカーの動作に影響を与えるとは予想されません。
The RTP circuit breaker operates on a per-RTP session basis. An RTP sender that participates in several RTP sessions MUST treat each RTP session independently with regards to the RTP circuit breaker.
RTPサーキットブレーカーは、RTPセッションごとに動作します。複数のRTPセッションに参加するRTP送信者は、RTPサーキットブレーカーに関して、各RTPセッションを個別に処理する必要があります。
An RTP sender can generate several media streams within a single RTP session, with each stream using a different SSRC. This can happen if bundled media are in use when using simulcast or when using layered media coding. By default, each SSRC will be treated independently by the RTP circuit breaker. However, the sender MAY choose to treat the flows (or a subset thereof) as a group such that a circuit breaker trigger for one flow applies to the group of flows as a whole and either causes the entire group to cease transmission or causes the sending rate of the group to reduce by a factor of ten, depending on the RTP circuit breaker triggered. Grouping flows in this way is expected to be especially useful for layered flows sent using multiple SSRCs as it allows the layered flow to react as a whole, thus ceasing transmission on the enhancement layers first to reduce sending rate, if necessary, rather than treating each layer independently. Care needs to be taken if the different media streams sent on a single transport-layer flow use different Differentiated Services Code Point (DSCP) values [RFC7657] [WebRTC-QoS] since congestion could be experienced differently depending on the DSCP marking. Accordingly, RTP media streams with different DSCP values SHOULD NOT be considered as a group when evaluating the RTP circuit breaker conditions.
RTP送信者は、単一のRTPセッション内で複数のメディアストリームを生成でき、各ストリームは異なるSSRCを使用します。これは、サイマルキャストを使用するとき、またはレイヤードメディアコーディングを使用するときに、バンドルされたメディアが使用されている場合に発生する可能性があります。デフォルトでは、各SSRCはRTP回路ブレーカーによって個別に処理されます。ただし、送信者は、フロー（またはそのサブセット）をグループとして扱うことを選択して、1つのフローのサーキットブレーカートリガーが全体としてフローのグループに適用され、グループ全体が送信を停止するか、送信が行われるようにすることができます（MAY）。トリガーされたRTP回路ブレーカーに応じて、グループが10分の1に削減するレート。このようにフローをグループ化すると、複数のSSRCを使用して送信される階層化フローの場合に特に役立ちます。これにより、階層化フローが全体として反応し、拡張レイヤーでの送信が停止され、必要に応じて、それぞれを処理するのではなく、必要に応じて送信レートが低下します。独立して層。単一のトランスポート層フローで送信される異なるメディアストリームが異なるDiffServコードポイント（DSCP）値[RFC7657] [WebRTC-QoS]を使用する場合は、DSCPマーキングによって輻輳が異なるため、注意が必要です。したがって、異なるDSCP値を持つRTPメディアストリームは、RTP回路ブレーカーの状態を評価するときにグループと見なしてはいけません（SHOULD NOT）。
The security considerations of [RFC3550] apply.
[RFC3550]のセキュリティに関する考慮事項が適用されます。
If the RTP/AVPF profile is used to provide rapid RTCP feedback, the security considerations of [RFC4585] apply. If ECN feedback for RTP over UDP/IP is used, the security considerations of [RFC6679] apply.
RTP / AVPFプロファイルを使用して迅速なRTCPフィードバックを提供する場合、[RFC4585]のセキュリティに関する考慮事項が適用されます。 UDP / IP上のRTPのECNフィードバックが使用される場合、[RFC6679]のセキュリティに関する考慮事項が適用されます。
If non-authenticated RTCP reports are used, an on-path attacker can trivially generate fake RTCP packets that indicate high packet loss rates and thus cause the circuit breaker to trigger and disrupt an RTP session. This is somewhat more difficult for an off-path attacker due to the need to guess the randomly chosen RTP SSRC value and the RTP sequence number. This attack can be avoided if RTCP packets are authenticated; authentication options are discussed in [RFC7201].
認証されていないRTCPレポートが使用されている場合、パス上の攻撃者は、パケット損失率が高いことを示す偽のRTCPパケットを簡単に生成し、サーキットブレーカーにRTPセッションをトリガーして中断させる可能性があります。ランダムに選択されたRTP SSRC値とRTPシーケンス番号を推測する必要があるため、オフパス攻撃者にとってこれはやや困難です。この攻撃は、RTCPパケットが認証されれば回避できます。認証オプションは[RFC7201]で議論されています。
Timely operation of the RTP circuit breaker depends on the choice of RTCP reporting interval. If the receiver has a reporting interval that is overly long, then the responsiveness of the circuit breaker decreases. In the limit, the RTP circuit breaker can be disabled for all practical purposes by configuring an RTCP reporting interval that has a duration of many minutes. This issue is not specific to the circuit breaker: long RTCP reporting intervals also prevent reception quality reports, feedback messages, codec control messages, etc., from being used. Implementations are expected to impose an upper limit on the RTCP reporting interval they are willing to negotiate (based on the session bandwidth and RTCP bandwidth fraction) when using the RTP circuit breaker, as discussed in Section 4.3.
RTPサーキットブレーカーのタイムリーな動作は、RTCPレポート間隔の選択に依存します。レシーバーのレポート間隔が長すぎると、回路ブレーカーの応答性が低下します。制限では、RTPサーキットブレーカーは、何分も続くRTCPレポート間隔を構成することにより、実用的な目的ですべて無効にすることができます。この問題は回路ブレーカーに固有のものではありません。RTCPレポート間隔が長いと、受信品質レポート、フィードバックメッセージ、コーデック制御メッセージなどが使用できなくなります。 4.3で説明したように、RTPサーキットブレーカを使用する場合、実装では、（セッション帯域幅とRTCP帯域幅の割合に基づいて）ネゴシエートできるRTCPレポート間隔に上限を設けることが期待されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://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, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<http://www.rfc-editor.org/info/rfc4585>。
[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, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<http： //www.rfc-editor.org/info/rfc5348>。
[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, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。
[Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM Computer Communication Review, Volume 30, Issue 4, pages 43-56, DOI 10.1145/347059.347397, August 2000.
[フロイド] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「ユニキャストアプリケーションの方程式ベースの輻輳制御」、ACM SIGCOMM Computer Communication Review、Volume 30、Issue 4、43〜56ページ、DOI 10.1145 / 347059.347397、2000年8月。
[Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", ACM SIGCOMM Computer Communication Review, Volume 27, Issue 3, pages 67-82, DOI 10.1145/263932.264023, July 1997.
[Mathis] Mathis、M.、Semke、J.、Madhavi、J。、およびT. Ott、「TCP輻輳回避アルゴリズムの巨視的な動作」、ACM SIGCOMMコンピュータ通信レビュー、第27巻、第3号、67〜 82、DOI 10.1145 / 263932.264023、1997年7月。
[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", ACM SIGCOMM Computer Communication Review Volume 30, Issue 4, pages 303-314, DOI 10.1145/285237.285291, August 1998.
[Padhye] Padhye、J.、Firoiu、V.、Towsley、D。、およびJ. Kurose、「TCPスループットのモデリング：単純なモデルとその実証的検証」、ACM SIGCOMM Computer Communication Review Volume 30、Issue 4、303ページ-314、DOI 10.1145 / 285237.285291、1998年8月。
[RFC2862] Civanlar, M. and G. Cash, "RTP Payload Format for Real-Time Pointers", RFC 2862, DOI 10.17487/RFC2862, June 2000, <http://www.rfc-editor.org/info/rfc2862>.
[RFC2862] Civanlar、M。、およびG. Cash、「RTP Payload Format for Real-Time Pointers」、RFC 2862、DOI 10.17487 / RFC2862、June 2000、<http://www.rfc-editor.org/info/rfc2862 >。
[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, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <http://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G。およびP. Jones、「RTP Payload for Text Conversation」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<http://www.rfc-editor.org/info/rfc4103>。
[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, <http://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、<http://www.rfc-editor.org/info/rfc5104>。
[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, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, <http://www.rfc-editor.org/info/rfc5450>.
[RFC5450] Singer、D。およびH. Desineni、「RTPストリームの伝送時間オフセット」、RFC 5450、DOI 10.17487 / RFC5450、2009年3月、<http://www.rfc-editor.org/info/rfc5450>。
[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, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5506] Johansson、I。およびM. Westerlund、「Reduced-Size Real-Time Transport Control Protocol（RTCP）：Opportunities and Consequences」、RFC 5506、DOI 10.17487 / RFC5506、2009年4月、<http：// www .rfc-editor.org / info / rfc5506>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012, <http://www.rfc-editor.org/info/rfc6798>.
[RFC6798]クラークA.およびQ.ウー、「パケット遅延変動メトリックレポート用のRTP制御プロトコル（RTCP）拡張レポート（XR）ブロック」、RFC 6798、DOI 10.17487 / RFC6798、2012年11月、<http：// www .rfc-editor.org / info / rfc6798>。
[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, <http://www.rfc-editor.org/info/rfc6843>.
[RFC6843] Clark、A.、Gross、K。、およびQ. Wu、「RTP Control Protocol（RTCP）Extended Report（XR）Block for Delay Metric Reporting」、RFC 6843、DOI 10.17487 / RFC6843、2013年1月、<http ：//www.rfc-editor.org/info/rfc6843>。
[RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", RFC 6958, DOI 10.17487/RFC6958, May 2013, <http://www.rfc-editor.org/info/rfc6958>.
[RFC6958] Clark、A.、Zhang、S.、Zhao、J。、およびQ. Wu、編、「バースト/ギャップロスメトリックレポート用のRTPコントロールプロトコル（RTCP）拡張レポート（XR）ブロック」、RFC 6958 、DOI 10.17487 / RFC6958、2013年5月、<http://www.rfc-editor.org/info/rfc6958>。
[RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting", RFC 7002, DOI 10.17487/RFC7002, September 2013, <http://www.rfc-editor.org/info/rfc7002>.
[RFC7002] Clark、A.、Zorn、G。、およびQ. Wu、「RTP Control Protocol（RTCP）Extended Report（XR）Block for Discard Count Metric Reporting」、RFC 7002、DOI 10.17487 / RFC7002、2013年9月、< http://www.rfc-editor.org/info/rfc7002>。
[RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, September 2013, <http://www.rfc-editor.org/info/rfc7003>.
[RFC7003] Clark、A.、Huang、R。、およびQ. Wu、編、「バースト/ギャップ破棄メトリックレポート用のRTP制御プロトコル（RTCP）拡張レポート（XR）ブロック」、RFC 7003、DOI 10.17487 / RFC7003 、2013年9月、<http://www.rfc-editor.org/info/rfc7003>。
[RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, <http://www.rfc-editor.org/info/rfc7097>.
[RFC7097] Ott、J.、Singh、V.、Ed。、およびI. Curcio、「RTP Control Protocol（RTCP）Extended Report（XR）for RLE of Discarded Packets」、RFC 7097、DOI 10.17487 / RFC7097、2014年1月、<http://www.rfc-editor.org/info/rfc7097>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <http://www.rfc-editor.org/info/rfc7657>.
[RFC7657]ブラック、D。、エド。およびP.ジョーンズ、「Differentiated Services（Diffserv）and Real-Time Communication」、RFC 7657、DOI 10.17487 / RFC7657、2015年11月、<http://www.rfc-editor.org/info/rfc7657>。
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015, <http://www.rfc-editor.org/info/rfc7713>.
[RFC7713] Mathis、M。、およびB. Briscoe、「Congestion Exposure（ConEx）Concepts、Abstract Mechanism、and Requirements」、RFC 7713、DOI 10.17487 / RFC7713、December 2015、<http://www.rfc-editor.org / info / rfc7713>。
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <http://www.rfc-editor.org/info/rfc8084>.
[RFC8084] Fairhurst、G。、「Network Transport Circuit Breakers」、BCP 208、RFC 8084、DOI 10.17487 / RFC8084、2017年3月、<http://www.rfc-editor.org/info/rfc8084>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<http://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, <http://www.rfc-editor.org/info/rfc8108>.
[RFC8108] Lennox、J.、Westerlund、M.、Wu、Q。、およびC. Perkins、「単一のRTPセッションでの複数のRTPストリームの送信」、RFC 8108、DOI 10.17487 / RFC8108、2017年3月、<http：/ /www.rfc-editor.org/info/rfc8108>。
[Sarker] Sarker, Z., Singh, V., and C. Perkins, "An Evaluation of RTP Circuit Breaker Performance on LTE Networks", Proceedings of the IEEE INFOCOM Workshop on Communication and Networking Techniques for Contemporary Video, DOI 10.1109/INFCOMW.2014.6849240, April 2014.
[サーカー]サーカー、Z。、シン、V。、およびC.パーキンス、「LTEネットワークにおけるRTPサーキットブレーカーのパフォーマンスの評価」、IEEE INFOCOM Workshop on Communication and Networking Techniques for Contemporary Video、DOI 10.1109 / INFCOMW .2014.6849240、2014年4月。
[Singh] Singh, V., McQuistin, S., Ellis, M., and C. Perkins, "Circuit Breakers for Multimedia Congestion Control", Proceedings of the 2013 20th International Packet Video Workshop (PV), DOI 10.1109/PV.2013.6691439, December 2013.
[シン] Singh、V.、McQuistin、S.、Ellis、M。、およびC. Perkins、「マルチメディア輻輳制御のための回路ブレーカー」、2013年第20回国際パケットビデオワークショップ（PV）の議事録、DOI 10.1109 / PV。 2013.6691439、2013年12月。
[WebRTC-QoS] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Packet Markings for WebRTC QoS", Work in Progress, draft-ietf-tsvwg-rtcweb-qos-18, August 2016.
[WebRTC-QoS]ジョーンズ、P。、デシカン、S。、ジェニングス、C。、およびD.ドルタ、「WebRTC QoSのDSCPパケットマーキング」、作業中、draft-ietf-tsvwg-rtcweb-qos-18、 2016年8月。
Acknowledgements
謝辞
The authors would like to thank Bernard Aboba, Harald Alvestrand, Ben Campbell, Alissa Cooper, Spencer Dawkins, Gorry Fairhurst, Stephen Farrell, Nazila Fough, Kevin Gross, Cullen Jennings, Randell Jesup, Mirja Kuehlewind, Jonathan Lennox, Matt Mathis, Stephen McQuistin, Simon Perreault, Eric Rescorla, Abheek Saha, Meral Shirazipour, Fabio Verdicchio, and Magnus Westerlund for their valuable feedback.
著者は、バーナードアボバ、ハラルドアルヴェストランド、ベンキャンベル、アリッサクーパー、スペンサードーキンス、ゴーリーフェアハースト、スティーブンファレル、ナジラフォウ、ケビングロス、カレンジェニングス、ランデルジェサップ、ミルジャキュールウィンド、ジョナサンレノックス、マットマティスティンスティーブンマクティンマクティンスティーブンマクティン、Simon Perreault、Eric Rescorla、Abheek Saha、Meral Shirazipour、Fabio Verdicchio、Magnus Westerlundの貴重なフィードバックに感謝します。
Authors' Addresses
著者のアドレス
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
コリン・パーキンスグラスゴー大学コンピューティングサイエンススクールグラスゴーG12 8QQイギリス
Email: csp@csperkins.org
Varun Singh CALLSTATS I/O Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland
Varun Singh CALLSTATS I / O Oy Runeberginkatu 4c A 4ヘルシンキ00100フィンランド
Email: varun@callstats.io
URI: https://www.callstats.io/about