idnits 2.17.1 draft-ietf-avtcore-feedback-supression-rtp-17.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2012) is 4358 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) == Missing Reference: 'RFCXXXX' is mentioned on line 503, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft F. Xia 4 Intended status: Standards Track R. Even 5 Expires: October 15, 2012 Huawei 6 April 13, 2012 8 RTCP Extension for Third-party Loss Report 9 draft-ietf-avtcore-feedback-supression-rtp-17 11 Abstract 13 In a large RTP session using the RTP Control Protocol (RTCP) feedback 14 mechanism defined in RFC 4585, a feedback target may experience 15 transient overload if some event causes a large number of receivers 16 to send feedback at once. This overload is usually avoided by 17 ensuring that feedback reports are forwarded to all receivers, 18 allowing them to avoid sending duplicate feedback reports. However, 19 there are cases where it is not recommended to forward feedback 20 reports, and this may allow feedback implosion. This memo discusses 21 these cases and defines a new RTCP third-party loss report that can 22 be used to inform receivers that the feedback target is aware of some 23 loss event, allowing them to suppress feedback. Associated SDP 24 signaling is also defined. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 15, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Source Specific Multicast (SSM) use case . . . . . . . . . 5 65 3.2. Unicast based Rapid Acquisition of Multicast Stream 66 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. RTP Transport Translator use case . . . . . . . . . . . . 6 68 3.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 6 69 3.5. Mixer use case . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 8 72 5.1. Transport Layer Feedback: Third-Party Loss Report 73 (TPLR) . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.2. Payload Specific Feedback: Third-Party Loss Report 75 (TPLR) . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 84 A.1. draft-ietf-avtcore-feedback-suppression-rtp-17 . . . . . . 14 85 A.2. draft-ietf-avtcore-feedback-suppression-rtp-16 . . . . . . 14 86 A.3. draft-ietf-avtcore-feedback-suppression-rtp-15 . . . . . . 14 87 A.4. draft-ietf-avtcore-feedback-suppression-rtp-14 . . . . . . 14 88 A.5. draft-ietf-avtcore-feedback-suppression-rtp-13 . . . . . . 15 89 A.6. draft-ietf-avtcore-feedback-suppression-rtp-12 . . . . . . 15 90 A.7. draft-ietf-avtcore-feedback-suppression-rtp-11 . . . . . . 15 91 A.8. draft-ietf-avtcore-feedback-suppression-rtp-10 . . . . . . 15 92 A.9. draft-ietf-avtcore-feedback-suppression-rtp-09 . . . . . . 15 93 A.10. draft-ietf-avtcore-feedback-suppression-rtp-08 . . . . . . 16 94 A.11. draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 16 95 A.12. draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 16 96 A.13. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 16 97 A.14. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 17 98 A.15. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 17 99 A.16. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 18 100 A.17. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 18 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 103 1. Introduction 105 The RTP Control Protocol (RTCP) feedback messages [RFC4585] allow the 106 receivers in an RTP session to report events and ask for action from 107 the media source (or a delegated feedback target when using unicast 108 RTCP feedback with SSM [RFC5760]). There are cases where multiple 109 receivers may initiate the same, or an equivalent message towards the 110 same media source or the same feedback target. When the receiver 111 count is large, this behavior may cause transient overload of the 112 media source, the network or both. This is known as a "feedback 113 storm" or a "NACK storm". 115 One scenario that can cause such feedback storms involves video Fast 116 Update requests. A storm of these feedback messages can occur in 117 conversational multimedia scenarios like multipoint video switching 118 conference [RFC4587], where many receivers may simultaneously lose 119 synchronization with the video stream when the speaker is changed in 120 the middle of a session. Receivers that issue fast update requests 121 (i.e., Full Intra Request (FIR) described in RFC5104 [RFC5104]), can 122 cause an implosion of FIR requests from receivers to the same media 123 source since these requests must currently be made blind, without 124 knowledge of requests made by other receivers. 126 RTCP feedback storms may cause short term overload, and in extreme 127 cases to pose a possible risk of increasing network congestion on the 128 control channel (e.g., RTCP feedback), the data channel, or both. It 129 is therefore desirable to provide a way of suppressing unneeded 130 feedback. This document specifies a new third-party loss report for 131 this function. It supplements the existing the use of RTCP NACK 132 packet and further is more precise in the uses where the network is 133 active to suppress feedback. It tells receivers explicitly that 134 feedback for a particular packet or frame loss is not needed and can 135 provide an early indication before the receiver reacts to the loss 136 and invokes its packet loss repair machinery. Section 3 provides 137 some example use cases of when to send the Third-Party Loss Report 138 message. 140 2. Requirements Notation 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC2119 [RFC2119]. 146 2.1. Glossary 147 TPLR - Third-Party Loss Report 148 TLLEI - Transport Layer Third-Party Loss Early Indication 149 PSLEI - Payload Specific Third-Party Loss Early Indication 150 FCI - Feedback Control Information [RFC4585] 151 AVPF - The Audio-Visual Profile with RTCP-based feedback [RFC4585] 152 SSRC - Synchronization Source 153 BRS - Burst/Retransmission Sources [RFC6285] 154 FIR - Full Intra Request [RFC5104] 155 PLI - Picture Loss Indication [RFC4585] 156 SSM - Source Specific Multicast [RFC5760] 157 RAMS - Unicast based Rapid Acquisition of Multicast Stream [RFC6285] 158 MCU - Multipoint Control Unit [RFC5117] 160 3. Example Use Cases 162 The operation of feedback suppression is similar for all types of RTP 163 sessions and topologies [RFC5117], however the exact messages used 164 and the scenarios in which suppression is employed differ for various 165 use cases. The following sections outline some of the intended use 166 cases for using the Third-Party Loss Report for feedback suppression 167 and give an overview of the particular mechanisms. 169 3.1. Source Specific Multicast (SSM) use case 171 In SSM RTP sessions as described in "RTP Control Protocol (RTCP) 172 Extensions for Single-Source Multicast Sessions with Unicast 173 Feedback" [RFC5760], one or more Media Sources send RTP packets to a 174 Distribution Source. The Distribution Source relays the RTP packets 175 to the receivers using a source-specific multicast group. 177 As outlined in the RFC5760 [RFC5760], there are two Unicast Feedback 178 models that may be used for reporting, the Simple Feedback model and 179 the Distribution Source Feedback Summary Model. In the simple 180 Feedback Model, there's no need for distribution source to create the 181 RTCP TPLRs, instead, RTCP NACKs are reflected by the distribution 182 source to the other Receivers. However in the Distribution Source 183 Feedback Summary model, the distribution source will not redistribute 184 the NACK for some reason(e.g., to prevent revealing the identity or 185 existence of a system sending NACK)and may send an RTCP TPLR message 186 to the systems that were unable to receive the NACK, and won't 187 receive the NACK via other means. The RTCP TPLR can be generated at 188 the distribution source when downstream loss is reported (e.g., 189 downstream loss report is received), which indicates to the receivers 190 that they should not transmit feedback messages for the same loss 191 event for a certain time. Therefore the distribution source in the 192 feedback summary model can be reasonably certain that it will help 193 the situation (i.e., unable receive the NACK) by sending this RTCP 194 TPLR message to all the relevant receivers impacted by the packet 195 loss. 197 3.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 198 case 200 The typical RAMS architecture [RFC6285] may have several Burst/ 201 Retransmission Sources(BRS) behind the multicast source (MS) placed 202 at the same level. These BRSes will receive the primary multicast 203 RTP stream from the media source and cache most recent packets after 204 joining multicast session. If packet loss happens at the upstream of 205 all the BRSs or the downstream of BRSes. One of the BRSes or all the 206 BRSes may send an RTCP NACK or RTCP TPLR message to the DS, where the 207 SSRC in this RTCP NACK or RTCP TPLR message is the BRS that is 208 sending the message. The DS forwards/reflects this message down on 209 the primary SSM. The details on how DS deal with this message is 210 specified in [RETRANSMISSION-FOR-SSM]. 212 3.3. RTP Transport Translator use case 214 A Transport Translator (Topo-Trn-Translator), as defined in RFC5117 215 [RFC5117] is typically forwarding the RTP and RTCP traffic between 216 RTP clients, for example converting from multicast to unicast for 217 domains that do not support multicast. The translator may suffer a 218 loss of important video packets. In this case, the translator may 219 forward RTCP TPLR message received from upstream in the same way as 220 forwarding other RTCP traffic. If the translator acting as the 221 monitor [MONARCH] is aware of packet loss, it may use the SSRC of 222 monitor as packet sender SSRC to create NACK message and send it to 223 the receivers that are not aware of packet loss. 225 3.4. Multipoint Control Unit (MCU) use case 227 When the speaker is changed in a voice-activated multipoint video 228 switching conference [RFC4587], an RTP mixer can be used to select 229 the available input streams and forward them to each participants. 230 If the MCU is doing a blind switch without waiting for a 231 synchronization point on the new stream it can send a FIR to the new 232 video source. In this case the MCU should send a FIR suppression 233 message to the new receivers: e.g., when the RTP Mixer starts to 234 receive FIR from some participants it can suppress the remaining 235 session participants from sending FIR by sending out an RTCP TPLR 236 message. 238 3.5. Mixer use case 240 A Mixer, in accordance with RFC5117 [RFC5117], aggregates multiple 241 RTP streams from other session participants and generates a new RTP 242 stream sent to the session participants. In some cases, the video 243 frames delivery may get damaged, for example due to packet loss or 244 delayed delivery, between media source and the mixer. In such case, 245 the mixer need to check if the packet loss will result in PLI or FIR 246 transmissions from most of the group by analyzing the received video. 247 If so the mixer may initiate FIR or PLI towards the media source on 248 behalf of all the session participants and send out an RTCP TPLR 249 message to these session participants that may or are expected to 250 send a PLI or FIR. Alternatively, when the mixer starts to receive 251 FIR or PLI from some participants and like to suppress the remaining 252 session participants from sending FIR or PLI by forwarding the FIR/ 253 PLI from one session participant to others. 255 4. Protocol Overview 257 This document extends the RTCP feedback messages defined in the RTP/ 258 AVPF [RFC4585] defining an RTCP Third-Party Loss Report (TPLR) 259 message. The RTCP TPLR message can be used by the intermediaries to 260 inform the receiver that the sender of the RTCP TPLR has received 261 reports that the indicated packets were lost, and asks the receiver 262 not to send feedback to it regarding these packets. Intermediaries 263 are variously referred to as Distribution source, Burst/ 264 Retransmission Sources (BRS), MCUs, RTP translator, or RTP mixers, 265 depending on the precise use case described Section 3. 267 RTCP TPLR follows the similar format of message type as RTCP NACK or 268 Full Intra Request Command. However, the RTCP TPLR is defined as an 269 indication that the sender of the feedback has received reports that 270 the indicated packets were lost, while NACK [RFC4585] just indicates 271 that the sender of the NACK observed that these packets were lost. 272 The RTCP TPLR message is generated by an intermediary that may not 273 have seen the actual packet loss. It is sent following the same 274 timing rule as sending NACK defined in RFC4585 [RFC4585]. The RTCP 275 TPLR message may be sent in a regular full compound RTCP packet or in 276 an early RTCP packet, as per the RTP/AVPF rules. Intermediaries in 277 the network that receive an RTCP TPLR MUST NOT send their own 278 additional Third-Party Loss Report messages for the same packet 279 sequence numbers. They SHOULD simply forward the RTCP TPLR message 280 received from upstream direction to the receiver(s), additionally, 281 they may generate their own RTCP TPLR that reports a set of the 282 losses they see, which are different from ones reported in the RTCP 283 TPLR they received. The RTCP TPLR does not have the retransmission 284 request [RFC4588] semantics. 286 When a receiver gets an RTCP TPLR message, it MUST follow the rules 287 for NACK suppression in RFC4585 [RFC4585]and refrain from sending a 288 feedback request (e.g., NACK or FIR) for the missing packets reported 289 in the message, which is dealt with in the same way as receiving 290 NACK. 292 To increase the robustness to the loss of a TPLR, The RTCP TPLR may 293 be retransmitted. If the additional TPLR arrives at receiver, the 294 receiver SHOULD deal with the additional TPLR in the same way as 295 receiving the first TPLR for the same packet and no additional 296 behavior for receiver is required. 298 A receiver may have sent a Feedback message according to the RTP/AVPF 299 scheduling algorithm of RFC4585 [RFC4585] before receiving an RTCP 300 TPLR message, but further feedback messages for those sequence 301 numbers SHOULD be suppressed after receiving the RTCP TPLR. Nodes 302 that do not understand the RTCP TPLR message will ignore it, and 303 might therefore still send feedback according to the AVPF scheduling 304 algorithm of RFC4585 [RFC4585]. The media source or intermediate 305 nodes cannot be certain that the use of an RTCP TPLR message actually 306 reduces the amount of feedback it receives. 308 5. Format of RTCP Feedback Messages 310 This document introduces two new RTCP Feedback messages for Third 311 Party Loss Report. Applications that are employing one or more loss- 312 repair methods MAY use the RTCP TPLR together with their existing 313 loss-repair methods either for every packet they expect to receive, 314 or for an application-specific subset of the RTP packets in a 315 session. 317 The following two sections each define an RTCP TPLR message. Both 318 messages are feedback messages as defined in section 6.1 of RFC4585 319 [RFC4585], and use the header format defined there. Each section 320 defines how to populate the PT, FMT, length, SSRC of packet sender, 321 SSRC of media source, and FCI fields in that header. 323 5.1. Transport Layer Feedback: Third-Party Loss Report (TPLR) 325 This TPLR message is identified by RTCP packet type value PT=RTPFB 326 and FMT=TBA1. 328 Within the common packet header for feedback messages (as defined in 329 section 6.1 of RFC4585 [RFC4585]), the "SSRC of packet sender" field 330 indicates the source of the request, and the "SSRC of media source" 331 denotes the media sender of the flow for which the indicated losses 332 are being suppressed. 334 The Feedback Control Information (FCI) field MUST contain one or more 335 entries of Transport Layer Third-Party loss Early Indication (TLLEI). 337 Each entry applies to the same media source identified by the SSRC 338 contained in the SSRC of media source field of Feedback header. The 339 length field in the TLLEI feedback message MUST be set to N+2, where 340 N is the number of FCI entries. 342 The FCI field for TLLEI uses the similar format of message Types 343 defined in the section 6.2.1 of RFC4585 [RFC4585]. The format is 344 shown in Figure 1. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | PID | BLP | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 1: Syntax of an FCI Entry in the TLLEI Feedback Message 354 Packet ID (PID): 16 bits 356 The PID field is used to specify a lost packet. The PID field 357 refers to the RTP sequence number of the lost packet. 359 bitmask of lost packets (BLP): 16 bits 361 The BLP allows for reporting losses of any of the 16 RTP packets 362 immediately following the RTP packet indicated by the PID. The 363 BLP's definition is identical to that given in the section 6.2.1 364 of [RFC4585]. 366 5.2. Payload Specific Feedback: Third-Party Loss Report (TPLR) 368 This TPLR message is identified by RTCP packet type value PT=PSFB and 369 FMT=TBA2, which is used to suppress FIR [RFC5104] and PLI [RFC4585]. 371 Within the common packet header for feedback messages (as defined in 372 section 6.1 of RFC4585 [RFC4585]), the "SSRC of packet sender" field 373 indicates the source of the request, and the "SSRC of media source" 374 is not used and SHALL be set to 0. The SSRCs of the media senders to 375 which this message applies are in the corresponding FCI entries. 377 The FCI field for a Payload Specific Third-Party Loss Early 378 Indication (PSLEI) consists one or more FCI entries. Each entry 379 applies to a different media source, identified by its SSRC. the 380 content of which is depicted in Figure 2. The length field in the 381 PSLEI feedback message MUST be set to N+2, where N is the number of 382 FCI entries. 384 The format is shown in Figure 2. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | SSRC | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 2: Syntax of an FCI Entry in the PSLEI Feedback Message 394 Synchronization source (SSRC): 32 bits 396 The SSRC value of the media source that is already aware, or in 397 the process of being made aware, that some receiver lost 398 synchronization with the media stream and for which the PSLEI 399 receiver's own response to any such error is suppressed. 401 6. SDP Signaling 403 The Session Description Protocol (SDP) [RFC4566] attribute, rtcp-fb, 404 is defined in the Section 4 of RFC4585 [RFC4585] and may be used to 405 negotiate the capability to handle specific AVPF commands and 406 indications. The ABNF for rtcp-fb is described in section 4.2 of 407 RFC4585 [RFC4585]. In this section, we extend the rtcp-fb attribute 408 to include the commands and indications that are described for third- 409 party loss report in the present document. 411 In the ABNF [RFC5234] for rtcp-fb-val defined in RFC4585 [RFC4585], 412 the feedback type "nack", without parameters, indicates use of the 413 Generic NACK feedback format as defined in Section 6.2.1of RFC4585 414 [RFC4585]. In this document, we define two parameters that indicate 415 the third-party loss supported for use with "nack", namely: 417 o "tllei" denotes support of Transport Layer Third-Party Loss Early 418 Indication. 420 o "pslei" denotes support of Payload Specific Third-Party Loss Early 421 Indication. 423 The ABNF for these two parameters for "nack" is defined here (please 424 refer to section 4.2 of RFC4585 [RFC4585] for complete ABNF syntax). 426 rtcp-fb-val =/ "nack" rtcp-fb-nack-param 427 rtcp-fb-nack-param = SP "tllei" 428 ;transport layer third party 429 ; loss early indication 430 / SP "pslei" 431 ;payload specific third party 432 ; loss early indication 433 / SP token [SP byte-string] 434 ; for future commands/indications 435 token = 436 byte-string = 438 Refer to Section 4.2 of RFC4585 [RFC4585] for a detailed description 439 and the full syntax of the "rtcp-fb" attribute. 441 7. Security Considerations 443 The security considerations documented in [RFC4585] are also 444 applicable for the TPLR messages defined in this document. 446 More specifically, spoofed or maliciously created TPLR feedback 447 messages cause missing RTP packets to not be repaired in a timely 448 fashion and add risk of (undesired) feedback suppression at RTCP 449 receivers that accept such TPLR messages. Any packet loss detected 450 by a receiver and where this RTP receiver also receives a TPLR 451 message for the same missing packet(s), will negatively impact the 452 application that relies on the (timely) RTP retransmission 453 capabilities. 455 A solution to prevent such attack with maliciously sent TPLR 456 messages, is to apply an authentication and integrity protection 457 framework for the feedback messages. This can be accomplished using 458 the RTP profile that combines Secure RTP [RFC3711] and AVPF into 459 SAVPF [RFC5124]. 461 Note that intermediaries that are not visible at the RTP layer that 462 wish to send the Third-Party Loss Reports on behalf of the media 463 source can only do so if they spoof the SSRC of the media source. 464 This is difficult in case SRTP is in use. If the intermediary is 465 visible at the RTP layer, this is not an issue, provided the 466 intermediary is part of the security context for the session. 468 8. IANA Consideration 470 This document instructs IANA to add two values to the '"ack" and 471 "nack" Attribute Values' sub-registry [RFC4585] of the 'Session 472 Description Protocol (SDP) Parameters' registry. 474 The value registration for the attribute value "nack": 476 Value name: tllei 477 Long name: Transport Layer Third-Party Loss Early Indication 478 Usable with: nack 479 Reference: RFC 4585. 481 Value name: pslei 482 Long name: Payload Specific Third-Party Loss Early Indication 483 Usable with: nack 484 Reference: RFC 4585. 486 The following value have been registered as one FMT value in the "FMT 487 Values for RTPFB Payload Types" registry located at the time of 488 publication at: http://www.iana.org/assignments/rtp-parameters 490 RTPFB range 491 Name Long Name Value Reference 492 -------------- --------------------------------- ----- --------- 493 TLLEI Transport Layer Third-Party TBA1 [RFCXXXX] 494 Loss Early Indication 496 The following value have been registered as one FMT value in the "FMT 497 Values for PSFB Payload Types" registry located at the time of 498 publication at: http://www.iana.org/assignments/rtp-parameters 500 PSFB range 501 Name Long Name Value Reference 502 -------------- --------------------------------- ----- -------- 503 PSLEI Payload Specific Third-Party TBA2 [RFCXXXX] 504 Loss Early Indication 506 9. Acknowledgments 508 The authors would like to thank David R Oran, Magnus Westerlund, 509 Colin Perkins, Ali C. Begen, Tom van Caenegem, Francis Dupont, 510 Ingemar Johansson, Bill Ver Steeg, Jonathan Lennox, WeeSan Lee for 511 their valuable comments and suggestions on this document. 513 10. References 514 10.1. Normative References 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", March 1997. 519 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 520 "Extended RTP Profile for Real-time Transport Control 521 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 522 July 2006. 524 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 525 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 526 July 2006. 528 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 529 Description Protocol", RFC 4566, July 2006. 531 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 532 Specifications: ABNF", STD 68, RFC 5234, January 2008. 534 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 535 "Codec Control Messages in the RTP Audio-Visual Profile 536 with Feedback (AVPF)", RFC 5104, February 2008. 538 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 539 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 540 RFC 3711, March 2004. 542 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 543 Real-time Transport Control Protocol (RTCP)-Based Feedback 544 (RTP/SAVPF)", RFC 5124, February 2008. 546 10.2. Informative References 548 [RFC6285] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 549 Based Rapid Acquisition of Multicast RTP Sessions", 550 June 2011. 552 [MONARCH] Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures 553 for RTP", June 2011. 555 [RETRANSMISSION-FOR-SSM] 556 Caenegem, T., Steeg, B., and A. Begen, "Retransmission for 557 Source-Specific Multicast (SSM) Sessions", May 2011. 559 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 560 January 2008. 562 [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", 563 RFC 4587, August 2006. 565 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 566 Protocol (RTCP) Extensions for Single-Source Multicast 567 Sessions with Unicast Feedback", RFC 5760, February 2010. 569 Appendix A. Change Log 571 Note to the RFC-Editor: please remove this section prior to 572 publication as an RFC. 574 A.1. draft-ietf-avtcore-feedback-suppression-rtp-17 576 The following are the major changes compared to previous version: 578 o Editorial changes based on Gen-ART review. 580 o removes the discussion of improper dithering that is less of 581 motivation of the current version. 583 o change of the normative language from SHOULD NOT to MUST NOT in 584 the protocol overview section. 586 o Move Example use case section right after Introduction section. 588 A.2. draft-ietf-avtcore-feedback-suppression-rtp-16 590 The following are the major changes compared to previous version: 592 o Some Editorial changes. 594 A.3. draft-ietf-avtcore-feedback-suppression-rtp-15 596 The following are the major changes compared to previous version: 598 o Some Editorial changes. 600 A.4. draft-ietf-avtcore-feedback-suppression-rtp-14 602 The following are the major changes compared to previous version: 604 o Two References moving to normative references. 606 o Revise IANA section to clarify whether to create new registry or 607 add new value to the existing registry. 609 o Revise Security section to clarify ill effect of accepting 610 unauthenticated messages. 612 o Add a glossary to fix acronym issue. 614 o Other Editorial changes. 616 A.5. draft-ietf-avtcore-feedback-suppression-rtp-13 618 The following are the major changes compared to previous version: 620 o Additional Editorial changes. 622 A.6. draft-ietf-avtcore-feedback-suppression-rtp-12 624 The following are the major changes compared to previous version: 626 o Additional Editorial changes. 628 A.7. draft-ietf-avtcore-feedback-suppression-rtp-11 630 The following are the major changes compared to previous version: 632 o Additional Editorial changes. 634 A.8. draft-ietf-avtcore-feedback-suppression-rtp-10 636 The following are the major changes compared to previous version: 638 o Fix the definition of Synchronization source for TPLR in section 639 4.2. 641 o Associate SDP parameters tllei and pslei with "nack". 643 o Remove the packet loss recovery from TPLR loss handling part. 645 o Other typo fixed. 647 A.9. draft-ietf-avtcore-feedback-suppression-rtp-09 649 The following are the major changes compared to previous version: 651 o Clarify to suppression interval with regard to how long to receive 652 the 654 retransmitted packet. Treating TPLR in the same way as receiving 655 NACK. 657 o Replace timer based approach with timeless based approach. 659 A.10. draft-ietf-avtcore-feedback-suppression-rtp-08 661 The following are the major changes compared to previous version: 663 o Clarify which RTT is used and how timer is refreshed in the 664 section 3. 666 o Editorial changes to the Introduction, Protocol Overview, SDP 668 Signaling, Message Format, Use case, Security Consideration and 669 IANA sections. 671 o Remove Seq Nr field in the figure 2 for payload specific feedback. 673 o References reorganizing. 675 A.11. draft-ietf-avtcore-feedback-suppression-rtp-07 677 The following are the major changes compared to previous version: 679 o Restructuring the protocol overview section to clarify the round 680 trip 682 time calculation and receiver behavior to the additional TPLR. 684 o Restructuring the SSM use case section to focus on the use of 685 TPLR. 687 o Editorial changes to the abstract, introduction, message format, 688 use cases and IANA sections. 690 o References update 692 A.12. draft-ietf-avtcore-feedback-suppression-rtp-06 694 The following are the major changes compared to previous version: 696 o A few Editorial changes to the whole document. 698 A.13. draft-ietf-avtcore-feedback-suppression-rtp-05 700 The following are the major changes compared to previous version: 701 o Remove 3rd and 4th paragraphs of section 6.1 and replaced them 702 with 2nd and 3rd paragraphs of section 3. 704 o Remove section 6.1.1.1. 706 o Revise the last paragraph of section 1 to clarify the rationale of 707 using new message. 709 o Update RTP transport translator case in section 6.3 to correct the 710 use of the third-party loss report. 712 o Update MCU case in section 6.4 to correct the use of the third 713 party loss report. 715 o Revise SSM use case to address multiple DS issue. 717 o References Update. 719 o Move one rationale on preventing sending unicast NACK in 720 introduction section to SSM case section. 722 o Other Editorial changes to section 6.1, 6.1.1, 6.2. 724 A.14. draft-ietf-avtcore-feedback-suppression-rtp-04 726 The following are the major changes compared to previous version: 727 o Reference Update. 729 o Clarify the use of the third-party loss report in section 3 and 730 section 6.1.1. 732 A.15. draft-ietf-avtcore-feedback-suppression-rtp-03 734 The following are the major changes compared to previous version: 736 o In Appendix A, fix typo: Appendix A. Appendix A. -> Appendix A. 738 o Update abstract to clarify when third-party loss reports should be 739 sent instead of NACKs. 741 o Update section 3 Paragraph 2 to differentiate when a third-party 742 loss report should be used compared to a NACK. 744 o Update section 3 Paragraph 3 to explain when media source to send 745 a third-party loss. 747 o Move specific rules for section 6.1.1 and section 6.1.2 to section 748 6.1 as generic rules and delete section 6.1.1. 750 A.16. draft-ietf-avtcore-feedback-suppression-rtp-02 752 The following are the major changes compared to previous version: 754 o In Section 4.1, fix typo: change Section 4.3.1.1 of section 755 [RFC5104] to section 6.2.1 of [RFC4585]. 757 o In Section 3: Clarify how to deal with downstream loss using 758 Third-party loss report and upstream loss using NACK. 760 o Update title and abstract to focus on third-party loss report. 762 o In Section 6.1: Update this section to explain how third party 763 loss report is used to deal with downstream loss. 765 o In section 6.1.2: Update this section to explain how third party 766 loss report is used to deal with downstream loss. 768 o In section 6.2: Rephrase the text to discuss how BRS deal with the 769 third-party loss report. 771 A.17. draft-ietf-avtcore-feedback-suppression-rtp-01 773 The following are the major changes compared to previous version: 775 o Remove the merge report from SSM use case and additional text to 776 address report merging issue. 778 o Revise section 3 and section 6 to address FEC packet dealing issue 779 and Leave how to repair packet loss beyond the scope. 781 o Modify the SSM use case and RAMS use case to focus on uses. 783 o Other Editorial changes. 785 Authors' Addresses 787 Qin Wu 788 Huawei 789 101 Software Avenue, Yuhua District 790 Nanjing, Jiangsu 210012 791 China 793 Email: sunseawq@huawei.com 794 Frank Xia 795 Huawei 796 1700 Alma Dr. Suite 500 797 Plano, TX 75075 798 USA 800 Phone: +1 972-509-5599 801 Email: xiayangsong@huawei.com 803 Roni Even 804 Huawei 805 14 David Hamelech 806 Tel Aviv 64953 807 Israel 809 Email: even.roni@huawei.com