draft-ietf-rmcat-nada-04.txt   draft-ietf-rmcat-nada-05.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: September 28, 2017 S. Mena Expires: April 1, 2018 S. Mena
P. Jones P. Jones
J. Fu J. Fu
Cisco Systems Cisco Systems
S. D'Aronco S. D'Aronco
EPFL EPFL
March 27, 2017 September 28, 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-04 draft-ietf-rmcat-nada-05
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 37 skipping to change at page 1, line 37
losses instead. losses instead.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 September 28, 2017. This Internet-Draft will expire on April 1, 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . 7 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8
4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . 12
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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . 21
Appendix A. Network Node Operations . . . . . . . . . . . . . . 22 Appendix A. Network Node Operations . . . . . . . . . . . . . . 22
A.1. Default behavior of drop tail queues . . . . . . . . . . 22 A.1. Default behavior of drop tail queues . . . . . . . . . . 22
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 22
A.3. Random Early Marking with Virtual Queues . . . . . . . . 23 A.3. Random Early Marking with Virtual Queues . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described [RFC2119]. document are to be interpreted as described [RFC2119].
3. System Overview 3. System Overview
Figure 1 shows the end-to-end system for real-time media transport Figure 1 shows the end-to-end system for real-time media transport
that NADA operates in. Note that there also exist network nodes that NADA operates in. Note that there also exist network nodes
along the reverse (potentially uncongested) path that the RTCP along the reverse (potentially uncongested) path that the RTCP
feedback reports traverse. Those network nodes are not shown in the feedback reports traverse. Those network nodes are not shown in the
figure for sake of brevity. figure for sake of abrevity.
+---------+ r_vin +--------+ +--------+ +----------+ +---------+ r_vin +--------+ +--------+ +----------+
| Media |<--------| RTP | |Network | | RTP | | Media |<--------| RTP | |Network | | RTP |
| Encoder |========>| Sender |=======>| Node |====>| Receiver | | Encoder |========>| Sender |=======>| Node |====>| Receiver |
+---------+ r_vout +--------+ r_send +--------+ +----------+ +---------+ r_vout +--------+ r_send +--------+ +----------+
/|\ | /|\ |
| | | |
+---------------------------------+ +---------------------------------+
RTCP Feedback Report RTCP Feedback Report
skipping to change at page 5, line 16 skipping to change at page 5, line 16
Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA Like TCP-Friendly Rate Control (TFRC) [Floyd-CCR00] [RFC5348], NADA
is a rate-based congestion control algorithm. In its simplest form, is a rate-based congestion control algorithm. In its simplest form,
the sender reacts to the collection of network congestion indicators the sender reacts to the collection of network congestion indicators
in the form of an aggregated congestion signal, and operates in one in the form of an aggregated congestion signal, and operates in one
of two modes: of two modes:
o Accelerated ramp-up: when the bottleneck is deemed to be o Accelerated ramp-up: when the bottleneck is deemed to be
underutilized, the rate increases multiplicatively with respect to underutilized, the rate increases multiplicatively with respect to
the rate of previously successful transmissions. The rate the rate of previously successful transmissions. The rate
increase multiplier (gamma) is calculated based on observed round- increase mutliplier (gamma) is calculated based on observed round-
trip-time and target feedback interval, so as to limit self- trip-time and target feedback interval, so as to limit self-
inflicted queuing delay. inflicted queuing delay.
o Gradual rate update: in the presence of non-zero aggregate o Gradual rate update: in the presence of non-zero aggregate
congestion signal, the sending rate is adjusted in reaction to congestion signal, the sending rate is adjusted in reaction to
both its value (x_curr) and its change in value (x_diff). both its value (x_curr) and its change in value (x_diff).
This section introduces the list of mathematical notations and This section introduces the list of mathematical notations and
describes the core congestion control algorithm at the sender and describes the core congestion control algorithm at the sender and
receiver, respectively. Additional details on recommended practical receiver, respectively. Additional details on recommended practical
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 |
| tloss_exp | Time window for recently observed losses |
| rtt | Estimated round-trip-time at sender | | rtt | Estimated round-trip-time at sender |
| buffer_len | Rate shaping buffer occupancy measured in bytes | | buffer_len | Rate shaping buffer occupancy measured in bytes |
+--------------+-------------------------------------------------+ +--------------+-------------------------------------------------+
Figure 2: List of variables. Figure 2: List of variables.
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
| Notation | Parameter Name | Default Value | | Notation | Parameter Name | Default Value |
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
| PRIO | Weight of priority of the flow | 1.0 | PRIO | Weight of priority of the flow | 1.0
| RMIN | Minimum rate of application | 150 Kbps | | RMIN | Minimum rate of application | 150 Kbps |
| | supported by media encoder | | | | supported by media encoder | |
| RMAX | Maximum rate of application | 1.5 Mbps | | RMAX | Maximum rate of application | 1.5 Mbps |
| | supported by media encoder | | | | supported by media encoder | |
| XREF | Reference congestion level | 20ms | | 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 | | 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% | | GAMMA_MAX | Upper bound on rate increase | 50% |
| | 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 | |
+..............+..................................+................+ +..............+..................................+................+
| TEXP | Expiration time for previously | 30s | | MULTILOSS | Multiplier for self-scaling the | 7. |
| | observed packet loss | | | | recent observation time window | |
| QTH | Delay threshold for non-linear | 50ms | | | (tloss_exp) based on measured | |
| | warping | | | | average loss interval (tloss_int)| |
| QTH | Delay threshold for invoking | 50ms |
| | 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 | |
+..............+..................................+................+ +..............+..................................+................+
| DLOSS | Delay penalty for loss | 1.0s | | PLRREF | Reference packet loss ratio | 0.01 |
| DMARK | Delay penalty for ECN marking | 200ms | | PMRREF | Reference packet marking ratio | 0.01 |
| DLOSS | Reference delay penalty for loss | 10ms |
| | when packet loss ratio is at | |
| | PLRREF | |
| DMARK | Reference delay penalty for ECN | 2ms |
| | marking when packet marking | |
| | is at PMRREF | |
+..............+..................................+................+ +..............+..................................+................+
| 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 |
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
skipping to change at page 8, line 39 skipping to change at page 8, line 43
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, a moderate queuing delay value below 100ms is likely self-
inflicted or induced by other delay-based flows, whereas a high inflicted or induced by other delay-based flows, whereas a high
queuing delay value of several hundreds of milliseconds may indicate queuing delay value of several hundreds of milliseconds may indicate
the presence of a loss-based flow that does not refrain from the presence of a loss-based flow that does not refrain from
increased delay. increased delay.
If packet losses are observed within the previous time window of If packet losses are observed within the previous time window of
TEXP, the estimated queuing delay follows a non-linear warping: tloss_exp, 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 window 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 tloss_exp is configured to self-scale with the average
loss interval tloss_int with a multiplier MULTILOSS:
tloss_exp = MULTILOSS * tloss_int.
Estimation of the average loss interval tloss_int, in turn, follows
Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol
[RFC5348].
In practice, it is recommended to linearly interpolate between the
warped (d_tilde) and non-warped (d_queue) values of the queuing delay
during the transitional period lasting for the duration of tloss_int.
The aggregate congestion signal is: The aggregate congestion signal is:
x_curr = d_tilde + p_mark*DMARK + p_loss*DLOSS. (2) x_curr = d_tilde + DMARK*(p_mark/PMRREF)^2 + DLOSS*(p_loss/PLRREF)^2. (2)
Here, DMARK is prescribed delay penalty associated with ECN markings Here, DMARK is prescribed reference delay penalty associated with ECN
and DLOSS is prescribed delay penalty associated with packet losses. markings at the reference marking ratio of PMRREF; DLOSS is
The value of DLOSS and DMARK does not depend on configurations at the prescribed reference delay penalty associated with packet losses at
network node. Since ECN-enabled active queue management schemes the reference packet loss ratio of PLRREF. The value of DLOSS and
typically mark a packet before dropping it, the value of DLOSS SHOULD DMARK does not depend on configurations at the network node. Since
be higher than that of DMARK. Furthermore, the values of DLOSS and ECN-enabled active queue management schemes typically mark a packet
DMARK need to be set consistently across all NADA flows for them to before dropping it, the value of DLOSS SHOULD be higher than that of
compete fairly. DMARK. Furthermore, the values of DLOSS and DMARK need to be set
consistently across all NADA flows for them to 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 11, line 26 skipping to change at page 11, line 30
The rate changes in proportion to the previous rate decision. It is The rate changes in proportion to the previous rate decision. It is
affected by two terms: offset of the aggregate congestion signal from affected by two terms: offset of the aggregate congestion signal from
its value at equilibrium (x_offset) and its change (x_diff). its value at equilibrium (x_offset) and its change (x_diff).
Calculation of x_offset depends on maximum rate of the flow (RMAX), Calculation of x_offset depends on maximum rate of the flow (RMAX),
its weight of priority (PRIO), as well as a reference congestion its weight of priority (PRIO), as well as a reference congestion
signal (XREF). The value of XREF is chosen so that the maximum rate signal (XREF). The value of XREF is chosen so that the maximum rate
of RMAX can be achieved when the observed congestion signal level is of RMAX can be achieved when the observed congestion signal level is
below PRIO*XREF. below PRIO*XREF.
At equilibrium, the aggregated congestion signal stabilizes at x_curr At equilibrium, the aggregated congestion signal stablizes at x_curr
= PRIO*XREF*RMAX/r_ref. This ensures that when multiple flows share = PRIO*XREF*RMAX/r_ref. This ensures that when multiple flows share
the same bottleneck and observe a common value of x_curr, their rates the same bottleneck and observe a common value of x_curr, their rates
at equilibrium will be proportional to their respective priority at equilibrium will be proportional to their respective priority
levels (PRIO) and maximum rate (RMAX). Values of RMIN and RMAX will levels (PRIO) and maximum rate (RMAX). Values of RMIN and RMAX will
be provided by the media codec, as specified in be provided by the media codec, as specified in
[I-D.ietf-rmcat-cc-codec-interactions]. In the absence of such [I-D.ietf-rmcat-cc-codec-interactions]. In the absense of such
information, NADA sender will choose a default value of 0 for RMIN, information, NADA sender will choose a default value of 0 for RMIN,
and 2Mbps for RMAX. and 2Mbps for RMAX.
As mentioned in the sender-side algorithm, the final rate is clipped As mentioned in the sender-side algorithm, the final rate is clipped
within the dynamic range specified by the application: within the dynamic range specified by the application:
r_ref = min(r_ref, RMAX) (8) r_ref = min(r_ref, RMAX) (8)
r_ref = max(r_ref, RMIN) (9) r_ref = max(r_ref, RMIN) (9)
skipping to change at page 13, line 12 skipping to change at page 13, line 15
The filtered result is reported back to the sender as the observed The filtered result is reported back to the sender as the observed
packet loss ratio p_loss. packet loss ratio p_loss.
Estimation of packet marking ratio p_mark follows the same procedure Estimation of packet marking ratio p_mark follows the same procedure
as above. It is assumed that ECN marking information at the IP as above. It is assumed that ECN marking information at the IP
header can be passed to the receiving endpoint, e.g., by following header can be passed to the receiving endpoint, e.g., by following
the mechanism described in [RFC6679]. the mechanism described in [RFC6679].
5.1.3. Estimation of receiving rate 5.1.3. Estimation of receiving rate
It is fairly straightforward 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) is included
as part of the feedback report. 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
skipping to change at page 17, line 41 skipping to change at page 17, line 41
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 will not break
up the feedback control loop of NADA congestion control. 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 and TEXP for determining whether to design uses fixed values of QTH for determining whether to perform
perform the non-linear warping). It is possible to adapt the value the non-linear warping). It is possible to adapt its value based on
of both based on past observed patterns of queuing delay in the past observed patterns of queuing delay in the presence of packet
presence of packet losses. losses.
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 20, line 9 skipping to change at page 20, line 9
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, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for
their valuable questions and comments on earlier versions of this their valuable questions and comments on earlier versions of this
draft. Thanks to Charles Ganzhorn for contributing to the testbed- draft. Thanks to Charles Ganzhorn for contributing to the testbed-
based evaluation of NADA during an early stage of its development. 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,
<http://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,
<http://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, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[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, <http://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
[I-D.ietf-rmcat-eval-test] 11.2. Informative References
Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-04 (work in progress), October 2016.
[I-D.ietf-rmcat-cc-requirements] [Budzisz-TON11]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and
for Interactive Real-Time Media", draft-ietf-rmcat-cc- R. Shorten, "On the Fair Coexistence of Loss- and Delay-
requirements-09 (work in progress), December 2014. Based TCP", IEEE/ACM Transactions on Networking vol. 19,
no. 6, pp. 1811-1824, December 2011.
[I-D.ietf-rmcat-video-traffic-model] [Floyd-CCR00]
Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic Floyd, S., Handley, M., Padhye, J., and J. Widmer,
Sources for RMCAT Evaluations", draft-ietf-rmcat-video- "Equation-based Congestion Control for Unicast
traffic-model-02 (work in progress), January 2017. Applications", ACM SIGCOMM Computer Communications
Review vol. 30, no. 4, pp. 43-56, October 2000.
[I-D.ietf-rmcat-cc-codec-interactions] [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan,
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "NADA Update: Algorithm, Implementation, and Test Case
"Congestion Control and Codec interactions in RTP Evalua6on Results", July 2014,
Applications", draft-ietf-rmcat-cc-codec-interactions-02 <https://tools.ietf.org/agenda/90/slides/
(work in progress), March 2016. slides-90-rmcat-6.pdf>.
[I-D.ietf-rmcat-wireless-tests] [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and Jones, P., and S. D'Aronco, "NADA Algorithm Update and
M. Ramalho, "Evaluation Test Cases for Interactive Real- Test Case Evaluations", November 2014,
Time Media over Wireless Networks", draft-ietf-rmcat- <http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/
wireless-tests-03 (work in progress), November 2016. slides/slides-interim-2014-rmcat-1-2.pdf>.
11.2. Informative References [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA",
July 2015, <https://www.ietf.org/proceedings/93/slides/
slides-93-rmcat-0.pdf>.
[ns-2] "The Network Simulator - ns-2",
<http://www.isi.edu/nsnam/ns/>.
[ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>.
[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,
<http://www.rfc-editor.org/info/rfc2309>. <https://www.rfc-editor.org/info/rfc2309>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008, RFC 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>. <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,
<http://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,
<http://www.rfc-editor.org/info/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
[Floyd-CCR00]
Floyd, S., Handley, M., Padhye, J., and J. Widmer,
"Equation-based Congestion Control for Unicast
Applications", ACM SIGCOMM Computer Communications
Review vol. 30, no. 4, pp. 43-56, October 2000.
[Budzisz-TON11]
Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and
R. Shorten, "On the Fair Coexistence of Loss- and Delay-
Based TCP", IEEE/ACM Transactions on Networking vol. 19,
no. 6, pp. 1811-1824, December 2011.
[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.
[ns-2] "The Network Simulator - ns-2",
<http://www.isi.edu/nsnam/ns/>.
[ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>.
[IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan,
"NADA Update: Algorithm, Implementation, and Test Case
Evalua6on Results", July 2014,
<https://tools.ietf.org/agenda/90/slides/slides-90-rmcat-
6.pdf>.
[IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
Jones, P., and S. D'Aronco, "NADA Algorithm Update and
Test Case Evaluations", November 2014,
<http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/
slides/slides-interim-2014-rmcat-1-2.pdf>.
[IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA",
July 2015, <https://www.ietf.org/proceedings/93/slides/
slides-93-rmcat-0.pdf>.
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.
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
skipping to change at page 25, line 6 skipping to change at page 25, line 6
Rong Pan Rong Pan
Cisco Systems Cisco Systems
3625 Cisco Way 3625 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: ropan@cisco.com Email: ropan@cisco.com
Michael A. Ramalho Michael A. Ramalho
Cisco Systems, Inc. Cisco Systems, Inc.
6310 Watercrest Way, Unit 203 8000 Hawkins Road
Lakewood Ranch, FL 34202-5211 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
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
 End of changes. 40 change blocks. 
103 lines changed or deleted 127 lines changed or added

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