idnits 2.17.1 draft-ietf-avtcore-feedback-supression-rtp-02.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 (May 6, 2011) is 4739 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 638, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC5740' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 687, 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 (~~), 8 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: November 7, 2011 Huawei 6 May 6, 2011 8 RTCP Extension for Third-party Loss Report 9 draft-ietf-avtcore-feedback-supression-rtp-02 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 Extension 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 November 7, 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. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 7 72 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7 73 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 8 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 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 RTCP feedback messages [RFC4585] allow the receivers in an RTP 97 session to report events and ask for action from the media source (or 98 a delegated feedback target defined in SSM [RFC5760]). There are 99 cases where multiple receivers may initiate the same, or an 100 equivalent message towards the same media source. When the receiver 101 count is large, this behavior may cause transient overload of the 102 media source, the network or both. This is known as a "feedback 103 storm" or a "NACK storm". One common cause of such a feedback storm 104 is receivers utilizing RTP retransmission [RFC4588] as a packet loss 105 recovery technique based, sending feedback using RTCP NACK messages 106 [RFC4585] without proper dithering of the retransmission requests. 108 Another use case involves video Fast Update requests. A storm of 109 these feedback messages can occur in conversational multimedia 110 scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, 111 packet loss may happen on an upstream link of an intermediate network 112 element such as a Multipoint Control Unit(MCU). Poorly designed 113 receivers that blindly issue fast update requests (i.e., Full Intra 114 Request (FIR) described in [RFC5104]), can cause an implosion of FIR 115 requests from receivers to the same media source. 117 RTCP feedback storms may cause short term overload, and in extreme 118 cases to pose a possible risk of increasing network congestion on the 119 control channel (e.g. RTCP feedback), the data channel, or both. It 120 is therefore desirable to provide a way of suppressing unneeded 121 feedback. 123 One approach to this, suggested in [DVB-IPTV], involves sending a 124 NACK message to the other clients (or receiver) in the same group as 125 the sender of NACK. However sending multicast NACK to the group can 126 not prevent large amount of unicast NACK addressed to the same media 127 source or middlebox, for example when the NACK is used as a 128 retransmission request [RFC4588]. Also NACK is defined as a receiver 129 report sent from a receiver observing a packet loss, therefore it 130 only inform others that sender of NACK detected loss while the case 131 the sender of the feedback has received reports that the indicated 132 packets were lost is not covered. This document specifies a new 133 message for this function. It further is more precise in the 134 intended uses and less likely to be confusing to receivers. It tells 135 receivers explicitly that feedback for a particular packet or frame 136 loss is not needed for a period of time and can provide an early 137 indication before the receiver reacts to the loss and invokes its 138 packet loss repair machinery. 140 2. Terminology 142 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Protocol Overview 148 This document extends the RTCP feedback messages defined in the 149 Audio-Visual Profile with Feedback (AVPF) and define the Third Party 150 Loss Report message. The Third Party Loss Report message informs the 151 receiver in the downstream path of the middlebox that the sender of 152 the Third Party Loss Report has received reports that the indicated 153 packets were lost and asks a receiver to not send feedback messages 154 for particular packets (indicated by their RTP sequence numbers) 155 independent of whether the receiver detected the packet loss or 156 detected a need for a decoder refresh point. 158 In order to observe packet loss before the receivers perceive it, one 159 or more intermediate nodes may be placed between the media source and 160 the receivers. These intermediates are variously referred to as 161 Distribution servers, MCUs, RTP translator, or RTP mixers, depending 162 on the precise use case. These intermediaries monitor for packet 163 loss upstream of themselves by checking RTP sequence numbers, just as 164 receivers do. These intermediate nodes need to take into account 165 such factors as the tolerable application delay, packet loss recovery 166 techniques, the network dynamics, and the media type. Loss-repair 167 methods such as retransmission and Forward Error Correction may be 168 used to recover the missing packet. Upon observing (or suspecting) 169 an upstream loss, the intermediary Should send NACK both downstream 170 towards the receivers and upstream towards the media source, to 171 indicate that it has noticed the loss, and to suppress feedback from 172 other downstream receivers. Upon downstream loss is reported to the 173 intermediary, the intermediary SHOULD send the Third Party Loss 174 report to the other downstream receivers which are not aware of the 175 loss reports, to inform those receivers of the loss and suppress 176 their feedback. Therefore the intermediate node can be reasonably 177 certain that it will help the situation by sending a Third Party Loss 178 Report message and NACK message to all the relevant receivers, 179 thereby indicating to the receivers that they should not transmit 180 feedback messages for a period of time. 182 Alternatively, the media source may directly monitor the amount of 183 feedback requests it receives from downstream, and send the Third 184 Party Loss Report messages to the downstream receivers. 186 When a receiver gets such a Third Party Loss Report message, it 187 should refrain from sending a feedback request (e.g., NACK or FIR) 188 for the missing packets reported in the message for a period of time. 189 A receiver may still have sent a Feedback message according to the 190 AVPF scheduling algorithm of [RFC4585]before receiving a Third Party 191 Loss Report message, but further feedback messages for those sequence 192 numbers will be suppressed by this technique for a period of time. 193 Nodes that do not understand the Third Party Loss Report message will 194 ignore it, and might therefore still send feedback according to the 195 AVPF scheduling algorithm of [RFC4585]. The media source or 196 intermediate nodes cannot assume that the use of a Third Party Loss 197 Report message actually reduces the amount of feedback it receives. 199 RTCP Third Party Loss Report follows the similar format of message 200 type as RTCP NACK. But unlike RTCP NACK, the third party loss report 201 is defined as an indication that the sender of the feedback has 202 received reports that the indicated packets were lost and conveys the 203 packet receipt/loss events at the sequence number level from the 204 middlebox to the receivers in the downstream path of middlebox while 205 NACK [RFC4585] just indicates that the sender of the NACK observed 206 that these packets were lost. The Third Party Loss Report message is 207 generated by RTP middlebox that has not seen the actual packet loss 208 and sent to the corresponding receivers. Intermediaries downstream 209 of an intermediary receiving the upstream report obviously SHOULD NOT 210 initiate their own additional Third Party Loss Report messages for 211 the same packet sequence numbers. They may either simply forward the 212 Third Party Loss Report message received from upstream, or send its 213 own Third Party Loss Report message that reflects the loss they have 214 been told. The Third Party Loss Report does not have the 215 retransmission request [RFC4588] semantics. 217 Since Third Party Loss Report interacts strongly with repair timing, 218 it has to work together with feedback to not adversely impact the 219 repair of lost source packets. One example is the middle box gets 220 the retransmitted packet by sending a NACK upstream and sent it 221 downstream. This retransmitted packet was lost on the downstream 222 link. In order to deal with this, the downstream receiver can start 223 a timeout in which it expected to get a retransmission packet. When 224 this timeout expires and there is no retransmitted packet or a new 225 third party loss report message, it can take its normal behavior as 226 if there is no current retransmission suppression. In some cases 227 where the loss was detected and repair initiated much closer to the 228 source, the delay for the receiver to recover from packet loss can be 229 reduced through the combination of intermediary feedback to the 230 source and Third Party Loss Report downstream. In all (properly 231 operating) cases, the risk of increasing network congestion is 232 decreased. 234 4. Format of RTCP Feedback Messages 236 This document registers two new RTCP Feedback messages for Third 237 Party Loss Report. Applications that are employing one or more loss- 238 repair methods MAY use Third Party Loss Report together with their 239 existing loss-repair methods either for every packet they expect to 240 receive, or for an application-specific subset of the RTP packets in 241 a session. In other words, receivers MAY ignore Third Party Loss 242 Report messages, but SHOULD react to them unless they have good 243 reason to still send feedback messages despite having been requested 244 to suppress them. 246 4.1. Transport Layer Feedback: Third-party Loss Report 248 This Third Party Loss Report message is an extension to the RTCP 249 Transport Layer Feedback Report and identified by RTCP packet type 250 value PT=RTPFB and FMT=TBD. 252 The FCI field MUST contain one or more entries of transport layer 253 third party loss Early Indication (TLLEI). Each entry applies to a 254 different media source, identified by its SSRC. 256 The Feedback Control Information (FCI) for TLLEI uses the similar 257 format of message Types defined in the section 6.2.1 of [RFC4585]. 258 The format is shown in Figure 1. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | PID | BLP | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 1: Message Format for the Third Party Loss Report 268 Packet ID (PID): 16 bits 270 The PID field is used to specify a lost packet. The PID field 271 refers to the RTP sequence number of the lost packet. 273 bitmask of proceeding lost packets (BLP): 16 bits 275 The BLP allows for reporting losses of any of the 16 RTP packets 276 immediately following the RTP packet indicated by the PID. The 277 BLP's definition is identical to that given in [RFC4585]. 279 4.2. Payload Specific Feedback: Third-party Loss Report 281 This message is an extension to the RTCP Payload Specific Feedback 282 report and identified by RTCP packet type value PT=PSFB and FMT=TBD. 284 The FCI field MUST contain a Payload Specific Third Party Loss Early 285 Indication (PSLEI) entry. Each entry applies to a different media 286 source, identified by its SSRC. 288 The Feedback Control Information (FCI) for PSLEI uses the similar 289 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 290 The format is shown in Figure 2. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | SSRC | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Seq nr. | Reserved | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 2: Message Format for the Third Party Loss Report 302 SSRC (32 bits): 304 The SSRC value of the media source that is requested to send a 305 decoder refresh point. 307 Seq nr:8bits Command sequence number. The sequence number space is 308 unique for each pairing of the SSRC of command source and the SSRC 309 of the command target. The sequence number SHALL be increased by 310 1 modulo 256 for each new request. 312 Reserved: 24 bits 314 All bits SHALL be set to 0 by the media source and SHALL be 315 ignored on reception. 317 5. SDP Signaling 319 A new feedback value "tplr" needs to be defined for the Third Party 320 Loss Report message to be used with Session Description Protocol 321 (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) 322 [RFC4585]. 324 The "tplr" feedback value SHOULD be used with parameters that 325 indicate the third party loss supported. In this document, we define 326 two such parameter, namely: 328 o "tllei" denotes support of transport layer third party loss early 329 indication (fsei). 331 o "pslei" denotes support of payload specific third party loss early 332 indication. 334 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 335 placeholder called rtcp-fb-id to define new feedback types. "tplr" is 336 defined as a new feedback type in this document, and the ABNF for the 337 parameters for tplr is defined here (please refer to section 4.2 of 338 [RFC4585] for complete ABNF syntax). 340 rtcp-fb-val =/ "tplr" rtcp-fb-tplr-param 341 rtcp-fb-tplr-param = SP "tllei";transport layer third party loss early indication 342 / SP "pslei";payload specific third party loss early indication 343 / SP token [SP byte-string] 344 ; for future commands/indications 345 byte-string = 347 Refer to Section 4.2 of [RFC4585] for a detailed description and the 348 full syntax of the "rtcp-fb" attribute. 350 6. Example Use Cases 352 The operation of feedback suppression is similar for all types of RTP 353 sessions and topologies [RFC5117], however the exact messages used 354 and the scenarios in which suppression is employed differ for various 355 use cases. The following sections outline the intended use cases of 356 using Third Party Loss Report for feedback suppression and give an 357 overview of the particular mechanisms. 359 6.1. Source Specific Multicast (SSM) use case 361 In SSM RTP sessions as described in [RFC5760], one or more Media 362 Sources send RTP packets to a Distribution Source. The Distribution 363 Source relays the RTP packets to the receivers using a source- 364 specific multicast group. 366 In order to avoid the forms of Feedback implosion described in 367 section 1,the distribution source should be told that the indicated 368 packets were lost. How the distribution source know the indicated 369 packets were lost is beyond of scope of this document. When one 370 downstream receiver reports loss, the distribution source creates a 371 Third Party Loss Report and sent it to all the RTP receivers, over 372 the multicast channel. Another possibility is when there may be 373 multiple distribution sources placed between the media source and the 374 receivers, each distribution source may send its own Third Party Loss 375 report to downstream receivers respectively when downstream loss is 376 reported to each distribution source. And also the upstream 377 distribution source may inform downstream distribution sources in the 378 path of the detected packet loss using the Third Party Loss Report 379 messages. In response, if the upstream Third Party Loss Report 380 reports the different event, the downstream distribution sources 381 forward Third Party Loss Report received from upstream to all the RTP 382 receivers, over the multicast channel. If the same event is reported 383 both from upstream distribution source and from downstream receiver, 384 the downstream distribution source may suppress creating and sending 385 its own report to the relevant RTP receivers. This Third Party Loss 386 Report message tells the receivers that the sender of the third party 387 loss report has received reports that the indicated packets were 388 lost. The distribution source then can (optionally) ask for the lost 389 packets from the media source or itself on behalf of all the RTP 390 receivers. The lost packets will either be forthcoming from 391 distribution source, or it irretrievably lost such that there is 392 nothing to be gained by the receiver sending a NACK to the media 393 source. 395 The distribution source must be able to communicate with all group 396 members in order for either mechanism to be effective at suppressing 397 feedback. 399 As outlined in the [RFC5760], there are two Unicast Feedback models 400 that may be used for reporting, - the Simple Feedback model and the 401 Distribution Source Feedback Summary Model. The RTCP Feedback 402 extension for Third Party Loss Report specified in the Section 4 of 403 this document will work in both Feedback models. Details of 404 operation in each are specified below. 406 6.1.1. Simple Feedback Model 408 In the simple Feedback Model, NACKs from the receiver observing the 409 loss will be reflected to the other receivers, and there's no need 410 for distribution source to create the third-party loss report. The 411 distribution source that has not seen the actual packet loss should 412 pass through any Third Party Loss Report message it receives from the 413 upstream direction. 415 This RTCP Third Party Loss Report message lets the receivers know 416 that the sender of the Third party Loss Report has received reports 417 that the indicated packets were lost and feedback for this packet 418 loss is not needed and should not be sent to the media source(s). If 419 the media source(s) are part of the SSM group for RTCP packet 420 reflection, the Distribution Source must filter this packet out. If 421 the media source(s) are not part of the SSM group for RTCP packets, 422 the Distribution Source must not forward this RTCP Third Party Loss 423 Report message to the media source(s). 425 6.1.2. Distribution Source Feedback Summary Model 427 In the distribution source feedback summary model, there may be 428 multiple distribution sources who see the actual packet loss In this 429 section, we focus on this generic case to discuss the distribution 430 Source Feedback Summary Model. 432 The distribution source A must listen on the RTP channel for data. 433 When the distribution source A observes RTP packets from a media 434 source are not consecutive by checking the sequence number of 435 packets, the distribution source A generates the NACK message, and 436 then send it to receivers in the downstream path via the multicast 437 channel. 439 The Distribution Source B must also listen for RTCP data sent to the 440 RTCP port. Upon receiving the RTCP Third Party Loss Report from the 441 Distribution Source A, the Distribution Source B needs to check 442 whether it sees the same event reported both from upstream 443 distribution source A and downstream receiver. If the upstream Third 444 Party Loss Report reports the different event, the distribution 445 source B passes through any Third Party Loss Report message it 446 receives from the upstream direction. If the same event is reported 447 from both distribution source A and downstream receiver of 448 distribution source B, the distribution source B may suppress 449 creating and sending its own report with the same event to the 450 downstream RTP receiver. 452 Also the Distribution Source B may create and send its own Third 453 Party Loss Report described in the Section 4 to the group over the 454 multicast RTCP channel in response to NACKs received from downstream. 455 if downstream loss is reported using NACK to the distribution source 456 B. 458 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 459 case 461 The typical RAMS architecture 462 [I-D.ietf-avt-rapid-acquisition-for-rtp] may have several Burst/ 463 Retransmission Sources(BRS) behind the multicast source (MS) These 464 BRSes will receive the multicast SSM stream from the media source. 465 If one of the BRSes receives downstream loss report (i.e., First loss 466 in Figure 3) on its downstream link, but the others BRSes have not, 467 as the packet loss took place on the SSM tree branch that does not 468 impact the other BRSes. In such case, the BRSes not being impacted 469 are not aware of downstream loss at their downstream link, therefore 470 these BRSes will not create new Third Party Loss Report message and 471 send it to receivers in their downstream path. If the BRS impacted 472 by packet loss has been told the actual packet loss, the BRS MAY 473 choose to create new Third Party Loss Report message and send it to 474 the receivers in the downstream link. Note that BRS must use its own 475 SSRC as packet sender SSRC for transmitting the feedback suppress 476 message. 478 The BRS may also send a NACK upstream to request the retransmitted 479 packet. Upon receiving the retransmitted packet, the BRS sent it 480 downstream. Note that this retransmitted packet may get lost (i.e., 481 second loss in the Figure 3) on the downstream link. In order to 482 deal with this issue, the downstream receiver can start a timeout 483 clock in which it expected to get a retransmission packet. When this 484 timeout expires and there is no retransmitted packet or a new Third 485 Party Loss Report message, it can take its normal behavior as if 486 there is no current retransmission suppression in place. 488 +------------+ First Loss +----------+ 489 |Burst and |Second Loss | | 490 +-----------| Retrans. |----X--X--->| | 491 | Upstream |Source1(BRS)| Downstream | | 492 Link close | link 1 +------------+ link 1 | | 493 to multicast | | | 494 source | | | 495 | | | | 496 | | +------------+ | RTP | 497 +---------+ | +-----++ |Burst and | | Receiver | 498 |Multicast| V| | +----------| Retrans. |----------->| | 499 | Source +-----|Router|Upstream |Source2(BRS)| Downstream | RTP_Rx | 500 +---------+ | |link 2 +------------+ link 2 | | 501 +-----++ | | 502 | | | 503 | | | 504 | | | 505 | +------------+ | | 506 | |Burst and | | | 507 +-----------+ Retrans. |----------->| | 508 Upstream |Source k(BRS| Downstream | | 509 link k +------------+ link k +----------+ 511 Figure 3: RAMS Use Case 513 6.3. RTP transport translator use case 515 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 516 is typically forwarding the RTP and RTCP traffic between RTP clients, 517 for example converting between multicast and unicast for domains that 518 do not support multicast. The translator can identify packet loss 519 from the upstream and send the Third Party Loss Report message to the 520 unicast receivers. Note that the translator must be a participant in 521 the session and can then use it's own SSRC as packet sender SSRC for 522 transmitting the Third Party Loss Report message 524 6.4. Multipoint Control Unit (MCU) use case 526 In point to multipoint topologies using video switching MCU (Topo- 527 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 528 media stream to each participant, selected from the available input 529 streams. The selection of the input stream is often based on voice 530 activity in the audio-visual conference, but other conference 531 management mechanisms (like presentation mode or explicit floor 532 control) exist as well. 534 In this case the MCU may detect packet loss from the sender or may 535 decide to switch to a new source. In both cases the receiver may 536 lose synchronization with the video stream and may send a FIR 537 request. If the MCU itself can detect the mis-synchronization of the 538 video, the MCU can send the FIR suppression message to the receivers 539 and send a FIR request to the video source. As suggested in RFC 540 5117, this topology is better implemented as an Topo-mixer, in which 541 case the mixer's SSRC is used as packet sender SSRC for transmitting 542 Third Party Loss Report message. 544 7. Security Considerations 546 The defined messages have certain properties that have security 547 implications. These must be addressed and taken into account by 548 users of this protocol. 550 Spoofed or maliciously created feedback messages of the type defined 551 in this specification can have the following implications: 553 Sending Third Party Loss Report with wrong sequence number of lost 554 packet that makes missing RTP packets can not be compensated. 556 To prevent these attacks, there is a need to apply authentication and 557 integrity protection of the feedback messages. This can be 558 accomplished against threats external to the current RTP session 559 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 560 into SAVPF [RFC5124]. 562 Note that middleboxes that are not visible at the RTP layer that wish 563 to send Third Party Loss Reports on behalf of the media source can 564 only do so if they spoof the SSRC of the media source. This is 565 difficult in case SRTP is in use. If the middlebox is visible at the 566 RTP layer, this is not an issue, provided the middlebox is part of 567 the security context for the session. 569 Also note that endpoints that receive a Third Party Loss Report would 570 be well-advised to ignore it, unless it is authenticated via SRTCP or 571 similar. Accepting un-authenticated Third Party Loss Report can lead 572 to a denial of service attack, where the endpoint accepts poor 573 quality media that could be repaired. 575 8. IANA Consideration 577 New feedback type and New parameters for RTCP Third Party Loss Report 578 are subject to IANA registration. For general guidelines on IANA 579 considerations for RTCP feedback, refer to [RFC4585]. 581 This document assigns one new feedback type value x in the RTCP 582 feedback report registry to "Third Party Loss Report" with the 583 following registrations format: 585 Name: TPLR 586 Long Name: Third Party Loss Report 587 Value: TBD 588 Reference: This document. 590 This document also assigns the parameter value y in the RTCP TPLR 591 feedback report Registry to " Transport Layer Third Party Loss Early 592 Indication ", with the following registrations format: 594 Name: TLLEI 595 Long name: Transport Layer Third Party Loss Early Indication 596 Value: TBD 597 Reference: this document. 599 This document also assigns the parameter value z in the RTCP TPLR 600 feedback report Registry to "Payload Specific Third Party Loss Early 601 Indication ", with the following registrations format: 603 Name: PSLEI 604 Long name: Payload Specific Third Party Loss Early Indication 605 Value: TBD 606 Reference: this document. 608 The contact information for the registrations is: 610 Qin Wu 611 sunseawq@huawei.com 612 101 Software Avenue, Yuhua District 613 Nanjing, Jiangsu 210012, China 615 9. Acknowledgement 617 The authors would like to thank David R Oran, Ali C. Begen, Colin 618 Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, 619 Jonathan Lennox, WeeSan Lee for their valuable comments and 620 suggestions on this document. 622 10. References 624 10.1. Normative References 626 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 627 Protocol (RTCP) Extensions for Single-Source Multicast 628 Sessions with Unicast Feedback", RFC 5760, February 2010. 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, March 1997. 633 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 634 "Extended RTP Profile for Real-time Transport Control 635 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 636 July 2006. 638 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 639 Jacobson, "RTP: A Transport Protocol for Real-Time 640 Applications", STD 64, RFC 3550, July 2003. 642 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 643 January 2008. 645 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 646 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 647 July 2006. 649 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 650 Description Protocol", RFC 4566, July 2006. 652 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 653 Specifications: ABNF", STD 68, RFC 5234, January 2008. 655 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 656 "Codec Control Messages in the RTP Audio-Visual Profile 657 with Feedback (AVPF)", RFC 5104, February 2008. 659 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 660 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 661 RFC 3711, March 2004. 663 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 664 Real-time Transport Control Protocol (RTCP)-Based Feedback 665 (RTP/SAVPF)", RFC 5124, February 2008. 667 10.2. Informative References 669 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 670 "NACK-Oriented Reliable Multicast (NORM) Transport 671 Protocol", November 2009. 673 [DVB-IPTV] 674 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 675 of MPEG-2 TS Based DVB Services over IP Based Networks", 676 ETSI TS 102 034, V1.4.1 , August 2009. 678 [I-D.ietf-avt-rapid-acquisition-for-rtp] 679 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 680 Based Rapid Acquisition of Multicast RTP Sessions", 681 November 2010. 683 [I-D.hunt-avt-monarch-01] 684 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 685 August 2008. 687 [I-D.ietf-pmol-metrics-framework-02] 688 Clark, A., "Framework for Performance Metric Development". 690 Appendix A. Appendix A. Change Log 692 Note to the RFC-Editor: please remove this section prior to 693 publication as an RFC. 695 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 697 The following are the major changes compared to previous version: 698 o Remove the merge report from SSM use case and addional text to 699 address report merging issue. 701 o Revise section 3 and section 6 to address FEC packet dealing issue 702 and Leave how to repair packet loss beyond the scope. 703 o Modify the SSM use case and RAMS use case to focus on uses. 704 o Other Editorial changes. 706 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 708 The following are the major changes compared to previous version: 709 o In Appendix A, fix typo: Appendix A. Appendix A. -> Appdendix A. 710 o In Section 4.1, fix typo: Section 4.3.1.1 of section [RFC5104]-> 711 section 6.2.1 of [RFC4585]. 712 o In Section 3: Clarify how to deal with downstream loss using Third 713 party loss report and upstream loss using NACK. 714 o Update title and abstract to focus on third party loss report. 715 o In Section 6.1: Update this section to explain how third party 716 loss report is used to deal with downstream loss. 717 o In section 6.1.2: Update this section to explain how third party 718 loss report is used to deal with downstream loss. 719 o In section 6.2: Rephrase the text to discuss how BRS deal with the 720 third party loss report. 722 Authors' Addresses 724 Qin Wu 725 Huawei 726 101 Software Avenue, Yuhua District 727 Nanjing, Jiangsu 210012 728 China 730 Email: sunseawq@huawei.com 732 Frank Xia 733 Huawei 734 1700 Alma Dr. Suite 500 735 Plano, TX 75075 736 USA 738 Phone: +1 972-509-5599 739 Email: xiayangsong@huawei.com 740 Roni Even 741 Huawei 742 14 David Hamelech 743 Tel Aviv 64953 744 Israel 746 Email: even.roni@huawei.com