draft-ietf-rmcat-nada-11.txt   draft-ietf-rmcat-nada-12.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: January 26, 2020 S. Mena Expires: February 24, 2020 S. Mena
P. Jones
J. Fu
Cisco Systems Cisco Systems
S. D'Aronco August 23, 2019
ETH
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-11 draft-ietf-rmcat-nada-12
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 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 January 26, 2020. This Internet-Draft will expire on February 24, 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 44 skipping to change at page 2, line 35
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 . . . . . . . . . . . . . . . . . 20 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 20
7. Reference Implementation . . . . . . . . . . . . . . . . . . 20 7. Reference Implementations . . . . . . . . . . . . . . . . . . 20
8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 20 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Network Node Operations . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 24
A.1. Default behavior of drop tail queues . . . . . . . . . . 25 Appendix A. Network Node Operations . . . . . . . . . . . . . . 27
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 25 A.1. Default behavior of drop tail queues . . . . . . . . . . 27
A.3. Random Early Marking with Virtual Queues . . . . . . . . 26 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 A.3. Random Early Marking with Virtual Queues . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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]. [I-D.ietf-rmcat-cc-requirements]. It highlights that the desired
congestion control scheme should avoid flow starvation and attain a
reasonable fair share of bandwidth when competing against other
flows, adapt quickly, and operate in a stable manner.
This document describes an experimental congestion control scheme This document describes an experimental congestion control scheme
called network-assisted dynamic adaptation (NADA). The NADA design called network-assisted dynamic adaptation (NADA). The NADA design
benefits from explicit congestion control signals (e.g., ECN 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 timestamp [RFC3550] and RTCP feedback reports. The definition of the
standardized RTCP feedback message requires future work so as to desired RTCP feedback message is descirbed in detailed in
support the successful operation of several congestion control [I-D.ietf-avtcore-cc-feedback-message] so as to support the
schemes for real-time interactive media. successful operation of several congestion control schemes for real-
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
skipping to change at page 4, line 20 skipping to change at page 4, line 20
+---------+ 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 compressed bitstream which is
later packetized into RTP packets. As discussed in later packetized into RTP packets. As discussed in [RFC8593], the
[I-D.ietf-rmcat-video-traffic-model], the actual output rate from actual output rate from the encoder r_vout may fluctuate around
the encoder r_vout may fluctuate around the target r_vin. the target r_vin. Furthermore, it is possible that the encoder
Furthermore, it is possible that the encoder can only react to bit can only react to bit rate changes at rather coarse time
rate changes at rather coarse time intervals, e.g., once every 0.5 intervals, e.g., once every 0.5 seconds.
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
delay (based on sender timestamp), packet loss (based on RTP delay (based on sender timestamp), packet loss (based on RTP
skipping to change at page 9, line 15 skipping to change at page 9, line 15
/ d_queue, if d_queue<QTH; / d_queue, if d_queue<QTH;
| |
d_tilde = < (1) d_tilde = < (1)
| (d_queue-QTH) | (d_queue-QTH)
\ QTH exp(-LAMBDA ---------------) , otherwise. \ QTH exp(-LAMBDA ---------------) , otherwise.
QTH QTH
In (1), the queuing delay value is unchanged when it is below the In (1), the queuing delay value is unchanged when it is below the
first threshold QTH; otherwise it is scaled down following a non- first threshold QTH; otherwise it is scaled down following a non-
linear curve. This non-linear warping is inspired by the delay- linear curve. This non-linear warping is inspired by the delay-
adaptive congestion windown backoff policy in [Budzisz-TON11], so as adaptive congestion window backoff policy in [Budzisz-TON11], so as
to "gradually nudge" the controller to operate based on loss-induced to "gradually nudge" the controller to operate based on loss-induced
congestion signals when competing against loss-based flows. The congestion signals when competing against loss-based flows. The
exact form of the non-linear function has been simplified with exact form of the non-linear function has been simplified with
respect to [Budzisz-TON11]. The value of the threshold QTH may need respect to [Budzisz-TON11]. The value of the threshold QTH should be
to tuned for different operational environments. Typically, a higher carefully tuned for different operational environments, so as to
value of QTH is required in a noisier environment (e.g., over avoid potential risks of prematurely discounting the congestion
wireless connections, or where the video stream encounters many time- signal level. Typically, a higher value of QTH is required in a
varying background competing traffic) so as to stay robust against noisier environment (e.g., over wireless connections, or where the
occasional non-congestion-induced delay spikes. Additional insights video stream encounters many time-varying background competing
on how this value can be tuned or auto-tuned should be gathered from traffic) so as to stay robust against occasional non-congestion-
carrying out experimental studies in different real-world deployment induced delay spikes. Additional insights on how this value can be
scenarios. tuned or auto-tuned should be gathered from carrying out experimental
studies in different real-world deployment scenarios.
The value of loss_exp is configured to self-scale with the average The value of loss_exp is configured to self-scale with the average
packet loss interval loss_int with a multiplier MULTILOSS: packet loss interval loss_int with a multiplier MULTILOSS:
loss_exp = MULTILOSS * loss_int. loss_exp = MULTILOSS * loss_int.
Estimation of the average loss interval loss_int, in turn, follows Estimation of the average loss interval loss_int, in turn, follows
Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol
[RFC5348]. [RFC5348].
skipping to change at page 11, line 20 skipping to change at page 11, line 20
on receiving feedback report: on receiving feedback report:
obtain current timestamp from system clock: t_curr obtain current timestamp from system clock: t_curr
obtain values of rmode, x_curr, and r_recv from feedback report obtain values of rmode, x_curr, and r_recv from feedback report
update estimation of rtt update estimation of rtt
measure feedback interval: delta = t_curr - t_last measure feedback interval: delta = t_curr - t_last
if rmode == 0: if rmode == 0:
update r_ref following accelerated ramp-up rules update r_ref following accelerated ramp-up rules
else: else:
update r_ref following gradual update rules update r_ref following gradual update rules
clip rate r_ref within the range of minimum rate (RMIN)
and maximum rate (RMAX). clip rate r_ref within the range of minimum rate (RMIN)
and maximum rate (RMAX).
x_prev = x_curr x_prev = x_curr
t_last = t_curr t_last = t_curr
In accelerated ramp-up mode, the rate r_ref is updated as follows: In accelerated ramp-up mode, the rate r_ref is updated as follows:
QBOUND QBOUND
gamma = min(GAMMA_MAX, ------------------) (3) gamma = min(GAMMA_MAX, ------------------) (3)
rtt+DELTA+DFILT rtt+DELTA+DFILT
r_ref = max(r_ref, (1+gamma) r_recv) (4) r_ref = max(r_ref, (1+gamma) r_recv) (4)
skipping to change at page 12, line 37 skipping to change at page 12, line 37
= 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 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 3Mbps 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 always
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 = max(r_ref, RMIN) (9) r_ref = min(r_ref, RMAX) (8)
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
delay measurements, and base delay expiration. These will be delay measurements, and base delay expiration. These will be
addressed in Section 5 addressed in Section 5.
5. Practical Implementation of NADA 5. Practical Implementation of NADA
5.1. Receiver-Side Operation 5.1. Receiver-Side Operation
The receiver continuously monitors end-to-end per-packet statistics The receiver continuously monitors end-to-end per-packet statistics
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
skipping to change at page 13, line 37 skipping to change at page 13, line 37
individual queuing delay value is taken to be the difference between individual queuing delay value is taken to be the difference between
one-way delay and base delay. By re-estimating the base delay one-way delay and base delay. By re-estimating the base delay
periodically, one can avoid the potential issue of base delay periodically, one can avoid the potential issue of base delay
expiration, whereby an earlier measured base delay value is no longer expiration, whereby an earlier measured base delay value is no longer
valid due to underlying route changes. All delay estimations are valid due to underlying route changes. All delay estimations are
based on sender timestamps with a recommended granularity of 100 based on sender timestamps with a recommended granularity of 100
microseconds or higher. microseconds or higher.
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, instead due to processing "hiccup" at the network nodes. Therefore, in
of simply calculating the value of base delay using d_base = addition to calculating the value of queuing delay using d_queue =
min(d_base, d_fwd), as expressed in Section 5.1, current d_fwd - d_base, as expressed in Section 5.1, current implementation
implementation employs a minimum filter with a window size of 15 further employs a minimum filter with a window size of 15 samples
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
The receiver detects packet losses via gaps in the RTP sequence The receiver detects packet losses via gaps in the RTP sequence
numbers of received packets. For interactive real-time media numbers of received packets. For interactive real-time media
application with stringent latency constraint (e.g., video application with stringent latency constraint (e.g., video
conferencing), the receiver avoids the packet re-ordering delay by conferencing), the receiver avoids the packet re-ordering delay by
treating out-of-order packets as losses. The instantaneous packet treating out-of-order packets as losses. The instantaneous packet
loss ratio p_inst is estimated as the ratio between the number of loss ratio p_inst is estimated as the ratio between the number of
missing packets over the number of total transmitted packets within missing packets over the number of total transmitted packets within
skipping to change at page 14, line 22 skipping to change at page 14, line 22
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 straighforward 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) is included window over the time span. The receiving rate (r_recv) can be
as part of the feedback report. calculated at either the sender side based on the per-packet feedback
from the receiver, or included as part of the feedback report.
5.2. Sender-Side Operation 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
calculates the reference rate r_ref as specified in Section 4.3. It calculates the reference rate r_ref as specified in Section 4.3. It
further adjusts both the target rate for the live video encoder r_vin further adjusts both the target rate for the live video encoder r_vin
and the sending rate r_send over the network based on the updated and the sending rate r_send over the network based on the updated
value of r_ref and rate shaping buffer occupancy buffer_len. value of r_ref and rate shaping buffer occupancy buffer_len.
skipping to change at page 17, line 25 skipping to change at page 17, line 25
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
be specified. be specified.
The above list of information can be accommodated by 48 bits, or 6 The above list of information can be accommodated by 48 bits, or 6
bytes, in total. Choice of the feedback message interval DELTA is bytes, in total. They can be either included in the feedback report
discussed in Section 6.3 A target feedback interval of DELTA=100ms is from the receiver, or, in the case where all receiver-side
recommended. calculations are moved to the sender, derived from per-packet
information from the feedback message as defined in
[I-D.ietf-avtcore-cc-feedback-message]. Choice of the feedback
message interval DELTA is discussed in Section 6.3. A target
feedback interval of DELTA=100ms is recommended.
6. Discussions and Further Investigations 6. Discussions and Further Investigations
This section discussed the various design choices made by NADA, This section discussed the various design choices made by NADA,
potential alternative variants of its implementation, and guidelines potential alternative variants of its implementation, and guidelines
on how the key algorithm parameters can be chosen. Section 8 on how the key algorithm parameters can be chosen. Section 8
recommends additional experimental setups to further explore these recommends additional experimental setups to further explore these
topics. topics.
6.1. Choice of delay metrics 6.1. Choice of delay metrics
skipping to change at page 19, line 23 skipping to change at page 19, line 27
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 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 may need to be tuned for the non-linear warping). Its value should be carefully tuned for
different operational enviornments (e.g., over wired vs. wireless different operational enviornments (e.g., over wired vs. wireless
connections). It is possible to adapt its value based on past connections), so as to avoid the potential risk of prematurely
observed patterns of queuing delay in the presence of packet losses. discounting the congestion signal level. It is possible to adapt its
It needs to be noted that the non-linear warping mechanism may lead value based on past observed patterns of queuing delay in the
to multiple NADA streams stuck in loss-based mode when competing presence of packet losses. It needs to be noted that the non-linear
against each other. warping mechanism may lead to multiple NADA streams stuck in loss-
based mode when competing against each other.
In calculating the aggregate congestion signal x_curr, the choice of 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 futher 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). Alternatively, one can move the logics of (delay, loss, or marking) in use.
(1) and (2) to the sender. Such an approach requires slightly higher
overhead in the feedback messages, which should contain individual Alternatively, one can shift receiver-side calculations to the
fields on queuing delay (d_queue), packet loss ratio (p_loss), packet sender, whereby the receiver simply reports on per-packet information
marking ratio (p_mark), receiving rate (r_recv), and recommended rate via periodic feedback messages as defined in
adaptation mode (rmode). [I-D.ietf-avtcore-cc-feedback-message]. Such an approach enables
interoperability amongst senders operating on different congestion
control schemes, but requires slightly higher overhead in the
feedback messages. See additional discussions in
[I-D.ietf-avtcore-cc-feedback-message] regarding the desired format
of the feedback messages and the recommended feedback intervals.
6.5. Incremental deployment 6.5. Incremental deployment
One nice property of NADA is the consistent video endpoint behavior One nice property of NADA is the consistent video endpoint behavior
irrespective of network node variations. This facilitates gradual, irrespective of network node variations. This facilitates gradual,
incremental adoption of the scheme. incremental adoption of the scheme.
To start off with, the proposed congestion control mechanism can be Initially, the proposed congestion control mechanism can be
implemented without any explicit support from the network, and relies implemented without any explicit support from the network, and relies
solely on observed one-way delay measurements and packet loss ratios solely on observed relative one-way delay measurements and packet
as implicit congestion signals. loss ratios as implicit congestion signals.
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. Reference Implementation 7. Reference Implementations
The NADA scheme has been implemented in [ns-2] and [ns-3] simulation The NADA scheme has been implemented in both [ns-2] and [ns-3]
platforms. Extensive ns-2 simulation evaluations of an earlier simulation platforms. The implementation in ns-2 hosts the
version of the draft are documented in [Zhu-PV13]. Evaluation calculations as descirbed in Section 4.2 at the receiver side,
results of the current draft over several test cases in whereas the implementation in ns-3 hosts these receiver-side
[I-D.ietf-rmcat-eval-test] have been presented at recent IETF calculations at the sender for the sake of interoperability.
meetings [IETF-90][IETF-91]. Evaluation results of the current draft Extensive ns-2 simulation evaluations of an earlier version of the
over several test cases in [I-D.ietf-rmcat-wireless-tests] have been draft are documented in [Zhu-PV13]. An open source implementation of
presented at [IETF-93]. An open source implementation of NADA as NADA as part of a ns-3 module is available at [ns3-rmcat].
part of a ns-3 module is available at [ns3-rmcat] Evaluation results of the current draft based on ns-3 are presented
in [IETF-90] and [IETF-91] for wired test cases as documented in
[I-D.ietf-rmcat-eval-test]. Evaluation results of NADA over WiFi-
based test cases as defined in [I-D.ietf-rmcat-wireless-tests] are
presented in [IETF-93]. These simulation-based evaluations have
shown that NADA flows can obtain their fair share of bandwidth when
competing against each other. They typically adapt fast in reaction
to the arrival and departure of other flows, and can sustain a
reasonable throughput when competing against loss-based TCP flows.
The scheme has also been implemented and evaluated in a lab setting [IETF-90] describes the implemention and evaluation of NADA in a lab
as described in [IETF-90]. Preliminary evaluation results of NADA in setting. Preliminary evaluation results of NADA in single-flow and
single-flow and multi-flow scenarios have been presented in multi-flow test scenarios have been presented in [IETF-91].
[IETF-91].
A reference implementation of NADA has been carried out by modifying
the WebRTC module embedded in the Mozilla open source browser.
Presentations from [IETF-103] and [IETF-105] document real-world
evaluations of the modified browser driven by NADA. The experimental
setting involve remote connections with endpoints over either home or
enterprise wireless networks. These evaluations validate the
effectiveness of NADA flows in recovering quickly from throughput
drops caused by intermittent delay spikes over the last-hop wirelss
connections.
8. Suggested Experiments 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 to automatically adapte the values of the key on how to choose or automatically adapte the values of the key
algorithm parameters (see list in Figure 3) as discussed in 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: preferrably over real-world networks:
o Experiments reflecting the set up of a typical WAN connection. o Experiments reflecting the set up 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 RMCAT 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.
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
The rate adaptation mechanism in NADA relies on feedback from the The rate adaptation mechanism in NADA relies on feedback from the
receiver. As such, it is vulnerable to attacks where feedback receiver. As such, it is vulnerable to attacks where feedback
messages are hijacked, replaces, or intentionally injected with messages are hijacked, replaced, or intentionally injected with
misleading information, similar to those that can affect TCP. It is misleading information resulting in denial of service, similar to
therefore RECOMMENDED that the RTCP feedback message is at least those that can affect TCP. It is therefore RECOMMENDED that the RTCP
integrity checked. The modification of sending rate based on send- feedback message is at least integrity checked. In addition,
side rate shaping buffer may lead to temporary excessive congestion [I-D.ietf-avtcore-cc-feedback-message] discusses the potential risk
over the network in the presence of a unresponsive video encoder. of a receiver providing misleading congestion feedback information
However, this effect can be mitigated by limiting the amount of rate and the mechanisms for mitigating such risks.
modification introduced by the rate shaping buffer, bounding the size
of the rate shaping buffer at the sender, and maintaining a maximum The modification of sending rate based on send-side rate shaping
allowed sending rate by NADA. 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 valuable review comments and helpful input to
Thanks to Charles Ganzhorn for contributing to the testbed-based this specification.
evaluation of NADA during an early stage of its development.
12. References 12. Contributors
12.1. Normative References The following individuals have contributed to the implementation and
evaluation of the proposed scheme, and therefore have helped to
validate and substantially improve this specification.
Paul E. Jones <paulej@packetizer.com> of Cisco Systems
implemented an early version of the NADA congestion control scheme
and helped with its lab-based testbed evaluations.
Jiantao Fu <jianfu@cisco.com> of Cisco Systems helped with the
implementation and extensive evaluation of NADA both in Mozilla
web browsers and in earlier simulation-based evaluation efforts.
Stefano D'Aronco <stefano.daronco@geod.baug.ethz.ch> of ETH Zurich
(previously at Ecole Polytechnique Federale de Lausanne when
contributing to this work) helped with implementation and
evaluation of an early version of NADA in [ns-3].
Charles Ganzhorn <charles.ganzhorn@gmail.com> contributed to the
testbed-based evaluation of NADA during an early stage of its
development.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 22, line 48 skipping to change at page 24, line 9
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <https://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 13.2. Informative References
[Budzisz-TON11] [Budzisz-TON11]
Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and
R. Shorten, "On the Fair Coexistence of Loss- and Delay- R. Shorten, "On the Fair Coexistence of Loss- and Delay-
Based TCP", IEEE/ACM Transactions on Networking vol. 19, Based TCP", IEEE/ACM Transactions on Networking vol. 19,
no. 6, pp. 1811-1824, December 2011. no. 6, pp. 1811-1824, December 2011.
[Floyd-CCR00] [Floyd-CCR00]
Floyd, S., Handley, M., Padhye, J., and J. Widmer, Floyd, S., Handley, M., Padhye, J., and J. Widmer,
"Equation-based Congestion Control for Unicast "Equation-based Congestion Control for Unicast
Applications", ACM SIGCOMM Computer Communications Applications", ACM SIGCOMM Computer Communications
Review vol. 30, no. 4, pp. 43-56, October 2000. Review vol. 30, no. 4, pp. 43-56, October 2000.
[I-D.ietf-avtcore-cc-feedback-message]
Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control",
draft-ietf-avtcore-cc-feedback-message-04 (work in
progress), July 2019.
[I-D.ietf-rmcat-cc-codec-interactions] [I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP "Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-02 Applications", draft-ietf-rmcat-cc-codec-interactions-02
(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.
skipping to change at page 23, line 44 skipping to change at page 25, line 11
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-07 (work in progress), February 2019. 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]
Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu,
J., and S. D'Aronco, "NADA Implementation in Mozilla
Browser", November 2018,
<https://datatracker.ietf.org/meeting/103/materials/
slides-103-rmcat-nada-implementation-in-mozilla-browser-
00>.
[IETF-105]
Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu,
J., and S. D'Aronco, "NADA Implementation in Mozilla
Browser and Draft Update", July 2019,
<https://datatracker.ietf.org/meeting/105/materials/
slides-105-rmcat-nada-update-02.pdf>.
[IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, [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/
skipping to change at page 25, line 11 skipping to change at page 26, line 38
Lightweight Control Scheme to Address the Bufferbloat Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>. <https://www.rfc-editor.org/info/rfc8033>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290, and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018, DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>. <https://www.rfc-editor.org/info/rfc8290>.
[RFC8593] Zhu, X., Mena, S., and Z. Sarker, "Video Traffic Models
for RTP Congestion Control Evaluations", RFC 8593,
DOI 10.17487/RFC8593, May 2019,
<https://www.rfc-editor.org/info/rfc8593>.
[Zhu-PV13] [Zhu-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 28, line 4 skipping to change at page 29, line 19
12515 Research Blvd., Building 4 12515 Research Blvd., Building 4
Austin, TX 78759 Austin, TX 78759
USA USA
Email: xiaoqzhu@cisco.com Email: xiaoqzhu@cisco.com
Rong Pan * Rong Pan *
* Pending affiliation change. * Pending affiliation change.
Email: rong.pan@gmail.com Email: rong.pan@gmail.com
Michael A. Ramalho Michael A. Ramalho
Cisco Systems, Inc. Cisco Systems, Inc.
8000 Hawkins Road 8000 Hawkins Road
Sarasota, FL 34241 Sarasota, FL 34241
USA USA
Phone: +1 919 476 2038 Phone: +1 919 476 2038
Email: mramalho@cisco.com Email: mar42@cornell.edu
Sergio Mena de la Cruz Sergio Mena de la Cruz
Cisco Systems Cisco Systems
EPFL, Quartier de l'Innovation, Batiment E EPFL, Quartier de l'Innovation, Batiment E
Ecublens, Vaud 1015 Ecublens, Vaud 1015
Switzerland Switzerland
Email: semena@cisco.com Email: semena@cisco.com
Paul E. Jones
Cisco Systems
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Email: paulej@packetizer.com
Jiantao Fu
Cisco Systems
707 Tasman Drive
Milpitas, CA 95035
USA
Email: jianfu@cisco.com
Stefano D'Aronco
ETH Zurich
Stefano-Franscini-Platz 5
Zurich 8093
Switzerland
Email: stefano.daronco@geod.baug.ethz.ch
 End of changes. 39 change blocks. 
107 lines changed or deleted 190 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/