idnits 2.17.1 draft-ietf-avt-rtcp-non-compound-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 777. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 801. 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 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 (Nov 18, 2008) is 5630 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 (==), 9 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) Nov 18, 2008 6 Intended status: Standards Track 7 Expires: May 22, 2009 9 Support for Reduced-Size RTCP, Opportunities and Consequences 10 draft-ietf-avt-rtcp-non-compound-08 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 22, 2009. 37 Abstract 39 This memo discusses benefits and issues that arise when allowing RTCP 40 packets to be transmitted with reduced size. The size can be reduced 41 if the rules on how to create compound packets outlined in RFC3550 42 are removed or changed. Based on that analysis this memo defines 43 certain changes to the rules to allow feedback messages to be sent as 44 reduced-size RTCP packets under certain conditions when using the RTP 45 AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711] 46 and [RFC4585]. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Use Cases and Design Rationale . . . . . . . . . . . . . . . . 4 53 3.1. RTCP Compound Packets (Background) . . . . . . . . . . . . 4 54 3.2. Use Cases for Reduced-Size RTCP . . . . . . . . . . . . . 6 55 3.3. Benefits of Reduced-Size RTCP . . . . . . . . . . . . . . 7 56 3.4. Issues with Reduced-Size RTCP . . . . . . . . . . . . . . 8 57 3.4.1. Middle Boxes . . . . . . . . . . . . . . . . . . . . . 9 58 3.4.2. Packet Validation . . . . . . . . . . . . . . . . . . 9 59 3.4.3. Encryption/authentication . . . . . . . . . . . . . . 10 60 3.4.4. RTP and RTCP Multiplex on the Same Port . . . . . . . 10 61 3.4.5. Header Compression . . . . . . . . . . . . . . . . . . 11 62 4. Use of Reduced-size RTCP with AVPF . . . . . . . . . . . . . . 11 63 4.1. Definition of Reduced-Size RTCP . . . . . . . . . . . . . 12 64 4.2. Algorithm Considerations . . . . . . . . . . . . . . . . . 12 65 4.2.1. Verification of Delivery . . . . . . . . . . . . . . . 12 66 4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP . . . . 13 67 4.2.3. Enforcing Compound RTCP . . . . . . . . . . . . . . . 13 68 4.2.4. Immediate Mode . . . . . . . . . . . . . . . . . . . . 14 69 5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 Intellectual Property and Copyright Statements . . . . . . . . . . 18 79 1. Introduction 81 In RTP [RFC3550] it is currently mandatory to send RTP Control 82 Protocol (RTCP) packets as compound packets containing at least a 83 Sender Report (SR) or Receiver Report (RR), followed by a Source 84 Description (SDES) packet containing at least the CNAME item. There 85 are good reasons for this, as discussed below (see Section 3.1), 86 however it does result in the minimal RTCP packets being quite large. 88 The RTP profile AVPF [RFC4585] specifies new RTCP packet types for 89 feedback messages. Some of these feedback messages would benefit 90 from being transmitted with minimal delay. AVPF does provide some 91 mechanisms to support this, however for environments with low- 92 bitrate links these messages can still consume a large amount of 93 resources, and can introduce extra delay in the time it takes to 94 completely send the compound packet in the network. It is therefore 95 desirable to send just the feedback, without the other parts of a 96 compound RTCP packet. This memo proposes such a mechanism, for this, 97 and other use cases, as discussed in Section 3.2. 99 There are a number of benefits with reduced-size RTCP, these are 100 discussed in Section 3.3. 102 The use of reduced-size RTCP is not without issues. This is 103 discussed in Section 3.4. These issues need to be considered and are 104 part of the motivation for this document. 106 Finally this document defines how AVPF is updated to allow for the 107 transmission of reduced-size RTCP in a way that would not 108 substantially affect the mechanisms that compound packets provide, 109 see Section 4 for more details. The connection to AVPF (or SAVPF) is 110 motivated by the fact that reduced-size RTCP is mainly beneficial for 111 event driven feedback purposes and that the AVPF early and immediate 112 modes make this possible. 114 This document updates [RFC3550], [RFC3711] and [RFC4585]. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 The naming convention for RTCP is often confusing. Below a list of 123 RTCP terms and what they mean. See also section 6.1 in [RFC3550] and 124 section 3.1 in [RFC4585] for details. 126 RTCP packet: Can be of different types, contains a fixed header part 127 followed by structured elements depending on RTCP packet type. 129 Lower layer datagram: Can be interpreted as the UDP payload. It may 130 however, depending on the transport, be TCP or DCCP payload or 131 something else. Synonymous to "underlying protocol" defined in 132 section 3 in [RFC3550]. 134 Compound RTCP packet: A collection of two or more RTCP packets. A 135 compound RTCP packet is transmitted in a lower layer datagram. It 136 must contain at least an RTCP RR or SR packet and a SDES packet 137 with the CNAME item. Often "compound" is left out, the 138 interpretation of RTCP packet is therefore dependent on the 139 context. 141 Minimal compound RTCP packet: A compound RTCP packet that contains 142 the RTCP RR or SR packets and the SDES packet with the CNAME item 143 with a specified ordering. 145 (Full) compound RTCP packet: A compound RTCP packet that conforms to 146 the requirements on minimal compound RTCP packets and contains 147 more RTCP packets. 149 Reduced-size RTCP packet: May contain one or more RTCP packets but 150 does not follow the compound RTCP rules defined in section 6.1 in 151 [RFC3550] and is thus neither a minimal or a full compound RTCP. 152 See Section 4.1 for a full definition. 154 3. Use Cases and Design Rationale 156 3.1. RTCP Compound Packets (Background) 158 Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent 159 as a compound RTCP packet consisting of at least two individual RTCP 160 packets, first an Sender Report (SR) or Receiver Report (RR), 161 followed by additional packets including a mandatory SDES packet 162 containing a CNAME item for the transmitting source identifier 163 (SSRC). Below is a short description what these RTCP packet types 164 are used for. 166 1. The sender and receiver reports (see Section 6.4 of [RFC3550]) 167 provide the RTP session participant with the Synchronisation 168 Source (SSRC) Identifier of all RTP session participants. Having 169 all participants send these packets periodically allows everyone 170 to determine the current number of participants. This 171 information is used in the transmission scheduling algorithm. 172 Thus this is particularly important for new participants so that 173 they quickly can establish a good estimate of the group size. 174 Failure to do this would result in RTCP senders consuming too 175 much bandwidth. 177 2. Before a new session participant has sent any RTP or RTCP packet, 178 it can also avoid SSRC collisions with all the SSRCs it sees 179 prior to that transmission. So the possibility to see a 180 substantial proportion of the participating sources minimizes the 181 risk of any collision when selecting SSRC. 183 3. The sender and receiver reports contain some basic statistics 184 usable for monitoring of the transport and thus enable 185 adaptation. These reports become more useful if sent regularly 186 as the receiver of a report can perform analysis to find trends 187 between the individual reports. When used for media transmission 188 adaptation the information becomes more useful the more 189 frequently it is received, at least until one report per round- 190 trip time (RTT) is achieved. Therefore there is, in most cases, 191 no reason to not include the sender or receiver report in all 192 RTCP packets. 194 4. The CNAME SDES item (See Section 6.5.1 of [RFC3550]) exists to 195 allow receivers to determine which media flows should be 196 synchronized with each other, both within an RTP session and 197 between different RTP sessions carrying different media types. 198 Thus it is important to quickly receive this for each media 199 sender in the session when joining an RTP session. 201 5. Sender Reports (SR) are used in combination with the above SDES 202 CNAME mechanism to synchronize multiple RTP streams, such as 203 audio and video. After having determined which media streams 204 should be synchronized using the CNAME field, the receiver uses 205 the Sender Report's NTP and RTP timestamp fields to establish 206 synchronization. 208 6. The CNAME SDES item also allows a session participant to detect 209 SSRC collisions and separate them from routing loops. The 32-bit 210 randomly selected SSRC has some probability of collision. The 211 CNAME is used as longer canonical identifier of a particular end- 212 point instance that is bound to an SSRC. If that binding isn't 213 received and kept current the receiver may not detect a SSRC 214 collision, i.e. two different CNAMEs using the same SSRC. It 215 also can't detect a RTP level routing loop with the result that 216 the same SSRC and CNAME arrives from multiple lower-layer source 217 addresses. 219 Reviewing the above it is obvious that both SR/RR and the CNAME are 220 very important for new session participants to be able to utilize any 221 received media and to avoid flooding the network with RTCP reports. 222 In addition the dynamic nature of the information provided would make 223 it less useful if not sent regularly. 225 The following sections will describe the cases when reduced-size RTCP 226 is beneficial and also show the possible issues that must be 227 considered. 229 3.2. Use Cases for Reduced-Size RTCP 231 Below are listed a few use cases for reduced-size RTCP. 233 Control Plane Signaling: Open Mobile Alliance (OMA) Push-to-talk 234 over Cellular (PoC) [OMA-PoC] makes use of reduced-size RTCP when 235 transmitting certain events. The OMA POC service is primarily 236 used over cellular links capable of IP transport, such as the GSM 237 GPRS. 239 Codec Control Signaling: An example that can be used with reduced- 240 size RTCP is e.g TMMBR messages as specified in [RFC5104] which 241 signal a request for a change in codec bitrate. The benefit of 242 its use for these messages is in bad channel conditions as 243 reduced-size RTCP are much more likely to be successfully 244 transmitted than larger compound RTCP. This is critical as these 245 messages are likely to occur when channel conditions are poor. 246 Other examples of codec control usage for reduced-size RTCP are 247 found in [MTSI-3GPP] 249 Feedback: An example of a feedback scenario that would benefit from 250 reduced-size RTCP is Video streams with generic NACK. In cases 251 where the RTT is shorter than the receiver buffer depth, generic 252 NACK can be used to request retransmission of missing packets, 253 thus improving playout quality considerably. If the generic NACK 254 packets are transmitted as reduced-size RTCP, the bandwidth 255 requirement for RTCP will be minimal, enabling more frequent 256 feedback. As in the codec control case it is important that these 257 packets can be transmitted with as little delay as possible. 258 Another interesting use for reduced-size RTCP is in cases when 259 regular feedback is needed, as described in Section 3.3. 261 Status Reports: One proposed idea is to transmit small measurement 262 or status reports in reduced-size RTCP, and to be able to split 263 the minimal compound RTCP and transmit the individual RTCP 264 separately. The status reports can be used either by the 265 endpoints or by other network monitoring boxes in the network. 266 The benefit is that with some radio access technologies small 267 packets are more robust to poor radio conditions than large 268 packets. Additionally, with small (report) packets there is a 269 smaller risk that the report packets will affect the channel that 270 they report upon. Another benefit is that it is possible, with 271 reduced-size RTCP, to allow e.g anonymous status reporting to be 272 transmitted unencrypted. This is something that may be beneficial 273 for e.g network monitoring purposes. 275 3.3. Benefits of Reduced-Size RTCP 277 As mentioned in the introduction, most advantages of using reduced- 278 size RTCP packets exists in cases when the available RTCP bitrate is 279 limited. This because they can become substantially smaller than 280 compound packets. A compound packet is forced to contain both an RR 281 or an SR and the CNAME SDES item. The RR containing a report block 282 for a single source is 32 bytes, an SR is 52 bytes. Both may be 283 larger if they contain report blocks for multiple sources. The SDES 284 packet containing a CNAME item will be 10 bytes plus the CNAME string 285 length. Here it is reasonable that the CNAME string is at least 10 286 bytes to get a decent collision resistance. If the recommended form 287 of user@host is used, then most strings will be longer than 20 288 characters. Thus a reduced-size RTCP can become at least 70-80 bytes 289 smaller than the compound packet. 291 For low bitrate links the benefits of this reduction in size are as 292 follows: 294 o For links where the packet loss rate grows with the packet size, 295 smaller packets are be less likely to be dropped. Radio links are 296 an example of such links. In the cellular world there exist links 297 that are optimized to handle RTP packets sized for carrying 298 compressed speech. This increases the capacity and coverage for 299 voice services in a given wireless network. Minimal compound RTCP 300 packets are commonly 2-3 times the size of a RTP packet carrying 301 compressed speech. If the speech packet over such a bearer has a 302 packet loss probability of p, then the RTCP packet will experience 303 a loss probability of 1-(1-p)^x where x is the number of fragments 304 the compound packet will be split on the link layer, i.e. commonly 305 into 2 or 3 fragments. 307 o Shorter serialization time, i.e the time it takes the link to 308 transmit the packet. For slower links this time can be 309 substantial. For example transmitting 120 bytes over an link 310 interface capable of 30 kbps takes 32 milliseconds (ms) assuming 311 uniform transmission rate. 313 In cases when reduced-size RTCP carries important and time sensitive 314 feedback, both shorter serialization time and the lower loss 315 probability are important to enable the best possible functionality. 316 Having a packet loss rate that is much higher for the feedback 317 packets compared to media packets hurts when trying to perform media 318 adaptation, to for example handle the changed performance present at 319 the cell border in a cellular system. 321 For high bitrate applications there is usually no problem to supply 322 RTCP with sufficient bitrates. When using AVPF one can use the "trr- 323 int" parameter to restrict the regular reporting interval to 324 approximately once per RTT or less often. As in most cases there is 325 little reason to provide with regular reports of higher density than 326 this, any additional bandwidth can then be used for feedback 327 messages. The benefit of reduced-size RTCP in this case is limited, 328 but exists. One typical example is video using generic NACK in cases 329 where the RTT is low. Using reduced-size RTCP would reduce the total 330 amount of bits used for RTCP. This is primarily applicable if the 331 number of reports is large. This would also result in lower 332 processing delay and less complexity for the feedback packets as they 333 do not need to query the RTCP database to construct the right 334 messages. 336 As message size is generally a smaller issue at higher bitrates, it 337 is also possible to transmit multiple RTCP in each lower layer 338 datagram in these cases. The motivation behind reduced-size RTCP in 339 this case is not size, rather it is to avoid the extra overhead 340 caused by inclusion of the SR/RR and SDES CNAME items in each 341 transmitted RTCP. 343 Independently of the link type there are additional benefits with 344 sending feedback in small reduced-size RTCP. Applications that use 345 RTCP AVPF in early or immediate mode need to send frequent event 346 driven feedback. Under these circumstances, the risk is reduced that 347 the RTCP bandwidth becomes too high during periods of heavy feedback 348 signaling. 350 In cases when regular feedback is needed, such as the profile under 351 development for TCP friendly rate control (TFRC) for RTP 352 [I-D.ietf-avt-tfrc-profile], the size of compound RTCP can result in 353 very high bandwidth requirements if the round trip time is short. 354 For this particular application reduced-size RTCP gives a very 355 substantial improvement. 357 3.4. Issues with Reduced-Size RTCP 359 This section describes the known issues with reduced-size RTCP and 360 also a brief analysis of their effects and mitigation. 362 3.4.1. Middle Boxes 364 Middle boxes in the network may discard RTCP that do not follow the 365 rules outlined in section 6.1 of RFC3550. Newer report types may be 366 interpreted as unknown by the middle box. For instance if the 367 payload type number is 207 instead of 200 or 201 it may be treated as 368 unknown. The effect of this might for instance be that compound RTCP 369 would get through while the reduced-size RTCP would be lost. 371 Verification of the delivery of reduced-size RTCP is discussed in 372 Section 4.2.1. 374 3.4.2. Packet Validation 376 A reduced-size RTCP packet will be discarded by the packet validation 377 code in Appendix A of [RFC3550]. This has several impacts: 379 Weakened Packet Validation: The packet validation code needs to be 380 rewritten to accept reduced-size RTCP. This in particular affects 381 section 9.1 in [RFC3550] in the sense that the header verification 382 must take into account that the payload type numbers for the 383 (first) RTCP in the lower layer datagram may differ from 200 or 384 201 (SR or RR). One potential effect of this change is much 385 weaker validation that received packets actually are RTCP, and not 386 packets of some other type being wrongly delivered. Thus some 387 consideration should be done to ensure the best possible 388 validation is available. For example restricting reduced-size 389 RTCP to contain only some specific RTCP packet types, that are 390 preferably signalled on a per-session basis. However, the 391 application of a security mechanism for source authentication on 392 the packets will provide much stronger protection. 394 Old RTP Receivers: Any RTCP receiver without updated packet 395 validation code will discard the reduced-size RTCP which means 396 that the receiver will not see e.g the contained feedback 397 messages. The effect of this depends on the type of feedback 398 message and the role of the receiver. For example this may cause 399 complete function loss in the case of attempting to use a reduced 400 size NACK message (see Section 6.2.1 of [RFC4585]) to non updated 401 media sender in a session using the retransmission scheme defined 402 by [RFC4588]. This type of discarding would also affect the 403 feedback suppression defined in AVPF. The result would be a 404 partitioning of the receivers within the session between old ones 405 only seeing the compound RTCP feedback messages and the newer ones 406 seeing both, where the old ones may send feedback messages for 407 events already reported on in reduced-size RTCP. 409 Bandwidth Considerations: The discarding of reduced-size RTCP would 410 affect the RTCP transmission calculation in the following way: the 411 avg_rtcp_size value would become larger than for RTP receivers 412 that exclude the reduced-size RTCP in this calculation (assuming 413 that reduced-size RTCP are smaller than compound ones). Therefore 414 these senders would under-utilize the available bitrate and send 415 with a longer interval than updated receivers. For most sessions 416 this should not be an issue. However for sessions with a large 417 portion of reduced-size RTCP the updated receivers may time out 418 non-updated senders prematurely. This is however not likely to 419 occur, as the time between compound RTCP transmissions needs to 420 become 5 times that used by the reduced-sized RTCP senders for it 421 to happen. 423 Computation of avg_rtcp_size: Long intervals between compound RTCP 424 with many reduced-size RTCP in between may lead to a computation 425 of a value for avg_rtcp_size that varies greatly over time. 426 Investigation shows that although it varies this is not enough of 427 a problem to warrant further changes or complexities to the RTCP 428 scheduling algorithm. 430 3.4.3. Encryption/authentication 432 SRTP presents a problem for reduced-size RTCP. Section 3.4 in 433 [RFC3711] states "SRTCP MUST be given packets according to that 434 requirement in the sense that the first part MUST be a sender report 435 or a receiver report". 437 Upon examination of how SRTP process packets it becomes obvious that 438 SRTP has no real dependency on whether the first packet is an SR or 439 an RR packet. What is needed is the common RTCP packet header, which 440 is present in all the packet types, with a source SSRC. The 441 conclusion is therefore that it is possible to use reduced-size RTCP 442 with SRTP. Nevertheless, as this implies a change to the rules in 443 [RFC3711] changes in SRTP implementations MAY become necessary. 445 3.4.4. RTP and RTCP Multiplex on the Same Port 447 In applications which multiplex RTP and RTCP on the same port, as 448 defined in [I-D.ietf-avt-rtp-and-rtcp-mux], care must be taken to 449 ensure that the de-multiplexing is done properly even though the RTCP 450 packets are reduced size. The downside of reduced size RTCP is that 451 more values representing RTCP packets exist, reducing the available 452 RTP payload type space. However, section 4 in 453 [I-D.ietf-avt-rtp-and-rtcp-mux] already requires the corresponding 454 RTP payload type range not be used when performing this multiplexing. 456 3.4.5. Header Compression 458 Two issues are related to header compression, possible changes are 459 left for future work: 461 o Payload type number identification: The RoHC header compression 462 algorithm [RFC3095] needs to create different compression contexts 463 for RTP and RTCP for optimum performance. If RTP and RTCP are 464 multiplexed on the same port the classification may be based on 465 payload type numbers. The classification algorithm must here 466 acknowledge the fact that the payload type number for (the first) 467 RTCP may differ from 200 or 201. 469 o Compression of RTCP: No IETF defined header compression method 470 compress RTCP, however if such methods are developed in the 471 future, these methods must take reduced-size RTCP in account. 473 4. Use of Reduced-size RTCP with AVPF 475 Based on the above analysis it seems feasible to allow transmission 476 of reduced-size RTCP under some restrictions: 478 o First of all it is important that compound RTCP are transmitted at 479 regular intervals to ensure that the mechanisms maintained by the 480 compound packets, like feedback reporting works. The tracking of 481 session size and number of participants warrants mentioning again 482 as this ensures that the RTCP bandwidth remain bounded independent 483 of the number of session participants. 485 o Second, as the compound RTCP are also used to establish and 486 maintain synchronization between media, any newly joining 487 participant in a session would need to receive compound RTCP from 488 the media sender(s). 490 This implies that the regular transmission of compound RTCP MUST be 491 maintained throughout an RTP session. Reduced-size RTCP SHOULD be 492 restricted to be used as extra RTCP (e.g feedback) sent in cases when 493 a regular compound RTCP packet would not otherwise have been sent. 495 The usage of reduced-size RTCP SHALL only be done in RTP sessions 496 operating in AVPF [RFC4585] or SAVPF [RFC5124] Early or Immediate 497 mode. Reduced-size RTCP SHALL NOT be sent until at least one 498 compound RTCP has been sent. In Immediate mode all feedback messages 499 MAY be sent as reduced-size RTCP. In early mode a feedback message 500 scheduled for transmission as an Early RTCP, i.e not a Regular RTCP, 501 MAY be sent as reduced-size RTCP. All RTCP that are scheduled for 502 transmission as Regular RTCP SHALL be sent as compound RTCP as 503 indicated by AVPF [RFC4585]. 505 4.1. Definition of Reduced-Size RTCP 507 A reduced-size RTCP packet is an RTCP packet with the following 508 properties that makes it deviate from the compound RTCP packet 509 definition given in section 6.1 in [RFC3550]: 511 o Contains one or more RTCP packet(s) 513 o Any RTCP packet type allowed, however see section Section 4.2.1. 515 o MUST NOT be used for regular (scheduled) RTCP report purposes 517 o MUST NOT be used with the RTP/AVP profile [RFC3551] or the RTP/ 518 SAVP profile [RFC3711]. 520 4.2. Algorithm Considerations 522 4.2.1. Verification of Delivery 524 If an application is to use reduced-size RTCP it is important to 525 verify that the reduced-size RTCP packets actually reach the session 526 participants. As outlined above in Section 3.4.1 and Section 3.4.2 527 packets may be discarded along the path or in the end-point. 529 A few verification rules are RECOMMENDED to ensure robust RTCP 530 transmission and reception and to solve the identified issues when 531 reduced-size RTCP is used: 533 o The end-point issue can be solved by introducing signaling that 534 informs if all session participants are capable of reduced-size 535 RTCP. See Section 5. 537 o The middle box issue is more difficult and here one will be 538 required to use heuristics to determine if the reduced-size RTCP 539 are delivered or not. The methods detect successful delivery of 540 reduced-size RTCP packets depends on the packet type. The RTCP 541 packet types for which successful delivery can be detected are: 543 * Sender reports (SR): Successful transmission of a sender report 544 can be verified by inspection of the echoed timestamp in the 545 received receiver report (RR). This can also be used as a 546 method to verify if reduced-size RTCP can be used at all. 548 * Feedback RTCP packets: In many cases the feedback messages sent 549 using reduced-size RTCP will result in either explicit or 550 implicit indications that they have been received. An example 551 of is the RTP retransmission [RFC4588] that results from a NACK 552 message [RFC4585]. Another example is the Temporary Maximum 553 Media Bitrate Notification message resulting from a Temporary 554 Maximum Media Bitrate Request [RFC5104]. A third example is 555 the presence of a Decoder Refresh Point [RFC5104] in the video 556 media stream resulting from the Full Intra Request sent. 558 RTCP packet types for which it is not possible to detect 559 successful delivery SHOULD NOT be transmitted as reduced-size RTCP 560 packets unless they are transmitted in the same lower-layer 561 datagram as another RTCP packet type for which successful delivery 562 can be detected. 564 o An algorithm to detect consistent failure of delivery of reduced- 565 size RTCP MUST be used by any application using it. The details 566 of this algorithm are application dependent and therefore outside 567 the scope of this document. 569 If the verification fails it is strongly RECOMMENDED that only 570 compound RTCP according to the rules outlined in RFC3550 is 571 transmitted. 573 4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP 575 The result of the definition in Section 4.1 may be that the resulting 576 size of reduced-size RTCP can become larger than a regularly 577 scheduled compound RTCP packet. For applications that use access 578 types that are sensitive to packet size (see Paragraph 2 in 579 Section 3.3) it is strongly RECOMMENDED that the use of reduced-size 580 RTCP is limited to the transmission of a single RTCP packet in each 581 lower layer datagram. The method to determine the need for this is 582 outside the scope of this draft. 584 In general, as the benefit with large sized reduced-size RTCP packets 585 is very limited, it is strongly RECOMMENDED to transmit large 586 reduced-size RTCP packets as compound RTCP packets instead. 588 4.2.3. Enforcing Compound RTCP 590 As discussed earlier it is important that the transmission of 591 compound RTCP occurs at regular intervals. However, this will occur 592 as long as the RTCP senders follow the AVPF scheduling algorithm 593 defined in Section 3.5 in [RFC4585]. This follows as all regular 594 RTCP MUST be full compound RTCP. Note that there is also a 595 requirement on sending regular RTCP in immediate mode. 597 4.2.4. Immediate Mode 599 Section 3.3 in RFC4585 gives the option to use AVPF Immediate mode as 600 long as the groupsize is below a certain limit. As transmission 601 using reduced-size RTCP may reduce the bandwidth demand it also opens 602 up the possibility of a more liberal use of immediate mode. 604 5. Signaling 606 This document defines the "a=rtcp-rsize" SDP [RFC4566] attribute to 607 indicate if the session participant is capable of supporting reduced- 608 size RTCP for applications that uses SDP for configuration of RTP 609 sessions. It is REQUIRED that a participant that proposes the use of 610 reduced-size RTCP shall itself support the reception of reduced-size 611 RTCP. 613 An offering client that wishes to use reduced-size RTCP MUST include 614 the attribute "a=rtcp-rsize" in the SDP offer. If "a=rtcp-rsize" is 615 present in the offer SDP, the answerer that supports reduced-size 616 RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute 617 in the answer. 619 In declarative usage of SDP such as RTSP [RFC2326] and SAP [RFC2974] 620 the presence of the attribute indicates that the session participant 621 MAY use reduced size RTCP packets in its RTCP transmissions. 623 6. Security Considerations 625 The security considerations of RTP [RFC3550] and AVPF [RFC4585] will 626 apply also to reduced-size RTCP. The reduction in validation 627 strength for received packets on the RTCP port may result in a higher 628 degree of acceptance of spurious data as real RTCP. This 629 vulnerability can mostly be addressed by usage of any security 630 mechanism that provide authentication, one example such mechanism is 631 SRTP [RFC3711]. 633 7. IANA Considerations 635 Following the guidelines in [RFC4566], the IANA is requested to 636 register one new SDP attribute: 638 o Contact name, email address and telephone number: Authors of 639 RFCXXXX 641 o Attribute-name: rtcp-rsize 643 o Long-form attribute name: Reduced-size RTCP 645 o Type of attribute: media-level 647 o Subject to charset: no 649 This attribute defines the support for reduced-size RTCP, i.e the 650 possibility to transmit RTCP that does not conform to the rules for 651 compound RTCP defined in RFC3550. It is a property attribute, which 652 does not take a value. 654 Note to RFC Editor: please replace "RFC XXXX" above with the RFC 655 number of this memo, and remove this note. 657 8. Acknowledgements 659 The authors would like to thank all the people who gave feedback on 660 this document. Special thanks go to Colin Perkins. 662 This document also contain some text copied from [RFC3550], 663 [RFC4585]and [RFC3711]. We take the opportunity to thank the authors 664 of said documents. 666 9. References 668 9.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 674 Jacobson, "RTP: A Transport Protocol for Real-Time 675 Applications", STD 64, RFC 3550, July 2003. 677 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 678 Video Conferences with Minimal Control", STD 65, RFC 3551, 679 July 2003. 681 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 682 "Extended RTP Profile for Real-time Transport Control 683 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 684 July 2006. 686 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 687 Real-time Transport Control Protocol (RTCP)-Based Feedback 688 (RTP/SAVPF)", RFC 5124, February 2008. 690 9.2. Informative References 692 [I-D.ietf-avt-rtp-and-rtcp-mux] 693 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 694 Control Packets on a Single Port", 695 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 696 August 2007. 698 [I-D.ietf-avt-tfrc-profile] 699 Gharai, L., "RTP with TCP Friendly Rate Control", 700 draft-ietf-avt-tfrc-profile-10 (work in progress), 701 July 2007. 703 [MTSI-3GPP] 704 3GPP, "Specification : 3GPP TS 26.114 (v7.4.0), http:// 705 www.3gpp.org/ftp/Specs/archive/26_series/26.114/ 706 26114-740.zip", March 2007. 708 [OMA-PoC] Open Mobile Alliance, "Specification : Push to talk Over 709 Cellular User Plane, http://www.openmobilealliance.org/ 710 release_program/docs/PoC/V1_0_1-20061128-A/ 711 OMA-TS-PoC-UserPlane-V1_0_1-20061128-A.pdf", 712 November 2006. 714 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 715 Streaming Protocol (RTSP)", RFC 2326, April 1998. 717 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 718 Announcement Protocol", RFC 2974, October 2000. 720 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 721 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 722 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 723 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 724 Compression (ROHC): Framework and four profiles: RTP, UDP, 725 ESP, and uncompressed", RFC 3095, July 2001. 727 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 728 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 729 RFC 3711, March 2004. 731 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 732 Description Protocol", RFC 4566, July 2006. 734 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 736 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 737 July 2006. 739 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 740 "Codec Control Messages in the RTP Audio-Visual Profile 741 with Feedback (AVPF)", RFC 5104, February 2008. 743 Authors' Addresses 745 Ingemar Johansson 746 Ericsson AB 747 Laboratoriegrand 11 748 SE-971 28 Lulea 749 SWEDEN 751 Phone: +46 73 0783289 752 Email: ingemar.s.johansson@ericsson.com 754 Magnus Westerlund 755 Ericsson AB 756 Faeroegatan 6 757 SE-164 80 Stockholm 758 SWEDEN 760 Phone: +46 10 7148287 761 Email: magnus.westerlund@ericsson.com 763 Full Copyright Statement 765 Copyright (C) The IETF Trust (2008). 767 This document is subject to the rights, licenses and restrictions 768 contained in BCP 78, and except as set forth therein, the authors 769 retain all their rights. 771 This document and the information contained herein are provided on an 772 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 773 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 774 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 775 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 776 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 777 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 779 Intellectual Property 781 The IETF takes no position regarding the validity or scope of any 782 Intellectual Property Rights or other rights that might be claimed to 783 pertain to the implementation or use of the technology described in 784 this document or the extent to which any license under such rights 785 might or might not be available; nor does it represent that it has 786 made any independent effort to identify any such rights. Information 787 on the procedures with respect to rights in RFC documents can be 788 found in BCP 78 and BCP 79. 790 Copies of IPR disclosures made to the IETF Secretariat and any 791 assurances of licenses to be made available, or the result of an 792 attempt made to obtain a general license or permission for the use of 793 such proprietary rights by implementers or users of this 794 specification can be obtained from the IETF on-line IPR repository at 795 http://www.ietf.org/ipr. 797 The IETF invites any interested party to bring to its attention any 798 copyrights, patents or patent applications, or other proprietary 799 rights that may cover technology that may be required to implement 800 this standard. Please address the information to the IETF at 801 ietf-ipr@ietf.org.