idnits 2.17.1 draft-ietf-avtext-rtp-duplication-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 (October 02, 2013) is 3858 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) == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-delayed-duplication-02 == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-duplication-grouping-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: April 05, 2014 University of Glasgow 6 October 02, 2013 8 Duplicating RTP Streams 9 draft-ietf-avtext-rtp-duplication-04 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 or RTP 21 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 April 05, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology and Requirements Notation . . . . . . . . . . . . 3 59 3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3 60 3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 3 61 3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4 62 3.3. Dual Streaming over a Single Path or Multiple Paths . . . 4 63 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6 65 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6 66 4.2. Signaling Considerations . . . . . . . . . . . . . . . . 6 67 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8 68 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 69 5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8 70 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9 71 7. Congestion Control Considerations . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 11.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 The Real-time Transport Protocol (RTP) [RFC3550] is widely used today 83 for delivering IPTV traffic, and other real-time multimedia sessions. 84 Many of these applications support very large numbers of receivers, 85 and rely on intra-domain UDP/IP multicast for efficient distribution 86 of traffic within the network. 88 While this combination has proved successful, there does exist a 89 weakness. As [RFC2354] noted, packet loss is not avoidable, even in 90 a carefully managed network. This loss might be due to congestion, 91 it might also be a result of an unplanned outage caused by a flapping 92 link, link or interface failure, a software bug, or a maintenance 93 person accidentally cutting the wrong fiber. Since UDP/IP flows do 94 not provide any means for detecting loss and retransmitting packets, 95 it leaves up to the RTP layer and the applications to detect, and 96 recover from, packet loss. 98 One technique to recover from packet loss without incurring unbounded 99 delay for all the receivers is to duplicate the packets and send them 100 in separate redundant streams. Variations on this idea have been 101 implemented and deployed today [IC2011]. However, duplication of RTP 102 streams without breaking the RTP and RTCP functionality has not been 103 documented properly. This document discusses the most common use 104 cases and explains how duplication can be achieved for RTP streams in 105 such use cases to address the immediate market needs. In the future, 106 if there will be a different use case, which is not covered by this 107 document, a new specification that explains how RTP duplication 108 should be done in such a scenario may be needed. 110 Stream duplication offers a simple way to protect media flows from 111 packet loss. It has a comparatively high bandwidth overhead, since 112 everything is sent twice, but with a low processing overhead. It is 113 also very predictable in its overheads. Alternative approaches, for 114 example, retransmission-based recovery [RFC4588] or Forward Error 115 Correction [RFC6363], may be suitable in some other cases. 117 2. Terminology and Requirements Notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in 122 [RFC2119]. 124 3. Dual Streaming Use Cases 126 Dual streaming refers to a technique that involves transmitting two 127 redundant RTP streams (the original plus its duplicate) of the same 128 content, with each stream capable of supporting the playback when 129 there is no packet loss. Therefore, adding an additional RTP stream 130 provides a protection against packet loss. The level of protection 131 depends on how the packets are sent and transmitted inside the 132 network. 134 It is important to note that dual streaming can easily be extended to 135 support cases when more than two streams are desired. However, using 136 three or more streams is rare in practice, due to the high overhead 137 that it incurs and the little additional protection it provides. 139 3.1. Temporal Redundancy 141 From a routing perspective, two streams are considered identical if 142 the following two IP header fields are the same, since they will be 143 both routed over the same path: 145 o IP Source Address 146 o IP Destination Address 148 Two routing-plane identical RTP streams might carry the same payload, 149 but can use different Synchronization Sources (SSRC) to differentiate 150 the RTP packets belonging to each stream. In the context of dual RTP 151 streaming, we assume that the sender duplicates the RTP packets and 152 sends them in separate RTP streams, each with a unique SSRC. All the 153 redundant streams are transmitted in the same RTP session. 155 For example, one main stream and its duplicate stream can be sent to 156 the same IP destination address and UDP destination port with a 157 certain delay between them [I-D.ietf-mmusic-delayed-duplication]. 158 The streams carry the same payload in their respective RTP packets 159 with identical sequence numbers. This allows receivers (or other 160 nodes responsible for gap filling and duplicate suppression) to 161 identify and suppress the duplicate packets, and subsequently produce 162 a hopefully loss-free and duplication-free output stream. This 163 process is commonly called stream merging or de-duplication. 165 3.2. Spatial Redundancy 167 An RTP source might be associated with multiple network interfaces, 168 allowing it to send two redundant streams from two separate source 169 addresses. Such streams can be routed over diverse or identical 170 paths depending on the routing algorithm used inside the network. At 171 the receiving end, the node responsible for duplicate suppression can 172 look into various RTP header fields, for example SSRC and sequence 173 number, to identify and suppress the duplicate packets. 175 If source-specific multicast (SSM) transport is used to carry such 176 redundant streams, there will be a separate SSM session for each 177 redundant stream since the streams are sourced from different 178 interfaces (i.e., IP addresses). Thus, the receiving host has to 179 join each SSM session separately. 181 Alternatively, an RTP source might send the redundant streams to 182 separate IP destination addresses. 184 3.3. Dual Streaming over a Single Path or Multiple Paths 186 Having described the characteristics of the streams, one can reach 187 the following conclusions: 189 1. When two routing-plane identical streams are used, the two 190 streams will have identical IP headers. This makes it 191 impractical to forward the packets onto different paths. In 192 order to minimize packet loss, the packets belonging to one 193 stream are often interleaved with packets belonging to its 194 duplicate stream, and with a delay, so that if there is a packet 195 loss, such a delay would allow the same packet from the duplicate 196 stream to reach the receiver because the chances that the same 197 packet is lost in transit again is often small. This is what is 198 also known as Time-shifted Redundancy, Temporal Redundancy or 199 simply Delayed Duplication [I-D.ietf-mmusic-delayed-duplication] 200 [IC2011]. This approach can be used with both types of dual 201 streaming, described in Section 3.1 and Section 3.2. 203 2. If the two streams have different IP headers, an additional 204 opportunity arises in that one is able to build a network, with 205 physically diverse paths, to deliver the two streams concurrently 206 to the intended receivers. This reduces the delay when packet 207 loss occurs and needs to be recovered. Additionally, it also 208 further reduces chances for packet loss. An unrecoverable loss 209 happens only when two network failures happen in such a way that 210 the same packet is affected on both paths. This is referred to 211 as Spatial Diversity or Spatial Redundancy [IC2011]. The 212 techniques used to build diverse paths are beyond the scope of 213 this document. 215 Note that spatial redundancy often offers less delay in 216 recovering from packet loss provided that the forwarding delay of 217 the network paths are more or less the same (This is often made 218 sure through careful network design). For both temporal and 219 spatial redundancy approaches, packet misordering might still 220 happen and needs to be handled using the sequence numbers of some 221 sort (e.g., RTP sequence numbers). 223 To summarize, dual streaming allows an application and a network to 224 work together to provide a near zero-loss transport with a bounded or 225 minimum delay. The additional advantage includes a predictable 226 bandwidth overhead that is proportional to the minimum bandwidth 227 needed for the multimedia session, but independent of the number of 228 receivers experiencing a packet loss and requesting a retransmission. 229 For a survey and comparison of similar approaches, refer to [IC2011]. 231 3.4. Requirements 233 One of the following conditions is REQUIRED to hold in applications 234 using this specification: 236 o The original and duplicate RTP streams are carried (with their own 237 SSRCs) in the same "m" line (There could be other RTP streams 238 listed in the same "m" line) 240 o The original and duplicate RTP streams are carried in separate "m" 241 lines and there is no other RTP stream listed in either "m" line. 243 When the original and duplicate RTP streams are carried in separate 244 "m" lines in an SDP description and if the SDP description has one or 245 more other RTP streams listed in either "m" line, duplication 246 grouping is not trivial and further signaling will be needed, which 247 is left for future standardization. 249 4. Use of RTP and RTCP with Temporal Redundancy 251 To achieve temporal redundancy, the main and duplicate RTP streams 252 SHOULD be sent using the sample 5-tuple of transport protocol, source 253 and destination IP addresses, and source and destination transport 254 ports. Due to the possible presence of network address and port 255 translation (NAPT) devices, load balancers, or other middleboxes, use 256 of anything other than an identical 5-tuple might also cause spatial 257 redundancy (which might introduce an additional delay due to the 258 delta between the path delays), and so is NOT RECOMMENDED unless the 259 path is known to be free of such middleboxes. 261 Since the main and duplicate RTP streams follow an identical path, 262 they are part of the same RTP session. Accordingly, the sender MUST 263 choose a different SSRC for the duplicate RTP stream than it chose 264 for the main RTP stream, following the rules in [RFC3550] Section 8. 266 4.1. RTCP Considerations 268 If RTCP is being sent for the main RTP stream, then the sender MUST 269 also generate RTCP for the duplicate RTP stream. The RTCP for the 270 duplicate RTP stream is generated exactly as-if the duplicate RTP 271 stream were a regular media stream. The sender MUST NOT duplicate 272 the RTCP packets sent for the main RTP stream when sending the 273 duplicate stream, instead it MUST generate new RTCP reports for the 274 duplicate stream. The sender MUST use the same RTCP CNAME in the 275 RTCP reports it sends for both streams, so that the receiver can 276 synchronize them. 278 The main and duplicate streams are conceptually synchronized using 279 the standard RTCP Sender Report-based mechanism, deriving a mapping 280 between their timelines. However, the RTP timestamps and sequence 281 numbers MUST be identical in the main and duplicate streams, making 282 the mapping quite trivial. 284 Both the main and duplicate RTP streams, and their corresponding RTCP 285 reports, will be received. If RTCP is used, receivers MUST generate 286 RTCP reports for both the main and duplicate streams in the usual 287 way, treating them as entirely separate media streams. 289 4.2. Signaling Considerations 290 Signaling is needed to allow the receiver to determine that an RTP 291 stream is a duplicate of another, rather than a separate stream that 292 needs to be rendered in parallel. There are two parts to this: an 293 SDP extension is needed in the offer/answer exchange to negotiate 294 support for temporal redundancy; and signaling is needed to indicate 295 which stream is the duplicate (the latter can be done in-band using 296 an RTCP extension, or out-of-band in the SDP description). 298 We require out-of-band signaling for both features. The required SDP 299 attribute to signal duplication in the SDP offer/answer exchange 300 ('duplication-delay') is defined in 301 [I-D.ietf-mmusic-delayed-duplication]. The required SDP grouping 302 semantics are defined in [I-D.ietf-mmusic-duplication-grouping]. 304 In the following SDP example, a video stream is duplicated, and the 305 main and duplicate streams are transmitted in two separate SSRCs 306 (1000 and 1010): 308 v=0 309 o=ali 1122334455 1122334466 IN IP4 dup.example.com 310 s=Delayed Duplication 311 t=0 0 312 m=video 30000 RTP/AVP 100 313 c=IN IP4 233.252.0.1/127 314 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 315 a=rtpmap:100 MP2T/90000 316 a=ssrc:1000 cname:ch1a@example.com 317 a=ssrc:1010 cname:ch1a@example.com 318 a=ssrc-group:DUP 1000 1010 319 a=duplication-delay:50 320 a=mid:Ch1 322 As specified in Section 3.2 of 323 [I-D.ietf-mmusic-duplication-grouping], it is advisable that the SSRC 324 listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent 325 first, with the other SSRC (i.e., SSRC of 1010) being the time- 326 delayed duplicate. This is not critical, however, and a receiving 327 host should size its playout buffer based on the 'duplication-delay' 328 attribute, and play the stream that arrives first in preference, with 329 the other stream acting as a repair stream, irrespective of the order 330 in which they are signaled. 332 5. Use of RTP and RTCP with Spatial Redundancy 334 When using spatial redundancy, the duplicate RTP stream is sent using 335 a different source and/or destination address/port pair. This will 336 be a separate RTP session to the session conveying the main RTP 337 stream. Thus, the SSRCs used for the main and duplicate streams MUST 338 be chosen randomly, following the rules in Section 8 of [RFC3550]. 339 Accordingly, they will almost certainly not match each other. The 340 sender MUST, however, use the same RTCP CNAME for both the main and 341 duplicate streams. An "a=group:DUP" line or "a=ssrc-group:DUP" line 342 is used to indicate duplication. 344 5.1. RTCP Considerations 346 If RTCP is being sent for the main RTP stream, then the sender MUST 347 also generate RTCP for the duplicate RTP stream. The RTCP for the 348 duplicate RTP stream is generated exactly as-if the duplicate RTP 349 stream were a regular media stream. The sender MUST NOT duplicate 350 the RTCP packets sent for the main RTP stream when sending the 351 duplicate stream, instead it MUST generate new RTCP reports for the 352 duplicate stream. The sender MUST use the same RTCP CNAME in the 353 RTCP reports it sends for both streams, so that the receiver can 354 synchronize them. 356 The main and duplicate streams are conceptually synchronized using 357 the standard RTCP Sender Report-based mechanism, deriving a mapping 358 between their timelines. However, the RTP timestamps and sequence 359 numbers MUST be identical in the main and duplicate streams, making 360 the mapping quite trivial. 362 Both the main and duplicate RTP streams, and their corresponding RTCP 363 reports, will be received. If RTCP is used, receivers MUST generate 364 RTCP reports for both the main and duplicate streams in the usual 365 way, treating them as entirely separate media streams. 367 5.2. Signaling Considerations 369 The required SDP grouping semantics have been defined in 370 [I-D.ietf-mmusic-duplication-grouping]. In the following example, 371 the redundant streams have different IP destination addresses. The 372 example shows the same UDP port number and IP source address for each 373 stream, but either or both could have been different for the two 374 streams. 376 v=0 377 o=ali 1122334455 1122334466 IN IP4 dup.example.com 378 s=DUP Grouping Semantics 379 t=0 0 380 a=group:DUP S1a S1b 381 m=video 30000 RTP/AVP 100 382 c=IN IP4 233.252.0.1/127 383 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 384 a=rtpmap:100 MP2T/90000 385 a=mid:S1a 386 m=video 30000 RTP/AVP 101 387 c=IN IP4 233.252.0.2/127 388 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 389 a=rtpmap:101 MP2T/90000 390 a=mid:S1b 392 6. Use of RTP and RTCP with Temporal and Spatial Redundancy 394 This uses the same RTP/RTCP mechanisms from Sections Section 4 and 395 Section 5, plus a combination of both sets of signaling. 397 7. Congestion Control Considerations 399 Duplicating RTP streams has several considerations in the context of 400 congestion control. First of all, RTP duplication MUST NOT be used 401 in cases where the primary cause of packet loss is congestion since 402 duplication can make congestion only worse. Furthermore, RTP 403 duplication SHOULD NOT be used where there is a risk of congestion 404 upon duplicating an RTP stream. Duplication is RECOMMENDED only to 405 be used for protection against network outages due to a temporary 406 link or network element failure and where it is known that there is 407 sufficient network capacity to carry the duplicated traffic. The 408 capacity requirement constrains the use of duplication to managed 409 networks, and makes it unsuitable for use on unmanaged public 410 networks. 412 It is essential that the nodes responsible for the duplication and 413 de-duplication are aware of the original stream's requirements and 414 the available capacity inside the network. If there is an adaptation 415 capability for the original stream, these nodes have to assume the 416 same adaptation capability for the duplicated stream, too. For 417 example, if the source doubles the bitrate for the original stream, 418 the bitrate of the duplicate stream will also be doubled. 420 Depending on where de-duplication takes place, there could be 421 different scenarios. When the duplication and de-duplication takes 422 place inside the network before the ultimate end-points that will 423 consume the RTP media, the whole process is transparent to these end- 424 points. Thus, these end-points will apply any congestion control, if 425 applicable, on the de-duplicated RTP stream. This output stream will 426 have less losses than either of the original and duplicated stream, 427 and the end-point will make congestion control decisions accordingly. 428 However, if de-duplication takes place at the ultimate end-point, 429 this end-point MUST consider the aggregate of the original and 430 duplicated RTP stream in any congestion control it wants to apply. 431 The end-point will observe the losses in each stream separately, and 432 this information can be used to fine-tune the duplication process. 433 For example, the duplication interval can be adjusted based on the 434 duration of a common packet loss in both streams. 436 8. Security Considerations 438 The security considerations of [RFC3550], 439 [I-D.ietf-mmusic-delayed-duplication], 440 [I-D.ietf-mmusic-duplication-grouping], and any RTP profiles and 441 payload formats in use apply. 443 Duplication can be performed end-to-end, with the media sender 444 generating a duplicate RTP stream, and the receiver(s) performing de- 445 duplication. In such cases, if the original media stream is to be 446 authenticated (e.g., using SRTP [RFC3711]) then the duplicate stream 447 also needs to be authenticated, and duplicate packets that fail the 448 authentication check need to be discarded. 450 Stream duplication and de-duplication can also be performed by in- 451 network middleboxes. Such middleboxes will need to rewrite the RTP 452 SSRC such that the RTP packets in the duplicate stream have a 453 different SSRC to the original stream, and will need to generate and 454 respond to RTCP packets corresponding to the duplicate stream. This 455 sort of in-network duplication service has the potential to act as an 456 amplifier for denial-of-service attacks if the attacker can cause 457 attack traffic to be duplicated. To prevent this, middleboxes 458 providing the duplication service need to authenticate the traffic to 459 be duplicated as being from a legitimate source, for example using 460 the secure RTP (SRTP) profile [RFC3711]. This requires the middlebox 461 to be part of the security context of the media session being 462 duplicated, so it has access to the necessary keying material for 463 authentication. To do this, the middlebox will need to be privy to 464 the session set-up signalling. Details of how that is done will 465 depend on the type of signalling used (SIP, RTSP, WebRTC, etc.), and 466 is not specified here. 468 Similarly, to prevent packet injection attacks, a de-duplication 469 middlebox needs to authenticate original and duplicate streams, and 470 ought not use non-authenticated packets that are received. Again, 471 this requires the middlebox to be part of the security context, and 472 have access to the appropriate signalling and keying material. 474 The use of the encryption features of SRTP does not affect stream de- 475 duplication middleboxes, since the RTP headers are sent in the clear. 477 9. IANA Considerations 479 No IANA actions are required. 481 10. Acknowledgments 483 Thanks to Magnus Westerlund for his suggestions. 485 11. References 487 11.1. Normative References 489 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 490 Jacobson, "RTP: A Transport Protocol for Real-Time 491 Applications", STD 64, RFC 3550, July 2003. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [I-D.ietf-mmusic-delayed-duplication] 497 Begen, A., Cai, Y., and H. Ou, "Delayed Duplication 498 Attribute in the Session Description Protocol", draft- 499 ietf-mmusic-delayed-duplication-02 (work in progress), May 500 2013. 502 [I-D.ietf-mmusic-duplication-grouping] 503 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 504 Semantics in the Session Description Protocol", draft- 505 ietf-mmusic-duplication-grouping-03 (work in progress), 506 July 2013. 508 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 509 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 510 RFC 3711, March 2004. 512 11.2. Informative References 514 [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of 515 Streaming Media", RFC 2354, June 1998. 517 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 518 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 519 July 2006. 521 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 522 Correction (FEC) Framework", RFC 6363, October 2011. 524 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 525 "Toward Lossless Video Transport (to appear in IEEE 526 Internet Computing)", November 2011. 528 Authors' Addresses 530 Ali Begen 531 Cisco 532 181 Bay Street 533 Toronto, ON M5J 2T3 534 CANADA 536 Email: abegen@cisco.com 538 Colin Perkins 539 University of Glasgow 540 School of Computing Science 541 Glasgow G12 8QQ 542 UK 544 Email: csp@csperkins.org 545 URI: http://orcid.org/0000-0002-3404-8964