idnits 2.17.1 draft-ietf-avtcore-feedback-supression-rtp-05.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 (July 11, 2011) is 4673 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 569, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC5740' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework' is defined on line 617, 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) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: January 12, 2012 Huawei 6 July 11, 2011 8 RTCP Extension for Third-party Loss Report 9 draft-ietf-avtcore-feedback-supression-rtp-05 11 Abstract 13 In a large RTP session using the RTCP feedback mechanism defined in 14 RFC 4585, a feedback target may experience transient overload if some 15 event causes a large number of receivers to send feedback at once. 16 This overload is usually avoided by ensuring that feedback reports 17 are forwarded to all receivers, allowing them to avoid sending 18 duplicate feedback reports. However, there are cases where it is not 19 recommended to forward feedback reports, and this may allow feedback 20 implosion. This memo discusses these cases and defines a new RTCP 21 third-party loss report that can be used to inform receivers that a 22 feedback target is aware of some loss event, allowing them to 23 suppress feedback. Associated SDP signalling is also defined. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 12, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 6 75 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 6 76 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 7 77 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 79 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9 80 6.2. Unicast based Rapid Acquisition of Multicast Stream 81 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 10 82 6.3. RTP transport translator use case . . . . . . . . . . . . 11 83 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 11 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12 86 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 91 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 15 92 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 15 93 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 16 94 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 16 95 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 RTCP feedback messages [RFC4585] allow the receivers in an RTP 101 session to report events and ask for action from the media source (or 102 a delegated feedback target when using unicast RTCP feedback with SSM 103 [RFC5760]). There are cases where multiple receivers may initiate 104 the same, or an equivalent message towards the same media source. 105 When the receiver count is large, this behavior may cause transient 106 overload of the media source, the network or both. This is known as 107 a "feedback storm" or a "NACK storm". One common cause of such a 108 feedback storm is receivers utilizing RTP retransmission [RFC4588] as 109 a packet loss recovery technique based, sending feedback using RTCP 110 NACK messages [RFC4585] without proper dithering of the 111 retransmission requests. 113 Another use case involves video Fast Update requests. A storm of 114 these feedback messages can occur in conversational multimedia 115 scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, 116 packet loss may happen on an upstream link of an intermediate network 117 element such as a Multipoint Control Unit(MCU). Poorly designed 118 receivers that blindly issue fast update requests (i.e., Full Intra 119 Request (FIR) described in [RFC5104]), can cause an implosion of FIR 120 requests from receivers to the same media source. 122 RTCP feedback storms may cause short term overload, and in extreme 123 cases to pose a possible risk of increasing network congestion on the 124 control channel (e.g. RTCP feedback), the data channel, or both. It 125 is therefore desirable to provide a way of suppressing unneeded 126 feedback. 128 One approach to this, suggested in [DVB-IPTV], involves sending a 129 NACK message to the other clients (or receiver) in the same group as 130 the sender of NACK. However NACK is defined as a receiver report 131 sent from a receiver observing a packet loss, therefore it only 132 inform others that sender of NACK detected loss while the case the 133 sender of the feedback has received reports that the indicated 134 packets were lost is not covered. This document specifies a new 135 third-party loss report for this function. It further is more 136 precise in the intended uses and less likely to be confusing to 137 receivers. It tells receivers explicitly that feedback for a 138 particular packet or frame loss is not needed for a period of time 139 and can provide an early indication before the receiver reacts to the 140 loss and invokes its packet loss repair machinery. Section 6 141 provides some examples of when to send the third party loss report 142 message. 144 2. Terminology 146 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Protocol Overview 152 This document extends the RTCP feedback messages defined in the 153 Audio-Visual Profile with feedback (RTP/AVPF) [RFC4585] defining a 154 Third Party Loss Report message. The Third Party Loss Report message 155 can be used by the media source or intermediaries to inform the 156 receiver that the sender of the Third Party Loss Report has received 157 reports that the indicated packets were lost, and asks the receiver 158 not to send feedback to it regarding these packets. 160 When a receiver gets a Third Party Loss Report message, it should 161 refrain from sending a feedback request (e.g., NACK or FIR) for the 162 missing packets reported in the message for a period of time. A 163 receiver may still have sent a Feedback message according to the RTP/ 164 AVPF scheduling algorithm of [RFC4585]before receiving a Third Party 165 Loss Report message, but further feedback messages for those sequence 166 numbers will be suppressed by this technique for a period of time. 167 Nodes that do not understand the Third Party Loss Report message will 168 ignore it, and might therefore still send feedback according to the 169 AVPF scheduling algorithm of [RFC4585]. The media source or 170 intermediate nodes cannot assume that the use of a Third Party Loss 171 Report message actually reduces the amount of feedback it receives. 173 RTCP Third Party Loss Report follows the similar format of message 174 type as RTCP NACK. However, the third party loss report is defined 175 as an indication that the sender of the feedback has received reports 176 that the indicated packets were lost, while NACK [RFC4585] just 177 indicates that the sender of the NACK observed that these packets 178 were lost. The Third Party Loss Report message is generated by a 179 system that has not seen the actual packet loss. Systems that 180 receive a third party loss report SHOULD NOT initiate their own 181 additional Third Party Loss Report messages for the same packet 182 sequence numbers. They may either simply forward the Third Party 183 Loss Report message, or they may generate their own Third Party Loss 184 Report that reports a superset of the loss reported in the Third 185 Party Loss report they received. The Third Party Loss Report does 186 not have the retransmission request [RFC4588] semantics. 188 Since Third Party Loss Report interacts strongly with repair timing, 189 it has to work together with feedback to not adversely impact the 190 repair of lost source packets. One example is the middle box gets 191 the retransmitted packet by sending a NACK upstream and sent it 192 downstream. This retransmitted packet was lost on the downstream 193 link. In order to deal with this, the downstream receiver can start 194 a timeout in which it expected to get a retransmission packet. When 195 this timeout expires and there is no retransmitted packet or a new 196 third party loss report message, it can take its normal behavior as 197 if there is no current retransmission suppression. In this case when 198 the loss was detected and repair initiated much closer to the source, 199 the delay for the receiver to recover from packet loss can be reduced 200 through the combination of intermediary feedback to the source and 201 Third Party Loss Report downstream. 203 4. Format of RTCP Feedback Messages 205 This document registers two new RTCP Feedback messages for Third 206 Party Loss Report. Applications that are employing one or more loss- 207 repair methods MAY use Third Party Loss Report together with their 208 existing loss-repair methods either for every packet they expect to 209 receive, or for an application-specific subset of the RTP packets in 210 a session. In other words, receivers MAY ignore Third Party Loss 211 Report messages, but SHOULD react to them unless they have good 212 reason to still send feedback messages despite having been requested 213 to suppress them. 215 4.1. Transport Layer Feedback: Third-party Loss Report 217 This Third Party Loss Report message is an extension to the RTCP 218 Transport Layer Feedback Report and identified by RTCP packet type 219 value PT=RTPFB and FMT=TBD. 221 The FCI field MUST contain one or more entries of transport layer 222 third party loss Early Indication (TLLEI). Each entry applies to a 223 different media source, identified by its SSRC. 225 The Feedback Control Information (FCI) for TLLEI uses the similar 226 format of message Types defined in the section 6.2.1 of [RFC4585]. 227 The format is shown in Figure 1. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | PID | BLP | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 1: Message Format for the Third Party Loss Report 237 Packet ID (PID): 16 bits 239 The PID field is used to specify a lost packet. The PID field 240 refers to the RTP sequence number of the lost packet. 242 bitmask of proceeding lost packets (BLP): 16 bits 244 The BLP allows for reporting losses of any of the 16 RTP packets 245 immediately following the RTP packet indicated by the PID. The 246 BLP's definition is identical to that given in [RFC4585]. 248 4.2. Payload Specific Feedback: Third-party Loss Report 250 This message is an extension to the RTCP Payload Specific Feedback 251 report and identified by RTCP packet type value PT=PSFB and FMT=TBD. 253 The FCI field MUST contain a Payload Specific Third Party Loss Early 254 Indication (PSLEI) entry. Each entry applies to a different media 255 source, identified by its SSRC. 257 The Feedback Control Information (FCI) for PSLEI uses the similar 258 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 259 The format is shown in Figure 2. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | SSRC | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Seq nr. | Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2: Message Format for the Third Party Loss Report 271 SSRC (32 bits): 273 The SSRC value of the media source that is requested to send a 274 decoder refresh point. 276 Seq nr:8bits Command sequence number. The sequence number space is 277 unique for each pairing of the SSRC of command source and the SSRC 278 of the command target. The sequence number SHALL be increased by 279 1 modulo 256 for each new request. 281 Reserved: 24 bits 283 All bits SHALL be set to 0 by the media source and SHALL be 284 ignored on reception. 286 5. SDP Signaling 288 A new feedback value "tplr" needs to be defined for the Third Party 289 Loss Report message to be used with Session Description Protocol 290 (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) 291 [RFC4585]. 293 The "tplr" feedback value SHOULD be used with parameters that 294 indicate the third party loss supported. In this document, we define 295 two such parameter, namely: 297 o "tllei" denotes support of transport layer third party loss early 298 indication (fsei). 300 o "pslei" denotes support of payload specific third party loss early 301 indication. 303 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 304 placeholder called rtcp-fb-id to define new feedback types. "tplr" is 305 defined as a new feedback type in this document, and the ABNF for the 306 parameters for tplr is defined here (please refer to section 4.2 of 307 [RFC4585] for complete ABNF syntax). 309 rtcp-fb-val =/ "tplr" rtcp-fb-tplr-param 310 rtcp-fb-tplr-param = SP "tllei";transport layer third party loss early indication 311 / SP "pslei";payload specific third party loss early indication 312 / SP token [SP byte-string] 313 ; for future commands/indications 314 byte-string = 316 Refer to Section 4.2 of [RFC4585] for a detailed description and the 317 full syntax of the "rtcp-fb" attribute. 319 6. Example Use Cases 321 The operation of feedback suppression is similar for all types of RTP 322 sessions and topologies [RFC5117], however the exact messages used 323 and the scenarios in which suppression is employed differ for various 324 use cases. The following sections outline some of the intended use 325 cases for using Third Party Loss Report for feedback suppression and 326 give an overview of the particular mechanisms. 328 6.1. Source Specific Multicast (SSM) use case 330 In SSM RTP sessions as described in [RFC5760], one or more Media 331 Sources send RTP packets to a Distribution Source. The Distribution 332 Source relays the RTP packets to the receivers using a source- 333 specific multicast group. Note that each receiver sending multicast 334 NACK to its group may still need to send unicast NACK addressed to 335 the media source or distribution source , this may lead to a NACK 336 storm if feedback suppression is not performed and if the RTCP 337 bandwidth limit is misconfigured. 339 As outlined in the [RFC5760], there are two Unicast Feedback models 340 that may be used for reporting, - the Simple Feedback model and the 341 Distribution Source Feedback Summary Model. In the simple Feedback 342 Model, NACKs are reflected by the distribution source to the other 343 receivers, and there's no need for distribution source to create the 344 third-party loss report. The third-party loss report may be 345 generated at the distribution source when downstream loss report is 346 received in the Distribution Source Feedback Summary model, since 347 this summary feedback does not mandate the forwarding of NACK 348 downstream. 350 In order to observe packet loss before the receivers perceive it, one 351 or more intermediate nodes may be placed between the media source and 352 the receivers. These intermediaries monitor for upstream packet loss 353 . These intermediates may be Distribution source, MCUs, RTP 354 translator, or RTP mixers, depending on the precise implementation. 355 If an intermediary notices the loss itself, then it may send a NACK 356 both downstream towards the receivers and upstream towards the media 357 source, to indicate that it has noticed the loss, and to suppress 358 feedback from other downstream receivers. In the SSM case, If the 359 distribution source ,using the simple feedback model, receives a NACK 360 from another system (e.g.,an intermediary), it should redistribute 361 that NACK to all other systems that would not otherwise receive it. 362 If the distribution source, using the summary feedback model, 363 receives a NACK from another system, but, for some reason(e.g., to 364 prevent revealing the identity or existence of a system sending 365 NACK), cannot redistribute that NACK, then it may send a third-party 366 loss report to the systems that were unable to receive the NACK, and 367 won't receive the NACK via other means. . Therefore the intermediate 368 node can be reasonably certain that it will help the situation by 369 sending a Third Party Loss Report message to all the relevant 370 receivers, thereby indicating to the receivers that they should not 371 transmit feedback messages for a period of time. The intermediate 372 node needs to take into account such factors as the tolerable 373 application delay, packet loss recovery techniques, the network 374 dynamics, and the media type. Loss-repair methods such as 375 retransmission and Forward Error Correction may be used to recover 376 the missing packet. 378 Alternatively, the media source may directly monitor the amount of 379 feedback reports it receives from downstream. If the media source 380 notices the loss itself, then it may send a NACK downstream towards 381 the receivers to suppress feedback. If the media source receives a 382 NACK from another system, it should redistribute that NACK to all 383 other systems that would not otherwise receive it. If the media 384 source receives a NACK from another system, but, for some reason 385 (e.g., hiding identity or existing a system sending NACK, cannot 386 redistribute that NACK, then it may send a third-party loss report to 387 the systems that were unable to receive the NACK, and won't receive 388 the NACK via other means. 390 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 391 case 393 The typical RAMS architecture [RFC6285] may have several Burst/ 394 Retransmission Sources(BRS) behind the multicast source (MS) placed 395 at the same level. These BRSes will receive the multicast SSM stream 396 from the media source. If one of the BRSes receives downstream loss 397 report (i.e., First loss in Figure 3) on its downstream link, but the 398 others BRSes have not, as the packet loss took place on the SSM tree 399 branch that does not impact the other BRSes. In such case, the BRSes 400 not being impacted are not aware of downstream loss at their 401 downstream link, therefore these BRSes will not create new Third 402 Party Loss Report message and send it to receivers in their 403 downstream path. If the BRS impacted by packet loss has been told 404 the actual packet loss, the BRS MAY choose to create new Third Party 405 Loss Report message and send it to the receivers in the downstream 406 link. Note that BRS must use its own SSRC as packet sender SSRC for 407 transmitting the feedback suppress message. 409 The BRS may also send a NACK upstream to request the retransmitted 410 packet. Upon receiving the retransmitted packet, the BRS sent it 411 downstream. Note that this retransmitted packet may get lost (i.e., 412 second loss in the Figure 3) on the downstream link. In order to 413 deal with this issue, the downstream receiver can start a timeout 414 clock in which it expected to get a retransmission packet. When this 415 timeout expires and there is no retransmitted packet or a new Third 416 Party Loss Report message, it can take its normal behavior as if 417 there is no current retransmission suppression in place. 419 +------------+ First Loss +----------+ 420 |Burst and |Second Loss | | 421 +-----------| Retrans. |----X--X--->| | 422 | Upstream |Source1(BRS)| Downstream | | 423 Link close | link 1 +------------+ link 1 | | 424 to multicast | | | 425 source | | | 426 | | | | 427 | | +------------+ | RTP | 428 +---------+ | +-----++ |Burst and | | Receiver | 429 |Multicast| V| | +----------| Retrans. |----------->| | 430 | Source +-----|Router|Upstream |Source2(BRS)| Downstream | RTP_Rx | 431 +---------+ | |link 2 +------------+ link 2 | | 432 +-----++ | | 433 | | | 434 | | | 435 | | | 436 | +------------+ | | 437 | |Burst and | | | 438 +-----------+ Retrans. |----------->| | 439 Upstream |Source k(BRS| Downstream | | 440 link k +------------+ link k +----------+ 442 Figure 3: RAMS Use Case 444 6.3. RTP transport translator use case 446 A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] 447 is typically forwarding the RTP and RTCP traffic between RTP clients, 448 for example converting between multicast and unicast for domains that 449 do not support multicast. The translator can identify packet loss 450 using co-located monitor [I-D.ietf-avtcore-monarch] by receiving a 451 NACK from another system and then the monitor can use it's own SSRC 452 as packet sender SSRC for transmitting the Third Party Loss Report 453 message and send this message to the unicast receivers that is not 454 aware of packet loss. 456 6.4. Multipoint Control Unit (MCU) use case 458 In point to multipoint topologies using video switching MCU (Topo- 459 Video-switch-MCU) [RFC5117], the MCU typically forwards a single 460 media stream to each participant, selected from the available input 461 streams. The selection of the input stream is often based on voice 462 activity in the audio-visual conference, but other conference 463 management mechanisms (like presentation mode or explicit floor 464 control) exist as well. 466 In this case the MCU may identify packet loss by receiving a NACK 467 from another system or may decide to switch to a new source. In both 468 cases the receiver may lose synchronization with the video stream and 469 may send a FIR request. If the MCU itself can detect the mis- 470 synchronization of the video, the MCU can send the FIR suppression 471 message to the receivers and send a FIR request to the video source. 472 As suggested in RFC 5117, this topology is better implemented as an 473 Topo-mixer, in which case the mixer's SSRC is used as packet sender 474 SSRC for transmitting Third Party Loss Report message. 476 7. Security Considerations 478 The defined messages have certain properties that have security 479 implications. These must be addressed and taken into account by 480 users of this protocol. 482 Spoofed or maliciously created feedback messages of the type defined 483 in this specification can have the following implications: 485 Sending Third Party Loss Report with wrong sequence number of lost 486 packet that makes missing RTP packets can not be compensated. 488 To prevent these attacks, there is a need to apply authentication and 489 integrity protection of the feedback messages. This can be 490 accomplished against threats external to the current RTP session 491 using the RTP profile that combines Secure RTP [RFC3711] and AVPF 492 into SAVPF [RFC5124]. 494 Note that middleboxes that are not visible at the RTP layer that wish 495 to send Third Party Loss Reports on behalf of the media source can 496 only do so if they spoof the SSRC of the media source. This is 497 difficult in case SRTP is in use. If the middlebox is visible at the 498 RTP layer, this is not an issue, provided the middlebox is part of 499 the security context for the session. 501 Also note that endpoints that receive a Third Party Loss Report would 502 be well-advised to ignore it, unless it is authenticated via SRTCP or 503 similar. Accepting un-authenticated Third Party Loss Report can lead 504 to a denial of service attack, where the endpoint accepts poor 505 quality media that could be repaired. 507 8. IANA Consideration 509 New feedback type and New parameters for RTCP Third Party Loss Report 510 are subject to IANA registration. For general guidelines on IANA 511 considerations for RTCP feedback, refer to [RFC4585]. 513 This document assigns one new feedback type value x in the RTCP 514 feedback report registry to "Third Party Loss Report" with the 515 following registrations format: 517 Name: TPLR 518 Long Name: Third Party Loss Report 519 Value: TBD 520 Reference: This document. 522 This document also assigns the parameter value y in the RTCP TPLR 523 feedback report Registry to " Transport Layer Third Party Loss Early 524 Indication ", with the following registrations format: 526 Name: TLLEI 527 Long name: Transport Layer Third Party Loss Early Indication 528 Value: TBD 529 Reference: this document. 531 This document also assigns the parameter value z in the RTCP TPLR 532 feedback report Registry to "Payload Specific Third Party Loss Early 533 Indication ", with the following registrations format: 535 Name: PSLEI 536 Long name: Payload Specific Third Party Loss Early Indication 537 Value: TBD 538 Reference: this document. 540 The contact information for the registrations is: 542 Qin Wu 543 sunseawq@huawei.com 544 101 Software Avenue, Yuhua District 545 Nanjing, Jiangsu 210012, China 547 9. Acknowledgement 549 The authors would like to thank David R Oran, Ali C. Begen, Colin 550 Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, 551 Jonathan Lennox, WeeSan Lee for their valuable comments and 552 suggestions on this document. 554 10. References 555 10.1. Normative References 557 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 558 Protocol (RTCP) Extensions for Single-Source Multicast 559 Sessions with Unicast Feedback", RFC 5760, February 2010. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 565 "Extended RTP Profile for Real-time Transport Control 566 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 567 July 2006. 569 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 570 Jacobson, "RTP: A Transport Protocol for Real-Time 571 Applications", STD 64, RFC 3550, July 2003. 573 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 574 January 2008. 576 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 577 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 578 July 2006. 580 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 581 Description Protocol", RFC 4566, July 2006. 583 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 584 Specifications: ABNF", STD 68, RFC 5234, January 2008. 586 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 587 "Codec Control Messages in the RTP Audio-Visual Profile 588 with Feedback (AVPF)", RFC 5104, February 2008. 590 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 591 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 592 RFC 3711, March 2004. 594 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 595 Real-time Transport Control Protocol (RTCP)-Based Feedback 596 (RTP/SAVPF)", RFC 5124, February 2008. 598 10.2. Informative References 600 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 601 "NACK-Oriented Reliable Multicast (NORM) Transport 602 Protocol", November 2009. 604 [DVB-IPTV] 605 ETSI Standard, "Digital Video Broadcasting(DVB); Transport 606 of MPEG-2 TS Based DVB Services over IP Based Networks", 607 ETSI TS 102 034, V1.4.1 , August 2009. 609 [RFC6285] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 610 Based Rapid Acquisition of Multicast RTP Sessions", 611 June 2011. 613 [I-D.ietf-avtcore-monarch] 614 Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures 615 for RTP", June 2011. 617 [I-D.ietf-pmol-metrics-framework] 618 Clark, A. and B. Claise, "Framework for Performance Metric 619 Development", January 2011. 621 Appendix A. Change Log 623 Note to the RFC-Editor: please remove this section prior to 624 publication as an RFC. 626 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 628 The following are the major changes compared to previous version: 630 o Remove the merge report from SSM use case and additional text to 631 address report merging issue. 633 o Revise section 3 and section 6 to address FEC packet dealing issue 634 and Leave how to repair packet loss beyond the scope. 636 o Modify the SSM use case and RAMS use case to focus on uses. 638 o Other Editorial changes. 640 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 642 The following are the major changes compared to previous version: 644 o In Section 4.1, fix typo: Section 4.3.1.1 of section [RFC5104]-> 645 section 6.2.1 of [RFC4585]. 647 o In Section 3: Clarify how to deal with downstream loss using Third 648 party loss report and upstream loss using NACK. 650 o Update title and abstract to focus on third party loss report. 652 o In Section 6.1: Update this section to explain how third party 653 loss report is used to deal with downstream loss. 655 o In section 6.1.2: Update this section to explain how third party 656 loss report is used to deal with downstream loss. 658 o In section 6.2: Rephrase the text to discuss how BRS deal with the 659 third party loss report. 661 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 663 The following are the major changes compared to previous version: 665 o In Appendix A, fix typo: Appendix A. Appendix A. -> Appendix A. 667 o Update abstract to clarify when third-party loss reports should be 668 sent instead of NACKs. 670 o Update section 3 Paragraph 2 to differentiate when a third-party 671 loss report should be used compared to a NACK. 673 o Update section 3 Paragraph 3 to explain when media source to send 674 a third-party loss. 676 o Move specific rules for section 6.1.1 and section 6.1.2 to section 677 6.1 as generic rules and delete section 6.1.1. 679 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 681 The following are the major changes compared to previous version: 682 o Reference Update. 684 o Clarify the use of the third party loss report in section 3 and 685 section 6.1.1. 687 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 689 The following are the major changes compared to previous version: 690 o Remove 3rd and 4th paragraphs of section 6.1 and replaced them 691 with 2nd and 3rd paragraphs of section 3. 693 o Remove section 6.1.1.1. 695 o Revise the last paragraph of section 1 to clarify the rationale of 696 using new message. 698 o Update RTP transport translator case in section 6.3 to correct the 699 use of the third party loss report. 701 o Update MCU case in section 6.4 to correct the use of the third 702 party loss report. 704 o Revise SSM use case to address multiple DS issue. 706 o References Update. 708 o Move one rationale on preventing sending unicast NACK in 709 introduction section to SSM case section. 711 o Other Editorial changes to section 6.1, 6.1.1, 6.2. 713 Authors' Addresses 715 Qin Wu 716 Huawei 717 101 Software Avenue, Yuhua District 718 Nanjing, Jiangsu 210012 719 China 721 Email: sunseawq@huawei.com 723 Frank Xia 724 Huawei 725 1700 Alma Dr. Suite 500 726 Plano, TX 75075 727 USA 729 Phone: +1 972-509-5599 730 Email: xiayangsong@huawei.com 732 Roni Even 733 Huawei 734 14 David Hamelech 735 Tel Aviv 64953 736 Israel 738 Email: even.roni@huawei.com