idnits 2.17.1 draft-ietf-avtcore-feedback-supression-rtp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There 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 12, 2011) is 4726 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 13, 2011 Huawei 6 May 12, 2011 8 RTCP Extension for Third-party Loss Report 9 draft-ietf-avtcore-feedback-supression-rtp-03 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 certain cases where 19 it is not possible to forward feedback reports, and this may allow 20 feedback implosion. This memo defines a new RTCP third-party loss 21 report that can be used to inform receivers that a feedback target is 22 aware of some loss event, allowing them to suppress feedback. 23 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 November 13, 2011. 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 . . . . . . . . . . . . . . . 7 75 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7 76 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 8 77 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 79 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9 80 6.1.1. Distribution Source Feedback Summary Model . . . . . . 11 81 6.2. Unicast based Rapid Acquisition of Multicast Stream 82 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 11 83 6.3. RTP transport translator use case . . . . . . . . . . . . 12 84 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 87 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 92 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16 93 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 17 94 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 RTCP feedback messages [RFC4585] allow the receivers in an RTP 100 session to report events and ask for action from the media source (or 101 a delegated feedback target defined in SSM [RFC5760]). There are 102 cases where multiple receivers may initiate the same, or an 103 equivalent message towards the same media source. When the receiver 104 count is large, this behavior may cause transient overload of the 105 media source, the network or both. This is known as a "feedback 106 storm" or a "NACK storm". One common cause of such a feedback storm 107 is receivers utilizing RTP retransmission [RFC4588] as a packet loss 108 recovery technique based, sending feedback using RTCP NACK messages 109 [RFC4585] without proper dithering of the retransmission requests. 111 Another use case involves video Fast Update requests. A storm of 112 these feedback messages can occur in conversational multimedia 113 scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, 114 packet loss may happen on an upstream link of an intermediate network 115 element such as a Multipoint Control Unit(MCU). Poorly designed 116 receivers that blindly issue fast update requests (i.e., Full Intra 117 Request (FIR) described in [RFC5104]), can cause an implosion of FIR 118 requests from receivers to the same media source. 120 RTCP feedback storms may cause short term overload, and in extreme 121 cases to pose a possible risk of increasing network congestion on the 122 control channel (e.g. RTCP feedback), the data channel, or both. It 123 is therefore desirable to provide a way of suppressing unneeded 124 feedback. 126 One approach to this, suggested in [DVB-IPTV], involves sending a 127 NACK message to the other clients (or receiver) in the same group as 128 the sender of NACK. However sending multicast NACK to the group can 129 not prevent large amount of unicast NACK addressed to the same media 130 source or middlebox, for example when the NACK is used as a 131 retransmission request [RFC4588]. Also NACK is defined as a receiver 132 report sent from a receiver observing a packet loss, therefore it 133 only inform others that sender of NACK detected loss while the case 134 the sender of the feedback has received reports that the indicated 135 packets were lost is not covered. This document specifies a new 136 message for this function. It further is more precise in the 137 intended uses and less likely to be confusing to receivers. It tells 138 receivers explicitly that feedback for a particular packet or frame 139 loss is not needed for a period of time and can provide an early 140 indication before the receiver reacts to the loss and invokes its 141 packet loss repair machinery. 143 2. Terminology 145 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Protocol Overview 151 This document extends the RTCP feedback messages defined in the 152 Audio-Visual Profile with Feedback (AVPF) and define the Third Party 153 Loss Report message. The Third Party Loss Report message informs the 154 receiver in the downstream path of the middlebox that the sender of 155 the Third Party Loss Report has received reports that the indicated 156 packets were lost and asks a receiver to not send feedback messages 157 for particular packets (indicated by their RTP sequence numbers) 158 independent of whether the receiver detected the packet loss or 159 detected a need for a decoder refresh point. 161 In order to observe packet loss before the receivers perceive it, one 162 or more intermediate nodes may be placed between the media source and 163 the receivers. These intermediates are variously referred to as 164 Distribution servers, MCUs, RTP translator, or RTP mixers, depending 165 on the precise use case. These intermediaries monitor for packet 166 loss upstream of themselves by checking RTP sequence numbers, just as 167 receivers do. Upon observing (or suspecting) an upstream loss, the 168 intermediary Should send NACK both downstream towards the receivers 169 and upstream towards the media source, to indicate that it has 170 noticed the loss, and to suppress feedback from other downstream 171 receivers. However, in some cases where packet loss occurs in the 172 downstream of these intermediates, it is not possible for them to 173 distribute the NACKs to all receivers since they are unable to 174 observe downstream loss. In such cases, downstream loss needs to be 175 firstly reported to the intermediary. When downstream loss is 176 reported to the intermediary, the intermediary SHOULD create and send 177 the Third Party Loss report to the other downstream receivers which 178 are not aware of the loss reports, to inform those receivers of the 179 loss and suppress their feedback. Therefore the intermediate node 180 can be reasonably certain that it will help the situation by sending 181 a Third Party Loss Report message to all the relevant receivers, 182 thereby indicating to the receivers that they should not transmit 183 feedback messages for a period of time. The intermediate node needs 184 to take into account such factors as the tolerable application delay, 185 packet loss recovery techniques, the network dynamics, and the media 186 type. Loss-repair methods such as retransmission and Forward Error 187 Correction may be used to recover the missing packet. 189 Alternatively, the media source may directly monitor the amount of 190 feedback reports it receives from downstream. Upon receiving 191 downstream loss report in the form of such feedback report which is 192 only destined for media source, the media source SHOULD create and 193 send the Third Party Loss Report messages to the other downstream 194 receivers which are not aware of the loss reports, to inform those 195 receivers of the loss and suppress their feedback. 197 When a receiver gets such a Third Party Loss Report message, it 198 should refrain from sending a feedback request (e.g., NACK or FIR) 199 for the missing packets reported in the message for a period of time. 200 A receiver may still have sent a Feedback message according to the 201 AVPF scheduling algorithm of [RFC4585]before receiving a Third Party 202 Loss Report message, but further feedback messages for those sequence 203 numbers will be suppressed by this technique for a period of time. 204 Nodes that do not understand the Third Party Loss Report message will 205 ignore it, and might therefore still send feedback according to the 206 AVPF scheduling algorithm of [RFC4585]. The media source or 207 intermediate nodes cannot assume that the use of a Third Party Loss 208 Report message actually reduces the amount of feedback it receives. 210 RTCP Third Party Loss Report follows the similar format of message 211 type as RTCP NACK. But unlike RTCP NACK, the third party loss report 212 is defined as an indication that the sender of the feedback has 213 received reports that the indicated packets were lost and conveys the 214 packet receipt/loss events at the sequence number level from the 215 middlebox to the receivers in the downstream path of middlebox while 216 NACK [RFC4585] just indicates that the sender of the NACK observed 217 that these packets were lost. The Third Party Loss Report message is 218 generated by RTP middlebox that has not seen the actual packet loss 219 and sent to the corresponding receivers. Intermediaries downstream 220 of an intermediary receiving the upstream report obviously SHOULD NOT 221 initiate their own additional Third Party Loss Report messages for 222 the same packet sequence numbers. They may either simply forward the 223 Third Party Loss Report message received from upstream, or send its 224 own Third Party Loss Report message that reflects the loss they have 225 been told. The Third Party Loss Report does not have the 226 retransmission request [RFC4588] semantics. 228 Since Third Party Loss Report interacts strongly with repair timing, 229 it has to work together with feedback to not adversely impact the 230 repair of lost source packets. One example is the middle box gets 231 the retransmitted packet by sending a NACK upstream and sent it 232 downstream. This retransmitted packet was lost on the downstream 233 link. In order to deal with this, the downstream receiver can start 234 a timeout in which it expected to get a retransmission packet. When 235 this timeout expires and there is no retransmitted packet or a new 236 third party loss report message, it can take its normal behavior as 237 if there is no current retransmission suppression. In some cases 238 where the loss was detected and repair initiated much closer to the 239 source, the delay for the receiver to recover from packet loss can be 240 reduced through the combination of intermediary feedback to the 241 source and Third Party Loss Report downstream. In all (properly 242 operating) cases, the risk of increasing network congestion is 243 decreased. 245 4. Format of RTCP Feedback Messages 247 This document registers two new RTCP Feedback messages for Third 248 Party Loss Report. Applications that are employing one or more loss- 249 repair methods MAY use Third Party Loss Report together with their 250 existing loss-repair methods either for every packet they expect to 251 receive, or for an application-specific subset of the RTP packets in 252 a session. In other words, receivers MAY ignore Third Party Loss 253 Report messages, but SHOULD react to them unless they have good 254 reason to still send feedback messages despite having been requested 255 to suppress them. 257 4.1. Transport Layer Feedback: Third-party Loss Report 259 This Third Party Loss Report message is an extension to the RTCP 260 Transport Layer Feedback Report and identified by RTCP packet type 261 value PT=RTPFB and FMT=TBD. 263 The FCI field MUST contain one or more entries of transport layer 264 third party loss Early Indication (TLLEI). Each entry applies to a 265 different media source, identified by its SSRC. 267 The Feedback Control Information (FCI) for TLLEI uses the similar 268 format of message Types defined in the section 6.2.1 of [RFC4585]. 269 The format is shown in Figure 1. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | PID | BLP | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 1: Message Format for the Third Party Loss Report 279 Packet ID (PID): 16 bits 281 The PID field is used to specify a lost packet. The PID field 282 refers to the RTP sequence number of the lost packet. 284 bitmask of proceeding lost packets (BLP): 16 bits 286 The BLP allows for reporting losses of any of the 16 RTP packets 287 immediately following the RTP packet indicated by the PID. The 288 BLP's definition is identical to that given in [RFC4585]. 290 4.2. Payload Specific Feedback: Third-party Loss Report 292 This message is an extension to the RTCP Payload Specific Feedback 293 report and identified by RTCP packet type value PT=PSFB and FMT=TBD. 295 The FCI field MUST contain a Payload Specific Third Party Loss Early 296 Indication (PSLEI) entry. Each entry applies to a different media 297 source, identified by its SSRC. 299 The Feedback Control Information (FCI) for PSLEI uses the similar 300 format of message Types defined in the section 4.3.1.1 of [RFC5104]. 301 The format is shown in Figure 2. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | SSRC | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Seq nr. | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2: Message Format for the Third Party Loss Report 313 SSRC (32 bits): 315 The SSRC value of the media source that is requested to send a 316 decoder refresh point. 318 Seq nr:8bits Command sequence number. The sequence number space is 319 unique for each pairing of the SSRC of command source and the SSRC 320 of the command target. The sequence number SHALL be increased by 321 1 modulo 256 for each new request. 323 Reserved: 24 bits 325 All bits SHALL be set to 0 by the media source and SHALL be 326 ignored on reception. 328 5. SDP Signaling 330 A new feedback value "tplr" needs to be defined for the Third Party 331 Loss Report message to be used with Session Description Protocol 332 (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) 333 [RFC4585]. 335 The "tplr" feedback value SHOULD be used with parameters that 336 indicate the third party loss supported. In this document, we define 337 two such parameter, namely: 339 o "tllei" denotes support of transport layer third party loss early 340 indication (fsei). 342 o "pslei" denotes support of payload specific third party loss early 343 indication. 345 In the ABNF for rtcp-fb-val defined in [RFC4585], there is a 346 placeholder called rtcp-fb-id to define new feedback types. "tplr" is 347 defined as a new feedback type in this document, and the ABNF for the 348 parameters for tplr is defined here (please refer to section 4.2 of 349 [RFC4585] for complete ABNF syntax). 351 rtcp-fb-val =/ "tplr" rtcp-fb-tplr-param 352 rtcp-fb-tplr-param = SP "tllei";transport layer third party loss early indication 353 / SP "pslei";payload specific third party loss early indication 354 / SP token [SP byte-string] 355 ; for future commands/indications 356 byte-string = 358 Refer to Section 4.2 of [RFC4585] for a detailed description and the 359 full syntax of the "rtcp-fb" attribute. 361 6. Example Use Cases 363 The operation of feedback suppression is similar for all types of RTP 364 sessions and topologies [RFC5117], however the exact messages used 365 and the scenarios in which suppression is employed differ for various 366 use cases. The following sections outline the intended use cases of 367 using Third Party Loss Report for feedback suppression and give an 368 overview of the particular mechanisms. 370 6.1. Source Specific Multicast (SSM) use case 372 In SSM RTP sessions as described in [RFC5760], one or more Media 373 Sources send RTP packets to a Distribution Source. The Distribution 374 Source relays the RTP packets to the receivers using a source- 375 specific multicast group. 377 As outlined in the [RFC5760], there are two Unicast Feedback models 378 that may be used for reporting, - the Simple Feedback model and the 379 Distribution Source Feedback Summary Model. In the simple Feedback 380 Model, NACKs are reflected by the distribution source to the other 381 receivers, and there's no need for distribution source to create the 382 third-party loss report. The third-party loss report is only 383 generated at the distribution source when downstream loss report is 384 received in Distribution Source Feedback Summary model. Therefore 385 the RTCP extension for Third Party Loss Report specified in the 386 Section 4 of this document only works in Distribution Source Feedback 387 models. Details of operation are specified in Section 6.1.1. 389 In order to avoid the forms of Feedback implosion described in 390 section 1,the distribution source should be told that the indicated 391 packets were lost. When one downstream receiver reports loss, the 392 distribution source creates a Third Party Loss Report and sent it to 393 all the other RTP receivers which are not aware of feedback report, 394 over the multicast channel. Another possibility is when there may be 395 multiple distribution sources placed between the media source and the 396 receivers, each distribution source may send its own Third Party Loss 397 report to downstream receivers respectively when downstream loss is 398 reported to each distribution source. And also the upstream 399 distribution source may inform downstream distribution sources in the 400 path of the detected packet loss using the Third Party Loss Report 401 messages. In response, if the upstream Third Party Loss Report 402 reports the different event, the downstream distribution sources 403 forward Third Party Loss Report received from upstream to all the RTP 404 receivers, over the multicast channel. If the same event is reported 405 both from upstream distribution source and from the downstream 406 receiver, the downstream distribution source may suppress creating 407 and sending its own report to the relevant RTP receivers. This Third 408 Party Loss Report message tells the receivers that the sender of the 409 third party loss report has received reports that the indicated 410 packets were lost. The distribution source then can (optionally) ask 411 for the lost packets from the media source or itself on behalf of all 412 the RTP receivers. The lost packets will either be forthcoming from 413 distribution source, or it irretrievably lost such that there is 414 nothing to be gained by the receiver sending a NACK to the media 415 source. 417 The distribution source must be able to communicate with all group 418 members in order for either mechanism to be effective at suppressing 419 feedback. If the media source(s) are part of the SSM group for RTCP 420 packet, the Distribution Source must filter this packet out. If the 421 media source(s) are not part of the SSM group for RTCP packets, the 422 Distribution Source must not forward this RTCP Third Party Loss 423 Report message to the media source(s). 425 6.1.1. Distribution Source Feedback Summary Model 427 In the distribution source feedback summary model, we assume there 428 are two distribution sources between media source and receivers: 429 distribution source A and distribution source B. The distribution 430 source A is at the upstream of distribution source B. 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. 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: 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. 705 o Modify the SSM use case and RAMS use case to focus on uses. 707 o Other Editorial changes. 709 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 711 The following are the major changes compared to previous version: 713 o In Section 4.1, fix typo: Section 4.3.1.1 of section [RFC5104]-> 714 section 6.2.1 of [RFC4585]. 716 o In Section 3: Clarify how to deal with downstream loss using Third 717 party loss report and upstream loss using NACK. 719 o Update title and abstract to focus on third party loss report. 721 o In Section 6.1: Update this section to explain how third party 722 loss report is used to deal with downstream loss. 724 o In section 6.1.2: Update this section to explain how third party 725 loss report is used to deal with downstream loss. 727 o In section 6.2: Rephrase the text to discuss how BRS deal with the 728 third party loss report. 730 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 732 The following are the major changes compared to previous version: 734 o In Appendix A, fix typo: Appendix A. Appendix A. -> Appdendix A. 736 o Update abstract to clarify when third-party loss reports should be 737 sent instead of NACKs. 739 o Update section 3 Paragraph 2 to differentiate when a third-party 740 loss report should be used compared to a NACK. 742 o Update section 3 Paragraph 3 to explain when media source to send 743 a third-party loss. 745 o Move specific rules for section 6.1.1 and section 6.1.2 to section 746 6.1 as generic rules and delete section 6.1.1. 748 Authors' Addresses 750 Qin Wu 751 Huawei 752 101 Software Avenue, Yuhua District 753 Nanjing, Jiangsu 210012 754 China 756 Email: sunseawq@huawei.com 758 Frank Xia 759 Huawei 760 1700 Alma Dr. Suite 500 761 Plano, TX 75075 762 USA 764 Phone: +1 972-509-5599 765 Email: xiayangsong@huawei.com 767 Roni Even 768 Huawei 769 14 David Hamelech 770 Tel Aviv 64953 771 Israel 773 Email: even.roni@huawei.com