--- 1/draft-ietf-rmcat-nada-02.txt	2016-09-18 21:15:56.295772624 -0700
+++ 2/draft-ietf-rmcat-nada-03.txt	2016-09-18 21:15:56.347773927 -0700
@@ -1,25 +1,25 @@
 
 Network Working Group                                             X. Zhu
 Internet-Draft                                                    R. Pan
 Intended status: Experimental                                 M. Ramalho
-Expires: September 19, 2016                                      S. Mena
+Expires: March 22, 2017                                          S. Mena
                                                                 P. Jones
                                                                    J. Fu
                                                            Cisco Systems
                                                              S. D'Aronco
                                                                     EPFL
                                                              C. Ganzhorn
-                                                          March 18, 2016
+                                                      September 18, 2016
 
      NADA: A Unified Congestion Control Scheme for Real-Time Media
-                        draft-ietf-rmcat-nada-02
+                        draft-ietf-rmcat-nada-03
 
 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
@@ -34,21 +34,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 http://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 19, 2016.
+   This Internet-Draft will expire on March 22, 2017.
 
 Copyright Notice
 
    Copyright (c) 2016 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
    publication of this document.  Please review these documents
@@ -59,47 +59,48 @@
    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 . . . . . . . . . . . . . . . . .   8
-     4.3.  Sender-Side Algorithm . . . . . . . . . . . . . . . . . .  10
+     4.3.  Sender-Side Algorithm . . . . . . . . . . . . . . . . . .   9
    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
      6.1.  Choice of delay metrics . . . . . . . . . . . . . . . . .  16
      6.2.  Method for delay, loss, and marking ratio estimation  . .  16
      6.3.  Impact of parameter values  . . . . . . . . . . . . . . .  17
      6.4.  Sender-based vs. receiver-based calculation . . . . . . .  18
      6.5.  Incremental deployment  . . . . . . . . . . . . . . . . .  18
    7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  18
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
-   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
-   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
-     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
-     10.2.  Informative References . . . . . . . . . . . . . . . . .  20
-   Appendix A.  Network Node Operations  . . . . . . . . . . . . . .  21
+   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 . . . . . . . . . . . . . . . . . .  22
-     A.3.  Random Early Marking with Virtual Queues  . . . . . . . .  22
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23
+     A.2.  RED-based ECN marking . . . . . . . . . . . . . . . . . .  23
+     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
    scheme should also make effective use of all types of congestion
    signals, including packet loss, queuing delay, and explicit
@@ -255,27 +256,27 @@
     |              | 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           |                |
+    | TEXPLOSS     | Expiration time for previously   |     30s        |
+    |              | observed packet loss             |                |
     | QEPS         | Threshold for determining queuing|     10ms       |
     |              | delay build up at receiver       |                |
     +..............+..................................+................+
     | QTH          | Delay threshold for non-linear   |     50ms       |
     |              | warping                          |                |
-    | QMAX         | Delay upper bound for non-linear |    400ms       |
-    |              | warping                          |                |
     | DLOSS        | Delay penalty for loss           |    1.0s        |
     | DMARK        | Delay penalty for ECN marking    |    200ms       |
     +..............+..................................+................+
     | 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     |                |
     +..............+..................................+................+
     | FPS          | Frame rate of incoming video     |     30         |
     | BETA_S       | Scaling parameter for modulating |    0.1         |
@@ -319,36 +320,38 @@
 
    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.
 
-   When packet losses are observed, the estimated queuing delay follows
-   a non-linear warping inspired by the delay-adaptive congestion window
-   backoff policy in [Budzisz-TON11]:
+   If packet losses are observed within the previous time window of
+   TLOSS, the estimated queuing delay follows a non-linear warping:
 
               / d_queue,                if d_queue<QTH;
               |
-              |     (QMAX - d_queue)^4
-   d_tilde = <  QTH ------------------, if QTH<d_queue<QMAX  (1)
-              |       (QMAX - QTH)^4
-              |
-              \  0,                     otherwise.
+   d_tilde = <                                           (1)
+              |            -(d_queue-QTH)
+              \ QTH exp(- ----------------) , otherwise.
+                                  QTH
 
-   Here, the queuing delay value is unchanged when it is below the first
-   threshold QTH; it is scaled down following a non-linear curve when
-   its value falls between QTH and QMAX; above QMAX, the high queuing
-   delay value no longer counts toward congestion control.
+   In (1), the queuing delay value is unchanged when it is below the
+   first threshold QTH; otherwise it is scaled down following a non-
+   linear curve.  This non-linear warping is inspired by the delay-
+   adaptive congestion windown backoff policy in [Budzisz-TON11], so as
+   to "gradually nudge" the controller to operate based on loss-induced
+   congestion signals when competing against loss-based flows.  The
+   exact form of the non-linear function has been simplified with
+   respect to [Budzisz-TON11].
 
    The aggregate congestion signal is:
 
        x_curr = d_tilde + p_mark*DMARK + p_loss*DLOSS.      (2)
 
    Here, DMARK is prescribed delay penalty associated with ECN markings
    and DLOSS is prescribed delay penalty associated with packet losses.
    The value of DLOSS and DMARK does not depend on configurations at the
    network node.  Since ECN-enabled active queue management schemes
    typically mark a packet before dropping it, the value of DLOSS SHOULD
@@ -612,26 +615,27 @@
       (rmode=0) or gradual update mode (rmode=1).
 
    o  Aggregated congestion signal (x_curr): the most recently updated
       value, calculated by the receiver according to Section 4.2.  This
       information is expressed with a unit of 100 microsecond (i.e.,
       1/10 of a millisecond) in 15 bits.  This allows a maximum value of
       x_curr at approximately 3.27 second.
 
    o  Receiving rate (r_recv): the most recently measured receiving rate
       according to Section 5.1.3.  This information is expressed with a
-      unit of 10 Kilobits per second (Kbps) in 16 bits.  This allows a
-      maximum rate of approximately 6.55Mbps.
+      unit of bits per second (bps) in 32 bits (unsigned int).  This
+      allows a maximum rate of approximately 4.3Gbps.
 
-   The above list of information can be accommodated by 32 bits in
-   total.  Choice of the feedback message interval DELTA is discussed in
-   Section 6.3 A target feedback interval of DELTA=100ms is recommended.
+   The above list of information can be accommodated by 48 bits, or 6
+   bytes, in total.  Choice of the feedback message interval DELTA is
+   discussed in Section 6.3 A target feedback interval of DELTA=100ms is
+   recommended.
 
 6.  Discussions and Further Investigations
 
 6.1.  Choice of delay metrics
 
    The current design works with relative one-way-delay (OWD) as the
    main indication of congestion.  The value of the relative OWD is
    obtained by maintaining the minimum value of observed OWD over a
    relatively long time horizon and subtract that out from the observed
    absolute OWD value.  Such an approach cancels out the fixed
@@ -695,28 +699,29 @@
    adaptation is mostly driven by the change in the congestion signal
    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 --- less than 0.1% overhead for a 1 Mbps flow.
+   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 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 and QMAX.  It is possible to adapt
-   the value of both based on past observations of queuing delay in the
+   design uses fixed values of QTH and TLOSS (for determining whether to
+   perform the non-linear warpming).  It is possible to adapt the value
+   of both based on past observed patterns of queuing delay in the
    presence of packet losses.
 
    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
@@ -768,35 +773,64 @@
    [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].
 
    The scheme has also been implemented and evaluated in a lab setting
    as described in [IETF-90].  Preliminary evaluation results of NADA in
    single-flow and multi-flow scenarios have been presented in
    [IETF-91].
 
-8.  IANA Considerations
+8.  Suggested Experiments
+
+   NADA has been extensively evaluated under various test scenarios,
+   including the collection of test cases specified by
+   [I-D.ietf-rmcat-eval-test] and the subset of WiFi-based test cases in
+   [I-D.ietf-rmcat-wireless-tests].  Additional evaluations have been
+   carried out to characterize how NADA interacts with various active
+   queue management (AQM) schemes such as RED, CoDel, and PIE.  Most of
+   these evaluations have been carried out in simulators.  A few key
+   test cases have also bee evaluated in implementations embedded in
+   video conferencing clients.
+
+   Further experiments are suggested for the following scenarios:
+
+   o  Experiments with ECN marking capability turned on at the network
+      for existing test cases.
+
+   o  Experiments with multiple RMCAT streams bearing different user-
+      specified priorities.
+
+   o  Experiments with additional access technologies, especially over
+      cellular networks such as 3G/LTE.
+
+   o  Experiments with various media source contents, including audio
+      only, audio and video, and application content sharing (e.g.,
+      slide shows).
+
+   o
+
+9.  IANA Considerations
 
    This document makes no request of IANA.
 
-9.  Acknowledgements
+10.  Acknowledgements
 
    The authors would like to thank Randell Jesup, Luca De Cicco, Piers
    O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes,
    Safiqul Islam, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for
    their valuable questions and comments on earlier versions of this
    draft.
 
-10.  References
+11.  References
 
-10.1.  Normative References
+11.1.  Normative References
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,
               DOI 10.17487/RFC2119, March 1997,
               <http://www.rfc-editor.org/info/rfc2119>.
 
    [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,
               <http://www.rfc-editor.org/info/rfc3168>.
@@ -805,47 +839,47 @@
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
               July 2003, <http://www.rfc-editor.org/info/rfc3550>.
 
    [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, <http://www.rfc-editor.org/info/rfc6679>.
 
    [I-D.ietf-rmcat-eval-test]
-              Sarker, Z., Varun, V., Zhu, X., and M. Ramalho, "Test
+              Sarker, Z., Singh, V., Zhu, X., and D. Ramalho, "Test
               Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
               eval-test-03 (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-video-traffic-model]
               Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic
               Sources for RMCAT Evaluations", draft-ietf-rmcat-video-
-              traffic-model-00 (work in progress), January 2016.
+              traffic-model-01 (work in progress), July 2016.
 
    [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-01
-              (work in progress), October 2015.
+              Applications", draft-ietf-rmcat-cc-codec-interactions-02
+              (work in progress), March 2016.
 
    [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-01 (work in progress), November 2015.
+              wireless-tests-02 (work in progress), May 2016.
 
-10.2.  Informative References
+11.2.  Informative References
 
    [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,
               <http://www.rfc-editor.org/info/rfc2309>.
 
    [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP