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

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

                                                                J. Ott
                                              University of Bremen TZI

                                                               N. Sato
                                                           S. Fukunaga
                                                                   Oki

                                                            March 2003



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


   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.

Copyright Notice

      Copyright (C) The Internet Society (2003).  All Rights Reserved.


Abstract

   This document describes the results we achieved when simulating the
   timing rules of the Extended RTP Profile for RTCP-based Feedback,
   denoted AVPF.  Unicast and multicast topologies are considered as
   well as several protocol and environment configurations.  The


Burmeister et al.       Expires September 2003                       1
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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
   2 Conventions used in this document
   3 Timing rules of the extended RTP profile for RTCP-based feedback
   4 Simulation Environment
   5 RTCP Bit Rate Measurements
   5.1 Unicast
   6 Feedback Measurements
   6.1 Unicast
   7 Investigations on "l"
   8 Applications Using AVPF
   9 Summary
   References
   IPR Notices
   Authors' Address
   Full Copyright Statement

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


Burmeister et al.       Expires September 2003                       2
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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 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 bandwidth for RTCP traffic.  In Section 6, we show the
   benefit that applications could get from implementing the new
   profile.  In Section 7 we investigated the effect of the parameter
   "l" (used to calculate the T_dither_max value) upon the algorithm
   performance and finally in Section 8 we show the performance gain we
   could get for a special application, namely NEWPRED in [6] and [7].


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


Burmeister et al.       Expires September 2003                       3
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



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


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


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.  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 itself are implemented in C++ in the agents, which are
   connected to the nodes.  The documentation for ns2 and a the newest
   version can be found in [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


Burmeister et al.       Expires September 2003                       4
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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.

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


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.  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.  The figures below illustrate the main topologies.





















Burmeister et al.       Expires September 2003                       5
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



                                                   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 similarly
   to 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 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,
   i.e. some members using AVP some AVPF, can be allowed and that each
   session member behaves fair according to its corresponding
   specification.  Note that other value for the RTCP bandwidth limit
   may be specified using the RTCP bandwidth modifiers as in [10].


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.  We varied the configurations of the agents in
   the 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 of the
   AVPF profile.


Burmeister et al.       Expires September 2003                       6
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003




   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   |  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 is decreased.  This is due to the
   fact that agent A1 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 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.


Burmeister et al.       Expires September 2003                       7
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003




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


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



Burmeister et al.       Expires September 2003                       8
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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 in the unicast case.  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 with 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).

   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 subject of our investigations, but is
   left for future research.  The delay between the agents, which also
   influences 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 implosion does not happen.  The requirement that at maximum



Burmeister et al.       Expires September 2003                       9
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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, which we conducted in the simulations.  Therefore we
   use two metrics for measuring the performance of the algorithms,
   these are the "mean waiting time" (MWT) and the number of feedback
   packets that are sent, suppressed or not allowed.  The waiting time
   is the time, measured at a certain agent, between the detection of a
   packet loss event and the time when the corresponding feedback is
   sent.  Assuming that the value of the feedback decreases with its
   delay, we think that the mean waiting time is a good metric to
   measure the performance gain we could get by using AVPF instead of
   AVP.

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


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 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) 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 a pure receiver.

   |         |       |          Feedback Statistics          |
   | Session |       |       AVP         |       AVPF        |
   |Bandwidth|  PLR  | sent |disc| MWT   | sent |disc| MWT   |
   +---------+-------+------+----+-------+------+----+-------+


Burmeister et al.       Expires September 2003                      10
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   |  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 triggered
   feedback is sent.  This is because more RTCP bandwidth is available.
   There are only very few exceptions, which are probably due to more
   that one 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 triggered after the early
   packet was sent, but possibly too early to append it to the next
   regularly scheduled report, because of the limitation of the
   max_feedback_delay.  This is different for the cases with a small
   session bandwidth, where the RTCP bandwidth share is quite low and
   T_rr thus larger.  After an early packet was sent the time to the
   next regularly scheduled packet can be very high.  We saw that in
   some cases the time was larger than the max_feedback_delay and in
   these cases the feedback is not allowed to be sent at all.

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


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


Burmeister et al.       Expires September 2003                      11
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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 high bandwidth and low delay.

6.2.1 Shared Losses vs. Distributed Losses

   In our first investigation, we wanted to see the effect of the loss
   characteristic on the algorithm's performance.  We investigate the
   cases where packet loss occurs for several users simultaneously
   (shared losses) or totally independently (distributed losses).  We
   first define agent A1 to be the sender.  In the case of shared
   losses, we inserted a constant byte error rate on one of the middle
   links, i.e. the link between A1 and A2.  In the case of distributed
   losses, we inserted the same byte error rate on all links downstream
   of A2.

   These scenarios are especially interesting, because of the feedback
   suppression algorithm.  When all receivers share the same loss, it
   is only necessary for one of them to send the loss report.  Hence if
   a member receives feedback with the same content that it has
   scheduled to be sent, it suppresses the scheduled feedback.  Of
   course, this suppressed feedback does not contribute to the mean
   waiting times.  So we expect reduced waiting times for shared
   losses, because the probability is high that one of the receivers
   can send the feedback more or less immediately.  The results are
   shown in the following table.

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

   Table 4: Feedback statistics for multicast simulations.

   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, regardless
   of the loss characteristic.



Burmeister et al.       Expires September 2003                      12
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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.


7 Investigations on "l"

   In this section we want to investigate the effect of the parameter
   "l" on the T_dither_max calculation in RTP/AVPF agents.  We
   investigate the feedback suppression performance as well as the
   report delay for three sample scenarios.

   For all receivers the T_dither_max value is calculated as
   T_dither_max = l * T_rr, with l = 0.5.  The rational for this is
   that, in general, if the receiver has no 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
   is selected 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 loose some performance
   by choosing the wrong time value.  On the other hand, 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.

   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 an
   scenario where T_rr = 1s 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


Burmeister et al.       Expires September 2003                      13
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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 object of another document.  Note,
   however, that a really high bandwidth media stream is not that
   likely to rely on this kind of error repair in the first place.

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

   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 introduce on the link between
   the sender and agent A2.  Agents A6, A7 and A8 do not join the RTP
   session.  From the other agents only agents A3 and A9 join.  All
   agents are pure receivers, except A1 which is the sender.

   The second scenario 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.  Agents A5 and A6 share the same
   losses.  Agents A3 and A9 join the RTP session, but are pure
   receivers and do not see any losses.

   Finally, in the third scenario, the losses are shared between two
   agents, A5 and A6.  The same agents as in the second scenario are
   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.

   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.


7.1 Feedback Suppression Performance



Burmeister et al.       Expires September 2003                      14
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



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

   |      |  Feedback Suppression Rate  |
   |  l   | Scen. 1 | Scen. 2 | Scen. 3 |
   +------+---------+---------+---------+
   | 0.10 |  0.671  |  0.051  |  0.089  |
   | 0.25 |  0.582  |  0.060  |  0.210  |
   | 0.50 |  0.524  |  0.114  |  0.361  |
   | 0.75 |  0.523  |  0.180  |  0.370  |
   | 1.00 |  0.523  |  0.204  |  0.369  |
   | 1.25 |  0.506  |  0.187  |  0.372  |
   | 1.50 |  0.536  |  0.213  |  0.414  |
   | 1.75 |  0.526  |  0.215  |  0.424  |
   | 2.00 |  0.535  |  0.216  |  0.400  |
   | 3.00 |  0.522  |  0.220  |  0.405  |
   | 4.00 |  0.522  |  0.220  |  0.405  |

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

   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  |



Burmeister et al.       Expires September 2003                      15
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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 of additional performance increase is not significant from
   a certain threshold, dependency on the scenario is here as well
   noticeable.

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


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


Burmeister et al.       Expires September 2003                      16
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   | 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. Also, a similar effect as for the feedback
   suppression performance is present: 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.


7.3 Summary of "l" investigations

   We have shown experimentally that the performance of the feedback
   suppression mechanisms increases 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 trade-off 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.


8 Applications Using AVPF

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


8.1 NEWPRED Implementation in NS2



Burmeister et al.       Expires September 2003                      17
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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 a 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:
     - 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


Burmeister et al.       Expires September 2003                      18
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003




       (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


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

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


Burmeister et al.       Expires September 2003                      19
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



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

   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


Burmeister et al.       Expires September 2003                      20
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   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


8.2.2. Simulation B - Packet Loss due to Congestion

   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


Burmeister et al.       Expires September 2003                      21
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003






   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.

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


9 Summary

   The new RTP profile AVPF was investigated regarding performance and
   potential risks to the network stability.  Simulations were
   conducted using the network simulator, simulating unicast and
   several differently 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 implosion, or uses 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.  Other RTCP bandwidth
   values could be set using the RTCP bandwidth modifiers [10].  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 the sense that it uses only the allowed RTCP bandwidth,
   as defined by RTP.


Burmeister et al.       Expires September 2003                      22
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003




   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 the draft seems to be reasonable for most
   applications and environments.


References

   1 J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, "Extended
     RTP Profile for RTCP-based Feedback", Internet Draft, draft-ietf-
     avt-rtcp-feedback-05.txt, Work in Progress, February 2003.

   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-11.txt, Work in Progress, May 2002.

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

   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 H. Kimata, Y. Tomita, H. Yamaguchi, S. Ichinose, T. Ichikawa,
     "Receiver-Oriented Real-Time Error Resilient Video Communication


Burmeister et al.       Expires September 2003                      23
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



     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.

   10 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft-
     ietf-avt-rtcp-bw-05.txt, May 2002.


IPR Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP 11 [13].  Copies
   of claims of rights made available for publication 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 Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Authors' Address

   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

   Joerg Ott
   Universitdt Bremen TZI
   MZH 5180, Bibliothekstr. 1, 28359 Bremen, Germany


Burmeister et al.       Expires September 2003                      24
RTP/AVPF Profile  -Timing Rules Simulation Results -        March 2003



   {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


Full Copyright Statement

   "Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or
   assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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."












Burmeister et al.       Expires September 2003                      25