J. Chesterfield University of Cambridge J. Ott Internet Draft Tellitec GmbH Document: draft-ietf-avt-rtcpssm-10 E. Schooler Intel Expires: April 2006 24 October 2005 RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. 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 available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Chesterfield, et al. Internet Draft - Expires January 2006 [Page 1] RTCP with Unicast Feedback Table of Contents 1. Conventions and Acronyms......................................2 2. Introduction..................................................2 3. Basic Operation...............................................4 4. Definitions...................................................6 5. Packet types..................................................7 6. Simple Feedback Model.........................................8 7. Distribution Source Feedback Summary Model..................10 8. Mixer/Translator issues......................................24 9. Transmission interval calculation............................26 10. SDP Extensions..............................................27 11. Security Considerations.....................................29 12. Backwards Compatibility.....................................35 13. IANA Considerations.........................................36 14. Bibliography................................................37 15. Appendix: Distribution Report processing at the receiver....40 16. AUTHORS ADDRESSES...........................................48 17. IPR Notice..................................................48 18. FULL COPYRIGHT STATEMENT....................................49 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, enabling group size estimation and the distribution and 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 either a unicast or multicast mode. In multicast mode, it assumes an Any Source Multicast (ASM) group model, 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. To enable internet-wide multicast communication, intra-domain routing protocols (those that operate only within a Chesterfield, et al. Internet Draft - Expires April 2006 [Page 2] RTCP with Unicast Feedback single administrative domain, e.g., DVMRP [16], PIM [17][18]) are used in combination with an Inter-domain routing protocol (those that operate across administrative domain borders, e.g., MBGP [19], MSDP [20]). 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. However, there is a great deal of complexity involved at the routing level to support such a multicast service in the network. In addition, many-to-many communication is not always available, nor desired by all group applications. For example, with Source-Specific Multicast (SSM) and satellite communication, the multicast distribution channel only supports source-to-receiver traffic. In other cases, such as large ASM groups with a single active data source and many passive receivers, it is sub-optimal to create a full routing-level mesh of multicast sources just for the distribution of RTCP control packets. Thus, an alternative solution is preferable. Although a one-to-many multicast topology may simplify routing and may be a closer approximation of the requirements of certain RTP applications, unidirectional communication makes it impossible for receivers in the group to share RTCP feedback information amongst all other group members. Therefore, in this document, we specify a solution to this problem. We introduce unicast feedback as a new method to distribute RTCP control information amongst all session members. It is designed to operate under any group communication model, ASM or SSM. The RTP data stream protocol itself is unaltered. Scenarios under 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 using unicast to send receiver feedback to the source on the standard RTCP port. b) One-to-many broadcast networks. Unicast feedback may also be beneficial to one-to-many broadcast networks, such as a satellite network with a terrestrial low- bandwidth return channel or a broadband cable link. Unlike the SSM network, these networks may have the ability for a receiver to multicast return data to the group. However, a unicast feedback mechanism may be preferable for routing simplicity. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 3] RTCP with Unicast Feedback c) ASM with a single sender. A unicast feedback approach may be used by an ASM application with a single sender, as it would help to prevent overtaxing multicast routing infrastructure that does not scale as efficiently. Because it is not more efficient than a standard multicast group RTP communication scenario, it 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 document proposes two new methods to enable unicast receiver feedback. Each involves unicasting RTCP packets to a Distribution Source whose job it is to re-distribute the information to the members of the group. The Distribution Source must be able to communicate with all group members in order for either mechanism to work. The architecture is displayed below in Figure 1. There may be a single media sender or multiple media senders, Sender i, 1<=i<=N, on whose behalf the Distribution Source disseminates RTP and RTCP packets. The Distribution Source may be one and the same as a particular sender. The basic assumption is that communication is multicast (either SSM or ASM) in the direction from the Distribution Source to receivers, R(i), 1<=i<=N, and unicast in the direction from receivers to the Distribution Source. The Distribution Source is responsible for relaying RTCP information between media sender(s) and receivers in both directions and, of course, for forwarding RTP packets from the media sender(s) to the receivers. Communication between Media Senders (on the left of the figure) and the Distribution Source may be performed in numerous ways: i. Unicast only: The Media Senders MAY send RTP and RTCP via unicast to the Distribution Source and receive RTCP via unicast. ii. Any Source Multicast (ASM): the Media Senders and the Distribution Source MAY be in the same ASM group and RTP and RTCP packets are exchanged via multicast. iii. Source-Specific Multicast (SSM): The Media Senders and the Distribution Source MAY be in an SSM group with the source being the Distribution Source. RTP and RTCP packets from the Media Senders are sent via unicast to the Distribution Source while RTCP packets from the Distribution Source are sent via multicast to the Media Senders. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 4] RTCP with Unicast Feedback Note that this SSM group MAY be identical to the SSM group used for RTP/RTCP delivery from the Distribution Source to the receivers or MAY be a different one. The precise setup and the configuration of the senders and the Distribution Source is beyond the scope of this document (appropriate SDP descriptions MAY be used for this purpose) that only specifies how the various components interact within an RTP session. Informative examples for different configurations of the Media Sources and the Distribution Source are given in Appendix A. Source-specific +-----+ Multicast +--------+ | | +----------------> R(1) |Sender 1|<----->| D S | | | +--------+ | I O | +--+ | | S U | | | | +--------+ | T R | | +-----------> R(2) | |Sender 2|<----->| R C |->+----- : | | +--------+ | I E | | +------> R(n-1) | | | B | | | | | | : | U | +--+--> Rn | | | : | T | | | | | | I |<---------+ | | | | O |<---------------+ | | +--------+ | N |<--------------------+ | |Sender N|<----->| |<-------------------------+ +--------+ +-----+ Unicast Figure 1. System Architecture. The first method, the 'Simple Feedback Model', is a basic reflection mechanism whereby all Receiver RTCP packets are unicast to the Distribution Source and subsequently forwarded by the Distribution 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 Distribution Source, yet still receives forwarded RTCP traffic on the multicast control data channel. This method also has the advantage of being backwards compatible with standard RTP/RTCP implementations. The second method, the 'Distribution Source Feedback Summary Model', is a summarized reporting scheme that provides savings in bandwidth by consolidating Receiver Reports at the Distribution 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 reflection mechanism outlined above generates a large amount of packet forwarding when it replicates all the Chesterfield, et al. Internet Draft - Expires April 2006 [Page 5] RTCP with Unicast Feedback information to all the receivers. The basic operation of the scheme is similar to the first method in that receivers send feedback via unicast to the Distribution Source. In the second scheme, however the Distribution Source distributes summaries of the feedback over the multicast channel. Thus, this technique requires that all session members understand the new summarized packet format outlined in Section 7.1. Additionally, the summarized 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. 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 should not cause problems with respect to the calculation of the Receiver RTCP bandwidth share. 4. Definitions Distribution Source: In an SSM context, only one entity distributes RTP data and redistributes RTCP information to all receivers. This entity 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 consisting 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 8 for details). Media Sender: A Media Sender is an entity that originates RTP packets for a particular media session. In RFC 3550, a Media Sender is simply called a source. However, as the RTCP SSM system architecture includes a Distribution Source, to avoid confusion, in this document a media source is commonly referred to as a Media Sender. There may often be a single media sender that is co- located with the Distribution Source. But although there MUST be only one Distribution Source, there MAY be multiple Media Senders on whose behalf the Distribution Source forwards RTP and RTCP packets. 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 Chesterfield, et al. Internet Draft - Expires April 2006 [Page 6] RTCP with Unicast Feedback share the same multicast address but are differentiated via port numbers as specified in [1]. In an SSM context, the RTP channel is multicast, whereas the RTCP or feedback channel is actually the collection of unicast channels between each receiver and the source. Unicast RTCP Feedback Target: For a session defined as having a Distribution Source A, on ports n for the RTP channel and k for the RTCP channel, the unicast RTCP feedback target is the IP address of Source A on port k unless otherwise stated in the session description. See Section 10 for details on how the address is specified. SSRC: Synchronization source. A 32-bit value that uniquely identifies each member in a session. See [1] for further information. Report blocks: Report block is the standard terminology for an RTCP reception report. RTCP [1] encourages the stacking of multiple report blocks in Sender Report (SR) and Receiver Report (RR) packets. As a result, a variable size feedback packet may be created by one source that reports on multiple other sources in the group. The summarized reporting scheme builds upon this model through the inclusion of multiple summary report blocks in one packet. However, stacking of reports from multiple receivers is not permitted in the simple feedback scheme. 5. Packet types The RTCP packet types defined in [1], [26], and [15] 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 Chesterfield, et al. Internet Draft - Expires April 2006 [Page 7] RTCP with Unicast Feedback Within the Receiver Summary Information packet there are various types of information that may be reported and encapsulated in optional sub-report blocks: Report Block Type Description Identifier number ------------------------------------------------------------------ IPv4 Address IPv4 Unicast Feedback address 0 IPv6 Address IPv6 Unicast Feedback address 1 DNS name DNS name for Unicast Feedback 2 - - reserved - 3 Loss Loss distribution 4 Jitter Jitter distribution 5 RTT Round trip time distribution 6 Cumulative loss Cumulative loss distribution 7 Collisions SSRC collision list 8 - - reserved - 9 Stats General statistics 10 Receiver BW RTCP Receiver Bandwidth 11 Group Info RTCP Group and Avg Packet Size 12 - - reserved - 13 - 255 As with standard RTP/RTCP, 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. 6. Simple Feedback Model 6.1 Packet Formats The Simple Feedback Model uses the same packet types as traditional RTCP feedback described in [1]. Receivers still generate Receiver Reports with information on the quality of the stream received from the Distribution Source. The Distribution Source still must create Sender Reports that include timestamp information for stream synchronization 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 Distribution Source MUST provide a basic packet reflection mechanism. It is the default behavior for any Distribution Source and is the minimum requirement for acting as a Distribution Source to a group of receivers using unicast RTCP feedback. The Distribution Source (the unicast feedback target) MUST listen for unicast RTCP data sent to the RTCP port. All unicast data received on this port MUST be forwarded by the Distribution Source to the group on the multicast RTCP channel. The Distribution Source MUST NOT stack report blocks received from different receivers into Chesterfield, et al. Internet Draft - Expires April 2006 [Page 8] RTCP with Unicast Feedback one packet for retransmission to the group. Every RTCP packet from each receiver MUST be reflected individually. If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST also forward the RTCP packets received from the receivers to the Media Sender(s). If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet from one Media Sender to all other Media Senders. The Distribution Source MUST forward RTCP packets originating from the Media Senders to the receivers. The reflected or forwarded RTCP traffic SHOULD NOT be included in the transmission interval calculation by the Distribution Source. In other words, the Distribution Source SHOULD NOT consider reflected packets as part of its own control data bandwidth allowance. However, they MUST be processed by the Distribution Source and the average RTCP packet size, RTCP transmission rate, and RTCP statistics MUST be calculated. The algorithm for computing the allowance is explained in Section 9. If an application wishes to use APP packets, it is recommended that the Simple Feedback Model be used since it is likely that all receivers in the session will need to hear the APP-specific packets. The same applies for all other RTCP packets that are not defined in the base RTP specification [1]. The decision to use the Simple Feedback Model MUST be made in advance of the session and MUST be indicated in the SDP-based announcement or negotiation [5]. 6.3 Receiver behavior Receivers MUST listen on the RTP channel for data and the RTCP channel for control. Each receiver MUST calculate its share of the control bandwidth R/n, based on the standard rule that a fraction of the RTCP bandwidth, R, allocated to receivers is divided equally between the number of unique receiver SSRCs in the session, n. See Section 9 for further information on the calculation of the bandwidth allowance. When a receiver is eligible to transmit, it MUST send a unicast Receiver Report packet to the indicated unicast RTCP transport address of the Distribution Source following the rules defined in section 9. 6.4 Media Sender behavior Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (optionally forwarded by the Distribution Source). Processing and general operation follows [1]. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 9] RTCP with Unicast Feedback 7. Distribution Source Feedback Summary Model In the Distribution Source Feedback Summary Model, the Distribution Source is required to summarize the information received from all the Receiver Reports generated by the receivers and place the information into summary reports. The Distribution Source Feedback Summary Model introduces a new report block format, the Receiver Summary Information Report (RSI), and a number of optional sub- report block formats, which are enumerated in Section 7.1. 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. From an RTP perspective, the Distribution Source acts like an RTP receiver, generating its own Receiver Reports and sending them to the receiver group and to the Media Senders. However the Distribution Source is not counted in the receiver bandwidth allocation, as it summarizes information provided by the other receivers. Nevertheless, the Distribution Source's transmission rate MUST adhere to RTCP bandwidth limitations for receivers. In the Distribution Source Feedback Summary Model, an RSI report block MUST be appended to all RRs the Distribution Source generates. In addition, if there are multiple Media Senders, the Distribution Source forwards their RTCP SR reports without alteration. If the Distribution Source is actually a Media Sender, even if it is the only session sender, it MUST in addition generate its own Sender Report (SR) packets for its role as a Media Sender and its Receiver Reports in its role as the Distribution Source. The Distribution Source MUST use an SSRC value for transmitting summarization information and MUST perform proper SSRC collision detection and resolution. Note: Here, one could have optimized for the presumably common case (Distribution Source == sender) and reduce the forward bit rate. However, the generalized way always requiring the Distribution Source to be a receiver with its own SSRC is much cleaner, albeit this comes at the cost of some extra bits. The Distribution Source MUST send at least one Receiver Summary Information packet for each reporting interval. The Distribution Source MAY additionally stack sub-report blocks after the RSI packet. If it does so, each sub-report block MUST correspond to the initial RSI packet and constitutes an enhancement to the basic summary information required by the receivers to calculate their reporting time interval. For this reason, additional sub-report blocks are not required but recommended. RSI and the optional corresponding sub-report blocks MUST be sent in addition to the standard receiver-issued packets, such as Receiver Reports and SDES packets outlined in [1]. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 10] RTCP with Unicast Feedback There is one exception to this rule regarding the signaling of group size or bandwidth allocation for receivers. Appended to every RSI packet MUST be either a Group and Average Packet size sub-report or an RTCP Bandwidth sub-report. 7.1 Packet Formats 7.1.1 RSI: Receiver Summary Information Packet The RSI report block has a fixed header size 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : optional report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RSI packet includes the following fields: length: 16 bits As defined in [1], the length of the RTCP packet in 32-bit words minus one, including the header and any padding. SSRC: 32 bits The SSRC of the Distribution Source. Timestamp: 64 bits Indicates the wallclock time, which is seconds relative to 0:00.00 h UTC on 1 January 1900, when this report was sent. This value is used to enable detection of duplicate packets, reordering and to provide a chronological profile of the feedback reports. 7.1.2 Optional Sub-Report Block Types For RSI reports, this document also introduces a sub-report block format specific to the RSI packet. The sub-report blocks are appended to the RSI packet using the following generic format. All sub-report blocks MUST be 32-bit aligned. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 11] RTCP with Unicast Feedback 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data + | | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT: 8 bits Sub-Report Block Type. The sub-report block type identifier. The values for the sub-report block types are defined in section 5. Length: 8 bits The length of the sub-report in 32-bit words. SRBT-specific data: octets This field may contain type-specific information based upon the SRBT value. 7.1.3 Generic Sub-Report Block Fields For the sub-report blocks that convey distributions of values (Loss, Jitter, RTT, Cumulative Loss), a flexible 'data bucket' style report is used. This format divides the data set into variable size buckets that are interpreted according to 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 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SRBT | Length | NDB | MF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Distribution Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Distribution Value | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Distribution Buckets | | ... | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ The SRBT 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 data. The size of each bucket can be calculated using the formula ((length * 4) - 12)*8/NDB number of bits. The calculation is based on the length of the whole sub-report block in octets (length field * 4) minus the header of 12 octets. Providing 12 bits for the NDB field enables bucket sizes as small as 2 bits for a full length packet of MTU 1500 bytes. The bucket size in bits must always be divisible by 2 to ensure proper byte alignment. A bucket size of Chesterfield, et al. Internet Draft - Expires April 2006 [Page 12] RTCP with Unicast Feedback 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 2^MF indicates the multiplicative factor to be applied to each distribution bucket value. Possible values are 0 - 15, creating a range of values from MF = 1, 2, 4 ... 32768. Length: 8 bits The length field tells the receiver the full length of the sub- report block in 32-bit words (i.e., length * 4 bytes), and enables the receiver to identify the bucket size. For example, given no MTU restrictions, the data portion of a distribution packet may be only as large as 1008 bytes (255 * 4 - 12), providing up to 4032 data buckets of length 2 bits, or 2016 data buckets of length 4 bits, etc. Minimum distribution value (min): 32 bits The minimum distribution value, in combination with the maximum distribution value, indicates the range covered by the data bucket values. Maximum distribution value (max): 32 bits The maximum distribution value, in combination with the minimum distribution value, indicates the range covered by the data bucket values. The significance and range of the distribution values is defined in the individual profiles for each distribution type (DT). Distribution buckets: each bucket is ((length * 4) - 12)*8/NDB bits The size and number of buckets is calculated as outlined above based upon the value of NDB and the length of the packet. The values for distribution buckets are equally distributed; according to the following formula, distribution bucket x (with 0 <= x < NDB) covering the value range: x=0; [min, min+(x+1)*(max-min)/NDB] x>0; [min+(x)*(max-min)/NDB, min+(x+1)*(max-min)/NDB] Interpretation of the minimum, maximum and distribution values in the sub-report block are profile-specific and are addressed individually in the sections below. The size of the sub-report block is variable, as indicated by the packet length field. 7.1.4 Loss sub-report block The loss sub-report block allows a receiver to determine how its own reception quality relates to the other recipients. A receiver may use this information, e.g., to drop out of a session (instead of sending lots of error repair feedback) if it finds itself isolated at the lower end of the reception quality scale. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 13] RTCP with Unicast Feedback The loss sub-report block indicates the distribution of losses as reported by the receivers to the Distribution Source. Values are expressed as a fixed-point number with the binary point at the left edge of the field similar to the "fraction lost" field in SR and RR packets as defined in [1]. The sub-report block type (SRBT) is 4. 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 summarized loss report sub-blocks, see Appendix B. 7.1.5 Jitter sub-report block A jitter sub-report block indicates the distribution of the estimated statistical variance of the RTP data packet inter-arrival time reported by the receivers to the Distribution Source. This allows receivers both to place their own observed jitter values in context with the rest of the group, and to approximate dynamic parameters for playout buffers. See [1] for details on how the values are calculated and the relevance of the jitter results. Jitter values are measured in timestamp units and expressed as unsigned integers. The minimum distribution value MUST always be less than the maximum. The sub-report block type (SRBT) is 5. Since timestamp units are payload type specific, the relevance of a jitter value would be impacted by any change in the payload type during a session. Therefore, a Distribution Source MUST NOT report jitter distribution values for at least 2 reporting intervals in the event that a payload type change occurs. 7.1.6 Round Trip Time sub-report block A round trip time sub-report indicates the distribution of round trip times from the Distribution Source to the receivers, providing receivers with a global view of the range of values in the group. The Distribution Source is capable of calculating the round trip time to any other members since it forwards all the SR packets from the Media Sender(s) to the group. If the Distribution Source is not itself the actual Media Sender, it can calculate the round trip time from itself to any of the receivers by maintaining a record of the SR sender timestamp, and the current time as measured from its own system clock. The Distribution Source consequently calculates the round trip time from the receiver report by identifying the corresponding SR timestamp, and subtracting the RR advertised holding time as reported by the receiver, from its own time difference measurement as calculated by the time the RR packet is received, and the recorded time the SR was sent. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 14] RTCP with Unicast Feedback The Distribution Source has the option of distributing these round trip time estimations to the whole group, uses of which are described in Section 7.4. The Round trip time is expressed in units of 1/65536 seconds and indicates an absolute value. This is calculated by the Distribution Source based on the Receiver Report responses declaring the time difference since an original Sender Report, and the holding time at the receiver. The minimum distribution value MUST always be less than the maximum. The sub- report block type (SRBT) is 6. 7.1.7 Cumulative Loss sub-report block The cumulative loss field in a Receiver Report [1], in contrast to the Average Fraction Lost field, is intended to provide some historical perspective on the session performance, i.e. the total number of lost packets since the receiver joined the session. The cumulative loss value presents a smoothed average by summing over a larger sample set (typically the whole session). The Distribution Source MAY record the values as reported by the receiver group and report a distribution of values. Values are expressed as a fixed- point number with the binary point at the left edge of the field, in the same manner as the Loss sub-report block. The sender must maintain a record of the Cumulative number lost and Extended Highest Sequence number received as reported by each receiver. Ideally the recorded values are from the first report received. Future calculations are then based on ( - ) / ( - ). 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. The sub-report block type (SRBT) is 7. 7.1.8 Feedback Address Target sub-report block The feedback address target block provides a dynamic mechanism for the Distribution Source to signal an alternative unicast RTCP feedback address to the receivers. If this field is included, it MUST override any static SDP address information for the session. If this sub-report block is used, it MUST be included in every RTCP packet originated by the Distribution Source to ensure that all receivers understand the information. In this manner, receiver behavior should remain consistent even in the face of packet loss or for late session arrivals. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 15] RTCP with Unicast Feedback 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT={0,1,2} | Length | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 8 bits The length of the sub-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 number of 32-bit words making up the string plus 1 byte and any additional padding required to reach the next word boundary. Port: 2 octets (optional) The port number to which receivers send feedback reports. A port number of 0 is invalid and MUST NOT be used. Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) The address to which receivers send feedback reports. For IPv4 and IPv6 fixed-length address fields are used. A DNS name is an arbitrary length string that is padded with null bytes to the next 32 bit boundary. The string MUST be UTF-8 encoded [11]. For IPv4, SRBT=0. For IPv6, SRBT=1. For usage of the DNS name, SRBT=2. A feedback target address block with a certain SRBT MUST NOT occur more than once. Dual Numerical feedback target address blocks for IPv4 and IPv6 MAY both be present. If so, the resulting transport addresses MUST point to the same logical entity (i.e., the Distribution Source). If a feedback target address block with an SRBT indicating a DNS name is present, there SHOULD NOT be any other numerical feedback target address blocks present. The feedback target address presents a significant security risk if accepted from unauthenticated RTCP packets. See section 11.3 a) and 11.4 a). 7.1.9 Collisions sub-report block The collision SSRC sub-report provides the Distribution Source with a mechanism to report SSRC collisions amongst the group. In the event that a non-unique SSRC is discovered based on the tuple [SSRC,CNAME], the collision is reported in this block and the affected nodes must reselect their respective SSRC identifiers. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 16] RTCP with Unicast Feedback 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=8 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Collision SSRC : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Collision SSRC: n x 32 bits This field contains a list of 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 session using the Distribution Source Feedback Summary Model no longer have a global view of the session, the collision algorithm is handled by the Distribution Source. SSRCs that collide are listed in the packet. Each Collision SSRC is reported only once for each collision detection. If more Collision SSRCs need to be reported than fit into an MTU, the reporting is done in a round robin fashion so that all Collision SSRCs have been reported once before the second round of reporting starts. On receipt of the packet, receiver(s) MUST detect the collision and select another SSRC, if the collision pertains to them. 7.1.10 General Statistics sub-report block The general statistics sub-report block is used if specifying buckets is deemed too complex. With the general statistics sub- report block only aggregated values are reported back. The rules for the generation of these values are provided in section 7.2.1 b). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=10 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MFL | HCNL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Median interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Median fraction lost (MFL): 8 bits The median fraction lost indicated by Receiver Reports forwarded to this Distribution Source, expressed as a fixed point number with the binary point at the left edge of the field. A value of all '1's indicates that the MFL value is not provided. Highest cumulative number of packets lost (HCNL): 24 bits Chesterfield, et al. Internet Draft - Expires April 2006 [Page 17] RTCP with Unicast Feedback Highest 'cumulative number of packets lost' value out of the most recent RTCP RR packets from any of the receivers. A value of all '1's indicates that the HCNL value is not provided. Median inter-arrival jitter: 32 bits Median 'inter-arrival jitter' value out of the most recent RTCP RR packets from the receiver set. A value of all '1's indicates that this value is not provided. 7.1.11 RTCP Bandwidth indication sub-report block This sub-report block is used to inform the Media Senders and receivers about the maximum RTCP bandwidth that is supposed to be used by each Media Sender or about the maximum bandwidth allowance to be used by each receiver. The value is applied universally to all Media Senders or all receivers. Each receiver MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself. Each Media Sender MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by the Distribution Source to the receivers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=11 | Length |S|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTCP Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender (S): 1 bit The contained bandwidth value applies to each Media Sender. Receivers (R): 1 bit The contained bandwidth value applies to each RTP receiver. Reserved: 14 bits MUST be set to zero upon transmission and ignored upon reception. RTCP Bandwidth: 32 bits If the S bit is set to 1, this field indicates the maximum bandwidth allocated to each individual sender. This also informs the receivers about the RTCP report frequency to expect from the senders. This is a fixed point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per-receiver in kilobits per second with values in the range 0 <= BW < 65536. If the R bit is set to 1, this field indicates the maximum bandwidth allocated per receiver for sending RTCP data relating to the session. This is a fixed point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per-receiver in kilobits per second with Chesterfield, et al. Internet Draft - Expires April 2006 [Page 18] RTCP with Unicast Feedback values in the range 0 <= BW < 65536. Each receiver MUST use this value for its bandwidth allowance. This report block SHOULD only be used when the Group and Average Packet Size sub-report block is NOT included. 7.1.12 RTCP Group and Average Packet Size Sub-report Block This sub-report block is used to inform the Media Senders and receivers about the size of the group (used for calculating feedback bandwidth allocation) and the average packet size of the group. This sub-report MUST always be present, appended to every RSI packet, unless an RTCP Bandwidth indication sub-report block is included (in which case it MAY but need not be present). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=12 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Group Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Packet Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Group size: 32 bits This field provides the Distribution Source's view of the number of receivers in a session. Note that the number of Media Senders is not explicitly reported since it can be derived by observed the RTCP SR packets forwarded by the Distribution Source. The group size is calculated according to the rules outlined in [1]. When this sub-report block is included, this field MUST always be present. Average RTCP packet size: 32 bits This field provides the Distribution Source's view of the average RTCP packet size as locally calculated following the rules defined in [1]. When this sub-report block is included, this field MUST always be present. 7.2 Distribution Source behaviour In the Distribution Source Feedback Summary Model, the Distribution Source (the unicast feedback target) MUST listen for unicast RTCP data sent to the RTCP port. All unicast data received on this port MUST be processed by the Distribution Source as described below. The Distribution Source acts like a regular RTCP receiver. In particular, it receives an RTP stream from each RTP Media Sender(s) and MUST calculate the proper reception statistics for these RTP streams. It MUST transmit the resulting information as report blocks contained in each RTCP packet it sends (in an RR packet). Chesterfield, et al. Internet Draft - Expires April 2006 [Page 19] RTCP with Unicast Feedback Note: This information may help to determine the transmission characteristics of the feed path from the RTP sender to the Distribution Source (if these are separate entities). The Distribution Source is responsible for accepting RTCP packets from the receivers, and interpreting and storing per-receiver information as defined in [1]. The importance of providing these functions is apparent when creating the RSI and sub-report block reports, since incorrect information can have serious implications. Section 11 addresses the security risks in detail. As defined in [1], all RTCP reports from the Distribution Source MUST start with an RR report followed by any relevant SDES fields. Then, the Distribution Source MUST append any summarization specific data to an RR report since it always generates RR data. In addition, either the Group and Average Packet size sub-report or the Receiver RTCP Bandwidth sub-report block MUST be appended to the RSI header. A Distribution Source has the option of masking the Group size by including only an RTCP bandwidth sub-report. If both sub-reports are included, the information contained in the Receiver RTCP Bandwidth sub-report block MUST take precedence. The Receiver RTCP Bandwidth sub-report block provides the Distribution 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 Distribution Source. Regardless of the value selected by the Distribution Source for the Receiver RTCP Bandwidth sub-report block, the Distribution Source MUST continue to forward Sender Reports and RSI packets at the rate allowed by the total RTCP bandwidth allocation. See Section 9 for further details about the frequency of reports. A Distribution Source MAY start out reporting Group size and switch to Receiver RTCP Bandwidth reporting later on and vice versa. If the Distribution Source does so, it SHOULD ensure that the correspondingly indicated values for the Receiver RTCP Bandwidth roughly match, i.e., are at least the same order of magnitude. In order to identify SSRC collisions, the Distribution 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 Distribution 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). Chesterfield, et al. Internet Draft - Expires April 2006 [Page 20] RTCP with Unicast Feedback 7.2.1 Receiver Report Aggregation The Distribution Source is responsible for aggregating reception quality information received in SR and RR packets. In doing so, the Distribution Source MUST consider the report blocks received in every RR packet and MUST NOT consider the report blocks of an SR packet. For the optional sub-report blocks, the Distribution 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 tradeoff between the granularity of the data and the accuracy of the data based on the multiplicative factor (MF), the number of buckets, and the min and max values. In order to focus on a particular region of a distribution, the Distribution Source can adjust the minimum and maximum values, and either increase the number of buckets and possibly the factorization, 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 sub-report block information. For each value the Distribution Source decides to include in an RSI packet, it MUST adhere to the following measurement rules. a) If the Distribution Source intends to use a sub-report to convey a distribution of values (sections 7.1.3 to 7.1.7), it MUST keep per receiver state, i.e., remember the last value V reported by the respective receiver. If a new value is reported by a receiver, the existing value MUST be replaced by the new one. The value MUST be deleted (along with the entire entry) if the receiver is timed out (as per section 6.3.5 of [1]) or has sent a BYE packet (as per section 6.3.7 of [1]). All the values collected in this way MUST be included in the creation of the subsequent distribution sub-report block. The results should correspond as closely as possible to the values received during the interval since the last report. The Distribution Source may stack as many sub-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 link MTU. All stacked sub-reports MUST be internally consistent, i.e., generated from the same session data. Overlapping of distributions is therefore allowed, and variation in values should only occur as a result of data set granularity, with the more accurate bucket sizes taking precedence in the event that values differ. Non-divisible values MUST be rounded up or down to the closest bucket value, and the number of data buckets must always be an even number, padding where necessary with an additional zero bucket value to maintain consistency. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 21] RTCP with Unicast Feedback Note: This intentionally provides persistent full coverage of the entire session membership to avoid oscillations due to changing membership samples. b) If the Distribution Source intends to report a short summary using the format defined in section 7.1.10, for EACH of the values included in the report (AFL, HCNL, average interarrival jitter), it MUST keep a timer T_summary as well as three entries: V, V', and V" (indicated as Vi, with i=0,1,2). The respective value V (or V0) is included in each report sent. The summary values are included here to reflect the current group situation. By recording the last three reporting intervals the Distribution Source incorporates reports from all members while allowing for individual RTCP receiver report packet losses. The process of collecting these values also aims to avoid resetting any of the values and then having to send out an RSI report based upon just a few values collected. The timer constant T_summary MUST be initialized as T_summary = 1.5*Td, where Td is the reporting interval, and MUST be updated following timer reconsideration whenever the group size or the average RTCP size ("avg_rtcp_size") changes. This choice should allow each receiver to report once per interval. V, V', and V" are initialized to an "empty" value. Because 0 and -1 are sometimes valid values, here are guidelines on how to initialize the "empty" value. If Vi indicates a signed maximum, the empty value is -Infinity, for an unsigned maximum it is 0. If Vi indicates a (signed or unsigned) minimum, the empty value is +Infinity. If Vi indicates a median, the empty value is 0 and an associated counter VNi is required that is also initialized to 0 and that dampens the effects of large oscillations of newly received values. Furthermore, to capture the distribution needed for the median calculation, state is needed for each receiver j as Vi_j. As RTCP receiver reports are received by the Distribution Source, the values V, V', and V" are updated as described below. When T_summary expires, the assignments V = V' (V0=V1) and V' = V" (V1=V2) are carried out and V" (V2) is initialized to "empty". This also applies to per-receiver state. Let VR be the newly received value. For a maximum calculation, if Vr > Vi then Vi = Vr, otherwise Vi remains unchanged. For a minimum calculation, if Vr < Vi then Vi = Vr, otherwise Vi remains unchanged. For a median calculation, Vi_j is updated as follows when a report is received for receiver j containing the value Vr_j: Chesterfield, et al. Internet Draft - Expires April 2006 [Page 22] RTCP with Unicast Feedback Vi_j = Vr_j The median is only calculated upon transmission of the RSI packet: VN is set to the number of reports V0_j available (1 <= j <= VN) contained in V (V0). Then, the set V0 = { V0_j | for each V0_j } is sorted and the median V is determined using V0 and VN. 7.2.2 Receiver Report Forwarding If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST also forward the RTCP packets received from the receivers to the Media Sender(s). Instead of forwarding RTCP RRs from the receivers, the Distribution Source MAY also send the RSI packets to the senders (if it knows that the Media Senders understand RTCP RSI packets). 7.2.2 Handling Sender Reports The Distribution Source also receives SR packets from the RTP Media Senders. The Distribution Source MUST forward all RTCP packets from the RTCP Media Senders to the receivers. If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet from one Media Sender to all other Media Senders. 7.3 Receiver behavior An RTP 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 conveyed by the Distribution 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 analyzing all Receiver Reports. The RTP receiver MUST process the report blocks contained in any RTP SR and RR packets to complete its view of the RTP session. The SSRC collision list MUST be checked against the SSRC selected by the receiver to ensure there are no collisions. A Group and Average Packet size sub-report block is most likely to be appended to the RSI header (either a Group size sub-report or an RTCP Bandwith sub-report MUST be included). The Group size n allows a receiver to calculate its share of the RTCP bandwidth, r. Given R, the total available RTCP bandwidth share for receivers (in the SSM Chesterfield, et al. Internet Draft - Expires April 2006 [Page 23] RTCP with Unicast Feedback RTP session) r = R/(n). For the group size calculation, the RTP receiver MUST NOT include the Distribution Source, i.e. the only RTP receiver sending RSI packets. The Receiver RTCP Bandwidth field MAY override this value. If the Receiver RTCP Bandwidth field is present, the receiver MUST use this value as its own RTCP reporting bandwidth r. If the RTCP Bandwidth field was used by the Distribution Source in an RTCP session but this field was not included in the last five RTCP RSI reports, the receiver MUST revert to calculating its bandwidth share based upon the Group size information. If the receiver has not obtained any RTCP RSI packets from the Distribution Source for a period of five times the sender reporting interval, it MUST cease transmitting RTCP receiver reports until the next RTCP RSI packet is received. The receiver can use the summarized 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. The appendix B (section 16) provides further information and examples of data processing at the receiver. The receiver SHOULD assume that any sub-report blocks in the same packet correspond to the same data set received by the Distribution Source during the last reporting time interval. This applies to packets with multiple blocks, where each block conveys a different range of values. 7.4 Media Sender Behavior Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (optionally forwarded by the Distribution Source). Unlike in case of the simple forwarding model, Media Senders MUST be able to process RSI packets from the Distribution Source to determine the group size and their own RTCP bandwidth share. Media Senders MUST also be capable of determining the group size (and their corresponding RTCP bandwidth share) from listening to (forwarded) RTCP RR and SR packets (as mandated in [1]). As long as they send RTP packets they MUST also send RTCP SRs as defined in [1]. 8. Mixer/Translator issues The original RTP specification allows a session to use mixers and translators which help to connect heterogeneous networks into one Chesterfield, et al. Internet Draft - Expires April 2006 [Page 24] RTCP with Unicast Feedback 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 document 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 [5] for the single source session (Section 11) and use the feedback mechanism indicated. Receivers SHOULD be aware that by introducing a mixer- translator into the session, more than one Media Sender 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 + summarization reporting between more than one source may be complicated unless the mixer-translator is capable of summarization. 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 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 April 2006 [Page 25] RTCP with Unicast Feedback 9. Transmission interval calculation The Control Traffic Bandwidth referred to in [1] is an arbitrary amount that is intended to be supplied by a session management application (e.g., sdr [21]) or decided based upon the bandwidth of a single sender in a session. The RTCP transmission interval calculation remains the same as in the original RTP specification [1] or uses the algorithm in [10] when bandwidth modifiers have been specified for the session. 9.1 Receiver RTCP Transmission If the Distribution Source is operating in Simple Feedback mode (which may be indicated in the corresponding session description for the media session but which the receiver also notices from the absence of RTCP RSI packets), a receiver MUST calculate the number of other members in a session based upon its own SSRC count derived from the forwarded Sender and Receiver Reports it receives. The receiver MUST calculate the average RTCP packet size from all the RTCP packets it receives. If the Distribution Source is operating in Distribution Source Feedback Summary mode, the receiver MUST use either the Group size field and the average RTCP packet size field, or the Receiver Bandwidth Field from the respective sub-report blocks appended to the RSI packet. A receiver uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10]. 9.2 Distribution Source RTCP Transmission If operating in Simple Feedback mode, the Distribution Source MUST calculate the transmission interval for its Receiver Reports and associated RTCP packets based upon the above control traffic bandwidth and MUST count itself as RTP receiver. Receiver Reports will be forwarded as they arrive without further consideration. The Distribution Source MAY choose to validate that all or selected receivers roughly adhere to the calculated bandwidth constraints and MAY choose to drop excess packets for receivers that do not. In all cases, the average RTCP packet size is determined from the Media Senders' and receivers' RTCP packets forwarded and those originated by the Distribution Source. If operating in Distribution Source Feedback Summary mode, the Distribution Source does not share the forward RTCP bandwidth with any of the receivers. Therefore, the Distribution Source SHOULD use the full RTCP bandwidth for its receiver reports and associated RTCP packets, as well as RTCP RSI packets. In this case, the average Chesterfield, et al. Internet Draft - Expires April 2006 [Page 26] RTCP with Unicast Feedback RTCP packet size is only determined from the RTCP packets originated by the Distribution Source. The Distribution Source uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10]. 9.3 Media Senders RTCP Transmission In Simple Feedback Mode, the Media Senders obtain all RTCP SRs and RRs as they would in an ASM session, except that the packets are forwarded by the Distribution Source. They MUST perform their RTCP group size estimate and calculation of the calculation of the deterministic calculated interval as per [1] and [10]. In Distribution Source Feedback Summary Mode, the Media Senders obtain all RTCP SRs as they would in an ASM session. They receive either RTCP RR reports as in ASM (in case these packets are forwarded by the Distribution Source) or RSI packets containing summaries. In the former case, they MUST perform their RTCP group size estimate and calculation of the calculation of the deterministic calculated interval as per [1] and [10]. In the latter case, they MUST combine the information obtained from the Sender Reports and the RSI packets to create a complete view of the group size and the average RTCP packet size and perform the calculation of the deterministic calculated interval as per [1] and [10] based upon these input values. 9.4 Operation in conjunction with AVPF If the RTP session is an AVPF session [15] (as opposed to a regular AVP [6] session the receivers MAY modify their RTCP report scheduling as defined in [15]. Use of AVPF does not affect the Distribution Source's RTCP transmission or forwarding behavior. It is RECOMMENDED that a Distribution Source operates in the Simple Forwarding Mode in order not to counteract the damping mechanism built into AVPF. If only generic feedback packets are in use that are understood by the Distribution Source and that can easily be aggregated, the Distribution MAY combine several incoming RTCP feedback packets and forward the aggregate along with its next RTCP RR/RSI packet. In any case, the Distribution Source SHOULD NOT delay forwarding feedback information. In the event that APP specific packets without a defined summarization format are to be used, the Simple Forwarding Mode of operation MUST be adopted from the start. 10. SDP Extensions The Session Description Protocol (SDP) [5] is used as a means to describe media sessions in terms of their transport addresses, Chesterfield, et al. Internet Draft - Expires April 2006 [Page 27] RTCP with Unicast Feedback 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 document (and that also need to be registered with IANA). 10.1 SSM RTCP Session Identification A new session level attributes MUST be used to indicate the use of unicast instead of multicast feedback: "rtcp-unicast". This attribute uses one parameter to specify the mode of operation. rtcp-unicast:reflection This attribute MUST be used to indicate the "Simple Feedback" mode of operation where packet reflection is used by the RTCP target (without further processing). rtcp-unicast:rsi This attribute MUST be used to indicate the "Distribution Source Feedback Summary" mode of operation. 10.2 SSM Source Specification In addition, in a Source-Specific Multicast RTCP session, the Distribution Source needs 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 Distribution Source. This is achieved by following the proposal for SDP source filters documented in [4]. According to the specification, for SSM RTCP only the inclusion mode ("a=source-filter:incl") MUST be used. 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 alternative Distribution Source feedback address and port MAY be supplied using the SDP RTCP attribute [7], e.g., a=rtcp: IN IP4 192.168.1.1. Two "source-filter" attributes MAY be present to indicate an IPv4 and an IPv6 representation of the Distribution Source address. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 28] RTCP with Unicast Feedback 11. Security Considerations The level of security provided by the current RTP/RTCP model MUST NOT be diminished by the introduction of unicast feedback to the source. This section identifies the security weaknesses introduced by the feedback mechanism, potential threats, and level of protection that MUST be adopted. Any suggestions on increasing the level of security provided to RTP sessions above the current standard are RECOMMENDED but OPTIONAL. The final section outlines some security frameworks that are suitable to conform to this specification. 11.1 Assumptions RTP/RTCP is a protocol that carries real-time multimedia traffic, and therefore a main requirement is for any security framework to maintain as low overhead as possible. This includes the overhead of different applications and types of cryptographic operations, as well as the overhead to deploy or to create security infrastructure for large groups. Although the distribution of session parameters, typically encoded as SDP objects, through SAP [22], e-mail, or the web, is beyond the scope of this document, it is RECOMMENDED that the distribution method employs adequate security measures to ensure the integrity and authenticity of the information. Suitable solutions that meet the security requirements outlined here are included at the end of this section. In practice, the multicast and group distribution mechanism, e.g., the SSM routing tree, is not immune to source IP address spoofing or traffic snooping. Therefore, all security weaknesses are addressed from the transport level or above. 11.2 Security threats Attacks on media distribution and the feedback architecture proposed in this document may take a variety of forms. An outline of the types of attacks in detail: a) Denial of Service (DoS) DoS is a major area of concern. Due to the nature of the communication architecture a DoS can be generated in a number of ways by using the unicast feedback channel to the attackers advantage. b) Packet Forgery Another potential area for attack is packet forgery. In particular, it is essential to protect the integrity of certain influential packets since compromise could directly affect the transmission characteristics of the whole group. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 29] RTCP with Unicast Feedback c) Session Replay The potential for session recording and subsequent replay is an additional concern. An attacker may not actually need to understand packet content, but simply have the ability to record the data stream and, at a later time, replay it to any receivers that are listening. d) Eavesdropping on a session The consequences of an attacker eavesdropping on a session already constitutes a security weakness; in addition, it might benefit other types of attack, and is therefore considered a potential threat. For example, an attacker might be able to use the eavesdropped information to perform an intelligent DoS attack. 11.3 Architectural Contexts To better understand the requirements of the solution, the threats outlined above are addressed for each of the two communication contexts: a) Source-to-Receiver communication The downstream communication channel, from the source to the receivers, is critical to protect as it controls the behavior of the group; it conveys the bandwidth allocation for each receiver and hence the rate at which the RTCP traffic is unicast directly back to the source. All traffic that is distributed over the downstream channel is generated by a single source. Both the RTP data stream and the RTCP control data from the source are included in this context, with the RTCP data generated by the source being indirectly influenced by the group feedback. The downstream channel is vulnerable to four types of attacks. A denial of service attack is possible, but less of a concern. The worst case effect would be the transmission of large volumes of traffic over the distribution channel with the potential to reach every receiver, but only on a one-to-one basis. Consequently, this threat is no more pronounced than the current multicast ASM model. The real danger of denial of service attacks in this context comes indirectly via compromise of the source RTCP traffic. If receivers are provided with an incorrect group size estimate or bandwidth allowance, the return traffic to the source may create a distributed DoS effect on the source. Similarly, an incorrect feedback address whether as a result of a malicious attack or by mistake, e.g., an IP address configuration (e.g., typing) error, could directly create a denial of service attack on another host. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 30] RTCP with Unicast Feedback An additional concern relating to Denial of Service attacks would come indirectly through the generation of fake BYE packets causing the source to adjust the advertised group size. A Distribution Source MUST follow the correct rules for timing out members in a session prior to reporting a change in the group size, which allows the authentic SSRC sufficient time to continue to report and consequently cancel the fake BYE report. The danger of Packet Forgery in the worst case may be to maliciously instigate a denial of service attack, e.g., if an attacker were capable of spoofing the source address and injecting incorrect packets into the data stream or intercepting the source RTCP traffic and modifying the fields. The Replay of a Session would have the effect of recreating the receiver feedback to the source address at a time when the source is not expecting additional traffic from a potentially large group. The consequence of this type of attack may be less effective on its own, but in combination with other attacks might be serious. Eavesdropping on the session would provide an attacker with information on the characteristics of the source-to-receiver traffic such as the frequency of RTCP traffic. If RTCP traffic is unencrypted, this might also provide valuable information on characteristics such as group size and transmission characteristics of the receivers back to the source. b) Receiver-to-Distribution-Source communication The second context is the return traffic from the group to the Distribution Source. This traffic should only consist of RTCP packets, and should include receiver reports, SDES information, BYE reports, extended reports (XR), feedback messages (RTPFB, PSFB) and possibly Application specific packets. The effects of compromise on a single or subset of receivers is not likely to have as great an impact as the context (a), however much of the responsibility for detecting compromise of the source data stream relies on the receivers. The effects of compromise of critical Distribution Source control information would be amplified most seriously in this context. A large group of receivers may unwittingly generate a distributed DoS attack on the Distribution Source in the event that the integrity of the source RTCP channel has been compromised and is not detected by the individual receivers. An attacker capable of instigating a Packet Forgery attack could introduce false RTCP traffic and create fake SSRC identifiers. Such attacks might slow down the overall control channel data rate, since an incorrect perception of the group size may be created. Similarly, the creation of fake BYE reports by an attacker would cause some group size instability, but should not Chesterfield, et al. Internet Draft - Expires April 2006 [Page 31] RTCP with Unicast Feedback be effective as long as the correct timeout rules are applied by the source in removing SSRC entries from its database. 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. Therefore, ensuring authenticity and freshness of the data source is important. Eavesdropping in this context potentially provides an attacker with a great deal of potentially 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 allowances. 11.4 Requirements in each context To address these threats, this section presents the security requirements for each context. a) The main threat in the first context concerns denial of service attacks through possible packet forgery. The forgery may take the form of interception and modification of packets from the source, or simply injecting false packets into the distribution channel. To combat these attacks, data integrity and source authenticity MUST be applied to source traffic. Since the consequences of eavesdropping do not affect the operation of the protocol, confidentiality is not a requirement in this context. However without confidentiality, access to personal and group characteristics information would be unrestricted to an external listener. Therefore confidentiality is RECOMMENDED. b) The threats in the second context also concern the same kinds of attacks but are considered less important than the downstream traffic compromise. All the security weaknesses are also applicable to the current RTP/RTCP security model and therefore only recommendations are made towards protection from compromise. Data integrity is RECOMMENDED to ensure that interception and modification of an individual receiver's RTCP traffic can be detected. This would protect against the false influence of group control information and the potentially more serious compromise of future services provided by the distribution functionality. In order to ensure security, data integrity and authenticity of receiver traffic is therefore also RECOMMENDED. The same situation applies as in the first context with respect to data confidentiality, and it is RECOMMENDED that precautions should be taken to protect the privacy of the data. An additional security consideration that is not a component of this specification but has a direct influence upon the general security is the origin of the session initiation data. This involves the SDP parameters that are communicated to the members prior to the start of the session via channels such as an HTTP server, email, SAP, or Chesterfield, et al. Internet Draft - Expires April 2006 [Page 32] RTCP with Unicast Feedback other means. It is beyond the scope of this document to place any strict requirements on the external communication of such information, however suitably secure SDP communication approaches are outlined in section 11.7. 11.5 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 authorized group members share the same key and can equally encrypt/decrypt the data. This method assumes that an out-of-band method is applied to the distribution of the shared group key ensuring that every key-holder is individually authorized to receive the key, and in the event of member departures from the group, a re-keying exercise can occur. The advantage of this model is that the costly processing associated with one-way key authentication techniques is avoided, as well as the need to execute additional cipher operations with alternative key sets on the same data set, e.g., in the event that data confidentiality is also applied. The disadvantage is that, for very large groups where the receiver set becomes effectively untrusted, a shared key does not offer much protection. b) The public-key authentication model, using cryptosystems such as RSA-based or PGP authentication, provides a more secure method of source authentication at the expense of generating higher processing overhead. This is typically not recommended for Real- time data streams, but in the case of RTCP reports which are distributed with a minimum interval of 5 seconds, this may be a viable option (the processing overhead might still be too great for small, low-powered devices and should therefore be considered with caution). Wherever possible, however, the use of public key source authentication is preferable to the shared key model identified above. As concerns requirements for protocol acceptability, either model is acceptable, although it is RECOMMENDED that the more secure public- key based options should be applied wherever possible. 11.6 Recommended security solutions This section presents some existing security mechanisms that are RECOMMENDED to suitably address the requirements outlined in section 12.5. This is only intended as a guideline and it is acknowledged that there are other solutions that would also be suitable to be compliant with the specification. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 33] RTCP with Unicast Feedback 11.6.1 Secure Distribution of SDP Parameters a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters for the session SHOULD use a secure mechanism such as the SAP authentication framework which allows an authentication certificate to be attached to the session announcements. Other methods might involve HTTPS or signed email content from a trusted source. However, some more commonly used techniques for distributing session information and starting media streams are RTSP [13] and SIP [14]. b) RTSP -- RTSP provides a client or server initiated stream control mechanism for real-time multimedia streams. The session parameters are conveyed using SDP syntax and may adopt standard HTTP authentication mechanisms in combination with suitable network (e.g. IPSEC) or transport (e.g. TLS) level security. c) SIP -- A typical use of SIP involving a unicast feedback identifier might be a client wishing to dynamically join a multi- party call on a multicast address using unicast RTCP feedback. The client would be required to authenticate the SDP session descriptor information returned by the SIP server. The recommended method for this, as outlined in the SIP specification [14], is to use an S/MIME message body containing the session parameters signed with an acceptable certificate. For the purposes of this profile, it is acceptable to use any suitably secure authentication mechanism which establishes the identity and integrity of the information provided to the client. 11.6.2 Suitable Security Solutions for RTP Sessions with Unicast Feedback a) SRTP -- SRTP is the recommended AVT security framework for RTP sessions. It specifies the general packet formats and cipher operations that are used, and provides the flexibility to select different stream ciphers based on preference/requirements. It can provide confidentiality of the RTP and RTCP packets as well as protection against integrity compromise and replay attacks. It provides authentication of the data stream using the shared key trust model. Any suitable key-distribution mechanism can be used in parallel to the SRTP streams. b) IPSEC -- A more general group security profile which might be used is the Group Domain of Interpretation [23], 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 using a shared key or individually through public-key mechanisms. 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. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 34] RTCP with Unicast Feedback c) TESLA - TESLA [24] 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 lower than other standard public-key mechanisms and therefore may be more suited to small or energy restricted devices. 11.6.3 Secure Key Distribution Mechanisms a) MIKEY -- MIKEY [12] is the preferred solution for SRTP sessions providing a shared group key distribution mechanism and intra- session rekeying facilities. If a partly protected communication channel exists, keys may also be conveyed using SDP as per [27]. b) GSAKMP -- GSAKMP is the general solution favored for Multicast Secure group key distribution. It is the recommended key distribution solution for GDOI sessions. 12. Backwards Compatibility The use of unicast feedback to the source should not present any serious backwards compatibility issues. The RTP data streams should remain unaffected, as are the RTCP packets from the source enabling inter-stream synchronization in the case of multiple streams. The unicast transmission of RTCP data to a source that does not have the ability to reflect traffic by either mechanism could have serious security implications as outlined in Section 11, but would not actually break the operation of RTP. For RTP-compliant receivers that do not understand the unicast mechanism, the RTCP traffic may 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. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 35] RTCP with Unicast Feedback 13. IANA Considerations The following contact information shall be used for all registrations included here: Contact: Joerg Ott mailto:jo@acm.org tel:+358-9-451-2460 Based on the guidelines suggested in [2], this document proposes 1 new RTCP packet format to be registered with the RTCP Control Packet type (PT) Registry: Name: RSI Long name: Receiver Summary Information Value: 208 Reference: This document. This document defines a substructure for RTCP RSI packets. A new sub-registry needs to be set up for the sub-report block type (SRBT) values for the RSI packet, with the following registrations created initially: Name: IPv4 Address Long name: IPv4 Feedback Target Address Value: 0 Reference: This document. Name: IPv6 Address Long name: IPv6 Feedback Target Address Value: 1 Reference: This document. Name: DNS Name Long name: DNS Name indicating Feedback Target Address Value: 2 Reference: This document. Name: Loss Long name: Loss distribution Value: 4 Reference: This document. Name: Jitter Long name: Jitter Distribution Value: 5 Reference: This document. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 36] RTCP with Unicast Feedback Name: RTT Long name: Round-trip time distribution Value: 6 Reference: This document. Name: Cumulative loss Long name: Cumulative loss distribution Value: 7 Reference: This document. Name: Collisions Long name: SSRC Collision list Value: 8 Reference: This document. Name: Stats Long name: General statistics Value: 10 Reference: This document. Name: RTCP BW Long name: RTCP Bandwidth indication Value: 11 Reference: This document. Name: Group Info Long name: RTCP Group and Average Packet size Value: 12 Reference: This document. The value 3 shall be reserved for a further way of specifying a feedback target address. The value 3 MUST only be allocated for a use defined in an IETF Standards Track document. Further values may be registered on a first-come first-serve basis. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated sub-report block. The general registration procedures of [5] apply. 14. Bibliography 14.1 Normative References [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - A Transport Protocol for Real-time Applications," RFC 3550 (STD 64), July 2003. [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 37] RTCP with Unicast Feedback [3] M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund, and K. Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March 2004. [4] B. Quinn, R. Finlayson, "SDP Source-Filters", Internet Draft draft-ietf-mmusic-sdp-srcfilter-10.txt, Work in Progress, September 2005. [5] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session Description Protocol", Internet Draft draft-ietf-mmusic-sdp-new- 25.txt, Work in Progress, July 2005. [6] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551 (STD 65), July 2003. [7] C. Huitema, "RTCP Attribute in SDP", RFC 3605, October 2003. [8] D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", Internet Draft draft-ietf- mboned-ssm232-08.txt, Work in Progress, March 2004. [9] H. Holbrook, B. Cain, B. Haberman, "Using IGMPv3 For Source- Specific Multicast", Internet Draft draft-holbrook-idmr-igmpv3- ssm-08.txt, Work in Progress, October 2004. [10] S. Casner, "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. [11] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. 14.2 Informative References [12] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, "MIKEY: Multimedia Internet Keying", RFC 3830, August 2004. [13] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [14] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [15] J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, " Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", Internet Draft draft-ietf-ietf-avt-rtcp-feedback-11.txt, August 2004. [16] Pusateri, T, "Distance Vector Multicast Routing Protocol", Internet Draft draft-ietf-idmr-dvmrp-v3-11.txt, Work in Progress, October 2003. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 38] RTCP with Unicast Feedback [17] 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-11.txt, Work in Progress, October 2004. [18] Adams, A, Nicholas, J, Siadak, W, "Protocol Independent Multicast- Dense Mode (PIM-DM)", RFC 3973, January 2005. [19] Bates, T, Rekhter, Y, Chandra, R, Katz, D, "Multiprotocol Extension fo BGP-4", RFC 2858, June 2000. [20] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol (MSDP)", Experimental RFC 3618, October 2003. [21] 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/. [22] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol (SAP)", RFC 2974, October 2000. [23] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group Domain of Interpretation", RFC 3547, July 2003. [24] A. Perrig, D. Song, R. Canetti, D. Tygar, B. Briscoe, "TELSA: Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. [25] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. [26] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting Extensions", RFC 3611, November 2003. [27] F. Andreasen, M. Baugher, and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", Internet Draft draft-ietf-mmusic-sdescriptions-12.txt, September 2005. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 39] RTCP with Unicast Feedback 15. Appendix A: Examples for Sender Side Configurations This appendix describes a few common setups focusing on the contribution side, i.e., the communications between the Media Source(s) and the Distribution Source. In all cases, the same session description may be used for the distribution side as defined in the main part of this document. This is because this specification defines only the media stream setup between the Distribution Source and the receivers. 15.1 One Media Sender identical to the Distribution Source In the simplest case, the Distribution Source is identical to the Media Source as depicted in figure 2. Obviously, no further configuration for the interaction between the Media Sender and the Distribution Source is necessary. Source-specific +--------+ Multicast | | +----------------> R(1) |M D S | | | |E I O | +--+ | |D S U | | | | |I T R | | +-----------> R(2) | |A R C |->+----- : | | | = I E | | +------> R(n-1) | | |S B | | | | | | |E U | +--+--> Rn | | | |N T | | | | | |D I |<---------+ | | | |E O |<---------------+ | | |R N |<--------------------+ | | |<-------------------------+ +--------+ Unicast Figure 2: Media Source == Distribution Source 15.2 One Media Sender In a slightly more complex scenario, the Media Sender and the Distribution Source are separate entities running on the same or different machines. Hence, the Media Sender needs to deliver the media stream(s) to the Distribution Source. This can be done either via unicasting the RTP stream or via ASM multicast. In this case, the Distribution Source is responsible for forwarding the RTP packets comprising the media stream and the RTCP sender reports towards the receivers and conveying feedback from the receivers as well as from itself to the Media Sender. This scenario is depicted in figure 3. The communication setup between the Media Sender and the Distribution Source may be statically configured or SDP may be used in conjunction with some signaling protocol to convey the session parameters. Note that it Chesterfield, et al. Internet Draft - Expires April 2006 [Page 40] RTCP with Unicast Feedback is a configuration/local matter of the Distribution Source how to associate a contribution media session between the Media Sender and itself with the corresponding distribution media session between itself and the receivers. Source-specific +-----+ Multicast | | +----------------> R(1) | D S | | | | I O | +--+ | | S U | | | | +--------+ | T R | | +-----------> R(2) | | Media |<---->| R C |->+----- : | | | Sender | | I E | | +------> R(n-1) | | +--------+ | B | | | | | | | U | +--+--> Rn | | | | T | | | | | | I |<---------+ | | | | O |<---------------+ | | | N |<--------------------+ | | |<-------------------------+ +-----+ Unicast Contribution Distribution Session Session (unicast, ASM) (SSM) Figure 3: One Media Sender Separate from Distribution Source 15.3 Three Media Senders, Unicast Contribution Similar considerations apply if three media senders transmit to an SSM multicast group via the Distribution Source and individually sent their media stream RTP packets via a unicast to the Distribution Source. In this case, the responsibilities of the Distribution Source are a superset to the previous case: it also needs to perform relaying media traffic from each Media Sender to the receivers and forwarding (aggregated) feedback from the receivers to the Media Senders. In addition, the Distribution Source relays RTCP packets (SRs) from each Media Sender to the other two. The configuration of the Media Senders is identical to the previous case. It is just the Distribution Source that must be aware that there are multiple senders and then perform the necessary relaying. The transport address for the RTP session at the Distribution Source may be identical for all Media Senders (which may make correlation easier) or different addresses may be used. This setup is depicted in figure 4. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 41] RTCP with Unicast Feedback Source-specific +-----+ Multicast +--------+ | | +----------------> R(1) | Media |<---->| D S | | | |Sender 1| | I O | +--+ | +--------+ | S U | | | | | T R | | +-----------> R(2) | +--------+ | R C |->+----- : | | | Media |<---->| I E | | +------> R(n-1) | | |Sender 2| | B | | | | | | +--------+ | U | +--+--> Rn | | | | T | | | | | +--------+ | I |<---------+ | | | | Media |<---->| O |<---------------+ | | |Sender 3| | N |<--------------------+ | +--------+ | |<-------------------------+ +-----+ Unicast Contribution Distribution Session Session (unicast) (SSM) Figure 4: Three Media Senders, unicast contribution 15.4 Three Media Senders, ASM Contribution Group In this final example, the individual unicast contribution sessions between the Media Senders and the Distribution Source are replaced by a single ASM contribution group (i.e., a single common RTP session). Consequently, all Media Senders receive each other's traffic by means of IP layer multicast and the Distribution Source no longer needs to perform explicit forwarding between the Media Senders. Of course, the Distribution Source still forwards feedback information received from the receivers (optionally as summaries) to the ASM contribution group. The ASM contribution group may be statically configured or the necessary information can be communicated using a standard SDP session description for a multicast session. Again, it is up to the implementation of the Distribution Source to properly associate the ASM contribution session and the SSM distribution sessions. Figure 5 shows this scenario. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 42] RTCP with Unicast Feedback _ Source-specific / \ +-----+ Multicast +--------+ | | | | +----------------> R(1) | Media |<->| A | | D S | | | |Sender 1| | S | | I O | +--+ | +--------+ | M | | S U | | | | | | | T R | | +-----------> R(2) | +--------+ | G | | R C |->+----- : | | | Media |<->| r |<->| I E | | +------> R(n-1) | | |Sender 2| | o | | B | | | | | | +--------+ | u | | U | +--+--> Rn | | | | p | | T | | | | | +--------+ | | | I |<---------+ | | | | Media |<->| | | O |<---------------+ | | |Sender 3| \_/ | N |<--------------------+ | +--------+ | |<-------------------------+ +-----+ Unicast Contribution Distribution Session Session (ASM) (SSM) Figure 5: Three Media Sender in ASM Group Chesterfield, et al. Internet Draft - Expires April 2006 [Page 43] RTCP with Unicast Feedback 16. Appendix B: Distribution Report processing at the receiver 16.1 Algorithm Example processing of Loss Distribution Values X values represent the loss percentage. Y values represent the number of receivers. Number of x values is the NDB value xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV) First data point = MnDV,first ydata then Foreach ydata => xdata += (MnDV + (xrange / NDB)) 16.2 Pseudo-code Packet Variables -> factor,NDB,MnDVL,MaDV Code variables -> xrange, ydata[NDB],x,y xrange = MaDV - MnDV x = MnDV; for(i=0;i 20 Bytes) Minimum Data Value: 0 Chesterfield, et al. Internet Draft - Expires April 2006 [Page 46] RTCP with Unicast Feedback Maximum Data Value: 39 Data Bucket values: (each value is 16-bits) Results, 4-bit buckets: X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10 (Y - 1803 | 4403 | 5970 | 853 ) ACTUAL Y - 4 | 9 | 12 | 2 X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20 (Y - 110 | 140 | 89.5 | 12.5) ACTUAL Y - 0 | 0 | 0 | 0 X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 20 (Y - 447 | 3897 | 609.5 | 506.5) ACTUAL Y - 1 | 8 | 1 | 1 X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40 (Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL Y - 1 | 0 | 0 | 0 Example - 2nd 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 sub-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: 0 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. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 47] RTCP with Unicast Feedback Result 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. 18. Acknowledgements The authors would like to thank Magnus Westerlund for detailed reviews and valuable comments. 19. Authors' Addresses Julian Chesterfield University of Cambridge Computer Laboratory, JJ Thompson Avenue, Cambridge, CB3 0FD, UK Julian.chesterfield@cl.cam.ac.uk Joerg Ott Tellitec Engineering GmbH Berliner Str. 26 D-13507 Berlin GERMANY jo@acm.org Eve Schooler Intel CTL / Research 2200 Mission College Blvd., SC12-303 Santa Clara, CA, USA 95054-1537 eve_(underscore) schooler (at) acm.org 18. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use Chesterfield, et al. Internet Draft - Expires April 2006 [Page 48] RTCP with Unicast Feedback of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 20. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chesterfield, et al. Internet Draft - Expires April 2006 [Page 49]