Request for Comments: 4586 R. Hakenberg
Category: Informational A. Miyazaki
Panasonic
J. Ott
Helsinki University of Technology
N. Sato
S. Fukunaga
Oki
July 2006
Extended RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback:
Results of the Timing Rule Simulations
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
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.
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
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 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.
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.).
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].
This document investigates the new algorithms by the means of
simulations. We show that the new timing rules scale well and behave
in a network-friendly manner. Firstly, the key features of the new
RTP profile that are important for our simulations are roughly
described in Section 2. After that, we describe in Section 3 the
environment that is used to conduct the simulations. Section 4
describes simulation results that show the backwards compatibility to
RTP and that the new profile is network-friendly in terms of used
bandwidth for RTCP traffic. In Section 5, we show the benefit that
applications could get from implementing the new profile. In Section
6, we investigated the effect of the parameter "l" (used to calculate
the T_dither_max value) upon the algorithm performance, and finally,
in Section 7, we show the performance gain we could get for a special
application, namely, NEWPRED in [6] and [7].
2. Timing Rules of the Extended RTP Profile for RTCP-Based Feedback
As said above, RTP restricts the usage of RTCP feedback. The main
restrictions on RTCP are as follows:
- 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.
- 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.)
- The average minimum interval between two RTCP packets from the same
source is 5 seconds.
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.
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].
3. Simulation Environment
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
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].
3.2. RTP Agent
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.
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.
3.3. Scenarios
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.
The feedback messages are generally NACK messages as defined in [1]
and are triggered by packet loss.
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.
A5
A5 | A6
/ | /
/ | /--A7
/ |/
A2 A2-----A6 A2--A8
/ / / A9
/ / / /
/ / / /---A10
A1-----A2 A1-----A3 A1-----A3-----A7 A1------A3<
\ \ \ \---A11
\ \ \ \
\ \ \ A12
A4 A4-----A8 A4--A13
|\
| \--A14
| \
| A15
A16
T-2 T-4 T-8 T-16
Figure 1: Simulated topologies
4. RTCP Bit Rate Measurements
The new timing rules allow more frequent RTCP feedback for small
multicast groups. In large groups, the algorithm behaves similarly
to the normal RTCP timing rules. While it is generally good to
have more frequent feedback, it cannot be allowed at all to
increase the bit rate used for RTCP above a fixed limit, i.e., 5%
of the total RTP bandwidth according to RTP. This section shows
that the new timing rules keep RTCP bandwidth usage under the 5%
limit for all investigated scenarios, topologies, and group sizes.
Furthermore, we show that mixed groups (some members using
AVP, some AVPF) can be allowed and that each session member behaves
fairly according to its corresponding specification. Note that
other values for the RTCP bandwidth limit may be specified using
the RTCP bandwidth modifiers as in [10].
4.1. Unicast
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.
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.
| | | | | | 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
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.
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.
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.
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.
| | | | | | 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 |