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