idnits 2.17.1 draft-wu-avt-retransmission-supression-rtp-05.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This RTCP Feedback Report lets the receivers know that feedback for this packet loss is not needed and SHOULD NOT be sent to the media source(s). If the media source(s) are part of the SSM group for RTCP packet reflection, the Distribution Source MUST filter this packet out. If the media source(s) are not part of the SSM group for RTCP packets, the Distribution Source MUST not forward this RTCP packets received from the receivers to the media source(s). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2010) is 4929 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) == Unused Reference: 'RFC5234' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 735, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5117 (Obsoleted by RFC 7667) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- No information found for draft-hunt-avt-monarch-01 - is the name correct? -- No information found for draft-ietf-pmol-metrics-framework-02 - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft F. Xia 4 Intended status: Standards Track R. Even 5 Expires: April 23, 2011 Huawei 6 October 20, 2010 8 RTCP Report Extension for Feedback Suppression 9 draft-wu-avt-retransmission-supression-rtp-05 11 Abstract 13 When packet loss close to the media source or intermediary of the 14 session is detected as a loss by a large number of receivers, large 15 number of feedback requests used to ask for the lost RTP packets are 16 all addressed to the same media source, or a designated feedback 17 target. This may result in a phenomenon known variously as a 18 "feedback storm " or "feedback implosion ". 20 This document specifies an extension to the RTCP feedback messages 21 defined in the Audio-Visual Profile with Feedback (AVPF). This 22 extension allows an intermediate node in the network (such as an RTP 23 translator) inform downstream receivers that packet loss was detected 24 and sending a feedback message concerning a specified set of RTP 25 packets may be unnecessary, or even harmful. Receivers respond to 26 receipt of a feedback suppression message by not sending a feedback 27 message (e.g. a NACK) that they otherwise would, This in turn reduces 28 load on both the feedback target and on the network. The proposed 29 extension is useful for single-source multicast sessions. In 30 addition, it can be applied to any other types of RTP sessions and 31 topologies that might benefit from feedback suppression mechanism. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 23, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 82 4. RTCP Feedback Report Extension . . . . . . . . . . . . . . . . 7 83 4.1. Transport Layer Feedback: NACK Suppression Report . . . . 7 84 4.2. Payload Specific Feedback: FIR suppression report . . . . 8 85 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 86 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 87 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 10 88 6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 11 89 6.1.2. Distribution Source Feedback Summary Model . . . . . . 12 90 6.2. Unicast based Rapid Acquisition of Multicast Stream 91 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 13 92 6.3. RTP transport translator use case . . . . . . . . . . . . 13 93 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 14 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 15 96 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 100 Appendix A. Example scenarios for NACK Implosion . . . . . . . . 17 101 A.1. Scenario 1: One or more media source, One distribution 102 source . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 A.2. Scenario 2:One media source, Two distribution sources 104 in cascade . . . . . . . . . . . . . . . . . . . . . . . . 18 105 A.3. Scenario 3:One media source, Two distribution sources 106 in parallel . . . . . . . . . . . . . . . . . . . . . . . 18 107 Appendix B. Applicability of Feedback Suppression . . . . . . . . 19 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 110 1. Introduction 112 RTCP feedback messages [RFC4585]allow the receivers in an RTP session 113 to report events and ask for action from the media source (or a 114 delegated feedback target). There are cases where multiple receivers 115 may initiate the same, or an equivalent message towards the same 116 media source. When the receiver count is large, this behavior may 117 overload the media source or the network or both. One common case is 118 receivers utilizing RTP retransmission as a packet loss recovery 119 technique in a real-time application such as streaming video or 120 audio.[RFC4585]Feedback is accomplished using the RTCP NACK message 121 which conveys the RTP sequence number(s) of the lost packet(s). This 122 information can then be used by the media or distribution source to 123 retransmit the missing RTP packets using the RTP retransmission 124 payload format[RFC4588]. 126 However, in topologies utilizing transport translators (Topo-Trn- 127 Translator) or large-scale multicast transmission (Topo-Multicast) as 128 defined in [RFC5117], packet loss can occur on either an upstream 129 link or a downstream aggregate link of the intermediate network 130 element (e.g., Distribution Source, MCU, Transport Translator). 131 Where there are many receivers, this may result in a Feedback 132 implosion [RFC5740] towards the media or distribution source, i.e., 133 large number of feedback requests to the same multicast sender for 134 retransmission of the same RTP packets. This phenomenon goes by a 135 number of alternate names, such as the "feedback storm" or the "NACK 136 storm" terminology of [DVB-IPTV]. In an attempt to increase its 137 robustness against the loss of a feedback message or of 138 retransmission packets, a receiver may send multiple feedbacks for 139 the same detected packet loss, which may aggravate the feedback 140 implosion. 142 Another use case involves video Fast Update requests. A storm of 143 these feedback messages can occur in conversational multimedia 144 scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, 145 packet loss may happen on an upstream link of an intermediate network 146 element such as a Multipoint Control Unit(MCU). Receivers missing 147 the packets issue fast update requests (i.e., Full Intra Request(FIR) 148 described in [RFC5104]), which results in an implosion of FIR 149 requests from receivers to the same media source. 151 As these feedback storms propagate (e.g., NACK implosion or Fast 152 update implosion), the network may be permeated with more and more 153 feedback traffic, resulting in a positive feedback loop as the 154 network is also saturated with media traffic. RTCP feedback storms 155 may cause short term overload and, and in extreme cases to pose a 156 possible risk of increasing network congestion on the control channel 157 (e.g. RTCP feedback), the data channel (i.e. RTP retransmission), 158 or Both if the receivers are not correctly implemented 160 In order to mitigate these behaviors, the current text in [RFC5760] 161 allows the distribution source to filter out the NACK messages and 162 [DVB-IPTV] suggests sending a NACK message from server to the client 163 (or receiver). However NACK is defined as a receiver report sent 164 from a client to the server and therefore exhibits a semantic 165 mismatch when used as a suppression indication from the server (or 166 intermediary) to the client. This document instead specifies a newly 167 message for this function. It further is more precise in the 168 intended uses and less likely to be confusing to receivers. It tells 169 receivers explicitly that feedback for a particular packet loss is 170 not needed and can provide an early indication before the receiver 171 reacts to the loss and invokes its packet loss repair machinery. 173 Receivers respond to receipt of a feedback suppression message by not 174 sending a feedback message (e.g. a NACK) that they otherwise would, 175 This in turn reduces load on both the feedback target and on the 176 network. 178 Also the intermediate node may initiate its own feedback toward the 179 media source to provoke a retransmission. When the media source 180 receives the request from the intermediate node, the media source 181 resends the lost packets to the receivers by using the RTP 182 retransmission payload format [RFC4588] or resends a new refresh 183 point for FIR Initiator [RFC5104], depending on the type of feedback 184 it received. 186 2. Terminology 188 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 3. Protocol Overview 194 This document extends the RTCP feedback messages defined in the 195 Audio-Visual Profile with Feedback (AVPF) and define the Feedback 196 Suppression message. The Feedback Suppression message asks a 197 receiver to not send feedback messages for particular packets 198 (indicated by their RTP sequence numbers) independent of whether the 199 receiver detected the packet loss or detected a need for a decoder 200 refresh point). 202 In order to detect packet loss before the receivers perceive it, one 203 or more intermediate nodes are placed between the media source and 204 receiver (e.g., Distribution server, MCU, RTP translator). These 205 intermediaries monitor for packet loss upstream of themselves by 206 checking RTP sequence numbers, just as receivers do. Upon detecting 207 (or suspecting) an upstream loss, the intermediary may send Feedback 208 Suppression message towards the receivers as defined in this 209 specification. 211 These intermediate nodes need to take into account such factors as 212 the tolerable application delay, the network dynamics, and the media 213 type. When the packet loss is detected upstream of the intermediary 214 and additional latency is tolerable, the intermediate node may itself 215 send a feedback message asking for the suspected lost packet or ask 216 for the correct decoder refresh point. Because it has already 217 provided the necessary feedback toward the source, the intermediate 218 node can be reasonably certain that it will help the situation by 219 sending a Feedback Suppression message to all the relevant receivers, 220 thereby indicating that the receivers should not themselves transmit 221 feedback messages. 223 When the receiver receives such Feedback Suppression message, if the 224 receiver understands this message it will not send packet loss 225 request (e.g., NACK) for the missing packets reported in the message. 226 If it did not understand this new message, the host MAY send packet 227 loss request(i.e., Feedback messages) to the specified media source. 228 A receiver may still have sent a Feedback message before receiving a 229 feedback suppression message, but further feedback messages for those 230 sequence numbers will be suppressed by this technique. 232 RTCP Feedback Suppression follows the same semantic model as RTCP 233 NACK - it conveys the packet receipt/loss events at the sequence 234 number level and considers missing packets as unrepaired. But unlike 235 RTCP NACK, the Feedback Suppression messages can be generated at 236 intermediate nodes who are not RTP receivers and sent to the 237 corresponding receivers. Intermediaries downstream of an 238 intermediary detecting loss obviously SHOULD NOT initiate their own 239 additional feedback suppression messages for the same packet sequence 240 numbers. They may either simply forward the Feedback Suppression 241 message received from upstream, or augment (or replace) it with a 242 feedback suppression message that reflects the loss pattern they have 243 themselves seen. 245 Since feedback suppression interacts strongly with repair timing, it 246 has to work together with feedback to not adversely impact the repair 247 of lost source packets. In some cases where the loss was detected 248 and repair initiated much closer to the source, the delay for the 249 receiver to recover from packet loss can be reduced through the 250 combination of intermediary feedback to the source and feedback 251 suppression downstream. In all (properly operating) cases, the risk 252 of increasing network congestion is decreased. 254 This document registers two new RTCP Feedback messages for Feedback 255 Suppression. Applications that are employing one or more loss-repair 256 methods MAY use Feedback Suppression together with their existing 257 loss-repair methods either for every packet they expect to receive, 258 or for an application-specific subset of the RTP packets in a 259 session. In other words, receivers MAY ignore Feedback Suppression 260 messages, but SHOULD react to them unless they have good reason to 261 still send feedback messages despite having been requested to 262 suppress them. 264 4. RTCP Feedback Report Extension 266 4.1. Transport Layer Feedback: NACK Suppression Report 268 The NACK implosion Suppression message is an extension to the RTCP 269 feedback report and identified by RTCP packet type value PT=RTPFB and 270 FMT=TBD. 272 The FCI field MUST contain one or more NACK Suppression Early 273 Indication (NSEI) entries. Each entry applies to a different media 274 source, identified by its SSRC. 276 The Feedback Control Information (FCI) for NSEI uses the similar 277 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 278 The format is shown in Figure 1. 280 0 1 2 3 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | SSRC | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | PID | BLP | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 1: Message Format for the NSEI report 290 SSRC (32 bits): 292 The SSRC value of the media source that is requested to send the 293 lost packet. 295 Packet ID (PID): 16 bits 297 The PID field is used to specify a lost packet. The PID field 298 refers to the RTP sequence number of the lost packet. 300 bitmask of following lost packets (BLP): 16 bits 302 The BLP allows for reporting losses of any of the 16 RTP packets 303 immediately following the RTP packet indicated by the PID. The 304 BLP's definition is identical to that given in [RFC4585]. 306 4.2. Payload Specific Feedback: FIR suppression report 308 The FIR implosion Suppression message is an extension to the RTCP 309 receiver feedback report and identified by RTCP packet type value 310 PT=PSFB and FMT=TBD. 312 The FCI field MUST contain one or more FIR suppression Early 313 Indication (FSEI) entries. Each entry applies to a different media 314 source, identified by its SSRC. 316 The Feedback Control Information (FCI) for FSEI uses the similar 317 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 318 The format is shown in Figure 2. 320 0 1 2 3 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | SSRC | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Seq nr. | Reserved | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: Message Format for the FSEI report 330 SSRC (32 bits): 332 The SSRC value of the media source that is requested to send a 333 decoder refresh point. 335 Seq nr:8bits Command sequence number. The sequence number space is 336 unique for each pairing of the SSRC of command source and the SSRC 337 of the command target. The sequence number SHALL be increased by 338 1 modulo 256 for each new command. 340 Reserved: 24 bits 342 All bits SHALL be set to 0 by the media source and SHALL be 343 ignored on reception. 345 5. SDP Signaling 347 A new feedback value "fss" needs to be defined for the Feedback Storm 348 Suppression message to be used with Session Description Protocol 349 (SDP)[RFC4566] using the Augmented Backus-Naur Form (ABNF)[RFC4585]. 351 The "fss" feedback value SHOULD be used with parameters that indicate 352 the feedback suppression supported. In this document, we define two 353 such parameters, namely: 355 o "fsei" denotes support of fir suppression early indication (fsei). 357 o "nsei" denotes support of NACK suppression early indication. 359 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 360 placeholder called rtcp-fb-id to define new feedback types. "fss" is 361 defined as a new feedback type in this document, and the ABNF for the 362 parameters for fss is defined here (please refer to section 4.2 of 363 [RFC4585] for complete ABNF syntax). 365 rtcp-fb-val =/ "fss" rtcp-fb-fss-param 366 rtcp-fb-fss-param = SP "nsei";nack suppression early indication 367 / SP "fsei";fir suppression early indication 368 / SP token [SP byte-string] 369 ; for future commands/indications 370 byte-string = 372 Refer to Section 4.2 of [RFC4585] for a detailed description and the 373 full syntax of the "rtcp-fb" attribute. 375 6. Example Use Cases 377 The operation of feedback suppression is similar for all types of RTP 378 sessions and topologies [RFC5117], however the exact messages used 379 and the scenarios in which suppression is employed differ for various 380 use cases. The following sections outline the intended use cases for 381 feedback suppression and give an overview of the particular 382 mechanisms. 384 6.1. Source Specific Multicast (SSM) use case 386 In SSM RTP sessions as described in [RFC5760], one or more Media 387 Sources send RTP packets to a Distribution Source. The Distribution 388 Source relays the RTP packets to the receivers using a source- 389 specific multicast group. 391 In order to avoid the forms of NACK implosion described in section 392 1,the distribution source SHOULD choose to include the support for 393 loss detection. How the packet loss detection works is beyond of 394 scope of this document. When upstream link or downstream aggregate 395 link packet loss occurs, the distribution source creates a Feedback 396 Suppression report and sent it to all the RTP receivers, over the 397 multicast channel. Another possibility is when there may have 398 multiple distribution source placed between the media source and the 399 receivers, the upstream distribution source MAY inform downstream 400 distribution source of the detected packet loss using Feedback 401 Suppression messages. In response, the distribution source forwards 402 packet loss suppression report received from upstream to all the RTP 403 receivers, over the multicast channel. This loss suppression report 404 tells the receivers that the lost packet will either be forthcoming 405 from distribution source, or it irretrievably lost such that there is 406 nothing to be gained by the receiver sending a NACK to the media 407 source. The distribution source then can (optionally) ask for the 408 lost packets from the media source on behalf of all the RTP 409 receivers. 411 When there is only one distribution source with loss detection 412 support between the media source and the receivers, redistribution of 413 the feedback suppression report to all the receivers is trivial. 414 When there are multiple distribution sources between the media source 415 and the receiver, , each distribution source with loss detection 416 support MAY create a Feedback Suppression Report using the similar 417 format as conventional RTCP NACK packets at the RTP layer and send it 418 to its downstream distribution source or forward one Feedback 419 Suppression Report from upstream to its downstream distribution 420 source or the receivers. Also each distribution source at the 421 downstream of the other distribution source MAY also append non- 422 identical packet loss information into the Feedback Suppression 423 Report sent from upstream and form one summary report and send it to 424 the receivers. 426 The distribution source must be able to communicate with all group 427 members in order for either mechanism to be effective at suppressing 428 feedback. 430 As outlined in the [RFC5760], there are two Unicast Feedback models 431 that may be used for reporting, - the Simple Feedback model and the 432 Distribution Source Feedback Summary Model. The RTCP Feedback 433 Suppression report extension specified in the section 4 of this 434 document will work in both Feedback models. Details of operation in 435 each are specified below. 437 6.1.1. Simple Feedback Model 439 In the simple Feedback Model, the Loss detection instance(s)are 440 distributed into two different distribution sources. e.g., upstream 441 distribution source with loss detection support may act as the loss 442 detector of downstream distribution source while The downstream 443 distribution source doesn't have loss detection support. 445 The upstream distribution source MUST listen on the corresponding RTP 446 session for data. When the upstream distribution source observes 447 that a sequence of RTP packets from a media source contains gaps (by 448 checking the sequence number of packets), the upstream distribution 449 source MUST use the same packet types as traditional RTCP feedback 450 described in [RFC3550] and create one new RTCP Feedback Report with 451 information on the RTP sequence number of the lost packets and 452 suppression early indication event. When the upstream distribution 453 source is eligible to transmit, it MUST send this Report packet to 454 the upstream distribution source. 456 The downstream Distribution Source MUST listen for RTCP data sent to 457 the RTCP port. Upon receiving the RTCP Feedback Report packet from 458 the upstream distribution source, the downstream Distribution Source 459 MUST forward it to the group on the multicast RTCP session. Every 460 RTCP packet from each upstream distribution source MUST be reflected 461 individually. 463 This RTCP Feedback Report lets the receivers know that feedback for 464 this packet loss is not needed and SHOULD NOT be sent to the media 465 source(s). If the media source(s) are part of the SSM group for RTCP 466 packet reflection, the Distribution Source MUST filter this packet 467 out. If the media source(s) are not part of the SSM group for RTCP 468 packets, the Distribution Source MUST not forward this RTCP packets 469 received from the receivers to the media source(s). 471 When the receiver receives the RTCP packet, if the receiver 472 understands the message it will not send feedback (e.g., NACK) for 473 the missing packets reported in the message and will accept a 474 retransmission packet (if forthcoming) transmitted from the 475 Distribution Source. If it did not understand the Feedback 476 Suppression report the receiver MAY of course still send feedback 477 messages to the specified media source. When the distribution source 478 receives a feedback message reporting loss from one or more receivers 479 after it has already detected packet loss via loss detection 480 functionality, the distribution source MUST filter them out until 481 proactive recovery is complete. 483 6.1.2. Distribution Source Feedback Summary Model 485 In the distribution source feedback summary model, there may have 486 multiple distribution sources and the Loss Detection instances are 487 distributed into different distribution sources. In some cases, 488 these Loss Detection instances for the same session can exist at the 489 same time, e.g., one Loss Detection instance is implemented in the 490 upstream distribution source A, another two Loss Detection instances 491 for the same session is part of feedback target A and feedback target 492 B respectively within the distribution source B. In this section, we 493 focus on this generic case to discuss the distribution Source 494 Feedback Summary Model. 496 The distribution source A MUST listen on the RTP channel for data. 497 When the distribution source A observes RTP packets from a media 498 source are not consecutive by checking the sequence number of 499 packets, the distribution source A generates the new RTCP Feedback 500 Suppression Report packet described in the section 6, and then send 501 it to the distribution source B. 503 Two loss detection instances within the Distribution Source B MUST 504 listen for RTCP data sent to the RTCP port. Upon receiving the RTCP 505 Feedback Report packet from the Distribution Source A, the 506 distribution source B needs to summarize the information received 507 from all the RTCP Feedback Reports generated by the upstream 508 distribution source together with the information generated by two 509 loss detection instances witin the Distribution Source B and then 510 create the summary report to include all these information. In order 511 to reduce the processing load at the distribution source, each loss 512 detection instance MAY provide preliminary summarization report. 514 During the summary report creating, the Distribution Source B MUST 515 use its own SSRC value for transmitting summarization information and 516 MUST perform proper SSRC collision detection and resolution. 518 In some case, the distribution source B MAY receive RTCP NACK 519 messages from the receivers behind the Distribution Source before the 520 distribution source detects the packet loss which may cause potential 521 Feedback implosion. In such case, the distribution source MAY filter 522 them out if it already sent a packet loss request for the missing 523 packet to the media source. When the distribution source confirms 524 packet loss reported by the receiver, the distribution source 525 generates the summary report to include the packet loss information 526 from the corresponding receiver or upstream distribution source. 528 The distribution source MAY send this new RTCP summary report 529 described in the section 6 to the group on the multicast RTCP channel 530 and in the meanwhile sending a packet loss request to the media 531 source. 533 If there are a couple of distribution sources with loss detection 534 support looking at the same RTP stream, then the loss may be 535 identified by all and they will all send requests for the same packet 536 loss. In this case, the distribution source MUST filter out the 537 duplicated information from various distribution source and only 538 append one copy of such information to the summary report. 540 When the host receives the RTCP packet, if the host understands this 541 message it will not send packet loss request (e.g., NACK) for the 542 missing packets reported in the message. If it did not understand 543 this new message, the host MAY send packet loss request(e.g., NACK 544 messages) to the specified media source. When the distribution 545 source receives the packet loss request from the hosts after it has 546 already detected packet loss, the distribution source MUST filter it 547 out until proactive recovery is complete. 549 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 550 case 552 In the typical RAMS architecture, there may have one distribution 553 source placed between media source and BRS for relaying SSM stream 554 from media source. The BRS will receive the SSM stream from the DS. 555 Suppose there are several BRSes behind the distribution source or 556 media source, there may be just one BRS that detects packet loss on 557 its upstream link between the distribution source and BRS, but the 558 others will perhaps not, as the packet loss took place on SSM tree 559 branch that does not impact the other BRSes. In such case, the 560 distribution source with loss detection functionality support can not 561 detect packet loss at the downstream of itself, therefore the 562 distribution source SHOULD NOT create new Feedback Suppression 563 message and send it to all the BRS. If BRS impacted by packet loss 564 has loss detection support, the BRS MAY choose to create new Feedback 565 Suppression message and send it to the receivers behind this BRS. 567 6.3. RTP transport translator use case 569 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 570 is typically forwarding the RTP and RTCP traffic between RTP clients, 571 for example converting between multicast and unicast for domains that 572 do not support multicast. The translator can identify packet loss 573 from the upstream and send the Feedback Suppression message to the 574 unicast receivers. The translator can also serve as a loss reporter 575 on the multicast side as described in the SSM case. 577 6.4. Multipoint Control Unit (MCU) use case 579 In point to multipoint topologies using video switching MCU (Topo- 580 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 581 media stream to each participant, selected from the available input 582 streams. The selection of the input stream is often based on voice 583 activity in the audio-visual conference, but other conference 584 management mechanisms (like presentation mode or explicit floor 585 control) exist as well. 587 In this case the MCU MAY detect packet loss from the sender or may 588 decide to switch to a new source. In both cases the receiver MAY 589 lose synchronization with the video stream and MAY send a FIR 590 request. If the MCU itself can detect the mis-synchronization of the 591 video, the MCU can send the FIR suppression message to the receivers 592 and send a FIR request to the video source. 594 7. Security Considerations 596 The defined messages have certain properties that have security 597 implications. These must be addressed and taken into account by 598 users of this protocol. 600 Spoofed or maliciously created feedback messages of the type defined 601 in this specification can have the following implications: 603 Sending NACK Suppression Report with wrong sequence number of lost 604 packet that makes missing RTP packets can not be compensated. 606 Sending FIR Suppression Report with wrong sequence number of lost 607 packet that makes missing RTP packets can not be compensated by 608 update request mechanism. 610 To prevent these attacks, there is a need to apply authentication and 611 integrity protection of the feedback messages. This can be 612 accomplished against threats external to the current RTP session 613 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 614 into SAVPF [RFC5124]. 616 Note that middleboxes that are not visible at the RTP layer that wish 617 to send NACK/FIR suppression reports on behalf of the media source 618 can only do so if they spoof the SSRC of the media source. This is 619 difficult in case SRTP is in use. If the middlebox is visible at the 620 RTP layer, this is not an issue, provided the middlebox is part of 621 the security context for the session. 623 Also note that endpoints that receive a NACK/FIR suppression request 624 would be well-advised to ignore it, unless it is authenticated via 625 SRTCP or similar. Accepting un-authenticated NACK/ FIR suppression 626 requests can lead to a denial of service attack, where the endpoint 627 accepts poor quality media that could be repaired. 629 8. IANA Consideration 631 New feedback type and New parameters for RTCP FSS receiver feedback 632 report are subject to IANA registration. For general guidelines on 633 IANA considerations for RTCP feedback, refer to [RFC4585]. 635 This document assigns one new feedback type value x in the RTCP 636 feedback report registry to "Feedback Storm Suppression" with the 637 following registrations format: 639 Name: FSS 640 Long Name: Feedback Storm Suppression 641 Value: TBD 642 Reference: This document. 644 This document also assigns the parameter value y in the RTCP FSS 645 feedback report Registry to "NACK Suppression Early Indication ", 646 with the following registrations format: 648 Name: NSEI 649 Long name: NACK Suppression Early Indication 650 Value: TBD 651 Reference: this document. 653 This document also assigns the parameter value z in the RTCP FSS 654 feedback report Registry to "FIR Suppression Early Indication ", with 655 the following registrations format: 657 Name: FSEI 658 Long name: FIR Suppression Early Indication 659 Value: TBD 660 Reference: this document. 662 The contact information for the registrations is: 664 Qin Wu 665 sunseawq@huawei.com 666 101 Software Avenue, Yuhua District 667 Nanjing, Jiangsu 210012, China 669 9. Acknowledgement 671 The authors would like to thank David R Oran, Ali C. Begen, Colin 672 Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, WeeSan 673 Lee for their valuable comments and suggestions on this document. 675 10. References 677 10.1. Normative References 679 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 680 Protocol (RTCP) Extensions for Single-Source Multicast 681 Sessions with Unicast Feedback", RFC 5760, February 2010. 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, March 1997. 686 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 687 "Extended RTP Profile for Real-time Transport Control 688 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 689 July 2006. 691 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 692 Jacobson, "RTP: A Transport Protocol for Real-Time 693 Applications", STD 64, RFC 3550, July 2003. 695 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 696 January 2008. 698 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 699 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 700 July 2006. 702 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 703 Description Protocol", RFC 4566, July 2006. 705 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 706 Specifications: ABNF", STD 68, RFC 5234, January 2008. 708 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 709 "Codec Control Messages in the RTP Audio-Visual Profile 710 with Feedback (AVPF)", RFC 5104, February 2008. 712 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 713 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 714 RFC 3711, March 2004. 716 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 717 Real-time Transport Control Protocol (RTCP)-Based Feedback 718 (RTP/SAVPF)", RFC 5124, February 2008. 720 10.2. Informative References 722 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 723 "NACK-Oriented Reliable Multicast (NORM) Transport 724 Protocol", November 2009. 726 [DVB-IPTV] 727 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 728 of MPEG-2 TS Based DVB Services over IP Based Networks", 729 ETSI TS 102 034, V1.4.1 , August 2009. 731 [I-D.hunt-avt-monarch-01] 732 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 733 August 2008. 735 [I-D.ietf-pmol-metrics-framework-02] 736 Clark, A., "Framework for Performance Metric Development". 738 Appendix A. Example scenarios for NACK Implosion 740 In SSM RTP sessions as described in [RFC5760], there may have more 741 than one distribution source between the media source and the 742 receivers. In order for loss repair, the distribution source may 743 choose to include the support for retransmission as part of the 744 offered SDP and will expect such support from the media source.The 745 following section outline several example scenarios for NACK 746 Implosion. 748 A.1. Scenario 1: One or more media source, One distribution source 750 The scenario 1 is displayed below in Figure 3. In this scenario, one 751 or more Media Sources send RTP packets to the RTP Receivers through 752 the same Distribution Source. The Distribution Source relays the RTP 753 packets to the receivers using a source-specific multicast channel. 754 In the reverse direction, the receivers transmit RTCP packets via 755 unicast to the distribution source. The Distribution Source in turn 756 relays RTCP packets to the media souce and then transmits the RTCP 757 packets back to the receivers, using source-specific multicast. 759 +-------+ 760 |---->|RTP_Rx1| 761 +--------+ | +-------+ 762 | | +--------------+ | 763 | | | | | +-------+ 764 | Media |-------| Distribution |-------|---->|RTP_Rx2| 765 | | | Source | | +-------+ 766 | Source | | | | . 767 | | +--------------+ | . 768 | | | . 769 +--------+ | +-------+ 770 |---->|RTP_Rxn| 771 +-------+ 773 Figure 3: One media Source, one Distribution Source 775 A.2. Scenario 2:One media source, Two distribution sources in cascade 777 +-------+ 778 |---->|RTP_Rx1| 779 | +-------+ 780 +------+ | 781 | | +------------+ +------------+ | +-------+ 782 |Media |-+Distribution+--|Distribution+--|---->|RTP_Rx2| 783 |Source| | Source1 | | Source2 | | +-------+ 784 | | +------------+ +------------+ | . 785 +------+ | . 786 | . 787 | +-------+ 788 |---->|RTP_Rxn| 789 +-------+ 791 Figure 4: One media source, Two distribution sources in cascade 793 The scenario 2 is displayed below in Figure 4. In this scenario, One 794 media source passes through two distribution source in cascading and 795 sends RTP packets to all the RTP receivers. In this case, the 796 distribution source 2 is located in the downstream direction of 797 distribution source 1. 799 A.3. Scenario 3:One media source, Two distribution sources in parallel 801 The scenario 3 is displayed below in Figure 5. In this scenario, the 802 Media Sources send RTP packets to all the RTP receivers through two 803 different path respectively. In each path, there is a distribution 804 source. The distribution source1 is a neighboring node of 805 distribution source 2. 807 +--------+ 808 |---->|RTP_Rx11| 809 | +--------+ 810 +--------------+ | 811 | | | +--------+ 812 |--->| Distribution |----|---->|RTP_Rx12| 813 | | Source1 | | +--------+ 814 | | | | . 815 +--------+ | +--------------+ | . 816 | | | | . 817 | | | | +--------+ 818 | Media | | |---->|RTP_Rx1k| 819 | |---| +--------+ 820 | Source | | +--------+ 821 | | | |---->|RTP_Rx21| 822 | | | | +--------+ 823 +--------+ | +--------------+ | 824 | | | | +--------+ 825 | | Distribution |----|---->|RTP_Rx22| 826 |--->| Source2 | | +--------+ 827 | | | . 828 +--------------+ | . 829 | . 830 | +--------+ 831 |---->|RTP_Rx2j| 832 +--------+ 834 Figure 5: One Media Source, more distribution sources 836 Appendix B. Applicability of Feedback Suppression 838 This document defines new RTCP feedback Report, which we refer to as 839 Feedback Suppression to deal with NACK Implosion mentioned above. 840 Here we give two examples to show how this new RTCP feedback report 841 is applied into three scenarios described in Appendix A. 843 Applicability of Feedback Suppression in Scenario 1 described in 844 Figure 3 is shown in the Figure 6. In this figure, the distribution 845 source detect the packet loss before the receiver perceive it and ask 846 for retransmission of the lost packets from the media source on 847 behalf of all the RTP receivers. , in the meanwhile, the distribution 848 source transmits the RTCP Feedback Suppression Indication back to the 849 receivers using source-specific multicast channel. Upon receiving 850 the lost packet via the RTP retransmission payload format, the 851 distribution source forwards the retransmitted packet to all the 852 receivers. The receiver will accept a retransmission stream 853 transmitted from the Distrbituion Source. 855 When the distribution source receives a feedback message reporting 856 loss from one or more receivers after it has already detected packet 857 loss, the distribution source MUST filter them out until the 858 Retransmission stream is ready in the Distrbitution Source. In this 859 way, the delay for the receiver to recover from the packet loss can 860 be reduced and the risk of increasing network congestion can be 861 mitigated. 863 +------+ +--------------+ +--------+ 864 |Media | | Distribution | | | 865 |Source| | Source | | RTP_Rx | 866 +--+---+ +------+-------+ +---+----+ 867 | | | 868 | | | 869 |------------------->|------RTP Multicast---->| 870 | | | 871 | | | 872 | +--------+----------+ | 873 | |Detect Packet Loss | | 874 | |and Identify the SN| | 875 | |of missing Packets | | 876 | +--------+----------+ | 877 |<-----RTCP NACK-----| | 878 | | | 879 | +--Multicast RTCP FSS--->| 880 | RTP Retransmission | | 881 |------------------->| | 882 | |------RTP Multicast---->| 883 | | Retransmission | 884 | | | 885 | | | 886 | | | 888 Figure 6: Applicability of NACK Suppression Early Indication 890 Applicability of Feedback Suppression in Scenario 2 or 3 described in 891 Figure 4 and Figure 5 is shown in the Figure 7. The procedure in the 892 Figure 7 is similar to the one in the figure Figure 6. The only 893 difference is distribution source should not only notify all the 894 receiver behind itself not to send NACK but also propagate the 895 retransmission suppression indication to the neighboring distribution 896 sources. In this way, all the receivers behind all the neighboring 897 distribution source can avoid sending massive retransmission request 898 to the media source. 900 +------+ +--------+ +--------+ 901 |Media | +-----+ | RTP_Rx | +-----+ | RTP_Rx | 902 |Source| | DS1 | | served | | DS2 | | served | 903 +--+---+ +-----+ | by DS1 | +-----+ | by DS2 | 904 | | ----+----+ | ----+----+ 905 | |RTP Multicast | | | 906 |----------->|------------->| | | 907 | | | | | 908 | | | |RTP Multicast| 909 |------------------------------------------->|------------>| 910 | | | | | 911 | +--------+------------+ | | | 912 | |Detect Packet Loss | | | | 913 | |and Identify the SN | | | | 914 | |of the missing Packets | | | 915 | +--------+------------+ | | | 916 | | | | | 917 |<-RTCP NACK-| Multicast RTCP FSS | | 918 | |------------->| | | 919 | | | | | 920 | |-----Unicast RTCP FSS -------->|Multicast RTCP FSS 921 | | | |------------>| 922 |RTP Retransmission | | | 923 |----------->| | | | 924 | | | | | 925 | | RTP Retransmission | | 926 |------------+--------------+--------------->| | 927 | | | | | 928 | | RTP Multicast| | RTP Multicast 929 | |Retransmission| |Retransmission 930 | |------------->| |------------>| 931 | | | | | 932 DS1: Distribution Source 1 933 DS2: Distribution Source 2 935 Figure 7: Applicability of NACK Suppression Early Indication 937 Authors' Addresses 939 Qin Wu 940 Huawei 941 101 Software Avenue, Yuhua District 942 Nanjing, Jiangsu 210012 943 China 945 Email: sunseawq@huawei.com 946 Frank Xia 947 Huawei 948 1700 Alma Dr. Suite 500 949 Plano, TX 75075 950 USA 952 Phone: +1 972-509-5599 953 Email: xiayangsong@huawei.com 955 Roni Even 956 Huawei 957 14 David Hamelech 958 Tel Aviv 64953 959 Israel 961 Email: even.roni@huawei.com