--- 1/draft-ietf-rmcat-nada-03.txt	2017-03-27 08:13:37.236788324 -0700
+++ 2/draft-ietf-rmcat-nada-04.txt	2017-03-27 08:13:37.288789551 -0700
@@ -1,25 +1,24 @@
 
 Network Working Group                                             X. Zhu
 Internet-Draft                                                    R. Pan
 Intended status: Experimental                                 M. Ramalho
-Expires: March 22, 2017                                          S. Mena
+Expires: September 28, 2017                                      S. Mena
                                                                 P. Jones
                                                                    J. Fu
                                                            Cisco Systems
                                                              S. D'Aronco
                                                                     EPFL
-                                                             C. Ganzhorn
-                                                      September 18, 2016
+                                                          March 27, 2017
 
      NADA: A Unified Congestion Control Scheme for Real-Time Media
-                        draft-ietf-rmcat-nada-03
+                        draft-ietf-rmcat-nada-04
 
 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,45 +33,45 @@
    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 March 22, 2017.
+   This Internet-Draft will expire on September 28, 2017.
 
 Copyright Notice
 
-   Copyright (c) 2016 IETF Trust and the persons identified as the
+   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
    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 . . . . . . . . . . . . . . . . .   8
+     4.2.  Receiver-Side Algorithm . . . . . . . . . . . . . . . . .   7
      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
@@ -128,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 abrevity.
+   figure for sake of brevity.
 
      +---------+  r_vin  +--------+        +--------+     +----------+
      |  Media  |<--------|  RTP   |        |Network |     |   RTP    |
      | Encoder |========>| Sender |=======>|  Node  |====>| Receiver |
      +---------+  r_vout +--------+ r_send +--------+     +----------+
                              /|\                                |
                               |                                 |
                               +---------------------------------+
                                     RTCP Feedback Report
 
@@ -186,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 mutliplier (gamma) is calculated based on observed round-
+      increase multiplier (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
@@ -236,55 +235,58 @@
      | rmode        | Rate update mode: (0 = accelerated ramp-up;     |
      |              | 1 = gradual update)                             |
      | gamma        | Rate increase multiplier in accelerated ramp-up |
      |              | mode                                            |
      | 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        |
     | 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           |                |
-    | TEXPLOSS     | Expiration time for previously   |     30s        |
-    |              | observed packet loss             |                |
     | 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                          |                |
+    | 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       |
     +..............+..................................+................+
-    | 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         |
     |              | 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                   |
     +--------------+----------------------------------+----------------+
 
@@ -321,48 +323,48 @@
    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
-   TLOSS, the estimated queuing delay follows a non-linear warping:
+   TEXP, the estimated queuing delay follows a non-linear warping:
 
               / d_queue,                if d_queue<QTH;
               |
    d_tilde = <                                           (1)
-              |            -(d_queue-QTH)
-              \ QTH exp(- ----------------) , otherwise.
+              |                  (d_queue-QTH)
+              \ QTH exp(-LAMBDA ---------------) , otherwise.
                                   QTH
 
    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
+   adaptive congestion window 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
-   be higher than that of DMARK.  Furthermore, the values of DLOS and
+   be higher than that of DMARK.  Furthermore, the values of DLOSS and
    DMARK need to be set consistently across all NADA flows for them to
    compete fairly.
 
    In the absence of packet marking and losses, the value of x_curr
    reduces to the observed queuing delay d_queue.  In that case the NADA
    algorithm operates in the regime of delay-based adaptation.
 
    Given observed per-packet delay and loss information, the receiver is
    also in a good position to determine whether the network is
    underutilized and recommend the corresponding rate adaptation mode
@@ -432,27 +434,27 @@
 
    The rate changes in proportion to the previous rate decision.  It is
    affected by two terms: offset of the aggregate congestion signal from
    its value at equilibrium (x_offset) and its change (x_diff).
    Calculation of x_offset depends on maximum rate of the flow (RMAX),
    its weight of priority (PRIO), as well as a reference congestion
    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
+   At equilibrium, the aggregated congestion signal stabilizes 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 maximum rate (RMAX).  Values of RMIN and RMAX will
    be provided by the media codec, as specified in
-   [I-D.ietf-rmcat-cc-codec-interactions].  In the absense of such
+   [I-D.ietf-rmcat-cc-codec-interactions].  In the absence of such
    information, NADA sender will choose a default value of 0 for RMIN,
    and 2Mbps 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)
 
@@ -508,21 +510,21 @@
    The filtered result is reported back to the sender as the observed
    packet loss ratio p_loss.
 
    Estimation of packet marking ratio p_mark follows the same procedure
    as above.  It is assumed that ECN marking information at the IP
    header can be passed to the receiving endpoint, e.g., by following
    the mechanism described in [RFC6679].
 
 5.1.3.  Estimation of receiving rate
 
-   It is fairly straighforward to estimate the receiving rate r_recv.
+   It is fairly straightforward to estimate the receiving rate r_recv.
    NADA maintains a recent observation window with time span of LOGWIN,
    and simply divides the total size of packets arriving during that
    window over the time span.  The receiving rate (r_recv) is included
    as part of the feedback report.
 
 5.2.  Sender-Side Operation
 
    Figure 4 provides a detailed view of the NADA sender.  Upon receipt
    of an RTCP feedback report from the receiver, the NADA sender
    calculates the reference rate r_ref as specified in Section 4.3.  It
@@ -705,39 +707,36 @@
    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 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 TLOSS (for determining whether to
-   perform the non-linear warpming).  It is possible to adapt the value
+   design uses fixed values of QTH and TEXP for determining whether to
+   perform the non-linear warping).  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
    the presence of other competing loss-based flows (e.g., loss-based
    TCP) is under investigation.
 
-   [Editor's note: Choice of start value: is this in scope of congestion
-   control, or should this be decided by the application?]
-
 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
    marking ratio (p_mark), receiving rate (r_recv), and recommended rate
@@ -787,46 +786,47 @@
    [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 reflecting the set up of a typical WAN connection.
+
    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.
 
 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.
+   draft.  Thanks to Charles Ganzhorn for contributing to the testbed-
+   based evaluation of NADA during an early stage of its development.
 
 11.  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>.
 
@@ -839,45 +839,45 @@
               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., Singh, V., Zhu, X., and D. Ramalho, "Test
+              Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
               Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
-              eval-test-03 (work in progress), March 2016.
+              eval-test-04 (work in progress), October 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-01 (work in progress), July 2016.
+              traffic-model-02 (work in progress), January 2017.
 
    [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.
 
    [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-02 (work in progress), May 2016.
+              wireless-tests-03 (work in progress), November 2016.
 
 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>.
@@ -992,25 +992,28 @@
    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 are marked randomly.  The
    marking probability is calculated based on a token-bucket algorithm
    originally designed for the Pre-Congestion Notification (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.
 
-   * upon packet arrival, meter packet against token bucket (r,b);
+   Calculation of the marking probability involves the following steps:
 
-   * update token level b_tk;
+       upon packet arrival:
+           meter packet against token bucket (r,b);
 
-   * calculate the marking probability as:
+           update token level b_tk;
+
+           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
@@ -1037,22 +1040,22 @@
 
    Rong Pan
    Cisco Systems
    3625 Cisco Way
    San Jose, CA  95134
    USA
 
    Email: ropan@cisco.com
    Michael A. Ramalho
    Cisco Systems, Inc.
-   8000 Hawkins Road
-   Sarasota, FL  34241
+   6310 Watercrest Way, Unit 203
+   Lakewood Ranch, FL  34202-5211
    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
@@ -1075,16 +1078,10 @@
 
    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
    Switzerland
 
    Email: stefano.daronco@epfl.ch
-   Charles Ganzhorn
-   7900 International Drive, International Plaza, Suite 400
-   Bloomington, MN  55425
-   USA
-
-   Email: charles.ganzhorn@gmail.com