draft-ietf-rmcat-nada-10.txt   draft-ietf-rmcat-nada-11.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: August 7, 2019 S. Mena Expires: January 26, 2020 S. Mena
P. Jones P. Jones
J. Fu J. Fu
Cisco Systems Cisco Systems
S. D'Aronco S. D'Aronco
EPFL ETH
February 3, 2019 July 25, 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-10 draft-ietf-rmcat-nada-11
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 44 skipping to change at page 1, line 44
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 August 7, 2019. This Internet-Draft will expire on January 26, 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 43 skipping to change at page 2, line 43
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 . . . . . . . 19
6.5. Incremental deployment . . . . . . . . . . . . . . . . . 19 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 20
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 7. Reference Implementation . . . . . . . . . . . . . . . . . . 20
8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 20 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Network Node Operations . . . . . . . . . . . . . . 24 Appendix A. Network Node Operations . . . . . . . . . . . . . . 25
A.1. Default behavior of drop tail queues . . . . . . . . . . 24 A.1. Default behavior of drop tail queues . . . . . . . . . . 25
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 24 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 25
A.3. Random Early Marking with Virtual Queues . . . . . . . . 25 A.3. Random Early Marking with Virtual Queues . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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
skipping to change at page 4, line 47 skipping to change at page 4, line 47
receiving rate (r_recv) of the flow. It calculates the aggregated receiving rate (r_recv) of the flow. It calculates the aggregated
congestion signal (x_curr) that accounts for queuing delay, ECN congestion signal (x_curr) that accounts for queuing delay, ECN
markings, and packet losses. The receiver also determines the markings, and packet losses. The receiver also determines the
mode for sender rate adaptation (rmode) based on whether the flow mode for sender rate adaptation (rmode) based on whether the flow
has encountered any standing non-zero congestion. The receiver has encountered any standing non-zero congestion. The receiver
sends periodic RTCP reports back to the sender, containing values sends periodic RTCP reports back to the sender, containing values
of x_curr, rmode, and r_recv. of x_curr, rmode, and r_recv.
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, FQ-CoDel, also benefit from advanced AQM features such as PIE [RFC8033], FQ-
RED-based ECN marking, and PCN marking using a token bucket CoDel [RFC8290], ECN marking based on RED [RFC7567], and PCN
algorithm. Note that network node operation is out of control for marking using a token bucket algorithm ([RFC6660]). Note that
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 a rate-based congestion control algorithm. In its simplest form, is a rate-based congestion control algorithm. In its simplest form,
the sender reacts to the collection of network congestion indicators the sender reacts to the collection of network congestion indicators
in the form of an aggregated congestion signal, and operates in one in the form of an aggregated congestion signal, and operates in one
of two modes: of two modes:
o Accelerated ramp-up: when the bottleneck is deemed to be o Accelerated ramp-up: when the bottleneck is deemed to be
skipping to change at page 12, line 32 skipping to change at page 12, line 32
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 stablizes 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, as specified in 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 absense 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 2Mbps for RMAX. and 3Mbps for RMAX.
As mentioned in the sender-side algorithm, the final rate is clipped As mentioned in the sender-side algorithm, the final rate is clipped
within the dynamic range specified by the application: 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
synchronization between sender and receiver, filtering of noise in synchronization between sender and receiver, filtering of noise in
skipping to change at page 16, line 7 skipping to change at page 16, line 7
shaping buffer from building up. The mechanisms adopted are: shaping buffer from building up. The mechanisms adopted are:
o To deplete the rate shaping buffer faster by increasing the o To deplete the rate shaping buffer faster by increasing the
sending rate r_send; and sending rate r_send; and
o To limit incoming packets of the rate shaping buffer by reducing o To limit incoming packets of the rate shaping buffer by reducing
the video encoder target rate r_vin. the video encoder target rate r_vin.
5.2.2. Adjusting video target rate and sending rate 5.2.2. Adjusting video target rate and sending rate
The target rate for the live video encoder deviates from the network If the level of occupancy in the rate shaping buffer is accessible at
congestion control rate r_ref based on the level of occupancy in the the sender, such information can be leveraged to further adjust the
rate shaping buffer: target rate of the live video encoder r_vin as well as the actual
sending rate r_send. The purpose of such adjustments is to mitigate
r_vin = r_ref - BETA_V*8*buffer_len*FPS. (11) the additional latencies introduced by the rate shaping buffer. The
amount of rate adjustment can be calculated as follows:
The actual sending rate r_send is regulated in a similar fashion:
r_send = r_ref + BETA_S*8*buffer_len*FPS. (12) r_diff_v = min(0.05*r_ref, BETA_V*8*buffer_len*FPS). (11)
r_diff_s = min(0.05*r_ref, BETA_S*8*buffer_len*FPS). (12)
r_vin = max(RMIN, r_ref - r_diff_v). (13)
r_send = min(RMAX, r_ref + r_diff_s). (14)
In (11) and (12), the first term indicates the rate calculated from In (11) and (12), the amount of adjustment is calculated as
network congestion feedback alone. The second term indicates the proportional to the size of the rate shaping buffer but is bounded by
influence of the rate shaping buffer. A large rate shaping buffer 5% of the reference rate r_ref calculated from network congestion
nudges the encoder target rate slightly below -- and the sending rate feedback alone. This ensures that the adjustment introduced by the
slightly above -- the reference rate r_ref. rate shaping buffer will not counteract with the core congestion
control process. Equations (13) and (14) indicate the influence of
the rate shaping buffer. A large rate shaping buffer nudges the
encoder target rate slightly below -- and the sending rate slightly
above -- the reference rate r_ref. The final video target rate
(r_vin) and sending rate (r_send) are further bounded within the
original range of [RMIN, RMAX].
Intuitively, the amount of extra rate offset needed to completely Intuitively, the amount of extra rate offset needed to completely
drain the rate shaping buffer within the duration of a single video drain the rate shaping buffer within the duration of a single video
frame is given by 8*buffer_len*FPS, where FPS stands for the frame frame is given by 8*buffer_len*FPS, where FPS stands for the
rate of the video. The scaling parameters BETA_V and BETA_S can be reference frame rate of the video. The scaling parameters BETA_V and
tuned to balance between the competing goals of maintaining a small BETA_S can be tuned to balance between the competing goals of
rate shaping buffer and deviating from the reference rate point. maintaining a small rate shaping buffer and deviating from the
reference rate point. Empirical observations show that the rate
shaping buffer for a responsive live video encoder typically stays
empty and only occasionally holds a large frame (e.g., when an intra-
frame is produced) in transit. Therefore, the rate adjustment
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
48 Kbps given the recommended scaling parameters of BETA_V = 0.1 and
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).
skipping to change at page 18, line 21 skipping to change at page 18, line 39
The current recommended practice of applying minimum filter with a The current recommended practice of applying minimum filter with a
window size of 15 samples suffices in guarding against processing window size of 15 samples suffices in guarding against processing
delay outliers observed in wired connections. For wireless delay outliers observed in wired connections. For wireless
connections with a higher packet delay variation (PDV), more connections with a higher packet delay variation (PDV), more
sophisticated techniques on de-noising, outlier rejection, and trend sophisticated techniques on de-noising, outlier rejection, and trend
analysis may be needed. analysis may be needed.
More sophisticated methods in packet loss ratio calculation, such as More sophisticated methods in packet loss ratio calculation, such as
that adopted by [Floyd-CCR00], will likely be beneficial. These that adopted by [Floyd-CCR00], will likely be beneficial. These
alternatives are currently under investigation. alternatives are part of the experiments this document proposes.
6.3. Impact of parameter values 6.3. Impact of parameter values
In the gradual rate update mode, the parameter TAU indicates the In the gradual rate update mode, the parameter TAU indicates the
upper bound of round-trip-time (RTT) in feedback control loop. upper bound of round-trip-time (RTT) in feedback control loop.
Typically, the observed feedback interval delta is close to the Typically, the observed feedback interval delta is close to the
target feedback interval DELTA, and the relative ratio of delta/TAU target feedback interval DELTA, and the relative ratio of delta/TAU
versus ETA dictates the relative strength of influence from the versus ETA dictates the relative strength of influence from the
aggregate congestion signal offset term (x_offset) versus its recent aggregate congestion signal offset term (x_offset) versus its recent
change (x_diff), respectively. These two terms are analogous to the change (x_diff), respectively. These two terms are analogous to the
skipping to change at page 18, line 47 skipping to change at page 19, line 16
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 1 Mbps flow.
Furthermore, both simulation studies and frequency-domain analysis Furthermore, both simulation studies and frequency-domain analysis in
have established that a feedback interval below 250ms (i.e., more [IETF-95] have established that a feedback interval below 250ms
frequently than 4 feedback messages per second) will not break up the (i.e., more frequently than 4 feedback messages per second) will not
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 may need to be tuned for the non-linear warping). Its value may need to be tuned for
different operational enviornments (e.g., over wired vs. wireless different operational enviornments (e.g., over wired vs. wireless
connections). It is possible to adapt its value based on past connections). It is possible to adapt its value based on past
observed patterns of queuing delay in the presence of packet losses. observed patterns of queuing delay in the presence of packet losses.
It needs to be noted that the non-linear warping mechanism may lead It needs to be noted that the non-linear warping mechanism may lead
to multiple NADA streams stuck in loss-based mode when competing to multiple NADA streams stuck in loss-based mode when competing
against each other. 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, a scheme for automatically and predetermined in the current design, this document also
tuning these values based on desired bandwidth sharing behavior in encourages futher explorations of a scheme for automatically tuning
the presence of other competing loss-based flows (e.g., loss-based these values based on desired bandwidth sharing behavior in the
TCP) is under investigation. 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). Alternatively, one can move the logics of (delay, loss, or marking). Alternatively, one can move the logics of
(1) and (2) to the sender. Such an approach requires slightly higher (1) and (2) to the sender. Such an approach requires slightly higher
overhead in the feedback messages, which should contain individual overhead in the feedback messages, which should contain individual
fields on queuing delay (d_queue), packet loss ratio (p_loss), packet fields on queuing delay (d_queue), packet loss ratio (p_loss), packet
skipping to change at page 20, line 10 skipping to change at page 20, line 28
When ECN is enabled at the network nodes with RED-based marking, the When ECN is enabled at the network nodes with RED-based marking, the
receiver can fold its observations of ECN markings into the receiver can fold its observations of ECN markings into the
calculation of the equivalent delay. The sender can react to these calculation of the equivalent delay. The sender can react to these
explicit congestion signals without any modification. explicit congestion signals without any modification.
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. Implementation Status 7. Reference Implementation
The NADA scheme has been implemented in [ns-2] and [ns-3] simulation The NADA scheme has been implemented in [ns-2] and [ns-3] simulation
platforms. Extensive ns-2 simulation evaluations of an earlier platforms. Extensive ns-2 simulation evaluations of an earlier
version of the draft are documented in [Zhu-PV13]. Evaluation version of the draft are documented in [Zhu-PV13]. Evaluation
results of the current draft over several test cases in results of the current draft over several test cases in
[I-D.ietf-rmcat-eval-test] have been presented at recent IETF [I-D.ietf-rmcat-eval-test] have been presented at recent IETF
meetings [IETF-90][IETF-91]. Evaluation results of the current draft meetings [IETF-90][IETF-91]. Evaluation results of the current draft
over several test cases in [I-D.ietf-rmcat-wireless-tests] have been over several test cases in [I-D.ietf-rmcat-wireless-tests] have been
presented at [IETF-93]. An open source implementation of NADA as presented at [IETF-93]. An open source implementation of NADA as
part of a ns-3 module is available at [ns3-rmcat] part of a ns-3 module is available at [ns3-rmcat]
skipping to change at page 21, line 21 skipping to change at page 21, line 38
o Experiments with various media source contents, including audio o Experiments with various media source contents, including audio
only, audio and video, and application content sharing (e.g., only, audio and video, and application content sharing (e.g.,
slide shows). slide shows).
9. IANA Considerations 9. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
10. Security Considerations 10. Security Considerations
TBD The rate adaptation mechanism in NADA relies on feedback from the
receiver. As such, it is vulnerable to attacks where feedback
messages are hijacked, replaces, or intentionally injected with
misleading information, similar to those that can affect TCP. It is
therefore RECOMMENDED that the RTCP feedback message is at least
integrity checked. The modification of sending rate based on send-
side rate shaping buffer may lead to temporary excessive congestion
over the network in the presence of a unresponsive video encoder.
However, this effect can be mitigated by limiting the amount of rate
modification introduced by the rate shaping buffer, bounding the size
of the rate shaping buffer at the sender, and maintaining a maximum
allowed sending rate by NADA.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Randell Jesup, Luca De Cicco, Piers The authors would like to thank Randell Jesup, Luca De Cicco, Piers
O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes,
Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede
Nielsen, Julius Flohr, Roland Bless, Andreas Smas, and Martin Nielsen, Julius Flohr, Roland Bless, Andreas Smas, and Martin
Stiemerling for their various valuable review comments and feedback. Stiemerling for their various valuable review comments and feedback.
Thanks to Charles Ganzhorn for contributing to the testbed-based Thanks to Charles Ganzhorn for contributing to the testbed-based
evaluation of NADA during an early stage of its development. evaluation of NADA during an early stage of its development.
skipping to change at page 22, line 47 skipping to change at page 23, line 31
(work in progress), March 2016. (work in progress), March 2016.
[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-08 (work in progress), November 2018. eval-test-10 (work in progress), May 2019.
[I-D.ietf-rmcat-video-traffic-model] [I-D.ietf-rmcat-video-traffic-model]
Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models
for RTP Congestion Control Evaluations", draft-ietf-rmcat- for RTP Congestion Control Evaluations", draft-ietf-rmcat-
video-traffic-model-06 (work in progress), November 2018. 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-06 (work in progress), December 2018. wireless-tests-08 (work in progress), July 2019.
[IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan,
"NADA Update: Algorithm, Implementation, and Test Case "NADA Update: Algorithm, Implementation, and Test Case
Evalua6on Results", July 2014, Evalua6on Results", July 2014,
<https://tools.ietf.org/agenda/90/slides/ <https://tools.ietf.org/agenda/90/slides/
slides-90-rmcat-6.pdf>. slides-90-rmcat-6.pdf>.
[IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
Jones, P., and S. D'Aronco, "NADA Algorithm Update and Jones, P., and S. D'Aronco, "NADA Algorithm Update and
Test Case Evaluations", November 2014, Test Case Evaluations", November 2014,
<http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/ <http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/
slides/slides-interim-2014-rmcat-1-2.pdf>. slides/slides-interim-2014-rmcat-1-2.pdf>.
[IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA", Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA",
July 2015, <https://www.ietf.org/proceedings/93/slides/ July 2015, <https://www.ietf.org/proceedings/93/slides/
slides-93-rmcat-0.pdf>. slides-93-rmcat-0.pdf>.
[IETF-95] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu,
J., D'Aronco, S., and C. Ganzhorn, "Updates on NADA:
Stability Analysis and Impact of Feedback Intervals",
April 2016, <https://www.ietf.org/proceedings/95/slides/
slides-95-rmcat-5.pdf>.
[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>.
skipping to change at page 24, line 5 skipping to change at page 24, line 48
[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>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>.
[Zhu-PV13] [Zhu-PV13]
Zhu, X. and R. Pan, "NADA: A Unified Congestion Control Zhu, X. and R. Pan, "NADA: A Unified Congestion Control
Scheme for Low-Latency Interactive Video", in Proc. IEEE Scheme for Low-Latency Interactive Video", in Proc. IEEE
International Packet Video Workshop (PV'13) San Jose, CA, International Packet Video Workshop (PV'13) San Jose, CA,
USA, December 2013. USA, December 2013.
Appendix A. Network Node Operations Appendix A. Network Node Operations
NADA can work with different network queue management schemes and NADA can work with different network queue management schemes and
does not assume any specific network node operation. As an example, does not assume any specific network node operation. As an example,
skipping to change at page 27, line 4 skipping to change at page 28, line 28
Email: semena@cisco.com Email: semena@cisco.com
Paul E. Jones Paul E. Jones
Cisco Systems Cisco Systems
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: paulej@packetizer.com Email: paulej@packetizer.com
Jiantao Fu Jiantao Fu
Cisco Systems Cisco Systems
707 Tasman Drive 707 Tasman Drive
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
Email: jianfu@cisco.com Email: jianfu@cisco.com
Stefano D'Aronco Stefano D'Aronco
Ecole Polytechnique Federale de Lausanne ETH Zurich
EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11 Stefano-Franscini-Platz 5
Lausanne CH-1015 Zurich 8093
Switzerland Switzerland
Email: stefano.daronco@epfl.ch Email: stefano.daronco@geod.baug.ethz.ch
 End of changes. 27 change blocks. 
55 lines changed or deleted 101 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/