Internet Engineering Task Force Koichi Yano Internet Draft Matthew Podolsky draft-podolsky-avt-rtprx-01.txt Steven McCanne March 10, 2000 Expires: September 10, 2000 RTP Profile for RTCP-based Retransmission Request for Unicast session. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a new RTP profile for retransmission of lost packets of unicast multimedia sessions. We refer to this profile as "RTP/RX". This profile follows RFC 1889 as it is for data exchange. Specifically for unicast session, it changes the RTCP interval and defines a new RTCP packet type for retransmission requests. This document also describes how retransmission requests and retransmission data may be sent within RTP. 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 [2]. Yano, Podolsky, McCanne [Page 1] Internet Draft RTCP-based Retransmission March, 2000 2. Introduction RTP was designed as a flexible protocol capable of transporting real- time data over multicast or unicast. It has been widely deployed and used extensively for transmitting real-time (or "near" real-time) multimedia signals, commonly called media streams. And although considerable effort went into the design of RTP so that it could support multi-party interactive conferencing over multicast, a common use of it today is for one-way non-interactive transmission of media streams. Because the communication is non-interactive, extra playback buffering and delay may be tolerable, which in turn enables receivers to request and receive retransmissions of lost RTP packets before their scheduled play-out times. For example, popular commercial products like RealNetworks' G2 Player and Microsoft's NetShow use RTP as the underlying transport protocol for their media streams, and use retransmissions in unicast delivery sessions. However, as noted in [4], no standard exists for requesting the retransmission of streaming media. As a result, various independent and incompatible research and commercial schemes have been developed for retransmission of RTP streams [3, 5]. This purpose of this note is to define a standard retransmission request framework for use with unicast RTP streams. 3. RTCP Packet Forms and Protocol Behavior The section "RTP Profiles and Payload Format Specification" of RFC 1889 enumerates a number of items that can be specified or modified in a profile. This profile, RTP/RX, follows all of the default and/or recommended aspects of the Audio and Video Profile, RTP/AVP[6], except for the items which are described below. This section addresses the items which are modified by this profile. RTCP packet types: A new RTCP packet types, RTCP_NACK, is defined for requesting a retransmission. The packet format is specified in section 4.2. RTCP report interval: In order to allow immediate RTCP response to packet loss, the RTCP report interval restriction in RFC 1889 should be relaxed. However, in order to prevent RTCP packets from flooding the network, the bandwidth constraint of RFC 1889 should be preserved. Recommendations about the RTCP transmission frequency are specified in section 4.1. Yano, Podolsky, McCanne [Page 2] Internet Draft RTCP-based Retransmission March, 2000 4. Control packets for unicast session This note proposes extending the RTCP specification to accommodate retransmission requests. RTCP is a reasonable place for putting control packets into because it is a well-established control protocol and no extra connections need to be established. However, the RTCP interval specified in [1] is too large for timely retransmission requests. Thus, the current RTCP minimum transmission interval should be relaxed. 4.1. RTCP Transmission Bandwidth The RTCP transmission interval specified in [1] is not frequent enough to allow efficient control of a unicast session needing to request retransmissions of lost packets. RFC 1889 recommends a minimum interval of 5 seconds between control packets. In order to make RTCP applicable for unicast retransmission, a packet-granularity RTCP interval is necessary. The minimum interval restriction SHOULD be removed for unicast RTP sessions so that retransmission requests are allowed to be sent immediately after loss detection. In order to prevent RTCP packets from causing network congestion, it is RECOMMENDED that the average bandwidth allocated to RTCP be fixed at 5% of the overall session bandwidth. The recommended default values are 1/4 of the RTCP bandwidth (1.25%) for the data sender and the remainder of the bandwidth (3.75%) for the receiver, following the conventions of RFC 1889. If the size of RTP payload packets is 1 KBytes and the size of RTCP packets is 40 bytes, the 3.75% limitation is large enough for a receiver to send an RTCP packet at every other data packet interval. The interval is frequent enough to allow timely retransmission requests. The original RTCP packets (SR/RR) also SHOULD be sent based on RFC 1889. In order to regulate the sending rate of RTCP packets within the RTCP bandwidth, the deployment of a traffic shaping scheme such as a token backet is RECOMMENDED. The token rate should be set at (rtcp_bw / rtcp_size), where rtcp_bw is the RTCP bandwidth and rtcp_size is the size of RTCP packets. The bucket size should be determined according to the playback buffer size. As long as a token is in the bucket, the RTCP packet is sent immediately, and the long- term RTCP rate is regulated within the RTCP bandwidth limit. Yano, Podolsky, McCanne [Page 3] Internet Draft RTCP-based Retransmission March, 2000 4.2. Packet format for requesting retransmission This section defines a packet format for a negative acknowledgment (NACK) packet, which is sent from the receiver to the sender and which asks for the retransmission of one or more RTP packets. The format of NACK packets is as follows: 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| RC | PT=RTCP_NACK | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FSN | BLP | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FSN | BLP | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | The various fields V, P, RC, SSRC and length are defined in the RTP specification [1]. The FSN and BLP fields have similar definitions to those given for the RTCP_NACK packet specified in [3]. We summarize the meaning of all of the fields below: version (V): 2 bits This field identifies the RTP version. The current version is 2. padding (P): 1 bit If set, the padding bit indicates that the RTCP NACK packet contains additional padding octets at the end which are not part of the retransmission control information but are included in the length field. report count (RC): 5 bits The number of NACK blocks for different SSRC. packet type (PT): 8 bits This is the RTCP packet type which identifies the packet as being an RTCP NACK. length: 16 bits The length of this RTCP NACK packet in 32-bit words minus one, including the header and any padding. This conforms with the Yano, Podolsky, McCanne [Page 4] Internet Draft RTCP-based Retransmission March, 2000 definition of the length field used in RTCP sender and receiver reports [1]. SSRC: 16 bits The synchronization source identifier for the originator of this NACK packet. SSRC_n: 16 bits The SSRC identifier of the source to which the information in this NACK report block pertains. first sequence number (FSN): 16 bits The FSN corresponds to an RTP sequence number of a media stream. A NACK packet with a FSN field set to N is to be interpreted as a signal that the receiver has not received RTP data packet N, and that the receiver is requesting the retransmission of packet N. bitmask of following lost packets (BLP): 16 bits The BLP allows for the reporting of losses of the 16 RTP packets immediately following the RTP packet indicated by the FSN. The BLP's definition is identical to that given in [3]. Denoting the BLP's least significant bit as bit 1, and its most significant bit as bit 16, then bit i of the bitmask is set to 1 if the sender has not received RTP packet number FSN+i (modulo 2^16) and the receiver is requesting its retransmission; bit i is set to 0 otherwise. Note that the sender MUST NOT assume that a receiver has received a packet because its bitmask was set to 0. For example, the BLP is set to 0x00001 if the packet corresponding to the FSN and the following packet have been lost. However, the sender cannot infer that packets FSN+2 through FSN+16 have been received simply because bits 2 through 16 of the BLP are 0; all the sender knows is that their retransmission has not been requested. Note that the receiver may detect RTP packet loss via sequence number gaps, timer expirations, or other methods; however, details of the loss detection scheme are outside of the scope of this document. 5. Examples 5.1 A simple retransmission request system The simplest way to realize loss recovery using retransmission is that the receiver decides whether a NACK packet should be sent or not and the sender replies all retransmission requests. The receiver sends NACKs when it determines that one or more data packets have been lost and that their playback time has not yet passed. Yano, Podolsky, McCanne [Page 5] Internet Draft RTCP-based Retransmission March, 2000 This scheme can be realized without an extra control packet between the sender and the receiver. However it could results in many late packets that arrive after play out time because it does not consider transmission delay. 5.2. Receiver-based decisions on requesting retransmissions Before making a retransmission request at time Tr of packet N (scheduled for play-out at time Tp[N]), the receiver checks if Tr + eRTT < Tp[N] where eRTT is an estimate of the round trip time (RTT). If true the receiver assumes the retransmission will arrive in time, and it sends the request for packet N. If false the receiver does not send a retransmission request. The above check can be made more general to account for receiver decoding delays and the sender's request response time. RTT can be measured elapsed time between each NACK and the retransmission packet. eRTT is calculated from the RTT measurements through Karn's algorithm[7]. 5. References [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, January 1996. [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [3] Turletti, T. and Huitema, C., "RTP Payload Format for H.261 Video Streams," RFC 2032, October 1996. [4] Perkins, C. and Hodson, O., "Options for Repair of Streaming Media" RFC 2354, June 1998. [5] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar. Resilient multicast support for continuous media applications. In Proceedings of the 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV'97), Washington University in St. Louis, Missouri, May 1997. [6] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control," RFC 1890, January 1996. Yano, Podolsky, McCanne [Page 6] Internet Draft RTCP-based Retransmission March, 2000 [7] P. Karn and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocol." ACM Transactions on Computer Systems (TOCS), Vol. 9, No. 4, pp. 364-373, November 1991 AUTHORS' ADDRESSES Matthew Podolsky UC Berkeley Computer Science Dept. Phone: 510-642-8905 Email: podolsky@eecs.berkeley.edu URL: http://www.eecs.berkeley.edu/~podolsky Koichi Yano UC Berkeley Computer Science Dept. Phone: 510-642-9513 Email: yano@cs.berkeley.edu URL: http://www.cs.berkeley.edu/~yano Steven McCanne FastForward Networks Email: mccanne@cs.berkeley.edu This draft was created in March 10, 2000. It expires September 10, 2000. Yano, Podolsky, McCanne [Page 7]