One document matched: draft-ietf-rmcat-nada-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2309 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3168 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc4585 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc5506 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml">
<!ENTITY rfc5166 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5166.xml">
<!ENTITY rfc5033 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5033.xml">
<!ENTITY rfc5348 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml">
<!ENTITY rfc5681 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY rfc6660 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
<!ENTITY rfc6817 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6817.xml">
<!ENTITY I-D.ietf-rmcat-cc-requirements PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-requirements.xml">
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.ietf-rmcat-eval-criteria PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-criteria.xml">
<!ENTITY I-D.ietf-rtcweb-use-cases-and-requirements PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-use-cases-and-requirements.xml">
<!ENTITY I-D.ietf-rmcat-eval-test PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-test.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="exp"
docName="draft-ietf-rmcat-nada-01"
ipr="trust200902">
<!-- What is the category field value-->
<front>
<title abbrev="NADA">
NADA: A Unified Congestion Control Scheme for Real-Time Media
</title>
<author fullname="Xiaoqing Zhu" initials="X" surname="Zhu">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>12515 Research Blvd., Building 4</street>
<city>Austin</city>
<region>TX</region>
<code>78759</code>
<country>USA</country>
</postal>
<email>xiaoqzhu@cisco.com</email>
</address>
</author>
<author fullname="Rong Pan" initials="R" surname="Pan">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3625 Cisco Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>ropan@cisco.com</email>
</address>
</author>
<author fullname="Michael A. Ramalho" initials="M. A." surname="Ramalho">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>8000 Hawkins Road</street>
<city>Sarasota</city>
<region>FL</region>
<code>34241</code>
<country>USA</country>
</postal>
<phone>+1 919 476 2038</phone>
<email>mramalho@cisco.com</email>
</address>
</author>
<author fullname="Sergio Mena de la Cruz" initials="S. " surname="Mena">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>EPFL, Quartier de l'Innovation, Batiment E</street>
<city>Ecublens</city>
<region>Vaud</region>
<code>1015</code>
<country>Switzerland</country>
</postal>
<email>semena@cisco.com</email>
</address>
</author>
<author fullname="Paul E. Jones" initials="P. E." surname="Jones">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<email>paulej@packetizer.com</email>
</address>
</author>
<author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>707 Tasman Drive</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>USA</country>
</postal>
<email>jianfu@cisco.com</email>
</address>
</author>
<author fullname="Stefano D'Aronco" initials="S." surname="D'Aronco">
<organization abbrev="EPFL">Ecole Polytechnique Federale de Lausanne</organization>
<address>
<postal>
<street>EPFL STI IEL LTS4, ELD 220 (Batiment ELD), Station 11</street>
<city>Lausanne</city>
<region></region>
<code>CH-1015</code>
<country>Switzerland</country>
</postal>
<email>stefano.daronco@epfl.ch</email>
</address>
</author>
<author fullname="Charles Ganzhorn" initials="C" surname="Ganzhorn">
<address>
<postal>
<street>7900 International Drive, International Plaza, Suite 400</street>
<city>Bloomington</city>
<region>MN</region>
<code>55425</code>
<country>USA</country>
</postal>
<email>charles.ganzhorn@gmail.com</email>
</address>
</author>
<date year="2015" />
<area>TSV</area>
<keyword>Multimedia</keyword>
<keyword>Congestion Control</keyword>
<abstract>
<t>This document describes NADA (network-assisted dynamic adaptation),
a novel congestion control scheme for interactive real-time media
applications, such as video conferencing. In the proposed scheme, the
sender regulates its sending rate based on either implicit or
explicit congestion signaling, in a unified approach. The scheme can
benefit from explicit congestion notification (ECN) markings from
network nodes. It also maintains consistent sender behavior in the
absence of such markings, by reacting to queuing delays and packet
losses instead. </t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>Interactive real-time media applications introduce
a unique set of challenges for congestion control.
Unlike TCP, the mechanism used for real-time media needs
to adapt quickly to instantaneous bandwidth changes,
accommodate fluctuations in the output of video encoder
rate control, and cause low queuing delay over the network.
An ideal scheme should also make effective use of all types
of congestion signals, including packet loss, queuing delay,
and explicit congestion notification (ECN) <xref target="RFC3168"></xref>
markings. The requirements for the congestion control
algorithm are outlined in
<xref target="I-D.ietf-rmcat-cc-requirements"></xref>.
</t>
<t>This document describes an experimental congestion control
scheme called network-assisted dynamic adaptation (NADA).
The NADA design benefits from explicit congestion control
signals (e.g., ECN markings) from the network, yet also operates
when only implicit congestion indicators (delay and/or loss)
are available. In addition, it supports weighted bandwidth
sharing among competing video flows. The signaling mechanism
consists of standard RTP timestamp <xref target="RFC3550"></xref>
and standard RTCP feedback reports.
</t>
</section>
<section anchor="sec-term" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="sec-system-overview"
title="System Overview">
<t><xref target="fig-system-overview"></xref> shows the
end-to-end system for real-time media transport that NADA
operates in.</t>
<t>
<figure anchor="fig-system-overview"
title="System Overview">
<artwork><![CDATA[
+---------+ r_vin +--------+ +--------+ +----------+
| Media |<--------| RTP | |Network | | RTP |
| Encoder |========>| Sender |=======>| Node |====>| Receiver |
+---------+ r_vout +--------+ r_send +--------+ +----------+
/|\ |
| |
+---------------------------------+
RTCP Feedback Report
]]></artwork>
</figure></t>
<t><list style="symbols">
<t>Media encoder with rate control capabilities.
It encodes the source media stream into an RTP
stream with target bit rate r_vin. The actual
output rate from the encoder r_vout may fluctuate
around the target r_vin. In addition, the encoder
can only change its bit rate at rather coarse time
intervals, e.g., once every 0.5 seconds.
</t>
<t> RTP sender: responsible for calculating the
NADA reference rate based on network congestion
indicators (delay, loss, or ECN marking reports
from the receiver), for updating the video encoder
with a new target rate r_vin, and for regulating
the actual sending rate r_send accordingly.
The RTP sender also provides an RTP timestamp for
each outgoing packet.
</t>
<t>RTP receiver: responsible for measuring and
estimating end-to-end delay based on sender RTP
timestamp, packet loss and ECN marking ratios,
as well as receiving rate (r_recv) of the flow.
It calculates the aggregated congestion signal
(x_n) that accounts for queuing delay, ECN marking,
and packet losses, and determines the mode for
sender rate adaptation (rmode) based on whether
the flow has encountered any standing non-zero
congestion. The receiver sends periodic RTCP
reports back to the sender, containing values of
x_n, rmode, and r_recv.
</t>
<t>Network node with several modes of operation.
The system can work with the default behavior of
a simple drop tail queue. It can also benefit
from advanced AQM features such as PIE, FQ-CoDel,
RED-based ECN marking, and PCN marking using a
token bucket algorithm. Note that network node
operation is out of scope for the design of NADA.
</t>
</list></t>
</section>
<section anchor="sec-algorithm"
title="Core Congestion Control Algorithm">
<t>
Like TCP-Friendly Rate Control (TFRC)
<xref target="Floyd-CCR00"></xref>
<xref target="RFC5348"></xref>, NADA is a rate-based congestion
control algorithm. In its simplest form, the sender
reacts to the collection of network congestion
indicators in the form of an aggregated congestion
signal, and operates in one of two modes:
<list style="symbols">
<t>Accelerated ramp-up: when the bottleneck is deemed to
be underutilized, the rate increases multiplicatively with
respect to the rate of previously successful transmissions.
The rate increase mutliplier (gamma) is calculated based on
observed round-trip-time and target feedback interval, so
as to limit self-inflicted queuing delay.
</t>
<t>Gradual rate update: in the presence of non-zero
aggregate congestion signal, the sending rate is
adjusted in reaction to both its value (x_n)
and its change in value (x_diff).</t>
</list>
</t>
<t>This section introduces the list of mathematical notations
and describes the core congestion control algorithm at the
sender and receiver, respectively. Additional details on
recommended practical implementations are described in
<xref target="sec-receiver"></xref> and
<xref target="sec-sender"></xref>.
</t>
<section anchor="sec-notation"
title = "Mathematical Notations">
<t>This section summarizes the list of variables and parameters
used in the NADA algorithm. </t>
<t><figure anchor="tab-variables"
title ="List of variables.">
<artwork><![CDATA[
+--------------+-------------------------------------------------+
| Notation | Variable Name |
+--------------+-------------------------------------------------+
| t_curr | Current timestamp |
| t_last | Last time sending/receiving a feedback |
| delta | Observed interval between current and previous |
| | feedback reports: delta = t_curr-t_last |
| r_n | Reference rate based on network congestion |
| r_send | Sending rate |
| r_recv | Receiving rate |
| r_vin | Target rate for video encoder |
| r_vout | Output rate from video encoder |
| d_base | Estimated baseline delay |
| d_fwd | Measured and filtered one-way delay |
| d_n | Estimated queueing delay |
| d_tilde | Equivalent delay after non-linear warping |
| p_mark | Estimated packet ECN marking ratio |
| p_loss | Estimated packet loss ratio |
| x_n | Aggregate congestion signal |
| x_prev | Previous value of aggregate congestion signal |
| x_diff | Change in aggregate congestion signal w.r.t. |
| | its previous value: x_diff = x_n - x_prev |
| rmode | Rate update mode: (0 = accelerated ramp-up; |
| | 1 = gradual update) |
| gamma | Rate increase multiplier in accelerated ramp-up |
| | mode |
| rtt | Estimated round-trip-time at sender |
| buffer_len | Rate shaping buffer occupancy measured in bytes |
+--------------+-------------------------------------------------+
]]></artwork>
</figure></t>
<t><figure anchor="tab-parameters"
title ="List of algorithm parameters.">
<artwork><![CDATA[
+---------------+---------------------------------+----------------+
| Notation | Parameter Name | Default Value |
+--------------+----------------------------------+----------------+
| PRIO | Weight of priority of the flow | 1.0
| RMIN | Minimum rate of application | 150 Kbps |
| | supported by media encoder | |
| RMAX | Maximum rate of application | 1.5 Mbps |
| | supported by media encoder | |
| X_REF | Reference congestion level | 20ms |
| KAPPA | Scaling parameter for gradual | 0.5 |
| | rate update calculation | |
| ETA | Scaling parameter for gradual | 2.0 |
| | rate update calculation | |
| TAU | Upper bound of RTT in gradual | 500ms |
| | rate update calculation | |
| DELTA | Target feedback interval | 100ms |
| LOGWIN | Observation window in time for | 500ms |
| | calculating packet summary | |
| | statistics at receiver | |
| QEPS | Threshold for determining queuing| 10ms |
| | delay build up at receiver | |
+..............+..................................+................+
| QTH | Delay threshold for non-linear | 100ms |
| | warping | |
| QMAX | Delay upper bound for non-linear | 400ms |
| | warping | |
| DLOSS | Delay penalty for loss | 1.0s |
| DMARK | Delay penalty for ECN marking | 200ms |
+..............+..................................+................+
| GAMMA_MAX | Upper bound on rate increase | 20% |
| | ratio for accelerated ramp-up | |
| QBOUND | Upper bound on self-inflicted | 50ms |
| | queuing delay during ramp up | |
+..............+..................................+................+
| FPS | Frame rate of incoming video | 30 |
| BETA_S | Scaling parameter for modulating | 0.1 |
| | outgoing sending rate | |
| BETA_V | Scaling parameter for modulating | 0.1 |
| | video encoder target rate | |
| ALPHA | Smoothing factor in exponential | 0.1 |
| | smoothing of packet loss and | |
| | marking ratios |
+--------------+----------------------------------+----------------+
]]></artwork>
</figure></t>
</section>
<section anchor = "subsec-receiver-algorithm"
title = "Receiver-Side Algorithm">
<t>The receiver-side algorithm can be outlined as below:</t>
<t><figure>
<artwork><![CDATA[
On initialization:
set d_base = +INFINITY
set p_loss = 0
set p_mark = 0
set r_recv = 0
set both t_last and t_curr as current time
On receiving a media packet:
obtain current timestamp t_curr
obtain from packet header sending time stamp t_sent
obtain one-way delay measurement: d_fwd = t_curr - t_sent
update baseline delay: d_base = min(d_base, d_fwd)
update queuing delay: d_n = d_fwd - d_base
update packet loss ratio estimate p_loss
update packet marking ratio estimate p_mark
update measurement of receiving rate r_recv
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 aggregate congestion signal x_n
determine mode of rate adaptation for sender: rmode
send RTCP feedback report containing values of: rmode, x_n, and r_recv
update t_last = t_curr
]]></artwork>
</figure>
</t>
<t>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 distinguish between different levels of
observed queuing delay. For instance, a moderate queuing
delay value below 100ms is likely self-inflicted or induced
by other delay-based flows, whereas a high queuing delay
value of several hundreds of milliseconds may indicate the
presence of a loss-based flow that does not refrain from
increased delay. </t>
<t>When packet losses are observed, the estimated queuing
delay follows a non-linear warping inspired by the
delay-adaptive congestion window backoff policy in
<xref target="Budzisz-TON11"></xref>: </t>
<t><figure>
<artwork><![CDATA[
/ d_n, if d_n<QTH;
|
| (QMAX - d_n)^4
d_tilde = < QTH ----------------, if QTH<d_n<QMAX (1)
| (QMAX - QTH)^4
|
\ 0, otherwise.
]]></artwork>
</figure></t>
<t>
Here, the queuing delay value is unchanged when
it is below the first threshold QTH; it is
scaled down following a non-linear curve when
its value falls between QTH and QMAX;
above QMAX, the high queuing delay value no
longer counts toward congestion control. </t>
<t>The aggregate congestion signal is:</t>
<t><figure>
<artwork><![CDATA[
x_n = d_tilde + p_mark*DMARK + p_loss*DLOSS. (2)
]]></artwork>
</figure></t>
<t>Here, DMARK is prescribed delay penalty associated
with ECN markings and DLOSS is prescribed delay penalty
associated with packet losses. The value of DLOSS and
DMARK does not depend on configurations at the network
node, but does assume that ECN markings, when available,
occur before losses. Furthermore, the values of DLOSS
and DMARK need to be set consistently across all NADA
flows for them to compete fairly.</t>
<t>In the absence of packet marking and losses,
the value of x_n reduces to the observed queuing
delay d_n. In that case the NADA algorithm operates
in the regime of delay-based adaptation.
</t>
<t>Given observed per-packet delay and loss information,
the receiver is also in a good position to determine
whether the network is underutilized and recommend the
corresponding rate adaptation mode for the sender. The
criteria for operating in accelerated ramp-up mode are:</t>
<t><list style="symbols">
<t> No recent packet losses within the observation window LOGWIN; and</t>
<t> No build-up of queuing delay: d_fwd-d_base < QEPS for all
previous delay samples within the observation window LOGWIN.</t>
</list></t>
<t>Otherwise the algorithm operates in graduate update mode. </t>
</section>
<section anchor = "subsec-sender-algorithm"
title = "Sender-Side Algorithm">
<t>The sender-side algorithm is outlined as follows:</t>
<t><figure>
<artwork><![CDATA[
on initialization:
set r_n = RMIN
set rtt = 0
set x_prev = 0
set t_last and t_curr as current time
on receiving feedback report:
obtain current timestamp: t_curr
obtain values of rmode, x_n, and r_recv from feedback report
update estimation of rtt
measure feedback interval: delta = t_curr - t_last
if rmode == 0:
update r_n following accelerated ramp-up rules
else:
update r_n following gradual update rules
clip rate r_n within the range of [RMIN, RMAX]
x_prev = x_n
t_last = t_curr ]]></artwork>
</figure></t>
<t>In accelerated ramp-up mode, the rate r_n is updated as follows:</t>
<t><figure>
<artwork><![CDATA[
QBOUND
gamma = min(GAMMA_MAX, -----------) (3)
rtt+DELTA
r_n = (1+gamma) r_recv (4)
]]></artwork>
</figure></t>
<t>The rate increase multiplier gamma
is calculated as a function of upper bound of
self-inflicted queuing delay (QBOUND), round-trip-time (rtt),
and target feedback interval DELTA. It has a maximum value
of GAMMA_MAX. The rationale behind (3)-(4) is that
the longer it takes for the sender to observe self-inflicted
queuing delay build-up, the more conservative the sender
should be in increasing its rate, hence the smaller the
rate increase multiplier. </t>
<t>In gradual update mode, the rate r_n is updated as:</t>
<t><figure><artwork><![CDATA[
x_offset = x_n - PRIO*X_REF*RMAX/r_n (5)
x_diff = x_n - x_prev (6)
delta x_offset
r_n = r_n - KAPPA*-------*------------*r_n
TAU TAU
x_diff
- KAPPA*ETA*---------*r_n (7)
TAU
]]></artwork></figure></t>
<t>The rate changes in proportion to the previous rate decision.
It is affected by two terms: offset of the aggregate congestion
signal from its value at equilibrium (x_offset) and its change
(x_diff). Calculation of x_offset depends on maximum rate
of the flow (RMAX), its weight of priority (PRIO), as well
as a reference congestion signal (X_REF). The value of
X_REF is chosen that the maximum rate of RMAX can be achieved
when the observed congestion signal level is below PRIO*X_REF.
</t>
<t>
At equilibrium, the aggregated congestion signal stablizes at
x_n = PRIO*X_REF*RMAX/r_n. This ensures that when multiple flows
share the same bottleneck and observe a common value of x_n,
their rates at equilibrium will be proportional to their
respective priority levels (PRIO) and maximum rate (RMAX).
</t>
<t> As mentioned in the sender-side algorithm, the final rate
is clipped within the dynamic range specified by the application: </t>
<t><figure><artwork><![CDATA[
r_n = min(r_n, RMAX) (8)
r_n = max(r_n, RMIN) (9) ]]></artwork></figure></t>
<t>The above operations ignore many practical issues such as clock
synchronization between sender and receiver, filtering of noise in
delay measurements, and base delay expiration. These will be addressed
in later sections describing practical implementation of the
NADA algorithm. </t>
</section>
</section>
<section anchor="sec-practical-nada"
title = "Practical Implementation of NADA">
<section anchor="sec-receiver"
title="Receiver-Side Operation">
<t>The receiver continuously monitors end-to-end per-packet
statistics in terms of delay, loss, and/or ECN marking ratios.
It then aggregates all forms of congestion indicators into the
form of an equivalent delay and periodically reports this back
to the sender. In addition, the receiver tracks the receiving
rate of the flow and includes that in the feedback message.</t>
<section anchor="sec-receiver-a"
title="Estimation of one-way delay and queuing delay">
<t>
The delay estimation process in NADA follows a similar approach
as in earlier delay-based congestion control schemes, such as
<xref target="RFC6817">LEDBAT</xref>. NADA estimates the forward
delay as having a constant base delay component plus a time
varying queuing delay component. The base delay is estimated as
the minimum value of one-way delay observed over a relatively
long period (e.g., tens of minutes), whereas the individual
queuing delay value is taken to be the difference between one-way
delay and base delay.
</t>
<t>
The individual sample values of queuing delay should be further
filtered against various non-congestion-induced noise, such as
spikes due to processing "hiccup" at the network nodes. Current
implementation employs a 15-tab minimum filter over per-packet
queuing delay estimates. </t>
</section>
<section anchor="sec-receiver-b"
title="Estimation of packet loss/marking ratio">
<t>The receiver detects packet losses via gaps in the
RTP sequence numbers of received packets. Packets arriving
out-of-order are discarded, and count towards losses.
The instantaneous packet loss ratio p_inst is estimated
as the ratio between the number of missing packets over
the number of total transmitted packets within the
recent observation window LOGWIN. The packet loss ratio
p_loss is obtained after exponential smoothing: </t>
<t><figure>
<artwork><![CDATA[
p_loss = ALPHA*p_inst + (1-ALPHA)*p_loss. (10)
]]></artwork>
</figure></t>
<t>The filtered result is reported back to the sender as
the observed packet loss ratio p_loss. </t>
<t>
Estimation of packet marking ratio p_mark follows
the same procedure as above. It is assumed that ECN
marking information at the IP header can be passed
to the transport layer by the receiving endpoint. </t>
</section>
<section anchor = "sec-receiver-c"
title = "Estimation of receiving rate">
<t>
It is fairly straighforward to estimate the receiving
rate r_recv. NADA maintains a recent observation
window with time span of LOGWIN, and simply divides
the total size of packets arriving during that window
over the time span. The receiving rate (r_recv) is
included as part of the feedback report.
</t>
</section>
</section>
<section anchor="sec-sender"
title="Sender-Side Operation">
<t>
<xref target="fig-nada-sender"></xref> provides a detailed
view of the NADA sender. Upon receipt of an RTCP feedback
report from the receiver, the NADA sender calculates the
reference rate r_n as specified in
<xref target="subsec-sender-algorithm"></xref>.
It further adjusts both the target rate for the live video
encoder r_vin and the sending rate r_send over the network
based on the updated value of r_n and rate shaping buffer
occupancy buffer_len.
</t>
<t>
The NADA sender behavior stays the same in the presence
of all types of congestion indicators: delay, loss, and
ECN marking. This unified approach allows a graceful
transition of the scheme as the network shifts dynamically
between light and heavy congestion levels.
</t>
<t><figure anchor="fig-nada-sender"
title="NADA Sender Structure">
<artwork><![CDATA[
+----------------+
| Calculate | <---- RTCP report
| Reference Rate |
-----------------+
| r_n
+------------+-------------+
| |
\|/ \|/
+-----------------+ +---------------+
| Calculate Video | | Calculate |
| Target Rate | | Sending Rate |
+-----------------+ +---------------+
| /|\ /|\ |
r_vin | | | |
\|/ +-------------------+ |
+----------+ | buffer_len | r_send
| Video | r_vout -----------+ \|/
| Encoder |--------> |||||||||=================>
+----------+ -----------+ RTP packets
Rate Shaping Buffer
]]></artwork></figure></t>
<section anchor = "sec-sender-c"
title = "Rate shaping buffer">
<t>
The operation of the live video encoder is out of the scope
of the design for the congestion control scheme in NADA.
Instead, its behavior is treated as a black box.
</t>
<t>
A rate shaping buffer is employed to absorb any instantaneous
mismatch between encoder rate output r_vout and regulated sending
rate r_send. Its current level of occupancy is measured in bytes
and is denoted as buffer_len.
</t>
<t>A large rate shaping buffer contributes to higher
end-to-end delay, which may harm the performance of
real-time media communications. Therefore, the sender
has a strong incentive to prevent the rate shaping
buffer from building up. The mechanisms adopted are:
</t>
<t><list style="symbols">
<t>To deplete the rate shaping buffer faster by
increasing the sending rate r_send; and </t>
<t>To limit incoming packets of the rate shaping
buffer by reducing the video encoder target rate
r_vin. </t>
</list></t>
</section>
<section anchor = "sec-sender-d"
title = "Adjusting video target rate and sending rate">
<t>
The target rate for the live video encoder deviates
from the network congestion control rate r_n based
on the level of occupancy in the rate shaping buffer:
</t>
<t><figure><artwork><![CDATA[
r_vin = r_n - BETA_V*8*buffer_len*FPS. (11)
]]></artwork></figure></t>
<t>
The actual sending rate r_send is regulated in a
similar fashion: </t>
<t><figure><artwork><![CDATA[
r_send = r_n + BETA_S*8*buffer_len*FPS. (12)
]]></artwork></figure></t>
<t>
In (11) and (12), the first term indicates the rate calculated
from network congestion feedback alone. The second term
indicates the influence of the rate shaping buffer. A large
rate shaping buffer nudges the encoder target rate slightly
below -- and the sending rate slightly above -- the reference
rate r_n.
</t>
<t>
Intuitively, the amount of extra rate offset needed to completely
drain the rate shaping buffer within the duration of a single
video frame is given by 8*buffer_len*FPS, where FPS stands
for the frame rate of the video. The scaling parameters
BETA_V and BETA_S can be tuned to balance between the competing
goals of maintaining a small rate shaping buffer and deviating
the system from the reference rate point.
</t>
</section>
</section>
</section>
<section anchor = "sec-discussions"
title = "Discussions and Further Investigations">
<section anchor = "sec-discussion-a"
title = "Choice of delay metrics">
<t>
The current design works with relative one-way-delay (OWD)
as the main indication of congestion. The value of the relative
OWD is obtained by maintaining the minimum value of observed
OWD over a relatively long time horizon and subtract that out
from the observed absolute OWD value. Such an approach cancels
out the fixed difference between the sender and receiver clocks.
It has been widely adopted by other delay-based congestion
control approaches such as <xref target="RFC6817"></xref>.
As discussed in <xref target="RFC6817"></xref>, the time horizon
for tracking the minimum OWD needs to be chosen with care: it must
be long enough for an opportunity to observe the minimum OWD with
zero queuing delay along the path, and sufficiently short so as to
timely reflect "true" changes in minimum OWD introduced by route
changes and other rare events.
</t>
<t>
The potential drawback in relying on relative OWD as the congestion
signal is that when multiple flows share the same bottleneck, the
flow arriving late at the network experiencing a non-empty queue may
mistakenly consider the standing queuing delay as part of the fixed
path propagation delay. This will lead to slightly unfair bandwidth
sharing among the flows.
</t>
<t>Alternatively, one could move the per-packet statistical handling
to the sender instead and use relative round-trip-time (RTT) in lieu
of relative OWD, assuming that per-packet acknowledgements are available.
The main drawback of RTT-based approach is the noise in the measured delay
in the reverse direction.
</t>
<t>
Note that the choice of either delay metric (relative OWD vs. RTT)
involves no change in the proposed rate adaptation algorithm.
Therefore, comparing the pros and cons regarding which delay metric
to adopt can be kept as an orthogonal direction of investigation.
</t>
</section>
<section anchor="sec-discussion-b"
title = "Method for delay, loss, and marking ratio estimation">
<t>Like other delay-based congestion control schemes,
performance of NADA depends on the accuracy of its
delay measurement and estimation module. Appendix A
in <xref target = "RFC6817"></xref> provides an
extensive discussion on this aspect.
</t>
<t>The current recommended practice of simply applying a
15-tab minimum filter suffices in guarding against processing
delay outliers observed in wired connections. For wireless
connections with a higher packet delay variation (PDV),
more sophisticated techniques on de-noising, outlier rejection,
and trend analysis may be needed. </t>
<t>
More sophisticated methods in packet loss ratio calculation,
such as that adopted by <xref target="Floyd-CCR00"></xref>,
will likely be beneficial. These alternatives are currently
under investigation. </t>
</section>
<section anchor = "sec-discussion-c"
title = "Impact of parameter values">
<t>In the gradual rate update mode, the parameter TAU indicates
the upper bound of round-trip-time (RTT) in feedback control loop.
Typically, the observed feedback interval delta is close to the
target feedback interval DELTA, and the relative ratio of delta/TAU
versus ETA dictates the relative strength of influence from the
aggregate congestion signal offset term (x_offset) versus its recent
change (x_diff), respectively. These two terms are analogous to
the integral and proportional terms in a proportional-integral (PI)
controller. The recommended choice of TAU=500ms, DELTA=100ms and
ETA = 2.0 corresponds to a relative ratio of 1:10 between the gains
of the integral and proportional terms. Consequently, the rate
adaptation is mostly driven by the change in the congestion signal
with a long-term shift towards its equilibrium value driven by the
offset term. Finally, the scaling parameter KAPPA determines the
overall speed of the adaptation and needs to strike a balance
between responsiveness and stability.
</t>
<t>
The choice of the target feedback interval DELTA needs to strike
the right balance between timely feedback and low RTCP feedback
message counts. A target feedback interval of DELTA=100ms is
recommended, corresponding to a feedback bandwidth of 16Kbps
with 200 bytes per feedback message --- less than 0.1% overhead
for a 1 Mbps flow. Furthermore, both simulation studies and
frequency-domain analysis have established that a feedback
interval below 250ms will not break up the feedback control
loop of NADA congestion control. </t>
<t>In calculating the non-linear warping of delay in (1),
the current design uses fixed values of QTH and QMAX.
It is possible to adapt the value of both based on
past observations of queuing delay in the presence
of packet losses. </t>
<t>In calculating the aggregate congestion signal x_n, the
choice of DMARK and DLOSS influence the steady-state packet
loss/marking ratio experienced by the flow at a given
available bandwidth. Higher values of DMARK and DLOSS result
in lower steady-state loss/marking ratios, but are more
susceptible to the impact of individual packet loss/marking
events. While the value of DMARK and DLOSS are fixed and
predetermined in the current design, a scheme for automatically
tuning these values based on desired bandwidth sharing behavior
in the presence of other competing loss-based flows (e.g.,
loss-based TCP) is under investigation.</t>
<t>[Editor's note: Choice of start value: is this
in scope of congestion control, or should this be
decided by the application?] </t>
</section>
<section anchor="sec-discussion-d"
title = "Sender-based vs. receiver-based calculation">
<t>In the current design, the aggregated congestion
signal x_n is calculated at the receiver, keeping
the sender operation completely independent of the
form of actual network congestion indications (delay,
loss, or marking). Alternatively, one can move the logics
of (1) and (2) to the sender. Such an approach requires slightly
higher overhead in the feedback messages, which should
contain individual fields on queuing delay (d_n),
packet loss ratio (p_loss), packet marking ratio
(p_mark), receiving rate (r_recv), and recommended
rate adaptation mode (rmode). </t>
</section>
<section anchor = "sec-discussion-e"
title = "Incremental deployment">
<t>
One nice property of NADA is the consistent video endpoint
behavior irrespective of network node variations. This facilitates
gradual, incremental adoption of the scheme.
</t>
<t>
To start off with, the proposed congestion control mechanism can
be implemented without any explicit support from the network, and
relies solely on observed one-way delay measurements and packet
loss ratios as implicit congestion signals.
</t>
<t>
When ECN is enabled at the network nodes with RED-based marking,
the receiver can fold its observations of ECN markings into the
calculation of the equivalent delay. The sender can react to these
explicit congestion signals without any modification.
</t>
<t>
Ultimately, networks equipped with proactive marking based on
token bucket level metering can reap the additional benefits of
zero standing queues and lower end-to-end delay and work
seamlessly with existing senders and receivers.
</t>
</section>
</section>
<section anchor = "sec-implementation"
title ="Implementation Status">
<t>
The NADA scheme has been implemented in <xref target="ns-2"></xref>
and <xref target="ns-3"></xref> simulation platforms. Extensive ns-2
simulation evaluations of an earlier version of the draft are
documented in <xref target="Zhu-PV13"></xref>. Evaluation results
of the current draft over several test cases in
<xref target="I-D.ietf-rmcat-eval-test"></xref> have
been presented at recent IETF meetings
<xref target="IETF-90"></xref><xref target="IETF-91"></xref>.
</t>
<t>
The scheme has also been implemented and evaluated in a lab
setting as described in <xref target="IETF-90"></xref>.
Preliminary evaluation results of NADA in single-flow
and multi-flow scenarios have been presented in
<xref target="IETF-91"></xref>.</t>
</section>
<section anchor = "sec-iana"
title = "IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor = "sec-acknowledgements"
title = "Acknowledgements">
<t>
The authors would like to thank Randell Jesup, Luca De Cicco, Piers O'Hanlon,
Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, Safiqul Islam,
Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for their valuable questions
and comments on earlier versions of this draft.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119; <!-- RFCs -->
&rfc3168; <!-- ECN -->
&rfc3550; <!-- RTP -->
<!--RMCAT related -->
&I-D.ietf-rmcat-eval-criteria;
&I-D.ietf-rmcat-eval-test;
&I-D.ietf-rmcat-cc-requirements;
</references>
<references title="Informative References">
&rfc2309; <!-- RED -->
&rfc5348; <!-- TFRC -->
&rfc6660; <!-- PCN -->
&rfc6817; <!-- LEDBAT -->
<reference anchor="Floyd-CCR00"
target="">
<front>
<title>
Equation-based Congestion Control for Unicast Applications
</title>
<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization></organization>
</author>
<author fullname="Mark Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="Jitendra Padhye" initials="J." surname="Padhye">
<organization></organization>
</author>
<author fullname="Jorg Widmer" initials="J." surname="Widmer">
<organization></organization>
</author>
<date month="October" year="2000" />
</front>
<seriesInfo name="ACM SIGCOMM Computer Communications Review"
value="vol. 30, no. 4, pp. 43-56"/>
</reference>
<reference anchor="Budzisz-TON11"
target="">
<front>
<title>
On the Fair Coexistence of Loss- and Delay-Based TCP
</title>
<author fullname="Lukasz Budzisz" initials="L." surname="Budzisz">
<organization></organization>
</author>
<author fullname="Rade Stanojevic" initials="R." surname="Stanojevic">
<organization></organization>
</author>
<author fullname="Arieh Schlote" initials="A." surname="Schlote">
<organization></organization>
</author>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization></organization>
</author>
<author fullname="Robert Shorten" initials="R." surname="Shorten">
<organization></organization>
</author>
<date month="December" year="2011" />
</front>
<seriesInfo name="IEEE/ACM Transactions on Networking"
value="vol. 19, no. 6, pp. 1811-1824"/>
</reference>
<reference anchor="Zhu-PV13"
target="">
<front>
<title>
NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Video
</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization></organization>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization></organization>
</author>
<date month="December" year="2013" />
</front>
<seriesInfo name="in Proc. IEEE International Packet Video Workshop (PV'13)"
value="San Jose, CA, USA"/>
</reference>
<reference anchor="ns-2" target="http://www.isi.edu/nsnam/ns/">
<front>
<title>The Network Simulator - ns-2</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="ns-3" target="https://www.nsnam.org/">
<front>
<title>The Network Simulator - ns-3</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="IETF-90"
target="https://tools.ietf.org/agenda/90/slides/slides-90-rmcat-6.pdf">
<front>
<title>NADA Update: Algorithm, Implementation, and Test Case Evalua6on Results</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization></organization>
</author>
<author fullname="Michael Ramalho" initials="M." surname="Ramalho">
<organization></organization>
</author>
<author fullname="Charles Ganzhorn" initials="C." surname="Ganzhorn">
<organization></organization>
</author>
<author fullname="Paul E. Jones" initials="P. E." surname="Jones">
<organization></organization>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization></organization>
</author>
<date month= "July" year = "2014"/>
</front>
</reference>
<reference anchor="IETF-91"
target="http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/slides/slides-interim-2014-rmcat-1-2.pdf">
<front>
<title>NADA Algorithm Update and Test Case Evaluations</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization></organization>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization></organization>
</author>
<author fullname="Michael Ramalho" initials="M." surname="Ramalho">
<organization></organization>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena">
<organization></organization>
</author>
<author fullname="Charles Ganzhorn" initials="C." surname="Ganzhorn">
<organization></organization>
</author>
<author fullname="Paul E. Jones" initials="P. E." surname="Jones">
<organization></organization>
</author>
<author fullname="Stefano D'Aronco" initials="S." surname="D'Aronco">
<organization></organization>
</author>
<date month= "November" year = "2014"/>
</front>
</reference>
</references>
<section anchor="sec-network-nodes"
title="Network Node Operations">
<t>NADA can work with different network queue management
schemes and does not assume any specific network node operation.
As an example, this appendix describes three variants of queue
management behavior at the network node, leading to either
implicit or explicit congestion signals. </t>
<t>
In all three flavors described below, the network queue
operates with 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 number of video flows and
at high link capacity.
</t>
<section anchor="sec-network-droptail"
title="Default behavior of drop tail queues">
<t>
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. Packet drops at the queue are
detected at the receiver, and contributes to the calculation
of the aggregated congestion signal x_n. No special
action is required at network node.
</t>
</section>
<section anchor="sec-network-ecn"
title="RED-based ECN marking">
<t>In this mode, the network node randomly marks
the ECN field in the IP packet header following
the <xref target="RFC2309">Random Early Detection
(RED) algorithm</xref>. Calculation of the marking
probability involves the following steps:</t>
<t><figure><artwork><![CDATA[
on packet arrival:
update smoothed queue size q_avg as:
q_avg = w*q + (1-w)*q_avg.
calculate marking probability p as:
/ 0, if q < q_lo;
|
| q_avg - q_lo
p= < p_max*--------------, if q_lo <= q < q_hi;
| q_hi - q_lo
|
\ p = 1, if q >= q_hi.
]]></artwork></figure></t>
<t>
Here, q_lo and q_hi corresponds to the low
and high thresholds of queue occupancy.
The maximum marking probability is p_max.
</t>
<t>
The ECN markings events will contribute
to the calculation of an equivalent delay
x_n at the receiver. No changes are required
at the sender.
</t>
</section>
<section anchor = "sec-network-pcn"
title = "Random Early Marking with Virtual Queues">
<t>
Advanced network nodes may support random early marking
based on a token bucket algorithm originally designed for
<xref target="RFC6660">Pre-Congestion Notification (PCN)</xref>.
The early congestion notification (ECN) bit in the
IP header of packets are marked randomly.
The marking probability is calculated based on a
token-bucket algorithm originally designed for the
<xref target="RFC6660">Pre-Congestion Notification (PCN)</xref>.
The target link utilization is set as 90%; the marking
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.</t>
<t>
* upon packet arrival, meter packet against token bucket (r,b);
</t>
<t>
* update token level b_tk;
</t>
<t>* calculate the marking probability as:</t>
<t><figure><artwork><![CDATA[
/ 0, if b-b_tk < b_lo;
|
| b-b_tk-b_lo
p = < p_max* --------------, if b_lo<= b-b_tk <b_hi;
| b_hi-b_lo
|
\ 1, if b-b_tk>=b_hi.
]]></artwork>
</figure></t>
<t>
Here, the token bucket lower and upper limits are denoted by
b_lo and b_hi, respectively. The parameter b indicates the size
of the token bucket. The parameter r is chosen to be below
capacity, resulting in slight under-utilization of the link.
The maximum marking probability is p_max.
</t>
<t>The ECN markings events will contribute to the calculation
of an equivalent delay x_n at the receiver. No changes are
required at the sender. The virtual queuing mechanism from
the PCN-based marking algorithm will lead to additional
benefits such as zero standing queues.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:38:29 |