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