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