Internet DRAFT - draft-chesterfield-avt-rtcpssm

draft-chesterfield-avt-rtcpssm



Internet Engineering Task Force                                   AVT WG
Internet Draft                                       Julian Chesterfield
draft-chesterfield-avt-rtcpssm-02.txt             AT&T Internet Research
                                                               Joerg Ott
                                     Tellique Kommunikationstechnik GmbH
    
November, 2001
Expires:  May, 2002



        RTCP Extension for Single Source Multicast Sessions with 
	                   Unicast RTCP 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 to enable the operation of RTP/RTCP using unicast
   RTCP feedback for Single Source multicast sessions such as Source     
   Specific Multicast (SSM) Communication where the traditional model 
   of Any Source Multicast (ASM) group communication of many to
   many is either not possible or not preferred. This draft can be
   applied to any group communication which might benefit from a sender 
   controlled summarised reporting mechanism. It extends [1], section 6  
   which defines the RTP session group control channel.


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.
	
	
	




Chesterfield, Ott                                               [Page 1]

Internet Draft         RTCP with Unicast Feedback         November, 2001

2. Introduction

   RTP [1] provides a real-time transport mechanism suitable for unicast
   or Internet Standard Multicast communication between multimedia
   applications. Typical uses are for real-time or near real-time 
   group communication via 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 the distribution or calculation of session specific
   information such as packet loss, and round trip time calculation 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 and establish network conditions and diagnose faults based on
   receiver locations.
	
   RTP was designed to operate in a unicast mode or in the traditional  
   mode of Any Source Multicast (ASM) Group communication which         
   encompasses a network which supports both one to many and many to    
   many communication via a common group address in the range 224.0.0.0 
   through 239.255.255.255. Typical routing protocols that enable such  
   communication are Distance Vector Multicast Routing Protocol (DVMRP) 
   [2] or Protocol Independent Multicast (PIM) [3][4] Sparse/Dense Mode 
   in combination with an Inter-domain routing protocol such as
   Multicast Border Gateway Protocol (MBGP) [5] with Multicast Source
   Discovery (MSDP) [6]. Such routing protocols enable a host to join a
   single Multicast group address and send to or receive traffic from
   all members in the group with no prior knowledge of membership. In
   order to enable such a service in the network, however there is a
   great deal of complexity involved at the routing level. The Source
   Specific Multicast (SSM) [7] Model has the advantage of removing a
   great deal of the routing complexity involved in multicast group
   creation and source information distribution. The disadvantage of SSM
   with respect to Real-time traffic using RTP is that the
   simplification to the routing protocols removes the ability for any
   member of the group to communicate with any other member of the group
   without an explicit SSM (Source, Group) or unicast join to that host.
   The solution proposed in this draft defines a new method for
   distributing control information amongst all members in a multicast
   session and is designed to operate under any multicast group
   communication scenario. It is, however, of particular benefit to SSM 
   sessions in the absence of receivers being able to communicate with
   each other. The RTP data stream protocol itself is unaffected.
   
   The basic architectural models to which this feedback method could
   apply are:
   
   a) SSM groups with a single sender. This is the main motivation
   behind the unicast RTCP feedback mechanism and allows SSM groups
   which do not have many to many communication capability,
   traditionally available in ASM multicast groups to still receive RTP
   data streams and operate on them in the usual manner. SSM adopts the
   notion of a sender data channel which provides a one to many         
   communication facility from the source to all the receivers in the 
   






Chesterfield, Ott                                               [Page 2]

Internet Draft         RTCP with Unicast Feedback         November, 2001   
     

   group. The feedback is unicast to the source on the standard RTCP
   port.
   
   b) One to many broadcast networks such as satellite communication
   typically using a terrestrial link low bandwidth return channel or a
   broadband cable link. This architecture differs very little from the 
   SSM channel concept, but most likely will require a translator of
   some kind to render the RTP data stream onto the satellite or cable  
   distribution channel.
   
   c) ASM with a single sender. An SDP session announcement type
   identifies a session as having a single sender receiving unicast RTCP
   feedback. Receivers join the multicast group address and receive RTP
   and RTCP data on the specified address/port combinations. The RTCP
   feedback is directed to the source on the RTCP port. This model is
   not considered to be more efficient than a standard multicast group
   RTP communication scenario, and is therefore not recommended to
   replace the traditional mechanism, however it might be useful in
   helping to prevent overtaxing multicast routing infrastructure that
   does not scale as efficiently.   
  	
   SSM sessions are typically assigned a value in the group address
   range 232.0.0.0 through 232.255.255.255, although this is not a
   requirement. A session may be assigned any valid multicast address,
   as long as the local network is configured to allow source specific
   joins outside the suggested SSM range. In order for a host to receive
   traffic from an SSM capable source, it must support the IGMPv3
   multicast group membership reporting protocol which enables the host
   to explicitly request traffic from a source,group pair. In this case,
   the host is aware of the significance of the address range and is    
   therefore capable of identifying the unicast RTCP feedback session   
   requirements based on this knowledge. For sessions which take
   advantage of the unicast feedback model but do not inherently need to
   use it, it is anticipated that an SDP syntax will be defined.
   
   The modifications proposed in this document are intended to provide
   an  optional replacement to the method of RTCP operation for sessions
   which either require or may benefit from a new reporting structure.
   For certain distribution networks, such as SSM networks, this may be
   a requirement, however in other cases this is an optional feature
   which may be used.

	
3. Basic Operation

   This draft proposes two methods for enabling receiver feedback to 
   all members in a session. Each involves the unicasting of RTCP 
   packets to a source whose job it is to distribute the information
   to the members of the group. The source must always be able to       
   communicate with all the other members in order for either mechanism
   to work.
	
   The first method, the 'Simple Feedback Model' is a basic mechanism
   whereby all receiver reports are unicast to the source and
   





Chesterfield, Ott                                               [Page 3]

Internet Draft         RTCP with Unicast Feedback         November, 2001

   
   subsequently forwarded by the source to all receivers on the
   multicast feedback channel. The advantage of using this method is
   that an existing receiver implementation requires little modification
   in order to operate in this new state. Instead of forwarding Receiver
   Reports to a multicast address, it uses a unicast address and still
   receives RTCP traffic in the usual manner. This method also has the
   advantage of being backwards compatible with RTP/RTCP implementations
   which do not support unicast feedback to the source and operate using
   the standard multicast group communication model, ASM. In a session
   that is using ASM, such a receiver would multicast Receiver Reports
   to the group address and port+1 as stated in [1]. This would still be
   received by all receivers. In a session using an SSM distribution
   network, the network would prevent any data from the receiver being
   distributed further than the first hop router. Additionally, any data
   heard from this receiver by other hosts on the same subnet should be 
   filtered out by the host IP stack and will therefore not cause any
   problems with respect to the calculation of Receiver RTCP bandwidth
   since this receiver will not be heard by any other members.
	
   The second method, the 'Sender Feedback Summary Model' is a
   summarised reporting scheme that provides savings in bandwidth by
   consolidating all the receiver reports into one summary packet which
   is then distributed to all the receivers. The advantage of this
   scheme is apparent for large group sessions where the basic
   forwarding mechanism outlined above would create a large amount of
   packet replication in order to forward all the information to all the
   receivers. The basic operation of the scheme is the same as the first
   method, however it requires that all the members in the session
   understand the new summarised packet format outlined in section 7.1. 
	
   To differentiate between the two reporting mechanisms, a new SDP
   identifier is created and discussed in section 10. The  method of
   reporting must be decided prior to the start of the session, a
   distribution source may not change the method during a session.
	
	
4. Definitions

   Distribution Source: In order for unicast feedback to work, there
      must only be one session distribution source for any subset of
      receivers to which RTCP feedback is directed. 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 (see section 9 for details on 
      this) to create a single source group. However, in order for       
      unicast feedback to work, only one source must be responsible for 
      distributing the RTP stream and forwarding RTCP information to all
      receivers.
		
   RTP and RTCP Channels: The data distribution from the source to the  
      receivers whether via an SSM {source,group} identifier, a standard
      ASM multicast group or a unicast reflector, is referred to as the 
      RTP and RTCP channels. These channels are differentiated via the
      port numbers as [port] and [port + 1] for RTP and RTCP
      respectively. See [1] for further explanation of the port
      numbering.
      



Chesterfield, Ott                                               [Page 4]

Internet Draft         RTCP with Unicast Feedback         November, 2001

   Unicast RTCP Feedback Target: For a session defined as having a
      distribution source A, on ports n and n+1, the unicast feedback
      target is the IP address of Source A on port n+1.
         
   SSRC: Synchronization source. A 32-bit value that uniquely identifies
      each member in a session. See [1] for further information.
   
   Report blocks: In the RTCP design [1] it is encouraged to stack
      multiple report blocks in Sender and Receiver report packets. In
      this way, a variable size packet is created which can include
      information from one source pertaining to multiple sources in the
      group. The concept of report blocks is extended in this draft to
      encompass Loss Jitter Summary packets in which a source can
      optionally stack multiple reports into one packet in order to
      provide additional feedback on the RTCP traffic received from the
      group.
		

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

   These remain unmodified. In addition to the exisiting types, two new
   packet types are introduced. Further information on each of these is
   provided in this draft. The packet types are:
	
   type       description                    Payload number
   RSI        Receiver Summary Information   [see section 12]
   LJS        Loss and Jitter Summary        [see section 12]
	

6. Simple feedback model

6.1 Packet Formats
	
   For this mechanism, the packet types used remain the same as for
   standard RTCP feedback in [1]. Receivers generate Receiver Reports
   with information on the quality of the stream received from the
   source. The source must create Sender Reports which 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 usual rules for BYE and APP packets
   also apply. 
	
6.2 Distribution Source behaviour

   For the simple feedback model, the source provides a simple packet
   






Chesterfield, Ott                                               [Page 5]

Internet Draft         RTCP with Unicast Feedback         November, 2001   
   

   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. 
	
   The source may 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 to the
   group on the multicast RTP channel. Any multicast data received on   
   this port 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 it's own control data
   bandwidth allowance. The algorithm for computing the allowance is
   explained in section 9. The control bandwidth traffic included in the
   calculation includes any Sender reports to the group, along with any
   additional SDES and APP packets.
   
   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.
   This decision must be made in advance of the session and indicated in
   the SDP announcement.
	
6.3 Receiver behaviour

   Receivers listen on the RTP and RTCP channels for data. Each receiver
   calculates it's share of the receiver bandwidth based on the
   standard rules i.e. 75% of the RTCP bandwidth is divided equally
   between all unique SSRCs in the session. See section 9 for further
   information on this. 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 mode, the sender is required to
   summarise the information received from all the Receiver Reports
   generated by the receivers and place the information into summary
   reports. The sender must send at least 1 Receiver Summary Information
   packet for each reporting interval. The sender can additionally stack
   Loss Jitter Summary (LJS) reports after the RSI packet. Each LJS
   packet 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 LJS packets are not required but recommended. RSI and LJS
   packets are sent in addition to the standard Sender Reports and SDES 
   packets outlined in [1].

7.1 Packet Formats

   The Sender feedback summary model introduces 2 new packet formats.
   The Receiver Summary Information packet (RSI) which must be sent by a
   source if the summarised feedback mechanism is selected and the
   optional Loss and Jitter Summary report packet (LJS) that may be
   
Chesterfield, Ott                                               [Page 6]

Internet Draft         RTCP with Unicast Feedback         November, 2001   

   appended to the RSI packet to provide more detailed information on
   the overall session characteristics reported by all receivers.
	
7.1.1 RSI: Receiver Summary Information RTCP Packet


 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|    SC   |      PT       |             length            | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                         SSRC of Sender                        | 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
|                           group size                          | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|      AFL      |                    HCNL                       | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                   Highest interarrival jitter                 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                    Receiver RTCP Bandwidth                    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                       collision SSRC #1                       | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                             . . .                             | 


   The RSI packet consists of a main report block modeled along the same
   lines as a receiver report with optional LJS blocks appended. The  
   first 4 bytes of header extension follow the standard RTP header     
   outline. This ensures backwards compatibility with older versions    
   which may not understand the RSI packet format but can read the      
   length field indicating the end of the report block. The following   
   fields are included:
    
   The fields "V", "P", and "length" have the same meaning as per [1].
   
   SC: 5 bits
      The number of collision SSRC entries towards the end of the report
      block. A value of 0 is allowed.
      
   SSRC: 32 bits
      The synchronisation source identifier for the originator of the
      summary report packet.
      
   group size: 32 bits
      This field provides the sender's view of the number of receivers
      in a session. This should 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].
      
   Average fraction lost (AFL): 8 bits
      The average fraction lost indicated by receiver reports forwarded
      to this source, expressed as a fixed point number with the binary
      point at the left edge of the field.
      






Chesterfield, Ott                                               [Page 7]

Internet Draft         RTCP with Unicast Feedback         November, 2001      
      
   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.

   Highest interarrival jitter: 32 bits
      Highest 'interarrival jitter' value out of all RTCP RR packets
      since the last RSI from any of the receivers. 
   
   receiver 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.
   
   collision SSRC: n x 32 bits
      the final fields in the packet are used to identify any SSRCs
      that are duplicated within the group. Usually this is handled by
      the hosts upon detection of the same SSRC, however since receivers
      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 and it is the responsibility of the receiver(s) to
      detect the collision and select another ID.

7.1.2 LJS: Loss Jitter Summary RTCP Packet

 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|   LJSC  |      PT       |            Length             | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         SSRC of Sender                        |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  NLB  |   LF  |      MIL      |      MAL      |  NJB  |   JF  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Minimum Jitter Value                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      
|                      Maximum Jitter Value                     | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  block
|                            Loss Buckets                       |    1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Loss Buckets cont...                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Jitter Buckets                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Jitter Buckets cont...                   |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                             ...                               | report
|                             ...                               |  block
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+    2


   Loss Jitter Summary Count (LJSC): 5 bits
      The number of Loss Jitter Summary report blocks contained in this
      packet
      






Chesterfield, Ott                                               [Page 8]

Internet Draft         RTCP with Unicast Feedback         November, 2001      

   Number of Loss Buckets (NLB): 4 bits
      The number of Loss Buckets over the reserved 64 bit space.
      Possible values are 0, 1, 2, 4, 8, 16
      
   Loss Factor (LF): 4 bits
      Indicates the multiplicative factor to be applied to the Loss
      Bucket values. Possible values are 1 - 15.
		
   Minimum Loss Value (MIL): 8 bits
      Minimum loss value. In combination with the Maximum Loss value
      indicates the range covered by the Loss Bucket values. Possible
      values are 0 - 99. The Minimum Loss Value must always be less than
      the maximum, expressed as a fixed point number with the binary
      point at the left edge of the field.

   Maximum Loss Value (MAL): 8 bits
      Maximum loss value. In combination with the Minimum Loss value
      indicates the range covered by the Loss Bucket values. Possible
      values are 1 - 100. The maximum Loss Value must always be greater
      than the minimum, expressed as a fixed point number with the
      binary point at the left edge of the field.

   Number of Jitter Buckets (NJB): 4 bits
      The number of Jitter Buckets over the reserved 64 bit space.
      Possible values are 0, 1, 2, 4, 8, 16

   Jitter Factor (JF): 4 bits
      Indicates the multiplicative factor to be applied to the Jitter
      Bucket values. Possible values are 1 - 15.      
						
   Minimum Jitter Value (MIJ): 32 bits
      Minimum jitter value. In combination with the Maximum jitter value
      indicates the range covered by the jitter Bucket values. The
      Minimum jitter Value must always be less than the maximum.
		
   Maximum Jitter Value (MAJ): 32 bits
      Maximum jitter value. In combination with the Minimum jitter value
      indicates the range covered by the jitter Bucket values. The
      Maximum jitter Value must always be greater than the minimum.

   Loss Buckets: 16*4 bits - 8*8 bits - 4*16 bits - 2*32 bits - 1*64
                 bits
      Loss Bucket. The size and number of buckets depends upon the value
      of NLB. This indicates the division of the 64 bit space. Depending
      upon whether NLB is 16, 8, 4, 2 or 1, the size of each LB will be
      4, 8, 16, 32 or 64 bits respectively. Each value must be
      multiplied by the Loss Factor.
	
   Jitter Buckets: 16*4 bits - 8*8 bits - 4*16 bits - 2*32 bits - 1*64
                   bits
      Jitter Bucket. The size of the bucket depends upon the value of
      JLB. This indicates the division of the 64 bit space. Depending
      upon whether JLB is 16, 8, 4, 2 or 1, the size of each JB will be
      4, 8, 16, 32 or 64 bits respectively. Each value must be
      multiplied by the Jitter Factor.
      





Chesterfield, Ott                                               [Page 9]

Internet Draft         RTCP with Unicast Feedback         November, 2001 


7.2 Distribution Source behaviour
		
   The length field of the RSI packet must be calculated over the length
   of the whole packet, using the
   method defined in [1]. The group size must be included in the RSI
   packet. The source should also calculate the Receiver RTCP bandwidth
   field. Typically this value will be calculated as outlined in [1]
   using the group size and session bandwidth as variables. This field 
   does however provide the source with the capability to control the
   amount of feedback from the receivers and can be increased or
   decreased based on the requirements of the source. Regardless of the
   value selected by the source for the 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.
	
   In order to identify SSRC collisions, the source is responsible for
   maintaining a record of each SSRC and the correpsonding IP address
   within at least one reporting interval 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
   does not prevent the possibility of collisions since IP addresses may
   not be unique e.g. due to NAT gateways, however it greatly increases
   the capability to detect collisions. In the event that collisions are
   not detected, the effect will be an innaccurate impression of the
   group size on the part of the source. Since the statistical
   probablility that collisions will both occur and be undetectable is
   very low, the clients would have to randomly select the same SSRC and
   be located behind the same NAT gateway, this should not be a
   significant concern. 
	
   For the LJS packet, the source must decide which are the most        
   significant values to convey. 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 the
   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 RTCP reports as LJS information.
	
   The results should correspond as near as possible to the values
   received during the interval since the last report.
	
   The source may stack as many report blocks as required in order to
   convey loss and jitter information.

	
7.3 Receiver behaviour

   The receiver must process RSI packets and adapt session parameters
   






Chesterfield, Ott                                              [Page 10]

Internet Draft         RTCP with Unicast Feedback         November, 2001   
   
   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 the 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 it's share
   of the RTCP bandwidth. This share of the bandwidth may be overridden
   by the 'Receiver RTCP Bandwidth' field. This field provides the
   source with the capability to control the amount of feedback from the
   receivers. 
	
   The receiver can handle the LJS 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 it's 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 for the use of mixers and
   translators in an RTP session which help to connect heterogeneous
   networks into one session. There are a number of issues, however
   which are raised by the unicast feedback model proposed in this
   document. The term 'mixer' refers to devices that provide data stream
   multiplexing where multiple sources are combined into one stream.
   Conversely, a translator does not multiplex streams, but simply
   acts as a bridge between two distribution mechanisms, e.g. a unicast
   to multicast network translator. Since the issues raised by this
   draft apply equally to either a mixer or translator, they are
   referred to from this point onwards generically as a gateway. 
   
   A gateway 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 gateway 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.
	








Chesterfield, Ott                                              [Page 11]

Internet Draft         RTCP with Unicast Feedback         November, 2001
	
8.1 Use of a mixer-translator

   The gateway must adhere to the SDP descriptor for the single source
   session and use the feedback mechanism indicated. Receivers should be
   aware that by introducing a gateway into the session, more than one
   source may potentially be active in a session since the gateway 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 gateway itself. It is recommended
   that the simple packet reflection mechanism be used under these
   circumstances since attempting to coordinate RSI + LJS reporting
   between more than one source may be complicated unless the gateway 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 gateway must be able to follow the same security policy as the
   client in order to unicast forward RTCP data 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 gateway is not acting as the distribution source, and
   subsequent unicast feedback to the source is only allowed if the
   gateway can conduct the same source authentication as required by the
   receivers.

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 it's own SSRC count
   determined by the forwarded Receiver Reports, or from the RSI 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
   the group. The source
   should calculate the transmission interval for RSI + LJS packets out
   of it's 1/4 of the control traffic bandwidth with a minimum
   transmission interval of 5 seconds. 
	
	











Chesterfield, Ott                                              [Page 12]

Internet Draft         RTCP with Unicast Feedback         November, 2001

10. SDP Extensions

   The Session Description Protocol (SDP) is used as a means to describe
   media sessions in terms of their transport addresses, codecs, and
   further attributes.  Providing RTCP feedback via unicast as specified
   in this document constitutes another session parameter.  To make
   receivers aware that they are supposed to provide their feedback
   via unicast, this needs to be indicated in the session description.
   Similarly, parameters of SSM RTCP feedback -- such as the mode of
   summarizing information at the sender and the target unicast address
   to send feedback information to -- needs to be provided.  This section
   defines the necessary SDP parameters (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 further 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 ljs	   -- MUST be used to indicate the "Loss Jitter
			      Summary" mode of operation
			       
   rtcp:unicast rsi	   -- MUST be used to indicate the "Receiver
			      Summary Information" mode of operation. 


   10.2 SSM Source Specification

   In addition, in an SSM RTCP session, the sender(s) need to be
   indicated for both source-specific joins to the multicast group
   as well as for addressing RTCP packets to.
   
   This is done following the proposal for SDP source filters
   documented in draft-ietf-mmusic-sdp-srcfilter-00.txt [15].

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

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












Chesterfield, Ott                                              [Page 13]

Internet Draft         RTCP with Unicast Feedback         November, 2001

11. Security Considerations

   Packet bombing of unsuspecting victims via a fake SDP or SSM address
   is a real concern for this architecture. For this reason it is
   required that a security policy be applied to any session which
   involves unicast feedback of data to a single IP address. At a
   minimum, it is recommended that source authentication be conducted by
   every receiver prior to unicasting data.
	
   An additional concern is the problem of fake RSI + LJS packets which
   could increase the RTCP bandwidth sent to the source. Any security
   policy must address this as a minimum requirement.
	
   Receiver authentication would also be beneficial, since Denial of
   Service attacks by generating false Receiver Reports is also
   possible. The consequences of this are not as drastic, affecting only
   the group size and transmission interval calculation and therefore
   the integrity and frequency of the reported data.

   The issue of source feedback implosion should not occur in the event
   that receivers practice the standard RTP/RTCP guidelines for starting 
   sessions and for implementing the scaling algorithm based on the
   number of hosts. An additional issue which should be addressed, but
   is beyond the scope of this document is the potential for host
   anonymity which is facilitated by Source Specific Multicast and adds 
   additional security measures into group communication. By explicitly 
   controlling receiver feedback, a source could solicit feedback from
   the receivers in a scalable way without the need to inform all
   members in a session of the group membership.
	
11.1 Security Requirements Outline

   In order to overcome the issues outlined above, there are some
   minimal and recommended policies which must be addressed:
	
      - The information providing the unicast feedback address
      needs to be authenticated as being from a trusted source. 
		
      - Data integrity of the RTCP traffic from the source, particularly
      RSI + LJS packets is also required.
		
      - Receiver authentication is recommended in order to ensure
      integrity of RTCP traffic and group size.
		
      - Data encryption of both the RTCP and RTP streams are optional
      but recommended for this draft.
   
   Ideally, a public key infrastructure would provide the mechanism
   necessary to ensure the trusted authentication of distributed SDP
   announcements. Since this is not generally available, the following
   precautions are highly recommended.
   









Chesterfield, Ott                                              [Page 14]

Internet Draft         RTCP with Unicast Feedback         November, 2001


   The primary danger of the use of a fake session announcement must be
   addressed by the distribution media itself since SDP remains
   independent of the underlying mechanism and provides no facility to
   combat authentication and/or message integrity. The most common
   methods of distributing SDP messages are the Session Announcement
   Protocol (SAP)[11], a web page or an email message. All of these
   mechanisms provide the capability to authenticate the source of the
   announcement: 
   
      - SAP has the option to include an authentication header in
      the message which assures the integrity of the message contents
      and identifies the source of the message via public key
      encryption. 
   
      - A secure web server can be used to provide Secure Sockets Layer
      (SSL) [12] authentication of the web site containing the SDP
      message. 
   
      - An email message can be signed using a public key mechanism to
      ensure data integrity. 
   
   
   All of these methods rely on a level of trust in order to validate
   the public key of the originator of the message. The establishment of
   trust is beyond the scope of this document, however it is recommended
   that receivers should only trust an originating source if a digital
   certificate signed by a trusted third party such as a Signing
   Authority is available or if the key has been received prior to the
   session via some secure out-of-band method.
   
   A number of options are available to address the issue of session
   data integrity, the most obvious being the use of Secure RTP (SRTP)
   [14] or a more general security framework such as TESLA [13].
   Adopting such a scheme to ensure that both source traffic and
   receiver messages are encrypted would prevent the generation of fake
   RTCP traffic to the group or from any unsolicited receivers.
	

12. IANA Considerations

   Based on the guidelines suggested in [10], this document proposes 2
   new RTCP data payload types for consideration by IANA.

   Furthermore, four new SDP media-level attributes are defined in
   section 10.


13. 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-10.txt, Work in Progress, July 2001.

   [2] Pusateri, T, "Distance Vector Multicast Routing Protocol", 
   draft-ietf-idmr-dvmrp-v3-10, August 2000





Chesterfield, Ott                                              [Page 15]

Internet Draft         RTCP with Unicast Feedback         November, 2001


   [3] Fenner, B, Handley, M, Holbrook, H, Kouvelas, I, "Protocol 
   Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
   (Revised)", draft-ietf-pim-sm-v2-new-02.txt, March 2001

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

   [5] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree
   Construction", draft-ietf-idmr-bgp-mcast-attr-00.txt, February 1999

   [6] Farinacci, D, Rekhter, Y, Meyer, D, Lothberg, P, Kilmer, H, 
	Hall, J, "Multicast Source Discovery Protocol (MSDP)", 
   draft-ietf-msdp-spec-06.txt, July 2000

   [7] Shepherd, G, Luczycki, E, Rockell, R, "Source-Specific Protocol
   Independent Multicast in 232/8", draft-shepherd-ssm232-00.txt, March 
   2000.

   [8] Holbrook, H, Cain, B, "Using IGMPv3 For Source-Specific 
   Multicast", draft-holbrook-idmr-igmpv3-ssm-00.txt, July 2000.
   
   [9] Session Directory Rendez-vous (SDR), developed at University
   College London by Mark Handley and the Multimedia Research Group. 
   
   [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
   Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
   
   [11] Handley, M, Perkins, C, Whelan, E, "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] Perrig, Canetti, Briscoe, Tygar, Song, "TESLA: Multicast Source
   Authentication Transform", draft-irtf-smug-tesla-00.txt.
   
   [14] E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The
   Secure Real Time Transport Protocol", draft-ietf-avt-srtp-01.txt.

   [15] B. Quinn, "SDP Source-Filters", Internet Draft
   draft-ietf-mmusic-sdp-srcfilter-00.txt, Work in Progress, May 2000.



















Chesterfield, Ott                                              [Page 16]

Internet Draft         RTCP with Unicast Feedback         November, 2001


13. Appendix

A  LJS packet processing at the receiver


A.1 Algorithm
	
   X values represent the loss percentage.
   Y values represent the number of receivers.
   
   Number of x values is the NLB value
   xrange = MAL - MIL
   First data point = MIL,first ydata
   then
   Foreach ydata => xdata += (MIL + (xrange / NLB))
	
A.2 Pseudo-code
	
   Packet Variables -> factor,NLB,MIL,MAL
   Code variables -> xrange, ydata[NLB],x,y
	
   xrange = MAL - MIL
   x = MIL;
   for(i=0;i<NLB;i++) {
      y = ydata[i] * factor;
      /*OUTPUT x and y values*/
      x += (xrange / NLB)
   }	


B  LJS packet creation at the source

   See Postscript version.


C  AUTHORS ADDRESSES

   Julian Chesterfield
   AT&T Labs - Research
   75 Willow Road
   Menlo Park, CA 94025
   julian@research.att.com


   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
   







Chesterfield, Ott                                              [Page 17]

Internet Draft         RTCP with Unicast Feedback         November, 2001
   

D FULL COPYRIGHT STATEMENT

   Copyright (C) The Internet Society (2000). 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 doc-
   ument 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 develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet languages other than English.

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."



































Chesterfield, Ott                                              [Page 18]