idnits 2.17.1 draft-ietf-rmcat-gcc-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 566 has weird spacing: '... of the syste...' == Line 568 has weird spacing: '...nt used for t...' -- The document date (July 8, 2016) is 2848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '6' on line 412 -- Looks like a reference, but probably isn't: '600' on line 412 == Outdated reference: A later version (-01) exists of draft-holmer-rmcat-transport-wide-cc-extensions-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Holmer 3 Internet-Draft H. Lundin 4 Intended status: Informational Google 5 Expires: January 9, 2017 G. Carlucci 6 L. De Cicco 7 S. Mascolo 8 Politecnico di Bari 9 July 8, 2016 11 A Google Congestion Control Algorithm for Real-Time Communication 12 draft-ietf-rmcat-gcc-02 14 Abstract 16 This document describes two methods of congestion control when using 17 real-time communications on the World Wide Web (RTCWEB); one delay- 18 based and one loss-based. 20 It is published as an input document to the RMCAT working group on 21 congestion control for media streams. The mailing list of that 22 working group is rmcat@ietf.org. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 9, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Mathematical notation conventions . . . . . . . . . . . . 3 66 2. System model . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Feedback and extensions . . . . . . . . . . . . . . . . . . . 4 68 4. Sending Engine . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Delay-based control . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. Arrival-time model . . . . . . . . . . . . . . . . . . . 6 71 5.2. Pre-filtering . . . . . . . . . . . . . . . . . . . . . . 7 72 5.3. Arrival-time filter . . . . . . . . . . . . . . . . . . . 7 73 5.4. Over-use detector . . . . . . . . . . . . . . . . . . . . 8 74 5.5. Rate control . . . . . . . . . . . . . . . . . . . . . . 10 75 5.6. Parameters settings . . . . . . . . . . . . . . . . . . . 12 76 6. Loss-based control . . . . . . . . . . . . . . . . . . . . . 13 77 7. Interoperability Considerations . . . . . . . . . . . . . . . 14 78 8. Implementation Experience . . . . . . . . . . . . . . . . . . 14 79 9. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 13.2. Informative References . . . . . . . . . . . . . . . . . 16 86 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 87 A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 16 88 A.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 17 89 A.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 17 90 A.4. rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . . 17 91 A.5. rmcat -00 to -01 . . . . . . . . . . . . . . . . . . . . 17 92 A.6. rmcat -01 to -02 . . . . . . . . . . . . . . . . . . . . 17 93 A.7. rmcat -02 to -03 . . . . . . . . . . . . . . . . . . . . 18 94 A.8. ietf-rmcat -00 to ietf-rmcat -01 . . . . . . . . . . . . 18 95 A.9. ietf-rmcat -01 to ietf-rmcat -02 . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 98 1. Introduction 100 Congestion control is a requirement for all applications sharing the 101 Internet resources [RFC2914]. 103 Congestion control for real-time media is challenging for a number of 104 reasons: 106 o The media is usually encoded in forms that cannot be quickly 107 changed to accommodate varying bandwidth, and bandwidth 108 requirements can often be changed only in discrete, rather large 109 steps 111 o The participants may have certain specific wishes on how to 112 respond - which may not be reducing the bandwidth required by the 113 flow on which congestion is discovered 115 o The encodings are usually sensitive to packet loss, while the 116 real-time requirement precludes the repair of packet loss by 117 retransmission 119 This memo describes two congestion control algorithms that together 120 are able to provide good performance and reasonable bandwidth sharing 121 with other video flows using the same congestion control and with TCP 122 flows that share the same links. 124 The signaling used consists of experimental RTP header extensions and 125 RTCP messages RFC 3550 [RFC3550] as defined in [abs-send-time], 126 [I-D.alvestrand-rmcat-remb] and 127 [I-D.holmer-rmcat-transport-wide-cc-extensions]. 129 1.1. Mathematical notation conventions 131 The mathematics of this document have been transcribed from a more 132 formula-friendly format. 134 The following notational conventions are used: 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 vector X - conventionally marked by a 140 subscript i. 142 E{X} The expected value of the stochastic variable X 144 2. System model 146 The following elements are in the system: 148 o RTP packet - an RTP packet containing media data. 150 o Group of packets - a set of RTP packets transmitted from the 151 sender uniquely identified by the group departure and group 152 arrival time (absolute send time) [abs-send-time]. These could be 153 video packets, audio packets, or a mix of audio and video packets. 155 o Incoming media stream - a stream of frames consisting of RTP 156 packets. 158 o RTP sender - sends the RTP stream over the network to the RTP 159 receiver. It generates the RTP timestamp and the abs-send-time 160 header extension 162 o RTP receiver - receives the RTP stream, marks the time of arrival. 164 o RTCP sender at RTP receiver - sends receiver reports, REMB 165 messages and transport-wide RTCP feedback messages. 167 o RTCP receiver at RTP sender - receives receiver reports and REMB 168 messages and transport-wide RTCP feedback messages, reports these 169 to the sender side controller. 171 o RTCP receiver at RTP receiver, receives sender reports from the 172 sender. 174 o Loss-based controller - takes loss rate measurement, round trip 175 time measurement and REMB messages, and computes a target sending 176 bitrate. 178 o Delay-based controller - takes the packet arrival info, either at 179 the RTP receiver, or from the feedback received by the RTP sender, 180 and computes a maximum bitrate which it passes to the loss-based 181 controller. 183 Together, loss-based controller and delay-based controller implement 184 the congestion control algorithm. 186 3. Feedback and extensions 188 There are two ways to implement the proposed algorithm. One where 189 both the controllers are running at the send-side, and one where the 190 delay-based controller runs on the receive-side and the loss-based 191 controller runs on the send-side. 193 The first version can be realized by using a per-packet feedback 194 protocol as described in 195 [I-D.holmer-rmcat-transport-wide-cc-extensions]. Here, the RTP 196 receiver will record the arrival time and the transport-wide sequence 197 number of each received packet, which will be sent back to the sender 198 periodically using the transport-wide feedback message. The 199 RECOMMENDED feedback interval is once per received video frame or at 200 least once every 30 ms if audio-only or multi-stream. If the 201 feedback overhead needs to be limited this interval can be increased 202 to 100 ms. 204 The sender will map the received {sequence number, arrival time} 205 pairs to the send-time of each packet covered by the feedback report, 206 and feed those timestamps to the delay-based controller. It will 207 also compute a loss ratio based on the sequence numbers in the 208 feedback message. 210 The second version can be realized by having a delay-based controller 211 at the receive-side, monitoring and processing the arrival time and 212 size of incoming packets. The sender SHOULD use the abs-send-time 213 RTP header extension [abs-send-time] to enable the receiver to 214 compute the inter-group delay variation. The output from the delay- 215 based controller will be a bitrate, which will be sent back to the 216 sender using the REMB feedback message [I-D.alvestrand-rmcat-remb]. 217 The packet loss ratio is sent back via RTCP receiver reports. At the 218 sender the bitrate in the REMB message and the fraction of packets 219 lost are fed into the loss-based controller, which outputs a final 220 target bitrate. It is RECOMMENDED to send the REMB message as soon 221 as congestion is detected, and otherwise at least once every second. 223 4. Sending Engine 225 Pacing is used to actuate the target bitrate computed by the 226 controllers. 228 When media encoder produces data, this is fed into a Pacer queue. 229 The Pacer sends a group of packets to the network every burst_time 230 interval. RECOMMENDED value for burst_time is 5 ms. The size of a 231 group of packets is computed as the product between the target 232 bitrate and the burst_time. 234 5. Delay-based control 236 The delay-based control algorithm can be further decomposed into four 237 parts: a pre-filtering, an arrival-time filter, an over-use detector, 238 and a rate controller. 240 5.1. Arrival-time model 242 This section describes an adaptive filter that continuously updates 243 estimates of network parameters based on the timing of the received 244 groups of packets. 246 We define the inter-arrival time, t(i) - t(i-1), as the difference in 247 arrival time of two groups of packets. Correspondingly, the inter- 248 departure time, T(i) - T(i-1), is defined as the difference in 249 departure-time of two groups of packets. Finally, the inter-group 250 delay variation, d(i), is defined as the difference between the 251 inter-arrival time and the inter-departure time. Or interpreted 252 differently, as the difference between the delay of group i and group 253 i-1. 255 d(i) = t(i) - t(i-1) - (T(i) - T(i-1)) 257 An inter-departure time is computed between consecutive groups as 258 T(i) - T(i-1), where T(i) is the departure timestamp of the last 259 packet in the current packet group being processed. Any packets 260 received out of order are ignored by the arrival-time model. 262 Each group is assigned a receive time t(i), which corresponds to the 263 time at which the last packet of the group was received. A group is 264 delayed relative to its predecessor if t(i) - t(i-1) > T(i) - T(i-1), 265 i.e., if the inter-arrival time is larger than the inter-departure 266 time. 268 We can model the inter-group delay variation as: 270 d(i) = w(i) 272 Here, w(i) is a sample from a stochastic process W, which is a 273 function of the link capacity, the current cross traffic, and the 274 current sent bitrate. We model W as a white Gaussian process. If we 275 are over-using the channel we expect the mean of w(i) to increase, 276 and if a queue on the network path is being emptied, the mean of w(i) 277 will decrease; otherwise the mean of w(i) will be zero. 279 Breaking out the mean, m(i), from w(i) to make the process zero mean, 280 we get 282 Equation 1 284 d(i) = m(i) + v(i) 286 The noise term v(i) represents network jitter and other delay effects 287 not captured by the model. 289 5.2. Pre-filtering 291 The pre-filtering aims at handling delay transients caused by channel 292 outages. During an outage, packets being queued in network buffers, 293 for reasons unrelated to congestion, are delivered in a burst when 294 the outage ends. 296 The pre-filtering merges together groups of packets that arrive in a 297 burst. Packets are merged in the same group if one of these two 298 conditions holds: 300 o A sequence of packets which are sent within a burst_time interval 301 constitute a group. 303 o A Packet which has an inter-arrival time less than burst_time and 304 an inter-group delay variation d(i) less than 0 is considered 305 being part of the current group of packets. 307 5.3. Arrival-time filter 309 The parameter d(i) is readily available for each group of packets, i 310 > 1. We want to estimate m(i) and use this estimate to detect 311 whether or not the bottleneck link is over-used. The parameter can 312 be estimated by any adaptive filter - we are using the Kalman filter. 314 Let m(i) be the estimate at time i 316 We model the state evolution from time i to time i+1 as 318 m(i+1) = m(i) + u(i) 320 where u(i) is the state noise that we model as a stationary process 321 with Gaussian statistic with zero mean and variance 323 q(i) = E{u(i)^2} 325 q(i) is RECOMMENDED equal to 10^-3 327 Given equation 1 we get 329 d(i) = m(i) + v(i) 331 where v(i) is zero mean white Gaussian measurement noise with 332 variance var_v = E{v(i)^2} 334 The Kalman filter recursively updates our estimate m_hat(i) as 335 z(i) = d(i) - m_hat(i-1) 337 m_hat(i) = m_hat(i-1) + z(i) * k(i) 339 e(i-1) + q(i) 340 k(i) = ---------------------------------------- 341 var_v_hat(i) + (e(i-1) + q(i)) 343 e(i) = (1 - k(i)) * (e(i-1) + q(i)) 345 The variance var_v(i) = E{v(i)^2} is estimated using an exponential 346 averaging filter, modified for variable sampling rate 348 var_v_hat(i) = max(alpha * var_v_hat(i-1) + (1-alpha) * z(i)^2, 1) 350 alpha = (1-chi)^(30/(1000 * f_max)) 352 where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1,...,i is the 353 highest rate at which the last K packet groups have been received and 354 chi is a filter coefficient typically chosen as a number in the 355 interval [0.1, 0.001]. Since our assumption that v(i) should be zero 356 mean WGN is less accurate in some cases, we have introduced an 357 additional outlier filter around the updates of var_v_hat. If z(i) > 358 3*sqrt(var_v_hat) the filter is updated with 3*sqrt(var_v_hat) rather 359 than z(i). For instance v(i) will not be white in situations where 360 packets are sent at a higher rate than the channel capacity, in which 361 case they will be queued behind each other. 363 5.4. Over-use detector 365 The inter-group delay variation estimate m(i), obtained as the output 366 of the arrival-time filter, is compared with a threshold 367 del_var_th(i). An estimate above the threshold is considered as an 368 indication of over-use. Such an indication is not enough for the 369 detector to signal over-use to the rate control subsystem. A 370 definitive over-use will be signaled only if over-use has been 371 detected for at least overuse_time_th milliseconds. However, if m(i) 372 < m(i-1), over-use will not be signaled even if all the above 373 conditions are met. Similarly, the opposite state, under-use, is 374 detected when m(i) < -del_var_th(i). If neither over-use nor under- 375 use is detected, the detector will be in the normal state. 377 The threshold del_var_th has a remarkable impact on the overall 378 dynamics and performance of the algorithm. In particular, it has 379 been shown that using a static threshold del_var_th, a flow 380 controlled by the proposed algorithm can be starved by a concurrent 381 TCP flow [Pv13]. This starvation can be avoided by increasing the 382 threshold del_var_th to a sufficiently large value. 384 The reason is that, by using a larger value of del_var_th, a larger 385 queuing delay can be tolerated, whereas with a small del_var_th, the 386 over-use detector quickly reacts to a small increase in the offset 387 estimate m(i) by generating an over-use signal that reduces the 388 delay-based estimate of the available bandwidth A_hat (see 389 Section 4.4). Thus, it is necessary to dynamically tune the 390 threshold del_var_th to get good performance in the most common 391 scenarios, such as when competing with loss-based flows. 393 For this reason, we propose to vary the threshold del_var_th(i) 394 according to the following dynamic equation: 396 del_var_th(i) = 397 del_var_th(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-del_var_th(i-1)) 399 with K(i)=K_d if |m(i)| < del_var_th(i-1) or K(i)=K_u otherwise. The 400 rationale is to increase del_var_th(i) when m(i) is outside of the 401 range [-del_var_th(i-1),del_var_th(i-1)], whereas, when the offset 402 estimate m(i) falls back into the range, del_var_th is decreased. In 403 this way when m(i) increases, for instance due to a TCP flow entering 404 the same bottleneck, del_var_th(i) increases and avoids the 405 uncontrolled generation of over-use signals which may lead to 406 starvation of the flow controlled by the proposed algorithm [Pv13]. 407 Moreover, del_var_th(i) SHOULD NOT be updated if this condition 408 holds: 410 |m(i)| - del_var_th(i) > 15 412 It is also RECOMMENDED to clamp del_var_th(i) to the range [6, 600], 413 since a too small del_var_th(i) can cause the detector to become 414 overly sensitive. 416 On the other hand, when m(i) falls back into the range 417 [-del_var_th(i-1),del_var_th(i-1)] the threshold del_var_th(i) is 418 decreased so that a lower queuing delay can be achieved. 420 It is RECOMMENDED to choose K_u > K_d so that the rate at which 421 del_var_th is increased is higher than the rate at which it is 422 decreased. With this setting it is possible to increase the 423 threshold in the case of a concurrent TCP flow and prevent starvation 424 as well as enforcing intra-protocol fairness. RECOMMENDED values for 425 del_var_th(0), overuse_time_th, K_u and K_d are respectively 12.5 ms, 426 10 ms, 0.01 and 0.00018. 428 5.5. Rate control 430 The rate control is split in two parts, one controlling the bandwidth 431 estimate based on delay, and one controlling the bandwidth estimate 432 based on loss. Both are designed to increase the estimate of the 433 available bandwidth A_hat as long as there is no detected congestion 434 and to ensure that we will eventually match the available bandwidth 435 of the channel and detect an over-use. 437 As soon as over-use has been detected, the available bandwidth 438 estimated by the delay-based controller is decreased. In this way we 439 get a recursive and adaptive estimate of the available bandwidth. 441 In this document we make the assumption that the rate control 442 subsystem is executed periodically and that this period is constant. 444 The rate control subsystem has 3 states: Increase, Decrease and Hold. 445 "Increase" is the state when no congestion is detected; "Decrease" is 446 the state where congestion is detected, and "Hold" is a state that 447 waits until built-up queues have drained before going to "increase" 448 state. 450 The state transitions (with blank fields meaning "remain in state") 451 are: 453 +----+--------+-----------+------------+--------+ 454 | \ State | Hold | Increase |Decrease| 455 | \ | | | | 456 | Signal\ | | | | 457 +--------+----+-----------+------------+--------+ 458 | Over-use | Decrease | Decrease | | 459 +-------------+-----------+------------+--------+ 460 | Normal | Increase | | Hold | 461 +-------------+-----------+------------+--------+ 462 | Under-use | | Hold | Hold | 463 +-------------+-----------+------------+--------+ 465 The subsystem starts in the increase state, where it will stay until 466 over-use or under-use has been detected by the detector subsystem. 467 On every update the delay-based estimate of the available bandwidth 468 is increased, either multiplicatively or additively, depending on its 469 current state. 471 The system does a multiplicative increase if the current bandwidth 472 estimate appears to be far from convergence, while it does an 473 additive increase if it appears to be closer to convergence. We 474 assume that we are close to convergence if the currently incoming 475 bitrate, R_hat(i), is close to an average of the incoming bitrates at 476 the time when we previously have been in the Decrease state. "Close" 477 is defined as three standard deviations around this average. It is 478 RECOMMENDED to measure this average and standard deviation with an 479 exponential moving average with the smoothing factor 0.95, as it is 480 expected that this average covers multiple occasions at which we are 481 in the Decrease state. Whenever valid estimates of these statistics 482 are not available, we assume that we have not yet come close to 483 convergence and therefore remain in the multiplicative increase 484 state. 486 If R_hat(i) increases above three standard deviations of the average 487 max bitrate, we assume that the current congestion level has changed, 488 at which point we reset the average max bitrate and go back to the 489 multiplicative increase state. 491 R_hat(i) is the incoming bitrate measured by the delay-based 492 controller over a T seconds window: 494 R_hat(i) = 1/T * sum(L(j)) for j from 1 to N(i) 496 N(i) is the number of packets received the past T seconds and L(j) is 497 the payload size of packet j. A window between 0.5 and 1 second is 498 RECOMMENDED. 500 During multiplicative increase, the estimate is increased by at most 501 8% per second. 503 eta = 1.08^min(time_since_last_update_ms / 1000, 1.0) 504 A_hat(i) = eta * A_hat(i-1) 506 During the additive increase the estimate is increased with at most 507 half a packet per response_time interval. The response_time interval 508 is estimated as the round-trip time plus 100 ms as an estimate of 509 over-use estimator and detector reaction time. 511 response_time_ms = 100 + rtt_ms 512 alpha = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0) 513 A_hat(i) = A_hat(i-1) + max(1000, alpha * expected_packet_size_bits) 515 expected_packet_size_bits is used to get a slightly slower slope for 516 the additive increase at lower bitrates. It can for instance be 517 computed from the current bitrate by assuming a frame rate of 30 518 frames per second: 520 bits_per_frame = A_hat(i-1) / 30 521 packets_per_frame = ceil(bits_per_frame / (1200 * 8)) 522 avg_packet_size_bits = bits_per_frame / packets_per_frame 524 Since the system depends on over-using the channel to verify the 525 current available bandwidth estimate, we must make sure that our 526 estimate does not diverge from the rate at which the sender is 527 actually sending. Thus, if the sender is unable to produce a bit 528 stream with the bitrate the congestion controller is asking for, the 529 available bandwidth estimate should stay within a given bound. 530 Therefore we introduce a threshold 532 A_hat(i) < 1.5 * R_hat(i) 534 When an over-use is detected the system transitions to the decrease 535 state, where the delay-based available bandwidth estimate is 536 decreased to a factor times the currently incoming bitrate. 538 A_hat(i) = beta * R_hat(i) 540 beta is typically chosen to be in the interval [0.8, 0.95], 0.85 is 541 the RECOMMENDED value. 543 When the detector signals under-use to the rate control subsystem, we 544 know that queues in the network path are being emptied, indicating 545 that our available bandwidth estimate A_hat is lower than the actual 546 available bandwidth. Upon that signal the rate control subsystem 547 will enter the hold state, where the receive-side available bandwidth 548 estimate will be held constant while waiting for the queues to 549 stabilize at a lower level - a way of keeping the delay as low as 550 possible. This decrease of delay is wanted, and expected, 551 immediately after the estimate has been reduced due to over-use, but 552 can also happen if the cross traffic over some links is reduced. 554 It is RECOMMENDED that the routine to update A_hat(i) is run at least 555 once every response_time interval. 557 5.6. Parameters settings 558 +-----------------+-----------------------------------+-------------+ 559 | Parameter | Description | RECOMMENDED | 560 | | | Value | 561 +-----------------+-----------------------------------+-------------+ 562 | burst_time | Time limit in milliseconds | 5 ms | 563 | | between packet bursts which | | 564 | | identifies a group | | 565 | q | State noise covariance matrix | q = 10^-3 | 566 | e(0) | Initial value of the system | e(0) = 0.1 | 567 | | error covariance | | 568 | chi | Coefficient used for the | [0.1, | 569 | | measured noise variance | 0.001] | 570 | del_var_th(0) | Initial value for the adaptive | 12.5 ms | 571 | | threshold | | 572 | overuse_time_th | Time required to trigger an | 10 ms | 573 | | overuse signal | | 574 | K_u | Coefficient for the adaptive | 0.01 | 575 | | threshold | | 576 | K_d | Coefficient for the adaptive | 0.00018 | 577 | | threshold | | 578 | T | Time window for measuring the | [0.5, 1] s | 579 | | received bitrate | | 580 | beta | Decrease rate factor | 0.85 | 581 +-----------------+-----------------------------------+-------------+ 583 Table 1: RECOMMENDED values for delay based controller 585 Table 1 587 6. Loss-based control 589 A second part of the congestion controller bases its decisions on the 590 round-trip time, packet loss and available bandwidth estimates A_hat 591 received from the delay-based controller. The available bandwidth 592 estimates computed by the loss-based controller are denoted with 593 As_hat. 595 The available bandwidth estimates A_hat produced by the delay-based 596 controller are only reliable when the size of the queues along the 597 path sufficiently large. If the queues are very short, over-use will 598 only be visible through packet losses, which are not used by the 599 delay-based controller. 601 The loss-based controller SHOULD run every time feedback from the 602 receiver is received. 604 o If 2-10% of the packets have been lost since the previous report 605 from the receiver, the sender available bandwidth estimate 606 As_hat(i) will be kept unchanged. 608 o If more than 10% of the packets have been lost a new estimate is 609 calculated as As_hat(i) = As_hat(i-1)(1-0.5p), where p is the loss 610 ratio. 612 o As long as less than 2% of the packets have been lost As_hat(i) 613 will be increased as As_hat(i) = 1.05(As_hat(i-1)) 615 The loss-based estimate As_hat is compared with the delay-based 616 estimate A_hat. The actual sending rate is set as the minimum 617 between As_hat and A_hat. 619 We motivate the packet loss thresholds by noting that if the 620 transmission channel has a small amount of packet loss due to over- 621 use, that amount will soon increase if the sender does not adjust his 622 bitrate. Therefore we will soon enough reach above the 10% threshold 623 and adjust As_hat(i). However, if the packet loss ratio does not 624 increase, the losses are probably not related to self-inflicted 625 congestion and therefore we should not react on them. 627 7. Interoperability Considerations 629 In case a sender implementing these algorithms talks to a receiver 630 which do not implement any of the proposed RTCP messages and RTP 631 header extensions, it is suggested that the sender monitors RTCP 632 receiver reports and uses the fraction of lost packets and the round- 633 trip time as input to the loss-based controller. The delay-based 634 controller should be left disabled. 636 8. Implementation Experience 638 This algorithm has been implemented in the open-source WebRTC 639 project, has been in use in Chrome since M23, and is being used by 640 Google Hangouts. 642 Deployment of the algorithm have revealed problems related to, e.g, 643 congested or otherwise problematic WiFi networks, which have led to 644 algorithm improvements. The algorithm has also been tested in a 645 multi-party conference scenario with a conference server which 646 terminates the congestion control between endpoints. This ensures 647 that no assumptions are being made by the congestion control about 648 maximum send and receive bitrates, etc., which typically is out of 649 control for a conference server. 651 9. Further Work 653 This draft is offered as input to the congestion control discussion. 655 Work that can be done on this basis includes: 657 o Considerations of integrated loss control: How loss and delay 658 control can be better integrated, and the loss control improved. 660 o Considerations of locus of control: evaluate the performance of 661 having all congestion control logic at the sender, compared to 662 splitting logic between sender and receiver. 664 o Considerations of utilizing ECN as a signal for congestion 665 estimation and link over-use detection. 667 10. IANA Considerations 669 This document makes no request of IANA. 671 Note to RFC Editor: this section may be removed on publication as an 672 RFC. 674 11. Security Considerations 676 An attacker with the ability to insert or remove messages on the 677 connection would have the ability to disrupt rate control. This 678 could make the algorithm to produce either a sending rate under- 679 utilizing the bottleneck link capacity, or a too high sending rate 680 causing network congestion. 682 In this case, the control information is carried inside RTP, and can 683 be protected against modification or message insertion using SRTP, 684 just as for the media. Given that timestamps are carried in the RTP 685 header, which is not encrypted, this is not protected against 686 disclosure, but it seems hard to mount an attack based on timing 687 information only. 689 12. Acknowledgements 691 Thanks to Randell Jesup, Magnus Westerlund, Varun Singh, Tim Panton, 692 Soo-Hyun Choo, Jim Gettys, Ingemar Johansson, Michael Welzl and 693 others for providing valuable feedback on earlier versions of this 694 draft. 696 13. References 698 13.1. Normative References 700 [I-D.alvestrand-rmcat-remb] 701 Alvestrand, H., "RTCP message for Receiver Estimated 702 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 703 progress), October 2013. 705 [I-D.holmer-rmcat-transport-wide-cc-extensions] 706 Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions 707 for Transport-wide Congestion Control", draft-holmer- 708 rmcat-transport-wide-cc-extensions-00 (work in progress), 709 March 2015. 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 715 Jacobson, "RTP: A Transport Protocol for Real-Time 716 Applications", STD 64, RFC 3550, July 2003. 718 [abs-send-time] 719 "RTP Header Extension for Absolute Sender Time", 720 . 723 13.2. Informative References 725 [Pv13] De Cicco, L., Carlucci, G., and S. Mascolo, "Understanding 726 the Dynamic Behaviour of the Google Congestion Control", 727 Packet Video Workshop , December 2013. 729 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 730 2914, September 2000. 732 Appendix A. Change log 734 A.1. Version -00 to -01 736 o Added change log 738 o Added appendix outlining new extensions 740 o Added a section on when to send feedback to the end of section 3.3 741 "Rate control", and defined min/max FB intervals. 743 o Added size of over-bandwidth estimate usage to "further work" 744 section. 746 o Added startup considerations to "further work" section. 748 o Added sender-delay considerations to "further work" section. 750 o Filled in acknowledgments section from mailing list discussion. 752 A.2. Version -01 to -02 754 o Defined the term "frame", incorporating the transmission time 755 offset into its definition, and removed references to "video 756 frame". 758 o Referred to "m(i)" from the text to make the derivation clearer. 760 o Made it clearer that we modify our estimates of available 761 bandwidth, and not the true available bandwidth. 763 o Removed the appendixes outlining new extensions, added pointers to 764 REMB draft and RFC 5450. 766 A.3. Version -02 to -03 768 o Added a section on how to process multiple streams in a single 769 estimator using RTP timestamps to NTP time conversion. 771 o Stated in introduction that the draft is aimed at the RMCAT 772 working group. 774 A.4. rtcweb-03 to rmcat-00 776 Renamed draft to link the draft name to the RMCAT WG. 778 A.5. rmcat -00 to -01 780 Spellcheck. Otherwise no changes, this is a "keepalive" release. 782 A.6. rmcat -01 to -02 784 o Added Luca De Cicco and Saverio Mascolo as authors. 786 o Extended the "Over-use detector" section with new technical 787 details on how to dynamically tune the offset del_var_th for 788 improved fairness properties. 790 o Added reference to a paper analyzing the behavior of the proposed 791 algorithm. 793 A.7. rmcat -02 to -03 795 o Swapped receiver-side/sender-side controller with delay-based/ 796 loss-based controller as there is no longer a requirement to run 797 the delay-based controller on the receiver-side. 799 o Removed the discussion about multiple streams and transmission 800 time offsets. 802 o Introduced a new section about "Feedback and extensions". 804 o Improvements to the threshold adaptation in the "Over-use 805 detector" section. 807 o Swapped the previous MIMD rate control algorithm for a new AIMD 808 rate control algorithm. 810 A.8. ietf-rmcat -00 to ietf-rmcat -01 812 o Arrival-time filter converted from a two dimensional Kalman filter 813 to a scalar Kalman filter. 815 o The use of the TFRC equation was removed from the loss-based 816 controller, as it turned out to have little to no effect in 817 practice. 819 A.9. ietf-rmcat -01 to ietf-rmcat -02 821 o Added a section which better describes the pre-filtering 822 algorithm. 824 Authors' Addresses 826 Stefan Holmer 827 Google 828 Kungsbron 2 829 Stockholm 11122 830 Sweden 832 Email: holmer@google.com 833 Henrik Lundin 834 Google 835 Kungsbron 2 836 Stockholm 11122 837 Sweden 839 Email: hlundin@google.com 841 Gaetano Carlucci 842 Politecnico di Bari 843 Via Orabona, 4 844 Bari 70125 845 Italy 847 Email: gaetano.carlucci@poliba.it 849 Luca De Cicco 850 Politecnico di Bari 851 Via Orabona, 4 852 Bari 70125 853 Italy 855 Email: l.decicco@poliba.it 857 Saverio Mascolo 858 Politecnico di Bari 859 Via Orabona, 4 860 Bari 70125 861 Italy 863 Email: mascolo@poliba.it