idnits 2.17.1 draft-ietf-rmcat-gcc-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 : ---------------------------------------------------------------------------- ** 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 550 has weird spacing: '... of the syste...' == Line 552 has weird spacing: '...nt used for t...' -- The document date (October 19, 2015) is 3112 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '6' on line 395 -- Looks like a reference, but probably isn't: '600' on line 395 == 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: April 21, 2016 G. Carlucci 6 L. De Cicco 7 S. Mascolo 8 Politecnico di Bari 9 October 19, 2015 11 A Google Congestion Control Algorithm for Real-Time Communication 12 draft-ietf-rmcat-gcc-01 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 April 21, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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. Delay-based control . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Arrival-time model . . . . . . . . . . . . . . . . . . . 5 70 4.2. Arrival-time filter . . . . . . . . . . . . . . . . . . . 7 71 4.3. Over-use detector . . . . . . . . . . . . . . . . . . . . 8 72 4.4. Rate control . . . . . . . . . . . . . . . . . . . . . . 9 73 4.5. Parameters settings . . . . . . . . . . . . . . . . . . . 12 74 5. Loss-based control . . . . . . . . . . . . . . . . . . . . . 13 75 6. Interoperability Considerations . . . . . . . . . . . . . . . 13 76 7. Implementation Experience . . . . . . . . . . . . . . . . . . 14 77 8. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 12.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 85 A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 16 86 A.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 16 87 A.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 16 88 A.4. rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . . 16 89 A.5. rmcat -00 to -01 . . . . . . . . . . . . . . . . . . . . 17 90 A.6. rmcat -01 to -02 . . . . . . . . . . . . . . . . . . . . 17 91 A.7. rmcat -02 to -03 . . . . . . . . . . . . . . . . . . . . 17 92 A.8. ietf-rmcat -00 to ietf-rmcat -01 . . . . . . . . . . . . 17 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 97 Congestion control is a requirement for all applications sharing the 98 Internet resources [RFC2914]. 100 Congestion control for real-time media is challenging for a number of 101 reasons: 103 o The media is usually encoded in forms that cannot be quickly 104 changed to accommodate varying bandwidth, and bandwidth 105 requirements can often be changed only in discrete, rather large 106 steps 108 o The participants may have certain specific wishes on how to 109 respond - which may not be reducing the bandwidth required by the 110 flow on which congestion is discovered 112 o The encodings are usually sensitive to packet loss, while the 113 real-time requirement precludes the repair of packet loss by 114 retransmission 116 This memo describes two congestion control algorithms that together 117 are able to provide good performance and reasonable bandwidth sharing 118 with other video flows using the same congestion control and with TCP 119 flows that share the same links. 121 The signaling used consists of experimental RTP header extensions and 122 RTCP messages RFC 3550 [RFC3550] as defined in [abs-send-time], 123 [I-D.alvestrand-rmcat-remb] and 124 [I-D.holmer-rmcat-transport-wide-cc-extensions]. 126 1.1. Mathematical 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_hat An estimate of the true value of variable X - conventionally 134 marked by a circumflex accent on top of the variable name. 136 X(i) The "i"th value of vector X - conventionally marked by a 137 subscript i. 139 E{X} The expected value of the stochastic variable X 141 2. System model 143 The following elements are in the system: 145 o RTP packet - an RTP packet containing media data. 147 o Packet group - a set of RTP packets transmitted from the sender 148 uniquely identified by the group departure and group arrival time 149 (absolute send time) [abs-send-time]. These could be video 150 packets, audio packets, or a mix of audio and video packets. 152 o Incoming media stream - a stream of frames consisting of RTP 153 packets. 155 o RTP sender - sends the RTP stream over the network to the RTP 156 receiver. It generates the RTP timestamp and the abs-send-time 157 header extension 159 o RTP receiver - receives the RTP stream, marks the time of arrival. 161 o RTCP sender at RTP receiver - sends receiver reports, REMB 162 messages and transport-wide RTCP feedback messages. 164 o RTCP receiver at RTP sender - receives receiver reports and REMB 165 messages and transport-wide RTCP feedback messages, reports these 166 to the sender side controller. 168 o RTCP receiver at RTP receiver, receives sender reports from the 169 sender. 171 o Loss-based controller - takes loss rate measurement, round trip 172 time measurement and REMB messages, and computes a target sending 173 bitrate. 175 o Delay-based controller - takes the packet arrival info, either at 176 the RTP receiver, or from the feedback received by the RTP sender, 177 and computes a maximum bitrate which it passes to the loss-based 178 controller. 180 Together, loss-based controller and delay-based controller implement 181 the congestion control algorithm. 183 3. Feedback and extensions 185 There are two ways to implement the proposed algorithm. One where 186 both the controllers are running at the send-side, and one where the 187 delay-based controller runs on the receive-side and the loss-based 188 controller runs on the send-side. 190 The first version can be realized by using a per-packet feedback 191 protocol as described in 192 [I-D.holmer-rmcat-transport-wide-cc-extensions]. Here, the RTP 193 receiver will record the arrival time and the transport-wide sequence 194 number of each received packet, which will be sent back to the sender 195 periodically using the transport-wide feedback message. The 196 RECOMMENDED feedback interval is once per received video frame or at 197 least once every 30 ms if audio-only or multi-stream. If the 198 feedback overhead needs to be limited this interval can be increased 199 to 100 ms. 201 The sender will map the received {sequence number, arrival time} 202 pairs to the send-time of each packet covered by the feedback report, 203 and feed those timestamps to the delay-based controller. It will 204 also compute a loss ratio based on the sequence numbers in the 205 feedback message. 207 The second version can be realized by having a delay-based controller 208 at the receive-side, monitoring and processing the arrival time and 209 size of incoming packets. The sender SHOULD use the abs-send-time 210 RTP header extension [abs-send-time] to enable the receiver to 211 compute the inter-group delay variation. The output from the delay- 212 based controller will be a bitrate, which will be sent back to the 213 sender using the REMB feedback message [I-D.alvestrand-rmcat-remb]. 214 The packet loss ratio is sent back via RTCP receiver reports. At the 215 sender the bitrate in the REMB message and the fraction of packets 216 lost are fed into the loss-based controller, which outputs a final 217 target bitrate. It is RECOMMENDED to send the REMB message as soon 218 as congestion is detected, and otherwise at least once every second. 220 4. Delay-based control 222 The delay-based control algorithm can be further decomposed into 223 three parts: an arrival-time filter, an over-use detector, and a rate 224 controller. 226 4.1. Arrival-time model 228 This section describes an adaptive filter that continuously updates 229 estimates of network parameters based on the timing of the received 230 packets. 232 We define the inter-arrival time, t(i) - t(i-1), as the difference in 233 arrival time of two packets or two groups of packets. 234 Correspondingly, the inter-departure time, T(i) - T(i-1), is defined 235 as the difference in departure-time of two packets or two groups of 236 packets. Finally, the inter-group delay variation, d(i), is defined 237 as the difference between the inter-arrival time and the inter- 238 departure time. Or interpreted differently, as the difference 239 between the delay of group i and group i-1. 241 d(i) = t(i) - t(i-1) - (T(i) - T(i-1)) 243 At the receiving side we are observing groups of incoming packets, 244 where a group of packets is defined as follows: 246 o A sequence of packets which are sent within a burst_time interval 247 constitute a group. RECOMMENDED value for burst_time is 5 ms. 249 o In addition, any packet which has an inter-arrival time less than 250 burst_time and an inter-group delay variation d(i) less than 0 is 251 also considered being part of the current group of packets. The 252 reasoning behind including these packets in the group is to better 253 handle delay transients, caused by packets being queued up for 254 reasons unrelated to congestion. As an example this has been 255 observed to happen on many Wi-Fi and wireless networks. 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 4.2. Arrival-time filter 291 The parameter d(i) is readily available for each group of packets, i 292 > 1. We want to estimate m(i) and use this estimate to detect 293 whether or not the bottleneck link is over-used. The parameter can 294 be estimated by any adaptive filter - we are using the Kalman filter. 296 Let m(i) be the estimate at time i 298 We model the state evolution from time i to time i+1 as 300 m(i+1) = m(i) + u(i) 302 where u(i) is the state noise that we model as a stationary process 303 with Gaussian statistic with zero mean and variance 305 q(i) = E{u(i)^2} 307 q(i) is RECOMMENDED equal to 10^-3 309 Given equation 1 we get 311 d(i) = m(i) + v(i) 313 where v(i) is zero mean white Gaussian measurement noise with 314 variance var_v = E{v(i)^2} 316 The Kalman filter recursively updates our estimate m_hat(i) as 318 z(i) = d(i) - m_hat(i-1) 320 m_hat(i) = m_hat(i-1) + z(i) * k(i) 322 e(i-1) + q(i) 323 k(i) = ---------------------------------------- 324 var_v_hat(i) + (e(i-1) + q(i)) 326 e(i) = (1 - k(i)) * (e(i-1) + q(i)) 328 The variance var_v(i) = E{v(i)^2} is estimated using an exponential 329 averaging filter, modified for variable sampling rate 331 var_v_hat(i) = max(alpha * var_v_hat(i-1) + (1-alpha) * z(i)^2, 1) 333 alpha = (1-chi)^(30/(1000 * f_max)) 335 where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1,...,i is the 336 highest rate at which the last K packet groups have been received and 337 chi is a filter coefficient typically chosen as a number in the 338 interval [0.1, 0.001]. Since our assumption that v(i) should be zero 339 mean WGN is less accurate in some cases, we have introduced an 340 additional outlier filter around the updates of var_v_hat. If z(i) > 341 3*sqrt(var_v_hat) the filter is updated with 3*sqrt(var_v_hat) rather 342 than z(i). For instance v(i) will not be white in situations where 343 packets are sent at a higher rate than the channel capacity, in which 344 case they will be queued behind each other. 346 4.3. Over-use detector 348 The inter-group delay variation estimate m(i), obtained as the output 349 of the arrival-time filter, is compared with a threshold 350 del_var_th(i). An estimate above the threshold is considered as an 351 indication of over-use. Such an indication is not enough for the 352 detector to signal over-use to the rate control subsystem. A 353 definitive over-use will be signaled only if over-use has been 354 detected for at least overuse_time_th milliseconds. However, if m(i) 355 < m(i-1), over-use will not be signaled even if all the above 356 conditions are met. Similarly, the opposite state, under-use, is 357 detected when m(i) < -del_var_th(i). If neither over-use nor under- 358 use is detected, the detector will be in the normal state. 360 The threshold del_var_th has a remarkable impact on the overall 361 dynamics and performance of the algorithm. In particular, it has 362 been shown that using a static threshold del_var_th, a flow 363 controlled by the proposed algorithm can be starved by a concurrent 364 TCP flow [Pv13]. This starvation can be avoided by increasing the 365 threshold del_var_th to a sufficiently large value. 367 The reason is that, by using a larger value of del_var_th, a larger 368 queuing delay can be tolerated, whereas with a small del_var_th, the 369 over-use detector quickly reacts to a small increase in the offset 370 estimate m(i) by generating an over-use signal that reduces the 371 delay-based estimate of the available bandwidth A_hat (see 372 Section 4.4). Thus, it is necessary to dynamically tune the 373 threshold del_var_th to get good performance in the most common 374 scenarios, such as when competing with loss-based flows. 376 For this reason, we propose to vary the threshold del_var_th(i) 377 according to the following dynamic equation: 379 del_var_th(i) = 380 del_var_th(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-del_var_th(i-1)) 382 with K(i)=K_d if |m(i)| < del_var_th(i-1) or K(i)=K_u otherwise. The 383 rationale is to increase del_var_th(i) when m(i) is outside of the 384 range [-del_var_th(i-1),del_var_th(i-1)], whereas, when the offset 385 estimate m(i) falls back into the range, del_var_th is decreased. In 386 this way when m(i) increases, for instance due to a TCP flow entering 387 the same bottleneck, del_var_th(i) increases and avoids the 388 uncontrolled generation of over-use signals which may lead to 389 starvation of the flow controlled by the proposed algorithm [Pv13]. 390 Moreover, del_var_th(i) SHOULD NOT be updated if this condition 391 holds: 393 |m(i)| - del_var_th(i) > 15 395 It is also RECOMMENDED to clamp del_var_th(i) to the range [6, 600], 396 since a too small del_var_th(i) can cause the detector to become 397 overly sensitive. 399 On the other hand, when m(i) falls back into the range 400 [-del_var_th(i-1),del_var_th(i-1)] the threshold del_var_th(i) is 401 decreased so that a lower queuing delay can be achieved. 403 It is RECOMMENDED to choose K_u > K_d so that the rate at which 404 del_var_th is increased is higher than the rate at which it is 405 decreased. With this setting it is possible to increase the 406 threshold in the case of a concurrent TCP flow and prevent starvation 407 as well as enforcing intra-protocol fairness. RECOMMENDED values for 408 del_var_th(0), overuse_time_th, K_u and K_d are respectively 12.5 ms, 409 10 ms, 0.01 and 0.00018. 411 4.4. Rate control 413 The rate control is split in two parts, one controlling the bandwidth 414 estimate based on delay, and one controlling the bandwidth estimate 415 based on loss. Both are designed to increase the estimate of the 416 available bandwidth A_hat as long as there is no detected congestion 417 and to ensure that we will eventually match the available bandwidth 418 of the channel and detect an over-use. 420 As soon as over-use has been detected, the available bandwidth 421 estimated by the delay-based controller is decreased. In this way we 422 get a recursive and adaptive estimate of the available bandwidth. 424 In this document we make the assumption that the rate control 425 subsystem is executed periodically and that this period is constant. 427 The rate control subsystem has 3 states: Increase, Decrease and Hold. 428 "Increase" is the state when no congestion is detected; "Decrease" is 429 the state where congestion is detected, and "Hold" is a state that 430 waits until built-up queues have drained before going to "increase" 431 state. 433 The state transitions (with blank fields meaning "remain in state") 434 are: 436 +----+--------+-----------+------------+--------+ 437 | \ State | Hold | Increase |Decrease| 438 | \ | | | | 439 | Signal\ | | | | 440 +--------+----+-----------+------------+--------+ 441 | Over-use | Decrease | Decrease | | 442 +-------------+-----------+------------+--------+ 443 | Normal | Increase | | Hold | 444 +-------------+-----------+------------+--------+ 445 | Under-use | | Hold | Hold | 446 +-------------+-----------+------------+--------+ 448 The subsystem starts in the increase state, where it will stay until 449 over-use or under-use has been detected by the detector subsystem. 450 On every update the delay-based estimate of the available bandwidth 451 is increased, either multiplicatively or additively, depending on its 452 current state. 454 The system does a multiplicative increase if the current bandwidth 455 estimate appears to be far from convergence, while it does an 456 additive increase if it appears to be closer to convergence. We 457 assume that we are close to convergence if the currently incoming 458 bitrate, R_hat(i), is close to an average of the incoming bitrates at 459 the time when we previously have been in the Decrease state. "Close" 460 is defined as three standard deviations around this average. It is 461 RECOMMENDED to measure this average and standard deviation with an 462 exponential moving average with the smoothing factor 0.95, as it is 463 expected that this average covers multiple occasions at which we are 464 in the Decrease state. Whenever valid estimates of these statistics 465 are not available, we assume that we have not yet come close to 466 convergence and therefore remain in the multiplicative increase 467 state. 469 If R_hat(i) increases above three standard deviations of the average 470 max bitrate, we assume that the current congestion level has changed, 471 at which point we reset the average max bitrate and go back to the 472 multiplicative increase state. 474 R_hat(i) is the incoming bitrate measured by the delay-based 475 controller over a T seconds window: 477 R_hat(i) = 1/T * sum(L(j)) for j from 1 to N(i) 479 N(i) is the number of packets received the past T seconds and L(j) is 480 the payload size of packet j. A window between 0.5 and 1 second is 481 RECOMMENDED. 483 During multiplicative increase, the estimate is increased by at most 484 8% per second. 486 eta = 1.08^min(time_since_last_update_ms / 1000, 1.0) 487 A_hat(i) = eta * A_hat(i-1) 489 During the additive increase the estimate is increased with at most 490 half a packet per response_time interval. The response_time interval 491 is estimated as the round-trip time plus 100 ms as an estimate of 492 over-use estimator and detector reaction time. 494 response_time_ms = 100 + rtt_ms 495 alpha = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0) 496 A_hat(i) = A_hat(i-1) + max(1000, alpha * expected_packet_size_bits) 498 expected_packet_size_bits is used to get a slightly slower slope for 499 the additive increase at lower bitrates. It can for instance be 500 computed from the current bitrate by assuming a frame rate of 30 501 frames per second: 503 bits_per_frame = A_hat(i-1) / 30 504 packets_per_frame = ceil(bits_per_frame / (1200 * 8)) 505 avg_packet_size_bits = bits_per_frame / packets_per_frame 507 Since the system depends on over-using the channel to verify the 508 current available bandwidth estimate, we must make sure that our 509 estimate does not diverge from the rate at which the sender is 510 actually sending. Thus, if the sender is unable to produce a bit 511 stream with the bitrate the congestion controller is asking for, the 512 available bandwidth estimate should stay within a given bound. 513 Therefore we introduce a threshold 515 A_hat(i) < 1.5 * R_hat(i) 517 When an over-use is detected the system transitions to the decrease 518 state, where the delay-based available bandwidth estimate is 519 decreased to a factor times the currently incoming bitrate. 521 A_hat(i) = beta * R_hat(i) 523 beta is typically chosen to be in the interval [0.8, 0.95], 0.85 is 524 the RECOMMENDED value. 526 When the detector signals under-use to the rate control subsystem, we 527 know that queues in the network path are being emptied, indicating 528 that our available bandwidth estimate A_hat is lower than the actual 529 available bandwidth. Upon that signal the rate control subsystem 530 will enter the hold state, where the receive-side available bandwidth 531 estimate will be held constant while waiting for the queues to 532 stabilize at a lower level - a way of keeping the delay as low as 533 possible. This decrease of delay is wanted, and expected, 534 immediately after the estimate has been reduced due to over-use, but 535 can also happen if the cross traffic over some links is reduced. 537 It is RECOMMENDED that the routine to update A_hat(i) is run at least 538 once every response_time interval. 540 4.5. Parameters settings 542 +-----------------+-----------------------------------+-------------+ 543 | Parameter | Description | RECOMMENDED | 544 | | | Value | 545 +-----------------+-----------------------------------+-------------+ 546 | burst_time | Time limit in milliseconds | 5 ms | 547 | | between packet bursts which | | 548 | | identifies a group | | 549 | q | State noise covariance matrix | q = 10^-3 | 550 | e(0) | Initial value of the system | e(0) = 0.1 | 551 | | error covariance | | 552 | chi | Coefficient used for the | [0.1, | 553 | | measured noise variance | 0.001] | 554 | del_var_th(0) | Initial value for the adaptive | 12.5 ms | 555 | | threshold | | 556 | overuse_time_th | Time required to trigger an | 10 ms | 557 | | overuse signal | | 558 | K_u | Coefficient for the adaptive | 0.01 | 559 | | threshold | | 560 | K_d | Coefficient for the adaptive | 0.00018 | 561 | | threshold | | 562 | T | Time window for measuring the | [0.5, 1] s | 563 | | received bitrate | | 564 | beta | Decrease rate factor | 0.85 | 565 +-----------------+-----------------------------------+-------------+ 567 Table 1: RECOMMENDED values for delay based controller 569 Table 1 571 5. Loss-based control 573 A second part of the congestion controller bases its decisions on the 574 round-trip time, packet loss and available bandwidth estimates A_hat 575 received from the delay-based controller. The available bandwidth 576 estimates computed by the loss-based controller are denoted with 577 As_hat. 579 The available bandwidth estimates A_hat produced by the delay-based 580 controller are only reliable when the size of the queues along the 581 path sufficiently large. If the queues are very short, over-use will 582 only be visible through packet losses, which are not used by the 583 delay-based controller. 585 The loss-based controller SHOULD run every time feedback from the 586 receiver is received. 588 o If 2-10% of the packets have been lost since the previous report 589 from the receiver, the sender available bandwidth estimate 590 As_hat(i) will be kept unchanged. 592 o If more than 10% of the packets have been lost a new estimate is 593 calculated as As_hat(i) = As_hat(i-1)(1-0.5p), where p is the loss 594 ratio. 596 o As long as less than 2% of the packets have been lost As_hat(i) 597 will be increased as As_hat(i) = 1.05(As_hat(i-1)) 599 The loss-based estimate As_hat is compared with the delay-based 600 estimate A_hat. The actual sending rate is set as the minimum 601 between As_hat and A_hat. 603 We motivate the packet loss thresholds by noting that if the 604 transmission channel has a small amount of packet loss due to over- 605 use, that amount will soon increase if the sender does not adjust his 606 bitrate. Therefore we will soon enough reach above the 10% threshold 607 and adjust As_hat(i). However, if the packet loss ratio does not 608 increase, the losses are probably not related to self-inflicted 609 congestion and therefore we should not react on them. 611 6. Interoperability Considerations 613 In case a sender implementing these algorithms talks to a receiver 614 which do not implement any of the proposed RTCP messages and RTP 615 header extensions, it is suggested that the sender monitors RTCP 616 receiver reports and uses the fraction of lost packets and the round- 617 trip time as input to the loss-based controller. The delay-based 618 controller should be left disabled. 620 7. Implementation Experience 622 This algorithm has been implemented in the open-source WebRTC 623 project, has been in use in Chrome since M23, and is being used by 624 Google Hangouts. 626 Deployment of the algorithm have revealed problems related to, e.g, 627 congested or otherwise problematic WiFi networks, which have led to 628 algorithm improvements. The algorithm has also been tested in a 629 multi-party conference scenario with a conference server which 630 terminates the congestion control between endpoints. This ensures 631 that no assumptions are being made by the congestion control about 632 maximum send and receive bitrates, etc., which typically is out of 633 control for a conference server. 635 8. Further Work 637 This draft is offered as input to the congestion control discussion. 639 Work that can be done on this basis includes: 641 o Considerations of integrated loss control: How loss and delay 642 control can be better integrated, and the loss control improved. 644 o Considerations of locus of control: evaluate the performance of 645 having all congestion control logic at the sender, compared to 646 splitting logic between sender and receiver. 648 o Considerations of utilizing ECN as a signal for congestion 649 estimation and link over-use detection. 651 9. IANA Considerations 653 This document makes no request of IANA. 655 Note to RFC Editor: this section may be removed on publication as an 656 RFC. 658 10. Security Considerations 660 An attacker with the ability to insert or remove messages on the 661 connection would have the ability to disrupt rate control. This 662 could make the algorithm to produce either a sending rate under- 663 utilizing the bottleneck link capacity, or a too high sending rate 664 causing network congestion. 666 In this case, the control information is carried inside RTP, and can 667 be protected against modification or message insertion using SRTP, 668 just as for the media. Given that timestamps are carried in the RTP 669 header, which is not encrypted, this is not protected against 670 disclosure, but it seems hard to mount an attack based on timing 671 information only. 673 11. Acknowledgements 675 Thanks to Randell Jesup, Magnus Westerlund, Varun Singh, Tim Panton, 676 Soo-Hyun Choo, Jim Gettys, Ingemar Johansson, Michael Welzl and 677 others for providing valuable feedback on earlier versions of this 678 draft. 680 12. References 682 12.1. Normative References 684 [I-D.alvestrand-rmcat-remb] 685 Alvestrand, H., "RTCP message for Receiver Estimated 686 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 687 progress), October 2013. 689 [I-D.holmer-rmcat-transport-wide-cc-extensions] 690 Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions 691 for Transport-wide Congestion Control", draft-holmer- 692 rmcat-transport-wide-cc-extensions-00 (work in progress), 693 March 2015. 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 698 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 699 Jacobson, "RTP: A Transport Protocol for Real-Time 700 Applications", STD 64, RFC 3550, July 2003. 702 [abs-send-time] 703 "RTP Header Extension for Absolute Sender Time", 704 . 707 12.2. Informative References 709 [Pv13] De Cicco, L., Carlucci, G., and S. Mascolo, "Understanding 710 the Dynamic Behaviour of the Google Congestion Control", 711 Packet Video Workshop , December 2013. 713 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 714 2914, September 2000. 716 Appendix A. Change log 718 A.1. Version -00 to -01 720 o Added change log 722 o Added appendix outlining new extensions 724 o Added a section on when to send feedback to the end of section 3.3 725 "Rate control", and defined min/max FB intervals. 727 o Added size of over-bandwidth estimate usage to "further work" 728 section. 730 o Added startup considerations to "further work" section. 732 o Added sender-delay considerations to "further work" section. 734 o Filled in acknowledgments section from mailing list discussion. 736 A.2. Version -01 to -02 738 o Defined the term "frame", incorporating the transmission time 739 offset into its definition, and removed references to "video 740 frame". 742 o Referred to "m(i)" from the text to make the derivation clearer. 744 o Made it clearer that we modify our estimates of available 745 bandwidth, and not the true available bandwidth. 747 o Removed the appendixes outlining new extensions, added pointers to 748 REMB draft and RFC 5450. 750 A.3. Version -02 to -03 752 o Added a section on how to process multiple streams in a single 753 estimator using RTP timestamps to NTP time conversion. 755 o Stated in introduction that the draft is aimed at the RMCAT 756 working group. 758 A.4. rtcweb-03 to rmcat-00 760 Renamed draft to link the draft name to the RMCAT WG. 762 A.5. rmcat -00 to -01 764 Spellcheck. Otherwise no changes, this is a "keepalive" release. 766 A.6. rmcat -01 to -02 768 o Added Luca De Cicco and Saverio Mascolo as authors. 770 o Extended the "Over-use detector" section with new technical 771 details on how to dynamically tune the offset del_var_th for 772 improved fairness properties. 774 o Added reference to a paper analyzing the behavior of the proposed 775 algorithm. 777 A.7. rmcat -02 to -03 779 o Swapped receiver-side/sender-side controller with delay-based/ 780 loss-based controller as there is no longer a requirement to run 781 the delay-based controller on the receiver-side. 783 o Removed the discussion about multiple streams and transmission 784 time offsets. 786 o Introduced a new section about "Feedback and extensions". 788 o Improvements to the threshold adaptation in the "Over-use 789 detector" section. 791 o Swapped the previous MIMD rate control algorithm for a new AIMD 792 rate control algorithm. 794 A.8. ietf-rmcat -00 to ietf-rmcat -01 796 o Arrival-time filter converted from a two dimensional Kalman filter 797 to a scalar Kalman filter. 799 o The use of the TFRC equation was removed from the loss-based 800 controller, as it turned out to have little to no effect in 801 practice. 803 Authors' Addresses 804 Stefan Holmer 805 Google 806 Kungsbron 2 807 Stockholm 11122 808 Sweden 810 Email: holmer@google.com 812 Henrik Lundin 813 Google 814 Kungsbron 2 815 Stockholm 11122 816 Sweden 818 Email: hlundin@google.com 820 Gaetano Carlucci 821 Politecnico di Bari 822 Via Orabona, 4 823 Bari 70125 824 Italy 826 Email: gaetano.carlucci@poliba.it 828 Luca De Cicco 829 Politecnico di Bari 830 Via Orabona, 4 831 Bari 70125 832 Italy 834 Email: l.decicco@poliba.it 836 Saverio Mascolo 837 Politecnico di Bari 838 Via Orabona, 4 839 Bari 70125 840 Italy 842 Email: mascolo@poliba.it