idnits 2.17.1 draft-ietf-mmusic-delayed-duplication-01.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 20, 2013) is 4048 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 306, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-duplication-grouping-00 == Outdated reference: A later version (-06) exists of draft-ietf-avtext-rtp-duplication-01 -- 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 Cisco 4 Intended status: Standards Track Y. Cai 5 Expires: September 21, 2013 Microsoft 6 H. Ou 7 Cisco 8 March 20, 2013 10 Delayed Duplication Attribute in the Session Description Protocol 11 draft-ietf-mmusic-delayed-duplication-01 13 Abstract 15 A straightforward approach to provide protection against packet 16 losses due to network outages with a longest duration of T time units 17 is to simply duplicate the original packets and send each copy 18 separated in time by at least T time units. This approach is 19 commonly referred to as Time-shifted Redundancy, Temporal Redundancy 20 or simply Delayed Duplication. This document defines an attribute to 21 indicate the presence of temporally redundant media streams and the 22 duplication delay in the Session Description Protocol. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 21, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4 60 3. The 'duplication-delay' Attribute . . . . . . . . . . . . . . . 4 61 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. Registration of SDP Attributes . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Consider that a media sender transmits an original source packet and 74 transmits its duplicate after a certain delay following the original 75 transmission. If a network outage hits the original transmission, 76 the expectation is that the second transmission arrives at the 77 receiver. Alternatively, the second transmission may be hit by an 78 outage and gets dropped, and the original transmission completes 79 successfully. On the receiver side, both transmissions can also 80 arrive and in that case, the receiver (or the node that does the 81 duplicate suppression) needs to identify the duplicate packets and 82 discard them appropriately, producing a duplicate-free stream. 84 Delayed duplication can be used in a variety of multimedia 85 applications where there is sufficient bandwidth for the duplicated 86 traffic and the application can tolerate the introduced delay. 87 However, it must be used with care since it might easily result in a 88 new series of denial-of-service attacks. Furthermore, delayed 89 duplication must not be used in cases where the primary cause of 90 packet loss is congestion, rather than a network outage due to a 91 temporary link or network element failure. Duplication can make 92 congestion only worse. 94 One particular use case for delayed duplication is to improve the 95 reliability of real-time video feeds inside a core IP network 96 [IC2011]. Compared to other popular redundancy approaches such as 97 Forward Error Correction (FEC) [RFC6363] and redundant data encoding 98 (e.g., [RFC2198]), delayed duplication is quite easy to implement 99 since it does not require any special type of encoding or decoding. 101 For duplicate suppression, the receiver has to be able to identify 102 the identical packets. This is straightforward for media packets 103 that carry one or more unique identifiers such as the sequence number 104 field in RTP header [RFC3550]. In non-RTP applications, the receiver 105 can use unique sequence numbers if available or other alternative 106 approaches to compare the incoming packets and discard the duplicate 107 ones. 109 In this specification, we are not concerned about how the sender 110 should determine the duplication delay. We are not concerned about 111 how the receiver can suppress the duplicate packets and merge the 112 incoming streams to produce a hopefully loss-free and duplication- 113 free output stream (a process commonly called stream merging), 114 either. These considerations are out of the scope for this 115 specification. Rather, our goal is to introduce a new attribute for 116 the Session Description Protocol (SDP) [RFC4566] to indicate that a 117 media stream is to be duplicated and transmitted two or more times, 118 and also to indicate the relative delay for each additional 119 duplication. 121 In practice, more than two redundant streams are unlikely to be used 122 since the additional delay and increased overhead are not easily 123 justified. However, we define the new attribute in a general way so 124 that it could be used with more than two redundant streams (i.e., 125 multiple duplications), if needed. While the primary focus in this 126 specification is the RTP-based transport, the new attribute is 127 applicable to both RTP and non-RTP streams. Details on duplicating 128 RTP streams are presented in [I-D.ietf-avtext-rtp-duplication]. 130 2. Requirements Notation 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119]. 137 3. The 'duplication-delay' Attribute 139 The following ABNF [RFC5234] syntax formally describes the 140 'duplication-delay' attribute: 142 delaying-attribute = "a=duplication-delay:" periods CRLF 143 periods = period *( ":" period) 144 period = 1*DIGIT ; in milliseconds 146 Figure 1: ABNF syntax for the 'duplication-delay' attribute 148 The 'duplication-delay' attribute is defined as both a media-level 149 and session-level attribute. It specifies the relative delay for 150 each duplication in milliseconds (ms) at the time of transmission. 151 The following rules apply: 153 o If used as a media-level attribute, it MUST be used with the 154 'ssrc-group' attribute and "DUP" grouping semantics as defined in 155 [I-D.ietf-mmusic-duplication-grouping]. When used as a media- 156 level attribute, the relative delay value(s) it specifies SHALL 157 apply to every Synchronization Source (SSRC)-based duplication 158 grouping in the same media description. In other words, one 159 cannot specify different duplication delay values to different 160 duplication groups in the same media description. 162 o If used as a session-level attribute, it MUST be used with 'group' 163 attribute and "DUP" grouping semantics as defined in 165 [I-D.ietf-mmusic-duplication-grouping]. When used as a session- 166 level attribute, the relative delay value(s) it specifies SHALL 167 apply to every duplication grouping in the same SDP description. 168 In other words, one cannot specify different duplication delay 169 values to different duplication groups in the same SDP 170 description. If one needs to specify different duplication delay 171 values for different duplication groups, then one MUST use 172 different SDP descriptions for each or MUST use the 'duplication- 173 delay' attribute at media level. 175 o For offer/answer model considerations, refer to 176 [I-D.ietf-mmusic-duplication-grouping]. 178 4. SDP Examples 180 In the first example below, the multicast stream consists of two RTP 181 streams, each duplicated once, resulting in two sets of two-stream 182 groups. The same duplication delay of 100 ms is applied to each 183 grouping. The first set's streams have SSRCs of 1000 and 1010 and 184 the second set's streams have SSRCs of 1020 and 1030. 186 v=0 187 o=ali 1122334455 1122334466 IN IP4 dup.example.com 188 s=Delayed Duplication 189 t=0 0 190 m=video 30000 RTP/AVP 100 101 191 c=IN IP4 233.252.0.1/127 192 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 193 a=rtpmap:100 MP2T/90000 194 a=ssrc:1000 cname:ch1a@example.com 195 a=ssrc:1010 cname:ch1a@example.com 196 a=ssrc-group:DUP 1000 1010 197 a=rtpmap:101 MP2T/90000 198 a=ssrc:1020 cname:ch1b@example.com 199 a=ssrc:1030 cname:ch1b@example.com 200 a=ssrc-group:DUP 1020 1030 201 a=duplication-delay:100 202 a=mid:Ch1 204 Note that in actual use, SSRC values, which are random 32-bit 205 numbers, could be much larger than the ones shown in this example. 207 In the second example below, the multicast stream is duplicated 208 twice. 50 ms after the original transmission, the first duplicate is 209 transmitted and 100 ms after that, the second duplicate is 210 transmitted. In other words, the same packet is transmitted three 211 times over a period of 150 ms. 213 v=0 214 o=ali 1122334455 1122334466 IN IP4 dup.example.com 215 s=Delayed Duplication 216 t=0 0 217 m=video 30000 RTP/AVP 100 218 c=IN IP4 233.252.0.1/127 219 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 220 a=rtpmap:100 MP2T/90000 221 a=ssrc:1000 cname:ch1c@example.com 222 a=ssrc:1010 cname:ch1c@example.com 223 a=ssrc:1020 cname:ch1c@example.com 224 a=ssrc-group:DUP 1000 1010 1020 225 a=duplication-delay:50:100 226 a=mid:Ch1 228 In the third example below, the multicast UDP stream is duplicated 229 with a duplication delay of 50 ms. Redundant streams are sent in 230 separate source-specific multicast (SSM) sessions so the receiving 231 host has to join both SSM sessions if it wants to receive both 232 streams. 234 v=0 235 o=ali 1122334455 1122334466 IN IP4 dup.example.com 236 s=Delayed Duplication 237 t=0 0 238 a=group:DUP S1a S1b 239 a=duplication-delay:50 240 m=audio 30000 udp mp4 241 c=IN IP4 233.252.0.1/127 242 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 243 a=mid:S1a 244 m=audio 40000 udp mp4 245 c=IN IP4 233.252.0.2/127 246 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 247 a=mid:S1b 249 5. Security Considerations 251 The 'duplication-delay' attribute is not believed to introduce any 252 significant security risk to multimedia applications. A malevolent 253 third party could use this attribute to misguide the receiver(s) 254 about the duplication delays and/or the number of redundant streams. 255 For example, if the malevolent third party increases the value of the 256 duplication delay, the receiver(s) will unnecessarily incur a longer 257 delay since they will have to wait for the entire period. Or, if the 258 duplication delay is reduced by the malevolent third party, the 259 receiver(s) might not wait long enough for the duplicated 260 transmission and incur unnecessary packet losses. However, these 261 require intercepting and rewriting the packets carrying the SDP 262 description; and if an interceptor can do that, many more attacks are 263 also possible. 265 In order to avoid attacks of this sort, the SDP description needs to 266 be integrity protected and provided with source authentication. This 267 can, for example, be achieved on an end-to-end basis using S/MIME 268 [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME 269 types (application/sdp). Alternatively, HTTPS [RFC2818] or the 270 authentication method in the Session Announcement Protocol (SAP) 271 [RFC2974] could be used as well. 273 Another security risk is due to possible software misconfiguration or 274 a software bug where a large number of duplicates could be 275 unwillingly signaled in the 'duplication-delay' attribute. In 276 applications where this attribute is to be used, it is a good 277 practice to put a hard limit both on the number of duplicate streams 278 and the total delay introduced due to duplication regardless of what 279 the SDP description specifies. 281 6. IANA Considerations 283 The following contact information shall be used for all registrations 284 in this document: 286 Ali Begen 287 abegen@cisco.com 289 Note to the RFC Editor: In the following, replace "XXXX" with the 290 number of this document prior to publication as an RFC. 292 6.1. Registration of SDP Attributes 294 This document registers a new attribute name in SDP. 296 SDP Attribute ("att-field"): 297 Attribute name: duplication-delay 298 Long form: Duplication delay for temporally redundant 299 streams 300 Type of name: att-field 301 Type of attribute: Media or session level 302 Subject to charset: No 303 Purpose: Specifies the relative duplication delay(s) for 304 redundant stream(s) 305 Reference: [RFCXXXX] 306 Values: See [RFCXXXX] 308 7. Acknowledgements 310 Authors would like to thank Colin Perkins and Paul Kyzivat for their 311 suggestions and reviews. 313 8. References 315 8.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 321 Description Protocol", RFC 4566, July 2006. 323 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 324 Jacobson, "RTP: A Transport Protocol for Real-Time 325 Applications", STD 64, RFC 3550, July 2003. 327 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 328 Specifications: ABNF", STD 68, RFC 5234, January 2008. 330 [I-D.ietf-mmusic-duplication-grouping] 331 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 332 Semantics in the Session Description Protocol", 333 draft-ietf-mmusic-duplication-grouping-00 (work in 334 progress), October 2012. 336 8.2. Informative References 338 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 339 Correction (FEC) Framework", RFC 6363, October 2011. 341 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 342 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 343 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 344 September 1997. 346 [I-D.ietf-avtext-rtp-duplication] 347 Begen, A. and C. Perkins, "Duplicating RTP Streams", 348 draft-ietf-avtext-rtp-duplication-01 (work in progress), 349 December 2012. 351 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 352 "Toward Lossless Video Transport (to appear in IEEE 353 Internet Computing)", November 2011. 355 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 356 RFC 5652, September 2009. 358 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 359 Mail Extensions (S/MIME) Version 3.2 Message 360 Specification", RFC 5751, January 2010. 362 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 364 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 365 Announcement Protocol", RFC 2974, October 2000. 367 Authors' Addresses 369 Ali Begen 370 Cisco 371 181 Bay Street 372 Toronto, ON M5J 2T3 373 Canada 375 Email: abegen@cisco.com 377 Yiqun Cai 378 Microsoft 379 1065 La Avenida 380 Mountain View, CA 94043 381 USA 383 Email: yiqunc@microsoft.com 384 Heidi Ou 385 Cisco 386 170 W. Tasman Dr. 387 San Jose, CA 95134 388 USA 390 Email: hou@cisco.com