J. Chesterfield University of Cambridge J. Ott Internet Draft Tellitec GmbH Document: draft-ietf-avt-rtcpssm-07 E. Schooler AT&T Labs - Research Expires: January 2005 19 July 2004 RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback Status of this Memo By submitting this Internet-Draft, each author certifies that any applicable patent or other IPR claims of which the author is aware have been disclosed, or will be disclosed, and any of which each author becomes aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-draft, the authors accept the provisions of Section 3 of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (date). All Rights Reserved. Abstract This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarised reporting mechanism. Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 1] RTCP with Unicast Feedback Table of Contents 1. Conventions and Acronyms........................................2 2. Introduction....................................................2 3. Basic Operation.................................................4 4. Definitions.....................................................5 5. Packet types....................................................6 6. Simple feedback model...........................................6 7. Sender feedback summary model...................................8 8. Mixer/Translator issues........................................20 9. Transmission interval calculation..............................21 10. SDP Extensions................................................23 11. Security Considerations.......................................23 12. Backwards Compatibility.......................................30 13. IANA Considerations...........................................30 14. Bibliography..................................................32 15. Appendix: Distribution Report processing at the receiver......34 16. AUTHORS ADDRESSES.............................................39 17. IPR Notice....................................................39 18. FULL COPYRIGHT STATEMENT......................................40 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 single administrative domain, e.g., DVMRP [15], PIM [16][17]) are used in combination with an Inter-domain routing protocol (those Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 2] RTCP with Unicast Feedback that operate across administrative domain borders, e.g., MBGP [18], MSDP [19]). Such routing protocols enable a host to join a single multicast group address and to send to or to receive data from all members in the group with no prior knowledge of the membership. There is a great deal of complexity involved, however 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 to 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 draft, 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. 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 Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 3] RTCP with Unicast Feedback 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 draft proposes two new methods to enable unicast receiver feedback. Each involves the unicasting of RTCP packets to a source whose job it is to re-distribute the information to the members of the group. The source must be able to communicate with all group members in order for either mechanism to work. The first method, the 'Simple Feedback Model', is a basic reflection mechanism whereby all Receiver RTCP packets are unicast to the source and subsequently forwarded by the source to all receivers on the multicast RTCP channel. The advantage of using this method is that an existing receiver implementation requires little modification in order to use it. Instead of sending reports to a multicast address, a receiver uses a unicast address to send reports to the source, yet still receives forwarded RTCP traffic on the multicast control data channel. This method also has the advantage of being backwards compatible with standard RTP/RTCP implementations. The second method, the 'Sender Feedback Summary Model', is a summarised reporting scheme that provides savings in bandwidth by consolidating Receiver Reports at the source into one summary packet that is then distributed to all the receivers. The advantage of this scheme is apparent for large group sessions where the basic reflection mechanism outlined above generates a large amount of packet forwarding when it replicates all the 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 source. In the second scheme, however the source distributes summaries of the feedback over the multicast channel. Thus this technique requires that all session members understand the new summarised packet format outlined in Section 7.1. Additionally, the summarised scheme provides an optional mechanism to send distribution information or histograms about the feedback data reported by the whole group. Potential uses for the compilation of distribution information are addressed in Section 7.4. To differentiate between the two reporting methods, a new SDP identifier is created and discussed in Section 10. The reporting method MUST be decided prior to the start of the session. A distribution source MUST NOT change the method during a session. In a session using SSM, the network SHOULD prevent any multicast data from the receiver being distributed further than the first hop Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 4] RTCP with Unicast Feedback router. Additionally, any data heard from a non-unicast capable receiver by other hosts on the same subnet SHOULD be filtered out by the host IP stack and therefore will not cause problems with respect to the calculation of the Receiver RTCP bandwidth share. 4. Definitions Distribution Source: In an SSM context, only one source distributes RTP data and redistributes RTCP information to all receivers. That source is called the distribution source. In order for unicast feedback to work, there MUST be only one session distribution source for any subset of receivers to which RTCP feedback is directed. Note that heterogeneous networks comprised of ASM multiple- sender groups, unicast-only clients and/or SSM single-sender receiver groups MAY be connected via translators or mixers to create a single-source group (see Section 9 for details). RTP and RTCP Channels: The data distributed from the source to the receivers is referred to as the RTP channel and the control information the RTCP channel. With standard RTP/RTCP, these channels typically share the same multicast address but are differentiated via port numbers as specified in [1]. 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 summarised 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. Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 5] RTCP with Unicast Feedback 5. Packet types The RTCP packet types defined in [1], [6], and [10] are: Type Description Payload number ------------------------------------------------------- SR Sender Report 200 RR Receiver Report 201 SDES Source Description 202 BYE Goodbye 203 APP Application-Defined 204 RTPFB Generic RTP feedback 205 PSFB Payload-specific feedback 206 XR RTCP Extension 207 This document defines one further RTCP packet format: Type Description Payload number --------------------------------------------------------- RSI Receiver Summary Information 208 Within the Receiver Summary Information packet 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 Stats General statistics 10 Receiver BW RTCP Receiver Bandwidth 11 - - 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 source. The distribution source still must create Sender Reports Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 6] RTCP with Unicast Feedback that include timestamp information for stream synchronisation and round trip time calculation. Both senders and receivers are required to send SDES packets as outlined in [1]. The rules for generating BYE and APP packets as outlined in [1] also apply. 6.2 Distribution Source behaviour For the simple feedback model, the source MUST provide a basic packet reflection mechanism. It is the default behaviour for any distribution source and is the minimum requirement for acting as a source to a group of receivers using unicast RTCP feedback. In this model, the source MUST not stack report blocks received from different SSRCs into one packet for retransmission to the group. Every RTCP packet from each receiver MUST be reflected individually. The source (the unicast feedback target) MUST listen for unicast RTCP data sent to the RTCP port. All unicast data received on this port MUST be forwarded by the source to the group on the multicast RTCP channel. If the application can determine that the destination address of an RTCP packet is not a unicast address, the packet MUST NOT be forwarded but processed as defined in [1]. The reflected traffic SHOULD NOT be included in the transmission interval calculation by the source. In other words, the source SHOULD NOT consider reflected packets as part of its own control data bandwidth allowance. However, they MUST be processed by the source and the average RTCP packet size, RTCP transmission rate, and RTCP statistics must be calculated. The algorithm for computing the allowance is explained in Section 9. If an application wishes to use APP packets, it is recommended that the simple feedback model be used since it is likely that all receivers in the session will need to hear the APP-specific packets. The same applies for all other RTCP packets that are not defined in the base RTP specification [1]. The decision to use the simple feedback model MUST be made in advance of the session and MUST be indicated in the SDP announcement [5]. 6.3 Receiver behaviour Receivers listen on the RTP channel for data and the RTCP channel for control. Each receiver calculates its share of the control bandwidth 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 sends a unicast Receiver Report packet to the RTCP port of the distribution source. Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 7] RTCP with Unicast Feedback 7. Sender feedback summary model In the sender feedback summary model, the Distribution Source is required to summarise the information received from all the Receiver Reports generated by the receivers and place the information into summary reports. The sender feedback summary model introduces a new report block format and a number of optional sub-report block formats. The Receiver Summary Information report (RSI) is required and MUST be sent by a source if the summarised feedback mechanism is selected. Transmission of sub-report types is OPTIONAL. They MAY be appended to the RSI report block to provide more detailed information on the overall session characteristics reported by all receivers and also to convey important information such as the feedback address and reporting bandwidth. From an RTP perspective, the Distribution Source acts like an RTP receiver but it 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. Any summarization data MUST be appended to a Receiver Report (RR) packet generated by the distribution source and forwarded to the receiver group. If the distribution source is actually an RTP sender, even if it is the only session sender, it MUST also generate Sender Report (SR) packets. The Distribution Source MUST use an SSRC value for transmitting summarization information and MUST perform proper SSRC collision detection and resolution. Editor's note: Here, we can also optimize for the 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 appears to be much cleaner; but this comes at the cost of some extra bit rate. The Distribution Source MUST send at least one Receiver Summary Information packet for each reporting interval. The distribution source can additionally stack sub-report blocks after the RSI packet. Each sub-report block corresponds to the initial RSI packet and acts as an enhancement to the basic summary information required by the receivers to calculate their reporting time interval. For this reason, additional sub-report blocks are not required but recommended. RSI and the corresponding sub-report blocks are sent in addition to the standard receiver-issued packets, such as Receiver Reports and SDES packets outlined in [1]. 7.1 Packet Formats 7.1.1 RSI: Receiver Summary Information Packet Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 8] RTCP with Unicast Feedback 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 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 0h UTC on 1 January 1900, when this report was sent. This value is used to enable detection of duplicate packets, reordering and to provide a chronological profile of the feedback reports. Group size: 32 bits This field provides the sender's view of the number of receivers in a session. This MUST include the sender itself and any other senders potentially connected to the session, e.g., via a mixer/translator gateway. The group size is calculated according to the rules outlined in [1]. The group size field MAY be left empty (indicated by a value of 0); if so, the RTCP Bandwidth report block MUST be present to indicate the per-receiver RTCP bandwidth. 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 Jan 2005 [Page 9] 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 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 the bucket can be calculated using the formula ((length * 4) - 12)*8/NDB number of bits. The calculation is based upon 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 Jan 2005 [Page 10] 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 MF+1 indicates the multiplicative factor to be applied to each distribution bucket value. Possible values are 0 - 15, indicating multiplicative factors of 1 - 16. 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: [ min+(max-min)/NDB*x ; min+(max-min)/NDB*(x+1) ] 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 Jan 2005 [Page 11] 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 summarised loss report sub-blocks, see the Appendix. 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 interarrival time reported by the receivers to the distribution source. This allows receivers both to place their own observed jitter values in context with the rest of the group, and to approximate dynamic parameters for playout buffers. See [1] for details on how the values are calculated and the relevance of the jitter results. Jitter values are measured in timestamp units and expressed as unsigned integers. The minimum distribution value must alw