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
Network Working Group C. Burmeister
Request for Comments: 4586 R. Hakenberg
Category: Informational A. Miyazaki
Panasonic
J. Ott
Helsinki University of Technology
N. Sato
S. Fukunaga
Oki
July 2006
Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations
基于实时传输控制协议（RTCP）的反馈的扩展RTP配置文件：定时规则模拟结果
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic.
本文档描述了在模拟基于实时传输控制协议（RTCP）的反馈（表示为AVPF）的扩展RTP配置文件的定时规则时获得的结果。考虑了单播和多播拓扑以及几种协议和环境配置。结果表明，定时规则在反馈延迟方面具有更好的性能，并且在控制流量的允许比特率方面仍然保持公认的RTP规则。
Table of Contents
目录
1. Introduction ....................................................3
2. Timing Rules of the Extended RTP Profile for RTCP-Based
Feedback ........................................................4
3. Simulation Environment ..........................................5
3.1. Network Simulator Version 2 ................................5
3.2. RTP Agent ..................................................5
3.3. Scenarios ..................................................5
3.4. Topologies .................................................6
4. RTCP Bit Rate Measurements ......................................6
4.1. Unicast ....................................................7
4.2. Multicast .................................................10
4.3. Summary of the RTCP Bit Rate Measurements .................10
5. Feedback Measurements ..........................................11
5.1. Unicast ...................................................11
5.2. Multicast .................................................12
5.2.1. Shared Losses vs. Distributed Losses ...............13
6. Investigations on "l" ..........................................14
6.1. Feedback Suppression Performance ..........................16
6.2. Loss Report Delay .........................................18
6.3. Summary of "l" Investigations .............................18
7. Applications Using AVPF ........................................19
7.1. NEWPRED Implementation in NS2 .............................19
7.2. Simulation ................................................21
7.2.1. Simulation A - Constant Packet Loss Rate ...........21
7.2.2. Simulation B - Packet Loss Due to Congestion .......23
7.3. Summary of Application Simulations ........................24
8. Summary ........................................................24
9. Security Considerations ........................................25
10. Normative References ..........................................26
11. Informative References ........................................26
1. Introduction ....................................................3
2. Timing Rules of the Extended RTP Profile for RTCP-Based
Feedback ........................................................4
3. Simulation Environment ..........................................5
3.1. Network Simulator Version 2 ................................5
3.2. RTP Agent ..................................................5
3.3. Scenarios ..................................................5
3.4. Topologies .................................................6
4. RTCP Bit Rate Measurements ......................................6
4.1. Unicast ....................................................7
4.2. Multicast .................................................10
4.3. Summary of the RTCP Bit Rate Measurements .................10
5. Feedback Measurements ..........................................11
5.1. Unicast ...................................................11
5.2. Multicast .................................................12
5.2.1. Shared Losses vs. Distributed Losses ...............13
6. Investigations on "l" ..........................................14
6.1. Feedback Suppression Performance ..........................16
6.2. Loss Report Delay .........................................18
6.3. Summary of "l" Investigations .............................18
7. Applications Using AVPF ........................................19
7.1. NEWPRED Implementation in NS2 .............................19
7.2. Simulation ................................................21
7.2.1. Simulation A - Constant Packet Loss Rate ...........21
7.2.2. Simulation B - Packet Loss Due to Congestion .......23
7.3. Summary of Application Simulations ........................24
8. Summary ........................................................24
9. Security Considerations ........................................25
10. Normative References ..........................................26
11. Informative References ........................................26
The Real-time Transport Protocol (RTP) is widely used for the transmission of real-time or near real-time media data over the Internet. While it was originally designed to work well for multicast groups in very large scales, its scope is not limited to that. More and more applications use RTP for small multicast groups (e.g., video conferences) or even unicast (e.g., IP telephony and media streaming applications).
实时传输协议（RTP）广泛用于在Internet上传输实时或接近实时的媒体数据。虽然它最初设计用于大规模多播组，但其范围并不限于此。越来越多的应用程序将RTP用于小型多播组（例如，视频会议）甚至单播（例如，IP电话和媒体流应用程序）。
RTP comes together with its companion protocol Real-time Transport Control Protocol (RTCP), which is used to monitor the transmission of the media data and provide feedback of the reception quality. Furthermore, it can be used for loose session control. Having the scope of large multicast groups in mind, the rules regarding when to send feedback were carefully restricted to avoid feedback explosion or feedback-related congestion in the network. RTP and RTCP have proven to work well in the Internet, especially in large multicast groups, which is shown by their widespread usage today.
RTP与其配套协议实时传输控制协议（RTCP）一起提供，RTCP用于监控媒体数据的传输并提供接收质量反馈。此外，它还可以用于松散的会话控制。考虑到大型多播组的范围，有关何时发送反馈的规则被仔细限制，以避免网络中反馈爆炸或反馈相关的拥塞。RTP和RTCP已被证明在Internet上运行良好，特别是在大型多播组中，这一点在今天的广泛使用中得到了证明。
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反馈的使用。因此，决定创建一个新的扩展RTP配置文件，它重新定义了一些RTCP定时规则，但保留了RTP和RTCP的大多数算法，这些算法已被证明运行良好。新规则应该从单播扩展到多播，单播或小型多播应用程序从中获益最多。有关新配置文件及其计时规则的详细说明，请参见[1]。
This document investigates the new algorithms by the means of simulations. We show that the new timing rules scale well and behave in a network-friendly manner. Firstly, the key features of the new RTP profile that are important for our simulations are roughly described in Section 2. After that, we describe in Section 3 the environment that is used to conduct the simulations. Section 4 describes simulation results that show the backwards compatibility to RTP and that the new profile is network-friendly in terms of used
本文通过仿真研究了新算法。我们证明了新的定时规则具有良好的伸缩性，并且以网络友好的方式运行。首先，第2节粗略描述了对我们的模拟非常重要的新RTP配置文件的关键特性。之后，我们将在第3节中描述用于进行模拟的环境。第4节描述了模拟结果，显示了与RTP的向后兼容性，并且新的配置文件在使用方面是网络友好的
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。
As said above, RTP restricts the usage of RTCP feedback. The main restrictions on RTCP are as follows:
如上所述，RTP限制RTCP反馈的使用。RTCP的主要限制如下：
- RTCP messages are sent in compound packets, i.e., every RTCP packet contains at least one sender report (SR) or receiver report (RR) message and a source description (SDES) message.
- RTCP消息以复合数据包的形式发送，即每个RTCP数据包至少包含一条发送方报告（SR）或接收方报告（RR）消息和一条源描述（SDES）消息。
- The RTCP compound packets are sent in time intervals (T_rr), which are computed as a function of the average packet size, the number of senders and receivers in the group, and the session bandwidth (5% of the session bandwidth is used for RTCP messages; this bandwidth is shared between all session members, where the senders may get a larger share than the receivers.)
- RTCP复合数据包以时间间隔（T_rr）发送，时间间隔根据平均数据包大小、组中发送方和接收方的数量以及会话带宽计算（5%的会话带宽用于RTCP消息；该带宽在所有会话成员之间共享，其中发送方可能获得比接收方更大的共享。）
- The average minimum interval between two RTCP packets from the same source is 5 seconds.
- 来自同一来源的两个RTCP数据包之间的平均最小间隔为5秒。
We see that these rules prevent feedback explosion and scale well to large multicast groups. However, they do not allow timely feedback at all. While the second rule scales also to small groups or unicast (in this cases the interval might be as small as a few milliseconds), the third rule may prevent the receivers from sending feedback timely.
我们看到，这些规则可以防止反馈爆炸，并且可以很好地扩展到大型多播组。但是，它们根本不允许及时反馈。虽然第二条规则也适用于小团体或单播（在这种情况下，间隔可能只有几毫秒），但第三条规则可能会阻止接收者及时发送反馈。
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反馈的计时规则由两个关键组件组成。首先，取消了5秒的最小间隔。其次，接收器在每隔一个（现在相当小）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]中相同的变量名和缩写。
This section describes the simulation testbed that was used for the investigations and its key features. The extensions to the simulator that were necessary are roughly described in the following sections.
本节描述了用于调查的模拟试验台及其主要功能。下面几节将大致描述对模拟器进行的必要扩展。
The simulations were conducted using the network simulator version 2 (ns2). ns2 is an open source project, written in a combination of Tool Command Language (TCL) and C++. The scenarios are set up using TCL. Using the scripts, it is possible to specify the topologies (nodes and links, bandwidths, queue sizes, or error rates for links) and the parameters of the "agents", i.e., protocol configurations. The protocols themselves are implemented in C++ in the agents, which are connected to the nodes. The documentation for ns2 and the newest version can be found in [4].
使用网络模拟器版本2（ns2）进行模拟。NS2是一个开源的项目，它是用工具命令语言（TCL）和C++的组合编写的。这些场景是使用TCL设置的。使用脚本，可以指定拓扑（节点和链路、带宽、队列大小或链路的错误率）和“代理”的参数，即协议配置。协议本身在C++中实现，在代理中，它们连接到节点。ns2和最新版本的文档可在[4]中找到。
We implemented a new agent, based on RTP/RTCP. RTP packets are sent at a constant packet rate with the correct header sizes. RTCP packets are sent according to the timing rules of [2] and [3], and also its algorithms for group membership maintenance are implemented. Sender and receiver reports are sent.
我们实现了一个基于RTP/RTCP的新代理。RTP数据包以恒定的数据包速率和正确的报头大小发送。根据[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中的参数设置打开和关闭新定时规则的使用。
The scenarios that are simulated are defined in TCL scripts. We set up several different topologies, ranging from unicast with two session members to multicast with up to 25 session members. Depending on the sending rates used and the corresponding link bandwidths, congestion losses may occur. In some scenarios, bit errors are inserted on certain links. We simulated groups with RTP/AVP agents, RTP/AVPF agents, and mixed groups.
模拟的场景在TCL脚本中定义。我们设置了几种不同的拓扑，从具有两个会话成员的单播到具有多达25个会话成员的多播。根据使用的发送速率和相应的链路带宽，可能会发生拥塞损失。在某些情况下，会在某些链接上插入位错误。我们用RTP/AVP药物、RTP/AVPF药物和混合药物模拟组。
The feedback messages are generally NACK messages as defined in [1] and are triggered by packet loss.
反馈消息通常是[1]中定义的NACK消息，由分组丢失触发。
Mainly, four different topologies are simulated to show the key features of the extended profile. However, for some specific simulations we used different topologies. This is then indicated in the description of the simulation results. The main four topologies are named after the number of participating RTP agents, i.e., T-2, T-4, T-8, and T-16, where T-2 is a unicast scenario, T-4 contains four agents, etc. Figure 1 below illustrates the main topologies.
主要模拟了四种不同的拓扑结构，以显示扩展剖面的关键特征。但是，对于某些特定的模拟，我们使用了不同的拓扑。这将在模拟结果的描述中指出。主要四种拓扑以参与RTP代理的数量命名，即T-2、T-4、T-8和T-16，其中T-2是单播场景，T-4包含四种代理，等等。下面的图1说明了主要拓扑。
A5
A5 | A6
/ | /
/ | /--A7
/ |/
A2 A2-----A6 A2--A8
/ / / A9
/ / / /
/ / / /---A10
A1-----A2 A1-----A3 A1-----A3-----A7 A1------A3<
\ \ \ \---A11
\ \ \ \
\ \ \ A12
A4 A4-----A8 A4--A13
|\
| \--A14
| \
| A15
A16
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-2T-4T-8T-16
Figure 1: Simulated topologies
图1：模拟拓扑
The new timing rules allow more frequent RTCP feedback for small multicast groups. In large groups, the algorithm behaves similarly to the normal RTCP timing rules. While it is generally good to have more frequent feedback, it cannot be allowed at all to increase the bit rate used for RTCP above a fixed limit, i.e., 5% of the total RTP bandwidth according to RTP. This section shows that the new timing rules keep RTCP bandwidth usage under the 5% limit for all investigated scenarios, topologies, and group sizes. Furthermore, we show that mixed groups (some members using AVP, some AVPF) can be allowed and that each session member behaves
新的定时规则允许对小型多播组进行更频繁的RTCP反馈。在大型组中，该算法的行为类似于正常RTCP定时规则。虽然通常有更频繁的反馈是好的，但根本不允许将用于RTCP的比特率增加到固定限制以上，即根据RTP增加总RTP带宽的5%。本节说明，对于所有调查的场景、拓扑和组大小，新的定时规则将RTCP带宽使用率保持在5%以下。此外，我们还证明了混合组（一些成员使用AVP，一些AVPF）是允许的，并且每个会话成员的行为都是允许的
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带宽修饰符指定。
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。因此，一个代理在一个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秒（平均）。没有提前发送数据包，因为没有给出提前发送反馈的需要。不过，重要的是要看到RTCP使用的会话带宽不超过5%，并且AVP和AVPF成员可以在没有干扰的情况下共存。结果见表1。
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.01 | 0.02 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.49 | 2.55 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.50 | 2.58 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.06 | 0.12 |
|200 kbps | 1,2 | - | 1,2 | - | 0.08 | 0.08 | 0.16 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.44 | 2.54 | 4.98 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.51 | 5.01 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.48 | 3.06 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.77 | 2.51 | 3.28 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.61 | 1.19 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.77 | 0.79 | 1.58 |
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.01 | 0.02 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.49 | 2.55 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.50 | 2.58 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.06 | 0.12 |
|200 kbps | 1,2 | - | 1,2 | - | 0.08 | 0.08 | 0.16 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.44 | 2.54 | 4.98 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.51 | 5.01 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.48 | 3.06 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.77 | 2.51 | 3.28 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.61 | 1.19 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.77 | 0.79 | 1.58 |
Table 1: Unicast simulations without packet loss
表1：无数据包丢失的单播模拟
We can see that in configurations where both agents use the new timing rules each of them uses, at most, about 2.5% of the session bandwidth for RTP, which sums up to 5% of the session bandwidth for both. This is achieved regardless of the agent being a sender or a receiver. In the cases where agent A1 uses AVP and agent A2 AVPF, the total RTCP session bandwidth decreases. This is because agent A1 can send RTCP packets only with an average minimum interval of 5 seconds. Thus, only a small fraction of the session bandwidth is used for its RTCP packets. For a high-bit-rate session (session bandwidth = 2 Mbps), the fraction of the RTCP packets from agent A1 is as small as 0.01%. For smaller session bandwidths, the fraction increases because the same amount of RTCP data is sent. The bandwidth share that is used by RTCP packets from agent A2 is not different from what was used, when both agents implemented the AVPF. Thus, the interaction of AVP and AVPF agents is not problematic in these scenarios at all.
我们可以看到，在两个代理都使用新定时规则的配置中，每个代理最多使用RTP会话带宽的2.5%，这两个代理的会话带宽总和为5%。无论代理是发送方还是接收方，都可以实现这一点。在代理A1使用AVP和代理A2使用AVPF的情况下，总RTCP会话带宽减少。这是因为代理A1只能以5秒的平均最小间隔发送RTCP数据包。因此，只有一小部分会话带宽用于其RTCP数据包。对于高比特率会话（会话带宽=2 Mbps），来自代理A1的RTCP数据包的比例小至0.01%。对于较小的会话带宽，由于发送的RTCP数据量相同，因此分数会增加。来自代理A2的RTCP数据包使用的带宽共享与两个代理实现AVPF时使用的带宽共享没有区别。因此，在这些场景中，AVP和AVPF代理的交互根本没有问题。
In our second unicast experiment, we show that the allowed RTCP bandwidth share is not exceeded, even if packet loss occurs. We simulated a constant byte error rate (BYER) on the link. The byte errors are inserted randomly according to a uniform distribution.
在我们的第二个单播实验中，我们表明即使发生数据包丢失，也不会超过允许的RTCP带宽共享。我们模拟了链路上的恒定字节错误率（BYER）。字节错误按照均匀分布随机插入。
Packets with byte errors are discarded on the link; hence the receiving agents will not see the loss immediately. The agents detect packet loss by a gap in the sequence number.
在链路上丢弃有字节错误的数据包；因此，接收代理不会立即看到损失。代理通过序列号中的间隙检测数据包丢失。
When an AVPF agent detects a packet loss, the early feedback procedure is started. As described in AVPF [1], in unicast T_dither_max is always zero, hence an early packet can be sent immediately if allow_early is true. If the last packet was already an early one (i.e., allow_early = false), the feedback might be appended to the next regularly scheduled receiver report. The max_feedback_delay parameter (which we set to 1 second in our simulations) determines if that is allowed.
当AVPF代理检测到数据包丢失时，将启动早期反馈过程。如AVPF[1]中所述，在单播中，T_抖动_max始终为零，因此，如果allow_early为真，则可以立即发送早期数据包。如果最后一个数据包已经是早期数据包（即，allow_early=false），则可以将反馈附加到下一个定期安排的接收方报告中。max_feedback_delay参数（我们在模拟中设置为1秒）确定是否允许这样做。
The results are shown in Table 2, where we can see that there is no difference in the RTCP bandwidth share, whether or not losses occur. This is what we expected, because even though the RTCP packet size grows and early packets are sent, the interval between the packets increases and thus the RTCP bandwidth stays the same. Only the RTCP bandwidth of the agents that use the AVP increases slightly. This is because the interval between the packets is still 5 seconds (in average), but the packet size increased because of the feedback that is appended.
结果如表2所示，我们可以看到，无论是否发生损失，RTCP带宽共享没有差异。这是我们所期望的，因为即使RTCP数据包大小增加并且发送早期数据包，数据包之间的间隔也会增加，因此RTCP带宽保持不变。只有使用AVP的代理的RTCP带宽略有增加。这是因为数据包之间的间隔仍然是5秒（平均），但是数据包大小由于附加的反馈而增加。
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.02 | 0.03 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.49 | 4.99 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.50 | 2.56 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.49 | 2.57 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.07 | 0.13 |
|200 kbps | 1,2 | - | 1,2 | - | 0.09 | 0.08 | 0.17 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.57 | 4.99 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.52 | 2.51 | 5.03 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.54 | 3.12 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.83 | 2.43 | 3.26 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.73 | 1.31 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.86 | 0.84 | 1.70 |
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.02 | 0.03 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.49 | 4.99 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.50 | 2.56 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.49 | 2.57 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.07 | 0.13 |
|200 kbps | 1,2 | - | 1,2 | - | 0.09 | 0.08 | 0.17 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.57 | 4.99 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.52 | 2.51 | 5.03 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.54 | 3.12 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.83 | 2.43 | 3.26 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.73 | 1.31 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.86 | 0.84 | 1.70 |
Table 2: Unicast simulations with packet loss
表2：丢包情况下的单播模拟
Next, we investigated the RTCP bandwidth share in multicast scenarios; i.e., we simulated the topologies T-4, T-8, and T-16 and measured the fraction of the session bandwidth that was used for RTCP packets. Again we considered different situations and protocol configurations (e.g., with or without bit errors, groups with AVP and/or AVPF agents, etc.). For reasons of readability, we present only selected results. For a documentation of all results, see [5].
接下来，我们研究了多播场景下的RTCP带宽共享；i、 例如，我们模拟了拓扑T-4、T-8和T-16，并测量了用于RTCP数据包的会话带宽部分。我们再次考虑了不同的情况和协议配置（例如，有或没有位错误，有AVP和/或AVPF代理的组，等等）。出于可读性的原因，我们只提供选定的结果。有关所有结果的文档，请参见[5]。
The simulations of the different topologies in scenarios where no losses occur (neither through bit errors nor through congestion) show a similar behavior as in the unicast case. For all group sizes, the maximum RTCP bit rate share used is 5.06% of the session bandwidth in a simulation of 16 session members in a low-bit-rate scenario (session bandwidth = 20 kbps) with several senders. In all other scenarios without losses, the RTCP bit rate share used is below that. Thus, the requirement that not more than 5% of the session bit rate should be used for RTCP is fulfilled with reasonable accuracy.
在不发生丢失（既不是由于误码也不是由于拥塞）的情况下，对不同拓扑的模拟显示出与单播情况类似的行为。对于所有组大小，使用的最大RTCP比特率份额为会话带宽的5.06%，在低比特率场景（会话带宽=20 kbps）下，模拟16个会话成员，并使用多个发送方。在所有其他没有损失的情况下，使用的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%的规则（RTCP最多使用5.07%的会话带宽）。
Finally, we conducted simulations where we reduced the link bandwidth and thereby caused congestion-related losses. These simulations are different from the previous bit error simulations, in that the losses occur more in bursts and are more correlated, also between different agents. The correlation and "burstiness" of the packet loss is due to the queuing discipline in the routers we simulated; we used simple FIFO queues with a drop-tail strategy to handle congestion. Random Early Detection (RED) queues may enhance the performance, because the burstiness of the packet loss might be reduced; however, this is not the subject of our investigations, but is left for future study. The delay between the agents, which also influences RTP and RTCP packets, is much more variable because of the added queuing delay. Still the RTCP bit rate share used does not increase beyond 5.09% of the session bandwidth. Thus, also for these special cases the requirement is fulfilled.
最后，我们进行了模拟，减少了链路带宽，从而造成了与拥塞相关的损失。这些模拟不同于以前的误码模拟，因为丢失更多地发生在突发中，并且在不同的代理之间也更相关。分组丢失的相关性和“突发性”是由于我们模拟的路由器中的排队规则造成的；我们使用了简单的FIFO队列和一个掉尾策略来处理拥塞。随机早期检测（RED）队列可能会提高性能，因为数据包丢失的突发性可能会降低；然而，这不是我们调查的主题，而是留给未来的研究。代理之间的延迟也会影响RTP和RTCP数据包，由于增加了排队延迟，因此变化更大。然而，所使用的RTCP比特率份额并未增加到会话带宽的5.09%以上。因此，对于这些特殊情况，也满足了要求。
We have shown that for unicast and reasonable multicast scenarios, feedback implosion does not happen. The requirement that at maximum 5% of the session bandwidth is used for RTCP is fulfilled for all investigated scenarios.
我们已经证明，对于单播和合理的多播场景，反馈内爆不会发生。对于所有调查的场景，RTCP最多使用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.
在本节中，我们描述了我们在模拟中进行的反馈延迟测量的结果。因此，我们使用两个指标来衡量算法的性能；这些是“平均等待时间”（MWT）和发送、抑制或不允许的反馈数据包的数量。等待时间是在某个代理处测量的从检测到丢包事件到发送相应反馈之间的时间。假设反馈值随延迟而减小，我们认为平均等待时间是衡量使用AVPF而不是AVP可以获得的性能增益的一个很好的指标。
The feedback an RTP/AVPF agent wants to send can be either sent or not sent. If it was not sent, this could be due to feedback suppression (i.e., another receiver already sent the same feedback) or because the feedback was not allowed (i.e., the max_feedback_delay was exceeded). We traced for every detected loss, if the agent sent the corresponding feedback or not and if not, why. The more feedback was not allowed, the worse the performance of the algorithm. Together with the waiting times, this gives us a good hint of the overall performance of the scheme.
RTP/AVPF代理想要发送的反馈可以发送也可以不发送。如果未发送，这可能是由于反馈抑制（即，另一个接收器已发送相同的反馈）或由于不允许反馈（即，超过了最大反馈延迟）。我们跟踪了每一次检测到的损失，是否代理发送了相应的反馈，如果没有，原因是什么。不允许的反馈越多，算法的性能就越差。再加上等待时间，我们很好地了解了该方案的整体性能。
In the unicast case, the maximum dithering interval T_dither_max is fixed and set to zero. This is because it does not make sense for a unicast receiver to wait for other receivers if they have the same feedback to send. But still feedback can be delayed or might not be permitted to be sent at all. The regularly scheduled packets are spaced according to T_rr, which depends in the unicast case mainly on the session bandwidth.
在单播情况下，最大抖动间隔T_dither_max是固定的并设置为零。这是因为，如果一个单播接收机有相同的反馈要发送，那么等待其他接收机是没有意义的。但反馈可能会被延迟，或者根本不允许发送。定期调度的分组根据T_rr间隔，这在单播情况下主要取决于会话带宽。
Table 3 shows the mean waiting times (MWTs) measured in seconds for some configurations of the unicast topology T-2. The number of feedback packets that are sent or discarded is listed also (feedback sent (sent) or feedback discarded (disc)). We do not list suppressed packets, because for the unicast case feedback suppression does not apply. In the simulations, agent A1 was a sender and agent A2 was a pure receiver.
表3显示了一些单播拓扑T-2配置的平均等待时间（MWT），单位为秒。还列出了发送或丢弃的反馈数据包的数量（已发送反馈（sent））或已丢弃反馈（disc））。我们不列出被抑制的数据包，因为对于单播情况，反馈抑制不适用。在模拟中，代理A1是发送方，代理A2是纯接收方。
| | | Feedback Statistics |
| Session | | AVP | AVPF |
|Bandwidth| PLR | sent |disc| MWT | sent |disc| MWT |
+---------+-------+------+----+-------+------+----+-------+
| 2 Mbps | 0.001 | 781 | 0 | 2.604 | 756 | 0 | 0.015 |
| 2 Mbps | 0.01 | 7480 | 0 | 2.591 | 7548 | 2 | 0.006 |
| 2 Mbps | cong. | 25 | 0 | 2.557 | 1741 | 0 | 0.001 |
| 20 kbps | 0.001 | 79 | 0 | 2.472 | 74 | 2 | 0.034 |
| 20 kbps | 0.01 | 780 | 0 | 2.605 | 709 | 64 | 0.163 |
| 20 kbps | cong. | 780 | 0 | 2.590 | 687 | 70 | 0.162 |
| | | Feedback Statistics |
| Session | | AVP | AVPF |
|Bandwidth| PLR | sent |disc| MWT | sent |disc| MWT |
+---------+-------+------+----+-------+------+----+-------+
| 2 Mbps | 0.001 | 781 | 0 | 2.604 | 756 | 0 | 0.015 |
| 2 Mbps | 0.01 | 7480 | 0 | 2.591 | 7548 | 2 | 0.006 |
| 2 Mbps | cong. | 25 | 0 | 2.557 | 1741 | 0 | 0.001 |
| 20 kbps | 0.001 | 79 | 0 | 2.472 | 74 | 2 | 0.034 |
| 20 kbps | 0.01 | 780 | 0 | 2.605 | 709 | 64 | 0.163 |
| 20 kbps | cong. | 780 | 0 | 2.590 | 687 | 70 | 0.162 |
Table 3: Feedback statistics for the unicast simulations
表3：单播模拟的反馈统计信息
From the table above we see that the mean waiting time can be decreased dramatically by using AVPF instead of AVP. While the waiting times for agents using AVP is always around 2.5 seconds (half the minimum interval average), it can be decreased to a few ms for most of the AVPF configurations.
从上表中我们可以看出，使用AVPF代替AVP可以显著缩短平均等待时间。虽然使用AVP的代理的等待时间始终在2.5秒左右（最小平均间隔的一半），但对于大多数AVPF配置，等待时间可以减少到几毫秒。
In the configurations with high session bandwidth, normally all triggered feedback is sent. This is because more RTCP bandwidth is available. There are only very few exceptions, which are probably due to more than one packet loss within one RTCP interval, where the first loss was by chance sent quite early. In this case, it might be possible that the second feedback is triggered after the early packet was sent, but possibly too early to append it to the next regularly scheduled report, because of the limitation of the max_feedback_delay. This is different for the cases with a small session bandwidth, where the RTCP bandwidth share is quite low and T_rr thus larger. After an early packet was sent, the time to the next regularly scheduled packet can be very high. We saw that in some cases the time was larger than the max_feedback_delay, and in these cases the feedback is not allowed to be sent at all.
在具有高会话带宽的配置中，通常发送所有触发的反馈。这是因为有更多的RTCP带宽可用。只有极少数例外情况，这可能是由于在一个RTCP间隔内有多个数据包丢失造成的，其中第一个数据包丢失是偶然提前发送的。在这种情况下，可能在发送早期数据包后触发第二个反馈，但由于最大反馈延迟的限制，将其附加到下一个定期报告可能太早。对于会话带宽较小的情况，这是不同的，其中RTCP带宽共享非常低，因此T_rr更大。在发送了一个早期数据包之后，到下一个定时数据包的时间可能非常长。我们看到，在某些情况下，时间大于最大反馈延迟，在这些情况下，根本不允许发送反馈。
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.
使用不同的最大反馈延迟设置，可以有更多不允许的反馈和减少的平均等待时间，也可以有更多发送但增加等待时间的反馈。因此，应根据应用程序的需要小心设置参数。
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
在本节中，我们将描述多播模拟中反馈统计的一些度量。我们挑选出了某些特征和具有代表性的结果。我们考虑了拓扑结构T-16。针对该拓扑模拟了不同的场景和应用。不同链接的参数设置如下。代理A2、A3和A4连接到多播的中间节点
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.
树，即代理A1，通过高带宽和低延迟链路。其他代理通过不同的链路特性连接到节点2、3和4。连接到节点2的代理代表移动用户。在某些配置中，它们的访问链路上存在一定的字节错误率，并且延迟很高。连接到节点3的代理具有低带宽访问链路，但不会出现比特错误。最后连接到节点4的代理具有高带宽和低延迟。
In our first investigation, we wanted to see the effect of the loss characteristic on the algorithm's performance. We investigate the cases where packet loss occurs for several users simultaneously (shared losses) or totally independently (distributed losses). We first define agent A1 to be the sender. In the case of shared losses, we inserted a constant byte error rate on one of the middle links, i.e., the link between A1 and A2. In the case of distributed losses, we inserted the same byte error rate on all links downstream of A2.
在我们的第一次调查中，我们希望看到损失特性对算法性能的影响。我们研究多个用户同时（共享丢失）或完全独立（分布式丢失）发生数据包丢失的情况。我们首先将代理A1定义为发送方。在共享丢失的情况下，我们在其中一个中间链路（即A1和A2之间的链路）上插入了一个恒定的字节错误率。在分布式丢失的情况下，我们在A2下游的所有链路上插入相同的字节错误率。
These scenarios are especially interesting because of the feedback suppression algorithm. When all receivers share the same loss, it is only necessary for one of them to send the loss report. Hence if a member receives feedback with the same content that it has scheduled to be sent, it suppresses the scheduled feedback. Of course, this suppressed feedback does not contribute to the mean waiting times. So we expect reduced waiting times for shared losses, because the probability is high that one of the receivers can send the feedback more or less immediately. The results are shown in the following table.
由于反馈抑制算法，这些场景特别有趣。当所有接收人分担相同的损失时，只需其中一人发送损失报告。因此，如果成员收到的反馈内容与其计划发送的内容相同，则会抑制计划的反馈。当然，这种被抑制的反馈并不影响平均等待时间。因此，我们期望减少共享损失的等待时间，因为其中一个接收器可以或多或少立即发送反馈的概率很高。结果如下表所示。
| | Feedback Statistics |
| | Shared Losses | Distributed Losses |
|Agent|sent|fbsp|disc|sum | MWT |sent|fbsp|disc|sum | MWT |
+-----+----+----+----+----+-----+----+----+----+----+-----+
| A2 | 274| 351| 25| 650|0.267| -| -| -| -| -|
| A5 | 231| 408| 11| 650|0.243| 619| 2| 32| 653|0.663|
| A6 | 234| 407| 9| 650|0.235| 587| 2| 32| 621|0.701|
| A7 | 223| 414| 13| 650|0.253| 594| 6| 41| 641|0.658|
| A8 | 188| 443| 19| 650|0.235| 596| 1| 32| 629|0.677|
| | Feedback Statistics |
| | Shared Losses | Distributed Losses |
|Agent|sent|fbsp|disc|sum | MWT |sent|fbsp|disc|sum | MWT |
+-----+----+----+----+----+-----+----+----+----+----+-----+
| A2 | 274| 351| 25| 650|0.267| -| -| -| -| -|
| A5 | 231| 408| 11| 650|0.243| 619| 2| 32| 653|0.663|
| A6 | 234| 407| 9| 650|0.235| 587| 2| 32| 621|0.701|
| A7 | 223| 414| 13| 650|0.253| 594| 6| 41| 641|0.658|
| A8 | 188| 443| 19| 650|0.235| 596| 1| 32| 629|0.677|
Table 4: Feedback statistics for multicast simulations
表4：多播模拟的反馈统计信息
Table 4 shows the feedback statistics for the simulation of a large group size. All 16 agents of topology T-16 joined the RTP session. However, only agent A1 acts as an RTP sender; the other agents are pure receivers. Only 4 or 5 agents suffer from packet loss, i.e.,
表4显示了模拟大型组的反馈统计信息。拓扑T-16的所有16个代理都加入了RTP会话。然而，只有代理A1充当RTP发送方；其他代理人是纯粹的接受者。只有4或5个代理遭受数据包丢失，即。，
A2, A5, A6, A7, and A8 for the case of shared losses and A5, A6, A7, and A8 in the case of distributed losses. Since the number of session members is the same for both cases, T_rr is also the same on the average. Still the mean waiting times are reduced by more than 50% in the case of shared losses. This proves our assumption that shared losses enhance the performance of the algorithm, regardless of the loss characteristic.
A2、A5、A6、A7和A8用于分摊损失，A5、A6、A7和A8用于分摊损失。由于两种情况下会话成员的数量相同，因此T_rr的平均值也相同。然而，在分担损失的情况下，平均等待时间减少了50%以上。这证明了我们的假设，即无论损失特性如何，共享损失都会提高算法的性能。
The feedback suppression mechanism seems to be working quite well. Even though some feedback is sent from different receivers (i.e., 1150 loss reports are sent in total and only 650 packets were lost, resulting in loss reports being received on the average 1.8 times), most of the redundant feedback was suppressed. That is, 2023 loss reports were suppressed from 3250 individual detected losses, which means that more than 60% of the feedback was actually suppressed.
反馈抑制机制似乎工作得很好。即使一些反馈是从不同的接收器发送的（即，总共发送了1150个丢失报告，只有650个数据包丢失，导致丢失报告平均接收1.8次），大多数冗余反馈被抑制。也就是说，从3250个单独检测到的损失中，2023个损失报告被抑制，这意味着超过60%的反馈实际上被抑制。
In this section, we want to investigate the effect of the parameter "l" on the T_dither_max calculation in RTP/AVPF agents. We investigate the feedback suppression performance as well as the report delay for three sample scenarios.
在本节中，我们希望研究参数“l”对RTP/AVPF代理中T_抖动_max计算的影响。我们研究了反馈抑制性能以及三个示例场景的报告延迟。
For all receivers, the T_dither_max value is calculated as T_dither_max = l * T_rr, with l = 0.5. The rationale for this is that, in general, if the receiver has no round-trip time (RTT) estimation, it does not know how long it should wait for other receivers to send feedback. The feedback suppression algorithm would certainly fail if the time selected is too short. However, the waiting time is increased unnecessarily (and thus the value of the feedback is decreased) in case the chosen value is too large. Ideally, the optimum time value could be found for each case, but this is not always feasible. On the other hand, it is not dangerous if the optimum time is not used. A decreased feedback value and a failure of the feedback suppression mechanism do not hurt the network stability. We have shown for the cases of distributed losses that the overall bandwidth constraints are kept in any case and thus we could only lose some performance by choosing the wrong time value. On the other hand, a good measure for T_dither_max is the RTCP interval T_rr. This value increases with the number of session members. Also, we know that we can send feedback at least every T_rr. Thus, increasing T_dither max beyond T_rr would certainly make no sense. So by choosing T_rr/2, we guarantee that at least sometimes (i.e., when a loss is detected in the first half of the interval between two regularly scheduled RTCP packets) we are allowed to send early packets. Because of the randomness of T_dither, we still have a good chance of sending the early packet in time.
对于所有接收机，T_抖动_max值计算为T_抖动_max=l*T_rr，l=0.5。其基本原理是，一般来说，如果接收器没有往返时间（RTT）估计，它不知道应该等待其他接收器发送反馈多长时间。如果选择的时间太短，反馈抑制算法肯定会失败。但是，如果选择的值太大，则等待时间会不必要地增加（从而降低反馈值）。理想情况下，可以为每种情况找到最佳时间值，但这并不总是可行的。另一方面，如果不使用最佳时间，则不会有危险。反馈值减小和反馈抑制机制失效不会影响网络稳定性。我们已经证明，对于分布式损耗的情况，总体带宽约束在任何情况下都是保持的，因此，我们只能通过选择错误的时间值来损失一些性能。另一方面，衡量T_抖动_max的一个好方法是RTCP间隔T_rr。该值随会话成员数的增加而增加。此外，我们知道我们至少可以在每个T_rr发送反馈。因此，将T_抖动最大值增加到T_rr之外肯定没有意义。因此，通过选择T_rr/2，我们保证至少有时（即，当在两个定期调度的RTCP数据包之间的前半个间隔内检测到丢失时）允许发送早期数据包。由于T_抖动的随机性，我们仍然有很好的机会及时发送早期数据包。
The AVPF profile specifies that the calculation of T_dither_max, as given above, is common to session members having an RTT estimation and to those not having it. If this were not so, participants using different calculations for T_dither_max might also have very different mean waiting times before sending feedback, which translates into different reporting priorities. For example, in a scenario where T_rr = 1 s and the RTT = 100 ms, receivers using the RTT estimation would, on average, send more feedback than those not using it. This might partially cancel out the feedback suppression mechanism and even cause feedback implosion. Also note that, in a general case where the losses are shared, the feedback suppression mechanism works if the feedback packets from each receiver have enough time to reach each of the other ones before the calculated T_dither_max seconds. Therefore, in scenarios of very high bandwidth (small T_rr), the calculated T_dither_max could be much smaller than the propagation delay between receivers, which would translate into a failure of the feedback suppression mechanism. In these cases, one solution could be to limit the bandwidth available to receivers (see [10]) such that this does not happen. Another solution could be to develop a mechanism for feedback suppression based on the RTT estimation between senders. This will not be discussed here and may be the subject of another document. Note, however, that a really high bandwidth media stream is not that likely to rely on this kind of error repair in the first place.
AVPF配置文件规定，如上所述，T_抖动_max的计算对于具有RTT估计的会话成员和没有RTT估计的会话成员是通用的。如果不是这样的话，对T_dither_max使用不同计算的参与者在发送反馈之前的平均等待时间也可能非常不同，这就转化为不同的报告优先级。例如，在T_rr=1 s且RTT=100 ms的场景中，使用RTT估计的接收器平均而言将发送比不使用它的接收器更多的反馈。这可能会部分抵消反馈抑制机制，甚至导致反馈内爆。还请注意，在分担损失的一般情况下，如果来自每个接收器的反馈分组在计算出的T_抖动_max秒之前有足够的时间到达其他每个接收器，则反馈抑制机制工作。因此，在非常高带宽（小T_rr）的情况下，计算出的T_抖动_max可能远小于接收机之间的传播延迟，这将导致反馈抑制机制失效。在这些情况下，一种解决方案是限制接收机可用的带宽（见[10]），这样就不会发生这种情况。另一个解决方案是开发一种基于发送方之间RTT估计的反馈抑制机制。这将不在这里讨论，可能是另一份文件的主题。然而，请注意，真正的高带宽媒体流最初不太可能依赖这种错误修复。
In the following, we define three representative sample scenarios. We use the topology from the previous section, T-16. Most of the agents contribute only little to the simulations, because we introduced an error rate only on the link between the sender A1 and the agent A2.
在下面，我们定义了三个具有代表性的示例场景。我们使用上一节T-16中的拓扑。大多数代理对模拟的贡献很小，因为我们只在发送方A1和代理A2之间的链路上引入了错误率。
The first scenario represents those cases, where losses are shared between two agents. One agent is located upstream on the path between the other agent and the sender. Therefore, agent A2 and agent A5 see the same losses that are introduced on the link between the sender and agent A2. Agents A6, A7, and A8 do not join the RTP session. From the other agents, only agents A3 and A9 join. All agents are pure receivers, except A1, which is the sender.
第一个场景表示两个代理分担损失的情况。一个代理位于另一个代理和发送方之间路径的上游。因此，代理A2和代理A5在发送方和代理A2之间的链路上看到相同的损失。代理A6、A7和A8不加入RTP会话。从其他代理中，只有代理A3和A9加入。所有代理都是纯接收者，A1除外，A1是发送者。
The second scenario also represents cases where losses are shared between two agents, but this time the agents are located on different branches of the multicast tree. The delays to the sender are roughly of the same magnitude. Agents A5 and A6 share the same losses. Agents A3 and A9 join the RTP session, but are pure receivers and do not see any losses.
第二个场景还表示两个代理之间共享损失的情况，但这次代理位于多播树的不同分支上。发送端的延迟大致相同。代理A5和A6分担相同的损失。代理A3和A9加入RTP会话，但它们是纯接收方，没有看到任何损失。
Finally, in the third scenario, the losses are shared between two agents, A5 and A6. The same agents as in the second scenario are
最后，在第三种情况下，损失由两个代理（A5和A6）分担。与第二个场景中相同的代理包括
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.
忙碌的然而，链路的延迟是不同的。代理A2和A5之间的链路延迟减少到20毫秒，代理A2和A6之间的链路延迟减少到40毫秒。
All agents beside agent A1 are pure RTP receivers. Thus, these agents do not have an RTT estimation to the source. T_dither_max is calculated with the above given formula, depending only on T_rr and l, which means that all agents should calculate roughly the same T_dither_max.
除代理A1之外的所有代理都是纯RTP接收器。因此，这些代理对源没有RTT估计。T_dither_max使用上述公式计算，仅取决于T_rr和l，这意味着所有代理应计算大致相同的T_dither_max。
The feedback suppression rate for an agent is defined as the ratio of the total number of feedback packets not sent out of the total number of feedback packets the agent intended to send (i.e., the sum of sent and not sent). The reasons for not sending a packet include: the receiver already saw the same loss reported in a receiver report coming from another session member or the max_feedback_delay (application-specific) was surpassed.
代理的反馈抑制率定义为未发送的反馈数据包总数与代理打算发送的反馈数据包总数的比率（即，已发送和未发送的总和）。不发送数据包的原因包括：接收器已经看到来自另一个会话成员的接收器报告中报告的相同丢失，或者超过了最大反馈延迟（特定于应用程序）。
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.
表5中描述了远离发送者的代理Af的反馈抑制率的结果。一般来说，可以看出反馈抑制率随着l的增加而增加。但是，根据环境的不同，存在一个阈值，从该阈值中，额外增益不再显著。
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.671 | 0.051 | 0.089 |
| 0.25 | 0.582 | 0.060 | 0.210 |
| 0.50 | 0.524 | 0.114 | 0.361 |
| 0.75 | 0.523 | 0.180 | 0.370 |
| 1.00 | 0.523 | 0.204 | 0.369 |
| 1.25 | 0.506 | 0.187 | 0.372 |
| 1.50 | 0.536 | 0.213 | 0.414 |
| 1.75 | 0.526 | 0.215 | 0.424 |
| 2.00 | 0.535 | 0.216 | 0.400 |
| 3.00 | 0.522 | 0.220 | 0.405 |
| 4.00 | 0.522 | 0.220 | 0.405 |
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.671 | 0.051 | 0.089 |
| 0.25 | 0.582 | 0.060 | 0.210 |
| 0.50 | 0.524 | 0.114 | 0.361 |
| 0.75 | 0.523 | 0.180 | 0.370 |
| 1.00 | 0.523 | 0.204 | 0.369 |
| 1.25 | 0.506 | 0.187 | 0.372 |
| 1.50 | 0.536 | 0.213 | 0.414 |
| 1.75 | 0.526 | 0.215 | 0.424 |
| 2.00 | 0.535 | 0.216 | 0.400 |
| 3.00 | 0.522 | 0.220 | 0.405 |
| 4.00 | 0.522 | 0.220 | 0.405 |
Table 5: Fraction of feedback that was suppressed at agent (Af) of the total number of feedback messages the agent wanted to send
表5：在代理（Af）处被抑制的反馈占代理想要发送的反馈消息总数的比例
Similar results can be seen in Table 6 for the agent An that is nearer to the sender.
对于离发送者较近的代理An，可以在表6中看到类似的结果。
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.056 | 0.056 | 0.090 |
| 0.25 | 0.063 | 0.055 | 0.166 |
| 0.50 | 0.116 | 0.099 | 0.255 |
| 0.75 | 0.141 | 0.141 | 0.312 |
| 1.00 | 0.179 | 0.175 | 0.352 |
| 1.25 | 0.206 | 0.176 | 0.361 |
| 1.50 | 0.193 | 0.193 | 0.337 |
| 1.75 | 0.197 | 0.204 | 0.341 |
| 2.00 | 0.207 | 0.207 | 0.368 |
| 3.00 | 0.196 | 0.203 | 0.359 |
| 4.00 | 0.196 | 0.203 | 0.359 |
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.056 | 0.056 | 0.090 |
| 0.25 | 0.063 | 0.055 | 0.166 |
| 0.50 | 0.116 | 0.099 | 0.255 |
| 0.75 | 0.141 | 0.141 | 0.312 |
| 1.00 | 0.179 | 0.175 | 0.352 |
| 1.25 | 0.206 | 0.176 | 0.361 |
| 1.50 | 0.193 | 0.193 | 0.337 |
| 1.75 | 0.197 | 0.204 | 0.341 |
| 2.00 | 0.207 | 0.207 | 0.368 |
| 3.00 | 0.196 | 0.203 | 0.359 |
| 4.00 | 0.196 | 0.203 | 0.359 |
Table 6: Fraction of feedback that was suppressed at agent (An) of the total number of feedback messages the agent wanted to send
表6：在代理（An）处被抑制的反馈占代理想要发送的反馈消息总数的比例
The rate of feedback suppression failure is depicted in Table 7. The trend of additional performance increase is not significant beyond a certain threshold. Dependence on the scenario is noticeable here as well.
反馈抑制故障率如表7所示。超过一定阈值后，额外性能增加的趋势并不显著。对场景的依赖在这里也很明显。
| |Feedback Suppr. Failure Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.273 | 0.893 | 0.822 |
| 0.25 | 0.355 | 0.885 | 0.624 |
| 0.50 | 0.364 | 0.787 | 0.385 |
| 0.75 | 0.334 | 0.679 | 0.318 |
| 1.00 | 0.298 | 0.621 | 0.279 |
| 1.25 | 0.289 | 0.637 | 0.267 |
| 1.50 | 0.274 | 0.595 | 0.249 |
| 1.75 | 0.274 | 0.580 | 0.235 |
| 2.00 | 0.258 | 0.577 | 0.233 |
| 3.00 | 0.282 | 0.577 | 0.236 |
| 4.00 | 0.282 | 0.577 | 0.236 |
| |Feedback Suppr. Failure Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.273 | 0.893 | 0.822 |
| 0.25 | 0.355 | 0.885 | 0.624 |
| 0.50 | 0.364 | 0.787 | 0.385 |
| 0.75 | 0.334 | 0.679 | 0.318 |
| 1.00 | 0.298 | 0.621 | 0.279 |
| 1.25 | 0.289 | 0.637 | 0.267 |
| 1.50 | 0.274 | 0.595 | 0.249 |
| 1.75 | 0.274 | 0.580 | 0.235 |
| 2.00 | 0.258 | 0.577 | 0.233 |
| 3.00 | 0.282 | 0.577 | 0.236 |
| 4.00 | 0.282 | 0.577 | 0.236 |
Table 7: The ratio of feedback suppression failures.
表7：反馈抑制故障的比率。
Summarizing the feedback suppression results, it can be said that in general the feedback suppression performance increases as l increases. However, beyond a certain threshold, depending on environment parameters such as propagation delays or session bandwidth, the additional increase is not significant anymore. This threshold is not uniform across all scenarios; a value of l=0.5 seems to produce reasonable results with acceptable (though not optimal) overhead.
总结反馈抑制结果，可以说，一般来说，反馈抑制性能随着l的增加而增加。但是，超过某个阈值后，根据传播延迟或会话带宽等环境参数，额外的增加不再显著。该阈值并非在所有场景中都是一致的；l=0.5的值似乎可以产生合理的结果，但开销可以接受（尽管不是最优的）。
In this section, we show the results for the measured report delay during the simulations of the three sample scenarios. This measurement is a metric of the performance of the algorithms, because the value of the feedback for the sender typically decreases with the delay of its reception. The loss report delay is measured as the time at the sender between sending a packet and receiving the first corresponding loss report.
在本节中，我们将展示在三个示例场景的模拟过程中测量的报告延迟的结果。该度量是算法性能的度量，因为发送方的反馈值通常随接收延迟而降低。丢失报告延迟测量为发送方发送数据包和接收第一个相应丢失报告之间的时间。
| | 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.
表8：在发送方测量的平均损失报告延迟。
As can be seen from Table 8, the delay increases, in general, as l increases. Also, a similar effect as for the feedback suppression performance is present: beyond a certain threshold, the additional increase in delay is not significant anymore. The threshold is environment dependent and seems to be related to the threshold, where the feedback suppression gain would not increase anymore.
从表8可以看出，延迟通常随着l的增加而增加。此外，反馈抑制性能也存在类似的影响：超过某个阈值后，延迟的额外增加不再显著。阈值取决于环境，似乎与阈值有关，此时反馈抑制增益不再增加。
We have shown experimentally that the performance of the feedback suppression mechanisms increases as l increases. The same applies for the report delay, which also increases as l increases. This leads to a threshold where both the performance and the delay do not increase any further. The threshold is dependent upon the environment.
我们的实验表明，反馈抑制机制的性能随着l的增加而增加。这同样适用于报告延迟，它也随着l的增加而增加。这会导致性能和延迟不会进一步增加的阈值。阈值取决于环境。
So finding an optimum value of l is not possible because it is always a trade-off between delay and feedback suppression performance. With l=0.5, we think that a trade-off was found that is acceptable for typical applications and environments.
因此，找到l的最佳值是不可能的，因为它始终是延迟和反馈抑制性能之间的权衡。当l=0.5时，我们认为找到了一个折衷方案，这对于典型的应用程序和环境是可以接受的。
NEWPRED is one of the error resilience tools, which is defined in both ISO/IEC MPEG-4 visual part and ITU-T H.263. NEWPRED achieves fast error recovery using feedback messages. We simulated the behavior of NEWPRED in the network simulator environment as described above and measured the waiting time statistics, in order to verify that the extended RTP profile for RTCP-based feedback (AVPF) [1] is appropriate for the NEWPRED feedback messages. Simulation results, which are presented in the following sections, show that the waiting time is small enough to get the expected performance of NEWPRED.
NEWPRED是差错恢复工具之一，它在ISO/IEC MPEG-4视频部分和ITU-T H.263中都有定义。NEWPRED使用反馈消息实现快速错误恢复。如上所述，我们在网络模拟器环境中模拟了NEWPRED的行为，并测量了等待时间统计数据，以验证基于RTCP的反馈（AVPF）[1]的扩展RTP配置文件适用于NEWPRED反馈消息。以下部分给出的仿真结果表明，等待时间足够小，可以获得NEWPRED的预期性能。
The agent that performs the NEWPRED functionality, called NEWPRED agent, is different from the RTP agent we described above. Some of the added features and functionalities are described in the following points:
执行NEWPRED功能的代理称为NEWPRED代理，它不同于我们上面描述的RTP代理。以下几点描述了一些添加的特性和功能：
Application Feedback The "Application Layer Feedback Messages" format is used to transmit the NEWPRED feedback messages. Thereby the NEWPRED functionality is added to the RTP agent. The NEWPRED agent creates one NACK message for each lost segment of a video frame, and then assembles multiple NACK messages corresponding to the segments in the same video frame into one Application Layer Feedback Message. Although there are two modes, namely, NACK mode and ACK mode, in NEWPRED [6][7], only NACK mode is used in these simulations. In this simulation, the RTP layer doesn't generate feedback messages. Instead, the decoder (NEWPRED) generates a NACK message when the segment cannot be decoded because the data hasn't arrived or loss of reference picture has occurred. Those conditions are detected in the decoder with frame number, segment number, and existence of reference pictures in the decoder.
应用反馈“应用层反馈消息”格式用于传输NEWPRED反馈消息。因此，NEWPRED功能被添加到RTP代理中。NEWPRED代理为视频帧的每个丢失片段创建一条NACK消息，然后将与同一视频帧中的片段对应的多条NACK消息组合成一条应用层反馈消息。尽管在NEWPRED[6][7]中有两种模式，即NACK模式和ACK模式，但在这些模拟中仅使用NACK模式。在此模拟中，RTP层不生成反馈消息。相反，解码器（NEWPRED）在由于数据未到达或参考图片丢失而无法解码段时生成NACK消息。这些条件在解码器中通过帧编号、段编号和解码器中参考图片的存在来检测。
The parameters of NEWPRED agent are as follows:
NEWPRED代理的参数如下：
f: Frame Rate(frames/sec)
seg: Number of segments in one video frame
bw: RTP session bandwidth(kbps)
f: Frame Rate(frames/sec)
seg: Number of segments in one video frame
bw: RTP session bandwidth(kbps)
Generation of NEWPRED's NACK Messages The NEWPRED agent generates NACK messages when segments are lost.
生成NEWPRED的NACK消息当段丢失时，NEWPRED代理生成NACK消息。
a. The NEWPRED agent generates multiple NACK messages per one video frame when multiple segments are lost. These are assembled into one Feedback Control Information (FCI) message per video frame. If there is no lost segment, no message is generated and sent.
a. 当多个片段丢失时，NEWPRED代理会在每个视频帧中生成多个NACK消息。每个视频帧将这些信息组合成一条反馈控制信息（FCI）消息。如果没有丢失的段，则不会生成和发送消息。
b. The length of one NACK message is 4 bytes. Let num be the number of NACK messages in one video frame (1 <= num <= seg). Thus, 12+4*num bytes is the size of the low-delay RTCP feedback message in a compound RTCP packet.
b. 一条NACK消息的长度为4字节。设num为一个视频帧中NACK消息的数量（1<=num<=seg）。因此，12+4*num字节是复合RTCP数据包中低延迟RTCP反馈消息的大小。
Measurements We defined two values to be measured:
测量我们定义了两个要测量的值：
- 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)
(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
(Waiting time) = (Recovery time) - (Round-trip delay), where
(Round-trip delay ) = (Transmission time for feedback message) +
(Transmission time for media data)
(Round-trip delay ) = (Transmission time for feedback message) +
(Transmission time for media data)
Picture Reference |: Picture Segment
____________________ %: Lost Segment
/_ _ _ _ \
v/ \ / \ / \ / \ \
v \v \v \v \ \
Sender ---|----|----|----|----|----|---|------------->
\ \ ^ \
\ \ / \
\ \ / \
\ v / \
\ x / \
\ Lost / \
\ x / \
_____
v x / NACK v
Receiver ---------------|----%===-%----%----%----|----->
|-a-| |
|------- b -------|
Picture Reference |: Picture Segment
____________________ %: Lost Segment
/_ _ _ _ \
v/ \ / \ / \ / \ \
v \v \v \v \ \
Sender ---|----|----|----|----|----|---|------------->
\ \ ^ \
\ \ / \
\ \ / \
\ v / \
\ x / \
\ Lost / \
\ x / \
_____
v x / NACK v
Receiver ---------------|----%===-%----%----%----|----->
|-a-| |
|------- b -------|
a: Waiting time b: Recover time (%: Video segments are lost)
a：等待时间b：恢复时间（%：视频片段丢失）
Figure 2: Relation between the measured values at the NEWPRED agent
图2:NEWPRED代理处测量值之间的关系
We conducted two simulations (Simulation A and Simulation B). In Simulation A, the packets are dropped with a fixed packet loss rate on a link between two NEWPRED agents. In Simulation B, packet loss occurs due to congestion from other traffic sources, i.e., ftp sessions.
我们进行了两次模拟（模拟A和模拟B）。在模拟A中，在两个NEWPRED代理之间的链路上以固定的丢包率丢弃数据包。在模拟B中，由于来自其他流量源（即ftp会话）的拥塞而发生数据包丢失。
The network topology used for this simulation is shown in Figure 3.
用于此模拟的网络拓扑如图3所示。
Link 1 Link 2 Link 3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ +------+ +------+ +--------+
10(msec) x(msec) 10(msec)
Link 1 Link 2 Link 3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ +------+ +------+ +--------+
10(msec) x(msec) 10(msec)
Figure 3: Network topology that is used for Simulation A
图3：用于模拟的网络拓扑
Link1 and link3 are error free, and each link delay is 10 msec. Packets may get dropped on link2. The packet loss rates (Plr) and link delay (D) are as follows:
链路1和链路3无错误，每个链路延迟为10毫秒。数据包可能在链路2上被丢弃。分组丢失率（Plr）和链路延迟（D）如下所示：
D [ms] = {10, 50, 100, 200, 500}
Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}
D [ms] = {10, 50, 100, 200, 500}
Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}
Session bandwidth, frame rate, and the number of segments are shown in Table 9.
会话带宽、帧速率和段数如表9所示。
+------------+----------+-------------+-----+
|Parameter ID| bw(kbps) |f (frame/sec)| seg |
+------------+----------+-------------+-----+
| 32k-4-3 | 32 | 4 | 3 |
| 32k-5-3 | 32 | 5 | 3 |
| 64k-5-3 | 64 | 5 | 3 |
| 64k-10-3 | 64 | 10 | 3 |
| 128k-10-6 | 128 | 10 | 6 |
| 128k-15-6 | 128 | 15 | 6 |
| 384k-15-6 | 384 | 15 | 6 |
| 384k-30-6 | 384 | 30 | 6 |
| 512k-30-6 | 512 | 30 | 6 |
| 1000k-30-9 | 1000 | 30 | 9 |
| 2000k-30-9 | 2000 | 30 | 9 |
+------------+----------+-------------+-----+
+------------+----------+-------------+-----+
|Parameter ID| bw(kbps) |f (frame/sec)| seg |
+------------+----------+-------------+-----+
| 32k-4-3 | 32 | 4 | 3 |
| 32k-5-3 | 32 | 5 | 3 |
| 64k-5-3 | 64 | 5 | 3 |
| 64k-10-3 | 64 | 10 | 3 |
| 128k-10-6 | 128 | 10 | 6 |
| 128k-15-6 | 128 | 15 | 6 |
| 384k-15-6 | 384 | 15 | 6 |
| 384k-30-6 | 384 | 30 | 6 |
| 512k-30-6 | 512 | 30 | 6 |
| 1000k-30-9 | 1000 | 30 | 9 |
| 2000k-30-9 | 2000 | 30 | 9 |
+------------+----------+-------------+-----+
Table 9: Parameter sets of the NEWPRED agents
表9:NEWPRED代理的参数集
Figure 4 shows the key values of the result (packet loss rate vs. mean of waiting time).
图4显示了结果的关键值（丢包率与平均等待时间）。
When the packet loss rate is 5% and the session bandwidth is 32 kbps, the waiting time is around 400 msec, which is just allowable for reasonable NEWPRED performance.
当丢包率为5%且会话带宽为32 kbps时，等待时间约为400 ms，这仅允许合理的NEWPRED性能。
When the packet loss rate is less than 1%, the waiting time is less than 200 msec. In such a case, the NEWPRED allows as much as 200-msec additional link delay.
当分组丢失率小于1%时，等待时间小于200毫秒。在这种情况下，NEWPRED允许高达200毫秒的额外链路延迟。
When the packet loss rate is less than 5% and the session bandwidth is 64 kbps, the waiting time is also less than 200 msec.
当丢包率小于5%且会话带宽为64 kbps时，等待时间也小于200毫秒。
In 128-kbps cases, the result shows that when the packet loss rate is 20%, the waiting time is around 200 msec. In cases with more than 512-kbps session bandwidth, there is no significant delay. This means that the waiting time due to the feedback limitation of RTCP is negligible for the NEWPRED performance.
在128kbps的情况下，结果表明，当丢包率为20%时，等待时间约为200ms。在会话带宽超过512 kbps的情况下，没有明显的延迟。这意味着由于RTCP的反馈限制而导致的等待时间对于NEWPRED的性能可以忽略不计。
+------------------------------------------------------------+
| | Packet Loss Rate = |
| Bandwidth | 0.005| 0.01 | 0.02 | 0.03 | 0.05 |0.10 |0.20 |
|-----------+------+------+------+------+------+------+------|
| 32k |130- |200- |230- |280- |350- |470- |560- |
| | 180| 250| 320| 390| 430| 610| 780|
| 64k | 80- |100- |120- |150- |180- |210- |290- |
| | 130| 150| 180| 190| 210| 300| 400|
| 128k | 60- | 70- | 90- |110- |130- |170- |190- |
| | 70| 80| 100| 120| 140| 190| 240|
| 384k | 30- | 30- | 30- | 40- | 50- | 50- | 50- |
| | 50| 50| 50| 50| 60| 70| 90|
| 512k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 60 |
| | | | | | | | |
| 1000k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 55 |
| | | | | | | | |
| 2000k | < 30 | < 30 | < 30 | < 30 | < 30 | < 35 | < 35 |
+------------------+------+------+------+------+------+------+
+------------------------------------------------------------+
| | Packet Loss Rate = |
| Bandwidth | 0.005| 0.01 | 0.02 | 0.03 | 0.05 |0.10 |0.20 |
|-----------+------+------+------+------+------+------+------|
| 32k |130- |200- |230- |280- |350- |470- |560- |
| | 180| 250| 320| 390| 430| 610| 780|
| 64k | 80- |100- |120- |150- |180- |210- |290- |
| | 130| 150| 180| 190| 210| 300| 400|
| 128k | 60- | 70- | 90- |110- |130- |170- |190- |
| | 70| 80| 100| 120| 140| 190| 240|
| 384k | 30- | 30- | 30- | 40- | 50- | 50- | 50- |
| | 50| 50| 50| 50| 60| 70| 90|
| 512k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 60 |
| | | | | | | | |
| 1000k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 55 |
| | | | | | | | |
| 2000k | < 30 | < 30 | < 30 | < 30 | < 30 | < 35 | < 35 |
+------------------+------+------+------+------+------+------+
Figure 4: The result of simulation A
图4：模拟A的结果
The configurations of link1, link2, and link3 are the same as in Simulation A except that link2 is also error-free, regarding bit errors. However, in addition, some FTP agents are deployed to overload link2. See Figure 5 for the simulation topology.
link1、link2和link3的配置与模拟A中的配置相同，只是link2在比特错误方面也是无错误的。但是，此外，还部署了一些FTP代理来重载link2。有关仿真拓扑，请参见图5。
Link1 Link2 Link3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ /|+------+ +------+|\ +--------+
+---+/ | | \+---+
+-|FTP|+---+ +---+|FTP|-+
| +---+|FTP| ... |FTP|+---+ | ...
+---+ +---+ +---+ +---+
Link1 Link2 Link3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ /|+------+ +------+|\ +--------+
+---+/ | | \+---+
+-|FTP|+---+ +---+|FTP|-+
| +---+|FTP| ... |FTP|+---+ | ...
+---+ +---+ +---+ +---+
FTP Agents FTP Agents
FTP代理FTP代理
Figure 5: Network Topology of Simulation B
图5：模拟B的网络拓扑
The parameters are defined as for Simulation A with the following values assigned:
参数定义为模拟A，并指定了以下值：
D[ms] ={10, 50, 100, 200, 500} 32 FTP agents are deployed at each edge, for a total of 64 FTP agents active.
D[ms]={10,50,100,200,500}每个边缘部署32个FTP代理，总共有64个FTP代理处于活动状态。
The sets of session bandwidth, frame rate, and the number of segments are the same as in Simulation A (Table 9).
会话带宽、帧速率和段数的设置与模拟A中的相同（表9）。
We provide the results for the cases with 64 FTP agents, because these are the cases where packet losses could be detected to be stable. The results are similar to those for Simulation A except for a constant additional offset of 50..100 ms. This is due to the delay incurred by the routers' buffers.
我们提供了64个FTP代理的结果，因为在这些情况下，可以检测到数据包丢失是稳定的。除了50..100 ms的恒定附加偏移量外，结果与模拟A的结果类似。这是由于路由器缓冲区产生的延迟。
We have shown that the limitations of RTP AVPF profile do not generate such high delay in the feedback messages that the performance of NEWPRED is degraded for sessions from 32 kbps to 2 Mbps. We could see that the waiting time increases with a decreasing session bandwidth and/or an increasing packet loss rate. The cause of the packet loss is not significant; congestion and constant packet loss rates behave similarly. Still we see that for reasonable conditions and parameters the AVPF is well suited to support the feedback needed for NEWPRED. For more information about NEWPRED, see [8] and [9].
我们已经证明，RTP AVPF配置文件的局限性不会在反馈消息中产生如此高的延迟，以至于对于从32 kbps到2 Mbps的会话，NEWPRED的性能会降低。我们可以看到，等待时间随着会话带宽的减少和/或分组丢失率的增加而增加。丢包原因不明显；拥塞和恒定的数据包丢失率表现类似。我们仍然看到，对于合理的条件和参数，AVPF非常适合支持NEWPRED所需的反馈。有关NEWPRED的更多信息，请参见[8]和[9]。
The new RTP profile AVPF was investigated regarding performance and potential risks to the network stability. Simulations were conducted using the network simulator ns2, simulating unicast and several differently sized multicast topologies. The results were shown in this document.
研究了新的RTP配置文件AVPF的性能和对网络稳定性的潜在风险。使用网络模拟器ns2进行模拟，模拟单播和几种不同大小的多播拓扑。结果见本文件。
Regarding the network stability, it was important to show that the new profile does not lead to any feedback implosion or use more bandwidth than it is allowed. We measured the bandwidth that was used for RTCP in relation to the RTP session bandwidth. We have shown that, more or less exactly, 5% of the session bandwidth is used for RTCP, in all considered scenarios. Other RTCP bandwidth values could be set using the RTCP bandwidth modifiers [10]. The scenarios included unicast with and without errors, differently sized multicast groups, with and without errors or congestion on the links. Thus, we can say that the new profile behaves in a network-friendly manner in the sense that it uses only the allowed RTCP bandwidth, as defined by RTP.
关于网络稳定性，重要的是要表明新的配置文件不会导致任何反馈内爆或使用超出允许范围的带宽。我们测量了RTCP使用的带宽与RTP会话带宽的关系。我们已经证明，在所考虑的所有场景中，大约5%的会话带宽用于RTCP。可以使用RTCP带宽修饰符设置其他RTCP带宽值[10]。这些场景包括有无错误的单播、大小不同的多播组、链路上有无错误或拥塞。因此，我们可以说，新配置文件以网络友好的方式运行，即它只使用RTP定义的允许RTCP带宽。
Secondly, we have shown that receivers using the new profile experience a performance gain. This was measured by capturing the delay that the sender sees for the received feedback. Using the new profile, this delay can be decreased by orders of magnitude.
其次，我们已经证明，使用新配置文件的接收机会获得性能增益。这是通过捕获发送者看到的接收反馈的延迟来测量的。使用新的配置文件，该延迟可以减少几个数量级。
In the third place, we investigated the effect of the parameter "l" on the new algorithms. We have shown that there does not exist an optimum value for it but only a trade-off can be achieved. The influence of this parameter is highly environment-specific and a trade-off between performance of the feedback suppression algorithm and the experienced delay has to be met. The recommended value of l=0.5 given in this document seems to be reasonable for most applications and environments.
第三，我们研究了参数“l”对新算法的影响。我们已经证明，它不存在一个最优值，但只能实现一个折衷。该参数的影响具有高度的环境特异性，必须在反馈抑制算法的性能和所经历的延迟之间进行权衡。本文档中给出的l=0.5的建议值对于大多数应用程序和环境来说似乎是合理的。
This document describes the simulation work carried out to verify the correct working of the RTCP timing rules specified in the AVPF profile [1]. Consequently, security considerations concerning these timing rules are described in that document.
本文件描述了为验证AVPF配置文件[1]中规定的RTCP定时规则的正确工作而进行的模拟工作。因此，该文件中描述了有关这些定时规则的安全考虑。
[1] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[1] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[3] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[4] Network Simulator Version 2 - ns-2, available from http://www.isi.edu/nsnam/ns.
[4] 网络模拟器版本2-ns-2，可从http://www.isi.edu/nsnam/ns.
[5] C. Burmeister, T. Klinner, "Low Delay Feedback RTCP - Timing Rules Simulation Results". Technical Report of the Panasonic European Laboratories, September 2001, available from: http://www.informatik.uni-bremen.de/~jo/misc/ SimulationResults-A.pdf.
[5] C.Burmeister，T.Kliner，“低延迟反馈RTCP-时序规则模拟结果”。松下欧洲实验室技术报告，2001年9月，可从以下网址获得：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/IEC 14496-2:1999/Amd.1:2000，“信息技术-视听对象编码-第2部分：视觉”，2000年7月。
[7] ITU-T Recommendation, H.263. Video encoding for low bitrate communication. 1998.
[7] ITU-T建议，H.263。用于低比特率通信的视频编码。1998
[8] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video Coding by Dynamic Replacing of Reference Pictures", IEEE Global Telecommunications Conference (GLOBECOM), pp.1503-1508, 1996.
[8] S.Fukunaga，T.Nakai和H.Inoue，“通过动态替换参考图片的抗错误视频编码”，IEEE全球电信会议（GLOBECOM），第1503-15081996页。
[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] Kimata，Y.Tomita，H.Yamaguchi，S.Ichinose，T.Ichikawa，“面向接收器的实时容错视频通信系统：根据接收器处的内存大小从错误传播中自适应恢复”，日本电子与通信，第1部分，第84卷，第2期，第8-17页，2001年。
[10] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[10] Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
Authors' Addresses
作者地址
Carsten Burmeister Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Carsten Burmeister松下研发中心德国有限公司Monzastr。4c D-63225兰根，德国
EMail: carsten.burmeister@eu.panasonic.com
EMail: carsten.burmeister@eu.panasonic.com
Rolf Hakenberg Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Rolf Hakenberg松下研发中心德国有限公司Monzastr。4c D-63225兰根，德国
EMail: rolf.hakenberg@eu.panasonic.com
EMail: rolf.hakenberg@eu.panasonic.com
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
日本大阪市嘉道理市嘉道理宫崎松下电器工业有限公司1006
EMail: miyazaki.akihiro@jp.panasonic.com
EMail: miyazaki.akihiro@jp.panasonic.com
Joerg Ott Helsinki University of Technology, Networking Laboratory PO Box 3000, 02015 TKK, Finland
芬兰赫尔辛基工业大学TKK网络实验室PO盒3000, 02015
EMail: jo@acm.org
EMail: jo@acm.org
Noriyuki Sato Oki Electric Industry Co., Ltd. 1-16-8 Chuo, Warabi, Saitama 335-8510 Japan
Noriyuki Sato Oki电气工业有限公司，日本柴达木市瓦拉比中环1-16-8号，邮编335-8510
EMail: sato652@oki.com
EMail: sato652@oki.com
Shigeru Fukunaga Oki Electric Industry Co., Ltd. 2-5-7 Hommachi, Chuo-ku, Osaka 541-0053 Japan
日本大阪中央区Hommachi 2-5-7号福永茂Oki电气工业有限公司541-0053
EMail: fukunaga444@oki.com
EMail: fukunaga444@oki.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。