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