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
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).
著作権（C）インターネット協会（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.
この文書では、リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバックのための拡張RTPプロファイルのタイミングルールをシミュレートしたときに達成された結果を説明し、AVPFを表します。ユニキャストとマルチキャストトポロジを考慮だけでなく、いくつかのプロトコルと環境構成されています。結果は、タイミング規則はフィードバック遅延に関するパフォーマンスが向上し、まだ制御トラフィックに対する許容ビットレートに関して広く受け入れられ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とRTCPのためのアルゴリズムのほとんどを保持して新しい拡張RTPプロファイルを作成することを決めました。新規則は、ユニキャストからユニキャストまたは小規模マルチキャストアプリケーションはそれから最も利得を持つマルチキャストに拡張する必要があります。新しいプロファイルとそのタイミング規則の詳細な説明は、[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節では、アルゴリズムの性能に（T_dither_max値を計算するために使用される）、パラメータ「L」の効果を調査し、そして最後に、第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パケットは、少なくとも一つの送信者レポート（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.
- 同じソースから二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.
私たちは、これらのルールは、フィードバック爆発を防止し、大規模なマルチキャストグループにうまくスケールすることを参照してください。しかし、彼らがすべてでタイムリーなフィードバックを許可していません。第二の規則は小グループまたはユニキャスト（このケースでは間隔は数ミリ秒ほど小さいかもしれない）にも比例しながら、第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.
タイミング規則は、[1]二つの主要コンポーネントで構成さ新しいRTPプロファイルからのRTCPフィードバックを送信します。まず、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スクリプトで定義されています。私たちは、最大25人のセッションメンバーにマルチキャストするために、2人のセッションメンバーでユニキャストに至るまで、いくつかの異なるトポロジを設定します。使用送信レートと対応するリンクの帯域幅に応じて、渋滞損失が発生する可能性があります。いくつかのシナリオでは、ビットエラーが特定のリンクに挿入されています。私たちは、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つのトポロジはT-8、T-4、T-2、すなわち、参加RTPエージェントの数にちなんで名付けられ、そして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
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タイミング規則と同様に振る舞います。それは一般的に、より頻繁なフィードバックを有することが良いですが、即ち、総RTP帯域幅の5％RTPによれば、固定された限界を超えRTCPのために使用されるビットレートを増加させるために全く許されません。このセクションでは、新しいタイミング規則は、すべての調査のシナリオ、トポロジ、およびグループサイズのため、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およびその他の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秒の最小間隔を使用します。早期のフィードバックを送信する必要が与えられていないので、何早期のパケットは、送信されません。それでもセッション帯域幅の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.
我々は両方のエージェントが使用する構成で、新たなタイミングは、それらの各ルールていることがわかります使用して、最大で、両方のセッション帯域幅の5％までの合計RTPのセッション帯域幅の約2.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.
私たちの第二のユニキャストの実験では、我々は許可されRTCP帯域幅の共有はパケットロスが発生しても、超えていないことを示しています。当社は、リンク上の一定のバイトエラーレート（バイエル）をシミュレートしました。バイトエラーは一様分布に従ってランダムに挿入されています。
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]、ユニキャストT_dither_maxに常にゼロであるallow_earlyが真である場合、したがって早期パケットを直ちに送信することができます。最後のパケットがすでに初期の1（すなわち、allow_early =偽）だった場合は、フィードバックは、次の定期的にスケジュール受信レポートに追加される可能性があります。それが許可されている場合（私たちは私たちのシミュレーションでは1秒に設定）max_feedback_delayパラメータが決定されます。
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.
結果は、我々は損失が発生したか否か、RTCP帯域幅シェアの差がないことがわかります。表2に示されています。 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ビットレートシェアは、いくつかの送信者と低ビットレートのシナリオで16人のセッションメンバー（セッション帯域幅= 20 kbpsの）のシミュレーションのセッション帯域幅の5.06パーセントです。損失なしに、他のすべてのシナリオでは、使用されるRTCPビットレートシェアは、以下です。従って、セッション・ビット・レートの5％以下がRTCPのために使用されなければならない要件は、合理的な精度で満たされます。
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％ルールは、（RTCPのために使用されるセッション帯域幅の最大5.07パーセントで）維持されます。
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キューを使用しました。ランダム早期検出（RED）のキューのパケットロスのバースト性が低下するおそれがあるため、パフォーマンスを向上させることができます。しかし、これは私たちの調査の対象ではありませんが、今後の研究のために残されています。また、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）と、送信された抑制、または許可されていませんフィードバックパケットの数「の時間を待っている意味」です。待ち時間は、パケット損失イベントの検出及び対応するフィードバックが送信される時間の間、特定のエージェントで測定された時間、です。フィードバックの値はその遅れに伴って減少すると仮定すると、私たちは、平均待ち時間は、私たちがAVPF代わりのAVPを使用することによって得ることができ、パフォーマンスゲインを測定するための良いメトリックであると思います。
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）を示します。送信されるか、または破棄され、フィードバックパケットの数は、（フィードバック送信（送信）またはフィードバック廃棄（ディスク））にも記載されています。ユニキャストの場合のためにフィードバック抑制が適用されませんので、我々は、抑制のパケットは表示されません。シミュレーションでは、エージェント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.
上記の表から、我々は平均待ち時間がAVPF代わりのAVPを使用することによって劇的に減少させることができることを参照してください。 AVPを使用してエージェントのための待ち時間は常に約2.5秒（半分の最小間隔の平均）であるが、それはAVPF構成のほとんどは数ミリ秒に減少させることができます。
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.
これらのシナリオは、理由はフィードバック抑制アルゴリズムで特に興味深いです。すべての受信機が同じ損失を共有する場合、それらの一つが損失レポートを送信することが必要なだけです。部材は、それが送信されるようにスケジュールしている同じ内容でフィードバックを受信した場合従って、スケジュールフィードバックを抑制する。もちろん、この抑制フィードバックは、平均待ち時間には寄与しません。確率は受信機の一つは、多かれ少なかれ、すぐにフィードバックを送ることができるという高いので、だから我々は、共有の損失の減少した待ち時間を期待しています。結果を以下の表に示されています。
| | 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.,
表4は、大規模なグループサイズのシミュレーションのためのフィードバック統計を示しています。トポロジーT-16のすべての16個のエージェントは、RTPセッションに参加しました。しかし、唯一のエージェントA1は、RTP送信者として機能します。他の薬剤は、純粋なレシーバーです。わずか4または5の薬剤、すなわち、パケット損失に苦しみます、
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.
分散損失の場合の共有の損失と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倍で受信され、その結果、失われた）、冗長フィードバックの大部分が抑制されました。 3250個体がフィードバックの60％以上が実際に抑制されたことを意味し、損失を検出することであるから、2023損失レポートは抑制されました。
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値は、L = 0.5で、T_dither_max =のL * T_rrとして算出されます。この理論的根拠は、受信機が何のラウンドトリップ時間（RTT）の推定を持っていない場合は、一般的に、それは他の受信機がフィードバックを送信するためにどのくらい待つべきであるかを知らない、ということです。選択した時間が短すぎる場合、フィードバック抑制アルゴリズムは確かに失敗していました。ただし、待ち時間が不必要に増大する（したがって、フィードバックの値が減少する）場合に選択された値が大きすぎます。理想的には、最適な時間値は、それぞれの場合のために見つけることができますが、これは必ずしも現実的ではありません。最適な時間が使用されていない一方、それは危険ではありません。減少したフィードバック値とフィードバック抑制機構の障害はネットワークの安定性を傷つけることはありません。私たちは、全体的な帯域幅の制約がどのような場合に保管されているので、我々は唯一の誤った時刻値を選択することで、いくつかのパフォーマンスを失う可能性があり、分散損失の例のために示されています。一方、T_dither_maxのための良好な尺度は、RTCP間隔T_rrです。この値は、セッションメンバーの数とともに増加します。また、我々は、少なくともすべてのT_rrフィードバックを送ることができることを知っています。したがって、T_rr超えT_dither最大を増やすことは、確かに意味をなさないでしょう。だから、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秒とRTT = 100msのシナリオでは、RTT推定を用いて受信機は、平均して、それを使用しないものよりもより多くのフィードバックを送信することになります。これは、部分的にフィードバック抑制機構を相殺しても、フィードバック爆縮を引き起こす可能性があります。また、各受信機からのフィードバックパケットが計算さT_dither_max秒前に他のもののそれぞれに到達するための十分な時間を持っている場合、損失が共有されている一般的なケースでは、フィードバック抑制機構が働く、ということに注意してください。したがって、非常に高い帯域幅（小T_rr）のシナリオでは、計算されたT_dither_maxフィードバック抑制機構の故障につながることになる受信機との間の伝搬遅延よりもはるかに小さくなり得ます。これらの場合、一つの解決策は、（[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からトポロジを使用しています。我々は唯一の送信者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.
最初のシナリオでは、損失は二つの薬剤の間で共有されているような場合を表します。一つ剤を他の薬剤と送信者との間のパス上の上流に配置されています。そのため、エージェント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のシナリオでは、損失は二つの薬剤、A5およびA6の間で共有されています。第2のシナリオと同様剤が活性です。ただし、リンクの遅延が異なっています。エージェントA2とA5の間のリンクの遅延は、40ミリ秒、20ミリおよびA2とA6の間に低減されます。
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_dither_maxを計算する必要があることを意味し、T_rr及びLのみによって、上記の式を用いて計算されます。
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.
同様の結果は送信者に近い方である薬剤アンについては、表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 = 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ビジュアル部分とITU-T H.263の両方に定義されているエラー耐性ツールの一つです。 NEWPREDは、フィードバックメッセージを使用して高速なエラーリカバリを実現しています。我々は、上記のようにネットワークシミュレータ環境でNEWPREDの挙動をシミュレートし、RTCPベースのフィードバック（AVPF）のための拡張RTPプロファイル[1] NEWPREDフィードバックメッセージのために適切であることを確認するために、待機時間の統計を測定しました。次のセクションで説明されているシミュレーション結果は、待機時間が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メッセージを作成し、1つのApplication層フィードバックメッセージに同じビデオフレーム内のセグメントに対応する複数のNACKメッセージを組み立てます。 [6] [7]、のみNACKモードはこれらのシミュレーションで使用されNEWPRED 2つのモード、すなわち、NACKモード、ACKモード、があるが。このシミュレーションでは、RTP層は、フィードバックメッセージを生成しません。その代わりに、デコーダ（NEWPRED）は、データが到着していないか、参照ピクチャの損失が発生しているため、セグメントを復号することができないNACKメッセージを生成します。これらの条件は、フレーム番号、セグメント番号、およびデコーダにおける参照画像の有無と復号器で検出されます。
The parameters of NEWPRED agent are as follows:
次のようにNEWPREDエージェントのパラメータは次のとおりです。
f: Frame Rate(frames/sec) seg: Number of segments in one video frame bw: RTP session bandwidth(kbps)
F：フレームレート（フレーム/秒）SEG：1本のビデオフレームBWのセグメント数：RTPセッション帯域幅（kbps単位）
Generation of NEWPRED's NACK Messages The NEWPRED agent generates NACK messages when segments are lost.
セグメントが失われたときにNEWPREDのNACKメッセージの生成NEWPREDエージェントは、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メッセージを生成します。これらは、ビデオフレームごとにフィードバック制御情報（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にNEWPRED剤の挙動を示します。
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)
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において、パケットは、二つ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：シミュレーションAのために使用されるネットワーク・トポロジ
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:
リンク1とLINK3はエラーフリーであり、各リンクの遅延は10ミリ秒です。パケットは、リンク2上にドロップことがあります。次のようにパケット損失率（PLR）とリンク遅延（D）です。
D [ms] = {10, 50, 100, 200, 500} Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}
D [ミリ秒] = {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の場合は、待機時間は、合理的なNEWPREDパフォーマンスのためだけに許容されており、約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ミリ秒の追加のリンク遅延限り可能にします。
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.
リンク1、リンク2、およびLINK3の構成は、LINK2以外シミュレーションAと同じであるビットエラーについてもエラーフリーです。しかし、加えて、一部のFTPエージェントは、リンク2をオーバーロードするために展開されています。シミュレーショントポロジについては、図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、MSの一定のオフセットの追加を除いてシミュレーション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のパフォーマンスは2 Mbpsに32 kbpsのからのセッションのために分解されるフィードバックメッセージでこのような高い遅延が発生しないことを示しました。私たちは、待ち時間が減少セッション帯域幅および/または増加し、パケット損失率で増加することを見ることができました。パケットロスの原因は重要ではありません。混雑して一定のパケットロス率も同様に振る舞います。それでも我々は、合理的な条件やパラメータのための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.
第三に、我々は、新しいアルゴリズムのパラメータ「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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ、「リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル-Basedフィードバック（RTP / AVPF） 」、RFC 4585、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.、フレデリック、R.、およびV.ヤコブソン、 "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 - タイミングルールのシミュレーション結果"。 http://www.informatik.uni-bremen.de/~jo/misc/ SimulationResults-A.pdf：から入手パナソニックヨーロッパの研究所の技術報告書、2001年9月、。
[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：/ Amd.1 1999：2000、 "情報技術 - オーディオビジュアルオブジェクトのコーディング - パート2：ビジュアル"、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.福永、T.中井、およびH.井上、 "参考写真の交換、動的による誤り耐性動画像の符号化方式"、IEEEグローバル電気通信会議（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.木全、Y.富田、H.山口、S.一ノ瀬、T.市川、「レシーバー指向リアルタイムエラー弾力ビデオコミュニケーションシステム：適応回復受信機でのメモリサイズに応じてエラー伝播から」、日本における電子情報通信、パート1巻。 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.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、RFC 3556、2003年7月。
Authors' Addresses
著者のアドレス
Carsten Burmeister Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
カーステンBurmeisterパナソニックR＆DセンタードイツGmbH社Monzastr。図4c D-63225ランゲン、ドイツ
EMail: carsten.burmeister@eu.panasonic.com
メールアドレス：carsten.burmeister@eu.panasonic.com
Rolf Hakenberg Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ロルフHakenbergパナソニックR＆DセンタードイツGmbH社Monzastr。図4c D-63225ランゲン、ドイツ
EMail: rolf.hakenberg@eu.panasonic.com
メールアドレス：rolf.hakenberg@eu.panasonic.com
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
あきひろ みやざき まつした えぇｃｔりｃ いんづｓｔりあｌ こ。、 Ｌｔｄ １００６、 かどま、 かどま しｔｙ、 おさか、 じゃぱん
EMail: miyazaki.akihiro@jp.panasonic.com
メールアドレス：miyazaki.akihiro@jp.panasonic.com
Joerg Ott Helsinki University of Technology, Networking Laboratory PO Box 3000, 02015 TKK, Finland
テクノロジーのイェルクオットヘルシンキ大学、ネットワーキング研究所私書箱3000、02015 TKK、フィンランド
EMail: jo@acm.org
メールアドレス：jo@acm.org
Noriyuki Sato Oki Electric Industry Co., Ltd. 1-16-8 Chuo, Warabi, Saitama 335-8510 Japan
のりゆき さと おき えぇｃｔりｃ いんづｓｔｒｙ こ。、 Ｌｔｄ。 １ー１６ー８ ちゅお、 わらび、 さいたま ３３５ー８５１０ じゃぱん
EMail: sato652@oki.com
メールアドレス：sato652@oki.com
Shigeru Fukunaga Oki Electric Industry Co., Ltd. 2-5-7 Hommachi, Chuo-ku, Osaka 541-0053 Japan
しげる ふくなが おき えぇｃｔりｃ いんづｓｔｒｙ こ。、 Ｌｔｄ。 ２ー５ー７ ほっまち、 ちゅおーく、 おさか ５４１ー００５３ じゃぱん
EMail: fukunaga444@oki.com
メールアドレス：fukunaga444@oki.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。