RFC4586 日本語訳
4586 Extended RTP Profile for Real-time Transport Control Protocol(RTCP)-Based Feedback: Results of the Timing Rule Simulations. C.Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga. July 2006. (Format: TXT=66759 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループC.バーマイスター要求をネットワークでつないでください: 4586年のR.Hakenbergカテゴリ: 技術N.佐藤S.Fukunaga Oki2006年7月の情報のA.宮崎パナソニックJ.オットヘルシンキ大学
Extended RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback:
Results of the Timing Rule Simulations
拡張RTPはリアルタイムの輸送制御プロトコルのために(RTCP)ベースのフィードバックの輪郭を描きます: タイミング規則シミュレーションの結果
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)インターネット協会(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.
このドキュメントはレアル-時間Transport Controlプロトコル(RTCP)のベースのFeedbackのためにExtended RTP Profileのタイミング規則をシミュレートするとき獲得された結果について説明します、とAVPFが指示しました。 また、ユニキャストとマルチキャストtopologiesはいくつかのプロトコルと環境構成であるとみなされます。 結果は、タイミング規則がフィードバック遅れに関する、より良い性能をもたらすのを案内して、まだ許容ビット伝送速度に関するよく受け入れられたRTP規則をコントロール交通として保存しています。
Burmeister, et al. Informational [Page 1] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[1ページ]のRFC4586
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
1. 序論…3 2. RTCPベースのフィードバックのための拡張RTPプロフィールのタイミング規則…4 3. シミュレーション環境…5 3.1. シミュレータバージョン2をネットワークでつないでください…5 3.2. RTPエージェント…5 3.3. シナリオ…5 3.4. Topologies…6 4. RTCPビット伝送速度測定値…6 4.1. ユニキャスト…7 4.2. マルチキャスト…10 4.3. RTCPビット伝送速度測定値の概要…10 5. フィードバック測定値…11 5.1. ユニキャスト…11 5.2. マルチキャスト…12 5.2.1. 分配された損失に対して損失を分担します…13 6. 「l」における調査…14 6.1. フィードバック抑圧パフォーマンス…16 6.2. 損害報告遅れ…18 6.3. 「l」調査の概要…18 7. AVPFを使用するアプリケーション…19 7.1. NS2でのNEWPRED実現…19 7.2. シミュレーション…21 7.2.1. シミュレーションA--一定のパケット損失率…21 7.2.2. シミュレーションB--混雑によるパケットの損失…23 7.3. アプリケーションシミュレーションの概要…24 8. 概要…24 9. セキュリティ問題…25 10. 標準の参照…26 11. 有益な参照…26
Burmeister, et al. Informational [Page 2] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[2ページ]のRFC4586
1. Introduction
1. 序論
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).
レアル-時間Transportプロトコル(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は仲間プロトコルレアル-時間Transport Controlプロトコル(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のためにアルゴリズムの大部分を保ちます。(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
このドキュメントはシミュレーションの手段で新しいアルゴリズムを調査します。 私たちは、新しいタイミング規則がよく比例するのを示して、ネットワークに優しい態度で振る舞います。 まず第一に、新しいRTPプロフィールの私たちのシミュレーションに、重要な重要な特色はセクション2で手荒く説明されます。 その後に、私たちはセクション3でシミュレーションを行うのに使用される環境について説明します。 セクション4は遅れている互換性をRTPに示していて、新しいプロフィールがネットワーク使用されていた状態でに優しいシミュレーションの結果について説明します。
Burmeister, et al. Informational [Page 3] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[3ページ]のRFC4586
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].
RTCP交通への帯域幅。 セクション5では、私たちはアプリケーションが新しいプロフィールを実行するのから得ることができた利益を示しています。 セクション6では、私たちはパラメタ「l」(以前はよくT_震え_最大価値について計算していました)のアルゴリズム性能への効果を調査しました、そして、最終的に、セクション7では、すなわち、特別なアプリケーションのために[6]と[7]でNEWPREDを手に入れることができたのを性能向上に示します。
2. Timing Rules of the Extended RTP Profile for RTCP-Based Feedback
2. RTCPベースのフィードバックのための拡張RTPプロフィールのタイミング規則
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.)
- 時間間隔(T_rr)でRTCP合成パケットを送ります。(間隔は平均したパケットサイズと送付者の数とグループ、およびセッション帯域幅の受信機の機能として計算されます)。(セッション帯域幅の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に送るタイミング規則は2つの主要なコンポーネントから成ります。 まず最初に、5秒の最小間隔は撤廃されます。 2番目に、すなわち、受信機は計算された間隔で、得るのではなく、すぐに、実際にはRTCPパケットを送る彼らの(現在、かなり小さい)のRTCP間隔のあらゆるもう一方の間のある機会を「早く」得ます。 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]のように同じ変数名と略語を使用します。
Burmeister, et al. Informational [Page 4] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[4ページ]のRFC4586
3. Simulation Environment
3. シミュレーション環境
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.
このセクションは調査とその重要な特色に使用されたシミュレーションテストベッドについて説明します。 必要であった拡大は以下のセクションで手荒くシミュレータに説明されます。
3.1. Network Simulator Version 2
3.1. ネットワークシミュレータバージョン2
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はTool Command Language(TCL)とC++の組み合わせで書かれているオープンソースプロジェクトです。シナリオはTCLを使用するのに設定されます。 スクリプトを使用して、topologies(ノードとリンク(帯域幅)はサイズ、または誤り率をリンクへ列に並ばせる)と「エージェント」のパラメタを指定するのは可能です、すなわち、プロトコル構成。 プロトコル自体はエージェントでC++で実行されます。(そのエージェントは、ノードを接続されます)。 [4]でns2のためのドキュメンテーションと最も新しいバージョンを見つけることができます。
3.2. RTP Agent
3.2. RTPエージェント
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パケットを送ります。 [2]と[3]のタイミング規則に従って、RTCPパケットを送ります、そして、また、グループ会員資格メンテナンスのためのアルゴリズムを実行します。 送付者と受信機レポートを送ります。
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でのパラメタ設定で新しいタイミング規則の使用を断続的に回すことができます。
3.3. Scenarios
3.3. シナリオ
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スクリプトで定義されます。 私たちは数個の異なったtopologiesをセットアップします、最大25人のセッションメンバーと共に2人のセッションメンバーがいるユニキャストからマルチキャストまで及んで。 レートが使用した発信であることによって、対応は帯域幅をリンクして、混雑の損失は発生するかもしれません。 いくつかのシナリオでは、噛み付いている誤りはあるリンクに挿入されます。 私たちはRTP/AVPエージェント、RTP/AVPFエージェント、および複雑なグループと共にグループをシミュレートしました。
The feedback messages are generally NACK messages as defined in [1] and are triggered by packet loss.
フィードバックメッセージは、一般に[1]で定義されるようにナックメッセージであり、パケット損失で引き起こされます。
Burmeister, et al. Informational [Page 5] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[5ページ]のRFC4586
3.4. Topologies
3.4. Topologies
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異なったtopologiesが、拡張プロフィールに関する重要な特色を示しているためにシミュレートされます。 しかしながら、いくつかの特定のシミュレーションのために、私たちは異なったtopologiesを使用しました。 そして、これはシミュレーションの結果の記述で示されます。 主な4topologiesがすなわち、参加しているRTPエージェント、T-2、T-4、T-8の数にちなんで名付けられます、そして、T-16、T-4は4人のエージェントなどを含みます。そこでは、T-2がユニキャストシナリオです。 図1 以下では、主なtopologiesが例証します。
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
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: シミュレートされたtopologies
4. RTCP Bit Rate Measurements
4. RTCPビット伝送速度測定値
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
新しいタイミング規則は小さいマルチキャストグループのための、より頻繁なRTCPフィードバックを許します。 大きいグループでは、アルゴリズムは同様に正常なRTCPタイミング規則に振る舞います。 一般に、より頻繁なフィードバックを持っているのが良い間、それはRTCPに固定限界(すなわち、RTPに従った総RTP帯域幅の5%)を超えて使用されるビット伝送速度を全く増加させることができません。 このセクションは、新しいタイミング規則が、RTCP帯域幅が用法であることをすべての調査されたシナリオ、topologies、およびグループサイズのための5%の限界で保つのを示します。 その上、私たちは、複雑なグループ(AVPを使用している何人かのメンバー、いくらかのAVPF)を許容できて、それぞれのセッションメンバーが振る舞うのを示します。
Burmeister, et al. Informational [Page 6] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[6ページ]のRFC4586
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帯域幅限界のための他の値が[10]のようにRTCP帯域幅修飾語を使用することで指定されるかもしれないことに注意してください。
4.1. Unicast
4.1. ユニキャスト
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メンバーが干渉なしで共存できるのがわかるのは重要です。 Table1で結果を見つけることができます。
Burmeister, et al. Informational [Page 7] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[7ページ]のRFC4586
| | | | | | 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 |
| | | | | | 中古のRTCPビット伝送速度| | セッション| 発信してください。| Rec。 | AVP| AVPF| (%のセッションbw) | |帯域幅|エージェント|エージェント|エージェント|エージェント| A1| A2| 合計| +---------+------+------+------+------+------+------+------+ | 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キロビット毎秒| 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 | |200キロビット毎秒| 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 | |200キロビット毎秒| 1 | 2 | 1 | 2 | 0.06 | 2.49 | 2.55 | |200キロビット毎秒| 1,2 | - | 1 | 2 | 0.08 | 2.50 | 2.58 | |200キロビット毎秒| 1 | 2 | 1,2 | - | 0.06 | 0.06 | 0.12 | |200キロビット毎秒| 1,2 | - | 1,2 | - | 0.08 | 0.08 | 0.16 | | 20キロビット毎秒| 1 | 2 | - | 1,2 | 2.44 | 2.54 | 4.98 | | 20キロビット毎秒| 1,2 | - | - | 1,2 | 2.50 | 2.51 | 5.01 | | 20キロビット毎秒| 1 | 2 | 1 | 2 | 0.58 | 2.48 | 3.06 | | 20キロビット毎秒| 1,2 | - | 1 | 2 | 0.77 | 2.51 | 3.28 | | 20キロビット毎秒| 1 | 2 | 1,2 | - | 0.58 | 0.61 | 1.19 | | 20キロビット毎秒| 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%を使用するのを見ることができます。(RTPは両方のためにセッション帯域幅の最大5%をまとめます)。 これは送付者であるエージェントか受信機にかかわらず達成されます。エージェントA1がAVPとエージェントA2 AVPFを使用する場合では、総RTCPセッション帯域幅は静まります。 これはエージェントA1が5秒の平均した最小間隔だけがあるパケットをRTCPに送ることができるからです。 セッション帯域幅のわずかな部分だけがRTCPパケットに使用されます。 高ビット伝送速度セッション(セッション帯域幅は2Mbpsと等しい)のために、エージェントA1からのRTCPパケットの部分は0.01%と同じくらい小さいです。 より小さいセッション帯域幅に関しては、断片は、同じ量のRTCPデータを送るので、増加します。 RTCPパケットによって使用される帯域幅シェアは使用されたこととエージェントA2と異なっていません、両方のエージェントが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帯域幅シェアが超えられていないのを示します、パケット損失が起こっても。 私たちはリンクの上に一定のバイト誤り率(バイエル)をシミュレートしました。 一様分布によると、バイト誤りは手当たりしだいに挿入されます。
Burmeister, et al. Informational [Page 8] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[8ページ]のRFC4586
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では、いつも_震え_最大がゼロである、したがって、すぐに早いパケットを送ることができる、_を許容してください、早く、本当にあります。 最後のパケットが既に早めのもの(すなわち、早く_を= 虚偽で許容する)であるなら、次の定期的に予定されている受信機レポートにフィードバックを追加するでしょうに。 最大_フィードバック_遅れパラメタ(私たちが私たちのシミュレーションで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.
結果はTable2に示されます、損失が発生するか否かに関係なく。(そこでは、私たちが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 |
| | | | | | 中古のRTCPビット伝送速度| | セッション| 発信してください。| Rec。 | AVP| AVPF| (%のセッションbw) | |帯域幅|エージェント|エージェント|エージェント|エージェント| A1| A2| 合計| +---------+------+------+------+------+------+------+------+ | 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キロビット毎秒| 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 | |200キロビット毎秒| 1,2 | - | - | 1,2 | 2.50 | 2.49 | 4.99 | |200キロビット毎秒| 1 | 2 | 1 | 2 | 0.06 | 2.50 | 2.56 | |200キロビット毎秒| 1,2 | - | 1 | 2 | 0.08 | 2.49 | 2.57 | |200キロビット毎秒| 1 | 2 | 1,2 | - | 0.06 | 0.07 | 0.13 | |200キロビット毎秒| 1,2 | - | 1,2 | - | 0.09 | 0.08 | 0.17 | | 20キロビット毎秒| 1 | 2 | - | 1,2 | 2.42 | 2.57 | 4.99 | | 20キロビット毎秒| 1,2 | - | - | 1,2 | 2.52 | 2.51 | 5.03 | | 20キロビット毎秒| 1 | 2 | 1 | 2 | 0.58 | 2.54 | 3.12 | | 20キロビット毎秒| 1,2 | - | 1 | 2 | 0.83 | 2.43 | 3.26 | | 20キロビット毎秒| 1 | 2 | 1,2 | - | 0.58 | 0.73 | 1.31 | | 20キロビット毎秒| 1,2 | - | 1,2 | - | 0.86 | 0.84 | 1.70 |
Table 2: Unicast simulations with packet loss
テーブル2: パケット損失に伴うユニキャストシミュレーション
Burmeister, et al. Informational [Page 9] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[9ページ]のRFC4586
4.2. Multicast
4.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帯域幅シェアを調査しました。 すなわち、私たちは、topologies 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.
損失が全く発生しない(どちらも噛み付いている誤りか混雑で)シナリオにおける、異なったtopologiesのシミュレーションはユニキャストケースのように同様の振舞いを示しています。 すべてのグループサイズのために、RTCPビット伝送速度シェアが使用した最大は数人の送付者がいる低ビット伝送速度シナリオ(セッション帯域幅は20キロビット毎秒と等しい)における、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.
最終的に、私たちは私たちがリンク帯域幅を減少させて、その結果混雑関連の損失をもたらしたシミュレーションを行いました。 これらのシミュレーションは前の噛み付いている誤りシミュレーションと異なっています、損失が炸裂でさらに起こって、さらに関連するので、異なったエージェントの間でも。 パケット損失の相関関係と"burstiness"は私たちがシミュレートしたルータにおける待ち行列の規律のためです。 私たちは、混雑を扱うのに低下テール戦略がある簡単な先入れ先出し待ち行列を使用しました。 パケット損失のburstinessが減少するかもしれないので、無作為のEarly Detection(RED)待ち行列は性能を高めるかもしれません。 しかしながら、これは、私たちの調査の対象ではありませんが、今後の研究に発たれます。 エージェントの間の遅れ(また、RTPとRTCPパケットに影響を及ぼす)は加えられた列を作り遅れのためにはるかに可変です。 それでも、使用されるRTCPビット伝送速度シェアはセッション帯域幅の5.09%を超えて増加しません。 したがって、これらの特別なケースにおいても、要件が実現します。
4.3. Summary of the RTCP Bit Rate Measurements
4.3. RTCPビット伝送速度測定値の概要
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.
私たちは、ユニキャストと妥当なマルチキャストシナリオのために、フィードバック内部破裂が起こらないのを示しました。 RTCPがすべてのために実現しているので、セッション帯域幅の最大の5%で使用された要件はシナリオを調査しました。
Burmeister, et al. Informational [Page 10] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[10ページ]のRFC4586
5. Feedback Measurements
5. フィードバック測定値
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.
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.
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.
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.
5.1. Unicast
5.1. Unicast
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.
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.
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.
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.
Burmeister, et al. Informational [Page 11] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 11] RFC 4586 Timing Rules Simulation Results July 2006
| | | 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 |
| | | 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
Table 3: Feedback statistics for the unicast simulations
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.
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.
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.
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.
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.
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.
5.2. Multicast
5.2. Multicast
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
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
Burmeister, et al. Informational [Page 12] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 12] RFC 4586 Timing Rules Simulation Results July 2006
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.
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.
5.2.1. Shared Losses vs. Distributed Losses
5.2.1. Shared Losses vs. Distributed Losses
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.
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.
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.
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|
| | 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
Table 4: Feedback statistics for multicast simulations
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.,
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.,
Burmeister, et al. Informational [Page 13] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 13] RFC 4586 Timing Rules Simulation Results July 2006
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.
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.
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.
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.
6. Investigations on "l"
6. Investigations on "l"
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.
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.
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.
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.
Burmeister, et al. Informational [Page 14] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 14] RFC 4586 Timing Rules Simulation Results July 2006
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.
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.
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.
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.
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.
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.
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.
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.
Finally, in the third scenario, the losses are shared between two agents, A5 and A6. The same agents as in the second scenario are
Finally, in the third scenario, the losses are shared between two agents, A5 and A6. The same agents as in the second scenario are
Burmeister, et al. Informational [Page 15] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 15] RFC 4586 Timing Rules Simulation Results July 2006
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.
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.
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.
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.
6.1. Feedback Suppression Performance
6.1. Feedback Suppression Performance
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.
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.
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.
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.
| | 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 |
| | 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
Table 5: Fraction of feedback that was suppressed at agent (Af) of the total number of feedback messages the agent wanted to send
Similar results can be seen in Table 6 for the agent An that is nearer to the sender.
Similar results can be seen in Table 6 for the agent An that is nearer to the sender.
Burmeister, et al. Informational [Page 16] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 16] RFC 4586 Timing Rules Simulation Results July 2006
| | 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 |
| | 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
Table 6: Fraction of feedback that was suppressed at agent (An) of the total number of feedback messages the agent wanted to send
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.
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.
| |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 |
| |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.
Table 7: The ratio of feedback suppression failures.
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.
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.
Burmeister, et al. Informational [Page 17] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 17] RFC 4586 Timing Rules Simulation Results July 2006
6.2. Loss Report Delay
6.2. Loss Report Delay
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.
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.
| | 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 |
| | 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.
Table 8: The mean loss report delay, measured at the sender.
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.
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.
6.3. Summary of "l" Investigations
6.3. Summary of "l" Investigations
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.
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.
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.
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.
Burmeister, et al. Informational [Page 18] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 18] RFC 4586 Timing Rules Simulation Results July 2006
7. Applications Using AVPF
7. Applications Using AVPF
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 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.
7.1. NEWPRED Implementation in NS2
7.1. NEWPRED Implementation in NS2
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:
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:
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.
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.
The parameters of NEWPRED agent are as follows:
The parameters of NEWPRED agent are as follows:
f: Frame Rate(frames/sec)
seg: Number of segments in one video frame
bw: RTP session bandwidth(kbps)
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.
Generation of NEWPRED's NACK Messages The NEWPRED agent generates NACK messages when segments are lost.
Burmeister, et al. Informational [Page 19] RFC 4586 Timing Rules Simulation Results July 2006
Burmeister, et al. Informational [Page 19] RFC 4586 Timing Rules Simulation Results July 2006
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. 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.
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つのナックメッセージの長さは4バイトです。 numが1個のビデオフレーム(num1<=<はsegと等しい)のナックメッセージの数であることをさせてください。 したがって、12+4*numバイトは合成RTCPパケットの低い遅れRTCPフィードバックメッセージのサイズです。
Measurements
We defined two values to be measured:
測定値Weは測定されるために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)
(往復の遅れ)は+と等しいです(フィードバックメッセージのためのトランスミッション時間)。(メディアデータのためのトランスミッション時間)
Burmeister, et al. Informational [Page 20] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[20ページ]のRFC4586
Picture Reference |: Picture Segment
____________________ %: Lost Segment
/_ _ _ _ \
v/ \ / \ / \ / \ \
v \v \v \v \ \
Sender ---|----|----|----|----|----|---|------------->
\ \ ^ \
\ \ / \
\ \ / \
\ v / \
\ x / \
\ Lost / \
\ x / \
_____
v x / NACK v
Receiver ---------------|----%===-%----%----%----|----->
|-a-| |
|------- b -------|
絵の参照|: 絵のセグメント____________________ %: 無くなっているSegment/_ _ _ _ \v/\/\/\/\\対\v\v\v\\Sender---|----|----|----|----|----|---|-------------> \ \ ^ \ \ \ / \ \ \ / \ \ v / \ \ x / \ \ Lost / \ \ x / \ _____ x/ナック対Receiverに---------------|----%===-%----%----%----|----->|、-1、-| | |------- 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エージェントにおける測定値の関係
7.2. Simulation
7.2. シミュレーション
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とSimulation B)を行いました。 Simulation Aでは、2人のNEWPREDエージェントの間のリンクの上に固定パケット損失率がある状態で、パケットは落とされます。 Simulation Bでは、パケット損失は混雑のためすなわち、他の交通源、ftpセッションから起こります。
7.2.1. Simulation A - Constant Packet Loss Rate
7.2.1. シミュレーションA--一定のパケット損失率
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)
リンク1リンク2リンク3+--------+ +------+ +------+ +--------+ | 送付者|------|ルータ|-------|ルータ|------|受信機| +--------+ +------+ +------+ +--------+ 10(msec)x(msec)10(msec)
Figure 3: Network topology that is used for Simulation A
図3: Simulation 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:
Link1とlink3はエラーのないです、そして、それぞれのリンク遅れは10msecです。 パケットはlink2で落とされるかもしれません。 パケット損失率(Plr)とリンク遅れ(D)は以下の通りです:
Burmeister, et al. Informational [Page 21] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[21ページ]のRFC4586
D [ms] = {10, 50, 100, 200, 500}
Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}
D[ms]は10、50、100、200、500Plr=と等しいです。{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.
セグメントのセッション帯域幅、フレームレート、および数はTable9に示されます。
+------------+----------+-------------+-----+
|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 |
+------------+----------+-------------+-----+
+------------+----------+-------------+-----+ |パラメタID| bw(キロビット毎秒)|f(フレーム/秒)| 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キロビット毎秒であるときに、待ち時間はおよそ400msecです。(妥当なNEWPRED性能において、そのmsecはただ許容できます)。
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未満msecです。 このような場合には、NEWPREDは200msecの追加リンク遅れと同じくらい多くを許容します。
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キロビット毎秒であるときに、また、待ち時間は200未満msecです。
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キロビット毎秒の場合では、結果は、パケット損失率が20%であるときに、待ち時間がおよそ200msecであることを示します。 十二分に512キロビット毎秒のセッション帯域幅がある場合には、どんな重要な遅れもありません。 これは、NEWPRED性能に、RTCPのフィードバック限界による待ち時間が取るにたらないことを意味します。
Burmeister, et al. Informational [Page 22] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[22ページ]のRFC4586
+------------------------------------------------------------+
| | 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 |
+------------------+------+------+------+------+------+------+
+------------------------------------------------------------+ | | パケット損失率=| | 帯域幅| 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の結果
7.2.2. Simulation B - Packet Loss Due to Congestion
7.2.2. シミュレーションB--混雑によるパケット損失
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.
また、link2もエラーのないのを除いて、link1、link2、およびlink3の構成はSimulation Aと同じです、噛み付いている誤りに関して。 しかしながら、さらに、何人かのFTPエージェントが、link2を積みすぎるために配備されます。 シミュレーショントポロジーに図5を見てください。
Link1 Link2 Link3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ /|+------+ +------+|\ +--------+
+---+/ | | \+---+
+-|FTP|+---+ +---+|FTP|-+
| +---+|FTP| ... |FTP|+---+ | ...
+---+ +---+ +---+ +---+
Link1 Link2 Link3+--------+ +------+ +------+ +--------+ | 送付者|------|ルータ|-------|ルータ|------|受信機| +--------+ /|+------+ +------+|\ +--------+ +---+/ | | \+---+ +-|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:
以下の値が割り当てられている状態で、パラメタはSimulation Aのように定義されます:
D[ms] ={10, 50, 100, 200, 500} 32 FTP agents are deployed at each
edge, for a total of 64 FTP agents active.
32人のD[ms]=10、50、100、200、500FTPエージェントが各縁で配備されます、合計64人のFTPエージェントにとって、アクティブです。
Burmeister, et al. Informational [Page 23] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[23ページ]のRFC4586
The sets of session bandwidth, frame rate, and the number of segments are the same as in Simulation A (Table 9).
セッション帯域幅のセット、フレームレート、およびセグメントの数はSimulation 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の一定の追加オフセット以外のSimulation Aに、結果はそれらと同様です。100 原稿Thisはルータのバッファによって被られた遅れのためです。
7.3. Summary of Application Simulations
7.3. アプリケーションシミュレーションの概要
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キロビット毎秒からのセッションのために2Mbpsに下げられるのを示しました。 私たちは、減少しているセッション帯域幅、そして/または、増加するパケット損失率に従って待ち時間が増加するのを見ることができました。 パケット損失の原因は重要ではありません。 混雑と一定のパケット損失率は同様に振る舞います。 それでも、私たちは、妥当な状態とパラメタに関して、AVPFがフィードバックがNEWPREDに必要としたサポートによく合っているのがわかります。 NEWPREDに関する詳しい情報に関しては、[8]と[9]を見てください。
8. Summary
8. 概要
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を使用することで行われました、そして、数個がマルチキャストtopologiesを異なって大きさで分けました。 結果は本書では示されました。
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.
ネットワークの安定性に関して、新しいプロフィールがどんなフィードバック内部破裂にも通じもしませんし、それより多くの帯域幅を使用もしないのを示すのが許されているのは、重要でした。 私たちはRTCPにRTPセッション帯域幅と関連して使用された帯域幅を測定しました。 私たちはまさに多少それを示して、セッション帯域幅の5%はRTCPに使用されます、すべての考えられたシナリオで。 RTCP帯域幅修飾語[10]を使用するように他のRTCP帯域幅値を設定できました。 シナリオは誤り、誤りのあるなしにかかわらず異なって大きさで分けられたマルチキャストグループまたはリンクにおける混雑のあるなしにかかわらずユニキャストを含んでいました。 したがって、私たちは、新しいプロフィールが許容RTCP帯域幅だけを使用するという意味におけるネットワークに優しい態度で反応すると言うことができます、RTPによって定義されるように。
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.
第二に、私たちは、新しいプロフィールを使用する受信機が性能向上を経験するのを示しました。 これは、送付者が受理されたフィードバックに関して見る遅れを得ることによって、測定されました。 新しいプロフィールを使用して、この遅れは何桁も減少できます。
Burmeister, et al. Informational [Page 24] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[24ページ]のRFC4586
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の推奨値はほとんどのアプリケーションと環境に妥当であるように思えます。
9. Security Considerations
9. セキュリティ問題
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タイミング規則の正しい運用について確かめるために行われたシミュレーション仕事について説明します。 その結果、これらのタイミング規則に関するセキュリティ問題はそのドキュメントで説明されます。
Burmeister, et al. Informational [Page 25] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[25ページ]のRFC4586
10. Normative References
10. 引用規格
[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.、バーマイスター、C.、およびJ.レイは「リアルタイムの輸送制御プロトコル(RTCP)ベースのフィードバック(RTP/AVPF)のためにRTPプロフィールを広げました」、RFC4585、2006年7月。
11. Informative References
11. 有益な参照
[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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[4] Network Simulator Version 2 - ns-2, available from
http://www.isi.edu/nsnam/ns.
[4] Simulatorバージョン2をネットワークでつないでください-- http://www.isi.edu/nsnam/ns から利用可能なナノ秒-2。
[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.バーマイスター、T.Klinner、「低い遅れフィードバックRTCP--タイミングはシミュレーションの結果を統治します」。 以下からの2001年9月に利用可能なパナソニックヨーロッパの研究所の技術的なReport http://www.informatik.uni-bremen.de/~jo/misc/ SimulationResults-A.pdf。
[6] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology -
Coding of audio-visual objects - Part2: Visual", July 2000.
[6] ISO/IEC14496-2: 1999/Amd、.1:2000、「情報技術(視聴覚の物のコード化)Part2:」 2000年7月の「視覚」。
[7] ITU-T Recommendation, H.263. Video encoding for low bitrate
communication. 1998.
[7] ITU-T推薦、H.263。 少ないbitrateコミュニケーションのためのビデオのコード化。 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.中井とH.井上、「参照の絵のダイナミックな取り替えによる誤りの立ち直りの早いビデオ符号化」IEEE Global Telecommunicationsコンファレンス(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.トミタ、H.山口、S.Ichinose、T.市川、「受信機指向のリアルタイムの誤り弾力がある画像通信システム:」 日本、Part1、vol.84、No.2、pp.8-17、2001年の「Memory SizeがReceiverにあるAccordanceのError Propagationからの適応型のRecovery」、Electronics、およびCommunications。
[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)帯域幅修飾語」、RFC3556、2003年7月。
Burmeister, et al. Informational [Page 26] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[26ページ]のRFC4586
Authors' Addresses
作者のアドレス
Carsten Burmeister Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
カルステンバーマイスターパナソニック研究開発センタードイツ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パナソニック研究開発センタードイツ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
Akihiro宮崎松下電器産業社、Ltd1006、門真、門真市、大阪、日本
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
技術のヨルクオットヘルシンキ大学、TKK、ネットワーク研究所PO Box3000、02015フィンランド
EMail: jo@acm.org
メール: jo@acm.org
Noriyuki Sato Oki Electric Industry Co., Ltd. 1-16-8 Chuo, Warabi, Saitama 335-8510 Japan
ノリユキ佐藤沖電気工業株式会社1-16-8中央、蕨、日本埼玉335-8510
EMail: sato652@oki.com
メール: sato652@oki.com
Shigeru Fukunaga Oki Electric Industry Co., Ltd. 2-5-7 Hommachi, Chuo-ku, Osaka 541-0053 Japan
Shigeru Fukunaga沖電気工業株式会社2-5-7本町、中央区、日本大阪541-0053
EMail: fukunaga444@oki.com
メール: fukunaga444@oki.com
Burmeister, et al. Informational [Page 27] RFC 4586 Timing Rules Simulation Results July 2006
バーマイスター、他 シミュレーションの結果2006年7月に規則を調節する情報[27ページ]のRFC4586
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Burmeister, et al. Informational [Page 28]
バーマイスター、他 情報[28ページ]
一覧
スポンサーリンク
