idnits 2.17.1 draft-wu-avt-retransmission-supression-rtp-03.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 unicast RTCP Feedback Report lets the receivers know that feedback for this packet loss is not needed and should not be sent to the media sender(s). If the Media Sender(s) are part of the SSM group for RTCP packet reflection, the Distribution Source MUST filter this packet out. If the Media Sender(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 Sender(s). == 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: If the loss reporter is part of group, the Distribution source MUST not send the summary report back to this loss reporter. == 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 9, 2010) is 4945 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: 'RFC3550' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'RFC4588' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 795, 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 (~~), 10 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 12, 2011 Huawei 6 October 9, 2010 8 RTCP Report Extension for Feedback Suppression 9 draft-wu-avt-retransmission-supression-rtp-03 11 Abstract 13 This document specifies an extension to the RTCP feedback messages 14 defined in the Audio-Visual Profile with Feedback (AVPF). This 15 extension allows an intermediate node in the network (such as an RTP 16 translator) inform downstream receivers that sending a feedback 17 message concerning a specified set of RTP messages may be 18 unnecessary, or even harmful. For example, in a source-specific 19 multicast session with large fan-out, packet loss close to the media 20 or distribution source of the session is detected as a loss by a 21 large number of receivers. The RTCP NACK messages used to request 22 retransmission of the missing packets are all addressed to the media 23 sender, or a designated feedback target. This may result in a 24 phenomenon known variously as a "NACK implosion" or "feedback storm". 25 The Feedback Suppression message defined herein is used to notify 26 receivers that packet loss was detected and that the sender of the 27 report will either proactively recover, or no recovery is possible. 28 Receivers respond to receipt of a feedback suppression message by not 29 sending a feedback message (e.g. a NACK) that they otherwise would, 30 This in turn reduces load on both the feedback target and on the 31 network. This document registers two new RTCP messages for Feedback 32 Suppression. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 82 4. RTCP Receiver Feedback Report Extension . . . . . . . . . . . 9 83 4.1. Transport Layer Feedback Message . . . . . . . . . . . . . 9 84 4.1.1. NACK implosion Suppression Summary report . . . . . . 9 85 4.2. Payload Specific Feedback Message . . . . . . . . . . . . 10 86 4.2.1. FIR implosion Suppression Summary report . . . . . . . 10 87 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 88 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 12 89 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 12 90 6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 12 91 6.1.2. Distribution Source Feedback Summary Model . . . . . . 14 92 6.2. RTP transport translator use case . . . . . . . . . . . . 15 93 6.3. Multipoint Control Unit (MCU) use case . . . . . . . . . . 15 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 95 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 96 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 100 Appendix A. Example scenarios for Retransmission Storm 101 Suppression . . . . . . . . . . . . . . . . . . . . . 19 102 A.1. Scenario 1: One or more media sender,One distribution 103 source . . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 A.2. Scenario 2:One media sender, Two distribution sources 105 in cascade . . . . . . . . . . . . . . . . . . . . . . . . 20 106 A.3. Scenario 3:One media sender, Two distribution sources 107 in parallel . . . . . . . . . . . . . . . . . . . . . . . 20 108 Appendix B. Applicability of Feedback Storm Suppression . . . . . 21 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 111 1. Introduction 113 RTCP feedback messages [RFC4585]allow the receivers in an RTP session 114 to report events and ask for action from the sender (or a delegated 115 feedback target). There are cases where multiple receivers may 116 initiate the same, or an equivalent message towards the same sender. 117 When the receiver count is large, this behavior may overload the 118 sender or the network or both. One common case is receivers 119 utilizing RTP retransmission as a packet loss recovery technique in a 120 real-time application such as streaming video or 121 audio.[RFC4588]Feedback is accomplished using the RTCP NACK message 122 which conveys the RTP sequence number(s) of the lost packet(s). This 123 information can then be used by the sender to retransmit the missing 124 RTP packets using the RTP retransmission payload format[RFC4585]. 126 However, in topologies utilizing transport translators (Topo-Trn- 127 Translator) or large-scale multicast transmission (Topo-Multicast) as 128 defined in [RFC5117], packet loss can occur on either an upstream 129 link or a downstream aggregate link of the intermediate network 130 element (e.g., Retransmission server, Distribution Source). Where 131 there are many receivers, this may result in a NACK implosion towards 132 the sender, i.e., large number of NACK requests to the same multicast 133 sender for retransmission of the same RTP packets. This phenomenon 134 goes by a number of alternate names, such as the "NACK storm" 135 terminology of [DVB-IPTV]. In an attempt to increase its robustness 136 against the loss of a NACK message or of retransmission packets, a 137 receiver may send multiple NACKs for the same detected packet loss, 138 which may aggravate the NACK 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 sender. 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 pose a substantial risk of increasing network congestion, and in 154 extreme cases to congestion collapse on the control channel (e.g. 155 RTCP feedback), the data channel (i.e. RTP restransmission), or 156 both. 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 sender to the 161 receiver. However NACK is defined as a receiver report sent from a 162 receiver to the sender and therefore exhibits a semantic mismatch 163 when used as a suppression indication from the sender (or 164 intermediary) to the receiver. This document instead specifies a 165 newly 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 The Feedback Suppression message asks a receiver to not send feedback 172 messages for particular packets (indicated by their RTP sequence 173 numbers) independent of whether the receiver detected the packet loss 174 or detected a need for a decoder refresh point). 176 In order to detect packet loss before the receivers perceive it, one 177 or more intermediate nodes are placed between the media sender and 178 receiver (e.g., Distribution server, MCU, RTP translator). These 179 intermediaries monitor for packet loss upstream of themselves by 180 checking RTP sequence numbers, just as receivers do. Upon detecting 181 (or suspecting) an upstream loss, the intermediary may either 182 initiate its own feedback toward the source to provoke a 183 retransmission, send Feedback Suppression message towards the 184 receivers as defined in this specification, or both. 186 Instead of using specialized intermediaries, another possibility is 187 to instantiate one or more RTP receivers upstream of the loss region 188 to act as immediate reporters as described in[DVB-IPTV]. These 189 intermediate nodes need to take into account such factors as the 190 tolerable application delay, the network dynamics, and the media 191 type. When the packet loss is detected upstream of the intermediary 192 and additional latency is tolerable, the intermediate node may itself 193 send a feedback message asking for retransmission of the suspected 194 lost packet or ask for the correct decoder refresh point. Because it 195 has already provided the necessary feedback toward the source, the 196 intermediate node can be reasonably certain that it will help the 197 situation by sending a Feedback Suppression message to all the 198 relevant receivers, thereby indicating that the receivers should not 199 themselves transmit feedback messages. When the sender receives the 200 request from the intermediate node, the sender resends the missing 201 packets to the receivers by using the RTP retransmission payload 202 format [RFC4588]or resends a new refresh point for FIR Initiator 203 [RFC5104], depending on the type of feedback it received. 205 RTCP Feedback Storm Suppression follows the same semantic model as 206 RTCP NACK - it conveys the packet receipt/loss events at the sequence 207 number level and considers missing packets as unrepaired. But unlike 208 RTCP NACK, the Feedback Suppression messages can be generated at 209 intermediate nodes who are not RTP receivers and sent to the 210 corresponding receivers. Intermediaries downsteam of an intermediary 211 detecting loss obviously SHOULD NOT initiate their own additional 212 feedback suppression messages for the same packet sequence numbers. 213 They may either simply forward the Feedback Suppression message 214 received from upstream, or augment (or replace) it with a feedback 215 suppression message that reflects the loss pattern they have 216 themselves seen. 218 Since feedback suppression interacts strongly with repair timing, it 219 has to work together with feedback and retransmission to not 220 adversely impact the repair of lost source packets. In some cases 221 where the loss was detected and repair initiated much closer to the 222 source, the delay for the receiver to recover from packet loss can be 223 reduced through the combination of intermediary feedback to the 224 source and feedback suppression downstream. In all (properly 225 operating) cases, the risk of increasing network congestion is 226 decreased. A receiver may still have sent a Feedback message before 227 receiving a feedback suppression message, but further feedback 228 messages for those sequence numbers will be suppressed by this 229 technique. 231 This document registers two new RTCP Feedback messages for Feedback 232 Suppression. Applications that are employing one or more loss-repair 233 methods MAY use Feedback Suppression together with their existing 234 loss-repair methods either for every packet they expect to receive, 235 or for an application-specific subset of the RTP packets in a 236 session. In other words, receivers MAY ignore Feedback Suppression 237 messages, but SHOULD react to them unless they have good reason to 238 still send feedback messages despite having been requested to 239 suppress them. 241 2. Terminology 243 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119]. 247 Intermediate Source: 249 One intermediate node with logical function which is used to 250 process or foward packet at the RTP layer. The intermediate 251 Source is located between media sender and receivers. The 252 examples of intermediate source are Distribution server, MCU, RTP 253 translator. 255 Upstream RTP Client: 257 An RTP Client located in the upstream from the intermediate source 258 as described in [DVB-IPTV]. This Client is able to detect 259 upstream packet loss impacting all the RTP receivers serviced by 260 the intermediate source and receiving SSM service. 262 Immediate reporting RTP Client: 264 An RTP Client located on a downstream aggregate link from the 265 intermediate source as described in [DVB-IPTV]. This Client is 266 able to detect downstream packet loss on the aggregate link or 267 other nodes upstream of the aggregat link, thus impacting all the 268 RTP receivers serviced by the intermediate source and receiving 269 SSM service. 271 Loss Reporter: 273 The Loss Reporter is one logical function which is used to detect 274 the packet loss at the RTP layer and report it to the intermediate 275 source. The function of the loss reporter may be collocated with 276 or integrated into the same entity. In this case, for a session 277 defined as having a intermediate source A, on ports n for the RTP 278 channel and k for the RTCP channel, the unicast RTCP Feedback 279 Target is identified by an IP address of intermediate source A on 280 port k. The loss reporter MAY also be implemented in one or more 281 entities different from the intermediate source. In this case, 282 the loss reporter may be an upstream RTP client or immediate 283 reporting RTP client located on a downstream aggregate link of the 284 intermediate source. 286 3. Protocol Overview 288 In order to avoid the forms of NACK implosion described in section 1, 289 the loss reporter is introduced. The loss reporter detects and 290 reports packet loss, on both the upstream link and the downstream 291 aggregate link. When upstream link or downstream aggregate link 292 packet loss occurs, the Loss reporter may inform intermediate source 293 of the detected packet loss using Feedback Suppression messages. In 294 response, the intermediate source either forwards packet loss 295 suppression report received from loss reporter or creates a Feedback 296 Suppression report and sends it to all the RTP receivers, over the 297 multicast channel. This loss suppression report tells the receivers 298 that the lost packet will either be forthcoming from intermediate 299 source via retransmission, or it irretrievably lost such that there 300 is nothing to be gained by the receiver sending a NACK to the media 301 sender. The intermediate source then can (optionally) ask for 302 retransmission of the lost packets from the media sender on behalf of 303 all the RTP receivers. Upon receiving the lost packet via the RTP 304 retransmission payload format, the intermediate source forwards the 305 retransmitted packet to all the receivers. 307 When the loss reporter(s) are part of a feedback target collocated 308 with the intermediate source, redistribution of the feedback 309 suppression report is trivial. In such cases, the loss reporter 310 function in the feedback target detects packet loss coming from an 311 upstream link and informs the collocated intermediate source. Also 312 the loss reporter may detect packet loss occurring within 313 intermediate source itself and report to intermediate source using 314 the same method. When the loss reporter(s) are physically and(or) 315 topologically distinct from intermediate source, each loss reporter 316 MUST create a packet loss report using the similar format as 317 conventional RTCP NACK packets at the RTP layer and send it to the 318 intermediate source . The loss reporters may be upstream client or 319 downstream immediate reporter who is dedicated to detect and report 320 packet loss. 322 The intermediate source must be able to communicate with all group 323 members in order for either mechanism to be effective at suppressing 324 feedback. The general architecture is displayed below in Figure 1. 326 The Intermediate Source must be able to communicate with all group 327 members in order for either mechanism to be effective at suppressing 328 feedback. The general architecture is displayed below in Figure 1 329 +--------+ +------------+ Source-specific 330 |Media | | | Multicast 331 |Sender 1|<------->| | +----------------> R(1) 332 +--------+ |Intermediate| | 333 | SOURCE | +--+ 334 +--------+ | | | | 335 |Media |<------->| | | +-----------> R(2) 336 |Sender 2| | Feedback |->+ +---- : 337 +--------+ |+ Target --+| | +------> R(n-1) 338 : || +---+ || | | 339 : || | R| || +--+--> R(n) 340 || | E| || 341 +--------+ || |L P| || 342 |Media | || |O O| || 343 |Sender M|<---- -->|| |S R| || 344 +--------+ || |S T| || 345 || | E| || 346 || | R| || 347 || +---+ || 348 |+----------+| 349 +------------+ 350 Transport of packet loss informationfrom the Loss Reporter to the 351 Feedback Target is via unicast RTCP feedback if the two are not 352 co-located. 354 Figure 1: System Architecture 356 In this figure, we assume the intermediate source is separated from a 357 particular media sender and the loss reporter is part of feedback 358 target collocated with intermediate source. The communication 359 between the media sender and the intermediate source is compliant 360 with the methods described in [RFC5760]. Configuration information 361 also follows [RFC5760], with the following additional considerations: 363 o The Loss Reporters know the addresses of their respectively 364 responsible Feedback Targets. 366 4. RTCP Receiver Feedback Report Extension 368 4.1. Transport Layer Feedback Message 370 4.1.1. NACK implosion Suppression Summary report 372 The NACK implosion Suppression message is an extension to the RTCP 373 feedback report and identified by RTCP packet type value PT=RTPFB and 374 FMT=TBD. 376 The FCI field MUST contain one or more NACK Suppression Early 377 Indication (NSEI) entries. Each entry applies to a different media 378 sender, identified by its SSRC. 380 The Feedback Control Information (FCI) for NSEI uses the similar 381 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 382 The format is shown in Figure 2. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | SSRC | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | PID | BLP | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 2: Message Format for the NSEI report 394 SSRC (32 bits): 396 The SSRC value of the media sender that is requested to send the 397 lost packet. 399 Packet ID (PID): 16 bits 401 The PID field is used to specify a lost packet. The PID field 402 refers to the RTP sequence number of the lost packet. 404 bitmask of following lost packets (BLP): 16 bits 406 The BLP allows for reporting losses of any of the 16 RTP packets 407 immediately following the RTP packet indicated by the PID. The 408 BLP's definition is identical to that given in [RFC4585]. 410 4.2. Payload Specific Feedback Message 412 4.2.1. FIR implosion Suppression Summary report 414 The FIR implosion Suppression message is an extension to the RTCP 415 receiver feedback report and identified by RTCP packet type value 416 PT=PSFB and FMT=TBD. 418 The FCI field MUST contain one or more FIR suppression Early 419 Indication (FSEI) entries. Each entry applies to a different media 420 sender, identified by its SSRC. 422 The Feedback Control Information (FCI) for FSEI uses the similar 423 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 424 The format is shown in Figure 3. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | SSRC | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Seq nr. | Reserved | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 3: Message Format for the FSEI report 436 SSRC (32 bits): 438 The SSRC value of the media sender that is requested to send a 439 decoder refresh point. 441 Seq nr:8bits Command sequence number. The sequence number space is 442 unique for each pairing of the SSRC of command source and the SSRC 443 of the command target. The sequence number SHALL be increased by 444 1 modulo 256 for each new command. 446 Reserved: 24 bits 448 All bits SHALL be set to 0 by the sender and SHALL be ignored on 449 reception. 451 5. SDP Signaling 453 A new feedback value "fss" needs to be defined for the Feedback Storm 454 Suppression message to be used with Session Description Protocol 455 (SDP)[RFC4566] using the Augmented Backus-Naur Form (ABNF)[RFC4585]. 457 The "fss" feedback value SHOULD be used with parameters that indicate 458 the feedback suppression supported. In this document, we define two 459 such parameters, namely: 461 o "fsei" denotes support of fir suppression early indication (fsei). 463 o "nsei" denotes support of NACK suppression early indication. 465 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 466 placeholder called rtcp-fb-id to define new feedback types. "fss" is 467 defined as a new feedback type in this document, and the ABNF for the 468 parameters for fss is defined here (please refer to section 4.2 of 470 [RFC4585] for complete ABNF syntax). 472 rtcp-fb-val =/ "fss" rtcp-fb-fss-param 473 rtcp-fb-fss-param = SP "nsei";nack suppression early indication 474 / SP "fsei";fir suppression early indication 475 / SP token [SP byte-string] 476 ; for future commands/indications 477 byte-string = 479 Refer to Section 4.2 of [RFC4585] for a detailed description and the 480 full syntax of the "rtcp-fb" attribute. 482 6. Example Use Cases 484 The operation of feedback suppression is similar for all types of RTP 485 sessions and topologies [RFC5117], however the exact messages used 486 and the scenarios in which suppression is employed differ for various 487 use cases. The following sections outline the intended use cases for 488 feedback suppression and give an overview of the particular 489 mechanisms. 491 6.1. Source Specific Multicast (SSM) use case 493 In SSM RTP sessions as described in [RFC5760], one or more Media 494 Senders send RTP packets to a Distribution Source. The Distribution 495 Source relays the RTP packets to the receivers using a source- 496 specific multicast group. 498 As outlined in the [RFC5760], there are two Unicast Feedback models 499 that may be used for reporting, - the Simple Feedback model and the 500 Distribution Source Feedback Summary Model. The RTCP Feedback 501 Suppression report extension specified in the section 4 of this 502 document will work in both Feedback models. Details of operation in 503 each are specified below. 505 6.1.1. Simple Feedback Model 507 In the simple Feedback Model, the Loss reporter(s) are disjoint from 508 the distribution source. In this case, an upstream client or 509 immediate reporting receiver may be chosen as the loss reporter. 510 Also in this model, the distribution source includes support for 511 retransmission as part of the offered SDP and expects such support 512 from the Media Sender. 514 As one dedicated receiver for packet loss reporting, the Loss 515 reporter MUST listen on the corresponding RTP session for data. When 516 the Loss reporter observes that a sequence of RTP packets from a 517 Media Sender contains gaps (by checking the sequence number of 518 packets), the Loss reporter MUST use the same packet types as 519 traditional RTCP feedback described in[RFC3550]and create one new 520 RTCP Feedback Report with information on the RTP sequence number of 521 the lost packets and suppression early indication event. When a 522 receiver is eligible to transmit, it MUST send this Report packet to 523 the distribution source via unicast feedback. 525 The Distribution Source (unicast Feedback Target) MUST listen for 526 unicast RTCP data sent to the RTCP port. Upon receiving the unicast 527 RTCP Feedback Report packet from the loss reporter, the Distribution 528 Source MUST forward it to the group on the multicast RTCP session. 529 Every RTCP packet from each Loss reporter MUST be reflected 530 individually. If the loss reporter is part of group, the 531 Distribution source MUST filter this packet out and not forward it 532 back to this loss reporter. 534 If there are multiple loss reporters looking at the same RTP stream, 535 then the loss may be identified by more than one and those detecting 536 the loss will all send requests for the same packet loss. In this 537 case, the distribution source MUST filter the duplicated packet loss 538 request out and only forward one copy of the RTCP Feedback report 539 packet from the first loss reporter to the group impacted by packet 540 loss. 542 This unicast RTCP Feedback Report lets the receivers know that 543 feedback for this packet loss is not needed and should not be sent to 544 the media sender(s). If the Media Sender(s) are part of the SSM 545 group for RTCP packet reflection, the Distribution Source MUST filter 546 this packet out. If the Media Sender(s) are not part of the SSM 547 group for RTCP packets, the Distribution Source MUST not forward this 548 RTCP packets received from the receivers to the Media Sender(s). 550 When the receiver receives the RTCP packet, if the receiver 551 understands the message it will not send feedback (e.g., NACK) for 552 the missing packets reported in the message and will accept a 553 retransmission packet (if forthcoming) transmitted from the 554 Distribution Source. If it did not understand the Feedback 555 Suppression report the receiver may of course still send feedback 556 messages to the specified media sender. When the distribution source 557 receives a feedback message reporting loss from one or more receivers 558 after it has already detected packet loss or gotten a NACK feedback 559 message from loss reporter, the distribution source MUST filter them 560 out until the Retransmission stream is ready in the Distribution 561 Source. 563 6.1.2. Distribution Source Feedback Summary Model 565 In the distribution source feedback summary model, the distribution 566 source will include the support for retransmission as part of the 567 offered SDP and will expect such support from the Media Sender, also 568 the Loss reporter instance may be integrated in the distribution 569 source or may be separated from the distribution source. In some 570 cases, several loss reporter instances for the same session can exist 571 at the same time, e.g., one loss reporter instance (loss reporter A) 572 is implemented in the upstream client A, one loss reporter instance 573 (loss reporter B) is implemented in the upstream client B, another 574 loss reporter instance for the same session (loss reporter C) is part 575 of feedback target within the distribution source. In this section, 576 we focus on this generic case to discuss the distribution Source 577 Feedback Summary Model. 579 The Loss reporter A and the Loss reporter B MUST listen on the RTP 580 channel for data. When the Loss reporter observes RTP packets from a 581 Media Sender are not consecutive by checking the sequence number of 582 packets, the loss reporter generates NACK message described 583 in[RFC4585] or generates the new RTCP Feedback Report packet 584 described in the section 6, and then send either of them to the 585 distribution source via unicast feedback. 587 The Distribution Source (unicast Feedback Target) MUST listen for 588 unicast RTCP data sent to the RTCP port. Upon receiving the unicast 589 RTCP Feedback Report packet from the loss reporter, the distribution 590 source needs to filter them out, i.e., identify these unicast RTCP 591 packets coming from the Dedicated receivers (i.e.,Loss Reporter A and 592 Loss Reporter B)based on the IP address of loss reporters or 593 dedicated RTCP port for loss report, then summarize the information 594 received from all the RTCP Feedback Reports generated by the 595 Dedicated receivers together with the information generated by the 596 loss reporter integrated in the feedback target and then create the 597 summary report to include all these information. In order to reduce 598 the processing load at the distribution source, the individual 599 instance of Loss Reporter may provide preliminary summarization 600 report. 602 During the summary report creating, the Distribution Source MUST use 603 its own SSRC value for transmitting summarization information and 604 MUST perform proper SSRC collision detection and resolution. 606 In some case, the distribution source may receive RTCP NACK messages 607 from the receivers behind the Distribution Source before the 608 distribution source detects the packet loss which may cause potential 609 Feedback implosion. In such case, the distribution source may filter 610 them out if it already sent a packet loss request for the missing 611 packet to the media sender. When the distribution source confirms 612 packet loss reported by the receiver, the distribution source 613 generates the summary report to include the packet loss information 614 from the corresponding receiver (e.g., upstream client or loss 615 reporter). 617 The distribution source may send this new RTCP summary report 618 described in the section 6 to the group on the multicast RTCP channel 619 and in the meanwhile sending a packet loss request to the media 620 sender. 622 If the loss reporter is part of group, the Distribution source MUST 623 not send the summary report back to this loss reporter. 625 If there are a couple of loss reporters looking at the same RTP 626 stream, then the loss may be identified by all and they will all send 627 requests for the same packet loss. In this case, the distribution 628 source MUST filter out the duplicated information from various loss 629 reporters and only append one copy of such information to the summary 630 report. 632 When the host receives the RTCP packet, if the host understands this 633 message it will not send packet loss request (e.g., NACK) for the 634 missing packets reported in the message and will accept a 635 retransmission stream transmitted from the Distribution Source. If 636 it did not understand this new message, the host may send packet loss 637 request(e.g., NACK messages) to the specified media sender. When the 638 distribution source receives the packet loss request from the hosts 639 after it has already detected packet loss or got packet loss report 640 from loss reporter, the distribution source MUST filter it out until 641 the Retransmission stream is ready in the Distribution Source. 643 6.2. RTP transport translator use case 645 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 646 is typically forwarding the RTP and RTCP traffic between RTP clients, 647 for example converting between multicast and unicast for domains that 648 do not support multicast. The translator can identify packet loss 649 from the upstream and send the Feedback Suppression message to the 650 unicast receivers. The translator can also serve as a loss reporter 651 on the multicast side as described in the SSM case. 653 6.3. Multipoint Control Unit (MCU) use case 655 In point to multipoint topologies using video switching MCU (Topo- 656 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 657 media stream to each participant, selected from the available input 658 streams. The selection of the input stream is often based on voice 659 activity in the audio-visual conference, but other conference 660 management mechanisms (like presentation mode or explicit floor 661 control) exist as well. 663 In this case the MCU may detect packet loss from the sender or may 664 decide to switch to a new source. In both cases the receiver may 665 lose synchronization with the video stream and may send a FIR 666 request. If the MCU itself can detect the mis-synchronization of the 667 video, the MCU can send the FIR suppression message to the receivers 668 and send a FIR request to the video source. 670 7. Security Considerations 672 The defined messages have certain properties that have security 673 implications. These must be addressed and taken into account by 674 users of this protocol. 676 Spoofed or maliciously created feedback messages of the type defined 677 in this specification can have the following implications: 679 Sending NACK Implosion Summary Suppression Indication with wrong 680 sequence number of lost packet that makes missing RTP packets can not 681 be compensated by retransmission mechanism. 683 Sending FIR Implosion Summary Suppression Indication with wrong 684 sequence number of lost packet that makes missing RTP packets can not 685 be compensated by update request mechanism. 687 To prevent these attacks, there is a need to apply authentication and 688 integrity protection of the feedback messages. This can be 689 accomplished against threats external to the current RTP session 690 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 691 into SAVPF [RFC5124]. 693 8. IANA Consideration 695 New feedback type and New parameters for RTCP FSS receiver feedback 696 report are subject to IANA registration. For general guidelines on 697 IANA considerations for RTCP feedback, refer to [RFC4585]. 699 This document assigns one new feedback type value x in the RTCP 700 receiver feedback report registry to "Feedback Storm Suppression" 701 with the following registrations format: 703 Name: FSS 704 Long Name: Feedback Storm Suppression 705 Value: TBD 706 Reference: This document. 708 This document also assigns the parameter value y in the RTCP FSS 709 receiver feedback report Registry to "NACK Suppression Early 710 Indication ", with the following registrations format: 712 Name: NSEI 713 Long name: NACK Suppression Early Indication 714 Value: TBD 715 Reference: this document. 717 This document also assigns the parameter value z in the RTCP FSS 718 receiver feedback report Registry to "FIR Suppression Early 719 Indication ", with the following registrations format: 721 Name: FSEI 722 Long name: FIR Suppression Early Indication 723 Value: TBD 724 Reference: this document. 726 The contact information for the registrations is: 728 Qin Wu 729 sunseawq@huawei.com 730 Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd. 731 Nanjing, JiangSu 210001 China 733 9. Acknowledgement 735 The authors would like to thank David R Oran, Bill Ver Steeg, Ingemar 736 Johansson S, Colin Perkins, Tom VAN CAENEGEM, WeeSan Lee for their 737 valuable comments and suggestions on this document. 739 10. References 741 10.1. Normative References 743 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 744 Protocol (RTCP) Extensions for Single-Source Multicast 745 Sessions with Unicast Feedback", RFC 5760, February 2010. 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, March 1997. 750 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 751 "Extended RTP Profile for Real-time Transport Control 752 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 753 July 2006. 755 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 756 Jacobson, "RTP: A Transport Protocol for Real-Time 757 Applications", STD 64, RFC 3550, July 2003. 759 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 760 January 2008. 762 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 763 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 764 July 2006. 766 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 767 Description Protocol", RFC 4566, July 2006. 769 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 770 Specifications: ABNF", STD 68, RFC 5234, January 2008. 772 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 773 "Codec Control Messages in the RTP Audio-Visual Profile 774 with Feedback (AVPF)", RFC 5104, February 2008. 776 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 777 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 778 RFC 3711, March 2004. 780 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 781 Real-time Transport Control Protocol (RTCP)-Based Feedback 782 (RTP/SAVPF)", RFC 5124, February 2008. 784 10.2. Informative References 786 [DVB-IPTV] 787 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 788 of MPEG-2 TS Based DVB Services over IP Based Networks", 789 ETSI TS 102 034, V1.4.1 , August 2009. 791 [I-D.hunt-avt-monarch-01] 792 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 793 August 2008. 795 [I-D.ietf-pmol-metrics-framework-02] 796 Clark, A., "Framework for Performance Metric Development". 798 Appendix A. Example scenarios for Retransmission Storm Suppression 800 Feedback Storm Suppression can be further extended when a distributed 801 content distribution network (CDN) are considered. In these cases, 802 several intermediate node and media senders may constitute 803 hierarchical model. In the distributed content distribution 804 environment, the Feedback Storm Suppression is used to suppress the 805 neighboring node from sending packet loss request for the missing 806 packets via unicast. How the neighboring node is discovered is 807 beyond scope of this document. 809 A.1. Scenario 1: One or more media sender,One distribution source 811 The general architecture for scenario 1 is displayed below in 812 Figure 4. In this architecture, one or more Media Senders send RTP 813 packets to the RTP Receivers through the same Distribution Source. 814 The Distribution Source relays the RTP packets to the receivers using 815 a source-specific multicast channel. In the reverse direction, the 816 receivers transmit RTCP packets via unicast to the distribution 817 source. The Distribution Source in turn relays RTCP packets to the 818 media sender and then transmits the RTCP packets back to the 819 receivers, using source-specific multicast. When packet loss happens 820 in the upstream link or downstream aggregate link of distribution 821 source, it may result in massive retransmission request for the same 822 RTP packets from all the receivers using RTCP NACK to the same 823 multicast sender. We refer to it as Retransmission Storm. 825 +-------+ 826 |---->|RTP_Rx1| 827 +--------+ | +-------+ 828 | | +--------------+ | 829 | | | | | +-------+ 830 | Media |-------| Distribution |-------|---->|RTP_Rx2| 831 | | | Source | | +-------+ 832 | Sender | | | | . 833 | | +--------------+ | . 834 | | | . 835 +--------+ | +-------+ 836 |---->|RTP_Rxn| 837 +-------+ 839 Figure 4: One media Sender, one Distribution Source 841 A.2. Scenario 2:One media sender, Two distribution sources in cascade 843 +-------+ 844 |---->|RTP_Rx1| 845 | +-------+ 846 +------+ | 847 | | +------------+ +------------+ | +-------+ 848 |Media |-+Distribution+--|Distribution+--|---->|RTP_Rx2| 849 |Sender| | Source1 | | Source2 | | +-------+ 850 | | +------------+ +------------+ | . 851 +------+ | . 852 | . 853 | +-------+ 854 |---->|RTP_Rxn| 855 +-------+ 857 Figure 5: One media sender, Two distribution sources in cascade 859 The general architecture for scenario 2 is displayed below in 860 Figure 5. In this architecture, One media sender passes through two 861 distribution source in cascading and sends RTP packets to all the RTP 862 receivers. When packet loss happens in the upstream link or 863 downstream aggregate link of distribution source1, it may result in 864 massive retransmission request for the same RTP packets from all the 865 receivers using RTCP NACK to the same multicast sender. We refer to 866 it as Retransmission Storm. In this case, the distribution source 2 867 can be taken as one special RTP receiver located in the downstream 868 direction of distribution source 1. 870 A.3. Scenario 3:One media sender, Two distribution sources in parallel 872 The general architecture for scenario 3 is displayed below in 873 Figure 6. In this architecture, one media sender and two 874 Distribution source constitute one hierarchical tree model. In this 875 model, one Media Senders send RTP packets to all the RTP receivers 876 through two different path respectively. When packet loss happens in 877 the upstream link or downstream aggregate link of distribution 878 source, it may result in massive retransmission request for the same 879 RTP packets from all the receivers using RTCP NACK to the same 880 multicast sender. We refer to it as Retransmission Storm. 882 +--------+ 883 |---->|RTP_Rx11| 884 | +--------+ 885 +--------------+ | 886 | | | +--------+ 887 |--->| Distribution |----|---->|RTP_Rx12| 888 | | Source1 | | +--------+ 889 | | | | . 890 +--------+ | +--------------+ | . 891 | | | | . 892 | | | | +--------+ 893 | Media | | |---->|RTP_Rx1k| 894 | |---| +--------+ 895 | Sender | | +--------+ 896 | | | |---->|RTP_Rx21| 897 | | | | +--------+ 898 +--------+ | +--------------+ | 899 | | | | +--------+ 900 | | Distribution |----|---->|RTP_Rx22| 901 |--->| Source2 | | +--------+ 902 | | | . 903 +--------------+ | . 904 | . 905 | +--------+ 906 |---->|RTP_Rx2j| 907 +--------+ 909 Figure 6: One Media Sender, more distribution sources 911 Appendix B. Applicability of Feedback Storm Suppression 913 This document defines new RTCP Receiver feedback Report, which we 914 refer to as Feedback Storm Suppression to deal with Retransmission 915 Storm mentioned above. Here we give two examples to show how this 916 new RTCP receiver feedback report is applied into three scenarios 917 described in Appendix A for Retransmission Storm Suppression. 919 Applicability of Retransmission Storm Suppression in Scenario 1 920 described in Figure 4 is shown in the Figure 7. In this figure, the 921 distribution source detect the packet loss before the receiver 922 perceive it and ask for retransmission of the missing packets from 923 the media sender, in the meanwhile, the distribution source transmits 924 the RTCP Retransmission Storm Suppression Indication back to the 925 receivers using source-specific multicast channel. In this way, the 926 delay for the receiver to recover from the packet loss can be reduced 927 and the risk of increasing network congestion can be mitigated. 929 +------+ +--------------+ +--------+ 930 |Media | | Distribution | | | 931 |Sender| | Source | | RTP_Rx | 932 +--+---+ +------+-------+ +---+----+ 933 | | | 934 | | | 935 |------------------->|------RTP Multicast---->| 936 | | | 937 | | | 938 | +--------+----------+ | 939 | |Detect Packet Loss | | 940 | |and Identify the SN| | 941 | |of missing Packets | | 942 | +--------+----------+ | 943 |<-----RTCP NACK-----| | 944 | | | 945 | +--Multicast RTCP FSS--->| 946 | RTP Retransmission | | 947 |------------------->| | 948 | |------RTP Multicast---->| 949 | | Retransmission | 950 | | | 951 | | | 952 | | | 954 Figure 7: Applicability of Feedback Suppression Early Indication 956 Applicability of Feedback Storm Suppression in Scenario 2 or 3 957 described in Figure 5 and Figure 6 is shown in the Figure 8. The 958 procedure in the Figure 8 is similar to the one in the figure 959 Figure 7. The only difference is distribution source should not only 960 notify all the receiver behind itself not to send NACK but also 961 propagate the retransmission suppression indication to the 962 neighboring distribution sources. In this way, all the receivers 963 behind all the neighboring distribution source can avoid sending 964 massive retransmission request to the media sender. 966 +------+ +-------+ +--------+ +-------+ +--------+ 967 |Media | | | | RTP_Rx | | | | RTP_Rx | 968 |Sender| | DS1 | | (DS1) | | DS2 | | (DS2) | 969 +--+---+ +---+---+ +---+----+ +---+---+ +---+----+ 970 | | | | | 971 | |RTP Multicast | | | 972 |----------->|------------->| | | 973 | | | | | 974 | | | |RTP Multicast| 975 |------------------------------------------->|------------>| 976 | | | | | 977 | +--------+------------+ | | | 978 | |Detect Packet Loss | | | | 979 | |and Identify the SN | | | | 980 | |of the missing Packets | | | 981 | +--------+------------+ | | | 982 | | | | | 983 |<-RTCP NACK-| Multicast RTCP RSSI | | 984 | |------------->| | | 985 | | | | | 986 | |-----Unicast RTCP RSSI-------->|Multicast RTCP FSS 987 | | | |------------>| 988 |RTP Retransmission | | | 989 |----------->| | | | 990 | | | | | 991 | | RTP Retransmission | | 992 |------------+--------------+--------------->| | 993 | | | | | 994 | | RTP Multicast| | RTP Multicast 995 | |Retransmission| |Retransmission 996 | |------------->| |------------>| 997 | | | | | 998 DS1: Distribution Source 1 999 DS2: Distribution Source 2 1001 Figure 8: Applicability of Retransmission Suppression Early 1002 Indication 1004 Authors' Addresses 1006 Qin Wu 1007 Huawei 1008 101 Software Avenue, Yuhua District 1009 Nanjing, Jiangsu 210012 1010 China 1012 Email: sunseawq@huawei.com 1014 Frank Xia 1015 Huawei 1016 1700 Alma Dr. Suite 500 1017 Plano, TX 75075 1018 USA 1020 Phone: +1 972-509-5599 1021 Email: xiayangsong@huawei.com 1023 Roni Even 1024 Huawei 1025 14 David Hamelech 1026 Tel Aviv 64953 1027 Israel 1029 Email: even.roni@huawei.com