[要約] RFC 8298は、マルチメディアのための自己クロックレート適応に関する要約と目的を提供します。このRFCの目的は、ネットワーク上でのマルチメディアストリームの品質を向上させるために、自己クロックレート適応の仕組みを提案することです。
Internet Engineering Task Force (IETF) I. Johansson
Request for Comments: 8298 Z. Sarker
Category: Experimental Ericsson AB
ISSN: 2070-1721 December 2017
Self-Clocked Rate Adaptation for Multimedia
マルチメディア用の自己クロック速度適応
Abstract
概要
This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay-based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.
このメモは、インタラクティブビデオなどの会話型メディアサービスのレート適応アルゴリズムについて説明しています。このソリューションは、パケット保護の原則に準拠しており、損失と遅延を組み合わせた混雑制御アルゴリズムを使用しています。アルゴリズムは、シミュレートされたインターネットボトルネックシナリオとLong Term Evolution（LTE）システムシミュレータの両方で評価され、これらのシナリオで低遅延と高ビデオスループットの両方を実現することが示されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8298.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8298で入手できます。
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 (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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Wireless (LTE) Access Properties . . . . . . . . . . . . 4
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 6
3.1. Network Congestion Control . . . . . . . . . . . . . . . 8
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 9
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 9
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 10
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Constants and Parameter Values . . . . . . . . . . . 10
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 11
4.1.1.2. State Variables . . . . . . . . . . . . . . . . . 12
4.1.2. Network Congestion Control . . . . . . . . . . . . . 14
4.1.2.1. Reaction to Packet Loss and ECN . . . . . . . . . 17
4.1.2.2. Congestion Window Update . . . . . . . . . . . . 17
4.1.2.3. Competing Flows Compensation . . . . . . . . . . 20
4.1.2.4. Lost Packet Detection . . . . . . . . . . . . . . 22
4.1.2.5. Send Window Calculation . . . . . . . . . . . . . 23
4.1.2.6. Packet Pacing . . . . . . . . . . . . . . . . . . 24
4.1.2.7. Resuming Fast Increase Mode . . . . . . . . . . . 24
4.1.2.8. Stream Prioritization . . . . . . . . . . . . . . 24
4.1.3. Media Rate Control . . . . . . . . . . . . . . . . . 25
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 28
4.2.1. Requirements on Feedback Elements . . . . . . . . . . 28
4.2.2. Requirements on Feedback Intensity . . . . . . . . . 30
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
Congestion in the Internet occurs when the transmitted bitrate is higher than the available capacity over a given transmission path. Applications that are deployed in the Internet have to employ congestion control to achieve robust performance and to avoid congestion collapse in the Internet. Interactive real-time communication imposes a lot of requirements on the transport; therefore, a robust, efficient rate adaptation for all access types is an important part of interactive real-time communications, as the transmission channel bandwidth can vary over time. Wireless access such as LTE, which is an integral part of the current Internet, increases the importance of rate adaptation as the channel bandwidth of a default LTE bearer [QoS-3GPP] can change considerably in a very short time frame. Thus, a rate adaptation solution for interactive real-time media, such as WebRTC [RFC7478], should be both quick and be able to operate over a large range in channel capacity. This memo describes Self-Clocked Rate Adaptation for Multimedia (SCReAM), a solution that implements congestion control for RTP streams [RFC3550]. While SCReAM was originally devised for WebRTC, it can also be used for other applications where congestion control of RTP streams is necessary. SCReAM is based on the self-clocking principle of TCP and uses techniques similar to what is used in the rate adaptation algorithm based on Low Extra Delay Background Transport (LEDBAT) [RFC6817]. SCReAM is not entirely self-clocked as it augments self-clocking with pacing and a minimum send rate. SCReAM can take advantage of Explicit Congestion Notification (ECN) in cases where ECN is supported by the network and the hosts. However, ECN is not required for the basic congestion control functionality in SCReAM.
インターネットの輻輳は、送信されたビットレートが特定の送信パスで利用可能な容量よりも高い場合に発生します。インターネットに展開されているアプリケーションは、堅牢なパフォーマンスを実現し、インターネットでの輻輳の崩壊を回避するために、輻輳制御を採用する必要があります。インタラクティブなリアルタイム通信は、トランスポートに多くの要件を課します。したがって、伝送チャネルの帯域幅は時間とともに変化する可能性があるため、すべてのアクセスタイプに対する堅牢で効率的なレート調整は、インタラクティブなリアルタイム通信の重要な部分です。現在のインターネットに不可欠な部分であるLTEなどのワイヤレスアクセスは、デフォルトのLTEベアラ[QoS-3GPP]のチャネル帯域幅が非常に短い時間枠で大幅に変化する可能性があるため、レート適応の重要性を高めます。したがって、WebRTC [RFC7478]などのインタラクティブなリアルタイムメディアのレート適応ソリューションは、高速で、チャネル容量の広い範囲にわたって動作できる必要があります。このメモは、RTPストリームの輻輳制御を実装するソリューション[RFC3550]である、マルチメディアの自己クロック速度適応（SCReAM）について説明しています。 SCReAMはもともとWebRTC用に考案されましたが、RTPストリームの輻輳制御が必要な他のアプリケーションにも使用できます。 SCReAMは、TCPのセルフクロッキング原理に基づいており、低エクストラ遅延バックグラウンドトランスポート（LEDBAT）[RFC6817]に基づくレート適応アルゴリズムで使用されているものと同様の手法を使用します。 SCReAMは、ペーシングと最小送信レートでセルフクロッキングを強化するため、完全にセルフクロッキングではありません。 SCReAMは、ECNがネットワークとホストでサポートされている場合に、明示的輻輳通知（ECN）を利用できます。ただし、SCReAMの基本的な輻輳制御機能にはECNは必要ありません。
[WIRELESS-TESTS] describes the complications that can be observed in wireless environments. Wireless access such as LTE typically cannot guarantee a given bandwidth; this is true especially for default bearers. The network throughput can vary considerably, for instance, in cases where the wireless terminal is moving around. Even though LTE can support bitrates well above 100 Mbps, there are cases when the available bitrate can be much lower; examples are situations with high network load and poor coverage. An additional complication is that the network throughput can drop for short time intervals (e.g., at handover); these short glitches are initially very difficult to distinguish from more permanent reductions in throughput.
[WIRELESS-TESTS]は、ワイヤレス環境で観察される可能性のある問題を説明しています。 LTEなどのワイヤレスアクセスは、通常、特定の帯域幅を保証できません。これは特にデフォルトのベアラに当てはまります。ネットワークスループットは、たとえば、無線端末が移動している場合など、かなり変動する可能性があります。 LTEは100 Mbpsをはるかに超えるビットレートをサポートできますが、使用可能なビットレートがはるかに低くなる場合があります。例は、ネットワーク負荷が高く、カバレッジが不十分な状況です。さらに複雑になるのは、ネットワークスループットが短い時間間隔で（たとえば、ハンドオーバー時に）低下する可能性があることです。これらの短いグリッチは、スループットの永続的な低下と区別するのが最初は非常に困難です。
Unlike wireline bottlenecks with large statistical multiplexing, it is not possible to try to maintain a given bitrate when congestion is detected with the hope that other flows will yield. This is because there are generally few other flows competing for the same bottleneck. Each user gets its own variable throughput bottleneck, where the throughput depends on factors like channel quality, network load, and historical throughput. The bottom line is, if the throughput drops, the sender has no other option than to reduce the bitrate. Once the radio scheduler has reduced the resource allocation for a bearer, a flow (which is using RTP Media Congestion Avoidance Techniques (RMCAT)) in that bearer aims to reduce the sending rate quite quickly (within one RTT) in order to avoid excessive queuing delay or packet loss.
大規模な統計的多重化を伴う有線のボトルネックとは異なり、他のフローがもたらすことを期待して輻輳が検出された場合、特定のビットレートを維持しようとすることはできません。これは、通常、同じボトルネックを競合する他のフローがほとんどないためです。各ユーザーは、独自の可変スループットボトルネックを取得します。スループットは、チャネルの品質、ネットワーク負荷、履歴スループットなどの要因に依存します。つまり、スループットが低下した場合、送信者にはビットレートを下げる以外の選択肢がありません。無線スケジューラがベアラへのリソース割り当てを削減すると、そのベアラのフロー（RTPメディア輻輳回避技術（RMCAT）を使用）は、過度のキューイングを回避するために（1つのRTT内で）送信レートを非常に迅速に削減します。遅延またはパケット損失。
Self-clocked congestion control algorithms provide a benefit over their rate-based counterparts in that the former consists of two adaptation mechanisms:
セルフクロックの輻輳制御アルゴリズムは、前者が2つの適応メカニズムで構成されているという点で、レートベースの対応アルゴリズムよりも優れています。
o A congestion window computation that evolves over a longer timescale (several RTTs) especially when the congestion window evolution is dictated by estimated delay (to minimize vulnerability to, e.g., short-term delay variations).
o 輻輳ウィンドウの進化が推定遅延によって決定される場合（特に、短期的な遅延変動に対する脆弱性を最小限に抑えるため）、より長いタイムスケール（数RTT）で進化する輻輳ウィンドウの計算。
o A fine-grained congestion control given by the self-clocking; it operates on a shorter time scale (1 RTT). The benefits of self-clocking are also elaborated upon in [TFWC].
o セルフクロッキングによるきめ細かな輻輳制御。より短い時間スケールで動作します（1 RTT）。セルフクロッキングの利点は、[TFWC]でも詳しく説明されています。
A rate-based congestion control algorithm typically adjusts the rate based on delay and loss. The congestion detection needs to be done with a certain time lag to avoid overreaction to spurious congestion events such as delay spikes. Despite the fact that there are two or more congestion indications, the outcome is that there is still only one mechanism to adjust the sending rate. This makes it difficult to reach the goals of high throughput and prompt reaction to congestion.
レートベースの輻輳制御アルゴリズムは、通常、遅延と損失に基づいてレートを調整します。遅延スパイクなどの偽の輻輳イベントへの過剰反応を回避するために、輻輳検出は特定のタイムラグで実行する必要があります。 2つ以上の輻輳の兆候があるという事実にもかかわらず、結果として、送信レートを調整するメカニズムはまだ1つしかありません。これにより、高スループットの目標を達成し、輻輳に対する迅速な対応を困難にします。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The core SCReAM algorithm has similarities to the concepts of self-clocking used in TCP-friendly window-based congestion control [TFWC] and follows the packet conservation principle. The packet conservation principle is described as a key factor behind the protection of networks from congestion [Packet-conservation].
コアSCReAMアルゴリズムは、TCP対応のウィンドウベースの輻輳制御[TFWC]で使用されるセルフクロッキングの概念と類似しており、パケット保存の原則に従います。パケット保存の原則は、ネットワークを輻輳から保護する主要な要素として説明されています[パケット保存]。
In SCReAM, the receiver of the media echoes a list of received RTP packets and the timestamp of the RTP packet with the highest sequence number back to the sender in feedback packets. The sender keeps a list of transmitted packets, their respective sizes, and the time they were transmitted. This information is used to determine the number of bytes that can be transmitted at any given time instant. A congestion window puts an upper limit on how many bytes can be in flight, i.e., transmitted but not yet acknowledged.
SCReAMでは、メディアの受信者は、受信したRTPパケットのリストと、シーケンス番号が最も大きいRTPパケットのタイムスタンプをフィードバックパケットで送信者にエコーします。送信者は、送信されたパケット、それぞれのサイズ、および送信された時間のリストを保持します。この情報は、任意の時点で送信できるバイト数を決定するために使用されます。輻輳ウィンドウは、いくつのバイトを処理中、つまり送信できるがまだ確認されていないかに上限を設けます。
The congestion window is determined in a way similar to LEDBAT [RFC6817]. LEDBAT is a congestion control algorithm that uses send and receive timestamps to estimate the queuing delay (from now on denoted "qdelay") along the transmission path. This information is used to adjust the congestion window. The use of LEDBAT ensures that the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that LEDBAT has certain inherent issues that make it counteract its purpose of achieving low delay. The general problem described in the paper is that the base delay is offset by LEDBAT's own queue buildup. The big difference with using LEDBAT in the SCReAM context lies in the facts that the source is rate limited and that the RTP queue must be kept short (preferably empty). In addition, the output from a video encoder is rarely constant bitrate; static content (talking heads, for instance) gives almost zero video bitrate. This yields two useful properties when LEDBAT is used with SCReAM; they help to avoid the issues described in [LEDBAT-delay-impact]:
輻輳ウィンドウは、LEDBAT [RFC6817]と同様の方法で決定されます。 LEDBATは、送信タイムスタンプと受信タイムスタンプを使用して、送信パスに沿ったキューイング遅延（今後は「qdelay」と表示）を推定する輻輳制御アルゴリズムです。この情報は、輻輳ウィンドウを調整するために使用されます。 LEDBATを使用すると、エンドツーエンドのレイテンシが低く抑えられます。 [LEDBAT-delay-impact]は、LEDBATには、低遅延を達成するという目的を妨げる特定の固有の問題があることを示しています。このペーパーで説明されている一般的な問題は、ベース遅延がLEDBAT自体のキューの蓄積によって相殺されることです。 SCReAMコンテキストでLEDBATを使用することとの大きな違いは、ソースがレート制限されており、RTPキューを短く（できれば空に）保つ必要があるという事実にあります。さらに、ビデオエンコーダーからの出力が一定のビットレートになることはほとんどありません。静的コンテンツ（トーキングヘッドなど）では、ビデオのビットレートはほとんどゼロです。これにより、LEDBATがSCReAMで使用されるときに2つの有用な特性が得られます。 [LEDBAT-delay-impact]で説明されている問題を回避するのに役立ちます。
1. There is always a certain probability that SCReAM is short of data to transmit; this means that the network queue will become empty every once in a while.
1. SCReAMが送信するデータが不足している可能性は常にあります。これは、ネットワークキューが時々空になることを意味します。
2. The max video bitrate can be lower than the link capacity. If the max video bitrate is 5 Mbps and the capacity is 10 Mbps, then the network queue will become empty.
2. 最大ビデオビットレートはリンク容量よりも低くなる場合があります。最大ビデオビットレートが5 Mbpsで容量が10 Mbpsの場合、ネットワークキューは空になります。
It is sufficient that any of the two conditions above is fulfilled to make the base delay update properly. Furthermore, [LEDBAT-delay-impact] describes an issue with short-lived competing flows. In SCReAM, these short-lived flows will cause the self-clocking to slow down, thereby building up the RTP queue; in turn, this results in a reduced media video bitrate. Thus, SCReAM slows the bitrate more when there are competing short-lived flows than the traditional use of LEDBAT does. The basic functionality in the use of LEDBAT in SCReAM is quite simple; however, there are a few steps in order to make the concept work with conversational media:
ベース遅延を正しく更新するには、上記の2つの条件のいずれかが満たされていれば十分です。さらに、[LEDBAT-delay-impact]は、短期間の競合するフローの問題について説明しています。 SCReAMでは、これらの短期間のフローによりセルフクロッキングが遅くなり、RTPキューが増加します。その結果、メディアビデオのビットレートが低下します。したがって、SCReAMは、従来のLEDBATの使用よりも、短期間のフローが競合している場合にビットレートを遅くします。 SCReAMでLEDBATを使用する際の基本的な機能は非常に簡単です。ただし、会話型メディアでコンセプトを機能させるには、いくつかの手順があります。
o Congestion window validation techniques. These are similar to the method described in [RFC7661]. Congestion window validation ensures that the congestion window is limited by the actual number bytes in flight; this is important especially in the context of rate-limited sources such as video. Lack of congestion window validation would lead to a slow reaction to congestion as the congestion window does not properly reflect the congestion state in the network. The allowed idle period in this memo is shorter than in [RFC7661]; this to avoid excessive delays in the cases where, e.g., wireless throughput has decreased during a period where the output bitrate from the media coder has been low (for instance, due to inactivity). Furthermore, this memo allows for more relaxed rules for when the congestion window is allowed to grow; this is necessary as the variable output bitrate generally means that the congestion window is often underutilized.
o 輻輳ウィンドウ検証手法。これらは、[RFC7661]で説明されている方法に似ています。輻輳ウィンドウの検証は、輻輳ウィンドウが実際の飛行中のバイト数によって制限されることを保証します。これは、ビデオなどのレート制限されたソースのコンテキストでは特に重要です。輻輳ウィンドウがネットワークの輻輳状態を適切に反映していないため、輻輳ウィンドウの検証がないと、輻輳への反応が遅くなります。このメモの許可されたアイドル期間は[RFC7661]よりも短いです;これは、メディアコーダーからの出力ビットレートが低い（たとえば、非アクティブのため）期間中にワイヤレススループットが低下した場合に、過度の遅延を回避するためです。さらに、このメモでは、輻輳ウィンドウの拡大を許可するタイミングについて、より緩和されたルールを使用できます。可変出力ビットレートは通常、輻輳ウィンドウが十分に活用されていないことを意味するため、これは必要です。
o Fast increase mode makes the bitrate increase faster when no congestion is detected. It makes the media bitrate ramp up within 5 to 10 seconds. The behavior is similar to TCP slowstart. Fast increase mode is exited when congestion is detected. However, fast increase mode can resume if the congestion level is low; this enables a reasonably quick rate increase in case link throughput increases.
o 高速増加モードでは、輻輳が検出されない場合、ビットレートの増加が速くなります。メディアのビットレートが5〜10秒以内に上昇します。動作はTCPスロースタートに似ています。輻輳が検出されると、高速増加モードが終了します。ただし、輻輳レベルが低い場合、高速増加モードは再開できます。これにより、リンクのスループットが増加した場合に、適度に速いレート増加が可能になります。
o A qdelay trend is computed for earlier detection of incipient congestion; as a result, it reduces jitter.
o qdelayトレンドは、初期の輻輳を早期に検出するために計算されます。その結果、ジッターが減少します。
o Addition of a media rate control function.
o メディアレートコントロール機能の追加。
o Use of inflection points in the media rate calculation to achieve reduced jitter.
o メディアレートの計算で変曲点を使用して、ジッタを低減します。
o Adjustment of qdelay target for better performance when competing with other loss-based congestion-controlled flows.
o 他の損失ベースの輻輳制御フローと競合する場合のパフォーマンス向上のためのqdelayターゲットの調整。
The above-mentioned features will be described in more detail in Sections 3.1 to 3.3. The full details are described in Section 4.
上記の機能については、3.1項から3.3項で詳しく説明します。詳細については、セクション4で説明します。
+---------------------------+
| Media encoder |
+---------------------------+
^ |
| |(1)
|(3) RTP
| V
| +-----------+
+---------+ | |
| Media | (2) | Queue |
| rate |<------| |
| control | |RTP packets|
+---------+ | |
+-----------+
|
|(4)
RTP
|
v
+------------+ +--------------+
| Network | (7) | Sender |
+-->| congestion |------>| Transmission |
| | control | | Control |
| +------------+ +--------------+
| |
|-------------RTCP----------| |(5)
(6) | RTP
| v
+------------+
| UDP |
| socket |
+------------+
Figure 1: SCReAM Sender Functional View
図1：SCReAM送信者の機能ビュー
The SCReAM algorithm consists of three main parts: network congestion control, sender transmission control, and media rate control. All of these parts reside at the sender side. Figure 1 shows the functional overview of a SCReAM sender. The receiver-side algorithm is very simple in comparison, as it only generates feedback containing acknowledgements of received RTP packets and an ECN count.
SCReAMアルゴリズムは、ネットワーク輻輳制御、送信者送信制御、およびメディアレート制御の3つの主要部分で構成されています。これらのパーツはすべて送信側にあります。図1は、SCReAM送信側の機能概要を示しています。受信側のアルゴリズムは、受信したRTPパケットの確認応答とECNカウントのみを含むフィードバックを生成するため、比較すると非常に単純です。
The network congestion control sets an upper limit on how much data can be in the network (bytes in flight); this limit is called CWND (congestion window) and is used in the sender transmission control.
ネットワークの輻輳制御は、ネットワーク内に存在できるデータの量の上限（処理中のバイト数）を設定します。この制限はCWND（輻輳ウィンドウ）と呼ばれ、送信側の送信制御で使用されます。
The SCReAM congestion control method uses techniques similar to LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT, it is not necessary to use synchronized clocks in the sender and receiver in order to compute the qdelay. However, it is necessary that they use the same clock frequency, or that the clock frequency at the receiver can be inferred reliably by the sender. Failure to meet this requirement leads to malfunction in the SCReAM congestion control algorithm due to incorrect estimation of the network queue delay.
SCReAM輻輳制御方法は、LEDBAT [RFC6817]と同様の手法を使用してqdelayを測定します。 LEDBATの場合と同様に、qdelayを計算するために送信側と受信側で同期クロックを使用する必要はありません。ただし、同じクロック周波数を使用するか、受信側のクロック周波数を送信側が確実に推測できることが必要です。この要件を満たしていない場合、ネットワークキュー遅延の推定が正しくないため、SCReAM輻輳制御アルゴリズムが誤動作します。
The SCReAM sender calculates the congestion window based on the feedback from the SCReAM receiver. The congestion window is allowed to increase if the qdelay is below a predefined qdelay target; otherwise, the congestion window decreases. The qdelay target is typically set to 50-100 ms. This ensures that the queuing delay is kept low. The reaction to loss or ECN events leads to an instant reduction of CWND. Note that the source rate-limited nature of real-time media, such as video, typically means that the queuing delay will mostly be below the given delay target. This is contrary to the case where large files are transmitted using LEDBAT congestion control and the queuing delay will stay close to the delay target.
SCReAM送信側は、SCReAM受信側からのフィードバックに基づいて輻輳ウィンドウを計算します。 qdelayが事前定義されたqdelayターゲットを下回っている場合は、輻輳ウィンドウを増やすことができます。そうでない場合、輻輳ウィンドウは減少します。 qdelayターゲットは、通常50〜100ミリ秒に設定されます。これにより、キューイング遅延が低く抑えられます。損失またはECNイベントへの反応により、CWNDが即座に減少します。ビデオなどのリアルタイムメディアのソースレート制限の性質は、通常、キューイング遅延がほとんどの場合、指定された遅延ターゲットを下回ることを意味します。これは、LEDBAT輻輳制御を使用して大きなファイルが送信され、キューイング遅延が遅延ターゲットの近くに留まる場合とは逆です。
The sender transmission control limits the output of data, given by the relation between the number of bytes in flight and the congestion window. Packet pacing is used to mitigate issues with ACK compression that MAY cause increased jitter and/or packet loss in the media traffic. Packet pacing limits the packet transmission rate given by the estimated link throughput. Even if the send window allows for the transmission of a number of packets, these packets are not transmitted immediately; rather, they are transmitted in intervals given by the packet size and the estimated link throughput.
送信側の送信制御は、データの出力を制限します。これは、飛行中のバイト数と輻輳ウィンドウの間の関係によって与えられます。パケットペーシングは、メディアトラフィックのジッターやパケット損失の増加を引き起こす可能性があるACK圧縮の問題を軽減するために使用されます。パケットペーシングは、推定リンクスループットによって与えられるパケット伝送速度を制限します。送信ウィンドウで複数のパケットを送信できる場合でも、これらのパケットはすぐには送信されません。むしろ、それらは、パケットサイズと推定リンクスループットによって指定された間隔で送信されます。
The media rate control serves to adjust the media bitrate to ramp up quickly enough to get a fair share of the system resources when link throughput increases.
メディアレート制御は、メディアビットレートを調整して、リンクスループットが増加したときにシステムリソースの公平なシェアを獲得するのに十分な速さで増加するように機能します。
The reaction to reduced throughput MUST be prompt in order to avoid getting too much data queued in the RTP packet queue(s) in the sender. The media bitrate is decreased if the RTP queue size exceeds a threshold.
送信者のRTPパケットキューにキューイングされるデータが多すぎないようにするため、スループットの低下に対する反応は迅速でなければなりません。 RTPキューサイズがしきい値を超えると、メディアビットレートが減少します。
In cases where the sender's frame queues increase rapidly, such as in the case of a Radio Access Type (RAT) handover, the SCReAM sender MAY implement additional actions, such as discarding of encoded media frames or frame skipping in order to ensure that the RTP queues are drained quickly. Frame skipping results in the frame rate being temporarily reduced. Which method to use is a design choice and is outside the scope of this algorithm description.
Radio Access Type（RAT）ハンドオーバーのように、送信者のフレームキューが急速に増加する場合、SCReAM送信者は、RTPを確実にするために、エンコードされたメディアフレームの廃棄やフレームスキップなどの追加のアクションを実装できます（MAY）。キューはすぐに排出されます。フレームをスキップすると、フレームレートが一時的に低下します。どちらの方法を使用するかは設計上の選択であり、このアルゴリズムの説明の範囲外です。
This section describes the sender-side algorithm in more detail. It is split between the network congestion control, sender transmission control, and media rate control.
このセクションでは、送信側のアルゴリズムについて詳しく説明します。これは、ネットワークの輻輳制御、送信者送信制御、およびメディアレート制御に分割されます。
A SCReAM sender implements media rate control and an RTP queue for each media type or source, where RTP packets containing encoded media frames are temporarily stored for transmission. Figure 1 shows the details when a single media source (or stream) is used. A transmission scheduler (not shown in the figure) is added to support multiple streams. The transmission scheduler can enforce differing priorities between the streams and act like a coupled congestion controller for multiple flows. Support for multiple streams is implemented in [SCReAM-CPP-implementation].
SCReAM送信側は、メディアタイプまたはソースごとにメディアレート制御とRTPキューを実装します。エンコードされたメディアフレームを含むRTPパケットは、送信用に一時的に保存されます。図1は、単一のメディアソース（またはストリーム）を使用した場合の詳細を示しています。複数のストリームをサポートするために、送信スケジューラ（図には示されていない）が追加されています。送信スケジューラは、ストリーム間で異なる優先度を適用し、複数のフローに対して結合された輻輳コントローラのように機能できます。複数のストリームのサポートは、[SCReAM-CPP-implementation]で実装されています。
Media frames are encoded and forwarded to the RTP queue (1) in Figure 1. The media rate adaptation adapts to the size of the RTP queue (2) and provides a target rate for the media encoder (3). The RTP packets are picked from the RTP queue (4), for multiple flows from each RTP queue based on some defined priority order or simply in a round-robin fashion, by the sender transmission controller. The sender transmission controller (in case of multiple flows a transmission scheduler) sends the RTP packets to the UDP socket (5). In the general case, all media SHOULD go through the sender transmission controller and is limited so that the number of bytes in flight is less than the congestion window. RTCP packets are received (6) and the information about the bytes in flight and congestion window is exchanged between the network congestion control and the sender transmission control (7).
メディアフレームはエンコードされ、図1のRTPキュー（1）に転送されます。メディアレート適応はRTPキュー（2）のサイズに適応し、メディアエンコーダー（3）にターゲットレートを提供します。 RTPパケットは、RTPキュー（4）から選択されます。送信側の伝送コントローラーによって、定義された優先順位に基づいて、または単にラウンドロビン方式で、各RTPキューからの複数のフローが選択されます。送信側送信コントローラー（複数のフローの場合は送信スケジューラー）がRTPパケットをUDPソケットに送信します（5）。一般的なケースでは、すべてのメディアは送信側伝送コントローラーを通過する必要があり（SHOULD）、飛行中のバイト数が輻輳ウィンドウよりも小さくなるように制限されます。 RTCPパケットが受信され（6）、処理中のバイトと輻輳ウィンドウに関する情報がネットワークの輻輳制御と送信側送信制御の間で交換されます（7）。
Constants and state variables are listed in this section. Temporary variables are not listed; instead, they are appended with '_t' in the pseudocode to indicate their local scope.
このセクションには、定数と状態変数がリストされています。一時変数はリストされていません。代わりに、ローカルスコープを示すために、疑似コードに「_t」が追加されます。
The RECOMMENDED values, within parentheses "()", for the constants are deduced from experiments.
定数の括弧（()）内の推奨値は、実験から推定されます。
QDELAY_TARGET_LO (0.1 s) Target value for the minimum qdelay.
QDELAY_TARGET_LO（0.1 s）最小qdelayのターゲット値。
QDELAY_TARGET_HI (0.4 s) Target value for the maximum qdelay. This parameter provides an upper limit to how much the target qdelay (qdelay_target) can be increased in order to cope with competing loss-based flows. However, the target qdelay does not have to be initialized to this high value, as it would increase end-to-end delay and also make the rate control and congestion control loops sluggish.
QDELAY_TARGET_HI（0.4 s）最大qdelayのターゲット値。このパラメーターは、競合する損失ベースのフローに対処するためにターゲットqdelay（qdelay_target）をどれだけ増やすことができるかの上限を提供します。ただし、ターゲットのqdelayをこの高い値に初期化する必要はありません。エンドツーエンドの遅延が増加し、レート制御と輻輳制御のループが遅くなるためです。
QDELAY_WEIGHT (0.1) Averaging factor for qdelay_fraction_avg.
QDELAY_WEIGHT（0.1）qdelay_fraction_avgの平均係数。
QDELAY_TREND_TH (0.2) Threshold for the detection of incipient congestion.
QDELAY_TREND_TH（0.2）初期の輻輳を検出するためのしきい値。
MIN_CWND (3000 bytes) Minimum congestion window.
MIN_CWND（3000バイト）最小輻輳ウィンドウ。
MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) Headroom for the limitation of CWND.
MAX_BYTES_IN_FLIGHT_HEAD_ROOM（1.1）CWNDの制限のためのヘッドルーム。
GAIN (1.0) Gain factor for congestion window adjustment.
GAIN（1.0）輻輳ウィンドウ調整のゲイン係数。
BETA_LOSS (0.8) CWND scale factor due to loss event.
BETA_LOSS（0.8）損失イベントによるCWNDスケール係数。
BETA_ECN (0.9) CWND scale factor due to ECN event.
BETA_ECN（0.9）ECNイベントによるCWNDスケール係数。
BETA_R (0.9) Scale factor for target rate due to loss event.
BETA_R（0.9）損失イベントによる目標レートのスケール係数。
MSS (1000 byte) Maximum segment size = Max RTP packet size.
MSS（1000バイト）最大セグメントサイズ=最大RTPパケットサイズ。
RATE_ADJUST_INTERVAL (0.2 s) Interval between media bitrate adjustments.
RATE_ADJUST_INTERVAL（0.2 s）メディアのビットレート調整の間隔。
TARGET_BITRATE_MIN Minimum target bitrate in bps (bits per second).
TARGET_BITRATE_MIN bps（ビット/秒）単位の最小ターゲットビットレート。
TARGET_BITRATE_MAX Maximum target bitrate in bps.
TARGET_BITRATE_MAX最大ターゲットビットレート（bps）。
RAMP_UP_SPEED (200000 bps/s) Maximum allowed rate increase speed.
RAMP_UP_SPEED（200000 bps / s）最大許容レート増加速度。
PRE_CONGESTION_GUARD (0.0..1.0) Guard factor against early congestion onset. A higher value gives less jitter, possibly at the expense of a lower link utilization. This value MAY be subject to tuning depending on e.g., media coder characteristics. Experiments with H264 and VP8 indicate that 0.1 is a suitable value. See [SCReAM-CPP-implementation] and [SCReAM-implementation-experience] for evaluation of a real implementation.
PRE_CONGESTION_GUARD（0.0..1.0）早期の輻輳発生に対するガードファクター。値を高くするとジッターが少なくなりますが、リンクの使用率が低くなります。この値は、メディアコーダーの特性などに応じて調整される場合があります。 H264とVP8での実験では、0.1が適切な値であることを示しています。実際の実装の評価については、[SCReAM-CPP-implementation]および[SCReAM-implementation-experience]を参照してください。
TX_QUEUE_SIZE_FACTOR (0.0..2.0) Guard factor against RTP queue buildup. This value MAY be subject to tuning depending on, e.g., media coder characteristics. Experiments with H264 and VP8 indicate that 1.0 is a suitable value. See [SCReAM-CPP-implementation] and [SCReAM-implementation-experience] for evaluation of a real implementation.
TX_QUEUE_SIZE_FACTOR（0.0..2.0）RTPキューの増加に対するガードファクター。この値は、メディアコーダーの特性などに応じて調整される場合があります。 H264とVP8の実験では、1.0が適切な値であることを示しています。実際の実装の評価については、[SCReAM-CPP-implementation]および[SCReAM-implementation-experience]を参照してください。
RTP_QDELAY_TH (0.02 s) RTP queue delay threshold for a target rate reduction.
RTP_QDELAY_TH（0.02 s）ターゲットレート削減のためのRTPキュー遅延しきい値。
TARGET_RATE_SCALE_RTP_QDELAY (0.95) Scale factor for target rate when RTP qdelay threshold exceeds RTP_QDELAY_TH.
TARGET_RATE_SCALE_RTP_QDELAY（0.95）RTP qdelayしきい値がRTP_QDELAY_THを超える場合のターゲットレートのスケール係数。
QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
QDELAY_TREND_LO（0.2）qdelay_trendのしきい値。
T_RESUME_FAST_INCREASE (5 s) Time span until fast increase mode can be resumed, given that the qdelay_trend is below QDELAY_TREND_LO.
T_RESUME_FAST_INCREASE（5 s）qdelay_trendがQDELAY_TREND_LOを下回っていると仮定して、高速増加モードを再開できるまでの時間。
RATE_PACE_MIN (50000 bps) Minimum pacing rate.
RATE_PACE_MIN（50000 bps）最小ペーシングレート。
The values within parentheses "()" indicate initial values.
括弧()内の値は初期値を示します。
qdelay_target (QDELAY_TARGET_LO) qdelay target, a variable qdelay target is introduced to manage cases where a fixed qdelay target would otherwise starve the RMCAT flow under such circumstances (e.g., FTP competes for the bandwidth over the same bottleneck). The qdelay target is allowed to vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.
qdelay_target（QDELAY_TARGET_LO）qdelayターゲット。可変qdelayターゲットが導入され、固定qdelayターゲットがそのような状況でRMCATフローを枯渇させるケースを管理します（たとえば、FTPは同じボトルネックで帯域幅を競合します）。 qdelayターゲットは、QDELAY_TARGET_LOとQDELAY_TARGET_HIの間で変更できます。
qdelay_fraction_avg (0.0) Fractional qdelay filtered by the Exponentially Weighted Moving Average (EWMA).
qdelay_fraction_avg（0.0）指数加重移動平均（EWMA）によってフィルター処理された分数qdelay。
qdelay_fraction_hist[20] ({0,..,0}) Vector of the last 20 fractional qdelay samples.
qdelay_fraction_hist [20]（{0、..、0}）最後の20個の小数qdelayサンプルのベクトル。
qdelay_trend (0.0) qdelay trend; indicates incipient congestion.
qdelay_trend（0.0）qdelayトレンド。初期の輻輳を示します。
qdelay_trend_mem (0.0) Low-pass filtered version of qdelay_trend.
qdelay_trend_mem（0.0）qdelay_trendのローパスフィルターバージョン。
qdelay_norm_hist[100] ({0,..,0}) Vector of the last 100 normalized qdelay samples.
qdelay_norm_hist [100]（{0、..、0}）最後の100個の正規化されたqdelayサンプルのベクトル。
in_fast_increase (true) True if in fast increase mode.
in_fast_increase（true）高速増加モードの場合はtrue。
cwnd (MIN_CWND) Congestion window.
cwnd（MIN_CWND）輻輳ウィンドウ。
bytes_newly_acked (0) The number of bytes that was acknowledged with the last received acknowledgement, i.e., bytes acknowledged since the last CWND update.
bytes_newly_acked（0）最後に受信した確認応答で確認応答されたバイト数、つまり最後のCWND更新以降に確認応答されたバイト数。
max_bytes_in_flight (0) The maximum number of bytes in flight over a sliding time window, i.e., transmitted but not yet acknowledged bytes.
max_bytes_in_flight（0）スライディング時間ウィンドウ上での飛行中の最大バイト数。つまり、送信されたがまだ確認応答されていないバイト。
send_wnd (0) Upper limit to how many bytes can currently be transmitted. Updated when cwnd is updated and when RTP packet is transmitted.
send_wnd（0）現在送信できるバイト数の上限。 cwndが更新されたとき、およびRTPパケットが送信されたときに更新されます。
target_bitrate (0 bps) Media target bitrate.
target_bitrate（0 bps）メディアターゲットビットレート。
target_bitrate_last_max (1 bps) Inflection point of the media target bitrate, i.e., the last known highest target_bitrate. Used to limit bitrate increase speed close to the last known congestion point.
target_bitrate_last_max（1 bps）メディアターゲットビットレートの変曲点、つまり最後に認識された最高のtarget_bitrate。最後の既知の輻輳ポイントに近いビットレート増加速度を制限するために使用されます。
rate_transmit (0.0 bps) Measured transmit bitrate.
rate_transmit（0.0 bps）測定された送信ビットレート。
rate_ack (0.0 bps) Measured throughput based on received acknowledgements.
rate_ack（0.0 bps）受信した確認応答に基づいて測定されたスループット。
rate_media (0.0 bps) Measured bitrate from the media encoder.
rate_media（0.0 bps）メディアエンコーダーから測定されたビットレート。
rate_media_median (0.0 bps) Median value of rate_media, computed over more than 10 s.
rate_media_median（0.0 bps）10秒を超えて計算されたrate_mediaの中央値。
s_rtt (0.0s) Smoothed RTT (in seconds), computed with a similar method to that described in [RFC6298].
s_rtt（0.0s）[RFC6298]で説明されているのと同様の方法で計算された平滑化RTT（秒単位）。
rtp_queue_size (0 bits) Sum of the sizes of RTP packets in queue.
rtp_queue_size（0ビット）キュー内のRTPパケットのサイズの合計。
rtp_size (0 byte) Size of the last transmitted RTP packet.
rtp_size（0バイト）最後に送信されたRTPパケットのサイズ。
loss_event_rate (0.0) The estimated fraction of RTTs with lost packets detected.
loss_event_rate（0.0）失われたパケットが検出されたRTTの推定割合。
This section explains the network congestion control, which performs two main functions:
このセクションでは、2つの主要な機能を実行するネットワーク輻輳制御について説明します。
o Computation of congestion window at the sender: This gives an upper limit to the number of bytes in flight.
o 送信側の輻輳ウィンドウの計算：これにより、処理中のバイト数に上限が与えられます。
o Calculation of send window at the sender: RTP packets are transmitted if allowed by the relation between the number of bytes in flight and the congestion window. This is controlled by the send window.
o 送信側での送信ウィンドウの計算：RTPパケットは、送信中のバイト数と輻輳ウィンドウの関係によって許可されている場合に送信されます。これは、送信ウィンドウによって制御されます。
SCReAM is a window-based and byte-oriented congestion control protocol, where the number of bytes transmitted is inferred from the size of the transmitted RTP packets. Thus, a list of transmitted RTP packets and their respective transmission times (wall-clock time) MUST be kept for further calculation.
SCReAMはウィンドウベースのバイト指向の輻輳制御プロトコルで、送信されるバイト数は送信されるRTPパケットのサイズから推測されます。したがって、送信されたRTPパケットとそれぞれの送信時間（実時間）のリストは、さらに計算するために保持する必要があります。
The number of bytes in flight (bytes_in_flight) is computed as the sum of the sizes of the RTP packets ranging from the RTP packet most recently transmitted, down to but not including the acknowledged packet with the highest sequence number. This can be translated to the difference between the highest transmitted byte sequence number and the highest acknowledged byte sequence number. As an example: If an RTP packet with sequence number SN is transmitted and the last acknowledgement indicates SN-5 as the highest received sequence number, then bytes_in_flight is computed as the sum of the size of RTP packets with sequence number SN-4, SN-3, SN-2, SN-1, and SN. It does not matter if, for instance, the packet with sequence number SN-3 was lost -- the size of RTP packet with sequence number SN-3 will still be considered in the computation of bytes_in_flight.
処理中のバイト数（bytes_in_flight）は、最後に送信されたRTPパケットから、最も大きいシーケンス番号の確認済みパケットまでの、RTPパケットのサイズの合計として計算されます。これは、送信された最大のバイトシーケンス番号と確認された最大のバイトシーケンス番号の差に変換できます。例：シーケンス番号SNのRTPパケットが送信され、最後の確認応答がSN-5を受信した最大のシーケンス番号として示している場合、bytes_in_flightはシーケンス番号SN-4、SNのRTPパケットのサイズの合計として計算されます。 -3、SN-2、SN-1、SN。たとえば、シーケンス番号SN-3のパケットが失われたかどうかは関係ありません。シーケンス番号SN-3のRTPパケットのサイズは、bytes_in_flightの計算で考慮されます。
Furthermore, a variable bytes_newly_acked is incremented with a value corresponding to how much the highest sequence number has increased since the last feedback. As an example: If the previous acknowledgement indicated the highest sequence number N and the new acknowledgement indicated N+3, then bytes_newly_acked is incremented by a value equal to the sum of the sizes of RTP packets with sequence number N+1, N+2, and N+3. Packets that are lost are also included, which means that even though, e.g., packet N+2 was lost, its size is still included in the update of bytes_newly_acked. The bytes_newly_acked variable is reset to zero after a CWND update.
さらに、変数bytes_newly_ackedは、最後のフィードバック以降に最大シーケンス番号がどれだけ増加したかに対応する値で増分されます。例：前の確認応答が最高のシーケンス番号Nを示し、新しい確認応答がN + 3を示した場合、bytes_newly_ackedは、シーケンス番号N + 1、N + 2のRTPパケットのサイズの合計に等しい値だけ増加します。 、N + 3。失われたパケットも含まれます。これは、たとえば、パケットN + 2が失われた場合でも、そのサイズは引き続きbytes_newly_ackedの更新に含まれます。 CWNDの更新後、bytes_newly_acked変数はゼロにリセットされます。
The feedback from the receiver is assumed to consist of the following elements.
受信機からのフィードバックは、以下の要素で構成されると想定されます。
o A list of received RTP packets' sequence numbers.
o 受信したRTPパケットのシーケンス番号のリスト。
o The wall-clock timestamp corresponding to the received RTP packet with the highest sequence number.
o シーケンス番号が最大の受信RTPパケットに対応する壁時計のタイムスタンプ。
o The accumulated number of ECN-CE-marked packets (n_ECN). Here, "CE" refers to "Congestion Experienced".
o ECN-CEでマークされたパケットの累積数（n_ECN）。ここで、「CE」は「Congestion Experienced」を意味します。
When the sender receives RTCP feedback, the qdelay is calculated as outlined in [RFC6817]. A qdelay sample is obtained for each received acknowledgement. No smoothing of the qdelay is performed; however, some smoothing occurs anyway because the CWND computation is a low-pass filter function. A number of variables are updated as illustrated by the pseudocode below; temporary variables are appended with '_t'. As mentioned in Section 6, calculation of the proper congestion window and media bitrate may benefit from additional optimizations to handle very high and very low bitrates, and from additional damping to handle periodic packet bursts. Some such optimizations are implemented in [SCReAM-CPP-implementation], but they do not form part of the specification of SCReAM at this time.
送信者がRTCPフィードバックを受信すると、[RFC6817]で概説されているようにqdelayが計算されます。受信した確認応答ごとにqdelayサンプルが取得されます。 qdelayの平滑化は実行されません。ただし、CWND計算はローパスフィルター関数であるため、いずれにせよ平滑化が行われます。以下の疑似コードに示すように、いくつかの変数が更新されます。一時変数には「_t」が追加されます。セクション6で述べたように、適切な輻輳ウィンドウとメディアビットレートの計算は、非常に高いビットレートと非常に低いビットレートを処理するための追加の最適化と、定期的なパケットバーストを処理するための追加のダンピングから恩恵を受ける場合があります。このような最適化の一部は[SCReAM-CPP-implementation]に実装されていますが、現時点ではSCReAMの仕様の一部を構成していません。
<CODE BEGINS>
update_variables(qdelay):
qdelay_fraction_t = qdelay / qdelay_target
# Calculate moving average
qdelay_fraction_avg = (1 - QDELAY_WEIGHT) * qdelay_fraction_avg +
QDELAY_WEIGHT * qdelay_fraction_t
update_qdelay_fraction_hist(qdelay_fraction_t)
# Compute the average of the values in qdelay_fraction_hist
avg_t = average(qdelay_fraction_hist)
# R is an autocorrelation function of qdelay_fraction_hist,
# with the mean (DC component) removed, at lag K
# The subtraction of the scalar avg_t from
# qdelay_fraction_hist is performed element-wise
a_t = R(qdelay_fraction_hist-avg_t, 1) /
R(qdelay_fraction_hist-avg_t, 0)
# Calculate qdelay trend
qdelay_trend = min(1.0, max(0.0, a_t * qdelay_fraction_avg))
# Calculate a 'peak-hold' qdelay_trend; this gives a memory
# of congestion in the past
qdelay_trend_mem = max(0.99 * qdelay_trend_mem, qdelay_trend)
<CODE ENDS>
The qdelay fraction is sampled every 50 ms, and the last 20 samples are stored in a vector (qdelay_fraction_hist). This vector is used in the computation of a qdelay trend that gives a value between 0.0 and 1.0 depending on the estimated congestion level. The prediction coefficient 'a_t' has positive values if qdelay shows an increasing or decreasing trend; thus, an indication of congestion is obtained before the qdelay target is reached. As a side effect, if qdelay decreases, it's taken as a sign of congestion; however, experiments have shown that this is beneficial, as increasing or decreasing queue delay is an indication that the transmit rate is very close to the path capacity.
qdelay分数は50ミリ秒ごとにサンプリングされ、最後の20サンプルはベクトル（qdelay_fraction_hist）に格納されます。このベクトルは、推定された輻輳レベルに応じて0.0と1.0の間の値を与えるqdelayトレンドの計算に使用されます。 qdelayが増加または減少傾向を示す場合、予測係数 'a_t'は正の値になります。したがって、qdelayターゲットに到達する前に、輻輳の兆候が取得されます。副作用として、qdelayが減少すると、それは輻輳の兆候と見なされます。ただし、キュー遅延の増加または減少は送信レートがパス容量に非常に近いことを示すため、これは有益であることが実験で示されています。
The autocorrelation function 'R' is defined as follows. Let x be a vector constituting N values, the biased autocorrelation function for a given lag=k for the vector x is given by.
自己相関関数「R」は次のように定義されます。 xをN個の値を構成するベクトルとすると、ベクトルxの特定のlag = kのバイアス自己相関関数は次のようになります。
n=N-k
R(x,k) = SUM x(n) * x(n + k)
n=1
The prediction coefficient is further multiplied with qdelay_fraction_avg to reduce sensitivity to increasing qdelay when it is very small. The 50 ms sampling is a simplification that could have the effect that the same qdelay is sampled several times; however, this does not pose any problem, as the vector is only used to determine if the qdelay is increasing or decreasing. The qdelay_trend is utilized in the media rate control to indicate incipient congestion and to determine when to exit from fast increase mode. qdelay_trend_mem is used to enforce a less aggressive rate increase after congestion events. The function update_qdelay_fraction_hist(..) removes the oldest element and adds the latest qdelay_fraction element to the qdelay_fraction_hist vector.
予測係数にqdelay_fraction_avgをさらに乗算して、qdelayが非常に小さい場合に、qdelayの増加に対する感度を下げます。 50 msのサンプリングは、同じqdelayが数回サンプリングされるという影響を与える可能性がある単純化です。ただし、ベクトルはqdelayが増加しているか減少しているかを判断するためにのみ使用されるため、これは問題にはなりません。 qdelay_trendは、メディアレート制御で使用され、初期の輻輳を示し、高速増加モードを終了するタイミングを決定します。 qdelay_trend_memを使用して、輻輳イベント後の積極的なレート増加を強制します。関数update_qdelay_fraction_hist（..）は最も古い要素を削除し、最新のqdelay_fraction要素をqdelay_fraction_histベクトルに追加します。
A loss event is indicated if one or more RTP packets are declared missing. The loss detection is described in Section 4.1.2.4. Once a loss event is detected, further detected lost RTP packets SHOULD be ignored for a full smoothed round-trip time; the intention is to limit the congestion window decrease to at most once per round trip.
1つ以上のRTPパケットが欠落していると宣言された場合、損失イベントが示されます。損失の検出については、セクション4.1.2.4で説明しています。損失イベントが検出されると、完全に平滑化された往復時間の間、さらに検出された失われたRTPパケットは無視されるべきです（SHOULD）。目的は、輻輳ウィンドウの減少を、往復ごとに最大で1回に制限することです。
The congestion window back-off due to loss events is deliberately a bit less than is the case with TCP Reno, for example. TCP is generally used to transmit whole files; the file is then like a source with an infinite bitrate until the whole file has been transmitted. SCReAM, on the other hand, has a source whose rate is limited to a value close to the available transmit rate and often below that value; the effect is that SCReAM has less opportunity to grab free capacity than a TCP-based file transfer. To compensate for this, it is RECOMMENDED to let SCReAM reduce the congestion window less than what is the case with TCP when loss events occur.
損失イベントによる輻輳ウィンドウのバックオフは、たとえばTCP Renoの場合よりも意図的に少し少なくなっています。 TCPは通常、ファイル全体を送信するために使用されます。その場合、ファイルは、ファイル全体が送信されるまで、ビットレートが無限のソースのようになります。一方、SCReAMのソースは、使用可能な送信レートに近い値に制限されており、その値を下回ることがよくあります。その結果、SCReAMは、TCPベースのファイル転送よりも空き容量を取得する機会が少なくなります。これを補うために、SCReAMが輻輳ウィンドウを、ロスイベントが発生したときのTCPの場合よりも少なくなるようにすることをお勧めします。
An ECN event is detected if the n_ECN counter in the feedback report has increased since the previous received feedback. Once an ECN event is detected, the n_ECN counter is ignored for a full smoothed round-trip time; the intention is to limit the congestion window decrease to at most once per round trip. The congestion window back-off due to an ECN event MAY be smaller than if a loss event occurs. This is in line with the idea outlined in [ALT-BACKOFF] to enable ECN marking thresholds lower than the corresponding packet drop thresholds.
フィードバックレポートのn_ECNカウンターが前回受信したフィードバック以降増加した場合、ECNイベントが検出されます。 ECNイベントが検出されると、n_ECNカウンターは、完全に平滑化された往復時間に対して無視されます。目的は、輻輳ウィンドウの減少を、往復ごとに最大で1回に制限することです。 ECNイベントによる輻輳ウィンドウのバックオフは、損失イベントが発生した場合よりも小さくなる場合があります。これは、対応するパケットドロップしきい値よりも低いECNマーキングしきい値を有効にする[ALT-BACKOFF]で概説されているアイデアと一致しています。
The update of the congestion window depends on if loss, ECN-marking, or neither of the two occurs. The pseudocode below describes the actions for each case.
輻輳ウィンドウの更新は、損失、ECNマーキング、またはこの2つのどちらも発生しないかどうかによって異なります。以下の疑似コードは、各ケースのアクションを説明しています。
<CODE BEGINS>
on congestion event(qdelay):
# Either loss or ECN mark is detected
in_fast_increase = false
if (is loss)
# Loss is detected
cwnd = max(MIN_CWND, cwnd * BETA_LOSS)
else
# No loss, so it is then an ECN mark
cwnd = max(MIN_CWND, cwnd * BETA_ECN)
end
adjust_qdelay_target(qdelay) #compensating for competing flows
calculate_send_window(qdelay, qdelay_target)
# When no congestion event
on acknowledgement(qdelay):
update_bytes_newly_acked()
update_cwnd(bytes_newly_acked)
adjust_qdelay_target(qdelay) # compensating for competing flows
calculate_send_window(qdelay, qdelay_target)
check_to_resume_fast_increase()
<CODE ENDS>
The methods are described in detail below.
メソッドについては、以下で詳しく説明します。
The congestion window update is based on qdelay, except for the occurrence of loss events (one or more lost RTP packets in one RTT) or ECN events, which were described earlier.
輻輳ウィンドウの更新は、前述の損失イベント（1つのRTT内の1つ以上のRTPパケットの損失）またはECNイベントの発生を除いて、qdelayに基づいています。
Pseudocode for the update of the congestion window is found below.
輻輳ウィンドウの更新の疑似コードは以下にあります。
<CODE BEGINS>
update_cwnd(bytes_newly_acked):
# In fast increase mode?
if (in_fast_increase)
if (qdelay_trend >= QDELAY_TREND_TH)
# Incipient congestion detected; exit fast increase mode
in_fast_increase = false
else
# No congestion yet; increase cwnd if it
# is sufficiently used
# Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
if (bytes_in_flight * 1.5 + bytes_newly_acked > cwnd)
cwnd = cwnd + bytes_newly_acked
end
return
end
end
# Not in fast increase mode
# off_target calculated as with LEDBAT
off_target_t = (qdelay_target - qdelay) / qdelay_target
gain_t = GAIN
# Adjust congestion window
cwnd_delta_t =
gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
if (off_target_t > 0 &&
bytes_in_flight * 1.25 + bytes_newly_acked <= cwnd)
# No cwnd increase if window is underutilized
# Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
cwnd_delta_t = 0;
end
# Apply delta
cwnd += cwnd_delta_t
# limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight *
MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND)
<CODE ENDS> CWND is updated differently depending on whether or not the congestion control is in fast increase mode, as controlled by the variable in_fast_increase.
<コード終了> CWNDは、輻輳制御が変数in_fast_increaseによって制御される高速増加モードにあるかどうかに応じて、異なる方法で更新されます。
When in fast increase mode, the congestion window is increased with the number of newly acknowledged bytes as long as the window is sufficiently used. Sparse feedback can potentially limit congestion window growth; therefore, additional slack is added, given by the number of newly acknowledged bytes.
高速増加モードでは、ウィンドウが十分に使用されている限り、輻輳ウィンドウは新しく確認されたバイト数で増加します。スパースフィードバックは、輻輳ウィンドウの成長を制限する可能性があります。したがって、新たに確認応答されたバイト数に応じて、追加のスラックが追加されます。
The congestion window growth when in_fast_increase is false is dictated by the relation between qdelay and qdelay_target; congestion window growth is limited if the window is not used sufficiently.
in_fast_increaseがfalseの場合の輻輳ウィンドウの増加は、qdelayとqdelay_targetの関係によって決まります。ウィンドウが十分に使用されていない場合、輻輳ウィンドウの成長は制限されます。
SCReAM calculates the GAIN in a similar way to what is specified in [RFC6817]. However, [RFC6817] specifies that the CWND increase is limited by an additional function controlled by a constant ALLOWED_INCREASE. This additional limitation is removed in this specification.
SCReAMは、[RFC6817]で指定されているものと同様の方法でGAINを計算します。ただし、[RFC6817]は、CWNDの増加が、定数ALLOWED_INCREASEによって制御される追加機能によって制限されることを指定しています。この追加の制限は、この仕様では削除されています。
Further, the CWND is limited by max_bytes_in_flight and MIN_CWND. The limitation of the congestion window by the maximum number of bytes in flight over the last 5 seconds (max_bytes_in_flight) avoids possible overestimation of the throughput after, for example, idle periods. An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM provides slack to allow for a certain amount of variability in the media coder output rate.
さらに、CWNDはmax_bytes_in_flightおよびMIN_CWNDによって制限されます。最後の5秒間のフライトの最大バイト数（max_bytes_in_flight）による輻輳ウィンドウの制限により、アイドル期間後などのスループットの過大評価を回避できます。追加のMAX_BYTES_IN_FLIGHT_HEAD_ROOMは、メディアコーダーの出力レートに一定量の変動を許容するスラックを提供します。
It is likely that a flow using the SCReAM algorithm will have to share congested bottlenecks with other flows that use a more aggressive congestion control algorithm (for example, large FTP flows using loss-based congestion control). The worst condition occurs when the bottleneck queues are of tail-drop type with a large buffer size. SCReAM takes care of such situations by adjusting the qdelay_target when loss-based flows are detected, as shown in the pseudocode below.
SCReAMアルゴリズムを使用するフローは、輻輳したボトルネックを、より積極的な輻輳制御アルゴリズムを使用する他のフロー（たとえば、損失ベースの輻輳制御を使用する大きなFTPフロー）と共有する必要がある可能性があります。最悪の状態は、ボトルネックキューがテールドロップタイプで、バッファサイズが大きい場合に発生します。 SCReAMは、以下の疑似コードに示すように、損失ベースのフローが検出されたときにqdelay_targetを調整することにより、このような状況に対処します。
<CODE BEGINS>
adjust_qdelay_target(qdelay)
qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
update_qdelay_norm_history(qdelay_norm_t)
# Compute variance
qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))
# Compensation for competing traffic
# Compute average
qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
# Compute upper limit to target delay
new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
new_target_t *= QDELAY_TARGET_LO
if (loss_event_rate > 0.002)
# Packet losses detected
qdelay_target = 1.5 * new_target_t
else
if (qdelay_norm_var_t < 0.2)
# Reasonably safe to set target qdelay
qdelay_target = new_target_t
else
# Check if target delay can be reduced; this helps prevent
# the target delay from being locked to high values forever
if (new_target_t < QDELAY_TARGET_LO)
# Decrease target delay quickly, as measured queuing
# delay is lower than target
qdelay_target = max(qdelay_target * 0.5, new_target_t)
else
# Decrease target delay slowly
qdelay_target *= 0.9
end
end
end
# Apply limits
qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)
<CODE ENDS>
Two temporary variables are calculated. qdelay_norm_avg_t is the long-term average queue delay, qdelay_norm_var_t is the long-term variance of the queue delay. A high qdelay_norm_var_t indicates that the queue delay changes; this can be an indication that bottleneck bandwidth is reduced or that a competing flow has just entered. Thus, it indicates that it is not safe to adjust the queue delay target.
2つの一時変数が計算されます。 qdelay_norm_avg_tは長期の平均キュー遅延であり、qdelay_norm_var_tはキュー遅延の長期変動です。 qdelay_norm_var_tが高い場合は、キューの遅延が変化していることを示します。これは、ボトルネックの帯域幅が減少したこと、または競合するフローがちょうど開始したことを示している可能性があります。したがって、キューの遅延ターゲットを調整するのは安全ではないことを示しています。
A low qdelay_norm_var_t indicates that the queue delay is relatively stable. The reason could be that the queue delay is low, but it could also be that a competing flow is causing the bottleneck to reach the point that packet losses start to occur, in which case the queue delay will stay relatively high for a longer time.
qdelay_norm_var_tが低い場合は、キューの遅延が比較的安定していることを示しています。その理由は、キューの遅延が小さいことですが、競合するフローが原因でボトルネックが発生し、パケット損失が発生し始めるポイントに達している可能性もあります。この場合、キューの遅延は比較的長い間長く続きます。
The queue delay target is allowed to be increased if either the loss event rate is above a given threshold or qdelay_norm_var_t is low. Both these conditions indicate that a competing flow may be present. In all other cases, the queue delay target is decreased.
損失イベント率が所定のしきい値を超えるか、qdelay_norm_var_tが低い場合、キュー遅延ターゲットを増やすことができます。これらの両方の条件は、競合するフローが存在する可能性があることを示しています。他のすべての場合では、キュー遅延ターゲットは減少します。
The function that adjusts the qdelay_target is simple and could produce false positives and false negatives. The case that self-inflicted congestion by the SCReAM algorithm may be falsely interpreted as the presence of competing loss-based FTP flows is a false positive. The opposite case -- where the algorithm fails to detect the presence of a competing FTP flow -- is a false negative.
qdelay_targetを調整する関数は単純で、誤検知と誤検知を生成する可能性があります。 SCReAMアルゴリズムによる自己侵害による輻輳は、競合する損失ベースのFTPフローの存在が誤検知であると誤って解釈される場合があります。反対のケース（アルゴリズムが競合するFTPフローの存在を検出できない場合）は、偽陰性です。
Extensive simulations have shown that the algorithm performs well in LTE test cases and that it also performs well in simple bandwidth-limited bottleneck test cases with competing FTP flows. However, the potential failure of the algorithm cannot be completely ruled out. A false positive (i.e., when self-inflicted congestion is mistakenly identified as competing flows) is especially problematic when it leads to increasing the target queue delay, which can cause the end-to-end delay to increase dramatically.
広範なシミュレーションにより、このアルゴリズムはLTEテストケースで良好に実行され、帯域幅が制限された単純なボトルネックテストケースでも競合するFTPフローで良好に実行されることが示されています。ただし、アルゴリズムの潜在的な失敗を完全に排除することはできません。誤検知（つまり、自己に起因する輻輳が競合するフローとして誤って識別された場合）は、ターゲットキューの遅延の増加につながり、エンドツーエンドの遅延が劇的に増加する場合に特に問題になります。
If it is deemed unlikely that competing flows occur over the same bottleneck, the algorithm described in this section MAY be turned off. One such case is QoS-enabled bearers in 3GPP-based access such as LTE. However, when sending over the Internet, often the network conditions are not known for sure, so in general it is not possible to make safe assumptions on how a network is used and whether or not competing flows share the same bottleneck. Therefore, turning this algorithm off must be considered with caution, as it can lead to basically zero throughput if competing with loss-based traffic.
同じボトルネックで競合するフローが発生する可能性が低いと思われる場合は、このセクションで説明するアルゴリズムをオフにすることができます。そのようなケースの1つは、LTEなどの3GPPベースのアクセスにおけるQoS対応のベアラです。ただし、インターネット経由で送信する場合、ネットワークの状態が不明な場合が多いため、一般に、ネットワークの使用方法や、競合するフローが同じボトルネックを共有するかどうかを安全に想定することはできません。したがって、このアルゴリズムをオフにすることは、損失ベースのトラフィックと競合する場合、基本的にスループットがゼロになる可能性があるため、慎重に検討する必要があります。
Lost packet detection is based on the received sequence number list. A reordering window SHOULD be applied to prevent packet reordering from triggering loss events. The reordering window is specified as a time unit, similar to the ideas behind Recent ACKnowledgement (RACK) [RACK]. The computation of the reordering window is made possible by means of a lost flag in the list of transmitted RTP packets. This flag is set if the received sequence number list indicates that the given RTP packet is missing. If later feedback indicates that a previously lost marked packet was indeed received, then the reordering window is updated to reflect the reordering delay. The reordering window is given by the difference in time between the event that the packet was marked as lost and the event that it was indicated as successfully received. Loss is detected if a given RTP packet is not acknowledged within a time window (indicated by the reordering window) after an RTP packet with a higher sequence number was acknowledged.
失われたパケットの検出は、受信したシーケンス番号リストに基づいています。パケットの並べ替えによって損失イベントがトリガーされないように、並べ替えウィンドウを適用する必要があります（SHOULD）。並べ替えウィンドウは、最近の確認応答（RACK）[RACK]の背後にある考え方と同様に、時間単位として指定されます。並べ替えウィンドウの計算は、送信されたRTPパケットのリストにあるロストフラグによって可能になります。このフラグは、受信したシーケンス番号リストが、指定されたRTPパケットが欠落していることを示している場合に設定されます。以前に失われたマーク付きパケットが実際に受信されたことを後でフィードバックが示す場合、並べ替え遅延が反映されるように並べ替えウィンドウが更新されます。並べ替えウィンドウは、パケットが失われたとマークされたイベントと正常に受信されたと示されたイベントとの間の時間差によって与えられます。シーケンス番号の大きいRTPパケットが確認応答された後、指定されたRTPパケットが時間ウィンドウ（並べ替えウィンドウで示される）内で確認応答されない場合、損失が検出されます。
The basic design principle behind packet transmission in SCReAM is to allow transmission only if the number of bytes in flight is less than the congestion window. There are, however, two reasons why this strict rule will not work optimally:
SCReAMのパケット送信の背後にある基本的な設計原則は、送信中のバイト数が輻輳ウィンドウよりも少ない場合にのみ送信を許可することです。ただし、この厳密なルールが最適に機能しない理由は2つあります。
o Bitrate variations: Media sources such as video encoders generally produce frames whose size always vary to a larger or smaller extent. The RTP queue absorbs the natural variations in frame sizes. However, the RTP queue should be as short as possible to prevent the end-to-end delay from increasing. To achieve that, the media rate control takes the RTP queue size into account when the target bitrate for the media is computed. A strict 'send only when bytes in flight is less than the congestion window' rule can cause the RTP queue to grow simply because the send window is limited; in turn, this can cause the target bitrate to be pushed down. The consequence is that the congestion window will not increase, or will increase very slowly, because the congestion window is only allowed to increase when there is a sufficient amount of data in flight. The final effect is that the media bitrate increases very slowly or not at all.
o ビットレートの変動：ビデオエンコーダーなどのメディアソースは、通常、サイズが常に大きくまたは小さく変化するフレームを生成します。 RTPキューは、フレームサイズの自然な変動を吸収します。ただし、エンドツーエンドの遅延が増加しないように、RTPキューはできるだけ短くする必要があります。これを実現するために、メディアレート制御では、メディアのターゲットビットレートが計算されるときにRTPキューサイズが考慮されます。厳密な「送信中のバイトが輻輳ウィンドウよりも小さい場合にのみ送信する」ルールでは、送信ウィンドウが制限されているためにRTPキューが大きくなる可能性があります。これにより、ターゲットビットレートが低下する可能性があります。その結果、輻輳ウィンドウは、十分な量のデータが送信されている場合にのみ増加できるため、輻輳ウィンドウは増加しないか、非常にゆっくりと増加します。最後の効果は、メディアのビットレートが非常にゆっくりと増加するか、まったく増加しないことです。
o Reverse (feedback) path congestion: Especially in transport over buffer-bloated networks, the one-way delay in the reverse direction can jump due to congestion. The effect is that the acknowledgements are delayed, and the self-clocking is temporarily halted, even though the forward path is not congested.
o リバース（フィードバック）パスの輻輳：特にバッファが肥大化したネットワークを介した転送では、輻輳が原因で逆方向の一方向の遅延がジャンプする可能性があります。その結果、確認応答が遅れ、フォワードパスが輻輳していない場合でも、セルフクロッキングが一時的に停止します。
The send window is adjusted depending on qdelay, its relation to the qdelay target, and the relation between the congestion window and the number of bytes in flight. A strict rule is applied when qdelay is higher than qdelay_target, to avoid further queue buildup in the network. For cases when qdelay is lower than the qdelay_target, a more relaxed rule is applied. This allows the bitrate to increase quickly when no congestion is detected while still being able to exhibit stable behavior in congested situations.
送信ウィンドウは、qdelay、qdelayターゲットとの関係、および輻輳ウィンドウと飛行中のバイト数の関係に応じて調整されます。 qdelayがqdelay_targetよりも高い場合、ネットワークでのキューの増加を回避するために、厳密なルールが適用されます。 qdelayがqdelay_targetよりも低い場合は、より緩和されたルールが適用されます。これにより、輻輳が検出されないときにビットレートをすばやく増加させながら、輻輳した状況でも安定した動作を示すことができます。
The send window is given by the relation between the adjusted congestion window and the amount of bytes in flight according to the pseudocode below.
送信ウィンドウは、以下の疑似コードに従って、調整された輻輳ウィンドウと飛行中のバイト数の関係によって与えられます。
<CODE BEGINS>
calculate_send_window(qdelay, qdelay_target)
# send window is computed differently depending on congestion level
if (qdelay <= qdelay_target)
send_wnd = cwnd + MSS - bytes_in_flight
else
send_wnd = cwnd - bytes_in_flight
end
<CODE ENDS>
The send window is updated whenever an RTP packet is transmitted or an RTCP feedback messaged is received.
送信ウィンドウは、RTPパケットが送信されるか、RTCPフィードバックメッセージが受信されるたびに更新されます。
Packet pacing is used in order to mitigate coalescing, i.e., when packets are transmitted in bursts, with the risks of increased jitter and potentially increased packet loss. Packet pacing also mitigates possible issues with queue overflow due to key-frame generation in video coders. The time interval between consecutive packet transmissions is greater than or equal to t_pace, where t_pace is given by the equations below :
パケットペーシングは、合体を軽減するために使用されます。つまり、パケットがバーストで送信される場合に、ジッタが増加し、パケット損失が増加する可能性があります。パケットペーシングは、ビデオコーダーでのキーフレーム生成によるキューオーバーフローの問題も軽減します。連続するパケット送信間の時間間隔はt_pace以上です。ここで、t_paceは以下の方程式で与えられます。
<CODE BEGINS>
pace_bitrate = max (RATE_PACE_MIN, cwnd * 8 / s_rtt)
t_pace = rtp_size * 8 / pace_bitrate
<CODE ENDS>
rtp_size is the size of the last transmitted RTP packet, and s_rtt is the smoothed round trip time. RATE_PACE_MIN is the minimum pacing rate.
rtp_sizeは最後に送信されたRTPパケットのサイズで、s_rttは平滑化された往復時間です。 RATE_PACE_MINは最小ペーシングレートです。
Fast increase mode can resume in order to speed up the bitrate increase if congestion abates. The condition to resume fast increase mode (in_fast_increase = true) is that qdelay_trend is less than QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.
輻輳が緩和した場合、ビットレートの増加を加速するために、高速増加モードを再開できます。高速増加モード（in_fast_increase = true）を再開する条件は、qdelay_trendがT_RESUME_FAST_INCREASE秒以上QDELAY_TREND_LO未満であることです。
The SCReAM algorithm makes a good distinction between network congestion control and media rate control. This is easily extended to many streams -- RTP packets from two or more RTP queues are scheduled at the rate permitted by the network congestion control.
SCReAMアルゴリズムは、ネットワークの輻輳制御とメディアレート制御を適切に区別します。これは多くのストリームに簡単に拡張できます。2つ以上のRTPキューからのRTPパケットは、ネットワークの輻輳制御によって許可されたレートでスケジュールされます。
The scheduling can be done by means of a few different scheduling regimes. For example, the method for coupled congestion control specified in [COUPLED-CC] can be used. One implementation of SCReAM [SCReAM-CPP-implementation] uses credit-based scheduling. In credit-based scheduling, credit is accumulated by queues as they wait for service and is spent while the queues are being serviced. For instance, if one queue is allowed to transmit 1000 bytes, then a credit of 1000 bytes is allocated to the other unscheduled queues. This principle can be extended to weighted scheduling, where the credit allocated to unscheduled queues depends on the relative weights. The latter is also implemented in [SCReAM-CPP-implementation].
スケジューリングは、いくつかの異なるスケジューリング方式によって行うことができます。たとえば、[COUPLED-CC]で指定された結合輻輳制御の方法を使用できます。 SCReAMの1つの実装[SCReAM-CPP-implementation]は、クレジットベースのスケジューリングを使用します。クレジットベースのスケジューリングでは、キューはサービスを待機するときにキューによって累積され、キューがサービスされている間使用されます。たとえば、1つのキューが1000バイトの送信を許可されている場合、1000バイトのクレジットが他のスケジュールされていないキューに割り当てられます。この原則は、重み付けされたスケジューリングに拡張できます。スケジューリングされていないキューに割り当てられるクレジットは、相対的な重みに依存します。後者は、[SCReAM-CPP-implementation]にも実装されています。
The media rate control algorithm is executed at regular intervals, indicated by RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to loss events. The media rate control operates based on the size of the RTP packet send queue and observed loss events. In addition, qdelay_trend is also considered in the media rate control in order to reduce the amount of induced network jitter.
メディアレート制御アルゴリズムは、RATE_ADJUSTMENT_INTERVALで示される定期的な間隔で実行されますが、損失イベントに対する迅速な対応は例外です。メディアレート制御は、RTPパケット送信キューのサイズと観測された損失イベントに基づいて動作します。さらに、qdelay_trendは、誘発されるネットワークジッタの量を減らすために、メディアレート制御でも考慮されます。
The role of the media rate control is to strike a reasonable balance between a low amount of queuing in the RTP queue(s) and a sufficient amount of data to send in order to keep the data path busy. Setting the media rate control too cautiously leads to possible underutilization of network capacity; this can cause the flow to become starved out by other more opportunistic traffic. On the other hand, setting it too aggressively leads to increased jitter.
メディアレート制御の役割は、RTPキューでのキューイングの量が少ないことと、データパスをビジー状態に保つために送信するのに十分な量のデータとの間で適切なバランスを取ることです。メディアレート制御の設定が慎重すぎると、ネットワーク容量が十分に活用されない可能性があります。これにより、他のより日和見的なトラフィックによってフローが不足する可能性があります。一方、あまりにも積極的に設定すると、ジッタが増加します。
The target_bitrate is adjusted depending on the congestion state. The target bitrate can vary between a minimum value (TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX). TARGET_BITRATE_MIN SHOULD be set to a low enough value to prevent RTP packets from becoming queued up when the network throughput is reduced. The sender SHOULD also be equipped with a mechanism that discards RTP packets when the network throughput becomes very low and RTP packets are excessively delayed.
target_bitrateは、輻輳状態に応じて調整されます。ターゲットビットレートは、最小値（TARGET_BITRATE_MIN）と最大値（TARGET_BITRATE_MAX）の間で変化する可能性があります。 TARGET_BITRATE_MINは、ネットワークスループットが低下したときにRTPパケットがキューに入れられないように、十分に低い値に設定する必要があります（SHOULD）。送信者は、ネットワークスループットが非常に低くなり、RTPパケットが過度に遅延したときにRTPパケットを破棄するメカニズムも備えている必要があります（SHOULD）。
For the overall bitrate adjustment, two network throughput estimates are computed :
全体的なビットレート調整では、2つのネットワークスループットの見積もりが計算されます。
o rate_transmit: The measured transmit bitrate.
o rate_transmit：測定された送信ビットレート。
o rate_ack: The ACKed bitrate, i.e., the volume of ACKed bits per second.
o rate_ack：ACKされたビットレート、つまり1秒あたりのACKされたビットの量。
Both estimates are updated every 200 ms.
両方の推定値は200ミリ秒ごとに更新されます。
The current throughput, current_rate, is computed as the maximum value of rate_transmit and rate_ack. The rationale behind the use of rate_ack in addition to rate_transmit is that rate_transmit is affected also by the amount of data that is available to transmit, thus a lack of data to transmit can be seen as reduced throughput that can cause an unnecessary rate reduction. To overcome this shortcoming, rate_ack is used as well. This gives a more stable throughput estimate.
現在のスループットcurrent_rateは、rate_transmitおよびrate_ackの最大値として計算されます。 rate_transmitに加えてrate_ackを使用する背後にある理論的根拠は、rate_transmitが送信可能なデータの量にも影響を受けるため、送信するデータの不足がスループットの低下と見なされ、不必要なレートの低下を引き起こす可能性があることです。この欠点を克服するために、rate_ackも使用されます。これにより、スループットの見積もりがより安定します。
The rate change behavior depends on whether a loss or ECN event has occurred and whether the congestion control is in fast increase mode.
レート変更の動作は、損失またはECNイベントが発生したかどうか、および輻輳制御が高速増加モードになっているかどうかによって異なります。
<CODE BEGINS> # The target_bitrate is updated at a regular interval according # to RATE_ADJUST_INTERVAL
<CODE BEGINS>＃target_bitrateは、RATE_ADJUST_INTERVALに従って＃定期的に更新されます
on loss: # Loss event detected target_bitrate = max(BETA_R * target_bitrate, TARGET_BITRATE_MIN) exit on ecn_mark: # ECN event detected target_bitrate = max(BETA_ECN * target_bitrate, TARGET_BITRATE_MIN) exit
損失時：＃損失イベントが検出されましたtarget_bitrate = max（BETA_R * target_bitrate、TARGET_BITRATE_MIN）exit on ecn_mark：＃ECNイベントが検出されましたtarget_bitrate = max（BETA_ECN * target_bitrate、TARGET_BITRATE_MIN）exit
ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate / 2.0)
scale_t = (target_bitrate - target_bitrate_last_max) /
target_bitrate_last_max
scale_t = max(0.2, min(1.0, (scale_t * 4)^2))
# min scale_t value 0.2, as the bitrate should be allowed to
# increase slowly. This prevents locking the rate to
# target_bitrate_last_max
if (in_fast_increase = true)
increment_t = ramp_up_speed_t * RATE_ADJUST_INTERVAL
increment_t *= scale_t
target_bitrate += increment_t
else
current_rate_t = max(rate_transmit, rate_ack)
# Compute a bitrate change
delta_rate_t = current_rate_t * (1.0 - PRE_CONGESTION_GUARD *
queue_delay_trend) - TX_QUEUE_SIZE_FACTOR * rtp_queue_size
# Limit a positive increase if close to target_bitrate_last_max
if (delta_rate_t > 0)
delta_rate_t *= scale_t
delta_rate_t =
min(delta_rate_t, ramp_up_speed_t * RATE_ADJUST_INTERVAL)
end target_bitrate += delta_rate_t # Force a slight reduction in bitrate if RTP queue # builds up rtp_queue_delay_t = rtp_queue_size / current_rate_t if (rtp_queue_delay_t > RTP_QDELAY_TH) target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY end end
end target_bitrate + = delta_rate_t＃RTPキューが構築された場合、ビットレートをわずかに削減する＃rtp_queue_delay_t = rtp_queue_size / current_rate_t if（rtp_queue_delay_t> RTP_QDELAY_TH）target_bitrate * = TARGET_RATE_SCALE_RTP_QDELAY end
rate_media_limit_t =
max(current_rate_t, max(rate_media, rtp_rate_median))
rate_media_limit_t *= (2.0 - qdelay_trend_mem)
target_bitrate = min(target_bitrate, rate_media_limit_t)
target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN, target_bitrate))
<CODE ENDS>
In case of a loss event, the target_bitrate is updated and the rate change procedure is exited. Otherwise, the rate change procedure continues. The rationale behind the rate reduction due to loss is that a congestion window reduction will take effect, and a rate reduction proactively prevents RTP packets from being queued up when the transmit rate decreases due to the reduced congestion window. A similar rate reduction happens when ECN events are detected.
損失イベントの場合、target_bitrateが更新され、レート変更手順が終了します。それ以外の場合、レート変更手順は続行されます。損失によるレート削減の背後にある理論的根拠は、輻輳ウィンドウの削減が有効になり、レート削減は、輻輳ウィンドウの減少により送信レートが低下したときに、RTPパケットがキューに入れられるのを予防的に防ぐことです。 ECNイベントが検出されると、同様のレート低下が発生します。
The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless a loss event occurs. The value is based on experimentation with real-life limitations in video coders taken into account [SCReAM-CPP-implementation]. A too short interval is shown to make the rate control loop in video coders more unstable; a too long interval makes the overall congestion control sluggish.
損失イベントが発生しない限り、レート更新頻度はRATE_ADJUST_INTERVALによって制限されます。この値は、ビデオコーダーの実際の制限を考慮した実験に基づいています[SCReAM-CPP-implementation]。ビデオコーダーのレート制御ループを不安定にするために、短すぎる間隔が示されています。間隔が長すぎると、全体的な輻輳制御が遅くなります。
When in fast increase mode (in_fast_increase = true), the bitrate increase is given by the desired ramp-up speed (RAMP_UP_SPEED). The ramp-up speed is limited when the target bitrate is low to avoid rate oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED depends on preferences. A high setting such as 1000 kbps/s makes it possible to quickly get high-quality media; however, this is at the expense of increased jitter, which can manifest itself as choppy video rendering, for example.
高速増加モード（in_fast_increase = true）の場合、ビットレートの増加は、望ましいランプアップ速度（RAMP_UP_SPEED）によって与えられます。ターゲットのビットレートが低い場合、立ち下がり速度は制限され、ボトルネックの低いビットレートでのレートの変動を回避します。 RAMP_UP_SPEEDの設定は、プリファレンスによって異なります。 1000 kbps / sなどの高い設定では、高品質のメディアをすばやく取得できます。ただし、これはジッターの増加を犠牲にしており、ジッターは、たとえば、途切れ途切れのビデオレンダリングとして現れる可能性があります。
When in_fast_increase is false, the bitrate increase is given by the current bitrate and is also controlled by the estimated RTP queue and the qdelay trend, thus it is sufficient that an increased congestion level is sensed by the network congestion control to limit the bitrate. The target_bitrate_last_max is updated when congestion is detected.
in_fast_increaseがfalseの場合、ビットレートの増加は現在のビットレートによって与えられ、推定RTPキューとqdelayトレンドによっても制御されるため、ネットワークの輻輳制御によって増加した輻輳レベルが感知され、ビットレートが制限されれば十分です。 target_bitrate_last_maxは、輻輳が検出されると更新されます。
Finally, the target_bitrate is within the defined min and max values.
最後に、target_bitrateは、定義された最小値と最大値の範囲内です。
The aware reader may notice the dependency on the qdelay in the computation of the target bitrate; this manifests itself in the use of the qdelay_trend. As these parameters are used also in the network congestion control, one may suspect some odd interaction between the media rate control and the network congestion control. This is in fact the case if the parameter PRE_CONGESTION_GUARD is set to a high value. The use of qdelay_trend in the media rate control is solely to reduce jitter; the dependency can be removed by setting PRE_CONGESTION_GUARD=0. The effect is a somewhat larger rate increase after congestion, at the expense of increased jitter in congested situations.
認識している読者は、ターゲットビットレートの計算におけるqdelayへの依存に気付くかもしれません。これは、qdelay_trendの使用に現れます。これらのパラメータはネットワークの輻輳制御でも使用されるため、メディアレート制御とネットワークの輻輳制御の間の何らかの奇妙な相互作用が疑われる場合があります。これは実際には、PRE_CONGESTION_GUARDパラメータが高い値に設定されている場合です。メディアレート制御でのqdelay_trendの使用は、ジッタを減らすことのみを目的としています。 PRE_CONGESTION_GUARD = 0を設定すると、依存関係を削除できます。この効果は、輻輳後のジッタの増加を犠牲にして、輻輳後のレートの増加がやや大きくなります。
The simple task of the SCReAM receiver is to feed back acknowledgements of received packets and total ECN count to the SCReAM sender. In addition, the receive time of the RTP packet with the highest sequence number is echoed back. Upon reception of each RTP packet, the receiver MUST maintain enough information to send the aforementioned values to the SCReAM sender via an RTCP transport-layer feedback message. The frequency of the feedback message depends on the available RTCP bandwidth. The requirements on the feedback elements and the feedback interval are described below.
SCReAMレシーバーの単純なタスクは、受信したパケットの確認応答と総ECNカウントをSCReAMセンダーにフィードバックすることです。さらに、シーケンス番号が最も大きいRTPパケットの受信時刻がエコーバックされます。各RTPパケットを受信すると、受信者は、RTCPトランスポート層フィードバックメッセージを介して前述の値をSCReAM送信者に送信するのに十分な情報を維持する必要があります。フィードバックメッセージの頻度は、使用可能なRTCP帯域幅によって異なります。フィードバック要素とフィードバック間隔の要件を以下に示します。
The following feedback elements are REQUIRED for basic functionality in SCReAM.
SCReAMの基本機能には、次のフィードバック要素が必要です。
o A list of received RTP packets. This list SHOULD be sufficiently long to cover all received RTP packets. This list can be realized with the Loss RLE (Run Length Encoding) Report Block in [RFC3611].
o 受信したRTPパケットのリスト。このリストは、受信したすべてのRTPパケットをカバーするのに十分な長さにする必要があります（SHOULD）。このリストは、[RFC3611]のLoss RLE（Run Length Encoding）レポートブロックで実現できます。
o A wall-clock timestamp corresponding to the received RTP packet with the highest sequence number is required in order to compute the qdelay. This can be realized by means of the Packet Receipt Times Report Block in [RFC3611]. begin_seq MUST be set to the highest received sequence number (which has possibly wrapped around); end_seq MUST be set to begin_seq+1 modulo 65536. The timestamp clock MAY be set according to [RFC3611], i.e., equal to the RTP timestamp clock. Detailed individual packet receive times are not necessary, as SCReAM does currently not describe how they can be used.
o qdelayを計算するには、シーケンス番号が最大の受信RTPパケットに対応する実時間のタイムスタンプが必要です。これは、[RFC3611]のパケット受信時間レポートブロックによって実現できます。 begin_seqは、受信した最も高いシーケンス番号に設定する必要があります（これはおそらく折り返しています）。 end_seqはbegin_seq + 1 modulo 65536に設定する必要があります。タイムスタンプクロックは、[RFC3611]に従って、つまりRTPタイムスタンプクロックに等しく設定することができます（MAY）。 SCReAMは現在、それらの使用方法を説明していないため、個々のパケットの詳細な受信時間は必要ありません。
The basic feedback needed for SCReAM involves the use of the Loss RLE Report Block and the Packet Receipt Times Report Block as shown in Figure 2.
SCReAMに必要な基本的なフィードバックには、図2に示すように、損失RLEレポートブロックとパケット受信時間レポートブロックの使用が含まれます。
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|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Basic Feedback Message for SCReAM, Based on RFC 3611
図2：RFC 3611に基づくSCReAMの基本的なフィードバックメッセージ
In a typical use case, no more than four Loss RLE chunks are needed, thus the feedback message will be 44 bytes. It is obvious from Figure 2 that there is a lot of redundant information in the feedback message. A more optimized feedback format, including the additional feedback elements listed below, could reduce the feedback message size a bit.
典型的な使用例では、必要なLoss RLEチャンクは4つ以下なので、フィードバックメッセージは44バイトになります。図2から明らかなように、フィードバックメッセージには冗長な情報がたくさんあります。以下にリストされている追加のフィードバック要素を含む、より最適化されたフィードバック形式は、フィードバックメッセージのサイズを少し減らすことができます。
An additional feedback element that can improve the performance of SCReAM is:
SCReAMのパフォーマンスを改善できる追加のフィードバック要素は次のとおりです。
o Accumulated number of ECN-CE-marked packets (n_ECN). For instance, this can be realized with the ECN Feedback Report Format in [RFC6679]. The given feedback report format is slightly overkill, as SCReAM would do quite well with only a counter that increments by one for each received packet with the ECN-CE codepoint set. The more bulky format could nevertheless be useful for, e.g., ECN black-hole detection.
o ECN-CEでマークされたパケットの累積数（n_ECN）。たとえば、これは[RFC6679]のECNフィードバックレポート形式で実現できます。 SCReAMは、ECN-CEコードポイントが設定された受信パケットごとに1つずつ増加するカウンターのみで十分機能するため、指定されたフィードバックレポートの形式はやや過剰です。それにもかかわらず、よりかさばるフォーマットは、たとえば、ECNブラックホール検出に役立つ可能性があります。
SCReAM benefits from relatively frequent feedback. It is RECOMMENDED that a SCReAM implementation follows the guidelines below.
SCReAMは、比較的頻繁なフィードバックから恩恵を受けます。 SCReAMの実装は、以下のガイドラインに従うことをお勧めします。
The feedback interval depends on the media bitrate. At low bitrates, it is sufficient with a feedback interval of 100 to 400 ms; while at high bitrates, a feedback interval of roughly 20 ms is preferred. At very high bitrates, even shorter feedback intervals MAY be needed in order to keep the self-clocking in SCReAM working well. One indication that feedback is too sparse is that the SCReAM implementation cannot reach high bitrates, even in uncongested links. More frequent feedback might solve this issue.
フィードバック間隔は、メディアのビットレートによって異なります。低ビットレートでは、フィードバック間隔は100〜400 msで十分です。高いビットレートでは、フィードバック間隔は約20 msが推奨されます。非常に高いビットレートでは、SCReAMのセルフクロッキングを適切に機能させるために、さらに短いフィードバック間隔が必要になる場合があります。フィードバックが希薄であることを示す1つの兆候は、SCReAM実装が、輻輳していないリンクであっても、高いビットレートに到達できないことです。より頻繁なフィードバックがこの問題を解決する可能性があります。
The numbers above can be formulated as a feedback interval function that can be useful for the computation of the desired RTCP bandwidth. The following equation expresses the feedback rate:
上記の数値は、望ましいRTCP帯域幅の計算に役立つフィードバック間隔関数として定式化できます。次の方程式はフィードバック率を表します。
rate_fb = min(50, max(2.5, rate_media / 10000))
rate_media is the RTP media bitrate expressed in bps; rate_fb is the feedback rate expressed in packets/s. Converting to feedback interval, we get:
rate_mediaは、bpsで表されるRTPメディアビットレートです。 rate_fbは、パケット/秒で表されるフィードバックレートです。フィードバック間隔に変換すると、次のようになります。
fb_int = 1.0 / min(50, max(2.5, rate_media / 10000))
The transmission interval is not critical. So, in the case of multi-stream handling between two hosts, the feedback for two or more synchronization sources (SSRCs) can be bundled to save UDP/IP overhead. However, the final realized feedback interval SHOULD not exceed 2*fb_int in such cases, meaning that a scheduled feedback transmission event should not be delayed more than fb_int.
送信間隔は重要ではありません。そのため、2つのホスト間のマルチストリーム処理の場合、UDP / IPオーバーヘッドを節約するために、2つ以上の同期ソース（SSRC）のフィードバックをバンドルできます。ただし、このような場合、最終的に実現されるフィードバック間隔は2 * fb_intを超えてはなりません（SHOULD）。つまり、スケジュールされたフィードバック送信イベントがfb_intよりも遅くなることはありません。
SCReAM works with AVPF regular mode; immediate or early mode is not required by SCReAM but can nonetheless be useful for RTCP messages not directly related to SCReAM, such as those specified in [RFC4585]. It is RECOMMENDED to use reduced-size RTCP [RFC5506], where regular full compound RTCP transmission is controlled by trr-int as described in [RFC4585].
SCReAMはAVPF通常モードで動作します。即時モードまたは早期モードはSCReAMでは必要ありませんが、[RFC4585]で指定されているような、SCReAMに直接関連しないRTCPメッセージには役立ちます。縮小サイズのRTCP [RFC5506]を使用することをお勧めします。通常の完全な複合RTCP送信は、[RFC4585]で説明されているようにtrr-intによって制御されます。
This section covers a few discussion points.
このセクションでは、いくつかの論点について説明します。
o Clock drift: SCReAM can suffer from the same issues with clock drift as is the case with LEDBAT [RFC6817]. However, Appendix A.2 in [RFC6817] describes ways to mitigate issues with clock drift.
o クロックドリフト：SCReAMは、LEDBAT [RFC6817]の場合と同じように、クロックドリフトの問題に悩まされる可能性があります。ただし、[RFC6817]の付録A.2では、クロックドリフトの問題を軽減する方法について説明しています。
o Support for alternate ECN semantics: This specification adopts the proposal in [ALT-BACKOFF] to reduce the congestion window less when ECN-based congestion events are detected. Future work on Low Loss, Low Latency for Scalable throughput (L4S) may lead to updates in a future document that describes SCReAM support for L4S.
o 代替ECNセマンティクスのサポート：この仕様は、[ALT-BACKOFF]の提案を採用して、ECNベースの輻輳イベントが検出されたときに輻輳ウィンドウを少なくします。スケーラブルなスループット（L4S）の低損失、低遅延に関する今後の作業は、L4SのSCReAMサポートを説明する将来のドキュメントの更新につながる可能性があります。
o A new transport-layer feedback message (as specified in RFC 4585) could be standardized if the use of the already existing RTCP extensions as described in Section 4.2 is not deemed sufficient.
o 新しいトランスポート層フィードバックメッセージ（RFC 4585で指定）は、セクション4.2で説明されている既存のRTCP拡張の使用が十分でないと見なされた場合に標準化できます。
o The target bitrate given by SCReAM is the bitrate including the RTP and Forward Error Correction (FEC) overhead. The media encoder SHOULD take this overhead into account when the media bitrate is set. This means that the media coder bitrate SHOULD be computed as
o SCReAMによって提供されるターゲットビットレートは、RTPおよびForward Error Correction（FEC）オーバーヘッドを含むビットレートです。メディアエンコーダーは、メディアビットレートが設定されている場合、このオーバーヘッドを考慮する必要があります（SHOULD）。つまり、メディアコーダーのビットレートは次のように計算する必要があります。
media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate
media_rate = target_bitrate-rtp_plus_fec_overhead_bitrate
It is not necessary to make a 100% perfect compensation for the overhead, as the SCReAM algorithm will inherently compensate for moderate errors. Under-compensating for the overhead has the effect of increasing jitter, while overcompensating will cause the bottleneck link to become underutilized.
SCReAMアルゴリズムは本質的に中程度のエラーを補正するため、オーバーヘッドを100％完全に補正する必要はありません。オーバーヘッドの補正不足はジッタの増加に影響しますが、補正過剰はボトルネックリンクの利用率を低下させます。
SCReAM has been evaluated in a number of different ways, mostly in a simulator. The OpenWebRTC implementation work ([OpenWebRTC] and [SCReAM-implementation]) involved extensive testing with artificial bottlenecks with varying bandwidths and using two different video coders (OpenH264 and VP9).
SCReAMは、多くの異なる方法で、主にシミュレーターで評価されてきました。 OpenWebRTC実装作業（[OpenWebRTC]と[SCReAM-implementation]）は、さまざまな帯域幅を使用し、2つの異なるビデオコーダー（OpenH264とVP9）を使用して、人工的なボトルネックを伴う広範なテストを行いました。
Preferably, further experiments will be done by means of implementation in real clients and web browsers. RECOMMENDED experiments are:
好ましくは、さらなる実験は、実際のクライアントおよびウェブブラウザにおける実装によって行われるであろう。推奨される実験は次のとおりです。
o Trials with various access technologies: EDGE/3G/4G, Wi-Fi, DSL. Some experiments have already been carried out with LTE access; see [SCReAM-CPP-implementation] and [SCReAM-implementation-experience].
o さまざまなアクセス技術を使用した試験：EDGE / 3G / 4G、Wi-Fi、DSL。いくつかの実験はすでにLTEアクセスで実行されています。 [SCReAM-CPP-implementation]および[SCReAM-implementation-experience]を参照してください。
o Trials with different kinds of media: Audio, video, slideshow content. Evaluation of multi-stream handling in SCReAM.
o さまざまな種類のメディアによる試用：オーディオ、ビデオ、スライドショーコンテンツ。 SCReAMでのマルチストリーム処理の評価。
o Evaluation of functionality of the compensation mechanism when there are competing flows: Evaluate how SCReAM performs with competing TCP-like traffic and to what extent the compensation for competing flows causes self-inflicted congestion.
o 競合するフローがある場合の補償メカニズムの機能の評価：SCReAMが競合するTCPのようなトラフィックでどのように実行されるか、および競合するフローの補償がどの程度自己衝突による輻輳を引き起こすかを評価します。
o Determine proper parameters: A set of default parameters are given that makes SCReAM work over a reasonably large operation range. However, for very low or very high bitrates, it may be necessary to use different values for the RAMP_UP_SPEED, for instance.
o 適切なパラメーターを決定する：かなり広い操作範囲でSCReAMを機能させる一連のデフォルトパラメーターが指定されています。ただし、非常に低いまたは非常に高いビットレートの場合、たとえば、RAMP_UP_SPEEDに異なる値を使用する必要がある場合があります。
o Experimentation with further improvements to the congestion window and media bitrate calculation. [SCReAM-CPP-implementation] implements some optimizations, not described in this memo, that improve performance slightly. Further experiments are likely to lead to more optimizations of the algorithm.
o 輻輳ウィンドウとメディアビットレート計算をさらに改善した実験。 [SCReAM-CPP-implementation]は、このメモには記載されていない、パフォーマンスをわずかに向上させるいくつかの最適化を実装します。さらなる実験は、アルゴリズムのより多くの最適化につながる可能性があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
The feedback can be vulnerable to attacks similar to those that can affect TCP. It is therefore RECOMMENDED that the RTCP feedback is at least integrity protected. Furthermore, as SCReAM is self-clocked, a malicious middlebox can drop RTCP feedback packets and thus cause the self-clocking in SCReAM to stall. However, this attack is mitigated by the minimum send rate maintained by SCReAM when no feedback is received.
フィードバックは、TCPに影響を与える可能性のある攻撃と同様の攻撃に対して脆弱になる可能性があります。したがって、RTCPフィードバックは少なくとも整合性が保護されていることが推奨されます。さらに、SCReAMはセルフクロックであるため、悪意のあるミドルボックスがRTCPフィードバックパケットをドロップし、SCReAMのセルフクロッキングを停止させる可能性があります。ただし、この攻撃は、フィードバックが受信されないときにSCReAMによって維持される最小送信レートによって軽減されます。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[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]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <https://www.rfc-editor.org/info/rfc3611>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC5506] Johansson、I。およびM. Westerlund、「Reduced-Size Real-Time Transport Control Protocol（RTCP）：Opportunities and Consequences」、RFC 5506、DOI 10.17487 / RFC5506、2009年4月、<https：// www .rfc-editor.org / info / rfc5506>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：//www.rfc- editor.org/info/rfc6298>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<https：// www.rfc-editor.org/info/rfc6817>。
[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>。
[ALT-BACKOFF] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", Work in Progress, draft-ietf-tcpm-alternativebackoff-ecn-04, November 2017.
[ALT-BACKOFF] Khademi、N.、Welzl、M.、Armitage、G。、およびG. Fairhurst、「ECN（ABE）によるTCP代替バックオフ」、作業中、draft-ietf-tcpm-alternativebackoff-ecn- 2017年11月4日。
[COUPLED-CC] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", Work in Progress, draft-ietf-rmcat-coupled-cc-07, September 2017.
[COUPLED-CC] Islam、S.、Welzl、M.、and S. Gjessing、 "Coupled congestion control for RTP media"、Work in Progress、draft-ietf-rmcat-coupled-cc-07、September 2017。
[LEDBAT-delay-impact] Ros, D. and M. Welzl, "Assessing LEDBAT's Delay Impact", IEEE Communications Letters, Vol. 17, No. 5, DOI 10.1109/LCOMM.2013.040213.130137, May 2013, <http://home.ifi.uio.no/michawe/research/publications/ ledbat-impact-letters.pdf>.
[LEDBAT-delay-impact] Ros、D.およびM. Welzl、「Assessing LEDBAT's Delay Impact」、IEEE Communications Letters、Vol。 17、No。5、DOI 10.1109 / LCOMM.2013.040213.130137、2013年5月、<http://home.ifi.uio.no/michawe/research/publications/ledbat-impact-letters.pdf>。
[OpenWebRTC] Ericsson Research, "OpenWebRTC", <http://www.openwebrtc.org>.
[OpenWebRTC] Ericsson Research、「OpenWebRTC」、<http://www.openwebrtc.org>。
[Packet-conservation] Jacobson, V., "Congestion Avoidance and Control", ACM SIGCOMM Computer Communication Review, DOI 10.1145/52325.52356, August 1988.
[パケット保護] Jacobson、V。、「輻輳回避と制御」、ACM SIGCOMM Computer Communication Review、DOI 10.1145 / 52325.52356、1988年8月。
[QoS-3GPP] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203, July 2017, <http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.
[QoS-3GPP] 3GPP、「ポリシーおよび課金制御アーキテクチャ」、3GPP TS 23.203、2017年7月、<http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>。
[RACK] Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time-based fast loss detection algorithm for TCP", Work in Progress, draft-ietf-tcpm-rack-02, March 2017.
[RACK] Cheng、Y.、Cardwell、N。、およびN. Dukkipati、「RACK：TCPの時間ベースの高速損失検出アルゴリズム」、Work in Progress、draft-ietf-tcpm-rack-02、2017年3月。
[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、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<https://www.rfc-editor.org/info/rfc6679>。
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <https://www.rfc-editor.org/info/rfc7478>.
[RFC7478] Holmberg、C.、Hakansson、S。、およびG. Eriksson、「Web Real-Time Communication Use Cases and Requirements」、RFC 7478、DOI 10.17487 / RFC7478、2015年3月、<https：//www.rfc- editor.org/info/rfc7478>。
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating TCP to Support Rate-Limited Traffic", RFC 7661, DOI 10.17487/RFC7661, October 2015, <https://www.rfc-editor.org/info/rfc7661>.
[RFC7661] Fairhurst、G.、Sathiaseelan、A。、およびR. Secchi、「レート制限されたトラフィックをサポートするためのTCPの更新」、RFC 7661、DOI 10.17487 / RFC7661、2015年10月、<https：//www.rfc-editor .org / info / rfc7661>。
[SCReAM-CPP-implementation] Ericsson Research, "SCReAM - Mobile optimised congestion control algorithm", <https://github.com/EricssonResearch/scream>.
[SCReAM-CPP-implementation] Ericsson Research、「SCReAM-モバイル最適化輻輳制御アルゴリズム」、<https://github.com/EricssonResearch/scream>。
[SCReAM-implementation] Ericsson Research, "OpenWebRTC specific GStreamer plugins", <https://github.com/EricssonResearch/ openwebrtc-gst-plugins>.
[SCReAM実装] Ericsson Research、「OpenWebRTC固有のGStreamerプラグイン」、<https://github.com/EricssonResearch/openwebrtc-gst-plugins>。
[SCReAM-implementation-experience] Sarker, Z. and I. Johansson, "Updates on SCReAM: An implementation experience", November 2015, <https://www.ietf.org/proceedings/94/slides/ slides-94-rmcat-8.pdf>.
[SCReAM-implementation-experience] Sarker、Z。およびI. Johansson、「SCReAMの更新：実装エクスペリエンス」、2015年11月、<https://www.ietf.org/proceedings/94/slides/slides-94- rmcat-8.pdf>。
[TFWC] Choi, S. and M. Handley, "Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming Applications", DOI 10.1145/1364654.1364717, December 2007, <http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/ tfwc-conext.pdf>.
[TFWC] Choi、S。およびM. Handley、「Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming Applications」、DOI 10.1145 / 1364654.1364717、2007年12月、<http://www-dept.cs.ucl.ac.uk /staff/M.Handley/papers/ tfwc-conext.pdf>。
[WIRELESS-TESTS] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", Work in Progress, draft-ietf-rmcat-wireless-tests-04, May 2017.
[ワイヤレステスト] Sarker、Z.、Johansson、I.、Zhu、X.、Fu、J.、Tan、W。、およびM. Ramalho、「ワイヤレスネットワーク上のインタラクティブなリアルタイムメディアの評価テストケース」、 Work in Progress、draft-ietf-rmcat-wireless-tests-04、2017年5月。
Acknowledgements
謝辞
We would like to thank the following people for their comments, questions, and support during the work that led to this memo: Markus Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Sjoeberg, Robert Swain, Magnus Westerlund, and Stefan Aalund. Many additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja Kuehlewind for patiently reading, suggesting improvements and also for asking all the difficult but necessary questions. Thanks to Stefan Holmer, Xiaoqing Zhu, Safiqul Islam, and David Hayes for the additional review of this document. Thanks to Ralf Globisch for taking time to try out SCReAM in his challenging low-bitrate use cases, Robert Hedman for finding a few additional flaws in the running code, and Gustavo Garcia and 'miseri' for code contributions.
このメモにつながった作業中のコメント、質問、サポートについて、以下の人々に感謝します：マーカスアンダーソン、ボーバーマン、トマスフランクキラ、フレデリックギャビン、ローリッツハム、ハンスハンヌ、ニコラスヘルマンス、ステファンハーカンソン、アーレンドゥルカールソン、ダニエルリンストローム、マッツノードバーグ、ジョナサンサミュエルソン、リッカードシェーバーグ、ロバートスウェイン、マグナスウェスタールンド、ステファンオーランド。 RMCATの議長であるKaren E. E. NielsenとMirja Kuehlewindに辛抱強く読んでいただき、改善を提案し、すべての困難だが必要な質問をしていただき、ありがとうございました。このドキュメントの追加レビューを提供してくれたStefan Holmer、Xiaoqing Zhu、Safiqul Islam、David Hayesに感謝します。困難な低ビットレートのユースケースでSCReAMを試して時間を割いてくれたRalf Globisch、実行中のコードにいくつかの追加の欠陥を見つけてくれたRobert Hedman、コードの貢献にGustavo Garciaと 'miseri'に感謝します。
Authors' Addresses
著者のアドレス
Ingemar Johansson Ericsson AB Laboratoriegraend 11 Luleaa 977 53 Sweden
Ingemar Johansson Ericsson AB Laboratoriegraend 11 Luleaa 977 53スウェーデン
Phone: +46 730783289
Email: ingemar.s.johansson@ericsson.com
Zaheduzzaman Sarker Ericsson AB Laboratoriegraend 11 Luleaa 977 53 Sweden
Jaheduzzaman SAARCのLabratriGrind G Lulia 98 53スウェーデンのエリクソンスウェーデン
Phone: +46 761153743
Email: zaheduzzaman.sarker@ericsson.com