idnits 2.17.1 draft-ott-avt-rtcp-guidelines-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 730. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 12, 2008) is 5797 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2733 (Obsoleted by RFC 5109) ** Obsolete normative reference: RFC 5117 (Obsoleted by RFC 7667) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-17 == Outdated reference: A later version (-09) exists of draft-ietf-avt-rtcp-non-compound-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group J. Ott 3 Internet-Draft Helsinki University of Technology 4 Intended status: Informational C. Perkins 5 Expires: December 14, 2008 University of Glasgow 6 June 12, 2008 8 Guidelines for Extending the RTP Control Protocol (RTCP) 9 draft-ott-avt-rtcp-guidelines-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 14, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The RTP Control Protocol (RTCP) is used along with the Real-time 43 Transport Protocol (RTP) to provide a control channel between media 44 senders and receivers. This allows constructing a feedback loop to 45 enable application adaptivity and monitoring, among other uses. The 46 basic reporting mechanisms offered by RTCP are generic, yet quite 47 powerful and suffice to cover a range of uses. This document 48 provides guidelines on extending RTCP if those basic mechanisms prove 49 insufficient. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. RTP and RTCP Operation Overview . . . . . . . . . . . . . . . 4 56 3.1. RTCP Capabilities . . . . . . . . . . . . . . . . . . . . 5 57 3.2. RTCP Limitations . . . . . . . . . . . . . . . . . . . . . 7 58 4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 8 59 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 67 Intellectual Property and Copyright Statements . . . . . . . . . . 17 69 1. Introduction 71 The Real-time Transport Protocol (RTP) [RFC3550] is used to carry 72 time-dependent (often continuous) media such as audio or video across 73 a packet network in an RTP session. RTP usually runs on top of an 74 unreliable transport such as UDP, DTLS, or DCCP, so that RTP packets 75 are susceptible to loss, re-ordering, or duplication. Associated 76 with RTP is the RTP Control Protocol (RTCP) which provides a control 77 channel for each session: media senders provide information about 78 their current sending activities ("feed forward") and media receivers 79 report on their reception statistics ("feedback") in terms of 80 received packets, losses, and jitter. Senders and receivers provide 81 self-descriptions allowing to disambiguate all entities in an RTP 82 session and correlate SSRC identifiers with specific application 83 instances. RTCP is carried over the same transport as RTP and is 84 hence inherently best-effort and hence the RTCP reports are designed 85 for such an unreliable environment, e.g., by making them "for 86 information only". 88 The RTCP control channel provides coarse-grained information about 89 the session in two respects: 1) the RTCP SR and RR packets contain 90 only cumulative information or means over a certain period of time 91 and 2) the time period is in the order of seconds and thus neither 92 has a high resolution nor does the feedback come back 93 instantaneously. Both these restrictions have their origin in RTP 94 being scalable and generic. Even these basic mechanisms (which are 95 still not implemented everywhere despite their simplicity and very 96 precise specification, including sample code) offer substantial 97 information for designing adaptive applications and for monitoring 98 purposes, among others. 100 Recently, numerous extensions have been proposed in different 101 contexts to RTCP which significantly increase the complexity of the 102 protocol and the reported values, mutate it toward an command 103 channel, and/or attempt turning it into a reliable messaging 104 protocol. While the reasons for such extensions may be legitimate, 105 many of the resulting designs appear ill-advised in the light of the 106 RTP architecture. Moreover, extensions are often badly motivated and 107 thus appear unnecessary given what can be achieved with the RTCP 108 mechanisms in place today. 110 This document is intended to provide some guidelines for designing 111 RTCP extensions. It is particularly intended to avoid an extension 112 creep for corner cases which can only harm interoperability and 113 future evolution of the protocol at large. We first outline the 114 basic operation of RTCP and constructing feedback loops using the 115 basic RTCP mechanisms. Subsequently, we outline categories of 116 extensions proposed (and partly already accepted) for RTCP and 117 discuss issues and alternative ways of thinking by example. Finally, 118 we provide some guidelines and highlight a number of questions to ask 119 (and answer!) before writing up an RTCP extension. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in BCP 14, RFC 2119 126 [RFC2119] and indicate requirement levels for compliant 127 implementations. 129 The terminology defined in RTP [RFC3550], the RTP Profile for Audio 130 and Video Conferences with Minimal Control [RFC3551], and the 131 Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] 132 apply. 134 3. RTP and RTCP Operation Overview 136 One of the twelve networking truths states: "In protocol design, 137 perfection has been reached not when there is nothing left to add, 138 but when there is nothing left to take away" [RFC1925]. Despite (or 139 because of) this being an April, 1st, RFC, this specific truth is 140 very valid and it applies to RTCP as well. 142 In this section, we will briefly review what is available from the 143 basic RTP/RTCP specifications. As specifications, we include those 144 which are generic, i.e., do not have dependencies on particular media 145 types. This includes the RTP base specification [RFC3550] and 146 profile [RFC3551], the RTCP bandwidth modifiers for session 147 descriptions [RFC3556], the timely feedback extensions (RFC 4585), 148 and the extensions to run RTCP over SSM networks. RTCP XR [RFC3611] 149 provides extended reporting mechanisms which are partly generic in 150 nature, partly specific to a certain media stream. 152 We do not discuss RTP-related documents that are orthogonal to RTCP. 153 The Secure RTP Profile [RFC3711] can be used to secure RTCP in much 154 the same way it secures RTP data, but otherwise does not affect the 155 behaviour of RTCP. The transport protocol used also has little 156 impact, since RTCP remains a group communication protocol even when 157 running over a unicast transport (such as TCP [RFC4571] or DCCP 158 [I-D.ietf-dccp-rtp]), and is little affected by congestion control 159 due to its low rate relative to the media. The description of RTP 160 topologies [RFC5117] is useful knowledge, but is functionally not 161 relevant here. The various RTP error correction mechanisms (e.g. 162 [RFC2198], [RFC2733], [RFC4588], [RFC5109]) are useful for protecting 163 RTP media streams, and may be enabled as a result of RTCP feedback, 164 but do not directly affect RTCP behaviour. 166 3.1. RTCP Capabilities 168 The RTP/RTCP specifications quoted above provide feedback mechanisms 169 with the following properties, which can be considered as "building 170 blocks" for adaptive real-time applications for IP networks. 172 o Sender Reports (SR) indicate to the receivers the total number of 173 packets and octets have been sent (since the beginning of the 174 session or the last change of the sender's SSRC). These values 175 allow deducing the mean data rate and mean packet size for both 176 the entire session and, if continuously monitored, for every 177 transmission interval. They also allow a receiver to distinguish 178 between breaks in reception caused by network problems, and those 179 due to pauses in transmission. 180 o Receiver Reports (RR) and SRs indicate reception statistics from 181 each receiver for every sender. These statistics include: 182 * The packet loss rate since the last SR or RR was sent. 183 * The total number of packets lost since the beginning of the 184 session which may again be broken down to each reporting 185 period. 186 * The highest sequence number received so far -- which allows a 187 sender to roughly estimate how much data is in flight when used 188 together with the SR and RR timestamps (and also allows 189 observing whether the path still works and at which rate 190 packets are delivered to the receiver). 191 * The moving average of the inter-arrival jitter of media 192 packets. This gives the sender an indirect view of the size of 193 any adaptive playout buffer used at the receiver ([RFC3611] 194 gives precise figures for VoIP sessions). 195 o Sender Reports also contain NTP and RTP format timestamps. These 196 allow receivers to synchronise multiple RTP streams, and (when 197 used in conjunction with Receiver Reports) allow the sender to 198 calculate the current RTT to each receiver. This value can be 199 monitored over time and thus may be used to infer trends at coarse 200 granularity. A similar mechanism is provided by [RFC3611] to 201 allow receivers to calculate the RTT to senders. 203 RTCP sender reports and receiver reports are sent, and the statistics 204 are sampled, at random intervals chosen uniformly in the range 0.5 205 ... 1.5 times the deterministic calculated interval, T. The interval 206 T is calculated based on the media bit rate, the mean RTCP packet 207 size, whether the sampling node is a sender or a receiver, and the 208 number of participants in the session, and will remain constant while 209 the number of participants in the session remains constant. The 210 lower bound on the base inter-report interval, T, is five seconds, or 211 360 seconds divided by the session bandwidth in kilobits/second 212 (giving an interval smaller than 5 seconds for bandwidths greater 213 than 72 kb/s) [RFC3550]. 215 This lower limit can be eliminated, allowing more frequent feedback, 216 when using the early feedback profile for RTCP [RFC4585]. In this 217 case, the RTCP frequency is only limited by the available bitrate 218 (usually 5% of the media stream bit rate is allocated for RTCP). If 219 this fraction is insufficient, the RTCP bitrate may be increased in 220 the session description to enable more frequent feedback [RFC3556]. 221 Ongoing work [I-D.ietf-avt-rtcp-non-compound] may reduce the mean 222 RTCP packet size, further increasing feedback frequency. 224 The mechanisms defined in [RFC4585] even allow -- statistically -- a 225 receiver to provide close-to-instant feedback to a sender about 226 observed events in the media stream (e.g. picture or slice loss). 228 RTCP is suitable for unicast and multicast communications. All basic 229 functions are designed with group communications in mind. While 230 traditional (any-source) multicast (ASM) is clearly not available in 231 the Internet at large, source-specific multicast (SSM) and overlay 232 multicast are -- and both are commercially relevant. RTCP extensions 233 have been defined to operate over SSM, and complex topologies may be 234 created by interconnecting RTP mixers and translators. The group 235 communication nature of RTP and RTCP is also essential for the 236 operation of Multipoint Conference Units. 238 These mechanisms can used to implement a quite flexible feedback loop 239 and enable short-term reaction to observed events as well as long 240 term adaptation to changes in the networking environment. Adaptation 241 mechanisms available on the sender side include (but are not limited 242 to) choosing different codecs, different parameters for codecs 243 (spatial or temporal resolution for video, audible quality for audio 244 and voice), and different packet sizes to adjust the bit rate. 245 Furthermore, various forward error correction mechanisms and, if RTTs 246 are short and the application permits extra delays, even reactive 247 error control such as retransmissions. Long-term feedback can be 248 provided in regular RTCP reports at configurable intervals, whereas 249 (close-to-)instant feedback is available by means of the early 250 feedback profile. Figure 1 below outlines this idea graphically. 252 Long-term adaptation: RTCP Sender Reports Media processing: 253 - Codec+parameter choice - Data rate, pkt count - Dejittering 254 - Packet size - Timing and sync info - Synchronization 255 - FEC, interleaving - Traffic characteristics - Error concealment 256 --------------------------------> - Playout 257 +---------------+/ \+---------------+ 258 | | RTP media stream (codec, repair) | | 259 | Media Sender |=================================>| Media receiver | 260 | | | | 261 +---------------+\ RTCP Receiver Reports /+---------------+ 262 <-------------------------------- 263 Short-term reaction: - long-term statistics Control functions: 264 - Retransmissions - event information - RTP monitoring 265 - Retro-active FEC - media-specific info and reporting 266 - Adaptive source coding - "congestion info"(*) - Instant event 267 - Congestion control(*) notifications 269 (*) RTCP feedback is insufficient for TCP-Friendly congestion control 270 purposes due to the infrequent nature of reporting (which should 271 be in the order of once per RTT), but can still be used to adapt 272 to the available bandwidth on slower timescales. 274 Figure 1: Outline of an RTCP Feedback Loop 276 It is important to note that not all information needs to be 277 signalled explicitly -- ever or upon every RTCP packet -- but can be 278 derived locally from other pieces of information and from the 279 evolution of the information over time. 281 3.2. RTCP Limitations 283 The design of RTP limits what can meaningfully be done (and hence 284 should be done) with RTCP. In particular, the design favours 285 scalability and loose coupling over tightly controlled feedback 286 loops. Some of these limitations are listed below (they need to be 287 taken into account when designing extensions): 289 o RTCP is designed to provide occasional feedback which is unlike, 290 e.g., TCP ACKs which can be sent in response to every (other) 291 packet. It does not offer per-packet feedback (even when using 292 [RFC4585] with increased RTCP bandwidth fraction, the feedback 293 guarantees are only statistical in nature). 294 o RTCP is not capable of providing truly instant feedback. 295 o RTCP is inherently unreliable, and does not guarantee any 296 consistency between the observed state at multiple members of a 297 group. 299 It is important to note that these features of RTCP are intentional 300 design choices, and are essential for it to scale to large groups. 302 4. Issues with RTCP Extensions 304 Issues that have come up in the past with extensions to RTP and RTCP 305 include (but are probably not limited to) the following: 307 o Defined only or primarily for unicast two-party sessions. RTP is 308 inherently a group communication protocol, even when operating on 309 a unicast connection. Extensions may become useful in the future 310 well outside their originally intended area of application, and 311 should consider this. Stating that something works for unicast 312 only is not acceptable, particularly since various flavours of 313 multicast have become relevant again, and as middleboxes such as 314 repair servers, mixers, and RTCP-supporting MCUs [RFC5117] become 315 more widely used. 316 o Assuming reliable (instant) state synchronization. RTCP reports 317 are sent irregularly and may be lost. Hence, there may be a 318 significant time lag (several seconds) between intending to send a 319 state update to the RTP peer(s) and the packet being received, in 320 some cases, the packet may not be received at all. 321 o Requiring reliable delivery of RTCP reports. While reliability 322 can be implemented on top of RTCP using acknowledgements, this 323 will come at the cost of significant additional delay, which may 324 defeat the purpose of providing the feedback in the first place. 325 Moreover, for scalability reasons due to the group-based nature of 326 RTCP, these ACKs need to be adaptively rate limited or targeted to 327 a subgroup or individual entity to avoid implosion as group sizes 328 increase. RTCP is not intended or suitable for use as a reliable 329 control channel. 330 o Commands are issued, rather than hints given. RTCP is about 331 reporting observations -- in a best-effort manner -- between RTP 332 entities. Causing actions on the remote side requires some form 333 of reliability (see above), and adherence cannot be verified. 334 o RTCP reporting is expanded to become a network management tool. 335 RTCP is sensitive to the size of RTCP reports as the latter 336 determines the mean reporting interval given a certain bit rate 337 share for RTCP. The amount of information going into RTCP reports 338 should primarily target the peer (and thus include information 339 that can be meaningfully reacted upon). Gathering and reporting 340 statistics beyond this is not an RTCP task and should be addressed 341 by out-of-band protocols. 342 o Serious complexity is created. Related to the previous item, RTCP 343 reports that convey all kinds of data first need to gather and 344 calculate/infer this information to begin with (which requires 345 very precise specifications). Given that it already seems to be 346 difficult to even implement baseline RTCP, any added complexity 347 can only discourage implementers, may lead to buggy 348 implementations (in which case the reports do not serve the 349 purpose they were intended to), and hinder interoperability. 350 o Architectural issues. Extensions are written without considering 351 the architectural concepts of RTP. For example, point-to-point 352 communication is assumed, yet third party monitors are expected to 353 listen in. Besides being a bad idea to rely on eavesdropping 354 entities on the path, this is obviously not possible if SRTP is 355 being used with encrypted SRTCP packets. 357 This list is surely not exhaustive. Also, the authors do not claim 358 that the suggested extensions (even if using acknowledgements) would 359 not serve a legitimate purpose. We rather want to draw attention to 360 the fact that the same results may be achievable in a way which is 361 architecturally cleaner and conceptually more RTP/RTCP-compliant. 362 The following section contains a first attempt to provide some 363 guidelines on what to consider when thinking about extensions to RTP 364 and RTCP. 366 5. Guidelines 368 Designing RTCP extensions requires consideration of a number issues, 369 as well as in-depth understanding of the operation of RTP mechanisms. 370 While it is expected that there are many aspects not yet covered by 371 RTCP reporting and operation, quite a bit of functionality is readily 372 available for use. Other mechanisms should probably never become 373 part of the RTP family of specifications, despite the existance of 374 their equivalents in other environments. In the following, we 375 provide some guidance to consider when (and before!) developing an 376 extension to RTCP. 378 We begin with a short check list concerning the applicability of RTCP 379 in the first place: 381 o Check what can be done with the existing mechanisms, exploiting 382 the information that is already available in RTCP. Is the need 383 for an extension only perceived (e.g., due to lazy implementers, 384 or artificial constraints in endpoints), or is the function or 385 data really not available (or derivable from existing reports)? 386 It is worthwhile remembering that redundant information supplied 387 by a protocol runs the risk of being inconsistent at some point, 388 and various implementation may handle such situations differently 389 (e.g., give precedence to different values). Similarly, there 390 should be exactly one (well-specified) way of performing every 391 function and operation of the protocol. 393 o Is the extension applicable to RTP entities running anywhere in 394 the Internet, or is it a link- or environment-specific extension? 395 In the latter cases, local extensions (e.g. header compression, or 396 non-RTP protocols) may be preferable. RTCP should not be used to 397 carry information specific to a particular (access) link. 398 o Is the extension applicable in a group communication environment, 399 or is it specific to point-to-point communications? RTP and RTCP 400 are inherently group communication protocols, and extensions must 401 scale gracefully with increasing group sizes. 403 From a conceptual viewpoint, the designer of every RTCP extension 404 should ask -- and answer(!) -- at least the following questions: 406 o How will this new building block complement and work with the 407 other components of RTCP? Are all interactions fully specified? 408 o Will this extension work with all different profiles (e.g. the 409 Secure RTP Profile [RFC3711], and the Extended RTP Profile for 410 RTCP-based Feedback [RFC4585])? Are any feature interactions 411 expected? 412 o Should this extension be kept in-line with baseline RTP and its 413 existing profiles, or does it deviate so much from the base RTP 414 operation that an incompatible new profile must be defined? Use 415 and definition of incompatible profiles is strongly discouraged, 416 but if they prove necessary, how do nodes using the different 417 profiles interact? What are the failure modes, and how is it 418 ensured that the system fails in a safe manner? 419 o How does this extension interoperate with other nodes when the 420 extension is not understood by the peer(s)? 421 o How will the extension deal with different networking conditions 422 (e.g., how does performance degrade with increases in losses and 423 latency, possibly across orders of magnitude)? 424 o How will this extension work with group communication scenarios, 425 such as multicast? Will the extensions degrade gracefully with 426 increasing group sizes? What will be the impact on the RTCP 427 report frequency and bitrate allocation? 429 For the specific design, the following considerations should be taken 430 into account (they're a mixture of common protocol design guidelines, 431 and specifics for RTCP): 433 o First of all, if there is (and for RTCP this applies quite often) 434 an old-style mechanisms from a different networking environment, 435 don't try to directly recreate this mechanism in RTP/RTCP. The 436 Internet environment is extremely heterogeneous, and will often 437 have drastically different properties and behaviour to other 438 network environments. Instead, ask what the actual semantics and 439 the result required to be perceived by the application or the user 440 are. Then, design a mechanism that achieves this result in a way 441 that is compatible with RTP/RTCP. (And do not forget that every 442 mechanism will break when no packets get through -- the Internet 443 does not guarantee connectivity or performance.) 444 o Target re-usability of the specification. That is, think broader 445 than a specific use case and try to solve the general problem in 446 cases where it makes sense to do so. Point solutions need a very 447 good motivation to be dealt with in the IETF in the first place. 448 This essentially suggests developing buildings blocks whenever 449 possible, allowing them to be combined in different environments 450 than initially considered. Where possible, avoid mechanisms that 451 are specific to particular payload formats, media types, link or 452 network types, etc. 453 o For everything (packet format, value, procedure, timer, etc.) 454 being defined, make sure that it is defined properly, so that 455 independent interoperable implementation can be built. It is not 456 sufficient that you can implement the feature: it has to be 457 implementable in several years by someone unfamiliar with the 458 working group discussion and industry context. Remember that 459 fields need to be both generated and reacted upon, that mechanisms 460 need to be implemented, etc., and that all of this increases the 461 complexity of an implementation. Features which are too complex 462 won't get implemented (correctly) in the first place. 463 o Extensions defining new metrics and parameters should reference 464 existing standards whenever possible, rather than try to invent 465 something new and/or proprietary. 466 o Remember that not every bit or every action must be represented or 467 signalled explicitly. It may be possible to infer the necessary 468 pieces of information from other values or their evolution (a very 469 prominent example is TCP congestion control). As a result, it may 470 be possible to decouple bits on the wire from local actions and 471 reduce the overhead. 472 o Particularly with media streams, reliability can often be "soft". 473 Rather than implementing explicit acknowledgements, receipt of a 474 hint may also be observed from the altered behaviour (e.g., the 475 reception of a requested intra-frame, or changing the reference 476 frame for video, changing the codec, etc.). The semantics of 477 messages should be idempotent so that the respective message may 478 be sent repeatedly. Requiring hard reliability does not scale 479 with increasing group sizes, and does not degrade gracefully as 480 network performance reduces. 481 o Choose the appropriate extension point. Depending on the type of 482 RTCP extension being developed, new data items can be transported 483 in several different ways: 484 * A new RTCP SDES item is appropriate for transporting data that 485 describes the source, or the user represented by the source, 486 rather than the ongoing media transmission. New SDES items may 487 be registered to transport source description information of 488 general interest, or the PRIV item may be used for proprietary 489 extensions. 490 * A new RTCP XR block type is appropriate for transporting new 491 metrics regarding transmission or reception quality. 492 * New RTP profiles may define a profile-specific extension to 493 RTCP SR and/or RR packets, to give additional feedback. Such 494 extension is not recommended, since the resulting packets are 495 not backwards compatible. It's generally more appropriate to 496 define a new RTCP XR block or a new RTCP packet type instead. 497 * New RTCP AVPF transport layer feedback messages should be used 498 to transmit general purpose feedback information, to be 499 generated and processed by the RTP transport. Examples include 500 (negative) acknowledgements for particular packets, or requests 501 to limit the transmission rate. This information is intended 502 to be independent of the codec or application in use. 503 * New RTCP AVPF payload-specific feedback messages should be used 504 to convey feedback information that is specific to a particular 505 media codec, RTP payload format, or category of RTP payload 506 formats. Examples include video picture loss indication or 507 reference picture selection, that are useful for many video 508 codecs. 509 * New RTCP AVPF application layer feedback messages should be 510 used to convery higher-level feedback, from one application to 511 another, above the level of codecs or transport. 512 * A new RTCP APP packet is appropriate for private use by 513 applications that don't need to interoperate with others, or 514 for experimentation before registering a new RTCP packet type. 515 It is not appropriate to register an RTCP APP packet in a 516 standards document. 517 Finally, new RTCP packet types may be registered if none of the 518 other extension points are appropriate. 520 The RTP framework was designed following the principle of application 521 level framing with integrated layer processing, proposed by Clark and 522 Tennenhouse [ALF]. Effective use of RTP requires that extensions and 523 implementations be designed and built following the same philosophy. 524 That philosophy differs markedly from many previous systems in this 525 space, and making effective use of RTP requires an understanding of 526 those differences. 528 6. Security Considerations 530 This memo does not specify any new protocol mechansims or procedures, 531 and so raises no explicit security considerations. When designing 532 RTCP extensions, it is important to consider the following points: 534 o Privacy: RTCP extensions, in particular new Source Description 535 (SDES) items, can potentially reveal information considered to be 536 sensitive by end users. Extensions should carefully consider the 537 uses to which information the release could be put, and should be 538 designed to reveal the minimum amount of additional information 539 needed for their correct operation. 540 o Congestion control: RTCP transmission timers have been carefully 541 designed such that the total amount of traffic generated by RTCP 542 is a small fraction of the media data rate. One consequence of 543 this is that the individual RTCP reporting interval scales with 544 both the media data rate and the group size. The RTCP timing 545 algorithms have been shown to scale from two-party unicast 546 sessions to group with tens of thousands of participants, and to 547 gracefully handle flash crowds and sudden departures [TimerRecon]. 548 Proposals that modify the RTCP timer algorithms must be careful to 549 avoid congestion, potentially leading to denial of service, across 550 the full range of environments where RTCP is used. 551 o Denial of service: RTCP extensions that change the location where 552 feedback is sent must be carefully designed to prevent denial of 553 service attacks against third party nodes. When such extensions 554 are signalled, for example in SDP, this typically requires some 555 form of authentication of the signalling messages (e.g. see the 556 security considerations of [I-D.ietf-avt-rtcpssm]). 558 At the time of this writing there are several proposals for in-band 559 signalling of secure RTP sessions, where the signalling information 560 is conveyed on the media path. These proposals were discussed in the 561 Audio/Video Transport working group session at the 67th IETF meeting, 562 with the consensus being that such signalling is not to be conveyed 563 within RTP data packets, but should instead be sent within some form 564 of control packet, and that it is acceptable to multiplex control and 565 data packets on the same port, provided the packet types can be 566 clearly distinguished. There was no consensus in the working group 567 on the question of whether keying information should be conveyed in 568 RTCP packets multiplexed on the RTP port, or in some other protocol 569 multiplexed on the RTP port. The opinion of the working group chairs 570 and area director was, however, that both approaches are workable, 571 and fit within the RTP architecture, but that it may be cleaner to 572 use a separate keying protocol (modelled after STUN), than to try to 573 fit keying within RTCP 575 The security considerations of the RTP specification [RFC3550] apply, 576 along with any applicable profile (e.g. [RFC3551]). 578 7. IANA Considerations 580 No IANA actions are necessary. 582 8. Acknowledgements 584 This draft has been motivated by many discussions in the AVT WG. The 585 authors would like to acknowledge the active members in the group for 586 providing the inspiration. 588 9. References 590 9.1. Normative References 592 [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, 593 April 1996. 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 599 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 600 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 601 September 1997. 603 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 604 for Generic Forward Error Correction", RFC 2733, 605 December 1999. 607 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 608 Jacobson, "RTP: A Transport Protocol for Real-Time 609 Applications", STD 64, RFC 3550, July 2003. 611 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 612 Video Conferences with Minimal Control", STD 65, RFC 3551, 613 July 2003. 615 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 616 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 617 RFC 3556, July 2003. 619 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 620 Protocol Extended Reports (RTCP XR)", RFC 3611, 621 November 2003. 623 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 624 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 625 RFC 3711, March 2004. 627 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 628 and RTP Control Protocol (RTCP) Packets over Connection- 629 Oriented Transport", RFC 4571, July 2006. 631 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 632 "Extended RTP Profile for Real-time Transport Control 633 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 634 July 2006. 636 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 637 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 638 July 2006. 640 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 641 Correction", RFC 5109, December 2007. 643 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 644 January 2008. 646 9.2. Informative References 648 [I-D.ietf-avt-rtcpssm] 649 Ott, J., "RTCP Extensions for Single-Source Multicast 650 Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 651 (work in progress), January 2008. 653 [I-D.ietf-avt-rtcp-non-compound] 654 Johansson, I. and M. Westerlund, "Support for non-compound 655 RTCP, opportunities and consequences", 656 draft-ietf-avt-rtcp-non-compound-02 (work in progress), 657 February 2008. 659 [I-D.ietf-dccp-rtp] 660 Perkins, C., "RTP and the Datagram Congestion Control 661 Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in 662 progress), June 2007. 664 [ALF] Clark, D. and D. Tennenhouse, "Architectural 665 Considerations for a New Generation of Protocols", 666 Proceedings of ACM SIGCOMM 1990, September 1990. 668 [TimerRecon] 669 Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration 670 for Enhanced RTP Scalability", Proceedings of IEEE 671 Infocom 1998, March 1998. 673 Authors' Addresses 675 Joerg Ott 676 Helsinki University of Technology 677 Otakaari 5 A 678 Espoo, FIN 02150 679 Finland 681 Email: jo@netlab.hut.fi 683 Colin Perkins 684 University of Glasgow 685 Department of Computing Science 686 Lilybank Gardens 687 Glasgow G12 8QQ 688 United Kingdom 690 Email: csp@csperkins.org 692 Full Copyright Statement 694 Copyright (C) The IETF Trust (2008). 696 This document is subject to the rights, licenses and restrictions 697 contained in BCP 78, and except as set forth therein, the authors 698 retain all their rights. 700 This document and the information contained herein are provided on an 701 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 702 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 703 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 704 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 705 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 706 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 708 Intellectual Property 710 The IETF takes no position regarding the validity or scope of any 711 Intellectual Property Rights or other rights that might be claimed to 712 pertain to the implementation or use of the technology described in 713 this document or the extent to which any license under such rights 714 might or might not be available; nor does it represent that it has 715 made any independent effort to identify any such rights. Information 716 on the procedures with respect to rights in RFC documents can be 717 found in BCP 78 and BCP 79. 719 Copies of IPR disclosures made to the IETF Secretariat and any 720 assurances of licenses to be made available, or the result of an 721 attempt made to obtain a general license or permission for the use of 722 such proprietary rights by implementers or users of this 723 specification can be obtained from the IETF on-line IPR repository at 724 http://www.ietf.org/ipr. 726 The IETF invites any interested party to bring to its attention any 727 copyrights, patents or patent applications, or other proprietary 728 rights that may cover technology that may be required to implement 729 this standard. Please address the information to the IETF at 730 ietf-ipr@ietf.org. 732 Acknowledgment 734 Funding for the RFC Editor function is provided by the IETF 735 Administrative Support Activity (IASA).