idnits 2.17.1 draft-ietf-rmcat-nada-06.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 are 2 instances 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 457 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 (December 3, 2017) is 2334 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RMIN' is mentioned on line 430, but not defined == Missing Reference: 'RMAX' is mentioned on line 430, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-rmcat-eval-test-05 == Outdated reference: A later version (-07) exists of draft-ietf-rmcat-video-traffic-model-03 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-wireless-tests-04 -- 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 Cisco Systems 4 Intended status: Experimental R. Pan 5 Expires: June 6, 2018 Pensando Systems 6 M. Ramalho 7 S. Mena 8 P. Jones 9 J. Fu 10 Cisco Systems 11 S. D'Aronco 12 EPFL 13 December 3, 2017 15 NADA: A Unified Congestion Control Scheme for Real-Time Media 16 draft-ietf-rmcat-nada-06 18 Abstract 20 This document describes NADA (network-assisted dynamic adaptation), a 21 novel congestion control scheme for interactive real-time media 22 applications, such as video conferencing. In the proposed scheme, 23 the sender regulates its sending rate based on either implicit or 24 explicit congestion signaling, in a unified approach. The scheme can 25 benefit from explicit congestion notification (ECN) markings from 26 network nodes. It also maintains consistent sender behavior in the 27 absence of such markings, by reacting to queuing delays and packet 28 losses instead. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 6, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5 68 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 69 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8 70 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10 71 5. Practical Implementation of NADA . . . . . . . . . . . . . . 12 72 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12 73 5.1.1. Estimation of one-way delay and queuing delay . . . . 12 74 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 13 75 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13 76 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13 77 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14 78 5.2.2. Adjusting video target rate and sending rate . . . . 15 79 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15 80 6. Discussions and Further Investigations . . . . . . . . . . . 16 81 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16 82 6.2. Method for delay, loss, and marking ratio estimation . . 16 83 6.3. Impact of parameter values . . . . . . . . . . . . . . . 17 84 6.4. Sender-based vs. receiver-based calculation . . . . . . . 18 85 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 86 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 87 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 92 11.2. Informative References . . . . . . . . . . . . . . . . . 20 93 Appendix A. Network Node Operations . . . . . . . . . . . . . . 23 94 A.1. Default behavior of drop tail queues . . . . . . . . . . 23 95 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23 96 A.3. Random Early Marking with Virtual Queues . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 99 1. Introduction 101 Interactive real-time media applications introduce a unique set of 102 challenges for congestion control. Unlike TCP, the mechanism used 103 for real-time media needs to adapt quickly to instantaneous bandwidth 104 changes, accommodate fluctuations in the output of video encoder rate 105 control, and cause low queuing delay over the network. An ideal 106 scheme should also make effective use of all types of congestion 107 signals, including packet loss, queuing delay, and explicit 108 congestion notification (ECN) [RFC3168] markings. The requirements 109 for the congestion control algorithm are outlined in 110 [I-D.ietf-rmcat-cc-requirements]. 112 This document describes an experimental congestion control scheme 113 called network-assisted dynamic adaptation (NADA). The NADA design 114 benefits from explicit congestion control signals (e.g., ECN 115 markings) from the network, yet also operates when only implicit 116 congestion indicators (delay and/or loss) are available. Such a 117 unified sender behavior distinguishes NADA from other congestion 118 control schemes for real-time media. In addition, its core 119 congestion control algorithm is designed to guarantee stability for 120 path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms 121 with default parameter choices). It further supports weighted 122 bandwidth sharing among competing video flows with different 123 priorities. The signaling mechanism consists of standard RTP 124 timestamp [RFC3550] and RTCP feedback reports with non-standard 125 messages. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described [RFC2119]. 133 3. System Overview 135 Figure 1 shows the end-to-end system for real-time media transport 136 that NADA operates in. Note that there also exist network nodes 137 along the reverse (potentially uncongested) path that the RTCP 138 feedback reports traverse. Those network nodes are not shown in the 139 figure for sake of abrevity. 141 +---------+ r_vin +--------+ +--------+ +----------+ 142 | Media |<--------| RTP | |Network | | RTP | 143 | Encoder |========>| Sender |=======>| Node |====>| Receiver | 144 +---------+ r_vout +--------+ r_send +--------+ +----------+ 145 /|\ | 146 | | 147 +---------------------------------+ 148 RTCP Feedback Report 150 Figure 1: System Overview 152 o Media encoder with rate control capabilities. It encodes raw 153 media (audio and video) frames into compressed bitstream which is 154 later packetized into RTP packets. As discussed in 155 [I-D.ietf-rmcat-video-traffic-model], the actual output rate from 156 the encoder r_vout may fluctuate around the target r_vin. 157 Furthermore, it is possible that the encoder can only react to bit 158 rate changes at rather coarse time intervals, e.g., once every 0.5 159 seconds. 161 o RTP sender: responsible for calculating the NADA reference rate 162 based on network congestion indicators (delay, loss, or ECN 163 marking reports from the receiver), for updating the video encoder 164 with a new target rate r_vin, and for regulating the actual 165 sending rate r_send accordingly. The RTP sender also generates a 166 sending timestamp for each outgoing packet. 168 o RTP receiver: responsible for measuring and estimating end-to-end 169 delay (based on sender timestamp), packet loss (based on RTP 170 sequence number), ECN marking ratios (based on [RFC6679]), and 171 receiving rate (r_recv) of the flow. It calculates the aggregated 172 congestion signal (x_curr) that accounts for queuing delay, ECN 173 markings, and packet losses. The receiver also determines the 174 mode for sender rate adaptation (rmode) based on whether the flow 175 has encountered any standing non-zero congestion. The receiver 176 sends periodic RTCP reports back to the sender, containing values 177 of x_curr, rmode, and r_recv. 179 o Network node with several modes of operation. The system can work 180 with the default behavior of a simple drop tail queue. It can 181 also benefit from advanced AQM features such as PIE, FQ-CoDel, 182 RED-based ECN marking, and PCN marking using a token bucket 183 algorithm. Note that network node operation is out of control for 184 the design of NADA. 186 4. Core Congestion Control Algorithm 188 Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA 189 is a rate-based congestion control algorithm. In its simplest form, 190 the sender reacts to the collection of network congestion indicators 191 in the form of an aggregated congestion signal, and operates in one 192 of two modes: 194 o Accelerated ramp-up: when the bottleneck is deemed to be 195 underutilized, the rate increases multiplicatively with respect to 196 the rate of previously successful transmissions. The rate 197 increase mutliplier (gamma) is calculated based on observed round- 198 trip-time and target feedback interval, so as to limit self- 199 inflicted queuing delay. 201 o Gradual rate update: in the presence of non-zero aggregate 202 congestion signal, the sending rate is adjusted in reaction to 203 both its value (x_curr) and its change in value (x_diff). 205 This section introduces the list of mathematical notations and 206 describes the core congestion control algorithm at the sender and 207 receiver, respectively. Additional details on recommended practical 208 implementations are described in Section 5.1 and Section 5.2. 210 4.1. Mathematical Notations 212 This section summarizes the list of variables and parameters used in 213 the NADA algorithm. 215 +--------------+-------------------------------------------------+ 216 | Notation | Variable Name | 217 +--------------+-------------------------------------------------+ 218 | t_curr | Current timestamp | 219 | t_last | Last time sending/receiving a feedback | 220 | delta | Observed interval between current and previous | 221 | | feedback reports: delta = t_curr-t_last | 222 | r_ref | Reference rate based on network congestion | 223 | r_send | Sending rate | 224 | r_recv | Receiving rate | 225 | r_vin | Target rate for video encoder | 226 | r_vout | Output rate from video encoder | 227 | d_base | Estimated baseline delay | 228 | d_fwd | Measured and filtered one-way delay | 229 | d_queue | Estimated queueing delay | 230 | d_tilde | Equivalent delay after non-linear warping | 231 | p_mark | Estimated packet ECN marking ratio | 232 | p_loss | Estimated packet loss ratio | 233 | x_curr | Aggregate congestion signal | 234 | x_prev | Previous value of aggregate congestion signal | 235 | x_diff | Change in aggregate congestion signal w.r.t. | 236 | | its previous value: x_diff = x_curr - x_prev | 237 | rmode | Rate update mode: (0 = accelerated ramp-up; | 238 | | 1 = gradual update) | 239 | gamma | Rate increase multiplier in accelerated ramp-up | 240 | | mode | 241 | loss_int | Measured average loss interval in packet count | 242 | loss_exp | Threshold value for setting the last observed | 243 | | packet loss to expiration | 244 | rtt | Estimated round-trip-time at sender | 245 | buffer_len | Rate shaping buffer occupancy measured in bytes | 246 +--------------+-------------------------------------------------+ 248 Figure 2: List of variables. 250 +--------------+----------------------------------+----------------+ 251 | Notation | Parameter Name | Default Value | 252 +--------------+----------------------------------+----------------+ 253 | PRIO | Weight of priority of the flow | 1.0 254 | RMIN | Minimum rate of application | 150 Kbps | 255 | | supported by media encoder | | 256 | RMAX | Maximum rate of application | 1.5 Mbps | 257 | | supported by media encoder | | 258 | XREF | Reference congestion level | 10ms | 259 | KAPPA | Scaling parameter for gradual | 0.5 | 260 | | rate update calculation | | 261 | ETA | Scaling parameter for gradual | 2.0 | 262 | | rate update calculation | | 263 | TAU | Upper bound of RTT in gradual | 500ms | 264 | | rate update calculation | | 265 | DELTA | Target feedback interval | 100ms | 266 +..............+..................................+................+ 267 | LOGWIN | Observation window in time for | 500ms | 268 | | calculating packet summary | | 269 | | statistics at receiver | | 270 | QEPS | Threshold for determining queuing| 10ms | 271 | | delay build up at receiver | | 272 | DFILT | Bound on filtering delay | 120ms | 273 | GAMMA_MAX | Upper bound on rate increase | 0.5 | 274 | | ratio for accelerated ramp-up | | 275 | QBOUND | Upper bound on self-inflicted | 50ms | 276 | | queuing delay during ramp up | | 277 +..............+..................................+................+ 278 | MULTILOSS | Multiplier for self-scaling the | 7. | 279 | | expiration threshold of the last | | 280 | | observed loss (loss_exp) based on| | 281 | | measured average loss interval | | 282 | | (loss_int) | | 283 | QTH | Delay threshold for invoking | 50ms | 284 | | non-linear warping | | 285 | LAMBDA | Scaling parameter in the | 0.5 | 286 | | exponent of non-linear warping | | 287 +..............+..................................+................+ 288 | PLRREF | Reference packet loss ratio | 0.01 | 289 | PMRREF | Reference packet marking ratio | 0.01 | 290 | DLOSS | Reference delay penalty for loss | 10ms | 291 | | when packet loss ratio is at | | 292 | | PLRREF | | 293 | DMARK | Reference delay penalty for ECN | 2ms | 294 | | marking when packet marking | | 295 | | is at PMRREF | | 296 +..............+..................................+................+ 297 | FPS | Frame rate of incoming video | 30 | 298 | BETA_S | Scaling parameter for modulating | 0.1 | 299 | | outgoing sending rate | | 300 | BETA_V | Scaling parameter for modulating | 0.1 | 301 | | video encoder target rate | | 302 | ALPHA | Smoothing factor in exponential | 0.1 | 303 | | smoothing of packet loss and | | 304 | | marking ratios | 305 +--------------+----------------------------------+----------------+ 307 Figure 3: List of algorithm parameters. 309 4.2. Receiver-Side Algorithm 311 The receiver-side algorithm can be outlined as below: 313 On initialization: 314 set d_base = +INFINITY 315 set p_loss = 0 316 set p_mark = 0 317 set r_recv = 0 318 set both t_last and t_curr as current time 320 On receiving a media packet: 321 obtain current timestamp t_curr from system clock 322 obtain from packet header sending time stamp t_sent 323 obtain one-way delay measurement: d_fwd = t_curr - t_sent 324 update baseline delay: d_base = min(d_base, d_fwd) 325 update queuing delay: d_queue = d_fwd - d_base 326 update packet loss ratio estimate p_loss 327 update packet marking ratio estimate p_mark 328 update measurement of receiving rate r_recv 330 On time to send a new feedback report (t_curr - t_last > DELTA): 331 calculate non-linear warping of delay d_tilde if packet loss exists 332 calculate current aggregate congestion signal x_curr 333 determine mode of rate adaptation for sender: rmode 334 send RTCP feedback report containing values of: rmode, x_curr, and r_recv 335 update t_last = t_curr 337 In order for a delay-based flow to hold its ground when competing 338 against loss-based flows (e.g., loss-based TCP), it is important to 339 distinguish between different levels of observed queuing delay. For 340 instance, over wired connections, a moderate queuing delay value 341 below 100ms is likely self-inflicted or induced by other delay-based 342 flows, whereas a high queuing delay value of several hundreds of 343 milliseconds may indicate the presence of a loss-based flow that does 344 not refrain from increased delay. 346 If the last observed packet loss is within the expiration window of 347 loss_exp (measured in terms of packet counts), the estimated queuing 348 delay follows a non-linear warping: 350 / d_queue, if d_queue |||||||||=================> 594 +----------+ -----------+ RTP packets 595 Rate Shaping Buffer 597 Figure 4: NADA Sender Structure 599 5.2.1. Rate shaping buffer 601 The operation of the live video encoder is out of the scope of the 602 design for the congestion control scheme in NADA. Instead, its 603 behavior is treated as a black box. 605 A rate shaping buffer is employed to absorb any instantaneous 606 mismatch between encoder rate output r_vout and regulated sending 607 rate r_send. Its current level of occupancy is measured in bytes and 608 is denoted as buffer_len. 610 A large rate shaping buffer contributes to higher end-to-end delay, 611 which may harm the performance of real-time media communications. 612 Therefore, the sender has a strong incentive to prevent the rate 613 shaping buffer from building up. The mechanisms adopted are: 615 o To deplete the rate shaping buffer faster by increasing the 616 sending rate r_send; and 618 o To limit incoming packets of the rate shaping buffer by reducing 619 the video encoder target rate r_vin. 621 5.2.2. Adjusting video target rate and sending rate 623 The target rate for the live video encoder deviates from the network 624 congestion control rate r_ref based on the level of occupancy in the 625 rate shaping buffer: 627 r_vin = r_ref - BETA_V*8*buffer_len*FPS. (11) 629 The actual sending rate r_send is regulated in a similar fashion: 631 r_send = r_ref + BETA_S*8*buffer_len*FPS. (12) 633 In (11) and (12), the first term indicates the rate calculated from 634 network congestion feedback alone. The second term indicates the 635 influence of the rate shaping buffer. A large rate shaping buffer 636 nudges the encoder target rate slightly below -- and the sending rate 637 slightly above -- the reference rate r_ref. 639 Intuitively, the amount of extra rate offset needed to completely 640 drain the rate shaping buffer within the duration of a single video 641 frame is given by 8*buffer_len*FPS, where FPS stands for the frame 642 rate of the video. The scaling parameters BETA_V and BETA_S can be 643 tuned to balance between the competing goals of maintaining a small 644 rate shaping buffer and deviating from the reference rate point. 646 5.3. Feedback Message Requirements 648 The following list of information is required for NADA congestion 649 control to function properly: 651 o Recommended rate adaptation mode (rmode): a 1-bit flag indicating 652 whether the sender should operate in accelerated ramp-up mode 653 (rmode=0) or gradual update mode (rmode=1). 655 o Aggregated congestion signal (x_curr): the most recently updated 656 value, calculated by the receiver according to Section 4.2. This 657 information is expressed with a unit of 100 microsecond (i.e., 658 1/10 of a millisecond) in 15 bits. This allows a maximum value of 659 x_curr at approximately 3.27 second. 661 o Receiving rate (r_recv): the most recently measured receiving rate 662 according to Section 5.1.3. This information is expressed with a 663 unit of bits per second (bps) in 32 bits (unsigned int). This 664 allows a maximum rate of approximately 4.3Gbps. 666 The above list of information can be accommodated by 48 bits, or 6 667 bytes, in total. Choice of the feedback message interval DELTA is 668 discussed in Section 6.3 A target feedback interval of DELTA=100ms is 669 recommended. 671 6. Discussions and Further Investigations 673 6.1. Choice of delay metrics 675 The current design works with relative one-way-delay (OWD) as the 676 main indication of congestion. The value of the relative OWD is 677 obtained by maintaining the minimum value of observed OWD over a 678 relatively long time horizon and subtract that out from the observed 679 absolute OWD value. Such an approach cancels out the fixed 680 difference between the sender and receiver clocks. It has been 681 widely adopted by other delay-based congestion control approaches 682 such as [RFC6817]. As discussed in [RFC6817], the time horizon for 683 tracking the minimum OWD needs to be chosen with care: it must be 684 long enough for an opportunity to observe the minimum OWD with zero 685 standing queue along the path, and sufficiently short so as to timely 686 reflect "true" changes in minimum OWD introduced by route changes and 687 other rare events. 689 The potential drawback in relying on relative OWD as the congestion 690 signal is that when multiple flows share the same bottleneck, the 691 flow arriving late at the network experiencing a non-empty queue may 692 mistakenly consider the standing queuing delay as part of the fixed 693 path propagation delay. This will lead to slightly unfair bandwidth 694 sharing among the flows. 696 Alternatively, one could move the per-packet statistical handling to 697 the sender instead and use relative round-trip-time (RTT) in lieu of 698 relative OWD, assuming that per-packet acknowledgements are 699 available. The main drawback of RTT-based approach is the noise in 700 the measured delay in the reverse direction. 702 Note that the choice of either delay metric (relative OWD vs. RTT) 703 involves no change in the proposed rate adaptation algorithm. 704 Therefore, comparing the pros and cons regarding which delay metric 705 to adopt can be kept as an orthogonal direction of investigation. 707 6.2. Method for delay, loss, and marking ratio estimation 709 Like other delay-based congestion control schemes, performance of 710 NADA depends on the accuracy of its delay measurement and estimation 711 module. Appendix A in [RFC6817] provides an extensive discussion on 712 this aspect. 714 The current recommended practice of applying minimum filter with a 715 window size of 15 samples suffices in guarding against processing 716 delay outliers observed in wired connections. For wireless 717 connections with a higher packet delay variation (PDV), more 718 sophisticated techniques on de-noising, outlier rejection, and trend 719 analysis may be needed. 721 More sophisticated methods in packet loss ratio calculation, such as 722 that adopted by [Floyd-CCR00], will likely be beneficial. These 723 alternatives are currently under investigation. 725 6.3. Impact of parameter values 727 In the gradual rate update mode, the parameter TAU indicates the 728 upper bound of round-trip-time (RTT) in feedback control loop. 729 Typically, the observed feedback interval delta is close to the 730 target feedback interval DELTA, and the relative ratio of delta/TAU 731 versus ETA dictates the relative strength of influence from the 732 aggregate congestion signal offset term (x_offset) versus its recent 733 change (x_diff), respectively. These two terms are analogous to the 734 integral and proportional terms in a proportional-integral (PI) 735 controller. The recommended choice of TAU=500ms, DELTA=100ms and ETA 736 = 2.0 corresponds to a relative ratio of 1:10 between the gains of 737 the integral and proportional terms. Consequently, the rate 738 adaptation is mostly driven by the change in the congestion signal 739 with a long-term shift towards its equilibrium value driven by the 740 offset term. Finally, the scaling parameter KAPPA determines the 741 overall speed of the adaptation and needs to strike a balance between 742 responsiveness and stability. 744 The choice of the target feedback interval DELTA needs to strike the 745 right balance between timely feedback and low RTCP feedback message 746 counts. A target feedback interval of DELTA=100ms is recommended, 747 corresponding to a feedback bandwidth of 16Kbps with 200 bytes per 748 feedback message --- approximately 1.6% overhead for a 1 Mbps flow. 749 Furthermore, both simulation studies and frequency-domain analysis 750 have established that a feedback interval below 250ms (i.e., more 751 frequently than 4 feedback messages per second) will not break up the 752 feedback control loop of NADA congestion control. 754 In calculating the non-linear warping of delay in (1), the current 755 design uses fixed values of QTH for determining whether to perform 756 the non-linear warping). Its value may need to be tuned for 757 different operational enviornments (e.g., over wired vs. wireless 758 connections). It is possible to adapt its value based on past 759 observed patterns of queuing delay in the presence of packet losses. 760 It needs to be noted that the non-linear warping mechanism may lead 761 to multiple NADA streams stuck in loss-based mode when competing 762 against each other. 764 In calculating the aggregate congestion signal x_curr, the choice of 765 DMARK and DLOSS influence the steady-state packet loss/marking ratio 766 experienced by the flow at a given available bandwidth. Higher 767 values of DMARK and DLOSS result in lower steady-state loss/marking 768 ratios, but are more susceptible to the impact of individual packet 769 loss/marking events. While the value of DMARK and DLOSS are fixed 770 and predetermined in the current design, a scheme for automatically 771 tuning these values based on desired bandwidth sharing behavior in 772 the presence of other competing loss-based flows (e.g., loss-based 773 TCP) is under investigation. 775 6.4. Sender-based vs. receiver-based calculation 777 In the current design, the aggregated congestion signal x_curr is 778 calculated at the receiver, keeping the sender operation completely 779 independent of the form of actual network congestion indications 780 (delay, loss, or marking). Alternatively, one can move the logics of 781 (1) and (2) to the sender. Such an approach requires slightly higher 782 overhead in the feedback messages, which should contain individual 783 fields on queuing delay (d_queue), packet loss ratio (p_loss), packet 784 marking ratio (p_mark), receiving rate (r_recv), and recommended rate 785 adaptation mode (rmode). 787 6.5. Incremental deployment 789 One nice property of NADA is the consistent video endpoint behavior 790 irrespective of network node variations. This facilitates gradual, 791 incremental adoption of the scheme. 793 To start off with, the proposed congestion control mechanism can be 794 implemented without any explicit support from the network, and relies 795 solely on observed one-way delay measurements and packet loss ratios 796 as implicit congestion signals. 798 When ECN is enabled at the network nodes with RED-based marking, the 799 receiver can fold its observations of ECN markings into the 800 calculation of the equivalent delay. The sender can react to these 801 explicit congestion signals without any modification. 803 Ultimately, networks equipped with proactive marking based on token 804 bucket level metering can reap the additional benefits of zero 805 standing queues and lower end-to-end delay and work seamlessly with 806 existing senders and receivers. 808 7. Implementation Status 810 The NADA scheme has been implemented in [ns-2] and [ns-3] simulation 811 platforms. Extensive ns-2 simulation evaluations of an earlier 812 version of the draft are documented in [Zhu-PV13]. Evaluation 813 results of the current draft over several test cases in 814 [I-D.ietf-rmcat-eval-test] have been presented at recent IETF 815 meetings [IETF-90][IETF-91]. Evaluation results of the current draft 816 over several test cases in [I-D.ietf-rmcat-wireless-tests] have been 817 presented at [IETF-93]. An open source implementation of NADA as 818 part of a ns-3 module is available at [ns3-rmcat] 820 The scheme has also been implemented and evaluated in a lab setting 821 as described in [IETF-90]. Preliminary evaluation results of NADA in 822 single-flow and multi-flow scenarios have been presented in 823 [IETF-91]. 825 8. Suggested Experiments 827 NADA has been extensively evaluated under various test scenarios, 828 including the collection of test cases specified by 829 [I-D.ietf-rmcat-eval-test] and the subset of WiFi-based test cases in 830 [I-D.ietf-rmcat-wireless-tests]. Additional evaluations have been 831 carried out to characterize how NADA interacts with various active 832 queue management (AQM) schemes such as RED, CoDel, and PIE. Most of 833 these evaluations have been carried out in simulators. A few key 834 test cases have also bee evaluated in implementations embedded in 835 video conferencing clients. 837 Further experiments are suggested for the following scenarios: 839 o Experiments reflecting the set up of a typical WAN connection. 841 o Experiments with ECN marking capability turned on at the network 842 for existing test cases. 844 o Experiments with multiple RMCAT streams bearing different user- 845 specified priorities. 847 o Experiments with additional access technologies, especially over 848 cellular networks such as 3G/LTE. 850 o Experiments with various media source contents, including audio 851 only, audio and video, and application content sharing (e.g., 852 slide shows). 854 9. IANA Considerations 856 This document makes no request of IANA. 858 10. Acknowledgements 860 The authors would like to thank Randell Jesup, Luca De Cicco, Piers 861 O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, 862 Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede 863 Nielsen, Julius Flohr, Roland Bless, and Andreas Smas for their 864 various valuable review comments and feedback. Thanks to Charles 865 Ganzhorn for contributing to the testbed-based evaluation of NADA 866 during an early stage of its development. 868 11. References 870 11.1. Normative References 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997, 875 . 877 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 878 of Explicit Congestion Notification (ECN) to IP", 879 RFC 3168, DOI 10.17487/RFC3168, September 2001, 880 . 882 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 883 Jacobson, "RTP: A Transport Protocol for Real-Time 884 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 885 July 2003, . 887 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 888 Friendly Rate Control (TFRC): Protocol Specification", 889 RFC 5348, DOI 10.17487/RFC5348, September 2008, 890 . 892 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 893 and K. Carlberg, "Explicit Congestion Notification (ECN) 894 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 895 2012, . 897 11.2. Informative References 899 [Budzisz-TON11] 900 Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and 901 R. Shorten, "On the Fair Coexistence of Loss- and Delay- 902 Based TCP", IEEE/ACM Transactions on Networking vol. 19, 903 no. 6, pp. 1811-1824, December 2011. 905 [Floyd-CCR00] 906 Floyd, S., Handley, M., Padhye, J., and J. Widmer, 907 "Equation-based Congestion Control for Unicast 908 Applications", ACM SIGCOMM Computer Communications 909 Review vol. 30, no. 4, pp. 43-56, October 2000. 911 [I-D.ietf-rmcat-cc-codec-interactions] 912 Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, 913 "Congestion Control and Codec interactions in RTP 914 Applications", draft-ietf-rmcat-cc-codec-interactions-02 915 (work in progress), March 2016. 917 [I-D.ietf-rmcat-cc-requirements] 918 Jesup, R. and Z. Sarker, "Congestion Control Requirements 919 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 920 requirements-09 (work in progress), December 2014. 922 [I-D.ietf-rmcat-eval-test] 923 Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test 924 Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- 925 eval-test-05 (work in progress), April 2017. 927 [I-D.ietf-rmcat-video-traffic-model] 928 Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic 929 Sources for RMCAT Evaluations", draft-ietf-rmcat-video- 930 traffic-model-03 (work in progress), July 2017. 932 [I-D.ietf-rmcat-wireless-tests] 933 Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and 934 M. Ramalho, "Evaluation Test Cases for Interactive Real- 935 Time Media over Wireless Networks", draft-ietf-rmcat- 936 wireless-tests-04 (work in progress), May 2017. 938 [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, 939 "NADA Update: Algorithm, Implementation, and Test Case 940 Evalua6on Results", July 2014, 941 . 944 [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., 945 Jones, P., and S. D'Aronco, "NADA Algorithm Update and 946 Test Case Evaluations", November 2014, 947 . 950 [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., 951 Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA", 952 July 2015, . 955 [ns-2] "The Network Simulator - ns-2", 956 . 958 [ns-3] "The Network Simulator - ns-3", . 960 [ns3-rmcat] 961 Fu, J., Mena, S., and X. Zhu, "NS3 open source module of 962 IETF RMCAT congestion control protocols", November 2017, 963 . 965 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 966 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 967 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 968 S., Wroclawski, J., and L. Zhang, "Recommendations on 969 Queue Management and Congestion Avoidance in the 970 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 971 . 973 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 974 Pre-Congestion Notification (PCN) States in the IP Header 975 Using a Single Diffserv Codepoint (DSCP)", RFC 6660, 976 DOI 10.17487/RFC6660, July 2012, 977 . 979 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 980 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 981 DOI 10.17487/RFC6817, December 2012, 982 . 984 [Zhu-PV13] 985 Zhu, X. and R. Pan, "NADA: A Unified Congestion Control 986 Scheme for Low-Latency Interactive Video", in Proc. IEEE 987 International Packet Video Workshop (PV'13) San Jose, CA, 988 USA, December 2013. 990 Appendix A. Network Node Operations 992 NADA can work with different network queue management schemes and 993 does not assume any specific network node operation. As an example, 994 this appendix describes three variants of queue management behavior 995 at the network node, leading to either implicit or explicit 996 congestion signals. It needs to be acknowledged that NADA has not 997 yet been tested with non-probabilistic ECN marking behaviors. 999 In all three flavors described below, the network queue operates with 1000 the simple first-in-first-out (FIFO) principle. There is no need to 1001 maintain per-flow state. The system can scale easily with a large 1002 number of video flows and at high link capacity. 1004 A.1. Default behavior of drop tail queues 1006 In a conventional network with drop tail or RED queues, congestion is 1007 inferred from the estimation of end-to-end delay and/or packet loss. 1008 Packet drops at the queue are detected at the receiver, and 1009 contributes to the calculation of the aggregated congestion signal 1010 x_curr. No special action is required at network node. 1012 A.2. RED-based ECN marking 1014 In this mode, the network node randomly marks the ECN field in the IP 1015 packet header following the Random Early Detection (RED) algorithm 1016 [RFC2309]. Calculation of the marking probability involves the 1017 following steps: 1019 on packet arrival: 1020 update smoothed queue size q_avg as: 1021 q_avg = w*q + (1-w)*q_avg. 1023 calculate marking probability p as: 1025 / 0, if q < q_lo; 1026 | 1027 | q_avg - q_lo 1028 p= < p_max*--------------, if q_lo <= q < q_hi; 1029 | q_hi - q_lo 1030 | 1031 \ p = 1, if q >= q_hi. 1033 Here, q_lo and q_hi corresponds to the low and high thresholds of 1034 queue occupancy. The maximum marking probability is p_max. 1036 The ECN markings events will contribute to the calculation of an 1037 equivalent delay x_curr at the receiver. No changes are required at 1038 the sender. 1040 A.3. Random Early Marking with Virtual Queues 1042 Advanced network nodes may support random early marking based on a 1043 token bucket algorithm originally designed for Pre-Congestion 1044 Notification (PCN) [RFC6660]. The early congestion notification 1045 (ECN) bit in the IP header of packets are marked randomly. The 1046 marking probability is calculated based on a token-bucket algorithm 1047 originally designed for the Pre-Congestion Notification (PCN) 1048 [RFC6660]. The target link utilization is set as 90%; the marking 1049 probability is designed to grow linearly with the token bucket size 1050 when it varies between 1/3 and 2/3 of the full token bucket limit. 1052 Calculation of the marking probability involves the following steps: 1054 upon packet arrival: 1055 meter packet against token bucket (r,b); 1057 update token level b_tk; 1059 calculate the marking probability as: 1061 / 0, if b-b_tk < b_lo; 1062 | 1063 | b-b_tk-b_lo 1064 p = < p_max* --------------, if b_lo<= b-b_tk =b_hi. 1069 Here, the token bucket lower and upper limits are denoted by b_lo and 1070 b_hi, respectively. The parameter b indicates the size of the token 1071 bucket. The parameter r is chosen to be below capacity, resulting in 1072 slight under-utilization of the link. The maximum marking 1073 probability is p_max. 1075 The ECN markings events will contribute to the calculation of an 1076 equivalent delay x_curr at the receiver. No changes are required at 1077 the sender. The virtual queuing mechanism from the PCN-based marking 1078 algorithm will lead to additional benefits such as zero standing 1079 queues. 1081 Authors' Addresses 1083 Xiaoqing Zhu 1084 Cisco Systems 1085 12515 Research Blvd., Building 4 1086 Austin, TX 78759 1087 USA 1089 Email: xiaoqzhu@cisco.com 1091 Rong Pan 1092 Pensando Systems 1093 1730 Technology Drive 1094 San Jose, CA 95110 1095 USA 1097 Email: rong@pensando.io 1099 Michael A. Ramalho 1100 Cisco Systems, Inc. 1101 8000 Hawkins Road 1102 Sarasota, FL 34241 1103 USA 1105 Phone: +1 919 476 2038 1106 Email: mramalho@cisco.com 1108 Sergio Mena de la Cruz 1109 Cisco Systems 1110 EPFL, Quartier de l'Innovation, Batiment E 1111 Ecublens, Vaud 1015 1112 Switzerland 1114 Email: semena@cisco.com 1116 Paul E. Jones 1117 Cisco Systems 1118 7025 Kit Creek Rd. 1119 Research Triangle Park, NC 27709 1120 USA 1122 Email: paulej@packetizer.com 1123 Jiantao Fu 1124 Cisco Systems 1125 707 Tasman Drive 1126 Milpitas, CA 95035 1127 USA 1129 Email: jianfu@cisco.com 1131 Stefano D'Aronco 1132 Ecole Polytechnique Federale de Lausanne 1133 EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11 1134 Lausanne CH-1015 1135 Switzerland 1137 Email: stefano.daronco@epfl.ch