draft-ietf-rmcat-nada-08.txt   draft-ietf-rmcat-nada-09.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 3, 2019 S. Mena Expires: February 4, 2019 S. Mena
P. Jones P. Jones
J. Fu J. Fu
Cisco Systems Cisco Systems
S. D'Aronco S. D'Aronco
EPFL EPFL
July 2, 2018 August 3, 2018
NADA: A Unified Congestion Control Scheme for Real-Time Media NADA: A Unified Congestion Control Scheme for Real-Time Media
draft-ietf-rmcat-nada-08 draft-ietf-rmcat-nada-09
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 January 3, 2019. This Internet-Draft will expire on February 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3
4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5 4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5
4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5
4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8
4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10
5. Practical Implementation of NADA . . . . . . . . . . . . . . 12 5. Practical Implementation of NADA . . . . . . . . . . . . . . 13
5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 13
5.1.1. Estimation of one-way delay and queuing delay . . . . 12 5.1.1. Estimation of one-way delay and queuing delay . . . . 13
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 . . . . . . . . . . . . 13 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 14
5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 14
5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 15
5.2.2. Adjusting video target rate and sending rate . . . . 15 5.2.2. Adjusting video target rate and sending rate . . . . 16
5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 16
6. Discussions and Further Investigations . . . . . . . . . . . 16 6. Discussions and Further Investigations . . . . . . . . . . . 17
6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 17
6.2. Method for delay, loss, and marking ratio estimation . . 16 6.2. Method for delay, loss, and marking ratio estimation . . 18
6.3. Impact of parameter values . . . . . . . . . . . . . . . 17 6.3. Impact of parameter values . . . . . . . . . . . . . . . 18
6.4. Sender-based vs. receiver-based calculation . . . . . . . 18 6.4. Sender-based vs. receiver-based calculation . . . . . . . 19
6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 19
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Network Node Operations . . . . . . . . . . . . . . 23 Appendix A. Network Node Operations . . . . . . . . . . . . . . 24
A.1. Default behavior of drop tail queues . . . . . . . . . . 23 A.1. Default behavior of drop tail queues . . . . . . . . . . 24
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 24
A.3. Random Early Marking with Virtual Queues . . . . . . . . 24 A.3. Random Early Marking with Virtual Queues . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 3, line 34 skipping to change at page 3, line 34
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 with non-standard timestamp [RFC3550] and RTCP feedback reports. The definition of
messages. standardized RTCP feedback message requires future work so as to
support the 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 5, line 32 skipping to change at page 5, line 32
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. the NADA algorithm. Figure 3 also includes the default values for
choosing the algorithm parameters either to represent a typical
setting in practical applications or based on theoretical and
simulation studies. See Section 6.3 for some of the discussions on
the impact of parameter values. In the experimental phase of this
draft, additional studies in real-world settings will gather further
learnings on how to choose and adapt these parameter values in
practical deployment.
+--------------+-------------------------------------------------+ +--------------+-------------------------------------------------+
| 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 |
skipping to change at page 7, line 49 skipping to change at page 7, line 49
| FPS | Frame rate of incoming video | 30 | | FPS | Frame rate of incoming video | 30 |
| BETA_S | Scaling parameter for modulating | 0.1 | | BETA_S | Scaling parameter for modulating | 0.1 |
| | outgoing sending rate | | | | outgoing sending rate | |
| BETA_V | Scaling parameter for modulating | 0.1 | | BETA_V | Scaling parameter for modulating | 0.1 |
| | video encoder target rate | | | | video encoder target rate | |
| ALPHA | Smoothing factor in exponential | 0.1 | | ALPHA | Smoothing factor in exponential | 0.1 |
| | smoothing of packet loss and | | | | smoothing of packet loss and | |
| | marking ratios | | | marking ratios |
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
Figure 3: List of algorithm parameters. Figure 3: List of algorithm parameters and their default values.
4.2. Receiver-Side Algorithm 4.2. Receiver-Side Algorithm
The receiver-side algorithm can be outlined as below: The receiver-side algorithm can be outlined as below:
On initialization: On initialization:
set d_base = +INFINITY set d_base = +INFINITY
set p_loss = 0 set p_loss = 0
set p_mark = 0 set p_mark = 0
set r_recv = 0 set r_recv = 0
set both t_last and t_curr as current time set both t_last and t_curr as current time in milliseconds
On receiving a media packet: On receiving a media packet:
obtain current timestamp t_curr from system clock obtain current timestamp t_curr from system clock
obtain from packet header sending time stamp t_sent obtain from packet header sending time stamp t_sent
obtain one-way delay measurement: d_fwd = t_curr - t_sent obtain one-way delay measurement: d_fwd = t_curr - t_sent
update baseline delay: d_base = min(d_base, d_fwd) update baseline delay: d_base = min(d_base, d_fwd)
update queuing delay: d_queue = d_fwd - d_base update queuing delay: d_queue = d_fwd - d_base
update packet loss ratio estimate p_loss update packet loss ratio estimate p_loss
update packet marking ratio estimate p_mark update packet marking ratio estimate p_mark
update measurement of receiving rate r_recv update measurement of receiving rate r_recv
skipping to change at page 8, line 36 skipping to change at page 8, line 36
On time to send a new feedback report (t_curr - t_last > DELTA): On time to send a new feedback report (t_curr - t_last > DELTA):
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 instance, over wired connections, a moderate queuing delay value on
below 100ms is likely self-inflicted or induced by other delay-based the order of tens of milliseonds is likely self-inflicted or induced
flows, whereas a high queuing delay value of several hundreds of by other delay-based flows, whereas a high queuing delay value of
milliseconds may indicate the presence of a loss-based flow that does several hundreds of milliseconds may indicate the presence of a loss-
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;
| |
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 windown 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 may need
to tuned for different operational enviornments. to tuned for different operational environments. Typically, a higher
value of QTH is required in a noisier environment (e.g., over
wireless connections, or where the video stream encounters many time-
varying background competing traffic) so as to stay robust against
occasional non-congestion-induced delay spikes. Additional insights
on how this value can be tuned or auto-tuned should be gathered from
carrying out experimental studies in different real-world deployment
scenarios.
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 10, line 5 skipping to change at page 10, line 13
\ PMRREF / \ PLRREF / \ PMRREF / \ PLRREF /
Here, DMARK is prescribed reference delay penalty associated with ECN Here, DMARK is prescribed reference delay penalty associated with ECN
markings at the reference marking ratio of PMRREF; DLOSS is markings at the reference marking ratio of PMRREF; DLOSS is
prescribed reference delay penalty associated with packet losses at prescribed reference delay penalty associated with packet losses at
the reference packet loss ratio of PLRREF. The value of DLOSS and the reference packet loss ratio of PLRREF. The value of DLOSS and
DMARK does not depend on configurations at the network node. Since DMARK does not depend on configurations at the network node. Since
ECN-enabled active queue management schemes typically mark a packet ECN-enabled active queue management schemes typically mark a packet
before dropping it, the value of DLOSS SHOULD be higher than that of before dropping it, the value of DLOSS SHOULD be higher than that of
DMARK. Furthermore, the values of DLOSS and DMARK need to be set DMARK. Furthermore, the values of DLOSS and DMARK need to be set
consistently across all NADA flows for them to compete fairly. consistently across all NADA flows sharing the same bottleneck link,
so that they can compete fairly.
In the absence of packet marking and losses, the value of x_curr In the absence of packet marking and losses, the value of x_curr
reduces to the observed queuing delay d_queue. In that case the NADA reduces to the observed queuing delay d_queue. In that case the NADA
algorithm operates in the regime of delay-based adaptation. algorithm operates in the regime of delay-based adaptation.
Given observed per-packet delay and loss information, the receiver is Given observed per-packet delay and loss information, the receiver is
also in a good position to determine whether the network is also in a good position to determine whether the network is
underutilized and recommend the corresponding rate adaptation mode underutilized and recommend the corresponding rate adaptation mode
for the sender. The criteria for operating in accelerated ramp-up for the sender. The criteria for operating in accelerated ramp-up
mode are: mode are:
skipping to change at page 13, line 16 skipping to change at page 13, line 46
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, instead
of simply calculating the value of base delay using d_base = of simply calculating the value of base delay using d_base =
min(d_base, d_fwd), as expressed in Section 5.1, current min(d_base, d_fwd), as expressed in Section 5.1, current
implementation employs a minimum filter with a window size of 15 implementation employs a minimum filter with a window size of 15
samples over per-packet queuing delay values. samples 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. Packets arriving out-of-order are numbers of received packets. For interactive real-time media
discarded, and count towards losses. The instantaneous packet loss application with stringent latency constraint (e.g., video
ratio p_inst is estimated as the ratio between the number of missing conferencing), the receiver avoids the packet re-ordering delay by
packets over the number of total transmitted packets within the treating out-of-order packets as losses. The instantaneous packet
recent observation window LOGWIN. The packet loss ratio p_loss is loss ratio p_inst is estimated as the ratio between the number of
obtained after exponential smoothing: missing packets over the number of total transmitted packets within
the recent observation window LOGWIN. The packet loss ratio p_loss
is obtained after exponential smoothing:
p_loss = ALPHA*p_inst + (1-ALPHA)*p_loss. (10) p_loss = ALPHA*p_inst + (1-ALPHA)*p_loss. (10)
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].
skipping to change at page 15, line 48 skipping to change at page 16, line 48
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 is 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. allows a maximum rate of approximately 4.3Gbps, approximately 1000
times of the streaming rate of a typical high-definition (HD)
video conferencing session today. This field can be expanded
further by a few more bytes, in case an even higher rate need to
be specified.
The above list of information can be accommodated by 48 bits, or 6 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. Choice of the feedback message interval DELTA is
discussed in Section 6.3 A target feedback interval of DELTA=100ms is discussed in Section 6.3 A target feedback interval of DELTA=100ms is
recommended. recommended.
6. Discussions and Further Investigations 6. Discussions and Further Investigations
This section discussed the various design choices made by NADA,
potential alternative variants of its implementation, and guidelines
on how the key algorithm parameters can be chosen. Section 8
recommends additional experimental setups to further explore these
topics.
6.1. Choice of delay metrics 6.1. Choice of delay metrics
The current design works with relative one-way-delay (OWD) as the The current design works with relative one-way-delay (OWD) as the
main indication of congestion. The value of the relative OWD is main indication of congestion. The value of the relative OWD is
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
skipping to change at page 19, line 31 skipping to change at page 20, line 36
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 also bee evaluated in implementations embedded in test cases have been evaluated in lab environments with
video conferencing clients. implementations embedded in video conferencing clients. It is
strongly recommended to carry out implementation and experimentation
of NADA in real-world settings. Such exercise will provide insights
on how to choose to automatically adapte the values of the key
algorithm parameters (see list in Figure 3) as discussed in
Section 6.
Further experiments are suggested for the following scenarios: Additional experiments are suggested for the following scenarios and
preferrably over real-world networks:
o Experiments reflecting the set up of a typical WAN connection. o Experiments 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 RMCAT streams bearing different user-
specified priorities. specified priorities.
o Experiments with additional access technologies, especially over o Experiments with additional access technologies, especially over
skipping to change at page 21, line 40 skipping to change at page 22, line 50
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-06 (work in progress), June 2018. eval-test-06 (work in progress), June 2018.
[I-D.ietf-rmcat-video-traffic-model] [I-D.ietf-rmcat-video-traffic-model]
Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models
Sources for RMCAT Evaluations", draft-ietf-rmcat-video- for RTP Congestion Control Evaluations", draft-ietf-rmcat-
traffic-model-04 (work in progress), January 2018. video-traffic-model-05 (work in progress), July 2018.
[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-04 (work in progress), May 2017. wireless-tests-05 (work in progress), June 2018.
[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,
 End of changes. 20 change blocks. 
57 lines changed or deleted 92 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/