--- 1/draft-ietf-rmcat-nada-12.txt	2019-09-06 10:13:05.365100431 -0700
+++ 2/draft-ietf-rmcat-nada-13.txt	2019-09-06 10:13:05.429102040 -0700
@@ -1,20 +1,20 @@
 
 Network Working Group                                             X. Zhu
 Internet-Draft                                                    R. Pan
 Intended status: Experimental                                 M. Ramalho
-Expires: February 24, 2020                                       S. Mena
+Expires: March 8, 2020                                           S. Mena
                                                            Cisco Systems
-                                                         August 23, 2019
+                                                       September 5, 2019
 
      NADA: A Unified Congestion Control Scheme for Real-Time Media
-                        draft-ietf-rmcat-nada-12
+                        draft-ietf-rmcat-nada-13
 
 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
@@ -29,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 February 24, 2020.
+   This Internet-Draft will expire on March 8, 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
@@ -68,104 +68,104 @@
        5.1.2.  Estimation of packet loss/marking ratio . . . . . . .  13
        5.1.3.  Estimation of receiving rate  . . . . . . . . . . . .  14
      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.4.  Sender-based vs. receiver-based calculation . . . . . . .  20
      6.5.  Incremental deployment  . . . . . . . . . . . . . . . . .  20
    7.  Reference Implementations . . . . . . . . . . . . . . . . . .  20
    8.  Suggested Experiments . . . . . . . . . . . . . . . . . . . .  21
    9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
    10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
    11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
    12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  22
    13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
      13.1.  Normative References . . . . . . . . . . . . . . . . . .  23
      13.2.  Informative References . . . . . . . . . . . . . . . . .  24
-   Appendix A.  Network Node Operations  . . . . . . . . . . . . . .  27
+   Appendix A.  Network Node Operations  . . . . . . . . . . . . . .  26
      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
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
 
 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].  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
+   called network-assisted dynamic adaptation (NADA).  The design of
+   NADA 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 the
-   desired RTCP feedback message is descirbed in detailed in
+   desired RTCP feedback message is described in detail 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
 
    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
 
                          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 [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
+      media (audio and video) frames into a compressed bitstream which
+      is 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
@@ -181,53 +181,52 @@
 
    o  Network node with several modes of operation.  The system can work
       with the default behavior of a simple drop tail queue.  It can
       also benefit from advanced AQM features such as PIE [RFC8033], FQ-
       CoDel [RFC8290], ECN marking based on RED [RFC7567], and PCN
       marking using a token bucket algorithm ([RFC6660]).  Note that
       network node operation is out of control for the design of NADA.
 
 4.  Core Congestion Control Algorithm
 
-   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:
+   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
    implementations are described in Section 5.1 and Section 5.2.
 
 4.1.  Mathematical Notations
 
    This section summarizes the list of variables and parameters used in
    the NADA algorithm.  Figure 3 also includes the default values for
    choosing the algorithm parameters either to represent a typical
    setting in practical applications or based on theoretical and
    simulation studies.  See Section 6.3 for some of the discussions on
-   the impact of parameter values.  In the experimental phase of this
-   draft, additional studies in real-world settings will gather further
-   learnings on how to choose and adapt these parameter values in
-   practical deployment.
+   the impact of parameter values.  Additional studies in real-world
+   settings suggested in Section 8 could gather further insight on how
+   to choose and adapt these parameter values in practical deployment.
 
      +--------------+-------------------------------------------------+
      | Notation     | Variable Name                                   |
      +--------------+-------------------------------------------------+
      | t_curr       | Current timestamp                               |
      | t_last       | Last time sending/receiving a feedback          |
      | delta        | Observed interval between current and previous  |
      |              | feedback reports: delta = t_curr-t_last         |
      | r_ref        | Reference rate based on network congestion      |
      | r_send       | Sending rate                                    |
@@ -278,21 +277,21 @@
     |              | calculating packet summary       |                |
     |              | statistics at receiver           |                |
     | QEPS         | Threshold for determining queuing|     10ms       |
     |              | delay build up at receiver       |                |
     | DFILT        | Bound on filtering delay         |    120ms       |
     | GAMMA_MAX    | Upper bound on rate increase     |      0.5       |
     |              | ratio for accelerated ramp-up    |                |
     | QBOUND       | Upper bound on self-inflicted    |    50ms        |
     |              | queuing delay during ramp up     |                |
     +..............+..................................+................+
-    | MULTILOSS    | Multiplier for self-scaling the  |     7.         |
+    | MULTILOSS    | Multiplier for self-scaling the  |     7.0        |
     |              | expiration threshold of the last |                |
     |              | observed loss (loss_exp) based on|                |
     |              | measured average loss interval   |                |
     |              | (loss_int)                       |                |
     | QTH          | Delay threshold for invoking     |     50ms       |
     |              | non-linear warping               |                |
     | LAMBDA       | Scaling parameter in the         |     0.5        |
     |              | exponent of non-linear warping   |                |
     +..............+..................................+................+
     | PLRREF       | Reference packet loss ratio      |    0.01        |
@@ -341,21 +340,21 @@
      calculate non-linear warping of delay d_tilde if packet loss exists
      calculate current aggregate congestion signal x_curr
      determine mode of rate adaptation for sender: rmode
      send feedback containing values of: rmode, x_curr, and r_recv
      update t_last = t_curr
 
    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, over wired connections, a moderate queuing delay value on
-   the order of tens of milliseonds is likely self-inflicted or induced
+   the order of tens of milliseconds 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 the last observed packet loss is within the expiration window of
    loss_exp (measured in terms of packet counts), the estimated queuing
    delay follows a non-linear warping:
 
               / d_queue,                   if d_queue<QTH;
               |
@@ -487,28 +486,28 @@
 
    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 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
+   [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 3Mbps for RMAX.
 
    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
@@ -524,34 +523,37 @@
    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
    includes that in the feedback message.
 
 5.1.1.  Estimation of one-way delay and queuing delay
 
    The delay estimation process in NADA follows a similar approach as in
    earlier delay-based congestion control schemes, such as LEDBAT
-   [RFC6817].  Instead of relying on RTP timestamps, the NADA sender
-   generates its own timestamp based on local system clock and embeds
-   that information in the transport packet header.  The NADA receiver
-   estimates the forward delay as having a constant base delay component
-   plus a time varying queuing delay component.  The base delay is
-   estimated as the minimum value of one-way delay observed over a
-   relatively long period (e.g., tens of minutes), whereas the
-   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.
+   [RFC6817].  For experimental implementations, instead of relying on
+   RTP timestamps and the transmission time offset RTP header extension
+   [RFC5450], the NADA sender can generate its own timestamp based on
+   local system clock and embed that information in the transport packet
+   header.  The NADA receiver estimates the forward delay as having a
+   constant base delay component plus a time varying queuing delay
+   component.  The base delay is estimated as the minimum value of one-
+   way delay observed over a relatively long period (e.g., tens of
+   minutes), whereas the 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 or
+   cumulative timing difference introduced by the clock rate skew
+   between sender and receiver.  All delay estimations are based on
+   sender timestamps with a recommended granularity of 100 microseconds
+   or finer.
 
    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, 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
@@ -571,21 +573,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) 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
@@ -689,21 +691,21 @@
 
    The following list of information is required for NADA congestion
    control to function properly:
 
    o  Recommended rate adaptation mode (rmode): a 1-bit flag indicating
       whether the sender should operate in accelerated ramp-up mode
       (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.,
+      information can be 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 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
@@ -733,34 +735,35 @@
    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
    difference between the sender and receiver clocks.  It has been
    widely adopted by other delay-based congestion control approaches
    such as [RFC6817].  As discussed in [RFC6817], the time horizon for
    tracking the minimum OWD needs to be chosen with care: it must be
    long enough for an opportunity to observe the minimum OWD with zero
    standing queue along the path, and sufficiently short so as to timely
    reflect "true" changes in minimum OWD introduced by route changes and
-   other rare events.
+   other rare events and to mitigate the cumulative impact of clock rate
+   skew over time.
 
    The potential drawback in relying on relative OWD as the congestion
    signal is that when multiple flows share the same bottleneck, the
    flow arriving late at the network experiencing a non-empty queue may
    mistakenly consider the standing queuing delay as part of the fixed
    path propagation delay.  This will lead to slightly unfair bandwidth
    sharing among the flows.
 
    Alternatively, one could move the per-packet statistical handling to
    the sender instead and use relative round-trip-time (RTT) in lieu of
-   relative OWD, assuming that per-packet acknowledgements are
-   available.  The main drawback of RTT-based approach is the noise in
-   the measured delay in the reverse direction.
+   relative OWD, assuming that per-packet acknowledgments are available.
+   The main drawback of RTT-based approach is the noise in the measured
+   delay in the reverse direction.
 
    Note that the choice of either delay metric (relative OWD vs. RTT)
    involves no change in the proposed rate adaptation algorithm.
    Therefore, comparing the pros and cons regarding which delay metric
    to adopt can be kept as an orthogonal direction of investigation.
 
 6.2.  Method for delay, loss, and marking ratio estimation
 
    Like other delay-based congestion control schemes, performance of
    NADA depends on the accuracy of its delay measurement and estimation
@@ -803,36 +806,36 @@
    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 should be carefully tuned for
-   different operational enviornments (e.g., over wired vs. wireless
+   different operational environments (e.g., over wired vs. wireless
    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
+   encourages further 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) in use.
 
@@ -864,26 +867,27 @@
 
    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 Implementations
 
    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,
+   calculations as described 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.
 
@@ -880,53 +884,53 @@
    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.
 
-   [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].
+   [IETF-90] describes the implementation 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
+   drops caused by intermittent delay spikes over the last-hop wireless
    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 or automatically adapte the values of the key
+   on how to choose or automatically adapt 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:
+   preferably 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 NADA streams bearing different user-
       specified priorities.
 
    o  Experiments with additional access technologies, especially over
@@ -1054,25 +1058,20 @@
    [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-eval-test]
               Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
               Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
               eval-test-10 (work in progress), May 2019.
 
-   [I-D.ietf-rmcat-video-traffic-model]
-              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,
@@ -1113,20 +1112,24 @@
    [ns-2]     "The Network Simulator - ns-2",
               <http://www.isi.edu/nsnam/ns/>.
 
    [ns-3]     "The Network Simulator - ns-3", <https://www.nsnam.org/>.
 
    [ns3-rmcat]
               Fu, J., Mena, S., and X. Zhu, "NS3 open source module of
               IETF RMCAT congestion control protocols", November 2017,
               <https://github.com/cisco/ns3-rmcat>.
 
+   [RFC5450]  Singer, D. and H. Desineni, "Transmission Time Offsets in
+              RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009,
+              <https://www.rfc-editor.org/info/rfc5450>.
+
    [RFC6660]  Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
               Pre-Congestion Notification (PCN) States in the IP Header
               Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
               DOI 10.17487/RFC6660, July 2012,
               <https://www.rfc-editor.org/info/rfc6660>.
 
    [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
               "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
               DOI 10.17487/RFC6817, December 2012,
               <https://www.rfc-editor.org/info/rfc6817>.