idnits 2.17.1 draft-wu-avt-retransmission-supression-rtp-07.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (November 8, 2010) is 4917 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 647, but no explicit reference was found in the text == Unused Reference: 'RFC5740' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 677, 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: 3 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: May 12, 2011 Huawei 6 November 8, 2010 8 RTCP Report Extension for Feedback Suppression 9 draft-wu-avt-retransmission-supression-rtp-07 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 May 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 for a period of 130 time and can provide an early indication before the receiver reacts 131 to the loss and invokes its packet loss repair machinery. 133 Since feedback suppression interacts strongly with repair timing, it 134 has to work together with feedback to not adversely impact the repair 135 of lost source packets. One example is the middle box gets the 136 retransmitted packet by sending a NACK upstream and sent it 137 downstream. This retransmitted packet was lost on the downstream 138 link.In order to deal with this, the downstream receiver can start a 139 timeout in which it expected to get a retransmission packet. When 140 this timeout expires and there is no retransmitted packet or a new 141 suppression message, it can take its normal behavior as if there is 142 no current retransmission suppression.In some cases where the loss 143 was detected and repair initiated much closer to the source, the 144 delay for the receiver to recover from packet loss can be reduced 145 through the combination of intermediary feedback to the source and 146 feedback suppression downstream. In all (properly operating) cases, 147 the risk of increasing network congestion is decreased. 149 2. Terminology 151 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Protocol Overview 157 This document extends the RTCP feedback messages defined in the 158 Audio-Visual Profile with Feedback (AVPF) and define the Feedback 159 Suppression message. The Feedback Suppression message asks a 160 receiver to not send feedback messages for particular packets 161 (indicated by their RTP sequence numbers) independent of whether the 162 receiver detected the packet loss or detected a need for a decoder 163 refresh point). 165 In order to detect packet loss before the receivers perceive it, one 166 or more intermediate nodes may be placed between the media source and 167 receiver. These intermediates are variously referred to as 168 Distribution servers, MCUs, RTP translator, or RTP mixers, depending 169 on the precise use case. These intermediaries monitor for packet 170 loss upstream of themselves by checking RTP sequence numbers, just as 171 receivers do. Upon detecting (or suspecting) an upstream loss, the 172 intermediary may send Feedback Suppression message towards the 173 receivers as defined in this specification. 175 These intermediate nodes need to take into account such factors as 176 the tolerable application delay, the network dynamics, and the media 177 type. When the packet loss is detected upstream of the intermediary 178 and additional latency is tolerable, the intermediate node may itself 179 send a feedback message asking for the suspected lost packet or ask 180 for the correct decoder refresh point. Because it has already 181 provided the necessary feedback toward the source, the intermediate 182 node can be reasonably certain that it will help the situation by 183 sending a Feedback Suppression message to all the relevant receivers, 184 thereby indicating that the receivers should not themselves transmit 185 feedback messages for a period of time. 187 Alternatively, the media source may directly monitor the amount of 188 feedback requests it receives, and send feedback suppression messages 189 to the receivers. 191 When a receiver gets such a feedback suppression message, it should 192 refrain from sending a feedback request (e.g., NACK or FIR) for the 193 missing packets reported in the message for a period of time. A 194 receiver may still have sent a Feedback message before receiving a 195 feedback suppression message, but further feedback messages for those 196 sequence numbers will be suppressed by this technique for a period 197 time.Nodes that do not understand the feedback suppression message 198 will ignore it, and might therefore still send feedback. The media 199 source or intermediate nodes cannot assume that the use of a feedback 200 suppression request actually reduces the amount of feedback it 201 receives. 203 RTCP Feedback Suppression follows the same semantic model as RTCP 204 NACK - it conveys the packet receipt/loss events at the sequence 205 number level and considers missing packets as unrepaired. But unlike 206 RTCP NACK, the Feedback Suppression messages can be generated at RTP 207 middleboxs and sent to the corresponding receivers. Intermediaries 208 downstream of an intermediary detecting loss obviously SHOULD NOT 209 initiate their own additional feedback suppression messages for the 210 same packet sequence numbers. They may either simply forward the 211 Feedback Suppression message received from upstream, or augment (or 212 replace) it with a feedback suppression message that reflects the 213 loss pattern they have themselves seen. 215 4. RTCP Feedback Report Extension 217 This document registers two new RTCP Feedback messages for Feedback 218 Suppression. Applications that are employing one or more loss-repair 219 methods MAY use Feedback Suppression together with their existing 220 loss-repair methods either for every packet they expect to receive, 221 or for an application-specific subset of the RTP packets in a 222 session. In other words, receivers MAY ignore Feedback Suppression 223 messages, but SHOULD react to them unless they have good reason to 224 still send feedback messages despite having been requested to 225 suppress them. 227 4.1. Transport Layer Feedback: NACK Suppression Report 229 The NACK implosion Suppression message is an extension to the RTCP 230 feedback report and identified by RTCP packet type value PT=RTPFB and 231 FMT=TBD. 233 The FCI field MUST contain one or more NACK Suppression Early 234 Indication (NSEI) entries. Each entry applies to a different media 235 source, identified by its SSRC. 237 The Feedback Control Information (FCI) for NSEI uses the similar 238 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 239 The format is shown in Figure 1. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | SSRC | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | PID | BLP | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 1: Message Format for the NSEI report 251 SSRC (32 bits): 253 The SSRC value of the media source that is requested to send the 254 lost packet. 256 Packet ID (PID): 16 bits 258 The PID field is used to specify a lost packet. The PID field 259 refers to the RTP sequence number of the lost packet. 261 bitmask of proceeding lost packets (BLP): 16 bits 263 The BLP allows for reporting losses of any of the 16 RTP packets 264 immediately following the RTP packet indicated by the PID. The 265 BLP's definition is identical to that given in [RFC4585]. 267 4.2. Payload Specific Feedback: FIR suppression report 269 The FIR implosion Suppression message is an extension to the RTCP 270 receiver feedback report and identified by RTCP packet type value 271 PT=PSFB and FMT=TBD. 273 The FCI field MUST contain one or more FIR suppression Early 274 Indication (FSEI) entries. Each entry applies to a different media 275 source, identified by its SSRC. 277 The Feedback Control Information (FCI) for FSEI uses the similar 278 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 279 The format is shown in Figure 2. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | SSRC | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Seq nr. | Reserved | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 2: Message Format for the FSEI report 291 SSRC (32 bits): 293 The SSRC value of the media source that is requested to send a 294 decoder refresh point. 296 Seq nr:8bits Command sequence number. The sequence number space is 297 unique for each pairing of the SSRC of command source and the SSRC 298 of the command target. The sequence number SHALL be increased by 299 1 modulo 256 for each new request. 301 Reserved: 24 bits 303 All bits SHALL be set to 0 by the media source and SHALL be 304 ignored on reception. 306 5. SDP Signaling 308 A new feedback value "fss" needs to be defined for the Feedback Storm 309 Suppression message to be used with Session Description Protocol 310 (SDP)[RFC4566] using the Augmented Backus-Naur Form (ABNF)[RFC4585]. 312 The "fss" feedback value SHOULD be used with parameters that indicate 313 the feedback suppression supported. In this document, we define two 314 such parameters, namely: 316 o "fsei" denotes support of fir suppression early indication (fsei). 318 o "nsei" denotes support of NACK suppression early indication. 320 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 321 placeholder called rtcp-fb-id to define new feedback types. "fss" is 322 defined as a new feedback type in this document, and the ABNF for the 323 parameters for fss is defined here (please refer to section 4.2 of 324 [RFC4585] for complete ABNF syntax). 326 rtcp-fb-val =/ "fss" rtcp-fb-fss-param 327 rtcp-fb-fss-param = SP "nsei";nack suppression early indication 328 / SP "fsei";fir suppression early indication 329 / SP token [SP byte-string] 330 ; for future commands/indications 331 byte-string = 333 Refer to Section 4.2 of [RFC4585] for a detailed description and the 334 full syntax of the "rtcp-fb" attribute. 336 6. Example Use Cases 338 The operation of feedback suppression is similar for all types of RTP 339 sessions and topologies [RFC5117], however the exact messages used 340 and the scenarios in which suppression is employed differ for various 341 use cases. The following sections outline the intended use cases for 342 feedback suppression and give an overview of the particular 343 mechanisms. 345 6.1. Source Specific Multicast (SSM) use case 347 In SSM RTP sessions as described in [RFC5760], one or more Media 348 Sources send RTP packets to a Distribution Source. The Distribution 349 Source relays the RTP packets to the receivers using a source- 350 specific multicast group. 352 In order to avoid the forms of NACK implosion described in section 353 1,the distribution source should choose to include the support for 354 loss detection. How the packet loss detection works is beyond of 355 scope of this document. When upstream link or downstream aggregate 356 link packet loss occurs, the distribution source creates a Feedback 357 Suppression report and sent it to all the RTP receivers, over the 358 multicast channel. Another possibility is when there may have 359 multiple distribution source placed between the media source and the 360 receivers, the upstream distribution source may inform downstream 361 distribution source of the detected packet loss using Feedback 362 Suppression messages. In response, the distribution source forwards 363 packet loss suppression report received from upstream to all the RTP 364 receivers, over the multicast channel. This loss suppression report 365 tells the receivers that the lost packet will either be forthcoming 366 from distribution source, or it irretrievably lost such that there is 367 nothing to be gained by the receiver sending a NACK to the media 368 source. The distribution source then can (optionally) ask for the 369 lost packets from the media source on behalf of all the RTP 370 receivers. 372 When there is only one distribution source with loss detection 373 support between the media source and the receivers, redistribution of 374 the feedback suppression report to all the receivers is trivial. 375 When there are multiple distribution sources between the media source 376 and the receiver, , each distribution source with loss detection 377 support may create a Feedback Suppression Report using the similar 378 format as conventional RTCP NACK packets at the RTP layer and send it 379 to its downstream distribution source or forward one Feedback 380 Suppression Report from upstream to its downstream distribution 381 source or the receivers. Also each distribution source at the 382 downstream of the other distribution source may also create 383 additional Feedback Suppression Report and send it to the receivers. 385 The distribution source must be able to communicate with all group 386 members in order for either mechanism to be effective at suppressing 387 feedback. 389 As outlined in the [RFC5760], there are two Unicast Feedback models 390 that may be used for reporting, - the Simple Feedback model and the 391 Distribution Source Feedback Summary Model. The RTCP Feedback 392 Suppression report extension specified in the section 4 of this 393 document will work in both Feedback models. Details of operation in 394 each are specified below. 396 6.1.1. Simple Feedback Model 398 In the simple Feedback Model, there may have one distribution source 399 with loss detection support. The distribution source must listen on 400 the corresponding RTP session for data. When the distribution source 401 observes that a sequence of RTP packets from upstream contains gaps 402 (by checking the sequence number of packets), the distribution source 403 must use the same packet types as traditional RTCP feedback described 404 in [RFC3550] and create one new RTCP Feedback Report with information 405 on the RTP sequence number of the lost packets and suppression early 406 indication event. When the distribution source is eligible to 407 transmit, it must send this Report packet to the the group on the 408 multicast RTCP session. 410 Alternatively the distribution source should pass through any 411 feedback suppression requests it receives from the upstream 412 direction. Such a distribution source can also choose to not send 413 feedback suppression messages if it's already seen similar messages 414 with identical packet loss from upstream. 416 This RTCP Feedback Report lets the receivers know that feedback for 417 this packet loss is not needed and should not be sent to the media 418 source(s). If the media source(s) are part of the SSM group for RTCP 419 packet reflection, the Distribution Source must filter this packet 420 out. If the media source(s) are not part of the SSM group for RTCP 421 packets, the Distribution Source must not forward this RTCP packets 422 received from the receivers to the media source(s). 424 6.1.2. Distribution Source Feedback Summary Model 426 In the distribution source feedback summary model, there may have 427 multiple distribution sources and the Loss Detection instances are 428 distributed into different distribution sources. In some cases, 429 these Loss Detection instances for the same session can exist at the 430 same time, e.g., one Loss Detection instance is implemented in the 431 upstream distribution source A, another two Loss Detection instances 432 for the same session is part of feedback target A and feedback target 433 B respectively within the distribution source B. In this section, we 434 focus on this generic case to discuss the distribution Source 435 Feedback Summary Model. 437 The distribution source A must listen on the RTP channel for data. 438 When the distribution source A observes RTP packets from a media 439 source are not consecutive by checking the sequence number of 440 packets, the distribution source A generates the new RTCP Feedback 441 Suppression Report packet described in the section 6, and then send 442 it to the distribution source B. 444 Two loss detection instances within the Distribution Source B must 445 listen for RTCP data sent to the RTCP port. Upon receiving the RTCP 446 Feedback Report packet from the Distribution Source A, the 447 distribution source B needs to summarize the information received 448 from all the RTCP Feedback Reports generated by the upstream 449 distribution source together with the information generated by two 450 loss detection instances witin the Distribution Source B and then 451 create the summary report to include all these information. In order 452 to reduce the processing load at the distribution source, each loss 453 detection instance may provide preliminary summarization report. 455 During the summary report creating, the Distribution Source B must 456 use its own SSRC value for transmitting summarization information and 457 MUST perform proper SSRC collision detection and resolution. 459 In some case, the distribution source B may receive RTCP NACK 460 messages from the receivers behind the Distribution Source before the 461 distribution source detects the packet loss which may cause potential 462 Feedback implosion. In such case, the distribution source B may 463 filter them out if it already sent a packet loss request for the 464 missing packet to the media source. When the distribution source B 465 confirms packet loss reported by the receiver, the distribution 466 source B generates the summary report to include the packet loss 467 information from the corresponding receiver or upstream distribution 468 source. 470 The distribution source B may send this new RTCP summary report 471 described in the section 6 to the group on the multicast RTCP channel 472 and in the meanwhile sending a packet loss request to the media 473 source. 475 If there are a couple of distribution sources with loss detection 476 support looking at the same RTP stream, then the loss may be 477 identified by all and they will all send requests for the same packet 478 loss. In this case, the distribution source must filter out the 479 duplicated information from various distribution source and only 480 append one copy of such information to the summary report. 482 When the host receives the RTCP Feedback Suppression message, if the 483 host understands this message it will not send packet loss request 484 (e.g., NACK) for the missing packets reported in the message. If it 485 did not understand this new message, the host MAY send packet loss 486 request(e.g., NACK messages) to the specified media source. When the 487 distribution source receives the packet loss request from the hosts 488 after it has already detected packet loss, the distribution source 489 MUST filter it out until proactive recovery is complete. 491 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 492 case 494 In the typical RAMS architecture, there may have one distribution 495 source placed between media source and BRS for relaying SSM stream 496 from media source. The BRS will receive the SSM stream from the DS. 497 Suppose there are several BRSes behind the distribution source or 498 media source, there may be just one BRS that detects packet loss on 499 its upstream link between the distribution source and BRS, but the 500 others will perhaps not, as the packet loss took place on SSM tree 501 branch that does not impact the other BRSes. In such case, the 502 distribution source with loss detection functionality support can not 503 detect packet loss at the downstream of itself, therefore the 504 distribution source SHOULD NOT create new Feedback Suppression 505 message and send it to all the BRS. If BRS impacted by packet loss 506 has loss detection support, the BRS MAY choose to create new Feedback 507 Suppression message and send it to the receivers behind this BRS. 509 6.3. RTP transport translator use case 511 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 512 is typically forwarding the RTP and RTCP traffic between RTP clients, 513 for example converting between multicast and unicast for domains that 514 do not support multicast. The translator can identify packet loss 515 from the upstream and send the Feedback Suppression message to the 516 unicast receivers. The translator can also serve as a loss reporter 517 on the multicast side as described in the SSM case. 519 6.4. Multipoint Control Unit (MCU) use case 521 In point to multipoint topologies using video switching MCU (Topo- 522 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 523 media stream to each participant, selected from the available input 524 streams. The selection of the input stream is often based on voice 525 activity in the audio-visual conference, but other conference 526 management mechanisms (like presentation mode or explicit floor 527 control) exist as well. 529 In this case the MCU may detect packet loss from the sender or may 530 decide to switch to a new source. In both cases the receiver may 531 lose synchronization with the video stream and may send a FIR 532 request. If the MCU itself can detect the mis-synchronization of the 533 video, the MCU can send the FIR suppression message to the receivers 534 and send a FIR request to the video source. 536 7. Security Considerations 538 The defined messages have certain properties that have security 539 implications. These must be addressed and taken into account by 540 users of this protocol. 542 Spoofed or maliciously created feedback messages of the type defined 543 in this specification can have the following implications: 545 Sending NACK Suppression Report with wrong sequence number of lost 546 packet that makes missing RTP packets can not be compensated. 548 Sending FIR Suppression Report with wrong sequence number of lost 549 packet that makes missing RTP packets can not be compensated by 550 update request mechanism. 552 To prevent these attacks, there is a need to apply authentication and 553 integrity protection of the feedback messages. This can be 554 accomplished against threats external to the current RTP session 555 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 556 into SAVPF [RFC5124]. 558 Note that middleboxes that are not visible at the RTP layer that wish 559 to send NACK/FIR suppression reports on behalf of the media source 560 can only do so if they spoof the SSRC of the media source. This is 561 difficult in case SRTP is in use. If the middlebox is visible at the 562 RTP layer, this is not an issue, provided the middlebox is part of 563 the security context for the session. 565 Also note that endpoints that receive a NACK/FIR suppression request 566 would be well-advised to ignore it, unless it is authenticated via 567 SRTCP or similar. Accepting un-authenticated NACK/ FIR suppression 568 requests can lead to a denial of service attack, where the endpoint 569 accepts poor quality media that could be repaired. 571 8. IANA Consideration 573 New feedback type and New parameters for RTCP FSS receiver feedback 574 report are subject to IANA registration. For general guidelines on 575 IANA considerations for RTCP feedback, refer to [RFC4585]. 577 This document assigns one new feedback type value x in the RTCP 578 feedback report registry to "Feedback Storm Suppression" with the 579 following registrations format: 581 Name: FSS 582 Long Name: Feedback Storm Suppression 583 Value: TBD 584 Reference: This document. 586 This document also assigns the parameter value y in the RTCP FSS 587 feedback report Registry to "NACK Suppression Early Indication ", 588 with the following registrations format: 590 Name: NSEI 591 Long name: NACK Suppression Early Indication 592 Value: TBD 593 Reference: this document. 595 This document also assigns the parameter value z in the RTCP FSS 596 feedback report Registry to "FIR Suppression Early Indication ", with 597 the following registrations format: 599 Name: FSEI 600 Long name: FIR Suppression Early Indication 601 Value: TBD 602 Reference: this document. 604 The contact information for the registrations is: 606 Qin Wu 607 sunseawq@huawei.com 608 101 Software Avenue, Yuhua District 609 Nanjing, Jiangsu 210012, China 611 9. Acknowledgement 613 The authors would like to thank David R Oran, Ali C. Begen, Colin 614 Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, WeeSan 615 Lee for their valuable comments and suggestions on this document. 617 10. References 619 10.1. Normative References 621 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 622 Protocol (RTCP) Extensions for Single-Source Multicast 623 Sessions with Unicast Feedback", RFC 5760, February 2010. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 629 "Extended RTP Profile for Real-time Transport Control 630 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 631 July 2006. 633 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 634 Jacobson, "RTP: A Transport Protocol for Real-Time 635 Applications", STD 64, RFC 3550, July 2003. 637 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 638 January 2008. 640 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 641 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 642 July 2006. 644 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 645 Description Protocol", RFC 4566, July 2006. 647 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 648 Specifications: ABNF", STD 68, RFC 5234, January 2008. 650 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 651 "Codec Control Messages in the RTP Audio-Visual Profile 652 with Feedback (AVPF)", RFC 5104, February 2008. 654 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 655 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 656 RFC 3711, March 2004. 658 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 659 Real-time Transport Control Protocol (RTCP)-Based Feedback 660 (RTP/SAVPF)", RFC 5124, February 2008. 662 10.2. Informative References 664 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 665 "NACK-Oriented Reliable Multicast (NORM) Transport 666 Protocol", November 2009. 668 [DVB-IPTV] 669 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 670 of MPEG-2 TS Based DVB Services over IP Based Networks", 671 ETSI TS 102 034, V1.4.1 , August 2009. 673 [I-D.hunt-avt-monarch-01] 674 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 675 August 2008. 677 [I-D.ietf-pmol-metrics-framework-02] 678 Clark, A., "Framework for Performance Metric Development". 680 Authors' Addresses 682 Qin Wu 683 Huawei 684 101 Software Avenue, Yuhua District 685 Nanjing, Jiangsu 210012 686 China 688 Email: sunseawq@huawei.com 690 Frank Xia 691 Huawei 692 1700 Alma Dr. Suite 500 693 Plano, TX 75075 694 USA 696 Phone: +1 972-509-5599 697 Email: xiayangsong@huawei.com 698 Roni Even 699 Huawei 700 14 David Hamelech 701 Tel Aviv 64953 702 Israel 704 Email: even.roni@huawei.com