J. Chesterfield
                                                University of Cambridge
                                                            E. Schooler
   Internet Draft                                  AT&T Labs - Research
   Document: draft-ietf-avt-rtcpssm-05                           J. Ott
                                                          Tellique GmbH
   Expires: March 2004                                  27 October 2003




            RTCP Extensions for Single-Source Multicast Sessions
                           with Unicast Feedback


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.

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


Abstract

   This document specifies a modification to the Real-time Transport
   Control Protocol (RTCP) to use unicast feedback. The proposed
   extension is useful for single-source multicast sessions such as
   Source-Specific Multicast (SSM) communication where the traditional
   model of many-to-many group communication is either not possible or
   not preferred. In addition, it can be applied to any group that
   might benefit from a sender-controlled summarised reporting
   mechanism.

Table of Contents

   1. Conventions and Acronyms........................................2
   2. Introduction....................................................2
   3. Basic Operation.................................................4


   Chesterfield  Internet Draft - Expires March 2004         [Page 1]


                      RTCP with Unicast Feedback

   4. Definitions.....................................................5
   5. Packet types....................................................6
   6. Simple feedback model...........................................7
   7. Sender feedback summary model...................................8
   8. Mixer/Translator issues........................................17
   9. Transmission interval calculation..............................18
   10. SDP Extensions................................................20
   11. Security Considerations.......................................21
   12. Backwards Compatibility.......................................28
   13. IANA Considerations...........................................29
   14. Open Issues...................................................30
   15. Bibliography..................................................31
   16. Appendix: Distribution Report processing at the receiver......33
   17.AUTHORS ADDRESSES..............................................38
   18. IPR Notice....................................................38
   19. FULL COPYRIGHT STATEMENT......................................39



1. Conventions and Acronyms

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119.


2. Introduction

   The Real-time Transport Protocol (RTP) [1] provides a real-time
   transport mechanism suitable for unicast or multicast communication
   between multimedia applications. Typical uses of RTP are for real-
   time or near real-time group communication of audio and video data
   streams. An important component of the RTP protocol is the control
   channel, defined as the Real-Time Control Protocol (RTCP). RTCP
   involves the periodic transmission of control packets between group
   members in a session, enabling group size estimation and the
   distribution or calculation of session-specific information such as
   packet loss and round trip time to other hosts. An additional
   advantage of providing a control channel for a session is that a
   third-party session monitor can listen to the traffic to establish
   network conditions and to diagnose faults based on receiver
   locations.

   RTP was designed to operate in a unicast mode or in the traditional
   multicast mode of Any Source Multicast (ASM) group communication,
   where both one-to-many and many-to-many communication are supported
   via a common group address in the range 224.0.0.0 through
   239.255.255.255. Typical intra-domain routing protocols, that is
   protocols that operate only within a single administrative domain,
   that enable such communication are the Distance Vector Multicast
   Routing Protocol (DVMRP) [15] or Protocol Independent Multicast
   (PIM) [16][17]. Typically these are used in combination with an



Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 2]


                      RTCP with Unicast Feedback

   Inter-domain routing protocol, that is to say a protocol that
   operates across administrative domain borders, such as the Multi-
   protocol extension to the Border Gateway Protocol (MBGP) [18] in
   combination with the Multicast Source Discovery Protocol (MSDP)
   [19]. Such routing protocols enable a host to join a single
   multicast group address and to send to or to receive data from all
   members in the group with no prior knowledge of the membership
   across any multicast-enabled portion of the internet. In order to
   enable such a service in the network, however, there is a great deal
   of complexity involved at the routing level.

   The many-to-many mode of communication however is not always desired
   by or, in some cases, even available to an application. The recent
   popularity of Source-Specific Multicast (SSM) is one such example
   where the multicast distribution channel is only available to
   source-to-receiver traffic. In other cases, such as large ASM groups
   with a single active data source and many passive receivers, it is
   not optimal to create a full routing level mesh of multicast sources
   just for the distribution of control packets.  Thus an alternative
   solution is preferable.

   The effect of using a unidirectional broadcast topology for RTP is
   that it removes the ability for receivers in the group to
   communicate RTCP control information with all other members in the
   group, whether for reasons of resource economy or availability. In
   this draft, therefore, we define a solution to this problem.  We
   introduce unicast feedback as a new method to distribute control
   information amongst all members in a multicast session. It is
   designed to operate under any group communication scenario (ASM or
   SSM). The RTP data stream protocol itself is unaffected. The basic
   architectural models to which the unicast feedback method could
   provide benefit include but are not limited to:


   a) SSM groups with a single sender.

      The proposed extensions allow SSM groups that do not have many-
      to-many communication capability to still receive RTP data
      streams and to continue to participate in the RTP control
      protocol, RTCP, by using multicast in the source-to-receiver
      Direction and unicasting receiver feedback to the source on the
      standard RTCP port.

   b) One-to-many broadcast networks.

      An example of such a network is a satellite network with a
      terrestrial low-bandwidth return channel or a broadband cable
      link. Unlike the SSM network, this communication architecture may
      have the ability for a receiver to multicast return data to the
      group, however, a unicast feedback mechanism is likely to be
      preferable for routing simplicity.

   c) ASM with a single sender.


Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 3]


                      RTCP with Unicast Feedback

      An SDP [5] session announcement may identify a session as having
      a single sender receiving unicast RTCP feedback. Receivers join
      the multicast group address and receive RTP and RTCP data from
      the source on the specified address/port combinations. However,
      the RTCP feedback is unicast back to the source on the RTCP port.
      The unicast feedback approach may help to prevent overtaxing
      multicast routing infrastructure that does not scale as
      efficiently. However, it is not more efficient than a standard
      multicast group RTP communication scenario, and therefore is not
      expected to replace the traditional mechanism.

   The modifications proposed in this document are intended to
   supplement the existing RTCP feedback mechanisms described in [1],
   Section 6.


3. Basic Operation

   This draft proposes two new methods to enable receiver feedback to
   all members in a session. Each involves the unicasting of RTCP
   packets to a source whose job it is to re-distribute the information
   to the members of the group. The source must be able to communicate
   with all group members in order for either mechanism to work.

   The content of receiver RTCP traffic will continue to include
   Receiver Reports (RRs) and Session Description (SDES) information
   since they are never active sources in the session. Additionally,
   Goodbye (BYE) packets and Application-defined (APP) packets may also
   be transmitted. The various reports may be combined into a single
   RTCP packet, which should not exceed the path MTU. Packets continue
   to be sent at a rate that is inversely proportional to the group
   size in order to scale the amount of traffic generated.

   The first method, the 'Simple Feedback Model', is a basic reflection
   mechanism whereby all Receiver RTCP packets are unicast to the
   source and subsequently forwarded by the source to all receivers on
   the multicast RTCP channel. The advantage of using this method is
   that an existing receiver implementation requires little
   modification in order to use it. Instead of sending reports to a
   multicast address, a receiver uses a unicast address to send reports
   to the source, yet still receives forwarded RTCP traffic on the
   multicast control data channel. This method also has the advantage
   of being backwards compatible with RTP/RTCP implementations that do
   not support unicast feedback to the source and that operate using
   the standard multicast group communication model, ASM. In a session
   that uses ASM, such a receiver would multicast reports to the group
   address and designated RTCP port as stated in [1]. The reports would
   be directly received by all members. In a session using SSM, the
   network SHOULD prevent any multicast data from the receiver being
   distributed further than the first hop router. Additionally, any
   data heard from a non-unicast capable receiver by other hosts on the
   same subnet SHOULD be filtered out by the host IP stack and
   therefore will not cause problems with respect to the calculation of
   the Receiver RTCP bandwidth share.

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 4]


                      RTCP with Unicast Feedback


   The second method, the 'Sender Feedback Summary Model', is a
   summarised reporting scheme that provides savings in bandwidth by
   consolidating Receiver Reports at the source into one summary packet
   that is then distributed to all the receivers. The advantage of this
   scheme is apparent for large group sessions where the basic
   forwarding mechanism outlined above would create a large amount of
   packet replication to forward all the information to all the
   receivers. The basic operation of the scheme is the same as the
   first method; receivers send feedback via unicast to the source, and
   the source distributes summaries of the feedback over the multicast
   channel. However, the technique requires that all session members
   understand the new summarised packet format outlined in Section 7.1.
   Additionally, the summarised scheme provides an optional mechanism
   to send distribution information or histograms about the feedback
   data reported by the whole group. Potential uses for the compilation
   of distribution information are addressed in Section 7.4.

   To differentiate between the two reporting methods, a new SDP
   identifier is created and discussed in Section 10. The reporting
   method MUST be decided prior to the start of the session. A
   distribution source MUST NOT change the method during a session.


4. Definitions

   Distribution Source:
        In an SSM context, only one source distributes RTP data and
        redistributes RTCP information to all receivers. That source is
        called the distribution source. In order for unicast feedback
        to work, there MUST be only one session distribution source for
        any subset of receivers to which RTCP feedback is directed.
        Note that heterogeneous networks comprised of ASM multiple-
        sender groups, unicast-only clients and/or SSM single-sender
        receiver groups MAY be connected via translators or mixers to
        create a single-source group (see Section 9 for details).

   RTP and RTCP Channels:
        The data distributed from the source to the receivers is
        referred to as the RTP channel and the control information the
        RTCP channel. With standard RTP/RTCP, these channels typically
        share the same multicast address but are differentiated via
        port numbers as specified in [1].

   Unicast RTCP Feedback Target:
        For a session defined as having a distribution source A, on
        ports n for the RTP channel and k for the RTCP channel, the
        unicast RTCP feedback target is the IP address of Source A on
        port k unless otherwise stated in the session description. See
        Section 10 for details on how the address is specified.

   SSRC:
        Synchronization source. A 32-bit value that uniquely identifies
        each member in a session. See [1] for further information.

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 5]


                      RTCP with Unicast Feedback


   Report blocks:
        RTCP [1] encourages the stacking of multiple report blocks in
        Sender and Receiver Report packets. As a result, a variable
        size feedback packet is created and sent from one source that
        pertains to multiple other sources in the group. Report block
        is the standard terminology for an RTCP reception report and
        multiple report blocks may be sent in the same packet.


5. Packet types

   The RTCP packet types defined in [1], [6], and [10] are:

   Type       Description                  Payload number
   -------------------------------------------------------
   SR         Sender Report                200
   RR         Receiver Report              201
   SDES       Source Description           202
   BYE        Goodbye                      203
   APP        Application-Defined          204
   RTPFB      Generic RTP feedback         205
   PSFB       Payload-specific feedback    206
   XR         RTCP Extension               207


   This document defines one further RTCP packet format:

   type       description                    Payload number
   ---------------------------------------------------------
   RSI        Receiver Summary Information   208

   Within the Receiver Summary Information packet, various types of
   distribution data may be reported, each of which requires a
   distribution type identifier for report blocks.  In addition, other
   information may be reported, also encapsulated in separate report
   blocks.

   The sub-types identifying the report blocks are:

   Report Block Type    Description                    Identifier
   number
   ------------------------------------------------------------------
   IPv4 Address      IPv4 Unicast Feedback address        0
   IPv6 Address      IPv6 Unicast Feedback address        1
   DNS name          DNS name for Unicast Feedback        2
   -                 - reserved -                         3
   Jitter            Jitter distribution                  4
   RTT               Round trip time distribution         5
   Cumulative loss   Cumulative loss distribution         6
   Loss              Loss distribution                    7
   Collisions        SSRC collision list                  8
   BYE               BYE list                             9
   Stats             General statistics                   10

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 6]


                      RTCP with Unicast Feedback

   Receiver BW       RTCP Receiver Bandwidth              11
   -                 - reserved -                         12 - 255


6. Simple feedback model

6.1 Packet Formats

   The simple feedback model uses the same packet types as traditional
   RTCP feedback described in [1]. Receivers still generate Receiver
   Reports with information on the quality of the stream received from
   the source. The distribution source still must create Sender Reports
   that include timestamp information for stream synchronisation and
   round trip time calculation. Both senders and receivers are required
   to send SDES packets as outlined in [1]. The rules for generating
   BYE and APP packets as outlined in [1] also apply.


6.2 Distribution Source behaviour

   For the simple feedback model, the source MUST provide a basic
   packet reflection mechanism. It is the default behaviour for any
   distribution source and is the minimum requirement for acting as a
   source to a group of receivers using unicast RTCP feedback.

   In this model, the source MUST not stack report blocks received from
   different SSRCs into one packet for retransmission to the group.
   Every RTCP packet from each receiver MUST be reflected individually.

   The source (which is the unicast feedback target) MUST listen for
   unicast RTCP data sent to the RTCP port. All unicast data received
   on this port MUST be forwarded by the source to the group on the
   multicast RTCP channel. If the application can determine the
   destination address of an RTCP packet as being non-unicast, the
   packet MUST NOT be forwarded but processed as defined in [1].

   The reflected traffic SHOULD NOT be included in the transmission
   interval calculation by the source. In other words, the source
   SHOULD NOT consider reflected packets as part of its own control
   data bandwidth allowance. However, they MUST be processed by the
   source and the average RTCP packet size, RTCP transmission rate, and
   RTCP statistics must be calculated.  The algorithm for computing the
   allowance is explained in Section 9.

   If an application wishes to use APP packets, it is recommended that
   the simple feedback model be used since it is likely that all
   receivers in the session will need to hear the APP specific packets.
   The same applies for all other RTCP packets that are not defined in
   the base RTP specification [1]. The decision to use the simple
   feedback model MUST be made in advance of the session and MUST be
   indicated in the SDP announcement [5].




Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 7]


                      RTCP with Unicast Feedback

6.3 Receiver behaviour

   Receivers listen on the RTP channel for data and the RTCP channel
   for control. Each receiver calculates its share of the control
   bandwidth based on the standard rule that a fraction of the receiver
   bandwidth R/n_r -- with R indicating the RTCP bandwidth share for
   the receivers and n the number of receivers-- of the RTCP bandwidth
   is divided equally between all unique receiver SSRCs in the session.
   See Section 9 for further information on the calculation of the
   bandwidth allowance. When a receiver is eligible to transmit, it
   sends a unicast Receiver Report packet to the RTCP port of the
   distribution source.


7. Sender feedback summary model

   In the sender feedback summary model, the source is required to
   summarise the information received from all the Receiver Reports
   generated by the receivers and place the information into summary
   reports. The sender feedback summary model introduces a new report
   block format and a number of optional report block formats. The
   Receiver Summary Information report (RSI) is required and MUST be
   sent by a source if the summarised feedback mechanism is selected.
   Transmission of sub-report types is OPTIONAL.  They MAY be appended
   to the RSI report block to provide more detailed information on the
   overall session characteristics reported by all receivers and also
   to convey important information such as the feedback address and
   reporting bandwidth.

   The sender MUST send at least one Receiver Summary Information
   packet for each reporting interval. The sender can additionally
   stack report blocks after the RSI packet. Each report block
   corresponds to the initial RSI packet and acts as an enhancement to
   the basic summary information required by the receivers to calculate
   their reporting time interval. For this reason, report blocks are
   not required but recommended. RSI and corresponding report blocks
   are sent in addition to the standard sender-issued packets, such as
   Sender Reports and SDES packets outlined in [1].


7.1 Packet Formats


 7.1.1 RSI: Receiver Summary Information Packet

   The RSI report block has a fixed header size of 4 octets followed by
   a variable length report:








Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 8]


                      RTCP with Unicast Feedback

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |V=2|P|reserved |   PT=RSI=208  |             length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           SSRC/CSRC                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                           Timestamp                           +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Group size                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                     optional report blocks                    :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The RSI packet includes the following fields:

   SSRC: 32 bits
      The SSRC of the distribution source.

   Timestamp: 64 bits
      Indicates the wallclock time, which is seconds relative to 0h UTC
      on 1 January 1900, when this report was sent.  This value is used
      to enable detection of duplicate packets, reordering and to
      provide a chronological profile of the feedback reports.

   Group size: 32 bits
      This field provides the sender's view of the number of receivers
      in a session. This MUST include the sender itself and any other
      senders potentially connected to the session, e.g., via a
      mixer/translator gateway. The group size is calculated according
      to the rules outlined in [1].


7.1.2 Optional Report Block Types

   For RSI reports, this document also introduces a report block format
   specific to the RSI packet. The report blocks are appended to the
   RSI packet using the following generic format.  All report blocks
   MUST be 32-bit aligned.


  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      RBT      |    Length     |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       RBT-specific data       +
 |                                                               |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 9]


                      RTCP with Unicast Feedback

   RBT: 8 bits
      Report block Type. The report block type identifier.  The values
      for the report block types are defined in section 5.

   Length: 8 bits
      The length of the sub-report in 32-bit words.

   RBT-specific data: <Length*4 - 2> octets
      This field may contain type-specific information based upon the
      RBT value.


 7.1.3 Generic Report Block Fields

   For the report blocks that convey distributions of values (Loss,
   Jitter, RTT, Cumulative Loss), a flexible 'data bucket' style report
   is used. This divides the data set into variable size buckets that
   are read based upon the guide fields at the head of the report
   block.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |      RBT      |    Length     |        NDB            |   MF  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Minimum Distribution Value                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Maximum Distribution Value                  |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                      Distribution Buckets                     |
 |                             ...                               |
 |                             ...                               |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   The RBT and Length fields are calculated as explained in section
   7.1.2.

   Number of distribution buckets (NDB): 12 bits
      The number of distribution buckets of the data. The size of the
      bucket can be calculated using the formula, number of bits equals
      ((length * 4) - 12)*8/NDB. The calculation is based upon the
      length of the whole report block in octets (length field * 4)
      minus the header of 12 octets. Providing 12 bits for the NDB
      field enables bucket sizes as small as 2 bits for a full length
      packet of MTU 1500 bytes. The bucket size in bits must always be
      divisible by 2 to ensure proper byte alignment. A bucket size of
      2 bits is fairly restrictive, however, and it is expected that
      larger bucket sizes will be more practical for most
      distributions.

   Multiplicative Factor (MF): 4 bits
      MF+1 indicates the multiplicative factor to be applied to each
      distribution Bucket value.  Possible values are 0 - 15,
      indicating factors 1 - 16.

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 10]


                      RTCP with Unicast Feedback


   Length: 8 bits
      The length field tells the receiver the full length of the report
      block in 32-bit words, and enables the receiver to identify the
      bucket size. For example, based on a Maximum ethernet MTU of 1500
      bytes, the data portion of a distribution packet may be only as
      large as 1008 bytes, providing up to 4032 data buckets of length
      2 bits, or 2016 data buckets of length 4 bits etc...

   Minimum distribution value (min): 32 bits
      The minimum distribution value, in combination with the maximum
      distribution value, indicates the range covered by the data
      bucket values.

   Maximum distribution value (max): 32 bits
      The maximum distribution value, in combination with the minimum
      distribution value, indicates the range covered by the data
      bucket values. The significance and range of the distribution
      values is defined in the individual profiles for each
      distribution type (DT).

   Distribution buckets: each bucket is ((length * 4) - 12)*8/NDB bits
      The size and number of buckets is calculated as outlined above
      based upon the value of NDB and the length of the packet. The
      values for distribution buckets are equally distributed;
      according to the following formula, distribution bucket x (with 0
      <= x < NDB) covering the value range:

             [ min+(max-min)/NDB*x ; min+(max-min)/NDB*(x+1) ]

   Interpretation of the minimum, maximum and distribution values in
   the report block are profile-specific and are addressed individually
   in the sections below. The size of the report block is variable, as
   indicated by the packet length field.


 7.1.4 Loss report block

   The loss report block allows a receiver to determine how its own
   reception quality relates to the other recipients.  A receiver may
   use this information e.g. to drop out of a session (instead of
   sending lots of error repair feedback) if it finds itself isolated
   at the lower end of the reception quality scale.

   The report block indicates the distribution of losses as reported by
   the receivers to the distribution source. Values are expressed as a
   fixed-point number with the binary point at the left edge of the
   field similar to the "fraction lost" field in SR and RR packets as
   defined in [1]. The report block type (RBT) is 3.

   Valid results for the minimum distribution value field are 0 - 254.
   Similarly, valid results for the maximum distribution value field
   are 1 - 255. The minimum distribution value MUST always be less than
   the maximum.

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 11]


                      RTCP with Unicast Feedback


   For examples on processing summarised loss report blocks, see the
   Appendix.




  7.1.5 Jitter report block

   A jitter report block indicates the distribution of the estimated
   statistical variance of the RTP data packet interarrival time
   reported by the receivers to the distribution source. This allows
   receivers both to place their own observed jitter values in context
   with the rest of the group, and to approximate dynamic parameters
   for playout buffers. See [1] for details on how the values are
   calculated and the relevance of the jitter results. Jitter values
   are measured in timestamp units and expressed as unsigned integers.
   The minimum distribution value must always be less than the maximum.
   The report block type (RBT) is 4.


  7.1.6 Round Trip Time report block

   A round trip time report indicates the distribution of round trip
   times from the distribution source to the receivers, providing
   receivers with a global view of the range of values in the group.
   The distribution source is the only member of the group capable of
   calculating the round trip time to any other members since it is the
   only sender in the group. The sender has the option of distributing
   these round trip time estimations to the whole group, uses of which
   are described in Section 7.4. Round trip times are measured in
   timestamp units and expressed as unsigned integers. The
   multiplicative factor can be used to reduce the number of bits
   required to represent the values. The minimum distribution value
   MUST always be less than the maximum. The report block type (RBT) is
   5.


  7.1.7 Cumulative Loss report block

   The cumulative loss field, in contrast to the Average Fraction Lost
   field, in a Receiver Report [1] is intended to provide some
   historical perspective on the session performance. The distribution
   is provided as a percentage figure based on the long term
   accumulation of values. The sender must maintain a record of the
   Cumulative number lost and Extended Highest Sequence number received
   as reported by each receiver, ideally the recorded values are from
   the first report received. Future calculations are then based on
   (the new cumulative loss value - the recorded value) / (new extended
   highest sequence number - recorded sequence number) * 100. The
   report block type (RBT) is 6.




Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 12]


                      RTCP with Unicast Feedback

  7.1.8 Feedback Address Target report block

   The feedback address target block provides a dynamic mechanism for
   the source to signal an alternative unicast RTCP feedback address to
   the receivers. If this field is included, it MUST override any
   static SDP address information for the session.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  RBT={0,1,2}  |     Length    |             Port              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                            Address                            :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length: 8 bits
      The length of the report block in 32-bit words. For an IPv4
      address this should be 2 (e.g. Total length = 4 + 4 = 2*4
      Octets). For an IPv6 address this should be 5).  For a DNS name,
      the length field indicates the padded number of 32-bit words
      making up the string plus 1.

   Port: 2 octets (optional)
      The port number to direct reports to.  A port number of 0 is
      invalid and MUST NOT be used.

   Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
      The address to which receivers send feedback reports.  For IPv4
      and IPv6 fixed-length address fields are used.  A DNS name is an
      arbitrary length string that is padded with null bytes to the
      next 32 bit boundary.  The string is UTF-8 encoded (RFC 2279).
      For IPv4, RBT=0.  For IPv6, RBT=1. And for the DNS name for
      unicast feedback, RBT=2.

   A feedback target address block with a certain RBT MUST NOT occur
   more than once.  Feedback target address blocks for IPv4 and IPv6
   MAY both be present.  If so, the resulting transport addresses MUST
   point to the same logical entity (i.e. the distribution source).

   If feedback target address block with a an RBT indicating a DNS name
   is present, another feedback target address block MUST NOT be
   present.



 7.1.9 Collisions report block

   The collision SSRC report provides the source with a mechanism to
   report SSRC collisions amongst the group. In the event that a non-
   unique SSRC is discovered based on the tuple [SSRC,CNAME], the


Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 13]


                      RTCP with Unicast Feedback

   collision is reported in this block and the affected nodes must
   reselect an SSRC identifier.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     RBT=8     |    Length     |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                         Collision SSRC                        :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Collision SSRC: n x 32 bits
      The final fields in the packet are used to identify any SSRCs
      that are duplicated within the group. Usually this is handled by
      the hosts upon detection of the same SSRC, however since
      receivers in an SSM context no longer have a global view of the
      session, the collision algorithm is handled by the source. SSRCs
      that collide are listed in the packet.  Each Collision SSRC is
      included repeatedly in Collision report blocks and sent at least
      five times.  If more Collision SSRCs need to be reported than fit
      into an MTU, the reporting is done in a round robin fashion so
      that all Collision SSRCs have been reported once before the
      second round of reporting starts.  On receipt of the packet,
      receiver(s) MUST detect the collision and select another SSRC,
      if the collision pertains to them.


 7.1.10 General Statistics report block

   The general statistics report block is used if specifying buckets is
   deemed too complex so that only cumulative values shall be reported
   back.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     RBT=10    |    Length     |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      AFL      |                    HCNL                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Average interarrival jitter                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Average fraction lost (AFL): 8 bits
      The average fraction lost indicated by Receiver Reports forwarded
      to this source, expressed as a fixed point number with the binary
      point at the left edge of the field.  A value of all '1's
      indicates that the AFL field is not provided.

   Highest cumulative number of packets lost (HCNL): 24 bits

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 14]


                      RTCP with Unicast Feedback

      Highest 'cumulative number of packets lost' value out of all RTCP
      RR packets since the last RSI from any of the receivers.  A value
      of all '1's indicates that the HCNL field is not provided.

   Average interarrival jitter: 32 bits
      Average 'interarrival jitter' value out of all RTCP RR packets
      since the last RSI from the receiver set.  A value of all '1's
      indicates that this field is not provided.


7.1.11 RTCP Bandwidth indication block

   This report block is used to inform the receivers about the maximum
   total relative RTCP bandwidth that is used by (all) the sender(s) or
   about the maximum total bandwidth allowance for all receivers.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     RBT=11    |     Length    |S|R|         Reserved          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        RTCP Bandwidth                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Sender (S): 1 bit
      The contained bandwidth value applies to all RTCP senders.

   Receivers (R): 1 bit
      The contained bandwidth value applies to all RTCP receivers.

   Reserved: 14 bits
      MUST be set to zero upon transmission and ignored upon reception.

   RTCP Bandwidth: 32 bits
      If the S bit is set to 1, this field indicates the maximum
      bandwidth allocated to the sender(s).  This informs the receivers
      about the RTCP report frequency to be expected from the senders.
      This is a fraction value indicating a percentage of the session
      bandwidth, expressed as a fixed-point number with the binary
      point at the left edge of the field.

      If the R bit is set to 1, this field indicates the maximum
      bandwidth allocated jointly to all receivers for sending RTCP
      data relating to the session. This is a fraction value indicating
      a percentage of the session bandwidth, expressed as a fixed-point
      number with the binary point at the left edge of the field.  Each
      receiver uses this value to calculate its bandwidth allowance as
      <RTCP Bandwidth> / <number of receivers>.  The number of
      receivers if known from the <group size> field in the RSI packet
      header.




Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 15]


                      RTCP with Unicast Feedback

7.2 Distribution Source behaviour

   The source is responsible for accepting RTCP packets from the
   receivers, interpreting and storing the per-receiver information as
   defined in [1]. The importance of this is apparent when creating the
   RSI and report block reports, since incorrect information can have
   serious implications. Section 11 addresses the security risks in
   detail.

   Either the group size or the Receiver RTCP Bandwidth fields MUST be
   included. A sender has the option of masking the group size by
   setting it to a value of choice, however the receiver bandwidth
   field MUST be included. If both are included, the bandwidth field
   MUST override the Session bandwidth/group size calculation as
   outlined in [1]. The Receiver RTCP Bandwidth field therefore
   provides the source with the capability to control the amount of
   feedback from the receivers and MAY be increased or decreased based
   on the requirements of the source. Regardless of the value selected
   by the source for the Receiver RTCP Bandwidth field, the source MUST
   continue to forward Sender Reports and RSI packets at the rate
   allowed by the total RTCP bandwidth allocation. See Section 9 for
   further details about the frequency of reports.

   In order to identify SSRC collisions, the source is responsible for
   maintaining a record of each SSRC and the corresponding CNAME within
   at least one reporting interval by the group in order to
   differentiate between clients. It is RECOMMENDED that an updated
   list of more than one interval be maintained to increase accuracy.
   This mechanism should prevent the possibility of collisions since
   the combination of SSRC and CNAME should be unique if the CNAME is
   generated correctly. If collisions are not detected, the source will
   have an inaccurate impression of the group size. Since the
   statistical probability is very low that collisions will both occur
   and be undetectable, this should not be a significant concern.  In
   particular, the clients would have to randomly select the same SSRC
   and have the same username + IP address (e.g., using private address
   space behind a NAT router).

   For the optional report blocks, the source MAY decide which are the
   most significant feedback values to convey and MAY choose not to
   include any. The packet format provides flexibility in the amount of
   detail conveyed by the data points. There is a trade-off between the
   granularity of the data and the accuracy based on the factorisation
   values, the number of buckets and the min and max values. In order
   to focus on a particular region of a distribution, the source can
   adjust the minimum and maximum values and either increase the number
   of buckets and possibly the factorisation, or decrease the number of
   buckets and provide more accurate values. See Appendix B for
   detailed examples on how to convey a summary of RTCP Receiver
   Reports as RSI report block information.

   The results should correspond as near as possible to the values
   received during the interval since the last report. The source may
   stack as many report blocks as required in order to convey different

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 16]


                      RTCP with Unicast Feedback

   distributions. If the distribution size exceeds the largest packet
   length (1008 bytes data portion), more packets MAY be stacked with
   additional information up to the MTU of the session.


7.3 Receiver behaviour

   The receiver MUST process RSI packets and adapt session parameters
   such as the RTCP bandwidth based on the information received. The
   receiver no longer has a global view of the session, and will
   therefore be unable to receive information from individual receivers
   aside from itself. However, the information portrayed by the source
   can be extremely detailed, providing the receiver with an accurate
   view of the session quality overall, without the processing overhead
   associated with listening to and analysing all Receiver Reports.

   The SSRC collision list MUST be checked against the SSRC selected by
   the receiver to ensure there are no collisions. The group size value
   provides the receiver with the data necessary to calculate its share
   of the RTCP bandwidth. The Receiver RTCP Bandwidth field may
   override this value. The Receiver RTCP Bandwidth field provides the
   source with the capability to control the amount of feedback from
   the receivers.

   The receiver can use the summarised data as desired. This data is
   most useful in providing the receiver with a more global view of the
   conditions experienced by other receivers, and enables the client to
   place itself within the distribution and establish the extent to
   which its reported conditions correspond to the group reports as a
   whole. Appendix A provides further information and examples of data
   processing at the receiver.

   The receiver SHOULD assume that any report blocks in the same packet
   correspond to the same data set received by the source during the
   last reporting time interval. This applies to packets with multiple
   blocks, where each block conveys a different range of values.


8. Mixer/Translator issues

   The original RTP specification allows a session to use mixers and
   translators which help to connect heterogeneous networks into one
   session. There are a number of issues, however, which are raised by
   the unicast feedback model proposed in this document. The term
   'mixer' refers to devices that provide data stream multiplexing
   where multiple sources are combined into one stream. Conversely, a
   translator does not multiplex streams, but simply acts as a bridge
   between two distribution mechanisms, e.g., a unicast-to-multicast
   network translator. Since the issues raised by this draft apply
   equally to either a mixer or translator, they are referred to from
   this point onwards as mixer-translator devices.

   A mixer-translator between distribution networks in a session must
   ensure that all members in the session receive all the relevant

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 17]


                      RTCP with Unicast Feedback

   traffic to enable the usual operation by the clients. A typical use
   may be to connect an older implementation of an RTP client with an
   SSM distribution network, where the client is not capable of
   unicasting feedback to the source. In this instance the mixer-
   translator must join the session on behalf of the client and send
   and receive traffic from the session to the client. Certain hybrid
   scenarios may have different requirements.


8.1 Use of a mixer-translator

   The mixer-translator MUST adhere to the SDP description [5] for the
   single source session (Section 10) and use the feedback mechanism
   indicated. Receivers SHOULD be aware that by introducing a mixer-
   translator into the session, more than one source may be active in a
   session since the mixer-translator may be forwarding traffic from
   either multiple unicast sources or from an ASM session to the SSM
   receivers. Receivers SHOULD still forward unicast RTCP reports in
   the usual manner to the distribution source, which in this case
   would be the mixer-translator itself. It is RECOMMENDED that the
   simple packet reflection mechanism be used under these circumstances
   since attempting to coordinate RSI + summarisation reporting between
   more than one source may be complicated unless the mixer-translator
   is capable of undertaking the summarisation itself.


8.2 Encryption and Authentication issues

   Encryption and security issues are discussed in detail in Section
   11. A mixer-translator MUST be able to follow the same security
   policy as the client in order to unicast forward RTCP feedback to
   the source, and it therefore MUST be able to apply the same
   authentication and/or encryption policy required for the session.
   Transparent bridging, where the mixer-translator is not acting as
   the distribution source, and subsequent unicast feedback to the
   source is only allowed if the mixer-translator can conduct the same
   source authentication as required by the receivers. A translator may
   forward unicast packets on behalf of a client, but SHOULD NOT
   translate between multicast to unicast flows towards the source
   without authenticating the source of the feedback address
   information.


9. Transmission interval calculation

   The Control Traffic Bandwidth referred to in [1] is an arbitrary
   amount which is intended to be supplied by a session management
   application (e.g., [20]) or decided based upon the bandwidth of a
   single sender in a session.

   The RTCP transmission Interval calculation remains the same as in
   the original RTP specification [1]. In the original specification,
   the senders are allocated a fraction of S/(R+S) of the control
   traffic bandwidth if they number S/(R+S) or less than the group

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 18]


                      RTCP with Unicast Feedback

   size. Otherwise the allocation for senders is the percentage of
   senders to group size. The remaining bandwidth is allocated to the
   receivers and is divided evenly amongst them.


   9.1 Receiver RTCP Transmission

   If the distribution source is operating in simple feedback mode
   (which may be indicated in the corresponding session description for
   the media session but which the receiver also notices from the
   absence of RTCP RSI packets), a receiver MUST calculate the number
   of other members in a session based upon its own SSRC count derived
   from the forwarded Receiver Reports it receives.  The receiver MUST
   calculate the average RTCP packet size from all the RTCP packets it
   receives.

   If the distribution source is operating in sender feedback summary
   mode, the receiver MUST use the group size field and the average
   RTCP packet size field from the respective RTCP RSI header fields.

   A receiver uses these values as input to the calculation of the
   deterministic calculated interval as per [1].


   9.2 Distribution Source RTCP Transmission

   If operating in simple feedback mode, the distribution source should
   calculate the transmission interval for its sender reports and
   associated RTCP packets based upon the above control traffic
   bandwidthand considering itself the only RTP sender.  Receiver
   reports will be forwarded as they arrive without further
   consideration.  The distribution source MAY validate for all or
   selected receivers whether they roughly adhere to the calculated
   bandwidth constraints and drop excess packets for receivers that do
   not.  In all cases, the average RTCP packet size is determined from
   the receivers' RTCP packets forwarded and those originated by the
   distribution source.

   If operating in sender feedback summary mode, the distribution
   source does not share the forward RTCP bandwidth with any of the
   receivers.  Therefore, the distribution source SHOULD use the full
   RTCP bandwidth for sender reports and associated RTCP packets as
   well as RTCP RSI packets.  In this case, the average RTCP packet
   size is only determined from the RTCP packets originated by the
   distribution source.

   The distribution source uses these values as input to the
   calculation of the deterministic calculated interval as per [1].


   9.3 Operation in conjunction with AVPF

   If the RTP session is an AVPF session [10] (as opposed to a regular
   AVP [11] session the receivers MAY modify their RTCP report

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 19]


                      RTCP with Unicast Feedback

   scheduling as defined in [10].  Use of AVPF does not affect the
   sender RTCP transmission or forwarding behavior nor the sender's
   summarization.

   In the event that APP specific packets without a defined
   summarisation format are to be used, the reflection mode of
   operation MUST be adopted from the start.


10. SDP Extensions

   The Session Description Protocol (SDP) [5] is used as a means to
   describe media sessions in terms of their transport addresses,
   codecs, and other attributes. Providing RTCP feedback via unicast as
   specified in this document constitutes another session parameter
   needed in the session description. Similarly, other single-source
   multicast RTCP feedback parameters need to be provided, such as the
   summarisation mode at the sender and the target unicast address to
   which to send feedback information.  This section defines the SDP
   parameters that are needed by the proposed mechanisms in this draft
   (and that also need to be registered with IANA).


10.1 SSM RTCP Session Identification

   A new session level attributes MUST be used to indicate the use of
   unicast instead of multicast feedback: "rtcp-unicast".

   This attribute uses one parameter to specify the mode of operation.

   Rtcp-unicast:reflection -- MUST be used to indicate packet
   reflection by the RTCP target (without further processing).

   Rtcp-unicast:rsi        -- MUST be used to indicate the "Receiver
   Summary Information" mode of operation.


10.2 SSM Source Specification

   In addition, in a Source-Specific Multicast RTCP session, the
   sender(s) need to be indicated for both source-specific joins to the
   multicast group, as well as for addressing unicast RTCP packets on
   the backchannel from receivers to the source.

   This is done following the proposal for SDP source filters
   documented in [4].

   From this specification, only the inclusion mode
   ("a=source-filter:incl") MUST be used for SSM RTCP.

   There SHOULD be exactly one "a=source-filter:incl" attribute listing
   the address of the sender.  The RTCP port MUST be derived from the
   m= line of the media description.


Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 20]


                      RTCP with Unicast Feedback

   An alternative feedback address and port may be supplied using the
   SDP RTCP attribute [12], e.g. a=rtcp:<port> IN IP4 192.168.1.1.


11. Security Considerations

   The level of security provided by the current RTP/RTCP model MUST
   NOT be diminished by the introduction of unicast feedback to the
   source. This section identifies the security weaknesses introduced
   by the feedback mechanism, potential threats and level of protection
   that MUST be adopted. Any Suggestions on increasing the level of
   security provided to RTP sessions above the current standard are
   RECOMMENDED but OPTIONAL.

   [JO: The major overall issue with the security considerations
   section is that the chairs would like us to give concrete guidelines
   rather than just general observations.  We need to work through this
   section and fix this.  Will be in the next revision though.]


11.1 Assumptions

   RTP/RTCP is a protocol for carrying real-time multimedia traffic,
   and therefore one of the main requirements for solutions must be to
   maintain as low an overhead as possible. This includes the
   consideration of overhead for different applications and types of
   cryptographic operations, as well as considerations for deploying or
   creating security infrastructure for large groups.

   The distribution of session parameters, typically encoded as SDP
   objects, through SAP [21], email or the web is beyond the scope of
   this document. It is RECOMMENDED, however, that the method used
   employs adequate security measures to ensure the integrity and
   authenticity of the information. Suggested solutions which would
   meet the security requirements outlined here are included at the end
   of this section.

   In practice, the multicast and group distribution mechanism, e.g.,
   the SSM routing tree, is not immune to source IP address spoofing or
   traffic snooping. All security weaknesses are therefore addressed
   from a transport level perspective or above.

11.2 Security threats

   Attacks on media distribution and feedback architecture described in
   this document may take a variety of forms, the following section
   outlines the types of attacks in detail.

   a) Denial of Service

      A major area of concern is a denial of service attack. Due to the
      nature of the communication architecture thiscan be generated in
      a number of ways by using the unicast feedback characteristic to
      the attackers advantage.

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 21]


                      RTCP with Unicast Feedback


   b) Packet Forgery

      One potential area of attack is packet forgery. In particular, it
      is important to protect the integrity of certain influential
      packets since compromise of certain control packets could
      directly affect the transmission characteristics of the whole
      group.

   c) Session Replay

      The potential for session recording and subsequent replay is an
      additional concern.  An attacker may not actually need to
      understand the packet contents, but simply have the ability to
      record the data stream and, at a later time, replay it to any
      receivers that are listening. This is less effective than a
      direct denial of service attack, since the integrity of the
      original session packets would not be affected, however the
      feedback at that time by the receiver group to the source would
      be unexpected.

   d) Eavesdropping on a session

      The consequences of eavesdropping by an attacker on a session may
      not directly constitute a security weakness, however it might
      benefit other types of attack, and should therefore be considered
      as a potential threat. For example, an attacker might be able to
      use the information obtained to perform an intelligent DoS
      attack.


11.3 Security properties

   The following security types are relevant to the threats outlined
   above and will be addressed in greater detail.

   a) Data integrity

      Ensures that any third party has not tampered with the data
      received from the network, either maliciously or through a
      network error. This property ensures that each packet received is
      guaranteed to be in exactly the same condition as intended.

   b) Data authenticity

      Ensures the origin of the message can either be uniquely
      identified, or in the case of group authentication can be
      identified as coming from a specific trusted group of sources.

   c) Data confidentiality

      Ensures that only intended receiver(s) can recover the plaintext
      of the transmitted packets,  It does not prevent eavesdroppers


Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 22]


                      RTCP with Unicast Feedback

      receiving the ciphertext but does guarantee that they cannot
      recover the plaintext.

   d) Replay protection

      This prevents an attacker from re-using the packet via simple
      replay without necessarily having to recover the plaintext.



11.4 Architectural Contexts

   The security profile can be divided into two contexts in order to
   better understand the requirements of any solution. The threats
   outlined above are addressed in the following section for each of
   the two communication contexts.

   a) Source to Receiver communication

      The first, and most influential context to protect, is the
      'downstream' communication channel from the source to the
      receivers. This is the main controlling influence over the
      behavour of the group as it controls the bandwidth allocation for
      each receiver and hence the rate at which the RTCP traffic is
      directly unicast back to the source. All traffic that is
      distributed over the downstream channel is generated by a single
      source. Both the RTP data stream and the RTCP control data from
      the source are included in this context, RTCP data generated by
      the source being directly influenced by the feedback received
      from the whole group.

      This context is vulnerable to all four attacks outlined in the
      previous subsection. A denial of service attack from the source
      to the receivers is possible, but less of a concern since the
      worst case effect of sending large volumes of traffic over the
      distribution channel has the potential to reach every receiver,
      but only on a one-to-one basis, this is no different from the
      current multicast model where an individual source may send large
      volumes of traffic to a multicast group. The real danger of
      denial of service attacks in this context comes indirectly via
      compromise of the source RTCP traffic. If receivers are provided
      with an incorrect group size estimate or bandwidth allowance, the
      return traffic to the source may create a distributed DoS effect
      on the source. Similarly, an incorrect feedback address whether
      as a result of a malicious attack or by mistake, e.g., an IP
      address typing error, could directly create a denial of service
      attack on another host.

      An additional concern relating to Denial of Service attacks would
      come in the form of fake BYE packets generated by an attacker and
      forwarded to the source. Such an attack has potential to generate
      a false group size estimation by the source, however if the
      source follows the correct rules for timing out members in a
      session prior to reporting a change in the group size, the

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 23]


                      RTCP with Unicast Feedback

      affected SSRC should continue to report, consequently cancelling
      the BYE report.

      The danger of Packet forgery in the worst case may be to
      maliciously instigate a denial of service attack, e.g. if an
      attacker were capable of spoofing the source address and
      injecting incorrect packets into the data stream or intercepting
      the source RTCP traffic and modifying the fields. Other
      consequences of packet forgery in this context may be the
      compromise of data affecting the integrity of the data received
      both in the RTP stream itself and the RTCP data in general.

      The replay of a session would have the effect of recreating the
      receiver feedback to the source address at a time when the source
      is not expecting additional traffic from a potentially large
      group. The consequences of this type of attack may be less
      effective on their own, but in combination with other attacks
      might be serious.

      Eavesdropping on the session would provide an attacker with
      information on the characteristics of the source to receiver
      traffic such as the frequency of RTCP traffic. If RTCP traffic is
      unencrypted, this might also provide valuable information on
      characteristics such as group size and transmission
      characteristics of the receivers back to the source in addition
      to enabling an attacker to listen to the media streams. In this
      context, the attacker might also have access to personal
      information carried in the SDES packets such as email, phone and
      full username information through traffic analysis.

   b) Receiver to source or gateway communication

      The second context to address is the return traffic from the
      group to the source or gateway. This traffic should only consist
      of RTCP packets, and should include receiver reports, SDES
      information, BYE reports, extended reports (XR), feedback
      messages (RTPFB, PSFB) and possibly Application specific packets.
      The effects of compromise on a single or subset of receivers is
      less likely to have as great an impact as the first context,
      however much of the responsibility for detecting compromise of
      the source data stream relies on the receivers.

      The effects of compromise of the first context with respect to
      critical source RTCP control information would be witnessed most
      seriously in the second context. A large group of receivers may
      unwittingly generate a distributed DoS attack on the source in
      the event that the integrity of the source RTCP channel has been
      compromised and is not detected by the individual receivers.

      An attacker capable of instigating a packet forgery attack could
      introduce false RTCP traffic and create fake SSRC identifiers.
      Such attacks might slow down the overall control channel data
      rate, since an incorrect perception of the group size may be
      created. This might affect external issues such as group

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 24]


                      RTCP with Unicast Feedback

      accounting and other as yet unknown potential uses of the
      distribution functionality for controlling group behaviour such
      as leader election based on feedback criteria. The creation of
      fake BYE reports by an attacker should not have any effect if the
      correct timeout rules are applied by the source in removing SSRC
      entries from it's database, since the authentic SSRC should
      continue to send RTCP traffic during the timeout period.

      A replay attack on receiver return data to the source would have
      the same implications as the generation of false SSRC identifiers
      and RTCP traffic to the source. It is therefore equally as
      important to protect against compromise of any receiver
      contribution to the RTCP channel, as it is to ensure authenticity
      and freshness of the data source.

      Eavesdropping in this context may potentially provide an attacker
      with a great deal of personal information about a large group of
      receivers available from SDES packets. It would also provide an
      attacker with information on group traffic generation
      characteristics and parameters for calculating individual
      receiver bandwidth allowance.


11.5 Requirements in each context

   To address these threats, the following section presents the
   security requirements in each context.

   a) The main threat in the first context concerns denial of service
      attacks through possible packet forgery. The forgery may take the
      form of interception and modification of packets from the source,
      or simply injecting false packets into the distribution channel.
      To combat these attacks, data integrity and source authenticity
      of the source traffic MUST be applied. The degree of
      confidentiality which may be deployed is not a requirement in
      this context since the actual consequences of eavesdropping do
      not affect the operation of the protocol. However without
      confidentiality, access to personal and group characteristics
      information would be unrestricted to an external listener and it
      is therefore recommended.

   b) The threats in the second context also concern the same kinds of
      attacks but are considered less important than the downstream
      traffic compromise. All the security weaknesses are also
      applicable to the current RTP/RTCP security model and therefore
      only recommendations are made towards protection from compromise.
      Data integrity is RECOMMENDED to ensure that interception and
      modification of an individual receiver's RTCP traffic can be
      detected. This would protect against the false influence of group
      control information and the potentially more serious compromise
      of future services provided by the distribution functionality. In
      order to ensure security, data integrity and authenticity of
      receiver traffic is therefore also RECOMMENDED. The same
      situation applies as in the first context with respect to data

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 25]


                      RTCP with Unicast Feedback

      confidentiality, and it is recommended that precautions should be
      taken to protect the privacy of the data.

   An additional security consideration that is not a component of this
   specification but has a direct influence upon the general security
   is the origin of the session initiation data. This involves the SDP
   parameters that are communicated to the members prior to the start
   of the session via channels such as an HTTP server, email, SAP, or
   other means. As it is beyond the scope of this document to place any
   requirements on the external communication of such information, no
   further analysis is included here, however it is highly RECOMMENDED
   that wherever possible an implementer or user of the protocol
   attempts to identify the source of the information.


11.6 Discussion of trust models

   As identified in the previous sections, source authenticity is a
   fundamental requirement of the protocol, however it is important to
   also clarify the model of trust that would be acceptable to achieve
   this requirement. There are two fundamental models that apply in
   this instance:

   a) The shared key model where all authorised group members share the
      same key and can equally encrypt/decrypt the data. This method
      assumes that an out-of-band method is applied to the distribution
      of the shared group key ensuring that every key-holder is
      individually authorized to receive the key, and in the event of
      member departures from the group, a re-keying exercise can occur.
      The advantage of this model is that the costly processing
      associated with one-way key authentication techniques is avoided,
      as well as the need to execute additional cipher operations with
      alternative key sets on the same data set, e.g. in the event that
      data confidentiality is also applied. The disadvantage is that
      for very large groups where the receiver set becomes effectively
      untrusted, a shared key does not offer much protection.

   b) The public-key authentication model using cryptosystems such as
      RSA-based or PGP authentication provides a more secure method of
      source authentication at the expense of generating higher
      processing overhead. This is typically not recommended for Real-
      time data streams, but in the case of RTCP reports which are
      distributed with a minimum interval of 5 seconds, this is
      potentially an option (the processing overhead might still be too
      great for small, low-powered devices and should therefore be
      considered with caution). Wherever possible, however the use of
      public key source authentication is preferable to the shared key
      model identified above.

   As concerns requirements for protocol acceptability, either model is
   acceptable, although it is RECOMMENDED that the more secure public-
   key based options should be applied wherever possible.



Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 26]


                      RTCP with Unicast Feedback

11.7 Discussion of suitable security solutions

   This section presents some existing security mechanisms that would
   be suitable for addressing the requirements outlined in section
   11.5. This is only intended as a guideline and it is acknowledged
   that there are many other solutions that would adequately address
   the requirements.

  11.7.1 Secure Distribution of SDP Parameters

   a) SAP, HTTPS, Email - Initial distribution of the SDP parameters
      for the session should use a secure mechanism such as the SAP
      authentication framework which allows an authentication
      certificate to be attached to the session announcements. Other
      methods might involve HTTPS or signed email content from a
      trusted source, however some commonly used techniques for
      distributing session initiation information and starting media
      streams are RTSP [8] and SIP [9].

   b) RTSP - RTSP provides a client or server initiated stream control
      mechanism for real-time multimedia streams. The session
      parameters are conveyed using SDP syntax and may adopt standard
      Transport Layer Security techniques such as are common in HTTP
      transactions. In other words, in order to securely retrieve and
      authenticate the source of the session description information
      such as the multicast session address and the unicast feedback
      identifier, the RTSP client and server should use a transport
      level security transaction, e.g. SSL incorporating X.509 style
      certificates.

   c) SIP - A typical use of SIP involving a unicast feedback
      identifier might be a client wishing to dynamically join a multi-
      party call on a multicast address using unicast RTCP feedback.
      The client would be required to authenticate the SDP session
      descriptor information returned by the SIP server. The
      recommended method for this, as outlined in the SIP specification
      [9] is to use an S/MIME message body containing the session
      parameters signed with an acceptable certificate. Assuming some
      prior knowledge or established chain of trust, the mechanisms of
      which are beyond the scope of this document, this would provide
      the client with satisfactory knowledge of the authenticity and
      integrity of the session descriptor information. Other options
      exist within the SIP specification for establishing authenticity
      of data such as end-to-end SIP message tunneling. For the
      purposes of this profile, it is acceptable to use any suitably
      secure authentication mechanism which establishes the identity
      and integrity of the information provided to the client.


  11.7.2 Suitable Security Solutions for RTP Sessions with Unicast
  Feedback

   a) SRTP - SRTP is the recommended AVT security framework for RTP
   sessions. It specifies the general packet formats and cipher

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 27]


                      RTCP with Unicast Feedback

   operations that are used, and provides the flexibility to select
   different stream ciphers based on preference/requirements. It can
   provide confidentiality of the RTP and RTCP packets as well as
   protection against integrity compromise and replay attacks. It
   provides authentication of the data stream using the shared key
   trust model. Any suitable key-distribution mechanism can be used in
   parallel to the SRTP streams.

   b) IPSEC - A more general group security profile which might be used
   is the Group Domain of Interpretation [22], which defines the
   process of applying IPSec mechanisms to multicast groups. This
   requires the use of ESP in tunnel mode as the framework and it
   provides the capability to authenticate either just using a shared
   key or on an individual basis. It should be noted that using IPSec
   would break the 'transport independent' condition of RTP and would
   therefore not be useable for anything other than IP based
   communication.

   c) TESLA - TESLA [23] is a scheme that provides a more flexible
   approach to data authentication using time-based key disclosure. The
   authentication uses one-way pseudo-random key functions based on key
   chain hashes that have a short period of authenticity based on the
   key disclosure intervals from the source. As long as the receiver
   can ensure that the encrypted packet is received prior to the key
   disclosure by the source, this requires loose time synchronization
   between source and receivers, it can prove the authenticity of the
   packet. The scheme does introduce a delay into the packet
   distribution/decryption phase due to the key disclosure delay
   however the processing overhead is much less than other standard
   public-key mechanisms.


  11.7.3 Secure Key Distribution Mechanisms

   a) MIKEY -- MIKEY [7] is the preferred solution for SRTP sessions
      providing a shared group key distribution mechanism and intra-
      session rekeying facilities.

   b) GSAKMP -- GSAKMP [x] is the general solution favoured for
      Multicast Secure group key distribution. It is the recommended
      key distribution solution for GDOI sessions.


12. Backwards Compatibility

   The use of unicast feedback to the source should not present any
   serious backwards compatibility issues. The RTP data streams should
   remain unaffected, as are the RTCP packets from the source enabling
   inter-stream synchronization in the case of multiple streams. The
   unicast transmission of RTCP data to a source that does not have the
   ability to reflect traffic by either mechanism could have serious
   security implications as outlined in Section 11, but would not
   actually break the operation of RTP. For RTP compliant receivers
   that do not understand the unicast mechanism, the RTCP traffic may

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 28]


                      RTCP with Unicast Feedback

   still reach the group, in the event that an ASM distribution network
   is used, in which case there may be some duplication of traffic due
   to the reflection channel, but this should be ignored. It is
   anticipated, however that typically the distribution network will
   not enable the receiver to multicast RTCP traffic, in which case the
   data will be lost, and the RTCP calculations will not include those
   receivers. It is RECOMMENDED that any session that may involve non-
   unicast capable clients should always use the simple packet
   reflection mechanism to ensure that the packets received can be
   understood by all clients.


13. IANA Considerations

   The following contact information shall be used for all
   registrations included here:

     Contact:      Joerg Ott
                   mailto:jo@acm.org
                   tel:+49-421-201-7028

   Based on the guidelines suggested in [2], this document proposes 1
   new RTCP packet format to be registered with the RTCP Control Packet
   type (PT) Registry:

     Name:           RSI
     Long name:      Receiver Summary Information
     Value:          208
     Reference:      This document.

   This document defines a substructure for RTCP RSI packets.  A new
   sub-registry needs to be set up for the report block type (RBT)
   values for the RSI packet, with the following registrations created
   initially:

     Name:           IPv4 Address
     Long name:      IPv4 Feedback Target Address
     Value:          0
     Reference:      This document.

     Name:           IPv6 Address
     Long name:      IPv6 Feedback Target Address
     Value:          1
     Reference:      This document.

     Name:           DNS Name
     Long name:      DNS Name indicating Feedback Target Address
     Value:          2
     Reference:      This document.






Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 29]


                      RTCP with Unicast Feedback

     Name:           Jitter
     Long name:      Jitter Distribution
     Value:          4
     Reference:      This document.

     Name:           RTT
     Long name:      Round-trip time distribution
     Value:          5
     Reference:      This document.

     Name:           Cumulative loss
     Long name:      Cumulative loss distribution
     Value:          6
     Reference:      This document.

     Name:           Loss
     Long name:      Cumulative loss distribution
     Value:          7
     Reference:      This document.

     Name:           Collisions
     Long name:      SSRC Collision list
     Value:          8
     Reference:      This document.

     Name:           Stats
     Long name:      General statistics
     Value:          9
     Reference:      This document.

     Name:           RTCP BW
     Long name:      RTCP Bandwidth indication
     Value:          10
     Reference:      This document.

      The value 3 shall be reserved for a further way of specifying a
      feedback target address.  The value 3 MUST only be allocated for a
      use defined in an IETF Standards Track document.

      Further values may be registered on a first-come first-serve
      basis.  For each new registration, it is mandatory that a
      permanent, stable, and publicly accessible document exists that
      specifies the semantics of the registered parameter as well as the
      syntax and semantics of the associated report block.  The general
      registration procedures of [5] apply.

14. Open Issues

   1.  Do not provide explicit coverage reporting for summaries in RSI
        packets.  BUT: need to specify how the distribution source
        operates here to generate those values.

   2.  Streamline security considerations section and further its
        organization in the style of a cookbook.

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 30]


                      RTCP with Unicast Feedback


   3.  Per RFC 3550, each RTCP packet must start with SR or RR.  Hence,
        we would need to include an SR in every RSI packet.  In this
        case, however, we can in principle omit the NTP timestamp from
        the RSI packet itself.

   4.  Currently, the RTCP data rate may be derived from the group size
        and from an explicit RTCP bandwidth indicator.  The latter was
        requested to allow service providers to keep the actual group
        size secret.  Is it deemed useful to have both ways of
        specifying the RTCP transmission rate?  If so, we need to define
        what takes precedence in case both values are present.


15. Bibliography

   15.1 Normative References

   [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
        A Transport Protocol for Real-time Applications," RFC 3550, July
        2003.

   [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [3] M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund,
        and K. Norrman, "The Secure Real Time Transport Protocol",
        Internet Draft draft-ietf-avt-srtp-09.txt, Work in Progress,
        July 2003.

   [4] B. Quinn, R. Finlayson, "SDP Source-Filters", Internet Draft
        draft-ietf-mmusic-sdp-srcfilter-05.txt, Work in Progress, May
        2003.

   [5] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session
        Description Protocol", Internet Draft draft-ietf-mmusic-sdp-new-
        13, Work in Progress, May 2003.

   [6] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting
        Extensions", Internet Draft, draft-ietf-avt-rtcp-report-extns-
        06.txt, Work in Progress, May 2003.

   [7] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman,
        "MIKEY: Multimedia Internet Keying", Internet Draft draft-ietf-
        msec-mikey-07.txt, Work in Progress, June 2003.

   [8] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

   [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
        Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
        Initiation Protocol", RFC 3261, June 2002.



Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 31]


                      RTCP with Unicast Feedback

   [10] J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, "
        Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
        Internet Draft draft-ietf-ietf-avt-rtcp-feedback-07.txt, June
        2003.

   [11] H. Schulzrinne, S. Casner, " RTP Profile for Audio and Video
        Conferences with Minimal Control", RFC 3551, July 2003.

   [12] C. Huitema, "RTCP Attribute in SDP", Internet Draft draft-ietf-
        mmusic-sdp4nat-05.txt, May 2003.

   [13] D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol
        Independent Multicast in 232/8", Internet Draft draft-ietf-
        mboned-ssm232-05.txt, Work in Progress, May 2003.

   [14] H. Holbrook, B. Cain, B. Haberman, "Using IGMPv3 For Source-
        Specific  Multicast", Internet Draft draft-holbrook-idmr-igmpv3-
        ssm-04.txt, Work in Progress, March 2003.

   15.2 Informative References

   [15] Pusateri, T, "Distance Vector Multicast Routing Protocol",
        Internet Draft draft-ietf-idmr-dvmrp-v3-10.txt, Work in
        Progress, August 2000.

   [16] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
        Independent Multicast - Sparse Mode (PIM-SM): Protocol
        Specification (Revised)", Internet Draft, draft-ietf-pim-sm-v2-
        new-07.txt, Work in Progress, March 2003.

   [17] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-
        DM", Internet Draft, draft-ietf-pim-refresh-02.txt, Work in
        Progress, November, 2000.

   [18] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree
        Construction", Internet Draft draft-ietf-idmr-bgp-mcast-attr-
        00.txt, Work in Progress, February 1999.

   [19] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol
        (MSDP)", Internet Draft draft-ietf-msdp-spec-20.txt, Work in
        Progress, May 2003.

   [20] Session Directory Rendez-vous (SDR), developed at University
        College London by Mark Handley and the Multimedia Research
        Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.

   [21] M. Handley, C. Perkins, E. Whelan, "Session Announcement
        Protocol (SAP)", RFC 2974, October 2000.

   [22] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group
        Domain of Interpretation", RFC 3547, July 2003.




Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 32]


                      RTCP with Unicast Feedback

   [23] A. Perrig, R. Canetti, B. Whillock, "TELSA: Multicast Source
        Authentication Transform Specification", Internet Draft draft-
        ietf-msec-tesla-spec-00.txt, Work in Progress, April 2002.

   [24] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
        Netscape Communications Corp., Nov 18, 1996.



16. Appendix: Distribution Report processing at the receiver

   16.1 Algorithm

   Example processing of Loss Distribution Values
   X values represent the loss percentage.
   Y values represent the number of receivers.

   Number of x values is the NDB value
   xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)
   First data point = MnDV,first ydata
   then
   Foreach ydata => xdata += (MnDV + (xrange / NDB))

   16.2 Pseudo-code

   Packet Variables -> factor,NDB,MnDVL,MaDV
   Code variables -> xrange, ydata[NDB],x,y

   xrange = MaDV - MnDV
   x = MnDV;

   for(i=0;i<NDB;i++) {
        y = (ydata[i] * factor);
        /*OUTPUT x and y values*/
        x += (xrange / NDB);
   }


   16.3 Application Uses and Scenarios

   Providing a distribution function in a feedback message has a number
   of uses for different types of applications. Although this section
   enumerates potential uses for the distribution scheme, it is
   anticipated that future applications might benefit from it in ways
   not addressed in this document. Due to the flexible nature of the
   summarisation format, future extensions may easily be added. Some of
   the scenarios addressed in this section envisage potential uses
   beyond a simple SSM architecture. For example, single-source group
   topologies where every receiver may in fact also be capable of
   becoming the source. Another example may be multiple SSM topologies,
   which when combined, make up a larger distribution tree.




Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 33]


                      RTCP with Unicast Feedback

   A distribution of values is useful as input into any algorithm,
   multicast or otherwise, that could be optimized or tuned as a result
   of having access to the feedback values for all group members.
   Following is a list of example areas that might benefit from
   distribution information:

   - The parameterization of a multicast Forward Error Correction (FEC)
   algorithm. Given an accurate estimate of the distribution of
   reported losses, a source or other distribution agent, which does
   not have a global view, would be able to tune the degree of
   redundancy built in to the FEC stream. The distribution might help
   to identify whether the majority of the group is experiencing high
   levels of loss, or whether in fact the high loss reports are only
   from a small subset of the group. Similarly, this data might enable
   a receiver to make a more informed decision about whether it should
   leave a group that includes a very high percentage of the worst-case
   reporters.

   - The organization of a multicast data stream into useful layers for
   layered coding schemes. The distribution of packet losses and delay
   would help to identify what percentage of members experience various
   loss and delay levels, and thus how the data stream bandwidth might
   be partitioned to suit the group conditions. This would require the
   same algorithm to be used by both senders and receivers in order to
   derive the same results.

   - The establishment of a suitable feedback threshold. An application
   might be interested to generate feedback values when above (or
   below) a particular threshold.  However, determining an appropriate
   threshold may be difficult when the range and distribution of
   feedback values is not known a priori.  In a very large group,
   knowing the distribution of feedback values would allow a reasonable
   threshold value to be established, and in turn would have the
   potential to prevent message implosion if many group members share
   the same feedback value. A typical application might include a
   sensor network that gauges temperature or some other natural
   phenomenon.  Another example is a network of mobile devices
   interested in tracking signal power to assist with hand-off to a
   different distribution device when power becomes too low.

   - The tuning of Suppression algorithms. Having access to the
   distribution of round trip times, bandwidth, and network loss would
   allow optimization of wake-up timers and proper adjustment of the
   Suppression interval bounds.  In addition, biased wake-up functions
   could be created not only to favor the early response from more
   capable group members, but also to smooth out responses from
   subsequent respondents and to avoid bursty response traffic.

   - Leader election among a group of processes based on the maximum or
   minimum of some attribute value. Knowledge of the distribution of
   values would allow a group of processes to select a leader process
   or processes to act on behalf of the group. Leader election can
   promote scalability when group sizes become extremely large.


Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 34]


                      RTCP with Unicast Feedback


   16.4 Distribution Report creation at the source

   The following example demonstrates three different ways to convey
   loss data using the generic format of a Loss report block (section
   7.1.4). The same techniques could also be applied to representing
   other distribution types.

   1) The first method attempts to represent the data in as few bytes
   as possible.
   2) The second method, attempts to convey all the values, but in as
   small a space as possible by using a multiplicative value.
   3) The final example conveys all values without providing any
   savings in bandwidth.

   The second and third methods provide similar results, but as the
   graphs indicate at the end of the example, the second method is
   not as accurate as the third method.

   Data Set
   X values indicate loss percentage reported, Y values indicate the
   number of receivers reporting that loss percentage

        X -  0  |  1  | 2 |  3   |   4  |  5   |  6   |  7   |  8  |  9
        Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103

        X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
        Y - 74 | 21 | 30 | 65 | 60 | 80 |  6 |  7 |  4 |  5

        X - 20 | 21 | 22  |  23  |  24  | 25  | 26  | 27  | 28  | 29
        Y - 2  | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205


        X - 30  | 31  | 32  | 33 | 34 | 35 | 36 | 37 | 38 | 39
        Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4


   Constant value
   Due to the size of the multiplicative factor field being 4 bits, the
   Maximum multiplicative value is 15.

   The Distribution Type field of this packet would be value 1 since it
   it represents loss data.


   EXAMPLE - 1st Method

   Description
   The minimal method of conveying data, i.e., small amount of
   bytes used to convey the values.

   Algorithm
   Attempt to fit the data set into a small report size, selected length
   8 Octets

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 35]


                      RTCP with Unicast Feedback


   Option 1 - Can we split the range (0 - 39) into 16 4-bit values?
   The maximum value would therefore be 5 - 7.5 which is 5970. This will
   not fit into the 4-bit space using the maximum multiplicative value.

   Option 2 - Can we split the range (0 - 39) into 8 8-bit values?
   The maximum value would therefore be 5 - 9 which is 6823. This will
   not fit into the 8-bit space using the maximum multiplicative value.

   Option 3 - Can we split the range (0 - 39) into 4 16-bit values?
   The maximum value would therefore be 0 - 9 which is 13029. This will
   fit into the 16-bit space using a multiplicative factor of 1. Only 1
   report block of length 8 bytes is necessary.

   The packet fields will contain the values:
   Header distribution Block
   Distribution Type:                       1
   Number of Data Buckets:                  4
   Multiplicative Factor:                   1
   Packet Length field:                     5 (5 * 4 => 20 Bytes)
   Minimum Data Value:                      0
   Maximum Data Value:                      39
   Data Bucket values:                      13029, 352, 5460, 855
   (each value is 16-bits)

   Results, 16-bit buckets:

        X - 0 - 9 | 10 - 19 | 20 - 29 | 30 - 39
        Y - 13029 |   352   |   5460  |   855

   Example - 2nd Method

   Description
   A semi-accurate method for representing data. This method wishes to
   optimise the space used to convey results while representing every
   value.

   Algorithm
   Attempt to convey all values, i.e. 40 buckets, but in the smallest
   amount of space possible by using the multiplicative factor.

   The maximum value is 3120. Using the maximum multiplicative factor
   this will not fit into a 2, 4 or 6 bit space. The next minimum size
   block is 8 bits. The maximum value of 3120 will fit into an 8 bit
   space using the lowest possible multiplicative factor of 13.

   Can the whole of the data set fit into a maximum size packet? The
   maximum packet size is 1008 bytes. This will fit since there are only
   39 data points.

   The packet fields will contain the values:

   Header Distribution Block
   Distribution Type:                        1

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 36]


                      RTCP with Unicast Feedback

   Number of Data Buckets:                   40
   Multiplicative Factor:                    13
   Packet Length field:                      13 (13 * 4 => 52 Bytes)
   Minimum Loss Value:                       0
   Maximum Loss Value:                       39

   Data Portion
   Results, 8-bit buckets:

        X -  0 | 1  | 2 |  3  |  4  |  5  |  6  |  7 |  8 | 9
        Y - 77 | 62 | 0 | 138 | 200 | 240 | 177 | 85 | 15 | 8

        X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
        Y -  6 |  2 |  2 |  5 |  5 |  6 |  0 |  1 |  0 |  0

        X - 20 | 21 | 22 |  23 | 24 | 25 | 26 | 27 | 28 | 29
        Y - 0  | 1  | 7  | 177 | 89 | 21 | 18 | 16 | 15 | 16

        X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39
        Y - 13 | 13 |  8 |  7 |  6 |  4 |  5 |  6 |  3 |  0


   Example - 3rd Method

   Description
   This demonstrates the most accurate method for representing the data
   set. This method doesn't attempt to optimise any values.

   Algorithm
   Identify the highest value and select buckets large enough to convey
   the exact values, i.e. no multiplicative factor.

   The highest value is 3120. This requires 12 bits (closest 2 bit
   boundary) to represent, therefore it will use 60 bytes to represent
   the entire distribution. This is within the max packet size,
   therefore all data will fit within one report block. The
   multiplicative value will be 1.

   The packet fields will contain the values:

   Header Distribution Block
   Distribution Type:                        1
   Number of Data Buckets:                   40
   Multiplicative Factor:                    1
   Packet Length field:                      18 (18 * 4 => 72 Bytes)
   Minimum Loss Value:                       0
   Maximum Loss Value:                       39


   Bucket values are the same as initial data set.

   Result
   The selection of which of the three methods outlined above might be
   determined by a congestion parameter, or a user preference. The

Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 37]


                      RTCP with Unicast Feedback

   overhead associated with processing the packets is likely to differ
   very little between the techniques. The savings in bandwidth are
   apparent however, using 20, 52 and 72 octets respectively. These
   values would vary more widely for a larger data set with less
   correlation between results.


17.AUTHORS ADDRESSES

   Julian Chesterfield
   University of Cambridge
   Computer Laboratory,
   JJ Thompson Avenue,
   Cambridge, CB3 0FD, UK
   Julian.chesterfield@cl.cam.ac.uk

   Eve Schooler
   AT&T Labs - Research
   75 Willow Road
   Menlo Park, CA 94025
   eve_schooler@acm.org

   Joerg Ott
   Tellique Kommunikationstechnik GmbH
   Berliner Str. 26
   D-13507 Berlin
   GERMANY
   Phone: +49.30.43095-560  (sip:jo@tzi.org)
   Fax:   +49.30.43095-579
   Email: jo@tellique.com


18. IPR Notice

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


Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 38]


                      RTCP with Unicast Feedback



19. FULL COPYRIGHT STATEMENT

   Copyright (C) The Internet Society (2002). 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 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."




























Chesterfield, et al.  Internet Draft - Expires March 2004  [Page 39]