Network Working Group C. Perkins Internet-Draft University of Glasgow Expires: July 14, 2004 January 14, 2004 RTP Retransmission Using Reactive FEC draft-perkins-avt-rtp-reactive-fec-00.txt 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. This Internet-Draft will expire on July 14, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo describes how the RTP Payload Format for Generic Forward Error Correction can be combined with the Extended RTP Profile for RTCP-based Feedback to provide a solution for retransmission of lost RTP packets. Such a retransmission format is expected to be useful to improve the reliability of real-time applications with relaxed delay bounds, for example non-interactive streaming audio/video. 1. Introduction The quality of real-time audio/video services on the Internet is often less than might be desired. In large part, this is due to packet loss. As discussed in [6], several techniques may be used to correct for the effects of packet loss. These include forward error Perkins Expires July 14, 2004 [Page 1] Internet-Draft SDP January 2004 correction (FEC) and retransmission. Several FEC solutions exist [5],[2] and can be used with RTP-based applications. This memo specifes a retransmission format that can be used with RTP. The use of retransmissions in RTP as a repair method for streaming media is appropriate in those scenarios with relaxed delay bounds and where full reliability is not a requirement. More specifically, RTP retransmission allows to trade-off reliability vs. delay, i.e. the endpoints may give up retransmitting a lost packet after a given buffering time has elapsed. Unlike TCP there is thus no head-of-line blocking caused by RTP retransmissions. The implementer should be aware that in cases where full reliability is required or higher delay and jitter can be tolerated, TCP or other transport options are more appropriate, and should be considered. 2. 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]. 3. Requirements The RTP retransmission scheme defined in this document is designed to fulfil the following set of requirements: 1. It MUST NOT break general RTP and RTCP mechanisms. 2. It MUST be suitable for unicast and small multicast groups. 3. It MUST work with RTP mixers and translators. 4. It MUST work with all known payload types. 5. It MUST NOT prevent the use of multiple payload types in a session. 6. In order to support the largest variety of payload formats, the receiver MUST be able to determine how many and which RTP packets were lost as a result of a gap in received RTP sequence numbers. 4. Requesting Retransmission In order to perform retransmission of RTP data packets it is necessary for a receiver to send a request to the sender, indicating the packets which should be retransmitted. The extended RTP profile for RTCP-based feedback, denoted RTP/AVPF, [4] allows receivers to Perkins Expires July 14, 2004 [Page 2] Internet-Draft SDP January 2004 request retransmission of lost packets using NACK messages. Such retransmission requests MAY be sent in both unicast and small group multicast sessions. Retransmission requests SHOULD be sent according to the timing rules defined in [4]. These rules may limit the number of packet loss events that can be repaired. The receivers SHOULD NOT send a retransmission request as soon as they detect a missing sequence number, but SHOULD instead add some extra delay to compensate for packet reordering. This extra delay may, for example, be based on past observations of the packet reordering. The receiver should generally assess whether the retransmitted packet would still be useful at the time it is received. The timestamp of the missing packet can be estimated from the timestamps of packets preceding and/or following the sequence number gap caused by the missing packet in the original stream. In most cases, some form of linear estimate of the timestamp is good enough. To increase the robustness to the loss of a NACK packet or of a retransmitted data packet, a receiver may send a new NACK for the same packet. This is referred to as multiple retransmissions. Before sending a new NACK for a missing packet, the receiver SHOULD rely on a timer to be reasonably sure that the previous retransmission attempt has failed in order to avoid unnecessary retransmissions. 5. Retransmission of RTP Packets Using Reactive FEC The RTP payload format defined in [2] allows a sender associate an RTP session containing parity FEC packets with a standard RTP session. The amount of FEC data generated may be varied according to the amount of packet loss observed, and there is no need to signal changes in the FEC pattern to receivers out-of-band (the information needed to decode the FEC is included within each packet). A sender using the FEC format defined in [2] MAY generate FEC packets continually, according to some pattern. This will allow receivers to repair a subset of packet losses without having to contact the sender. Alternatively a sender MAY generate FEC packets only when requested to do so by a receiver, for example on receipt of NACK packets sent using the RTP/AVPF profile. Generation of FEC packets on demand is termed Reactive FEC. When using reactive FEC to repair a single packet loss, the parity FEC packets MAY be generated with an "SN base" which is numerically close to that of the lost packet, and with a single bit of the "mask" field set (see Section 6.2 of [2]). Since only a single packet is selected, the protection operation becomes equal to a bit copy, and Perkins Expires July 14, 2004 [Page 3] Internet-Draft SDP January 2004 the FEC payload is thus equal to the original payload. A receiver of FEC packets generated in this manner can use them to repair the original media stream. The FEC packets are standalone, and do not require receipt of other packets in the stream to decode. Alternatively, if multiple retransmission requests are received, the sender MAY generate FEC packets using the parity operation on some set of data packets. This may be useful when sending to a small multicast group, since a single FEC packet can be used to repair multiple losses. Reactive FEC packets generated in this manner can only be decoded by receivers which understand the parity FEC operation, and which receive the appropriate subset of packets. This adds some complexity, compared to the single repair case, but saves bandwidth due to the reduced number of repair packets sent. In all cases, the resulting FEC packet MUST be sent as a separate stream, using the mechanisms defined in [2]. 6. Congestion Control RTP retransmission poses a risk of increasing network congestion. In a best-effort environment, packet loss is caused by congestion. Reacting to loss by retransmission of older data without decreasing the rate of the original stream will further increase congestion. Implementations MUST follow the recommendations below in order to use retransmission safely. The RTP profile under which the retransmission scheme is used MUST define an appropriate congestion control mechanism for different environments. Following the rules under the profile, an application can determine its acceptable bitrate and packet rate in order to be fair to other TCP or RTP flows. If an RTP application uses retransmission, the acceptable packet rate and bitrate includes both the original and retransmitted data. This guarantees that an application using retransmission achieves the same fairness as one that does not. Such a rule translates into the following actions: o If enhanced service is used, the total bitrate and packet rate MUST NOT exceed that of the requested service. A receiver SHOULD monitor the network to ensure that the requested service is delivered. o In best-effort environments, senders MUST NOT send retransmission packets without reducing the rate of the original stream (e.g. by encoding the data at a lower rate) to compensate for the extra retransmission data. Perkins Expires July 14, 2004 [Page 4] Internet-Draft SDP January 2004 These congestion control mechanisms should keep the packet loss rate within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve, on a reasonable timescale, average throughput that is not less than the one the RTP flow achieves. If the packet loss rate exceeds an acceptable level, the sender MUST reduce its sending rate or, if this is not possible, stop transmission. It is to be noted that RTP retransmission is not appropriate for sessions where reliability is more important than timeliness. In these cases, a protocol such as TCP/IP SHOULD be used. 7. Signalling using SDP Retransmission using reactive FEC may be signalled using SDP as in the following example: v=0 o=hamming 2890844526 2890842807 IN IP4 10.0.42.7 s=FEC Seminar c=IN IP4 10.6.1.4 t=0 0 m=audio 49170 RTP/AVPF 0 98 a=rtpmap:98 parityfec/8000 a=fmtp:98 49172 IN IP4 10.6.1.4 a=rtcp-fb:0 nack Note that use of RTP/AVPF with nack feedback for the original media. 8. IANA Considerations No IANA actions are necessary. 9. Security Considerations The security considerations of [2], [3] and [4] apply. 10. Acknowledgements Parts of this memo are derived from an earlier retransmission format developed by Jose Rey, David Leon, Akihiro Miyazaki, Viktor Varsa and Rolf Hakenberg. Thanks are due to John Lazzaro and Jonathan Rosenberg for their comments on an early version of this draft. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Perkins Expires July 14, 2004 [Page 5] Internet-Draft SDP January 2004 Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999. [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [4] Ott, J. and S. Wenger, "Extended RTP Profile for RTCP-based Feedback(RTP/AVPF)", draft-ietf-avt-rtcp-feedback-07 (work in progress), June 2003. Informative References [5] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [6] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998. Author's Address Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ United Kingdom EMail: csp@csperkins.org Perkins Expires July 14, 2004 [Page 6] Internet-Draft SDP January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Perkins Expires July 14, 2004 [Page 7] Internet-Draft SDP January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Perkins Expires July 14, 2004 [Page 8]