idnits 2.17.1 draft-ietf-mmusic-delayed-duplication-02.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 (May 27, 2013) is 3986 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-01 == 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: November 28, 2013 Microsoft 6 H. Ou 7 Cisco 8 May 27, 2013 10 Delayed Duplication Attribute in the Session Description Protocol 11 draft-ietf-mmusic-delayed-duplication-02 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 November 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 60 3. The 'duplication-delay' Attribute . . . . . . . . . . . . . . 3 61 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Registration of SDP Attributes . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 *( SP period) 144 period = 1*DIGIT ; in milliseconds 145 Figure 1: ABNF syntax for the 'duplication-delay' attribute 147 The 'duplication-delay' attribute is defined as both a media-level 148 and session-level attribute. It specifies the relative delay with 149 respect to the previous stream for each duplication in milliseconds 150 (ms) at the time of transmission. The following rules apply: 152 o If used as a media-level attribute, it MUST be used with the 153 'ssrc-group' attribute and "DUP" grouping semantics as defined in 154 [I-D.ietf-mmusic-duplication-grouping]. When used as a media- 155 level attribute, the relative delay value(s) it specifies SHALL 156 apply to every Synchronization Source (SSRC)-based duplication 157 grouping in the same media description. In other words, one 158 cannot specify different duplication delay values to different 159 duplication groups in the same media description. 161 o If used as a session-level attribute, it MUST be used with 'group' 162 attribute and "DUP" grouping semantics as defined in 163 [I-D.ietf-mmusic-duplication-grouping]. When used as a session- 164 level attribute, the relative delay value(s) it specifies SHALL 165 apply to every duplication grouping in the same SDP description. 166 In other words, one cannot specify different duplication delay 167 values to different duplication groups in the same SDP 168 description. If one needs to specify different duplication delay 169 values for different duplication groups, then one MUST use 170 different SDP descriptions for each or MUST use the 'duplication- 171 delay' attribute at media level. In that case, the 'duplication- 172 delay' attribute MUST NOT be used at the session level. 174 o For offer/answer model considerations, refer to 175 [I-D.ietf-mmusic-duplication-grouping]. 177 4. SDP Examples 179 In the first example below, the multicast stream consists of two RTP 180 streams, each duplicated once, resulting in two sets of two-stream 181 groups. The same duplication delay of 100 ms is applied to each 182 grouping. The first set's streams have SSRCs of 1000 and 1010 and 183 the second set's streams have SSRCs of 1020 and 1030. 185 v=0 186 o=ali 1122334455 1122334466 IN IP4 dup.example.com 187 s=Delayed Duplication 188 t=0 0 189 m=video 30000 RTP/AVP 100 101 190 c=IN IP4 233.252.0.1/127 191 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 192 a=rtpmap:100 MP2T/90000 193 a=ssrc:1000 cname:ch1a@example.com 194 a=ssrc:1010 cname:ch1a@example.com 195 a=ssrc-group:DUP 1000 1010 196 a=rtpmap:101 MP2T/90000 197 a=ssrc:1020 cname:ch1b@example.com 198 a=ssrc:1030 cname:ch1b@example.com 199 a=ssrc-group:DUP 1020 1030 200 a=duplication-delay:100 201 a=mid:Ch1 203 Note that in actual use, SSRC values, which are random 32-bit 204 numbers, could be much larger than the ones shown in this example. 206 In the second example below, the multicast stream is duplicated 207 twice. 50 ms after the original transmission, the first duplicate is 208 transmitted and 100 ms after that, the second duplicate is 209 transmitted. In other words, the same packet is transmitted three 210 times over a period of 150 ms. 212 v=0 213 o=ali 1122334455 1122334466 IN IP4 dup.example.com 214 s=Delayed Duplication 215 t=0 0 216 m=video 30000 RTP/AVP 100 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=rtpmap:100 MP2T/90000 220 a=ssrc:1000 cname:ch1c@example.com 221 a=ssrc:1010 cname:ch1c@example.com 222 a=ssrc:1020 cname:ch1c@example.com 223 a=ssrc-group:DUP 1000 1010 1020 224 a=duplication-delay:50 100 225 a=mid:Ch1 227 In the third example below, the multicast UDP stream is duplicated 228 with a duplication delay of 50 ms. Redundant streams are sent in 229 separate source-specific multicast (SSM) sessions so the receiving 230 host has to join both SSM sessions if it wants to receive both 231 streams. 233 v=0 234 o=ali 1122334455 1122334466 IN IP4 dup.example.com 235 s=Delayed Duplication 236 t=0 0 237 a=group:DUP S1a S1b 238 a=duplication-delay:50 239 m=audio 30000 udp mp4 240 c=IN IP4 233.252.0.1/127 241 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 242 a=mid:S1a 243 m=audio 40000 udp mp4 244 c=IN IP4 233.252.0.2/127 245 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 246 a=mid:S1b 248 5. Security Considerations 250 The 'duplication-delay' attribute is not believed to introduce any 251 significant security risk to multimedia applications. A malevolent 252 third party could use this attribute to misguide the receiver(s) 253 about the duplication delays and/or the number of redundant streams. 254 For example, if the malevolent third party increases the value of the 255 duplication delay, the receiver(s) will unnecessarily incur a longer 256 delay since they will have to wait for the entire period. Or, if the 257 duplication delay is reduced by the malevolent third party, the 258 receiver(s) might not wait long enough for the duplicated 259 transmission and incur unnecessary packet losses. However, these 260 require intercepting and rewriting the packets carrying the SDP 261 description; and if an interceptor can do that, many more attacks are 262 also possible. 264 In order to avoid attacks of this sort, the SDP description needs to 265 be integrity protected and provided with source authentication. This 266 can, for example, be achieved on an end-to-end basis using S/MIME 267 [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME 268 types (application/sdp). Alternatively, HTTPS [RFC2818] or the 269 authentication method in the Session Announcement Protocol (SAP) 270 [RFC2974] could be used as well. 272 Another security risk is due to possible software misconfiguration or 273 a software bug where a large number of duplicates could be 274 unwillingly signaled in the 'duplication-delay' attribute. 275 Similarly, an attacker can use this attribute to start a denial-of- 276 service attack by signaling and sending too many duplicated streams. 277 In applications where this attribute is to be used, it is a good 278 practice to put a hard limit both on the number of duplicate streams 279 and the total delay introduced due to duplication regardless of what 280 the SDP description specifies. 282 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", draft- 333 ietf-mmusic-duplication-grouping-01 (work in progress), 334 March 2013. 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 368 Ali Begen 369 Cisco 370 181 Bay Street 371 Toronto, ON M5J 2T3 372 Canada 374 Email: abegen@cisco.com 376 Yiqun Cai 377 Microsoft 378 1065 La Avenida 379 Mountain View, CA 94043 380 USA 382 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