idnits 2.17.1 draft-ietf-rmcat-nada-01.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 2 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 407 has weird spacing: '... delta x_o...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 9, 2015) is 3121 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RMIN' is mentioned on line 381, but not defined == Missing Reference: 'RMAX' is mentioned on line 381, but not defined == Unused Reference: 'I-D.ietf-rmcat-eval-criteria' is defined on line 763, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-rmcat-eval-criteria-03 == Outdated reference: A later version (-10) exists of draft-ietf-rmcat-eval-test-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: April 11, 2016 S. Mena 6 P. Jones 7 J. Fu 8 Cisco Systems 9 S. D'Aronco 10 EPFL 11 C. Ganzhorn 12 October 9, 2015 14 NADA: A Unified Congestion Control Scheme for Real-Time Media 15 draft-ietf-rmcat-nada-01 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 April 11, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . 4 67 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 68 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 7 69 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 9 70 5. Practical Implementation of NADA . . . . . . . . . . . . . . 10 71 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 10 72 5.1.1. Estimation of one-way delay and queuing delay . . . . 11 73 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 11 74 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 11 75 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 12 76 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 12 77 5.2.2. Adjusting video target rate and sending rate . . . . 13 78 6. Discussions and Further Investigations . . . . . . . . . . . 13 79 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 13 80 6.2. Method for delay, loss, and marking ratio estimation . . 14 81 6.3. Impact of parameter values . . . . . . . . . . . . . . . 14 82 6.4. Sender-based vs. receiver-based calculation . . . . . . . 15 83 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 16 84 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 10.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Appendix A. Network Node Operations . . . . . . . . . . . . . . 19 91 A.1. Default behavior of drop tail queues . . . . . . . . . . 19 92 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 19 93 A.3. Random Early Marking with Virtual Queues . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 Interactive real-time media applications introduce a unique set of 100 challenges for congestion control. Unlike TCP, the mechanism used 101 for real-time media needs to adapt quickly to instantaneous bandwidth 102 changes, accommodate fluctuations in the output of video encoder rate 103 control, and cause low queuing delay over the network. An ideal 104 scheme should also make effective use of all types of congestion 105 signals, including packet loss, queuing delay, and explicit 106 congestion notification (ECN) [RFC3168] markings. The requirements 107 for the congestion control algorithm are outlined in 108 [I-D.ietf-rmcat-cc-requirements]. 110 This document describes an experimental congestion control scheme 111 called network-assisted dynamic adaptation (NADA). The NADA design 112 benefits from explicit congestion control signals (e.g., ECN 113 markings) from the network, yet also operates when only implicit 114 congestion indicators (delay and/or loss) are available. In 115 addition, it supports weighted bandwidth sharing among competing 116 video flows. The signaling mechanism consists of standard RTP 117 timestamp [RFC3550] and standard RTCP feedback reports. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described [RFC2119]. 125 3. System Overview 127 Figure 1 shows the end-to-end system for real-time media transport 128 that NADA operates in. 130 +---------+ r_vin +--------+ +--------+ +----------+ 131 | Media |<--------| RTP | |Network | | RTP | 132 | Encoder |========>| Sender |=======>| Node |====>| Receiver | 133 +---------+ r_vout +--------+ r_send +--------+ +----------+ 134 /|\ | 135 | | 136 +---------------------------------+ 137 RTCP Feedback Report 139 Figure 1: System Overview 141 o Media encoder with rate control capabilities. It encodes the 142 source media stream into an RTP stream with target bit rate r_vin. 143 The actual output rate from the encoder r_vout may fluctuate 144 around the target r_vin. In addition, the encoder can only change 145 its bit rate at rather coarse time intervals, e.g., once every 0.5 146 seconds. 148 o RTP sender: responsible for calculating the NADA reference rate 149 based on network congestion indicators (delay, loss, or ECN 150 marking reports from the receiver), for updating the video encoder 151 with a new target rate r_vin, and for regulating the actual 152 sending rate r_send accordingly. The RTP sender also provides an 153 RTP timestamp for each outgoing packet. 155 o RTP receiver: responsible for measuring and estimating end-to-end 156 delay based on sender RTP timestamp, packet loss and ECN marking 157 ratios, as well as receiving rate (r_recv) of the flow. It 158 calculates the aggregated congestion signal (x_n) that accounts 159 for queuing delay, ECN marking, and packet losses, and determines 160 the mode for sender rate adaptation (rmode) based on whether the 161 flow has encountered any standing non-zero congestion. The 162 receiver sends periodic RTCP reports back to the sender, 163 containing values of x_n, rmode, and r_recv. 165 o Network node with several modes of operation. The system can work 166 with the default behavior of a simple drop tail queue. It can 167 also benefit from advanced AQM features such as PIE, FQ-CoDel, 168 RED-based ECN marking, and PCN marking using a token bucket 169 algorithm. Note that network node operation is out of scope for 170 the design of NADA. 172 4. Core Congestion Control Algorithm 174 Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA 175 is a rate-based congestion control algorithm. In its simplest form, 176 the sender reacts to the collection of network congestion indicators 177 in the form of an aggregated congestion signal, and operates in one 178 of two modes: 180 o Accelerated ramp-up: when the bottleneck is deemed to be 181 underutilized, the rate increases multiplicatively with respect to 182 the rate of previously successful transmissions. The rate 183 increase mutliplier (gamma) is calculated based on observed round- 184 trip-time and target feedback interval, so as to limit self- 185 inflicted queuing delay. 187 o Gradual rate update: in the presence of non-zero aggregate 188 congestion signal, the sending rate is adjusted in reaction to 189 both its value (x_n) and its change in value (x_diff). 191 This section introduces the list of mathematical notations and 192 describes the core congestion control algorithm at the sender and 193 receiver, respectively. Additional details on recommended practical 194 implementations are described in Section 5.1 and Section 5.2. 196 4.1. Mathematical Notations 198 This section summarizes the list of variables and parameters used in 199 the NADA algorithm. 201 +--------------+-------------------------------------------------+ 202 | Notation | Variable Name | 203 +--------------+-------------------------------------------------+ 204 | t_curr | Current timestamp | 205 | t_last | Last time sending/receiving a feedback | 206 | delta | Observed interval between current and previous | 207 | | feedback reports: delta = t_curr-t_last | 208 | r_n | Reference rate based on network congestion | 209 | r_send | Sending rate | 210 | r_recv | Receiving rate | 211 | r_vin | Target rate for video encoder | 212 | r_vout | Output rate from video encoder | 213 | d_base | Estimated baseline delay | 214 | d_fwd | Measured and filtered one-way delay | 215 | d_n | Estimated queueing delay | 216 | d_tilde | Equivalent delay after non-linear warping | 217 | p_mark | Estimated packet ECN marking ratio | 218 | p_loss | Estimated packet loss ratio | 219 | x_n | Aggregate congestion signal | 220 | x_prev | Previous value of aggregate congestion signal | 221 | x_diff | Change in aggregate congestion signal w.r.t. | 222 | | its previous value: x_diff = x_n - x_prev | 223 | rmode | Rate update mode: (0 = accelerated ramp-up; | 224 | | 1 = gradual update) | 225 | gamma | Rate increase multiplier in accelerated ramp-up | 226 | | mode | 227 | rtt | Estimated round-trip-time at sender | 228 | buffer_len | Rate shaping buffer occupancy measured in bytes | 229 +--------------+-------------------------------------------------+ 231 Figure 2: List of variables. 233 +---------------+---------------------------------+----------------+ 234 | Notation | Parameter Name | Default Value | 235 +--------------+----------------------------------+----------------+ 236 | PRIO | Weight of priority of the flow | 1.0 237 | RMIN | Minimum rate of application | 150 Kbps | 238 | | supported by media encoder | | 239 | RMAX | Maximum rate of application | 1.5 Mbps | 240 | | supported by media encoder | | 241 | X_REF | Reference congestion level | 20ms | 242 | KAPPA | Scaling parameter for gradual | 0.5 | 243 | | rate update calculation | | 244 | ETA | Scaling parameter for gradual | 2.0 | 245 | | rate update calculation | | 246 | TAU | Upper bound of RTT in gradual | 500ms | 247 | | rate update calculation | | 248 | DELTA | Target feedback interval | 100ms | 249 | LOGWIN | Observation window in time for | 500ms | 250 | | calculating packet summary | | 251 | | statistics at receiver | | 252 | QEPS | Threshold for determining queuing| 10ms | 253 | | delay build up at receiver | | 254 +..............+..................................+................+ 255 | QTH | Delay threshold for non-linear | 100ms | 256 | | warping | | 257 | QMAX | Delay upper bound for non-linear | 400ms | 258 | | warping | | 259 | DLOSS | Delay penalty for loss | 1.0s | 260 | DMARK | Delay penalty for ECN marking | 200ms | 261 +..............+..................................+................+ 262 | GAMMA_MAX | Upper bound on rate increase | 20% | 263 | | ratio for accelerated ramp-up | | 264 | QBOUND | Upper bound on self-inflicted | 50ms | 265 | | queuing delay during ramp up | | 266 +..............+..................................+................+ 267 | FPS | Frame rate of incoming video | 30 | 268 | BETA_S | Scaling parameter for modulating | 0.1 | 269 | | outgoing sending rate | | 270 | BETA_V | Scaling parameter for modulating | 0.1 | 271 | | video encoder target rate | | 272 | ALPHA | Smoothing factor in exponential | 0.1 | 273 | | smoothing of packet loss and | | 274 | | marking ratios | 275 +--------------+----------------------------------+----------------+ 277 Figure 3: List of algorithm parameters. 279 4.2. Receiver-Side Algorithm 281 The receiver-side algorithm can be outlined as below: 283 On initialization: 284 set d_base = +INFINITY 285 set p_loss = 0 286 set p_mark = 0 287 set r_recv = 0 288 set both t_last and t_curr as current time 290 On receiving a media packet: 291 obtain current timestamp t_curr 292 obtain from packet header sending time stamp t_sent 293 obtain one-way delay measurement: d_fwd = t_curr - t_sent 294 update baseline delay: d_base = min(d_base, d_fwd) 295 update queuing delay: d_n = d_fwd - d_base 296 update packet loss ratio estimate p_loss 297 update packet marking ratio estimate p_mark 298 update measurement of receiving rate r_recv 300 On time to send a new feedback report (t_curr - t_last > DELTA): 301 calculate non-linear warping of delay d_tilde if packet loss exists 302 calculate aggregate congestion signal x_n 303 determine mode of rate adaptation for sender: rmode 304 send RTCP feedback report containing values of: rmode, x_n, and r_recv 305 update t_last = t_curr 307 In order for a delay-based flow to hold its ground when competing 308 against loss-based flows (e.g., loss-based TCP), it is important to 309 distinguish between different levels of observed queuing delay. For 310 instance, a moderate queuing delay value below 100ms is likely self- 311 inflicted or induced by other delay-based flows, whereas a high 312 queuing delay value of several hundreds of milliseconds may indicate 313 the presence of a loss-based flow that does not refrain from 314 increased delay. 316 When packet losses are observed, the estimated queuing delay follows 317 a non-linear warping inspired by the delay-adaptive congestion window 318 backoff policy in [Budzisz-TON11]: 320 / d_n, if d_n |||||||||=================> 532 +----------+ -----------+ RTP packets 533 Rate Shaping Buffer 535 Figure 4: NADA Sender Structure 537 5.2.1. Rate shaping buffer 539 The operation of the live video encoder is out of the scope of the 540 design for the congestion control scheme in NADA. Instead, its 541 behavior is treated as a black box. 543 A rate shaping buffer is employed to absorb any instantaneous 544 mismatch between encoder rate output r_vout and regulated sending 545 rate r_send. Its current level of occupancy is measured in bytes and 546 is denoted as buffer_len. 548 A large rate shaping buffer contributes to higher end-to-end delay, 549 which may harm the performance of real-time media communications. 550 Therefore, the sender has a strong incentive to prevent the rate 551 shaping buffer from building up. The mechanisms adopted are: 553 o To deplete the rate shaping buffer faster by increasing the 554 sending rate r_send; and 556 o To limit incoming packets of the rate shaping buffer by reducing 557 the video encoder target rate r_vin. 559 5.2.2. Adjusting video target rate and sending rate 561 The target rate for the live video encoder deviates from the network 562 congestion control rate r_n based on the level of occupancy in the 563 rate shaping buffer: 565 r_vin = r_n - BETA_V*8*buffer_len*FPS. (11) 567 The actual sending rate r_send is regulated in a similar fashion: 569 r_send = r_n + BETA_S*8*buffer_len*FPS. (12) 571 In (11) and (12), the first term indicates the rate calculated from 572 network congestion feedback alone. The second term indicates the 573 influence of the rate shaping buffer. A large rate shaping buffer 574 nudges the encoder target rate slightly below -- and the sending rate 575 slightly above -- the reference rate r_n. 577 Intuitively, the amount of extra rate offset needed to completely 578 drain the rate shaping buffer within the duration of a single video 579 frame is given by 8*buffer_len*FPS, where FPS stands for the frame 580 rate of the video. The scaling parameters BETA_V and BETA_S can be 581 tuned to balance between the competing goals of maintaining a small 582 rate shaping buffer and deviating the system from the reference rate 583 point. 585 6. Discussions and Further Investigations 587 6.1. Choice of delay metrics 589 The current design works with relative one-way-delay (OWD) as the 590 main indication of congestion. The value of the relative OWD is 591 obtained by maintaining the minimum value of observed OWD over a 592 relatively long time horizon and subtract that out from the observed 593 absolute OWD value. Such an approach cancels out the fixed 594 difference between the sender and receiver clocks. It has been 595 widely adopted by other delay-based congestion control approaches 596 such as [RFC6817]. As discussed in [RFC6817], the time horizon for 597 tracking the minimum OWD needs to be chosen with care: it must be 598 long enough for an opportunity to observe the minimum OWD with zero 599 queuing delay along the path, and sufficiently short so as to timely 600 reflect "true" changes in minimum OWD introduced by route changes and 601 other rare events. 603 The potential drawback in relying on relative OWD as the congestion 604 signal is that when multiple flows share the same bottleneck, the 605 flow arriving late at the network experiencing a non-empty queue may 606 mistakenly consider the standing queuing delay as part of the fixed 607 path propagation delay. This will lead to slightly unfair bandwidth 608 sharing among the flows. 610 Alternatively, one could move the per-packet statistical handling to 611 the sender instead and use relative round-trip-time (RTT) in lieu of 612 relative OWD, assuming that per-packet acknowledgements are 613 available. The main drawback of RTT-based approach is the noise in 614 the measured delay in the reverse direction. 616 Note that the choice of either delay metric (relative OWD vs. RTT) 617 involves no change in the proposed rate adaptation algorithm. 618 Therefore, comparing the pros and cons regarding which delay metric 619 to adopt can be kept as an orthogonal direction of investigation. 621 6.2. Method for delay, loss, and marking ratio estimation 623 Like other delay-based congestion control schemes, performance of 624 NADA depends on the accuracy of its delay measurement and estimation 625 module. Appendix A in [RFC6817] provides an extensive discussion on 626 this aspect. 628 The current recommended practice of simply applying a 15-tab minimum 629 filter suffices in guarding against processing delay outliers 630 observed in wired connections. For wireless connections with a 631 higher packet delay variation (PDV), more sophisticated techniques on 632 de-noising, outlier rejection, and trend analysis may be needed. 634 More sophisticated methods in packet loss ratio calculation, such as 635 that adopted by [Floyd-CCR00], will likely be beneficial. These 636 alternatives are currently under investigation. 638 6.3. Impact of parameter values 640 In the gradual rate update mode, the parameter TAU indicates the 641 upper bound of round-trip-time (RTT) in feedback control loop. 642 Typically, the observed feedback interval delta is close to the 643 target feedback interval DELTA, and the relative ratio of delta/TAU 644 versus ETA dictates the relative strength of influence from the 645 aggregate congestion signal offset term (x_offset) versus its recent 646 change (x_diff), respectively. These two terms are analogous to the 647 integral and proportional terms in a proportional-integral (PI) 648 controller. The recommended choice of TAU=500ms, DELTA=100ms and ETA 649 = 2.0 corresponds to a relative ratio of 1:10 between the gains of 650 the integral and proportional terms. Consequently, the rate 651 adaptation is mostly driven by the change in the congestion signal 652 with a long-term shift towards its equilibrium value driven by the 653 offset term. Finally, the scaling parameter KAPPA determines the 654 overall speed of the adaptation and needs to strike a balance between 655 responsiveness and stability. 657 The choice of the target feedback interval DELTA needs to strike the 658 right balance between timely feedback and low RTCP feedback message 659 counts. A target feedback interval of DELTA=100ms is recommended, 660 corresponding to a feedback bandwidth of 16Kbps with 200 bytes per 661 feedback message --- less than 0.1% overhead for a 1 Mbps flow. 662 Furthermore, both simulation studies and frequency-domain analysis 663 have established that a feedback interval below 250ms will not break 664 up the feedback control loop of NADA congestion control. 666 In calculating the non-linear warping of delay in (1), the current 667 design uses fixed values of QTH and QMAX. It is possible to adapt 668 the value of both based on past observations of queuing delay in the 669 presence of packet losses. 671 In calculating the aggregate congestion signal x_n, the choice of 672 DMARK and DLOSS influence the steady-state packet loss/marking ratio 673 experienced by the flow at a given available bandwidth. Higher 674 values of DMARK and DLOSS result in lower steady-state loss/marking 675 ratios, but are more susceptible to the impact of individual packet 676 loss/marking events. While the value of DMARK and DLOSS are fixed 677 and predetermined in the current design, a scheme for automatically 678 tuning these values based on desired bandwidth sharing behavior in 679 the presence of other competing loss-based flows (e.g., loss-based 680 TCP) is under investigation. 682 [Editor's note: Choice of start value: is this in scope of congestion 683 control, or should this be decided by the application?] 685 6.4. Sender-based vs. receiver-based calculation 687 In the current design, the aggregated congestion signal x_n is 688 calculated at the receiver, keeping the sender operation completely 689 independent of the form of actual network congestion indications 690 (delay, loss, or marking). Alternatively, one can move the logics of 691 (1) and (2) to the sender. Such an approach requires slightly higher 692 overhead in the feedback messages, which should contain individual 693 fields on queuing delay (d_n), packet loss ratio (p_loss), packet 694 marking ratio (p_mark), receiving rate (r_recv), and recommended rate 695 adaptation mode (rmode). 697 6.5. Incremental deployment 699 One nice property of NADA is the consistent video endpoint behavior 700 irrespective of network node variations. This facilitates gradual, 701 incremental adoption of the scheme. 703 To start off with, the proposed congestion control mechanism can be 704 implemented without any explicit support from the network, and relies 705 solely on observed one-way delay measurements and packet loss ratios 706 as implicit congestion signals. 708 When ECN is enabled at the network nodes with RED-based marking, the 709 receiver can fold its observations of ECN markings into the 710 calculation of the equivalent delay. The sender can react to these 711 explicit congestion signals without any modification. 713 Ultimately, networks equipped with proactive marking based on token 714 bucket level metering can reap the additional benefits of zero 715 standing queues and lower end-to-end delay and work seamlessly with 716 existing senders and receivers. 718 7. Implementation Status 720 The NADA scheme has been implemented in [ns-2] and [ns-3] simulation 721 platforms. Extensive ns-2 simulation evaluations of an earlier 722 version of the draft are documented in [Zhu-PV13]. Evaluation 723 results of the current draft over several test cases in 724 [I-D.ietf-rmcat-eval-test] have been presented at recent IETF 725 meetings [IETF-90][IETF-91]. 727 The scheme has also been implemented and evaluated in a lab setting 728 as described in [IETF-90]. Preliminary evaluation results of NADA in 729 single-flow and multi-flow scenarios have been presented in 730 [IETF-91]. 732 8. IANA Considerations 734 This document makes no request of IANA. 736 9. Acknowledgements 738 The authors would like to thank Randell Jesup, Luca De Cicco, Piers 739 O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, 740 Safiqul Islam, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for 741 their valuable questions and comments on earlier versions of this 742 draft. 744 10. References 746 10.1. Normative References 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 750 RFC2119, March 1997, 751 . 753 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 754 of Explicit Congestion Notification (ECN) to IP", RFC 755 3168, DOI 10.17487/RFC3168, September 2001, 756 . 758 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 759 Jacobson, "RTP: A Transport Protocol for Real-Time 760 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 761 July 2003, . 763 [I-D.ietf-rmcat-eval-criteria] 764 Singh, V. and J. Ott, "Evaluating Congestion Control for 765 Interactive Real-time Media", draft-ietf-rmcat-eval- 766 criteria-03 (work in progress), March 2015. 768 [I-D.ietf-rmcat-eval-test] 769 Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test 770 Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- 771 eval-test-02 (work in progress), September 2015. 773 [I-D.ietf-rmcat-cc-requirements] 774 Jesup, R. and Z. Sarker, "Congestion Control Requirements 775 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 776 requirements-09 (work in progress), December 2014. 778 10.2. Informative References 780 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 781 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 782 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 783 S., Wroclawski, J., and L. Zhang, "Recommendations on 784 Queue Management and Congestion Avoidance in the 785 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 786 . 788 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 789 Friendly Rate Control (TFRC): Protocol Specification", RFC 790 5348, DOI 10.17487/RFC5348, September 2008, 791 . 793 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 794 Pre-Congestion Notification (PCN) States in the IP Header 795 Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 796 10.17487/RFC6660, July 2012, 797 . 799 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 800 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 801 DOI 10.17487/RFC6817, December 2012, 802 . 804 [Floyd-CCR00] 805 Floyd, S., Handley, M., Padhye, J., and J. Widmer, 806 "Equation-based Congestion Control for Unicast 807 Applications", ACM SIGCOMM Computer Communications Review 808 vol. 30, no. 4, pp. 43-56, October 2000. 810 [Budzisz-TON11] 811 Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and 812 R. Shorten, "On the Fair Coexistence of Loss- and Delay- 813 Based TCP", IEEE/ACM Transactions on Networking vol. 19, 814 no. 6, pp. 1811-1824, December 2011. 816 [Zhu-PV13] 817 Zhu, X. and R. Pan, "NADA: A Unified Congestion Control 818 Scheme for Low-Latency Interactive Video", in Proc. IEEE 819 International Packet Video Workshop (PV'13) San Jose, CA, 820 USA, December 2013. 822 [ns-2] "The Network Simulator - ns-2", 823 . 825 [ns-3] "The Network Simulator - ns-3", . 827 [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, 828 "NADA Update: Algorithm, Implementation, and Test Case 829 Evalua6on Results", July 2014, 830 . 833 [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., 834 Jones, P., and S. D'Aronco, "NADA Algorithm Update and 835 Test Case Evaluations", November 2014, 836 . 839 Appendix A. Network Node Operations 841 NADA can work with different network queue management schemes and 842 does not assume any specific network node operation. As an example, 843 this appendix describes three variants of queue management behavior 844 at the network node, leading to either implicit or explicit 845 congestion signals. 847 In all three flavors described below, the network queue operates with 848 the simple first-in-first-out (FIFO) principle. There is no need to 849 maintain per-flow state. The system can scale easily with a large 850 number of video flows and at high link capacity. 852 A.1. Default behavior of drop tail queues 854 In a conventional network with drop tail or RED queues, congestion is 855 inferred from the estimation of end-to-end delay and/or packet loss. 856 Packet drops at the queue are detected at the receiver, and 857 contributes to the calculation of the aggregated congestion signal 858 x_n. No special action is required at network node. 860 A.2. RED-based ECN marking 862 In this mode, the network node randomly marks the ECN field in the IP 863 packet header following the Random Early Detection (RED) algorithm 864 [RFC2309]. Calculation of the marking probability involves the 865 following steps: 867 on packet arrival: 868 update smoothed queue size q_avg as: 869 q_avg = w*q + (1-w)*q_avg. 871 calculate marking probability p as: 873 / 0, if q < q_lo; 874 | 875 | q_avg - q_lo 876 p= < p_max*--------------, if q_lo <= q < q_hi; 877 | q_hi - q_lo 878 | 879 \ p = 1, if q >= q_hi. 881 Here, q_lo and q_hi corresponds to the low and high thresholds of 882 queue occupancy. The maximum marking probability is p_max. 884 The ECN markings events will contribute to the calculation of an 885 equivalent delay x_n at the receiver. No changes are required at the 886 sender. 888 A.3. Random Early Marking with Virtual Queues 890 Advanced network nodes may support random early marking based on a 891 token bucket algorithm originally designed for Pre-Congestion 892 Notification (PCN) [RFC6660]. The early congestion notification 893 (ECN) bit in the IP header of packets are marked randomly. The 894 marking probability is calculated based on a token-bucket algorithm 895 originally designed for the Pre-Congestion Notification (PCN) 896 [RFC6660]. The target link utilization is set as 90%; the marking 897 probability is designed to grow linearly with the token bucket size 898 when it varies between 1/3 and 2/3 of the full token bucket limit. 900 * upon packet arrival, meter packet against token bucket (r,b); 902 * update token level b_tk; 904 * calculate the marking probability as: 906 / 0, if b-b_tk < b_lo; 907 | 908 | b-b_tk-b_lo 909 p = < p_max* --------------, if b_lo<= b-b_tk =b_hi. 914 Here, the token bucket lower and upper limits are denoted by b_lo and 915 b_hi, respectively. The parameter b indicates the size of the token 916 bucket. The parameter r is chosen to be below capacity, resulting in 917 slight under-utilization of the link. The maximum marking 918 probability is p_max. 920 The ECN markings events will contribute to the calculation of an 921 equivalent delay x_n at the receiver. No changes are required at the 922 sender. The virtual queuing mechanism from the PCN-based marking 923 algorithm will lead to additional benefits such as zero standing 924 queues. 926 Authors' Addresses 928 Xiaoqing Zhu 929 Cisco Systems 930 12515 Research Blvd., Building 4 931 Austin, TX 78759 932 USA 934 Email: xiaoqzhu@cisco.com 936 Rong Pan 937 Cisco Systems 938 3625 Cisco Way 939 San Jose, CA 95134 940 USA 942 Email: ropan@cisco.com 944 Michael A. Ramalho 945 Cisco Systems, Inc. 946 8000 Hawkins Road 947 Sarasota, FL 34241 948 USA 950 Phone: +1 919 476 2038 951 Email: mramalho@cisco.com 952 Sergio Mena de la Cruz 953 Cisco Systems 954 EPFL, Quartier de l'Innovation, Batiment E 955 Ecublens, Vaud 1015 956 Switzerland 958 Email: semena@cisco.com 960 Paul E. Jones 961 Cisco Systems 962 7025 Kit Creek Rd. 963 Research Triangle Park, NC 27709 964 USA 966 Email: paulej@packetizer.com 968 Jiantao Fu 969 Cisco Systems 970 707 Tasman Drive 971 Milpitas, CA 95035 972 USA 974 Email: jianfu@cisco.com 976 Stefano D'Aronco 977 Ecole Polytechnique Federale de Lausanne 978 EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11 979 Lausanne CH-1015 980 Switzerland 982 Email: stefano.daronco@epfl.ch 984 Charles Ganzhorn 985 7900 International Drive, International Plaza, Suite 400 986 Bloomington, MN 55425 987 USA 989 Email: charles.ganzhorn@gmail.com