idnits 2.17.1 draft-ietf-avt-rtcp-non-compound-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3550], [RFC3711], [RFC4585]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 20, 2009) is 5543 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) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Johansson 3 Internet-Draft M. Westerlund 4 Updates: 3550,3711,4585 Ericsson AB 5 (if approved) Feb 20, 2009 6 Intended status: Standards Track 7 Expires: August 24, 2009 9 Support for Reduced-Size RTCP, Opportunities and Consequences 10 draft-ietf-avt-rtcp-non-compound-09 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 24, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This memo discusses benefits and issues that arise when allowing RTCP 50 packets to be transmitted with reduced size. The size can be reduced 51 if the rules on how to create compound packets outlined in RFC3550 52 are removed or changed. Based on that analysis this memo defines 53 certain changes to the rules to allow feedback messages to be sent as 54 reduced-size RTCP packets under certain conditions when using the RTP 55 AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711] 56 and [RFC4585]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Use Cases and Design Rationale . . . . . . . . . . . . . . . . 4 63 3.1. RTCP Compound Packets (Background) . . . . . . . . . . . . 4 64 3.2. Use Cases for Reduced-Size RTCP . . . . . . . . . . . . . 6 65 3.3. Benefits of Reduced-Size RTCP . . . . . . . . . . . . . . 7 66 3.4. Issues with Reduced-Size RTCP . . . . . . . . . . . . . . 8 67 3.4.1. Middle Boxes . . . . . . . . . . . . . . . . . . . . . 9 68 3.4.2. Packet Validation . . . . . . . . . . . . . . . . . . 9 69 3.4.3. Encryption/authentication . . . . . . . . . . . . . . 10 70 3.4.4. RTP and RTCP Multiplex on the Same Port . . . . . . . 10 71 3.4.5. Header Compression . . . . . . . . . . . . . . . . . . 11 72 4. Use of Reduced-size RTCP with AVPF . . . . . . . . . . . . . . 11 73 4.1. Definition of Reduced-Size RTCP . . . . . . . . . . . . . 12 74 4.2. Algorithm Considerations . . . . . . . . . . . . . . . . . 12 75 4.2.1. Verification of Delivery . . . . . . . . . . . . . . . 12 76 4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP . . . . 13 77 4.2.3. Enforcing Compound RTCP . . . . . . . . . . . . . . . 13 78 4.2.4. Immediate Mode . . . . . . . . . . . . . . . . . . . . 14 79 5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 In RTP [RFC3550] it is currently mandatory to send RTP Control 91 Protocol (RTCP) packets as compound packets containing at least a 92 Sender Report (SR) or Receiver Report (RR), followed by a Source 93 Description (SDES) packet containing at least the CNAME item. There 94 are good reasons for this, as discussed below (see Section 3.1), 95 however it does result in the minimal RTCP packets being quite large. 97 The RTP profile AVPF [RFC4585] specifies new RTCP packet types for 98 feedback messages. Some of these feedback messages would benefit 99 from being transmitted with minimal delay. AVPF does provide some 100 mechanisms to support this, however for environments with low- 101 bitrate links these messages can still consume a large amount of 102 resources, and can introduce extra delay in the time it takes to 103 completely send the compound packet in the network. It is therefore 104 desirable to send just the feedback, without the other parts of a 105 compound RTCP packet. This memo proposes such a mechanism, for this, 106 and other use cases, as discussed in Section 3.2. 108 There are a number of benefits with reduced-size RTCP; these are 109 discussed in Section 3.3. 111 The use of reduced-size RTCP is not without issues. This is 112 discussed in Section 3.4. These issues need to be considered and are 113 part of the motivation for this document. 115 Finally this document defines how AVPF is updated to allow for the 116 transmission of reduced-size RTCP in a way that would not 117 substantially affect the mechanisms that compound packets provide, 118 see Section 4 for more details. The connection to AVPF (or SAVPF) is 119 motivated by the fact that reduced-size RTCP is mainly beneficial for 120 event driven feedback purposes and that the AVPF early and immediate 121 modes make this possible. 123 This document updates [RFC3550], [RFC3711] and [RFC4585]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 The naming convention for RTCP is often confusing. Below a list of 132 RTCP terms and what they mean. See also section 6.1 in [RFC3550] and 133 section 3.1 in [RFC4585] for details. 135 RTCP packet: Can be of different types, contains a fixed header part 136 followed by structured elements depending on RTCP packet type. 138 Lower layer datagram: Can be interpreted as the UDP payload. It may 139 however, depending on the transport, be TCP or DCCP payload or 140 something else. Synonymous to "underlying protocol" defined in 141 section 3 in [RFC3550]. 143 Compound RTCP packet: A collection of two or more RTCP packets. A 144 compound RTCP packet is transmitted in a lower layer datagram. It 145 must contain at least an RTCP RR or SR packet and a SDES packet 146 with the CNAME item. Often "compound" is left out, the 147 interpretation of RTCP packet is therefore dependent on the 148 context. 150 Minimal compound RTCP packet: A compound RTCP packet that contains 151 the RTCP RR or SR packets and the SDES packet with the CNAME item 152 with a specified ordering. 154 (Full) compound RTCP packet: A compound RTCP packet that conforms to 155 the requirements on minimal compound RTCP packets and contains 156 more RTCP packets. 158 Reduced-size RTCP packet: May contain one or more RTCP packets but 159 does not follow the compound RTCP rules defined in section 6.1 in 160 [RFC3550] and is thus neither a minimal or a full compound RTCP. 161 See Section 4.1 for a full definition. 163 3. Use Cases and Design Rationale 165 3.1. RTCP Compound Packets (Background) 167 Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent 168 as a compound RTCP packet consisting of at least two individual RTCP 169 packets, first an Sender Report (SR) or Receiver Report (RR), 170 followed by additional packets including a mandatory SDES packet 171 containing a CNAME item for the transmitting source identifier 172 (SSRC). Below is a short description what these RTCP packet types 173 are used for. 175 1. The sender and receiver reports (see Section 6.4 of [RFC3550]) 176 provide the RTP session participant with the Synchronisation 177 Source (SSRC) Identifier of all RTP session participants. Having 178 all participants send these packets periodically allows everyone 179 to determine the current number of participants. This 180 information is used in the transmission scheduling algorithm. 181 Thus this is particularly important for new participants so that 182 they quickly can establish a good estimate of the group size. 183 Failure to do this would result in RTCP senders consuming too 184 much bandwidth. 186 2. Before a new session participant has sent any RTP or RTCP packet, 187 it can also avoid SSRC collisions with all the SSRCs it sees 188 prior to that transmission. So the possibility to see a 189 substantial proportion of the participating sources minimizes the 190 risk of any collision when selecting SSRC. 192 3. The sender and receiver reports contain some basic statistics 193 usable for monitoring of the transport and thus enable 194 adaptation. These reports become more useful if sent regularly 195 as the receiver of a report can perform analysis to find trends 196 between the individual reports. When used for media transmission 197 adaptation the information becomes more useful the more 198 frequently it is received, at least until one report per round- 199 trip time (RTT) is achieved. Therefore there is, in most cases, 200 no reason to not include the sender or receiver report in all 201 RTCP packets. 203 4. The CNAME SDES item (See Section 6.5.1 of [RFC3550]) exists to 204 allow receivers to determine which media flows should be 205 synchronized with each other, both within an RTP session and 206 between different RTP sessions carrying different media types. 207 Thus it is important to quickly receive this for each media 208 sender in the session when joining an RTP session. 210 5. Sender Reports (SR) are used in combination with the above SDES 211 CNAME mechanism to synchronize multiple RTP streams, such as 212 audio and video. After having determined which media streams 213 should be synchronized using the CNAME field, the receiver uses 214 the Sender Report's NTP and RTP timestamp fields to establish 215 synchronization. 217 6. The CNAME SDES item also allows a session participant to detect 218 SSRC collisions and separate them from routing loops. The 32-bit 219 randomly selected SSRC has some probability of collision. The 220 CNAME is used as longer canonical identifier of a particular end- 221 point instance that is bound to an SSRC. If that binding isn't 222 received and kept current the receiver may not detect a SSRC 223 collision, i.e. two different CNAMEs using the same SSRC. It 224 also can't detect a RTP level routing loop with the result that 225 the same SSRC and CNAME arrives from multiple lower-layer source 226 addresses. 228 Reviewing the above it is obvious that both SR/RR and the CNAME are 229 very important for new session participants to be able to utilize any 230 received media and to avoid flooding the network with RTCP reports. 231 In addition the dynamic nature of the information provided would make 232 it less useful if not sent regularly. 234 The following sections will describe the cases when reduced-size RTCP 235 is beneficial and also show the possible issues that must be 236 considered. 238 3.2. Use Cases for Reduced-Size RTCP 240 Below are listed a few use cases for reduced-size RTCP. 242 Control Plane Signaling: Open Mobile Alliance (OMA) Push-to-talk 243 over Cellular (PoC) [OMA-PoC] makes use of reduced-size RTCP when 244 transmitting certain events. The OMA POC service is primarily 245 used over cellular links capable of IP transport, such as the GSM 246 GPRS. 248 Codec Control Signaling: An example that can be used with reduced- 249 size RTCP is e.g TMMBR messages as specified in [RFC5104] which 250 signal a request for a change in codec bitrate. The benefit of 251 its use for these messages is in bad channel conditions as 252 reduced-size RTCP are much more likely to be successfully 253 transmitted than larger compound RTCP. This is critical as these 254 messages are likely to occur when channel conditions are poor. 255 Other examples of codec control usage for reduced-size RTCP are 256 found in [MTSI-3GPP] 258 Feedback: An example of a feedback scenario that would benefit from 259 reduced-size RTCP is Video streams with generic NACK. In cases 260 where the RTT is shorter than the receiver buffer depth, generic 261 NACK can be used to request retransmission of missing packets, 262 thus improving playout quality considerably. If the generic NACK 263 packets are transmitted as reduced-size RTCP, the bandwidth 264 requirement for RTCP will be minimal, enabling more frequent 265 feedback. As in the codec control case it is important that these 266 packets can be transmitted with as little delay as possible. 267 Another interesting use for reduced-size RTCP is in cases when 268 regular feedback is needed, as described in Section 3.3. 270 Status Reports: One proposed idea is to transmit small measurement 271 or status reports in reduced-size RTCP, and to be able to split 272 the minimal compound RTCP and transmit the individual RTCP 273 separately. The status reports can be used either by the 274 endpoints or by other network monitoring boxes in the network. 275 The benefit is that with some radio access technologies small 276 packets are more robust to poor radio conditions than large 277 packets. Additionally, with small (report) packets there is a 278 smaller risk that the report packets will affect the channel that 279 they report upon. Another benefit is that it is possible, with 280 reduced-size RTCP, to allow e.g anonymous status reporting to be 281 transmitted unencrypted. This is something that may be beneficial 282 for e.g network monitoring purposes. 284 3.3. Benefits of Reduced-Size RTCP 286 As mentioned in the introduction, most advantages of using reduced- 287 size RTCP packets exists in cases when the available RTCP bitrate is 288 limited. This because they can become substantially smaller than 289 compound packets. A compound packet is forced to contain both an RR 290 or an SR and the CNAME SDES item. The RR containing a report block 291 for a single source is 32 bytes, an SR is 52 bytes. Both may be 292 larger if they contain report blocks for multiple sources. The SDES 293 packet containing a CNAME item will be 10 bytes plus the CNAME string 294 length. Here it is reasonable that the CNAME string is at least 10 295 bytes to get a decent collision resistance. If the recommended form 296 of user@host is used, then most strings will be longer than 20 297 characters. Thus a reduced-size RTCP can become at least 70-80 bytes 298 smaller than the compound packet. 300 For low bitrate links the benefits of this reduction in size are as 301 follows: 303 o For links where the packet loss rate grows with the packet size, 304 smaller packets are be less likely to be dropped. Radio links are 305 an example of such links. In the cellular world there exist links 306 that are optimized to handle RTP packets sized for carrying 307 compressed speech. This increases the capacity and coverage for 308 voice services in a given wireless network. Minimal compound RTCP 309 packets are commonly 2-3 times the size of a RTP packet carrying 310 compressed speech. If the speech packet over such a bearer has a 311 packet loss probability of p, then the RTCP packet will experience 312 a loss probability of 1-(1-p)^x where x is the number of fragments 313 the compound packet will be split on the link layer, i.e. commonly 314 into 2 or 3 fragments. 316 o Shorter serialization time, i.e the time it takes the link to 317 transmit the packet. For slower links this time can be 318 substantial. For example transmitting 120 bytes over an link 319 interface capable of 30 kbps takes 32 milliseconds (ms) assuming 320 uniform transmission rate. 322 In cases when reduced-size RTCP carries important and time sensitive 323 feedback, both shorter serialization time and the lower loss 324 probability are important to enable the best possible functionality. 325 Having a packet loss rate that is much higher for the feedback 326 packets compared to media packets hurts when trying to perform media 327 adaptation, to for example handle the changed performance present at 328 the cell border in a cellular system. 330 For high bitrate applications there is usually no problem to supply 331 RTCP with sufficient bitrates. When using AVPF one can use the "trr- 332 int" parameter to restrict the regular reporting interval to 333 approximately once per RTT or less often. As in most cases there is 334 little reason to provide with regular reports of higher density than 335 this, any additional bandwidth can then be used for feedback 336 messages. The benefit of reduced-size RTCP in this case is limited, 337 but exists. One typical example is video using generic NACK in cases 338 where the RTT is low. Using reduced-size RTCP would reduce the total 339 amount of bits used for RTCP. This is primarily applicable if the 340 number of reports is large. This would also result in lower 341 processing delay and less complexity for the feedback packets as they 342 do not need to query the RTCP database to construct the right 343 messages. 345 As message size is generally a smaller issue at higher bitrates, it 346 is also possible to transmit multiple RTCP in each lower layer 347 datagram in these cases. The motivation behind reduced-size RTCP in 348 this case is not size, rather it is to avoid the extra overhead 349 caused by inclusion of the SR/RR and SDES CNAME items in each 350 transmitted RTCP. 352 Independently of the link type there are additional benefits with 353 sending feedback in small reduced-size RTCP. Applications that use 354 RTCP AVPF in early or immediate mode need to send frequent event 355 driven feedback. Under these circumstances, the risk is reduced that 356 the RTCP bandwidth becomes too high during periods of heavy feedback 357 signaling. 359 In cases when regular feedback is needed, such as the profile under 360 development for TCP friendly rate control (TFRC) for RTP 361 [I-D.ietf-avt-tfrc-profile], the size of compound RTCP can result in 362 very high bandwidth requirements if the round trip time is short. 363 For this particular application reduced-size RTCP gives a very 364 substantial improvement. 366 3.4. Issues with Reduced-Size RTCP 368 This section describes the known issues with reduced-size RTCP and 369 also a brief analysis of their effects and mitigation. 371 3.4.1. Middle Boxes 373 Middle boxes in the network may discard RTCP that do not follow the 374 rules outlined in section 6.1 of RFC3550. Newer report types may be 375 interpreted as unknown by the middle box. For instance if the 376 payload type number is 207 instead of 200 or 201 it may be treated as 377 unknown. The effect of this might for instance be that compound RTCP 378 would get through while the reduced-size RTCP would be lost. 380 Verification of the delivery of reduced-size RTCP is discussed in 381 Section 4.2.1. 383 3.4.2. Packet Validation 385 A reduced-size RTCP packet will be discarded by the packet validation 386 code in Appendix A of [RFC3550]. This has several impacts: 388 Weakened Packet Validation: The packet validation code needs to be 389 rewritten to accept reduced-size RTCP. This in particular affects 390 section 9.1 in [RFC3550] in the sense that the header verification 391 must take into account that the payload type numbers for the 392 (first) RTCP in the lower layer datagram may differ from 200 or 393 201 (SR or RR). One potential effect of this change is much 394 weaker validation that received packets actually are RTCP, and not 395 packets of some other type being wrongly delivered. Thus some 396 consideration should be done to ensure the best possible 397 validation is available. For example restricting reduced-size 398 RTCP to contain only some specific RTCP packet types, that are 399 preferably signalled on a per-session basis. However, the 400 application of a security mechanism for source authentication on 401 the packets will provide much stronger protection. 403 Old RTP Receivers: Any RTCP receiver without updated packet 404 validation code will discard the reduced-size RTCP which means 405 that the receiver will not see e.g the contained feedback 406 messages. The effect of this depends on the type of feedback 407 message and the role of the receiver. For example this may cause 408 complete function loss in the case of attempting to use a reduced 409 size NACK message (see Section 6.2.1 of [RFC4585]) to non updated 410 media sender in a session using the retransmission scheme defined 411 by [RFC4588]. This type of discarding would also affect the 412 feedback suppression defined in AVPF. The result would be a 413 partitioning of the receivers within the session between old ones 414 only seeing the compound RTCP feedback messages and the newer ones 415 seeing both, where the old ones may send feedback messages for 416 events already reported on in reduced-size RTCP. 418 Bandwidth Considerations: The discarding of reduced-size RTCP would 419 affect the RTCP transmission calculation in the following way: the 420 avg_rtcp_size value would become larger than for RTP receivers 421 that exclude the reduced-size RTCP in this calculation (assuming 422 that reduced-size RTCP are smaller than compound ones). Therefore 423 these senders would under-utilize the available bitrate and send 424 with a longer interval than updated receivers. For most sessions 425 this should not be an issue. However for sessions with a large 426 portion of reduced-size RTCP the updated receivers may time out 427 non-updated senders prematurely. This is however not likely to 428 occur, as the time between compound RTCP transmissions needs to 429 become 5 times that used by the reduced-sized RTCP senders for it 430 to happen. 432 Computation of avg_rtcp_size: Long intervals between compound RTCP 433 with many reduced-size RTCP in between may lead to a computation 434 of a value for avg_rtcp_size that varies greatly over time. 435 Investigation shows that although it varies this is not enough of 436 a problem to warrant further changes or complexities to the RTCP 437 scheduling algorithm. 439 3.4.3. Encryption/authentication 441 SRTP presents a problem for reduced-size RTCP. Section 3.4 in 442 [RFC3711] states "SRTCP MUST be given packets according to that 443 requirement in the sense that the first part MUST be a sender report 444 or a receiver report". 446 Upon examination of how SRTP process packets it becomes obvious that 447 SRTP has no real dependency on whether the first packet is an SR or 448 an RR packet. What is needed is the common RTCP packet header, which 449 is present in all the packet types, with a source SSRC. The 450 conclusion is therefore that it is possible to use reduced-size RTCP 451 with SRTP. Nevertheless, as this implies a change to the rules in 452 [RFC3711] changes in SRTP implementations MAY become necessary. 454 3.4.4. RTP and RTCP Multiplex on the Same Port 456 In applications which multiplex RTP and RTCP on the same port, as 457 defined in [I-D.ietf-avt-rtp-and-rtcp-mux], care must be taken to 458 ensure that the de-multiplexing is done properly even though the RTCP 459 packets are reduced size. The downside of reduced size RTCP is that 460 more values representing RTCP packets exist, reducing the available 461 RTP payload type space. However, section 4 in 462 [I-D.ietf-avt-rtp-and-rtcp-mux] already requires the corresponding 463 RTP payload type range not be used when performing this multiplexing. 465 3.4.5. Header Compression 467 Two issues are related to header compression. Possible changes are 468 left for future work: 470 o Payload type number identification: The RoHC header compression 471 algorithm [RFC3095] needs to create different compression contexts 472 for RTP and RTCP for optimum performance. If RTP and RTCP are 473 multiplexed on the same port the classification may be based on 474 payload type numbers. The classification algorithm must here 475 acknowledge the fact that the payload type number for (the first) 476 RTCP may differ from 200 or 201. 478 o Compression of RTCP: No IETF defined header compression method 479 compress RTCP, however if such methods are developed in the 480 future, these methods must take reduced-size RTCP in account. 482 4. Use of Reduced-size RTCP with AVPF 484 Based on the above analysis it seems feasible to allow transmission 485 of reduced-size RTCP under some restrictions: 487 o First of all it is important that compound RTCP are transmitted at 488 regular intervals to ensure that the mechanisms maintained by the 489 compound packets, like feedback reporting works. The tracking of 490 session size and number of participants warrants mentioning again 491 as this ensures that the RTCP bandwidth remain bounded independent 492 of the number of session participants. 494 o Second, as the compound RTCP are also used to establish and 495 maintain synchronization between media, any newly joining 496 participant in a session would need to receive compound RTCP from 497 the media sender(s). 499 This implies that the regular transmission of compound RTCP MUST be 500 maintained throughout an RTP session. Reduced-size RTCP SHOULD be 501 restricted to be used as extra RTCP (e.g feedback) sent in cases when 502 a regular compound RTCP packet would not otherwise have been sent. 504 The usage of reduced-size RTCP SHALL only be done in RTP sessions 505 operating in AVPF [RFC4585] or SAVPF [RFC5124] Early or Immediate 506 mode. Reduced-size RTCP SHALL NOT be sent until at least one 507 compound RTCP has been sent. In Immediate mode all feedback messages 508 MAY be sent as reduced-size RTCP. In early mode a feedback message 509 scheduled for transmission as an Early RTCP, i.e not a Regular RTCP, 510 MAY be sent as reduced-size RTCP. All RTCP that are scheduled for 511 transmission as Regular RTCP SHALL be sent as compound RTCP as 512 indicated by AVPF [RFC4585]. 514 4.1. Definition of Reduced-Size RTCP 516 A reduced-size RTCP packet is an RTCP packet with the following 517 properties that makes it deviate from the compound RTCP packet 518 definition given in section 6.1 in [RFC3550]: 520 o Contains one or more RTCP packet(s) 522 o Any RTCP packet type allowed, however see section Section 4.2.1. 524 o MUST NOT be used for regular (scheduled) RTCP report purposes 526 o MUST NOT be used with the RTP/AVP profile [RFC3551] or the RTP/ 527 SAVP profile [RFC3711]. 529 4.2. Algorithm Considerations 531 4.2.1. Verification of Delivery 533 If an application is to use reduced-size RTCP it is important to 534 verify that the reduced-size RTCP packets actually reach the session 535 participants. As outlined above in Section 3.4.1 and Section 3.4.2 536 packets may be discarded along the path or in the end-point. 538 A few verification rules are RECOMMENDED to ensure robust RTCP 539 transmission and reception and to solve the identified issues when 540 reduced-size RTCP is used: 542 o The end-point issue can be solved by introducing signaling that 543 informs if all session participants are capable of reduced-size 544 RTCP. See Section 5. 546 o The middle box issue is more difficult and here one will be 547 required to use heuristics to determine if the reduced-size RTCP 548 are delivered or not. The method used to detect successful 549 delivery of reduced-size RTCP packets depends on the packet type. 550 The RTCP packet types for which successful delivery can be 551 detected are: 553 * Sender reports (SR): Successful transmission of a sender report 554 can be verified by inspection of the echoed timestamp in the 555 received receiver report (RR). This can also be used as a 556 method to verify if reduced-size RTCP can be used at all. 558 * Feedback RTCP packets: In many cases the feedback messages sent 559 using reduced-size RTCP will result in either explicit or 560 implicit indications that they have been received. An example 561 of is the RTP retransmission [RFC4588] that results from a NACK 562 message [RFC4585]. Another example is the Temporary Maximum 563 Media Bitrate Notification message resulting from a Temporary 564 Maximum Media Bitrate Request [RFC5104]. A third example is 565 the presence of a Decoder Refresh Point [RFC5104] in the video 566 media stream resulting from the Full Intra Request sent. 568 RTCP packet types for which it is not possible to detect 569 successful delivery SHOULD NOT be transmitted as reduced-size RTCP 570 packets unless they are transmitted in the same lower-layer 571 datagram as another RTCP packet type for which successful delivery 572 can be detected. 574 o An algorithm to detect consistent failure of delivery of reduced- 575 size RTCP MUST be used by any application using it. The details 576 of this algorithm are application dependent and therefore outside 577 the scope of this document. 579 If the verification fails it is strongly RECOMMENDED that only 580 compound RTCP according to the rules outlined in RFC3550 is 581 transmitted. 583 4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP 585 The result of the definition in Section 4.1 may be that the resulting 586 size of reduced-size RTCP can become larger than a regularly 587 scheduled compound RTCP packet. For applications that use access 588 types that are sensitive to packet size (see Paragraph 2 in 589 Section 3.3) it is strongly RECOMMENDED that the use of reduced-size 590 RTCP is limited to the transmission of a single RTCP packet in each 591 lower layer datagram. The method to determine the need for this is 592 outside the scope of this draft. 594 In general, as the benefit with large sized reduced-size RTCP packets 595 is very limited, it is strongly RECOMMENDED to transmit large 596 reduced-size RTCP packets as compound RTCP packets instead. 598 4.2.3. Enforcing Compound RTCP 600 As discussed earlier it is important that the transmission of 601 compound RTCP occurs at regular intervals. However, this will occur 602 as long as the RTCP senders follow the AVPF scheduling algorithm 603 defined in Section 3.5 in [RFC4585]. This follows as all regular 604 RTCP MUST be full compound RTCP. Note that there is also a 605 requirement on sending regular RTCP in immediate mode. 607 4.2.4. Immediate Mode 609 Section 3.3 in RFC4585 gives the option to use AVPF Immediate mode as 610 long as the groupsize is below a certain limit. As transmission 611 using reduced-size RTCP may reduce the bandwidth demand it also opens 612 up the possibility of a more liberal use of immediate mode. 614 5. Signaling 616 This document defines the "a=rtcp-rsize" SDP [RFC4566] attribute to 617 indicate if the session participant is capable of supporting reduced- 618 size RTCP for applications that uses SDP for configuration of RTP 619 sessions. It is REQUIRED that a participant that proposes the use of 620 reduced-size RTCP shall itself support the reception of reduced-size 621 RTCP. 623 An offering client that wishes to use reduced-size RTCP MUST include 624 the attribute "a=rtcp-rsize" in the SDP offer. If "a=rtcp-rsize" is 625 present in the offer SDP, the answerer that supports reduced-size 626 RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute 627 in the answer. 629 In declarative usage of SDP such as RTSP [RFC2326] and SAP [RFC2974] 630 the presence of the attribute indicates that the session participant 631 MAY use reduced size RTCP packets in its RTCP transmissions. 633 6. Security Considerations 635 The security considerations of RTP [RFC3550] and AVPF [RFC4585] will 636 apply also to reduced-size RTCP. The reduction in validation 637 strength for received packets on the RTCP port may result in a higher 638 degree of acceptance of spurious data as real RTCP. This 639 vulnerability can mostly be addressed by usage of any security 640 mechanism that provide authentication; one such mechanism is SRTP 641 [RFC3711]. 643 7. IANA Considerations 645 Following the guidelines in [RFC4566], the IANA is requested to 646 register one new SDP attribute: 648 o Contact name, email address and telephone number: Authors of 649 RFCXXXX 651 o Attribute-name: rtcp-rsize 653 o Long-form attribute name: Reduced-size RTCP 655 o Type of attribute: media-level 657 o Subject to charset: no 659 This attribute defines the support for reduced-size RTCP, i.e the 660 possibility to transmit RTCP that does not conform to the rules for 661 compound RTCP defined in RFC3550. It is a property attribute, which 662 does not take a value. 664 Note to RFC Editor: please replace "RFC XXXX" above with the RFC 665 number of this memo, and remove this note. 667 8. Acknowledgements 669 The authors would like to thank all the people who gave feedback on 670 this document. Special thanks go to Colin Perkins. 672 This document also contain some text copied from [RFC3550], 673 [RFC4585]and [RFC3711]. We take the opportunity to thank the authors 674 of said documents. 676 9. References 678 9.1. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 684 Jacobson, "RTP: A Transport Protocol for Real-Time 685 Applications", STD 64, RFC 3550, July 2003. 687 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 688 Video Conferences with Minimal Control", STD 65, RFC 3551, 689 July 2003. 691 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 692 "Extended RTP Profile for Real-time Transport Control 693 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 694 July 2006. 696 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 697 Real-time Transport Control Protocol (RTCP)-Based Feedback 698 (RTP/SAVPF)", RFC 5124, February 2008. 700 9.2. Informative References 702 [I-D.ietf-avt-rtp-and-rtcp-mux] 703 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 704 Control Packets on a Single Port", 705 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 706 August 2007. 708 [I-D.ietf-avt-tfrc-profile] 709 Gharai, L., "RTP with TCP Friendly Rate Control", 710 draft-ietf-avt-tfrc-profile-10 (work in progress), 711 July 2007. 713 [MTSI-3GPP] 714 3GPP, "Specification : 3GPP TS 26.114 (v7.4.0), http:// 715 www.3gpp.org/ftp/Specs/archive/26_series/26.114/ 716 26114-740.zip", March 2007. 718 [OMA-PoC] Open Mobile Alliance, "Specification : Push to talk Over 719 Cellular User Plane, http://www.openmobilealliance.org/ 720 release_program/docs/PoC/V1_0_1-20061128-A/ 721 OMA-TS-PoC-UserPlane-V1_0_1-20061128-A.pdf", 722 November 2006. 724 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 725 Streaming Protocol (RTSP)", RFC 2326, April 1998. 727 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 728 Announcement Protocol", RFC 2974, October 2000. 730 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 731 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 732 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 733 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 734 Compression (ROHC): Framework and four profiles: RTP, UDP, 735 ESP, and uncompressed", RFC 3095, July 2001. 737 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 738 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 739 RFC 3711, March 2004. 741 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 742 Description Protocol", RFC 4566, July 2006. 744 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 746 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 747 July 2006. 749 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 750 "Codec Control Messages in the RTP Audio-Visual Profile 751 with Feedback (AVPF)", RFC 5104, February 2008. 753 Authors' Addresses 755 Ingemar Johansson 756 Ericsson AB 757 Laboratoriegrand 11 758 SE-971 28 Lulea 759 SWEDEN 761 Phone: +46 73 0783289 762 Email: ingemar.s.johansson@ericsson.com 764 Magnus Westerlund 765 Ericsson AB 766 Faeroegatan 6 767 SE-164 80 Stockholm 768 SWEDEN 770 Phone: +46 10 7148287 771 Email: magnus.westerlund@ericsson.com