idnits 2.17.1 draft-vancaenegem-avtcore-retransmission-for-ssm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 26, 2011) is 4711 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 (-17) exists of draft-ietf-avtcore-feedback-supression-rtp-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE T. VanCaenegem 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track B. VerSteeg 5 Expires: November 27, 2011 A. Begen 6 Cisco 7 May 26, 2011 9 Retransmission for Source-Specific Multicast (SSM) Sessions 10 draft-vancaenegem-avtcore-retransmission-for-ssm-00 12 Abstract 14 This document describes RTP retransmission for source-specific 15 multicast (SSM) architectures with unicast feedback. RTP payload 16 format for retransmissions has been defined in RFC 4588, whereas the 17 RTP profile an RTP receiver could use to issue RTP Control Protocol 18 (RTCP) feedback messages and the format of these feedback messages 19 have been defined in RFC 4585. RFC 5760 defines the operation for 20 SSM architectures with unicast feedback. 22 First, we document potential issues that could arise when providing a 23 retransmission service using RTP retransmission (RFC 4588 and RFC 24 4585) for RFC 5760 architectures based on rules described in the 25 relevant RFCs. We then present solutions that allow to avoid 26 unnecessary feedback suppression, provide enhanced retransmission 27 services and address congestion control for retransmission in an SSM 28 environment. These solutions specify certain rules that apply to the 29 distribution source, feedback target(s), retransmission source(s) and 30 RTP receivers. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 27, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 68 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Feedback Suppression and Retransmission for SSM: 70 Applicable Specifications . . . . . . . . . . . . . . . . . . 6 71 4.1. RTCP Feedback Suppression in RFC 4585 . . . . . . . . . . 6 72 4.2. RTCP Feedback Message Distribution in RFC 5760 . . . . . . 7 73 4.3. RAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Pitfalls When Combining RTCP Feedback Handling and 75 Retransmission Using RFC 5760 Rules . . . . . . . . . . . . . 10 76 5.1. Case of DS Forwarding/Reflecting All RTCP NACKs . . . . . 10 77 5.2. Case of DS Terminating All RTCP NACKs . . . . . . . . . . 10 78 5.3. Case of Multiple FTs . . . . . . . . . . . . . . . . . . . 11 79 5.4. Takeaways . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. Rules for SSM with Retransmissions . . . . . . . . . . . . . . 13 81 6.1. Feedback Suppression Behavioral Requirements for DS, 82 FT and RTP_Rx's . . . . . . . . . . . . . . . . . . . . . 13 83 6.2. Informing RTP_Rx's with the SSRC Value of FT/RS . . . . . 15 84 6.3. Unsolicited Retransmissions . . . . . . . . . . . . . . . 17 85 6.4. Congestion Control Considerations . . . . . . . . . . . . 18 86 6.4.1. Congestion Control in RFC 4585 and in RAMS . . . . . . 18 87 6.4.2. Congestion Handling for SSM with Retransmissions . . . 19 88 6.5. New RSI Message and RAMS-I TLV Extension . . . . . . . . . 21 89 6.5.1. RSI Message 'FT SSRC List' . . . . . . . . . . . . . . 21 90 6.5.2. RAMS-I TLV Extension 'FT SSRC' . . . . . . . . . . . . 21 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 9. RTP Retransmission Service in DVB IPTV . . . . . . . . . . . . 22 94 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 101 1. Introduction 103 The RTP toolkit is used to deliver a variety services over IP 104 multicast. [RFC5760] defines a source-specific multicast (SSM) 105 architecture with one or several Media Senders, a Distribution Source 106 (DS) (sourcing the SSM), one or several Feedback Targets (FT) that 107 may or may not be co-joint with the DS and RTP receivers (RTP_Rx) 108 that send unicast feedback to a FT. This document explores the 109 complications one might face when adding one or more Retransmission 110 Sources (RSo) in this architecture for reliable multicast 111 distribution. 113 In this specification, we assume that FT and RSo logical entities are 114 combined in a single physical entity and they share state. In the 115 remainder of the text, the term Retransmission Server (RS) is used 116 whenever appropriate, to refer to this single physical entity. As in 117 [I-D.ietf-avt-rapid-acquisition-for-rtp], the RS receives the RTP 118 packets sent in an SSM session (as a normal RTP_Rx), and buffers 119 these packets for a certain time for retransmission purposes. 121 The term RAMS (Rapid Acquisition of Multicast Sessions) will be used 122 to refer to the protocol and architecture defined in 123 [I-D.ietf-avt-rapid-acquisition-for-rtp]. The RAMS specification 124 presents a method in which an RTP_Rx can rapidly acquire reference 125 information transported in an SSM session. This is enabled by having 126 the RTP_Rx retrieve a unicast burst of data from an RS, formatted as 127 RTP retransmission packets prior to joining the SSM session. While 128 the present document will include some requirements and observations 129 expressed in [I-D.ietf-avt-rapid-acquisition-for-rtp], it will 130 particularly focus on the impact of packet loss events experienced in 131 an SSM distribution, and how the elements in the SSM architecture 132 interact best to ensure impacted RTP_Rx's are provided with 133 appropriate RTP retransmissions. 135 A packet loss event in an SSM session, will in general trigger one or 136 multiple interactions between the RTP_Rx and the FT/RS/DS entities: 138 o The RTP_Rx sending an RTCP NACK message to the FT ([RFC4585]) 140 o The RTP_Rx receiving RTP retransmission(s) from the RS 142 o The RTP_Rx receiving an RTCP feedback message from the DS 144 This document describes the behavior for all entities defined in an 145 SSM architecture with unicast feedback as described in [RFC5760] (DS, 146 FT, RS and RTP_Rx) addressing feedback implosion (avoidance), 147 retransmission efficacy and congestion concerns. 149 One application that can benefit from this document is IPTV. In many 150 IPTV deployments, streams are transported over SSM. Transporting 151 this data over SSM enables a packet loss recovery by means of RTP 152 retransmissions and/or forward error correction (FEC) 153 [I-D.ietf-fecframe-dvb-al-fec]. This document focuses on 154 retransmission. Note that Digital Video Broadcasting (DVB) forum has 155 specified an RTP retransmission solution for its managed Linear Media 156 Broadcast (LMB) service, and which references most of the relevant 157 RTP specifications. An overview of this solution is provided in 158 Section 9. 160 2. Requirements Notation 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in 165 [RFC2119]. 167 3. Definitions 169 This document uses some acronyms and definitions which have been 170 introduced [I-D.ietf-avt-rapid-acquisition-for-rtp] as the baseline. 171 Some of these definitions have been slightly retailored to fit the 172 restricted scope of this document. 174 (Primary) SSM (or Multicast) Session: The multicast session to which 175 RTP_Rx's can join at a random point in time. A primary SSM session 176 can carry multiple RTP streams. 178 Primary Multicast RTP Session: The multicast RTP session that is of 179 interest to an RTP receiver. It comprises the primary multicast RTP 180 stream(s) and an associated unicast RTCP feedback stream to a 181 Feedback Target. 183 Primary Multicast (RTP) Streams: The RTP stream(s) carried in the 184 primary multicast RTP session. 186 Source Filtering Group Management Protocol (SFGMP): Following the 187 definition in [RFC4604], SFGMP refers to the Internet Group 188 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 189 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 190 IPv6 networks, respectively. In the remainder of this document, 191 SFGMP will refer to any group management protocol that has Join and 192 Leave functionalities. 194 Feedback Target (FT): Unicast RTCP feedback target as defined in 196 [RFC5760]. FT_Ap denotes a specific feedback target running on a 197 particular address and port. 199 Retransmission Packet: An RTP packet that is formatted as defined in 200 Section 4 of [RFC4588]. The payload of a retransmission packet 201 comprises the retransmission payload header followed by the payload 202 of the original RTP packet. 204 (Unicast) Retransmission RTP Session: The unicast RTP session used 205 to send one or more unicast retransmission RTP streams and their 206 associated RTCP messages. This session is setup as described in 207 [I-D.ietf-avtcore-ports-for-ucast-mcast-rtp]. 209 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 210 the retransmission packets. 212 New definitions introduced in this document are: 214 Solicited Retransmission: Retransmission packet(s) that are received 215 by an RTP_Rx which have been explicitly requested by this RTP_Rx by 216 means of one or more RTCP NACKs. 218 Unsolicited Retransmission: Retransmission packet(s) that are 219 received by an RTP_Rx which have not been explicitly requested by 220 this RTP_Rx by means of an RTCP NACK. 222 Feedback Implosion/Storm: The situation where multiple RTP receivers 223 start sending (quasi-) simultaneously (RTCP) feedback, often 224 triggered by an upstream packet loss event in the SSM tree impacting 225 a large set of RTP receivers. 227 4. Feedback Suppression and Retransmission for SSM: Applicable 228 Specifications 230 In this section we first look at the various specifications in place 231 that describe the architecture for SSM with unicast feedback and 232 determine how feedback suppression and retransmission are 233 accomplished. 235 4.1. RTCP Feedback Suppression in RFC 4585 237 [RFC4585] defines an RTP profile for an RTP receiver that wishes to 238 provide fast feedback by means of RTCP feedback messages, such as is 239 applicable to an RTP retransmission scenario. [RFC4585] defines the 240 timing rules by which such RTCP feedback messages can be transmitted 241 both in unicast and multicast/multi-party sessions, and it also 242 defines the general format of RTCP feedback messages, as well as some 243 specific feedback messages. One of the transport-layer feedback 244 messages that is particularly relevant here is the RTCP NACK message 245 through which an RTP receiver can report missing packets. The 246 missing packets are identified by means of an SSRC identifier 247 (associated with the primary multicast stream for which the DS uses 248 this SSRC as media sender) and an RTP sequence number (SN). The RS 249 receiving such an RTCP NACK message can respond by sending 250 retransmission packets whose format has been described in [RFC4588]. 251 An important aspect covered by [RFC4585] is feedback suppression for 252 RTP receivers involved in a multi-party session in order to avoid 253 feedback implosion. To that extent, the RTP receiver waits for a 254 (short) random dithering interval to check whether it sees a feedback 255 message from any other RTP receiver reporting the same event. If 256 such a feedback message is received, the RTP receiver refrains from 257 sending the feedback message and continues to follow the regular RTCP 258 transmission schedule. Note that a feedback message from one RTP 259 receiver is typically not visible to other RTP receivers, so the FT 260 might need to provide information to the RTP receivers. We will 261 investigate the implications of this feedback suppression rule for 262 SSM architectures with unicast feedback as defined in [RFC5760], 263 where one or multiple RS's are deployed. To that extent we first 264 provide an overview of how RTCP feedback messages transmitted by the 265 RTP receivers are handled in the SSM architecture as specified by 266 [RFC5760]. 268 4.2. RTCP Feedback Message Distribution in RFC 5760 270 Two models in terms of DS behavior have been defined in [RFC5760]: 272 o In Feedback Summary Model, the unicast RTCP receiver report 273 messages from the RTP_Rx's are by default aggregated at the DS and 274 their information is transmitted as Receiver Summary Information 275 (RSI) messages in the SSM session. The RTCP feedback messages are 276 by default terminated by the DS. However, the DS might also 277 aggregate or forward RTCP feedback messages and transmit them in 278 the SSM session, when this is explicitly signaled. Note that from 279 the RTP perspective, the DS is an RTP_Rx generating its own RTCP 280 receiver reports as well as other RTCP packets and sending them to 281 the receiver group and media senders. 283 o In Simple Feedback Model, the DS reflects all RTCP messages 284 (including RTCP feedback) received in unicast via the FT from the 285 RTP_Rx's. Note that many network topologies have a high degree of 286 fanout, and also have a constrained link between the FT and the 287 RTP_Rx's, so that reflecting all of the feedback messages is often 288 not feasible. 290 The communication between DS and disjoint FT(s) occurs as follows: 292 [RFC5760] indicates that for the Simple Feedback Model where the 293 FT(s) are disjoint from the DS, the FT must forward all RTCP packets 294 to the DS. 296 [RFC5760] indicates the following for the Feedback Summary Model 297 where the FT(s) are disjoint from the DS: 299 o The FTs may simply forward all RTCP packets incoming from the 300 RTP_Rx's to the DS. 302 o The FTs may also perform aggregation of incoming RTCP packets and 303 send only aggregated information to the DS. 305 o If the FT performs summarization functions, it must also act as a 306 receiver and choose a unique SSRC for its own reporting towards 307 the DS. 309 4.3. RAMS 311 Assume now that the FT is combined with an RSo, constituting together 312 the RS, which provides retransmissions in response to unicast RTCP 313 NACK messages received from RTP_Rx's. Such architecture is described 314 in [I-D.ietf-avt-rapid-acquisition-for-rtp] where the FT is co-joint 315 with a Burst/Retransmission Source (BRS). 317 Figure 1 shows the main entities involved in SSM with retransmission 318 enabled. They are 320 o Distribution Source 322 o Feedback Target (FT) 324 o Retransmission Source (RSo) 326 o RTP Receiver (RTP_Rx) 328 The figure also shows the various RTP/RTCP flows and associated 329 sessions. The difference with RAMS is that the Burst/Retransmission 330 Source (BRS) is replaced with a Retrasmission Source (RSo). Another 331 difference - not shown in the figure - is that next to the primary 332 multicast session, there might also be a (source-specific) multicast 333 retransmission session that can be sourced by the same DS entity 334 (acting as an RS itself) or by the same RS that provides the unicast 335 retransmissions. This is discussed in more detail in Section 6.3. 336 The unicast retransmission session must be established as per 337 [I-D.ietf-avtcore-ports-for-ucast-mcast-rtp]. Note that when RAMS 338 and retransmissions are provided for the same SSM session, a single 339 unicast retransmission session is established. The RAMS 340 specification puts a constraint on the RS/FT, stating that an FT 341 (identified by means of IP address and port, and referred to as 342 FT_Ap) must be associated with only a single RTP session. This 343 constraint was put in place, because an RTP_Rx using the RAMS service 344 may not necessarily know the media sender SSRC a priori. However, an 345 RTP_Rx using the retransmission service can of course learn the SSRC 346 by inspecting the SSRC identifier field in the RTP packets, and 347 furthermore the SSRC field needs to be correctly filled out in the 348 RTCP NACK message. Thus, while we do not have this constraint on FTs 349 when only the retransmission service is enabled, the contraint still 350 applies when both RAMS and retransmission services are enabled. 352 ----------- -------------- 353 | |------------------------------------>| | 354 | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | 355 | | | | 356 | Distrib. | ---------------- | | 357 | Source | | Retransmission | | | 358 | |-------->| Server (RS) | | | 359 | |.-.-.-.->| | | | 360 | | | ------------ | | | 361 ----------- | | Feedback | |<.=.=.=.=.| | 362 | | Target (FT)| |<~~~~~~~~~| RTP Receiver | 363 PRIMARY SSM | ------------ | | (RTP_Rx) | 364 RTP SESSION with | | | | 365 UNICAST FEEDBACK | | | | 366 | | | | 367 - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- - 368 | | | | 369 UNICAST | ------------ | | | 370 RETRANSMISSION | | | |<~~~~~~~~>| | 371 RTP SESSION | | Retrans. | |.........>| | 372 | |Source (RSo)| |<.=.=.=.=>| | 373 | ------------ | | | 374 | | | | 375 ---------------- -------------- 377 -------> Multicast RTP Flow 378 .-.-.-.> Multicast RTCP Flow 379 .=.=.=.> Unicast RTCP Reports 380 ~~~~~~~> Unicast RTCP Feedback Messages 381 .......> Unicast RTP Flow 383 Figure 1: Flow diagram for SSM with retransmission 385 5. Pitfalls When Combining RTCP Feedback Handling and Retransmission 386 Using RFC 5760 Rules 388 In this section, we investigate a number of scenarios in terms of SSM 389 topology and behavior of the DS with respect to the forwarding/ 390 termination of RTCP feedback messages received from RTP_Rx's. In the 391 first two scenarios, we assume there is only one FT. Note that the 392 DS could be joint with the FT or disjoint from the FT. 394 5.1. Case of DS Forwarding/Reflecting All RTCP NACKs 396 The forwarding of RTCP feedback messages is one option allowed for by 397 the Feedback Summary Model of [RFC5760], where reflection is what the 398 DS must do based on the Simple Feedback Model of RFC 5760. In this 399 case, RTP_Rx's applying the [RFC4585]suppression rule will result in 400 the following: when an RTP_Rx X reports a packet loss to the FT by 401 sending an RTCP NACK, this message is distributed, via the FT and, by 402 the DS via the SSM to all other RTP_Rx's. If an RTP_Rx Y, different 403 from RTP_Rx X, detected the same packet loss, but prior to sending 404 out a NACK, this receiver Y gets the NACK message originally sent by 405 X, it will refrain from sending a NACK, following [RFC4585]. The 406 forwarding/reflection of RTCP NACK messages effectively results in 407 feedback suppression, but obviously this is at the expense of limited 408 visibility to the RS on which RTP_Rx suffered packet loss. In 409 general this will result in a decreased quality at the service layer 410 for any RTP_Rx X, because the SSM receiver does not even get an 411 opportunity to report its packet loss by means of an RTCP NACK. Note 412 that for packet losses upstream of the DS and which subsequently 413 impact all RTP_Rx's, the DS does not need to be informed by each 414 individual RTP_Rx about this packet loss. When the DS is capable of 415 recovering the lost packet in due time, it may send an unsolicited 416 retransmission to all RTP_Rx's. The reduced visibility to the RS of 417 packet losses taking place downstream of the DS, could be compensated 418 for by having the RS sending an unsolicited retransmission, whenever 419 an RTCP NACK is received. This will increase the chance on network 420 congestion and will also consume RS processing resources when 421 retransmissions are provided over unicast. The conclusion is that 422 reflection/forwarding of RTCP NACK messages by the DS is not (always) 423 the "right" thing to do. 425 5.2. Case of DS Terminating All RTCP NACKs 427 Not forwarding and hence terminating RTCP feedback messages is the 428 alternative option for a DS behaving in [RFC5760] Feedback Summary 429 Model. In this case every RTP_Rx that detects a packet loss event, 430 will also transmit an RTCP NACK (assuming no congestion is sensed by 431 the receiver, see Section 6.4.2 ). We look at two example scenarios 432 resulting in different consequences: As a first example: two or 433 multiple RTP_Rx's detect the same packet loss, which was caused by 434 two or multiple un-related packet loss events taking place (quasi-) 435 simultaneously. This could be caused by link transmission errors, 436 such as on xDSL links or in cable networks. In this case, the RS 437 will receive the NACKs from all impacted receivers, and can act 438 accordingly by sending a unicast (solicited) retransmission to the 439 impacted receivers. As a second example, take the case considered 440 previously where a packet loss event took place on the link between a 441 media sender and the DS. Because, even though the transmissions 442 could be dispersed in a time frame Delta T, when a very large number 443 of SSM receivers are impacted by the single packet loss event, a 444 feedback implosion might occur. This may load the network link(s) 445 downstream of the RS and the RS itself, beyond its processing 446 capabilities. Clearly, this is a case where the feedback suppression 447 rule of [RFC4585] would be useful. The conclusion is that 448 termination of RTCP NACK messages by the DS is not (always) the 449 "right" thing to do. 451 5.3. Case of Multiple FTs 453 A specific case of SSM with unicast feedback, is where there are 454 multiple FTs, disjoint from the DS. Similar as before, in the 455 considered architectures, each FT is combined with a retransmission 456 source, constituting a retransmission server. Note that the RS are 457 generally not positioned in the direct SSM path between the DS and 458 the RTP_Rx's, i.e., an RS is typically a leaf of the SSM tree. This 459 architecture provides a scalable solution for SSM with a large 460 population of receivers, because it is able to distribute RTCP 461 feedback processing loads across different entities in different 462 parts of the network. It is an architecture that is well suited for 463 IPTV networks, where the DS is the head-end sourcing the SSM that 464 carries video broadcast streams over IP. Note that we again assume 465 that the RTP_Rx's behave compliant to [RFC4585], inclusive 466 conformance to the feedback suppression rule. The previous 467 discussions on feedback suppression (or absence of feedback 468 suppression) and its consequences on retransmissions for the SSM with 469 single FT topology remains applicable and valid for the SSM with 470 multiple (disjoint) FTs topology. A distributed FT architecture 471 brings in an additional aspect that should be addressed, and a 472 dedicated example packet loss event use case visualizes this. The 473 considered topology is a DS with two disjoint FT/RS entities, FT/RS 1 474 and FT/RS 2 , where each FT receives RTCP messages from a separate 475 group of RTP_Rx's. The assumption is that 477 o An RTP packet (with RTP sequence number N) in the primary SSM got 478 dropped in the network upstream of the FT 1 and upstream of the 479 SSM receivers that report to FT 1. 481 o The FT 2 and the SSM receivers reporting to FT 2 are not impacted 482 by the packet loss event impacting FT 1. This is because the FT 2 483 and its reporting SSM receivers do not get the original SSM 484 packets from the DS via the router where the packet loss impacting 485 FT 1 took place. 487 The FT 1 and its reporting SSM receivers experience a situation that 488 is discussed in a previous section. Because the packet loss event 489 impacts all SSM receivers reporting to FT 1, it is important that 490 those receivers in general suppress sending an RTCP NACK. Hence 491 having the FT 1 forwarding the first received RTCP NACK(s) from an 492 RTP_Rx to the DS which then reflects/forwards the NACK over the 493 original SSM, is the correct thing to do from that point of view. 494 However, the reflection /forwarding of the NACK by the DS means that 495 also the RTP_Rx's reporting to the FT 2 will suppress sending an RTCP 496 NACK for packet N in the SSM. As a consequence, a packet loss event 497 involving an RTP packet with SN N impacting a single RTP_Rx reporting 498 to FT 2 / RS 2 -e.g. due to a link transmission error- will not be 499 reported by this RTP_Rx to RS 2. 501 This means there is a discrepancy between the network reach of the 502 suppression (covering all SSM receivers) and the actual network 503 domain that was commonly impacted by the packet loss. The RS 2 will 504 in general not know whether there are any SSM receivers (reporting to 505 FT 2) that missed RTP packet with RTP SN N. Note also that an 506 unsolicited retransmission by RS 1 optionally following the loss 507 detection for packet with SN N -can remain confined to the subdomain 508 impacted by the loss, when the FT is co-located with the RS (using 509 either unicast retransmission sessions or a multicast retransmission 510 session sourced by the RS). 512 SSM with multiple disjoint unicast FTs hence may result in efficient 513 feedback storm suppression across all RTP_Rx's, but this also 514 prevents any RTP_Rx from sending an RTCP NACK for detected packet 515 loss, even when no feedback storm was imminent for the subdomain 516 covered by a particular FT. A solution for maximizing the 517 retransmission service fulfillment may be for the DS to also act as 518 RS and always send retransmissions requested by a particular FT, over 519 a separate retransmission SSM to all RTP_Rx's. However, this 520 unnecessarily loads the network and requires all the SSM RTP 521 receivers to join both a primary SSM and the multicast retransmission 522 session. 524 5.4. Takeaways 526 The general conclusion from these three scenarios is that feedback 527 suppression enabled by having the DS forwarding/reflecting RTCP 528 Messages received from the RTP_Rx's or (disjoint) FTs is sometimes 529 the right thing to do, but sometimes feedback suppression is not 530 appropriate and interferes in a negative way with the packet loss 531 reporting and retransmission service. 533 6. Rules for SSM with Retransmissions 535 6.1. Feedback Suppression Behavioral Requirements for DS, FT and 536 RTP_Rx's 538 The combination of the [RFC4585] suppression rule imposed on RTP_Rx's 539 and the behavior of the DS and the FT(s) -when disjoint from the DS- 540 as specified in [RFC5760], does result in non-ideal situations when 541 deploying an SSM RTP session with Retransmission Server(s), 542 especially for a large group of receivers. In this section we 543 provide some rules for DS and FT on the one hand and RTP_Rx's on the 544 other hand, which impose a deviation respectively from rules defined 545 in [RFC5760] and [RFC4585] , and which results in: 547 o All RTP_Rx's offering the opportunity to report detected packet 548 loss by means of RTCP NACK when there is no risk on feedback 549 implosion 551 o RTCP NACK suppression (only) when RTCP NACK implosion is imminent 553 o A better retransmission efficacy 555 The rules apply to the transmission and handling of RTCP NACK 556 messages by RTP_Rx's and FT, but similar rules may be applicable for 557 other RTCP feedback messages that may or may not trigger dedicated 558 service actions. 560 Note that in the context of this document, the FT is part of a 561 Retransmission Server, which is an RTP_Rx on its own. In the 562 remainder of this text, the term 'RTP_Rx' always refers to any RTP 563 receiver reporting to a FT/RS and which does not host a FT/RS 564 functionality, unless mentioned otherwise. 566 The rules are: 568 1. A FT/RS that is disjoint from the DS MUST NOT forward nor reflect 569 RTCP NACK messages received from the RTP_Rx's, to the DS. 571 This behavior for a FT operating in an SSM enabled with 572 retransmission is different from the behavior prescribed by 573 [RFC5760] for a FT with a primary SSM operating in Simple 574 Feedback mode.This rule will prevent feedback suppression at the 575 RTP_Rx's directly triggered by RTCP feedback messages sent by 576 other RTP_Rx's. 578 2. A disjoint FT MAY send either an RTCP NACK or a 3rd party loss 579 RTCP feedback message, each time using its own SSRC, to the DS. 581 Note : The third party loss message format is defined in 582 [I-D.ietf-avtcore-feedback-supression-rtp]. 584 This behavior for a FT operating in an SSM enabled with 585 retransmission is different from the behavior prescribed by 586 [RFC5760] for a FT with a primary SSM operating in Simple 587 Feedback mode. 589 This rule will enable feedback suppression in the group of 590 RTP_Rx's reporting to this FT (see recommendation 5). 592 The FT/RS will send an RTCP NACK or 3rd party loss message 593 depending on the location of the packet loss event: 595 * The FT/RS SHOULD send an RTCP NACK to the DS -using its own 596 SSRC- when it detected packet loss itself (with the FT/RS 597 acting as an RTP_Rx). 599 * The FT/RS SHOULD send an RTCP NACK or a third party loss 600 message to the DS -using its own SSRC- when it did not detect 601 packet loss itself, but there is a risk on feedback implosion. 603 Feedback implosion risk detection by the FT without detecting 604 directly packet loss, can be based on monitoring the amount of 605 arriving RTCP NACKs from RTP_Rx's reporting the same packet loss, 606 and setting a threshold as function of the known amount of RTP 607 SSM receivers reporting to this FT/RS. 609 3. A DS MUST forward/reflect any RTCP NACK or RTCP third party loss 610 feedback message received from FT entities on the primary SSM RTP 611 session 613 4. When capable of detecting packet loss in the RTP streams received 614 from the media senders, the DS MUST send an RTCP NACK using its 615 own SSRC on the primary SSM RTP session and to the media senders 617 5. An RTP_Rx receiving a third party loss message or RTCP NACK in 618 the primary SSM RTP session MUST conform to the following 619 behavior: 621 If the SSRC identifier in the 'packet sender SSRC' field in the 622 received RTCP feedback message matches either 623 * the SSRC of the (primary SSM) DS (this is the 'media sender 624 SSRC') 626 * or the SSRC that is used by the FT/RS entity to which the 627 RTP_Rx reports (see next section) 629 the RTP_Rx MUST follow the feedback suppression rule defined in 630 [RFC4585], i.e. it abstains from sending an RTCP NACK for the 631 same SN. 633 If there is no match with these SSRC values, the RTP_Rx SHOULD 634 NOT apply the [RFC4585] feedback suppression rule 636 This behavior is different from [RFC4585], and prevents feedback 637 suppression when there is no risk on feedback implosion. 639 If the RTP_Rx does not know the value of the SSRC that is used by 640 the FT/RS entity -in its role towards the DS- to which the 641 receiver reports, it MAY still send its own RTCP feedback 642 message, when having detected the same packet loss, but 643 respecting the [RFC4585]timing rules. 645 RTP_Rx's that do not know the value of the SSRC that is used by 646 its FT/RS entity in its primary SSM role and abstain from sending 647 an RTCP NACK message when receiving such a message, implement 648 feedback suppression and behave as defined in [RFC4585]. 650 The next section describes how an RTP_Rx knows the value of the 651 SSRC that is used by the FT/RS entity to which the receiver 652 reports 654 6.2. Informing RTP_Rx's with the SSRC Value of FT/RS 656 There are different SSRC values that can be associated to the FT/RS: 658 o As described in [RFC5760], in summary feedback model, the FT must 659 act as a receiver and choose a unique SSRC for its own reporting 660 towards the Distribution Source. If a FT acts strictly according 661 to the Simple Feedback Model of [RFC5760], it does not need a 662 unique SSRC. However, with the recommendation '2' of the previous 663 section, the FT acts rather as translator when sending its own 664 RTCP NACK or Third Party Loss message to the DS. The FT selects a 665 SSRC value in its role as translator between the RTP_Rx's and the 666 DS. 668 o The FT is part of the RS and the RS will typically also act as 669 RTP_Rx, being the most efficient way for obtaining and caching 670 copies of RTP packets that are transmitted down the primary SSM 671 and providing retransmission from that RS. The RS selects a SSRC 672 value in its role as RTP_Rx as well, when reporting to the DS. 673 Nothing prevents this SSRC value to be the same as the SSRC value 674 used by the FT entity. 676 o An RS also takes a role as RTP sender towards each of the RTP_Rx's 677 that established a unicast retransmission session. In this 678 unicast retransmission session, the SSRC used by the RS is the 679 same as the SSRC value used by the DS in the primary SSM RTP 680 session, as per [RFC4588]. 682 Note that the CNAME of the FT/RS associated with all these SSRC 683 identifier values is one and the same. 685 It is the SSRC value used by the FT acting as receiver/translator in 686 the SSM with unicast feedback topology, that will be present in the 687 'Packet Sender SSRC' field of the RTCP NACK or Third Party Loss 688 message forwarded by the DS to the RTP_Rx's. There can be several 689 ways by which an RTP_Rx learns this SSRC value: 691 1. In-band : applies only for the Feedback Summary Model, where by 692 means of a new RSI "FT SSRC list" message, the DS provides a 693 listing of all deployed FT_Ap's with the corresponding SSRC for 694 each of these FTs/RSs. FTs/RSs are identified by means of their 695 IPv4/IPv6 address, optional port, and optional CNAME. The DS can 696 learn the SSRC value chosen by a FT/RS by inspecting RTCP 697 messages received from the FT. The DS sends regularly the RSI 698 "FT SSRC list" message down the primary SSM, to give every RTP_Rx 699 joining the SSM at a random time a chance to learn this SSRC 700 value. 702 2. Application-specific : a specific extension can be defined for 703 the RAMS-I message that signals the SSRC value associated with 704 the FT in its role as reporter to the DS. This RAMS-I message is 705 transferred in the Burst/Retransmission Session. 707 3. Out-of-band for either the Feedback Summary or Simple Feedback 708 Model of SSM operation, by advertising the FT's SSRC as a media 709 attribute for the FT in the SSM RTP session description 710 [RFC5576]. 712 The out-of-band signaling mechanism requires the application 713 signaling to know/learn the SSRCs deployed by the FTs prior to 714 signaling this information to the RTP_Rx's. 716 6.3. Unsolicited Retransmissions 718 The method of providing an (unsolicited) RTP retransmission packet to 719 a set of RTP_Rx's enables loss recovery for packet loss events 720 impacting a large set of receivers without risk for feedback 721 implosion. Unsolicited retransmissions can be provided over each of 722 the established unicast retransmission sessions or only once in a 723 single multicast retransmission session, sourced either by the DS or 724 by the RS. Providing (unsolicited) retransmissions over a separate 725 multicast retransmission RTP session has the following advantages: 727 o The retransmission packet is transmitted by the DS/RS only once, 728 saving both network and server resources. 730 o The multicast retransmission packet is less likely to be blocked 731 by any intermediate gateway or a middlebox on the path between the 732 DS/RS and RTP_Rx. 734 o An RTP_Rx that joins the multicast retransmission RTP session via 735 SFGMP, implicitly indicates it is willing to accept unsolicited 736 retransmissions. 738 The rules related to the feedback suppression in Section 6.1 do not 739 impose an RS/DS implementation to provide (support for) unsolicited 740 retransmissions. In this document, we assume that whenever the FT/ 741 RS/DS supports solicited retransmission and it actively suppresses 742 feedback by sending a RTCP NACK or 3rd party loss message, it might 743 try to provide one or more subsequent unsolicited retransmissions. 744 However, as it is the case with any RTP retransmission, such 745 unsolicited retransmissions may or may not arrive at their 746 destinations. 748 The requirements for unsolicited retransmissions are: 750 1. Unsolicited retransmissions MAY be provided over a separate 751 multicast retransmission that is sourced by the RS that also acts 752 as retransmission server for the unicast retransmission sessions 753 or by the DS that also sources the primary SSM session. 755 2. An RS SHOULD only send unsolicited retransmissions when it knows 756 with a minimum certainty that the receiver has implemented 757 feedback suppression for this specific packet (unicast 758 retransmission) or a majority of the receivers have implemented 759 feedback suppression (multicast retransmission). 761 The same retransmission of a packet originally transmitted in the 762 primary SSM can be sent in both a unicast retransmission session and 763 multicast retransmission session. The RTP_Rx will handle these two 764 (solicited or unsolicited) packets as duplicate packets. 766 Editor's note: Should we define a means by which an RTP_Rx can 767 indicate it does not want to receive unsolicited retransmissions in 768 the unicast retransmission session? 770 6.4. Congestion Control Considerations 772 6.4.1. Congestion Control in RFC 4585 and in RAMS 774 The RAMS document indicates that an RTP SSM distribution equipped 775 with a retransmission/burst server can work reliably in both 776 engineered and best-effort networks. However, there is a difference 777 in the core operation of RAMS and the core operation of a 778 Retransmission-enabled SSM in terms of congestion risk and avoidance: 780 1. In RAMS, retransmission packets, constituting a burst from the 781 RAMS server, are requested by an RTP_Rx prior to the moment the 782 receiver joins the SSM session. The Retransmission server bursts 783 the retransmission packets to the receiver and instructs the 784 receiver when to join the SSM, which will take place near the end 785 of this burst. The congestion control for the bursting process 786 can hence be decoupled from the SSM distribution (and any 787 congestion control taking place on the SSM). RAMS discusses in 788 more detail how to limit the risk on congestion for the RAMS 789 bursts, especially in a best effort environment. 791 2. When using retransmission service for an SSM, retransmission 792 packets are transmitted to and received by an RTP_Rx, while the 793 RTP_Rx also receives simultaneously the SSM RTP session. When 794 used in best effort networks, packet losses can be caused by 795 congestion or (access) transmission link errors. If packets in 796 the SSM are dropped because of congestion, there is a good chance 797 that a subsequent retransmission will actually exaggerate the 798 congestion situation (this will depend on the relative 799 positioning of the congestion, the RS and the RTP_Rx in the 800 considered SSM topology). 802 [RFC4588] section 7 states: 'In a best-effort environment, the 803 sender SHOULD NOT send retransmission packets without reducing the 804 packet rate and bitrate of the original stream (for example, by 805 encoding the data at a lower rate).' In the context of SSM, some 806 RTP_Rx's may observe packet loss (caused by congestion), other 807 receivers receiving the same SSM may not. As the DS transmits a 808 single original stream to all SSM receivers, the recommendation from 809 [RFC4588] for the DS to adapt its packet rate whenever an RTP_Rx is 810 reporting packet loss, will impact all SSM receivers. This would 811 make SSM with retransmission service practically infeasible in best 812 effort networks. It is also important to note that the 813 retransmission server/sender may be different from the DS sending the 814 original stream, especially in large-scale SSM applications. Hence, 815 to a large extent the SSM path from DS to an SSM receiver may be 816 decoupled from the network path between RS and SSM receiver. I.e. it 817 is quite possible that the congestion on the SSM does not impact the 818 network path taken by the retransmission packet(s). For these 819 reasons, a different recommendation is in place in terms of 820 congestion handling when retransmission is applied in SSM with 821 unicast feedback. 823 6.4.2. Congestion Handling for SSM with Retransmissions 825 In this section we formulate a set of rules for the RS in order to be 826 cautious that retransmissions will not contribute to enhanced 827 congestion situations on the SSM path between DS and RTP_Rx, but 828 without imposing an explicit role to the RS to assist in (helping to) 829 relieve any (potential) congestion between DS and RTP_Rx. This 830 results in a congestion control mechanism for an RS operating in an 831 SSM deployment that is decoupled from the behavior of the DS which 832 may use its own congestion control. 834 Note: in this section only congestion on the path from the RS 835 towards the RTP_Rx is considered. Congestion on the upstream path 836 towards the FT/RS has been discussed in the context of feedback 837 implosion risk and avoidance in the previous sections. 839 Case: Unmanaged Networks 841 The general requirement is that for unmanaged networks, an RTP 842 retransmission server for an SSM RTP session SHOULD keep track, on a 843 per RTP_Rx basis, of the recent retransmission request pattern for 844 that RTP_Rx. The RS then behaves as follows: 846 o Initially and when an RTP_Rx sends a retransmission request for 847 the first time to the FT/RS, the RS SHOULD assume there is no 848 congestion between the DS and the RTP_Rx, unless the RS has 849 information deduced or received not by way of RTCP NACKs through 850 which it can assume the SSM path is likely congested. 852 Such non-RTCP feedback information can be information coming from 853 RTCP RR, other RTCP messages or any out-of-band signaling from the 854 receiver or other network elements. 856 o An RS MAY respond to a retransmission request with one or more 857 retransmission packets when the path from the DS to the RTP_Rx 858 originating the request is assumed to be congestion free. 860 o When an RS observes an increasing amount of retransmission 861 requests from a single receiver, while having serviced all or most 862 retransmission requests from that receiver, or the server receives 863 information in a way different from RTCP NACKs which predicts or 864 indicates that congestion may likely occur, it SHOULD stop 865 responding to retransmission requests from that receiver. 866 Equally, the RS SHOULD NOT send unicast unsolicited 867 retransmissions to such receiver. 869 o When no other information is available, an RS MAY assume absence 870 of congestion for an RTP_Rx when it has not received 871 retransmission requests for a minimum duration of time. 873 o An RS sending unsolicited retransmissions over a dedicated 874 retransmission multicast SHOULD only do so when it knows this will 875 not cause or contribute to congestion on the primary SSM path for 876 the large majority of primary SSM receivers. 878 Detailed algorithms by which a RS can declare an RTP_Rx in a 879 congestion state, or free from congestion, are not elaborated further 880 upon in this document. 882 Note 1: an RS may correlate information it has on RTP_Rx's to make a 883 judgement on congestion or congestion-free state of the SSM paths to 884 other RTP_Rx's using the same RS. 886 Note 2: any congestion handling policy is orthogonal to any other 887 policy maintained at the RS having to do with retransmission service 888 access control e.g. using access control lists, IP anti-spoofing 889 measures, authentication, etc. 891 Note 3: an algorithm similar to the one described above for 892 congestion handling, but to handle a denial of service attack MAY be 893 considered for the RS implementation, next to the other security 894 considerations related to retransmission as discussed in section 12 895 in [RFC4588]. 897 Equivalent requirements are formulated for an RTP_Rx in an unmanaged 898 network, where retransmission is enabled: 900 o An RTP_Rx which senses that the net throughput of the combination 901 of original RTP packets and retransmission packets decreases over 902 time with increasing amount of retransmission requests and 903 subsequent retransmissions, SHOULD cease making retransmission 904 requests. 906 o An RTP_Rx may re-start sending out retransmission requests once 907 the original SSM session is received with close-to-zero packet 908 loss, and where any optional sporadic packet loss can be assumed 909 to be attributed to link transmission errors. 911 Case: Managed Networks 913 For managed networks congestion should not happen on the SSM path or 914 otherwise be a rare event. [RFC4588] states : 'If enhanced service 915 is used, it should be made sure that the total bitrate and packet 916 rate do not exceed that of the requested service. It should be 917 further monitored that the requested services are actually 918 delivered.' 920 Note: The total bitrate and packet rate is the original data (or 921 primary data) and retransmission data. 923 This means that the network is engineered to make sure that the 924 combined SSM packets and retransmission packets on the network paths 925 to any RTP_Rx will not be impacted by congestion. 927 An alternative approach is to engineer the network for the 928 congestion-free transmission of the primary SSM data, where-as 929 retransmissions are delivered without dedicated bandwidth engineering 930 provisions or otherwise with limited engineering provisions, in a 931 sense that up to a certain maximum rate and up to certain maximum 932 burst size, the retransmission traffic can be delivered on a 933 congestion-free path. 935 In the engineered case for SSM where retransmissions are not taken 936 into account for the bandwidth provisioning, the chance on having 937 congestion in the retransmission session for SSM enabled with 938 retransmission-only service is expected to be smaller compared to an 939 SSM enabled with RAMS service. This is because a single RAMS-R 940 request results in a burst of packets in the retransmission session 941 whereas retransmissions requests typically results in the 942 transmission of only one or several retransmission packets, with 943 retransmission requests being sporadic. 945 6.5. New RSI Message and RAMS-I TLV Extension 947 6.5.1. RSI Message 'FT SSRC List' 949 TBD. 951 6.5.2. RAMS-I TLV Extension 'FT SSRC' 953 TBD. 955 7. Security Considerations 957 Editor's note: A subset of the security aspects discussed in the 958 RAMS specification also applies to this document. TBC. 960 8. IANA Considerations 962 TBC. 964 9. RTP Retransmission Service in DVB IPTV 966 RTP retransmission for linear IPTV streams has been specified in 967 Annex D of [DVB-IPTV]. This ETSI document, produced by the DVB 968 Technical Module on IP-Infrastructure (TM-IPI) specifies the 969 interface of a managed IPTV service client, commonly called the Home 970 Network End Device or HNED in DVB IPTV terms. The DVB IPTV RTP 971 retransmission solution in Annex D references [RFC3550], [RFC4585], 972 [RFC4588] and the [RFC5760]. Its solution is hence very well aligned 973 with the IETF RTP specifications and addresses feedback implosion and 974 feedback suppression in a similar way as described in this document: 976 o The DVB Linear Media Broadcast (LMB) services are delivered over 977 an RTP SSM that operates according to the summary feedback model 978 defined in [RFC5760] 980 o RTCP NACK messages transmitted by HNEDs towards the FT('s) are not 981 forwarded over the primary RTP SSM. 983 o An HNED enables feedback suppression when receiving an RTCP 984 Feedforward message from the network. This RTCP Feedforward (FF) 985 message has the same format as an RTCP NACK message. 987 o The RTCP FF message stems from a 'so-called' upstream reporter 988 (having its own SSRC identifier, signaled to the HNEDs in a DVB 989 IPTV specific way) , which represents the Retransmission Server in 990 its role as primary RTP_Rx. Alternatively the RTCP FF message is 991 transmitted by the RS acting as RTP translator when the RS assumes 992 a packet loss event took place that is impacting many HNEDs, but 993 not the RS (as RTP_Rx) itself. 995 o This RTCP FF message may be sent in the primary RTP SSM but may 996 also be sent in a dedicated RTP SSM sourced by the Retransmission 997 Server. 999 o In order to better control and allow the Retransmission Server to 1000 better recognize potential feedback implosion situations, an 1001 optional feature has been defined. A subset of RTP_Rx can act as 1002 immediate reporters (which do not follow the dithering 1003 transmission timing rules from [RFC4585]), and will send an RTCP 1004 NACK message immediately upon packet loss detection. Whether an 1005 HNED acts as immediate reporter or not is determined by whether 1006 its randomly chosen SSRC identifier value maps to a pre-defined 1007 SSRC mask/pattern that is signaled to all HNEDs. 1009 10. Contributors 1011 TBC. 1013 11. Acknowledgments 1015 TBC. 1017 12. References 1019 12.1. Normative References 1021 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1022 Jacobson, "RTP: A Transport Protocol for Real-Time 1023 Applications", STD 64, RFC 3550, July 2003. 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, March 1997. 1028 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1029 Thyagarajan, "Internet Group Management Protocol, Version 1030 3", RFC 3376, October 2002. 1032 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1033 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1035 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1036 "Extended RTP Profile for Real-time Transport Control 1037 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1038 July 2006. 1040 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1041 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1042 July 2006. 1044 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1045 Protocol (RTCP) Extensions for Single-Source Multicast 1046 Sessions with Unicast Feedback", RFC 5760, February 2010. 1048 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1049 Group Management Protocol Version 3 (IGMPv3) and Multicast 1050 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1051 Specific Multicast", RFC 4604, August 2006. 1053 [I-D.ietf-avtcore-ports-for-ucast-mcast-rtp] 1054 Begen, A., Wing, D., and T. VanCaenegem, "Port Mapping 1055 Between Unicast and Multicast RTP Sessions", 1056 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02 (work in 1057 progress), April 2011. 1059 [I-D.ietf-avt-rapid-acquisition-for-rtp] 1060 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 1061 Based Rapid Acquisition of Multicast RTP Sessions", 1062 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 1063 progress), November 2010. 1065 [I-D.ietf-avtcore-feedback-supression-rtp] 1066 Wu, W., Xia, F., and R. Even, "RTCP Extension for Third- 1067 party Loss Report", 1068 draft-ietf-avtcore-feedback-supression-rtp-03 (work in 1069 progress), May 2011. 1071 12.2. Informative References 1073 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1074 Media Attributes in the Session Description Protocol 1075 (SDP)", RFC 5576, June 2009. 1077 [I-D.ietf-fecframe-dvb-al-fec] 1078 Begen, A. and T. Stockhammer, "Guidelines for Implementing 1079 DVB-IPTV Application-Layer Hybrid FEC Protection", 1080 draft-ietf-fecframe-dvb-al-fec-04 (work in progress), 1081 December 2009. 1083 [DVB-IPTV] 1084 "ETSI TS 102034 Digital Video Broadcasting (DVB); 1085 Transport of MPEG-2 TS Based DVB Services over IP Based 1086 Networks", August 2009. 1088 Authors' Addresses 1090 Tom VanCaenegem 1091 Alcatel-Lucent 1092 Copernicuslaan 50 1093 Antwerpen, 2018 1094 Belgium 1096 Email: Tom.Van_Caenegem@alcatel-lucent.com 1098 Bill VerSteeg 1099 Cisco 1100 5030 Sugarloaf Parkway 1101 Lawrenceville, GA 30044 1102 USA 1104 Email: billvs@cisco.com 1106 Ali Begen 1107 Cisco 1108 181 Bay Street 1109 Toronto, ON M5J 2T3 1110 Canada 1112 Email: abegen@cisco.com