idnits 2.17.1 draft-ietf-avtcore-feedback-supression-rtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 20 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). == 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 (April 15, 2011) is 4758 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 639, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC5740' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-avt-rapid-acquisition-for-rtp' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 688, 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 (~~), 9 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: October 17, 2011 Huawei 6 April 15, 2011 8 RTCP Extension for Feedback Suppression Indication 9 draft-ietf-avtcore-feedback-supression-rtp-01 11 Abstract 13 In a large RTP session using the RTCP feedback mechanism defined in 14 RFC 4585, a media source or middlebox may experience transient 15 overload if some event causes a large number of receivers to send 16 feedback at once. This feedback implosion can be mitigated if the 17 device suffering from overload can send a third party loss report 18 message to the receivers to inhibit further feedback. This memo 19 defines RTCP extensions for third party loss report, to suppress NACK 20 and FIR feedback requests. It also defines associated SDP signaling. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 17, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 71 4. RTCP Feedback Report Extension . . . . . . . . . . . . . . . . 6 72 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7 73 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 7 74 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 76 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9 77 6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 10 78 6.1.2. Distribution Source Feedback Summary Model . . . . . . 11 79 6.2. Unicast based Rapid Acquisition of Multicast Stream 80 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 11 81 6.3. RTP transport translator use case . . . . . . . . . . . . 13 82 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 85 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 89 Appendix A. Appendix A. Change Log . . . . . . . . . . . . . . . 16 90 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 RTCP feedback messages [RFC4585] allow the receivers in an RTP 96 session to report events and ask for action from the media source (or 97 a delegated feedback target defined in SSM [RFC5760]). There are 98 cases where multiple receivers may initiate the same, or an 99 equivalent message towards the same media source. When the receiver 100 count is large, this behavior may cause transient overload of the 101 media source, the network or both. This is known as a "feedback 102 storm" or a "NACK storm". One common cause of such a feedback storm 103 is receivers utilizing RTP retransmission [RFC4588] as a packet loss 104 recovery technique based, sending feedback using RTCP NACK messages 105 [RFC4585] without proper dithering of the retransmission requests. 107 Another use case involves video Fast Update requests. A storm of 108 these feedback messages can occur in conversational multimedia 109 scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, 110 packet loss may happen on an upstream link of an intermediate network 111 element such as a Multipoint Control Unit(MCU). Poorly designed 112 receivers that blindly issue fast update requests (i.e., Full Intra 113 Request (FIR) described in [RFC5104]), can cause an implosion of FIR 114 requests from receivers to the same media source. 116 RTCP feedback storms may cause short term overload, and in extreme 117 cases to pose a possible risk of increasing network congestion on the 118 control channel (e.g. RTCP feedback), the data channel, or both. It 119 is therefore desirable to provide a way of suppressing unneeded 120 feedback. 122 One approach to this, suggested in [DVB-IPTV], involves sending a 123 NACK message to the other clients (or receiver) in the same group as 124 the sender of NACK. However sending multicast NACK to the group can 125 not prevent large amount of unicast NACK addressed to the same media 126 source or middlebox, for example when the NACK is used as a 127 retransmission request [RFC4588]. Also NACK is defined as a receiver 128 report sent from a receiver observing a packet loss, therefore it 129 only inform others that sender of NACK detected loss while the case 130 the sender of the feedback has received reports that the indicated 131 packets were lost is not covered. This document specifies a new 132 message for this function. It further is more precise in the 133 intended uses and less likely to be confusing to receivers. It tells 134 receivers explicitly that feedback for a particular packet or frame 135 loss is not needed for a period of time and can provide an early 136 indication before the receiver reacts to the loss and invokes its 137 packet loss repair machinery. 139 2. Terminology 141 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Protocol Overview 147 This document extends the RTCP feedback messages defined in the 148 Audio-Visual Profile with Feedback (AVPF) and define the Third Party 149 Loss Report message. The Third Party Loss Report message informs the 150 receiver in the downstream path of the middlebox that the sender of 151 the Third Party Loss Report has received reports that the indicated 152 packets were lost and asks a receiver to not send feedback messages 153 for particular packets (indicated by their RTP sequence numbers) 154 independent of whether the receiver detected the packet loss or 155 detected a need for a decoder refresh point. 157 In order to observe packet loss before the receivers perceive it, one 158 or more intermediate nodes may be placed between the media source and 159 the receivers. These intermediates are variously referred to as 160 Distribution servers, MCUs, RTP translator, or RTP mixers, depending 161 on the precise use case. These intermediaries monitor for packet 162 loss upstream of themselves by checking RTP sequence numbers, just as 163 receivers do. Upon observing (or suspecting) an upstream loss, the 164 intermediary may send Loss Party Loss Report message towards the 165 receivers as defined in this specification. 167 These intermediate nodes need to take into account such factors as 168 the tolerable application delay, packet loss recovery techniques, the 169 network dynamics, and the media type. When the packet loss is 170 detected upstream of the intermediary and additional latency is 171 tolerable, loss-repair methods such as Forward Error Correction and 172 retransmission may be used to recover the missing packets. Therefore 173 the intermediate node can be reasonably certain that it will help the 174 situation by sending a Third Party Loss Report message to all the 175 relevant receivers, thereby indicating to the receivers that they 176 should not transmit feedback messages for a period of time. 178 Alternatively, the media source may directly monitor the amount of 179 feedback requests it receives, and send Third Party Loss Report 180 messages to the receivers. 182 When a receiver gets such a Third Party Loss Report message, it 183 should refrain from sending a feedback request (e.g., NACK or FIR) 184 for the missing packets reported in the message for a period of time. 185 A receiver may still have sent a Feedback message according to the 186 AVPF scheduling algorithm of [RFC4585]before receiving a Third Party 187 Loss Report message, but further feedback messages for those sequence 188 numbers will be suppressed by this technique for a period of time. 189 Nodes that do not understand the Third Party Loss Report message will 190 ignore it, and might therefore still send feedback according to the 191 AVPF scheduling algorithm of [RFC4585]. The media source or 192 intermediate nodes cannot assume that the use of a Third Party Loss 193 Report message actually reduces the amount of feedback it receives. 195 RTCP Third Party Loss Report follows the similar format of message 196 type as RTCP NACK. But unlike RTCP NACK, the third party loss report 197 is defined as an indication that the sender of the feedback has 198 received reports that the indicated packets were lost and conveys the 199 packet receipt/loss events at the sequence number level from the 200 middlebox to the receivers in the downstream path of middlebox while 201 NACK [RFC4585]just indicates that the sender of the NACK observed 202 that these packets were lost. The Third Party Loss Report message 203 can also be generated by RTP middlebox that has not seen the actual 204 packet loss and sent to the corresponding receivers. Intermediaries 205 downstream of an intermediary detecting loss obviously SHOULD NOT 206 initiate their own additional Third Party Loss Report messages for 207 the same packet sequence numbers. They may either simply forward the 208 Third Party Loss Report message received from upstream, or replace it 209 with a Third Party Loss Report message that reflects the loss pattern 210 they have themselves seen. The Third Party Loss Report does not have 211 the retransmission request [rfc4588] semantics. 213 Since Third Party Loss Report interacts strongly with repair timing, 214 it has to work together with feedback to not adversely impact the 215 repair of lost source packets. One example is the middle box gets 216 the retransmitted packet by sending a NACK upstream and sent it 217 downstream. This retransmitted packet was lost on the downstream 218 link. In order to deal with this, the downstream receiver can start 219 a timeout in which it expected to get a retransmission packet. When 220 this timeout expires and there is no retransmitted packet or a new 221 third party loss report message, it can take its normal behavior as 222 if there is no current retransmission suppression. In some cases 223 where the loss was detected and repair initiated much closer to the 224 source, the delay for the receiver to recover from packet loss can be 225 reduced through the combination of intermediary feedback to the 226 source and Third Party Loss Report downstream. In all (properly 227 operating) cases, the risk of increasing network congestion is 228 decreased. 230 4. RTCP Feedback Report Extension 232 This document registers two new RTCP Feedback messages for Third 233 Party Loss Report. Applications that are employing one or more loss- 234 repair methods MAY use Third Party Loss Report together with their 235 existing loss-repair methods either for every packet they expect to 236 receive, or for an application-specific subset of the RTP packets in 237 a session. In other words, receivers MAY ignore Third Party Loss 238 Report messages, but SHOULD react to them unless they have good 239 reason to still send feedback messages despite having been requested 240 to suppress them. 242 4.1. Transport Layer Feedback: Third-party Loss Report 244 This Third Party Loss Report message is an extension to the RTCP 245 Transport Layer Feedback Report and identified by RTCP packet type 246 value PT=RTPFB and FMT=TBD. 248 The FCI field MUST contain one or more entries of transport layer 249 third party loss Early Indication (TLLEI). Each entry applies to a 250 different media source, identified by its SSRC. 252 The Feedback Control Information (FCI) for TLLEI uses the similar 253 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 254 The format is shown in Figure 1. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | PID | BLP | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 1: Message Format for the Third Party Loss Report 264 Packet ID (PID): 16 bits 266 The PID field is used to specify a lost packet. The PID field 267 refers to the RTP sequence number of the lost packet. 269 bitmask of proceeding lost packets (BLP): 16 bits 271 The BLP allows for reporting losses of any of the 16 RTP packets 272 immediately following the RTP packet indicated by the PID. The 273 BLP's definition is identical to that given in [RFC4585]. 275 4.2. Payload Specific Feedback: Third-party Loss Report 277 This message is an extension to the RTCP Payload Specific Feedback 278 report and identified by RTCP packet type value PT=PSFB and FMT=TBD. 280 The FCI field MUST contain a Payload Specific Third Party Loss Early 281 Indication (PSLEI) entry. Each entry applies to a different media 282 source, identified by its SSRC. 284 The Feedback Control Information (FCI) for PSLEI uses the similar 285 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 286 The format is shown in Figure 2. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | SSRC | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Seq nr. | Reserved | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 2: Message Format for the Third Party Loss Report 298 SSRC (32 bits): 300 The SSRC value of the media source that is requested to send a 301 decoder refresh point. 303 Seq nr:8bits Command sequence number. The sequence number space is 304 unique for each pairing of the SSRC of command source and the SSRC 305 of the command target. The sequence number SHALL be increased by 306 1 modulo 256 for each new request. 308 Reserved: 24 bits 310 All bits SHALL be set to 0 by the media source and SHALL be 311 ignored on reception. 313 5. SDP Signaling 315 A new feedback value "tplr" needs to be defined for the Third Party 316 Loss Report message to be used with Session Description Protocol 317 (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) 318 [RFC4585]. 320 The "tplr" feedback value SHOULD be used with parameters that 321 indicate the third party loss supported. In this document, we define 322 two such parameter, namely: 324 o "tllei" denotes support of transport layer third party loss early 325 indication (fsei). 327 o "pslei" denotes support of payload specific third party loss early 328 indication. 330 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 331 placeholder called rtcp-fb-id to define new feedback types. "tplr" is 332 defined as a new feedback type in this document, and the ABNF for the 333 parameters for tplr is defined here (please refer to section 4.2 of 334 [RFC4585] for complete ABNF syntax). 336 rtcp-fb-val =/ "tplr" rtcp-fb-tplr-param 337 rtcp-fb-tplr-param = SP "tllei";transport layer third party loss early indication 338 / SP "pslei";payload specific third party loss early indication 339 / SP token [SP byte-string] 340 ; for future commands/indications 341 byte-string = 343 Refer to Section 4.2 of [RFC4585] for a detailed description and the 344 full syntax of the "rtcp-fb" attribute. 346 6. Example Use Cases 348 The operation of feedback suppression is similar for all types of RTP 349 sessions and topologies [RFC5117], however the exact messages used 350 and the scenarios in which suppression is employed differ for various 351 use cases. The following sections outline the intended use cases of 352 using Third Party Loss Report for feedback suppression and give an 353 overview of the particular mechanisms. 355 6.1. Source Specific Multicast (SSM) use case 357 In SSM RTP sessions as described in [RFC5760], one or more Media 358 Sources send RTP packets to a Distribution Source. The Distribution 359 Source relays the RTP packets to the receivers using a source- 360 specific multicast group. 362 In order to avoid the forms of Feedback implosion described in 363 section 1,the distribution source should be told that the indicated 364 packets were lost. How the distribution source know the indicated 365 packets were lost is beyond of scope of this document. When upstream 366 link or downstream aggregate link packet loss occurs, the 367 distribution source creates a Third Party Loss Report and sent it to 368 all the RTP receivers, over the multicast channel. Another 369 possibility is when there may be multiple distribution sources placed 370 between the media source and the receivers, each distribution source 371 may send its own Third Party Loss report to downstream receivers 372 respectively. And also the upstream distribution source may inform 373 downstream distribution sources in the path of the detected packet 374 loss using Third Party Loss Report messages. In response, if the 375 upstream Third Party Loss Report reports the different event, the 376 downstream distribution sources forward Third Party Loss Report 377 received from upstream to all the RTP receivers, over the multicast 378 channel. If the same event is reported from upstream distribution 379 source, the downstream distribution source may suppress creating and 380 sending its own report to the relevant RTP receivers. This Third 381 Party Loss Report message tells the receivers that the sender of the 382 third party loss report has received reports that the indicated 383 packets were lost. The distribution source then can (optionally) ask 384 for the lost packets from the media source or itself on behalf of all 385 the RTP receivers. The lost packets will either be forthcoming from 386 distribution source, or it irretrievably lost such that there is 387 nothing to be gained by the receiver sending a NACK to the media 388 source. 390 The distribution source must be able to communicate with all group 391 members in order for either mechanism to be effective at suppressing 392 feedback. 394 As outlined in the [RFC5760], there are two Unicast Feedback models 395 that may be used for reporting, - the Simple Feedback model and the 396 Distribution Source Feedback Summary Model. The RTCP Feedback 397 extension for Third Party Loss Report specified in the Section 4 of 398 this document will work in both Feedback models. Details of 399 operation in each are specified below. 401 6.1.1. Simple Feedback Model 403 In the simple Feedback Model, NACKs from the receiver observing the 404 loss will be reflected to the other receivers, and there's no need 405 for distribution source to create the third-party loss report. The 406 distribution source that has not seen the actual packet loss should 407 pass through any Third Party Loss Report message it receives from the 408 upstream direction. 410 This RTCP Third Party Loss Report message lets the receivers know 411 that the sender of the Third party Loss Report has received reports 412 that the indicated packets were lost and feedback for this packet 413 loss is not needed and should not be sent to the media source(s). If 414 the media source(s) are part of the SSM group for RTCP packet 415 reflection, the Distribution Source must filter this packet out. If 416 the media source(s) are not part of the SSM group for RTCP packets, 417 the Distribution Source must not forward this RTCP Third Party Loss 418 Report message to the media source(s). 420 6.1.2. Distribution Source Feedback Summary Model 422 In the distribution source feedback summary model, there may be 423 multiple distribution sources who see the actual packet loss In this 424 section, we focus on this generic case to discuss the distribution 425 Source Feedback Summary Model. 427 The distribution source A must listen on the RTP channel for data. 428 When the distribution source A observes RTP packets from a media 429 source are not consecutive by checking the sequence number of 430 packets, the distribution source A generates the new RTCP Third Party 431 Loss Report message described in the Section 4, and then send it to 432 receivers in the downstream path via the multicast channel. Note 433 that the distribution source A must use its own SSRC value as packet 434 sender SSRC for transmitting the new RTCP Third Party Loss Report 435 message. 437 The Distribution Source B must also listen for RTCP data sent to the 438 RTCP port. Upon receiving the RTCP Third Party Loss Report from the 439 Distribution Source A, the Distribution Source B needs to check 440 whether it sees upstream third party loss report from distribution 441 source A reporting the same event. If the upstream Third Party Loss 442 Report reports the different event, the distribution source B passes 443 through any Third Party Loss Report message it receives from the 444 upstream direction. If the same event is reported from distribution 445 source A, the distribution source B may suppress creating and sending 446 its own report with the same event to the downstream RTP receiver. 447 Also the Distribution Source B may create and send its own summary 448 Third Party Loss Report described in the Section 4 to the group over 449 the multicast RTCP channel. . In order to reduce the processing load 450 at the distribution source, the distribution source B may provide 451 preliminary summarization Third Party Loss Report. 453 In some case, the distribution source B may receive RTCP NACK 454 messages from the receivers behind the Distribution Source before the 455 distribution source detects the packet loss which may cause potential 456 Feedback implosion. In such case, the distribution source B may 457 filter them out if it already detected the same loss. 459 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 460 case 462 The typical RAMS architecture 463 [I-D.ietf-avt-rapid-acquisition-for-rtp]may have several Burst/ 464 Retransmission Sources(BRS) behind the multicast source (MS) These 465 BRSes will receive the multicast SSM stream from the media source. 466 If one of the BRSes detects packet loss (i.e., First loss in 467 Figure 3) on its upstream link between the MS and itself, but the 468 others BRSes have not, as the packet loss took place on the SSM tree 469 branch that does not impact the other BRSes. In such case, the BRSes 470 not being impacted cannot detect packet loss at their upstream link, 471 therefore these BRSes will not create new Third Party Loss Report 472 message and send it to receivers in their downstream path. If the 473 BRS impacted by packet loss has seen the actual packet loss, the BRS 474 MAY choose to create new Third Party Loss Report message and send it 475 to the receivers in the downstream link. Note that BRS must use its 476 own SSRC as packet sender SSRC for transmitting the feedback suppress 477 message. 479 The BRS may also send a NACK upstream to request the retransmitted 480 packet. Upon receiving the retransmitted packet, the BRS sent it 481 downstream. Note that this retransmitted packet may get lost (i.e., 482 second loss in the Figure 3) on the downstream link. In order to 483 deal with this issue, the downstream receiver can start a timeout 484 clock in which it expected to get a retransmission packet. When this 485 timeout expires and there is no retransmitted packet or a new Third 486 Party Loss Report message, it can take its normal behavior as if 487 there is no current retransmission suppression in place. 489 First +------------+ +----------+ 490 loss |Burst and |Second Loss | | 491 +-----X-----| Retrans. |----X------>| | 492 | Upstream |Source1(BRS)| Downstream | | 493 Link close | link 1 +------------+ link 1 | | 494 to multicast | | | 495 source | | | 496 | | | | 497 | | +------------+ | RTP | 498 +---------+ | +-----++ |Burst and | | Receiver | 499 |Multicast| V| | +----------| Retrans. |----------->| | 500 | Source +-----|Router|Upstream |Source2(BRS)| Downstream | RTP_Rx | 501 +---------+ | |link 2 +------------+ link 2 | | 502 +-----++ | | 503 | | | 504 | | | 505 | | | 506 | +------------+ | | 507 | |Burst and | | | 508 +-----------+ Retrans. |----------->| | 509 Upstream |Source k(BRS| Downstream | | 510 link k +------------+ link k +----------+ 512 Figure 3: RAMS Use Case 514 6.3. RTP transport translator use case 516 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 517 is typically forwarding the RTP and RTCP traffic between RTP clients, 518 for example converting between multicast and unicast for domains that 519 do not support multicast. The translator can identify packet loss 520 from the upstream and send the Third Party Loss Report message to the 521 unicast receivers. Note that the translator must be a participant in 522 the session and can then use it's own SSRC as packet sender SSRC for 523 transmitting the Third Party Loss Report message 525 6.4. Multipoint Control Unit (MCU) use case 527 In point to multipoint topologies using video switching MCU (Topo- 528 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 529 media stream to each participant, selected from the available input 530 streams. The selection of the input stream is often based on voice 531 activity in the audio-visual conference, but other conference 532 management mechanisms (like presentation mode or explicit floor 533 control) exist as well. 535 In this case the MCU may detect packet loss from the sender or may 536 decide to switch to a new source. In both cases the receiver may 537 lose synchronization with the video stream and may send a FIR 538 request. If the MCU itself can detect the mis-synchronization of the 539 video, the MCU can send the FIR suppression message to the receivers 540 and send a FIR request to the video source. As suggested in RFC 541 5117, this topology is better implemented as an Topo-mixer, in which 542 case the mixer's SSRC is used as packet sender SSRC for transmitting 543 Third Party Loss Report message. 545 7. Security Considerations 547 The defined messages have certain properties that have security 548 implications. These must be addressed and taken into account by 549 users of this protocol. 551 Spoofed or maliciously created feedback messages of the type defined 552 in this specification can have the following implications: 554 Sending Third Party Loss Report with wrong sequence number of lost 555 packet that makes missing RTP packets can not be compensated. 557 To prevent these attacks, there is a need to apply authentication and 558 integrity protection of the feedback messages. This can be 559 accomplished against threats external to the current RTP session 560 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 561 into SAVPF [RFC5124]. 563 Note that middleboxes that are not visible at the RTP layer that wish 564 to send Third Party Loss Reports on behalf of the media source can 565 only do so if they spoof the SSRC of the media source. This is 566 difficult in case SRTP is in use. If the middlebox is visible at the 567 RTP layer, this is not an issue, provided the middlebox is part of 568 the security context for the session. 570 Also note that endpoints that receive a Third Party Loss Report would 571 be well-advised to ignore it, unless it is authenticated via SRTCP or 572 similar. Accepting un-authenticated Third Party Loss Report can lead 573 to a denial of service attack, where the endpoint accepts poor 574 quality media that could be repaired. 576 8. IANA Consideration 578 New feedback type and New parameters for RTCP Third Party Loss Report 579 are subject to IANA registration. For general guidelines on IANA 580 considerations for RTCP feedback, refer to [RFC4585]. 582 This document assigns one new feedback type value x in the RTCP 583 feedback report registry to "Third Party Loss Report" with the 584 following registrations format: 586 Name: TPLR 587 Long Name: Third Party Loss Report 588 Value: TBD 589 Reference: This document. 591 This document also assigns the parameter value y in the RTCP TPLR 592 feedback report Registry to " Transport Layer Third Party Loss Early 593 Indication ", with the following registrations format: 595 Name: TLLEI 596 Long name: Transport Layer Third Party Loss Early Indication 597 Value: TBD 598 Reference: this document. 600 This document also assigns the parameter value z in the RTCP TPLR 601 feedback report Registry to "Payload Specific Third Party Loss Early 602 Indication ", with the following registrations format: 604 Name: PSLEI 605 Long name: Payload Specific Third Party Loss Early Indication 606 Value: TBD 607 Reference: this document. 609 The contact information for the registrations is: 611 Qin Wu 612 sunseawq@huawei.com 613 101 Software Avenue, Yuhua District 614 Nanjing, Jiangsu 210012, China 616 9. Acknowledgement 618 The authors would like to thank David R Oran, Ali C. Begen, Colin 619 Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, 620 Jonathan Lennox, WeeSan Lee for their valuable comments and 621 suggestions on this document. 623 10. References 625 10.1. Normative References 627 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 628 Protocol (RTCP) Extensions for Single-Source Multicast 629 Sessions with Unicast Feedback", RFC 5760, February 2010. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 635 "Extended RTP Profile for Real-time Transport Control 636 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 637 July 2006. 639 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 640 Jacobson, "RTP: A Transport Protocol for Real-Time 641 Applications", STD 64, RFC 3550, July 2003. 643 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 644 January 2008. 646 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 647 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 648 July 2006. 650 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 651 Description Protocol", RFC 4566, July 2006. 653 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 654 Specifications: ABNF", STD 68, RFC 5234, January 2008. 656 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 657 "Codec Control Messages in the RTP Audio-Visual Profile 658 with Feedback (AVPF)", RFC 5104, February 2008. 660 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 661 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 662 RFC 3711, March 2004. 664 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 665 Real-time Transport Control Protocol (RTCP)-Based Feedback 666 (RTP/SAVPF)", RFC 5124, February 2008. 668 10.2. Informative References 670 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 671 "NACK-Oriented Reliable Multicast (NORM) Transport 672 Protocol", November 2009. 674 [DVB-IPTV] 675 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 676 of MPEG-2 TS Based DVB Services over IP Based Networks", 677 ETSI TS 102 034, V1.4.1 , August 2009. 679 [I-D.ietf-avt-rapid-acquisition-for-rtp] 680 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 681 Based Rapid Acquisition of Multicast RTP Sessions", 682 November 2010. 684 [I-D.hunt-avt-monarch-01] 685 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 686 August 2008. 688 [I-D.ietf-pmol-metrics-framework-02] 689 Clark, A., "Framework for Performance Metric Development". 691 Appendix A. Appendix A. Change Log 693 Note to the RFC-Editor: please remove this section prior to 694 publication as an RFC. 696 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 698 The following are the major changes compared to previous version: 699 o Remove the merge report from SSM use case and addional text to 700 address report merging issue. 702 o Revise section 3 and section 6 to address FEC packet dealing issue 703 and Leave how to repair packet loss beyond the scope. 704 o Modify the SSM use case and RAMS use case to focus on uses. 705 o Other Editorial changes. 707 Authors' Addresses 709 Qin Wu 710 Huawei 711 101 Software Avenue, Yuhua District 712 Nanjing, Jiangsu 210012 713 China 715 Email: sunseawq@huawei.com 717 Frank Xia 718 Huawei 719 1700 Alma Dr. Suite 500 720 Plano, TX 75075 721 USA 723 Phone: +1 972-509-5599 724 Email: xiayangsong@huawei.com 726 Roni Even 727 Huawei 728 14 David Hamelech 729 Tel Aviv 64953 730 Israel 732 Email: even.roni@huawei.com