[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 rfc4586                                  
                                                          C.Burmeister
Internet Draft                                             R.Hakenberg
draft-burmeister-avt-rtcp-feedback-sim-00.txt               A.Miyazaki
Expires: April 2002                                         Matsushita

                                                                 J.Ott
                                              University of Bremen TZI

                                                                N.Sato
                                                            S.Fukunaga
                                                                   Oki

                                                         November 2001



               Extended RTP Profile for RTCP-based Feedback
                - Results of the Timing Rule Simulations -


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This document describes the results we achieved when simulating the
   timing rules of the Extended RTP Profile for RTCP-based Feedback.
   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.




Burmeister et al.          Expires May 2002                          1
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



Table of Contents

   Status of this Memo
   Abstract

   1 Introduction

   2 Conventions used in this document

   3 Timing rules of the extended RTP profile for RTCP-based feedback

   4 Simulation Environment
     4.1 Network Simulator Version 2
     4.2 RTP Agent
     4.3 Scenarios
     4.4 Topologies

   5 RTCP Bit Rate Measurements
     5.1 Unicast
     5.2 Multicast
     5.3 Summary of the RTCP bit rate measurements

   6 Feedback Measurements
     6.1 Unicast
     6.2 Multicast
       6.2.1 Shared Losses vs Distributed Losses
       6.2.2 Sender vs. Receiver

   7 Investigations on "k"
     7.1 Feedback Suppression Performance
     7.2 Loss Report Delay
     7.3 Summary of "k" investigations

   8 Investigations on "l"
     8.1 Feedback Suppression Performance
     8.2 Loss Report Delay
     8.3 Summary of "l" investigations

   9 Applications Using AVPF
     9.1 NEWPRED Implementation in NS2
     9.2 Simulation
       9.2.1. Simulation A - Constant Packet Loss Rate
       9.2.2. Simulation B - Packet Loss due to Congestion
     9.3 Summary

   10 Summary

   References
   Authors Addresses


Burmeister et al.          Expires May 2002                          2
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



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. 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.
   What is more it can be used for a loosely session control. Having
   the scope of large multicast groups in mind, the rules when to send
   feedback were much 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 its tremendous usages 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 might be able to react to
   changes in the reception quality, which might be due to congestion
   in the network or other sudden changes. Possible reactions include
   sending 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 said before, more feedback would be needed to increase the
   reception quality, but RTP restricts the use of RTCP feedback very
   much. 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 and behave
   network friendly. Therefore we first describe roughly the key
   features of the new RTP profile, which are important for our
   simulations, in Section 3. After that we describe the environment
   that is used to conduct the simulations in Section 4. Section 5
   describes simulation results that show the backwards compatibility
   to RTP and that the new profile is network friendly in terms of used
   bit rate for feedback and other control traffic. In Section 6 we
   show the benefit that applications could get from implementing the
   new profile. In Section 7 and 8 we show the merit for some special


Burmeister et al.          Expires May 2002                          3
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   parameters settings and finally in section 9 we show the performance
   gain we could get for a special application, namely NEWPRED in
   MPEG-4.


2 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119.


3 Timing rules of the extended RTP profile for RTCP-based feedback

   As said above, RTP restricts the usage of RTCP feedback. The main
   rules that restrict the feedback 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
     is 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
     might get more than the receivers.)
   - The minimum interval between two RTCP packets from the same source
     is 5 seconds.

   We see that these rules prevent feedback explosion and scale to very
   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 prevents the receivers from sending
   feedback in time.

   The timing rules to send RTCP feedback from the new RTP profile [1]
   consists of two key components. First the minimum interval of 5
   seconds is abolished. Second, receivers get once during their (now
   quite small) RTCP interval the chance 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]. We do not want to describe the algorithms here,
   but rather reference these from the original specification where
   needed. Therefore we use also the same variable names and
   abbreviations as in [1].


Burmeister et al.          Expires May 2002                          4
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



4 Simulation Environment

   This section describes the simulator that was used for the
   investigations and its key features. The extensions to the
   simulator, that were necessary are described roughly.


4.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. In 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 itself are implemented in C++ in the agents, which are
   connected to the nodes. A detailed description of ns2 and a
   downloadable newest version can be found at [4].


4.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 also its
   algorithms for group membership maintenance are implemented. Sender
   and receiver reports are sent and the senders use these reports to
   maintain a RTT estimation to the other group members, as it is
   described in [2].

   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.


4.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 used sending rates 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.




Burmeister et al.          Expires May 2002                          5
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



4.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, which is then indicated
   at 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. The figures below illustrate 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.


5 RTCP Bit Rate Measurements

   The new timing rules allow more frequent RTCP feedback for small
   multicast groups. In large groups the algorithm behaves similar to
   usual RTP. 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 with the new timing rules we keep the
   5% limit for all investigated scenarios, topologies and group sizes.
   What is more, we show that mixed groups, i.e. some members use AVP
   some use AVPF, can be allowed and that each session member behaves
   fair according to its corresponding specification.




Burmeister et al.          Expires May 2002                          6
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



5.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 which are varied to simulate a large range of
   different scenarios. First we varied the RTP session bandwidth. For
   large session bandwidths, the allowed RTCP bit rate increases also
   and thus more RTCP packets can be sent. Second we changed the number
   of agents that are pure receivers or also senders. This has also
   some influence on the RTCP feedback, because on the one hand pure
   receivers do not have an RTT estimation and one the other hand they
   do not send sender reports. Third we varied the configurations of
   the agents in that sense that the agents may use the 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.

   First 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 the AVPF, and use the
   minimum interval of 5s if they implement the AVP. No early packets
   are sent, because the need to send 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 co-exist 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   | 1,2  | 0.01 | 2.49 | 2.50 |
   |  2 Mbps | 1,2  |  -   |  1   | 1,2  | 0.01 | 2.48 | 2.49 |
   |  2 Mbps |  1   |  2   | 1,2  | 1,2  | 0.01 | 0.01 | 0.02 |
   |  2 Mbps | 1,2  |  -   | 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   | 1,2  | 0.06 | 2.49 | 2.55 |
   |200 kbps | 1,2  |  -   |  1   | 1,2  | 0.08 | 2.50 | 2.58 |
   |200 kbps |  1   |  2   | 1,2  | 1,2  | 0.06 | 0.06 | 0.12 |
   |200 kbps | 1,2  |  -   | 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   | 1,2  | 0.58 | 2.48 | 3.06 |
   | 20 kbps | 1,2  |  -   |  1   | 1,2  | 0.77 | 2.51 | 3.28 |
   | 20 kbps |  1   |  2   | 1,2  | 1,2  | 0.58 | 0.61 | 1.19 |
   | 20 kbps | 1,2  |  -   | 1,2  | 1,2  | 0.77 | 0.79 | 1.58 |

   Table 1: Unicast simulations without packet loss.



Burmeister et al.          Expires May 2002                          7
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   We can see that in configurations, where both Agents use the new
   timing rules each of them uses 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 Agent1 uses AVP and Agent2 AVPF, the total RTCP
   session bandwidth is decreased. This is due to the fact that Agent1
   can send RTCP packets only with a 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 one 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 2 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 with 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 the agents detect a packet loss, they feel the need to send
   feedback. 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 losses occur or not.
   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, but the
   packet size increased because of the feedback that is appended.











Burmeister et al.          Expires May 2002                          8
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   |         |      |      |      |      | 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   | 1,2  | 0.01 | 2.49 | 2.50 |
   |  2 Mbps | 1,2  |  -   |  1   | 1,2  | 0.01 | 2.48 | 2.49 |
   |  2 Mbps |  1   |  2   | 1,2  | 1,2  | 0.01 | 0.02 | 0.03 |
   |  2 Mbps | 1,2  |  -   | 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   | 1,2  | 0.06 | 2.50 | 2.56 |
   |200 kbps | 1,2  |  -   |  1   | 1,2  | 0.08 | 2.49 | 2.57 |
   |200 kbps |  1   |  2   | 1,2  | 1,2  | 0.06 | 0.07 | 0.13 |
   |200 kbps | 1,2  |  -   | 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   | 1,2  | 0.58 | 2.54 | 3.12 |
   | 20 kbps | 1,2  |  -   |  1   | 1,2  | 0.83 | 2.43 | 3.26 |
   | 20 kbps |  1   |  2   | 1,2  | 1,2  | 0.58 | 0.73 | 1.31 |
   | 20 kbps | 1,2  |  -   | 1,2  | 1,2  | 0.86 | 0.84 | 1.70 |

   Table 2: Unicast simulations with packet loss.


5.2 Multicast

   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].

   The simulations of the different topologies in scenarios, where no
   losses occur, neither through bit errors nor through congestion,
   show a similar behavior as the unicast scenarios. For all group
   sizes the maximum used RTCP bit rate share is 5.06% of the session
   bandwidth in a simulation of 16 session members in a low bit rate
   scenario (session bandwidth = 20kbps) with several senders. In all
   other scenarios without losses the used RTCP bit rate share is below
   that. Thus the requirement, that not more than 5% of the session bit
   rate should be used for RTCP is fulfilled in reasonable accuracy.

   Simulations, were 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).


Burmeister et al.          Expires May 2002                          9
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -




   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 burstness 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 burstness of the packet loss might be
   reduced, however this is not subject of our investigations, but is
   left for future research. The delay between the agents, which also
   influence RTP and RTCP packets, is much more variable because of the
   added queuing delay. Still the used RTCP bit rate share does not
   increase beyond 5.09% of the session bandwidth. Thus also for these
   special cases the requirement is fulfilled.


5.3 Summary of the RTCP bit rate measurements

   We have shown that for unicast and reasonable multicast scenarios,
   feedback explosion does not happen. The requirement that at maximum
   5% of the session bandwidth is used for RTCP is fulfilled for all
   investigated scenarios.


6 Feedback Measurements

   In this chapter we describe the results of feedback delay
   measurements, 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 that is
   sent, suppressed or not allowed. The waiting time is the time,
   measured at a certain agent, between the detection of a packet loss
   and the time when the corresponding feedback is sent. Assuming that
   the value of the feedback decreases with its delay, we think that
   the mean waiting time is a good metric to measure the performance
   gain we could get by using AVPF instead of AVP.

   The feedback an agent wants to send can be either sent or not sent.
   If it was not sent, this could be due to the 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.




Burmeister et al.          Expires May 2002                         10
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



6.1 Unicast

   In the unicast case, the maximum dithering interval T_Dither_max is
   fixed and set to zero. This is due to the fact that 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 dithering interval is
   a parameter for the early packets, but at maximum every second
   packet can be an early packet. The regularly scheduled packets are
   spaced according to T_rr, which depends in the unicast case mainly
   on the session bandwidth.

   Table 3 shows the mean waiting times (MWT) 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 1 was a sender and agent 2 a pure receiver. We
   did not vary this, because the only difference in being a sender or
   pure receiver, is that the sender has an RTT estimation to the
   receivers. However the RTT estimation is used for the T_Dither_max
   calculations only in the multicast cases.

   |         |       |          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.

   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) it can be decreased to a few ms for most
   of the AVPF configurations.

   In the cases of high session bandwidth normally all feedback is
   sent. This is because the packet size is quite large (1000byte) and
   thus per lost packet, more RTCP bandwidth is available. There are
   only very few exceptions, which are probably due to two packet
   losses 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 detected after the early packet was sent, but too early


Burmeister et al.          Expires May 2002                         11
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   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. Here we have a small packet
   size (100byte) and thus many packets are transmitted, while the RTCP
   bandwidth share is quite low. T_rr is thus quite large. 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 than max_feedback_delay, because in these cases the
   feedback is not allowed to be sent at all.

   With a different setting of max_feedback_delay it is possible to
   have either more feedback that is not allowed and a decreased mean
   waiting time or more feedback that is sent but an increased waiting
   time. Thus the parameter should be set with care according to the
   application's needs.


6.2 Multicast

   In this section we describe some measurements of feedback statistics
   in the multicast simulations. We picked out certain characteristic
   and representative results. Therefore we considered the topology T-
   16. Different scenarios and applications are simulated for this
   topology. The parameters of the different links are set as follows.
   The agents A2, A3 and A4 are connected to the middle node of the
   multicast tree, i.e. agent A1, via high bandwidth and low delay
   links. The other agents are connected to the nodes 2, 3 and 4 via
   different link characteristics. The agents connected to node 2
   represent mobile users. They suffer in certain configurations from a
   certain byte error rate on their access links and the delays are
   quite high. The agents that are connected to node 3 have low
   bandwidth access links, but do not suffer from bit errors. The last
   agents, that are connected to node 4 have quite high bandwidth and
   quite low delay.

6.2.1 Shared Losses vs Distributed Losses

   In our first investigation, we wanted to see the influence the loss
   characteristic on the algorithm's performance, i.e. we wanted to
   investigate the cases where packet loss occurs for several users
   simultaneously or totally independently. Therefore we first define
   agent A1 to be the sender. In the shared-loss-case we insert 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.

   This scenario is 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


Burmeister et al.          Expires May 2002                         12
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   to be sent, it suppresses the scheduled feedback. Of course this
   suppressed feedback does not contribute to the mean waiting times.
   So we expect reduced waiting times for shared losses, because the
   probability is high that one of the receivers can send the feedback
   more or less immediately. The results are shown in the following
   table.

   |     |                Feedback Statistics                |
   |     |  Shared Losses          |  Distributed Losses     |
   |Agent|sent|fbsp|disc|sum | MWT |sent|fbsp|disc|sum | MWT |
   +-----+----+----+----+----+-----+----+----+----+----+-----+
   |  A2 | 274| 351|  25| 650|0.267|   -|   -|   -|   -|    -|
   |  A5 | 231| 408|  11| 650|0.243| 619|   2|  32| 653|0.663|
   |  A6 | 234| 407|   9| 650|0.235| 587|   2|  32| 621|0.701|
   |  A7 | 223| 414|  13| 650|0.253| 594|   6|  41| 641|0.658|
   |  A8 | 188| 443|  19| 650|0.235| 596|   1|  32| 629|0.677|

   Table 4: Feedback statistics for multicast simulations.

   Table 4 shows the feedback statistics for the simulation of a large
   group size. All 16 agents of topology T-16  joined the RTP session.
   However only agent A1 acts as an RTP sender, the other agents are
   pure receivers. Only 4 or 5 agents suffer from packet loss, i.e. A2,
   A5, A6, A7 and A8 for the case of shared losses and A5, A6, A7 and
   A8 in the case of distributed losses. Since the number of session
   members is the same for both cases, T_rr is also the same on the
   average. Still the mean waiting times are reduced by more than 50%
   in the case of shared losses. This proves our assumption that shared
   losses enhance the performance of the algorithm.

   The feedback suppression mechanism seems to be working quite fine.
   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 report being received on the average 1.8 times)
   most of the redundant feedback was suppressed. I.e. 2023 loss
   reports were suppressed from 3250 individual detected losses, which
   means that more than 60% of the feedback was actually suppressed.

6.2.2 Sender vs. Receiver

   RTP senders are able to maintain a RTT measurement to all receivers,
   which send receiver reports. This is done by the means of the ntp
   timestamp in the sender report and the repetition of this value
   together with the delay since last sender report value in the
   receiver report. However RTP session members that do not send RTP
   packets are not an RTP sender and thus do not send sender reports.
   Therefore pure receivers do not have an RTT measurement to the
   senders or other receivers. This fact is considered in AVPF, by
   giving two possibilities to calculate T_dither_max.



Burmeister et al.          Expires May 2002                         13
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   If the RTP member has an RTT measurement to the sender of the packet
   it wants to provide feedback to, it calculates T_dither_max = k *
   T_rtt/2 * members, with k = 1. Thus t_dither_max is increased with
   the number of session members and the RTT. The rational for RTT/2 is
   that the distance to the sender is a good measure how long to wait
   at maximum. Other receivers, who are more far away, i.e. have a
   larger RTT estimation, will detect the packets later and also the
   feedback from those would arrive later and hence have less value.
   Thus the nearest receivers get the chance first to send their
   feedback. Because of the larger distance of the other receivers to
   the sender, they will probably wait longer (probably, because of the
   randomness, i.e. we calculate T_dither_max, from which T_dither is
   picked randomly). While those are waiting, it is likely that they
   receive the feedback from the receivers that are nearer to the
   source. With this it is possible to find a good compromise between
   waiting time and feedback suppression. To let the algorithm scale to
   large group sizes, the number of session members is included. The
   number of members is the maximum number of receivers that shared the
   same loss. The more members are in the session, the higher is the
   probability that other receivers share the loss and thus the higher
   is the value of waiting longer, because the probability is increased
   that feedback suppression will work. If all receivers calculate the
   same T_dither_max ( i.e. have a similar RTT estimation) and pick a
   T_dither from this interval randomly with a uniform distribution, it
   is likely that one feedback is sent within the first RTT interval.

   In case the RTP session member does not have an RTT measurement,
   i.e. it is a pure receiver, is calculates T_dither_max = l * T_rr,
   with l = 0.5. The rational for this is that the receiver, if it has
   no RTT estimation, does not know at all how long it should wait for
   other receivers to send feedback. The feedback suppression algorithm
   would certainly fail, if the time is selected too short. However the
   waiting time is increased unnecessarily (and thus the value of the
   feedback is decreased!) in case the time is chosen too long. It
   would be good to find the optimum time (which is tried to be done
   with the RTT estimation), but it is not dangerous if the optimum
   time is not chosen. 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
   loose some performance by choosing the wrong time. A good measure
   for T_dither_max however 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 to send the early
   packet in time.


Burmeister et al.          Expires May 2002                         14
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -




   Having said that, we assume that the RTP members who have an RTT
   measurement would perform better regarding the feedback suppression.
   We want to show that by simulating the same scenario of the previous
   section, but enabling all receivers that suffer from packet loss to
   maintain a RTT measurement. We do this by declaring the
   corresponding agents to RTP senders. However we do not send RTP
   packets from this agents, to be comparable to the previous results.
   The only difference to the previous simulations is that sender
   reports are sent, which enables the sender to maintain a RTT
   measurement.

   |     |                Feedback Statistics                |
   |     |  Shared Losses          |  Distributed Losses     |
   |Agent|sent|fbsp|disc|sum | MWT |sent|fbsp|disc|sum | MWT |
   +-----+----+----+----+----+-----+----+----+----+----+-----+
   |  A2 | 582|  43|   7| 632|0.100|   -|   -|   -|   -|    -|
   |  A5 |  70| 562|   0| 632|0.121| 644|   1|   1| 646|0.576|
   |  A6 |  60| 572|   0| 632|0.114| 638|   5|   1| 644|0.575|
   |  A7 |  73| 559|   0| 632|0.109| 607|   3|   1| 611|0.567|
   |  A8 |  63| 569|   0| 632|0.108| 626|   3|   0| 629|0.589|

   Table 5: Feedback statistics for multicast simulations, where the
   agents that suffer from packet loss do have an RTT estimation to the
   sender.

   Table 5 shows the results of the simulations. As assumed, we see
   that the performance regarding the waiting time is increased
   significantly. In case of shared losses, the mean time is less than
   half of the mean waiting times of the receivers that do not have a
   RTT estimation. Also for the case of distributed losses, we see a
   slight gain in performance, however not as big as for the shared
   losses. But still we see that the calculation of T-dither_max, using
   the RTT estimation finds a better tradeoff between waiting time and
   feedback suppression. The waiting time is reduced and the feedback
   suppression increased where possible. Thus for both cases, whether
   feedback suppression is possible or not, the performance is
   increased. Feedback suppression in the case of shared losses is
   working much better with a RTT estimation. From 3160 individual
   detected losses only 848 loss reports are sent.


7 Investigations on "k"

   The parameter k in the formula how to calculate T_Dither_max if an
   RTT estimation is available has some influence of the performance of
   the algorithm. Thus we investigated the effect and tried to find an
   optimum value for k. Therefore we defined a sample scenarios and
   tried to find an optimum value for k.



Burmeister et al.          Expires May 2002                         15
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   We define three representative sample scenarios. We use the topology
   from the previous section. Most of the agents however contribute
   only little to the simulations, because we introduced an error rate
   only on the link between the sender A1 and the agent A2.

   The first scenario represents 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 introduce on the link between the sender and
   agent A2. Agent A6, A7 and A8 do not join the RTP session. From the
   other agents only agents A3 and A9 join. Both agent A2 and A5 are
   declared as RTP senders, in order to have an RTT estimation to the
   sender A1.

   The second scenario represents also 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. Agent 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.

   Also in the third scenario, the losses re shared between two agents,
   A5 and A6. The same agents as in the second scenario are active.
   However the delays of the links are different. The delay of the link
   between agent A2 and A5 is reduced to 20ms and between A2 and A6 to
   40ms. Thus the RTT estimations of agents A5 and A6 to the sender are
   reduced significantly.


7.1 Feedback Suppression Performance

   First we consider the fraction of feedback that the agent An
   suppresses (Feedback Suppression Rate). An is thereby the agent
   nearer to the source. The simulation results can be seen from
   Table 7. In general it can be seen that agent An suppresses more
   feedback if the differences between the delays to the source are
   smaller. This is reasonable, because the feedback from other
   receivers will be faster received in that case. It can also be seen
   that the feedback suppression rate increases with k. This is due to
   the fact that T_dither_max increases with k. Thus the agents will
   wait longer on the average before sending their feedback. By
   increasing the waiting time for all agents, the time were feedback
   suppression is possible at all is increased.









Burmeister et al.          Expires May 2002                         16
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   |      |  Feedback Suppression Rate  |
   |  k   | Scen. 1 | Scen. 2 | Scen. 3 |
   +------+---------+---------+---------+
   | 0.10 |  0.070  |  0.039  |  0.064  |
   | 0.25 |  0.068  |  0.063  |  0.065  |
   | 0.50 |  0.062  |  0.114  |  0.124  |
   | 0.75 |  0.047  |  0.172  |  0.129  |
   | 1.00 |  0.056  |  0.234  |  0.176  |
   | 1.25 |  0.056  |  0.282  |  0.233  |
   | 1.50 |  0.047  |  0.315  |  0.251  |
   | 1.75 |  0.040  |  0.331  |  0.245  |
   | 2.00 |  0.048  |  0.297  |  0.284  |
   | 3.00 |  0.047  |  0.347  |  0.330  |
   | 4.00 |  0.063  |  0.347  |  0.353  |

   Table 7: Fraction of feedback that was suppressed at agent An of the
   total number of feedback the agent wanted to send

   In Table 8 the results for the feedback suppression of agent Af are
   depicted. Again we see that the number of feedback suppressions
   increase with k. Only in scenario 1 the number is more or less
   constant. However by increasing the waiting times, the probability
   that the feedback is suppressed is decreased at agent Af. k=1 seems
   to be a threshold, where the feedback suppression does not change
   anymore significantly in the given scenarios. This is because for
   the given parameters, the early packets will not be sent any more,
   because the next regularly scheduled RTCP packet will we within the
   T_dither_max interval.

   |      |  Feedback Suppression Rate  |
   |  k   | Scen. 1 | Scen. 2 | Scen. 3 |
   +------+---------+---------+---------+
   | 0.10 |  0.736  |  0.064  |  0.071  |
   | 0.25 |  0.814  |  0.079  |  0.119  |
   | 0.50 |  0.859  |  0.162  |  0.239  |
   | 0.75 |  0.865  |  0.222  |  0.376  |
   | 1.00 |  0.844  |  0.290  |  0.401  |
   | 1.25 |  0.850  |  0.338  |  0.429  |
   | 1.50 |  0.849  |  0.316  |  0.473  |
   | 1.75 |  0.868  |  0.316  |  0.505  |
   | 2.00 |  0.843  |  0.376  |  0.487  |
   | 3.00 |  0.845  |  0.345  |  0.502  |
   | 4.00 |  0.820  |  0.345  |  0.493  |

   Table 8 Fraction of feedback that was suppressed at agent Af of the
   total number of feedback the agent wanted to send

   In Table 9 the ration of feedback suppression failures is
   illustrated. In general the observations from the figures above are
   summarized. The ratio of feedback failures decreases with an


Burmeister et al.          Expires May 2002                         17
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   increasing k for the scenarios 2 and 3. In scenario 1 the ratio is
   hardly influenced at all by k. The simulations show a kind of steady
   state at k larger two or three, where the rationale for this is that
   for very large k, T_dither_max becomes equal or more than T_rr and
   thus no early packets are send any more. The maximum dithering
   interval is for these cases limited by the next regularly scheduled
   RR.

   |      |Feedback Suppr. Failure Rate |
   |  k   | Scen. 1 | Scen. 2 | Scen. 3 |
   +------+---------+---------+---------+
   | 0.10 |  0.194  |  0.897  |  0.865  |
   | 0.25 |  0.117  |  0.858  |  0.816  |
   | 0.50 |  0.079  |  0.725  |  0.638  |
   | 0.75 |  0.088  |  0.606  |  0.495  |
   | 1.00 |  0.100  |  0.468  |  0.423  |
   | 1.25 |  0.094  |  0.381  |  0.338  |
   | 1.50 |  0.104  |  0.369  |  0.276  |
   | 1.75 |  0.092  |  0.353  |  0.250  |
   | 2.00 |  0.110  |  0.328  |  0.229  |
   | 3.00 |  0.108  |  0.308  |  0.169  |
   | 4.00 |  0.116  |  0.308  |  0.154  |

   Table 8: The ratio of feedback suppression failures.

   Summarizing, it can be said, that the feedback suppression
   performance is highly dependent on the topology, the parameters and
   configurations.

   In general a larger value for k increases the probability that the
   feedback suppression works, however the performance gain decreases
   with an increasing k. For a certain threshold, depending on the
   configuration and environment, an increasing k does not lead to any
   performance gain any more.


7.2 Loss Report Delay

   In this section we investigate the influence of the parameter k on
   the loss report delay. Therefore we measured for the three sample
   scenarios the mean loss report delay as seen by the sender, i.e. the
   sender calculates for every loss report, it receives for the first
   time the delay since the corresponding packet was sent.

   The results are depicted in Table 9. In general it can be said, that
   the loss report delay increases with k. This is only natural,
   because T_Dither_max is proportional to k. Thus the agents wait on
   the average longer to send their early packets. In cases of very
   large k values, the report delay does not increase significantly any
   more. In these cases nearly no early packets are sent, because the


Burmeister et al.          Expires May 2002                         18
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   next regularly scheduled packet is within the T_dither_max interval.
   The threshold of k, from which on the delay will not increase, is
   dependent on the RTT estimation. For increasing RTT values, the
   threshold decreases. We see that in scenario 1 the threshold lies
   between k=2 and k=3. For the scenarios with smaller RTT, the
   threshold is higher.

   Summarizing it can be said, that the report delay increases with an
   increasing k. From a certain threshold the increase is not
   significant, however this threshold is highly dependent on topology
   and environment parameters.

   |      |   Mean Loss Report Delay    |
   |  k   | Scen. 1 | Scen. 2 | Scen. 3 |
   +------+---------+---------+---------+
   | 0.10 |  0.128  |  0.282  |  0.431  |
   | 0.25 |  0.135  |  0.266  |  0.430  |
   | 0.50 |  0.150  |  0.264  |  0.497  |
   | 0.75 |  0.160  |  0.286  |  0.538  |
   | 1.00 |  0.194  |  0.305  |  0.613  |
   | 1.25 |  0.203  |  0.329  |  0.661  |
   | 1.50 |  0.208  |  0.363  |  0.690  |
   | 1.75 |  0.209  |  0.387  |  0.739  |
   | 2.00 |  0.242  |  0.412  |  0.764  |
   | 3.00 |  0.243  |  0.507  |  0.790  |
   | 4.00 |  0.287  |  0.568  |  0.790  |

   Table 9: The mean loss report delay, measured at the sender.


7.3 Summary of "k" investigations

   We have shown by simulations that the parameter k influence the
   feedback performance. While in general the feedback suppression
   performance increases with k, the report delay increases also. Hence
   we need to find a tradeoff, between the amount of feedback that is
   sent and the delay of the feedback, when it is received at the
   sender. Since we have shown that the performance curves for the
   feedback suppression as well as the report delay is highly variable
   for different topologies and environments, it is not possible to
   give an optimized parameter value for k. We think that k=1 is a
   compromise, which should be acceptable for most of our considered
   cases. At least we guarantee with k=1 that no feedback explosion
   will occur and thus keep the network stability untouched.








Burmeister et al.          Expires May 2002                         19
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



8 Investigations on "l"

   In this section we want to investigate the influence of the
   parameter "l" from the T_Dither_max calculation in agents that do
   not have an RTT estimation to the sender. As we have done in the
   previous section for the parameter "k", we investigate the feedback
   suppression performance as well as the report delay for three sample
   scenarios. For simplicity we use the same scenarios as in the
   previous section, but this time the 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 other formula,
   depending only on T_rr and l, which means that all agents should
   calculate roughly the same T_Dither_Max.


8.1 Feedback Suppression Performance

   The results for the feedback suppression rate of the agent Af that
   is more far away from the sender, are depicted in Table 10. In
   general it can be seen that the feedback suppression rate increases
   with an increasing l. However there is a threshold, depending on the
   environment, from which the additional gain is not significant any
   more.

   |      |  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 10: Fraction of feedback that was suppressed at agent An of
   the total number of feedback the agent wanted to send











Burmeister et al.          Expires May 2002                         20
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   Similar results can be seen for the agent that is nearer to the
   sender in Table 11.

   |      |  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 11: Fraction of feedback that was suppressed at agent An of
   the total number of feedback the agent wanted to send

   The rate of feedback suppression failure is depicted in Table 12.
   The trend that the additional performance increase is not
   significant from a certain threshold, depending on the environment
   is here as well visible.

   |      |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 12: The ratio of feedback suppression failures.

   Summarizing the feedback suppression results it can be said that in
   general the feedback suppression performance increases with an
   increasing l. However from a certain threshold, depending on
   environment parameters such as propagation delays or session
   bandwidth, the additional increase is not significant anymore.




Burmeister et al.          Expires May 2002                         21
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



8.2 Loss Report Delay

   In this section we show the results for the measured report delay
   during the simulations of the three sample scenarios. This
   measurement is a metric of the performance of the algorithms,
   because the value of the feedback for the sender typically decreases
   with the delay of its reception. The loss report delay is measured
   as the time at the sender between sending a packet and receiving the
   first corresponding loss report.

   |      |   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 13: The mean loss report delay, measured at the sender.

   As can be seen from Table 13 the delay increases in general with an
   increasing value of l. However a similar effect as for the feedback
   suppression performance is visible: from 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.3 Summary of "l" investigations

   We have shown that theoretically the performance of the feedback
   suppression mechanisms is increasing with an increasing value of l.
   The same applies for the report delay, which increases also with an
   increasing l. This leads to a threshold where both the performance
   and the delay does not increase any further. The threshold is
   environment dependent.

   So finding an optimum value of l is not possible because it is
   always a tradeoff between delay and feedback suppression
   performance. With l=0.5 we think that a tradeoff was found that is
   acceptable for typical applications and environments.



Burmeister et al.          Expires May 2002                         22
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -




9 Applications Using AVPF

   NEWPRED is one of the error resilience tools, which is defined in
   both ISO/IEC MPEG-4 visual part and ITU-T H.263. NEWPRED achieves
   fast error recovery using feedback messages. We simulated the
   behavior of NEWPRED in the network simulator environment as
   described above and measured the waiting time statistics, in order
   verify that the extended RTP profile for RTCP-based feedback
   (AVPF)[1] is appropriate for the NEWPRED feedback messages.
   Simulation results, which present in the following sections, show
   that the waiting time is enough small to get the satisfactory
   performance of NEWPRED.


9.1 NEWPRED Implementation in NS2

   The agent that performs the NEWPRED functionality, called NEWPRED
   agent, is different from the RTP agent we described above. Some of
   the added features and functionalities are described in the
   following points:

   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 plural number of 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.
     The parameters of NEWPRED agent are as follows:
           f: Frame Rate(frames/sec)
         seg: Number of segments in one video frame
          bw: RTP session bandwidth(kbps)

   Generation of NEWPRED's NACK Messages
     The NEWPRED agent generates NACK messages when segments are lost.
     a. The NEWPRED agent generates plural number of NACK messages per
        one video frame when plural number of segments are lost. These
        are assembled into one FCI message per video frame. If there is
        no lost segment, no message is generated and sent.
     b. The length of one NACK message is 4 bytes. Let num be the
        number of NACK messages in one video frame(1 <= num <= seg).
        Thus, 12+4*num bytes is the size of the low delay RTCP feedback
        message.

   Measurements
     We defined two values to be measured:


Burmeister et al.          Expires May 2002                         23
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



     - 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.

     Fig.1 depicts the behavior of a NEWPRED agent when a loss occurs.
     The recovery time is approximated as follows:
       (Recovery time) = (Waiting time) +
                         (Transmission time for feedback message) +
                         (Transmission time for media data)

     Therefore, the waiting time is derived as follows:

       (Waiting time) = (Recovery time) - (Round-trip delay), where

       (Round-trip delay ) = (Transmission time for feedback message) +
                             (Transmission time for media data)





        Picture Reference                            |: Picture Segment
                 ____________________                %: Lost Segment
                /_    _    _    _    \
               v/ \  / \  / \  / \    \
               v   \v   \v   \v   \    \
   Sender   ---|----|----|----|----|----|---|------------->
                    \    \                 ^ \
                     \    \               /   \
                      \    \             /     \
                       \    v           /       \
                        \    x         /         \
                         \   Lost     /           \
                          \    x     /             \              _____
                           v    x   / NACK          v
   Receiver ---------------|----%===-%----%----%----|----->
                                |-a-|               |
                                |-------  b  -------|

                          a: Waiting time
                          b: Recover time (%: Video segments are lost)

   Fig.1: Relation between the measured values at the NEWPRED agent





Burmeister et al.          Expires May 2002                         24
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -




9.2 Simulation

   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.

9.2.1. Simulation A - Constant Packet Loss Rate

   The network topology, used for this simulation is shown in Fig.2.




                  Link 1         Link 2        Link 3
        +--------+      +------+       +------+      +--------+
        | Sender |------|Router|-------|Router|------|Receiver|
        +--------+      +------+       +------+      +--------+
                 10(msec)       x(msec)       10(msec)


   Fig2. Network topology that is used for Simulation A

   Link1 and link3 are error free, and each link delay is 10 msec.
   Packets may get dropped on link2. The packet loss rates (Plr) and
   link delay (D) are as follows:

      D [ms] = {10, 50, 100, 200, 500}
      Plr    = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}
      Session band width, frame rate and the number of segments are
      shown in Table 14

   +------------+----------+-------------+-----+
   |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  |
   +------------+----------+-------------+-----+



Burmeister et al.          Expires May 2002                         25
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   Table 14: Parameter sets of the NEWPRED agents

   Figure3 shows the packet loss rate vs. mean of waiting time. A
   plotted line represents a parameter ID ( "[session bandwidth] -
   [frame rate] - [the number of segments] - [link2 delay]" ).
   E.g. 384k-15-9-100 means the session of 384kbps session bandwidth,
   15 frames per second, 9 segments per frame and 100msec link delay.

   When the packet loss rate is 5% and the session bandwidth is 32kbps,
   the waiting time is around 400msec, which is just allowable for
   reasonable NEWPRED performance.

   When the packet loss rate is less than 1%, the waiting time is less
   than 200msec. In such a case, the NEWPRED allows as much as 200msec
   additional link delay.

   When the packet loss rate is less than 5% and the session bandwidth
   is 64kbps, the waiting time is also less than 200msec.

   In 128kbps cases, the result shows that when the packet loss rate is
   20%, the waiting time is around 200msec. In cases with more than
   512kbps session bandwidth, there is no significant delay. This means
   that the waiting time due to the feedback limitation of RTCP is
   neglectable for the NEWPRED performance.

   +------------------------------------------------------------+
   |           | 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 |
   +------------------+------+------+------+------+------+------+

   Fig. 3 The result of simulation A


9.2.2. Simulation B - Packet Loss due to Congestion



Burmeister et al.          Expires May 2002                         26
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   The configuration 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 4 for the simulation topology.






                      Link1         Link2          Link3
           +--------+      +------+       +------+      +--------+
           | Sender |------|Router|-------|Router|------|Receiver|
           +--------+    /|+------+       +------+|\    +--------+
                   +---+/ |                       | \+---+
                 +-|FTP|+---+                   +---+|FTP|-+
                 | +---+|FTP| ...               |FTP|+---+ | ...
                 +---+  +---+                   +---+  +---+

                  FTP Agents                      FTP Agents


                  Fig4. Network Topology of Simulation B



   The parameters are defined as for Simulation A with the following
   values assigned:

      D[ms] ={10, 50, 100, 200, 500}
      32 FTP agents are deployed at each edge, and totally 64 FTP
      agents are active.
      The sets of session bandwidth, frame rate, the number of segments
      are the same as in Simulation A (Table 14)

   We provide the results for the cases of 64 FTP agents, because these
   are the cases where packet losses could be detected stable. The
   results are similar to the Simulation A except for a constant
   additional offset of 50..100ms. This is due to the delay incurred by
   the routers buffers.


9.3 Summary of Application Simulations

   We have shown that the limitations of RTP AVPF profile do not
   generate such high delay to the feedback messages that the
   performance of NEWPRED is degraded in the sessions from 32kbps to
   2Mbps. We could see that the waiting time increases with a
   decreasing session bandwidth and/or an increasing packet loss rate.
   Thereby it is not significant what the packet loss caused.


Burmeister et al.          Expires May 2002                         27
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



   Congestion or constant packet loss rates behave similar. Still we
   see that for reasonable conditions and parameters the AVPF is well
   suited to support the feedback needed for NEWPRED.


10 Summary

   The new RTP profile AVPF was investigated regarding performance and
   potential dangers to the network stability. Simulations were
   conducted using the network simulator, simulating unicast and
   different sized multicast topologies. The results were shown in this
   document.

   Regarding the network stability, it was important to show that the
   new profile does not lead to any feedback explosion, or use more
   bandwidth as it is allowed. Thus 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. The scenarios included
   unicast with and without bit errors, different sized multicast
   groups, with and without errors or congestion on the links. Thus we
   can say that the new profile behaves network friendly in that sense
   that it uses only the allowed bandwidth that was assigned by RTP.

   Second we have shown that receivers using the new profile experience
   a performance gain. We have shown that especially RTP receiver that
   do have an RTT estimation to the sender gain from using the new
   profile. But also the other receivers could increase their
   performance. This was measured by the delay that the sender sees for
   the received feedback. Using the new profile this delay can be
   decreased by orders of magnitude.

   Third we investigated certain parameters of the new algorithms. We
   have shown that there does not exist an optimum value for those. The
   influence of the parameters is highly environment specific and a
   tradeoff between performance of the feedback suppression algorithm
   and the experienced delay has to be found. The values that are given
   in the draft seem to be reasonable for most applications and
   environments.













Burmeister et al.          Expires May 2002                         28
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



References

   [1]  J.Ott, S.Wenger, S.Fukunaga, N.Sato, K.Yano, A.Miyazaki,
        K.Hata, R.Hakenberg, C.Burmeister: Extended RTP Profile for
        RTCP-based Feedback, Internet Draft,
        draft-ietf-avt-rtcp-feedback-00.txt, Work in Progress,
        July 2001.

   [2]  H.Schulzrinne, S.Casner, R.Frederick, and V.Jacobson:
        RTP - A Transport Protocol for Real-time Applications,
        Internet Draft, draft-ietf-avt-rtp-new-10.txt, Work in
        Progress, July 2001.

   [3]  H.Schulzrinne, S.Casner: RTP Profile for Audio and Video
        Conferences with Minimal Control, Internet Draft,
        draft-ietf-avt-profile-new-11.txt, Work in Progress, July 2001.

   [4]  Network Simulator Version 2 - ns-2, available from
        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.pel.panasonic.de/ietf/docs/SimulationResults-A.pdf

   [6]  ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology -
        Coding of audio-visual objects - Part2: Visual", July 2000.

   [7]  ITU-T Recommendation, H.263. Video encoding for low bitrate
        communication. 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.

   [9]  Hideaki Kimata, Yasuhiro Tomita, Hiroyuki Yamaguchi, Susumu
        Ichinose, and Tadashi 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.











Burmeister et al.          Expires May 2002                         29
Extended RTP Profile for RTCP-based Feedback             November 2001
- Results of the Timing Rule Simulations -



Authors Addresses

   Carsten Burmeister
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   mailto:burmeister@panasonic.de

   Rolf Hakenberg
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   mailto:hakenberg@panasonic.de

   Akihiro Miyazaki
   Matsushita Electric Industrial Co., Ltd
   1006, Kadoma, Kadoma City, Osaka, Japan
   mailto :akihiro@isl.mei.co.jp

   J÷rg Ott
   Universit„t Bremen TZI
   MZH 5180, Bibliothekstr. 1, 28359 Bremen, Germany
   {sip,mailto}:jo@tzi.uni-bremen.de

   Noriyuki Sato
   Oki Electric Industry Co., Ltd.
   1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan
   mailto:sato652@oki.co.jp

   Shigeru Fukunaga
   Oki Electric Industry Co., Ltd.
   1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan
   mailto:fukunaga444@oki.co.jp





















Burmeister et al.          Expires May 2002                         30