idnits 2.17.1 draft-ietf-avt-rtcp-guidelines-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2010) is 5178 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2326 (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 5117 (Obsoleted by RFC 7667) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group J. Ott 3 Internet-Draft Aalto University 4 Intended status: Informational C. Perkins 5 Expires: August 25, 2010 University of Glasgow 6 February 21, 2010 8 Guidelines for Extending the RTP Control Protocol (RTCP) 9 draft-ietf-avt-rtcp-guidelines-03.txt 11 Abstract 13 The RTP Control Protocol (RTCP) is used along with the Real-time 14 Transport Protocol (RTP) to provide a control channel between media 15 senders and receivers. This allows constructing a feedback loop to 16 enable application adaptation and monitoring, among other uses. The 17 basic reporting mechanisms offered by RTCP are generic, yet quite 18 powerful and suffice to cover a range of uses. This document 19 provides guidelines on extending RTCP if those basic mechanisms prove 20 insufficient. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 25, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. RTP and RTCP Operation Overview . . . . . . . . . . . . . . . 4 77 3.1. RTCP Capabilities . . . . . . . . . . . . . . . . . . . . 5 78 3.2. RTCP Limitations . . . . . . . . . . . . . . . . . . . . . 7 79 3.3. Interactions with Network and Transport Layer 80 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 8 82 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The Real-time Transport Protocol (RTP) [RFC3550] is used to carry 94 time-dependent (often continuous) media such as audio or video across 95 a packet network in an RTP session. RTP usually runs on top of an 96 unreliable transport such as UDP, DTLS, or DCCP, so that RTP packets 97 are susceptible to loss, re-ordering, or duplication. Associated 98 with RTP is the RTP Control Protocol (RTCP) which provides a control 99 channel for each session: media senders provide information about 100 their current sending activities ("feed forward") and media receivers 101 report on their reception statistics ("feedback") in terms of 102 received packets, losses, and jitter. Senders and receivers provide 103 self-descriptions allowing to disambiguate all entities in an RTP 104 session and correlate SSRC identifiers with specific application 105 instances. RTCP is carried over the same transport as RTP and is 106 hence inherently best-effort and hence the RTCP reports are designed 107 for such an unreliable environment, e.g., by making them "for 108 information only". 110 The RTCP control channel provides coarse-grained information about 111 the session in two respects: 1) the RTCP SR and RR packets contain 112 only cumulative information or means over a certain period of time 113 and 2) the time period is in the order of seconds and thus neither 114 has a high resolution nor does the feedback come back 115 instantaneously. Both these restrictions have their origin in RTP 116 being scalable and generic. Even these basic mechanisms (which are 117 still not implemented everywhere despite their simplicity and very 118 precise specification, including sample code) offer substantial 119 information for designing adaptive applications and for monitoring 120 purposes, among others. 122 Recently, numerous extensions have been proposed in different 123 contexts to RTCP which significantly increase the complexity of the 124 protocol and the reported values, mutate it toward an command 125 channel, and/or attempt turning it into a reliable messaging 126 protocol. While the reasons for such extensions may be legitimate, 127 many of the resulting designs appear ill-advised in the light of the 128 RTP architecture. Moreover, extensions are often badly motivated and 129 thus appear unnecessary given what can be achieved with the RTCP 130 mechanisms in place today. 132 This document is intended to provide some guidelines for designing 133 RTCP extensions. It is particularly intended to avoid an extension 134 creep for corner cases which can only harm interoperability and 135 future evolution of the protocol at large. We first outline the 136 basic operation of RTCP and constructing feedback loops using the 137 basic RTCP mechanisms. Subsequently, we outline categories of 138 extensions proposed (and partly already accepted) for RTCP and 139 discuss issues and alternative ways of thinking by example. Finally, 140 we provide some guidelines and highlight a number of questions to ask 141 (and answer!) before writing up an RTCP extension. 143 2. Terminology 145 The terminology defined in RTP [RFC3550], the RTP Profile for Audio 146 and Video Conferences with Minimal Control [RFC3551], and the 147 Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] 148 apply. 150 3. RTP and RTCP Operation Overview 152 One of the twelve networking truths states: "In protocol design, 153 perfection has been reached not when there is nothing left to add, 154 but when there is nothing left to take away" [RFC1925]. Despite (or 155 because of) this being an April, 1st, RFC, this specific truth is 156 very valid and it applies to RTCP as well. 158 In this section, we will briefly review what is available from the 159 basic RTP/RTCP specifications. As specifications, we include those 160 which are generic, i.e., do not have dependencies on particular media 161 types. This includes the RTP base specification [RFC3550] and 162 profile [RFC3551], the RTCP bandwidth modifiers for session 163 descriptions [RFC3556], the timely feedback extensions (RFC 4585), 164 and the extensions to run RTCP over SSM networks 165 [I-D.ietf-avt-rtcpssm]. RTCP XR [RFC3611] provides extended 166 reporting mechanisms which are partly generic in nature, partly 167 specific to a certain media stream. 169 We do not discuss RTP-related documents that are orthogonal to RTCP. 170 The Secure RTP Profile [RFC3711] can be used to secure RTCP in much 171 the same way it secures RTP data, but otherwise does not affect the 172 behaviour of RTCP. The transport protocol used also has little 173 impact, since RTCP remains a group communication protocol even when 174 running over a unicast transport (such as TCP [RFC4571] or DCCP 175 [I-D.ietf-dccp-rtp]), and is little affected by congestion control 176 due to its low rate relative to the media. The description of RTP 177 topologies [RFC5117] is useful knowledge, but is functionally not 178 relevant here. The various RTP error correction mechanisms (e.g. 179 [RFC2198], [RFC4588], [RFC5109]) are useful for protecting RTP media 180 streams, and may be enabled as a result of RTCP feedback, but do not 181 directly affect RTCP behaviour. 183 3.1. RTCP Capabilities 185 The RTP/RTCP specifications quoted above provide feedback mechanisms 186 with the following properties, which can be considered as "building 187 blocks" for adaptive real-time applications for IP networks. 189 o Sender Reports (SR) indicate to the receivers the total number of 190 packets and octets have been sent (since the beginning of the 191 session or the last change of the sender's SSRC). These values 192 allow deducing the mean data rate and mean packet size for both 193 the entire session and, if continuously monitored, for every 194 transmission interval. They also allow a receiver to distinguish 195 between breaks in reception caused by network problems, and those 196 due to pauses in transmission. 198 o Receiver Reports (RR) and SRs indicate reception statistics from 199 each receiver for every sender. These statistics include: 201 * The packet loss rate since the last SR or RR was sent. 203 * The total number of packets lost since the beginning of the 204 session which may again be broken down to each reporting 205 period. 207 * The highest sequence number received so far -- which allows a 208 sender to roughly estimate how much data is in flight when used 209 together with the SR and RR timestamps (and also allows 210 observing whether the path still works and at which rate 211 packets are delivered to the receiver). 213 * The moving average of the inter-arrival jitter of media 214 packets. This gives the sender an indirect view of the size of 215 any adaptive playout buffer used at the receiver ([RFC3611] 216 gives precise figures for VoIP sessions). 218 o Sender Reports also contain NTP and RTP format timestamps. These 219 allow receivers to synchronise multiple RTP streams, and (when 220 used in conjunction with Receiver Reports) allow the sender to 221 calculate the current RTT to each receiver. This value can be 222 monitored over time and thus may be used to infer trends at coarse 223 granularity. A similar mechanism is provided by [RFC3611] to 224 allow receivers to calculate the RTT to senders. 226 RTCP sender reports and receiver reports are sent, and the statistics 227 are sampled, at random intervals chosen uniformly in the range 0.5 228 ... 1.5 times the deterministic calculated interval, T. The interval 229 T is calculated based on the media bit rate, the mean RTCP packet 230 size, whether the sampling node is a sender or a receiver, and the 231 number of participants in the session, and will remain constant while 232 the number of participants in the session remains constant. The 233 lower bound on the base inter-report interval, T, is five seconds, or 234 360 seconds divided by the session bandwidth in kilobits/second 235 (giving an interval smaller than 5 seconds for bandwidths greater 236 than 72 kb/s) [RFC3550]. 238 This lower limit can be eliminated, allowing more frequent feedback, 239 when using the early feedback profile for RTCP [RFC4585]. In this 240 case, the RTCP frequency is only limited by the available bitrate 241 (usually 5% of the media stream bit rate is allocated for RTCP). If 242 this fraction is insufficient, the RTCP bitrate may be increased in 243 the session description to enable more frequent feedback [RFC3556]. 244 Ongoing work [RFC5506] may reduce the mean RTCP packet size, further 245 increasing feedback frequency. 247 The mechanisms defined in [RFC4585] even allow -- statistically -- a 248 receiver to provide close-to-instant feedback to a sender about 249 observed events in the media stream (e.g. picture or slice loss). 251 RTCP is suitable for unicast and multicast communications. All basic 252 functions are designed with group communications in mind. While 253 traditional (any-source) multicast (ASM) is clearly not available in 254 the Internet at large, source-specific multicast (SSM) and overlay 255 multicast are -- and both are commercially relevant. RTCP extensions 256 have been defined to operate over SSM, and complex topologies may be 257 created by interconnecting RTP mixers and translators. The group 258 communication nature of RTP and RTCP is also essential for the 259 operation of Multipoint Conference Units. 261 These mechanisms can used to implement a quite flexible feedback loop 262 and enable short-term reaction to observed events as well as long 263 term adaptation to changes in the networking environment. Adaptation 264 mechanisms available on the sender side include (but are not limited 265 to) choosing different codecs, different parameters for codecs 266 (spatial or temporal resolution for video, audible quality for audio 267 and voice), and different packet sizes to adjust the bit rate. 268 Furthermore, various forward error correction mechanisms and, if RTTs 269 are short and the application permits extra delays, even reactive 270 error control such as retransmissions. Long-term feedback can be 271 provided in regular RTCP reports at configurable intervals, whereas 272 (close-to-)instant feedback is available by means of the early 273 feedback profile. Figure 1 below outlines this idea graphically. 275 Long-term adaptation: RTCP Sender Reports Media processing: 276 - Codec+parameter choice - Data rate, pkt count - De-jittering 277 - Packet size - Timing and sync info - Synchronisation 278 - FEC, interleaving - Traffic characteristics - Error concealment 279 --------------------------------> - Playout 280 +---------------+/ \+---------------+ 281 | | RTP media stream (codec, repair) | | 282 | Media Sender |=================================>| Media receiver | 283 | | | | 284 +---------------+\ RTCP Receiver Reports /+---------------+ 285 <-------------------------------- 286 Short-term reaction: - long-term statistics Control functions: 287 - Retransmissions - event information - RTP monitoring 288 - Retroactive FEC - media-specific info and reporting 289 - Adaptive source coding - "congestion info"(*) - Instant event 290 - Congestion control(*) notifications 292 (*) RTCP feedback is insufficient for TCP-Friendly congestion control 293 purposes due to the infrequent nature of reporting (which should 294 be in the order of once per RTT), but can still be used to adapt 295 to the available bandwidth on slower time-scales. 297 Figure 1: Outline of an RTCP Feedback Loop 299 It is important to note that not all information needs to be 300 signalled explicitly -- ever or upon every RTCP packet -- but can be 301 derived locally from other pieces of information and from the 302 evolution of the information over time. 304 3.2. RTCP Limitations 306 The design of RTP limits what can meaningfully be done (and hence 307 should be done) with RTCP. In particular, the design favours 308 scalability and loose coupling over tightly controlled feedback 309 loops. Some of these limitations are listed below (they need to be 310 taken into account when designing extensions): 312 o RTCP is designed to provide occasional feedback which is unlike, 313 e.g., TCP ACKs which can be sent in response to every (other) 314 packet. It does not offer per-packet feedback (even when using 315 [RFC4585] with increased RTCP bandwidth fraction, the feedback 316 guarantees are only statistical in nature). 318 o RTCP is not capable of providing truly instant feedback. 320 o RTCP is inherently unreliable, and does not guarantee any 321 consistency between the observed state at multiple members of a 322 group. 324 It is important to note that these features of RTCP are intentional 325 design choices, and are essential for it to scale to large groups. 327 3.3. Interactions with Network and Transport Layer Mechanisms 329 As discussed above, RTCP flows are used to measure, infer, and convey 330 information about the performance of an RTP media stream. 332 Inference in baseline RTCP is mainly limited to determining the path 333 RTT from pairs of RTCP SR and RR packets. This inference makes the 334 implicit assumption that RTP and RTCP are treated equally: they are 335 routed along the same path, mapped to the same (DiffServ) traffic 336 classes, and treated as part of the same fair queuing classification. 337 This is true in many cases, however since RTP and RTCP are generally 338 sent using different ports, any flow classification based upon the 339 quintuple (source and destination IP address and port number, 340 transport protocol) could lead to a differentiation between RTP and 341 RTCP flows, disrupting the statistics. 343 While some networks may wish to intentionally prioritise RTCP over 344 RTP (to provide quicker feedback) or RTP over RTCP (since the media 345 is considered more important than control), we recommend that they be 346 treated identically where possible, to enable this inference of 347 network performance, and hence support application adaptation. 349 When using reliable transport connections for (RTP and) RTCP 350 [RFC2326] [RFC4571], retransmissions and head-of-line blocking may 351 similarly lead to inaccurate RTT estimates derived by RTCP. (These 352 may, nevertheless, properly reflect the mean RTT for a media packet 353 including retransmissions.) 355 The conveyance of information in RTCP is affected by the above only 356 as soon as the prioritisation leads to RTCP packets being dropped 357 over proportionally. 359 All of this emphasises the unreliable nature of RTCP. Multiplexing 360 on the same port number [I-D.ietf-avt-rtp-and-rtcp-mux] or inside the 361 same transport connection might help mitigating some of these 362 effects; but this is limited to speculation at this point and should 363 not be relied upon. 365 4. Issues with RTCP Extensions 367 Issues that have come up in the past with extensions to RTP and RTCP 368 include (but are probably not limited to) the following: 370 o Defined only or primarily for unicast two-party sessions. RTP is 371 inherently a group communication protocol, even when operating on 372 a unicast connection. Extensions may become useful in the future 373 well outside their originally intended area of application, and 374 should consider this. Stating that something works for unicast 375 only is not acceptable, particularly since various flavours of 376 multicast have become relevant again, and as middleboxes such as 377 repair servers, mixers, and RTCP-supporting MCUs [RFC5117] become 378 more widely used. 380 o Assuming reliable (instant) state synchronisation. RTCP reports 381 are sent irregularly and may be lost. Hence, there may be a 382 significant time lag (several seconds) between intending to send a 383 state update to the RTP peer(s) and the packet being received, in 384 some cases, the packet may not be received at all. 386 o Requiring reliable delivery of RTCP reports. While reliability 387 can be implemented on top of RTCP using acknowledgements, this 388 will come at the cost of significant additional delay, which may 389 defeat the purpose of providing the feedback in the first place. 390 Moreover, for scalability reasons due to the group-based nature of 391 RTCP, these ACKs need to be adaptively rate limited or targeted to 392 a subgroup or individual entity to avoid implosion as group sizes 393 increase. RTCP is not intended or suitable for use as a reliable 394 control channel. 396 o Commands are issued, rather than hints given. RTCP is about 397 reporting observations -- in a best-effort manner -- between RTP 398 entities. Causing actions on the remote side requires some form 399 of reliability (see above), and adherence cannot be verified. 401 o RTCP reporting is expanded to become a network management tool. 402 RTCP is sensitive to the size of RTCP reports as the latter 403 determines the mean reporting interval given a certain bit rate 404 share for RTCP (yet, RTCP may also be used to report information 405 that has fine-grained temporal characteristics, if summarisation 406 or data reduction by the endpoint would lose essential 407 resolution). The information going into RTCP reports should 408 primarily target the peer(s) (and thus include information that 409 can be meaningfully reacted upon), nevertheless, such reports may 410 provide useful information to augment other network management 411 tools. Gathering and reporting statistics beyond this is not an 412 RTCP task and should be addressed by out-of-band protocols. 414 o Serious complexity is created. Related to the previous item, RTCP 415 reports that convey all kinds of data first need to gather and 416 calculate/infer this information to begin with (which requires 417 very precise specifications). Given that it already seems to be 418 difficult to even implement baseline RTCP, any added complexity 419 can only discourage implementers, may lead to buggy 420 implementations (in which case the reports do not serve the 421 purpose they were intended to), and hinder interoperability. 423 o Architectural issues. Extensions are written without considering 424 the architectural concepts of RTP. For example, point-to-point 425 communication is assumed, yet third party monitors are expected to 426 listen in. Besides being a bad idea to rely on eavesdropping 427 entities on the path, this is obviously not possible if SRTP is 428 being used with encrypted SRTCP packets. 430 This list is surely not exhaustive. Also, the authors do not claim 431 that the suggested extensions (even if using acknowledgements) would 432 not serve a legitimate purpose. We rather want to draw attention to 433 the fact that the same results may be achievable in a way which is 434 architecturally cleaner and conceptually more RTP/RTCP-compliant. 435 The following section contains a first attempt to provide some 436 guidelines on what to consider when thinking about extensions to RTP 437 and RTCP. 439 5. Guidelines 441 Designing RTCP extensions requires consideration of a number issues, 442 as well as in-depth understanding of the operation of RTP mechanisms. 443 While it is expected that there are many aspects not yet covered by 444 RTCP reporting and operation, quite a bit of functionality is readily 445 available for use. Other mechanisms should probably never become 446 part of the RTP family of specifications, despite the existence of 447 their equivalents in other environments. In the following, we 448 provide some guidance to consider when (and before!) developing an 449 extension to RTCP. 451 We begin with a short check list concerning the applicability of RTCP 452 in the first place: 454 o Check what can be done with the existing mechanisms, exploiting 455 the information that is already available in RTCP. Is the need 456 for an extension only perceived (e.g., due to lazy implementers, 457 or artificial constraints in endpoints), or is the function or 458 data really not available (or derivable from existing reports)? 459 It is worthwhile remembering that redundant information supplied 460 by a protocol runs the risk of being inconsistent at some point, 461 and various implementation may handle such situations differently 462 (e.g., give precedence to different values). Similarly, there 463 should be exactly one (well-specified) way of performing every 464 function and operation of the protocol. 466 o Is the extension applicable to RTP entities running anywhere in 467 the Internet, or is it a link- or environment-specific extension? 468 In the latter cases, local extensions (e.g. header compression, or 469 non-RTP protocols) may be preferable. RTCP should not be used to 470 carry information specific to a particular (access) link. 472 o Is the extension applicable in a group communication environment, 473 or is it specific to point-to-point communications? RTP and RTCP 474 are inherently group communication protocols, and extensions must 475 scale gracefully with increasing group sizes. 477 From a conceptual viewpoint, the designer of every RTCP extension 478 should ask -- and answer(!) -- at least the following questions: 480 o How will this new building block complement and work with the 481 other components of RTCP? Are all interactions fully specified? 483 o Will this extension work with all different profiles (e.g. the 484 Secure RTP Profile [RFC3711], and the Extended RTP Profile for 485 RTCP-based Feedback [RFC4585])? Are any feature interactions 486 expected? 488 o Should this extension be kept in-line with baseline RTP and its 489 existing profiles, or does it deviate so much from the base RTP 490 operation that an incompatible new profile must be defined? Use 491 and definition of incompatible profiles is strongly discouraged, 492 but if they prove necessary, how do nodes using the different 493 profiles interact? What are the failure modes, and how is it 494 ensured that the system fails in a safe manner? 496 o How does this extension interoperate with other nodes when the 497 extension is not understood by the peer(s)? 499 o How will the extension deal with different networking conditions 500 (e.g., how does performance degrade with increases in losses and 501 latency, possibly across orders of magnitude)? 503 o How will this extension work with group communication scenarios, 504 such as multicast? Will the extensions degrade gracefully with 505 increasing group sizes? What will be the impact on the RTCP 506 report frequency and bitrate allocation? 508 For the specific design, the following considerations should be taken 509 into account (they're a mixture of common protocol design guidelines, 510 and specifics for RTCP): 512 o First of all, if there is (and for RTCP this applies quite often) 513 a mechanism from a different networking environment, don't try to 514 directly recreate this mechanism in RTP/RTCP. The Internet 515 environment is extremely heterogeneous, and will often have 516 drastically different properties and behaviour to other network 517 environments. Instead, ask what the actual semantics and the 518 result required to be perceived by the application or the user 519 are. Then, design a mechanism that achieves this result in a way 520 that is compatible with RTP/RTCP. (And do not forget that every 521 mechanism will break when no packets get through -- the Internet 522 does not guarantee connectivity or performance.) 524 o Target re-usability of the specification. That is, think broader 525 than a specific use case and try to solve the general problem in 526 cases where it makes sense to do so. Point solutions need a very 527 good motivation to be dealt with in the IETF in the first place. 528 This essentially suggests developing buildings blocks whenever 529 possible, allowing them to be combined in different environments 530 than initially considered. Where possible, avoid mechanisms that 531 are specific to particular payload formats, media types, link or 532 network types, etc. 534 o For everything (packet format, value, procedure, timer, etc.) 535 being defined, make sure that it is defined properly, so that 536 independent interoperable implementation can be built. It is not 537 sufficient that you can implement the feature: it has to be 538 implemented in several years by someone unfamiliar with the 539 working group discussion and industry context. Remember that 540 fields need to be both generated and reacted upon, that mechanisms 541 need to be implemented, etc., and that all of this increases the 542 complexity of an implementation. Features which are too complex 543 won't get implemented (correctly) in the first place. 545 o Extensions defining new metrics and parameters should reference 546 existing standards whenever possible, rather than try to invent 547 something new and/or proprietary. 549 o Remember that not every bit or every action must be represented or 550 signalled explicitly. It may be possible to infer the necessary 551 pieces of information from other values or their evolution (a very 552 prominent example is TCP congestion control). As a result, it may 553 be possible to de-couple bits on the wire from local actions and 554 reduce the overhead. 556 o Particularly with media streams, reliability can often be "soft". 557 Rather than implementing explicit acknowledgements, receipt of a 558 hint may also be observed from the altered behaviour (e.g., the 559 reception of a requested intra-frame, or changing the reference 560 frame for video, changing the codec, etc.). The semantics of 561 messages should be idempotent so that the respective message may 562 be sent repeatedly. Requiring hard reliability does not scale 563 with increasing group sizes, and does not degrade gracefully as 564 network performance reduces. 566 o Choose the appropriate extension point. Depending on the type of 567 RTCP extension being developed, new data items can be transported 568 in several different ways: 570 * A new RTCP SDES item is appropriate for transporting data that 571 describes the source, or the user represented by the source, 572 rather than the ongoing media transmission. New SDES items may 573 be registered to transport source description information of 574 general interest (see [RFC3550] section 15), or the PRIV item 575 ([RFC3550] Section 6.5.8) may be used for proprietary 576 extensions. 578 * A new RTCP XR block type is appropriate for transporting new 579 metrics regarding media transmission or reception quality (see 580 [RFC3611] Section 6.2). 582 * New RTP profiles may define a profile-specific extension to 583 RTCP SR and/or RR packets, to give additional feedback (see 584 [RFC3550] section 6.4.3). It is important to note that while 585 extensions using this mechanism have low overhead, they are not 586 backwards compatible with other profiles. Where compatibility 587 is needed, it's generally more appropriate to define a new RTCP 588 XR block or a new RTCP packet type instead. 590 * New RTCP AVPF transport layer feedback messages should be used 591 to transmit general purpose feedback information, to be 592 generated and processed by the RTP transport. Examples include 593 (negative) acknowledgements for particular packets, or requests 594 to limit the transmission rate. This information is intended 595 to be independent of the codec or application in use (see 596 [RFC4585] sections 6.2 and 9). 598 * New RTCP AVPF payload-specific feedback messages should be used 599 to convey feedback information that is specific to a particular 600 media codec, RTP payload format, or category of RTP payload 601 formats. Examples include video picture loss indication or 602 reference picture selection, that are useful for many video 603 codecs (see [RFC4585] sections 6.3 and 9). 605 * New RTCP AVPF application layer feedback messages should be 606 used to convey higher-level feedback, from one application to 607 another, above the level of codecs or transport (see [RFC4585] 608 sections 6.4 and 9). 610 * A new RTCP APP packet is appropriate for private use by 611 applications that don't need to interoperate with others, or 612 for experimentation before registering a new RTCP packet type 613 ([RFC3550] section 6.7). It is not appropriate to define a new 614 RTCP APP packet in a standards document: use one of the other 615 extension points, or define a new RTCP packet type instead. 617 * Finally, new RTCP packet types may be registered with IANA if 618 none of the other RTCP extension points are appropriate (see 619 [RFC3550] section 15). 621 The RTP framework was designed following the principle of application 622 level framing with integrated layer processing, proposed by Clark and 623 Tennenhouse [ALF]. Effective use of RTP requires that extensions and 624 implementations be designed and built following the same philosophy. 625 That philosophy differs markedly from many previous systems in this 626 space, and making effective use of RTP requires an understanding of 627 those differences. 629 6. Security Considerations 631 This memo does not specify any new protocol mechanisms or procedures, 632 and so raises no explicit security considerations. When designing 633 RTCP extensions, it is important to consider the following points: 635 o Privacy: RTCP extensions, in particular new Source Description 636 (SDES) items, can potentially reveal information considered to be 637 sensitive by end users. Extensions should carefully consider the 638 uses to which information they release could be put, and should be 639 designed to reveal the minimum amount of additional information 640 needed for their correct operation. 642 o Congestion control: RTCP transmission timers have been carefully 643 designed such that the total amount of traffic generated by RTCP 644 is a small fraction of the media data rate. One consequence of 645 this is that the individual RTCP reporting interval scales with 646 both the media data rate and the group size. The RTCP timing 647 algorithms have been shown to scale from two-party unicast 648 sessions to group with tens of thousands of participants, and to 649 gracefully handle flash crowds and sudden departures [TimerRecon]. 650 Proposals that modify the RTCP timer algorithms must be careful to 651 avoid congestion, potentially leading to denial of service, across 652 the full range of environments where RTCP is used. 654 o Denial of service: RTCP extensions that change the location where 655 feedback is sent must be carefully designed to prevent denial of 656 service attacks against third party nodes. When such extensions 657 are signalled, for example in SDP, this typically requires some 658 form of authentication of the signalling messages (e.g. see the 659 security considerations of [I-D.ietf-avt-rtcpssm]). 661 The security considerations of the RTP specification [RFC3550] apply, 662 along with any applicable profile (e.g. [RFC3551]). 664 7. IANA Considerations 666 No IANA actions are necessary. 668 8. Acknowledgements 670 This draft has been motivated by many discussions in the AVT WG. The 671 authors would like to acknowledge the active members in the group for 672 providing the inspiration. 674 9. References 676 9.1. Normative References 678 [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, 679 April 1996. 681 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 682 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 683 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 684 September 1997. 686 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 687 Streaming Protocol (RTSP)", RFC 2326, April 1998. 689 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 690 Jacobson, "RTP: A Transport Protocol for Real-Time 691 Applications", STD 64, RFC 3550, July 2003. 693 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 694 Video Conferences with Minimal Control", STD 65, RFC 3551, 695 July 2003. 697 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 698 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 699 RFC 3556, July 2003. 701 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 702 Protocol Extended Reports (RTCP XR)", RFC 3611, 703 November 2003. 705 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 706 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 707 RFC 3711, March 2004. 709 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 710 and RTP Control Protocol (RTCP) Packets over Connection- 711 Oriented Transport", RFC 4571, July 2006. 713 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 714 "Extended RTP Profile for Real-time Transport Control 715 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 716 July 2006. 718 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 719 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 720 July 2006. 722 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 723 Correction", RFC 5109, December 2007. 725 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 726 January 2008. 728 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 729 Real-Time Transport Control Protocol (RTCP): Opportunities 730 and Consequences", RFC 5506, April 2009. 732 9.2. Informative References 734 [I-D.ietf-avt-rtcpssm] 735 Ott, J. and J. Chesterfield, "RTCP Extensions for Single- 736 Source Multicast Sessions with Unicast Feedback", 737 draft-ietf-avt-rtcpssm-19 (work in progress), 738 November 2009. 740 [I-D.ietf-dccp-rtp] 741 Perkins, C., "RTP and the Datagram Congestion Control 742 Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in 743 progress), June 2007. 745 [I-D.ietf-avt-rtp-and-rtcp-mux] 746 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 747 Control Packets on a Single Port", 748 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 749 August 2007. 751 [ALF] Clark, D. and D. Tennenhouse, "Architectural 752 Considerations for a New Generation of Protocols", 753 Proceedings of ACM SIGCOMM 1990, September 1990. 755 [TimerRecon] 756 Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration 757 for Enhanced RTP Scalability", Proceedings of IEEE 758 Infocom 1998, March 1998. 760 Authors' Addresses 762 Joerg Ott 763 Aalto University 764 School of Science and Technology 765 Otakaari 5 A 766 Espoo, FIN 02150 767 Finland 769 Email: jo@netlab.tkk.fi 771 Colin Perkins 772 University of Glasgow 773 Department of Computing Science 774 Glasgow G12 8QQ 775 United Kingdom 777 Email: csp@csperkins.org