idnits 2.17.1 draft-zhu-rmcat-nada-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 355 has weird spacing: '...---, if d_th<...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 23, 2015) is 3321 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Zhu, R. Pan 3 Internet Draft M. A. Ramalho, S. Mena 4 Intended Status: Informational C. Ganzhorn, P. E. Jones 5 Expires: September 24, 2015 Cisco Systems 6 S. De Aronco 7 Ecole Polytechnique Federale de Lausanne 8 March 23, 2015 10 NADA: A Unified Congestion Control Scheme for Real-Time Media 11 draft-zhu-rmcat-nada-05 13 Abstract 15 Network-Assisted Dynamic Adaptation (NADA) is a novel congestion 16 control scheme for interactive real-time media applications, such as 17 video conferencing. In NADA, the sender regulates its sending rate 18 based on either implicit or explicit congestion signaling in a 19 consistent manner. As one example of explicit signaling, NADA can 20 benefit from explicit congestion notification (ECN) markings from 21 network nodes. It also maintains consistent sender behavior in the 22 absence of explicit signaling by reacting to queuing delay and packet 23 loss. 25 This document describes the overall system architecture for NADA, 26 recommended behavior at the sender and the receiver, as well as 27 expected network node operations. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. System Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Network Node Operations . . . . . . . . . . . . . . . . . . . . 5 71 4.1 Default behavior of drop tail . . . . . . . . . . . . . . . 5 72 4.2 ECN marking . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.3 PCN marking . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.4 Comments and Discussions . . . . . . . . . . . . . . . . . . 7 75 5. Receiver Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.1 Estimation of one-way delay and queuing delay . . . . . . . 7 77 5.2 Estimation of packet loss/marking ratio . . . . . . . . . . 8 78 5.3 Non-linear warping of delay . . . . . . . . . . . . . . . . 9 79 5.4 Aggregating congestion signals . . . . . . . . . . . . . . . 10 80 5.5 Estimating receiving rate . . . . . . . . . . . . . . . . . 10 81 5.6 Sending periodic feedback . . . . . . . . . . . . . . . . . 10 82 5.7 Discussions on delay metrics . . . . . . . . . . . . . . . . 11 83 6. Sender Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.1 Reference rate calculation . . . . . . . . . . . . . . . . . 13 85 6.1.1. Accelerated ramp up . . . . . . . . . . . . . . . . . . 13 86 6.1.2. Gradual rate update . . . . . . . . . . . . . . . . . . 14 87 6.2 Video encoder rate control . . . . . . . . . . . . . . . . . 15 88 6.3 Rate shaping buffer . . . . . . . . . . . . . . . . . . . . 15 89 6.4 Adjusting video target rate and sending rate . . . . . . . . 15 90 7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 16 91 8. Implementation Status . . . . . . . . . . . . . . . . . . . . . 17 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 95 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 98 1. Introduction 100 Interactive real-time media applications introduce a unique set of 101 challenges for congestion control. Unlike TCP, the mechanism used for 102 real-time media needs to adapt quickly to instantaneous bandwidth 103 changes, accommodate fluctuations in the output of video encoder rate 104 control, and cause low queuing delay over the network. An ideal 105 scheme should also make effective use of all types of congestion 106 signals, including packet loss, queuing delay, and explicit 107 congestion notification (ECN) [RFC3168] markings. 109 Based on the above considerations, this document describes a scheme 110 called network-assisted dynamic adaptation (NADA). The NADA design 111 benefits from explicit congestion control signals (e.g., ECN 112 markings) from the network, yet also operates when only implicit 113 congestion indicators (delay and/or loss) are available. In addition, 114 it supports weighted bandwidth sharing among competing video flows. 116 This documentation describes the overall system architecture, 117 recommended designs at the sender and receiver, as well as expected 118 network node operations. The signaling mechanism consists of standard 119 RTP timestamp [RFC3550] and standard RTCP feedback reports. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 3. System Model 129 The system consists of the following elements: 131 * Source media stream, in the form of consecutive raw video 132 frames and audio samples; 134 * Media encoder with rate control capabilities. It takes the 135 source media stream and encodes it to an RTP stream at a target 136 bit rate R_v. Note that the actual output rate from the encoder 137 R_o may fluctuate around the target R_v. Also, the encoder can 138 only change its rate at rather coarse time intervals, e.g., once 139 every 0.5 seconds. 141 * RTP sender, responsible for calculating the target bit rate 142 R_n based on network congestion indicators (delay, loss, or ECN 143 marking reports from the receiver), for updating the video 144 encoder with a new target rate R_v, and for regulating the 145 actual sending rate R_s accordingly. A rate shaping buffer is 146 employed to absorb the instantaneous difference between video 147 encoder output rate R_v and sending rate R_s. The buffer size 148 L_s, together with R_n, influences the calculation of actual 149 sending rate R_s and video encoder target rate R_v. The RTP 150 sender also generates RTP timestamp in outgoing packets. 152 * RTP receiver, responsible for measuring and estimating end-to- 153 end delay based on sender RTP timestamp. In the presence of 154 packet loss and ECN markings, it keeps track of packet loss and 155 ECN marking ratios. It calculates the equivalent delay x_n that 156 accounts for queuing delay, ECN marking, and packet loss, as 157 well as the derivative (i.e., rate of change) of this congestion 158 signal as x'_n. The receiver feeds both pieces of information 159 (x_n and x'_n) back to the sender via periodic RTCP reports. 161 * Network node, with several modes of operation. The system can 162 work with the default behavior of a simple drop tail queue. It 163 can also benefit from advanced AQM features such as RED-based 164 ECN marking, and PCN marking using a token bucket algorithm. 166 In the following, we will elaborate on the respective operations at the 167 network node, the receiver, and the sender. 169 4. Network Node Operations 171 We consider three variations of queue management behavior at the network 172 node, leading to either implicit or explicit congestion signals. 174 4.1 Default behavior of drop tail 176 In a conventional network with drop tail or RED queues, congestion is 177 inferred from the estimation of end-to-end delay and/or packet loss. 178 Packet drops at the queue are detected at the receiver, and contributes 179 to the calculation of the equivalent delay x_n. No special action is 180 required at network node. 182 4.2 ECN marking 184 In this mode, the network node randomly marks the ECN field in the IP 185 packet header following the Random Early Detection (RED) algorithm 186 [RFC2309]. Calculation of the marking probability involves the following 187 steps: 189 * upon packet arrival, update smoothed queue size q_avg as: 191 q_avg = alpha*q + (1-alpha)*q_avg. 193 The smoothing parameter alpha is a value between 0 and 1. A value of 194 alpha=1 corresponds to performing no smoothing at all. 196 * calculate marking probability p as: 198 p = 0, if q < q_lo; 200 q_avg - q_lo 201 p = p_max*--------------, if q_lo <= q < q_hi; 202 q_hi - q_lo 204 p = 1, if q >= q_hi. 206 Here, q_lo and q_hi corresponds to the low and high thresholds of queue 207 occupancy. The maximum marking probability is p_max. 209 The ECN markings events will contribute to the calculation of an 210 equivalent delay x_n at the receiver. No changes are required at the 211 sender. 213 4.3 PCN marking 215 As a more advanced feature, we also envisage network nodes which support 216 PCN marking based on virtual queues. In such a case, the marking 217 probability of the ECN bit in the IP packet header is calculated as 218 follows: 220 * upon packet arrival, meter packet against token bucket (r,b); 222 * update token level b_tk; 224 * calculate the marking probability as: 226 p = 0, if b-b_tk < b_lo; 228 b-b_tk-b_lo 229 p = p_max* --------------, if b_lo<= b-b_tk =b_hi. 234 Here, the token bucket lower and upper limits are denoted by b_lo and 235 b_hi, respectively. The parameter b indicates the size of the token 236 bucket. The parameter r is chosen as r=gamma*C, where gamma<1 is the 237 target utilization ratio and C designates link capacity. The maximum 238 marking probability is p_max. 240 The ECN markings events will contribute to the calculation of an 241 equivalent delay x_n at the receiver. No changes are required at the 242 sender. The virtual queuing mechanism from the PCN marking algorithm 243 will lead to additional benefits such as zero standing queues. 245 4.4 Comments and Discussions 247 In all three flavors described above, the network queue operates with 248 the simple first-in-first-out (FIFO) principle. There is no need to 249 maintain per-flow state. Such a simple design ensures that the system 250 can scale easily with a large number of video flows and high link 251 capacity. 253 The sender behavior stays the same in the presence of all types of 254 congestion indicators: delay, loss, ECN marking due to either RED/ECN or 255 PCN algorithms. This unified approach allows a graceful transition of 256 the scheme as the network shifts dynamically between light and heavy 257 congestion levels. 259 5. Receiver Behavior 261 The receiver continuously monitors end-to-end per-packet statistics in 262 terms of delay, loss, and/or ECN marking ratios. It then aggregates all 263 forms of congestion indicators into the form of an equivalent delay and 264 periodically reports this back to the sender. In addition, the receiver 265 tracks the receiving rate of the flow and includes that in the feedback 266 message. 268 5.1 Estimation of one-way delay and queuing delay 270 The delay estimation process in NADA follows a similar approach as in 271 earlier delay-based congestion control schemes, such as LEDBAT 272 [RFC6817]. NADA estimates the forward delay as having a constant base 273 delay component plus a time varying queuing delay component. The base 274 delay is estimated as the minimum value of one-way delay observed over a 275 relatively long period (e.g., tens of minutes), whereas the individual 276 queuing delay value is taken to be the difference between one-way delay 277 and base delay. 279 In mathematical terms, for packet n arriving at the receiver, one-way 280 delay is calculated as: 282 x_n = t_r,n - t_s,n, 284 where t_s,n and t_r,n are sender and receiver timestamps, respectively. 285 A real-world implementation should also properly handle practical issues 286 such as wrap-around in the value of x_n, which are omitted from the 287 above simple expression for brevity. 289 The base delay, d_f, is estimated as the minimum value of previously 290 observed x_n's over a relatively long period. This assumes that the 291 drift between sending and receiving clocks remains bounded by a small 292 value. 294 Correspondingly, the queuing delay experienced by the packet n is 295 estimated as: 297 d_n = x_n - d_f. 299 The individual sample values of queuing delay should be further filtered 300 against various non-congestion-induced noise, such as spikes due to 301 processing "hiccup" at the network nodes. We denote the resulting 302 queuing delay value as d_hat_n. 304 Our current implementation employs a simple 5-point median filter over 305 per-packet queuing delay estimates, followed by an exponential smoothing 306 filter. We have found such relatively simple treatment to suffice in 307 guarding against processing delay outliers observed in wired 308 connections. For wireless connections with a higher packet delay 309 variation (PDV), more sophisticated techniques on de-noising, outlier 310 rejection, and trend analysis may be needed. 312 Like other delay-based congestion control schemes, performance of NADA 313 depends on the accuracy of its delay measurement and estimation module. 314 Appendix A in [RFC6817] provides an extensive discussion on this aspect. 316 5.2 Estimation of packet loss/marking ratio 318 The receiver detects packet losses via gaps in the RTP sequence numbers 319 of received packets. It then calculates instantaneous packet loss ratio 320 as the ratio between the number of missing packets over the number of 321 total transmitted packets in the given time window (e.g., during the 322 most recent 500ms). This instantaneous value is passed over an 323 exponential smoothing filter, and the filtered result is reported back 324 to the sender as the observed packet loss ratio p_L. 326 We note that more sophisticated methods in packet loss ratio 327 calculation, such as that adopted by TFRC [Floyd-CCR00], will likely be 328 beneficial. These alternatives are currently under investigation. 330 Estimation of packet marking ratio p_M, when ECN is enabled at 331 bottleneck network nodes along the path, will follow the same procedure 332 as above. Here it is assumed that ECN marking information at the IP 333 header are somehow passed along to the transport layer by the receiving 334 endpoint. 336 5.3 Non-linear warping of delay 338 In order for a delay-based flow to hold its ground and sustain a 339 reasonable share of bandwidth in the presence of a loss-based flow 340 (e.g., loss-based TCP), it is important to distinguish between different 341 levels of observed queuing delay. For instance, a moderate queuing delay 342 value below 100ms is likely self-inflicted or induced by other delay- 343 based flows, whereas a high queuing delay value of several hundreds of 344 milliseconds may indicate the presence of a loss-based flow that does 345 not refrain from increased delay. 347 Inspired by the delay-adaptive congestion window backoff policy in 348 [Budzisz-TON11] -- the work by itself is a window-based congestion 349 control scheme with fair coexistence with TCP -- we devise the following 350 non-linear warping of estimated queuing delay value: 352 d_tilde_n = (d_hat_n), if d_hat_n < d_th; 354 (d_max - d_hat_n)^4 355 d_tilde_n = d_th --------------------, if d_th d_max. 360 Here, the queuing delay value is unchanged when it is below the first 361 threshold d_th; it is discounted following a non-linear curve when its 362 value falls between d_th and d_max; above d_max, the high queuing delay 363 value no longer counts toward congestion control. 365 When queuing delay is in the range (0, d_th), NADA operates in pure 366 delay-based mode if no losses/markings are present. When queuing delay 367 exceeds d_max, NADA reacts to loss/marking only. In between d_th and 368 d_max, the sending rate will converge and stabilize at an operating 369 point with a fairly high queuing delay and non-zero packet loss ratio. 371 In our current implementation d_th is chosen as 50ms and d_max is chosen 372 as 400ms. The impact of the choice of d_th and d_max will be 373 investigated in future work. 375 5.4 Aggregating congestion signals 377 The receiver aggregates all three forms of congestion signal in terms of 378 an equivalent delay: 380 x_n = d_tilde_n + p_M*d_M + p_L*d_L, (1) 382 where d_M is a prescribed fictitious delay value associated with ECN 383 markings (e.g., d_M = 200 ms), and d_L is a prescribed fictitious delay 384 value associated with packet losses (e.g., d_L = 1 second). By 385 introducing a large fictitious delay penalty for ECN marking and packet 386 loss, the proposed scheme leads to low end-to-end actual delay in the 387 presence of such events. 389 While the value of d_M and d_L are fixed and predetermined in the 390 current design, a scheme for automatically tuning these values based on 391 desired bandwidth sharing behavior in the presence of other competing 392 loss-based flows (e.g., loss-based TCP) is being studied. 394 In the absence of ECN marking from the network, the value of x_n falls 395 back to the observed queuing delay d_n for packet n when queuing delay 396 is low and no packets are lost over a lightly congested path. In that 397 case the algorithm operates in purely delay-based mode. 399 5.5 Estimating receiving rate 401 Estimation of receiving rate of the flow is fairly straightforward. NADA 402 maintains a recent observation window of 500ms, and simply divides the 403 total size of packets arriving during that window over the time span. 404 The receiving rate is denoted as R_r. 406 5.6 Sending periodic feedback 408 Periodically, the receiver feeds back a tuple of the most recent values 409 of in RTCP feedback messages to aid the sender 410 in its calculation of target rate. The queuing delay value d_hat_n is 411 included along with the composite congestion signal x_n so that the 412 sender can decide whether the network is truly underutilized (see Sec. 413 6.1.1 Accelerated ramp-up). 415 The value of x'_n corresponds to the derivative (i.e., rate of change) 416 of the composite congestion signal: 418 x_n - x_(n-k) 419 x'_n = ---------------, (2) 420 delta 422 where the interval between consecutive RTCP feedback messages is denoted 423 as delta. The packet indices corresponding to the current and previous 424 feedback are n and (n-k), respectively. 426 The choice of target feedback interval needs to strike the right balance 427 between timely feedback and low RTCP feedback message counts. Through 428 simulation studies and frequency-domain analysis, it was determined that 429 a feedback interval below 250ms will not break up the feedback control 430 loop of the NADA congestion control algorithm. Thus, it is recommended 431 to use a target feed interval of 100ms. This will result in a feedback 432 bandwidth of 16Kbps with 200 bytes per feedback message, less than 0.1% 433 overhead for a 1Mbps flow. 435 5.7 Discussions on delay metrics 437 The current design works with relative one-way-delay (OWD) as the main 438 indication of congestion. The value of the relative OWD is obtained by 439 maintaining the minimum value of observed OWD over a relatively long 440 time horizon and subtract that out from the observed absolute OWD value. 441 Such an approach cancels out the fixed difference between the sender and 442 receiver clocks. It has been widely adopted by other delay-based 443 congestion control approaches such as LEDBAT [RFC6817]. As discussed in 444 [RFC6817], the time horizon for tracking the minimum OWD needs to be 445 chosen with care: it must be long enough for an opportunity to observe 446 the minimum OWD with zero queuing delay along the path, and sufficiently 447 short so as to timely reflect "true" changes in minimum OWD introduced 448 by route changes and other rare events. 450 The potential drawback in relying on relative OWD as the congestion 451 signal is that when multiple flows share the same bottleneck, the flow 452 arriving late at the network experiencing a non-empty queue may 453 mistakenly consider the standing queuing delay as part of the fixed path 454 propagation delay. This will lead to slightly unfair bandwidth sharing 455 among the flows. 457 Alternatively, one could move the per-packet statistical handling to the 458 sender instead and use RTT in lieu of OWD, assuming that per-packet ACKs 459 are available. The main drawback of this latter approach is that the 460 scheme will be confused by congestion in the reverse direction. 462 Note that the adoption of either delay metric (relative OWD vs. RTT) 463 involves no change in the proposed rate adaptation algorithm at the 464 sender. Therefore, comparing the pros and cons regarding which delay 465 metric to adopt can be kept as an orthogonal direction of 466 investigation. 468 6. Sender Behavior 470 Figure 1 provides a detailed view of the NADA sender. Upon receipt of an 471 RTCP report from the receiver, the NADA sender updates its calculation 472 of the reference rate R_n. It further adjusts both the target rate for 473 the live video encoder R_v and the sending rate R_s over the network 474 based on the updated value of R_n, as well as the size of the rate 475 shaping buffer. 477 In the following, we describe these modules in further detail, and 478 explain how they interact with each other. 480 -------------------- 481 | | 482 | Reference Rate | <---- RTCP report 483 | Calculator | 484 | | 485 -------------------- 486 | 487 | R_n 488 | 489 -------------------------- 490 | | 491 | | 492 \ / \ / 493 -------------------- ----------------- 494 | | | | 495 | Video Target | | Sending Rate | 496 | Rate Calculator | | Calculator | 497 | | | | 498 -------------------- ----------------- 499 | /|\ /|\ | 500 R_v| | | | 501 | ----------------------- | 502 | | | R_s 503 ------------ |L_s | 504 | | | | 505 | | R_o -------------- \|/ 506 | Encoder |----------> | | | | | ---------------> 507 | | | | | | | video packets 508 ------------ -------------- 509 Rate Shaping Buffer 511 Figure 1 NADA Sender Structure 513 6.1 Reference rate calculation 515 The sender initializes the reference rate R_n as R-min by default, or to 516 a value specified by the upper-layer application. [Editor's note: should 517 proper choice of starting rate value be within the scope of the CC 518 solution? ] 520 The reference rate R_n is calculated based on receiver feedback 521 information regarding queuing delay d_tilde_n, composite congestion 522 signal x_n, its derivative x'_n, as well as the receiving rate R_r. The 523 sender switches between two modes of operation: 525 * Accelerated ramp up: if the reported queuing delay is close to 526 zero and both values of x_n and x'_n are close to zero, 527 indicating empty queues along the path of the flow and, 528 consequently, underutilized network bandwidth; or 530 * Gradual rate update: in all other conditions, whereby the 531 receiver reports on a standing or increasing/decreasing queue 532 and/or composite congestion signal. 534 6.1.1. Accelerated ramp up 536 In the absence of a non-zero congestion signal to guide the sending rate 537 calculation, the sender needs to ramp up its estimated bandwidth as 538 quickly as possible without introducing excessive queuing delay. Ideally 539 the flow should inflict no more than T_th milliseconds of queuing delay 540 at the bottleneck during the ramp-up process. A typical value of T_th is 541 50ms. 543 Note that the sender will be aware of any queuing delay introduced by 544 its rate increase after at least one round-trip time. In addition, the 545 bottleneck bandwidth C is greater than or equal to the receive rate R_r 546 reported from the most recent "no congestion" feedback message. The rate 547 R_n is updated as follows: 549 T_th 550 gamma = min [gamma_0, ---------------] (3) 551 RTT_0+delta_0 553 R_n = (1+gamma) R_r (4) 555 In (3) and (4), the multiplier gamma for rate increase is upper-bounded 556 by a fixed ratio gamma_0 (e.g., 20%), as well as a ratio which depends 557 on T_th, base RTT as measured during the non-congested phase, and target 558 ACK interval delta_0. The rationale behind this is that the rate 559 increase multiplier should decrease with the delay in the feedback 560 control loop, and that RTT_0 + delta_0 provides a worst-case estimate of 561 feedback control delay when the network is not congested. 563 6.1.2. Gradual rate update 565 When the receiver reports indicate a standing congestion level, NADA 566 operates in gradual update mode, and calculates its reference rate as: 568 kappa * delta_s 569 R_n <-- R_n + ---------------- * (theta-(R_n-R_min)*x_hat) (5) 570 tau_o^2 572 where 574 theta = w*(R_max - R_min)*x_ref. (6) 576 x_hat = x_n + eta*tau_o* x'_n (7) 578 In (5), delta_s refers to the time interval between current and previous 579 rate updates. Note that delta_s is the same as the RTCP report interval 580 at the receiver (see delta from (2)) when the backward path is un- 581 congested. 583 In (6), R_min and R_max denote the content-dependent rate range the 584 encoder can produce. The weighting factor reflecting a flow's priority 585 is w. The reference congestion signal x_ref is chosen so that the 586 maximum rate of R_max can be achieved when x_hat = w*x_ref. 588 Proper choice of the scaling parameters eta and kappa in (5) and (7) can 589 ensure system stability so long as the RTT falls below the upper bound 590 of tau_o. The recommended default value of tau_o is chosen as 500ms. 592 For both modes of operations, the final reference rate R_n is clipped 593 within the range of [R_min, R_max]. Note also that the sender does not 594 need any explicit knowledge of the management scheme inside the network. 596 Rather, it reacts to the aggregation of all forms of congestion 597 indications (delay, loss, and explicit markings) via the composite 598 congestion signals x_n and x'_n from the receiver in a coherent manner. 600 6.2 Video encoder rate control 602 The video encoder rate control procedure has the following 603 characteristics: 605 * Rate changes can happen only at large intervals, on the order of 606 seconds. 608 * Given a target rate R_o, the encoder output rate may fluctuate 609 around it. 611 * The encoder output rate is further constrained by video content 612 complexity. The range of the final rate output is [R_min, R_max]. 613 Note that it is content-dependent and may vary over time. 615 The operation of the live video encoder is out of the scope of the 616 design for the congestion control scheme in NADA. Instead, its behavior 617 is treated as a black box. 619 6.3 Rate shaping buffer 621 A rate shaping buffer is employed to absorb any instantaneous mismatch 622 between encoder rate output R_o and regulated sending rate R_s. The size 623 of the buffer evolves from time t-tau to time t as: 625 L_s(t) = max [0, L_s(t-tau)+(R_o-R_s)*tau]. 627 A large rate shaping buffer contributes to higher end-to-end delay, 628 which may harm the performance of real-time media communications. 629 Therefore, the sender has a strong incentive to constrain the size of 630 the shaping buffer. It can either deplete it faster by increasing the 631 sending rate R_s, or limit its growth by reducing the target rate for 632 the video encoder rate control R_v. 634 6.4 Adjusting video target rate and sending rate 636 The target rate for the live video encoder is updated based on both the 637 reference rate R_n and the rate shaping buffer size L_s, as follows: 639 L_s 640 R_v = R_n - beta_v * -------. (8) 641 tau_v 643 Similarly, the outgoing rate is regulated based on both the reference 644 rate R_n and the rate shaping buffer size L_s, such that: 646 L_s 647 R_s = R_n + beta_s * -------. (9) 648 tau_v 650 In (8) and (9), the first term indicates the rate calculated from 651 network congestion feedback alone. The second term indicates the 652 influence of the rate shaping buffer. A large rate shaping buffer nudges 653 the encoder target rate slightly below -- and the sending rate slightly 654 above -- the reference rate R_n. 656 Intuitively, the amount of extra rate offset needed to completely drain 657 the rate shaping buffer within the same time frame of encoder rate 658 adaptation tau_v is given by L_s/tau_v. The scaling parameters beta_v 659 and beta_s can be tuned to balance between the competing goals of 660 maintaining a small rate shaping buffer and deviating the system from 661 the reference rate point. 663 7. Incremental Deployment 665 One nice property of NADA is the consistent video endpoint behavior 666 irrespective of network node variations. This facilitates gradual, 667 incremental adoption of the scheme. 669 To start off with, the encoder congestion control mechanism can be 670 implemented without any explicit support from the network, and relies 671 solely on observed one-way delay measurements and packet loss ratios as 672 implicit congestion signals. 674 When ECN is enabled at the network nodes with RED-based marking, the 675 receiver can fold its observations of ECN markings into the calculation 676 of the equivalent delay. The sender can react to these explicit 677 congestion signals without any modification. 679 Ultimately, networks equipped with proactive marking based on token 680 bucket level metering can reap the additional benefits of zero standing 681 queues and lower end-to-end delay and work seamlessly with existing 682 senders and receivers. 684 8. Implementation Status 686 The NADA scheme has been implemented in the ns-2 simulation platform 687 [ns2]. Extensive simulation evaluations of an earlier version of the 688 draft are documented in [Zhu-PV13]. Evaluation results of the current 689 draft over several test cases in [I-D.draft-sarker-rmcat-eval-test] have 690 been presented at recent IETF meetings [IETF-90][IETF-91]. 692 The scheme has also been implemented and evaluated in a lab setting as 693 described in [IETF-90]. Preliminary evaluation results of NADA in 694 single-flow and multi-flow scenarios have been presented in [IETF-91]. 696 9. IANA Considerations 698 There are no actions for IANA. 700 10. References 702 10.1 Normative References 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, March 1997. 707 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 708 of Explicit Congestion Notification (ECN) to IP", 709 RFC 3168, September 2001. 711 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 712 Jacobson, "RTP: A Transport Protocol for Real-Time 713 Applications", STD 64, RFC 3550, July 2003. 715 10.2 Informative References 717 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 718 of Explicit Congestion Notification (ECN) to IP", 719 RFC 3168, September 2001. 721 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 722 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 723 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 724 S., Wroclawski, J., and L. Zhang, "Recommendations on 725 Queue Management and Congestion Avoidance in the 726 Internet", RFC 2309, April 1998. 728 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and Kuehlewind, M., 729 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 730 December 2012 732 [Floyd-CCR00] Floyd, S., Handley, M., Padhye, J., and Widmer, J., 733 "Equation-based Congestion Control for Unicast 734 Applications", ACM SIGCOMM Computer Communications Review, 735 vol. 30. no. 4., pp. 43-56, October 2000. 737 [Budzisz-TON11] Budzisz, L. et al., "On the Fair Coexistence of 738 Loss- and Delay-Based TCP", IEEE/ACM Transactions on 739 Networking, vol. 19, no. 6, pp. 1811-1824, December 2011. 741 [ns2] "The Network Simulator - ns-2", http://www.isi.edu/nsnam/ns/ 743 [Zhu-PV13] Zhu, X. and Pan, R., "NADA: A Unified Congestion Control 744 Scheme for Low-Latency Interactive Video", in Proc. IEEE 745 International Packet Video Workshop (PV'13). San Jose, CA, 746 USA. December 2013. 748 [I-D.draft-sarker-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., 749 and Ramalho, M., "Test Cases for Evaluating RMCAT 750 Proposals", draft-sarker-rmcat-eval-test-01 (work in 751 progress), June 2014. 753 [IETF-90] Zhu, X. et al., "NADA Update: Algorithm, Implementation, 754 and Test Case Evalua6on Results", presented at IETF 90, 755 https://tools.ietf.org/agenda/90/slides/slides-90-rmcat- 756 6.pdf 758 [IETF-91] Zhu, X. et al., "NADA Algorithm Update and Test Case 759 Evaluations", presented at IETF 91 Interium, 760 https://datatracker.ietf.org/meeting/91/agenda/rmcat/ 762 Authors' Addresses 764 Xiaoqing Zhu 765 Cisco Systems, 766 12515 Research Blvd., 767 Austin, TX 78759, USA 768 Email: xiaoqzhu@cisco.com 769 Rong Pan 770 Cisco Systems 771 510 McCarthy Blvd, 772 Milpitas, CA 95134, USA 773 Email: ropan@cisco.com 775 Michael A. Ramalho 776 6310 Watercrest Way Unit 203 777 Lakewood Ranch, FL, 34202, USA 778 Email: mramalho@cisco.com 780 Sergio Mena de la Cruz 781 EPFL, Quartier de l'Innovation 782 Batiment E 783 Ecublens, Vaud 1015, Switzerland 784 Email: semena@cisco.com 786 Charles Ganzhorn 787 7900 International Drive 788 International Plaza, Suite 400 789 Bloomington, MN 55425, USA 790 Email: charles.ganzhorn@gmail.com 792 Paul E. Jones 793 7025 Kit Creek Rd. 794 Research Triangle Park, NC 27709, USA 795 Email: paulej@packetizer.com 797 Stefano D'Aronco 798 EPFL STI IEL LTS4 799 ELD 220 (Batiment ELD), Station 11 800 CH-1015 Lausanne, Switzerland 801 Email: stefano.daronco@epfl.ch