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