draft-ietf-rmcat-nada-05.txt   draft-ietf-rmcat-nada-06.txt 
Network Working Group X. Zhu Network Working Group X. Zhu
Internet-Draft R. Pan Internet-Draft Cisco Systems
Intended status: Experimental M. Ramalho Intended status: Experimental R. Pan
Expires: April 1, 2018 S. Mena Expires: June 6, 2018 Pensando Systems
M. Ramalho
S. Mena
P. Jones P. Jones
J. Fu J. Fu
Cisco Systems Cisco Systems
S. D'Aronco S. D'Aronco
EPFL EPFL
September 28, 2017 December 3, 2017
NADA: A Unified Congestion Control Scheme for Real-Time Media NADA: A Unified Congestion Control Scheme for Real-Time Media
draft-ietf-rmcat-nada-05 draft-ietf-rmcat-nada-06
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 46
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 April 1, 2018. This Internet-Draft will expire on June 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . 12
5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12
5.1.1. Estimation of one-way delay and queuing delay . . . . 12 5.1.1. Estimation of one-way delay and queuing delay . . . . 12
5.1.2. Estimation of packet loss/marking ratio . . . . . . . 12 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 . . . . . . . . . . . . 13
5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13
5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14
5.2.2. Adjusting video target rate and sending rate . . . . 15 5.2.2. Adjusting video target rate and sending rate . . . . 15
5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15
6. Discussions and Further Investigations . . . . . . . . . . . 16 6. Discussions and Further Investigations . . . . . . . . . . . 16
6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16
6.2. Method for delay, loss, and marking ratio estimation . . 16 6.2. Method for delay, loss, and marking ratio estimation . . 16
6.3. Impact of parameter values . . . . . . . . . . . . . . . 17 6.3. Impact of parameter values . . . . . . . . . . . . . . . 17
6.4. Sender-based vs. receiver-based calculation . . . . . . . 18 6.4. Sender-based vs. receiver-based calculation . . . . . . . 18
6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Network Node Operations . . . . . . . . . . . . . . 22 Appendix A. Network Node Operations . . . . . . . . . . . . . . 23
A.1. Default behavior of drop tail queues . . . . . . . . . . 22 A.1. Default behavior of drop tail queues . . . . . . . . . . 23
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 22 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23
A.3. Random Early Marking with Virtual Queues . . . . . . . . 23 A.3. Random Early Marking with Virtual Queues . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 6, line 31 skipping to change at page 6, line 31
| p_mark | Estimated packet ECN marking ratio | | p_mark | Estimated packet ECN marking ratio |
| p_loss | Estimated packet loss ratio | | p_loss | Estimated packet loss ratio |
| x_curr | Aggregate congestion signal | | x_curr | Aggregate congestion signal |
| x_prev | Previous value of aggregate congestion signal | | x_prev | Previous value of aggregate congestion signal |
| x_diff | Change in aggregate congestion signal w.r.t. | | x_diff | Change in aggregate congestion signal w.r.t. |
| | its previous value: x_diff = x_curr - x_prev | | | its previous value: x_diff = x_curr - x_prev |
| rmode | Rate update mode: (0 = accelerated ramp-up; | | rmode | Rate update mode: (0 = accelerated ramp-up; |
| | 1 = gradual update) | | | 1 = gradual update) |
| gamma | Rate increase multiplier in accelerated ramp-up | | gamma | Rate increase multiplier in accelerated ramp-up |
| | mode | | | mode |
| tloss_int | Measured average loss interval | | loss_int | Measured average loss interval in packet count |
| tloss_exp | Time window for recently observed losses | | loss_exp | Threshold value for setting the last observed |
| | packet loss to expiration |
| rtt | Estimated round-trip-time at sender | | rtt | Estimated round-trip-time at sender |
| buffer_len | Rate shaping buffer occupancy measured in bytes | | buffer_len | Rate shaping buffer occupancy measured in bytes |
+--------------+-------------------------------------------------+ +--------------+-------------------------------------------------+
Figure 2: List of variables. Figure 2: List of variables.
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
| Notation | Parameter Name | Default Value | | Notation | Parameter Name | Default Value |
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
| PRIO | Weight of priority of the flow | 1.0 | PRIO | Weight of priority of the flow | 1.0
skipping to change at page 7, line 8 skipping to change at page 7, line 9
| | supported by media encoder | | | | supported by media encoder | |
| XREF | Reference congestion level | 10ms | | XREF | Reference congestion level | 10ms |
| KAPPA | Scaling parameter for gradual | 0.5 | | KAPPA | Scaling parameter for gradual | 0.5 |
| | rate update calculation | | | | rate update calculation | |
| ETA | Scaling parameter for gradual | 2.0 | | ETA | Scaling parameter for gradual | 2.0 |
| | rate update calculation | | | | rate update calculation | |
| TAU | Upper bound of RTT in gradual | 500ms | | TAU | Upper bound of RTT in gradual | 500ms |
| | rate update calculation | | | | rate update calculation | |
| DELTA | Target feedback interval | 100ms | | DELTA | Target feedback interval | 100ms |
+..............+..................................+................+ +..............+..................................+................+
| DFILT | Bound on filtering delay | 120ms |
| LOGWIN | Observation window in time for | 500ms | | LOGWIN | Observation window in time for | 500ms |
| | calculating packet summary | | | | calculating packet summary | |
| | statistics at receiver | | | | statistics at receiver | |
| QEPS | Threshold for determining queuing| 10ms | | QEPS | Threshold for determining queuing| 10ms |
| | delay build up at receiver | | | | delay build up at receiver | |
| GAMMA_MAX | Upper bound on rate increase | 50% | | DFILT | Bound on filtering delay | 120ms |
| GAMMA_MAX | Upper bound on rate increase | 0.5 |
| | ratio for accelerated ramp-up | | | | ratio for accelerated ramp-up | |
| QBOUND | Upper bound on self-inflicted | 50ms | | QBOUND | Upper bound on self-inflicted | 50ms |
| | queuing delay during ramp up | | | | queuing delay during ramp up | |
+..............+..................................+................+ +..............+..................................+................+
| MULTILOSS | Multiplier for self-scaling the | 7. | | MULTILOSS | Multiplier for self-scaling the | 7. |
| | recent observation time window | | | | expiration threshold of the last | |
| | (tloss_exp) based on measured | | | | observed loss (loss_exp) based on| |
| | average loss interval (tloss_int)| | | | measured average loss interval | |
| | (loss_int) | |
| QTH | Delay threshold for invoking | 50ms | | QTH | Delay threshold for invoking | 50ms |
| | non-linear warping | | | | non-linear warping | |
| LAMBDA | Scaling parameter in the | 0.5 | | LAMBDA | Scaling parameter in the | 0.5 |
| | exponent of non-linear warping | | | | exponent of non-linear warping | |
+..............+..................................+................+ +..............+..................................+................+
| PLRREF | Reference packet loss ratio | 0.01 | | PLRREF | Reference packet loss ratio | 0.01 |
| PMRREF | Reference packet marking ratio | 0.01 | | PMRREF | Reference packet marking ratio | 0.01 |
| DLOSS | Reference delay penalty for loss | 10ms | | DLOSS | Reference delay penalty for loss | 10ms |
| | when packet loss ratio is at | | | | when packet loss ratio is at | |
| | PLRREF | | | | PLRREF | |
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 RTCP feedback report containing values of: rmode, x_curr, and r_recv send RTCP feedback report 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, a moderate queuing delay value below 100ms is likely self- instance, over wired connections, a moderate queuing delay value
inflicted or induced by other delay-based flows, whereas a high below 100ms is likely self-inflicted or induced by other delay-based
queuing delay value of several hundreds of milliseconds may indicate flows, whereas a high queuing delay value of several hundreds of
the presence of a loss-based flow that does not refrain from milliseconds may indicate the presence of a loss-based flow that does
increased delay. not refrain from increased delay.
If packet losses are observed within the previous time window of If the last observed packet loss is within the expiration window of
tloss_exp, the estimated queuing delay follows a non-linear warping: loss_exp (measured in terms of packet counts), the estimated queuing
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]. respect to [Budzisz-TON11]. The value of the threshold QTH may need
to tuned for different operational enviornments.
The value of tloss_exp is configured to self-scale with the average The value of loss_exp is configured to self-scale with the average
loss interval tloss_int with a multiplier MULTILOSS: packet loss interval loss_int with a multiplier MULTILOSS:
tloss_exp = MULTILOSS * tloss_int. loss_exp = MULTILOSS * loss_int.
Estimation of the average loss interval tloss_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].
In practice, it is recommended to linearly interpolate between the In practice, it is recommended to linearly interpolate between the
warped (d_tilde) and non-warped (d_queue) values of the queuing delay warped (d_tilde) and non-warped (d_queue) values of the queuing delay
during the transitional period lasting for the duration of tloss_int. during the transitional period lasting for the duration of loss_int.
The aggregate congestion signal is: The aggregate congestion signal is:
x_curr = d_tilde + DMARK*(p_mark/PMRREF)^2 + DLOSS*(p_loss/PLRREF)^2. (2) x_curr = d_tilde + DMARK*(p_mark/PMRREF)^2 + DLOSS*(p_loss/PLRREF)^2. (2)
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
skipping to change at page 12, line 30 skipping to change at page 12, line 37
The delay estimation process in NADA follows a similar approach as in The delay estimation process in NADA follows a similar approach as in
earlier delay-based congestion control schemes, such as LEDBAT earlier delay-based congestion control schemes, such as LEDBAT
[RFC6817]. Instead of relying on RTP timestamps, the NADA sender [RFC6817]. Instead of relying on RTP timestamps, the NADA sender
generates its own timestamp based on local system clock and embeds generates its own timestamp based on local system clock and embeds
that information in the transport packet header. The NADA receiver that information in the transport packet header. The NADA receiver
estimates the forward delay as having a constant base delay component estimates the forward delay as having a constant base delay component
plus a time varying queuing delay component. The base delay is plus a time varying queuing delay component. The base delay is
estimated as the minimum value of one-way delay observed over a estimated as the minimum value of one-way delay observed over a
relatively long period (e.g., tens of minutes), whereas the relatively long period (e.g., tens of minutes), whereas the
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. All delay estimations are based on one-way delay and base delay. By re-estimating the base delay
sender timestamps with higher granularity than RTP timestamps. periodically, one can avoid the potential issue of base delay
expiration, whereby an earlier measured base delay value is no longer
valid due to underlying route changes. All delay estimations are
based on sender timestamps with a recommended granularity of 100
microseconds or higher.
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. Current due to processing "hiccup" at the network nodes. Therefore, instead
implementation employs a 15-tap minimum filter over per-packet of simply calculating the value of base delay using d_base =
queuing delay estimates. min(d_base, d_fwd), as expressed in Section 5.1, current
implementation employs a minimum filter with a window size of 15
samples over per-packet queuing delay values.
5.1.2. Estimation of packet loss/marking ratio 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. Packets arriving out-of-order are
discarded, and count towards losses. The instantaneous packet loss discarded, and count towards losses. The instantaneous packet loss
ratio p_inst is estimated as the ratio between the number of missing ratio p_inst is estimated as the ratio between the number of missing
packets over the number of total transmitted packets within the packets over the number of total transmitted packets within the
recent observation window LOGWIN. The packet loss ratio p_loss is recent observation window LOGWIN. The packet loss ratio p_loss is
obtained after exponential smoothing: obtained after exponential smoothing:
skipping to change at page 16, line 50 skipping to change at page 16, line 50
Therefore, comparing the pros and cons regarding which delay metric Therefore, comparing the pros and cons regarding which delay metric
to adopt can be kept as an orthogonal direction of investigation. to adopt can be kept as an orthogonal direction of investigation.
6.2. Method for delay, loss, and marking ratio estimation 6.2. Method for delay, loss, and marking ratio estimation
Like other delay-based congestion control schemes, performance of Like other delay-based congestion control schemes, performance of
NADA depends on the accuracy of its delay measurement and estimation NADA depends on the accuracy of its delay measurement and estimation
module. Appendix A in [RFC6817] provides an extensive discussion on module. Appendix A in [RFC6817] provides an extensive discussion on
this aspect. this aspect.
The current recommended practice of simply applying a 15-tab minimum The current recommended practice of applying minimum filter with a
filter suffices in guarding against processing delay outliers window size of 15 samples suffices in guarding against processing
observed in wired connections. For wireless connections with a delay outliers observed in wired connections. For wireless
higher packet delay variation (PDV), more sophisticated techniques on connections with a higher packet delay variation (PDV), more
de-noising, outlier rejection, and trend analysis may be needed. sophisticated techniques on de-noising, outlier rejection, and trend
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 currently under investigation.
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
skipping to change at page 17, line 37 skipping to change at page 17, line 38
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
have established that a feedback interval below 250ms will not break have established that a feedback interval below 250ms (i.e., more
up the feedback control loop of NADA congestion control. frequently than 4 feedback messages per second) will not break up the
feedback control loop of NADA congestion control.
In calculating the non-linear warping of delay in (1), the current 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). It is possible to adapt its value based on the non-linear warping). Its value may need to be tuned for
past observed patterns of queuing delay in the presence of packet different operational enviornments (e.g., over wired vs. wireless
losses. connections). It is possible to adapt its value based on past
observed patterns of queuing delay in the presence of packet losses.
It needs to be noted that the non-linear warping mechanism may lead
to multiple NADA streams stuck in loss-based mode when competing
against each other.
In calculating the aggregate congestion signal x_curr, the choice of 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, a scheme for automatically
tuning these values based on desired bandwidth sharing behavior in tuning these values based on desired bandwidth sharing behavior in
the presence of other competing loss-based flows (e.g., loss-based the presence of other competing loss-based flows (e.g., loss-based
skipping to change at page 18, line 51 skipping to change at page 19, line 14
7. Implementation Status 7. Implementation Status
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]. presented at [IETF-93]. An open source implementation of NADA as
part of a ns-3 module is available at [ns3-rmcat]
The scheme has also been implemented and evaluated in a lab setting The scheme has also been implemented and evaluated in a lab setting
as described in [IETF-90]. Preliminary evaluation results of NADA in as described in [IETF-90]. Preliminary evaluation results of NADA in
single-flow and multi-flow scenarios have been presented in single-flow and multi-flow scenarios have been presented in
[IETF-91]. [IETF-91].
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
skipping to change at page 19, line 47 skipping to change at page 20, line 13
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. Acknowledgements 10. Acknowledgements
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, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede
their valuable questions and comments on earlier versions of this Nielsen, Julius Flohr, Roland Bless, and Andreas Smas for their
draft. Thanks to Charles Ganzhorn for contributing to the testbed- various valuable review comments and feedback. Thanks to Charles
based evaluation of NADA during an early stage of its development. Ganzhorn for contributing to the testbed-based evaluation of NADA
during an early stage of its development.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), March 2016.
[I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014.
[I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-05 (work in progress), April 2017.
[I-D.ietf-rmcat-video-traffic-model]
Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic
Sources for RMCAT Evaluations", draft-ietf-rmcat-video-
traffic-model-03 (work in progress), July 2017.
[I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-04 (work in progress), May 2017.
[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>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>.
[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>.
11.2. Informative References 11.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-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), March 2016.
[I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014.
[I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-05 (work in progress), April 2017.
[I-D.ietf-rmcat-video-traffic-model]
Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic
Sources for RMCAT Evaluations", draft-ietf-rmcat-video-
traffic-model-03 (work in progress), July 2017.
[I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-04 (work in progress), May 2017.
[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 21, line 46 skipping to change at page 22, line 21
[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>.
[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]
Fu, J., Mena, S., and X. Zhu, "NS3 open source module of
IETF RMCAT congestion control protocols", November 2017,
<https://github.com/cisco/ns3-rmcat>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the Queue Management and Congestion Avoidance in the
Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
<https://www.rfc-editor.org/info/rfc2309>. <https://www.rfc-editor.org/info/rfc2309>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660, Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012, DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>. <https://www.rfc-editor.org/info/rfc6660>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
skipping to change at page 22, line 33 skipping to change at page 23, line 11
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,
this appendix describes three variants of queue management behavior this appendix describes three variants of queue management behavior
at the network node, leading to either implicit or explicit at the network node, leading to either implicit or explicit
congestion signals. congestion signals. It needs to be acknowledged that NADA has not
yet been tested with non-probabilistic ECN marking behaviors.
In all three flavors described below, the network queue operates with In all three flavors described below, the network queue operates with
the simple first-in-first-out (FIFO) principle. There is no need to the simple first-in-first-out (FIFO) principle. There is no need to
maintain per-flow state. The system can scale easily with a large maintain per-flow state. The system can scale easily with a large
number of video flows and at high link capacity. number of video flows and at high link capacity.
A.1. Default behavior of drop tail queues A.1. Default behavior of drop tail queues
In a conventional network with drop tail or RED queues, congestion is In a conventional network with drop tail or RED queues, congestion is
inferred from the estimation of end-to-end delay and/or packet loss. inferred from the estimation of end-to-end delay and/or packet loss.
skipping to change at page 24, line 43 skipping to change at page 25, line 16
Xiaoqing Zhu Xiaoqing Zhu
Cisco Systems Cisco Systems
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
Cisco Systems Pensando Systems
3625 Cisco Way 1730 Technology Drive
San Jose, CA 95134 San Jose, CA 95110
USA USA
Email: ropan@cisco.com Email: rong@pensando.io
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: mramalho@cisco.com
Sergio Mena de la Cruz Sergio Mena de la Cruz
 End of changes. 34 change blocks. 
93 lines changed or deleted 120 lines changed or added

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