idnits 2.17.1 draft-wu-avt-retransmission-supression-rtp-04.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 is 1 instance of too long lines in the document, the longest one being 2 characters 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). == 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 13, 2010) is 4941 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 741, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 771, 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: April 16, 2011 Huawei 6 October 13, 2010 8 RTCP Report Extension for Feedback Suppression 9 draft-wu-avt-retransmission-supression-rtp-04 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 16, 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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 12 89 6.1.2. Distribution Source Feedback Summary Model . . . . . . 13 90 6.2. RTP transport translator use case . . . . . . . . . . . . 14 91 6.3. Multipoint Control Unit (MCU) use case . . . . . . . . . . 14 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 15 94 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 97 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 98 Appendix A. Example scenarios for NACK Implosion . . . . . . . . 18 99 A.1. Scenario 1: One or more media source, One distribution 100 source . . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 A.2. Scenario 2:One media source, Two distribution sources 102 in cascade . . . . . . . . . . . . . . . . . . . . . . . . 19 103 A.3. Scenario 3:One media source, Two distribution sources 104 in parallel . . . . . . . . . . . . . . . . . . . . . . . 19 105 Appendix B. Applicability of Feedback Suppression . . . . . . . . 20 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Introduction 110 RTCP feedback messages [RFC4585]allow the receivers in an RTP session 111 to report events and ask for action from the media source (or a 112 delegated feedback target). There are cases where multiple receivers 113 may initiate the same, or an equivalent message towards the same 114 media source. When the receiver count is large, this behavior may 115 overload the media source or the network or both. One common case is 116 receivers utilizing RTP retransmission as a packet loss recovery 117 technique in a real-time application such as streaming video or 118 audio.[RFC4585]Feedback is accomplished using the RTCP NACK message 119 which conveys the RTP sequence number(s) of the lost packet(s). This 120 information can then be used by the media or distribution source to 121 retransmit the missing RTP packets using the RTP retransmission 122 payload format[RFC4588]. 124 However, in topologies utilizing transport translators (Topo-Trn- 125 Translator) or large-scale multicast transmission (Topo-Multicast) as 126 defined in [RFC5117], packet loss can occur on either an upstream 127 link or a downstream aggregate link of the intermediate network 128 element (e.g., Retransmission server, Distribution Source). Where 129 there are many receivers, this may result in a Feedback implosion 130 [RFC5740] towards the media or distribution source, i.e., large 131 number of feedback requests to the same multicast sender for 132 retransmission of the same RTP packets. This phenomenon goes by a 133 number of alternate names, such as the "feedback storm" or the "NACK 134 storm" terminology of [DVB-IPTV]. In an attempt to increase its 135 robustness against the loss of a feedback message or of 136 retransmission packets, a receiver may send multiple feedbacks for 137 the same detected packet loss, which may aggravate the feedback 138 implosion. 140 Another use case involves video Fast Update requests. A storm of 141 these feedback messages can occur in conversational multimedia 142 scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, 143 packet loss may happen on an upstream link of an intermediate network 144 element such as a Multipoint Control Unit(MCU). Receivers missing 145 the packets issue fast update requests (i.e., Full Intra Request(FIR) 146 described in [RFC5104]), which results in an implosion of FIR 147 requests from receivers to the same media source. 149 As these feedback storms propagate (e.g., NACK implosion or Fast 150 update implosion), the network may be permeated with more and more 151 feedback traffic, resulting in a positive feedback loop as the 152 network is also saturated with media traffic. RTCP feedback storms 153 may cause short term overload and, and in extreme cases to pose a 154 possible risk of increasing network congestion on the control channel 155 (e.g. RTCP feedback), the data channel (i.e. RTP retransmission), 156 or Both if the receivers are not correctly implemented 158 In order to mitigate these behaviors, the current text in [RFC5760] 159 allows the distribution source to filter out the NACK messages and 160 [DVB-IPTV] suggests sending a NACK message from server to the client 161 (or receiver). However NACK is defined as a receiver report sent 162 from a client to the server and therefore exhibits a semantic 163 mismatch when used as a suppression indication from the server (or 164 intermediary) to the client. This document instead specifies a newly 165 message for this function. It further is more precise in the 166 intended uses and less likely to be confusing to receivers. It tells 167 receivers explicitly that feedback for a particular packet loss is 168 not needed and can provide an early indication before the receiver 169 reacts to the loss and invokes its packet loss repair machinery. 171 Receivers respond to receipt of a feedback suppression message by not 172 sending a feedback message (e.g. a NACK) that they otherwise would, 173 This in turn reduces load on both the feedback target and on the 174 network. 176 Also the intermediate node may initiate its own feedback toward the 177 media source to provoke a retransmission. When the media source 178 receives the request from the intermediate node, the media source 179 resends the lost packets to the receivers by using the RTP 180 retransmission payload format [RFC4588] or resends a new refresh 181 point for FIR Initiator [RFC5104], depending on the type of feedback 182 it received. 184 2. Terminology 186 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 Loss Detector: 192 The Loss Detector is one logical function which is used to detect 193 the packet loss at the RTP layer and report it to the distribution 194 source. The function of the loss reporter may be collocated with 195 or integrated into the same entity. In this case, for a session 196 defined as having a distribution source A, on ports n for the RTP 197 channel and k for the RTCP channel, the Loss Detector are 198 identified by an IP address of distribution source A on port k. 199 The Loss Detector MAY also be implemented in one or more entities 200 different from the distribution source. 202 3. Protocol Overview 204 This document extend the RTCP feedback messages defined in the Audio- 205 Visual Profile with Feedback (AVPF) and define the Feedback 206 Suppression message. The Feedback Suppression message asks a 207 receiver to not send feedback messages for particular packets 208 (indicated by their RTP sequence numbers) independent of whether the 209 receiver detected the packet loss or detected a need for a decoder 210 refresh point). 212 In order to detect packet loss before the receivers perceive it, one 213 or more intermediate nodes are placed between the media source and 214 receiver (e.g., Distribution server, MCU, RTP translator). These 215 intermediaries monitor for packet loss upstream of themselves by 216 checking RTP sequence numbers, just as receivers do. Upon detecting 217 (or suspecting) an upstream loss, the intermediary may send Feedback 218 Suppression message towards the receivers as defined in this 219 specification. 221 Instead of using specialized intermediaries, another possibility is 222 to instantiate one or more RTP receivers upstream of the loss region 223 to act as immediate reporters as described in[DVB-IPTV]. These 224 intermediate nodes need to take into account such factors as the 225 tolerable application delay, the network dynamics, and the media 226 type. When the packet loss is detected upstream of the intermediary 227 and additional latency is tolerable, the intermediate node may itself 228 send a feedback message asking for the suspected lost packet or ask 229 for the correct decoder refresh point. Because it has already 230 provided the necessary feedback toward the source, the intermediate 231 node can be reasonably certain that it will help the situation by 232 sending a Feedback Suppression message to all the relevant receivers, 233 thereby indicating that the receivers should not themselves transmit 234 feedback messages. 236 RTCP Feedback Storm Suppression follows the same semantic model as 237 RTCP NACK - it conveys the packet receipt/loss events at the sequence 238 number level and considers missing packets as unrepaired. But unlike 239 RTCP NACK, the Feedback Suppression messages can be generated at 240 intermediate nodes who are not RTP receivers and sent to the 241 corresponding receivers. Intermediaries downstream of an 242 intermediary detecting loss obviously SHOULD NOT initiate their own 243 additional feedback suppression messages for the same packet sequence 244 numbers. They may either simply forward the Feedback Suppression 245 message received from upstream, or augment (or replace) it with a 246 feedback suppression message that reflects the loss pattern they have 247 themselves seen. 249 Since feedback suppression interacts strongly with repair timing, it 250 has to work together with feedback to not adversely impact the repair 251 of lost source packets. In some cases where the loss was detected 252 and repair initiated much closer to the source, the delay for the 253 receiver to recover from packet loss can be reduced through the 254 combination of intermediary feedback to the source and feedback 255 suppression downstream. In all (properly operating) cases, the risk 256 of increasing network congestion is decreased. A receiver may still 257 have sent a Feedback message before receiving a feedback suppression 258 message, but further feedback messages for those sequence numbers 259 will be suppressed by this technique. 261 This document registers two new RTCP Feedback messages for Feedback 262 Suppression. Applications that are employing one or more loss-repair 263 methods MAY use Feedback Suppression together with their existing 264 loss-repair methods either for every packet they expect to receive, 265 or for an application-specific subset of the RTP packets in a 266 session. In other words, receivers MAY ignore Feedback Suppression 267 messages, but SHOULD react to them unless they have good reason to 268 still send feedback messages despite having been requested to 269 suppress them. 271 4. RTCP Feedback Report Extension 273 4.1. Transport Layer Feedback: NACK Suppression Report 275 The NACK implosion Suppression message is an extension to the RTCP 276 feedback report and identified by RTCP packet type value PT=RTPFB and 277 FMT=TBD. 279 The FCI field MUST contain one or more NACK Suppression Early 280 Indication (NSEI) entries. Each entry applies to a different media 281 source, identified by its SSRC. 283 The Feedback Control Information (FCI) for NSEI uses the similar 284 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 285 The format is shown in Figure 1. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | SSRC | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | PID | BLP | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 1: Message Format for the NSEI report 297 SSRC (32 bits): 299 The SSRC value of the media source that is requested to send the 300 lost packet. 302 Packet ID (PID): 16 bits 304 The PID field is used to specify a lost packet. The PID field 305 refers to the RTP sequence number of the lost packet. 307 bitmask of following lost packets (BLP): 16 bits 309 The BLP allows for reporting losses of any of the 16 RTP packets 310 immediately following the RTP packet indicated by the PID. The 311 BLP's definition is identical to that given in [RFC4585]. 313 4.2. Payload Specific Feedback: FIR suppression report 315 The FIR implosion Suppression message is an extension to the RTCP 316 receiver feedback report and identified by RTCP packet type value 317 PT=PSFB and FMT=TBD. 319 The FCI field MUST contain one or more FIR suppression Early 320 Indication (FSEI) entries. Each entry applies to a different media 321 source, identified by its SSRC. 323 The Feedback Control Information (FCI) for FSEI uses the similar 324 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 325 The format is shown in Figure 2. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | SSRC | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Seq nr. | Reserved | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 2: Message Format for the FSEI report 337 SSRC (32 bits): 339 The SSRC value of the media source that is requested to send a 340 decoder refresh point. 342 Seq nr:8bits Command sequence number. The sequence number space is 343 unique for each pairing of the SSRC of command source and the SSRC 344 of the command target. The sequence number SHALL be increased by 345 1 modulo 256 for each new command. 347 Reserved: 24 bits 349 All bits SHALL be set to 0 by the media source and SHALL be 350 ignored on reception. 352 5. SDP Signaling 354 A new feedback value "fss" needs to be defined for the Feedback Storm 355 Suppression message to be used with Session Description Protocol 356 (SDP)[RFC4566] using the Augmented Backus-Naur Form (ABNF)[RFC4585]. 358 The "fss" feedback value SHOULD be used with parameters that indicate 359 the feedback suppression supported. In this document, we define two 360 such parameters, namely: 362 o "fsei" denotes support of fir suppression early indication (fsei). 364 o "nsei" denotes support of NACK suppression early indication. 366 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 367 placeholder called rtcp-fb-id to define new feedback types. "fss" is 368 defined as a new feedback type in this document, and the ABNF for the 369 parameters for fss is defined here (please refer to section 4.2 of 370 [RFC4585] for complete ABNF syntax). 372 rtcp-fb-val =/ "fss" rtcp-fb-fss-param 373 rtcp-fb-fss-param = SP "nsei";nack suppression early indication 374 / SP "fsei";fir suppression early indication 375 / SP token [SP byte-string] 376 ; for future commands/indications 377 byte-string = 379 Refer to Section 4.2 of [RFC4585] for a detailed description and the 380 full syntax of the "rtcp-fb" attribute. 382 6. Example Use Cases 384 The operation of feedback suppression is similar for all types of RTP 385 sessions and topologies [RFC5117], however the exact messages used 386 and the scenarios in which suppression is employed differ for various 387 use cases. The following sections outline the intended use cases for 388 feedback suppression and give an overview of the particular 389 mechanisms. 391 6.1. Source Specific Multicast (SSM) use case 393 In SSM RTP sessions as described in [RFC5760], one or more Media 394 Sources send RTP packets to a Distribution Source. The Distribution 395 Source relays the RTP packets to the receivers using a source- 396 specific multicast group. 398 In order to avoid the forms of NACK implosion described in section 1, 399 the Loss Detector is introduced. The Loss Detector detects and 400 reports packet loss, on both the upstream link and the downstream 401 aggregate link. How the loss detector SHOULD detect the packet loss 402 is beyond of scope of this document. When upstream link or 403 downstream aggregate link packet loss occurs, the Loss Detector MAY 404 inform distribution source of the detected packet loss using Feedback 405 Suppression messages. In response, the distribution source either 406 forwards packet loss suppression report received from Loss Detector 407 or creates a Feedback Suppression report and sends it to all the RTP 408 receivers, over the multicast channel. This loss suppression report 409 tells the receivers that the lost packet will either be forthcoming 410 from distribution source, or it irretrievably lost such that there is 411 nothing to be gained by the receiver sending a NACK to the media 412 source. The distribution source then can (optionally) ask for the 413 lost packets from the media source on behalf of all the RTP 414 receivers. 416 When the Loss Detector(s) are part of a feedback target collocated 417 with the distribution source, redistribution of the feedback 418 suppression report is trivial. In such cases, the Loss Detector 419 function in the feedback target detects packet loss coming from an 420 upstream link and informs the collocated distribution source. Also 421 the Loss Detector may detect packet loss occurring within 422 distribution source itself and report to distribution source using 423 the same method. When the Loss Detector(s) are physically and(or) 424 topologically distinct from distribution source, each Loss Detector 425 MUST create a packet loss report using the similar format as 426 conventional RTCP NACK packets at the RTP layer and send it to the 427 distribution source . 429 The distribution source must be able to communicate with all group 430 members in order for either mechanism to be effective at suppressing 431 feedback. The general architecture is displayed below in Figure 1. 433 The distribution Source must be able to communicate with all group 434 members in order for either mechanism to be effective at suppressing 435 feedback. The general architecture is displayed below in Figure 3 437 +--------+ +------------+ Source-specific 438 |Media | | | Multicast 439 |Source 1|<------->| | +----------------> R(1) 440 +--------+ |Distribution| | 441 | SOURCE | +--+ 442 +--------+ | | | | 443 |Media |<------->| | | +-----------> R(2) 444 |Source 2| | Feedback |->+ +---- : 445 +--------+ |+ Target --+| | +------> R(n-1) 446 : || +---+ || | | 447 : || | D| || +--+--> R(n) 448 || | E| || 449 +--------+ || |L T| || 450 |Media | || |O E| || 451 |Source M|<---- -->|| |S C| || 452 +--------+ || |S T| || 453 || | O| || 454 || | R| || 455 || +---+ || 456 |+----------+| 457 +------------+ 458 Transport of packet loss informationfrom the Loss Detector to the 459 Feedback Target is via unicast RTCP feedback if the two are not 460 co-located. 462 Figure 3: System Architecture 464 In this figure, we assume the distribution source is separated from a 465 particular media source and the Loss Detector is part of feedback 466 target collocated with Distribution source. The communication 467 between the media source and the distribution source is compliant 468 with the methods described in [RFC5760]. Configuration information 469 also follows [RFC5760], with the following additional considerations: 471 o The Loss Detectors know the addresses of their respectively 472 responsible Feedback Targets. 474 As outlined in the [RFC5760], there are two Unicast Feedback models 475 that may be used for reporting, - the Simple Feedback model and the 476 Distribution Source Feedback Summary Model. The RTCP Feedback 477 Suppression report extension specified in the section 4 of this 478 document will work in both Feedback models. Details of operation in 479 each are specified below. 481 6.1.1. Simple Feedback Model 483 In the simple Feedback Model, the Loss reporter instance(s)are 484 distributed into two different distribution sources. e.g., upstream 485 distribution source may act as the loss detector of downstream of 486 distribution source. 488 The Loss Detector MUST listen on the corresponding RTP session for 489 data. When the Loss Detector observes that a sequence of RTP packets 490 from a media source contains gaps (by checking the sequence number of 491 packets), the Loss Detector MUST use the same packet types as 492 traditional RTCP feedback described in [RFC3550] and create one new 493 RTCP Feedback Report with information on the RTP sequence number of 494 the lost packets and suppression early indication event. When the 495 Loss Detector is eligible to transmit, it MUST send this Report 496 packet to the distribution source via feedback. 498 The Distribution Source (unicast Feedback Target) MUST listen for 499 RTCP data sent to the RTCP port. Upon receiving the RTCP Feedback 500 Report packet from the Loss Detector, the Distribution Source MUST 501 forward it to the group on the multicast RTCP session. Every RTCP 502 packet from each Loss Detector MUST be reflected individually. 504 If there are multiple Loss Detectors looking at the same RTP stream, 505 then the loss may be identified by more than one and those detecting 506 the loss will all send requests for the same packet loss. In this 507 case, the distribution source MUST filter the duplicated packet loss 508 request out and only forward one copy of the RTCP Feedback report 509 packet from the first Loss Detector to the group impacted by packet 510 loss. 512 This RTCP Feedback Report lets the receivers know that feedback for 513 this packet loss is not needed and SHOULD NOT be sent to the media 514 source(s). If the media source(s) are part of the SSM group for RTCP 515 packet reflection, the Distribution Source MUST filter this packet 516 out. If the media source(s) are not part of the SSM group for RTCP 517 packets, the Distribution Source MUST not forward this RTCP packets 518 received from the receivers to the media source(s). 520 When the receiver receives the RTCP packet, if the receiver 521 understands the message it will not send feedback (e.g., NACK) for 522 the missing packets reported in the message and will accept a 523 retransmission packet (if forthcoming) transmitted from the 524 Distribution Source. If it did not understand the Feedback 525 Suppression report the receiver MAY of course still send feedback 526 messages to the specified media source. When the distribution source 527 receives a feedback message reporting loss from one or more receivers 528 after it has already detected packet loss or gotten a NACK feedback 529 message from Loss Detector, the distribution source MUST filter them 530 out until proactive recovery is complete. 532 6.1.2. Distribution Source Feedback Summary Model 534 In the distribution source feedback summary model, the Loss Detector 535 instances may be distributed into different distribution sources. In 536 some cases, several Loss Detector instances for the same session can 537 exist at the same time, e.g., one Loss Detector instance (Loss 538 Detector A) is implemented in the upstream distribution source A, one 539 Loss Detector instance (Loss Detector B) is implemented in the 540 upstream distribution source B, another Loss Detector instance for 541 the same session (Loss Detector C) is part of feedback target within 542 the distribution source C. In this section, we focus on this generic 543 case to discuss the distribution Source Feedback Summary Model. 545 The Loss Detector A and the Loss Detector B MUST listen on the RTP 546 channel for data. When the Loss Detector observes RTP packets from a 547 media source are not consecutive by checking the sequence number of 548 packets, the Loss Detector generates NACK message described 549 in[RFC4585] or generates the new RTCP Feedback Report packet 550 described in the section 6, and then send either of them to the 551 distribution source via feedback. 553 The Distribution Source (unicast Feedback Target) MUST listen for 554 unicast RTCP data sent to the RTCP port. Upon receiving the unicast 555 RTCP Feedback Report packet from the Loss Detector, the distribution 556 source needs to filter them out, i.e., identify these unicast RTCP 557 packets coming from the Dedicated receivers (i.e.,Loss Detector A and 558 Loss Detector B)based on the IP address of Loss Detectors or 559 dedicated RTCP port for loss report, then summarize the information 560 received from all the RTCP Feedback Reports generated by the 561 Dedicated receivers together with the information generated by the 562 Loss Detector integrated in the feedback target and then create the 563 summary report to include all these information. In order to reduce 564 the processing load at the distribution source, the individual 565 instance of Loss Detector MAY provide preliminary summarization 566 report. 568 During the summary report creating, the Distribution Source MUST use 569 its own SSRC value for transmitting summarization information and 570 MUST perform proper SSRC collision detection and resolution. 572 In some case, the distribution source MAY receive RTCP NACK messages 573 from the receivers behind the Distribution Source before the 574 distribution source detects the packet loss which may cause potential 575 Feedback implosion. In such case, the distribution source MAY filter 576 them out if it already sent a packet loss request for the missing 577 packet to the media source. When the distribution source confirms 578 packet loss reported by the receiver, the distribution source 579 generates the summary report to include the packet loss information 580 from the corresponding receiver (e.g., upstream Loss Detector). 582 The distribution source MAY send this new RTCP summary report 583 described in the section 6 to the group on the multicast RTCP channel 584 and in the meanwhile sending a packet loss request to the media 585 source. 587 If there are a couple of loss reporters looking at the same RTP 588 stream, then the loss may be identified by all and they will all send 589 requests for the same packet loss. In this case, the distribution 590 source MUST filter out the duplicated information from various Loss 591 Detectors and only append one copy of such information to the summary 592 report. 594 When the host receives the RTCP packet, if the host understands this 595 message it will not send packet loss request (e.g., NACK) for the 596 missing packets reported in the message. If it did not understand 597 this new message, the host MAY send packet loss request(e.g., NACK 598 messages) to the specified media source. When the distribution 599 source receives the packet loss request from the hosts after it has 600 already detected packet loss, the distribution source MUST filter it 601 out until proactive recovery is complete. 603 6.2. RTP transport translator use case 605 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 606 is typically forwarding the RTP and RTCP traffic between RTP clients, 607 for example converting between multicast and unicast for domains that 608 do not support multicast. The translator can identify packet loss 609 from the upstream and send the Feedback Suppression message to the 610 unicast receivers. The translator can also serve as a loss reporter 611 on the multicast side as described in the SSM case. 613 6.3. Multipoint Control Unit (MCU) use case 615 In point to multipoint topologies using video switching MCU (Topo- 616 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 617 media stream to each participant, selected from the available input 618 streams. The selection of the input stream is often based on voice 619 activity in the audio-visual conference, but other conference 620 management mechanisms (like presentation mode or explicit floor 621 control) exist as well. 623 In this case the MCU MAY detect packet loss from the sender or may 624 decide to switch to a new source. In both cases the receiver MAY 625 lose synchronization with the video stream and MAY send a FIR 626 request. If the MCU itself can detect the mis-synchronization of the 627 video, the MCU can send the FIR suppression message to the receivers 628 and send a FIR request to the video source. 630 7. Security Considerations 632 The defined messages have certain properties that have security 633 implications. These must be addressed and taken into account by 634 users of this protocol. 636 Spoofed or maliciously created feedback messages of the type defined 637 in this specification can have the following implications: 639 Sending NACK Suppression Report with wrong sequence number of lost 640 packet that makes missing RTP packets can not be compensated. 642 Sending FIR Suppression Report with wrong sequence number of lost 643 packet that makes missing RTP packets can not be compensated by 644 update request mechanism. 646 To prevent these attacks, there is a need to apply authentication and 647 integrity protection of the feedback messages. This can be 648 accomplished against threats external to the current RTP session 649 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 650 into SAVPF [RFC5124]. 652 Note that middleboxes that are not visible at the RTP layer that wish 653 to send NACK/FIR suppression reports on behalf of the media source 654 can only do so if they spoof the SSRC of the media source. This is 655 difficult in case SRTP is in use. If the middlebox is visible at the 656 RTP layer, this is not an issue, provided the middlebox is part of 657 the security context for the session. 659 Also note that endpoints that receive a NACK/FIR suppression request 660 would be well-advised to ignore it, unless it is authenticated via 661 SRTCP or similar. Accepting un-authenticated NACK/ FIR suppression 662 requests can lead to a denial of service attack, where the endpoint 663 accepts poor quality media that could be repaired. 665 8. IANA Consideration 667 New feedback type and New parameters for RTCP FSS receiver feedback 668 report are subject to IANA registration. For general guidelines on 669 IANA considerations for RTCP feedback, refer to [RFC4585]. 671 This document assigns one new feedback type value x in the RTCP 672 feedback report registry to "Feedback Storm Suppression" with the 673 following registrations format: 675 Name: FSS 676 Long Name: Feedback Storm Suppression 677 Value: TBD 678 Reference: This document. 680 This document also assigns the parameter value y in the RTCP FSS 681 feedback report Registry to "NACK Suppression Early Indication ", 682 with the following registrations format: 684 Name: NSEI 685 Long name: NACK Suppression Early Indication 686 Value: TBD 687 Reference: this document. 689 This document also assigns the parameter value z in the RTCP FSS 690 feedback report Registry to "FIR Suppression Early Indication ", with 691 the following registrations format: 693 Name: FSEI 694 Long name: FIR Suppression Early Indication 695 Value: TBD 696 Reference: this document. 698 The contact information for the registrations is: 700 Qin Wu 701 sunseawq@huawei.com 702 101 Software Avenue, Yuhua District 703 Nanjing, Jiangsu 210012, China 705 9. Acknowledgement 707 The authors would like to thank David R Oran, Ali C. Begen, Colin 708 Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, WeeSan 709 Lee for their valuable comments and suggestions on this document. 711 10. References 713 10.1. Normative References 715 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 716 Protocol (RTCP) Extensions for Single-Source Multicast 717 Sessions with Unicast Feedback", RFC 5760, February 2010. 719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 720 Requirement Levels", BCP 14, RFC 2119, March 1997. 722 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 723 "Extended RTP Profile for Real-time Transport Control 724 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 725 July 2006. 727 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 728 Jacobson, "RTP: A Transport Protocol for Real-Time 729 Applications", STD 64, RFC 3550, July 2003. 731 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 732 January 2008. 734 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 735 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 736 July 2006. 738 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 739 Description Protocol", RFC 4566, July 2006. 741 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 742 Specifications: ABNF", STD 68, RFC 5234, January 2008. 744 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 745 "Codec Control Messages in the RTP Audio-Visual Profile 746 with Feedback (AVPF)", RFC 5104, February 2008. 748 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 749 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 750 RFC 3711, March 2004. 752 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 753 Real-time Transport Control Protocol (RTCP)-Based Feedback 754 (RTP/SAVPF)", RFC 5124, February 2008. 756 10.2. Informative References 758 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 759 "NACK-Oriented Reliable Multicast (NORM) Transport 760 Protocol", November 2009. 762 [DVB-IPTV] 763 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 764 of MPEG-2 TS Based DVB Services over IP Based Networks", 765 ETSI TS 102 034, V1.4.1 , August 2009. 767 [I-D.hunt-avt-monarch-01] 768 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 769 August 2008. 771 [I-D.ietf-pmol-metrics-framework-02] 772 Clark, A., "Framework for Performance Metric Development". 774 Appendix A. Example scenarios for NACK Implosion 776 In SSM RTP sessions as described in [RFC5760], there may have more 777 than one distribution source between the media source and the 778 receivers. In order for loss repair, the distribution source may 779 choose to include the support for retransmission as part of the 780 offered SDP and will expect such support from the media source.The 781 following section outline several example scenarios for NACK 782 Implosion. 784 A.1. Scenario 1: One or more media source, One distribution source 786 The scenario 1 is displayed below in Figure 4. In this scenario, one 787 or more Media Sources send RTP packets to the RTP Receivers through 788 the same Distribution Source. The Distribution Source relays the RTP 789 packets to the receivers using a source-specific multicast channel. 790 In the reverse direction, the receivers transmit RTCP packets via 791 unicast to the distribution source. The Distribution Source in turn 792 relays RTCP packets to the media souce and then transmits the RTCP 793 packets back to the receivers, using source-specific multicast. 795 +-------+ 796 |---->|RTP_Rx1| 797 +--------+ | +-------+ 798 | | +--------------+ | 799 | | | | | +-------+ 800 | Media |-------| Distribution |-------|---->|RTP_Rx2| 801 | | | Source | | +-------+ 802 | Source | | | | . 803 | | +--------------+ | . 804 | | | . 805 +--------+ | +-------+ 806 |---->|RTP_Rxn| 807 +-------+ 809 Figure 4: One media Source, one Distribution Source 811 A.2. Scenario 2:One media source, Two distribution sources in cascade 813 +-------+ 814 |---->|RTP_Rx1| 815 | +-------+ 816 +------+ | 817 | | +------------+ +------------+ | +-------+ 818 |Media |-+Distribution+--|Distribution+--|---->|RTP_Rx2| 819 |Source| | Source1 | | Source2 | | +-------+ 820 | | +------------+ +------------+ | . 821 +------+ | . 822 | . 823 | +-------+ 824 |---->|RTP_Rxn| 825 +-------+ 827 Figure 5: One media source, Two distribution sources in cascade 829 The scenario 2 is displayed below in Figure 5. In this scenario, One 830 media source passes through two distribution source in cascading and 831 sends RTP packets to all the RTP receivers. In this case, the 832 distribution source 2 is located in the downstream direction of 833 distribution source 1. 835 A.3. Scenario 3:One media source, Two distribution sources in parallel 837 The scenario 3 is displayed below in Figure 6. In this scenario, the 838 Media Sources send RTP packets to all the RTP receivers through two 839 different path respectively. In each path, there is a distribution 840 source. The distribution source1 is a neighboring node of 841 distribution source 2. 843 +--------+ 844 |---->|RTP_Rx11| 845 | +--------+ 846 +--------------+ | 847 | | | +--------+ 848 |--->| Distribution |----|---->|RTP_Rx12| 849 | | Source1 | | +--------+ 850 | | | | . 851 +--------+ | +--------------+ | . 852 | | | | . 853 | | | | +--------+ 854 | Media | | |---->|RTP_Rx1k| 855 | |---| +--------+ 856 | Source | | +--------+ 857 | | | |---->|RTP_Rx21| 858 | | | | +--------+ 859 +--------+ | +--------------+ | 860 | | | | +--------+ 861 | | Distribution |----|---->|RTP_Rx22| 862 |--->| Source2 | | +--------+ 863 | | | . 864 +--------------+ | . 865 | . 866 | +--------+ 867 |---->|RTP_Rx2j| 868 +--------+ 870 Figure 6: One Media Source, more distribution sources 872 Appendix B. Applicability of Feedback Suppression 874 This document defines new RTCP feedback Report, which we refer to as 875 Feedback Suppression to deal with NACK Implosion mentioned above. 876 Here we give two examples to show how this new RTCP feedback report 877 is applied into three scenarios described in Appendix A. 879 Applicability of Feedback Suppression in Scenario 1 described in 880 Figure 4 is shown in the Figure 7. In this figure, the distribution 881 source detect the packet loss before the receiver perceive it and ask 882 for retransmission of the lost packets from the media source on 883 behalf of all the RTP receivers. , in the meanwhile, the distribution 884 source transmits the RTCP Feedback Suppression Indication back to the 885 receivers using source-specific multicast channel. Upon receiving 886 the lost packet via the RTP retransmission payload format, the 887 distribution source forwards the retransmitted packet to all the 888 receivers. The receiver will accept a retransmission stream 889 transmitted from the Distrbituion Source. 891 When the distribution source receives a feedback message reporting 892 loss from one or more receivers after it has already detected packet 893 loss, the distribution source MUST filter them out until the 894 Retransmission stream is ready in the Distrbitution Source. In this 895 way, the delay for the receiver to recover from the packet loss can 896 be reduced and the risk of increasing network congestion can be 897 mitigated. 899 +------+ +--------------+ +--------+ 900 |Media | | Distribution | | | 901 |Source| | Source | | RTP_Rx | 902 +--+---+ +------+-------+ +---+----+ 903 | | | 904 | | | 905 |------------------->|------RTP Multicast---->| 906 | | | 907 | | | 908 | +--------+----------+ | 909 | |Detect Packet Loss | | 910 | |and Identify the SN| | 911 | |of missing Packets | | 912 | +--------+----------+ | 913 |<-----RTCP NACK-----| | 914 | | | 915 | +--Multicast RTCP FSS--->| 916 | RTP Retransmission | | 917 |------------------->| | 918 | |------RTP Multicast---->| 919 | | Retransmission | 920 | | | 921 | | | 922 | | | 924 Figure 7: Applicability of NACK Suppression Early Indication 926 Applicability of Feedback Suppression in Scenario 2 or 3 described in 927 Figure 5 and Figure 6 is shown in the Figure 8. The procedure in the 928 Figure 8 is similar to the one in the figure Figure 7. The only 929 difference is distribution source should not only notify all the 930 receiver behind itself not to send NACK but also propagate the 931 retransmission suppression indication to the neighboring distribution 932 sources. In this way, all the receivers behind all the neighboring 933 distribution source can avoid sending massive retransmission request 934 to the media source. 936 +------+ +--------+ +--------+ 937 |Media | +-----+ | RTP_Rx | +-----+ | RTP_Rx | 938 |Source| | DS1 | | served | | DS2 | | served | 939 +--+---+ +-----+ | by DS1 | +-----+ | by DS2 | 940 | | ----+----+ | ----+----+ 941 | |RTP Multicast | | | 942 |----------->|------------->| | | 943 | | | | | 944 | | | |RTP Multicast| 945 |------------------------------------------->|------------>| 946 | | | | | 947 | +--------+------------+ | | | 948 | |Detect Packet Loss | | | | 949 | |and Identify the SN | | | | 950 | |of the missing Packets | | | 951 | +--------+------------+ | | | 952 | | | | | 953 |<-RTCP NACK-| Multicast RTCP FSS | | 954 | |------------->| | | 955 | | | | | 956 | |-----Unicast RTCP FSS -------->|Multicast RTCP FSS 957 | | | |------------>| 958 |RTP Retransmission | | | 959 |----------->| | | | 960 | | | | | 961 | | RTP Retransmission | | 962 |------------+--------------+--------------->| | 963 | | | | | 964 | | RTP Multicast| | RTP Multicast 965 | |Retransmission| |Retransmission 966 | |------------->| |------------>| 967 | | | | | 968 DS1: Distribution Source 1 969 DS2: Distribution Source 2 971 Figure 8: Applicability of NACK Suppression Early Indication 973 Authors' Addresses 975 Qin Wu 976 Huawei 977 101 Software Avenue, Yuhua District 978 Nanjing, Jiangsu 210012 979 China 981 Email: sunseawq@huawei.com 982 Frank Xia 983 Huawei 984 1700 Alma Dr. Suite 500 985 Plano, TX 75075 986 USA 988 Phone: +1 972-509-5599 989 Email: xiayangsong@huawei.com 991 Roni Even 992 Huawei 993 14 David Hamelech 994 Tel Aviv 64953 995 Israel 997 Email: even.roni@huawei.com