idnits 2.17.1 draft-ietf-avtext-rtp-duplication-06.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 (February 20, 2014) is 3718 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: August 24, 2014 University of Glasgow 6 February 20, 2014 8 Duplicating RTP Streams 9 draft-ietf-avtext-rtp-duplication-06 11 Abstract 13 Packet loss is undesirable for real-time multimedia sessions, but can 14 occur due to a variety of reasons including unplanned network 15 outages. In unicast transmissions, recovering from such an outage 16 can be difficult depending on the outage duration due to the 17 potential large number of missing packets. In multicast 18 transmissions, recovery is even more challenging as many receivers 19 could be impacted by the outage. One solution to this challenge 20 without incurring unbounded delay is to duplicate the packets and 21 send them in separate redundant streams, provided that the underlying 22 network satisfies certain requirements. This document explains how 23 Real-time Transport Protocol (RTP) streams can be duplicated without 24 breaking RTP or RTP Control Protocol (RTCP) rules. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 24, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Requirements Notation . . . . . . . . . . . . 3 62 3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3 63 3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4 64 3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4 65 3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5 66 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6 68 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6 69 4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7 70 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8 71 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 72 5.2. Signaling Considerations . . . . . . . . . . . . . . . . 9 73 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9 74 7. Congestion Control Considerations . . . . . . . . . . . . . . 9 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 11.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 The Real-time Transport Protocol (RTP) [RFC3550] is widely used today 86 for delivering IPTV traffic, and other real-time multimedia sessions. 87 Many of these applications support very large numbers of receivers, 88 and rely on intra-domain UDP/IP multicast for efficient distribution 89 of traffic within the network. 91 While this combination has proved successful, there does exist a 92 weakness. As [RFC2354] noted, packet loss is not avoidable. This 93 loss might be due to congestion; it might also be a result of an 94 unplanned outage caused by a flapping link, link or interface 95 failure, a software bug, or a maintenance person accidentally cutting 96 the wrong fiber. Since UDP/IP flows do not provide any means for 97 detecting loss and retransmitting packets, it is left up to the RTP 98 layer and the applications to detect, and recover from, packet loss. 100 In a carefully managed network, congestion should not normally 101 happen, however, network outages can still happen due to the reasons 102 listed above. In such a managed network, one technique to recover 103 from packet loss without incurring unbounded delay is to duplicate 104 the packets and send them in separate redundant streams. As 105 described later in this document, the probability that two copies of 106 the same packet are lost in cases of non-congestive packet loss is 107 quite small. 109 Variations on this idea have been implemented and deployed today 110 [IC2011]. However, duplication of RTP streams without breaking the 111 RTP and RTCP functionality has not been documented properly. This 112 document discusses the most common use cases and explains how 113 duplication can be achieved for RTP streams in such use cases to 114 address the immediate market needs. In the future, if there will be 115 a different use case, which is not covered by this document, a new 116 specification that explains how RTP duplication should be done in 117 such a scenario may be needed. 119 Stream duplication offers a simple way to protect media flows from 120 packet loss. It has a comparatively high bandwidth overhead, since 121 everything is sent twice, but with a low processing overhead. It is 122 also very predictable in its overheads. Alternative approaches, for 123 example, retransmission-based recovery [RFC4588] or Forward Error 124 Correction [RFC6363], may be suitable in some other cases. 126 2. Terminology and Requirements Notation 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 [RFC2119]. 133 3. Dual Streaming Use Cases 135 Dual streaming refers to a technique that involves transmitting two 136 redundant RTP streams (the original plus its duplicate) of the same 137 content, with each stream capable of supporting the playback when 138 there is no packet loss. Therefore, adding an additional RTP stream 139 provides a protection against packet loss. The level of protection 140 depends on how the packets are sent and transmitted inside the 141 network. 143 It is important to note that dual streaming can easily be extended to 144 support cases when more than two streams are desired. However, using 145 three or more streams is rare in practice, due to the high overhead 146 that it incurs and the little additional protection it provides. 148 3.1. Temporal Redundancy 150 From a routing perspective, two streams are considered identical if 151 the following two IP header fields are the same (in addition to the 152 transport ports), since they will be both routed over the same path: 154 o IP Source Address 156 o IP Destination Address 158 Two routing-plane identical RTP streams might carry the same payload, 159 but can use different Synchronization Sources (SSRC) to differentiate 160 the RTP packets belonging to each stream. In the context of dual RTP 161 streaming, we assume that the sender duplicates the RTP packets and 162 sends them in separate RTP streams, each with a unique SSRC. All the 163 redundant streams are transmitted in the same RTP session. 165 For example, one main stream and its duplicate stream can be sent to 166 the same IP destination address and UDP destination port with a 167 certain delay between them [I-D.ietf-mmusic-delayed-duplication]. 168 The streams carry the same payload in their respective RTP packets 169 with identical sequence numbers. This allows receivers (or other 170 nodes responsible for gap filling and duplicate suppression) to 171 identify and suppress the duplicate packets, and subsequently produce 172 a hopefully loss-free and duplication-free output stream. This 173 process is commonly called stream merging or de-duplication. 175 3.2. Spatial Redundancy 177 An RTP source might be associated with multiple network interfaces, 178 allowing it to send two redundant streams from two separate source 179 addresses. Such streams can be routed over diverse or identical 180 paths depending on the routing algorithm used inside the network. At 181 the receiving end, the node responsible for duplicate suppression can 182 look into various RTP header fields, for example SSRC and sequence 183 number, to identify and suppress the duplicate packets. 185 If source-specific multicast (SSM) transport is used to carry such 186 redundant streams, there will be a separate SSM session for each 187 redundant stream since the streams are sourced from different 188 interfaces (i.e., IP addresses). Thus, the receiving host has to 189 join each SSM session separately. 191 Alternatively, destination host could also have multiple IP addresses 192 for an RTP source to send the redundant streams to. 194 3.3. Dual Streaming over a Single Path or Multiple Paths 196 Having described the characteristics of the streams, one can reach 197 the following conclusions: 199 1. When two routing-plane identical streams are used, the flow 200 labels will be the same. This makes it impractical to forward 201 the packets onto different paths. In order to minimize packet 202 loss, the packets belonging to one stream are often interleaved 203 with packets belonging to its duplicate stream, and with a delay, 204 so that if there is a packet loss, such a delay would allow the 205 same packet from the duplicate stream to reach the receiver 206 because the chances that the same packet is lost in transit again 207 is often small. This is what is also known as Time-shifted 208 Redundancy, Temporal Redundancy or simply Delayed Duplication 209 [I-D.ietf-mmusic-delayed-duplication] [IC2011]. This approach 210 can be used with both types of dual streaming, described in 211 Section 3.1 and Section 3.2. 213 2. If the two streams have different IP headers, an additional 214 opportunity arises in that one is able to build a network, with 215 physically diverse paths, to deliver the two streams concurrently 216 to the intended receivers. This reduces the delay when packet 217 loss occurs and needs to be recovered. Additionally, it also 218 further reduces chances for packet loss. An unrecoverable loss 219 happens only when two network failures happen in such a way that 220 the same packet is affected on both paths. This is referred to 221 as Spatial Diversity or Spatial Redundancy [IC2011]. The 222 techniques used to build diverse paths are beyond the scope of 223 this document. 225 Note that spatial redundancy often offers less delay in 226 recovering from packet loss provided that the forwarding delay of 227 the network paths are more or less the same (This is often made 228 sure through careful network design). For both temporal and 229 spatial redundancy approaches, packet misordering might still 230 happen and needs to be handled using the sequence numbers of some 231 sort (e.g., RTP sequence numbers). 233 Temporal and spatial redundancy deal with different patterns of 234 packet loss. The former helps with transient loss (within the 235 duplication window), while the latter helps with longer-term packet 236 loss that affects only one of the two redundant paths. 238 To summarize, dual streaming allows an application and a network to 239 work together to provide a near zero-loss transport with a bounded or 240 minimum delay. The additional advantage includes a predictable 241 bandwidth overhead that is proportional to the minimum bandwidth 242 needed for the multimedia session, but independent of the number of 243 receivers experiencing a packet loss and requesting a retransmission. 244 For a survey and comparison of similar approaches, refer to [IC2011]. 246 3.4. Requirements 248 One of the following conditions is currently REQUIRED to hold in 249 applications using this specification: 251 o The original and duplicate RTP streams are carried (with their own 252 SSRCs) in the same "m" line (There could be other RTP streams 253 listed in the same "m" line). 255 o The original and duplicate RTP streams are carried in separate "m" 256 lines and there is no other RTP stream listed in either "m" line. 258 When the original and duplicate RTP streams are carried in separate 259 "m" lines in a Session Description Protocol (SDP) description and if 260 the SDP description has one or more other RTP streams listed in 261 either "m" line, duplication grouping is not trivial and further 262 signaling will be needed, which is left for future standardization. 264 4. Use of RTP and RTCP with Temporal Redundancy 266 To achieve temporal redundancy, the main and duplicate RTP streams 267 SHOULD be sent using the sample 5-tuple of transport protocol, source 268 and destination IP addresses, and source and destination transport 269 ports. Due to the possible presence of network address and port 270 translation (NAPT) devices, load balancers, or other middleboxes, use 271 of anything other than an identical 5-tuple and flow label might also 272 cause spatial redundancy (which might introduce an additional delay 273 due to the delta between the path delays), and so is NOT RECOMMENDED 274 unless the path is known to be free of such middleboxes. 276 Since the main and duplicate RTP streams follow an identical path, 277 they are part of the same RTP session. Accordingly, the sender MUST 278 choose a different SSRC for the duplicate RTP stream than it chose 279 for the main RTP stream, following the rules in [RFC3550] Section 8. 281 4.1. RTCP Considerations 283 If RTCP is being sent for the main RTP stream, then the sender MUST 284 also generate RTCP for the duplicate RTP stream. The RTCP for the 285 duplicate RTP stream is generated exactly as-if the duplicate RTP 286 stream were a regular media stream. The sender MUST NOT duplicate 287 the RTCP packets sent for the main RTP stream when sending the 288 duplicate stream, instead it MUST generate new RTCP reports for the 289 duplicate stream. The sender MUST use the same RTCP CNAME in the 290 RTCP reports it sends for both streams, so that the receiver can 291 synchronize them. 293 The main and duplicate streams are conceptually synchronized using 294 the standard RTCP Sender Report-based mechanism, deriving a mapping 295 between their timelines. However, the RTP timestamps and sequence 296 numbers MUST be identical in the main and duplicate streams, making 297 the mapping quite trivial. 299 Both the main and duplicate RTP streams, and their corresponding RTCP 300 reports, will be received. If RTCP is used, receivers MUST generate 301 RTCP reports for both the main and duplicate streams in the usual 302 way, treating them as entirely separate media streams. 304 4.2. Signaling Considerations 306 Signaling is needed to allow the receiver to determine that an RTP 307 stream is a duplicate of another, rather than a separate stream that 308 needs to be rendered in parallel. There are two parts to this: an 309 SDP extension is needed in the offer/answer exchange to negotiate 310 support for temporal redundancy; and signaling is needed to indicate 311 which stream is the duplicate (the latter can be done in-band using 312 an RTCP extension, or out-of-band in the SDP description). 314 Out-of-band signalling is needed for both features. The SDP 315 attribute to signal duplication in the SDP offer/answer exchange 316 ('duplication-delay') is defined in 317 [I-D.ietf-mmusic-delayed-duplication]. The required SDP grouping 318 semantics are defined in [RFC7104]. 320 In the following SDP example, a video stream is duplicated, and the 321 main and duplicate streams are transmitted in two separate SSRCs 322 (1000 and 1010): 324 v=0 325 o=ali 1122334455 1122334466 IN IP4 dup.example.com 326 s=Delayed Duplication 327 t=0 0 328 m=video 30000 RTP/AVP 100 329 c=IN IP4 233.252.0.1/127 330 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 331 a=rtpmap:100 MP2T/90000 332 a=ssrc:1000 cname:ch1a@example.com 333 a=ssrc:1010 cname:ch1a@example.com 334 a=ssrc-group:DUP 1000 1010 335 a=duplication-delay:50 336 a=mid:Ch1 338 Section 3.2 of [RFC7104] states that it is advisable that the SSRC 339 listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent 340 first, with the other SSRC (i.e., SSRC of 1010) being the time- 341 delayed duplicate. This is not critical, however, and a receiving 342 host should size its playout buffer based on the 'duplication-delay' 343 attribute, and play the stream that arrives first in preference, with 344 the other stream acting as a repair stream, irrespective of the order 345 in which they are signaled. 347 5. Use of RTP and RTCP with Spatial Redundancy 349 Assuming the network is structured appropriately, when using spatial 350 redundancy, the duplicate RTP stream is sent using a different source 351 and/or destination address/port pair. This will be a separate RTP 352 session to the session conveying the main RTP stream. Thus, the 353 SSRCs used for the main and duplicate streams MUST be chosen 354 randomly, following the rules in Section 8 of [RFC3550]. 355 Accordingly, they will almost certainly not match each other. The 356 sender MUST, however, use the same RTCP CNAME for both the main and 357 duplicate streams. An "a=group:DUP" line or "a=ssrc-group:DUP" line 358 is used to indicate duplication. 360 5.1. RTCP Considerations 362 If RTCP is being sent for the main RTP stream, then the sender MUST 363 also generate RTCP for the duplicate RTP stream. The RTCP for the 364 duplicate RTP stream is generated exactly as-if the duplicate RTP 365 stream were a regular media stream. The sender MUST NOT duplicate 366 the RTCP packets sent for the main RTP stream when sending the 367 duplicate stream, instead it MUST generate new RTCP reports for the 368 duplicate stream. The sender MUST use the same RTCP CNAME in the 369 RTCP reports it sends for both streams, so that the receiver can 370 synchronize them. 372 The main and duplicate streams are conceptually synchronized using 373 the standard RTCP Sender Report-based mechanism, deriving a mapping 374 between their timelines. However, the RTP timestamps and sequence 375 numbers MUST be identical in the main and duplicate streams, making 376 the mapping quite trivial. 378 Both the main and duplicate RTP streams, and their corresponding RTCP 379 reports, will be received. If RTCP is used, receivers MUST generate 380 RTCP reports for both the main and duplicate streams in the usual 381 way, treating them as entirely separate media streams. 383 5.2. Signaling Considerations 385 The required SDP grouping semantics have been defined in [RFC7104]. 386 In the following example, the redundant streams have different IP 387 destination addresses. The example shows the same UDP port number 388 and IP source address for each stream, but either or both could have 389 been different for the two streams. 391 v=0 392 o=ali 1122334455 1122334466 IN IP4 dup.example.com 393 s=DUP Grouping Semantics 394 t=0 0 395 a=group:DUP S1a S1b 396 m=video 30000 RTP/AVP 100 397 c=IN IP4 233.252.0.1/127 398 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 399 a=rtpmap:100 MP2T/90000 400 a=mid:S1a 401 m=video 30000 RTP/AVP 101 402 c=IN IP4 233.252.0.2/127 403 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 404 a=rtpmap:101 MP2T/90000 405 a=mid:S1b 407 6. Use of RTP and RTCP with Temporal and Spatial Redundancy 409 This uses the same RTP/RTCP mechanisms from Sections Section 4 and 410 Section 5, plus a combination of both sets of signaling. 412 7. Congestion Control Considerations 414 Duplicating RTP streams has several considerations in the context of 415 congestion control. First of all, RTP duplication MUST NOT be used 416 in cases where the primary cause of packet loss is congestion since 417 duplication can make congestion only worse. Furthermore, RTP 418 duplication SHOULD NOT be used where there is a risk of congestion 419 upon duplicating an RTP stream. Duplication is RECOMMENDED only to 420 be used for protection against network outages due to a temporary 421 link or network element failure and where it is known (e.g., through 422 explicit operator configuration) that there is sufficient network 423 capacity to carry the duplicated traffic. The capacity requirement 424 constrains the use of duplication to managed networks, and makes it 425 unsuitable for use on unmanaged public networks. 427 It is essential that the nodes responsible for the duplication and 428 de-duplication are aware of the original stream's requirements and 429 the available capacity inside the network. If there is an adaptation 430 capability for the original stream, these nodes have to assume the 431 same adaptation capability for the duplicated stream, too. For 432 example, if the source doubles the bitrate for the original stream, 433 the bitrate of the duplicate stream will also be doubled. 435 Depending on where de-duplication takes place, there could be 436 different scenarios. When the duplication and de-duplication takes 437 place inside the network before the ultimate end-points that will 438 consume the RTP media, the whole process is transparent to these end- 439 points. Thus, these end-points will apply any congestion control, if 440 applicable, on the de-duplicated RTP stream. This output stream will 441 have less losses than either of the original and duplicated stream, 442 and the end-point will make congestion control decisions accordingly. 443 However, if de-duplication takes place at the ultimate end-point, 444 this end-point MUST consider the aggregate of the original and 445 duplicated RTP stream in any congestion control it wants to apply. 446 The end-point will observe the losses in each stream separately, and 447 this information can be used to fine-tune the duplication process. 448 For example, the duplication interval can be adjusted based on the 449 duration of a common packet loss in both streams. In these 450 scenarios, the RTP Monitoring Framework[RFC6792] can be used to 451 monitor the duplicated streams in the same way an ordinary RTP would 452 be monitored. 454 8. Security Considerations 456 The security considerations of [RFC3550], 457 [I-D.ietf-mmusic-delayed-duplication], [RFC7104], and any RTP 458 profiles and payload formats in use apply. 460 Duplication can be performed end-to-end, with the media sender 461 generating a duplicate RTP stream, and the receiver(s) performing de- 462 duplication. In such cases, if the original media stream is to be 463 authenticated (e.g., using SRTP [RFC3711]) then the duplicate stream 464 also needs to be authenticated, and duplicate packets that fail the 465 authentication check need to be discarded. 467 Stream duplication and de-duplication can also be performed by in- 468 network middleboxes. Such middleboxes will need to rewrite the RTP 469 SSRC such that the RTP packets in the duplicate stream have a 470 different SSRC to the original stream, and will need to generate and 471 respond to RTCP packets corresponding to the duplicate stream. This 472 sort of in-network duplication service has the potential to act as an 473 amplifier for denial-of-service attacks if the attacker can cause 474 attack traffic to be duplicated. To prevent this, middleboxes 475 providing the duplication service need to authenticate the traffic to 476 be duplicated as being from a legitimate source, for example using 477 the secure RTP (SRTP) profile [RFC3711]. This requires the middlebox 478 to be part of the security context of the media session being 479 duplicated, so it has access to the necessary keying material for 480 authentication. To do this, the middlebox will need to be privy to 481 the session set-up signalling. Details of how that is done will 482 depend on the type of signalling used (SIP, RTSP, WebRTC, etc.), and 483 is not specified here. 485 Similarly, to prevent packet injection attacks, a de-duplication 486 middlebox needs to authenticate original and duplicate streams, and 487 ought not use non-authenticated packets that are received. Again, 488 this requires the middlebox to be part of the security context, and 489 have access to the appropriate signalling and keying material. 491 The use of the encryption features of SRTP does not affect stream de- 492 duplication middleboxes, since the RTP headers are sent in the clear. 494 9. IANA Considerations 496 No IANA actions are required. 498 10. Acknowledgments 500 Thanks to Magnus Westerlund for his suggestions. 502 11. References 504 11.1. Normative References 506 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 507 Jacobson, "RTP: A Transport Protocol for Real-Time 508 Applications", STD 64, RFC 3550, July 2003. 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [I-D.ietf-mmusic-delayed-duplication] 514 Begen, A., Cai, Y., and H. Ou, "Delayed Duplication 515 Attribute in the Session Description Protocol", draft- 516 ietf-mmusic-delayed-duplication-03 (work in progress), 517 December 2013. 519 [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 520 Semantics in the Session Description Protocol", RFC 7104, 521 January 2014. 523 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 524 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 525 RFC 3711, March 2004. 527 11.2. Informative References 529 [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of 530 Streaming Media", RFC 2354, June 1998. 532 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 533 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 534 July 2006. 536 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 537 Correction (FEC) Framework", RFC 6363, October 2011. 539 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 540 RTP Monitoring Framework", RFC 6792, November 2012. 542 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 543 "Toward Lossless Video Transport (to appear in IEEE 544 Internet Computing)", November 2011. 546 Authors' Addresses 548 Ali Begen 549 Cisco 550 181 Bay Street 551 Toronto, ON M5J 2T3 552 CANADA 554 Email: abegen@cisco.com 555 Colin Perkins 556 University of Glasgow 557 School of Computing Science 558 Glasgow G12 8QQ 559 UK 561 Email: csp@csperkins.org 562 URI: http://orcid.org/0000-0002-3404-8964