idnits 2.17.1 draft-begen-mmusic-temporal-interleaving-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2012) is 4421 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 282, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-03) exists of draft-begen-mmusic-redundancy-grouping-02 == Outdated reference: A later version (-01) exists of draft-begen-avtcore-rtp-duplication-00 -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Y. Cai 4 Intended status: Standards Track H. Ou 5 Expires: September 12, 2012 Cisco 6 March 11, 2012 8 Delayed Duplication Attribute in the Session Description Protocol 9 draft-begen-mmusic-temporal-interleaving-04 11 Abstract 13 A straightforward approach to provide protection against packet 14 losses due to network outages with a longest duration of T time units 15 is to simply duplicate the original packets and send each copy 16 separated in time by at least T time units. This approach is 17 commonly referred to as Time-shifted Redundancy, Temporal Redundancy 18 or simply Delayed Duplication. This document defines an attribute to 19 indicate the presence of temporally redundant media streams and the 20 duplication delay in the Session Description Protocol. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4 58 3. The 'duplication-delay' Attribute . . . . . . . . . . . . . . . 4 59 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Registration of SDP Attributes . . . . . . . . . . . . . . 7 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Consider that a media sender transmits an original source packet and 72 transmits its duplicate after a certain delay following the original 73 transmission. If a network outage hits the original transmission, 74 the expectation is that the second transmission arrives at the 75 receiver. Alternatively, the second transmission may be hit by an 76 outage and gets dropped, and the original transmission completes 77 successfully. On the receiver side, both transmissions can also 78 arrive and in that case, the receiver (or the node that does the 79 duplicate suppression) needs to identify the duplicate packets and 80 discard them appropriately, producing a duplicate-free stream. 82 Delayed duplication can be used in a variety of multimedia 83 applications where there is sufficient bandwidth for the duplicated 84 traffic and the application can tolerate the introduced delay. 85 However, it must be used with care since it might easily result in a 86 new series of denial-of-service attacks. Furthermore, delayed 87 duplication must not be used in cases where the primary cause of 88 packet loss is congestion, rather than a network outage due to a 89 temporary link or network element failure. Duplication can make 90 congestion only worse. 92 One particular use case for delayed duplication is to improve the 93 reliability of real-time video feeds inside a core IP network 94 [IC2011]. Compared to other popular redundancy approaches such as 95 Forward Error Correction (FEC) [RFC6363] and redundant data encoding 96 (e.g., [RFC2198]), delayed duplication is quite easy to implement 97 since it does not require any special type of encoding or decoding. 99 For duplicate suppression, the receiver has to be able to identify 100 the identical packets. This is straightforward for media packets 101 that carry one or more unique identifiers such as the sequence number 102 field in RTP header [RFC3550]. In non-RTP applications, the receiver 103 can use unique sequence numbers if available or other alternative 104 approaches to compare the incoming packets and discard the duplicate 105 ones. 107 In this specification, we are not concerned about how the sender 108 should determine the duplication delay. We are not concerned about 109 how the receiver can suppress the duplicate packets and merge the 110 incoming streams to produce a hopefully loss-free and duplication- 111 free output stream (called stream merging), either. These 112 considerations are out of the scope for this specification. Rather, 113 our goal is simply to introduce a new attribute for the Session 114 Description Protocol (SDP) [RFC4566] that indicates that the media 115 stream is to be duplicated and sent two or more times, and also 116 indicates the relative delay for each additional duplication. 118 In practice, more than two redundant streams are unlikely to be used 119 since the additional delay and increased overhead are not easily 120 justified. However, we define the new attribute in a general way so 121 that it could be used with more than two redundant streams if needed. 122 While the primary focus in this specification is the RTP-based 123 transport, the new attribute is applicable to both RTP and non-RTP 124 streams. Details on duplicating RTP streams are presented in 125 [I-D.begen-avtcore-rtp-duplication]. 127 2. Requirements Notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 [RFC2119]. 134 3. The 'duplication-delay' Attribute 136 The following ABNF [RFC5234] syntax formally describes the 137 'duplication-delay' attribute: 139 delaying-attribute = "a=duplication-delay:" periods CRLF 140 periods = period *( ":" period) 141 period = 1*DIGIT ; in milliseconds 143 Figure 1: ABNF syntax for the 'interleaving-period' attribute 145 The 'duplication-delay' attribute is defined as both a media-level 146 and session-level attribute. It specifies the relative delay for 147 each duplication in milliseconds (ms). If used as a media-level 148 attribute, it MUST be used with the 'ssrc-group' attribute and "DUP" 149 grouping semantics as defined in 150 [I-D.begen-mmusic-redundancy-grouping]. If used as a session-level 151 attribute, it MUST be used with 'group' attribute and "DUP" grouping 152 semantics as defined in [I-D.begen-mmusic-redundancy-grouping]. 154 4. SDP Examples 156 In the first example below, the multicast stream is duplicated with a 157 duplication delay of 100 ms. The streams have Synchronization 158 Sources (SSRC) of 1000 and 1010, and they are grouped together using 159 the 'ssrc-group' attribute defined in [RFC5576]. The "DUP" grouping 160 semantics are defined in [I-D.begen-mmusic-redundancy-grouping]. The 161 reason for using explicit grouping is that not all the media streams 162 in the same "m" line are necessarily duplicates of each other. 164 v=0 165 o=ali 1122334455 1122334466 IN IP4 dup.example.com 166 s=Delayed Duplication 167 t=0 0 168 m=video 30000 RTP/AVP 100 169 c=IN IP4 233.252.0.1/127 170 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 171 a=rtpmap:100 MP2T/90000 172 a=ssrc:1000 cname:ch1@example.com 173 a=ssrc:1010 cname:ch1@example.com 174 a=ssrc-group:DUP 1000 1010 175 a=duplication-delay:100 176 a=mid:Group1 178 Note that in actual use, SSRC values, which are random 32-bit 179 numbers, could be much larger than the ones shown in this example. 181 In the second example below, the multicast stream is duplicated 182 twice. 50 ms after the original transmission, the first duplicate is 183 transmitted and 100 ms after that, the second duplicate is 184 transmitted. In other words, the same packet is transmitted three 185 times over a period of 150 ms. 187 v=0 188 o=ali 1122334455 1122334466 IN IP4 dup.example.com 189 s=Delayed Duplication 190 t=0 0 191 m=video 30000 RTP/AVP 100 192 c=IN IP4 233.252.0.1/127 193 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 194 a=rtpmap:100 MP2T/90000 195 a=ssrc:1000 cname:ch1@example.com 196 a=ssrc:1010 cname:ch1@example.com 197 a=ssrc:1020 cname:ch1@example.com 198 a=ssrc-group:DUP 1000 1010 1020 199 a=duplication-delay:50:100 200 a=mid:Group1 202 In the third example below, the multicast UDP stream is duplicated 203 with a duplication delay of 50 ms. Both streams are sent in the same 204 source-specific multicast (SSM) session but they are sent to 205 different ports. The "DUP" grouping semantics 207 [I-D.begen-mmusic-redundancy-grouping] are used to describe the 208 redundany relation. 210 v=0 211 o=ali 1122334455 1122334466 IN IP4 dup.example.com 212 s=Delayed Duplication 213 t=0 0 214 a=group:DUP S1a S1b 215 a=duplication-delay:50 216 m=audio 30000 udp mp4 217 c=IN IP4 233.252.0.1/127 218 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 219 a=mid:S1a 220 m=audio 40000 udp mp4 221 c=IN IP4 233.252.0.2/127 222 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 223 a=mid:S1b 225 5. Security Considerations 227 The 'duplication-delay' attribute is not believed to introduce any 228 significant security risk to multimedia applications. A malevolent 229 third party could use this attribute to misguide the receiver(s) 230 about the duplication delays and/or the number of redundant streams. 231 For example, if the malevolent third party increases the value of the 232 duplication delay, the receiver(s) will unnecessarily incur a longer 233 delay since they will have to wait for the entire period. Or, if the 234 duplication delay is reduced by the malevolent third party, the 235 receiver(s) might not wait long enough for the duplicated 236 transmission and incur unnecessary packet losses. However, these 237 require intercepting and rewriting the packets carrying the SDP 238 description; and if an interceptor can do that, many more attacks are 239 also possible. 241 In order to avoid attacks of this sort, the SDP description needs to 242 be integrity protected and provided with source authentication. This 243 can, for example, be achieved on an end-to-end basis using S/MIME 244 [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME 245 types (application/sdp). Alternatively, HTTPS [RFC2818] or the 246 authentication method in the Session Announcement Protocol (SAP) 247 [RFC2974] could be used as well. 249 Another security risk is due to possible software misconfiguration or 250 a software bug where a large number of duplicates could be 251 unwillingly signaled in the 'duplication-delay' attribute. In 252 applications where this attribute is to be used, it is a good 253 practice to put a hard limit both on the number of duplicate streams 254 and the total delay introduced due to duplication regardless of what 255 the SDP description specifies. 257 6. IANA Considerations 259 The following contact information shall be used for all registrations 260 in this document: 262 Ali Begen 263 abegen@cisco.com 265 Note to the RFC Editor: In the following, replace "XXXX" with the 266 number of this document prior to publication as an RFC. 268 6.1. Registration of SDP Attributes 270 This document registers a new attribute name in SDP. 272 SDP Attribute ("att-field"): 273 Attribute name: duplication-delay 274 Long form: Duplication delay for temporally redundant 275 streams 276 Type of name: att-field 277 Type of attribute: Media or session level 278 Subject to charset: No 279 Purpose: Specifies the relative duplication delay(s) for 280 redundant stream(s) 281 Reference: [RFCXXXX] 282 Values: See [RFCXXXX] 284 7. Acknowledgements 286 Authors would like to thank Colin Perkins for his suggestions and 287 review. 289 8. References 291 8.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 297 Description Protocol", RFC 4566, July 2006. 299 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 300 Jacobson, "RTP: A Transport Protocol for Real-Time 301 Applications", STD 64, RFC 3550, July 2003. 303 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 304 Specifications: ABNF", STD 68, RFC 5234, January 2008. 306 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 307 Media Attributes in the Session Description Protocol 308 (SDP)", RFC 5576, June 2009. 310 [I-D.begen-mmusic-redundancy-grouping] 311 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 312 Semantics in the Session Description Protocol", 313 draft-begen-mmusic-redundancy-grouping-02 (work in 314 progress), October 2011. 316 8.2. Informative References 318 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 319 Correction (FEC) Framework", RFC 6363, October 2011. 321 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 322 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 323 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 324 September 1997. 326 [I-D.begen-avtcore-rtp-duplication] 327 Begen, A. and C. Perkins, "Duplicating RTP Streams", 328 draft-begen-avtcore-rtp-duplication-00 (work in progress), 329 October 2011. 331 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 332 "Toward Lossless Video Transport (to appear in IEEE 333 Internet Computing)", November 2011. 335 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 336 RFC 5652, September 2009. 338 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 339 Mail Extensions (S/MIME) Version 3.2 Message 340 Specification", RFC 5751, January 2010. 342 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 344 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 345 Announcement Protocol", RFC 2974, October 2000. 347 Authors' Addresses 349 Ali Begen 350 Cisco 351 181 Bay Street 352 Toronto, ON M5J 2T3 353 Canada 355 Email: abegen@cisco.com 357 Yiqun Cai 358 Cisco 359 170 W. Tasman Dr. 360 San Jose, CA 95134 361 USA 363 Email: ycai@cisco.com 365 Heidi Ou 366 Cisco 367 170 W. Tasman Dr. 368 San Jose, CA 95134 369 USA 371 Email: hou@cisco.com