J. Chesterfield 
                                                University of Cambridge 
                                                            E. Schooler 
Internet Draft                                     AT&T Labs - Research 
Document: draft-ietf-avt-rtcpssm-04                              J. Ott 
                                                          Tellique GmbH 
Expires: December 2003                                     29 June 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. 
    
    
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 
   4. Definitions.....................................................5 
   5. Packet types....................................................6 
   6. Simple feedback model...........................................6 
   7. Sender feedback summary model...................................7 

     
   Chesterfield Internet Draft - Expires December 2002        [Page 1] 

                      RTCP with Unicast Feedback 
 
   8. Mixer/Translator issues........................................16 
   9. Transmission interval calculation..............................18 
   10. SDP Extensions................................................18 
   11. Security Considerations.......................................19 
   12. Backwards Compatibility.......................................26 
   13. IANA Considerations...........................................27 
   14. Outstanding Issues............................................29 
   15. References....................................................29 
   16. Appendix......................................................31 
   A  Distribution Report processing at the receiver.................31 
   B Distribution Report creation at the source......................33 
   C AUTHORS ADDRESSES...............................................36 
   D FULL COPYRIGHT STATEMENT........................................36 
    
    
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) [2] or Protocol Independent Multicast (PIM) 
   [3][4]. Typically these are used in combination with an 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) [5] in combination with the 


     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 2] 

                      RTCP with Unicast Feedback 
 
   Multicast Source Discovery Protocol (MSDP) [6]. 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 at the routing level a full 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.  
      An SDP [16] 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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 3] 

                      RTCP with Unicast Feedback 
 
      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. 
    
   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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 4] 

                      RTCP with Unicast Feedback 
 
   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 and k, 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. 
    
   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. 
    
    
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 5] 

                      RTCP with Unicast Feedback 
 
5. Packet types 

   The RTCP packet types defined in [1] 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: 
    
   Sub-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 
   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 standard 
   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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 6] 

                      RTCP with Unicast Feedback 
 
   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 provides 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 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 multicast, 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. 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 [16]. 
    
    
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 75% of the RTCP bandwidth 
   is divided equally between all unique 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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 7] 

                      RTCP with Unicast Feedback 
 
   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: 
 
  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: 32 bits 
      The time the packet was sent. This is an unsigned integer value 
      displayed in NTP timestamp units to enable detection of duplicate 
      packets, reordering and to provide a chronological profile of the 
      feedback reports. 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 8] 

                      RTCP with Unicast Feedback 
 
    
   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       + 
 |                                                               | 
 :                                                               : 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
   RBT: 8 bits 
      Sub-Block Type. The sub-block type identifier.  The values for the
      sub-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 
      SBT value. 
    
    
 7.1.3 Generic Sub-Block Fields 
    
   For the sub-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                  | 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 9] 

                      RTCP with Unicast Feedback 
 
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
 |                      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 packet 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. 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.  
    
   Length: 8 bits 
      The length field tells the receiver the full length of the sub-
      block in 32-bit words, and enables the receiver to identify the 
      bucket size based on the calculation ((length * 4) - 12)*8/NDB. 
      Therefore the maximum data portion of a distribution packet may 
      be 1008 bytes, which would provide up to 4032 data buckets of 
      length 2 bits, or 2016 data buckets of length 4 bits etc... 
    
   Minimum distribution value: 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: 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 depends upon the value of NDB and 
      the length of the packet. In order to calculate the size of the 
      bucket, the formula ((length * 4) - 12)*8/NDB should be used. 
      This indicates the division of the data space and the size of 
      each data point in bits. Each value must be multiplied by the 
      multiplicative factor. 
    
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 10] 

                      RTCP with Unicast Feedback 
 
   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 
   
   A loss 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. The sub-block type (SBT) 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. 
    
   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. 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 sub-block type (SBT) 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. 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 sub-block type (SBT) 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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 11] 

                      RTCP with Unicast Feedback 
 
   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 sub-
   block type (SBT) is 6. 
    
  7.1.8 Feedback Address Target 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={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.  If port==0, the port 
      number MUST be ignored. 
    
   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, SBT=0.  For IPv6, SBT=1. And for the DNS name for 
      unicast feedback, SBT=2. 
 
 
 7.1.9 Collisions 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=8     |    Length     |           Reserved            |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                                                               | 
 :                         Collision SSRC                        : 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 
   Collision SSRC: n x 32 bits 

     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 12] 

                      RTCP with Unicast Feedback 
 
      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 BYE 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=9     |    Length     |           Reserved            |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                                                               | 
 :                          Leaving SSRC                         : 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 
   Leaving SSRC: n x 32 bits 
      The final fields in the packet are used to identify any SSRCs 
      from which a BYE message has been received.  Each Leaving SSRC is 
      included repeatedly in BYE list report blocks and sent at least 
      five times.  If more Leaving SSRCs need to be reported than fit 
      into an MTU, the reporting is done in a round robin fashion so 
      that all Leaving SSRCs have been reported once before the second 
      round of reporting starts.  Receivers of BYE report blocks remove 
      the corresponding SSRCs from their list of session members. 
    
    
 7.1.11 General Statistics 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=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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 13] 

                      RTCP with Unicast Feedback 
 
      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  
      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.12 RTCP Bandwidth indication 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=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 
      Indicates the maximum bandwidth allocated to any single receiver 
      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. 
    
   Only the sender bit or the receiver bit MAY be set to 1 at the same 
   time. 
    
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 sub-block reports, since incorrect information can have 
   serious implications. Section 11 addresses the security risks in 
   detail. 
    
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 14] 

                      RTCP with Unicast Feedback 
 
   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 its bandwidth allocation. See Section 9 for further 
   details about the frequency of reports. 
    
   In the event that the source receives a BYE notification from any 
   number of receivers, it MUST forward a BYE summary report listing 
   the SSRC or SSRCs that are leaving. The announcement MUST be made at 
   least 5 times. If there are more SSRCs than can be listed in a BYE 
   summary within the space available, the BYE SSRC list MUST be 
   announced in a round-robin fashion, until all SSRCs have been 
   announced at least 5 times. The source MUST NOT adjust the group 
   size estimator value, either the group size or RTCP bandwidth 
   fields, to reflect the change until the relevant SSRC has been 
   announced at least 5 times. See Section 11 for further explanation 
   of this. 
    
   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. 
    
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 15] 

                      RTCP with Unicast Feedback 
 
   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 
   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 BYE SSRC summarisation list MUST be checked for any entries 
   corresponding to the receiver's own SSRC. In the event that a BYE is 
   incorrectly advertised for a receiver that is still active, the 
   standard process for reselecting an SSRC in the event of a collision 
   must be initiated. See section 11 for further explanation.  
    
   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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 16] 

                      RTCP with Unicast Feedback 
 
   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 
   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 [16] 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.  
    
    


     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 17] 

                      RTCP with Unicast Feedback 
 
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., [9]) or decided based upon the bandwidth of a 
   single sender in a session. A receiver MUST calculate the number of 
   other members in a session based upon either its own SSRC count 
   determined by the number of forwarded Receiver Reports it receives, 
   from the group size field or the RTCP bandwidth field in a control 
   report from a sender.  
    
   The RTCP transmission Interval calculation remains the same as in 
   the original RTP specification [1]. In the original specification, 
   the senders are allocated 1/4 of the control traffic bandwidth if 
   they number 25% or less than the group size. Otherwise the 
   allocation for senders is the percentage of senders to group size. 
   The remaining bandwidth is allocated to the receivers to be divided 
   evenly amongst them. The source should calculate the transmission 
   interval for RSI and summarisation packets out of its 1/4 of the 
   control traffic bandwidth with a minimum transmission interval of 5 
   seconds. 
    
    
10. SDP Extensions 

   The Session Description Protocol (SDP) [16] 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 additional 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 
    
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 18] 

                      RTCP with Unicast Feedback 
 
   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 draft-ietf-mmusic-sdp-srcfilter-05.txt [15]. 
    
   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. 
    
   An optional alternative feedback address may be supplied using an 
   attribute such as 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 presents an analysis of the security weaknesses 
   introduced by the feedback mechanism, identifying the potential 
   threats and specifying the measures that MUST be adopted to address 
   the issues. Any Suggestions on increasing the level of security 
   provided to RTP sessions above the current standard are RECOMMENDED 
   but OPTIONAL. 
    
11.1 Assumptions 
    
   RTP/RTCP is a protocol for carrying real-time multimedia traffic, 
   and therefore one of the main considerations for any security 
   solution must be to maintain as low an overhead as possible in order 
   to limit processing constraints. 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 using type 
   information through SAP, email or the web is beyond the scope of 
   this document. It is recommended, however, that the method used 
   should employ adequate security measures to ensure the integrity and 
   authenticity of the information. For the purposes of this analysis, 
   it is assumed that the information has already been securely 
   distributed out-of-band. This work is in progress within the Gsec 
   working group, which is addressing the security implications of 
   distributing session announcements. 
    
   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. 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 19] 

                      RTCP with Unicast Feedback 
 
    
11.2 Security threats 
    
   Attacks on this architecture may take a variety of forms, and in 
   order to identify the security weaknesses, it is important to 
   address these individually. 
    
   a) Denial of Service 
      A major area of concern would be a denial of service attack. Due 
      to the nature of the communication architecture this is a 
      situation that could be generated a number of ways by using the 
      unicast feedback characteristic to the attackers advantage. 
    
   b) Packet Forgery 
      One potential area of attack to guard against is packet forgery. 
      In particular, it is important to protect against the integrity 
      of certain influential packets since compromise of certain 
      control packets could directly affect the transmission 
      characteristics of the whole group, however for the purposes of 
      defining a security profile at this stage, every packet is 
      considered equally as important. This decision may be revisited 
      in future revisions as the requirements emerge more clearly. It 
      is clear, however that in the case of a large group, the 
      compromise of RTCP traffic could have serious consequences.  
    
   c) Session Replay 
      An additional concern is the potential for session recording and 
      subsequent replay. The issue to deal with in particular in this 
      instance is that an attacker may not actually need to understand 
      the packet contents, but just simply have the ability to record 
      the data stream and at a later time replay it to any receivers 
      that are listening. This would be 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 to perform an intelligent DoS attack.  
    
    
11.3 Security properties 
    
   The following security types are relevant to this draft and will be 
   addressed in greater detail in subsequent sections. 
    
   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 the packet received is 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 20] 

                      RTCP with Unicast Feedback 
 
      guaranteed to be in exactly the same condition as intended, and 
      that what is received can be confirmed as being from an 
      authenticated source. 
    
   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 the only receiver(s) that can recover the plaintext 
      is the intended receivers, therefore in order to restrict access 
      only to authorized entities, confidentiality is required. It does 
      not prevent eavesdroppers 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 
    
   In order to understand the potential weaknesses to guard against, it 
   is necessary to divide the communication model into a number of 
   distinct contexts.  
    
   a) Source to Receiver communication 
      The first, and perhaps most influential context to protect, is 
      the 'downstream' communication channel from the source to the 
      receivers. This is effectively the main controlling influence 
      over the behaviour of the group since it determines 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 should be generated by 
      a single source. Both the RTP data stream and the RTCP control 
      data are sent over this channel. The RTCP data is indirectly 
      influenced by the information the source has received from the 
      whole group. 
       
      This context is vulnerable to all four attacks outlined in the 
      previous section. 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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 21] 

                      RTCP with Unicast Feedback 
 
      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, potentially causing 
      a distributed DoS effect by the receiver group. 
       
      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 very 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 and, if 
      unencrypted, 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, which for the purposes of this 
      analysis may be considered in the same light as a distribution 
      source. This traffic should only be RTCP type data, and should 
      include receiver reports, SDES information 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 

     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 22] 

                      RTCP with Unicast Feedback 
 
      the event that the integrity of the source RTCP channel has been 
      compromised and is not detected by the individual receivers.  
       
      In the event that packet forgery may occur in this context, the 
      effect may be the introduction of false RTCP traffic and/or the 
      creation of fake SSRC identifiers. Such an attack 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 accounting and other as yet unknown 
      potential uses of the distribution functionality for controlling 
      group behaviour such as leader election based on feedback 
      criteria.  
       
      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 
    
   Some initial requirements to consider for each context in general 
   are that the overhead of ensuring the security of the session should 
   be kept as low as possible. This entails keeping the setup and 
   communication of keys to a minimum. The nature of RTP/RTCP traffic 
   is that sessions require real-time processing and minimal overhead 
   for communication. This means that processing constraints imposed by 
   the required cryptographic techniques are an important consideration 
   in defining this security profile. 
    
   Having identified the security weaknesses for each communication 
   context, security type requirements can be addressed for each. 
    
   a) The first context is concerned with 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. 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 23] 

                      RTCP with Unicast Feedback 
 
    
   b) The second context SHOULD defend against the same kinds of 
      attacks but is 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 is not 
      accomplished. 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 such as leader election based on various 
      parameters. In order to ensure security, data integrity and 
      authenticity of receiver trafficis therefore also RECOMMENDED. 
      The same situation applies as in the first context with respect 
      to data 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 or SAP. 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 should attempt to 
   identify the source of the information. 
    
   As specified in the draft, a source MUST forward BYE notification 
   messages at least 5 times from each SSRC once it receives a report. 
   It MUST NOT adjust the group size estimator or receiver RTCP 
   bandwidth fields until the BYE SSRC has been announced at least 5 
   times, providing receivers with enough time detect the compromise 
   and initiate the SSRC collision detection algorithm. In the extreme, 
   large numbers of false BYE reports sent to a source might cause 
   instability in a group with respect to fluctuation of joins and 
   leaves, however the calculated group reporting interval should not 
   be adversely affected. 
 

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 have 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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 24] 

                      RTCP with Unicast Feedback 
 
      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 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. 
    
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. 
    
   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 [21] and SIP [22].  
    
   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. 
    
   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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 25] 

                      RTCP with Unicast Feedback 
 
   required to authenticate the SDP session descriptor information 
   returned by the SIP server. The recommended method for this, as 
   outlined in the SIP specification [22] 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. 
    
   SRTP is the recommended AVT security framework for RTP sessions. It 
   specifies the general packet formats and cipher 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, however MIKEY [18] is the preferred system by the 
   authors. 
 
   A more general group security profile which might be used is the 
   Group Domain of Interpretation [19], 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. 
    
   TESLA [20] 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. 
 

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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 26] 

                      RTCP with Unicast Feedback 
 
   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 
   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 [10], 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. 
    




     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 27] 

                      RTCP with Unicast Feedback 
 
     Name:           DNS Name 
     Long name:      DNS Name indicating Feedback Target Address 
     Value:          2 
     Reference:      This document. 
    
     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:           BYE 
     Long name:      BYE list 
     Value:          9 
     Reference:      This document. 
    
     Name:           Stats 
     Long name:      General statistics 
     Value:          10 
     Reference:      This document. 
    
     Name:           RTCP BW 
     Long name:      RTCP Bandwidth indication 
     Value:          11 
     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

     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 28] 

                      RTCP with Unicast Feedback 
 
      syntax and semantics of the associated sub-block.  The general 
      registration procedures of [16] apply. 
    
14. Outstanding Issues 

   a) The source currently transmits RSI packets only with its own bit 
   rate budget.  This means that the receiver share of the RTCP 
   bandwidth is unused and the granularity for information conveyed to 
   the receivers (particularly for the group size) is inherently 
   limited.  Shall we allow, optionally, for extra bandwidth from the 
   distribution source to the receivers to convey RSI and other 
   information more frequently?  How about the five second rule? 
    
   b) We may need/want to explicitly indicate the part of the group 
   covered by each RSI report along with further information describing 
   the sampling interval. 
    
   c) Currently, BYE announcements are repeated several times in the 
   RSI report which is not really necessary (but follows the same 
   behavior used for SSRC collision detection).  Should we keep those 
   two aligned or make BYE simple to handle. 
    
    
15. References 

   [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - 
   A Transport Protocol for Real-time Applications," Internet     
   Draft, draft-ietf-avt-rtp-new-12.txt, Work in Progress, March 2003. 
    
   [2] Pusateri, T, "Distance Vector Multicast Routing Protocol", 
   Internet Draft draft-ietf-idmr-dvmrp-v3-10.txt, Work in Progress, 
   August 2000 
    
   [3] 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-02.txt, Work in 
   Progress, March 2001. 
    
   [4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-
   DM", Internet Draft, draft-ietf-pim-refresh-02.txt, Work in 
   Progress, November, 2000. 
    
   [5] 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. 
    
   [6] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol 
   (MSDP)", Internet Draft draft-ietf-msdp-spec-14.txt, Work in 
   Progress, November 2002. 
    
   [7] D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol 
   Independent Multicast in 232/8", Internet Draft draft-ietf-mboned-
   ssm232-04.txt, Work in Progress, January 2003. 
    
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 29] 

                      RTCP with Unicast Feedback 
 
   [8] H. Holbrook, B. Cain, B. Haberman, "Using IGMPv3 For Source-
   Specific  Multicast", Internet Draft draft-holbrook-idmr-igmpv3-ssm-
   03.txt, Work in Progress, November 2002. 
       
   [9] 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/. 
       
   [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 
   Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 
       
   [11] M. Handley, C. Perkins, E. Whelan, "Session Announcement 
   Protocol (SAP)", RFC 2974, October 2000. 
       
   [12] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 
   Netscape Communications Corp., Nov 18, 1996. 
       
   [13] A. Perrig, R. Canetti, B. Whillock, "TESLA: Multicast Source 
   Authentication Transform", Internet Draft draft-ietf-msec-tesla-
   spec-01.txt, Work in Progress, October 2002. 
       
   [14] 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-05.txt, Work in Progress, June 
   2002. 
    
   [15] B. Quinn, R. Finlayson, "SDP Source-Filters", Internet Draft 
   draft-ietf-mmusic-sdp-srcfilter-05.txt, Work in Progress, May 2003. 
    
   [16] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session 
   Description Protocol", Internet Draft draft-ietf-mmusic-sdp-new-11, 
   Work in Progress ,November 2002. 
    
   [17] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting 
   Extensions", Internet Draft, draft-ietf-avt-rtcp-report-extns-
   02.txt, Work in Progress, February 2003.  
    
   [18] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, 
   "MIKEY: Multimedia Internet Keying", Internet Draft draft-ietf-msec-
   mikey-06.txt, Work in Progress, February 2003. 
    
   [19] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group 
   Domain of Interpretation", Internet Draft draft-ietf-msec-gdoi-
   07.txt, Work in Progress, December 2003. 
    
   [20] A. Perrig, R. Canetti, B. Whillock, "TELSA: Multicast Source 
   Authentication Transform Specification", Internet Draft draft-ietf-
   msec-tesla-spec-00.txt, Work in Progress, October 2002. 
    
   [21] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 
   Protocol (RTSP)", RFC 2326, April 1998. 
    


     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 30] 

                      RTCP with Unicast Feedback 
 
   [22] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 
   Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 
   Initiation Protocol", RFC 3261, June 2002. 
    
    
16. Appendix 

A  Distribution Report processing at the receiver 

 

A.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)) 
    
A.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); 
   } 
    
    
A.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 December 2002  [Page 31] 

                      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 December 2002  [Page 32] 

                      RTCP with Unicast Feedback 
 
    
B 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       

     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 33] 

                      RTCP with Unicast Feedback 
 
   Attempt to fit the data set into a small report size, selected length
   8 Octets  
    
   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: 
    
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 34] 

                      RTCP with Unicast Feedback 
 
   Header Distribution Block       
   Distribution Type:                        1       
   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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 35] 

                      RTCP with Unicast Feedback 
 
   The selection of which of the three methods outlined above might be 
   determined by a congestion parameter, or a user preference. The 
   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. 
    
C 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 
    
D 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 
     
Chesterfield, et al.  Internet Draft - Expires December 2002  [Page 36] 

                      RTCP with Unicast Feedback 
 
   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 December 2002  [Page 37]