idnits 2.17.1 draft-wu-avt-retransmission-supression-rtp-06.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). == 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 25, 2010) is 4932 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 639, but no explicit reference was found in the text == Unused Reference: 'RFC5740' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 669, 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 28, 2011 Huawei 6 October 25, 2010 8 RTCP Report Extension for Feedback Suppression 9 draft-wu-avt-retransmission-supression-rtp-06 11 Abstract 13 In a large RTP session using the RTCP feedback mechanism defined in 14 RFC 4585, a media source or middlebox may experience transient 15 overload if some event causes a large number of receivers to send 16 feedback at once. This feedback implosion can be mitigated if the 17 device suffering from overload can send a feedback suppression 18 message to the receivers to inhibit further feedback. This memo 19 defines RTCP extensions for feedback suppression, to suppress NACK 20 and FIR feedback requests. It also defines associated SDP 21 signalling." 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 28, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 72 4. RTCP Feedback Report Extension . . . . . . . . . . . . . . . . 6 73 4.1. Transport Layer Feedback: NACK Suppression Report . . . . 6 74 4.2. Payload Specific Feedback: FIR suppression report . . . . 7 75 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 77 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9 78 6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 10 79 6.1.2. Distribution Source Feedback Summary Model . . . . . . 11 80 6.2. Unicast based Rapid Acquisition of Multicast Stream 81 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 12 82 6.3. RTP transport translator use case . . . . . . . . . . . . 12 83 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 86 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 RTCP feedback messages [RFC4585] allow the receivers in an RTP 95 session to report events and ask for action from the media source (or 96 a delegated feedback target). There are cases where multiple 97 receivers may initiate the same, or an equivalent message towards the 98 same media source. When the receiver count is large, this behavior 99 may cause transient overload of the media source,the network or both. 100 This is known as a "feedback storm" or a "NACK storm". One common 101 cause of such a feedback storm is receivers utilizing RTP 102 retransmission [RFC4588] as a packet loss recovery technique based, 103 sending feedback using RTCP NACK messages [RFC4585] without proper 104 dithering of the retransmission requests. 106 Another use case involves video Fast Update requests. A storm of 107 these feedback messages can occur in conversational multimedia 108 scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, 109 packet loss may happen on an upstream link of an intermediate network 110 element such as a Multipoint Control Unit(MCU). Poorly designed 111 receivers that blindly issue fast update requests (i.e., Full Intra 112 Request (FIR) described in [RFC5104]), can cause an implosion of FIR 113 requests from receivers to the same media source. 115 RTCP feedback storms may cause short term overload and, and in 116 extreme cases to pose a possible risk of increasing network 117 congestion on the control channel (e.g. RTCP feedback), the data 118 channel, or both. It is therefore desirable to provide a way of 119 suppressing unneeded feedback. 121 One approach to this, suggested in [DVB-IPTV], involves sending a 122 NACK message from server to the client (or receiver). However NACK 123 is defined as a receiver report sent from a client to the server and 124 therefore exhibits a semantic mismatch when used as a suppression 125 indication from the server (or intermediary) to the client. This 126 document instead specifies a newly message for this function. It 127 further is more precise in the intended uses and less likely to be 128 confusing to receivers. It tells receivers explicitly that feedback 129 for a particular packet or frame loss is not needed and can provide 130 an early indication before the receiver reacts to the loss and 131 invokes its packet loss repair machinery. 133 2. Terminology 135 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Protocol Overview 141 This document extends the RTCP feedback messages defined in the 142 Audio-Visual Profile with Feedback (AVPF) and define the Feedback 143 Suppression message. The Feedback Suppression message asks a 144 receiver to not send feedback messages for particular packets 145 (indicated by their RTP sequence numbers) independent of whether the 146 receiver detected the packet loss or detected a need for a decoder 147 refresh point). 149 In order to detect packet loss before the receivers perceive it, one 150 or more intermediate nodes may be placed between the media source and 151 receiver. These intermediates are variously referred to as 152 Distribution servers, MCUs, RTP translator, or RTP mixers, depending 153 on the precise use case. These intermediaries monitor for packet 154 loss upstream of themselves by checking RTP sequence numbers, just as 155 receivers do. Upon detecting (or suspecting) an upstream loss, the 156 intermediary may send Feedback Suppression message towards the 157 receivers as defined in this specification. 159 These intermediate nodes need to take into account such factors as 160 the tolerable application delay, the network dynamics, and the media 161 type. When the packet loss is detected upstream of the intermediary 162 and additional latency is tolerable, the intermediate node may itself 163 send a feedback message asking for the suspected lost packet or ask 164 for the correct decoder refresh point. Because it has already 165 provided the necessary feedback toward the source, the intermediate 166 node can be reasonably certain that it will help the situation by 167 sending a Feedback Suppression message to all the relevant receivers, 168 thereby indicating that the receivers should not themselves transmit 169 feedback messages. 171 Alternatively, the media source may directly monitor the amount of 172 feedback requests it receives, and send feedback suppression messages 173 to the receivers. 175 When a receiver gets such a feedback suppression message, it should 176 refrain from sending a feedback request (e.g., NACK or FIR) for the 177 missing packets reported in the message. A receiver may still have 178 sent a Feedback message before receiving a feedback suppression 179 message, but further feedback messages for those sequence numbers 180 will be suppressed by this technique. Nodes that do not understand 181 the feedback suppression message will ignore it, and might therefore 182 still send feedback. The media source or intermediate nodes cannot 183 assume that the use of a feedback suppression request actually 184 reduces the amount of feedback it receives. 186 RTCP Feedback Suppression follows the same semantic model as RTCP 187 NACK - it conveys the packet receipt/loss events at the sequence 188 number level and considers missing packets as unrepaired. But unlike 189 RTCP NACK, the Feedback Suppression messages can be generated at RTP 190 middleboxs and sent to the corresponding receivers. Intermediaries 191 downstream of an intermediary detecting loss obviously SHOULD NOT 192 initiate their own additional feedback suppression messages for the 193 same packet sequence numbers. They may either simply forward the 194 Feedback Suppression message received from upstream, or augment (or 195 replace) it with a feedback suppression message that reflects the 196 loss pattern they have themselves seen. 198 Since feedback suppression interacts strongly with repair timing, it 199 has to work together with feedback to not adversely impact the repair 200 of lost source packets. In some cases where the loss was detected 201 and repair initiated much closer to the source, the delay for the 202 receiver to recover from packet loss can be reduced through the 203 combination of intermediary feedback to the source and feedback 204 suppression downstream. In all (properly operating) cases, the risk 205 of increasing network congestion is decreased. 207 4. RTCP Feedback Report Extension 209 This document registers two new RTCP Feedback messages for Feedback 210 Suppression. Applications that are employing one or more loss-repair 211 methods MAY use Feedback Suppression together with their existing 212 loss-repair methods either for every packet they expect to receive, 213 or for an application-specific subset of the RTP packets in a 214 session. In other words, receivers MAY ignore Feedback Suppression 215 messages, but SHOULD react to them unless they have good reason to 216 still send feedback messages despite having been requested to 217 suppress them. 219 4.1. Transport Layer Feedback: NACK Suppression Report 221 The NACK implosion Suppression message is an extension to the RTCP 222 feedback report and identified by RTCP packet type value PT=RTPFB and 223 FMT=TBD. 225 The FCI field MUST contain one or more NACK Suppression Early 226 Indication (NSEI) entries. Each entry applies to a different media 227 source, identified by its SSRC. 229 The Feedback Control Information (FCI) for NSEI uses the similar 230 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 231 The format is shown in Figure 1. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | SSRC | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | PID | BLP | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 1: Message Format for the NSEI report 243 SSRC (32 bits): 245 The SSRC value of the media source that is requested to send the 246 lost packet. 248 Packet ID (PID): 16 bits 250 The PID field is used to specify a lost packet. The PID field 251 refers to the RTP sequence number of the lost packet. 253 bitmask of proceeding lost packets (BLP): 16 bits 255 The BLP allows for reporting losses of any of the 16 RTP packets 256 immediately following the RTP packet indicated by the PID. The 257 BLP's definition is identical to that given in [RFC4585]. 259 4.2. Payload Specific Feedback: FIR suppression report 261 The FIR implosion Suppression message is an extension to the RTCP 262 receiver feedback report and identified by RTCP packet type value 263 PT=PSFB and FMT=TBD. 265 The FCI field MUST contain one or more FIR suppression Early 266 Indication (FSEI) entries. Each entry applies to a different media 267 source, identified by its SSRC. 269 The Feedback Control Information (FCI) for FSEI uses the similar 270 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 271 The format is shown in Figure 2. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | SSRC | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Seq nr. | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 2: Message Format for the FSEI report 283 SSRC (32 bits): 285 The SSRC value of the media source that is requested to send a 286 decoder refresh point. 288 Seq nr:8bits Command sequence number. The sequence number space is 289 unique for each pairing of the SSRC of command source and the SSRC 290 of the command target. The sequence number SHALL be increased by 291 1 modulo 256 for each new request. 293 Reserved: 24 bits 295 All bits SHALL be set to 0 by the media source and SHALL be 296 ignored on reception. 298 5. SDP Signaling 300 A new feedback value "fss" needs to be defined for the Feedback Storm 301 Suppression message to be used with Session Description Protocol 302 (SDP)[RFC4566] using the Augmented Backus-Naur Form (ABNF)[RFC4585]. 304 The "fss" feedback value SHOULD be used with parameters that indicate 305 the feedback suppression supported. In this document, we define two 306 such parameters, namely: 308 o "fsei" denotes support of fir suppression early indication (fsei). 310 o "nsei" denotes support of NACK suppression early indication. 312 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 313 placeholder called rtcp-fb-id to define new feedback types. "fss" is 314 defined as a new feedback type in this document, and the ABNF for the 315 parameters for fss is defined here (please refer to section 4.2 of 316 [RFC4585] for complete ABNF syntax). 318 rtcp-fb-val =/ "fss" rtcp-fb-fss-param 319 rtcp-fb-fss-param = SP "nsei";nack suppression early indication 320 / SP "fsei";fir suppression early indication 321 / SP token [SP byte-string] 322 ; for future commands/indications 323 byte-string = 325 Refer to Section 4.2 of [RFC4585] for a detailed description and the 326 full syntax of the "rtcp-fb" attribute. 328 6. Example Use Cases 330 The operation of feedback suppression is similar for all types of RTP 331 sessions and topologies [RFC5117], however the exact messages used 332 and the scenarios in which suppression is employed differ for various 333 use cases. The following sections outline the intended use cases for 334 feedback suppression and give an overview of the particular 335 mechanisms. 337 6.1. Source Specific Multicast (SSM) use case 339 In SSM RTP sessions as described in [RFC5760], one or more Media 340 Sources send RTP packets to a Distribution Source. The Distribution 341 Source relays the RTP packets to the receivers using a source- 342 specific multicast group. 344 In order to avoid the forms of NACK implosion described in section 345 1,the distribution source should choose to include the support for 346 loss detection. How the packet loss detection works is beyond of 347 scope of this document. When upstream link or downstream aggregate 348 link packet loss occurs, the distribution source creates a Feedback 349 Suppression report and sent it to all the RTP receivers, over the 350 multicast channel. Another possibility is when there may have 351 multiple distribution source placed between the media source and the 352 receivers, the upstream distribution source may inform downstream 353 distribution source of the detected packet loss using Feedback 354 Suppression messages. In response, the distribution source forwards 355 packet loss suppression report received from upstream to all the RTP 356 receivers, over the multicast channel. This loss suppression report 357 tells the receivers that the lost packet will either be forthcoming 358 from distribution source, or it irretrievably lost such that there is 359 nothing to be gained by the receiver sending a NACK to the media 360 source. The distribution source then can (optionally) ask for the 361 lost packets from the media source on behalf of all the RTP 362 receivers. 364 When there is only one distribution source with loss detection 365 support between the media source and the receivers, redistribution of 366 the feedback suppression report to all the receivers is trivial. 367 When there are multiple distribution sources between the media source 368 and the receiver, , each distribution source with loss detection 369 support may create a Feedback Suppression Report using the similar 370 format as conventional RTCP NACK packets at the RTP layer and send it 371 to its downstream distribution source or forward one Feedback 372 Suppression Report from upstream to its downstream distribution 373 source or the receivers. Also each distribution source at the 374 downstream of the other distribution source may also create 375 additional Feedback Suppression Report and send it to the receivers. 377 The distribution source must be able to communicate with all group 378 members in order for either mechanism to be effective at suppressing 379 feedback. 381 As outlined in the [RFC5760], there are two Unicast Feedback models 382 that may be used for reporting, - the Simple Feedback model and the 383 Distribution Source Feedback Summary Model. The RTCP Feedback 384 Suppression report extension specified in the section 4 of this 385 document will work in both Feedback models. Details of operation in 386 each are specified below. 388 6.1.1. Simple Feedback Model 390 In the simple Feedback Model, there may have one distribution source 391 with loss detection support. The distribution source must listen on 392 the corresponding RTP session for data. When the distribution source 393 observes that a sequence of RTP packets from upstream contains gaps 394 (by checking the sequence number of packets), the distribution source 395 must use the same packet types as traditional RTCP feedback described 396 in [RFC3550] and create one new RTCP Feedback Report with information 397 on the RTP sequence number of the lost packets and suppression early 398 indication event. When the distribution source is eligible to 399 transmit, it must send this Report packet to the the group on the 400 multicast RTCP session. 402 Alternatively the distribution source should pass through any 403 feedback suppression requests it receives from the upstream 404 direction. Such a distribution source can also choose to not send 405 feedback suppression messages if it's already seen similar messages 406 with identical packet loss from upstream. 408 This RTCP Feedback Report lets the receivers know that feedback for 409 this packet loss is not needed and should not be sent to the media 410 source(s). If the media source(s) are part of the SSM group for RTCP 411 packet reflection, the Distribution Source must filter this packet 412 out. If the media source(s) are not part of the SSM group for RTCP 413 packets, the Distribution Source must not forward this RTCP packets 414 received from the receivers to the media source(s). 416 6.1.2. Distribution Source Feedback Summary Model 418 In the distribution source feedback summary model, there may have 419 multiple distribution sources and the Loss Detection instances are 420 distributed into different distribution sources. In some cases, 421 these Loss Detection instances for the same session can exist at the 422 same time, e.g., one Loss Detection instance is implemented in the 423 upstream distribution source A, another two Loss Detection instances 424 for the same session is part of feedback target A and feedback target 425 B respectively within the distribution source B. In this section, we 426 focus on this generic case to discuss the distribution Source 427 Feedback Summary Model. 429 The distribution source A must listen on the RTP channel for data. 430 When the distribution source A observes RTP packets from a media 431 source are not consecutive by checking the sequence number of 432 packets, the distribution source A generates the new RTCP Feedback 433 Suppression Report packet described in the section 6, and then send 434 it to the distribution source B. 436 Two loss detection instances within the Distribution Source B must 437 listen for RTCP data sent to the RTCP port. Upon receiving the RTCP 438 Feedback Report packet from the Distribution Source A, the 439 distribution source B needs to summarize the information received 440 from all the RTCP Feedback Reports generated by the upstream 441 distribution source together with the information generated by two 442 loss detection instances witin the Distribution Source B and then 443 create the summary report to include all these information. In order 444 to reduce the processing load at the distribution source, each loss 445 detection instance may provide preliminary summarization report. 447 During the summary report creating, the Distribution Source B must 448 use its own SSRC value for transmitting summarization information and 449 MUST perform proper SSRC collision detection and resolution. 451 In some case, the distribution source B may receive RTCP NACK 452 messages from the receivers behind the Distribution Source before the 453 distribution source detects the packet loss which may cause potential 454 Feedback implosion. In such case, the distribution source B may 455 filter them out if it already sent a packet loss request for the 456 missing packet to the media source. When the distribution source B 457 confirms packet loss reported by the receiver, the distribution 458 source B generates the summary report to include the packet loss 459 information from the corresponding receiver or upstream distribution 460 source. 462 The distribution source B may send this new RTCP summary report 463 described in the section 6 to the group on the multicast RTCP channel 464 and in the meanwhile sending a packet loss request to the media 465 source. 467 If there are a couple of distribution sources with loss detection 468 support looking at the same RTP stream, then the loss may be 469 identified by all and they will all send requests for the same packet 470 loss. In this case, the distribution source must filter out the 471 duplicated information from various distribution source and only 472 append one copy of such information to the summary report. 474 When the host receives the RTCP Feedback Suppression message, if the 475 host understands this message it will not send packet loss request 476 (e.g., NACK) for the missing packets reported in the message. If it 477 did not understand this new message, the host MAY send packet loss 478 request(e.g., NACK messages) to the specified media source. When the 479 distribution source receives the packet loss request from the hosts 480 after it has already detected packet loss, the distribution source 481 MUST filter it out until proactive recovery is complete. 483 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 484 case 486 In the typical RAMS architecture, there may have one distribution 487 source placed between media source and BRS for relaying SSM stream 488 from media source. The BRS will receive the SSM stream from the DS. 489 Suppose there are several BRSes behind the distribution source or 490 media source, there may be just one BRS that detects packet loss on 491 its upstream link between the distribution source and BRS, but the 492 others will perhaps not, as the packet loss took place on SSM tree 493 branch that does not impact the other BRSes. In such case, the 494 distribution source with loss detection functionality support can not 495 detect packet loss at the downstream of itself, therefore the 496 distribution source SHOULD NOT create new Feedback Suppression 497 message and send it to all the BRS. If BRS impacted by packet loss 498 has loss detection support, the BRS MAY choose to create new Feedback 499 Suppression message and send it to the receivers behind this BRS. 501 6.3. RTP transport translator use case 503 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 504 is typically forwarding the RTP and RTCP traffic between RTP clients, 505 for example converting between multicast and unicast for domains that 506 do not support multicast. The translator can identify packet loss 507 from the upstream and send the Feedback Suppression message to the 508 unicast receivers. The translator can also serve as a loss reporter 509 on the multicast side as described in the SSM case. 511 6.4. Multipoint Control Unit (MCU) use case 513 In point to multipoint topologies using video switching MCU (Topo- 514 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 515 media stream to each participant, selected from the available input 516 streams. The selection of the input stream is often based on voice 517 activity in the audio-visual conference, but other conference 518 management mechanisms (like presentation mode or explicit floor 519 control) exist as well. 521 In this case the MCU may detect packet loss from the sender or may 522 decide to switch to a new source. In both cases the receiver may 523 lose synchronization with the video stream and may send a FIR 524 request. If the MCU itself can detect the mis-synchronization of the 525 video, the MCU can send the FIR suppression message to the receivers 526 and send a FIR request to the video source. 528 7. Security Considerations 530 The defined messages have certain properties that have security 531 implications. These must be addressed and taken into account by 532 users of this protocol. 534 Spoofed or maliciously created feedback messages of the type defined 535 in this specification can have the following implications: 537 Sending NACK Suppression Report with wrong sequence number of lost 538 packet that makes missing RTP packets can not be compensated. 540 Sending FIR Suppression Report with wrong sequence number of lost 541 packet that makes missing RTP packets can not be compensated by 542 update request mechanism. 544 To prevent these attacks, there is a need to apply authentication and 545 integrity protection of the feedback messages. This can be 546 accomplished against threats external to the current RTP session 547 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 548 into SAVPF [RFC5124]. 550 Note that middleboxes that are not visible at the RTP layer that wish 551 to send NACK/FIR suppression reports on behalf of the media source 552 can only do so if they spoof the SSRC of the media source. This is 553 difficult in case SRTP is in use. If the middlebox is visible at the 554 RTP layer, this is not an issue, provided the middlebox is part of 555 the security context for the session. 557 Also note that endpoints that receive a NACK/FIR suppression request 558 would be well-advised to ignore it, unless it is authenticated via 559 SRTCP or similar. Accepting un-authenticated NACK/ FIR suppression 560 requests can lead to a denial of service attack, where the endpoint 561 accepts poor quality media that could be repaired. 563 8. IANA Consideration 565 New feedback type and New parameters for RTCP FSS receiver feedback 566 report are subject to IANA registration. For general guidelines on 567 IANA considerations for RTCP feedback, refer to [RFC4585]. 569 This document assigns one new feedback type value x in the RTCP 570 feedback report registry to "Feedback Storm Suppression" with the 571 following registrations format: 573 Name: FSS 574 Long Name: Feedback Storm Suppression 575 Value: TBD 576 Reference: This document. 578 This document also assigns the parameter value y in the RTCP FSS 579 feedback report Registry to "NACK Suppression Early Indication ", 580 with the following registrations format: 582 Name: NSEI 583 Long name: NACK Suppression Early Indication 584 Value: TBD 585 Reference: this document. 587 This document also assigns the parameter value z in the RTCP FSS 588 feedback report Registry to "FIR Suppression Early Indication ", with 589 the following registrations format: 591 Name: FSEI 592 Long name: FIR Suppression Early Indication 593 Value: TBD 594 Reference: this document. 596 The contact information for the registrations is: 598 Qin Wu 599 sunseawq@huawei.com 600 101 Software Avenue, Yuhua District 601 Nanjing, Jiangsu 210012, China 603 9. Acknowledgement 605 The authors would like to thank David R Oran, Ali C. Begen, Colin 606 Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, WeeSan 607 Lee for their valuable comments and suggestions on this document. 609 10. References 611 10.1. Normative References 613 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 614 Protocol (RTCP) Extensions for Single-Source Multicast 615 Sessions with Unicast Feedback", RFC 5760, February 2010. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 621 "Extended RTP Profile for Real-time Transport Control 622 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 623 July 2006. 625 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 626 Jacobson, "RTP: A Transport Protocol for Real-Time 627 Applications", STD 64, RFC 3550, July 2003. 629 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 630 January 2008. 632 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 633 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 634 July 2006. 636 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 637 Description Protocol", RFC 4566, July 2006. 639 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 640 Specifications: ABNF", STD 68, RFC 5234, January 2008. 642 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 643 "Codec Control Messages in the RTP Audio-Visual Profile 644 with Feedback (AVPF)", RFC 5104, February 2008. 646 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 647 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 648 RFC 3711, March 2004. 650 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 651 Real-time Transport Control Protocol (RTCP)-Based Feedback 652 (RTP/SAVPF)", RFC 5124, February 2008. 654 10.2. Informative References 656 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 657 "NACK-Oriented Reliable Multicast (NORM) Transport 658 Protocol", November 2009. 660 [DVB-IPTV] 661 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 662 of MPEG-2 TS Based DVB Services over IP Based Networks", 663 ETSI TS 102 034, V1.4.1 , August 2009. 665 [I-D.hunt-avt-monarch-01] 666 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 667 August 2008. 669 [I-D.ietf-pmol-metrics-framework-02] 670 Clark, A., "Framework for Performance Metric Development". 672 Authors' Addresses 674 Qin Wu 675 Huawei 676 101 Software Avenue, Yuhua District 677 Nanjing, Jiangsu 210012 678 China 680 Email: sunseawq@huawei.com 682 Frank Xia 683 Huawei 684 1700 Alma Dr. Suite 500 685 Plano, TX 75075 686 USA 688 Phone: +1 972-509-5599 689 Email: xiayangsong@huawei.com 690 Roni Even 691 Huawei 692 14 David Hamelech 693 Tel Aviv 64953 694 Israel 696 Email: even.roni@huawei.com