Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media
RFC 8698

lt;https://tools.ietf.org/html/draft-ietf-rmcat-eval-
              test-10>.

   [RTCP-FEEDBACK]
              Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
              Control Protocol (RTCP) Feedback for Congestion Control",
              Work in Progress, Internet-Draft, draft-ietf-avtcore-cc-
              feedback-message-05, 4 November 2019,
              <https://tools.ietf.org/html/draft-ietf-avtcore-cc-
              feedback-message-05>.

   [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", Work in Progress,
              Internet-Draft, draft-ietf-rmcat-wireless-tests-08, 5 July
              2019, <https://tools.ietf.org/html/draft-ietf-rmcat-
              wireless-tests-08>.

   [ZHU-PV13] Zhu, X. and R. Pan, "NADA: A Unified Congestion Control
              Scheme for Low-Latency Interactive Video", Proc. IEEE
              International Packet Video Workshop, San Jose, CA, USA,
              DOI 10.1109/PV.2013.6691448, December 2013,
              <https://doi.org/10.1109/PV.2013.6691448>.

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.  It needs to be acknowledged that NADA has not
   yet been tested with non-probabilistic ECN marking behaviors.

   In all three flavors described below, the network queue operates with
   the simple First In, First Out (FIFO) principle.  There is no need to
   maintain per-flow state.  The system can scale easily with a large
   number of video flows and at high link capacity.

A.1.  Default Behavior of Drop-Tail Queues

   In a conventional network with drop-tail or RED queues, congestion is
   inferred from the estimation of end-to-end delay and/or packet loss.
   Packet drops at the queue are detected at the receiver and contribute
   to the calculation of the aggregated congestion signal x_curr.  No
   special action is required at the network node.

A.2.  RED-Based ECN Marking

   In this mode, the network node randomly marks the ECN field in the IP
   packet header following the Random Early Detection (RED) algorithm
   [RFC7567].  Calculation of the marking probability involves the
   following steps on packet arrival:

   1.  update smoothed queue size q_avg as:

         q_avg = w*q + (1-w)*q_avg

   2.  calculate marking probability p as:

              / 0,                    if q < q_lo
              |
              |        q_avg - q_lo
          p= <  p_max*--------------, if q_lo <= q < q_hi
              |         q_hi - q_lo
              |
              \ p = 1,                if q >= q_hi

   Here, q_lo and q_hi correspond to the low and high thresholds of
   queue occupancy.  The maximum marking probability is p_max.

   The ECN marking events will contribute to the calculation of an
   equivalent delay x_curr at the receiver.  No changes are required at
   the sender.

A.3.  Random Early Marking with Virtual Queues

   Advanced network nodes may support random early marking based on a
   token bucket algorithm originally designed for Pre-Congestion
   Notification (PCN) [RFC6660].  The early congestion notification
   (ECN) bit in the IP header of packets is marked randomly.  The
   marking probability is calculated based on a token bucket algorithm
   originally designed for PCN [RFC6660].  The target link utilization
   is set as 90%; the marking probability is designed to grow linearly
   with the token bucket size when it varies between 1/3 and 2/3 of the
   full token bucket limit.

   Calculation of the marking probability involves the following steps
   upon packet arrival:

   1.  meter packet against token bucket (r,b)

   2.  update token level b_tk

   3.  calculate the marking probability as:

               / 0,                     if b-b_tk < b_lo
               |
               |          b-b_tk-b_lo
          p = <  p_max* --------------, if b_lo <= b-b_tk < b_hi
               |           b_hi-b_lo
               |
               \ 1,                     if b-b_tk >= b_hi

   Here, the token bucket lower and upper limits are denoted by b_lo and
   b_hi, respectively.  The parameter b indicates the size of the token
   bucket.  The parameter r is chosen to be below capacity, resulting in
   slight underutilization of the link.  The maximum marking probability
   is p_max.

   The ECN marking events will contribute to the calculation of an
   equivalent delay x_curr at the receiver.  No changes are required at
   the sender.  The virtual queuing mechanism from the PCN-based marking
   algorithm will lead to additional benefits such as zero standing
   queues.

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 Kühlewind, Karen Elisabeth Egede
   Nielsen, Julius Flohr, Roland Bless, Andreas Smas, and Martin
   Stiemerling for their valuable review comments and helpful input to
   this specification.

Contributors

   The following individuals contributed to the implementation and
   evaluation of the proposed scheme and, therefore, helped to validate
   and substantially improve this specification.

   Paul E. Jones <paulej@packetizer.com> of Cisco Systems implemented an
   early version of the NADA congestion control scheme and helped with
   its lab-based testbed evaluations.

   Jiantao Fu <jianfu@cisco.com> of Cisco Systems helped with the
   implementation and extensive evaluation of NADA both in Mozilla web
   browsers and in earlier simulation-based evaluation efforts.

   Stefano D'Aronco <stefano.daronco@geod.baug.ethz.ch> of ETH Zurich
   (previously at Ecole Polytechnique Federale de Lausanne when
   contributing to this work) helped with the implementation and
   evaluation of an early version of NADA in [NS-3].

   Charles Ganzhorn <charles.ganzhorn@gmail.com> contributed to the
   testbed-based evaluation of NADA during an early stage of its
   development.

Authors' Addresses

   Xiaoqing Zhu
   Cisco Systems
   12515 Research Blvd., Building 4
   Austin, TX 78759
   United States of America

   Email: xiaoqzhu@cisco.com

   Rong Pan
   Intel Corporation
   2200 Mission College Blvd
   Santa Clara, CA 95054
   United States of America

   Email: rong.pan@intel.com

   Michael A. Ramalho
   AcousticComms Consulting
   6310 Watercrest Way Unit 203
   Lakewood Ranch, FL 34202-5211
   United States of America

   Phone: +1 732 832 9723
   Email: mar42@cornell.edu
   URI:   http://ramalho.webhop.info/

   Sergio Mena
   Cisco Systems
   EPFL, Quartier de l'Innovation, Batiment E
   CH-1015 Ecublens
   Switzerland

   Email: semena@cisco.com