idnits 2.17.1 draft-ietf-rmcat-nada-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 5 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 422 has weird spacing: '... delta x_o...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 18, 2016) is 2954 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RMIN' is mentioned on line 395, but not defined == Missing Reference: 'RMAX' is mentioned on line 395, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-rmcat-eval-test-03 == Outdated reference: A later version (-07) exists of draft-ietf-rmcat-video-traffic-model-00 == Outdated reference: A later version (-02) exists of draft-ietf-rmcat-cc-codec-interactions-01 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-wireless-tests-01 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Zhu 3 Internet-Draft R. Pan 4 Intended status: Experimental M. Ramalho 5 Expires: September 19, 2016 S. Mena 6 P. Jones 7 J. Fu 8 Cisco Systems 9 S. D'Aronco 10 EPFL 11 C. Ganzhorn 12 March 18, 2016 14 NADA: A Unified Congestion Control Scheme for Real-Time Media 15 draft-ietf-rmcat-nada-02 17 Abstract 19 This document describes NADA (network-assisted dynamic adaptation), a 20 novel congestion control scheme for interactive real-time media 21 applications, such as video conferencing. In the proposed scheme, 22 the sender regulates its sending rate based on either implicit or 23 explicit congestion signaling, in a unified approach. The scheme can 24 benefit from explicit congestion notification (ECN) markings from 25 network nodes. It also maintains consistent sender behavior in the 26 absence of such markings, by reacting to queuing delays and packet 27 losses instead. 29 Status of This Memo 31 This Internet-Draft is submitted 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). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 19, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5 67 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 68 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8 69 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10 70 5. Practical Implementation of NADA . . . . . . . . . . . . . . 12 71 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12 72 5.1.1. Estimation of one-way delay and queuing delay . . . . 12 73 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 12 74 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13 75 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13 76 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14 77 5.2.2. Adjusting video target rate and sending rate . . . . 15 78 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15 79 6. Discussions and Further Investigations . . . . . . . . . . . 16 80 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16 81 6.2. Method for delay, loss, and marking ratio estimation . . 16 82 6.3. Impact of parameter values . . . . . . . . . . . . . . . 17 83 6.4. Sender-based vs. receiver-based calculation . . . . . . . 18 84 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 85 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 10.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Appendix A. Network Node Operations . . . . . . . . . . . . . . 21 92 A.1. Default behavior of drop tail queues . . . . . . . . . . 22 93 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 22 94 A.3. Random Early Marking with Virtual Queues . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 Interactive real-time media applications introduce a unique set of 100 challenges for congestion control. Unlike TCP, the mechanism used 101 for real-time media needs to adapt quickly to instantaneous bandwidth 102 changes, accommodate fluctuations in the output of video encoder rate 103 control, and cause low queuing delay over the network. An ideal 104 scheme should also make effective use of all types of congestion 105 signals, including packet loss, queuing delay, and explicit 106 congestion notification (ECN) [RFC3168] markings. The requirements 107 for the congestion control algorithm are outlined in 108 [I-D.ietf-rmcat-cc-requirements]. 110 This document describes an experimental congestion control scheme 111 called network-assisted dynamic adaptation (NADA). The NADA design 112 benefits from explicit congestion control signals (e.g., ECN 113 markings) from the network, yet also operates when only implicit 114 congestion indicators (delay and/or loss) are available. Such a 115 unified sender behavior distinguishes NADA from other congestion 116 control schemes for real-time media. In addition, its core 117 congestion control algorithm is designed to guarantee stability for 118 path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms 119 with default parameter choices). It further supports weighted 120 bandwidth sharing among competing video flows with different 121 priorities. The signaling mechanism consists of standard RTP 122 timestamp [RFC3550] and RTCP feedback reports with non-standard 123 messages. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described [RFC2119]. 131 3. System Overview 133 Figure 1 shows the end-to-end system for real-time media transport 134 that NADA operates in. Note that there also exist network nodes 135 along the reverse (potentially uncongested) path that the RTCP 136 feedback reports traverse. Those network nodes are not shown in the 137 figure for sake of abrevity. 139 +---------+ r_vin +--------+ +--------+ +----------+ 140 | Media |<--------| RTP | |Network | | RTP | 141 | Encoder |========>| Sender |=======>| Node |====>| Receiver | 142 +---------+ r_vout +--------+ r_send +--------+ +----------+ 143 /|\ | 144 | | 145 +---------------------------------+ 146 RTCP Feedback Report 148 Figure 1: System Overview 150 o Media encoder with rate control capabilities. It encodes raw 151 media (audio and video) frames into compressed bitstream which is 152 later packetized into RTP packets. As discussed in 153 [I-D.ietf-rmcat-video-traffic-model], the actual output rate from 154 the encoder r_vout may fluctuate around the target r_vin. 155 Furthermore, it is possible that the encoder can only react to bit 156 rate changes at rather coarse time intervals, e.g., once every 0.5 157 seconds. 159 o RTP sender: responsible for calculating the NADA reference rate 160 based on network congestion indicators (delay, loss, or ECN 161 marking reports from the receiver), for updating the video encoder 162 with a new target rate r_vin, and for regulating the actual 163 sending rate r_send accordingly. The RTP sender also generates a 164 sending timestamp for each outgoing packet. 166 o RTP receiver: responsible for measuring and estimating end-to-end 167 delay (based on sender timestamp), packet loss (based on RTP 168 sequence number), ECN marking ratios (based on [RFC6679]), and 169 receiving rate (r_recv) of the flow. It calculates the aggregated 170 congestion signal (x_curr) that accounts for queuing delay, ECN 171 markings, and packet losses. The receiver also determines the 172 mode for sender rate adaptation (rmode) based on whether the flow 173 has encountered any standing non-zero congestion. The receiver 174 sends periodic RTCP reports back to the sender, containing values 175 of x_curr, rmode, and r_recv. 177 o Network node with several modes of operation. The system can work 178 with the default behavior of a simple drop tail queue. It can 179 also benefit from advanced AQM features such as PIE, FQ-CoDel, 180 RED-based ECN marking, and PCN marking using a token bucket 181 algorithm. Note that network node operation is out of control for 182 the design of NADA. 184 4. Core Congestion Control Algorithm 186 Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA 187 is a rate-based congestion control algorithm. In its simplest form, 188 the sender reacts to the collection of network congestion indicators 189 in the form of an aggregated congestion signal, and operates in one 190 of two modes: 192 o Accelerated ramp-up: when the bottleneck is deemed to be 193 underutilized, the rate increases multiplicatively with respect to 194 the rate of previously successful transmissions. The rate 195 increase mutliplier (gamma) is calculated based on observed round- 196 trip-time and target feedback interval, so as to limit self- 197 inflicted queuing delay. 199 o Gradual rate update: in the presence of non-zero aggregate 200 congestion signal, the sending rate is adjusted in reaction to 201 both its value (x_curr) and its change in value (x_diff). 203 This section introduces the list of mathematical notations and 204 describes the core congestion control algorithm at the sender and 205 receiver, respectively. Additional details on recommended practical 206 implementations are described in Section 5.1 and Section 5.2. 208 4.1. Mathematical Notations 210 This section summarizes the list of variables and parameters used in 211 the NADA algorithm. 213 +--------------+-------------------------------------------------+ 214 | Notation | Variable Name | 215 +--------------+-------------------------------------------------+ 216 | t_curr | Current timestamp | 217 | t_last | Last time sending/receiving a feedback | 218 | delta | Observed interval between current and previous | 219 | | feedback reports: delta = t_curr-t_last | 220 | r_ref | Reference rate based on network congestion | 221 | r_send | Sending rate | 222 | r_recv | Receiving rate | 223 | r_vin | Target rate for video encoder | 224 | r_vout | Output rate from video encoder | 225 | d_base | Estimated baseline delay | 226 | d_fwd | Measured and filtered one-way delay | 227 | d_queue | Estimated queueing delay | 228 | d_tilde | Equivalent delay after non-linear warping | 229 | p_mark | Estimated packet ECN marking ratio | 230 | p_loss | Estimated packet loss ratio | 231 | x_curr | Aggregate congestion signal | 232 | x_prev | Previous value of aggregate congestion signal | 233 | x_diff | Change in aggregate congestion signal w.r.t. | 234 | | its previous value: x_diff = x_curr - x_prev | 235 | rmode | Rate update mode: (0 = accelerated ramp-up; | 236 | | 1 = gradual update) | 237 | gamma | Rate increase multiplier in accelerated ramp-up | 238 | | mode | 239 | rtt | Estimated round-trip-time at sender | 240 | buffer_len | Rate shaping buffer occupancy measured in bytes | 241 +--------------+-------------------------------------------------+ 243 Figure 2: List of variables. 245 +---------------+---------------------------------+----------------+ 246 | Notation | Parameter Name | Default Value | 247 +--------------+----------------------------------+----------------+ 248 | PRIO | Weight of priority of the flow | 1.0 249 | RMIN | Minimum rate of application | 150 Kbps | 250 | | supported by media encoder | | 251 | RMAX | Maximum rate of application | 1.5 Mbps | 252 | | supported by media encoder | | 253 | XREF | Reference congestion level | 20ms | 254 | KAPPA | Scaling parameter for gradual | 0.5 | 255 | | rate update calculation | | 256 | ETA | Scaling parameter for gradual | 2.0 | 257 | | rate update calculation | | 258 | TAU | Upper bound of RTT in gradual | 500ms | 259 | | rate update calculation | | 260 | DELTA | Target feedback interval | 100ms | 261 | DFILT | Bound on filtering delay | 120ms | 262 | LOGWIN | Observation window in time for | 500ms | 263 | | calculating packet summary | | 264 | | statistics at receiver | | 265 | QEPS | Threshold for determining queuing| 10ms | 266 | | delay build up at receiver | | 267 +..............+..................................+................+ 268 | QTH | Delay threshold for non-linear | 50ms | 269 | | warping | | 270 | QMAX | Delay upper bound for non-linear | 400ms | 271 | | warping | | 272 | DLOSS | Delay penalty for loss | 1.0s | 273 | DMARK | Delay penalty for ECN marking | 200ms | 274 +..............+..................................+................+ 275 | GAMMA_MAX | Upper bound on rate increase | 50% | 276 | | ratio for accelerated ramp-up | | 277 | QBOUND | Upper bound on self-inflicted | 50ms | 278 | | queuing delay during ramp up | | 279 +..............+..................................+................+ 280 | FPS | Frame rate of incoming video | 30 | 281 | BETA_S | Scaling parameter for modulating | 0.1 | 282 | | outgoing sending rate | | 283 | BETA_V | Scaling parameter for modulating | 0.1 | 284 | | video encoder target rate | | 285 | ALPHA | Smoothing factor in exponential | 0.1 | 286 | | smoothing of packet loss and | | 287 | | marking ratios | 288 +--------------+----------------------------------+----------------+ 290 Figure 3: List of algorithm parameters. 292 4.2. Receiver-Side Algorithm 294 The receiver-side algorithm can be outlined as below: 296 On initialization: 297 set d_base = +INFINITY 298 set p_loss = 0 299 set p_mark = 0 300 set r_recv = 0 301 set both t_last and t_curr as current time 303 On receiving a media packet: 304 obtain current timestamp t_curr from system clock 305 obtain from packet header sending time stamp t_sent 306 obtain one-way delay measurement: d_fwd = t_curr - t_sent 307 update baseline delay: d_base = min(d_base, d_fwd) 308 update queuing delay: d_queue = d_fwd - d_base 309 update packet loss ratio estimate p_loss 310 update packet marking ratio estimate p_mark 311 update measurement of receiving rate r_recv 313 On time to send a new feedback report (t_curr - t_last > DELTA): 314 calculate non-linear warping of delay d_tilde if packet loss exists 315 calculate current aggregate congestion signal x_curr 316 determine mode of rate adaptation for sender: rmode 317 send RTCP feedback report containing values of: rmode, x_curr, and r_recv 318 update t_last = t_curr 320 In order for a delay-based flow to hold its ground when competing 321 against loss-based flows (e.g., loss-based TCP), it is important to 322 distinguish between different levels of observed queuing delay. For 323 instance, a moderate queuing delay value below 100ms is likely self- 324 inflicted or induced by other delay-based flows, whereas a high 325 queuing delay value of several hundreds of milliseconds may indicate 326 the presence of a loss-based flow that does not refrain from 327 increased delay. 329 When packet losses are observed, the estimated queuing delay follows 330 a non-linear warping inspired by the delay-adaptive congestion window 331 backoff policy in [Budzisz-TON11]: 333 / d_queue, if d_queue |||||||||=================> 553 +----------+ -----------+ RTP packets 554 Rate Shaping Buffer 556 Figure 4: NADA Sender Structure 558 5.2.1. Rate shaping buffer 560 The operation of the live video encoder is out of the scope of the 561 design for the congestion control scheme in NADA. Instead, its 562 behavior is treated as a black box. 564 A rate shaping buffer is employed to absorb any instantaneous 565 mismatch between encoder rate output r_vout and regulated sending 566 rate r_send. Its current level of occupancy is measured in bytes and 567 is denoted as buffer_len. 569 A large rate shaping buffer contributes to higher end-to-end delay, 570 which may harm the performance of real-time media communications. 571 Therefore, the sender has a strong incentive to prevent the rate 572 shaping buffer from building up. The mechanisms adopted are: 574 o To deplete the rate shaping buffer faster by increasing the 575 sending rate r_send; and 577 o To limit incoming packets of the rate shaping buffer by reducing 578 the video encoder target rate r_vin. 580 5.2.2. Adjusting video target rate and sending rate 582 The target rate for the live video encoder deviates from the network 583 congestion control rate r_ref based on the level of occupancy in the 584 rate shaping buffer: 586 r_vin = r_ref - BETA_V*8*buffer_len*FPS. (11) 588 The actual sending rate r_send is regulated in a similar fashion: 590 r_send = r_ref + BETA_S*8*buffer_len*FPS. (12) 592 In (11) and (12), the first term indicates the rate calculated from 593 network congestion feedback alone. The second term indicates the 594 influence of the rate shaping buffer. A large rate shaping buffer 595 nudges the encoder target rate slightly below -- and the sending rate 596 slightly above -- the reference rate r_ref. 598 Intuitively, the amount of extra rate offset needed to completely 599 drain the rate shaping buffer within the duration of a single video 600 frame is given by 8*buffer_len*FPS, where FPS stands for the frame 601 rate of the video. The scaling parameters BETA_V and BETA_S can be 602 tuned to balance between the competing goals of maintaining a small 603 rate shaping buffer and deviating from the reference rate point. 605 5.3. Feedback Message Requirements 607 The following list of information is required for NADA congestion 608 control to function properly: 610 o Recommended rate adaptation mode (rmode): a 1-bit flag indicating 611 whether the sender should operate in accelerated ramp-up mode 612 (rmode=0) or gradual update mode (rmode=1). 614 o Aggregated congestion signal (x_curr): the most recently updated 615 value, calculated by the receiver according to Section 4.2. This 616 information is expressed with a unit of 100 microsecond (i.e., 617 1/10 of a millisecond) in 15 bits. This allows a maximum value of 618 x_curr at approximately 3.27 second. 620 o Receiving rate (r_recv): the most recently measured receiving rate 621 according to Section 5.1.3. This information is expressed with a 622 unit of 10 Kilobits per second (Kbps) in 16 bits. This allows a 623 maximum rate of approximately 6.55Mbps. 625 The above list of information can be accommodated by 32 bits in 626 total. Choice of the feedback message interval DELTA is discussed in 627 Section 6.3 A target feedback interval of DELTA=100ms is recommended. 629 6. Discussions and Further Investigations 631 6.1. Choice of delay metrics 633 The current design works with relative one-way-delay (OWD) as the 634 main indication of congestion. The value of the relative OWD is 635 obtained by maintaining the minimum value of observed OWD over a 636 relatively long time horizon and subtract that out from the observed 637 absolute OWD value. Such an approach cancels out the fixed 638 difference between the sender and receiver clocks. It has been 639 widely adopted by other delay-based congestion control approaches 640 such as [RFC6817]. As discussed in [RFC6817], the time horizon for 641 tracking the minimum OWD needs to be chosen with care: it must be 642 long enough for an opportunity to observe the minimum OWD with zero 643 standing queue along the path, and sufficiently short so as to timely 644 reflect "true" changes in minimum OWD introduced by route changes and 645 other rare events. 647 The potential drawback in relying on relative OWD as the congestion 648 signal is that when multiple flows share the same bottleneck, the 649 flow arriving late at the network experiencing a non-empty queue may 650 mistakenly consider the standing queuing delay as part of the fixed 651 path propagation delay. This will lead to slightly unfair bandwidth 652 sharing among the flows. 654 Alternatively, one could move the per-packet statistical handling to 655 the sender instead and use relative round-trip-time (RTT) in lieu of 656 relative OWD, assuming that per-packet acknowledgements are 657 available. The main drawback of RTT-based approach is the noise in 658 the measured delay in the reverse direction. 660 Note that the choice of either delay metric (relative OWD vs. RTT) 661 involves no change in the proposed rate adaptation algorithm. 662 Therefore, comparing the pros and cons regarding which delay metric 663 to adopt can be kept as an orthogonal direction of investigation. 665 6.2. Method for delay, loss, and marking ratio estimation 667 Like other delay-based congestion control schemes, performance of 668 NADA depends on the accuracy of its delay measurement and estimation 669 module. Appendix A in [RFC6817] provides an extensive discussion on 670 this aspect. 672 The current recommended practice of simply applying a 15-tab minimum 673 filter suffices in guarding against processing delay outliers 674 observed in wired connections. For wireless connections with a 675 higher packet delay variation (PDV), more sophisticated techniques on 676 de-noising, outlier rejection, and trend analysis may be needed. 678 More sophisticated methods in packet loss ratio calculation, such as 679 that adopted by [Floyd-CCR00], will likely be beneficial. These 680 alternatives are currently under investigation. 682 6.3. Impact of parameter values 684 In the gradual rate update mode, the parameter TAU indicates the 685 upper bound of round-trip-time (RTT) in feedback control loop. 686 Typically, the observed feedback interval delta is close to the 687 target feedback interval DELTA, and the relative ratio of delta/TAU 688 versus ETA dictates the relative strength of influence from the 689 aggregate congestion signal offset term (x_offset) versus its recent 690 change (x_diff), respectively. These two terms are analogous to the 691 integral and proportional terms in a proportional-integral (PI) 692 controller. The recommended choice of TAU=500ms, DELTA=100ms and ETA 693 = 2.0 corresponds to a relative ratio of 1:10 between the gains of 694 the integral and proportional terms. Consequently, the rate 695 adaptation is mostly driven by the change in the congestion signal 696 with a long-term shift towards its equilibrium value driven by the 697 offset term. Finally, the scaling parameter KAPPA determines the 698 overall speed of the adaptation and needs to strike a balance between 699 responsiveness and stability. 701 The choice of the target feedback interval DELTA needs to strike the 702 right balance between timely feedback and low RTCP feedback message 703 counts. A target feedback interval of DELTA=100ms is recommended, 704 corresponding to a feedback bandwidth of 16Kbps with 200 bytes per 705 feedback message --- less than 0.1% overhead for a 1 Mbps flow. 706 Furthermore, both simulation studies and frequency-domain analysis 707 have established that a feedback interval below 250ms will not break 708 up the feedback control loop of NADA congestion control. 710 In calculating the non-linear warping of delay in (1), the current 711 design uses fixed values of QTH and QMAX. It is possible to adapt 712 the value of both based on past observations of queuing delay in the 713 presence of packet losses. 715 In calculating the aggregate congestion signal x_curr, the choice of 716 DMARK and DLOSS influence the steady-state packet loss/marking ratio 717 experienced by the flow at a given available bandwidth. Higher 718 values of DMARK and DLOSS result in lower steady-state loss/marking 719 ratios, but are more susceptible to the impact of individual packet 720 loss/marking events. While the value of DMARK and DLOSS are fixed 721 and predetermined in the current design, a scheme for automatically 722 tuning these values based on desired bandwidth sharing behavior in 723 the presence of other competing loss-based flows (e.g., loss-based 724 TCP) is under investigation. 726 [Editor's note: Choice of start value: is this in scope of congestion 727 control, or should this be decided by the application?] 729 6.4. Sender-based vs. receiver-based calculation 731 In the current design, the aggregated congestion signal x_curr is 732 calculated at the receiver, keeping the sender operation completely 733 independent of the form of actual network congestion indications 734 (delay, loss, or marking). Alternatively, one can move the logics of 735 (1) and (2) to the sender. Such an approach requires slightly higher 736 overhead in the feedback messages, which should contain individual 737 fields on queuing delay (d_queue), packet loss ratio (p_loss), packet 738 marking ratio (p_mark), receiving rate (r_recv), and recommended rate 739 adaptation mode (rmode). 741 6.5. Incremental deployment 743 One nice property of NADA is the consistent video endpoint behavior 744 irrespective of network node variations. This facilitates gradual, 745 incremental adoption of the scheme. 747 To start off with, the proposed congestion control mechanism can be 748 implemented without any explicit support from the network, and relies 749 solely on observed one-way delay measurements and packet loss ratios 750 as implicit congestion signals. 752 When ECN is enabled at the network nodes with RED-based marking, the 753 receiver can fold its observations of ECN markings into the 754 calculation of the equivalent delay. The sender can react to these 755 explicit congestion signals without any modification. 757 Ultimately, networks equipped with proactive marking based on token 758 bucket level metering can reap the additional benefits of zero 759 standing queues and lower end-to-end delay and work seamlessly with 760 existing senders and receivers. 762 7. Implementation Status 764 The NADA scheme has been implemented in [ns-2] and [ns-3] simulation 765 platforms. Extensive ns-2 simulation evaluations of an earlier 766 version of the draft are documented in [Zhu-PV13]. Evaluation 767 results of the current draft over several test cases in 768 [I-D.ietf-rmcat-eval-test] have been presented at recent IETF 769 meetings [IETF-90][IETF-91]. Evaluation results of the current draft 770 over several test cases in [I-D.ietf-rmcat-wireless-tests] have been 771 presented at [IETF-93]. 773 The scheme has also been implemented and evaluated in a lab setting 774 as described in [IETF-90]. Preliminary evaluation results of NADA in 775 single-flow and multi-flow scenarios have been presented in 776 [IETF-91]. 778 8. IANA Considerations 780 This document makes no request of IANA. 782 9. Acknowledgements 784 The authors would like to thank Randell Jesup, Luca De Cicco, Piers 785 O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, 786 Safiqul Islam, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for 787 their valuable questions and comments on earlier versions of this 788 draft. 790 10. References 792 10.1. Normative References 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, 796 DOI 10.17487/RFC2119, March 1997, 797 . 799 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 800 of Explicit Congestion Notification (ECN) to IP", 801 RFC 3168, DOI 10.17487/RFC3168, September 2001, 802 . 804 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 805 Jacobson, "RTP: A Transport Protocol for Real-Time 806 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 807 July 2003, . 809 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 810 and K. Carlberg, "Explicit Congestion Notification (ECN) 811 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 812 2012, . 814 [I-D.ietf-rmcat-eval-test] 815 Sarker, Z., Varun, V., Zhu, X., and M. Ramalho, "Test 816 Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- 817 eval-test-03 (work in progress), March 2016. 819 [I-D.ietf-rmcat-cc-requirements] 820 Jesup, R. and Z. Sarker, "Congestion Control Requirements 821 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 822 requirements-09 (work in progress), December 2014. 824 [I-D.ietf-rmcat-video-traffic-model] 825 Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic 826 Sources for RMCAT Evaluations", draft-ietf-rmcat-video- 827 traffic-model-00 (work in progress), January 2016. 829 [I-D.ietf-rmcat-cc-codec-interactions] 830 Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, 831 "Congestion Control and Codec interactions in RTP 832 Applications", draft-ietf-rmcat-cc-codec-interactions-01 833 (work in progress), October 2015. 835 [I-D.ietf-rmcat-wireless-tests] 836 Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and 837 M. Ramalho, "Evaluation Test Cases for Interactive Real- 838 Time Media over Wireless Networks", draft-ietf-rmcat- 839 wireless-tests-01 (work in progress), November 2015. 841 10.2. Informative References 843 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 844 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 845 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 846 S., Wroclawski, J., and L. Zhang, "Recommendations on 847 Queue Management and Congestion Avoidance in the 848 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 849 . 851 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 852 Friendly Rate Control (TFRC): Protocol Specification", 853 RFC 5348, DOI 10.17487/RFC5348, September 2008, 854 . 856 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 857 Pre-Congestion Notification (PCN) States in the IP Header 858 Using a Single Diffserv Codepoint (DSCP)", RFC 6660, 859 DOI 10.17487/RFC6660, July 2012, 860 . 862 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 863 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 864 DOI 10.17487/RFC6817, December 2012, 865 . 867 [Floyd-CCR00] 868 Floyd, S., Handley, M., Padhye, J., and J. Widmer, 869 "Equation-based Congestion Control for Unicast 870 Applications", ACM SIGCOMM Computer Communications 871 Review vol. 30, no. 4, pp. 43-56, October 2000. 873 [Budzisz-TON11] 874 Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and 875 R. Shorten, "On the Fair Coexistence of Loss- and Delay- 876 Based TCP", IEEE/ACM Transactions on Networking vol. 19, 877 no. 6, pp. 1811-1824, December 2011. 879 [Zhu-PV13] 880 Zhu, X. and R. Pan, "NADA: A Unified Congestion Control 881 Scheme for Low-Latency Interactive Video", in Proc. IEEE 882 International Packet Video Workshop (PV'13) San Jose, CA, 883 USA, December 2013. 885 [ns-2] "The Network Simulator - ns-2", 886 . 888 [ns-3] "The Network Simulator - ns-3", . 890 [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, 891 "NADA Update: Algorithm, Implementation, and Test Case 892 Evalua6on Results", July 2014, 893 . 896 [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., 897 Jones, P., and S. D'Aronco, "NADA Algorithm Update and 898 Test Case Evaluations", November 2014, 899 . 902 [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., 903 Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA", 904 July 2015, . 907 Appendix A. Network Node Operations 909 NADA can work with different network queue management schemes and 910 does not assume any specific network node operation. As an example, 911 this appendix describes three variants of queue management behavior 912 at the network node, leading to either implicit or explicit 913 congestion signals. 915 In all three flavors described below, the network queue operates with 916 the simple first-in-first-out (FIFO) principle. There is no need to 917 maintain per-flow state. The system can scale easily with a large 918 number of video flows and at high link capacity. 920 A.1. Default behavior of drop tail queues 922 In a conventional network with drop tail or RED queues, congestion is 923 inferred from the estimation of end-to-end delay and/or packet loss. 924 Packet drops at the queue are detected at the receiver, and 925 contributes to the calculation of the aggregated congestion signal 926 x_curr. No special action is required at network node. 928 A.2. RED-based ECN marking 930 In this mode, the network node randomly marks the ECN field in the IP 931 packet header following the Random Early Detection (RED) algorithm 932 [RFC2309]. Calculation of the marking probability involves the 933 following steps: 935 on packet arrival: 936 update smoothed queue size q_avg as: 937 q_avg = w*q + (1-w)*q_avg. 939 calculate marking probability p as: 941 / 0, if q < q_lo; 942 | 943 | q_avg - q_lo 944 p= < p_max*--------------, if q_lo <= q < q_hi; 945 | q_hi - q_lo 946 | 947 \ p = 1, if q >= q_hi. 949 Here, q_lo and q_hi corresponds to the low and high thresholds of 950 queue occupancy. The maximum marking probability is p_max. 952 The ECN markings events will contribute to the calculation of an 953 equivalent delay x_curr at the receiver. No changes are required at 954 the sender. 956 A.3. Random Early Marking with Virtual Queues 958 Advanced network nodes may support random early marking based on a 959 token bucket algorithm originally designed for Pre-Congestion 960 Notification (PCN) [RFC6660]. The early congestion notification 961 (ECN) bit in the IP header of packets are marked randomly. The 962 marking probability is calculated based on a token-bucket algorithm 963 originally designed for the Pre-Congestion Notification (PCN) 964 [RFC6660]. The target link utilization is set as 90%; the marking 965 probability is designed to grow linearly with the token bucket size 966 when it varies between 1/3 and 2/3 of the full token bucket limit. 968 * upon packet arrival, meter packet against token bucket (r,b); 970 * update token level b_tk; 972 * calculate the marking probability as: 974 / 0, if b-b_tk < b_lo; 975 | 976 | b-b_tk-b_lo 977 p = < p_max* --------------, if b_lo<= b-b_tk =b_hi. 982 Here, the token bucket lower and upper limits are denoted by b_lo and 983 b_hi, respectively. The parameter b indicates the size of the token 984 bucket. The parameter r is chosen to be below capacity, resulting in 985 slight under-utilization of the link. The maximum marking 986 probability is p_max. 988 The ECN markings events will contribute to the calculation of an 989 equivalent delay x_curr at the receiver. No changes are required at 990 the sender. The virtual queuing mechanism from the PCN-based marking 991 algorithm will lead to additional benefits such as zero standing 992 queues. 994 Authors' Addresses 996 Xiaoqing Zhu 997 Cisco Systems 998 12515 Research Blvd., Building 4 999 Austin, TX 78759 1000 USA 1002 Email: xiaoqzhu@cisco.com 1003 Rong Pan 1004 Cisco Systems 1005 3625 Cisco Way 1006 San Jose, CA 95134 1007 USA 1009 Email: ropan@cisco.com 1011 Michael A. Ramalho 1012 Cisco Systems, Inc. 1013 8000 Hawkins Road 1014 Sarasota, FL 34241 1015 USA 1017 Phone: +1 919 476 2038 1018 Email: mramalho@cisco.com 1020 Sergio Mena de la Cruz 1021 Cisco Systems 1022 EPFL, Quartier de l'Innovation, Batiment E 1023 Ecublens, Vaud 1015 1024 Switzerland 1026 Email: semena@cisco.com 1028 Paul E. Jones 1029 Cisco Systems 1030 7025 Kit Creek Rd. 1031 Research Triangle Park, NC 27709 1032 USA 1034 Email: paulej@packetizer.com 1036 Jiantao Fu 1037 Cisco Systems 1038 707 Tasman Drive 1039 Milpitas, CA 95035 1040 USA 1042 Email: jianfu@cisco.com 1043 Stefano D'Aronco 1044 Ecole Polytechnique Federale de Lausanne 1045 EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11 1046 Lausanne CH-1015 1047 Switzerland 1049 Email: stefano.daronco@epfl.ch 1051 Charles Ganzhorn 1052 7900 International Drive, International Plaza, Suite 400 1053 Bloomington, MN 55425 1054 USA 1056 Email: charles.ganzhorn@gmail.com