idnits 2.17.1 draft-ietf-avt-rapid-acquisition-for-rtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 12, 2009) is 5462 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-18 == Outdated reference: A later version (-14) exists of draft-ietf-rmt-pi-norm-revised-11 == Outdated reference: A later version (-06) exists of draft-begen-avt-rtp-mpeg2ts-preamble-00 == Outdated reference: A later version (-03) exists of draft-begen-avt-rapid-sync-rtcp-xr-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT B. VerSteeg 3 Internet-Draft A. Begen 4 Intended status: Standards Track Cisco Systems 5 Expires: November 13, 2009 T. VanCaenegem 6 Alcatel-Lucent 7 Z. Vax 8 Microsoft Corporation 9 May 12, 2009 11 Unicast-Based Rapid Acquisition of Multicast RTP Sessions 12 draft-ietf-avt-rapid-acquisition-for-rtp-00 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on November 13, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 When an RTP receiver joins a primary multicast session, it may need 60 to acquire and parse certain Reference Information before it can 61 process any data sent in the multicast session. Depending on the 62 join time, length of the Reference Information repetition interval, 63 size of the Reference Information as well as the application and 64 transport properties, the time lag before an RTP receiver can 65 usefully consume the multicast data, which we refer to as the 66 Acquisition Delay, varies and may be large. This is an undesirable 67 phenomenon for receivers that frequently switch among different 68 multicast sessions, such as video broadcasts. 70 In this document, we describe a method using the existing RTP and 71 RTCP protocol machinery that reduces the acquisition delay. In this 72 method, an auxiliary unicast RTP session carrying the Reference 73 Information to the receiver precedes/accompanies the primary 74 multicast stream. This unicast RTP flow may be transmitted at a 75 faster than natural rate to further accelerate the acquisition. The 76 motivating use case for this capability is multicast applications 77 that carry real-time compressed audio and video. However, the 78 proposed method can also be used in other types of multicast 79 applications where the acquisition delay is long enough to be a 80 problem. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 86 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 4. Elements of Delay in Multicast Applications . . . . . . . . . 7 88 5. Protocol Design Considerations and Their Effect on 89 Resource Management for Rapid Acquisition . . . . . . . . . . 9 90 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 11 91 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 12 93 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 20 94 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 20 95 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 21 96 7.1. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 22 97 7.2. RAMS Information . . . . . . . . . . . . . . . . . . . . . 23 98 7.3. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 26 99 7.4. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 27 100 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 28 101 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 28 102 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 31 104 10. Known Implementations . . . . . . . . . . . . . . . . . . . . 31 105 10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 31 106 10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 31 107 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 108 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 109 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 110 13.1. Registration of SDP Attribute Values . . . . . . . . . . . 32 111 13.2. Registration of FMT Values . . . . . . . . . . . . . . . . 33 112 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 113 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33 114 15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 34 115 15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 34 116 15.3. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 34 117 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 118 16.1. Normative References . . . . . . . . . . . . . . . . . . . 35 119 16.2. Informative References . . . . . . . . . . . . . . . . . . 36 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 122 1. Introduction 124 Most multicast flows carry a stream of inter-related data. Certain 125 information must first be acquired by the receivers to start 126 processing any data sent in the multicast session. This document 127 refers to this information as Reference Information. The Reference 128 Information is conventionally sent periodically in the multicast 129 session and usually consists of items such as a description of the 130 schema for the rest of the data, references to which data to process 131 for the receivers, encryption information including keys, as well as 132 any other information required to process the data in the primary 133 multicast stream. 135 Real-time multicast applications require the receivers to buffer 136 data. The receiver may have to buffer data to smooth out the network 137 jitter, to allow loss-repair methods such as Forward Error Correction 138 and retransmission to recover the missing packets, and to satisfy the 139 data processing requirements of the application layer. 141 When a receiver joins a multicast session, it has no control over 142 what point in the flow is currently being transmitted. Sometimes the 143 receiver may join the session right before the Reference Information 144 is sent in the session. In this case, the required waiting time is 145 usually minimal. Other times, the receiver may join the session 146 right after the Reference Information has been transmitted. In this 147 case, the receiver has to wait for the Reference Information to 148 appear again in the flow before it can start processing any multicast 149 data. In some other cases, the Reference Information is not 150 contiguous in the flow but dispersed over a large period, which 151 forces the receiver to wait for all of the Reference Information to 152 arrive before starting to process the rest of the data. 154 The net effect of waiting for the Reference Information and waiting 155 for various buffers to fill up is that the receivers may experience 156 significantly large delays in data processing. In this document, we 157 refer to the difference between the time an RTP receiver joins the 158 multicast session and the time the RTP receiver acquires all the 159 necessary Reference Information as the Acquisition Delay. The 160 acquisition delay may not be the same for different receivers; it 161 usually varies depending on the join time, length of the Reference 162 Information repetition interval, size of the Reference Information as 163 well as the application and transport properties. 165 The varying nature of the acquisition delay adversely affects the 166 receivers that frequently switch among multicast sessions. In this 167 specification, we address this problem for RTP-based multicast 168 applications and describe a method that uses the fundamental tools 169 offered by the existing RTP and RTCP protocols [RFC3550]. In this 170 method, either the multicast source (or the distribution source in a 171 single-source multicast (SSM) session) retains the Reference 172 Information for a period after its transmission, or an intermediary 173 network element joins the multicast session and continuously caches 174 the Reference Information as it is sent in the session and acts as a 175 feedback target (See [I-D.ietf-avt-rtcpssm]) for the session. When 176 an RTP receiver wishes to join the same multicast session, instead of 177 simply issuing a Source Filtering Group Management Protocol (SFGMP) 178 Join message, it sends a request to the feedback target for the 179 session asking for the Reference Information. The feedback target 180 starts a unicast retransmission RTP session and sends the Reference 181 Information to the RTP receiver over that session. If there is spare 182 bandwidth, the feedback target may also burst the Reference 183 Information at a faster than its natural rate. As soon as the 184 receiver acquires the Reference Information, it can join the 185 multicast session and start processing the multicast data. This 186 method potentially reduces the acquisition delay. We refer to this 187 method as Unicast-based Rapid Acquisition of Multicast RTP Sessions. 188 A simplified network diagram showing this method through an 189 intermediary network element is depicted in Figure 1. 191 +-------------------+ 192 +--->| Intermediary | 193 | ...| Network Element | 194 | : +-------------------+ 195 | : 196 | v 197 +-----------+ +----------+ +----------+ 198 | Multicast | | Router |---------->| Joining | 199 | Source |------->| |..........>| RTP | 200 +-----------+ +----------+ | Receiver | 201 | +----------+ 202 | 203 | +----------+ 204 +---------------->| Existing | 205 | RTP | 206 | Receiver | 207 +----------+ 209 ...> Unicast RTP Flow 210 ---> Multicast RTP Flow 212 Figure 1: Rapid acquisition through an intermediary network element 214 A primary design goal in this solution is to use the existing tools 215 in the RTP/RTCP protocol family. This improves the versatility of 216 the existing implementations, and promotes faster deployment and 217 better interoperability. To this effect, we use the unicast 218 retransmission support of RTP [RFC4588] and the capabilities of RTCP 219 to handle the signaling needed to accomplish the acquisition. The 220 packet(s) carrying the Reference Information are sent by the feedback 221 target in the auxiliary unicast RTP session for rapid acquisition. 222 These are constructed as retransmission packets that would have been 223 sent in a unicast RTP session to recover the missing packets at an 224 RTP receiver that has never received any packet. In fact, a single 225 RTP session MAY be used for both rapid acquisition and 226 retransmission-based loss repair. Furthermore, the session can be 227 used to simultaneously provide the unicast burst for the rapid 228 acquisition and the repair packets requested by the RTP receivers 229 when they detect lost burst packets or lost RTP packets in the 230 primary multicast stream. The conventional RTCP feedback message 231 that requests the retransmission of the missing packets [RFC4585] 232 indicates their sequence numbers. However, upon joining a new 233 session the RTP receiver has never received a packet, and thus, does 234 not know the sequence numbers. Instead, the RTP receiver sends a 235 newly defined RTCP feedback message to request the Reference 236 Information needed to rapidly get on the track with the primary 237 multicast session. It is also worth noting that in order to issue 238 the initial RTCP message to the feedback target, the SSRC of the 239 session to be joined must be known prior to any packet reception, and 240 hence, needs to be signaled out-of-band (or otherwise communicated to 241 the RTP receiver in advance of the initiation of the rapid 242 acquisition operation). In a Session Description Protocol (SDP) 243 description, the SSRC MUST be signaled through the 'ssrc' attribute 244 [I-D.ietf-avt-rtcpssm]. 246 In the rest of this specification, we have the following outline: In 247 Section 4, we describe the delay components in generic multicast 248 applications. Section 5 presents an overview of the protocol design 249 considerations for rapid acquisition. We provide the protocol 250 details of the rapid acquisition method in Section 6 and Section 7. 251 Section 8 and Section 9 discuss the SDP signaling issues with 252 examples and NAT-related issues, respectively. 254 Note that Section 3 provides a list of the definitions frequently 255 used in this document. 257 2. Requirements Notation 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 260 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 261 document are to be interpreted as described in [RFC2119]. 263 3. Definitions 265 This document uses the following acronyms and definitions frequently: 267 Primary Multicast Session: The multicast RTP session to which RTP 268 receivers can join at a random point in time. 270 Primary Multicast Stream: The RTP stream carried in the primary 271 multicast session. 273 Source Filtering Group Management Protocol (SFGMP): Following the 274 definition in [RFC4604], SFGMP refers to the Internet Group 275 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 276 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 277 IPv6 networks, respectively. 279 Feedback Target: (Unicast RTCP) Feedback target as defined in 280 [I-D.ietf-avt-rtcpssm]. 282 Retransmission Packet: An RTP packet that is formatted as defined in 283 [RFC4588]. 285 Reference Information: The set of certain media content and metadata 286 information that is sufficient for an RTP receiver to start usefully 287 consuming a media stream. The meaning, format and size of this 288 information are specific to the application and are out of scope of 289 this document. 291 Burst (Stream): A unicast stream of RTP retransmission packets that 292 enable an RTP receiver to rapidly acquire the Reference Information. 293 The burst stream is typically transmitted at an accelerated rate. 295 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 296 the retransmission packets and the burst stream. 298 4. Elements of Delay in Multicast Applications 300 In an any-source (ASM) or a single-source (SSM) multicast delivery 301 system, there are three major elements that contribute to the overall 302 acquisition delay when an RTP receiver switches from one multicast 303 session to another one. These are: 305 o Multicast switching delay 307 o Reference Information latency 308 o Buffering delays 310 Multicast switching delay is the delay that is experienced to leave 311 the current multicast session (if any) and join the new multicast 312 session. In typical systems, the multicast join and leave operations 313 are handled by a group management protocol. For example, the 314 receivers and routers participating in a multicast session may use 315 the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or 316 the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. 317 In either of these protocols, when a receiver wants to join a 318 multicast session, it sends a message to its upstream router and the 319 routing infrastructure sets up the multicast forwarding state to 320 deliver the packets of the multicast session to the new receiver. 321 Depending on the proximity of the upstream router, the current state 322 of the multicast tree, the load on the system and the protocol 323 implementation, the join times vary. Current systems provide join 324 latencies usually less than 200 milliseconds (ms). If the receiver 325 had been participating in another multicast session before joining 326 the new session, it needs to send a Leave message to its upstream 327 router to leave the session. In common multicast routing protocols, 328 the leave times are usually smaller than the join times, however, it 329 is possible that the Leave and Join messages may get lost, in which 330 case the multicast switching delay inevitably increases. 332 Reference Information latency is the time it takes the receiver to 333 acquire the Reference Information. It is highly dependent on the 334 proximity of the actual time the receiver joined the session to the 335 next time the Reference Information will be sent to the receivers in 336 the session, whether the Reference Information is sent contiguously 337 or not, and the size of the Reference Information. For some 338 multicast flows, there is a little or no interdependency in the data, 339 in which case the Reference Information latency will be nil or 340 negligible. For other multicast flows, there is a high degree of 341 interdependency. One example of interest is the multicast flows that 342 carry compressed audio/video. For these flows, the Reference 343 Information latency may become quite large and be a major contributor 344 to the overall delay. 346 The buffering component of the overall acquisition delay is driven by 347 the way the application layer processes the payload. In many 348 multicast applications, an unreliable transport protocol such as UDP 349 [RFC0768] is often used to transmit the data packets, and the 350 reliability, if needed, is usually addressed through other means such 351 as Forward Error Correction and retransmission 352 [I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require 353 buffering at the receiver side to function properly. In many 354 applications, it is also often necessary to de-jitter the incoming 355 data packets before feeding them to the application. The de- 356 jittering process also increases the buffering delays. Besides these 357 network-related buffering delays, there are also specific buffering 358 needs that are required by the individual applications. For example, 359 standard video decoders typically require an amount, sometimes a 360 significant amount, of coded video data to be available in the pre- 361 decoding buffers prior to starting to decode the video bitstream. 363 5. Protocol Design Considerations and Their Effect on Resource 364 Management for Rapid Acquisition 366 Rapid acquisition is an optimization of a system that must continue 367 to work correctly whether or not the optimization is effective, or 368 even fails due to lost control messages, congestion, or other 369 problems. This is fundamental to the overall design requirements 370 surrounding the protocol definition and to the resource management 371 schemes to be employed together with the protocol (e.g., QoS 372 machinery, server load management, etc). In particular, the system 373 needs to operate within a number of constraints: 375 o First, a rapid acquisition operation must fail gracefully. The 376 user experience must, except perhaps in pathological 377 circumstances, be not significantly worse for trying and failing 378 to complete rapid acquisition compared to simply joining the 379 multicast session. 381 o Second, providing the rapid acquisition optimizations must not 382 cause collateral damage to either the multicast session being 383 joined, or other multicast sessions sharing resources with the 384 rapid acquisition operation. In particular, the rapid acquisition 385 operation must avoid self-interference with the multicast session 386 that may be simultaneously being received by other hosts. In 387 addition, it must also avoid interference with other multicast 388 sessions sharing the same network resources. These properties are 389 possible, but are usually difficult to achieve. 391 One challenge is the existence of multiple bandwidth bottlenecks 392 between the receiver and the server(s) in the network providing the 393 rapid acquisition service. In commercial IPTV deployments, for 394 example, bottlenecks are often present in the aggregation network 395 connecting the IPTV servers to the network edge, the access links 396 (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some 397 of these links may serve only a single subscriber, limiting 398 congestion impact to the traffic of only that subscriber, but others 399 can be shared links carrying multicast sessions of many subscribers. 400 Also note that the state of these links may be varying over time. 401 The receiver may have knowledge of a portion of this network, or may 402 have partial knowledge of the entire network. The methods employed 403 by the devices to acquire this network state information is out of 404 scope for this document. The receiver should be able to signal the 405 server with the bandwidth that it believes it can handle. The server 406 also needs to be able to rate limit the flow in order to stay within 407 the performance envelope that it knows about. Both the server and 408 receiver need to be able to inform the other of changes in the 409 requested and delivered rates. However, the protocol must be robust 410 in the presence of packet loss, so this signaling must include the 411 appropriate default behaviors. 413 A second challenge is that for some uses (e.g., high-bitrate video) 414 the unicast burst bandwidth is high while the flow duration of the 415 unicast burst is short. This is because the purpose of the unicast 416 burst is to allow the RTP receiver to join the multicast quickly and 417 thereby limit the overall resources consumed by the burst. Such 418 high-bitrate, short-duration flows are not amenable to conventional 419 admission control techniques. For example, per-flow signaled 420 admission control techniques such as RSVP have too much latency and 421 control channel overhead to be a good fit for rapid acquisition. 422 Similarly, using a TCP (or TCP-like) approach with a 3-way handshake 423 and slow-start to avoid inducing congestion would defeat the purpose 424 of attempting rapid acquisition in the first place by introducing 425 many RTTs of delay. 427 These observations lead to certain unavoidable requirements and goals 428 for a rapid acquisition protocol. These are: 430 o The protocol must be designed to allow a deterministic upper bound 431 on the extra bandwidth used (compared to just joining the 432 multicast session). A reasonable size bound is e*B, where B is 433 the "nominal" bandwidth of the primary multicast stream, and e is 434 an "excess-bandwidth" coefficient The total duration of the 435 unicast burst must have a reasonable bound; long unicast bursts 436 devolve to the bandwidth profile of multi-unicast for the whole 437 system. 439 o The scheme should minimize (or better eliminate) the overlap of 440 the unicast burst and the primary multicast stream. This 441 minimizes the window during which congestion could be induced on a 442 bottleneck link compared to just carrying the multicast or unicast 443 packets alone. 445 o The scheme must minimize (or better eliminate) any gap between the 446 unicast burst and the primary multicast stream, which has to be 447 repaired later, or in the absence of repair, will result in loss 448 being experienced by the application. 450 In addition to the above, there are some other protocol design issues 451 to be considered. First, there is at least one RTT of "slop" in the 452 control loop. In starting a rapid acquisition burst, this manifests 453 as the time between the client requesting the unicast burst and the 454 burst description (and possibly the first unicast burst packets) 455 arriving at the receiver. For managing and terminating the unicast 456 burst, there are two possible approaches for the control loop: The 457 receiver can adapt to the unicast burst as received, converge based 458 on observation and explicitly terminate the unicast burst with a 459 second control loop exchange (which takes a minimum of one RTT, just 460 as starting the unicast burst does). Alternatively, the server 461 generating the unicast burst can pre-compute the burst parameters 462 based on the information in the initial request and tell the receiver 463 the burst duration. 465 The protocol described in the next section allows either method of 466 controlling the rapid acquisition unicast burst. 468 6. Rapid Acquisition of Multicast RTP Sessions 470 We start this section with an overview of the rapid acquisition of 471 multicast sessions (RAMS) method. 473 6.1. Overview 475 [I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control 476 Protocol (RTCP) to use unicast feedback in an SSM session. It 477 defines an architecture that introduces the concept of Distribution 478 Source, which - in an SSM context - distributes the RTP data and 479 redistributes RTCP information to all RTP receivers. This RTCP 480 information is retrieved from the Feedback Target, to which RTCP 481 unicast feedback traffic is sent. The Feedback Target MAY be 482 implemented in one or more entities different from the Distribution 483 Source, and different RTP receivers MAY use different Feedback 484 Targets. 486 This document builds further on these concepts to reduce the 487 acquisition time when an RTP receiver wants to join a multicast 488 session at a random point in time by introducing the concept of the 489 Burst Source and new RTCP feedback messages. The Burst Source has a 490 cache where the most recent packets from the primary multicast 491 session are continuously stored. When an RTP receiver wants to 492 receive the primary multicast stream, prior to joining the SSM 493 session, it will first request a unicast burst from the Burst Source. 494 In this burst, the packets are formatted as RTP retransmission 495 packets [RFC4588] and carry the Reference Information. This 496 information allows the RTP receiver to start usefully consuming the 497 RTP packets sent in the primary multicast session. 499 Using an accelerated rate (as compared to the rate of the primary 500 multicast stream) for the unicast burst implies that at a certain 501 point in time, the payload transmitted in the unicast burst is going 502 to be the same as the payload multicast in the SSM session, i.e., the 503 unicast burst will catch up with the primary multicast stream. At 504 this point, the RTP receiver no longer needs to receive the unicast 505 burst and can join the primary multicast session. This method is 506 referred to as the Rapid Acquisition of Multicast Sessions (RAMS). 508 This document proposes extensions to [RFC4585] for an RTP receiver to 509 request a unicast burst as well as for additional control messaging 510 that can be leveraged during the acquisition process. 512 6.2. Message Flows 514 Figure 2 shows the main entities involved in rapid acquisition: 516 o Multicast Source 518 o Feedback Target (FT) 520 o Burst Source 522 o Retransmission Source 524 o RTP Receiver (RR) 525 +----------------------------------------------+ 526 | Retransmission Server | 527 | (RS) | 528 | +----------+ +--------+ +----------------+ | 529 | | Feedback | | Burst | | Retransmission | | 530 | | Target | | Source | | Source | | 531 | +----------+ +--------+ +----------------+ | 532 +----------------------------------------------+ 533 ^ ^ : 534 | ' : 535 | ' : 536 | ' v 537 +-----------+ +----------+ +----------+ 538 | | | |'''''''''''>| | 539 | Multicast |------->| Router |...........>| RTP | 540 | Source | | |<~~~~~~~~~~~| Receiver | 541 | | | |----------->| (RR) | 542 +-----------+ +----------+ +----------+ 544 '''> Unicast RTCP Messages 545 ~~~> SFGMP Messages 546 ...> Unicast RTP Flow 547 ---> Multicast RTP Flow 549 Figure 2: Flow diagram for unicast-based rapid acquisition 551 A Retransmission Source can equally act as a Burst Source. The 552 Retransmission Source can also incorporate the Feedback Target 553 ([I-D.ietf-avt-rtcpssm] permits the feedback target to be a 554 retransmission server, since it is a logical function to which RRs 555 send their unicast feedback), and we will use the term Retransmission 556 Server (RS) in the remainder of the document to refer to a single 557 physical entity comprising these three entities. Note that the same 558 method (with the identical message flows) would also apply in a 559 scenario where rapid acquisition is performed by a feedback target 560 co-located with the media source. 562 As the unicast burst packets are formatted as RTP retransmission 563 packets [RFC4585], the unicast burst and RTP retransmissions MAY be 564 provided in one and the same RTP (retransmission) session. 566 The unicast burst is triggered by the RTCP feedback message defined 567 in this document, whereas an RTP retransmission is triggered by an 568 RTCP NACK message defined in [RFC4585]. Pending on RAMS practices, 569 there may be a gap between the end of the burst and the reception of 570 the primary multicast stream because of the imperfections in the 571 switch-over. If needed, RR can make use of the RTCP NACK message to 572 request a retransmission for the missing packets in the gap. 574 Editor's note: As stated above, FT, Burst Source and Retransmission 575 Source are logical entities. For efficiency and simplicity, they MAY 576 be implemented by a single physical Retransmission Server (RS). In a 577 number of places throughout this document we assume (and explicitly 578 state so) that all three are implemented by the same physical entity 579 and therefore share the same IP address and the port number. The 580 authors look to the AVT community for recommendations on whether this 581 is sufficient or the mechanism has to explicitly address other 582 topologies where FT, Burst Source and Retransmission Source are not 583 co-located. 585 Figure 3 depicts an example of messaging flow for rapid acquisition. 586 The RTCP feedback messages are explained below. Note that the 587 messages indicated in parentheses may or may not be present during 588 rapid acquisition. 590 +-----------+ +----------------+ +----------+ +------------+ 591 | Multicast | | Retransmission | | | | RTP | 592 | Source | | Server | | Router | | Receiver | 593 | | | (RS) | | | | (RR) | 594 +-----------+ +----------------+ +----------+ +------------+ 595 | | | | 596 |-- RTP Multicast ------------------->| | 597 | | | | 598 |-- RTP Multicast ->| | | 599 | | | | 600 | |<'''''''''''''''''' RTCP RAMS-R ''| 601 | | | | 602 | | | | 603 | |'' (RTCP RAMS-I) ''''''''''''''''>| 604 | | | | 605 | | | | 606 | |.. Unicast RTP Burst ............>| 607 | | | | 608 | |<''''''''''''''''''(RTCP RAMS-R)''| 609 | | | | 610 | | | | 611 | |'' (RTCP RAMS-I) ''''''''''''''''>| 612 | | | | 613 | | | | 614 | | |<~ SFGMP Join ~~| 615 | | | | 616 | | | | 617 |-- RTP Multicast ------------------------------------>| 618 | | | | 619 | | | | 620 | |<'''''''''''''''''' RTCP RAMS-T ''| 621 | | | | 622 | | | | 623 | |<''''''''''''''''''' (RTCP NACK)''| 624 | | | | 625 | | | | 626 | |.. (Unicast Retransmissions) ....>| 627 | | | | 628 | | | | 629 | |<''''''''''''''''''' (RTCP BYE) ''| 630 | | | | 631 | | | | 633 '''> Unicast RTCP Messages 634 ~~~> SFGMP Messages 635 ...> Unicast RTP Flow 636 ---> Multicast RTP Flow 637 Figure 3: Message flows for unicast-based rapid acquisition 639 This document defines the expected behaviors of RS and RR. It is 640 instructive to have independently operating implementations on RS and 641 RR that request the burst, describe the burst, start the burst, join 642 the multicast session and stop the burst. These implementations send 643 messages to each other, but there MUST be provisions for the cases 644 where the control messages get lost, or re-ordered, or are not being 645 delivered to their destinations. 647 The following steps describe rapid acquisition in detail: 649 1. Request: RR sends a rapid acquisition request for the new 650 multicast RTP session to the feedback target address of that 651 session. The request contains the SSRC of RR and the SSRC of the 652 media source. This RTCP feedback message is defined as the RAMS- 653 Request (RAMS-R) message and MAY contain parameters, which may 654 constrain the burst, such as the bandwidth limit. Other 655 parameters may be related to the amount of buffering capacity 656 available at RR, which may be used by RS to prepare a burst that 657 conforms with RR's requirements. 659 Before joining the primary multicast session, a new joining RR 660 learns the addresses associated with the new multicast session 661 (addresses for the multicast source, group and retransmission 662 server) by out-of-band means. Also note that since no RTP 663 packets have been received yet for this session, the SSRC must be 664 obtained out-of-band. See Section 8 for details. 666 2. Response: RS receives the RAMS-R message and decides whether to 667 accept it or not. RS MUST send an (at least one) RAMS- 668 Information (RAMS-I) message to RR. The first RAMS-I message MAY 669 precede the unicast burst or it MAY be sent during the burst. 670 Additional RAMS-I messages MAY be sent during the burst and these 671 RAMS-I messages may or may not be a direct response to an RAMS-R 672 message. 674 Note that RS learns the IP address and port information for RR 675 from the RAMS-R message it received. (This description glosses 676 over the NAT details. Refer to Section 9 for a discussion of 677 NAT-related issues.) 679 If RS cannot provide a rapid acquisition service, RS rejects the 680 request and informs RR immediately via an RAMS-I message. If RR 681 receives a message indicating that its rapid acquisition request 682 has been denied, it abandons the rapid acquisition attempt and 683 MAY immediately join the multicast session by sending an SFGMP 684 Join message to its upstream multicast router for the new primary 685 multicast session. 687 If RS accepts the request, it sends an RAMS-I message to RR 688 (before commencing the unicast burst or during the unicast burst) 689 that comprises fields that can be used to describe the unicast 690 burst (e.g., the maximum bitrate and the duration of the unicast 691 burst). 693 The unicast burst duration MAY be calculated by RS, and its value 694 MAY be updated by messages received from RR. The join time 695 information (for the new multicast session) MUST be populated in 696 at least one of the RAMS-I messages. Note that RS MAY send the 697 RAMS-I message after a significant delay, so RR SHOULD NOT make 698 protocol dependencies on quickly receiving an RAMS-I message. 700 3. Unicast Burst: If the request is accepted, RS starts sending the 701 unicast burst that comprises one or more RTP retransmission 702 packets. In addition, there MAY be optional payload-specific 703 information that RS chooses to send to RR. Such an example is 704 discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] for 705 transmitting the payload-specific information for MPEG2 Transport 706 Streams. 708 4. Updated Request: RR MAY send a new RAMS-R message with a 709 different value for one or more fields of an earlier RAMS-R 710 message. Upon receiving an updated request, RS MAY use the 711 updated values for sending/shaping the burst, or refine the 712 values and use the refined values for sending/shaping the burst. 713 RS MAY send a new RAMS-I message to indicate the changes it made. 714 However, note that RS does not have to send a new RAMS-I, or the 715 new RAMS-I message may get lost. It is also possible that the 716 updated RAMS-R message could have been lost. Thus, RR SHOULD NOT 717 make protocol dependencies on quickly (or ever) receiving a new 718 RAMS-I message, or assume that RS will honor the requested 719 changes. 721 RR may be in an environment where the available resources are 722 time-varying, which may or may not deserve sending a new updated 723 request. Determining the circumstances where RR should or should 724 not send an updated request and the methods that RR can use to 725 detect and evaluate the time-varying available resources are not 726 specified in this document. 728 5. Updated Response: RS may send more than one RAMS-I messages, 729 e.g., to update the value of one or more fields in an earlier 730 RAMS-I message and/or to signal RR in real time to join the 731 primary multicast session. RR usually depends on RS to learn the 732 join time, which can be conveyed by the first RAMS-I message, or 733 can be sent/revised in a later RAMS-I message. If RS is not 734 capable of determining the join time in the first RAMS-I message, 735 it MUST send another RAMS-I message (with the join time 736 information) later. 738 6. Multicast Join Signaling: In principal, RR can join the primary 739 multicast session any time during or after the end of the unicast 740 burst via an SFGMP Join message. However, there may be missing 741 packets if RR joins the primary multicast session too early or 742 too late. For example, if RR starts receiving the primary 743 multicast stream while it is still receiving the unicast burst at 744 a high excess bitrate, this may result in an increased risk of 745 packet loss. Or, if RR joins the primary multicast session some 746 time after the unicast burst is finished, there may be a gap 747 between the burst and multicast data (a number of RTP packets may 748 be missing). In both cases, RR MAY issue retransmissions 749 requests [RFC4585] to fill the gap. 751 Yet, there are cases where the remaining available bandwidth may 752 limit the number of retransmissions that can be provided within a 753 certain time period, causing the retransmission data to arrive 754 too late at RR (from an application-layer point of view). To 755 cope with such cases, the RAMS-I message allows RS to signal 756 explicitly when RR should send the SFGMP Join message. 757 Alternatively, RS may pre-compute the burst duration and the time 758 RR should send the SFGMP Join message. This information may be 759 conveyed in the RAMS-I message and can be updated in a subsequent 760 RAMS-I message. While RR MAY use a locally calculated join time, 761 it SHOULD use the information from the most recent RAMS-I 762 message. 764 7. Multicast Receive: After the join, RR starts receiving the 765 primary multicast stream. 767 8. Terminate: RS may know when it needs to stop the unicast burst 768 based on the burst parameters, or RR MAY explicitly let RS know 769 the sequence number of the first RTP packet it received from the 770 multicast session, or RR MAY request RS to terminate the burst 771 immediately. 773 Regardless of whether or not RS knows when it needs to stop the 774 burst, RR SHALL use the RAMS-Termination (RAMS-T) message at an 775 appropriate time. RR can choose to send the RAMS-T message 776 before or after it starts receiving the multicast data. In the 777 latter case, RR SHALL include the sequence number of the first 778 RTP packet received in the primary multicast session in the 779 RAMS-T message, and RS SHOULD terminate the burst after it sends 780 the unicast burst packet whose Original Sequence Number (OSN) 781 field in the RTP retransmission payload header matches this 782 number minus one. 784 If RR wants to stop the burst prior to receiving the multicast 785 data, it sends an RAMS-T message without an RTP sequence number. 787 Note that RR MUST send at least one RAMS-T message. Against the 788 possibility of a message loss, RR MAY repeat the RAMS-T message 789 multiple times as long as it follows the RTCP timer rules defined 790 in [RFC4585]. 792 9. Terminate with RTCP BYE: When RR is no longer interested in 793 receiving the primary multicast stream and the associated unicast 794 burst, RR SHALL issue an RTCP BYE message to RS to terminate the 795 burst and the RTP retransmission session. Upon receiving an RTCP 796 BYE message, RS MUST terminate the rapid acquisition operation, 797 and cease transmitting any further packets of the associated 798 unicast burst. Section 6.1 of [RFC3550] mandates the RTCP BYE 799 message always to be sent with a sender or receiver report in a 800 compound RTCP packet (If no data has been received, an empty 801 receiver report MUST be included). With the information 802 contained in the receiver report, RS can also figure out how many 803 duplicate RTP packets have been delivered to RR (Note that this 804 will be an upper-bound estimate as one or more packets might have 805 been lost during the burst transmission). The impact of 806 duplicate packets and measures that can be taken to minimize the 807 impact of receiving duplicate packets will be addressed in 808 Section 6.3. 810 Note that if RR decides to switch to a new multicast session 811 after it already joined a multicast session following a rapid 812 acquisition request, RR MUST also send an RTCP BYE message to the 813 Feedback Target for the RTP session associated with the current 814 primary multicast stream. 816 Editor's note: Is there a benefit for sending an RAMS-T message 817 in conjuction with an RTCP BYE message in this case? 819 Note that for the purpose of gathering detailed information about 820 RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr] 821 defines an RTCP Extended Report (XR) Block. This report is designed 822 to be payload-independent, thus, it can be used by any multicast 823 application that supports rapid acquisition. Support for this XR 824 report is, however, optional. 826 6.3. Shaping the Unicast Burst 828 Editor's note: This section may discuss sizing of the buffers, 829 output buffer overload protection, output bandwidth management, 830 adjustment of burst rate and duration. 832 TBC. 834 6.4. Failure Cases 836 All RAMS messages MAY be sent several times against the possibility 837 of message loss as long as RS/RR follows the RTCP timer rules defined 838 in [RFC4585]. In the following, we examine the implications of 839 losing the RAMS-R, RAMS-I or RAMS-T messages. 841 When RR sends an RAMS-R message to initiate a rapid acquisition but 842 the message gets lost and RS does not receive it, RR will not get an 843 RAMS-I message, nor a unicast burst. In this case, RR MAY resend the 844 request when it is eligible to do so. Or, after a reasonable amount 845 of time, RR MAY time out (based on the previous observed response 846 times) and immediately join the primary multicast session. In this 847 case, RR MUST still send an RAMS-T message. 849 In the case RR starts receiving a unicast burst but it does not 850 receive a corresponding RAMS-I message within a reasonable amount of 851 time, RR MAY either discard the burst data and stop the burst by 852 sending an RAMS-T message to RS, or decide not to interrupt the 853 unicast burst and be prepared to join the primary multicast session 854 at an appropriate time it determines or indicated in a subsequent 855 RAMS-I message (if available). In either case, RR SHALL send an 856 RAMS-T message to RS at an appropriate time. 858 In the case the RAMS-T message sent by RR does not reach its 859 destination, RS may continue sending the unicast burst even though RR 860 no longer needs it. In some cases, RS has not pre-computed the burst 861 duration and does not know when to stop the burst. To cover that 862 case, RR MAY repeat the RAMS-T message multiple times as long as it 863 follows the RTCP timer rules defined in [RFC4585]. RS MUST be 864 provisioned to deterministically terminate the burst at some point, 865 even if it never receives an RAMS-T message for an ongoing burst. 867 Upon a failure if RR becomes no longer interested in receiving the 868 primary multicast stream and the associated unicast burst, RR SHALL 869 issue an RTCP BYE message to RS to terminate the burst and the RTP 870 retransmission session. Only after that, RR MAY send a new rapid 871 acquisition request for another primary multicast session. 873 7. Encoding of the Signaling Protocol in RTCP 875 This section defines the formats of the RTCP transport-layer feedback 876 messages that are exchanged between the Retransmission Server (RS) 877 and RTP Receiver (RR) during rapid acquisition. These messages are 878 payload-independent and MUST be used by all RTP-based multicast 879 applications that support rapid acquisition regardless of the payload 880 they carry. 882 Specific payload formats are not defined in this document, but a 883 framework is presented that allows payload-specific information to be 884 included in the exchange. 886 The common packet format for the RTCP feedback messages is defined in 887 Section 6.1 of [RFC4585]. Each feedback message has a fixed-length 888 field for version, padding, feedback message type (FMT), payload type 889 (PT), length, SSRC of packet sender, SSRC of media source as well as 890 a variable-length field for feedback control information (FCI). In 891 the transport-layer feedback messages, the PT field is set to RTPFB 892 (205). 894 In the feedback messages defined in this section, optional extensions 895 are encoded by using TLV elements as described below and sketched in 896 Figure 4: 898 o Type: A single-octet identifier that defines the type of the 899 parameter represented in this TLV element. 901 o Length: A two-octet field that indicates the length of the Value 902 field in octets. 904 o Value: Variable-size set of octets that contains the specific 905 value for the parameter. 907 If a TLV element does not fall on a 32-bit boundary, the last word 908 must be padded to the boundary using further bits set to 0. 910 0 1 2 3 911 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type | Length | Value | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Value contd. / 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Figure 4: Structure of a TLV element 920 Editor's note: The optional fields in the RAMS messages (defined 921 below) will be converted to TLV elements in a later version of this 922 document. 924 7.1. RAMS Request 926 The RAMS Request message is identified by PT=RTPFB and FMT=6. 928 The FCI field MUST contain only one RAMS Request. 930 The RAMS Request is used by RR to request rapid acquisition for a new 931 multicast RTP session. 933 The FCI field has the structure depicted in Figure 5. 935 Editor's note: We have not finalized whether RAMS-R messages need a 936 sequence number or not. 938 0 1 2 3 939 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Min RAMS Buffer Fill Requirement | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Max RAMS Buffer Fill Requirement | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Max Receive Bitrate | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 : (TLV-encoded Extensions) : 948 : : 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Figure 5: FCI field syntax for the RAMS Request message 953 o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element 954 that denotes the minimum number of octets of content the RTP 955 receiver desires to have in its buffer as a result of the unicast 956 burst. 958 The RTP receiver may have knowledge of its buffering requirements. 959 These requirements may be application or device specific. For 960 instance, the receiver may need to have a certain amount of data 961 in its application buffer to handle interdependency within the 962 data. If RS is told the buffering ability of the receiver, it may 963 tailor the burst more precisely. The methods used by the receiver 964 to determine this value are application specific, and thus, out of 965 scope. 967 If specified, the amount of backfill that will be provided by the 968 unicast burst SHOULD NOT be smaller than this value since it will 969 not be able to build up the desired level of buffer at RR and may 970 cause buffer underruns. 972 o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element 973 that denotes the maximum number of octets of content the RTP 974 receiver can buffer without losing the burst data due to buffer 975 overflow. 977 The RTP receiver may have knowledge of its buffering requirements. 978 These requirements may be application or device specific. For 979 instance, one receiver may have more physical memory than another 980 receiver, and thus, can buffer more data. If RS knows the 981 buffering ability of the receiver, it may tailor the burst more 982 precisely. The methods used by the receiver to determine this 983 value are application specific, and thus, out of scope. 985 If specified, the amount of backfill that will be provided by the 986 unicast burst SHOULD NOT be larger than this value since it may 987 cause buffer overflows at RR. 989 o Max Receive Bitrate (32 bits): Optional TLV element that denotes 990 the maximum bitrate (in bits per second) that the RTP receiver can 991 process the unicast burst. This rate should include whatever 992 knowledge the receiver has that would provide an upper bound on 993 the unicast burst bitrate. The limits may include local receiver 994 limits as well as network limits that are known to the receiver. 996 If specified, the unicast burst bitrate SHOULD NOT be larger than 997 this value since it may cause congestion and packet loss. 999 The semantics of the RAMS-R feedback message is independent of the 1000 payload type. 1002 7.2. RAMS Information 1004 The RAMS Information message is identified by PT=RTPFB and FMT=7. 1006 The FCI field MUST contain only one RAMS Information. 1008 The RAMS Information is used to describe the unicast burst that will 1009 be sent for rapid acquisition. It also includes other useful 1010 information for RR as described below. Optional payload-specific 1011 information MAY follow RAMS Information. 1013 The FCI field has the structure depicted in Figure 6. 1015 0 1 2 3 1016 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | MSN |S| Response | Rsvd. | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Extended RTP Seqnum of the First Burst Packet | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Earliest Multicast Join Time | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Burst Duration | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Max Burst Bitrate | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 : (TLV-encoded Extensions) : 1029 : : 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 Figure 6: FCI field syntax for the RAMS Information message 1034 o Message Sequence Number (8 bits) : Mandatory field that denotes 1035 the sequence number of this RAMS-I message. During rapid 1036 acquisition, multiple RAMS-I messages MAY be sent and/or the same 1037 RAMS-I message MAY be repeated. The first RAMS-I message SHALL 1038 have an MSN value of 0. This value SHALL NOT be changed if the 1039 same RAMS-I message is sent to the same RR multiple times for 1040 redundancy purposes. If a new information is conveyed in a new 1041 RAMS-I message, the MSN value SHALL be incremented by one. 1043 o Support for Updated Requests (1 bit): Mandatory field that 1044 denotes whether RS supports updated request messages or not. A 1045 value of zero in this field means that RS does not support updated 1046 request messages and RS will ignore such requests. In this case, 1047 RR SHOULD NOT send updated requests. However, RR MAY repeat its 1048 initial request. A value of one in this field means that RS 1049 supports updated request messages. In this case, RR MAY send 1050 updated requests. 1052 Note that even if this field is set to one, RS may or may not be 1053 able to accept value changes in every field in an RAMS-R message. 1054 Furthermore, RS may or may not honor the requested changes 1055 depending on the resources available. 1057 Editor's note: The use of this flag is still under discussion. 1059 o Response (8 bits): Mandatory field that denotes the RS response 1060 code for this RAMS-I message. 1062 Editor's note: Response codes will be defined and registered with 1063 IANA in a later version. Current proposals include: 1065 1. Success 1067 2. Bad_Request 1069 3. No_Server_Resources_Available 1071 4. No_Network_Resources_Available 1073 5. No_Buffered_Content_Available 1075 o Rsvd (16 bits): Reserved. This field SHALL be set to 0. 1077 o Extended RTP Seqnum of the First Burst Packet (32 bits): 1078 Mandatory field that specifies the extended RTP sequence number of 1079 the first packet that will be sent as part of the burst. This 1080 allows RR to know if one or more packets have been dropped at the 1081 beginning of the burst. 32-bit extended RTP sequence number is 1082 constructed by putting the 16-bit RTP sequence number in the lower 1083 two bytes and octet 0's in the higher two bytes. 1085 o Earliest Multicast Join Time (32 bits): Optional TLV element that 1086 specifies the time difference (i.e., delta time) between the 1087 arrival of this RAMS-I message and the earliest time instant when 1088 RR could join the primary multicast session. A zero value in this 1089 field means that RR can join the primary multicast session right 1090 away. 1092 Editor's note: We need to decide whether we will use ms or RTP 1093 ticks in this field. 1095 Note that if the RAMS request has been accepted, RS MUST send this 1096 field at least once, so that RR knows when to join the primary 1097 multicast session. If the burst request has been rejected as 1098 indicated in the Response field, this field MAY be omitted or set 1099 to 0. In that case, it is up to RR when or whether to join the 1100 primary multicast session. 1102 o Burst Duration (32 bits): Optional TLV element that denotes the 1103 duration of the burst that RS is planning to send (in RTP ticks). 1104 In the absence of additional stimulus, RS will send a burst of 1105 this duration. However, the burst duration may be modified by 1106 subsequent events, including changes in the primary multicast 1107 stream and reception of RAMS-T messages. 1109 Note that RS MUST terminate the flow in a deterministic timeframe, 1110 even if it does not get an RAMS-T or a BYE from RR. It is 1111 optional to send this field in an RAMS-I message when the burst 1112 request is accepted. If the burst request has been rejected as 1113 indicated in the Response field, this field MAY be omitted or set 1114 to 0. 1116 o Max Burst Bitrate (32 bits): Optional TLV element that denotes 1117 the maximum bitrate (in bits per second) that will be used by RS 1118 for the unicast burst. 1120 The semantics of the RAMS-I feedback message is independent of the 1121 payload type. 1123 The RAMS-I message MAY be sent multiple times at the start of, prior 1124 to, or during the unicast burst. The subsequent RAMS-I messages MAY 1125 signal changes in any of the fields. 1127 7.3. RAMS Termination 1129 The RAMS Termination message is identified by PT=RTPFB and FMT=8. 1131 The FCI field MUST contain only one RAMS Termination. 1133 The RAMS Termination may be used to assist RS in determining when to 1134 stop the burst. 1136 If prior to sending the RAMS-T message RR has already joined the 1137 primary multicast session and received at least one RTP packet from 1138 the multicast session, RR includes the sequence number of the first 1139 RTP packet in the RAMS-T message. With this information, RS can 1140 decide when to terminate the unicast burst. 1142 If RR issues the RAMS-T message before it has joined and/or begun 1143 receiving RTP packets from the primary multicast session, RR does not 1144 specify any sequence number in the RAMS-T message, which indicates RS 1145 to stop the burst immediately. However, the RAMS-T message may get 1146 lost and RS may not receive this message. 1148 The FCI field has the structure depicted in Figure 7. 1150 0 1 2 3 1151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Extended RTP Seqnum of First Multicast Packet | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 : (TLV-encoded Extensions) : 1156 : : 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 Figure 7: FCI field syntax for the RAMS Termination message 1161 o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional 1162 TLV element that specifies the extended RTP sequence number of the 1163 of the first multicast packet received by RR. If no RTP packet 1164 has been received from the primary multicast session, this field 1165 does not exist and tells RS to stop the burst immediately. 1167 The semantics of the RAMS-T feedback message is independent of the 1168 payload type. 1170 7.4. Extensions 1172 To improve the functionality of the RAMS method in certain 1173 applications, it may be desirable to define new fields in the RAMS 1174 Request, Information and Termination messages. Such fields MUST be 1175 defined as TLV elements. If the goal in defining these new fields is 1176 to extend the protocol in a vendor-neutral manner, they MUST be 1177 registered with IANA through an Informational or a Standards-track 1178 RFC. The support for these new fields is OPTIONAL. In an RAMS 1179 message, any extension MUST be placed after any existing mandatory 1180 field for that message. 1182 Editor's note: We should specify the requirements for registering 1183 new TLV elements. 1185 It is also desirable to allow vendors to use vendor-specific 1186 extensions (in TLV format) in any of the RAMS messages. For 1187 interoperability, such extensions MUST NOT collide with each other. 1189 Editor's note: Some approaches are currently being examined for 1190 vendor-specific extensions. A potential solution is depicted in 1191 Figure 8. In this approach, the enterprise numbers are used from 1192 http://www.iana.org/assignments/enterprise-numbers. This will ensure 1193 the uniqueness of the vendor-specific extensions. 1195 0 1 2 3 1196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 : Mandatory Fields as Defined in This Document : 1199 : : 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Type = TBD | Length | Ent. Number | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Ent. Number contd. | Value | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Value contd. / 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 Figure 8: Structure of a vendor-specific extension 1210 8. SDP Definitions and Examples 1212 8.1. Definitions 1214 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. 1215 Here we add the following syntax to the 'rtcp-fb' attribute (the 1216 feedback type and optional parameters are all case sensitive): 1218 (In the following ABNF [RFC5234], fmt, SP and CRLF are used as 1219 defined in [RFC4566].) 1221 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1223 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1224 / fmt ; as defined in SDP spec 1226 rtcp-fb-val = "nack" SP "ssli" 1228 The following parameter is defined in this document for use with 1229 'nack': 1231 o 'ssli' stands for Stream Synchronization Loss Indication and 1232 indicates the use of RAMS messages as defined in Section 7. 1234 8.2. Examples 1236 This section provides a declarative SDP [RFC4566] example for 1237 enabling rapid acquisition of multicast RTP sessions. The following 1238 example uses the SDP grouping semantics [RFC3388], the RTP/AVPF 1239 profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP 1240 extensions for SSM sessions with unicast feedback 1241 [I-D.ietf-avt-rtcpssm] and the source-specific media attributes 1243 [I-D.ietf-mmusic-sdp-source-attributes]. 1245 In the example below, we have two primary source streams and two 1246 unicast retransmission streams for each of these source streams. The 1247 source streams are multicast from a distribution source (with a 1248 source IP address of 8.166.1.1) in different multicast sessions. For 1249 each source stream, a feedback target address (9.30.30.1) is also 1250 specified with the 'rtcp' attribute. The RTP receiver(s) can report 1251 missing packets on the source stream to the feedback target and 1252 request retransmissions. The parameter 'rtx-time' specifies the time 1253 in milliseconds (measured from the time a packet was first sent) that 1254 the sender (in this case the feedback target) keeps an RTP packet in 1255 its buffers available for retransmission. 1257 For the first source stream, only the conventional retransmission 1258 support is enabled. For the second source stream, both the 1259 conventional retransmission and rapid acquisition support are 1260 enabled. This is achieved by the "a=rtcp-fb:98 nack ssli" line. 1262 When an RTP receiver requires rapid acquisition for a new multicast 1263 session it wants to join, it sends an RAMS-R message to the feedback 1264 target. This feedback message has to have the SSRC of the primary 1265 source session for which rapid acquisition is requested for. 1266 However, since this RTP receiver has not received any RTP packets 1267 from this primary source session yet, the RTP receiver MUST learn the 1268 SSRC value from the 'ssrc' attribute of the media description 1269 [I-D.ietf-avt-rtcpssm]. In addition to the SSRC value, the 'cname' 1270 source attribute MUST also be present in the SDP description 1271 [I-D.ietf-mmusic-sdp-source-attributes]. Note that listing the SSRC 1272 values for the primary source sessions in the SDP file does not 1273 create a problem in SSM sessions when an SSRC collision occurs. This 1274 is because in SSM sessions, an RTP receiver that observed an SSRC 1275 collision with a media source MUST change its own SSRC 1276 [I-D.ietf-avt-rtcpssm] by following the rules defined in [RFC3550]. 1278 A feedback target that receives an RAMS-R feedback message becomes 1279 aware that the prediction chain at the RTP receiver side has been 1280 broken or does not exist any more. If the necessary conditions are 1281 satisfied (as outlined in Section 7 of [RFC4585]) and available 1282 resources exist, the feedback target MAY react to the RAMS-R message 1283 by sending any payload-specific feedback message(s) and starting the 1284 unicast burst. 1286 v=0 1287 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1288 s=Rapid Acquisition Examples 1289 t=0 0 1290 a=group:FID 1 2 1291 a=group:FID 3 4 1292 a=rtcp-unicast:rsi 1293 m=video 40000 RTP/AVPF 96 1294 i=Primary Multicast Stream #1 1295 c=IN IP4 224.1.1.1/255 1296 a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2 1297 a=recvonly 1298 a=rtpmap:96 MP2T/90000 1299 a=rtcp:40001 IN IP4 192.0.2.1 1300 a=rtcp-fb:96 nack 1301 a=mid:1 1302 m=video 40002 RTP/AVPF 97 1303 i=Unicast Retransmission Stream #1 (Ret. Support Only) 1304 c=IN IP4 192.0.2.1 1305 a=recvonly 1306 a=rtpmap:97 rtx/90000 1307 a=rtcp:40003 1308 a=fmtp:97 apt=96 1309 a=fmtp:97 rtx-time=3000 1310 a=mid:2 1311 m=video 41000 RTP/AVPF 98 1312 i=Primary Multicast Stream #2 1313 c=IN IP4 224.1.1.2/255 1314 a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 1315 a=recvonly 1316 a=rtpmap:98 MP2T/90000 1317 a=rtcp:41001 IN IP4 192.0.2.1 1318 a=rtcp-fb:98 nack 1319 a=rtcp-fb:98 nack ssli 1320 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1321 a=mid:3 1322 m=video 41002 RTP/AVPF 99 1323 i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) 1324 c=IN IP4 192.0.2.1 1325 a=recvonly 1326 a=rtpmap:99 rtx/90000 1327 a=rtcp:41003 1328 a=fmtp:99 apt=98; rtx-time=5000 1329 a=mid:4 1331 The offer/answer model considerations [RFC3264] for the 'rtcp-fb' 1332 attribute are provided in Section 4.2 of [RFC4585]. 1334 Editor's note: We will provide more SDP examples in a later version 1335 as needed. 1337 9. NAT Considerations 1339 Editor's note: This section will explain the potential issues 1340 experienced in NAT environments. Some solution approaches will be 1341 presented. This section will also include a recommendation for the 1342 RTP/RTCP Muxing solution that is discussed in 1343 [I-D.ietf-avt-rtp-and-rtcp-mux]. 1345 10. Known Implementations 1347 10.1. Open Source RTP Receiver Implementation by Cisco 1349 An open source RTP Receiver code that implements the functionalities 1350 introduced in this document is available. For documentation, visit 1351 the following URL: 1353 http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_0/user/guide/ 1354 ch1_over.html 1356 The code is also available at: 1358 ftp://ftpeng.cisco.com/ftp/vqec/ 1360 Note that this code is under development and may be based on an 1361 earlier version of this document. As we make progress in the draft, 1362 the source code will also be updated to reflect the changes. 1364 Some preliminary results based on this code are available in [CCNC09] 1365 and [IC2009]. 1367 10.2. IPTV Commercial Implementation by Microsoft 1369 Rapid Acquisition of Multicast RTP Sessions is supported as part of 1370 the Microsoft Mediaroom Internet Protocol Television (IPTV) and 1371 multimedia software platform. This system is in wide commercial 1372 deployment. More information can be found at: 1374 http://www.microsoft.com/mediaroom 1376 http://informitv.com/articles/2008/10/13/channelchangetimes/ 1378 11. Open Issues 1380 o Update message formats to reflect the TLV encapsulations. 1382 o Check whether we can register only one FMT value for all RAMS 1383 messages and use a sub FMT value in the messages to indicate the 1384 specific RAMS message. This change seams feasible and will be 1385 made in a later version. 1387 o Define the structure for vendor-specific extensions and check 1388 whether SDES can be used for this purpose. 1390 o The use of extended seqnums in the RAMS messages. 1392 o Check whether RFC 5506 should be used/supported. 1394 o Update the SDP example (Use correct unicast and multicast 1395 addresses). 1397 o Burst shaping issues and security considerations sections. 1399 12. Security Considerations 1401 TBC. 1403 13. IANA Considerations 1405 This document registers a new SDP attribute value and several new 1406 RTCP packets. 1408 The following contact information shall be used for all registrations 1409 in this document: 1411 Ali Begen 1412 abegen@cisco.com 1414 170 West Tasman Drive 1415 San Jose, CA 95134 USA 1417 13.1. Registration of SDP Attribute Values 1419 This document registers a new value for the 'nack' attribute to be 1420 used with the 'rtcp-fb' attribute in SDP. For more information about 1421 'rtcp-fb', refer to [RFC4585]. 1423 Value name: ssli 1424 Long name: Stream Synchronization Loss Indication 1425 Usable with: nack 1426 Reference: This document 1428 13.2. Registration of FMT Values 1430 Within the RTPFB range, the following three format (FMT) values are 1431 registered: 1433 Name: RAMS-R 1434 Long name: Rapid Acquisition of Multicast Sessions Request 1435 Value: 6 1436 Reference: This document 1438 Name: RAMS-I 1439 Long name: Rapid Acquisition of Multicast Sessions Information 1440 Value: 7 1441 Reference: This document 1443 Name: RAMS-T 1444 Long name: Rapid Acquisition of Multicast Sessions Termination 1445 Value: 8 1446 Reference: This document 1448 14. Acknowledgments 1450 The authors would like to specially thank Peilin Yang for his 1451 contributions to this document and detailed reviews. 1453 The authors also thank the following individuals for their 1454 contributions, comments and suggestions to this document: Dave Oran, 1455 Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, Roni 1456 Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Zou, 1457 Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and Sean 1458 Sheedy. 1460 15. Change Log 1461 15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-03 1463 The following are the major changes compared to version 02: 1465 o The title and message names have been changed. 1467 o RTCP message semantics have been added. RAMS protocol has been 1468 revised to handle updated requests and responses. 1470 o Definitions have been revised. 1472 o RTP/RTCP muxing reference has been added. 1474 15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-02 1476 The following are the major changes compared to version 01: 1478 o The discussion around MPEG2-TS has been moved to another document. 1480 o The RAMS-R, RAMS-I and RAMS-T messages have been extensively 1481 modified and they have been made mandatory. 1483 o IANA Considerations section has been updated. 1485 o The discussion of RTCP XR report has been moved to another 1486 document. 1488 o A new section on protocol design considerations has been added. 1490 15.3. draft-versteeg-avt-rapid-synchronization-for-rtp-01 1492 The following are the major changes compared to version 00: 1494 o The core of the rapid synchronization method is now payload- 1495 independent. But, the draft still defines payload-specific 1496 messages that are required for enabling rapid synch for the RTP 1497 flows carrying MPEG2-TS. 1499 o RTCP APP packets have been removed, new RTCP transport-layer and 1500 payload-specific feedback messages have been defined. 1502 o The step for leaving the current multicast session has been 1503 removed from Section 6.2. 1505 o A new RTCP XR (Multicast Join) report has been defined. 1507 o IANA Considerations section have been updated. 1509 o Editorial changes to clarify several points. 1511 16. References 1513 16.1. Normative References 1515 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1516 Jacobson, "RTP: A Transport Protocol for Real-Time 1517 Applications", STD 64, RFC 3550, July 2003. 1519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1520 Requirement Levels", BCP 14, RFC 2119, March 1997. 1522 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1523 Thyagarajan, "Internet Group Management Protocol, Version 1524 3", RFC 3376, October 2002. 1526 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1527 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1529 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1530 Group Management Protocol Version 3 (IGMPv3) and Multicast 1531 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1532 Specific Multicast", RFC 4604, August 2006. 1534 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1535 Description Protocol", RFC 4566, July 2006. 1537 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1538 Schulzrinne, "Grouping of Media Lines in the Session 1539 Description Protocol (SDP)", RFC 3388, December 2002. 1541 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1542 "Extended RTP Profile for Real-time Transport Control 1543 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1544 July 2006. 1546 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1547 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1548 July 2006. 1550 [I-D.ietf-avt-rtcpssm] 1551 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 1552 Extensions for Single-Source Multicast Sessions with 1553 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 1554 progress), March 2009. 1556 [I-D.ietf-mmusic-sdp-source-attributes] 1557 Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1558 Media Attributes in the Session Description Protocol 1559 (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work 1560 in progress), October 2008. 1562 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1563 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1565 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1566 with Session Description Protocol (SDP)", RFC 3264, 1567 June 2002. 1569 16.2. Informative References 1571 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1572 August 1980. 1574 [I-D.ietf-rmt-pi-norm-revised] 1575 Adamson, B., Bormann, C., London, U., and J. Macker, 1576 "NACK-Oriented Reliable Multicast Protocol", 1577 draft-ietf-rmt-pi-norm-revised-11 (work in progress), 1578 April 2009. 1580 [I-D.begen-avt-rtp-mpeg2ts-preamble] 1581 Begen, A., "RTP Payload Format for MPEG2-TS Preamble", 1582 draft-begen-avt-rtp-mpeg2ts-preamble-00 (work in 1583 progress), March 2009. 1585 [I-D.begen-avt-rapid-sync-rtcp-xr] 1586 Begen, A., "Rapid Multicast Synchronization Report Block 1587 Type for RTCP XR", draft-begen-avt-rapid-sync-rtcp-xr-00 1588 (work in progress), March 2009. 1590 [I-D.ietf-avt-rtp-and-rtcp-mux] 1591 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1592 Control Packets on a Single Port", 1593 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 1594 August 2007. 1596 [CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified 1597 Approach for Repairing Packet Loss and Accelerating 1598 Channel Changes in Multicast IPTV (IEEE CCNC)", 1599 January 2009. 1601 [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing 1602 Channel Change Times in IPTV with Real-Time Transport 1603 Protocol (IEEE Internet Computing)", May 2009. 1605 Authors' Addresses 1607 Bill VerSteeg 1608 Cisco Systems 1609 5030 Sugarloaf Parkway 1610 Lawrenceville, GA 30044 1611 USA 1613 Email: billvs@cisco.com 1615 Ali Begen 1616 Cisco Systems 1617 170 West Tasman Drive 1618 San Jose, CA 95134 1619 USA 1621 Email: abegen@cisco.com 1623 Tom VanCaenegem 1624 Alcatel-Lucent 1625 Copernicuslaan 50 1626 Antwerpen, 2018 1627 Belgium 1629 Email: Tom.Van_Caenegem@alcatel-lucent.be 1631 Zeev Vax 1632 Microsoft Corporation 1633 1065 La Avenida 1634 Mountain View, CA 94043 1635 USA 1637 Email: zeevvax@microsoft.com