idnits 2.17.1 draft-perkins-avtcore-rtp-circuit-breakers-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2012) is 4408 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-08) exists of draft-ietf-avtcore-ecn-for-rtp-06 == Outdated reference: A later version (-14) exists of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-02 == Outdated reference: A later version (-12) exists of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-01 == Outdated reference: A later version (-12) exists of draft-ietf-xrblock-rtcp-xr-delay-01 == Outdated reference: A later version (-15) exists of draft-ietf-xrblock-rtcp-xr-discard-01 == Outdated reference: A later version (-09) exists of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 == Outdated reference: A later version (-08) exists of draft-ietf-xrblock-rtcp-xr-pdv-02 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Intended status: Standards Track V. Singh 5 Expires: September 5, 2012 Aalto University 6 March 4, 2012 8 RTP Congestion Control: Circuit Breakers for Unicast Sessions 9 draft-perkins-avtcore-rtp-circuit-breakers-00 11 Abstract 13 The Real-time Transport Protocol (RTP) is widely used for telephony, 14 video conferencing, and telepresence applications. These 15 applications are often used over best-effort UDP/IP networks. If 16 congestion control is not implemented then network congestion will 17 deteriorate the user's multimedia experience. This document does not 18 propose a congestion control algorithm. Instead, it specifies a 19 minimal set of "circuit-breakers". Circuit-breakers are conditions 20 under which an RTP flow should cease to transmit media to protect the 21 network from excessive congestion. It is expected that all RTP 22 applications running on best-effort networks will be able to run 23 without triggering these circuit breakers in normal operation. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 5, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . . 6 63 4.1. RTP/AVP Circuit Breaker #1: Timeout . . . . . . . . . . . 7 64 4.2. RTP/AVP Circuit Breaker #2: Congestion . . . . . . . . . . 8 65 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 10 66 6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Impact of Explicit Congestion Notification (ECN) . . . . . . . 11 68 8. Session Timeout . . . . . . . . . . . . . . . . . . . . . . . 11 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 The Real-time Transport Protocol (RTP) [RFC3550] is widely used in 77 voice-over-IP, video teleconferencing, and telepresence systems. 78 Many of these systems run over best-effort IP networks, and can 79 suffer from packet loss and increased latency due to network 80 congestion. Designing effective RTP congestion control algorithms, 81 to adapt the transmission of RTP-based media to match the available 82 network capacity, while also maintaining the user experience, is a 83 difficult but important problem. Many such congestion control and 84 media adaptation algorithms have been proposed, but to date there is 85 no consensus on the correct approach, or even that a single standard 86 algorithm is desirable. 88 This memo does not attempt to propose a new RTP congestion control 89 algorithm. Rather, it proposes a minimal set of "circuit breakers"; 90 conditions under which there should be general agreement that an RTP 91 flow is causing serious congestion, and should cease transmission. 92 It is expected that any future standards-track congestion control 93 algorithms for RTP will operate within the envelope defined by this 94 memo. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. Background 104 We consider congestion control for unicast RTP traffic flows. This 105 is the problem of adapting the transmission of an audio/visual data 106 flow, encapsulated within an RTP transport session, from one sender 107 to one receiver so that it matches the available network bandwidth. 108 Such adaptation must be done in a way that limits the disruption to 109 the user experience caused by both packet loss and excessive rate 110 changes. 112 Congestion control for unicast RTP traffic can be implemented in one 113 of two places in the protocol stack. One approach is to run the RTP 114 traffic over a congestion controlled transport protocol, for example 115 over TCP, and to adapt the media encoding to match the dictates of 116 the transport-layer congestion control algorithm. This is safe for 117 the network, but may be suboptimal for the media quality unless the 118 transport protocol is designed to support real-time media flows. We 119 do not consider this class of applications further in this memo, as 120 their network safety is guaranteed by the underlying transport. 122 Alternatively, RTP flows can be run over a non-congestion controlled 123 transport protocol, for example UDP, performing rate adaptation at 124 the application layer based on RTP Control Protocol (RTCP) feedback. 125 With a well-designed, network-aware, application, this allows highly 126 effective media quality adaptation, but there is potential to disrupt 127 the network operation if the application does not adapt its sending 128 rate in a timely and effective manner. This memo focusses on this 129 class of application. 131 Congestion control relies on monitoring the delivery of a media flow, 132 and responding to adapt the transmission of that flow when there are 133 signs that the network path is congested. Network congestion may be 134 detected in one of three ways: 1) a receiver may infer the onset of 135 congestion by observing an increase in one-way delay caused by queue 136 build-up within the network; 2) if Explicit Congestion Notification 137 (ECN) [RFC3168] is supported, the network may signal the presence of 138 congestion by marking packets with ECN Congestion Experienced (CE) 139 marks; or 3) in the extreme case, congestion will cause packet loss, 140 which can be detected by observing a gap in the received RTP sequence 141 numbers. Once the onset of congestion is observed, the receiver must 142 send feedback to the sender to indicate that the transmission rate 143 should be reduced. How the sender reduces the transmission rate is 144 highly dependent on the media codec being used, and is outside the 145 scope of this memo. 147 There are several ways in which a receiver may send feedback to a 148 media sender within the RTP framework: 150 o The base RTP specification [RFC3550] defines RTCP Reception Report 151 (RR) packets to convey reception quality feedback information, and 152 Sender Report (SR) packets to convey information about the media 153 transmission. RTCP SR packets contain data that can be used to 154 reconstruct media timing at a receiver, along with a count of the 155 total number of octets and packets sent. RTCP RR packets report 156 on the fraction of packets lost in the last reporting interval, 157 the cumulative number of packets lost, the highest sequence number 158 received, and the inter-arrival jitter. The RTCP RR packets also 159 contain timing information that allows the sender to estimate the 160 network round trip time (RTT) to the receivers. RTCP reports are 161 sent periodically, with the reporting interval being determined by 162 the number of participants in the session and a configured session 163 bandwidth estimate. The interval between reports sent from each 164 receiver tends to be on the order of a few seconds on average, and 165 it is randomised to avoid synchronisation of reports from multiple 166 receivers. If a receiver detects problems, the base RTP 167 specification contains no provisions for sending the feedback 168 report early and must wait until the next scheduled reporting 169 interval. 171 o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more 172 complex and sophisticated reception quality metrics, but do not 173 change the RTCP timing rules. RTCP extended reports of potential 174 interest for congestion control purposes are 1) the extended 175 packet loss, discard or burst/gap metrics for reacting based on 176 loss patterns; and 2) the end-system delay metrics for delay-based 177 congestion control. 179 o Rapid feedback about the occurrence of congestion events can be 180 achieved using the Extended RTP Profile for RTCP-Based Feedback 181 (RTP/AVPF) [RFC4585]. This modifies the RTCP timing rules to 182 allow RTCP reports to be sent early, in some cases immediately, 183 provided the average RTCP reporting interval remains unchanged. 184 It also defines new transport-layer feedback messages, including 185 negative acknowledgements (NACKs), that can be used to report on 186 specific congestion events. The use of the RTP/AVPF profile is 187 dependent on signalling, but is otherwise generally backwards 188 compatible, as it keeps the same average RTCP reporting interval 189 as the base RTP specification. The Codec control messages 190 [RFC5104] extend the RTP/AVPF profile with additional feedback 191 message that can be used to influence that way in which rate 192 adaptation occurs. The dynamics of how rapidly feedback can be 193 sent are unchanged. 195 o Finally, the RTP and RTCP extensions for Explicit Congestion 196 Notification (ECN) [I-D.ietf-avtcore-ecn-for-rtp] can be used to 197 provide feedback on the number of packets that received an ECN 198 Congestion Experienced (CE) mark. This extension builds on the 199 RTP/AVPF profile to allow rapid congestion feedback. 201 In addition to these mechanisms for providing feedback, the sender 202 can include an RTP header extension in each packet to record packet 203 transmission times. There are two methods: [RFC5450] represents the 204 transmission time in terms of a time-offset from the RTP timestamp of 205 the packet, while [RFC6051] includes an explicit NTP-format sending 206 timestamp (potentially more accurate, but a higher header overhead). 207 Accurate sending timestamps can be helpful for estimating queuing 208 delays, to get an early indication of the onset of congestion. 210 Taken together, these various mechanisms allow receivers to provide 211 feedback on the senders when congestion events occur, with varying 212 degrees of timeliness and accuracy. The key distinction is between 213 systems that use only the basic RTCP mechanisms, without RTP/AVPF 214 rapid feedback, and those that use the RTP/AVPF extensions, and can 215 respond to congestion more rapidly. 217 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile 219 The feedback mechanisms defined in [RFC3550] are the minimum that can 220 be required for a baseline circuit breaker mechanism suitable for all 221 unicast applications of RTP. Accordingly, for an RTP circuit breaker 222 to be useful, it should be able to detect that an RTP flow is causing 223 excessive congestion using only basic RTCP features, without needing 224 RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports. 226 Three potential congestion signals are available from the basic RTCP 227 SR/RR packets, and are reported for each SSRC in the RTP session: 229 1. The sender can estimate the network round-trip time once per RTCP 230 reporting interval, based on the contents and timing of RTCP SR 231 and RR packets. 233 2. Receivers report estimated jitter (the statistical variance of 234 the RTP data packet inter-arrival time) calculated over the RTCP 235 reporting interval. Due to the nature of the jitter calculation 236 ([RFC3550], section 6.4.4), the jitter is only meaningful for RTP 237 flows that send a single data packet for each RTP timestamp value 238 (i.e., audio flows, or video flows where each frame comprises one 239 RTP packet). 241 3. Receivers report the fraction of packets lost during the RTCP 242 reporting interval, and the cumulative number of packets lost 243 over the entire RTP session. 245 These congestion signals limit the possible circuit breakers, since 246 they give only limited visibility into the behaviour of the network. 248 RTT estimates are widely used in congestion control algorithms, as a 249 proxy for queuing delay measures in delay-based congestion control, 250 or to determine connection timeouts. RTT estimates derived from RTCP 251 SR and RR packets send according to the RTP/AVP timing rules are too 252 infrequent to be useful though, and don't give enough information to 253 distinguish a delay change due to routing updates from queuing delay 254 caused by congestion. Accordingly, we do not use the RTT estimate 255 alone as an RTP circuit breaker. 257 Increased jitter can be a signal of transient network congestion, but 258 in the highly aggregated form reported in RTCP RR packets, it offers 259 insufficient information to estimate the extent or persistence of 260 congestion. Jitter reports are a useful early warning of potential 261 network congestion, but provide an insufficiently strong signal to be 262 used as a circuit breaker. 264 The remaining congestion signals are the packet loss fraction and the 265 cumulative number of packets lost. These are robust indicators of 266 congestion in networks where packet loss is primarily due to queue 267 overflows, although less accurate in networks where losses can be 268 caused by non-congestive packet corruption. TCP also uses packet 269 loss as a congestion signal. 271 Two packet loss regimes can be observed: 1) RTCP RR packets show a 272 non-zero packet loss fraction, while the extended highest sequence 273 number received continues to increment; and 2) RR packets show a loss 274 fraction of zero, but the extended highest sequence number received 275 does not increment even though the sender has been transmitting RTP 276 data packets. The former corresponds to the TCP congestion avoidance 277 state, and indicates a congested path that is still delivering data; 278 the latter corresponds to a TCP timeout, and is most likely due to a 279 path failure. We derive circuit breaker conditions for these two 280 loss regimes. 282 4.1. RTP/AVP Circuit Breaker #1: Timeout 284 If RTP data packets are being sent while the corresponding RTCP RR 285 packets report a non-increasing extended highest sequence number 286 received, this is an indication that those RTP data packets are not 287 reaching the receiver. This could be a short-term issue affecting 288 only a few packets, perhaps caused by a slow-to-open firewall or a 289 transient connectivity problem, but if the issue persists, it is a 290 sign of a more ongoing and significant problem. Accordingly, if a 291 sender of RTP data packets receives two or more consecutive RTCP RR 292 packets from the same receiver that correspond to its transmission 293 and have a non-increasing extended highest sequence number received 294 field, then that sender SHOULD cease transmission. 296 Systems that usually send at a high data rate, but which can reduce 297 their data rate significantly (i.e., by an order of magnitude), MAY 298 first reduce their sending rate to this lower value, but MUST then 299 cease transmission if the problem does not resolve itself within a 300 further two RTCP reporting intervals. An example of this might be a 301 video conferencing system that backs off to sending audio only, 302 before completely dropping the call. 304 The choice of two RTCP reporting intervals is to give enough time for 305 transient problems to resolve themselves, but to stop problem flows 306 quickly enough to avoid causing serious problems. A single RTCP 307 report showing no reception could be caused by numerous transient 308 faults, and so should not stop transmission. More than two RTCP 309 reports could avoid false positives, but would lead to problematic 310 flows running for a long time before being cut off. 312 4.2. RTP/AVP Circuit Breaker #2: Congestion 314 If RTP data packets are being sent, and the corresponding RTCP RR 315 packets show non-zero packet loss fraction and increasing extended 316 highest sequence number received, then the RTP data packets are 317 arriving at the receiver, but some degree of congestion is occurring. 318 The RTP/AVP profile [RFC3551] states that: 320 If best-effort service is being used, RTP receivers SHOULD monitor 321 packet loss to ensure that the packet loss rate is within 322 acceptable parameters. Packet loss is considered acceptable if a 323 TCP flow across the same network path and experiencing the same 324 network conditions would achieve an average throughput, measured 325 on a reasonable timescale, that is not less than the RTP flow is 326 achieving. This condition can be satisfied by implementing 327 congestion control mechanisms to adapt the transmission rate (or 328 the number of layers subscribed for a layered multicast session), 329 or by arranging for a receiver to leave the session if the loss 330 rate is unacceptably high. 332 The comparison to TCP cannot be specified exactly, but is intended 333 as an "order-of-magnitude" comparison in timescale and throughput. 334 The timescale on which TCP throughput is measured is the round- 335 trip time of the connection. In essence, this requirement states 336 that it is not acceptable to deploy an application (using RTP or 337 any other transport protocol) on the best-effort Internet which 338 consumes bandwidth arbitrarily and does not compete fairly with 339 TCP within an order of magnitude. 341 The throughput of a long-lived TCP connection can be estimated using 342 the TCP throughput equation: 344 s 345 X = -------------------------------------------------------------- 346 R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) 348 Where: 350 X is the transmit rate in bytes/second. 352 s is the packet size in bytes. If the RTP data packets vary in 353 size, then the average size should be used. 355 R is the round trip time in seconds. 357 p is the loss event rate, between 0 and 1.0, of the number of loss 358 events as a fraction of the number of packets transmitted. 360 t_RTO is the TCP retransmission timeout value in seconds, 361 approximated by setting t_RTO = 4*R. 363 b is the number of packets acknowledged by a single TCP 364 acknowledgement ([RFC3448] recommends the use of b=1 since many 365 TCP implementations do not use delayed acknowledgements). 367 This is the same approach to estimated TCP throughput that is used in 368 [RFC3448]. Two parameters must be estimated in order to calculate 369 the throughput: the round trip time, R, and the loss event rate, p. 370 The round trip time can be estimated from RTCP. This is done too 371 infrequently for accurate statistics, but is the best that can be 372 done with the standard RTCP mechanisms. 374 RTCP RR packets contain the packet loss fraction, rather than the 375 loss event rate, so p cannot be reported (TCP typically treats the 376 loss of multiple packets within a single RTT as one loss event, but 377 RTCP RR packets report the overall fraction of packets lost, not 378 caring about when the losses occurred). Using the loss fraction in 379 place of the loss event rate can overestimate the loss. We believe 380 that this overestimate will not be significant, given that we are 381 only interested in order of magnitude comparison (Floyd et al, 382 "Equation-Based Congestion Control for Unicast Applications", Proc. 383 SIGCOMM 2000, section 3.2.1, show that the difference is small for 384 steady-state conditions and random loss, but using the loss fraction 385 is more conservative in the case of bursty loss). 387 The congestion circuit breaker is therefore: when RTCP RR packets are 388 received, estimate the TCP throughput using the above equation and 389 the measured R, p (approximated by the loss fraction), and s. 390 Compare this with the actual sending rate. If the actual sending 391 rate has been more than an order of magnitude greater than the 392 throughput equation estimate for two or more RTCP reporting 393 intervals, stop transmitting. 395 Again, we use two reporting intervals to avoid triggering the circuit 396 breaker on transient failures. This circuit breaker is a worst-case 397 condition, and congestion control should be performed to keep well 398 within this bound. It is expected that the circuit breaker will only 399 be triggered if the usual congestion control fails for some reason. 401 (tbd -- we need to base the circuit breaker condition on something, 402 so TCP seems a logical choice. Following TCP limits too closely is 403 inappropriate for many applications of RTP, though, since they have 404 different dynamics. Is the above lax enough to not disrupt valid 405 applications, but tight enough to provide meaningful protection for 406 the network?) 408 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile 410 More rapid feedback allows more responsiveness. The receiver SHOULD 411 provide feedback more often during, or at onset of, congestion, and 412 provide feedback less often when there is no congestion. 414 (tbd -- mechanisms may probably need to be designed in conjunction 415 with the different classes of congestion control that can leverage 416 RTP/AVPF; e.g., we might need to specify limits for TFRC-like or 417 delay-based algorithms using RTP/AVPF feedback.) 419 (tbd -- a high-level question to be answered is whether we need to 420 specify anything different for the circuit breaker for AVPF, or if we 421 leave that unchanged, and focus solely on the dynamics, to ensure the 422 circuit breaker is never triggered.) 424 6. Impact of RTCP XR 426 (tbd) 428 This improves the information, but doesn't change the dynamics of the 429 congestion control loop. Suspect the impact will actually be quite 430 small. 432 Packets discarded [I-D.ietf-xrblock-rtcp-xr-discard] or bytes 433 discarded [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] due to late 434 arrival by the receiver may indicate congestion. Congestion control 435 should consider the discarded packets as if they were lost packets. 437 The RTCP RR reports the loss fraction over an RTCP interval which is 438 insufficient to distinguish between solitary or bursty losses. To 439 provide rough sense of duration of losses or discards, an endpoint 440 may use burst/gap reporting for loss 441 [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] and discard 442 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. For more accurate 443 reporting the receiver may use Run-length encoded (RLE) lost 444 [RFC3611] or discarded [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] 445 packets. 447 For precise measurement of network roundtrip delay the receiver can 448 signal its end-system delay [I-D.ietf-xrblock-rtcp-xr-delay] 449 [RFC3611]. 451 A receiver may also indicate onset or end of congestion by reporting 452 the distribution of the inter-packet delay variation 453 [I-D.ietf-xrblock-rtcp-xr-pdv] [RFC3611]. 455 7. Impact of Explicit Congestion Notification (ECN) 457 ECN-CE marked packets SHOULD be treated as if it were lost for the 458 purposes of congestion control, when determining the optimal rate at 459 which to send. However, it seems unwise to treat the receipt of 460 multiple ECN-CE marked packets as a circuit breaker, since it is 461 likely that ECN-capable and non-ECN-capable paths will exist for a 462 long time to come. Rather, consider packet loss as the circuit 463 breaker condition as for non-ECN flows. 465 8. Session Timeout 467 From a usability perspective, if there is no audio or video response 468 from the other peer, it is likely that the user may terminate the 469 session. 471 According to RFC 3550 [RFC3550], any participant that has not sent an 472 RTP packet within the last two RTCP interval is removed from the 473 sender list. To avoid timing out the specific flow, the endpoint 474 MUST send corresponding RTCP reports. Interactive Connectivity 475 Establishment (ICE) [RFC5245] recommends that the timeout MUST NOT be 476 less than 15 seconds. 478 If no RTCP RR arrives for two complete SR intervals, the sender 479 SHOULD cease transmission. However, if the endpoint can reduce the 480 media rate then it MAY first reduce the rate to the lower value, but 481 terminate the transmission if still no RTCP RR is received in the 482 next two SR intervals. 484 9. References 486 9.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 492 Friendly Rate Control (TFRC): Protocol Specification", 493 RFC 3448, January 2003. 495 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 497 Jacobson, "RTP: A Transport Protocol for Real-Time 498 Applications", STD 64, RFC 3550, July 2003. 500 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 501 Video Conferences with Minimal Control", STD 65, RFC 3551, 502 July 2003. 504 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 505 Protocol Extended Reports (RTCP XR)", RFC 3611, 506 November 2003. 508 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 509 "Extended RTP Profile for Real-time Transport Control 510 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 511 July 2006. 513 9.2. Informative References 515 [I-D.ietf-avtcore-ecn-for-rtp] 516 Westerlund, M., Johansson, I., Perkins, C., and K. 517 Carlberg, "Explicit Congestion Notification (ECN) for RTP 518 over UDP", draft-ietf-avtcore-ecn-for-rtp-06 (work in 519 progress), February 2012. 521 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 522 Clark, A., Hunt, G., Wu, W., and R. Huang, "RTCP XR Report 523 Block for Burst/Gap Discard metric Reporting", 524 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-02 (work in 525 progress), January 2012. 527 [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] 528 Clark, A., Hunt, G., Zhao, J., Wu, W., and S. Zhang, "RTCP 529 XR Report Block for Burst/Gap Loss metric Reporting", 530 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-01 (work in 531 progress), January 2012. 533 [I-D.ietf-xrblock-rtcp-xr-delay] 534 Hunt, G., Gross, K., and A. Clark, "RTCP XR Report Block 535 for Delay metric Reporting", 536 draft-ietf-xrblock-rtcp-xr-delay-01 (work in progress), 537 December 2011. 539 [I-D.ietf-xrblock-rtcp-xr-discard] 540 Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report 541 Block for Discard metric Reporting", 542 draft-ietf-xrblock-rtcp-xr-discard-01 (work in progress), 543 December 2011. 545 [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] 546 Ott, J., Singh, V., and I. Curcio, "Real-time Transport 547 Control Protocol (RTCP) Extension Report (XR) for Run 548 Length Encoding of Discarded Packets", 549 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 (work in 550 progress), February 2012. 552 [I-D.ietf-xrblock-rtcp-xr-pdv] 553 Hunt, G. and A. Clark, "RTCP XR Report Block for Packet 554 Delay Variation Metric Reporting", 555 draft-ietf-xrblock-rtcp-xr-pdv-02 (work in progress), 556 December 2011. 558 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 559 of Explicit Congestion Notification (ECN) to IP", 560 RFC 3168, September 2001. 562 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 563 "Codec Control Messages in the RTP Audio-Visual Profile 564 with Feedback (AVPF)", RFC 5104, February 2008. 566 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 567 (ICE): A Protocol for Network Address Translator (NAT) 568 Traversal for Offer/Answer Protocols", RFC 5245, 569 April 2010. 571 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 572 RTP Streams", RFC 5450, March 2009. 574 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 575 Flows", RFC 6051, November 2010. 577 Authors' Addresses 579 Colin Perkins 580 University of Glasgow 581 School of Computing Science 582 Glasgow G12 8QQ 583 United Kingdom 585 Email: csp@csperkins.org 586 Varun Singh 587 Aalto University 588 School of Science and Technology 589 Otakaari 5 A 590 Espoo, FIN 02150 591 Finland 593 Email: varun@comnet.tkk.fi 594 URI: http://www.netlab.tkk.fi/~varun/