--- 1/draft-ietf-rmcat-nada-10.txt 2019-07-25 13:13:05.458414971 -0700 +++ 2/draft-ietf-rmcat-nada-11.txt 2019-07-25 13:13:05.518416488 -0700 @@ -1,24 +1,24 @@ Network Working Group X. Zhu Internet-Draft R. Pan Intended status: Experimental M. Ramalho -Expires: August 7, 2019 S. Mena +Expires: January 26, 2020 S. Mena P. Jones J. Fu Cisco Systems S. D'Aronco - EPFL - February 3, 2019 + ETH + July 25, 2019 NADA: A Unified Congestion Control Scheme for Real-Time Media - draft-ietf-rmcat-nada-10 + draft-ietf-rmcat-nada-11 Abstract This document describes NADA (network-assisted dynamic adaptation), a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 7, 2019. + This Internet-Draft will expire on January 26, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -73,34 +73,34 @@ 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 14 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 14 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 15 5.2.2. Adjusting video target rate and sending rate . . . . 16 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 16 6. Discussions and Further Investigations . . . . . . . . . . . 17 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 17 6.2. Method for delay, loss, and marking ratio estimation . . 18 6.3. Impact of parameter values . . . . . . . . . . . . . . . 18 6.4. Sender-based vs. receiver-based calculation . . . . . . . 19 - 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 19 - 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 + 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 20 + 7. Reference Implementation . . . . . . . . . . . . . . . . . . 20 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22 - Appendix A. Network Node Operations . . . . . . . . . . . . . . 24 - A.1. Default behavior of drop tail queues . . . . . . . . . . 24 - A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 24 - A.3. Random Early Marking with Virtual Queues . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + Appendix A. Network Node Operations . . . . . . . . . . . . . . 25 + A.1. Default behavior of drop tail queues . . . . . . . . . . 25 + A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 25 + A.3. Random Early Marking with Virtual Queues . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Interactive real-time media applications introduce a unique set of challenges for congestion control. Unlike TCP, the mechanism used for real-time media needs to adapt quickly to instantaneous bandwidth changes, accommodate fluctuations in the output of video encoder rate control, and cause low queuing delay over the network. An ideal scheme should also make effective use of all types of congestion signals, including packet loss, queuing delay, and explicit @@ -174,24 +174,24 @@ receiving rate (r_recv) of the flow. It calculates the aggregated congestion signal (x_curr) that accounts for queuing delay, ECN markings, and packet losses. The receiver also determines the mode for sender rate adaptation (rmode) based on whether the flow has encountered any standing non-zero congestion. The receiver sends periodic RTCP reports back to the sender, containing values of x_curr, rmode, and r_recv. o Network node with several modes of operation. The system can work with the default behavior of a simple drop tail queue. It can - also benefit from advanced AQM features such as PIE, FQ-CoDel, - RED-based ECN marking, and PCN marking using a token bucket - algorithm. Note that network node operation is out of control for - the design of NADA. + also benefit from advanced AQM features such as PIE [RFC8033], FQ- + CoDel [RFC8290], ECN marking based on RED [RFC7567], and PCN + marking using a token bucket algorithm ([RFC6660]). Note that + network node operation is out of control for the design of NADA. 4. Core Congestion Control Algorithm Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA is a rate-based congestion control algorithm. In its simplest form, the sender reacts to the collection of network congestion indicators in the form of an aggregated congestion signal, and operates in one of two modes: o Accelerated ramp-up: when the bottleneck is deemed to be @@ -491,24 +491,24 @@ signal (XREF). The value of XREF is chosen so that the maximum rate of RMAX can be achieved when the observed congestion signal level is below PRIO*XREF. At equilibrium, the aggregated congestion signal stablizes at x_curr = PRIO*XREF*RMAX/r_ref. This ensures that when multiple flows share the same bottleneck and observe a common value of x_curr, their rates at equilibrium will be proportional to their respective priority levels (PRIO) and the range between minimum and maximum rate. Values of the minimum rate (RMIN) and maximum rate (RMAX) will be provided - by the media codec, as specified in + by the media codec, for instance, as outlined by [I-D.ietf-rmcat-cc-codec-interactions]. In the absense of such information, NADA sender will choose a default value of 0 for RMIN, - and 2Mbps for RMAX. + and 3Mbps for RMAX. As mentioned in the sender-side algorithm, the final rate is clipped within the dynamic range specified by the application: r_ref = min(r_ref, RMAX) (8) r_ref = max(r_ref, RMIN) (9) The above operations ignore many practical issues such as clock synchronization between sender and receiver, filtering of noise in @@ -637,42 +637,58 @@ shaping buffer from building up. The mechanisms adopted are: o To deplete the rate shaping buffer faster by increasing the sending rate r_send; and o To limit incoming packets of the rate shaping buffer by reducing the video encoder target rate r_vin. 5.2.2. Adjusting video target rate and sending rate - The target rate for the live video encoder deviates from the network - congestion control rate r_ref based on the level of occupancy in the - rate shaping buffer: - - r_vin = r_ref - BETA_V*8*buffer_len*FPS. (11) - - The actual sending rate r_send is regulated in a similar fashion: + If the level of occupancy in the rate shaping buffer is accessible at + the sender, such information can be leveraged to further adjust the + target rate of the live video encoder r_vin as well as the actual + sending rate r_send. The purpose of such adjustments is to mitigate + the additional latencies introduced by the rate shaping buffer. The + amount of rate adjustment can be calculated as follows: - r_send = r_ref + BETA_S*8*buffer_len*FPS. (12) + r_diff_v = min(0.05*r_ref, BETA_V*8*buffer_len*FPS). (11) + r_diff_s = min(0.05*r_ref, BETA_S*8*buffer_len*FPS). (12) + r_vin = max(RMIN, r_ref - r_diff_v). (13) + r_send = min(RMAX, r_ref + r_diff_s). (14) - In (11) and (12), the first term indicates the rate calculated from - network congestion feedback alone. The second term indicates the - influence of the rate shaping buffer. A large rate shaping buffer - nudges the encoder target rate slightly below -- and the sending rate - slightly above -- the reference rate r_ref. + In (11) and (12), the amount of adjustment is calculated as + proportional to the size of the rate shaping buffer but is bounded by + 5% of the reference rate r_ref calculated from network congestion + feedback alone. This ensures that the adjustment introduced by the + rate shaping buffer will not counteract with the core congestion + control process. Equations (13) and (14) indicate the influence of + the rate shaping buffer. A large rate shaping buffer nudges the + encoder target rate slightly below -- and the sending rate slightly + above -- the reference rate r_ref. The final video target rate + (r_vin) and sending rate (r_send) are further bounded within the + original range of [RMIN, RMAX]. Intuitively, the amount of extra rate offset needed to completely drain the rate shaping buffer within the duration of a single video - frame is given by 8*buffer_len*FPS, where FPS stands for the frame - rate of the video. The scaling parameters BETA_V and BETA_S can be - tuned to balance between the competing goals of maintaining a small - rate shaping buffer and deviating from the reference rate point. + frame is given by 8*buffer_len*FPS, where FPS stands for the + reference frame rate of the video. The scaling parameters BETA_V and + BETA_S can be tuned to balance between the competing goals of + maintaining a small rate shaping buffer and deviating from the + reference rate point. Empirical observations show that the rate + shaping buffer for a responsive live video encoder typically stays + empty and only occasionally holds a large frame (e.g., when an intra- + frame is produced) in transit. Therefore, the rate adjustment + introduced by this mechanism is expected to be minor. For instance, + a rate shaping buffer of 2000 Bytes will lead to a rate adjustment of + 48 Kbps given the recommended scaling parameters of BETA_V = 0.1 and + BETA_S = 0.1 and reference frame rate of FPS = 30. 5.3. Feedback Message Requirements The following list of information is required for NADA congestion control to function properly: o Recommended rate adaptation mode (rmode): a 1-bit flag indicating whether the sender should operate in accelerated ramp-up mode (rmode=0) or gradual update mode (rmode=1). @@ -747,21 +763,21 @@ The current recommended practice of applying minimum filter with a window size of 15 samples suffices in guarding against processing delay outliers observed in wired connections. For wireless connections with a higher packet delay variation (PDV), more sophisticated techniques on de-noising, outlier rejection, and trend analysis may be needed. More sophisticated methods in packet loss ratio calculation, such as that adopted by [Floyd-CCR00], will likely be beneficial. These - alternatives are currently under investigation. + alternatives are part of the experiments this document proposes. 6.3. Impact of parameter values In the gradual rate update mode, the parameter TAU indicates the upper bound of round-trip-time (RTT) in feedback control loop. Typically, the observed feedback interval delta is close to the target feedback interval DELTA, and the relative ratio of delta/TAU versus ETA dictates the relative strength of influence from the aggregate congestion signal offset term (x_offset) versus its recent change (x_diff), respectively. These two terms are analogous to the @@ -773,45 +789,45 @@ with a long-term shift towards its equilibrium value driven by the offset term. Finally, the scaling parameter KAPPA determines the overall speed of the adaptation and needs to strike a balance between responsiveness and stability. The choice of the target feedback interval DELTA needs to strike the right balance between timely feedback and low RTCP feedback message counts. A target feedback interval of DELTA=100ms is recommended, corresponding to a feedback bandwidth of 16Kbps with 200 bytes per feedback message --- approximately 1.6% overhead for a 1 Mbps flow. - Furthermore, both simulation studies and frequency-domain analysis - have established that a feedback interval below 250ms (i.e., more - frequently than 4 feedback messages per second) will not break up the - feedback control loop of NADA congestion control. + Furthermore, both simulation studies and frequency-domain analysis in + [IETF-95] have established that a feedback interval below 250ms + (i.e., more frequently than 4 feedback messages per second) will not + break up the feedback control loop of NADA congestion control. In calculating the non-linear warping of delay in (1), the current design uses fixed values of QTH for determining whether to perform the non-linear warping). Its value may need to be tuned for different operational enviornments (e.g., over wired vs. wireless connections). It is possible to adapt its value based on past observed patterns of queuing delay in the presence of packet losses. It needs to be noted that the non-linear warping mechanism may lead to multiple NADA streams stuck in loss-based mode when competing against each other. In calculating the aggregate congestion signal x_curr, the choice of DMARK and DLOSS influence the steady-state packet loss/marking ratio experienced by the flow at a given available bandwidth. Higher values of DMARK and DLOSS result in lower steady-state loss/marking ratios, but are more susceptible to the impact of individual packet loss/marking events. While the value of DMARK and DLOSS are fixed - and predetermined in the current design, a scheme for automatically - tuning these values based on desired bandwidth sharing behavior in - the presence of other competing loss-based flows (e.g., loss-based - TCP) is under investigation. + and predetermined in the current design, this document also + encourages futher explorations of a scheme for automatically tuning + these values based on desired bandwidth sharing behavior in the + presence of other competing loss-based flows (e.g., loss-based TCP). 6.4. Sender-based vs. receiver-based calculation In the current design, the aggregated congestion signal x_curr is calculated at the receiver, keeping the sender operation completely independent of the form of actual network congestion indications (delay, loss, or marking). Alternatively, one can move the logics of (1) and (2) to the sender. Such an approach requires slightly higher overhead in the feedback messages, which should contain individual fields on queuing delay (d_queue), packet loss ratio (p_loss), packet @@ -832,21 +848,21 @@ When ECN is enabled at the network nodes with RED-based marking, the receiver can fold its observations of ECN markings into the calculation of the equivalent delay. The sender can react to these explicit congestion signals without any modification. Ultimately, networks equipped with proactive marking based on token bucket level metering can reap the additional benefits of zero standing queues and lower end-to-end delay and work seamlessly with existing senders and receivers. -7. Implementation Status +7. Reference Implementation The NADA scheme has been implemented in [ns-2] and [ns-3] simulation platforms. Extensive ns-2 simulation evaluations of an earlier version of the draft are documented in [Zhu-PV13]. Evaluation results of the current draft over several test cases in [I-D.ietf-rmcat-eval-test] have been presented at recent IETF meetings [IETF-90][IETF-91]. Evaluation results of the current draft over several test cases in [I-D.ietf-rmcat-wireless-tests] have been presented at [IETF-93]. An open source implementation of NADA as part of a ns-3 module is available at [ns3-rmcat] @@ -890,21 +906,32 @@ o Experiments with various media source contents, including audio only, audio and video, and application content sharing (e.g., slide shows). 9. IANA Considerations This document makes no request of IANA. 10. Security Considerations - TBD + The rate adaptation mechanism in NADA relies on feedback from the + receiver. As such, it is vulnerable to attacks where feedback + messages are hijacked, replaces, or intentionally injected with + misleading information, similar to those that can affect TCP. It is + therefore RECOMMENDED that the RTCP feedback message is at least + integrity checked. The modification of sending rate based on send- + side rate shaping buffer may lead to temporary excessive congestion + over the network in the presence of a unresponsive video encoder. + However, this effect can be mitigated by limiting the amount of rate + modification introduced by the rate shaping buffer, bounding the size + of the rate shaping buffer at the sender, and maintaining a maximum + allowed sending rate by NADA. 11. Acknowledgments The authors would like to thank Randell Jesup, Luca De Cicco, Piers O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede Nielsen, Julius Flohr, Roland Bless, Andreas Smas, and Martin Stiemerling for their various valuable review comments and feedback. Thanks to Charles Ganzhorn for contributing to the testbed-based evaluation of NADA during an early stage of its development. @@ -963,50 +990,56 @@ (work in progress), March 2016. [I-D.ietf-rmcat-cc-requirements] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", draft-ietf-rmcat-cc- requirements-09 (work in progress), December 2014. [I-D.ietf-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- - eval-test-08 (work in progress), November 2018. + eval-test-10 (work in progress), May 2019. [I-D.ietf-rmcat-video-traffic-model] Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models for RTP Congestion Control Evaluations", draft-ietf-rmcat- - video-traffic-model-06 (work in progress), November 2018. + video-traffic-model-07 (work in progress), February 2019. [I-D.ietf-rmcat-wireless-tests] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real- Time Media over Wireless Networks", draft-ietf-rmcat- - wireless-tests-06 (work in progress), December 2018. + wireless-tests-08 (work in progress), July 2019. [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, "NADA Update: Algorithm, Implementation, and Test Case Evalua6on Results", July 2014, . [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., Jones, P., and S. D'Aronco, "NADA Algorithm Update and Test Case Evaluations", November 2014, . [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA", July 2015, . + [IETF-95] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, + J., D'Aronco, S., and C. Ganzhorn, "Updates on NADA: + Stability Analysis and Impact of Feedback Intervals", + April 2016, . + [ns-2] "The Network Simulator - ns-2", . [ns-3] "The Network Simulator - ns-3", . [ns3-rmcat] Fu, J., Mena, S., and X. Zhu, "NS3 open source module of IETF RMCAT congestion control protocols", November 2017, . @@ -1019,20 +1052,32 @@ [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, . [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . + [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, + "Proportional Integral Controller Enhanced (PIE): A + Lightweight Control Scheme to Address the Bufferbloat + Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, + . + + [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, + J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler + and Active Queue Management Algorithm", RFC 8290, + DOI 10.17487/RFC8290, January 2018, + . + [Zhu-PV13] Zhu, X. and R. Pan, "NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Video", in Proc. IEEE International Packet Video Workshop (PV'13) San Jose, CA, USA, December 2013. Appendix A. Network Node Operations NADA can work with different network queue management schemes and does not assume any specific network node operation. As an example, @@ -1155,25 +1199,26 @@ Email: semena@cisco.com Paul E. Jones Cisco Systems 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Email: paulej@packetizer.com + Jiantao Fu Cisco Systems 707 Tasman Drive Milpitas, CA 95035 USA Email: jianfu@cisco.com Stefano D'Aronco - Ecole Polytechnique Federale de Lausanne - EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11 - Lausanne CH-1015 + ETH Zurich + Stefano-Franscini-Platz 5 + Zurich 8093 Switzerland - Email: stefano.daronco@epfl.ch + Email: stefano.daronco@geod.baug.ethz.ch