David Leon Internet Draft Viktor Varsa Document: draft-leon-rtp-retransmission-01.txt Nokia Expires: April 2002 November 2001 RTP retransmission framework 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 RTP retransmission is an effective packet loss recovery scheme for real-time applications with relaxed delay bounds. This document describes an RTP retransmission framework. It defines a payload format for retransmitted packets and recommends rules for sending these packets. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders indicating the occurred packet losses is available by some means not defined here. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Leon, Varsa IETF draft - Expires April 2002 1 RTP retransmission framework November 2001 Table of Contents Abstract...........................................................1 Terminology........................................................1 1. Introduction....................................................2 2. Retransmission payload format...................................2 3. Use with extended RTP profile for RTCP feedback.................4 4. Congestion control and scheme efficiency........................5 5. Example scenario................................................6 6. SDP usage.......................................................6 7. Security consideration..........................................6 8. References......................................................7 Author's Addresses.................................................7 1. Introduction RTP packet loss between a source and a receiver may significantly degrade the quality of the received signal. Several techniques, such as forward error correction (FEC), retransmissions or adaptation of application layer (e.g. video) error resilience techniques based on back-channel messages may be considered to increase the robustness to packet loss. RFC-2354 [2] discusses the different options. When choosing a technique for a particular system, the tolerable latency of the application has to be taken into account. In the case of multimedia conferencing, the end-to-end delay has to be at most a few hundred milliseconds in order to guarantee interactivity, which usually excludes the use of retransmission. On the other hand, in the case of streaming, latency is perceived by the user as part of the session setup delay and thus a latency of several seconds is tolerable. Retransmission may thus be considered for such applications. This document proposes a retransmission framework. It defines a payload format for retransmitted RTP streams and retransmission rules. This RTP retransmission scheme requires frequent enough RTCP feedback as well as packet request feedback messages. The AV profile [3] does not provide these features and could therefore not be used. However, the retransmission scheme could be run under the extended RTP profile for RTCP-based feedback[4]. 2. Retransmission payload format In this document, an original packet refers to any media packet sent by an RTP source. A retransmission packet is an RTP packet which includes the original payload and is sent on a request of a receiver. Retransmission packets MUST be sent to a different RTP session (as defined in RTP [5]) from that of the original RTP media. The Leon, Varsa - Expires December 2001 2 RTP retransmission framework November 2001 original and retransmission streams must therefore be sent to different multicast group/unicast addresses and/or port numbers. The payload format of a retransmission packet (RTX packet) is as shown below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| OPT | OSN | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Original RTP Packet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP header usage: The same SSRC value SHOULD be used for the original stream and the retransmission stream. In the RTP header, the sequence number has the standard definition, i.e. it MUST be one higher than the sequence number in the previously retransmitted packet. All other fields of the RTP header have the same value as in the original RTP packet. The retransmitted packet payload carries an E bit, a OPT field (7 bits) and an OSN field (2 bytes) followed by the original RTP payload data. The E bit is an extension bit for future-proofing. It MUST be set to zero. The OPT and OSN field are respectively the payload type and sequence number of the original RTP packet that is being retransmitted. There are several advantages when using a separate RTP session for the retransmission stream as described below. *There are no modifications to the payload format of the original packets. Retransmission can thus work with any existing payload format. *When the RTX stream is sent to a multicast session, receivers may choose to subscribe to the retransmission session or not. Therefore, a multicast streaming session may be joined by receivers which may or may not implement the retransmission payload format. *In particular, the original RTP session may be multicast while there may be separate unicast retransmission sessions to each participant. Each sender will then receive retransmissions only for packets it has himself requested. *Mixers/translators may ignore the retransmitted packets. *As a consequence of having separate sessions for original and retransmission traffic, there are also separate RTCP streams and statistics for these two sessions. There is thus no corruption of Leon, Varsa - Expires December 2001 3 RTP retransmission framework November 2001 the original data RTCP statistics. The RTP sender is able to know the packet loss and jitter of the original stream. It can thus estimate what the quality of the received signal would be without the use of retransmission. 3. Use with extended RTP profile for RTCP feedback When the extended RTP profile is used, it is RECOMMENDED that receivers send retransmission requests according to the rules in the present section. The rules described hereafter aim at minimizing the bandwidth required for RTCP and are compliant to the more general rules described in the profile itself. The minimum RTCP report interval is computed according to the allowed RTCP bandwidth of a given session (obtained explicitly or calculated as a percentage of the RTP session bandwidth). The NACK message format defined in the profile is used. Early feedback packets SHOULD NOT be used, and the NACK message SHOULD always be appended to a regularly scheduled compound RTCP packet that is sent at every RTCP report interval T_rr. A receiver should compute an estimate of the delay D to receive a retransmission packet after a request has been sent. This estimate may be obtained from past observations, RTCP report round-trip time if available or any other means. The playout buffer delay B at the receiver needs to be higher than the RTCP reporting interval added to the delay estimate, i.e. B>T_rr+D It can be seen that the needed buffering delay is dependent on the amount of RTCP traffic allowed in the session. It is illustrated in Section 5 that moderate RTCP feedback traffic is enough to perform retransmission with reasonable playout buffering delay at the receiver. A receiver needs to maintain a list of missing packet sequence numbers since it last sent RTCP packet. If the retransmission stream is sent to a multicast session, the receiver SHOULD listen to retransmission requests from other receivers. If a request for one of the missing packets has been sent by another receiver, the receiver SHOULD remove the stored sequence number. Also, the receiver should upon a retransmission reception remove the corresponding request from the list of missing SNs. A receiver needs also to store for each missing packet an estimated RTP timestamp. The estimate can be calculated using the TS of consecutive packets to the missing packet. At the next scheduled RTCP packet time, the receiver estimates based on the estimated RTP timestamp of the missing packet if its retransmission could be received before its playout time. If not, it removes the packet from its list of missing packets (it might also choose to adapt its Leon, Varsa - Expires December 2001 4 RTP retransmission framework November 2001 playout delay). The receiver then adds the request for the missing packets to the scheduled RTCP compound packet using the PID and BLP fields of the NACK packet format. If needed, there should be multiple PID and BLP fields in the sent packets. Since the RTCP packet is a regularly scheduled packet, the E bit should not be set. The same retransmission request may be resent by the receiver if the requested packet was not received after its estimated retransmission reception time. This increases robustness to the loss of retransmission request or of a retransmission packet. The next retransmission request may be sent at the earliest at the next RTCP report scheduled time. Any other rules to send feedback MAY be used as long as they are compliant with the profile in use. In particular, a receiver MAY send NACK packets as early feedback packets. However, in that case the time when the next RTCP packet following this early RTCP packet can be sent may be too late to report a loss occurring right after the early RTCP packet was sent. Sending RTCP packets at regular intervals guarantees that the delay between detecting a packet loss and being able to send a request for that packet is no longer than the regular RTCP interval. In addition, if packet loss is caused by congestion, it is better to retransmit the packet at a latter point of time to increase the probability that the retransmission succeeds since network conditions may have improved by then. Since the original RTP stream and the retransmission stream are sent into separate RTP sessions, there needs to be two different RTCP streams as well. The amount of RTCP sent for the retransmission stream is computed as a fraction of the retransmission session bandwidth. Since, the retransmission traffic should be limited, the overhead caused by the retransmission session should be moderate. For example, assuming a 64 kbps original RTP session and on average 3% packet loss and all lost packets retransmitted once, the bandwidth of the retransmission session would be about 2 kbps. In this case the recommended RTCP traffic for the retransmission session would be 0.1 kbps. Extended or early feedback messages SHOULD NOT be used in the retransmission session. 4. Congestion control and scheme efficiency Use of retransmission should not increase the packet loss in the original stream. The client should monitor the RTCP statistics of the original stream and check that they do not deteriorate with the use of retransmission. RTP with retransmissions should be fair to RTP without retransmissions and TCP. An RTP sender using retransmission must follow the congestion control rules of its RTP profile. Leon, Varsa - Expires December 2001 5 RTP retransmission framework November 2001 The sender SHOULD retransmit only the packets that it deems important and ignore retransmission requests for other packets in order to limit the sent bitrate. It should further reduce its packet rate and bitrate (by encoding the data at a lower rate) in a best- effort network to avoid congestion. The scheme should be applied to moderate packet loss. The maximum tolerable packet loss rate depends on the application but probably not more than 5 to 10% at a maximum. Higher packet loss would mean that the level of congestion is too high on a best-effort network. 5. Example scenario Unicast video streaming to a mobile client In this scenario, packet loss is caused by bit errors over the radio interface. Let us assume that the packet loss is 6%, the receiver playout buffering is 3 seconds, the round trip time 500 ms. A 2- second RTCP interval would thus allow the receiver to perform one retransmission attempt. Let us assume a packet rate of 50 packets per second. The average loss rate is thus 3 packets per second. The maximum overhead of a NACK report packet to request 3 packet losses is a NACK packet of length 24 bytes (length field in fixed header is set to 5) which carries three PIDs and three BLPs. Compound RTCP packets sent by the mobile may be as follows: IPv4 (20), UDP (8), RR(header 8 + report 24), CNAME(12), NACK (24). The total size would thus be 96 bytes. The needed uplink RTCP overhead would then be 0,384 kbps. Let us assume that the RTP session bandwidth is 64 kbps, the recommended RTCP bandwidth is 2.5% of this, that is 1.6 kbps. Therefore, the feedback can be easily accommodated with the RTCP recommended bandwidth. 6. SDP usage The binding to the payload type number is indicated by an rtpmap attribute. The name used in the binding is "RTX". An example SDP description is shown below. c=IN IP4 113.3.12.11 m=video 49170 RTP/AVPF 96 a=rtpmap:96 H263-1998/90000 a=fmtp:96 rtcp-fb nack m=video 49172 RTP/AVPF 97 a=rtpmap:97 RTX/90000 Leon, Varsa - Expires December 2001 6 RTP retransmission framework November 2001 7. Security consideration The security considerations of the profile under which the retransmission scheme is used should be applied. 8. References 1 RFC 2119 S Bradner ., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Perkins, C., Hodson, O., "Options for Repair of Streaming Media", RFC 2354, June 1998. 3 Schulzrinne, H and Casner, S. " RTP Profile for Audio and VideoConferences with Minimal Control," Internet Draft draft- ietf-avt-profile-new-09.txt, July 2000. 4 J Ott, S Wenger, S Fukunaga, N Sato, K Yano, M Akihiro, H Koichi, R Hakenberg, C. Burmeister "Extended RTP profile for RTCP-based feedback" 5 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", Internet Draft draft-ietf-avt-rtp-new-08.txt, July 2000. Author's Addresses David Leon Nokia Research Center 6000 Connection Drive Phone: 1-972-374-1860 Irving, TX. USA Email: david.leon@nokia.com Viktor Varsa Nokia Research Center 6000 Connection Drive Phone: 1-972-374-1861 Irving, TX. USA Email: viktor.varsa@nokia.com Leon, Varsa - Expires December 2001 7