draft-ietf-rmcat-nada-03.txt   draft-ietf-rmcat-nada-04.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: March 22, 2017 S. Mena Expires: September 28, 2017 S. Mena
P. Jones P. Jones
J. Fu J. Fu
Cisco Systems Cisco Systems
S. D'Aronco S. D'Aronco
EPFL EPFL
C. Ganzhorn March 27, 2017
September 18, 2016
NADA: A Unified Congestion Control Scheme for Real-Time Media NADA: A Unified Congestion Control Scheme for Real-Time Media
draft-ietf-rmcat-nada-03 draft-ietf-rmcat-nada-04
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 45 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 22, 2017. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . 8 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 7
4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 9 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 9
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
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 abrevity. figure for sake of brevity.
+---------+ 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 mutliplier (gamma) is calculated based on observed round- increase multiplier (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 7, line 5 skipping to change at page 6, line 37
| 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 |
| 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 | 20ms |
| 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 | |
| TEXPLOSS | Expiration time for previously | 30s |
| | observed packet loss | |
| 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% |
| | ratio for accelerated ramp-up | |
| QBOUND | Upper bound on self-inflicted | 50ms |
| | queuing delay during ramp up | |
+..............+..................................+................+ +..............+..................................+................+
| TEXP | Expiration time for previously | 30s |
| | observed packet loss | |
| QTH | Delay threshold for non-linear | 50ms | | QTH | Delay threshold for non-linear | 50ms |
| | warping | | | | warping | |
| LAMBDA | Scaling parameter in the | 0.5 |
| | exponent of non-linear warping | |
+..............+..................................+................+
| DLOSS | Delay penalty for loss | 1.0s | | DLOSS | Delay penalty for loss | 1.0s |
| DMARK | Delay penalty for ECN marking | 200ms | | DMARK | Delay penalty for ECN marking | 200ms |
+..............+..................................+................+ +..............+..................................+................+
| GAMMA_MAX | Upper bound on rate increase | 50% |
| | ratio for accelerated ramp-up | |
| QBOUND | Upper bound on self-inflicted | 50ms |
| | queuing delay during ramp up | |
+..............+..................................+................+
| 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 43 skipping to change at page 8, line 39
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
TLOSS, the estimated queuing delay follows a non-linear warping: TEXP, 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(- ----------------) , otherwise. \ QTH exp(-LAMBDA ---------------) , otherwise.
QTH QTH
In (1), the queuing delay value is unchanged when it is below the In (1), the queuing delay value is unchanged when it is below the
first threshold QTH; otherwise it is scaled down following a non- first threshold QTH; otherwise it is scaled down following a non-
linear curve. This non-linear warping is inspired by the delay- linear curve. This non-linear warping is inspired by the delay-
adaptive congestion windown backoff policy in [Budzisz-TON11], so as adaptive congestion window backoff policy in [Budzisz-TON11], so as
to "gradually nudge" the controller to operate based on loss-induced to "gradually nudge" the controller to operate based on loss-induced
congestion signals when competing against loss-based flows. The congestion signals when competing against loss-based flows. The
exact form of the non-linear function has been simplified with exact form of the non-linear function has been simplified with
respect to [Budzisz-TON11]. respect to [Budzisz-TON11].
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 + p_mark*DMARK + p_loss*DLOSS. (2)
Here, DMARK is prescribed delay penalty associated with ECN markings Here, DMARK is prescribed delay penalty associated with ECN markings
and DLOSS is prescribed delay penalty associated with packet losses. and DLOSS is prescribed delay penalty associated with packet losses.
The value of DLOSS and DMARK does not depend on configurations at the The value of DLOSS and DMARK does not depend on configurations at the
network node. Since ECN-enabled active queue management schemes network node. Since ECN-enabled active queue management schemes
typically mark a packet before dropping it, the value of DLOSS SHOULD typically mark a packet before dropping it, the value of DLOSS SHOULD
be higher than that of DMARK. Furthermore, the values of DLOS and be higher than that of DMARK. Furthermore, the values of DLOSS and
DMARK need to be set consistently across all NADA flows for them to DMARK need to be set consistently across all NADA flows for them to
compete fairly. 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
skipping to change at page 11, line 26 skipping to change at page 11, line 26
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 stablizes at x_curr At equilibrium, the aggregated congestion signal stabilizes 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 absense of such [I-D.ietf-rmcat-cc-codec-interactions]. In the absence 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 12
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 straighforward to estimate the receiving rate r_recv. It is fairly straightforward 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 TLOSS (for determining whether to design uses fixed values of QTH and TEXP for determining whether to
perform the non-linear warpming). It is possible to adapt the value perform the non-linear warping). It is possible to adapt the value
of both based on past observed patterns of queuing delay in the of both based on past observed patterns of queuing delay in the
presence of packet losses. presence of packet 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
TCP) is under investigation. TCP) is under investigation.
[Editor's note: Choice of start value: is this in scope of congestion
control, or should this be decided by the application?]
6.4. Sender-based vs. receiver-based calculation 6.4. Sender-based vs. receiver-based calculation
In the current design, the aggregated congestion signal x_curr is In the current design, the aggregated congestion signal x_curr is
calculated at the receiver, keeping the sender operation completely calculated at the receiver, keeping the sender operation completely
independent of the form of actual network congestion indications independent of the form of actual network congestion indications
(delay, loss, or marking). Alternatively, one can move the logics of (delay, loss, or marking). Alternatively, one can move the logics of
(1) and (2) to the sender. Such an approach requires slightly higher (1) and (2) to the sender. Such an approach requires slightly higher
overhead in the feedback messages, which should contain individual overhead in the feedback messages, which should contain individual
fields on queuing delay (d_queue), packet loss ratio (p_loss), packet fields on queuing delay (d_queue), packet loss ratio (p_loss), packet
marking ratio (p_mark), receiving rate (r_recv), and recommended rate marking ratio (p_mark), receiving rate (r_recv), and recommended rate
skipping to change at page 19, line 27 skipping to change at page 19, line 24
[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 also bee evaluated in implementations embedded in
video conferencing clients. video conferencing clients.
Further experiments are suggested for the following scenarios: Further experiments are suggested for the following scenarios:
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
cellular networks such as 3G/LTE. cellular networks such as 3G/LTE.
o Experiments with various media source contents, including audio o Experiments with various media source contents, including audio
only, audio and video, and application content sharing (e.g., only, audio and video, and application content sharing (e.g.,
slide shows). slide shows).
o
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, 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. draft. Thanks to Charles 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
[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>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 32 skipping to change at page 20, line 30
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, <http://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, <http://www.rfc-editor.org/info/rfc6679>.
[I-D.ietf-rmcat-eval-test] [I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and D. 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-03 (work in progress), March 2016. eval-test-04 (work in progress), October 2016.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[I-D.ietf-rmcat-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, "Modeling Video Traffic
Sources for RMCAT Evaluations", draft-ietf-rmcat-video- Sources for RMCAT Evaluations", draft-ietf-rmcat-video-
traffic-model-01 (work in progress), July 2016. traffic-model-02 (work in progress), January 2017.
[I-D.ietf-rmcat-cc-codec-interactions] [I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP "Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-02 Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), March 2016. (work in progress), March 2016.
[I-D.ietf-rmcat-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-02 (work in progress), May 2016. wireless-tests-03 (work in progress), November 2016.
11.2. Informative References 11.2. Informative References
[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>. <http://www.rfc-editor.org/info/rfc2309>.
skipping to change at page 23, line 45 skipping to change at page 23, line 45
Advanced network nodes may support random early marking based on a Advanced network nodes may support random early marking based on a
token bucket algorithm originally designed for Pre-Congestion token bucket algorithm originally designed for Pre-Congestion
Notification (PCN) [RFC6660]. The early congestion notification Notification (PCN) [RFC6660]. The early congestion notification
(ECN) bit in the IP header of packets are marked randomly. The (ECN) bit in the IP header of packets are marked randomly. The
marking probability is calculated based on a token-bucket algorithm marking probability is calculated based on a token-bucket algorithm
originally designed for the Pre-Congestion Notification (PCN) originally designed for the Pre-Congestion Notification (PCN)
[RFC6660]. The target link utilization is set as 90%; the marking [RFC6660]. The target link utilization is set as 90%; the marking
probability is designed to grow linearly with the token bucket size probability is designed to grow linearly with the token bucket size
when it varies between 1/3 and 2/3 of the full token bucket limit. when it varies between 1/3 and 2/3 of the full token bucket limit.
* upon packet arrival, meter packet against token bucket (r,b); Calculation of the marking probability involves the following steps:
* update token level b_tk; upon packet arrival:
meter packet against token bucket (r,b);
* calculate the marking probability as: update token level b_tk;
calculate the marking probability as:
/ 0, if b-b_tk < b_lo; / 0, if b-b_tk < b_lo;
| |
| b-b_tk-b_lo | b-b_tk-b_lo
p = < p_max* --------------, if b_lo<= b-b_tk <b_hi; p = < p_max* --------------, if b_lo<= b-b_tk <b_hi;
| b_hi-b_lo | b_hi-b_lo
| |
\ 1, if b-b_tk>=b_hi. \ 1, if b-b_tk>=b_hi.
Here, the token bucket lower and upper limits are denoted by b_lo and Here, the token bucket lower and upper limits are denoted by b_lo and
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.
8000 Hawkins Road 6310 Watercrest Way, Unit 203
Sarasota, FL 34241 Lakewood Ranch, FL 34202-5211
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
skipping to change at page 26, line 4 skipping to change at line 1088
Email: jianfu@cisco.com Email: jianfu@cisco.com
Stefano D'Aronco Stefano D'Aronco
Ecole Polytechnique Federale de Lausanne Ecole Polytechnique Federale de Lausanne
EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11 EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11
Lausanne CH-1015 Lausanne CH-1015
Switzerland Switzerland
Email: stefano.daronco@epfl.ch Email: stefano.daronco@epfl.ch
Charles Ganzhorn
7900 International Drive, International Plaza, Suite 400
Bloomington, MN 55425
USA
Email: charles.ganzhorn@gmail.com
 End of changes. 37 change blocks. 
44 lines changed or deleted 47 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/