--- 1/draft-ietf-rmcat-nada-11.txt	2019-08-24 21:13:13.199841802 -0700
+++ 2/draft-ietf-rmcat-nada-12.txt	2019-08-24 21:13:13.259843326 -0700
@@ -1,24 +1,20 @@
 
 Network Working Group                                             X. Zhu
 Internet-Draft                                                    R. Pan
 Intended status: Experimental                                 M. Ramalho
-Expires: January 26, 2020                                        S. Mena
-                                                                P. Jones
-                                                                   J. Fu
+Expires: February 24, 2020                                       S. Mena
                                                            Cisco Systems
-                                                             S. D'Aronco
-                                                                     ETH
-                                                           July 25, 2019
+                                                         August 23, 2019
 
      NADA: A Unified Congestion Control Scheme for Real-Time Media
-                        draft-ietf-rmcat-nada-11
+                        draft-ietf-rmcat-nada-12
 
 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 +29,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 January 26, 2020.
+   This Internet-Draft will expire on February 24, 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
@@ -74,63 +70,68 @@
      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  . . . . . . . . . . . . . . . . .  20
-   7.  Reference Implementation  . . . . . . . . . . . . . . . . . .  20
-   8.  Suggested Experiments . . . . . . . . . . . . . . . . . . . .  20
-   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
-   10. Security Considerations . . . . . . . . . . . . . . . . . . .  21
+   7.  Reference Implementations . . . . . . . . . . . . . . . . . .  20
+   8.  Suggested Experiments . . . . . . . . . . . . . . . . . . . .  21
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
+   10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
    11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
-   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
-     12.1.  Normative References . . . . . . . . . . . . . . . . . .  22
-     12.2.  Informative References . . . . . . . . . . . . . . . . .  22
-   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
+   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  22
+   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
+     13.1.  Normative References . . . . . . . . . . . . . . . . . .  23
+     13.2.  Informative References . . . . . . . . . . . . . . . . .  24
+   Appendix A.  Network Node Operations  . . . . . . . . . . . . . .  27
+     A.1.  Default behavior of drop tail queues  . . . . . . . . . .  27
+     A.2.  RED-based ECN marking . . . . . . . . . . . . . . . . . .  27
+     A.3.  Random Early Marking with Virtual Queues  . . . . . . . .  28
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29
 
 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
    congestion notification (ECN) [RFC3168] markings.  The requirements
    for the congestion control algorithm are outlined in
-   [I-D.ietf-rmcat-cc-requirements].
+   [I-D.ietf-rmcat-cc-requirements].  It highlights that the desired
+   congestion control scheme should avoid flow starvation and attain a
+   reasonable fair share of bandwidth when competing against other
+   flows, adapt quickly, and operate in a stable manner.
 
    This document describes an experimental congestion control scheme
    called network-assisted dynamic adaptation (NADA).  The NADA design
    benefits from explicit congestion control signals (e.g., ECN
    markings) from the network, yet also operates when only implicit
    congestion indicators (delay and/or loss) are available.  Such a
    unified sender behavior distinguishes NADA from other congestion
    control schemes for real-time media.  In addition, its core
    congestion control algorithm is designed to guarantee stability for
    path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms
    with default parameter choices).  It further supports weighted
    bandwidth sharing among competing video flows with different
    priorities.  The signaling mechanism consists of standard RTP
-   timestamp [RFC3550] and RTCP feedback reports.  The definition of
-   standardized RTCP feedback message requires future work so as to
-   support the successful operation of several congestion control
-   schemes for real-time interactive media.
+   timestamp [RFC3550] and RTCP feedback reports.  The definition of the
+   desired RTCP feedback message is descirbed in detailed in
+   [I-D.ietf-avtcore-cc-feedback-message] so as to support the
+   successful operation of several congestion control schemes for real-
+   time interactive media.
 
 2.  Terminology
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.
 
 3.  System Overview
@@ -147,26 +148,25 @@
      +---------+  r_vout +--------+ r_send +--------+     +----------+
                              /|\                                |
                               |                                 |
                               +---------------------------------+
                                     RTCP Feedback Report
 
                          Figure 1: System Overview
 
    o  Media encoder with rate control capabilities.  It encodes raw
       media (audio and video) frames into compressed bitstream which is
-      later packetized into RTP packets.  As discussed in
-      [I-D.ietf-rmcat-video-traffic-model], the actual output rate from
-      the encoder r_vout may fluctuate around the target r_vin.
-      Furthermore, it is possible that the encoder can only react to bit
-      rate changes at rather coarse time intervals, e.g., once every 0.5
-      seconds.
+      later packetized into RTP packets.  As discussed in [RFC8593], the
+      actual output rate from the encoder r_vout may fluctuate around
+      the target r_vin.  Furthermore, it is possible that the encoder
+      can only react to bit rate changes at rather coarse time
+      intervals, e.g., once every 0.5 seconds.
 
    o  RTP sender: responsible for calculating the NADA reference rate
       based on network congestion indicators (delay, loss, or ECN
       marking reports from the receiver), for updating the video encoder
       with a new target rate r_vin, and for regulating the actual
       sending rate r_send accordingly.  The RTP sender also generates a
       sending timestamp for each outgoing packet.
 
    o  RTP receiver: responsible for measuring and estimating end-to-end
       delay (based on sender timestamp), packet loss (based on RTP
@@ -360,33 +360,34 @@
               / d_queue,                   if d_queue<QTH;
               |
    d_tilde = <                                           (1)
               |                  (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 value of the threshold QTH may need
-   to tuned for different operational environments.  Typically, a higher
-   value of QTH is required in a noisier environment (e.g., over
-   wireless connections, or where the video stream encounters many time-
-   varying background competing traffic) so as to stay robust against
-   occasional non-congestion-induced delay spikes.  Additional insights
-   on how this value can be tuned or auto-tuned should be gathered from
-   carrying out experimental studies in different real-world deployment
-   scenarios.
+   respect to [Budzisz-TON11].  The value of the threshold QTH should be
+   carefully tuned for different operational environments, so as to
+   avoid potential risks of prematurely discounting the congestion
+   signal level.  Typically, a higher value of QTH is required in a
+   noisier environment (e.g., over wireless connections, or where the
+   video stream encounters many time-varying background competing
+   traffic) so as to stay robust against occasional non-congestion-
+   induced delay spikes.  Additional insights on how this value can be
+   tuned or auto-tuned should be gathered from carrying out experimental
+   studies in different real-world deployment scenarios.
 
    The value of loss_exp is configured to self-scale with the average
    packet loss interval loss_int with a multiplier MULTILOSS:
 
          loss_exp = MULTILOSS * loss_int.
 
    Estimation of the average loss interval loss_int, in turn, follows
    Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol
    [RFC5348].
 
@@ -496,31 +498,30 @@
    = 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, 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 3Mbps for RMAX.
 
-   As mentioned in the sender-side algorithm, the final rate is clipped
-   within the dynamic range specified by the application:
+   As mentioned in the sender-side algorithm, the final rate is always
+   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
    delay measurements, and base delay expiration.  These will be
-   addressed in Section 5
+   addressed in Section 5.
 
 5.  Practical Implementation of NADA
 
 5.1.  Receiver-Side Operation
 
    The receiver continuously monitors end-to-end per-packet statistics
    in terms of delay, loss, and/or ECN marking ratios.  It then
    aggregates all forms of congestion indicators into the form of an
    equivalent delay and periodically reports this back to the sender.
    In addition, the receiver tracks the receiving rate of the flow and
@@ -540,25 +541,25 @@
    individual queuing delay value is taken to be the difference between
    one-way delay and base delay.  By re-estimating the base delay
    periodically, one can avoid the potential issue of base delay
    expiration, whereby an earlier measured base delay value is no longer
    valid due to underlying route changes.  All delay estimations are
    based on sender timestamps with a recommended granularity of 100
    microseconds or higher.
 
    The individual sample values of queuing delay should be further
    filtered against various non-congestion-induced noise, such as spikes
-   due to processing "hiccup" at the network nodes.  Therefore, instead
-   of simply calculating the value of base delay using d_base =
-   min(d_base, d_fwd), as expressed in Section 5.1, current
-   implementation employs a minimum filter with a window size of 15
-   samples over per-packet queuing delay values.
+   due to processing "hiccup" at the network nodes.  Therefore, in
+   addition to calculating the value of queuing delay using d_queue =
+   d_fwd - d_base, as expressed in Section 5.1, current implementation
+   further employs a minimum filter with a window size of 15 samples
+   over per-packet queuing delay values.
 
 5.1.2.  Estimation of packet loss/marking ratio
 
    The receiver detects packet losses via gaps in the RTP sequence
    numbers of received packets.  For interactive real-time media
    application with stringent latency constraint (e.g., video
    conferencing), the receiver avoids the packet re-ordering delay by
    treating out-of-order packets as losses.  The instantaneous packet
    loss ratio p_inst is estimated as the ratio between the number of
    missing packets over the number of total transmitted packets within
@@ -573,22 +574,23 @@
    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.
    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.
+   window over the time span.  The receiving rate (r_recv) can be
+   calculated at either the sender side based on the per-packet feedback
+   from the receiver, or 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
    further adjusts both the target rate for the live video encoder r_vin
    and the sending rate r_send over the network based on the updated
    value of r_ref and rate shaping buffer occupancy buffer_len.
 
@@ -701,23 +703,27 @@
    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 bits per second (bps) in 32 bits (unsigned int).  This
       allows a maximum rate of approximately 4.3Gbps, approximately 1000
       times of the streaming rate of a typical high-definition (HD)
       video conferencing session today.  This field can be expanded
       further by a few more bytes, in case an even higher rate need to
       be specified.
 
    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.
+   bytes, in total.  They can be either included in the feedback report
+   from the receiver, or, in the case where all receiver-side
+   calculations are moved to the sender, derived from per-packet
+   information from the feedback message as defined in
+   [I-D.ietf-avtcore-cc-feedback-message].  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
 
    This section discussed the various design choices made by NADA,
    potential alternative variants of its implementation, and guidelines
    on how the key algorithm parameters can be chosen.  Section 8
    recommends additional experimental setups to further explore these
    topics.
 
 6.1.  Choice of delay metrics
@@ -796,156 +802,206 @@
    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 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
+   the non-linear warping).  Its value should be carefully 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.
+   connections), so as to avoid the potential risk of prematurely
+   discounting the congestion signal level.  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, 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
-   marking ratio (p_mark), receiving rate (r_recv), and recommended rate
-   adaptation mode (rmode).
+   (delay, loss, or marking) in use.
+
+   Alternatively, one can shift receiver-side calculations to the
+   sender, whereby the receiver simply reports on per-packet information
+   via periodic feedback messages as defined in
+   [I-D.ietf-avtcore-cc-feedback-message].  Such an approach enables
+   interoperability amongst senders operating on different congestion
+   control schemes, but requires slightly higher overhead in the
+   feedback messages.  See additional discussions in
+   [I-D.ietf-avtcore-cc-feedback-message] regarding the desired format
+   of the feedback messages and the recommended feedback intervals.
 
 6.5.  Incremental deployment
 
    One nice property of NADA is the consistent video endpoint behavior
    irrespective of network node variations.  This facilitates gradual,
    incremental adoption of the scheme.
 
-   To start off with, the proposed congestion control mechanism can be
+   Initially, the proposed congestion control mechanism can be
    implemented without any explicit support from the network, and relies
-   solely on observed one-way delay measurements and packet loss ratios
-   as implicit congestion signals.
+   solely on observed relative one-way delay measurements and packet
+   loss ratios as implicit congestion signals.
 
    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.  Reference Implementation
+7.  Reference Implementations
 
-   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]
+   The NADA scheme has been implemented in both [ns-2] and [ns-3]
+   simulation platforms.  The implementation in ns-2 hosts the
+   calculations as descirbed in Section 4.2 at the receiver side,
+   whereas the implementation in ns-3 hosts these receiver-side
+   calculations at the sender for the sake of interoperability.
+   Extensive ns-2 simulation evaluations of an earlier version of the
+   draft are documented in [Zhu-PV13].  An open source implementation of
+   NADA as part of a ns-3 module is available at [ns3-rmcat].
+   Evaluation results of the current draft based on ns-3 are presented
+   in [IETF-90] and [IETF-91] for wired test cases as documented in
+   [I-D.ietf-rmcat-eval-test].  Evaluation results of NADA over WiFi-
+   based test cases as defined in [I-D.ietf-rmcat-wireless-tests] are
+   presented in [IETF-93].  These simulation-based evaluations have
+   shown that NADA flows can obtain their fair share of bandwidth when
+   competing against each other.  They typically adapt fast in reaction
+   to the arrival and departure of other flows, and can sustain a
+   reasonable throughput when competing against loss-based TCP flows.
 
-   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].
+   [IETF-90] describes the implemention and evaluation of NADA in a lab
+   setting.  Preliminary evaluation results of NADA in single-flow and
+   multi-flow test scenarios have been presented in [IETF-91].
+
+   A reference implementation of NADA has been carried out by modifying
+   the WebRTC module embedded in the Mozilla open source browser.
+   Presentations from [IETF-103] and [IETF-105] document real-world
+   evaluations of the modified browser driven by NADA.  The experimental
+   setting involve remote connections with endpoints over either home or
+   enterprise wireless networks.  These evaluations validate the
+   effectiveness of NADA flows in recovering quickly from throughput
+   drops caused by intermittent delay spikes over the last-hop wirelss
+   connections.
 
 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 been evaluated in lab environments with
    implementations embedded in video conferencing clients.  It is
    strongly recommended to carry out implementation and experimentation
    of NADA in real-world settings.  Such exercise will provide insights
-   on how to choose to automatically adapte the values of the key
+   on how to choose or automatically adapte the values of the key
    algorithm parameters (see list in Figure 3) as discussed in
    Section 6.
 
    Additional experiments are suggested for the following scenarios and
    preferrably over real-world networks:
 
    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-
+   o  Experiments with multiple NADA 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).
 
 9.  IANA Considerations
 
    This document makes no request of IANA.
 
 10.  Security Considerations
 
    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.
+   messages are hijacked, replaced, or intentionally injected with
+   misleading information resulting in denial of service, similar to
+   those that can affect TCP.  It is therefore RECOMMENDED that the RTCP
+   feedback message is at least integrity checked.  In addition,
+   [I-D.ietf-avtcore-cc-feedback-message] discusses the potential risk
+   of a receiver providing misleading congestion feedback information
+   and the mechanisms for mitigating such risks.
+
+   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.
+   Stiemerling for their valuable review comments and helpful input to
+   this specification.
 
-12.  References
+12.  Contributors
 
-12.1.  Normative References
+   The following individuals have contributed to the implementation and
+   evaluation of the proposed scheme, and therefore have 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 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.
+
+13.  References
+
+13.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,
               <https://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,
               <https://www.rfc-editor.org/info/rfc3168>.
@@ -962,34 +1018,40 @@
 
    [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, <https://www.rfc-editor.org/info/rfc6679>.
 
    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
               May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 
-12.2.  Informative References
+13.2.  Informative References
 
    [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.
 
    [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-avtcore-cc-feedback-message]
+              Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
+              Control Protocol (RTCP) Feedback for Congestion Control",
+              draft-ietf-avtcore-cc-feedback-message-04 (work in
+              progress), July 2019.
+
    [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-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.
@@ -1003,20 +1065,35 @@
               Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models
               for RTP Congestion Control Evaluations", draft-ietf-rmcat-
               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-08 (work in progress), July 2019.
 
+   [IETF-103]
+              Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu,
+              J., and S. D'Aronco, "NADA Implementation in Mozilla
+              Browser", November 2018,
+              <https://datatracker.ietf.org/meeting/103/materials/
+              slides-103-rmcat-nada-implementation-in-mozilla-browser-
+              00>.
+
+   [IETF-105]
+              Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu,
+              J., and S. D'Aronco, "NADA Implementation in Mozilla
+              Browser and Draft Update", July 2019,
+              <https://datatracker.ietf.org/meeting/105/materials/
+              slides-105-rmcat-nada-update-02.pdf>.
+
    [IETF-90]  Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan,
               "NADA Update: Algorithm, Implementation, and Test Case
               Evalua6on Results", July 2014,
               <https://tools.ietf.org/agenda/90/slides/
               slides-90-rmcat-6.pdf>.
 
    [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,
               <http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/
@@ -1064,20 +1141,25 @@
               Lightweight Control Scheme to Address the Bufferbloat
               Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
               <https://www.rfc-editor.org/info/rfc8033>.
 
    [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,
               <https://www.rfc-editor.org/info/rfc8290>.
 
+   [RFC8593]  Zhu, X., Mena, S., and Z. Sarker, "Video Traffic Models
+              for RTP Congestion Control Evaluations", RFC 8593,
+              DOI 10.17487/RFC8593, May 2019,
+              <https://www.rfc-editor.org/info/rfc8593>.
+
    [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,
@@ -1175,50 +1257,27 @@
    12515 Research Blvd., Building 4
    Austin, TX  78759
    USA
 
    Email: xiaoqzhu@cisco.com
 
    Rong Pan *
    * Pending affiliation change.
 
    Email: rong.pan@gmail.com
+
    Michael A. Ramalho
    Cisco Systems, Inc.
    8000 Hawkins Road
    Sarasota, FL  34241
    USA
 
    Phone: +1 919 476 2038
-   Email: mramalho@cisco.com
+   Email: mar42@cornell.edu
 
    Sergio Mena de la Cruz
    Cisco Systems
    EPFL, Quartier de l'Innovation, Batiment E
    Ecublens, Vaud  1015
    Switzerland
 
    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
-   ETH Zurich
-   Stefano-Franscini-Platz 5
-   Zurich  8093
-   Switzerland
-
-   Email: stefano.daronco@geod.baug.ethz.ch