idnits 2.17.1 draft-perkins-avtcore-rtp-circuit-breakers-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4296 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: 1 error (**), 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: January 17, 2013 Aalto University 6 July 16, 2012 8 RTP Congestion Control: Circuit Breakers for Unicast Sessions 9 draft-perkins-avtcore-rtp-circuit-breakers-01 11 Abstract 13 The Real-time Transport Protocol (RTP) is widely used in telephony, 14 video conferencing, and telepresence applications. Such applications 15 are often run on best-effort UDP/IP networks. If congestion control 16 is not implemented in the applications, then network congestion will 17 deteriorate the user's multimedia experience. This document does not 18 propose a congestion control algorithm; rather, it defines a minimal 19 set of "circuit-breakers". Circuit-breakers are conditions under 20 which an RTP flow is expected to stop transmiting media to protect 21 the 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. Any 24 future RTP congestion control specification is expected to operate 25 within the envelope defined by these circuit breakers. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 17, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . . 6 65 4.1. RTP/AVP Circuit Breaker #1: Timeout . . . . . . . . . . . 7 66 4.2. RTP/AVP Circuit Breaker #2: Congestion . . . . . . . . . . 8 67 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 10 68 6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Impact of Explicit Congestion Notification (ECN) . . . . . . . 11 70 8. Session Timeout . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 The Real-time Transport Protocol (RTP) [RFC3550] is widely used in 83 voice-over-IP, video teleconferencing, and telepresence systems. 84 Many of these systems run over best-effort UDP/IP networks, and can 85 suffer from packet loss and increased latency if network congestion 86 occurs. Designing effective RTP congestion control algorithms, to 87 adapt the transmission of RTP-based media to match the available 88 network capacity, while also maintaining the user experience, is a 89 difficult but important problem. Many such congestion control and 90 media adaptation algorithms have been proposed, but to date there is 91 no consensus on the correct approach, or even that a single standard 92 algorithm is desirable. 94 This memo does not attempt to propose a new RTP congestion control 95 algorithm. Rather, it proposes a minimal set of "circuit breakers"; 96 conditions under which there is general agreement that an RTP flow is 97 causing serious congestion, and ought to cease transmission. It is 98 expected that future standards-track congestion control algorithms 99 for RTP will operate within the envelope defined by this memo. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 This interpretation of these key words applies only when written in 107 ALL CAPS. Mixed- or lower-case uses of these key words are not to be 108 interpreted as carrying special significance in this memo. 110 3. Background 112 We consider congestion control for unicast RTP traffic flows. This 113 is the problem of adapting the transmission of an audio/visual data 114 flow, encapsulated within an RTP transport session, from one sender 115 to one receiver, so that it matches the available network bandwidth. 116 Such adaptation needs to be done in a way that limits the disruption 117 to the user experience caused by both packet loss and excessive rate 118 changes. 120 Congestion control for unicast RTP traffic can be implemented in one 121 of two places in the protocol stack. One approach is to run the RTP 122 traffic over a congestion controlled transport protocol, for example 123 over TCP, and to adapt the media encoding to match the dictates of 124 the transport-layer congestion control algorithm. This is safe for 125 the network, but can be suboptimal for the media quality unless the 126 transport protocol is designed to support real-time media flows. We 127 do not consider this class of applications further in this memo, as 128 their network safety is guaranteed by the underlying transport. 130 Alternatively, RTP flows can be run over a non-congestion controlled 131 transport protocol, for example UDP, performing rate adaptation at 132 the application layer based on RTP Control Protocol (RTCP) feedback. 133 With a well-designed, network-aware, application, this allows highly 134 effective media quality adaptation, but there is potential to disrupt 135 the network's operation if the application does not adapt its sending 136 rate in a timely and effective manner. We consider this class of 137 applications in this memo. 139 Congestion control relies on monitoring the delivery of a media flow, 140 and responding to adapt the transmission of that flow when there are 141 signs that the network path is congested. Network congestion can be 142 detected in one of three ways: 1) a receiver can infer the onset of 143 congestion by observing an increase in one-way delay caused by queue 144 build-up within the network; 2) if Explicit Congestion Notification 145 (ECN) [RFC3168] is supported, the network can signal the presence of 146 congestion by marking packets using ECN Congestion Experienced (CE) 147 marks; or 3) in the extreme case, congestion will cause packet loss 148 that can be detected by observing a gap in the received RTP sequence 149 numbers. Once the onset of congestion is observed, the receiver has 150 to send feedback to the sender to indicate that the transmission rate 151 needs to be reduced. How the sender reduces the transmission rate is 152 highly dependent on the media codec being used, and is outside the 153 scope of this memo. 155 There are several ways in which a receiver can send feedback to a 156 media sender within the RTP framework: 158 o The base RTP specification [RFC3550] defines RTCP Reception Report 159 (RR) packets to convey reception quality feedback information, and 160 Sender Report (SR) packets to convey information about the media 161 transmission. RTCP SR packets contain data that can be used to 162 reconstruct media timing at a receiver, along with a count of the 163 total number of octets and packets sent. RTCP RR packets report 164 on the fraction of packets lost in the last reporting interval, 165 the cumulative number of packets lost, the highest sequence number 166 received, and the inter-arrival jitter. The RTCP RR packets also 167 contain timing information that allows the sender to estimate the 168 network round trip time (RTT) to the receivers. RTCP reports are 169 sent periodically, with the reporting interval being determined by 170 the number of participants in the session and a configured session 171 bandwidth estimate. The interval between reports sent from each 172 receiver tends to be on the order of a few seconds on average, and 173 it is randomised to avoid synchronisation of reports from multiple 174 receivers. RTCP RR packets allow a receiver to report ongoing 175 network congestion to the sender. However, if a receiver detects 176 the onset of congestion partway through a reporting interval, the 177 base RTP specification contains no provision for sending the RTCP 178 RR packet early, and the receiver has to wait until the next 179 scheduled reporting interval. 181 o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more 182 complex and sophisticated reception quality metrics, but do not 183 change the RTCP timing rules. RTCP extended reports of potential 184 interest for congestion control purposes are the extended packet 185 loss, discard, and burst metrics [RFC3611], and 186 [I-D.ietf-xrblock-rtcp-xr-discard], 187 [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics], 188 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], 189 [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss]; and the extended delay 190 metrics [I-D.ietf-xrblock-rtcp-xr-delay], 191 [I-D.ietf-xrblock-rtcp-xr-pdv]. Other RTCP Extended Reports that 192 could be helpful for congestion control purposes might be 193 developed in future. 195 o Rapid feedback about the occurrence of congestion events can be 196 achieved using the Extended RTP Profile for RTCP-Based Feedback 197 (RTP/AVPF) [RFC4585] in place of the more common RTP/AVP profile 198 [RFC3551]. This modifies the RTCP timing rules to allow RTCP 199 reports to be sent early, in some cases immediately, provided the 200 average RTCP reporting interval remains unchanged. It also 201 defines new transport-layer feedback messages, including negative 202 acknowledgements (NACKs), that can be used to report on specific 203 congestion events. The use of the RTP/AVPF profile is dependent 204 on signalling, but is otherwise generally backwards compatible, as 205 it keeps the same average RTCP reporting interval as the base RTP 206 specification. The RTP Codec Control Messages [RFC5104] extend 207 the RTP/AVPF profile with additional feedback messages that can be 208 used to influence that way in which rate adaptation occurs. The 209 dynamics of how rapidly feedback can be sent are unchanged. 211 o Finally, the RTP and RTCP extensions for Explicit Congestion 212 Notification (ECN) [I-D.ietf-avtcore-ecn-for-rtp] can be used to 213 provide feedback on the number of packets that received an ECN 214 Congestion Experienced (CE) mark. This extension builds on the 215 RTP/AVPF profile to allow rapid congestion feedback when ECN is 216 supported. 218 In addition to these mechanisms for providing feedback, the sender 219 can include an RTP header extension in each packet to record packet 220 transmission times. There are two methods: [RFC5450] represents the 221 transmission time in terms of a time-offset from the RTP timestamp of 222 the packet, while [RFC6051] includes an explicit NTP-format sending 223 timestamp (potentially more accurate, but a higher header overhead). 224 Accurate sending timestamps can be helpful for estimating queuing 225 delays, to get an early indication of the onset of congestion. 227 Taken together, these various mechanisms allow receivers to provide 228 feedback on the senders when congestion events occur, with varying 229 degrees of timeliness and accuracy. The key distinction is between 230 systems that use only the basic RTCP mechanisms, without RTP/AVPF 231 rapid feedback, and those that use the RTP/AVPF extensions and so can 232 respond to congestion more rapidly. 234 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile 236 The feedback mechanisms defined in [RFC3550] and available under the 237 RTP/AVP profile [RFC3551] are the minimum that can be assumed for a 238 baseline circuit breaker mechanism that is suitable for all unicast 239 applications of RTP. Accordingly, for an RTP circuit breaker to be 240 useful, it needs to be able to detect that an RTP flow is causing 241 excessive congestion using only basic RTCP features, without needing 242 RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports. 244 Three potential congestion signals are available from the basic RTCP 245 SR/RR packets and are reported for each synchronisation source (SSRC) 246 in the RTP session: 248 1. The sender can estimate the network round-trip time once per RTCP 249 reporting interval, based on the contents and timing of RTCP SR 250 and RR packets. 252 2. Receivers report a jitter estimate (the statistical variance of 253 the RTP data packet inter-arrival time) calculated over the RTCP 254 reporting interval. Due to the nature of the jitter calculation 255 ([RFC3550], section 6.4.4), the jitter is only meaningful for RTP 256 flows that send a single data packet for each RTP timestamp value 257 (i.e., audio flows, or video flows where each frame comprises one 258 RTP packet). 260 3. Receivers report the fraction of RTP data packets lost during the 261 RTCP reporting interval, and the cumulative number of RTP packets 262 lost over the entire RTP session. 264 These congestion signals limit the possible circuit breakers, since 265 they give only limited visibility into the behaviour of the network. 267 RTT estimates are widely used in congestion control algorithms, as a 268 proxy for queuing delay measures in delay-based congestion control or 269 to determine connection timeouts. RTT estimates derived from RTCP SR 270 and RR packets sent according to the RTP/AVP timing rules are far too 271 infrequent to be useful though, and don't give enough information to 272 distinguish a delay change due to routing updates from queuing delay 273 caused by congestion. Accordingly, we do not use the RTT estimate 274 alone as an RTP circuit breaker. 276 Increased jitter can be a signal of transient network congestion, but 277 in the highly aggregated form reported in RTCP RR packets, it offers 278 insufficient information to estimate the extent or persistence of 279 congestion. Jitter reports are a useful early warning of potential 280 network congestion, but provide an insufficiently strong signal to be 281 used as a circuit breaker. 283 The remaining congestion signals are the packet loss fraction and the 284 cumulative number of packets lost. These are robust indicators of 285 congestion in a network where packet loss is primarily due to queue 286 overflows, although less accurate in networks where losses can be 287 caused by non-congestive packet corruption. TCP uses packet loss as 288 a congestion signal. 290 Two packet loss regimes can be observed: 1) RTCP RR packets show a 291 non-zero packet loss fraction, while the extended highest sequence 292 number received continues to increment; and 2) RR packets show a loss 293 fraction of zero, but the extended highest sequence number received 294 does not increment even though the sender has been transmitting RTP 295 data packets. The former corresponds to the TCP congestion avoidance 296 state, and indicates a congested path that is still delivering data; 297 the latter corresponds to a TCP timeout, and is most likely due to a 298 path failure. We derive circuit breaker conditions for these two 299 loss regimes. 301 4.1. RTP/AVP Circuit Breaker #1: Timeout 303 If RTP data packets are being sent while the corresponding RTCP RR 304 packets report a non-increasing extended highest sequence number 305 received, this is an indication that those RTP data packets are not 306 reaching the receiver. This could be a short-term issue affecting 307 only a few packets, perhaps caused by a slow-to-open firewall or a 308 transient connectivity problem, but if the issue persists, it is a 309 sign of a more ongoing and significant problem. Accordingly, if a 310 sender of RTP data packets receives two or more consecutive RTCP RR 311 packets from the same receiver that correspond to its transmission, 312 and have a non-increasing extended highest sequence number received 313 field (i.e., at least three RTCP RR packets that report the same 314 value in the extended highest sequence number received field, when 315 the sender has sent data packets that would have caused an increase 316 in the reported value of the extended highest sequence number 317 received if they had reached the receiver), then that sender SHOULD 318 cease transmission. 320 Systems that usually send at a high data rate, but which can reduce 321 their data rate significantly (i.e., by at least a factor of ten), 322 MAY first reduce their sending rate to this lower value to see if 323 this resolves the congestion, but MUST then cease transmission if the 324 problem does not resolve itself within a further two RTCP reporting 325 intervals. An example of this might be a video conferencing system 326 that backs off to sending audio only, before completely dropping the 327 call. If such a reduction in sending rate resolves the congestion 328 problem, the sender MAY gradually increase the rate at which it sends 329 data after a reasonable amount of time has passed, provided it takes 330 care not to cause the problem to recur ("reasonable" is intentionally 331 not defined here). 333 The choice of two RTCP reporting intervals is to give enough time for 334 transient problems to resolve themselves, but to stop problem flows 335 quickly enough to avoid causing serious ongoing network congestion. 336 A single RTCP report showing no reception could be caused by numerous 337 transient faults, and so will not cease transmission. Waiting for 338 more than two RTCP reports before stopping a flow might avoid some 339 false positives, but would lead to problematic flows running for a 340 long time before being cut off. 342 4.2. RTP/AVP Circuit Breaker #2: Congestion 344 If RTP data packets are being sent, and the corresponding RTCP RR 345 packets show non-zero packet loss fraction and increasing extended 346 highest sequence number received, then the RTP data packets are 347 arriving at the receiver, but some degree of congestion is occurring. 348 The RTP/AVP profile [RFC3551] states that: 350 If best-effort service is being used, RTP receivers SHOULD monitor 351 packet loss to ensure that the packet loss rate is within 352 acceptable parameters. Packet loss is considered acceptable if a 353 TCP flow across the same network path and experiencing the same 354 network conditions would achieve an average throughput, measured 355 on a reasonable timescale, that is not less than the RTP flow is 356 achieving. This condition can be satisfied by implementing 357 congestion control mechanisms to adapt the transmission rate (or 358 the number of layers subscribed for a layered multicast session), 359 or by arranging for a receiver to leave the session if the loss 360 rate is unacceptably high. 362 The comparison to TCP cannot be specified exactly, but is intended 363 as an "order-of-magnitude" comparison in timescale and throughput. 364 The timescale on which TCP throughput is measured is the round- 365 trip time of the connection. In essence, this requirement states 366 that it is not acceptable to deploy an application (using RTP or 367 any other transport protocol) on the best-effort Internet which 368 consumes bandwidth arbitrarily and does not compete fairly with 369 TCP within an order of magnitude. 371 (The phase "order of magnitude" in the above means a factor of ten). 373 The throughput of a long-lived TCP connection can be estimated using 374 the TCP throughput equation: 376 s 377 X = -------------------------------------------------------------- 378 R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) 380 Where: 382 X is the transmit rate in bytes/second. 384 s is the packet size in bytes. If the RTP data packets vary in 385 size, then the average size is to be used. 387 R is the round trip time in seconds. 389 p is the loss event rate, between 0 and 1.0, of the number of loss 390 events as a fraction of the number of packets transmitted. 392 t_RTO is the TCP retransmission timeout value in seconds, 393 approximated by setting t_RTO = 4*R. 395 b is the number of packets acknowledged by a single TCP 396 acknowledgement ([RFC3448] recommends the use of b=1 since many 397 TCP implementations do not use delayed acknowledgements). 399 This is the same approach to estimated TCP throughput that is used in 400 [RFC3448]. Under conditions of low packet loss, this formula can be 401 approximated as follows with reasonable accuracy: 403 s 404 X = --------------- 405 R * sqrt(p*2/3) 407 It is RECOMMENDED that this simplified throughout equation be used, 408 since the reduction in accuracy is small, and it is much simpler to 409 calculate than the full equation. 411 Given this TCP equation, two parameters need to be estimated in order 412 to calculate the throughput: the round trip time, R, and the loss 413 event rate, p (the packet size, s, is known to the sender). The 414 round trip time can be estimated from RTCP SR and RR packets. This 415 is done too infrequently for accurate statistics, but is the best 416 that can be done with the standard RTCP mechanisms. 418 RTCP RR packets contain the packet loss fraction, rather than the 419 loss event rate, so p cannot be reported (TCP typically treats the 420 loss of multiple packets within a single RTT as one loss event, but 421 RTCP RR packets report the overall fraction of packets lost, not 422 caring about when the losses occurred). Using the loss fraction in 423 place of the loss event rate can overestimate the loss. We believe 424 that this overestimate will not be significant, given that we are 425 only interested in order of magnitude comparison (Floyd et al, 426 "Equation-Based Congestion Control for Unicast Applications", Proc. 427 SIGCOMM 2000, section 3.2.1, show that the difference is small for 428 steady-state conditions and random loss, but using the loss fraction 429 is more conservative in the case of bursty loss). 431 The congestion circuit breaker is therefore: when RTCP RR packets are 432 received, estimate the TCP throughput using the simplified equation 433 above, and the measured R, p (approximated by the loss fraction), and 434 s. Compare this with the actual sending rate. If the actual sending 435 rate has been more than a factor of ten greater than the throughput 436 equation estimate for two or more RTCP reporting intervals, stop 437 transmitting. 439 Again, we use two reporting intervals to avoid triggering the circuit 440 breaker on transient failures. This circuit breaker is a worst-case 441 condition, and congestion control needs to be performed to keep well 442 within this bound. It is expected that the circuit breaker will only 443 be triggered if the usual congestion control fails for some reason. 445 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile 447 More rapid feedback allows more responsiveness. The receiver SHOULD 448 provide feedback more often during, or at onset of, congestion, and 449 provide feedback less often when there is no congestion. 451 (tbd -- mechanisms probably need to be designed in conjunction with 452 the different classes of congestion control that can leverage RTP/ 453 AVPF; e.g., we might need to specify limits for TFRC-like or delay- 454 based algorithms using RTP/AVPF feedback.) 456 (tbd -- a high-level question to be answered is whether we need to 457 specify anything different for the circuit breaker for AVPF, or if we 458 leave that unchanged, and focus solely on the dynamics, to ensure the 459 circuit breaker is never triggered.) 461 6. Impact of RTCP XR 463 (tbd) 465 This improves the information, but doesn't change the dynamics of the 466 congestion control loop. Suspect the impact will actually be quite 467 small. 469 Packets discarded [I-D.ietf-xrblock-rtcp-xr-discard] or bytes 470 discarded [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] due to late 471 arrival by the receiver might indicate congestion. Congestion 472 control needs to consider the discarded packets as if they were lost 473 packets. 475 The RTCP RR reports the loss fraction over an RTCP interval which is 476 insufficient to distinguish between solitary or bursty losses. To 477 provide rough sense of duration of losses or discards, an endpoint 478 can use burst/gap reporting for loss 479 [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] and discard 480 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. For more accurate 481 reporting the receiver can use Run-length encoded (RLE) lost 482 [RFC3611] or discarded [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] 483 packets. 485 For precise measurement of network roundtrip delay the receiver can 486 signal its end-system delay [I-D.ietf-xrblock-rtcp-xr-delay] 487 [RFC3611]. 489 A receiver can also indicate onset or end of congestion by reporting 490 the distribution of the inter-packet delay variation 491 [I-D.ietf-xrblock-rtcp-xr-pdv] [RFC3611]. 493 7. Impact of Explicit Congestion Notification (ECN) 495 ECN-CE marked packets SHOULD be treated as if it were lost for the 496 purposes of congestion control, when determining the optimal rate at 497 which to send. However, it seems unwise to treat the receipt of 498 multiple ECN-CE marked packets as a circuit breaker, since it is 499 likely that ECN-capable and non-ECN-capable paths will exist for a 500 long time to come. Rather, consider packet loss as the circuit 501 breaker condition as for non-ECN flows. 503 8. Session Timeout 505 From a usability perspective, if there is no audio or video response 506 from the other peer, it is likely that the user will terminate the 507 session. 509 According to RFC 3550 [RFC3550], any participant that has not sent an 510 RTP packet within the last two RTCP interval is removed from the 511 sender list. To avoid timing out the specific flow, the endpoint 512 MUST send corresponding RTCP reports. Interactive Connectivity 513 Establishment (ICE) [RFC5245] recommends that the timeout MUST NOT be 514 less than 15 seconds. 516 If no RTCP RR arrives for two complete SR intervals, the sender 517 SHOULD cease transmission. However, if the endpoint can reduce the 518 media rate then it MAY first reduce the rate to the lower value, but 519 terminate the transmission if still no RTCP RR is received in the 520 next two SR intervals. 522 9. IANA Considerations 524 There are no actions for IANA. 526 10. Security Considerations 528 (tbd: Security considerations: how to protect against fake RTCP 529 reports being used to force sessions to close? SRTCP is one option, 530 but are there any lighter weight options?) 532 11. Open Issues 534 o Clarify: when will the recipient end a call, if it receives no 535 data? 537 o When we say "cease transmission", do we need some minimum interval 538 before we're allowed to restart? 540 o What does "cease transmission" mean? Do we send an RTCP BYE and 541 leave the session, or is it more temporary than that? 543 o Add a receiver-based circuit-breaker condition. Note that this is 544 dependent on the signalling still working, since the receiver 545 needs to be able to inform the sender. 547 12. Acknowledgements 549 The authors would like to thank Harald Alvestrand, Randell Jesup, and 550 Abheek Saha for their valuable feedback. 552 13. References 554 13.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 560 Friendly Rate Control (TFRC): Protocol Specification", 561 RFC 3448, January 2003. 563 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 564 Jacobson, "RTP: A Transport Protocol for Real-Time 565 Applications", STD 64, RFC 3550, July 2003. 567 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 568 Video Conferences with Minimal Control", STD 65, RFC 3551, 569 July 2003. 571 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 572 Protocol Extended Reports (RTCP XR)", RFC 3611, 573 November 2003. 575 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 576 "Extended RTP Profile for Real-time Transport Control 577 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 578 July 2006. 580 13.2. Informative References 582 [I-D.ietf-avtcore-ecn-for-rtp] 583 Westerlund, M., Johansson, I., Perkins, C., and K. 584 Carlberg, "Explicit Congestion Notification (ECN) for RTP 585 over UDP", draft-ietf-avtcore-ecn-for-rtp-06 (work in 586 progress), February 2012. 588 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 589 Clark, A., Hunt, G., Wu, W., and R. Huang, "RTCP XR Report 590 Block for Burst/Gap Discard metric Reporting", 591 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-02 (work in 592 progress), January 2012. 594 [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] 595 Clark, A., Hunt, G., Zhao, J., Wu, W., and S. Zhang, "RTCP 596 XR Report Block for Burst/Gap Loss metric Reporting", 597 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-01 (work in 598 progress), January 2012. 600 [I-D.ietf-xrblock-rtcp-xr-delay] 601 Hunt, G., Gross, K., and A. Clark, "RTCP XR Report Block 602 for Delay metric Reporting", 603 draft-ietf-xrblock-rtcp-xr-delay-01 (work in progress), 604 December 2011. 606 [I-D.ietf-xrblock-rtcp-xr-discard] 607 Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report 608 Block for Discard metric Reporting", 609 draft-ietf-xrblock-rtcp-xr-discard-01 (work in progress), 610 December 2011. 612 [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] 613 Ott, J., Singh, V., and I. Curcio, "Real-time Transport 614 Control Protocol (RTCP) Extension Report (XR) for Run 615 Length Encoding of Discarded Packets", 616 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 (work in 617 progress), February 2012. 619 [I-D.ietf-xrblock-rtcp-xr-pdv] 620 Hunt, G. and A. Clark, "RTCP XR Report Block for Packet 621 Delay Variation Metric Reporting", 622 draft-ietf-xrblock-rtcp-xr-pdv-02 (work in progress), 623 December 2011. 625 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 626 of Explicit Congestion Notification (ECN) to IP", 627 RFC 3168, September 2001. 629 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 630 "Codec Control Messages in the RTP Audio-Visual Profile 631 with Feedback (AVPF)", RFC 5104, February 2008. 633 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 634 (ICE): A Protocol for Network Address Translator (NAT) 635 Traversal for Offer/Answer Protocols", RFC 5245, 636 April 2010. 638 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 639 RTP Streams", RFC 5450, March 2009. 641 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 642 Flows", RFC 6051, November 2010. 644 Authors' Addresses 646 Colin Perkins 647 University of Glasgow 648 School of Computing Science 649 Glasgow G12 8QQ 650 United Kingdom 652 Email: csp@csperkins.org 654 Varun Singh 655 Aalto University 656 School of Science and Technology 657 Otakaari 5 A 658 Espoo, FIN 02150 659 Finland 661 Email: varun@comnet.tkk.fi 662 URI: http://www.netlab.tkk.fi/~varun/