--- 1/draft-ietf-rmcat-nada-04.txt 2017-09-28 15:13:13.026815080 -0700 +++ 2/draft-ietf-rmcat-nada-05.txt 2017-09-28 15:13:13.078816341 -0700 @@ -1,24 +1,24 @@ Network Working Group X. Zhu Internet-Draft R. Pan Intended status: Experimental M. Ramalho -Expires: September 28, 2017 S. Mena +Expires: April 1, 2018 S. Mena P. Jones J. Fu Cisco Systems S. D'Aronco EPFL - March 27, 2017 + September 28, 2017 NADA: A Unified Congestion Control Scheme for Real-Time Media - draft-ietf-rmcat-nada-04 + draft-ietf-rmcat-nada-05 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 @@ -26,53 +26,53 @@ losses instead. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://datatracker.ietf.org/drafts/current/. + 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 September 28, 2017. + This Internet-Draft will expire on April 1, 2018. Copyright Notice Copyright (c) 2017 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 - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 - 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 7 - 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 9 + 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8 + 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10 5. Practical Implementation of NADA . . . . . . . . . . . . . . 12 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12 5.1.1. Estimation of one-way delay and queuing delay . . . . 12 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 12 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14 5.2.2. Adjusting video target rate and sending rate . . . . 15 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15 6. Discussions and Further Investigations . . . . . . . . . . . 16 @@ -83,21 +83,21 @@ 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Network Node Operations . . . . . . . . . . . . . . 22 A.1. Default behavior of drop tail queues . . . . . . . . . . 22 - A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23 + A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 22 A.3. Random Early Marking with Virtual Queues . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 @@ -127,21 +127,21 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described [RFC2119]. 3. System Overview Figure 1 shows the end-to-end system for real-time media transport that NADA operates in. Note that there also exist network nodes along the reverse (potentially uncongested) path that the RTCP feedback reports traverse. Those network nodes are not shown in the - figure for sake of brevity. + figure for sake of abrevity. +---------+ r_vin +--------+ +--------+ +----------+ | Media |<--------| RTP | |Network | | RTP | | Encoder |========>| Sender |=======>| Node |====>| Receiver | +---------+ r_vout +--------+ r_send +--------+ +----------+ /|\ | | | +---------------------------------+ RTCP Feedback Report @@ -185,21 +185,21 @@ 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 underutilized, the rate increases multiplicatively with respect to the rate of previously successful transmissions. The rate - increase multiplier (gamma) is calculated based on observed round- + increase mutliplier (gamma) is calculated based on observed round- trip-time and target feedback interval, so as to limit self- inflicted queuing delay. o Gradual rate update: in the presence of non-zero aggregate congestion signal, the sending rate is adjusted in reaction to both its value (x_curr) and its change in value (x_diff). This section introduces the list of mathematical notations and describes the core congestion control algorithm at the sender and receiver, respectively. Additional details on recommended practical @@ -229,63 +229,73 @@ | p_mark | Estimated packet ECN marking ratio | | p_loss | Estimated packet loss ratio | | x_curr | Aggregate congestion signal | | x_prev | Previous value of aggregate congestion signal | | x_diff | Change in aggregate congestion signal w.r.t. | | | its previous value: x_diff = x_curr - x_prev | | rmode | Rate update mode: (0 = accelerated ramp-up; | | | 1 = gradual update) | | gamma | Rate increase multiplier in accelerated ramp-up | | | mode | + | tloss_int | Measured average loss interval | + | tloss_exp | Time window for recently observed losses | | rtt | Estimated round-trip-time at sender | | buffer_len | Rate shaping buffer occupancy measured in bytes | +--------------+-------------------------------------------------+ Figure 2: List of variables. +--------------+----------------------------------+----------------+ | Notation | Parameter Name | Default Value | +--------------+----------------------------------+----------------+ | PRIO | Weight of priority of the flow | 1.0 | RMIN | Minimum rate of application | 150 Kbps | | | supported by media encoder | | | RMAX | Maximum rate of application | 1.5 Mbps | | | supported by media encoder | | - | XREF | Reference congestion level | 20ms | + | XREF | Reference congestion level | 10ms | | KAPPA | Scaling parameter for gradual | 0.5 | | | rate update calculation | | | ETA | Scaling parameter for gradual | 2.0 | | | rate update calculation | | | TAU | Upper bound of RTT in gradual | 500ms | | | rate update calculation | | | DELTA | Target feedback interval | 100ms | +..............+..................................+................+ | DFILT | Bound on filtering delay | 120ms | | LOGWIN | Observation window in time for | 500ms | | | calculating packet summary | | | | statistics at receiver | | | QEPS | Threshold for determining queuing| 10ms | | | delay build up at receiver | | | GAMMA_MAX | Upper bound on rate increase | 50% | | | ratio for accelerated ramp-up | | | QBOUND | Upper bound on self-inflicted | 50ms | | | queuing delay during ramp up | | +..............+..................................+................+ - | TEXP | Expiration time for previously | 30s | - | | observed packet loss | | - | QTH | Delay threshold for non-linear | 50ms | - | | warping | | + | MULTILOSS | Multiplier for self-scaling the | 7. | + | | recent observation time window | | + | | (tloss_exp) based on measured | | + | | average loss interval (tloss_int)| | + | QTH | Delay threshold for invoking | 50ms | + | | non-linear warping | | | LAMBDA | Scaling parameter in the | 0.5 | | | exponent of non-linear warping | | +..............+..................................+................+ - | DLOSS | Delay penalty for loss | 1.0s | - | DMARK | Delay penalty for ECN marking | 200ms | + | PLRREF | Reference packet loss ratio | 0.01 | + | PMRREF | Reference packet marking ratio | 0.01 | + | DLOSS | Reference delay penalty for loss | 10ms | + | | when packet loss ratio is at | | + | | PLRREF | | + | DMARK | Reference delay penalty for ECN | 2ms | + | | marking when packet marking | | + | | is at PMRREF | | +..............+..................................+................+ | FPS | Frame rate of incoming video | 30 | | BETA_S | Scaling parameter for modulating | 0.1 | | | outgoing sending rate | | | BETA_V | Scaling parameter for modulating | 0.1 | | | video encoder target rate | | | ALPHA | Smoothing factor in exponential | 0.1 | | | smoothing of packet loss and | | | | marking ratios | +--------------+----------------------------------+----------------+ @@ -323,50 +333,64 @@ In order for a delay-based flow to hold its ground when competing against loss-based flows (e.g., loss-based TCP), it is important to distinguish between different levels of observed queuing delay. For instance, a moderate queuing delay value below 100ms is likely self- inflicted or induced by other delay-based flows, whereas a high queuing delay value of several hundreds of milliseconds may indicate the presence of a loss-based flow that does not refrain from increased delay. If packet losses are observed within the previous time window of - TEXP, the estimated queuing delay follows a non-linear warping: + tloss_exp, the estimated queuing delay follows a non-linear warping: / d_queue, if d_queue. + . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, - . + . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, - July 2003, . + July 2003, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August - 2012, . + 2012, . - [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-04 (work in progress), October 2016. +11.2. Informative References - [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. + [Budzisz-TON11] + Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and + R. Shorten, "On the Fair Coexistence of Loss- and Delay- + Based TCP", IEEE/ACM Transactions on Networking vol. 19, + no. 6, pp. 1811-1824, December 2011. - [I-D.ietf-rmcat-video-traffic-model] - Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic - Sources for RMCAT Evaluations", draft-ietf-rmcat-video- - traffic-model-02 (work in progress), January 2017. + [Floyd-CCR00] + Floyd, S., Handley, M., Padhye, J., and J. Widmer, + "Equation-based Congestion Control for Unicast + Applications", ACM SIGCOMM Computer Communications + Review vol. 30, no. 4, pp. 43-56, October 2000. - [I-D.ietf-rmcat-cc-codec-interactions] - Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, - "Congestion Control and Codec interactions in RTP - Applications", draft-ietf-rmcat-cc-codec-interactions-02 - (work in progress), March 2016. + [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, + "NADA Update: Algorithm, Implementation, and Test Case + Evalua6on Results", July 2014, + . - [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-03 (work in progress), November 2016. + [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, + . -11.2. Informative References + [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, . + + [ns-2] "The Network Simulator - ns-2", + . + + [ns-3] "The Network Simulator - ns-3", . [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, - . + . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, - . + . [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, - . + . [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, - . - - [Floyd-CCR00] - Floyd, S., Handley, M., Padhye, J., and J. Widmer, - "Equation-based Congestion Control for Unicast - Applications", ACM SIGCOMM Computer Communications - Review vol. 30, no. 4, pp. 43-56, October 2000. - - [Budzisz-TON11] - Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and - R. Shorten, "On the Fair Coexistence of Loss- and Delay- - Based TCP", IEEE/ACM Transactions on Networking vol. 19, - no. 6, pp. 1811-1824, December 2011. + . [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. - [ns-2] "The Network Simulator - ns-2", - . - - [ns-3] "The Network Simulator - ns-3", . - - [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, . - 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, this appendix describes three variants of queue management behavior at the network node, leading to either implicit or explicit congestion signals. In all three flavors described below, the network queue operates with the simple first-in-first-out (FIFO) principle. There is no need to @@ -1040,22 +1065,22 @@ Rong Pan Cisco Systems 3625 Cisco Way San Jose, CA 95134 USA Email: ropan@cisco.com Michael A. Ramalho Cisco Systems, Inc. - 6310 Watercrest Way, Unit 203 - Lakewood Ranch, FL 34202-5211 + 8000 Hawkins Road + Sarasota, FL 34241 USA Phone: +1 919 476 2038 Email: mramalho@cisco.com Sergio Mena de la Cruz Cisco Systems EPFL, Quartier de l'Innovation, Batiment E Ecublens, Vaud 1015 Switzerland