MMUSIC A. Begen Internet-Draft Y. Cai Intended status: Standards Track H. Ou Expires: April 12, 2012 Cisco October 10, 2011 Delayed Duplication Attribute in the Session Description Protocol draft-begen-mmusic-temporal-interleaving-03 Abstract A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to simply duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication. This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. 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 12, 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, et al. Expires April 12, 2012 [Page 1] Internet-Draft Delayed Duplication Attribute in SDP 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4 3. The 'duplication-delay' Attribute . . . . . . . . . . . . . . . 4 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Performance Evaluation and Reporting . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Registration of SDP Attributes . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Begen, et al. Expires April 12, 2012 [Page 2] Internet-Draft Delayed Duplication Attribute in SDP October 2011 1. Introduction Consider that a media sender transmits an original source packet and transmits its duplicate after a certain delay following the original transmission. If a network outage hits the original transmission, the expectation is that the second transmission arrives at the receiver. Alternatively, the second transmission may be hit by an outage and gets dropped, and the original transmission completes successfully. On the receiver side, both transmissions can also arrive and in that case, the receiver (or the node that does the duplicate suppression) needs to identify the duplicate packets and discard them appropriately, producing a duplicate-free stream. Delayed duplication can be used in a variety of multimedia applications where there is sufficient bandwidth for the duplicated traffic and the application can tolerate the introduced delay. However, it must be used with care since it might easily result in a new series of Denial-of-Service attacks. Furthermore, delayed duplication must not be used in cases where the primary cause of packet loss is congestion, rather than a network outage due to a temporary link or network element failure. Duplication can make congestion only worse. One particular use case for delayed duplication is to improve the reliability of real-time video feeds inside a core IP network [IC2011]. Compared to other popular redundancy approaches such as Forward Error Correction (FEC) [I-D.ietf-fecframe-framework] and redundant data encoding (e.g., [RFC2198]), delayed duplication is quite easy to implement since it does not require any special type of encoding or decoding. For duplicate suppression, the receiver has to be able to identify the identical packets. This is straightforward for media packets that carry one or more unique identifiers such as the sequence number field in RTP header [RFC3550]. In non-RTP applications, the receiver can use unique sequence numbers if available or other alternative approaches to compare the incoming packets and discard the duplicate ones. In this specification, we are not concerned about how the sender should determine the duplication delay. We are not concerned about how the receiver can suppress the duplicate packets and merge the incoming streams to produce a hopefully loss-free and duplication- free output stream (called stream merging), either. These considerations are out of the scope for this specification. Rather, we introduce a new attribute for the Session Description Protocol (SDP) [RFC4566] that indicates that the media stream is to be duplicated and sent two or more times, and also indicates the Begen, et al. Expires April 12, 2012 [Page 3] Internet-Draft Delayed Duplication Attribute in SDP October 2011 relative delay for each additional duplication. In practice, more than two redundant streams are unlikely to be used since the additional delay and increased overhead are not easily justified. However, we define the new attribute in a general way so that it could be used with more than two redundant streams if needed. While the primary focus in this specification is the RTP-based transport, the new attribute is applicable to both RTP and non-RTP streams. 2. 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. The 'duplication-delay' Attribute The following ABNF [RFC5234] syntax formally describes the 'duplication-delay' attribute: delaying-attribute = "a=duplication-delay:" periods CRLF periods = period *( ":" period) period = 1*DIGIT ; in milliseconds Figure 1: ABNF syntax for the 'interleaving-period' attribute The 'duplication-delay' attribute is defined as both a media-level and session-level attribute. It specifies the relative delay for each duplication in milliseconds (ms). If used as a media-level attribute, it MUST be used with the 'ssrc-group' attribute and "DUP" grouping semantics as defined in [I-D.begen-mmusic-redundancy-grouping]. If used as a session-level attribute, it MUST be used with 'group' attribute and "DUP" grouping semantics as defined in [I-D.begen-mmusic-redundancy-grouping]. 4. SDP Examples In the first example below, the multicast stream is duplicated with a duplication delay of 100 ms. The streams have Synchronization Sources (SSRC) of 1000 and 1010, and they are grouped together using the 'ssrc-group' attribute defined in [RFC5576]. The "DUP" grouping semantics is defined in [I-D.begen-mmusic-redundancy-grouping]. The Begen, et al. Expires April 12, 2012 [Page 4] Internet-Draft Delayed Duplication Attribute in SDP October 2011 reason for using explicit grouping is that not all the media streams in the same "m" line are necessarily duplicates of each other. v=0 o=ali 1122334455 1122334466 IN IP4 dup.example.com s=Delayed Duplication t=0 0 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=rtpmap:100 MP2T/90000 a=ssrc:1000 cname:ch1@example.com a=ssrc:1010 cname:ch1@example.com a=ssrc-group:DUP 1000 1010 a=duplication-delay:100 a=mid:Group1 Note that in actual use, SSRC values, which are random 32-bit numbers, could be much larger than the ones shown in this example. In the second example below, the multicast stream is duplicated twice. 50 ms after the original transmission, the first duplicate is transmitted and 100 ms after that, the second duplicate is transmitted. In other words, the same packet is transmitted three times over a period of 150 ms. v=0 o=ali 1122334455 1122334466 IN IP4 dup.example.com s=Delayed Duplication t=0 0 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=rtpmap:100 MP2T/90000 a=ssrc:1000 cname:ch1@example.com a=ssrc:1010 cname:ch1@example.com a=ssrc:1020 cname:ch1@example.com a=ssrc-group:DUP 1000 1010 1020 a=duplication-delay:50:100 a=mid:Group1 In the third example below, the multicast UDP stream is duplicated with a duplication delay of 50 ms. Both redundant streams are sent in the same source-specific multicast (SSM) session but they are sent Begen, et al. Expires April 12, 2012 [Page 5] Internet-Draft Delayed Duplication Attribute in SDP October 2011 to different ports. The "DUP" grouping semantics [I-D.begen-mmusic-redundancy-grouping] is used to describe the redundany relation. v=0 o=ali 1122334455 1122334466 IN IP4 dup.example.com s=Delayed Duplication t=0 0 a=group:DUP S1a S1b a=duplication-delay:50 m=audio 30000 udp mp4 c=IN IP4 233.252.0.1/127 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=mid:S1a m=audio 40000 udp mp4 c=IN IP4 233.252.0.2/127 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=mid:S1b 5. Performance Evaluation and Reporting Each duplicated stream has a separate (unique) SSRC identifier [I-D.begen-mmusic-redundancy-grouping]. Thus, individual RTCP receiver reports can be sent as usual for each of them from the receiving node that suppresses the duplicate packets. This way, the sender can be notified about the delivery performance of the individual 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. 6. Security Considerations The 'duplication-delay' attribute is not believed to introduce any significant security risk to multimedia applications. A malevolent third party could use this attribute to misguide the receiver(s) about the duplication delays and/or the number of redundant streams. For example, if the malevolent third party increases the value of the duplication delay, the receiver(s) will unnecessarily incur a longer delay since they will have to wait for the entire period. Or, if the duplication delay is reduced by the malevolent third party, the receiver(s) might not wait long enough for the duplicated transmission and incur unnecessary packet losses. However, these require intercepting and rewriting the packets carrying the SDP Begen, et al. Expires April 12, 2012 [Page 6] Internet-Draft Delayed Duplication Attribute in SDP October 2011 description; and if an interceptor can do that, many more attacks are also possible. In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This can, for example, be achieved on an end-to-end basis using S/MIME [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the authentication method in the Session Announcement Protocol (SAP) [RFC2974] could be used as well. Another security risk is due to possible software misconfiguration or a software bug where a large number of duplicates could be unwillingly signaled in the 'duplication-delay' attribute. In applications where this attribute is to be used, it is a good practice to put a hard limit both on the number of duplicate streams and the total delay introduced due to duplication regardless of what the SDP description specifies. 7. IANA Considerations The following contact information shall be used for all registrations in this document: Ali Begen abegen@cisco.com Note to the RFC Editor: In the following, replace "XXXX" with the number of this document prior to publication as an RFC. 7.1. Registration of SDP Attributes This document registers a new attribute name in SDP. Begen, et al. Expires April 12, 2012 [Page 7] Internet-Draft Delayed Duplication Attribute in SDP October 2011 SDP Attribute ("att-field"): Attribute name: duplication-delay Long form: Duplication delay for temporally redundant streams Type of name: att-field Type of attribute: Media or session level Subject to charset: No Purpose: Specifies the relative duplication delay(s) for redundant stream(s) Reference: [RFCXXXX] Values: See [RFCXXXX] 8. Acknowledgements Authors would like to thank Colin Perkins for his suggestions and review. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [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-01 (work in progress), June 2011. Begen, et al. Expires April 12, 2012 [Page 8] Internet-Draft Delayed Duplication Attribute in SDP October 2011 9.2. Informative References [I-D.ietf-fecframe-framework] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-15 (work in progress), June 2011. [RFC2198] 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. [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport (to appear in IEEE Internet Computing)", November 2011. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. Authors' Addresses Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada Email: abegen@cisco.com Begen, et al. Expires April 12, 2012 [Page 9] Internet-Draft Delayed Duplication Attribute in SDP October 2011 Yiqun Cai Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA Email: ycai@cisco.com Heidi Ou Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA Email: hou@cisco.com Begen, et al. Expires April 12, 2012 [Page 10]