AVT A. Begen Internet-Draft Cisco Intended status: Standards Track C. Perkins Expires: April 26, 2012 University of Glasgow October 24, 2011 Duplicating RTP Streams draft-begen-avtcore-rtp-duplication-00 Abstract Packet loss is undesirable for real-time multimedia sessions, but it is not avoidable due to congestion or other unplanned network outages. This is especially the case for IP multicast networks. One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document explains how RTP streams can be duplicated without breaking RTP and RTP Control Protocol (RTCP) rules. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 26, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Begen & Perkins Expires April 26, 2012 [Page 1] Internet-Draft RTP Duplication October 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Requirements Notation . . . . . . . . . . . . . 3 3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . . 3 3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . . 4 3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Using Separate Source Interfaces . . . . . . . . . . . 4 3.2.2. Using Separate Destination Addresses and/or Ports . . . 5 3.3. Dual Streaming over a Single Path or Multiple Paths . . . . 5 4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . . 6 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . . 6 4.2. Signaling Considerations . . . . . . . . . . . . . . . . . 6 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . . 7 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . . 7 5.2. Signaling Considerations . . . . . . . . . . . . . . . . . 7 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Begen & Perkins Expires April 26, 2012 [Page 2] Internet-Draft RTP Duplication October 2011 1. Introduction RTP [RFC3550] transport is widely used today for delivering real-time multimedia streams. Most of the applications also rely on IP multicast to reach many receivers efficiently. While the combination proves successful, there does exist a weakness. As [RFC2354] noted, packet loss is not avoidable. This might be due to congestion, it might also be a result of an unplanned outage caused by a flapping link, link or interface failure, a software bug, or a maintenance person accidentally cutting the wrong fiber. Since UDP does not provide any means for detecting loss and retransmitting packets, it leaves up to the RTP or the applications to detect and recover from the loss. For retransmission-based recovery, one example is described in [RFC4588]. One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. Variations of this technique have already been implemented and deployed today [IC2011]. However, duplication of RTP streams without breaking the RTP and RTCP functionality has not been documented properly. This document explains how duplication can be achieved for RTP streams. 2. Terminology and Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Dual Streaming Use Cases Dual streaming refers to a technique that involves transmitting two redundant (often RTP) streams of the same content, with each stream itself capable of supporting the playback when there is no packet loss. Therefore, adding an additional stream provides a protection against packet loss. The level of protection depends on how the packets are sent and transmitted inside the network. It is important to note that redundant streaming can easily be extended to support cases when more than two streams are desired. But triple, quadruple, or more, streaming is rarely used in practice. Begen & Perkins Expires April 26, 2012 [Page 3] Internet-Draft RTP Duplication October 2011 3.1. Temporal Redundancy From a routing perspective, two streams are considered identical if their following two fields are the same since they will be both routed over the same path: o IP Source Address o IP Destination Address Two routing-plane identical RTP streams might carry the same payload but they could use different Synchronization Sources (SSRC) to differentiate the RTP packets belonging to each stream. In the context of dual streaming, we assume that the source duplicates the RTP packets and put them into separate RTP streams each with a unique SSRC identifier. All the redundant streams are transmitted in the same RTP session. For example, two redundant RTP streams can be sent to the same IP destination address and UDP destination port with a certain delay between them [I-D.begen-mmusic-temporal-interleaving]. The streams carry the same payload in their respective RTP packets with identical sequence numbers. This allows the receiver (or any other node responsible for duplicate suppression) to identify and suppress the duplicate packets, and subsequently produce a hopefully loss-free and duplication-free output stream (called stream merging). 3.2. Spatial Redundancy 3.2.1. Using Separate Source Interfaces An RTP source might have multiple network interfaces associated with it and it can send two redundant streams from two separate interfaces. Such streams can be routed over diverse or identical paths depending on the routing algorithm inside the network. At the receiving end, the node responsible for duplicate suppression can look into various RTP related fields to identify and suppress the duplicate packets. If source-specific multicast (SSM) transport is used to carry such redundant streams, there will be a separate SSM session for each redundant stream since the streams are sourced from different interfaces (i.e., IP addresses). The receiving host has to join each SSM session separately. Begen & Perkins Expires April 26, 2012 [Page 4] Internet-Draft RTP Duplication October 2011 3.2.2. Using Separate Destination Addresses and/or Ports An RTP source might send the redundant streams to separate IP destination addresses and/or UDP ports. 3.3. Dual Streaming over a Single Path or Multiple Paths Having described the characteristics of the streams, one can reach the following conclusions: 1. When two routing-plane identical streams are used, the two streams will have identical IP headers. This makes it impractical to forward the packets onto different paths. In order to minimize packet loss, the packets belonging to one stream are often interleaved with packets belonging to the other, and with a delay, so that if there is a packet loss, such a delay would allow the same packet from the other stream to reach the receiver because the chances that the same packet is lost in transit again is often small. This is what is also known as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication [I-D.begen-mmusic-temporal-interleaving] [IC2011]. This approach can be used with all three types of dual streaming described in Section 3.1, Section 3.2.1 and Section 3.2.2. 2. If the two streams have different IP headers, an additional opportunity arises in that one is able to build a network, with physically diverse paths, to deliver the two streams concurrently to the intended receivers. This reduces the delay when packet loss occurs and needs to be recovered. Additionally, it also further reduces chances for packet loss. An unrecoverable loss happens only when two network failures happen in such a way that the same packet is affected on both paths. This is referred to as Spatial Diversity or Spatial Redundancy [IC2011]. The techniques used to build diverse paths are beyond the scope of this document. Note that spatial redundancy often offers less delay in recovering from packet loss provided that the forwarding delay of the network paths are more or less the same. For both temporal and spatial redundancy approaches, packet misordering might still happen and needs to be handled using the RTP sequence numbers. To summarize, dual streaming allows an application and a network to work together to provide a near zero-loss transport with a bounded or minimum delay. The additional advantage includes a predictable bandwidth overhead that is proportional to the minimum bandwidth needed for the multimedia session, but independent of the number of receivers experiencing a packet loss and requesting a retransmission. Begen & Perkins Expires April 26, 2012 [Page 5] Internet-Draft RTP Duplication October 2011 For a survey and comparison of similar approaches, refer to [IC2011]. 4. Use of RTP and RTCP with Temporal Redundancy To achieve temporal redundancy, the main and redundant RTP streams are sent using the same source and destination IP addresses and ports (that is the 5-tuple of transport protocol, source and destination IP addresses, and source and destination transport ports is the same for both main and redundant RTP streams). This is perhaps overly restrictive, but with the possible presence of network address and port translation (NAPT) devices, using anything other than an identical 5-tuple can also cause spatial redundancy. Since main and redundant RTP streams follow an identical path, they are part of the same RTP session. Accordingly, the sender MUST choose a different SSRC for the redundant RTP stream than it chose for the main RTP stream, following the rules in [RFC3550] section 8. 4.1. RTCP Considerations If RTCP is being sent for the main RTP stream, then the sender MUST also generate RTCP for the redundant RTP stream. The RTCP for the redundant RTP stream is generated exactly as-if the redundant RTP stream were a regular media stream; the sender MUST NOT duplicate the RTCP packets sent for the main RTP stream. The sender MUST use the same RTCP CNAME in the RTCP reports it sends for the main and redundant streams, so that the receiver can synchronize them. Both main and redundant streams, and their corresponding RTCP, will be received. If RTCP is used, receivers MUST generate RTCP reports for both main and redundant streams in the usual way, treating them as entirely separate media streams. Editor's note: The receiving node can also produce a new XR report to report on the (loss/delay/jitter/etc.) performance of the output stream after the stream merging process. This is TBD. 4.2. Signaling Considerations Signaling is needed to allow the receiver to determine that an RTP stream is a redundant copy of another, rather than a separate stream that needs to be rendered in parallel. We need an SDP attribute to ensure that the receiver supports temporal redundancy, plus a new RTCP SDES item to indicate that this is a redundant stream that should not be directly rendered. Editor's notes: Begen & Perkins Expires April 26, 2012 [Page 6] Internet-Draft RTP Duplication October 2011 o How should we correlate the duplicate streams? Grouping is straightforward when streams are SSRC-muxed but what if there are non-duplicated RTP streams in the same session? Maybe also use Magnus' srcname proposal? The required SDP grouping semantics and SDP attribute have been defined in [I-D.begen-mmusic-redundancy-grouping] and [I-D.begen-mmusic-temporal-interleaving], respectively. 5. Use of RTP and RTCP with Spatial Redundancy When using spatial redundancy, the redundant RTP stream is sent on using a different source and/or destination address/port pair. This will be a separate RTP session to the session conveying the main RTP stream. SSRC for the redundant stream chosen randomly, following the rules in Section 8 of [RFC3550] and will almost certainly not match that of the main RTP stream. Sender MUST use the same RTCP CNAME for both main and redundant streams, in their separate sessions. Also the sender uses the new SDES item to indicate that this is a redundant stream. This is how the receiver can correlate the flows (can use srcname if appropriate). 5.1. RTCP Considerations If RTCP is being sent for the main RTP stream, then the sender MUST also generate RTCP for the redundant RTP stream. The RTCP for the redundant RTP stream is generated exactly as-if the redundant RTP stream were a regular media stream; the sender MUST NOT duplicate the RTCP packets sent for the main RTP stream. The sender MUST use the same RTCP CNAME in the RTCP reports it sends for the main and redundant streams, so that the receiver can synchronize them. Both main and redundant streams, and their corresponding RTCP, will be received. If RTCP is used, receivers MUST generate RTCP reports for both main and redundant streams in the usual way, treating them as entirely separate media streams. Editor's note: The receiving node can also produce a new XR report to report on the (loss/delay/jitter/etc.) performance of the output stream after the stream merging process. This is TBD. 5.2. Signaling Considerations The required SDP grouping semantics and SDP attribute have been defined in [I-D.begen-mmusic-redundancy-grouping] and Begen & Perkins Expires April 26, 2012 [Page 7] Internet-Draft RTP Duplication October 2011 [I-D.begen-mmusic-temporal-interleaving], respectively. 6. Use of RTP and RTCP with Temporal and Spatial Redundancy Editor's note: Nothing new here. This should use the same RTP/RTCP mechanisms, plus a combination of both sets of signaling. 7. Security Considerations The security considerations of [RFC3550] apply to this memo. Additional security considerations are TBC. Editor's note: Email from csp. For the stream de-duplication device: it seems that this would work with SRTP encryption [RFC3711], since the headers are in the clear, but would break the authentication when the SSRC is rewritten. You could just re- authenticate the packets, and avoid re-encryption, with appropriate signaling of who authenticates the packets. 8. IANA Considerations TBC. 9. Acknowledgments Thanks to Magnus Westerlund for his suggestions. 10. References 10.1. Normative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.begen-mmusic-temporal-interleaving] Begen, A., Cai, Y., and H. Ou, "Delayed Duplication Attribute in the Session Description Protocol", draft-begen-mmusic-temporal-interleaving-03 (work in Begen & Perkins Expires April 26, 2012 [Page 8] Internet-Draft RTP Duplication October 2011 progress), October 2011. [I-D.begen-mmusic-redundancy-grouping] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", draft-begen-mmusic-redundancy-grouping-02 (work in progress), October 2011. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 10.2. Informative References [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport (to appear in IEEE Internet Computing)", November 2011. Authors' Addresses Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 CANADA Email: abegen@cisco.com Colin Perkins University of Glasgow School of Computing Science Glasgow, G12 8QQ UK Email: csp@csperkins.org Begen & Perkins Expires April 26, 2012 [Page 9]