idnits 2.17.1 draft-alvestrand-rmcat-congestion-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Dec13' is mentioned on line 407, but not defined ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Lundin 3 Internet-Draft S. Holmer 4 Intended status: Informational Google 5 Expires: August 18, 2014 L. De Cicco 6 S. Mascolo 7 Politecnico di Bari 8 H. Alvestrand, Ed. 9 Google 10 February 14, 2014 12 A Google Congestion Control Algorithm for Real-Time Communication 13 draft-alvestrand-rmcat-congestion-02 15 Abstract 17 This document describes two methods of congestion control when using 18 real-time communications on the World Wide Web (RTCWEB); one sender- 19 based and one receiver-based. 21 It is published as an input document to the RMCAT working group on 22 congestion control for media streams. The mailing list of that WG is 23 rmcat@ietf.org. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 18, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Mathemathical notation conventions . . . . . . . . . . . 3 67 2. System model . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Receiver side control . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Procsesing multiple streams using RTP timestamp to NTP 70 time conversion . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Arrival-time model . . . . . . . . . . . . . . . . . . . 5 72 3.3. Arrival-time filter . . . . . . . . . . . . . . . . . . . 7 73 3.4. Over-use detector . . . . . . . . . . . . . . . . . . . . 8 74 3.5. Rate control . . . . . . . . . . . . . . . . . . . . . . 10 75 4. Sender side control . . . . . . . . . . . . . . . . . . . . . 12 76 5. Interoperability Considerations . . . . . . . . . . . . . . . 14 77 6. Implementation Experience . . . . . . . . . . . . . . . . . . 14 78 7. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 11.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 17 86 A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 17 87 A.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 18 88 A.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 18 89 A.4. rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . . 18 90 A.5. rmcat -00 to -01 . . . . . . . . . . . . . . . . . . . . 18 91 A.6. rmcat -01 to -02 . . . . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 Congestion control is a requirement for all applications that wish to 97 share the Internet [RFC2914]. 99 The problem of doing congestion control for real-time media is made 100 difficult for a number of reasons: 102 o The media is usually encoded in forms that cannot be quickly 103 changed to accommodate varying bandwidth, and bandwidth 104 requirements can often be changed only in discrete, rather large 105 steps 107 o The participants may have certain specific wishes on how to 108 respond - which may not be reducing the bandwidth required by the 109 flow on which congestion is discovered 111 o The encodings are usually sensitive to packet loss, while the real 112 time requirement precludes the repair of packet loss by 113 retransmission 115 This memo describes two congestion control algorithms that together 116 are seen to give reasonable performance and reasonable (not perfect) 117 bandwidth sharing with other conferences and with TCP-using 118 applications that share the same links. 120 The signaling used consists of standard RTP timestamps [RFC3550] 121 possibly augmented with RTP transmission time offsets [RFC5450], 122 standard RTCP feedback reports and Temporary Maximum Media Stream Bit 123 Rate Requests (TMMBR) as defined in [RFC5104] section 3.5.4, or by 124 using the REMB feedback report defined in [I-D.alvestrand-rmcat-remb] 126 1.1. Mathemathical notation conventions 128 The mathematics of this document have been transcribed from a more 129 formula-friendly format. 131 The following notational conventions are used: 133 X_bar The variable X, where X is a vector - conventionally marked by 134 a bar on top of the variable name. 136 X_hat An estimate of the true value of variable X - conventionally 137 marked by a circumflex accent on top of the variable name. 139 X(i) The "i"th value of X - conventionally marked by a subscript i. 141 [x y z] A row vector consisting of elements x, y and z. 143 X_bar^T The transpose of vector X_bar. 145 E{X} The expected value of the stochastic variable X 147 2. System model 149 The following elements are in the system: 151 o RTP packet - an RTP packet containing media data. 153 o Frame - a set of RTP packets transmitted from the sender at the 154 same time instant. This could be a video frame, an audio frame, 155 or a mix of audio and video packets. A frame can be defined by 156 the RTP packet send time (RTP timestamp + transmission time 157 offset), or by the RTP timestamp if the transmission time offset 158 field is not present. 160 o Incoming media streams - a stream of frames consisting of RTP 161 packets. 163 o Media codec - has a bandwidth control, and encodes the incoming 164 media stream into an RTP stream. 166 o RTP sender - sends the RTP stream over the network to the RTP 167 receiver. Generates the RTP timestamp. 169 o RTP receiver - receives the RTP stream, notes the time of arrival. 170 Regenerates the media stream for the recipient. 172 o RTCP sender at RTP sender - sends sender reports with mappings 173 between RTP timestamps and NTP time. 175 o RTCP sender at RTP receiver - sends receiver reports and TMMBR/ 176 REMB messages. 178 o RTCP receiver at RTP sender - receives receiver reports and TMMBR/ 179 REMB messages, reports these to sender side control. 181 o RTCP receiver at RTP receiver. 183 o Sender side control - takes loss rate info, round trip time info, 184 and TMMBR/REMB messages and computes a sending bitrate. 186 o Receiver side control - takes the packet arrival info at the RTP 187 receiver and decides when to send TMMBR/REMB messages. 189 Together, sender side control and receiver side control implement the 190 congestion control algorithm. 192 3. Receiver side control 194 The receive-side algorithm can be further decomposed into four parts: 195 an RTP timestamp to NTP time conversion, arrival-time filter, an 196 over-use detector, and a remote rate-control. 198 3.1. Procsesing multiple streams using RTP timestamp to NTP time 199 conversion 201 It is common that multiple RTP streams are sent from the sender to 202 the receiver. In such a situation the RTP timestamps of incoming can 203 first be converted to a common time base using the RTP timestamp and 204 NTP time pairs in RTCP SR reports[RFC3550]. The converted timestamps 205 can then be used instead of RTP timestamps in the arrival-time 206 filtering, and since all streams from the same sender have timestamps 207 in the same time base they can all be processed by the same filter. 208 This has the advantage of quicker reactions and reduces problems of 209 noisy measurements due to self-inflicted cross-traffic. 211 In the time interval from the start of the call until a stream from 212 the same sender has received an RTCP SR report, the receiver-side 213 control operates in single-stream mode. In that mode only one RTP 214 stream can be processed by the over-use detector. As soon as a 215 stream has received one or more RTCP SR reports the receiver-side 216 control can change to a multi-stream mode, where all RTP streams from 217 the same sender which have received one or more RTCP SR reports can 218 be processed by the over-use detector. When switching to the multi- 219 stream mode the state of the over-use detector must be modified to 220 avoid a time base mismatch. This can either be done by resetting the 221 stored RTP timestamp values or by converting them using the newly 222 received RTCP SR report. 224 3.2. Arrival-time model 226 This section describes an adaptive filter that continuously updates 227 estimates of network parameters based on the timing of the received 228 frames. 230 At the receiving side we are observing groups of incoming packets, 231 where each group of packets corresponding to the same frame having 232 timestamp T(i). 234 Each frame is assigned a receive time t(i), which corresponds to the 235 time at which the whole frame has been received (ignoring any packet 236 losses). A frame is delayed relative to its predecessor if 237 t(i)-t(i-1)>T(i)-T(i-1), i.e., if the arrival time difference is 238 larger than the timestamp difference. 240 We define the (relative) inter-arrival time, d(i) as 242 d(i) = t(i)-t(i-1)-(T(i)-T(i-1)) 244 Since the time ts to send a frame of size L over a path with a 245 capacity of C is roughly 247 ts = L/C 249 we can model the inter-arrival time as 251 L(i)-L(i-1) 252 d(i) = -------------- + w(i) = dL(i)/C+w(i) 253 C 255 Here, w(i) is a sample from a stochastic process W, which is a 256 function of the capacity C, the current cross traffic X(i), and the 257 current send bit rate R(i). We model W as a white Gaussian process. 258 If we are over-using the channel we expect w(i) to increase, and if a 259 queue on the network path is being emptied, w(i) will decrease; 260 otherwise the mean of w(i) will be zero. 262 Breaking out the mean m(i) from w(i) to make the process zero mean, 263 we get 265 Equation 5 267 d(i) = dL(i)/C + m(i) + v(i) 269 This is our fundamental model, where we take into account that a 270 large frame needs more time to traverse the link than a small frame, 271 thus arriving with higher relative delay. The noise term represents 272 network jitter and other delay effects not captured by the model. 274 When graphing the values for d(i) versus dL(i) on a scatterplot, we 275 find that most samples cluster around the center, and the outliers 276 are clustered along a line with average slope 1/C and zero offset. 278 For instance, when using a regular video codec, most frames are 279 roughly the same size after encoding (the central "cloud"); the 280 exceptions are I-frames (or key frames) which are typically much 281 larger than the average causing positive outliers (the I-frame 282 itself) and negative outliers (the frame after an I-frame) on the dL 283 axis. Audio frames on the other hand often consist of single packets 284 of equal size, and an audio-only media stream would have its frames 285 scattered at dL = 0. 287 3.3. Arrival-time filter 289 The parameters d(i) and dL(i) are readily available for each frame i 290 > 1, and we want to estimate C(i) and m(i) and use those estimates to 291 detect whether or not we are over-using the bandwidth currently 292 available. These parameters are easily estimated by any adaptive 293 filter - we are using the Kalman filter. 295 Let 297 theta_bar(i) = [1/C(i) m(i)]^T 299 and call it the state of time i. We model the state evolution from 300 time i to time i+1 as 302 theta_bar(i+1) = theta_bar(i) + u_bar(i) 304 where u_bar(i) is the zero mean white Gaussian process noise with 305 covariance 307 Equation 7 309 Q(i) = E{u_bar(i) u_bar(i)^T} 311 Given equation 5 we get 313 Equation 8 315 d(i) = h_bar(i)^T theta_bar(i) + v(i) 317 h_bar(i) = [dL(i) 1]^T 319 where v(i) is zero mean white Gaussian measurement noise with 320 variance var_v = sigma(v,i)^2 322 The Kalman filter recursively updates our estimate 324 theta_hat(i) = [1/C_hat(i) m_hat(i)]^T 326 as 327 z(i) = d(i) - h_bar(i)^T * theta_hat(i-1) 329 theta_hat(i) = theta_hat(i-1) + z(i) * k_bar(i) 331 E(i-1) * h_bar(i) 332 k_bar(i) = -------------------------------------------- 333 var_v_hat + h_bar(i)^T * E(i-1) * h_bar(i) 335 E(i) = (I - K_bar(i) * h_bar(i)^T) * E(i-1) + Q(i) 337 I is the 2-by-2 identity matrix. 339 The variance var_v = sigma(v,i)^2 is estimated using an exponential 340 averaging filter, modified for variable sampling rate 342 var_v_hat = beta*sigma(v,i-1)^2 + (1-beta)*z(i)^2 344 beta = (1-alpha)^(30/(1000 * f_max)) 346 where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1...i is the 347 highest rate at which frames have been captured by the camera the 348 last K frames and alpha is a filter coefficient typically chosen as a 349 number in the interval [0.1, 0.001]. Since our assumption that v(i) 350 should be zero mean WGN is less accurate in some cases, we have 351 introduced an additional outlier filter around the updates of 352 var_v_hat. If z(i) > 3 var_v_hat the filter is updated with 3 353 sqrt(var_v_hat) rather than z(i). For instance v(i) will not be 354 white in situations where packets are sent at a higher rate than the 355 channel capacity, in which case they will be queued behind each 356 other. In a similar way, Q(i) is chosen as a diagonal matrix with 357 main diagonal elements given by 359 diag(Q(i)) = 30/(1000 * f_max)[10^-10 10^-2]^T 361 It is necessary to scale these filter parameters with the frame rate 362 to make the detector respond as quickly at low frame rates as at high 363 frame rates. 365 3.4. Over-use detector 367 The offset estimate m(i) is compared with a threshold gamma_1(i). An 368 estimate above the threshold is considered as an indication of over- 369 use. Such an indication is not enough for the detector to signal 370 over-use to the rate control subsystem. Not until over-use has been 371 detected for at least gamma_2 milliseconds and at least gamma_3 372 frames, a definitive over-use will be signaled. However, if the 373 offset estimate m(i) was decreased in the last update, over-use will 374 not be signaled even if all the above conditions are met. Similarly, 375 the opposite state, under-use, is detected when m(i) < -gamma_1(i). 376 If neither over-use nor under-use is detected, the detector will be 377 in the normal state. 379 The threshold gamma_1 has a remarkable impact on the overall dynamics 380 and performance of the algorithm. In particular, it has been shown 381 that when using a static threshold gamma_1, a flow controlled by the 382 proposed algorithm can be starved by a concurrent TCP flow [Pv13]. 383 This starvation can be avoided by increasing the threshold gamma_1 to 384 a sufficiently large value. 386 The reason is that, by using a larger value of gamma_1, a larger 387 queuing delay can be tolerated, whereas with a small gamma_1, the 388 over-use detector quickly reacts to a small increase in the offset 389 estimate m(i) by generating an over-use signal that reduces A_r. 390 Thus, it is necessary to dynamically tune the threshold gamma_1 to 391 get good performance in the most common scenarios, such as when 392 competing with loss-based flows. 394 For this reason, we propose to vary the threshold gamma_1(i) 395 according to the following dynamic equation: 397 gamma_1(i) = gamma_1(i-1) + (t(i)-t(i-1)) * K(i) * 398 (|m(i)| - gamma_1(i-1)) 400 with K(i)=K_d if |m(i)| < gamma_1(i-1) or K(i)=K_u otherwise. The 401 rationale is to increase gamma_1(i) when m(i) is outside of the range 402 [-gamma_1(i-1),gamma_1(i-1)], whereas, when the offset estimate m 403 falls back into the range, gamma_1 is decreased. In this way when 404 m(i) quickly increases, for instance due to a TCP flow entering the 405 same bottleneck, gamma_1(i) increases and avoids the uncontrolled 406 generation of over-use signals which may lead to starvation of the 407 flow controlled by the proposed algorithm [Dec13]. 409 On the other hand, when m(i) falls back into the range 410 [-gamma_1(i-1),gamma_1(i-1)] the threshold gamma_1(i) is decreased so 411 that a lower queuing delay can be achieved. 413 We suggest to choose K_u > K_d so that the rate at which gamma_1 is 414 increased is higher than the rate at which it is decreased. With 415 this setting it is possible to quickly increase the threshold in the 416 case of a concurrent TCP flow and prevent starvation. 418 3.5. Rate control 420 The rate control at the receiving side is designed to increase the 421 receive-side estimate of the available bandwidth A_hat as long as the 422 detected state is normal. Doing that assures that we, sooner or 423 later, will reach the available bandwidth of the channel and detect 424 an over-use. 426 As soon as over-use has been detected the receive-side estimate of 427 the available bandwidth is decreased. In this way we get a recursive 428 and adaptive estimate of the available bandwidth. 430 In this document we make the assumption that the rate control 431 subsystem is executed periodically and that this period is constant. 433 The rate control subsystem has 3 states: Increase, Decrease and Hold. 434 "Increase" is the state when no congestion is detected; "Decrease" is 435 the state where congestion is detected, and "Hold" is a state that 436 waits until built-up queues have drained before going to "increase" 437 state. 439 The state transitions (with blank fields meaning "remain in state") 440 are: 442 State ----> | Hold |Increase |Decrease 443 Signal----------------------------------------- 444 v | | | 445 Over-use | Decrease |Decrease | 446 ----------------------------------------------- 447 Normal | Increase | |Hold 448 ----------------------------------------------- 449 Under-use | |Hold |Hold 450 ----------------------------------------------- 452 The subsystem starts in the increase state, where it will stay until 453 over-use or under-use has been detected by the detector subsystem. 454 On every update the receive-side estimate of the available bandwidth 455 is increased with a factor which is a function of the global system 456 response time and the estimated measurement noise variance var_v_hat. 457 The global system response time is the time from an increase that 458 causes over-use until that over-use can be detected by the over-use 459 detector. The variance var_v_hat affects how responsive the Kalman 460 filter is, and is thus used as an indicator of the delay inflicted by 461 the Kalman filter. 463 A_hat(i) = eta*A_hat(i-1) 464 1.001+B 465 eta(RTT, var_v_hat) = ------------------------------------------ 466 1+e^(b(d*RTT - (c1 * var_v_hat + c2))) 468 Here, B, b, d, c1 and c2 are design parameters. 470 Since the system depends on over-using the channel to verify the 471 current available bandwidth estimate, we must make sure that our 472 estimate doesn't diverge from the rate at which the sender is 473 actually sending. Thus, if the sender is unable to produce a bit 474 stream with the bit rate the receiver is asking for, the available 475 bandwidth estimate must stay within a given bound. Therefore we 476 introduce a threshold 478 A_hat(i) < 1.5 * R_hat(i) 480 where R_hat(i) is the incoming bit rate measured over a T seconds 481 window: 483 R_hat(i) = 1/T * sum(L(j)) for j from 1 to N(i) 485 N(i) is the number of frames received the past T seconds and L(j) is 486 the payload size of frame j. Ideally T should be chosen to match the 487 rate controller at the sender. A window between 0.5 and 1 second is 488 recommended. 490 When an over-use is detected the system transitions to the decrease 491 state, where the receive-side available bandwidth estimate is 492 decreased to a factor times the currently incoming bit rate. 494 A_hat(i) = alpha * R_hat(i) 496 alpha is typically chosen to be in the interval [0.8, 0.95]. 498 When the detector signals under-use to the rate control subsystem, we 499 know that queues in the network path are being emptied, indicating 500 that our available bandwidth estimate is lower than the actual 501 available bandwidth. Upon that signal the rate control subsystem 502 will enter the hold state, where the receive-side available bandwidth 503 estimate will be held constant while waiting for the queues to 504 stabilize at a lower level - a way of keeping the delay as low as 505 possible. This decrease of delay is wanted, and expected, 506 immediately after the estimate has been reduced due to over-use, but 507 can also happen if the cross traffic over some links is reduced. In 508 either case we want to measure the highest incoming rate during the 509 under-use interval: 511 R_max = max{R_hat(i)} for i in 1..K 513 where K is the number of frames of under-use before returning to the 514 normal state. R_max is a measure of the actual bandwidth available 515 and is a good guess of what bit rate the sender should be able to 516 transmit at. Therefore the receive-side available bandwidth estimate 517 will be set to R_max when we transition from the hold state to the 518 increase state. 520 One design decision is when to send rate control messages. The time 521 from a change in congestion to the sending of the feedback message is 522 a limitation on how fast the sender can react. Sending too many 523 messages giving no new information is a waste of bandwidth - but in 524 the case of severe congestion, feedback messages can be lost, 525 resulting in a failure to react in a timely manner. 527 The conclusion is that feedback messages should be sent on a 528 "heartbeat" schedule, allowing the sender side control to react to 529 missing feedback messages by reducing its send rate, but they should 530 also be sent whenever the estimated bandwidth value has changed 531 significantly, without waiting for the heartbeat time, up to some 532 limiting upper bound on the send rate. 534 The minimum interval is named t_min_fb_interval. 536 The maximum interval is named t_max_fb_interval. 538 The permissible values of these intervals will be bounded by the RTP 539 session's RTCP bandwidth and its rtcp_frr setting. 541 [TODO: Get some example values for these timers] 543 4. Sender side control 545 An additional congestion controller resides at the sending side. It 546 bases its decisions on the round-trip time, packet loss and available 547 bandwidth estimates transmitted from the receiving side. 549 The available bandwidth estimates produced by the receiving side are 550 only reliable when the size of the queues along the channel are large 551 enough. If the queues are very short, over-use will only be visible 552 through packet losses, which aren't used by the receiving side 553 algorithm. 555 This algorithm is run every time a receive report arrives at the 556 sender, which will happen no more often than t_min_fb_interval, and 557 no less often than t_max_fb_interval. If no receive report is 558 received within 2x t_max_fb_interval (indicating at least 2 lost 559 feedback reports), the algorithm will take action as if all packets 560 in the interval have been lost, resulting in a halving of the send 561 rate. 563 o If 2-10% of the packets have been lost since the previous report 564 from the receiver, the sender available bandwidth estimate As(i) 565 (As denotes 'sender available bandwidth') will be kept unchanged. 567 o If more than 10% of the packets have been lost a new estimate is 568 calculated as As(i)=As(i-1)(1-0.5p), where p is the loss ratio. 570 o As long as less than 2% of the packets have been lost As(i) will 571 be increased as As(i)=1.05(As(i-1)+1000) 573 The new send-side estimate is limited by the TCP Friendly Rate 574 Control formula [RFC3448] and the receive-side estimate of the 575 available bandwidth A(i): 577 8 s 578 As(i) >= ---------------------------------------------------------- 579 R*sqrt(2*b*p/3) + (t_RTO*(3*sqrt(3*b*p/8) * p * (1+32*p^2))) 581 As(i) <= A(i) 583 where b is the number of packets acknowledged by a single TCP 584 acknowledgment (set to 1 per TFRC recommendations), t_RTO is the TCP 585 retransmission timeout value in seconds (set to 4*R) and s is the 586 average packet size in bytes. R is the round-trip time in seconds. 588 (The multiplication by 8 comes because TFRC is computing bandwidth in 589 bytes, while this document computes bandwidth in bits.) 591 In words: The sender-side estimate will never be larger than the 592 receiver-side estimate, and will never be lower than the estimate 593 from the TFRC formula. 595 We motivate the packet loss thresholds by noting that if the 596 transmission channel has a small amount of packet loss due to over- 597 use, that amount will soon increase if the sender does not adjust his 598 bit rate. Therefore we will soon enough reach above the 10 % 599 threshold and adjust As(i). However if the packet loss rate does not 600 increase, the losses are probably not related to self-induced channel 601 over-use and therefore we should not react on them. 603 5. Interoperability Considerations 605 There are three scenarios of interest, and one included for reference 607 o Both parties implement the algorithms described here 609 o Sender implements the algorithm described in section Section 4, 610 recipient does not implement Section 3 612 o Recipient implements the algorithm in section Section 3, sender 613 does not implement Section 4. 615 In the case where both parties implement the algorithms, we expect to 616 see most of the congestion control response to slowly varying 617 conditions happen by TMMBR/REMB messages from recipient to sender. 618 At most times, the sender will send less than the congestion-inducing 619 bandwidth limit C, and when he sends more, congestion will be 620 detected before packets are lost. 622 If sudden changes happen, packets will be lost, and the sender side 623 control will trigger, limiting traffic until the congestion becomes 624 low enough that the system switches back to the receiver-controlled 625 state. 627 In the case where sender only implements, we expect to see somewhat 628 higher loss rates and delays, but the system will still be overall 629 TCP friendly and self-adjusting; the governing term in the 630 calculation will be the TFRC formula. 632 In the case where recipient implements this algorithm and sender does 633 not, congestion will be avoided for slow changes as long as the 634 sender understands and obeys TMMBR/REMB; there will be no backoff for 635 packet-loss-inducing changes in capacity. Given that some kind of 636 congestion control is mandatory for the sender according to the TMMBR 637 spec, this case has to be reevaluated against the specific congestion 638 control implemented by the sender. 640 6. Implementation Experience 642 This algorithm has been implemented in the open-source WebRTC 643 project. 645 7. Further Work 647 This draft is offered as input to the congestion control discussion. 649 Work that can be done on this basis includes: 651 o Consideration of timing info: It may be sensible to use the 652 proposed TFRC RTP header extensions [I-D.gharai-avtcore-rtp-tfrc] 653 to carry per-packet timing information, which would both give more 654 data points and a timestamp applied closer to the network 655 interface. This draft includes consideration of using the 656 transmission time offset defined in [RFC5450] 658 o Considerations of cross-channel calculation: If all packets in 659 multiple streams follow the same path over the network, congestion 660 or queuing information should be considered across all packets 661 between two parties, not just per media stream. A feedback 662 message (REMB) that may be suitable for such a purpose is given in 663 [I-D.alvestrand-rmcat-remb]. 665 o Considerations of cross-channel balancing: The decision to slow 666 down sending in a situation with multiple media streams should be 667 taken across all media streams, not per stream. 669 o Considerations of additional input: How and where packet loss 670 detected at the recipient can be added to the algorithm. 672 o Considerations of locus of control: Whether the sender or the 673 recipient is in the best position to figure out which media 674 streams it makes sense to slow down, and therefore whether one 675 should use TMMBR to slow down one channel, signal an overall 676 bandwidth change and let the sender make the decision, or signal 677 the (possibly processed) delay info and let the sender run the 678 algorithm. 680 o Considerations of over-bandwidth estimation: Whether we can use 681 the estimate of how much we're over bandwidth in section 3 to 682 influence how much we reduce the bandwidth, rather than using a 683 fixed factor. 685 o Startup considerations. It's unreasonable to assume that just 686 starting at full rate is always the best strategy. 688 o Dealing with sender traffic shaping, which delays sending of 689 packets. Using send-time timestamps rather than RTP timestamps 690 may be useful here, but as long as the sender's traffic shaping 691 does not spread out packets more than the bottleneck link, it 692 should not matter. 694 o Stability considerations. It is not clear how to show that the 695 algorithm cannot provide an oscillating state, either alone or 696 when competing with other algorithms / flows. 698 These are matters for further work; since some of them involve 699 extensions that have not yet been standardized, this could take some 700 time. 702 8. IANA Considerations 704 This document makes no request of IANA. 706 Note to RFC Editor: this section may be removed on publication as an 707 RFC. 709 9. Security Considerations 711 An attacker with the ability to insert or remove messages on the 712 connection will, of course, have the ability to mess up rate control, 713 causing people to send either too fast or too slow, and causing 714 congestion. 716 In this case, the control information is carried inside RTP, and can 717 be protected against modification or message insertion using SRTP, 718 just as for the media. Given that timestamps are carried in the RTP 719 header, which is not encrypted, this is not protected against 720 disclosure, but it seems hard to mount an attack based on timing 721 information only. 723 10. Acknowledgements 725 Thanks to Randell Jesup, Magnus Westerlund, Varun Singh, Tim Panton, 726 Soo-Hyun Choo, Jim Gettys, Ingemar Johansson, Michael Welzl and 727 others for providing valuable feedback on earlier versions of this 728 draft. 730 11. References 732 11.1. Normative References 734 [I-D.alvestrand-rmcat-remb] 735 Alvestrand, H., "RTCP message for Receiver Estimated 736 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 737 progress), October 2013. 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, March 1997. 742 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 743 Friendly Rate Control (TFRC): Protocol Specification", RFC 744 3448, January 2003. 746 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 747 Jacobson, "RTP: A Transport Protocol for Real-Time 748 Applications", STD 64, RFC 3550, July 2003. 750 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 751 "Codec Control Messages in the RTP Audio-Visual Profile 752 with Feedback (AVPF)", RFC 5104, February 2008. 754 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 755 RTP Streams", RFC 5450, March 2009. 757 11.2. Informative References 759 [I-D.gharai-avtcore-rtp-tfrc] 760 Gharai, L. and C. Perkins, "RTP with TCP Friendly Rate 761 Control", draft-gharai-avtcore-rtp-tfrc-01 (work in 762 progress), September 2011. 764 [Pv13] De Cicco, L., Carlucci, G., and S. Mascolo, "Understanding 765 the Dynamic Behaviour of the Google Congestion Control", 766 Packet Video Workshop , December 2013. 768 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 769 2914, September 2000. 771 Appendix A. Change log 773 A.1. Version -00 to -01 775 o Added change log 777 o Added appendix outlining new extensions 779 o Added a section on when to send feedback to the end of section 3.3 780 "Rate control", and defined min/max FB intervals. 782 o Added size of over-bandwidth estimate usage to "further work" 783 section. 785 o Added startup considerations to "further work" section. 787 o Added sender-delay considerations to "further work" section. 789 o Filled in acknowledgments section from mailing list discussion. 791 A.2. Version -01 to -02 793 o Defined the term "frame", incorporating the transmission time 794 offset into its definition, and removed references to "video 795 frame". 797 o Referred to "m(i)" from the text to make the derivation clearer. 799 o Made it clearer that we modify our estimates of available 800 bandwidth, and not the true available bandwidth. 802 o Removed the appendixes outlining new extensions, added pointers to 803 REMB draft and RFC 5450. 805 A.3. Version -02 to -03 807 o Added a section on how to process multiple streams in a single 808 estimator using RTP timestamps to NTP time conversion. 810 o Stated in introduction that the draft is aimed at the RMCAT 811 working group. 813 A.4. rtcweb-03 to rmcat-00 815 Renamed draft to link the draft name to the RMCAT WG. 817 A.5. rmcat -00 to -01 819 Spellcheck. Otherwise no changes, this is a "keepalive" release. 821 A.6. rmcat -01 to -02 823 o Added Luca De Cicco and Saverio Mascolo as authors. 825 o Extended the "Over-use detector" section with new technical 826 details on how to dynamically tune the offset gamma_1 for improved 827 fairness properties. 829 o Added a reference to a paper analyzing the behavior of the 830 proposed algorithm. 832 Authors' Addresses 834 Henrik Lundin 835 Google 836 Kungsbron 2 837 Stockholm 11122 838 Sweden 839 Stefan Holmer 840 Google 841 Kungsbron 2 842 Stockholm 11122 843 Sweden 845 Email: holmer@google.com 847 Luca De Cicco 848 Politecnico di Bari 849 Via Orabona, 4 850 Bari 70125 851 Italy 853 Email: l.decicco@poliba.it 855 Saverio Mascolo 856 Politecnico di Bari 857 Via Orabona, 4 858 Bari 70125 859 Italy 861 Email: mascolo@poliba.it 863 Harald Alvestrand (editor) 864 Google 865 Kungsbron 2 866 Stockholm 11122 867 Sweden 869 Email: harald@alvestrand.no