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