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