idnits 2.17.1 draft-ietf-rmcat-nada-03.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 425 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 (September 18, 2016) is 2776 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RMIN' is mentioned on line 398, but not defined == Missing Reference: 'RMAX' is mentioned on line 398, 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-01 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-wireless-tests-02 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 2 errors (**), 0 flaws (~~), 8 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: March 22, 2017 S. Mena 6 P. Jones 7 J. Fu 8 Cisco Systems 9 S. D'Aronco 10 EPFL 11 C. Ganzhorn 12 September 18, 2016 14 NADA: A Unified Congestion Control Scheme for Real-Time Media 15 draft-ietf-rmcat-nada-03 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 March 22, 2017. 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 . . . . . . . . . . . . . . . . . . 9 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. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 91 11.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Appendix A. Network Node Operations . . . . . . . . . . . . . . 22 93 A.1. Default behavior of drop tail queues . . . . . . . . . . 22 94 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23 95 A.3. Random Early Marking with Virtual Queues . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 Interactive real-time media applications introduce a unique set of 101 challenges for congestion control. Unlike TCP, the mechanism used 102 for 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. The requirements 108 for the congestion control algorithm are outlined in 109 [I-D.ietf-rmcat-cc-requirements]. 111 This document describes an experimental congestion control scheme 112 called network-assisted dynamic adaptation (NADA). The NADA design 113 benefits from explicit congestion control signals (e.g., ECN 114 markings) from the network, yet also operates when only implicit 115 congestion indicators (delay and/or loss) are available. Such a 116 unified sender behavior distinguishes NADA from other congestion 117 control schemes for real-time media. In addition, its core 118 congestion control algorithm is designed to guarantee stability for 119 path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms 120 with default parameter choices). It further supports weighted 121 bandwidth sharing among competing video flows with different 122 priorities. The signaling mechanism consists of standard RTP 123 timestamp [RFC3550] and RTCP feedback reports with non-standard 124 messages. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described [RFC2119]. 132 3. System Overview 134 Figure 1 shows the end-to-end system for real-time media transport 135 that NADA operates in. Note that there also exist network nodes 136 along the reverse (potentially uncongested) path that the RTCP 137 feedback reports traverse. Those network nodes are not shown in the 138 figure for sake of abrevity. 140 +---------+ r_vin +--------+ +--------+ +----------+ 141 | Media |<--------| RTP | |Network | | RTP | 142 | Encoder |========>| Sender |=======>| Node |====>| Receiver | 143 +---------+ r_vout +--------+ r_send +--------+ +----------+ 144 /|\ | 145 | | 146 +---------------------------------+ 147 RTCP Feedback Report 149 Figure 1: System Overview 151 o Media encoder with rate control capabilities. It encodes raw 152 media (audio and video) frames into compressed bitstream which is 153 later packetized into RTP packets. As discussed in 154 [I-D.ietf-rmcat-video-traffic-model], the actual output rate from 155 the encoder r_vout may fluctuate around the target r_vin. 156 Furthermore, it is possible that the encoder can only react to bit 157 rate changes at rather coarse time intervals, e.g., once every 0.5 158 seconds. 160 o RTP sender: responsible for calculating the NADA reference rate 161 based on network congestion indicators (delay, loss, or ECN 162 marking reports from the receiver), for updating the video encoder 163 with a new target rate r_vin, and for regulating the actual 164 sending rate r_send accordingly. The RTP sender also generates a 165 sending timestamp for each outgoing packet. 167 o RTP receiver: responsible for measuring and estimating end-to-end 168 delay (based on sender timestamp), packet loss (based on RTP 169 sequence number), ECN marking ratios (based on [RFC6679]), and 170 receiving rate (r_recv) of the flow. It calculates the aggregated 171 congestion signal (x_curr) that accounts for queuing delay, ECN 172 markings, and packet losses. The receiver also determines the 173 mode for sender rate adaptation (rmode) based on whether the flow 174 has encountered any standing non-zero congestion. The receiver 175 sends periodic RTCP reports back to the sender, containing values 176 of x_curr, rmode, and r_recv. 178 o Network node with several modes of operation. The system can work 179 with the default behavior of a simple drop tail queue. It can 180 also benefit from advanced AQM features such as PIE, FQ-CoDel, 181 RED-based ECN marking, and PCN marking using a token bucket 182 algorithm. Note that network node operation is out of control for 183 the design of NADA. 185 4. Core Congestion Control Algorithm 187 Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA 188 is a rate-based congestion control algorithm. In its simplest form, 189 the sender reacts to the collection of network congestion indicators 190 in the form of an aggregated congestion signal, and operates in one 191 of two modes: 193 o Accelerated ramp-up: when the bottleneck is deemed to be 194 underutilized, the rate increases multiplicatively with respect to 195 the rate of previously successful transmissions. The rate 196 increase mutliplier (gamma) is calculated based on observed round- 197 trip-time and target feedback interval, so as to limit self- 198 inflicted queuing delay. 200 o Gradual rate update: in the presence of non-zero aggregate 201 congestion signal, the sending rate is adjusted in reaction to 202 both its value (x_curr) and its change in value (x_diff). 204 This section introduces the list of mathematical notations and 205 describes the core congestion control algorithm at the sender and 206 receiver, respectively. Additional details on recommended practical 207 implementations are described in Section 5.1 and Section 5.2. 209 4.1. Mathematical Notations 211 This section summarizes the list of variables and parameters used in 212 the NADA algorithm. 214 +--------------+-------------------------------------------------+ 215 | Notation | Variable Name | 216 +--------------+-------------------------------------------------+ 217 | t_curr | Current timestamp | 218 | t_last | Last time sending/receiving a feedback | 219 | delta | Observed interval between current and previous | 220 | | feedback reports: delta = t_curr-t_last | 221 | r_ref | Reference rate based on network congestion | 222 | r_send | Sending rate | 223 | r_recv | Receiving rate | 224 | r_vin | Target rate for video encoder | 225 | r_vout | Output rate from video encoder | 226 | d_base | Estimated baseline delay | 227 | d_fwd | Measured and filtered one-way delay | 228 | d_queue | Estimated queueing delay | 229 | d_tilde | Equivalent delay after non-linear warping | 230 | p_mark | Estimated packet ECN marking ratio | 231 | p_loss | Estimated packet loss ratio | 232 | x_curr | Aggregate congestion signal | 233 | x_prev | Previous value of aggregate congestion signal | 234 | x_diff | Change in aggregate congestion signal w.r.t. | 235 | | its previous value: x_diff = x_curr - x_prev | 236 | rmode | Rate update mode: (0 = accelerated ramp-up; | 237 | | 1 = gradual update) | 238 | gamma | Rate increase multiplier in accelerated ramp-up | 239 | | mode | 240 | rtt | Estimated round-trip-time at sender | 241 | buffer_len | Rate shaping buffer occupancy measured in bytes | 242 +--------------+-------------------------------------------------+ 244 Figure 2: List of variables. 246 +---------------+---------------------------------+----------------+ 247 | Notation | Parameter Name | Default Value | 248 +--------------+----------------------------------+----------------+ 249 | PRIO | Weight of priority of the flow | 1.0 250 | RMIN | Minimum rate of application | 150 Kbps | 251 | | supported by media encoder | | 252 | RMAX | Maximum rate of application | 1.5 Mbps | 253 | | supported by media encoder | | 254 | XREF | Reference congestion level | 20ms | 255 | KAPPA | Scaling parameter for gradual | 0.5 | 256 | | rate update calculation | | 257 | ETA | Scaling parameter for gradual | 2.0 | 258 | | rate update calculation | | 259 | TAU | Upper bound of RTT in gradual | 500ms | 260 | | rate update calculation | | 261 | DELTA | Target feedback interval | 100ms | 262 | DFILT | Bound on filtering delay | 120ms | 263 | LOGWIN | Observation window in time for | 500ms | 264 | | calculating packet summary | | 265 | | statistics at receiver | | 266 | TEXPLOSS | Expiration time for previously | 30s | 267 | | observed packet loss | | 268 | QEPS | Threshold for determining queuing| 10ms | 269 | | delay build up at receiver | | 270 +..............+..................................+................+ 271 | QTH | Delay threshold for non-linear | 50ms | 272 | | warping | | 273 | DLOSS | Delay penalty for loss | 1.0s | 274 | DMARK | Delay penalty for ECN marking | 200ms | 275 +..............+..................................+................+ 276 | GAMMA_MAX | Upper bound on rate increase | 50% | 277 | | ratio for accelerated ramp-up | | 278 | QBOUND | Upper bound on self-inflicted | 50ms | 279 | | queuing delay during ramp up | | 280 +..............+..................................+................+ 281 | FPS | Frame rate of incoming video | 30 | 282 | BETA_S | Scaling parameter for modulating | 0.1 | 283 | | outgoing sending rate | | 284 | BETA_V | Scaling parameter for modulating | 0.1 | 285 | | video encoder target rate | | 286 | ALPHA | Smoothing factor in exponential | 0.1 | 287 | | smoothing of packet loss and | | 288 | | marking ratios | 289 +--------------+----------------------------------+----------------+ 291 Figure 3: List of algorithm parameters. 293 4.2. Receiver-Side Algorithm 295 The receiver-side algorithm can be outlined as below: 297 On initialization: 298 set d_base = +INFINITY 299 set p_loss = 0 300 set p_mark = 0 301 set r_recv = 0 302 set both t_last and t_curr as current time 304 On receiving a media packet: 305 obtain current timestamp t_curr from system clock 306 obtain from packet header sending time stamp t_sent 307 obtain one-way delay measurement: d_fwd = t_curr - t_sent 308 update baseline delay: d_base = min(d_base, d_fwd) 309 update queuing delay: d_queue = d_fwd - d_base 310 update packet loss ratio estimate p_loss 311 update packet marking ratio estimate p_mark 312 update measurement of receiving rate r_recv 314 On time to send a new feedback report (t_curr - t_last > DELTA): 315 calculate non-linear warping of delay d_tilde if packet loss exists 316 calculate current aggregate congestion signal x_curr 317 determine mode of rate adaptation for sender: rmode 318 send RTCP feedback report containing values of: rmode, x_curr, and r_recv 319 update t_last = t_curr 321 In order for a delay-based flow to hold its ground when competing 322 against loss-based flows (e.g., loss-based TCP), it is important to 323 distinguish between different levels of observed queuing delay. For 324 instance, a moderate queuing delay value below 100ms is likely self- 325 inflicted or induced by other delay-based flows, whereas a high 326 queuing delay value of several hundreds of milliseconds may indicate 327 the presence of a loss-based flow that does not refrain from 328 increased delay. 330 If packet losses are observed within the previous time window of 331 TLOSS, the estimated queuing delay follows a non-linear warping: 333 / d_queue, if d_queue |||||||||=================> 556 +----------+ -----------+ RTP packets 557 Rate Shaping Buffer 559 Figure 4: NADA Sender Structure 561 5.2.1. Rate shaping buffer 563 The operation of the live video encoder is out of the scope of the 564 design for the congestion control scheme in NADA. Instead, its 565 behavior is treated as a black box. 567 A rate shaping buffer is employed to absorb any instantaneous 568 mismatch between encoder rate output r_vout and regulated sending 569 rate r_send. Its current level of occupancy is measured in bytes and 570 is denoted as buffer_len. 572 A large rate shaping buffer contributes to higher end-to-end delay, 573 which may harm the performance of real-time media communications. 574 Therefore, the sender has a strong incentive to prevent the rate 575 shaping buffer from building up. The mechanisms adopted are: 577 o To deplete the rate shaping buffer faster by increasing the 578 sending rate r_send; and 580 o To limit incoming packets of the rate shaping buffer by reducing 581 the video encoder target rate r_vin. 583 5.2.2. Adjusting video target rate and sending rate 585 The target rate for the live video encoder deviates from the network 586 congestion control rate r_ref based on the level of occupancy in the 587 rate shaping buffer: 589 r_vin = r_ref - BETA_V*8*buffer_len*FPS. (11) 591 The actual sending rate r_send is regulated in a similar fashion: 593 r_send = r_ref + BETA_S*8*buffer_len*FPS. (12) 595 In (11) and (12), the first term indicates the rate calculated from 596 network congestion feedback alone. The second term indicates the 597 influence of the rate shaping buffer. A large rate shaping buffer 598 nudges the encoder target rate slightly below -- and the sending rate 599 slightly above -- the reference rate r_ref. 601 Intuitively, the amount of extra rate offset needed to completely 602 drain the rate shaping buffer within the duration of a single video 603 frame is given by 8*buffer_len*FPS, where FPS stands for the frame 604 rate of the video. The scaling parameters BETA_V and BETA_S can be 605 tuned to balance between the competing goals of maintaining a small 606 rate shaping buffer and deviating from the reference rate point. 608 5.3. Feedback Message Requirements 610 The following list of information is required for NADA congestion 611 control to function properly: 613 o Recommended rate adaptation mode (rmode): a 1-bit flag indicating 614 whether the sender should operate in accelerated ramp-up mode 615 (rmode=0) or gradual update mode (rmode=1). 617 o Aggregated congestion signal (x_curr): the most recently updated 618 value, calculated by the receiver according to Section 4.2. This 619 information is expressed with a unit of 100 microsecond (i.e., 620 1/10 of a millisecond) in 15 bits. This allows a maximum value of 621 x_curr at approximately 3.27 second. 623 o Receiving rate (r_recv): the most recently measured receiving rate 624 according to Section 5.1.3. This information is expressed with a 625 unit of bits per second (bps) in 32 bits (unsigned int). This 626 allows a maximum rate of approximately 4.3Gbps. 628 The above list of information can be accommodated by 48 bits, or 6 629 bytes, in total. Choice of the feedback message interval DELTA is 630 discussed in Section 6.3 A target feedback interval of DELTA=100ms is 631 recommended. 633 6. Discussions and Further Investigations 635 6.1. Choice of delay metrics 637 The current design works with relative one-way-delay (OWD) as the 638 main indication of congestion. The value of the relative OWD is 639 obtained by maintaining the minimum value of observed OWD over a 640 relatively long time horizon and subtract that out from the observed 641 absolute OWD value. Such an approach cancels out the fixed 642 difference between the sender and receiver clocks. It has been 643 widely adopted by other delay-based congestion control approaches 644 such as [RFC6817]. As discussed in [RFC6817], the time horizon for 645 tracking the minimum OWD needs to be chosen with care: it must be 646 long enough for an opportunity to observe the minimum OWD with zero 647 standing queue along the path, and sufficiently short so as to timely 648 reflect "true" changes in minimum OWD introduced by route changes and 649 other rare events. 651 The potential drawback in relying on relative OWD as the congestion 652 signal is that when multiple flows share the same bottleneck, the 653 flow arriving late at the network experiencing a non-empty queue may 654 mistakenly consider the standing queuing delay as part of the fixed 655 path propagation delay. This will lead to slightly unfair bandwidth 656 sharing among the flows. 658 Alternatively, one could move the per-packet statistical handling to 659 the sender instead and use relative round-trip-time (RTT) in lieu of 660 relative OWD, assuming that per-packet acknowledgements are 661 available. The main drawback of RTT-based approach is the noise in 662 the measured delay in the reverse direction. 664 Note that the choice of either delay metric (relative OWD vs. RTT) 665 involves no change in the proposed rate adaptation algorithm. 666 Therefore, comparing the pros and cons regarding which delay metric 667 to adopt can be kept as an orthogonal direction of investigation. 669 6.2. Method for delay, loss, and marking ratio estimation 671 Like other delay-based congestion control schemes, performance of 672 NADA depends on the accuracy of its delay measurement and estimation 673 module. Appendix A in [RFC6817] provides an extensive discussion on 674 this aspect. 676 The current recommended practice of simply applying a 15-tab minimum 677 filter suffices in guarding against processing delay outliers 678 observed in wired connections. For wireless connections with a 679 higher packet delay variation (PDV), more sophisticated techniques on 680 de-noising, outlier rejection, and trend analysis may be needed. 682 More sophisticated methods in packet loss ratio calculation, such as 683 that adopted by [Floyd-CCR00], will likely be beneficial. These 684 alternatives are currently under investigation. 686 6.3. Impact of parameter values 688 In the gradual rate update mode, the parameter TAU indicates the 689 upper bound of round-trip-time (RTT) in feedback control loop. 690 Typically, the observed feedback interval delta is close to the 691 target feedback interval DELTA, and the relative ratio of delta/TAU 692 versus ETA dictates the relative strength of influence from the 693 aggregate congestion signal offset term (x_offset) versus its recent 694 change (x_diff), respectively. These two terms are analogous to the 695 integral and proportional terms in a proportional-integral (PI) 696 controller. The recommended choice of TAU=500ms, DELTA=100ms and ETA 697 = 2.0 corresponds to a relative ratio of 1:10 between the gains of 698 the integral and proportional terms. Consequently, the rate 699 adaptation is mostly driven by the change in the congestion signal 700 with a long-term shift towards its equilibrium value driven by the 701 offset term. Finally, the scaling parameter KAPPA determines the 702 overall speed of the adaptation and needs to strike a balance between 703 responsiveness and stability. 705 The choice of the target feedback interval DELTA needs to strike the 706 right balance between timely feedback and low RTCP feedback message 707 counts. A target feedback interval of DELTA=100ms is recommended, 708 corresponding to a feedback bandwidth of 16Kbps with 200 bytes per 709 feedback message --- approximately 1.6% overhead for a 1 Mbps flow. 710 Furthermore, both simulation studies and frequency-domain analysis 711 have established that a feedback interval below 250ms will not break 712 up the feedback control loop of NADA congestion control. 714 In calculating the non-linear warping of delay in (1), the current 715 design uses fixed values of QTH and TLOSS (for determining whether to 716 perform the non-linear warpming). It is possible to adapt the value 717 of both based on past observed patterns of queuing delay in the 718 presence of packet losses. 720 In calculating the aggregate congestion signal x_curr, the choice of 721 DMARK and DLOSS influence the steady-state packet loss/marking ratio 722 experienced by the flow at a given available bandwidth. Higher 723 values of DMARK and DLOSS result in lower steady-state loss/marking 724 ratios, but are more susceptible to the impact of individual packet 725 loss/marking events. While the value of DMARK and DLOSS are fixed 726 and predetermined in the current design, a scheme for automatically 727 tuning these values based on desired bandwidth sharing behavior in 728 the presence of other competing loss-based flows (e.g., loss-based 729 TCP) is under investigation. 731 [Editor's note: Choice of start value: is this in scope of congestion 732 control, or should this be decided by the application?] 734 6.4. Sender-based vs. receiver-based calculation 736 In the current design, the aggregated congestion signal x_curr is 737 calculated at the receiver, keeping the sender operation completely 738 independent of the form of actual network congestion indications 739 (delay, loss, or marking). Alternatively, one can move the logics of 740 (1) and (2) to the sender. Such an approach requires slightly higher 741 overhead in the feedback messages, which should contain individual 742 fields on queuing delay (d_queue), packet loss ratio (p_loss), packet 743 marking ratio (p_mark), receiving rate (r_recv), and recommended rate 744 adaptation mode (rmode). 746 6.5. Incremental deployment 748 One nice property of NADA is the consistent video endpoint behavior 749 irrespective of network node variations. This facilitates gradual, 750 incremental adoption of the scheme. 752 To start off with, the proposed congestion control mechanism can be 753 implemented without any explicit support from the network, and relies 754 solely on observed one-way delay measurements and packet loss ratios 755 as implicit congestion signals. 757 When ECN is enabled at the network nodes with RED-based marking, the 758 receiver can fold its observations of ECN markings into the 759 calculation of the equivalent delay. The sender can react to these 760 explicit congestion signals without any modification. 762 Ultimately, networks equipped with proactive marking based on token 763 bucket level metering can reap the additional benefits of zero 764 standing queues and lower end-to-end delay and work seamlessly with 765 existing senders and receivers. 767 7. Implementation Status 769 The NADA scheme has been implemented in [ns-2] and [ns-3] simulation 770 platforms. Extensive ns-2 simulation evaluations of an earlier 771 version of the draft are documented in [Zhu-PV13]. Evaluation 772 results of the current draft over several test cases in 773 [I-D.ietf-rmcat-eval-test] have been presented at recent IETF 774 meetings [IETF-90][IETF-91]. Evaluation results of the current draft 775 over several test cases in [I-D.ietf-rmcat-wireless-tests] have been 776 presented at [IETF-93]. 778 The scheme has also been implemented and evaluated in a lab setting 779 as described in [IETF-90]. Preliminary evaluation results of NADA in 780 single-flow and multi-flow scenarios have been presented in 781 [IETF-91]. 783 8. Suggested Experiments 785 NADA has been extensively evaluated under various test scenarios, 786 including the collection of test cases specified by 787 [I-D.ietf-rmcat-eval-test] and the subset of WiFi-based test cases in 788 [I-D.ietf-rmcat-wireless-tests]. Additional evaluations have been 789 carried out to characterize how NADA interacts with various active 790 queue management (AQM) schemes such as RED, CoDel, and PIE. Most of 791 these evaluations have been carried out in simulators. A few key 792 test cases have also bee evaluated in implementations embedded in 793 video conferencing clients. 795 Further experiments are suggested for the following scenarios: 797 o Experiments with ECN marking capability turned on at the network 798 for existing test cases. 800 o Experiments with multiple RMCAT streams bearing different user- 801 specified priorities. 803 o Experiments with additional access technologies, especially over 804 cellular networks such as 3G/LTE. 806 o Experiments with various media source contents, including audio 807 only, audio and video, and application content sharing (e.g., 808 slide shows). 810 o 812 9. IANA Considerations 814 This document makes no request of IANA. 816 10. Acknowledgements 818 The authors would like to thank Randell Jesup, Luca De Cicco, Piers 819 O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, 820 Safiqul Islam, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for 821 their valuable questions and comments on earlier versions of this 822 draft. 824 11. References 826 11.1. Normative References 828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 829 Requirement Levels", BCP 14, RFC 2119, 830 DOI 10.17487/RFC2119, March 1997, 831 . 833 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 834 of Explicit Congestion Notification (ECN) to IP", 835 RFC 3168, DOI 10.17487/RFC3168, September 2001, 836 . 838 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 839 Jacobson, "RTP: A Transport Protocol for Real-Time 840 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 841 July 2003, . 843 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 844 and K. Carlberg, "Explicit Congestion Notification (ECN) 845 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 846 2012, . 848 [I-D.ietf-rmcat-eval-test] 849 Sarker, Z., Singh, V., Zhu, X., and D. Ramalho, "Test 850 Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- 851 eval-test-03 (work in progress), March 2016. 853 [I-D.ietf-rmcat-cc-requirements] 854 Jesup, R. and Z. Sarker, "Congestion Control Requirements 855 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 856 requirements-09 (work in progress), December 2014. 858 [I-D.ietf-rmcat-video-traffic-model] 859 Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic 860 Sources for RMCAT Evaluations", draft-ietf-rmcat-video- 861 traffic-model-01 (work in progress), July 2016. 863 [I-D.ietf-rmcat-cc-codec-interactions] 864 Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, 865 "Congestion Control and Codec interactions in RTP 866 Applications", draft-ietf-rmcat-cc-codec-interactions-02 867 (work in progress), March 2016. 869 [I-D.ietf-rmcat-wireless-tests] 870 Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and 871 M. Ramalho, "Evaluation Test Cases for Interactive Real- 872 Time Media over Wireless Networks", draft-ietf-rmcat- 873 wireless-tests-02 (work in progress), May 2016. 875 11.2. Informative References 877 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 878 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 879 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 880 S., Wroclawski, J., and L. Zhang, "Recommendations on 881 Queue Management and Congestion Avoidance in the 882 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 883 . 885 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 886 Friendly Rate Control (TFRC): Protocol Specification", 887 RFC 5348, DOI 10.17487/RFC5348, September 2008, 888 . 890 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 891 Pre-Congestion Notification (PCN) States in the IP Header 892 Using a Single Diffserv Codepoint (DSCP)", RFC 6660, 893 DOI 10.17487/RFC6660, July 2012, 894 . 896 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 897 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 898 DOI 10.17487/RFC6817, December 2012, 899 . 901 [Floyd-CCR00] 902 Floyd, S., Handley, M., Padhye, J., and J. Widmer, 903 "Equation-based Congestion Control for Unicast 904 Applications", ACM SIGCOMM Computer Communications 905 Review vol. 30, no. 4, pp. 43-56, October 2000. 907 [Budzisz-TON11] 908 Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and 909 R. Shorten, "On the Fair Coexistence of Loss- and Delay- 910 Based TCP", IEEE/ACM Transactions on Networking vol. 19, 911 no. 6, pp. 1811-1824, December 2011. 913 [Zhu-PV13] 914 Zhu, X. and R. Pan, "NADA: A Unified Congestion Control 915 Scheme for Low-Latency Interactive Video", in Proc. IEEE 916 International Packet Video Workshop (PV'13) San Jose, CA, 917 USA, December 2013. 919 [ns-2] "The Network Simulator - ns-2", 920 . 922 [ns-3] "The Network Simulator - ns-3", . 924 [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, 925 "NADA Update: Algorithm, Implementation, and Test Case 926 Evalua6on Results", July 2014, 927 . 930 [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., 931 Jones, P., and S. D'Aronco, "NADA Algorithm Update and 932 Test Case Evaluations", November 2014, 933 . 936 [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., 937 Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA", 938 July 2015, . 941 Appendix A. Network Node Operations 943 NADA can work with different network queue management schemes and 944 does not assume any specific network node operation. As an example, 945 this appendix describes three variants of queue management behavior 946 at the network node, leading to either implicit or explicit 947 congestion signals. 949 In all three flavors described below, the network queue operates with 950 the simple first-in-first-out (FIFO) principle. There is no need to 951 maintain per-flow state. The system can scale easily with a large 952 number of video flows and at high link capacity. 954 A.1. Default behavior of drop tail queues 956 In a conventional network with drop tail or RED queues, congestion is 957 inferred from the estimation of end-to-end delay and/or packet loss. 958 Packet drops at the queue are detected at the receiver, and 959 contributes to the calculation of the aggregated congestion signal 960 x_curr. No special action is required at network node. 962 A.2. RED-based ECN marking 964 In this mode, the network node randomly marks the ECN field in the IP 965 packet header following the Random Early Detection (RED) algorithm 966 [RFC2309]. Calculation of the marking probability involves the 967 following steps: 969 on packet arrival: 970 update smoothed queue size q_avg as: 971 q_avg = w*q + (1-w)*q_avg. 973 calculate marking probability p as: 975 / 0, if q < q_lo; 976 | 977 | q_avg - q_lo 978 p= < p_max*--------------, if q_lo <= q < q_hi; 979 | q_hi - q_lo 980 | 981 \ p = 1, if q >= q_hi. 983 Here, q_lo and q_hi corresponds to the low and high thresholds of 984 queue occupancy. The maximum marking probability is p_max. 986 The ECN markings events will contribute to the calculation of an 987 equivalent delay x_curr at the receiver. No changes are required at 988 the sender. 990 A.3. Random Early Marking with Virtual Queues 992 Advanced network nodes may support random early marking based on a 993 token bucket algorithm originally designed for Pre-Congestion 994 Notification (PCN) [RFC6660]. The early congestion notification 995 (ECN) bit in the IP header of packets are marked randomly. The 996 marking probability is calculated based on a token-bucket algorithm 997 originally designed for the Pre-Congestion Notification (PCN) 998 [RFC6660]. The target link utilization is set as 90%; the marking 999 probability is designed to grow linearly with the token bucket size 1000 when it varies between 1/3 and 2/3 of the full token bucket limit. 1002 * upon packet arrival, meter packet against token bucket (r,b); 1004 * update token level b_tk; 1006 * calculate the marking probability as: 1008 / 0, if b-b_tk < b_lo; 1009 | 1010 | b-b_tk-b_lo 1011 p = < p_max* --------------, if b_lo<= b-b_tk =b_hi. 1016 Here, the token bucket lower and upper limits are denoted by b_lo and 1017 b_hi, respectively. The parameter b indicates the size of the token 1018 bucket. The parameter r is chosen to be below capacity, resulting in 1019 slight under-utilization of the link. The maximum marking 1020 probability is p_max. 1022 The ECN markings events will contribute to the calculation of an 1023 equivalent delay x_curr at the receiver. No changes are required at 1024 the sender. The virtual queuing mechanism from the PCN-based marking 1025 algorithm will lead to additional benefits such as zero standing 1026 queues. 1028 Authors' Addresses 1030 Xiaoqing Zhu 1031 Cisco Systems 1032 12515 Research Blvd., Building 4 1033 Austin, TX 78759 1034 USA 1036 Email: xiaoqzhu@cisco.com 1038 Rong Pan 1039 Cisco Systems 1040 3625 Cisco Way 1041 San Jose, CA 95134 1042 USA 1044 Email: ropan@cisco.com 1045 Michael A. Ramalho 1046 Cisco Systems, Inc. 1047 8000 Hawkins Road 1048 Sarasota, FL 34241 1049 USA 1051 Phone: +1 919 476 2038 1052 Email: mramalho@cisco.com 1054 Sergio Mena de la Cruz 1055 Cisco Systems 1056 EPFL, Quartier de l'Innovation, Batiment E 1057 Ecublens, Vaud 1015 1058 Switzerland 1060 Email: semena@cisco.com 1062 Paul E. Jones 1063 Cisco Systems 1064 7025 Kit Creek Rd. 1065 Research Triangle Park, NC 27709 1066 USA 1068 Email: paulej@packetizer.com 1070 Jiantao Fu 1071 Cisco Systems 1072 707 Tasman Drive 1073 Milpitas, CA 95035 1074 USA 1076 Email: jianfu@cisco.com 1078 Stefano D'Aronco 1079 Ecole Polytechnique Federale de Lausanne 1080 EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11 1081 Lausanne CH-1015 1082 Switzerland 1084 Email: stefano.daronco@epfl.ch 1085 Charles Ganzhorn 1086 7900 International Drive, International Plaza, Suite 400 1087 Bloomington, MN 55425 1088 USA 1090 Email: charles.ganzhorn@gmail.com