draft-ietf-rmcat-nada-12.txt   draft-ietf-rmcat-nada-13.txt 
Network Working Group X. Zhu Network Working Group X. Zhu
Internet-Draft R. Pan Internet-Draft R. Pan
Intended status: Experimental M. Ramalho Intended status: Experimental M. Ramalho
Expires: February 24, 2020 S. Mena Expires: March 8, 2020 S. Mena
Cisco Systems Cisco Systems
August 23, 2019 September 5, 2019
NADA: A Unified Congestion Control Scheme for Real-Time Media NADA: A Unified Congestion Control Scheme for Real-Time Media
draft-ietf-rmcat-nada-12 draft-ietf-rmcat-nada-13
Abstract Abstract
This document describes NADA (network-assisted dynamic adaptation), a This document describes NADA (network-assisted dynamic adaptation), a
novel congestion control scheme for interactive real-time media novel congestion control scheme for interactive real-time media
applications, such as video conferencing. In the proposed scheme, applications, such as video conferencing. In the proposed scheme,
the sender regulates its sending rate based on either implicit or the sender regulates its sending rate based on either implicit or
explicit congestion signaling, in a unified approach. The scheme can explicit congestion signaling, in a unified approach. The scheme can
benefit from explicit congestion notification (ECN) markings from benefit from explicit congestion notification (ECN) markings from
network nodes. It also maintains consistent sender behavior in the network nodes. It also maintains consistent sender behavior in the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5.1.2. Estimation of packet loss/marking ratio . . . . . . . 13 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 13
5.1.3. Estimation of receiving rate . . . . . . . . . . . . 14 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 14
5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 14 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 14
5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 15 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 15
5.2.2. Adjusting video target rate and sending rate . . . . 16 5.2.2. Adjusting video target rate and sending rate . . . . 16
5.3. Feedback Message Requirements . . . . . . . . . . . . . . 16 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 16
6. Discussions and Further Investigations . . . . . . . . . . . 17 6. Discussions and Further Investigations . . . . . . . . . . . 17
6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 17 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 17
6.2. Method for delay, loss, and marking ratio estimation . . 18 6.2. Method for delay, loss, and marking ratio estimation . . 18
6.3. Impact of parameter values . . . . . . . . . . . . . . . 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 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 20
7. Reference Implementations . . . . . . . . . . . . . . . . . . 20 7. Reference Implementations . . . . . . . . . . . . . . . . . . 20
8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 21 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 24 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.1. Default behavior of drop tail queues . . . . . . . . . . 27
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 27 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 27
A.3. Random Early Marking with Virtual Queues . . . . . . . . 28 A.3. Random Early Marking with Virtual Queues . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Interactive real-time media applications introduce a unique set of Interactive real-time media applications introduce a unique set of
challenges for congestion control. Unlike TCP, the mechanism used challenges for congestion control. Unlike TCP, the mechanism used
for real-time media needs to adapt quickly to instantaneous bandwidth for real-time media needs to adapt quickly to instantaneous bandwidth
changes, accommodate fluctuations in the output of video encoder rate changes, accommodate fluctuations in the output of video encoder rate
control, and cause low queuing delay over the network. An ideal control, and cause low queuing delay over the network. An ideal
scheme should also make effective use of all types of congestion scheme should also make effective use of all types of congestion
signals, including packet loss, queuing delay, and explicit signals, including packet loss, queuing delay, and explicit
congestion notification (ECN) [RFC3168] markings. The requirements congestion notification (ECN) [RFC3168] markings. The requirements
for the congestion control algorithm are outlined in for the congestion control algorithm are outlined in
[I-D.ietf-rmcat-cc-requirements]. It highlights that the desired [I-D.ietf-rmcat-cc-requirements]. It highlights that the desired
congestion control scheme should avoid flow starvation and attain a congestion control scheme should avoid flow starvation and attain a
reasonable fair share of bandwidth when competing against other reasonable fair share of bandwidth when competing against other
flows, adapt quickly, and operate in a stable manner. flows, adapt quickly, and operate in a stable manner.
This document describes an experimental congestion control scheme This document describes an experimental congestion control scheme
called network-assisted dynamic adaptation (NADA). The NADA design called network-assisted dynamic adaptation (NADA). The design of
benefits from explicit congestion control signals (e.g., ECN NADA benefits from explicit congestion control signals (e.g., ECN
markings) from the network, yet also operates when only implicit markings) from the network, yet also operates when only implicit
congestion indicators (delay and/or loss) are available. Such a congestion indicators (delay and/or loss) are available. Such a
unified sender behavior distinguishes NADA from other congestion unified sender behavior distinguishes NADA from other congestion
control schemes for real-time media. In addition, its core control schemes for real-time media. In addition, its core
congestion control algorithm is designed to guarantee stability for congestion control algorithm is designed to guarantee stability for
path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms
with default parameter choices). It further supports weighted with default parameter choices). It further supports weighted
bandwidth sharing among competing video flows with different bandwidth sharing among competing video flows with different
priorities. The signaling mechanism consists of standard RTP priorities. The signaling mechanism consists of standard RTP
timestamp [RFC3550] and RTCP feedback reports. The definition of the 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 [I-D.ietf-avtcore-cc-feedback-message] so as to support the
successful operation of several congestion control schemes for real- successful operation of several congestion control schemes for real-
time interactive media. time interactive media.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. System Overview 3. System Overview
Figure 1 shows the end-to-end system for real-time media transport Figure 1 shows the end-to-end system for real-time media transport
that NADA operates in. Note that there also exist network nodes that NADA operates in. Note that there also exist network nodes
along the reverse (potentially uncongested) path that the RTCP along the reverse (potentially uncongested) path that the RTCP
feedback reports traverse. Those network nodes are not shown in the feedback reports traverse. Those network nodes are not shown in the
figure for sake of abrevity. figure for sake of brevity.
+---------+ r_vin +--------+ +--------+ +----------+ +---------+ r_vin +--------+ +--------+ +----------+
| Media |<--------| RTP | |Network | | RTP | | Media |<--------| RTP | |Network | | RTP |
| Encoder |========>| Sender |=======>| Node |====>| Receiver | | Encoder |========>| Sender |=======>| Node |====>| Receiver |
+---------+ r_vout +--------+ r_send +--------+ +----------+ +---------+ r_vout +--------+ r_send +--------+ +----------+
/|\ | /|\ |
| | | |
+---------------------------------+ +---------------------------------+
RTCP Feedback Report RTCP Feedback Report
Figure 1: System Overview Figure 1: System Overview
o Media encoder with rate control capabilities. It encodes raw o Media encoder with rate control capabilities. It encodes raw
media (audio and video) frames into compressed bitstream which is media (audio and video) frames into a compressed bitstream which
later packetized into RTP packets. As discussed in [RFC8593], the is later packetized into RTP packets. As discussed in [RFC8593],
actual output rate from the encoder r_vout may fluctuate around the actual output rate from the encoder r_vout may fluctuate
the target r_vin. Furthermore, it is possible that the encoder around the target r_vin. Furthermore, it is possible that the
can only react to bit rate changes at rather coarse time encoder can only react to bit rate changes at rather coarse time
intervals, e.g., once every 0.5 seconds. intervals, e.g., once every 0.5 seconds.
o RTP sender: responsible for calculating the NADA reference rate o RTP sender: responsible for calculating the NADA reference rate
based on network congestion indicators (delay, loss, or ECN based on network congestion indicators (delay, loss, or ECN
marking reports from the receiver), for updating the video encoder marking reports from the receiver), for updating the video encoder
with a new target rate r_vin, and for regulating the actual with a new target rate r_vin, and for regulating the actual
sending rate r_send accordingly. The RTP sender also generates a sending rate r_send accordingly. The RTP sender also generates a
sending timestamp for each outgoing packet. sending timestamp for each outgoing packet.
o RTP receiver: responsible for measuring and estimating end-to-end o RTP receiver: responsible for measuring and estimating end-to-end
skipping to change at page 5, line 7 skipping to change at page 5, line 7
o Network node with several modes of operation. The system can work o Network node with several modes of operation. The system can work
with the default behavior of a simple drop tail queue. It can with the default behavior of a simple drop tail queue. It can
also benefit from advanced AQM features such as PIE [RFC8033], FQ- also benefit from advanced AQM features such as PIE [RFC8033], FQ-
CoDel [RFC8290], ECN marking based on RED [RFC7567], and PCN CoDel [RFC8290], ECN marking based on RED [RFC7567], and PCN
marking using a token bucket algorithm ([RFC6660]). Note that marking using a token bucket algorithm ([RFC6660]). Note that
network node operation is out of control for the design of NADA. network node operation is out of control for the design of NADA.
4. Core Congestion Control Algorithm 4. Core Congestion Control Algorithm
Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA Like TCP-Friendly Rate Control (TFRC)[Floyd-CCR00] [RFC5348], NADA is
is a rate-based congestion control algorithm. In its simplest form, a rate-based congestion control algorithm. In its simplest form, the
the sender reacts to the collection of network congestion indicators sender reacts to the collection of network congestion indicators in
in the form of an aggregated congestion signal, and operates in one the form of an aggregated congestion signal, and operates in one of
of two modes: two modes:
o Accelerated ramp-up: when the bottleneck is deemed to be o Accelerated ramp-up: when the bottleneck is deemed to be
underutilized, the rate increases multiplicatively with respect to underutilized, the rate increases multiplicatively with respect to
the rate of previously successful transmissions. The rate 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- trip-time and target feedback interval, so as to limit self-
inflicted queuing delay. inflicted queuing delay.
o Gradual rate update: in the presence of non-zero aggregate o Gradual rate update: in the presence of non-zero aggregate
congestion signal, the sending rate is adjusted in reaction to congestion signal, the sending rate is adjusted in reaction to
both its value (x_curr) and its change in value (x_diff). both its value (x_curr) and its change in value (x_diff).
This section introduces the list of mathematical notations and This section introduces the list of mathematical notations and
describes the core congestion control algorithm at the sender and describes the core congestion control algorithm at the sender and
receiver, respectively. Additional details on recommended practical receiver, respectively. Additional details on recommended practical
implementations are described in Section 5.1 and Section 5.2. implementations are described in Section 5.1 and Section 5.2.
4.1. Mathematical Notations 4.1. Mathematical Notations
This section summarizes the list of variables and parameters used in This section summarizes the list of variables and parameters used in
the NADA algorithm. Figure 3 also includes the default values for the NADA algorithm. Figure 3 also includes the default values for
choosing the algorithm parameters either to represent a typical choosing the algorithm parameters either to represent a typical
setting in practical applications or based on theoretical and setting in practical applications or based on theoretical and
simulation studies. See Section 6.3 for some of the discussions on simulation studies. See Section 6.3 for some of the discussions on
the impact of parameter values. In the experimental phase of this the impact of parameter values. Additional studies in real-world
draft, additional studies in real-world settings will gather further settings suggested in Section 8 could gather further insight on how
learnings on how to choose and adapt these parameter values in to choose and adapt these parameter values in practical deployment.
practical deployment.
+--------------+-------------------------------------------------+ +--------------+-------------------------------------------------+
| Notation | Variable Name | | Notation | Variable Name |
+--------------+-------------------------------------------------+ +--------------+-------------------------------------------------+
| t_curr | Current timestamp | | t_curr | Current timestamp |
| t_last | Last time sending/receiving a feedback | | t_last | Last time sending/receiving a feedback |
| delta | Observed interval between current and previous | | delta | Observed interval between current and previous |
| | feedback reports: delta = t_curr-t_last | | | feedback reports: delta = t_curr-t_last |
| r_ref | Reference rate based on network congestion | | r_ref | Reference rate based on network congestion |
| r_send | Sending rate | | r_send | Sending rate |
| r_recv | Receiving rate | | r_recv | Receiving rate |
| r_vin | Target rate for video encoder | | r_vin | Target rate for video encoder |
| r_vout | Output rate from video encoder | | r_vout | Output rate from video encoder |
| d_base | Estimated baseline delay | | d_base | Estimated baseline delay |
| d_fwd | Measured and filtered one-way delay | | d_fwd | Measured and filtered one-way delay |
| d_queue | Estimated queuing delay | | d_queue | Estimated queuing delay |
| d_tilde | Equivalent delay after non-linear warping | | d_tilde | Equivalent delay after non-linear warping |
| p_mark | Estimated packet ECN marking ratio | | p_mark | Estimated packet ECN marking ratio |
| p_loss | Estimated packet loss ratio | | p_loss | Estimated packet loss ratio |
| x_curr | Aggregate congestion signal | | x_curr | Aggregate congestion signal |
| x_prev | Previous value of aggregate congestion signal | | x_prev | Previous value of aggregate congestion signal |
| x_diff | Change in aggregate congestion signal w.r.t. | | x_diff | Change in aggregate congestion signal w.r.t. |
| | its previous value: x_diff = x_curr - x_prev | | | its previous value: x_diff = x_curr - x_prev |
| rmode | Rate update mode: (0 = accelerated ramp-up; | | rmode | Rate update mode: (0 = accelerated ramp-up; |
| | 1 = gradual update) | | | 1 = gradual update) |
| gamma | Rate increase multiplier in accelerated ramp-up | | gamma | Rate increase multiplier in accelerated ramp-up |
skipping to change at page 6, line 44 skipping to change at page 6, line 44
| rtt | Estimated round-trip-time at sender | | rtt | Estimated round-trip-time at sender |
| buffer_len | Rate shaping buffer occupancy measured in bytes | | buffer_len | Rate shaping buffer occupancy measured in bytes |
+--------------+-------------------------------------------------+ +--------------+-------------------------------------------------+
Figure 2: List of variables. Figure 2: List of variables.
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
| Notation | Parameter Name | Default Value | | Notation | Parameter Name | Default Value |
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
| PRIO | Weight of priority of the flow | 1.0 | PRIO | Weight of priority of the flow | 1.0
| RMIN | Minimum rate of application | 150 Kbps | | RMIN | Minimum rate of application | 150Kbps |
| | supported by media encoder | | | | supported by media encoder | |
| RMAX | Maximum rate of application | 1.5 Mbps | | RMAX | Maximum rate of application | 1.5Mbps |
| | supported by media encoder | | | | supported by media encoder | |
| XREF | Reference congestion level | 10ms | | XREF | Reference congestion level | 10ms |
| KAPPA | Scaling parameter for gradual | 0.5 | | KAPPA | Scaling parameter for gradual | 0.5 |
| | rate update calculation | | | | rate update calculation | |
| ETA | Scaling parameter for gradual | 2.0 | | ETA | Scaling parameter for gradual | 2.0 |
| | rate update calculation | | | | rate update calculation | |
| TAU | Upper bound of RTT in gradual | 500ms | | TAU | Upper bound of RTT in gradual | 500ms |
| | rate update calculation | | | | rate update calculation | |
| DELTA | Target feedback interval | 100ms | | DELTA | Target feedback interval | 100ms |
+..............+..................................+................+ +..............+..................................+................+
skipping to change at page 7, line 19 skipping to change at page 7, line 19
| | calculating packet summary | | | | calculating packet summary | |
| | statistics at receiver | | | | statistics at receiver | |
| QEPS | Threshold for determining queuing| 10ms | | QEPS | Threshold for determining queuing| 10ms |
| | delay build up at receiver | | | | delay build up at receiver | |
| DFILT | Bound on filtering delay | 120ms | | DFILT | Bound on filtering delay | 120ms |
| GAMMA_MAX | Upper bound on rate increase | 0.5 | | GAMMA_MAX | Upper bound on rate increase | 0.5 |
| | ratio for accelerated ramp-up | | | | ratio for accelerated ramp-up | |
| QBOUND | Upper bound on self-inflicted | 50ms | | QBOUND | Upper bound on self-inflicted | 50ms |
| | queuing delay during ramp up | | | | 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 | | | | expiration threshold of the last | |
| | observed loss (loss_exp) based on| | | | observed loss (loss_exp) based on| |
| | measured average loss interval | | | | measured average loss interval | |
| | (loss_int) | | | | (loss_int) | |
| QTH | Delay threshold for invoking | 50ms | | QTH | Delay threshold for invoking | 50ms |
| | non-linear warping | | | | non-linear warping | |
| LAMBDA | Scaling parameter in the | 0.5 | | LAMBDA | Scaling parameter in the | 0.5 |
| | exponent of non-linear warping | | | | exponent of non-linear warping | |
+..............+..................................+................+ +..............+..................................+................+
| PLRREF | Reference packet loss ratio | 0.01 | | PLRREF | Reference packet loss ratio | 0.01 |
skipping to change at page 8, line 37 skipping to change at page 8, line 37
calculate non-linear warping of delay d_tilde if packet loss exists calculate non-linear warping of delay d_tilde if packet loss exists
calculate current aggregate congestion signal x_curr calculate current aggregate congestion signal x_curr
determine mode of rate adaptation for sender: rmode determine mode of rate adaptation for sender: rmode
send feedback containing values of: rmode, x_curr, and r_recv send feedback containing values of: rmode, x_curr, and r_recv
update t_last = t_curr update t_last = t_curr
In order for a delay-based flow to hold its ground when competing 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 against loss-based flows (e.g., loss-based TCP), it is important to
distinguish between different levels of observed queuing delay. For distinguish between different levels of observed queuing delay. For
instance, over wired connections, a moderate queuing delay value on 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 by other delay-based flows, whereas a high queuing delay value of
several hundreds of milliseconds may indicate the presence of a loss- several hundreds of milliseconds may indicate the presence of a loss-
based flow that does not refrain from increased delay. based flow that does not refrain from increased delay.
If the last observed packet loss is within the expiration window of If the last observed packet loss is within the expiration window of
loss_exp (measured in terms of packet counts), the estimated queuing loss_exp (measured in terms of packet counts), the estimated queuing
delay follows a non-linear warping: delay follows a non-linear warping:
/ d_queue, if d_queue<QTH; / d_queue, if d_queue<QTH;
| |
skipping to change at page 12, line 26 skipping to change at page 12, line 26
The rate changes in proportion to the previous rate decision. It is The rate changes in proportion to the previous rate decision. It is
affected by two terms: offset of the aggregate congestion signal from affected by two terms: offset of the aggregate congestion signal from
its value at equilibrium (x_offset) and its change (x_diff). its value at equilibrium (x_offset) and its change (x_diff).
Calculation of x_offset depends on maximum rate of the flow (RMAX), Calculation of x_offset depends on maximum rate of the flow (RMAX),
its weight of priority (PRIO), as well as a reference congestion its weight of priority (PRIO), as well as a reference congestion
signal (XREF). The value of XREF is chosen so that the maximum rate 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 of RMAX can be achieved when the observed congestion signal level is
below PRIO*XREF. 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 = 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 the same bottleneck and observe a common value of x_curr, their rates
at equilibrium will be proportional to their respective priority at equilibrium will be proportional to their respective priority
levels (PRIO) and the range between minimum and maximum rate. Values levels (PRIO) and the range between minimum and maximum rate. Values
of the minimum rate (RMIN) and maximum rate (RMAX) will be provided of the minimum rate (RMIN) and maximum rate (RMAX) will be provided
by the media codec, for instance, as outlined by 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, information, NADA sender will choose a default value of 0 for RMIN,
and 3Mbps for RMAX. and 3Mbps for RMAX.
As mentioned in the sender-side algorithm, the final rate is always As mentioned in the sender-side algorithm, the final rate is always
clipped within the dynamic range specified by the application: clipped within the dynamic range specified by the application:
r_ref = min(r_ref, RMAX) (8) r_ref = min(r_ref, RMAX) (8)
r_ref = max(r_ref, RMIN) (9) r_ref = max(r_ref, RMIN) (9)
The above operations ignore many practical issues such as clock The above operations ignore many practical issues such as clock
skipping to change at page 13, line 20 skipping to change at page 13, line 20
in terms of delay, loss, and/or ECN marking ratios. It then in terms of delay, loss, and/or ECN marking ratios. It then
aggregates all forms of congestion indicators into the form of an aggregates all forms of congestion indicators into the form of an
equivalent delay and periodically reports this back to the sender. equivalent delay and periodically reports this back to the sender.
In addition, the receiver tracks the receiving rate of the flow and In addition, the receiver tracks the receiving rate of the flow and
includes that in the feedback message. includes that in the feedback message.
5.1.1. Estimation of one-way delay and queuing delay 5.1.1. Estimation of one-way delay and queuing delay
The delay estimation process in NADA follows a similar approach as in The delay estimation process in NADA follows a similar approach as in
earlier delay-based congestion control schemes, such as LEDBAT earlier delay-based congestion control schemes, such as LEDBAT
[RFC6817]. Instead of relying on RTP timestamps, the NADA sender [RFC6817]. For experimental implementations, instead of relying on
generates its own timestamp based on local system clock and embeds RTP timestamps and the transmission time offset RTP header extension
that information in the transport packet header. The NADA receiver [RFC5450], the NADA sender can generate its own timestamp based on
estimates the forward delay as having a constant base delay component local system clock and embed that information in the transport packet
plus a time varying queuing delay component. The base delay is header. The NADA receiver estimates the forward delay as having a
estimated as the minimum value of one-way delay observed over a constant base delay component plus a time varying queuing delay
relatively long period (e.g., tens of minutes), whereas the component. The base delay is estimated as the minimum value of one-
individual queuing delay value is taken to be the difference between way delay observed over a relatively long period (e.g., tens of
one-way delay and base delay. By re-estimating the base delay minutes), whereas the individual queuing delay value is taken to be
periodically, one can avoid the potential issue of base delay the difference between one-way delay and base delay. By re-
expiration, whereby an earlier measured base delay value is no longer estimating the base delay periodically, one can avoid the potential
valid due to underlying route changes. All delay estimations are issue of base delay expiration, whereby an earlier measured base
based on sender timestamps with a recommended granularity of 100 delay value is no longer valid due to underlying route changes or
microseconds or higher. 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 The individual sample values of queuing delay should be further
filtered against various non-congestion-induced noise, such as spikes filtered against various non-congestion-induced noise, such as spikes
due to processing "hiccup" at the network nodes. Therefore, in due to processing "hiccup" at the network nodes. Therefore, in
addition to calculating the value of queuing delay using d_queue = addition to calculating the value of queuing delay using d_queue =
d_fwd - d_base, as expressed in Section 5.1, current implementation d_fwd - d_base, as expressed in Section 5.1, current implementation
further employs a minimum filter with a window size of 15 samples further employs a minimum filter with a window size of 15 samples
over per-packet queuing delay values. over per-packet queuing delay values.
5.1.2. Estimation of packet loss/marking ratio 5.1.2. Estimation of packet loss/marking ratio
skipping to change at page 14, line 19 skipping to change at page 14, line 21
The filtered result is reported back to the sender as the observed The filtered result is reported back to the sender as the observed
packet loss ratio p_loss. packet loss ratio p_loss.
Estimation of packet marking ratio p_mark follows the same procedure Estimation of packet marking ratio p_mark follows the same procedure
as above. It is assumed that ECN marking information at the IP as above. It is assumed that ECN marking information at the IP
header can be passed to the receiving endpoint, e.g., by following header can be passed to the receiving endpoint, e.g., by following
the mechanism described in [RFC6679]. the mechanism described in [RFC6679].
5.1.3. Estimation of receiving rate 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, NADA maintains a recent observation window with time span of LOGWIN,
and simply divides the total size of packets arriving during that and simply divides the total size of packets arriving during that
window over the time span. The receiving rate (r_recv) can be window over the time span. The receiving rate (r_recv) can be
calculated at either the sender side based on the per-packet feedback calculated at either the sender side based on the per-packet feedback
from the receiver, or included as part of the feedback report. from the receiver, or included as part of the feedback report.
5.2. Sender-Side Operation 5.2. Sender-Side Operation
Figure 4 provides a detailed view of the NADA sender. Upon receipt Figure 4 provides a detailed view of the NADA sender. Upon receipt
of an RTCP feedback report from the receiver, the NADA sender of an RTCP feedback report from the receiver, the NADA sender
skipping to change at page 16, line 43 skipping to change at page 16, line 43
frame is given by 8*buffer_len*FPS, where FPS stands for the frame is given by 8*buffer_len*FPS, where FPS stands for the
reference frame rate of the video. The scaling parameters BETA_V and reference frame rate of the video. The scaling parameters BETA_V and
BETA_S can be tuned to balance between the competing goals of BETA_S can be tuned to balance between the competing goals of
maintaining a small rate shaping buffer and deviating from the maintaining a small rate shaping buffer and deviating from the
reference rate point. Empirical observations show that the rate reference rate point. Empirical observations show that the rate
shaping buffer for a responsive live video encoder typically stays shaping buffer for a responsive live video encoder typically stays
empty and only occasionally holds a large frame (e.g., when an intra- empty and only occasionally holds a large frame (e.g., when an intra-
frame is produced) in transit. Therefore, the rate adjustment frame is produced) in transit. Therefore, the rate adjustment
introduced by this mechanism is expected to be minor. For instance, introduced by this mechanism is expected to be minor. For instance,
a rate shaping buffer of 2000 Bytes will lead to a rate adjustment of a rate shaping buffer of 2000 Bytes will lead to a rate adjustment of
48 Kbps given the recommended scaling parameters of BETA_V = 0.1 and 48Kbps given the recommended scaling parameters of BETA_V = 0.1 and
BETA_S = 0.1 and reference frame rate of FPS = 30. BETA_S = 0.1 and reference frame rate of FPS = 30.
5.3. Feedback Message Requirements 5.3. Feedback Message Requirements
The following list of information is required for NADA congestion The following list of information is required for NADA congestion
control to function properly: control to function properly:
o Recommended rate adaptation mode (rmode): a 1-bit flag indicating o Recommended rate adaptation mode (rmode): a 1-bit flag indicating
whether the sender should operate in accelerated ramp-up mode whether the sender should operate in accelerated ramp-up mode
(rmode=0) or gradual update mode (rmode=1). (rmode=0) or gradual update mode (rmode=1).
o Aggregated congestion signal (x_curr): the most recently updated o Aggregated congestion signal (x_curr): the most recently updated
value, calculated by the receiver according to Section 4.2. This 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 1/10 of a millisecond) in 15 bits. This allows a maximum value of
x_curr at approximately 3.27 second. x_curr at approximately 3.27 second.
o Receiving rate (r_recv): the most recently measured receiving rate o Receiving rate (r_recv): the most recently measured receiving rate
according to Section 5.1.3. This information is expressed with a according to Section 5.1.3. This information is expressed with a
unit of bits per second (bps) in 32 bits (unsigned int). This unit of bits per second (bps) in 32 bits (unsigned int). This
allows a maximum rate of approximately 4.3Gbps, approximately 1000 allows a maximum rate of approximately 4.3Gbps, approximately 1000
times of the streaming rate of a typical high-definition (HD) times of the streaming rate of a typical high-definition (HD)
video conferencing session today. This field can be expanded video conferencing session today. This field can be expanded
further by a few more bytes, in case an even higher rate need to further by a few more bytes, in case an even higher rate need to
skipping to change at page 18, line 6 skipping to change at page 18, line 6
obtained by maintaining the minimum value of observed OWD over a obtained by maintaining the minimum value of observed OWD over a
relatively long time horizon and subtract that out from the observed relatively long time horizon and subtract that out from the observed
absolute OWD value. Such an approach cancels out the fixed absolute OWD value. Such an approach cancels out the fixed
difference between the sender and receiver clocks. It has been difference between the sender and receiver clocks. It has been
widely adopted by other delay-based congestion control approaches widely adopted by other delay-based congestion control approaches
such as [RFC6817]. As discussed in [RFC6817], the time horizon for such as [RFC6817]. As discussed in [RFC6817], the time horizon for
tracking the minimum OWD needs to be chosen with care: it must be 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 long enough for an opportunity to observe the minimum OWD with zero
standing queue along the path, and sufficiently short so as to timely standing queue along the path, and sufficiently short so as to timely
reflect "true" changes in minimum OWD introduced by route changes and 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 The potential drawback in relying on relative OWD as the congestion
signal is that when multiple flows share the same bottleneck, the signal is that when multiple flows share the same bottleneck, the
flow arriving late at the network experiencing a non-empty queue may flow arriving late at the network experiencing a non-empty queue may
mistakenly consider the standing queuing delay as part of the fixed mistakenly consider the standing queuing delay as part of the fixed
path propagation delay. This will lead to slightly unfair bandwidth path propagation delay. This will lead to slightly unfair bandwidth
sharing among the flows. sharing among the flows.
Alternatively, one could move the per-packet statistical handling to Alternatively, one could move the per-packet statistical handling to
the sender instead and use relative round-trip-time (RTT) in lieu of the sender instead and use relative round-trip-time (RTT) in lieu of
relative OWD, assuming that per-packet acknowledgements are relative OWD, assuming that per-packet acknowledgments are available.
available. The main drawback of RTT-based approach is the noise in The main drawback of RTT-based approach is the noise in the measured
the measured delay in the reverse direction. delay in the reverse direction.
Note that the choice of either delay metric (relative OWD vs. RTT) Note that the choice of either delay metric (relative OWD vs. RTT)
involves no change in the proposed rate adaptation algorithm. involves no change in the proposed rate adaptation algorithm.
Therefore, comparing the pros and cons regarding which delay metric Therefore, comparing the pros and cons regarding which delay metric
to adopt can be kept as an orthogonal direction of investigation. to adopt can be kept as an orthogonal direction of investigation.
6.2. Method for delay, loss, and marking ratio estimation 6.2. Method for delay, loss, and marking ratio estimation
Like other delay-based congestion control schemes, performance of Like other delay-based congestion control schemes, performance of
NADA depends on the accuracy of its delay measurement and estimation NADA depends on the accuracy of its delay measurement and estimation
skipping to change at page 19, line 19 skipping to change at page 19, line 20
adaptation is mostly driven by the change in the congestion signal adaptation is mostly driven by the change in the congestion signal
with a long-term shift towards its equilibrium value driven by the with a long-term shift towards its equilibrium value driven by the
offset term. Finally, the scaling parameter KAPPA determines the offset term. Finally, the scaling parameter KAPPA determines the
overall speed of the adaptation and needs to strike a balance between overall speed of the adaptation and needs to strike a balance between
responsiveness and stability. responsiveness and stability.
The choice of the target feedback interval DELTA needs to strike the The choice of the target feedback interval DELTA needs to strike the
right balance between timely feedback and low RTCP feedback message right balance between timely feedback and low RTCP feedback message
counts. A target feedback interval of DELTA=100ms is recommended, counts. A target feedback interval of DELTA=100ms is recommended,
corresponding to a feedback bandwidth of 16Kbps with 200 bytes per corresponding to a feedback bandwidth of 16Kbps with 200 bytes per
feedback message --- approximately 1.6% overhead for a 1 Mbps flow. feedback message --- approximately 1.6% overhead for a 1Mbps flow.
Furthermore, both simulation studies and frequency-domain analysis in Furthermore, both simulation studies and frequency-domain analysis in
[IETF-95] have established that a feedback interval below 250ms [IETF-95] have established that a feedback interval below 250ms
(i.e., more frequently than 4 feedback messages per second) will not (i.e., more frequently than 4 feedback messages per second) will not
break up the feedback control loop of NADA congestion control. break up the feedback control loop of NADA congestion control.
In calculating the non-linear warping of delay in (1), the current In calculating the non-linear warping of delay in (1), the current
design uses fixed values of QTH for determining whether to perform design uses fixed values of QTH for determining whether to perform
the non-linear warping). Its value should be carefully tuned for 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 connections), so as to avoid the potential risk of prematurely
discounting the congestion signal level. It is possible to adapt its discounting the congestion signal level. It is possible to adapt its
value based on past observed patterns of queuing delay in the value based on past observed patterns of queuing delay in the
presence of packet losses. It needs to be noted that the non-linear presence of packet losses. It needs to be noted that the non-linear
warping mechanism may lead to multiple NADA streams stuck in loss- warping mechanism may lead to multiple NADA streams stuck in loss-
based mode when competing against each other. based mode when competing against each other.
In calculating the aggregate congestion signal x_curr, the choice of In calculating the aggregate congestion signal x_curr, the choice of
DMARK and DLOSS influence the steady-state packet loss/marking ratio DMARK and DLOSS influence the steady-state packet loss/marking ratio
experienced by the flow at a given available bandwidth. Higher experienced by the flow at a given available bandwidth. Higher
values of DMARK and DLOSS result in lower steady-state loss/marking values of DMARK and DLOSS result in lower steady-state loss/marking
ratios, but are more susceptible to the impact of individual packet ratios, but are more susceptible to the impact of individual packet
loss/marking events. While the value of DMARK and DLOSS are fixed loss/marking events. While the value of DMARK and DLOSS are fixed
and predetermined in the current design, this document also 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 these values based on desired bandwidth sharing behavior in the
presence of other competing loss-based flows (e.g., loss-based TCP). presence of other competing loss-based flows (e.g., loss-based TCP).
6.4. Sender-based vs. receiver-based calculation 6.4. Sender-based vs. receiver-based calculation
In the current design, the aggregated congestion signal x_curr is In the current design, the aggregated congestion signal x_curr is
calculated at the receiver, keeping the sender operation completely calculated at the receiver, keeping the sender operation completely
independent of the form of actual network congestion indications independent of the form of actual network congestion indications
(delay, loss, or marking) in use. (delay, loss, or marking) in use.
skipping to change at page 20, line 42 skipping to change at page 20, line 47
Ultimately, networks equipped with proactive marking based on token Ultimately, networks equipped with proactive marking based on token
bucket level metering can reap the additional benefits of zero bucket level metering can reap the additional benefits of zero
standing queues and lower end-to-end delay and work seamlessly with standing queues and lower end-to-end delay and work seamlessly with
existing senders and receivers. existing senders and receivers.
7. Reference Implementations 7. Reference Implementations
The NADA scheme has been implemented in both [ns-2] and [ns-3] The NADA scheme has been implemented in both [ns-2] and [ns-3]
simulation platforms. The implementation in ns-2 hosts the 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 whereas the implementation in ns-3 hosts these receiver-side
calculations at the sender for the sake of interoperability. calculations at the sender for the sake of interoperability.
Extensive ns-2 simulation evaluations of an earlier version of the Extensive ns-2 simulation evaluations of an earlier version of the
draft are documented in [Zhu-PV13]. An open source implementation of draft are documented in [Zhu-PV13]. An open source implementation of
NADA as part of a ns-3 module is available at [ns3-rmcat]. 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 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 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- [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 based test cases as defined in [I-D.ietf-rmcat-wireless-tests] are
presented in [IETF-93]. These simulation-based evaluations have presented in [IETF-93]. These simulation-based evaluations have
shown that NADA flows can obtain their fair share of bandwidth when shown that NADA flows can obtain their fair share of bandwidth when
competing against each other. They typically adapt fast in reaction competing against each other. They typically adapt fast in reaction
to the arrival and departure of other flows, and can sustain a to the arrival and departure of other flows, and can sustain a
reasonable throughput when competing against loss-based TCP flows. reasonable throughput when competing against loss-based TCP flows.
skipping to change at page 21, line 10 skipping to change at page 21, line 15
Evaluation results of the current draft based on ns-3 are presented 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 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- [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 based test cases as defined in [I-D.ietf-rmcat-wireless-tests] are
presented in [IETF-93]. These simulation-based evaluations have presented in [IETF-93]. These simulation-based evaluations have
shown that NADA flows can obtain their fair share of bandwidth when shown that NADA flows can obtain their fair share of bandwidth when
competing against each other. They typically adapt fast in reaction competing against each other. They typically adapt fast in reaction
to the arrival and departure of other flows, and can sustain a to the arrival and departure of other flows, and can sustain a
reasonable throughput when competing against loss-based TCP flows. reasonable throughput when competing against loss-based TCP flows.
[IETF-90] describes the implemention and evaluation of NADA in a lab [IETF-90] describes the implementation and evaluation of NADA in a
setting. Preliminary evaluation results of NADA in single-flow and lab setting. Preliminary evaluation results of NADA in single-flow
multi-flow test scenarios have been presented in [IETF-91]. and multi-flow test scenarios have been presented in [IETF-91].
A reference implementation of NADA has been carried out by modifying A reference implementation of NADA has been carried out by modifying
the WebRTC module embedded in the Mozilla open source browser. the WebRTC module embedded in the Mozilla open source browser.
Presentations from [IETF-103] and [IETF-105] document real-world Presentations from [IETF-103] and [IETF-105] document real-world
evaluations of the modified browser driven by NADA. The experimental evaluations of the modified browser driven by NADA. The experimental
setting involve remote connections with endpoints over either home or setting involve remote connections with endpoints over either home or
enterprise wireless networks. These evaluations validate the enterprise wireless networks. These evaluations validate the
effectiveness of NADA flows in recovering quickly from throughput 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. connections.
8. Suggested Experiments 8. Suggested Experiments
NADA has been extensively evaluated under various test scenarios, NADA has been extensively evaluated under various test scenarios,
including the collection of test cases specified by 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-eval-test] and the subset of WiFi-based test cases in
[I-D.ietf-rmcat-wireless-tests]. Additional evaluations have been [I-D.ietf-rmcat-wireless-tests]. Additional evaluations have been
carried out to characterize how NADA interacts with various active carried out to characterize how NADA interacts with various active
queue management (AQM) schemes such as RED, CoDel, and PIE. Most of queue management (AQM) schemes such as RED, CoDel, and PIE. Most of
these evaluations have been carried out in simulators. A few key these evaluations have been carried out in simulators. A few key
test cases have been evaluated in lab environments with test cases have been evaluated in lab environments with
implementations embedded in video conferencing clients. It is implementations embedded in video conferencing clients. It is
strongly recommended to carry out implementation and experimentation strongly recommended to carry out implementation and experimentation
of NADA in real-world settings. Such exercise will provide insights 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 algorithm parameters (see list in Figure 3) as discussed in
Section 6. Section 6.
Additional experiments are suggested for the following scenarios and 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 reflecting the setup of a typical WAN connection.
o Experiments with ECN marking capability turned on at the network o Experiments with ECN marking capability turned on at the network
for existing test cases. for existing test cases.
o Experiments with multiple NADA streams bearing different user- o Experiments with multiple NADA streams bearing different user-
specified priorities. specified priorities.
o Experiments with additional access technologies, especially over o Experiments with additional access technologies, especially over
cellular networks such as 3G/LTE. cellular networks such as 3G/LTE.
skipping to change at page 24, line 45 skipping to change at page 24, line 45
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[I-D.ietf-rmcat-eval-test] [I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-10 (work in progress), May 2019. 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] [I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real- M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat- Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-08 (work in progress), July 2019. wireless-tests-08 (work in progress), July 2019.
[IETF-103] [IETF-103]
Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu,
J., and S. D'Aronco, "NADA Implementation in Mozilla J., and S. D'Aronco, "NADA Implementation in Mozilla
Browser", November 2018, Browser", November 2018,
skipping to change at page 26, line 10 skipping to change at page 26, line 5
[ns-2] "The Network Simulator - ns-2", [ns-2] "The Network Simulator - ns-2",
<http://www.isi.edu/nsnam/ns/>. <http://www.isi.edu/nsnam/ns/>.
[ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>. [ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>.
[ns3-rmcat] [ns3-rmcat]
Fu, J., Mena, S., and X. Zhu, "NS3 open source module of Fu, J., Mena, S., and X. Zhu, "NS3 open source module of
IETF RMCAT congestion control protocols", November 2017, IETF RMCAT congestion control protocols", November 2017,
<https://github.com/cisco/ns3-rmcat>. <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 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660, Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012, DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>. <https://www.rfc-editor.org/info/rfc6660>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
 End of changes. 39 change blocks. 
70 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/