[要約] 要約： RFC 4586は、RTCPベースのフィードバックに対する拡張RTPプロファイルに関する結果を報告しています。このRFCは、タイミングルールシミュレーションの結果をまとめています。目的： このRFCの目的は、RTCPベースのフィードバックに関する拡張RTPプロファイルの効果を評価し、タイミングルールのシミュレーション結果を提供することです。
Network Working Group C. Burmeister
Request for Comments: 4586 R. Hakenberg
Category: Informational A. Miyazaki
Panasonic
J. Ott
Helsinki University of Technology
N. Sato
S. Fukunaga
Oki
July 2006
Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations
リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバックの拡張RTPプロファイル：タイミングルールシミュレーションの結果
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic.
このドキュメントでは、AVPFを示すリアルタイム輸送制御プロトコル（RTCP）ベースのフィードバックの拡張RTPプロファイルのタイミングルールをシミュレートするときに達成された結果を説明します。ユニキャストおよびマルチキャストトポロジは、いくつかのプロトコルと環境の構成と同様に考慮されます。結果は、タイミングルールがフィードバック遅延に関するパフォーマンスが向上し、コントロールトラフィックの許可ビットレートに関するよく受け入れられたRTPルールを維持することを示しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Timing Rules of the Extended RTP Profile for RTCP-Based
Feedback ........................................................4
3. Simulation Environment ..........................................5
3.1. Network Simulator Version 2 ................................5
3.2. RTP Agent ..................................................5
3.3. Scenarios ..................................................5
3.4. Topologies .................................................6
4. RTCP Bit Rate Measurements ......................................6
4.1. Unicast ....................................................7
4.2. Multicast .................................................10
4.3. Summary of the RTCP Bit Rate Measurements .................10
5. Feedback Measurements ..........................................11
5.1. Unicast ...................................................11
5.2. Multicast .................................................12
5.2.1. Shared Losses vs. Distributed Losses ...............13
6. Investigations on "l" ..........................................14
6.1. Feedback Suppression Performance ..........................16
6.2. Loss Report Delay .........................................18
6.3. Summary of "l" Investigations .............................18
7. Applications Using AVPF ........................................19
7.1. NEWPRED Implementation in NS2 .............................19
7.2. Simulation ................................................21
7.2.1. Simulation A - Constant Packet Loss Rate ...........21
7.2.2. Simulation B - Packet Loss Due to Congestion .......23
7.3. Summary of Application Simulations ........................24
8. Summary ........................................................24
9. Security Considerations ........................................25
10. Normative References ..........................................26
11. Informative References ........................................26
The Real-time Transport Protocol (RTP) is widely used for the transmission of real-time or near real-time media data over the Internet. While it was originally designed to work well for multicast groups in very large scales, its scope is not limited to that. More and more applications use RTP for small multicast groups (e.g., video conferences) or even unicast (e.g., IP telephony and media streaming applications).
リアルタイムトランスポートプロトコル（RTP）は、インターネット上のリアルタイムまたはほぼリアルタイムメディアデータの送信に広く使用されています。もともとは非常に大きなスケールのマルチキャストグループに適しているように設計されていましたが、その範囲はそれに限定されません。ますます多くのアプリケーションが、小さなマルチキャストグループ（ビデオ会議など）またはユニキャスト（IPテレフォニーやメディアストリーミングアプリケーションなど）にRTPを使用します。
RTP comes together with its companion protocol Real-time Transport Control Protocol (RTCP), which is used to monitor the transmission of the media data and provide feedback of the reception quality. Furthermore, it can be used for loose session control. Having the scope of large multicast groups in mind, the rules regarding when to send feedback were carefully restricted to avoid feedback explosion or feedback-related congestion in the network. RTP and RTCP have proven to work well in the Internet, especially in large multicast groups, which is shown by their widespread usage today.
RTPには、コンパニオンプロトコルのリアルタイムトランスポートコントロールプロトコル（RTCP）が付属しています。これは、メディアデータの送信を監視し、受信品質のフィードバックを提供するために使用されます。さらに、セッション制御のゆるいために使用できます。大規模なマルチキャストグループの範囲を念頭に置いているため、フィードバックを送信する時期に関するルールは、ネットワーク内のフィードバック爆発またはフィードバック関連の混雑を避けるために慎重に制限されていました。RTPとRTCPは、インターネット、特に大規模なマルチキャストグループでうまく機能することが証明されています。これは、今日の広範な使用法によって示されています。
However, the applications that transmit the media data only to small multicast groups or unicast may benefit from more frequent feedback. The source of the packets may be able to react to changes in the reception quality, which may be due to varying network utilization (e.g., congestion) or other changes. Possible reactions include transmission rate adaptation according to a congestion control algorithm or the invocation of error resilience features for the media stream (e.g., retransmissions, reference picture selection, NEWPRED, etc.).
ただし、メディアデータを小さなマルチキャストグループまたはユニキャストにのみ送信するアプリケーションは、より頻繁なフィードバックの恩恵を受ける可能性があります。パケットのソースは、ネットワークの使用率が変化すること（輻輳など）またはその他の変更が原因であるため、受信品質の変化に反応できる場合があります。考えられる反応には、輻輳制御アルゴリズムまたはメディアストリームのエラーレジリエンス機能の呼び出し（例：再送信、参照画像選択、NewPredなど）に従って伝送速度適応が含まれます。
As mentioned before, more frequent feedback may be desirable to increase the reception quality, but RTP restricts the use of RTCP feedback. Hence it was decided to create a new extended RTP profile, which redefines some of the RTCP timing rules, but keeps most of the algorithms for RTP and RTCP, which have proven to work well. The new rules should scale from unicast to multicast, where unicast or small multicast applications have the most gain from it. A detailed description of the new profile and its timing rules can be found in [1].
前述のように、受信の質を高めるには、より頻繁なフィードバックが望ましい場合がありますが、RTPはRTCPフィードバックの使用を制限します。したがって、RTCPタイミングルールの一部を再定義する新しい拡張RTPプロファイルを作成することが決定されましたが、RTPとRTCPのアルゴリズムのほとんどを保持します。新しいルールは、ユニキャストからマルチキャストまで拡大する必要があります。ユニキャストまたは小さなマルチキャストアプリケーションが最も利益を得ることができます。新しいプロファイルとそのタイミングルールの詳細な説明は、[1]に記載されています。
This document investigates the new algorithms by the means of simulations. We show that the new timing rules scale well and behave in a network-friendly manner. Firstly, the key features of the new RTP profile that are important for our simulations are roughly described in Section 2. After that, we describe in Section 3 the environment that is used to conduct the simulations. Section 4 describes simulation results that show the backwards compatibility to RTP and that the new profile is network-friendly in terms of used bandwidth for RTCP traffic. In Section 5, we show the benefit that applications could get from implementing the new profile. In Section 6, we investigated the effect of the parameter "l" (used to calculate the T_dither_max value) upon the algorithm performance, and finally, in Section 7, we show the performance gain we could get for a special application, namely, NEWPRED in [6] and [7].
このドキュメントでは、シミュレーションの手段により新しいアルゴリズムを調査します。新しいタイミングルールが十分に拡大し、ネットワークに優しい方法で動作することを示します。まず、シミュレーションにとって重要な新しいRTPプロファイルの重要な機能については、セクション2で大まかに説明します。その後、セクション3でシミュレーションの実施に使用される環境について説明します。セクション4では、RTPへの逆方向の互換性を示すシミュレーション結果と、新しいプロファイルがRTCPトラフィックに使用される帯域幅の観点からネットワークに優しいことを説明しています。セクション5では、新しいプロファイルの実装からアプリケーションが得られる利点を示します。セクション6では、アルゴリズムのパフォーマンスに対するパラメーター「L」（T_Dither_Max値の計算に使用）の効果を調査し、最後にセクション7では、特別なアプリケーション、つまりNewPredで得られるパフォーマンスゲインを示します。[6]および[7]で。
As said above, RTP restricts the usage of RTCP feedback. The main restrictions on RTCP are as follows:
上記のように、RTPはRTCPフィードバックの使用を制限します。RTCPの主な制限は次のとおりです。
- RTCP messages are sent in compound packets, i.e., every RTCP packet contains at least one sender report (SR) or receiver report (RR) message and a source description (SDES) message.
- RTCPメッセージは複合パケットで送信されます。つまり、すべてのRTCPパケットには、少なくとも1つの送信者レポート（SR）またはレシーバーレポート（RR）メッセージとソース説明（SDES）メッセージが含まれています。
- The RTCP compound packets are sent in time intervals (T_rr), which are computed as a function of the average packet size, the number of senders and receivers in the group, and the session bandwidth (5% of the session bandwidth is used for RTCP messages; this bandwidth is shared between all session members, where the senders may get a larger share than the receivers.)
- RTCP化合物パケットは、平均パケットサイズ、グループ内の送信者と受信機の数、およびセッション帯域幅の関数として計算される時間間隔（T_RR）で送信されます（セッション帯域幅の5％がRTCPに使用されます。メッセージ;この帯域幅は、すべてのセッションメンバー間で共有され、送信者はレシーバーよりも大きな共有を得ることができます。）
- The average minimum interval between two RTCP packets from the same source is 5 seconds.
- 同じソースからの2つのRTCPパケット間の平均最小間隔は5秒です。
We see that these rules prevent feedback explosion and scale well to large multicast groups. However, they do not allow timely feedback at all. While the second rule scales also to small groups or unicast (in this cases the interval might be as small as a few milliseconds), the third rule may prevent the receivers from sending feedback timely.
これらのルールは、フィードバックの爆発を防ぎ、大規模なマルチキャストグループに拡大することがわかります。ただし、タイムリーなフィードバックはまったく許可されていません。2番目のルールは小グループまたはユニキャストにもスケーリングしますが（この場合、間隔は数ミリ秒ほど小さい可能性があります）、3番目のルールでは、受信機がフィードバックをタイムリーに送信できない場合があります。
The timing rules to send RTCP feedback from the new RTP profile [1] consist of two key components. First, the minimum interval of 5 seconds is abolished. Second, receivers get one chance during every other of their (now quite small) RTCP intervals to send an RTCP packet "early", i.e., not according to the calculated interval, but virtually immediately. It is important to note that the RTCP interval calculation is still inherited from the original RTP specification.
新しいRTPプロファイル[1]からRTCPフィードバックを送信するタイミングルール[1]は、2つの重要なコンポーネントで構成されています。まず、5秒の最小間隔が廃止されます。第二に、レシーバーは、RTCPパケットを「早期」に送信するために、RTCP間隔の他のすべての間に1つのチャンスを得ることができます。RTCP間隔計算は、元のRTP仕様からまだ継承されていることに注意することが重要です。
The specification and all the details of the extended timing rules can be found in [1]. Rather than describing the algorithms here, we reference the original specification [1]. Therefore, we use also the same variable names and abbreviations as in [1].
拡張タイミングルールの仕様とすべての詳細は、[1]に記載されています。ここでアルゴリズムを説明するのではなく、元の仕様[1]を参照します。したがって、[1]と同じ変数名と略語も使用します。
This section describes the simulation testbed that was used for the investigations and its key features. The extensions to the simulator that were necessary are roughly described in the following sections.
このセクションでは、調査に使用されたシミュレーションテストベッドとその主要な機能について説明します。必要なシミュレーターへの拡張は、次のセクションでおおよそ説明しています。
The simulations were conducted using the network simulator version 2 (ns2). ns2 is an open source project, written in a combination of Tool Command Language (TCL) and C++. The scenarios are set up using TCL. Using the scripts, it is possible to specify the topologies (nodes and links, bandwidths, queue sizes, or error rates for links) and the parameters of the "agents", i.e., protocol configurations. The protocols themselves are implemented in C++ in the agents, which are connected to the nodes. The documentation for ns2 and the newest version can be found in [4].
シミュレーションは、ネットワークシミュレーターバージョン2（NS2）を使用して実施されました。NS2は、ツールコマンド言語（TCL）とcの組み合わせで記述されたオープンソースプロジェクトです。シナリオはTCLを使用して設定されます。スクリプトを使用して、トポロジ（ノードとリンク、帯域幅、キューサイズ、またはリンクのエラー率）と「エージェント」のパラメーター、つまりプロトコル構成を指定することができます。プロトコル自体は、ノードに接続されているエージェントのCに実装されています。NS2と最新バージョンのドキュメントは[4]にあります。
We implemented a new agent, based on RTP/RTCP. RTP packets are sent at a constant packet rate with the correct header sizes. RTCP packets are sent according to the timing rules of [2] and [3], and also its algorithms for group membership maintenance are implemented. Sender and receiver reports are sent.
RTP/RTCPに基づいて、新しいエージェントを実装しました。RTPパケットは、正しいヘッダーサイズの一定のパケットレートで送信されます。RTCPパケットは[2]および[3]のタイミングルールに従って送信され、グループメンバーシップメンテナンスのためのアルゴリズムも実装されます。送信者と受信機のレポートが送信されます。
Further, we extended the agent to support the extended profile [1]. The use of the new timing rules can be turned on and off via parameter settings in TCL.
さらに、エージェントを拡張して、拡張プロファイルをサポートしました[1]。TCLのパラメーター設定を介して、新しいタイミングルールの使用をオン /オフにすることができます。
The scenarios that are simulated are defined in TCL scripts. We set up several different topologies, ranging from unicast with two session members to multicast with up to 25 session members. Depending on the sending rates used and the corresponding link bandwidths, congestion losses may occur. In some scenarios, bit errors are inserted on certain links. We simulated groups with RTP/AVP agents, RTP/AVPF agents, and mixed groups.
シミュレートされたシナリオは、TCLスクリプトで定義されています。ユニキャストから2人のセッションメンバーとの範囲で、最大25人のセッションメンバーを持つマルチキャストまで、いくつかの異なるトポロジを設定しました。使用される送信率と対応するリンク帯域幅に応じて、うっ血損失が発生する可能性があります。一部のシナリオでは、特定のリンクにビットエラーが挿入されます。RTP/AVPエージェント、RTP/AVPFエージェント、および混合グループを含むグループをシミュレートしました。
The feedback messages are generally NACK messages as defined in [1] and are triggered by packet loss.
フィードバックメッセージは、一般に[1]で定義されているNACKメッセージであり、パケット損失によってトリガーされます。
Mainly, four different topologies are simulated to show the key features of the extended profile. However, for some specific simulations we used different topologies. This is then indicated in the description of the simulation results. The main four topologies are named after the number of participating RTP agents, i.e., T-2, T-4, T-8, and T-16, where T-2 is a unicast scenario, T-4 contains four agents, etc. Figure 1 below illustrates the main topologies.
主に、拡張プロファイルの重要な機能を示すために、4つの異なるトポロジがシミュレートされます。ただし、特定のシミュレーションでは、さまざまなトポロジを使用しました。これは、シミュレーション結果の説明に示されます。主な4つのトポロジは、参加しているRTPエージェントの数、つまりT-2、T-4、T-8、およびT-16にちなんで命名されています。T-2はユニキャストシナリオで、T-4には4つのエージェントなどが含まれます。。以下の図1は、主要なトポロジーを示しています。
A5
A5 | A6
/ | /
/ | /--A7
/ |/
A2 A2-----A6 A2--A8
/ / / A9
/ / / /
/ / / /---A10
A1-----A2 A1-----A3 A1-----A3-----A7 A1------A3<
\ \ \ \---A11
\ \ \ \
\ \ \ A12
A4 A4-----A8 A4--A13
|\
| \--A14
| \
| A15
A16
T-2 T-4 T-8 T-16
Figure 1: Simulated topologies
図1：シミュレートされたトポロジ
The new timing rules allow more frequent RTCP feedback for small multicast groups. In large groups, the algorithm behaves similarly to the normal RTCP timing rules. While it is generally good to have more frequent feedback, it cannot be allowed at all to increase the bit rate used for RTCP above a fixed limit, i.e., 5% of the total RTP bandwidth according to RTP. This section shows that the new timing rules keep RTCP bandwidth usage under the 5% limit for all investigated scenarios, topologies, and group sizes. Furthermore, we show that mixed groups (some members using AVP, some AVPF) can be allowed and that each session member behaves fairly according to its corresponding specification. Note that other values for the RTCP bandwidth limit may be specified using the RTCP bandwidth modifiers as in [10].
新しいタイミングルールにより、小さなマルチキャストグループのRTCPフィードバックがより頻繁に使用されます。大規模なグループでは、アルゴリズムは通常のRTCPタイミングルールと同様に動作します。一般的に、より頻繁なフィードバックを得ることは良いことですが、RTCPに使用されるビットレートを固定制限、つまりRTPによるとRTPの合計帯域幅の5％を上げることはまったく許可できません。このセクションでは、新しいタイミングルールが、調査したすべてのシナリオ、トポロジ、およびグループサイズの5％制限の下でRTCP帯域幅の使用を維持していることを示しています。さらに、混合グループ（AVPを使用している一部のメンバー、AVPF）を許可し、各セッションメンバーが対応する仕様に従って公正に動作することを示します。RTCP帯域幅の制限の他の値は、[10]のようにRTCP帯域幅修飾子を使用して指定できることに注意してください。
First we measured the RTCP bandwidth share in the unicast topology T-2. Even for a fixed topology and group size, there are several protocol parameters that are varied to simulate a large range of different scenarios. We varied the configurations of the agents in the sense that the agents may use AVP or AVPF. Thereby it is possible that one agent uses AVP and the other AVPF in one RTP session. This is done to test the backwards compatibility of the AVPF profile.
最初に、ユニキャストトポロジT-2でRTCP帯域幅共有を測定しました。固定トポロジとグループサイズであっても、さまざまなシナリオをシミュレートするためにさまざまなプロトコルパラメーターがいくつかあります。エージェントがAVPまたはAVPFを使用できるという意味で、エージェントの構成を変化させました。これにより、1つのエージェントが1つのRTPセッションでAVPともう1つのAVPFを使用する可能性があります。これは、AVPFプロファイルの後方互換性をテストするために行われます。
Next, we consider scenarios where no losses occur. In this case, both RTP session members transmit the RTCP compound packets at regular intervals, calculated as T_rr, if they use AVPF, and use a minimum interval of 5 seconds (on average) if they implement AVP. No early packets are sent, because the need to send early feedback is not given. Still it is important to see that not more than 5% of the session bandwidth is used for RTCP and that AVP and AVPF members can coexist without interference. The results can be found in Table 1.
次に、損失が発生しないシナリオを検討します。この場合、両方のRTPセッションメンバーは、AVPFを使用する場合はT_RRとして計算された定期的にRTCP化合物パケットを定期的に送信し、AVPを実装する場合は平均（平均して）の最小間隔（平均）を使用します。早期のフィードバックを送信する必要性が与えられていないため、初期のパケットは送信されません。それでも、セッション帯域幅の5％以下がRTCPに使用されていないことを確認することが重要であり、AVPおよびAVPFメンバーは干渉なしに共存できることを確認することが重要です。結果は表1にあります。
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.01 | 0.02 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.49 | 2.55 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.50 | 2.58 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.06 | 0.12 |
|200 kbps | 1,2 | - | 1,2 | - | 0.08 | 0.08 | 0.16 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.44 | 2.54 | 4.98 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.51 | 5.01 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.48 | 3.06 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.77 | 2.51 | 3.28 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.61 | 1.19 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.77 | 0.79 | 1.58 |
Table 1: Unicast simulations without packet loss
表1：パケット損失のないユニキャストシミュレーション
We can see that in configurations where both agents use the new timing rules each of them uses, at most, about 2.5% of the session bandwidth for RTP, which sums up to 5% of the session bandwidth for both. This is achieved regardless of the agent being a sender or a receiver. In the cases where agent A1 uses AVP and agent A2 AVPF, the total RTCP session bandwidth decreases. This is because agent A1 can send RTCP packets only with an average minimum interval of 5 seconds. Thus, only a small fraction of the session bandwidth is used for its RTCP packets. For a high-bit-rate session (session bandwidth = 2 Mbps), the fraction of the RTCP packets from agent A1 is as small as 0.01%. For smaller session bandwidths, the fraction increases because the same amount of RTCP data is sent. The bandwidth share that is used by RTCP packets from agent A2 is not different from what was used, when both agents implemented the AVPF. Thus, the interaction of AVP and AVPF agents is not problematic in these scenarios at all.
両方のエージェントがそれぞれが使用する新しいタイミングルールを使用する構成では、せいぜいRTPのセッション帯域幅の約2.5％であり、両方のセッション帯域幅の最大5％を合計していることがわかります。これは、エージェントが送信者または受信機であることに関係なく、達成されます。エージェントA1がAVPおよびエージェントA2 AVPFを使用する場合、合計RTCPセッション帯域幅が減少します。これは、エージェントA1が5秒の平均最小間隔でのみRTCPパケットを送信できるためです。したがって、RTCPパケットにはセッション帯域幅のごく一部のみが使用されます。高ビットレートセッション（セッション帯域幅= 2 Mbps）の場合、エージェントA1のRTCPパケットの割合は0.01％です。セッションの帯域幅が小さい場合、同じ量のRTCPデータが送信されるため、画分が増加します。エージェントA2のRTCPパケットが使用する帯域幅の共有は、両方のエージェントがAVPFを実装したときに使用されたものと違いはありません。したがって、AVPとAVPFエージェントの相互作用は、これらのシナリオではまったく問題ではありません。
In our second unicast experiment, we show that the allowed RTCP bandwidth share is not exceeded, even if packet loss occurs. We simulated a constant byte error rate (BYER) on the link. The byte errors are inserted randomly according to a uniform distribution.
2回目のユニキャスト実験では、パケットの損失が発生した場合でも、許可されたRTCP帯域幅の共有が超えられないことを示します。リンク上の一定のバイトエラー率（Byer）をシミュレートしました。バイトエラーは、均一な分布に従ってランダムに挿入されます。
Packets with byte errors are discarded on the link; hence the receiving agents will not see the loss immediately. The agents detect packet loss by a gap in the sequence number.
リンクにバイトエラーがあるパケットが破棄されます。したがって、受信エージェントはすぐに損失を見ません。エージェントは、シーケンス番号のギャップによってパケットの損失を検出します。
When an AVPF agent detects a packet loss, the early feedback procedure is started. As described in AVPF [1], in unicast T_dither_max is always zero, hence an early packet can be sent immediately if allow_early is true. If the last packet was already an early one (i.e., allow_early = false), the feedback might be appended to the next regularly scheduled receiver report. The max_feedback_delay parameter (which we set to 1 second in our simulations) determines if that is allowed.
AVPFエージェントがパケット損失を検出すると、早期フィードバック手順が開始されます。AVPF [1]で説明されているように、Unicast t_dither_maxは常にゼロです。したがって、lowad_earlyが真である場合は、早期パケットをすぐに送信できます。最後のパケットがすでに初期のパケット（つまり、Allow_early = false）であった場合、フィードバックは次の定期的にスケジュールされたレシーバーレポートに追加される可能性があります。max_feedback_delayパラメーター（シミュレーションで1秒に設定）は、それが許可されているかどうかを判断します。
The results are shown in Table 2, where we can see that there is no difference in the RTCP bandwidth share, whether or not losses occur. This is what we expected, because even though the RTCP packet size grows and early packets are sent, the interval between the packets increases and thus the RTCP bandwidth stays the same. Only the RTCP bandwidth of the agents that use the AVP increases slightly. This is because the interval between the packets is still 5 seconds (in average), but the packet size increased because of the feedback that is appended.
結果は表2に示されており、損失が発生するかどうかにかかわらず、RTCP帯域幅共有に違いはないことがわかります。RTCPパケットサイズが増加し、初期パケットが送信されている場合でも、パケット間の間隔が増加し、RTCP帯域幅が同じままであるため、これは予想されていたことです。AVPを使用するエージェントのRTCP帯域幅のみがわずかに増加します。これは、パケット間の間隔がまだ5秒（平均）であるためですが、追加されたフィードバックのためにパケットサイズが増加したためです。
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.02 | 0.03 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.49 | 4.99 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.50 | 2.56 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.49 | 2.57 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.07 | 0.13 |
|200 kbps | 1,2 | - | 1,2 | - | 0.09 | 0.08 | 0.17 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.57 | 4.99 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.52 | 2.51 | 5.03 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.54 | 3.12 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.83 | 2.43 | 3.26 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.73 | 1.31 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.86 | 0.84 | 1.70 |
Table 2: Unicast simulations with packet loss
表2：パケット損失を伴うユニキャストシミュレーション
Next, we investigated the RTCP bandwidth share in multicast scenarios; i.e., we simulated the topologies T-4, T-8, and T-16 and measured the fraction of the session bandwidth that was used for RTCP packets. Again we considered different situations and protocol configurations (e.g., with or without bit errors, groups with AVP and/or AVPF agents, etc.). For reasons of readability, we present only selected results. For a documentation of all results, see [5].
次に、マルチキャストシナリオでRTCP帯域幅の共有を調査しました。つまり、トポロジーT-4、T-8、およびT-16をシミュレートし、RTCPパケットに使用されたセッション帯域幅の割合を測定しました。繰り返しますが、さまざまな状況とプロトコル構成を検討しました（たとえば、ビットエラー、AVPおよび/またはAVPFエージェントなどのグループなど）。読みやすさの理由から、選択された結果のみを提示します。すべての結果の文書については、[5]を参照してください。
The simulations of the different topologies in scenarios where no losses occur (neither through bit errors nor through congestion) show a similar behavior as in the unicast case. For all group sizes, the maximum RTCP bit rate share used is 5.06% of the session bandwidth in a simulation of 16 session members in a low-bit-rate scenario (session bandwidth = 20 kbps) with several senders. In all other scenarios without losses, the RTCP bit rate share used is below that. Thus, the requirement that not more than 5% of the session bit rate should be used for RTCP is fulfilled with reasonable accuracy.
損失が発生しないシナリオのさまざまなトポロジーのシミュレーション（ビットエラーも渋滞を介しても）は、ユニキャストの場合と同様の動作を示しています。すべてのグループサイズで、使用される最大RTCPビットレート共有は、いくつかの送信者を持つ低ビットレートシナリオ（セッション帯域幅= 20 kbps）の16人のセッションメンバーのシミュレーションのセッション帯域幅の5.06％です。損失のない他のすべてのシナリオでは、使用されるRTCPビットレート共有はそれ以下です。したがって、RTCPにセッションビットレートの5％以下を使用する必要があるという要件は、合理的な正確さで満たされます。
Simulations where bit errors are randomly inserted in RTP and RTCP packets and the corrupted packets are discarded give the same results. The 5% rule is kept (at maximum 5.07% of the session bandwidth is used for RTCP).
RTPおよびRTCPパケットにビットエラーがランダムに挿入され、破損したパケットが破棄されるシミュレーションは、同じ結果を与えます。5％のルールは保持されます（セッション帯域幅の最大5.07％がRTCPに使用されます）。
Finally, we conducted simulations where we reduced the link bandwidth and thereby caused congestion-related losses. These simulations are different from the previous bit error simulations, in that the losses occur more in bursts and are more correlated, also between different agents. The correlation and "burstiness" of the packet loss is due to the queuing discipline in the routers we simulated; we used simple FIFO queues with a drop-tail strategy to handle congestion. Random Early Detection (RED) queues may enhance the performance, because the burstiness of the packet loss might be reduced; however, this is not the subject of our investigations, but is left for future study. The delay between the agents, which also influences RTP and RTCP packets, is much more variable because of the added queuing delay. Still the RTCP bit rate share used does not increase beyond 5.09% of the session bandwidth. Thus, also for these special cases the requirement is fulfilled.
最後に、リンクの帯域幅を削減し、それにより混雑関連の損失を引き起こしたシミュレーションを実施しました。これらのシミュレーションは、以前のビットエラーシミュレーションとは異なります。これは、損失がバーストでより多く発生し、異なるエージェント間でより相関しているという点で異なります。パケット損失の相関と「破裂」は、私たちがシミュレートしたルーターのキューイングの規律によるものです。渋滞を処理するために、ドロップテール戦略を備えた簡単なFIFOキューを使用しました。ランダムな早期検出（赤）キューは、パケット損失の乱れが減る可能性があるため、パフォーマンスを向上させる可能性があります。しかし、これは私たちの調査の主題ではなく、将来の研究のために残されています。RTPとRTCPパケットにも影響するエージェント間の遅延は、キューイングの遅延が追加されているため、はるかに変動します。それでも、使用されるRTCPビットレート共有は、セッション帯域幅の5.09％を超えて増加しません。したがって、これらの特別なケースでは、要件が満たされます。
We have shown that for unicast and reasonable multicast scenarios, feedback implosion does not happen. The requirement that at maximum 5% of the session bandwidth is used for RTCP is fulfilled for all investigated scenarios.
ユニキャストと合理的なマルチキャストシナリオの場合、フィードバックの爆発は発生しないことを示しました。セッション帯域幅の最大5％でRTCPに使用されるという要件は、調査されたすべてのシナリオに対して満たされます。
In this section we describe the results of feedback delay measurements, which we conducted in the simulations. Therefore, we use two metrics for measuring the performance of the algorithms; these are the "mean waiting time" (MWT) and the number of feedback packets that are sent, suppressed, or not allowed. The waiting time is the time, measured at a certain agent, between the detection of a packet loss event and the time when the corresponding feedback is sent. Assuming that the value of the feedback decreases with its delay, we think that the mean waiting time is a good metric to measure the performance gain we could get by using AVPF instead of AVP.
このセクションでは、シミュレーションで実施したフィードバック遅延測定の結果について説明します。したがって、アルゴリズムのパフォーマンスを測定するために2つのメトリックを使用します。これらは、「平均待機時間」（MWT）と、送信、抑制、または許可されていないフィードバックパケットの数です。待ち時間は、特定のエージェントで測定された時間と、パケット損失イベントの検出と、対応するフィードバックが送信される時間です。フィードバックの値が遅延とともに低下すると仮定すると、AVPの代わりにAVPFを使用することで得られるパフォーマンスの向上を測定するための平均待機時間は良いメトリックであると考えています。
The feedback an RTP/AVPF agent wants to send can be either sent or not sent. If it was not sent, this could be due to feedback suppression (i.e., another receiver already sent the same feedback) or because the feedback was not allowed (i.e., the max_feedback_delay was exceeded). We traced for every detected loss, if the agent sent the corresponding feedback or not and if not, why. The more feedback was not allowed, the worse the performance of the algorithm. Together with the waiting times, this gives us a good hint of the overall performance of the scheme.
RTP/AVPFエージェントが送信したいフィードバックは、送信するか、送信しないことができます。送信されていない場合、これはフィードバック抑制（つまり、別のレシーバーがすでに同じフィードバックを送信した）またはフィードバックが許可されていないためである可能性があります（つまり、max_feedback_delayを超えた）。エージェントが対応するフィードバックを送信したかどうか、そうでない場合は、検出されたすべての損失を追跡しました。より多くのフィードバックが許可されていないほど、アルゴリズムのパフォーマンスが悪化します。待ち時間とともに、これはスキームの全体的なパフォーマンスの良いヒントを与えてくれます。
In the unicast case, the maximum dithering interval T_dither_max is fixed and set to zero. This is because it does not make sense for a unicast receiver to wait for other receivers if they have the same feedback to send. But still feedback can be delayed or might not be permitted to be sent at all. The regularly scheduled packets are spaced according to T_rr, which depends in the unicast case mainly on the session bandwidth.
ユニキャストの場合、最大ディザリング間隔t_dither_maxが固定され、ゼロに設定されています。これは、ユニキャストレシーバーが同じフィードバックを送信する場合、他のレシーバーを待つことが意味がないためです。しかし、フィードバックを遅らせることも、まったく送信することも許可されない場合があります。定期的にスケジュールされたパケットは、主にセッション帯域幅にユニキャストの場合に依存するT_RRに従って間隔を空けます。
Table 3 shows the mean waiting times (MWTs) measured in seconds for some configurations of the unicast topology T-2. The number of feedback packets that are sent or discarded is listed also (feedback sent (sent) or feedback discarded (disc)). We do not list suppressed packets, because for the unicast case feedback suppression does not apply. In the simulations, agent A1 was a sender and agent A2 was a pure receiver.
表3は、ユニキャストトポロジT-2の一部の構成で数秒で測定された平均待機時間（MWTS）を示しています。送信または破棄されるフィードバックパケットの数もリストされています（送信（送信）またはフィードバック廃棄（disc））。ユニキャストケースのフィードバック抑制が適用されないため、抑制されたパケットをリストしません。シミュレーションでは、エージェントA1は送信者であり、エージェントA2は純粋なレシーバーでした。
| | | Feedback Statistics |
| Session | | AVP | AVPF |
|Bandwidth| PLR | sent |disc| MWT | sent |disc| MWT |
+---------+-------+------+----+-------+------+----+-------+
| 2 Mbps | 0.001 | 781 | 0 | 2.604 | 756 | 0 | 0.015 |
| 2 Mbps | 0.01 | 7480 | 0 | 2.591 | 7548 | 2 | 0.006 |
| 2 Mbps | cong. | 25 | 0 | 2.557 | 1741 | 0 | 0.001 |
| 20 kbps | 0.001 | 79 | 0 | 2.472 | 74 | 2 | 0.034 |
| 20 kbps | 0.01 | 780 | 0 | 2.605 | 709 | 64 | 0.163 |
| 20 kbps | cong. | 780 | 0 | 2.590 | 687 | 70 | 0.162 |
Table 3: Feedback statistics for the unicast simulations
表3：ユニキャストシミュレーションのフィードバック統計
From the table above we see that the mean waiting time can be decreased dramatically by using AVPF instead of AVP. While the waiting times for agents using AVP is always around 2.5 seconds (half the minimum interval average), it can be decreased to a few ms for most of the AVPF configurations.
上の表から、AVPの代わりにAVPFを使用することにより、平均待機時間を劇的に減らすことができることがわかります。AVPを使用するエージェントの待ち時間は常に約2.5秒（最小間隔平均の半分）ですが、ほとんどのAVPF構成で数MSに減少する可能性があります。
In the configurations with high session bandwidth, normally all triggered feedback is sent. This is because more RTCP bandwidth is available. There are only very few exceptions, which are probably due to more than one packet loss within one RTCP interval, where the first loss was by chance sent quite early. In this case, it might be possible that the second feedback is triggered after the early packet was sent, but possibly too early to append it to the next regularly scheduled report, because of the limitation of the max_feedback_delay. This is different for the cases with a small session bandwidth, where the RTCP bandwidth share is quite low and T_rr thus larger. After an early packet was sent, the time to the next regularly scheduled packet can be very high. We saw that in some cases the time was larger than the max_feedback_delay, and in these cases the feedback is not allowed to be sent at all.
セッション帯域幅が高い構成では、通常、すべてのトリガーされたフィードバックが送信されます。これは、より多くのRTCP帯域幅が利用可能であるためです。例外はほとんどありません。これは、おそらく1つのRTCP間隔内で複数のパケット損失が原因であるため、最初の損失は偶然にかなり早く送信されました。この場合、MAX_FEEDBACK_DELAYの制限のために、初期のパケットが送信された後に2番目のフィードバックがトリガーされる可能性がありますが、次の定期的にスケジュールされたレポートに追加するには早すぎる可能性があります。これは、RTCP帯域幅の共有が非常に低く、T_RRが大きいため、小さなセッション帯域幅があるケースでは異なります。早期のパケットが送信された後、次の定期的にスケジュールされたパケットまでの時間は非常に高くなる可能性があります。場合によっては、時間がmax_feedback_delayよりも大きく、これらの場合、フィードバックをまったく送信できないことがわかりました。
With a different setting of max_feedback_delay, it is possible to have either more feedback that is not allowed and a decreased mean waiting time or more feedback that is sent but an increased waiting time. Thus, the parameter should be set with care according to the application's needs.
max_feedback_delayの別の設定では、許可されていないフィードバックを増やし、送信される平均待機時間の減少またはより多くのフィードバックを減らすことができますが、待機時間の増加が可能です。したがって、パラメーターは、アプリケーションのニーズに応じて注意して設定する必要があります。
In this section, we describe some measurements of feedback statistics in the multicast simulations. We picked out certain characteristic and representative results. We considered the topology T-16. Different scenarios and applications are simulated for this topology. The parameters of the different links are set as follows. The agents A2, A3, and A4 are connected to the middle node of the multicast tree, i.e., agent A1, via high bandwidth and low-delay links. The other agents are connected to the nodes 2, 3, and 4 via different link characteristics. The agents connected to node 2 represent mobile users. They suffer in certain configurations from a certain byte error rate on their access links and the delays are high. The agents that are connected to node 3 have low-bandwidth access links, but do not suffer from bit errors. The last agents, which are connected to node 4, have high bandwidth and low delay.
このセクションでは、マルチキャストシミュレーションのフィードバック統計の測定値について説明します。特定の特性と代表的な結果を選択しました。トポロジーT-16を検討しました。このトポロジについては、さまざまなシナリオとアプリケーションがシミュレートされます。異なるリンクのパラメーターは次のように設定されています。エージェントA2、A3、およびA4は、マルチキャストツリーの中央ノード、つまりエージェントA1に高帯域幅と低遅延リンクを介して接続されています。他のエージェントは、異なるリンク特性を介してノード2、3、および4に接続されています。ノード2に接続されているエージェントは、モバイルユーザーを表します。アクセスリンクの特定のバイトエラー率から特定の構成に苦しみ、遅延が高くなります。ノード3に接続されているエージェントは、低帯域幅アクセスリンクを持っていますが、ビットエラーに悩まされていません。ノード4に接続されている最後のエージェントは、帯域幅が高く、遅延が低くなっています。
In our first investigation, we wanted to see the effect of the loss characteristic on the algorithm's performance. We investigate the cases where packet loss occurs for several users simultaneously (shared losses) or totally independently (distributed losses). We first define agent A1 to be the sender. In the case of shared losses, we inserted a constant byte error rate on one of the middle links, i.e., the link between A1 and A2. In the case of distributed losses, we inserted the same byte error rate on all links downstream of A2.
最初の調査では、アルゴリズムのパフォーマンスに対する損失特性の影響を確認したかったのです。複数のユーザーに対してパケットの損失が同時に発生する（共有損失）または完全に独立して（分散損失）ケースを調査します。最初にエージェントA1を送信者に定義します。共有損失の場合、中間リンクの1つ、つまりA1とA2の間のリンクに一定のバイトエラー率を挿入しました。分布損失の場合、A2の下流のすべてのリンクに同じバイトエラー率を挿入しました。
These scenarios are especially interesting because of the feedback suppression algorithm. When all receivers share the same loss, it is only necessary for one of them to send the loss report. Hence if a member receives feedback with the same content that it has scheduled to be sent, it suppresses the scheduled feedback. Of course, this suppressed feedback does not contribute to the mean waiting times. So we expect reduced waiting times for shared losses, because the probability is high that one of the receivers can send the feedback more or less immediately. The results are shown in the following table.
これらのシナリオは、フィードバック抑制アルゴリズムのために特に興味深いものです。すべてのレシーバーが同じ損失を共有している場合、そのうちの1人が損失レポートを送信する必要があります。したがって、メンバーが送信される予定と同じコンテンツでフィードバックを受け取った場合、スケジュールされたフィードバックを抑制します。もちろん、この抑制されたフィードバックは、平均待機時間に寄与しません。そのため、レシーバーのいずれかがよりすぐにフィードバックを送信できる可能性が高いため、共有損失の待機時間の短縮が予想されます。結果を次の表に示します。
| | Feedback Statistics |
| | Shared Losses | Distributed Losses |
|Agent|sent|fbsp|disc|sum | MWT |sent|fbsp|disc|sum | MWT |
+-----+----+----+----+----+-----+----+----+----+----+-----+
| A2 | 274| 351| 25| 650|0.267| -| -| -| -| -|
| A5 | 231| 408| 11| 650|0.243| 619| 2| 32| 653|0.663|
| A6 | 234| 407| 9| 650|0.235| 587| 2| 32| 621|0.701|
| A7 | 223| 414| 13| 650|0.253| 594| 6| 41| 641|0.658|
| A8 | 188| 443| 19| 650|0.235| 596| 1| 32| 629|0.677|
Table 4: Feedback statistics for multicast simulations
表4：マルチキャストシミュレーションのフィードバック統計
Table 4 shows the feedback statistics for the simulation of a large group size. All 16 agents of topology T-16 joined the RTP session. However, only agent A1 acts as an RTP sender; the other agents are pure receivers. Only 4 or 5 agents suffer from packet loss, i.e., A2, A5, A6, A7, and A8 for the case of shared losses and A5, A6, A7, and A8 in the case of distributed losses. Since the number of session members is the same for both cases, T_rr is also the same on the average. Still the mean waiting times are reduced by more than 50% in the case of shared losses. This proves our assumption that shared losses enhance the performance of the algorithm, regardless of the loss characteristic.
表4は、大きなグループサイズのシミュレーションのフィードバック統計を示しています。トポロジーT-16の16エージェントすべてがRTPセッションに参加しました。ただし、エージェントA1のみがRTP送信者として機能します。他のエージェントは純粋なレシーバーです。分布損失の場合、共有損失の場合、つまりA2、A5、A6、A7、およびA8など、パケット損失、つまりA2、A5、A6、A7、およびA8のみが苦しんでいます。セッションメンバーの数はどちらの場合も同じであるため、T_RRも平均で同じです。それでも、共有された損失の場合、平均待機時間は50％以上削減されます。これは、損失の特性に関係なく、共有損失がアルゴリズムのパフォーマンスを向上させるという仮定を証明します。
The feedback suppression mechanism seems to be working quite well. Even though some feedback is sent from different receivers (i.e., 1150 loss reports are sent in total and only 650 packets were lost, resulting in loss reports being received on the average 1.8 times), most of the redundant feedback was suppressed. That is, 2023 loss reports were suppressed from 3250 individual detected losses, which means that more than 60% of the feedback was actually suppressed.
フィードバック抑制メカニズムは非常にうまく機能しているようです。さまざまなレシーバーからいくつかのフィードバックが送信されますが（つまり、合計で1150の損失レポートが送信され、650パケットのみが失われたため、平均1.8倍で損失レポートが受信されます）、ほとんどの冗長フィードバックが抑制されました。つまり、2023年の損失報告は、3250個の個別の検出された損失から抑制されました。つまり、フィードバックの60％以上が実際に抑制されました。
In this section, we want to investigate the effect of the parameter "l" on the T_dither_max calculation in RTP/AVPF agents. We investigate the feedback suppression performance as well as the report delay for three sample scenarios.
このセクションでは、RTP/AVPFエージェントのT_Dither_Max計算に対するパラメーター「L」の効果を調査します。フィードバック抑制パフォーマンスと、3つのサンプルシナリオのレポート遅延を調査します。
For all receivers, the T_dither_max value is calculated as T_dither_max = l * T_rr, with l = 0.5. The rationale for this is that, in general, if the receiver has no round-trip time (RTT) estimation, it does not know how long it should wait for other receivers to send feedback. The feedback suppression algorithm would certainly fail if the time selected is too short. However, the waiting time is increased unnecessarily (and thus the value of the feedback is decreased) in case the chosen value is too large. Ideally, the optimum time value could be found for each case, but this is not always feasible. On the other hand, it is not dangerous if the optimum time is not used. A decreased feedback value and a failure of the feedback suppression mechanism do not hurt the network stability. We have shown for the cases of distributed losses that the overall bandwidth constraints are kept in any case and thus we could only lose some performance by choosing the wrong time value. On the other hand, a good measure for T_dither_max is the RTCP interval T_rr. This value increases with the number of session members. Also, we know that we can send feedback at least every T_rr. Thus, increasing T_dither max beyond T_rr would certainly make no sense. So by choosing T_rr/2, we guarantee that at least sometimes (i.e., when a loss is detected in the first half of the interval between two regularly scheduled RTCP packets) we are allowed to send early packets. Because of the randomness of T_dither, we still have a good chance of sending the early packet in time.
すべての受信機について、t_dither_max値はt_dither_max = l * t_rrとして計算され、l = 0.5です。これの理論的根拠は、一般に、受信者に往復時間（RTT）の推定がない場合、他のレシーバーがフィードバックを送信するのを待つ時間がわからないということです。選択された時間が短すぎると、フィードバック抑制アルゴリズムは確かに失敗します。ただし、選択した値が大きすぎる場合、待機時間は不必要に（したがってフィードバックの値が減少します）。理想的には、各ケースで最適な時間値を見つけることができますが、これは必ずしも実行可能ではありません。一方、最適な時間を使用していない場合、危険ではありません。フィードバック値の低下とフィードバック抑制メカニズムの障害は、ネットワークの安定性を損なうことはありません。分散損失の場合、全体的な帯域幅の制約がいずれにせよ維持されているため、間違った時間値を選択することでパフォーマンスを失うことができることを示しました。一方、t_dither_maxの適切な尺度はRTCP間隔T_RRです。この値は、セッションメンバーの数とともに増加します。また、少なくともすべてのT_RRはフィードバックを送信できることを知っています。したがって、t_rrを超えてmaxを増やすことは確かに意味がありません。したがって、T_RR/2を選択することにより、少なくとも時々（つまり、定期的にスケジュールされた2つのRTCPパケット間の間隔の前半で損失が検出された場合）、早期パケットを送信できることを保証します。T_Ditherのランダム性があるため、早期のパケットを時間内に送信する可能性が高くなります。
The AVPF profile specifies that the calculation of T_dither_max, as given above, is common to session members having an RTT estimation and to those not having it. If this were not so, participants using different calculations for T_dither_max might also have very different mean waiting times before sending feedback, which translates into different reporting priorities. For example, in a scenario where T_rr = 1 s and the RTT = 100 ms, receivers using the RTT estimation would, on average, send more feedback than those not using it. This might partially cancel out the feedback suppression mechanism and even cause feedback implosion. Also note that, in a general case where the losses are shared, the feedback suppression mechanism works if the feedback packets from each receiver have enough time to reach each of the other ones before the calculated T_dither_max seconds. Therefore, in scenarios of very high bandwidth (small T_rr), the calculated T_dither_max could be much smaller than the propagation delay between receivers, which would translate into a failure of the feedback suppression mechanism. In these cases, one solution could be to limit the bandwidth available to receivers (see [10]) such that this does not happen. Another solution could be to develop a mechanism for feedback suppression based on the RTT estimation between senders. This will not be discussed here and may be the subject of another document. Note, however, that a really high bandwidth media stream is not that likely to rely on this kind of error repair in the first place.
AVPFプロファイルは、上記のように、T_Dither_maxの計算がRTT推定を持っているセッションメンバーとそれを持っていない人に共通することを指定します。これがそうでない場合、T_Dither_Maxに異なる計算を使用する参加者は、フィードバックを送信する前に非常に異なる平均待機時間を持つ可能性があり、これは異なるレポートの優先順位に変換されます。たとえば、T_RR = 1 sおよびRTT = 100ミリ秒のシナリオでは、RTT推定を使用するレシーバーは、平均して使用していないフィードバックよりも多くのフィードバックを送信します。これは、フィードバック抑制メカニズムを部分的にキャンセルし、フィードバックの爆発さえ引き起こす可能性があります。また、損失が共有される一般的なケースでは、各受信機からのフィードバックパケットが計算されたT_Dither_max秒前に他のそれぞれに到達するのに十分な時間がある場合、フィードバック抑制メカニズムが機能することに注意してください。したがって、非常に高い帯域幅（小さなT_RR）のシナリオでは、計算されたt_dither_maxは受信機間の伝播遅延よりもはるかに小さい可能性があり、これはフィードバック抑制メカニズムの障害に変換されます。これらの場合、1つの解決策は、受信機が使用できる帯域幅を制限することです（[10]を参照）、これが発生しないようにします。別の解決策は、送信者間のRTT推定に基づいて、フィードバック抑制のメカニズムを開発することです。これはここでは議論されず、別の文書の主題である可能性があります。ただし、非常に高い帯域幅メディアストリームは、そもそもこの種のエラー修復に依存する可能性が低いことに注意してください。
In the following, we define three representative sample scenarios. We use the topology from the previous section, T-16. Most of the agents contribute only little to the simulations, because we introduced an error rate only on the link between the sender A1 and the agent A2.
以下では、3つの代表的なサンプルシナリオを定義します。前のセクションT-16のトポロジーを使用します。エージェントのほとんどは、Sender A1とエージェントA2の間のリンクにのみエラー率を導入したため、シミュレーションにはほとんど貢献しません。
The first scenario represents those cases, where losses are shared between two agents. One agent is located upstream on the path between the other agent and the sender. Therefore, agent A2 and agent A5 see the same losses that are introduced on the link between the sender and agent A2. Agents A6, A7, and A8 do not join the RTP session. From the other agents, only agents A3 and A9 join. All agents are pure receivers, except A1, which is the sender.
最初のシナリオは、2つのエージェント間で損失が共有されるケースを表しています。1人のエージェントは、他のエージェントと送信者の間のパス上に上流に配置されます。したがって、エージェントA2とエージェントA5は、送信者とエージェントA2の間のリンクに導入された同じ損失を表示します。エージェントA6、A7、およびA8はRTPセッションに参加しません。他のエージェントから、エージェントA3とA9のみが結合します。すべてのエージェントは、送信者であるA1を除き、純粋なレシーバーです。
The second scenario also represents cases where losses are shared between two agents, but this time the agents are located on different branches of the multicast tree. The delays to the sender are roughly of the same magnitude. Agents A5 and A6 share the same losses. Agents A3 and A9 join the RTP session, but are pure receivers and do not see any losses.
2番目のシナリオは、2つのエージェント間で損失が共有される場合も表しますが、今回はエージェントはマルチキャストツリーの異なるブランチにあります。送信者への遅延は、ほぼ同じ大きさです。エージェントA5とA6は同じ損失を共有しています。エージェントA3とA9はRTPセッションに参加しますが、純粋な受信機であり、損失は見られません。
Finally, in the third scenario, the losses are shared between two agents, A5 and A6. The same agents as in the second scenario are active. However, the delays of the links are different. The delay of the link between agents A2 and A5 is reduced to 20 ms and between A2 and A6 to 40 ms.
最後に、3番目のシナリオでは、2つのエージェント、A5とA6の間で損失が共有されます。2番目のシナリオと同じエージェントがアクティブです。ただし、リンクの遅延は異なります。エージェントA2とA5間のリンクの遅延は、A2とA6〜40ミリ秒の間で20ミリ秒に減少します。
All agents beside agent A1 are pure RTP receivers. Thus, these agents do not have an RTT estimation to the source. T_dither_max is calculated with the above given formula, depending only on T_rr and l, which means that all agents should calculate roughly the same T_dither_max.
エージェントA1の横にあるすべてのエージェントは、純粋なRTPレシーバーです。したがって、これらのエージェントはソースにRTT推定を持っていません。t_dither_maxは、T_RRとLのみに依存する上記の式で計算されます。つまり、すべてのエージェントはほぼ同じT_Dither_maxを計算する必要があります。
The feedback suppression rate for an agent is defined as the ratio of the total number of feedback packets not sent out of the total number of feedback packets the agent intended to send (i.e., the sum of sent and not sent). The reasons for not sending a packet include: the receiver already saw the same loss reported in a receiver report coming from another session member or the max_feedback_delay (application-specific) was surpassed.
エージェントのフィードバック抑制率は、エージェントが送信するフィードバックパケットの総数（つまり、送信された送信と送信されない合計）から送信されないフィードバックパケットの総数の比として定義されます。パケットを送信しない理由は次のとおりです。レシーバーは、別のセッションメンバーからのレシーバーレポートで報告されているのと同じ損失をすでに見たか、MAX_FEEDBACK_DELAY（アプリケーション固有）を超えました。
The results for the feedback suppression rate of the agent Af that is further away from the sender are depicted in Table 5. In general, it can be seen that the feedback suppression rate increases as l increases. However there is a threshold, depending on the environment, from which the additional gain is not significant anymore.
送信者から遠く離れたエージェントAFのフィードバック抑制率の結果を表5に示します。一般に、Lが増加するにつれてフィードバック抑制率が増加することがわかります。ただし、環境に応じてしきい値があり、そこから追加のゲインはもはや重要ではありません。
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.671 | 0.051 | 0.089 |
| 0.25 | 0.582 | 0.060 | 0.210 |
| 0.50 | 0.524 | 0.114 | 0.361 |
| 0.75 | 0.523 | 0.180 | 0.370 |
| 1.00 | 0.523 | 0.204 | 0.369 |
| 1.25 | 0.506 | 0.187 | 0.372 |
| 1.50 | 0.536 | 0.213 | 0.414 |
| 1.75 | 0.526 | 0.215 | 0.424 |
| 2.00 | 0.535 | 0.216 | 0.400 |
| 3.00 | 0.522 | 0.220 | 0.405 |
| 4.00 | 0.522 | 0.220 | 0.405 |
Table 5: Fraction of feedback that was suppressed at agent (Af) of the total number of feedback messages the agent wanted to send
表5：エージェントが送信したいフィードバックメッセージの総数のエージェント（AF）で抑制されたフィードバックの割合
Similar results can be seen in Table 6 for the agent An that is nearer to the sender.
エージェントANの表6には、送信者に近い場合も同様の結果が見られます。
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.056 | 0.056 | 0.090 |
| 0.25 | 0.063 | 0.055 | 0.166 |
| 0.50 | 0.116 | 0.099 | 0.255 |
| 0.75 | 0.141 | 0.141 | 0.312 |
| 1.00 | 0.179 | 0.175 | 0.352 |
| 1.25 | 0.206 | 0.176 | 0.361 |
| 1.50 | 0.193 | 0.193 | 0.337 |
| 1.75 | 0.197 | 0.204 | 0.341 |
| 2.00 | 0.207 | 0.207 | 0.368 |
| 3.00 | 0.196 | 0.203 | 0.359 |
| 4.00 | 0.196 | 0.203 | 0.359 |
Table 6: Fraction of feedback that was suppressed at agent (An) of the total number of feedback messages the agent wanted to send
表6：エージェントが送信したいフィードバックメッセージの総数のエージェント（an）で抑制されたフィードバックの割合
The rate of feedback suppression failure is depicted in Table 7. The trend of additional performance increase is not significant beyond a certain threshold. Dependence on the scenario is noticeable here as well.
フィードバック抑制障害の速度を表7に示します。追加のパフォーマンスの増加の傾向は、特定のしきい値を超えて有意ではありません。ここでもシナリオへの依存が顕著です。
| |Feedback Suppr. Failure Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.273 | 0.893 | 0.822 |
| 0.25 | 0.355 | 0.885 | 0.624 |
| 0.50 | 0.364 | 0.787 | 0.385 |
| 0.75 | 0.334 | 0.679 | 0.318 |
| 1.00 | 0.298 | 0.621 | 0.279 |
| 1.25 | 0.289 | 0.637 | 0.267 |
| 1.50 | 0.274 | 0.595 | 0.249 |
| 1.75 | 0.274 | 0.580 | 0.235 |
| 2.00 | 0.258 | 0.577 | 0.233 |
| 3.00 | 0.282 | 0.577 | 0.236 |
| 4.00 | 0.282 | 0.577 | 0.236 |
Table 7: The ratio of feedback suppression failures.
表7：フィードバック抑制障害の比率。
Summarizing the feedback suppression results, it can be said that in general the feedback suppression performance increases as l increases. However, beyond a certain threshold, depending on environment parameters such as propagation delays or session bandwidth, the additional increase is not significant anymore. This threshold is not uniform across all scenarios; a value of l=0.5 seems to produce reasonable results with acceptable (though not optimal) overhead.
フィードバック抑制の結果を要約すると、一般に、Lが増加するにつれてフィードバック抑制性能が増加すると言えます。ただし、伝播遅延やセッション帯域幅などの環境パラメーターに応じて、特定のしきい値を超えて、追加の増加はもはや重要ではありません。このしきい値は、すべてのシナリオで均一ではありません。l = 0.5の値は、容認できる（最適ではない）オーバーヘッドを伴う合理的な結果を生成するようです。
In this section, we show the results for the measured report delay during the simulations of the three sample scenarios. This measurement is a metric of the performance of the algorithms, because the value of the feedback for the sender typically decreases with the delay of its reception. The loss report delay is measured as the time at the sender between sending a packet and receiving the first corresponding loss report.
このセクションでは、3つのサンプルシナリオのシミュレーション中の測定されたレポート遅延の結果を示します。この測定は、送信者のフィードバックの値が通常、受信の遅延とともに減少するため、アルゴリズムのパフォーマンスのメトリックです。損失レポートの遅延は、パケットの送信と最初の対応する損失レポートを受信する間の送信者の時間として測定されます。
| | Mean Loss Report Delay |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.124 | 0.282 | 0.210 |
| 0.25 | 0.168 | 0.266 | 0.234 |
| 0.50 | 0.243 | 0.264 | 0.284 |
| 0.75 | 0.285 | 0.286 | 0.325 |
| 1.00 | 0.329 | 0.305 | 0.350 |
| 1.25 | 0.351 | 0.329 | 0.370 |
| 1.50 | 0.361 | 0.363 | 0.388 |
| 1.75 | 0.360 | 0.387 | 0.392 |
| 2.00 | 0.367 | 0.412 | 0.400 |
| 3.00 | 0.368 | 0.507 | 0.398 |
| 4.00 | 0.368 | 0.568 | 0.398 |
Table 8: The mean loss report delay, measured at the sender.
表8：送信者で測定された平均損失報告遅延。
As can be seen from Table 8, the delay increases, in general, as l increases. Also, a similar effect as for the feedback suppression performance is present: beyond a certain threshold, the additional increase in delay is not significant anymore. The threshold is environment dependent and seems to be related to the threshold, where the feedback suppression gain would not increase anymore.
表8からわかるように、Lが増加するにつれて遅延が増加します。また、フィードバック抑制パフォーマンスと同様の効果が存在します。特定のしきい値を超えて、遅延の追加の増加はもはや重要ではありません。しきい値は環境に依存しており、フィードバック抑制ゲインがもはや増加しないしきい値に関連しているようです。
We have shown experimentally that the performance of the feedback suppression mechanisms increases as l increases. The same applies for the report delay, which also increases as l increases. This leads to a threshold where both the performance and the delay do not increase any further. The threshold is dependent upon the environment.
フィードバック抑制メカニズムのパフォーマンスがLが増加するにつれて増加することを実験的に示しました。レポート遅延にも同じことが当てはまります。これは、Lが増加するにつれて増加します。これは、パフォーマンスと遅延の両方がそれ以上増加しないしきい値につながります。しきい値は環境に依存します。
So finding an optimum value of l is not possible because it is always a trade-off between delay and feedback suppression performance. With l=0.5, we think that a trade-off was found that is acceptable for typical applications and environments.
したがって、Lの最適な値を見つけることは不可能です。これは、遅延とフィードバック抑制パフォーマンスの間のトレードオフであるため、不可能です。L = 0.5では、典型的なアプリケーションと環境では受け入れられるトレードオフが見つかったと考えています。
NEWPRED is one of the error resilience tools, which is defined in both ISO/IEC MPEG-4 visual part and ITU-T H.263. NEWPRED achieves fast error recovery using feedback messages. We simulated the behavior of NEWPRED in the network simulator environment as described above and measured the waiting time statistics, in order to verify that the extended RTP profile for RTCP-based feedback (AVPF) [1] is appropriate for the NEWPRED feedback messages. Simulation results, which are presented in the following sections, show that the waiting time is small enough to get the expected performance of NEWPRED.
NewPredは、ISO/IEC MPEG-4 Visual PartとITU-T H.263の両方で定義されているエラーレジリエンスツールの1つです。NewPredは、フィードバックメッセージを使用して高速エラー回復を実現します。上記のようにネットワークシミュレーター環境でのNewPREDの動作をシミュレートし、RTCPベースのフィードバック（AVPF）[1]の拡張RTPプロファイルがNewPredフィードバックメッセージに適していることを確認するために、待機時間統計を測定しました。次のセクションで提示されているシミュレーション結果は、新しいプレッドの予想されるパフォーマンスを得るのに十分な時間が小さいことを示しています。
The agent that performs the NEWPRED functionality, called NEWPRED agent, is different from the RTP agent we described above. Some of the added features and functionalities are described in the following points:
NewPredエージェントと呼ばれるNewPred機能を実行するエージェントは、上記のRTPエージェントとは異なります。追加された機能と機能のいくつかは、次のポイントで説明されています。
Application Feedback The "Application Layer Feedback Messages" format is used to transmit the NEWPRED feedback messages. Thereby the NEWPRED functionality is added to the RTP agent. The NEWPRED agent creates one NACK message for each lost segment of a video frame, and then assembles multiple NACK messages corresponding to the segments in the same video frame into one Application Layer Feedback Message. Although there are two modes, namely, NACK mode and ACK mode, in NEWPRED [6][7], only NACK mode is used in these simulations. In this simulation, the RTP layer doesn't generate feedback messages. Instead, the decoder (NEWPRED) generates a NACK message when the segment cannot be decoded because the data hasn't arrived or loss of reference picture has occurred. Those conditions are detected in the decoder with frame number, segment number, and existence of reference pictures in the decoder.
アプリケーションフィードバック「アプリケーションレイヤーフィードバックメッセージ」形式は、NewPredフィードバックメッセージを送信するために使用されます。これにより、NewPred機能がRTPエージェントに追加されます。NewPredエージェントは、ビデオフレームの失われた各セグメントに対して1つのNACKメッセージを作成し、同じビデオフレーム内のセグメントに対応する複数のNACKメッセージを1つのアプリケーションレイヤーフィードバックメッセージに組み立てます。NewPred [6] [7]では、NACKモードとACKモード、つまりNACKモードとACKモードの2つのモードがありますが、これらのシミュレーションではNACKモードのみが使用されます。このシミュレーションでは、RTPレイヤーはフィードバックメッセージを生成しません。代わりに、データが到着していないか、参照画像の損失が発生したためにセグメントをデコードできない場合、デコーダー（newPred）はNACKメッセージを生成します。これらの条件は、フレーム番号、セグメント番号、およびデコーダー内の参照画像の存在を備えたデコーダーで検出されます。
The parameters of NEWPRED agent are as follows:
New -Predエージェントのパラメーターは次のとおりです。
f: Frame Rate(frames/sec)
seg: Number of segments in one video frame
bw: RTP session bandwidth(kbps)
Generation of NEWPRED's NACK Messages The NEWPRED agent generates NACK messages when segments are lost.
NewPredのNACKメッセージの生成ニュープレッドエージェントは、セグメントが失われたときにNACKメッセージを生成します。
a. The NEWPRED agent generates multiple NACK messages per one video frame when multiple segments are lost. These are assembled into one Feedback Control Information (FCI) message per video frame. If there is no lost segment, no message is generated and sent.
a. NewPredエージェントは、複数のセグメントが紛失したときに1つのビデオフレームごとに複数のNACKメッセージを生成します。これらは、ビデオフレームごとに1つのフィードバック制御情報（FCI）メッセージに組み立てられます。失われたセグメントがない場合、メッセージが生成されて送信されません。
b. The length of one NACK message is 4 bytes. Let num be the number of NACK messages in one video frame (1 <= num <= seg). Thus, 12+4*num bytes is the size of the low-delay RTCP feedback message in a compound RTCP packet.
b. 1つのNACKメッセージの長さは4バイトです。numを1つのビデオフレーム（1 <= num <= seg）のNACKメッセージの数とします。したがって、12 4*numバイトは、化合物RTCPパケット内の低遅延RTCPフィードバックメッセージのサイズです。
Measurements We defined two values to be measured:
測定測定する2つの値を定義しました。
- Recovery time The recovery time is measured as the time between the detection of a lost segment and reception of a recovered segment. We measured this "recovery time" for each lost segment.
- 回復時間回復時間は、失われたセグメントの検出と回収されたセグメントの受信の間の時間として測定されます。失われたセグメントごとにこの「回復時間」を測定しました。
- Waiting time The waiting time is the additional delay due to the feedback limitation of RTP.
- 待機時間待機時間は、RTPのフィードバック制限による追加の遅延です。
Figure 2 depicts the behavior of a NEWPRED agent when a loss occurs.
図2は、損失が発生したときの新しいプレッドエージェントの動作を示しています。
The recovery time is approximated as follows:
回復時間は次のように近似されます。
(Recovery time) = (Waiting time) +
(Transmission time for feedback message) +
(Transmission time for media data)
Therefore, the waiting time is derived as follows:
したがって、待機時間は次のように導き出されます。
(Waiting time) = (Recovery time) - (Round-trip delay), where
(Round-trip delay ) = (Transmission time for feedback message) +
(Transmission time for media data)
Picture Reference |: Picture Segment
____________________ %: Lost Segment
/_ _ _ _ \
v/ \ / \ / \ / \ \
v \v \v \v \ \
Sender ---|----|----|----|----|----|---|------------->
\ \ ^ \
\ \ / \
\ \ / \
\ v / \
\ x / \
\ Lost / \
\ x / \
_____
v x / NACK v
Receiver ---------------|----%===-%----%----%----|----->
|-a-| |
|------- b -------|
a: Waiting time b: Recover time (%: Video segments are lost)
A：待機時間B：回復時間（％：ビデオセグメントが失われます）
Figure 2: Relation between the measured values at the NEWPRED agent
図2：NewPredエージェントの測定値間の関係
We conducted two simulations (Simulation A and Simulation B). In Simulation A, the packets are dropped with a fixed packet loss rate on a link between two NEWPRED agents. In Simulation B, packet loss occurs due to congestion from other traffic sources, i.e., ftp sessions.
2つのシミュレーション（シミュレーションAとシミュレーションB）を実施しました。シミュレーションAでは、2つのNewPredエージェント間のリンクに固定パケット損失率でパケットがドロップされます。シミュレーションBでは、他のトラフィックソースからの輻輳、つまりFTPセッションのためにパケットの損失が発生します。
The network topology used for this simulation is shown in Figure 3.
このシミュレーションに使用されるネットワークトポロジを図3に示します。
Link 1 Link 2 Link 3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ +------+ +------+ +--------+
10(msec) x(msec) 10(msec)
Figure 3: Network topology that is used for Simulation A
図3：シミュレーションに使用されるネットワークトポロジ
Link1 and link3 are error free, and each link delay is 10 msec. Packets may get dropped on link2. The packet loss rates (Plr) and link delay (D) are as follows:
link1とlink3はエラーフリーで、各リンク遅延は10ミリ秒です。パケットはlink2にドロップされる場合があります。パケット損失率（PLR）とリンク遅延（d）は次のとおりです。
D [ms] = {10, 50, 100, 200, 500}
Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}
Session bandwidth, frame rate, and the number of segments are shown in Table 9.
セッション帯域幅、フレームレート、およびセグメントの数を表9に示します。
+------------+----------+-------------+-----+
|Parameter ID| bw(kbps) |f (frame/sec)| seg |
+------------+----------+-------------+-----+
| 32k-4-3 | 32 | 4 | 3 |
| 32k-5-3 | 32 | 5 | 3 |
| 64k-5-3 | 64 | 5 | 3 |
| 64k-10-3 | 64 | 10 | 3 |
| 128k-10-6 | 128 | 10 | 6 |
| 128k-15-6 | 128 | 15 | 6 |
| 384k-15-6 | 384 | 15 | 6 |
| 384k-30-6 | 384 | 30 | 6 |
| 512k-30-6 | 512 | 30 | 6 |
| 1000k-30-9 | 1000 | 30 | 9 |
| 2000k-30-9 | 2000 | 30 | 9 |
+------------+----------+-------------+-----+
Table 9: Parameter sets of the NEWPRED agents
表9：NewPredエージェントのパラメーターセット
Figure 4 shows the key values of the result (packet loss rate vs. mean of waiting time).
図4は、結果の重要な値を示しています（パケット損失率対待機時間の平均）。
When the packet loss rate is 5% and the session bandwidth is 32 kbps, the waiting time is around 400 msec, which is just allowable for reasonable NEWPRED performance.
パケットの損失率が5％で、セッション帯域幅が32 kbpsの場合、待機時間は約400ミリ秒です。これは、合理的な新しいプレッドパフォーマンスには許容されます。
When the packet loss rate is less than 1%, the waiting time is less than 200 msec. In such a case, the NEWPRED allows as much as 200-msec additional link delay.
パケットの損失率が1％未満の場合、待機時間は200ミリ秒未満です。このような場合、NewPredは200 mSecの追加リンク遅延を許可します。
When the packet loss rate is less than 5% and the session bandwidth is 64 kbps, the waiting time is also less than 200 msec.
パケットの損失率が5％未満で、セッション帯域幅が64 kbpsの場合、待機時間も200ミリ秒未満です。
In 128-kbps cases, the result shows that when the packet loss rate is 20%, the waiting time is around 200 msec. In cases with more than 512-kbps session bandwidth, there is no significant delay. This means that the waiting time due to the feedback limitation of RTCP is negligible for the NEWPRED performance.
128 kbpsの場合、結果は、パケットの損失率が20％の場合、待機時間が約200ミリ秒であることを示しています。512 kbpsセッション帯域幅を超える場合、大きな遅延はありません。これは、RTCPのフィードバック制限による待ち時間がNewPredパフォーマンスでは無視できることを意味します。
+------------------------------------------------------------+
| | Packet Loss Rate = |
| Bandwidth | 0.005| 0.01 | 0.02 | 0.03 | 0.05 |0.10 |0.20 |
|-----------+------+------+------+------+------+------+------|
| 32k |130- |200- |230- |280- |350- |470- |560- |
| | 180| 250| 320| 390| 430| 610| 780|
| 64k | 80- |100- |120- |150- |180- |210- |290- |
| | 130| 150| 180| 190| 210| 300| 400|
| 128k | 60- | 70- | 90- |110- |130- |170- |190- |
| | 70| 80| 100| 120| 140| 190| 240|
| 384k | 30- | 30- | 30- | 40- | 50- | 50- | 50- |
| | 50| 50| 50| 50| 60| 70| 90|
| 512k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 60 |
| | | | | | | | |
| 1000k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 55 |
| | | | | | | | |
| 2000k | < 30 | < 30 | < 30 | < 30 | < 30 | < 35 | < 35 |
+------------------+------+------+------+------+------+------+
Figure 4: The result of simulation A
図4：シミュレーションの結果a
The configurations of link1, link2, and link3 are the same as in Simulation A except that link2 is also error-free, regarding bit errors. However, in addition, some FTP agents are deployed to overload link2. See Figure 5 for the simulation topology.
link1、link2、およびlink3の構成は、ビットエラーに関するリンク2もエラーがないことを除いて、シミュレーションAで同じです。ただし、さらに、一部のFTPエージェントは、Link2を過負荷にするために展開されます。シミュレーショントポロジについては、図5を参照してください。
Link1 Link2 Link3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ /|+------+ +------+|\ +--------+
+---+/ | | \+---+
+-|FTP|+---+ +---+|FTP|-+
| +---+|FTP| ... |FTP|+---+ | ...
+---+ +---+ +---+ +---+
FTP Agents FTP Agents
FTPエージェントFTPエージェント
Figure 5: Network Topology of Simulation B
図5：シミュレーションのネットワークトポロジb
The parameters are defined as for Simulation A with the following values assigned:
パラメーターは、次の値が割り当てられたシミュレーションAの場合に定義されます。
D[ms] ={10, 50, 100, 200, 500} 32 FTP agents are deployed at each edge, for a total of 64 FTP agents active.
d [MS] = {10、50、100、200、500} 32 FTPエージェントは、各エッジに展開され、合計64のFTPエージェントがアクティブになります。
The sets of session bandwidth, frame rate, and the number of segments are the same as in Simulation A (Table 9).
セッションの帯域幅、フレームレート、およびセグメントの数のセットは、シミュレーションAの場合と同じです（表9）。
We provide the results for the cases with 64 FTP agents, because these are the cases where packet losses could be detected to be stable. The results are similar to those for Simulation A except for a constant additional offset of 50..100 ms. This is due to the delay incurred by the routers' buffers.
64のFTPエージェントでケースの結果を提供します。これは、パケット損失が安定していることが検出される可能性がある場合です。結果は、50..100ミリ秒の一定の追加オフセットを除き、シミュレーションAの結果と類似しています。これは、ルーターのバッファーによって発生した遅延によるものです。
We have shown that the limitations of RTP AVPF profile do not generate such high delay in the feedback messages that the performance of NEWPRED is degraded for sessions from 32 kbps to 2 Mbps. We could see that the waiting time increases with a decreasing session bandwidth and/or an increasing packet loss rate. The cause of the packet loss is not significant; congestion and constant packet loss rates behave similarly. Still we see that for reasonable conditions and parameters the AVPF is well suited to support the feedback needed for NEWPRED. For more information about NEWPRED, see [8] and [9].
RTP AVPFプロファイルの制限は、NewPredのパフォーマンスが32 kbpsから2 Mbpsのセッションで劣化するというフィードバックメッセージのこのような高い遅延を生成しないことを示しました。セッション帯域幅の減少および/またはパケット損失率の増加とともに、待ち時間が増加することがわかりました。パケット損失の原因は重要ではありません。混雑と一定のパケット損失率も同様に動作します。それでも、合理的な条件とパラメーターのために、AVPFはNewPredに必要なフィードバックをサポートするのに適していることがわかります。NewPredの詳細については、[8]および[9]を参照してください。
The new RTP profile AVPF was investigated regarding performance and potential risks to the network stability. Simulations were conducted using the network simulator ns2, simulating unicast and several differently sized multicast topologies. The results were shown in this document.
新しいRTPプロファイルAVPFは、パフォーマンスとネットワークの安定性に対する潜在的なリスクに関して調査されました。シミュレーションは、ネットワークシミュレーターNS2を使用して実施され、ユニキャストといくつかの異なるサイズのマルチキャストトポロジをシミュレートしました。結果はこのドキュメントに示されています。
Regarding the network stability, it was important to show that the new profile does not lead to any feedback implosion or use more bandwidth than it is allowed. We measured the bandwidth that was used for RTCP in relation to the RTP session bandwidth. We have shown that, more or less exactly, 5% of the session bandwidth is used for RTCP, in all considered scenarios. Other RTCP bandwidth values could be set using the RTCP bandwidth modifiers [10]. The scenarios included unicast with and without errors, differently sized multicast groups, with and without errors or congestion on the links. Thus, we can say that the new profile behaves in a network-friendly manner in the sense that it uses only the allowed RTCP bandwidth, as defined by RTP.
ネットワークの安定性に関しては、新しいプロファイルがフィードバックの破裂につながっていないことを示すことが重要であるか、許可されているよりも多くの帯域幅を使用しないことを示すことが重要でした。RTPセッション帯域幅に関連してRTCPに使用された帯域幅を測定しました。多かれ少なかれ、セッション帯域幅の5％がRTCPに使用され、すべてのシナリオで使用されることを示しました。他のRTCP帯域幅値は、RTCP帯域幅修飾子を使用して設定できます[10]。シナリオには、エラーの有無にかかわらずユニキャスト、異なるサイズのマルチキャストグループ、リンクのエラーや輻輳の有無にかかわらずが含まれていました。したがって、新しいプロファイルは、RTPで定義されているように、許可されたRTCP帯域幅のみを使用するという意味で、ネットワークに優しい方法で動作すると言えます。
Secondly, we have shown that receivers using the new profile experience a performance gain. This was measured by capturing the delay that the sender sees for the received feedback. Using the new profile, this delay can be decreased by orders of magnitude.
第二に、新しいプロファイルを使用してレシーバーがパフォーマンスゲインを体験することを示しました。これは、送信者が受信したフィードバックに対して見た遅延をキャプチャすることによって測定されました。新しいプロファイルを使用すると、この遅延は桁違いに減少する可能性があります。
In the third place, we investigated the effect of the parameter "l" on the new algorithms. We have shown that there does not exist an optimum value for it but only a trade-off can be achieved. The influence of this parameter is highly environment-specific and a trade-off between performance of the feedback suppression algorithm and the experienced delay has to be met. The recommended value of l=0.5 given in this document seems to be reasonable for most applications and environments.
3位では、新しいアルゴリズムに対するパラメーター「L」の効果を調査しました。最適な値は存在しないが、トレードオフのみを達成できることを示しました。このパラメーターの影響は非常に環境固有であり、フィードバック抑制アルゴリズムのパフォーマンスと経験豊富な遅延の間のトレードオフを満たす必要があります。このドキュメントで与えられたL = 0.5の推奨値は、ほとんどのアプリケーションと環境にとって合理的であると思われます。
This document describes the simulation work carried out to verify the correct working of the RTCP timing rules specified in the AVPF profile [1]. Consequently, security considerations concerning these timing rules are described in that document.
このドキュメントでは、AVPFプロファイル[1]で指定されたRTCPタイミングルールの正しい作業を検証するために実行されたシミュレーション作業について説明します。したがって、これらのタイミングルールに関するセキュリティ上の考慮事項は、そのドキュメントで説明されています。
[1] 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, July 2006.
[1] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル」、RFC4585、2006年7月。
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[2] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[3] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[4] Network Simulator Version 2 - ns-2, available from http://www.isi.edu/nsnam/ns.
[4] ネットワークシミュレーターバージョン2 -NS -2、http：//www.isi.edu/nsnam/nsから入手可能。
[5] C. Burmeister, T. Klinner, "Low Delay Feedback RTCP - Timing Rules Simulation Results". Technical Report of the Panasonic European Laboratories, September 2001, available from: http://www.informatik.uni-bremen.de/~jo/misc/ SimulationResults-A.pdf.
[5] C. Burmeister、T。Klinner、「低遅延フィードバックRTCP-タイミングルールシミュレーション結果」。2001年9月、パナソニックヨーロッパ研究所のテクニカルレポート、http：//www.informatik.uni-bremen.de/~jo/misc/ simulationresresults-a.pdfから入手できます。
[6] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part2: Visual", July 2000.
[6] ISO/IEC 14496-2：1999/AMD.1：2000、「情報技術 - 視聴覚オブジェクトのコーディング-Part2：Visual」、2000年7月。
[7] ITU-T Recommendation, H.263. Video encoding for low bitrate communication. 1998.
[7] ITU-Tの推奨、H.263。低ビットレート通信のためのビデオエンコーディング。1998年。
[8] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video Coding by Dynamic Replacing of Reference Pictures", IEEE Global Telecommunications Conference (GLOBECOM), pp.1503-1508, 1996.
[8] S. Fukunaga、T。Nakai、およびH. Inoue、「リファレンス写真の動的置換によるエラーの回復力のあるビデオコーディング」、IEEE Global Telecommunications Conference（Globecom）、pp.1503-1508、1996。
[9] H. Kimata, Y. Tomita, H. Yamaguchi, S. Ichinose, T. Ichikawa, "Receiver-Oriented Real-Time Error Resilient Video Communication System: Adaptive Recovery from Error Propagation in Accordance with Memory Size at Receiver", Electronics and Communications in Japan, Part 1, vol. 84, no. 2, pp.8-17, 2001.
[9] H. Kimata、Y。Tomita、H。Yamaguchi、S。Ichinose、T。Ichikawa、「受信者指向のリアルタイムエラーの回復力のあるビデオ通信システム：レシーバーのメモリサイズに従ってエラー伝播からの適応回復」、電子機器、通信日本、パート1、vol。84、いいえ。2、pp.8-17、2001。
[10] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[10] Casner、S。、「RTPコントロールプロトコル（RTCP）帯域幅のセッション説明プロトコル（SDP）帯域幅修飾子」、RFC 3556、2003年7月。
Authors' Addresses
著者のアドレス
Carsten Burmeister Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Carsten Burmeister Panasonic R＆D CenterドイツGmbh Monzastr。4C D-63225 Langen、ドイツ
EMail: carsten.burmeister@eu.panasonic.com
Rolf Hakenberg Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Rolf Hakenberg Panasonic R＆D CenterドイツGmbh Monzastr。4C D-63225 Langen、ドイツ
EMail: rolf.hakenberg@eu.panasonic.com
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
明氏宮崎matsushita Electric Industrial Co.、Ltd 1006、Kadoma、Kadoma City、大阪、日本
EMail: miyazaki.akihiro@jp.panasonic.com
Joerg Ott Helsinki University of Technology, Networking Laboratory PO Box 3000, 02015 TKK, Finland
Joerg Ott Helsinki工科大学、ネットワーキング研究所PO Box 3000、02015 TKK、フィンランド
EMail: jo@acm.org
Noriyuki Sato Oki Electric Industry Co., Ltd. 1-16-8 Chuo, Warabi, Saitama 335-8510 Japan
Noriyuki oki Electric Industry Co.、Ltd。1-16-8 Chuo、Warabi、Saitama 335-8510 Japan
EMail: sato652@oki.com
Shigeru Fukunaga Oki Electric Industry Co., Ltd. 2-5-7 Hommachi, Chuo-ku, Osaka 541-0053 Japan
Shigeru Fukunaga Oki Electric Industry Co.、Ltd。2-5-7 Hommachi、Chuo-Ku、Osaka 541-0053 Japan
EMail: fukunaga444@oki.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。