idnits 2.17.1 draft-ietf-avtext-rtp-duplication-00.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 (July 2, 2012) is 4308 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTEXT A. Begen 3 Internet-Draft Cisco 4 Intended status: Standards Track C. Perkins 5 Expires: January 3, 2013 University of Glasgow 6 July 2, 2012 8 Duplicating RTP Streams 9 draft-ietf-avtext-rtp-duplication-00 11 Abstract 13 Packet loss is undesirable for real-time multimedia sessions, but can 14 occur due to congestion, or other unplanned network outages. This is 15 especially true for IP multicast networks, where packet loss patterns 16 can vary greatly between receivers. One technique that can be used 17 to recover from packet loss without incurring unbounded delay for all 18 the receivers is to duplicate the packets and send them in separate 19 redundant streams. This document explains how Real-time Transport 20 Protocol (RTP) streams can be duplicated without breaking RTP media 21 streams, or RTP Control Protocol (RTCP) rules. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 3, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Requirements Notation . . . . . . . . . . . . 3 59 3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . . 3 60 3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4 61 3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5 63 4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . . 6 64 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6 65 4.2. Signaling Considerations . . . . . . . . . . . . . . . . . 6 66 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 7 67 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 68 5.2. Signaling Considerations . . . . . . . . . . . . . . . . . 8 69 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The Real-time Transport Protocol (RTP) [RFC3550] is widely used today 81 for delivering IPTV traffic, and other real-time multimedia sessions. 82 Many of these applications support very large numbers of receivers, 83 and rely on intra-domain UDP/IP multicast for efficient distribution 84 of traffic within the network. 86 While this combination has proved successful, there does exist a 87 weakness. As [RFC2354] noted, packet loss is not avoidable, even in 88 a carefully managed network. This loss might be due to congestion, 89 it might also be a result of an unplanned outage caused by a flapping 90 link, link or interface failure, a software bug, or a maintenance 91 person accidentally cutting the wrong fiber. Since UDP/IP flows do 92 not provide any means for detecting loss and retransmitting packets, 93 it leaves up to the RTP layer and the applications to detect, and 94 recover from, packet loss. 96 One technique to recover from packet loss without incurring unbounded 97 delay for all the receivers is to duplicate the packets and send them 98 in separate redundant streams. Variations on this idea have been 99 implemented and deployed today [IC2011]. However, duplication of RTP 100 streams without breaking the RTP and RTCP functionality has not been 101 documented properly. This document explains how duplication can be 102 achieved for RTP streams. 104 Stream duplication offers a simple way to protect media flows from 105 packet loss. It has a comparatively high bandwidth overhead, since 106 everything is sent twice, but with a low processor overhead. It is 107 also very predictable in its overheads. Alternative approaches may 108 be suitable in some cases, for example retransmission-based recovery 109 [RFC4588] or forward error correction [RFC5109]. 111 2. Terminology and Requirements Notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 [RFC2119]. 118 3. Dual Streaming Use Cases 120 Dual streaming refers to a technique that involves transmitting two 121 redundant RTP streams of the same content, with each stream capable 122 of supporting the playback when there is no packet loss. Therefore, 123 adding an additional RTP stream provides a protection against packet 124 loss. The level of protection depends on how the packets are sent 125 and transmitted inside the network. 127 It is important to note that dual streaming can easily be extended to 128 support cases when more than two streams are desired. However, using 129 three or more streams is rare in practise, due to the high overhead 130 that it incurs. 132 3.1. Temporal Redundancy 134 From a routing perspective, two streams are considered identical if 135 the following two IP header fields are the same, since they will be 136 both routed over the same path: 138 o IP Source Address 140 o IP Destination Address 142 Two routing-plane identical RTP streams might carry the same payload, 143 but can use different Synchronization Sources (SSRC) to differentiate 144 the RTP packets belonging to each stream. In the context of dual RTP 145 streaming, we assume that the source duplicates the RTP packets and 146 sends them in separate RTP streams, each with a unique SSRC. All the 147 redundant streams are transmitted in the same RTP session. 149 For example, one main and one redundant RTP stream can be sent to the 150 same IP destination address and UDP destination port with a certain 151 delay between them [I-D.begen-mmusic-temporal-interleaving]. The 152 streams carry the same payload in their respective RTP packets with 153 identical sequence numbers. This allows receivers (or other nodes 154 responsible for gap filling and duplicate suppression) to identify 155 and suppress the duplicate packets, and subsequently produce a 156 hopefully loss-free and duplication-free output stream. This process 157 is called stream merging. 159 3.2. Spatial Redundancy 161 An RTP source might be associated with multiple network interfaces, 162 allowing it to send two redundant streams from two separate source 163 addresses. Such streams can be routed over diverse or identical 164 paths depending on the routing algorithm used inside the network. At 165 the receiving end, the node responsible for duplicate suppression can 166 look into various RTP header fields, for example SSRC and sequence 167 number, to identify and suppress the duplicate packets. 169 If source-specific multicast (SSM) transport is used to carry such 170 redundant streams, there will be a separate SSM session for each 171 redundant stream since the streams are sourced from different 172 interfaces (i.e., IP addresses). Thus, the receiving host has to 173 join each SSM session separately. 175 Alternatively, an RTP source might send the redundant streams to 176 separate IP destination addresses. 178 3.3. Dual Streaming over a Single Path or Multiple Paths 180 Having described the characteristics of the streams, one can reach 181 the following conclusions: 183 1. When two routing-plane identical streams are used, the two 184 streams will have identical IP headers. This makes it 185 impractical to forward the packets onto different paths. In 186 order to minimize packet loss, the packets belonging to one 187 stream are often interleaved with packets belonging to the other, 188 and with a delay, so that if there is a packet loss, such a delay 189 would allow the same packet from the other stream to reach the 190 receiver because the chances that the same packet is lost in 191 transit again is often small. This is what is also known as 192 Time-shifted Redundancy, Temporal Redundancy or simply Delayed 193 Duplication [I-D.begen-mmusic-temporal-interleaving] [IC2011]. 194 This approach can be used with both types of dual streaming, 195 described in Section 3.1 and Section 3.2. 197 2. If the two streams have different IP headers, an additional 198 opportunity arises in that one is able to build a network, with 199 physically diverse paths, to deliver the two streams concurrently 200 to the intended receivers. This reduces the delay when packet 201 loss occurs and needs to be recovered. Additionally, it also 202 further reduces chances for packet loss. An unrecoverable loss 203 happens only when two network failures happen in such a way that 204 the same packet is affected on both paths. This is referred to 205 as Spatial Diversity or Spatial Redundancy [IC2011]. The 206 techniques used to build diverse paths are beyond the scope of 207 this document. 209 Note that spatial redundancy often offers less delay in 210 recovering from packet loss provided that the forwarding delay of 211 the network paths are more or less the same. For both temporal 212 and spatial redundancy approaches, packet misordering might still 213 happen and needs to be handled using the sequence numbers of some 214 sort (e.g., RTP sequence numbers). 216 To summarize, dual streaming allows an application and a network to 217 work together to provide a near zero-loss transport with a bounded or 218 minimum delay. The additional advantage includes a predictable 219 bandwidth overhead that is proportional to the minimum bandwidth 220 needed for the multimedia session, but independent of the number of 221 receivers experiencing a packet loss and requesting a retransmission. 222 For a survey and comparison of similar approaches, refer to [IC2011]. 224 4. Use of RTP and RTCP with Temporal Redundancy 226 To achieve temporal redundancy, the main and redundant RTP streams 227 MUST be sent using the same 5-tuple of transport protocol, source and 228 destination IP addresses, and source and destination transport ports. 229 This is perhaps overly restrictive, but with the possible presence of 230 network address and port translation (NAPT) devices, using anything 231 other than an identical 5-tuple can also cause spatial redundancy. 233 Since main and redundant RTP streams follow an identical path, they 234 are part of the same RTP session. Accordingly, the sender MUST 235 choose a different SSRC for the redundant RTP stream than it chose 236 for the main RTP stream, following the rules in [RFC3550] Section 8. 238 4.1. RTCP Considerations 240 If RTCP is being sent for the main RTP stream, then the sender MUST 241 also generate RTCP for the redundant RTP stream. The RTCP for the 242 redundant RTP stream is generated exactly as-if the redundant RTP 243 stream were a regular media stream. The sender MUST NOT duplicate 244 the RTCP packets sent for the main RTP stream when sending the 245 duplicate stream, instead it MUST generate new RTCP reports for the 246 duplicate stream. The sender MUST use the same RTCP CNAME in the 247 RTCP reports it sends for the main and redundant streams, so that the 248 receiver can synchronize them. 250 Both the main and redundant RTP streams, and their corresponding RTCP 251 reports, will be received. If RTCP is used, receivers MUST generate 252 RTCP reports for both main and redundant streams in the usual way, 253 treating them as entirely separate media streams. 255 4.2. Signaling Considerations 257 Signaling is needed to allow the receiver to determine that an RTP 258 stream is a redundant copy of another, rather than a separate stream 259 that needs to be rendered in parallel. There are two parts to this: 260 an SDP extension is needed in the offer/answer exchange to negotiate 261 support for temporal redundancy; and signalling is needed to indicate 262 which stream is the duplicate (the latter can be done in-band using 263 an RTCP extension, or out-of-band by signalling the SSRCs used by the 264 duplicate streams in SDP). 266 We require out-of-band signalling for both features. The required 267 SDP attribute to signal duplication in the SDP offer/answer exchange 268 ('duplication-delay') is defined in 269 [I-D.begen-mmusic-temporal-interleaving]. The required SDP grouping 270 semantics are defined in [I-D.begen-mmusic-redundancy-grouping]. 272 In the following SDP example, a video stream is duplicated, and the 273 main and redundant streams are transmitted in two separate SSRCs 274 (1000 and 1010): 276 v=0 277 o=ali 1122334455 1122334466 IN IP4 dup.example.com 278 s=Delayed Duplication 279 t=0 0 280 m=video 30000 RTP/AVP 100 281 c=IN IP4 233.252.0.1/127 282 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 283 a=rtpmap:100 MP2T/90000 284 a=ssrc:1000 cname:ch1@example.com 285 a=ssrc:1010 cname:ch1@example.com 286 a=ssrc-group:DUP 1000 1010 287 a=duplication-delay:100 288 a=mid:Group1 290 It is RECOMMENDED that the SSRC listed first in the "a=ssrc-group:" 291 line is sent first, with the other RTP SSRC being the time-delayed 292 duplicate. This is not critical, however, and receivers should size 293 their playout buffers based on the "a=duplication-delay:" attribute, 294 and play the stream that arrives first in preference, with the other 295 stream acting as a repair stream, irrespective of the order in which 296 they are signalled. 298 5. Use of RTP and RTCP with Spatial Redundancy 300 When using spatial redundancy, the redundant RTP stream is sent on 301 using a different source and/or destination address/port pair. This 302 will be a separate RTP session to the session conveying the main RTP 303 stream. 305 The SSRCs used for the main and redundant streams MUST be chosen 306 randomly, following the rules in Section 8 of [RFC3550]. 307 Accordingly, they will almost certainly not match each other. The 308 sender MUST, however, use the same RTCP CNAME for both the main and 309 redundant streams, and MUST include an "a=ssrc:... srcname:..." 310 attribute to correlate the flows. An "a=group:DUP" attribute is used 311 to indicate duplication. 313 5.1. RTCP Considerations 315 If RTCP is being sent for the main RTP stream, then the sender MUST 316 also generate RTCP for the redundant RTP stream. The RTCP for the 317 redundant RTP stream is generated exactly as-if the redundant RTP 318 stream were a regular media stream; the sender MUST NOT duplicate the 319 RTCP packets sent for the main RTP stream. The sender MUST use the 320 same RTCP CNAME in the RTCP reports it sends for the main and 321 redundant streams, so that the receiver can synchronize them. 323 The main and redundant streams are conceptually synchronised using 324 the standard RTCP SR-based mechanism, deriving a mapping between 325 their timelines. The RTP timestamps and sequence numbers SHOULD be 326 identical in the main and redundant streams, however, making the 327 mapping trivial in most cases. 329 Both main and redundant streams, and their corresponding RTCP, will 330 be received. If RTCP is used, receivers MUST generate RTCP reports 331 for both main and redundant streams in the usual way, treating them 332 as entirely separate media streams. 334 5.2. Signaling Considerations 336 The required SDP grouping semantics have been defined in 337 [I-D.begen-mmusic-redundancy-grouping]. In the following example, 338 the redundant streams have different IP destination addresses. The 339 example shows the same UDP port number and IP source addresses, but 340 either or both could have been different for the two streams. 342 v=0 343 o=ali 1122334455 1122334466 IN IP4 dup.example.com 344 s=DUP Grouping Semantics 345 t=0 0 346 a=group:DUP S1a S1b 347 m=video 30000 RTP/AVP 100 348 c=IN IP4 233.252.0.1/127 349 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 350 a=rtpmap:100 MP2T/90000 351 a=ssrc:1000 cname:ch1@example.com 352 a=ssrc:1000 srcname:45:a8:f4:19:b4:c3 353 a=mid:S1a 354 m=video 30000 RTP/AVP 101 355 c=IN IP4 233.252.0.2/127 356 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 357 a=rtpmap:101 MP2T/90000 358 a=ssrc:1010 cname:ch1@example.com 359 a=ssrc:1010 srcname:45:a8:f4:19:b4:c3 360 a=mid:S1b 362 6. Use of RTP and RTCP with Temporal and Spatial Redundancy 364 This uses the same RTP/RTCP mechanisms, plus a combination of both 365 sets of signaling. 367 7. Security Considerations 369 The security considerations of [RFC3550], 370 [I-D.begen-mmusic-temporal-interleaving], and 371 [I-D.begen-mmusic-redundancy-grouping] apply. 373 If stream de-duplication is done by an in-network middlebox, rather 374 than by an end system, that middlebox can work if Secure RTP (SRTP) 375 encryption is used [RFC3711], since the RTP headers are in the clear. 376 Doing so would break the authentication when the SSRC is rewritten, 377 unless the de-duplication middlebox were trusted to re-authenticate 378 the packets. This would require additional signalling which is not 379 specified here, since de-duplication in the receiver end system is 380 expected to be the more common use case. 382 8. IANA Considerations 384 No IANA actions are required. 386 9. Acknowledgments 388 Thanks to Magnus Westerlund for his suggestions. 390 10. References 392 10.1. Normative References 394 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 395 Jacobson, "RTP: A Transport Protocol for Real-Time 396 Applications", STD 64, RFC 3550, July 2003. 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [I-D.begen-mmusic-temporal-interleaving] 402 Begen, A., Cai, Y., and H. Ou, "Delayed Duplication 403 Attribute in the Session Description Protocol", 404 draft-begen-mmusic-temporal-interleaving-04 (work in 405 progress), March 2012. 407 [I-D.begen-mmusic-redundancy-grouping] 408 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 409 Semantics in the Session Description Protocol", 410 draft-begen-mmusic-redundancy-grouping-03 (work in 411 progress), March 2012. 413 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 414 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 415 RFC 3711, March 2004. 417 10.2. Informative References 419 [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of 420 Streaming Media", RFC 2354, June 1998. 422 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 423 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 424 July 2006. 426 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 427 Correction", RFC 5109, December 2007. 429 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 430 "Toward Lossless Video Transport (to appear in IEEE 431 Internet Computing)", November 2011. 433 Authors' Addresses 435 Ali Begen 436 Cisco 437 181 Bay Street 438 Toronto, ON M5J 2T3 439 CANADA 441 Email: abegen@cisco.com 443 Colin Perkins 444 University of Glasgow 445 School of Computing Science 446 Glasgow, G12 8QQ 447 UK 449 Email: csp@csperkins.org