rfc8698xml2.original.xml   rfc8698.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml"> <rfc number="8698" xmlns:xi="http://www.w3.org/2001/XInclude" category="exp"
<!ENTITY rfc3168 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen docName="draft-ietf-rmcat-nada-13" ipr="trust200902" obsoletes=""
ce.RFC.3168.xml"> updates="" submissionType="IETF" consensus="true" xml:lang="en"
<!ENTITY rfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen tocInclude="true"
ce.RFC.3550.xml"> sortRefs="true" symRefs="true" version="3">
<!ENTITY rfc5348 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5348.xml">
<!ENTITY rfc5450 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5450.xml">
<!ENTITY rfc6660 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6660.xml">
<!ENTITY rfc6679 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6679.xml">
<!ENTITY rfc6817 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6817.xml">
<!ENTITY rfc7567 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7567.xml">
<!ENTITY rfc8033 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8033.xml">
<!ENTITY rfc8290 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8290.xml">
<!ENTITY rfc8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY rfc8593 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8593.xml">
<!ENTITY I-D.ietf-avtcore-cc-feedback-message SYSTEM "http://xml2rfc.tools.ietf.
org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-cc-feedback-message.xml">
<!ENTITY I-D.ietf-rmcat-cc-requirements SYSTEM "http://xml2rfc.tools.ietf.org/pu
blic/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-requirements.xml">
<!ENTITY I-D.ietf-rmcat-eval-test SYSTEM "http://xml2rfc.tools.ietf.org/public/r
fc/bibxml3/reference.I-D.ietf-rmcat-eval-test.xml">
<!ENTITY I-D.ietf-rmcat-wireless-tests SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml3/reference.I-D.ietf-rmcat-wireless-tests.xml">
<!ENTITY I-D.ietf-rmcat-cc-codec-interactions SYSTEM "http://xml2rfc.tools.ietf.
org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-codec-interactions.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-13"
ipr="trust200902">
<!-- What is the category field value-->
<front> <front>
<title abbrev="NADA"> <title abbrev="NADA">
NADA: A Unified Congestion Control Scheme for Real-Time Media Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control
Scheme for Real-Time Media
</title> </title>
<seriesInfo name="RFC" value="8698"/>
<author fullname="Xiaoqing Zhu" initials="X" surname="Zhu"> <author fullname="Xiaoqing Zhu" initials="X" surname="Zhu">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>12515 Research Blvd., Building 4</street> <street>12515 Research Blvd., Building 4</street>
<city>Austin</city> <city>Austin</city>
<region>TX</region> <region>TX</region>
<code>78759</code> <code>78759</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>xiaoqzhu@cisco.com</email> <email>xiaoqzhu@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Rong Pan *" initials="R" surname="Pan"> <author fullname="Rong Pan" initials="R" surname="Pan">
<organization abbrev="Cisco Systems">* Pending affiliation change.</organi <organization>Intel Corporation</organization>
zation>
<address> <address>
<email>rong.pan@gmail.com</email> <postal>
<street>2200 Mission College Blvd
</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>United States of America</country>
</postal>
<email>rong.pan@intel.com</email>
</address> </address>
</author> </author>
<author fullname="Michael A. Ramalho" initials="M. A." surname="Ramalho"> <author fullname="Michael A. Ramalho" initials="M." surname="Ramalho">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization> <organization abbrev="AcousticComms">AcousticComms
Consulting</organization>
<address> <address>
<postal> <postal>
<street>8000 Hawkins Road</street> <street>6310 Watercrest Way Unit 203</street>
<city>Sarasota</city> <city>Lakewood Ranch</city>
<region>FL</region> <region>FL</region>
<code>34241</code> <code>34202-5211</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 919 476 2038</phone> <phone>+1 732 832 9723</phone>
<email>mar42@cornell.edu</email> <email>mar42@cornell.edu</email>
<uri>http://ramalho.webhop.info/</uri>
</address> </address>
</author> </author>
<author fullname="Sergio Mena de la Cruz" initials="S. " surname="Mena"> <author fullname="Sergio Mena" initials="S. " surname="Mena">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>EPFL, Quartier de l'Innovation, Batiment E</street> <street>EPFL, Quartier de l'Innovation, Batiment E</street>
<city>Ecublens</city> <city>Ecublens</city>
<region>Vaud</region> <region>Vaud</region>
<code>1015</code> <code>1015</code>
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<email>semena@cisco.com</email> <email>semena@cisco.com</email>
</address> </address>
</author> </author>
<!-- <date month="February" year="2020"/>
<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="ETH">ETH Zurich</organization>
<address>
<postal>
<street>Stefano-Franscini-Platz 5</street>
<city>Zurich</city>
<region></region>
<code>8093</code>
<country>Switzerland</country>
</postal>
<email>stefano.daronco@geod.baug.ethz.ch</email>
</address>
</author>
-->
<date year="2019" />
<area>TSV</area> <area>TSV</area>
<keyword>Multimedia</keyword> <keyword>Multimedia</keyword>
<keyword>Congestion Control</keyword> <keyword>Congestion Control</keyword>
<abstract> <abstract>
<t>This document describes NADA (network-assisted dynamic adaptation), <t>This document describes Network-Assisted Dynamic Adaptation (NADA), a
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, the applications such as video conferencing. In the proposed scheme, the
sender regulates its sending rate based on either implicit or sender regulates its sending rate, based on either implicit or explicit
explicit congestion signaling, in a unified approach. The scheme can congestion signaling, in a unified approach. The scheme can benefit from
benefit from explicit congestion notification (ECN) markings from Explicit Congestion Notification (ECN) markings from network nodes. It
network nodes. It also maintains consistent sender behavior in the also maintains consistent sender behavior in the absence of such
absence of such markings, by reacting to queuing delays and packet markings by reacting to queuing delays and packet losses instead. </t>
losses instead. </t> </abstract>
</abstract> </front>
<middle>
</front> <section anchor="sec-intro" numbered="true" toc="default">
<name>Introduction</name>
<middle> <t>Interactive real-time media applications introduce a unique set of
<section anchor="sec-intro" title="Introduction"> 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" format="default"/>
markings. The requirements for the congestion control algorithm are
outlined in <xref target="I-D.ietf-rmcat-cc-requirements"
format="default"/>.
<t>Interactive real-time media applications introduce a unique set of The requirements highlight that the desired congestion control scheme
challenges for congestion control. Unlike TCP, the mechanism used for should 1) avoid flow starvation and attain a reasonable fair share of
real-time media needs to adapt quickly to instantaneous bandwidth changes, bandwidth when competing against other flows, 2) adapt quickly, and 3)
accommodate fluctuations in the output of video encoder rate control, operate in a stable manner. </t>
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>.
It highlights that the desired congestion control scheme should avoid
flow starvation and attain a reasonable fair share of bandwidth when
competing against other flows, adapt quickly, and operate in a stable
manner. </t>
<t>This document describes an experimental congestion control scheme <t>This document describes an experimental congestion control scheme
called network-assisted dynamic adaptation (NADA). The design of NADA called Network-Assisted Dynamic Adaptation (NADA). The design of NADA
benefits from explicit congestion control signals (e.g., ECN markings) benefits from explicit congestion control signals (e.g., ECN markings)
from the network, yet also operates when only implicit congestion from the network, yet also operates when only implicit congestion
indicators (delay and/or loss) are available. Such a unified sender indicators (delay and/or loss) are available. Such a unified sender
behavior distinguishes NADA from other congestion control schemes for behavior distinguishes NADA from other congestion control schemes for
real-time media. In addition, its core congestion control algorithm is real-time media. In addition, its core congestion control algorithm is
designed to guarantee stability for path round-trip-times (RTTs) below designed to guarantee stability for path round-trip times (RTTs) below
a prescribed bound (e.g., 250ms with default parameter choices). It a prescribed bound (e.g., 250 ms with default parameter choices). It
further supports weighted bandwidth sharing among competing video flows further supports weighted bandwidth sharing among competing video flows
with different priorities. The signaling mechanism consists of standard with different priorities. The signaling mechanism consists of standard
RTP timestamp <xref target="RFC3550"></xref> and RTCP feedback reports. Real-time Transport Protocol (RTP) timestamp <xref target="RFC3550"
format="default"/> and Real-time
Transport Control Protocol (RTCP) feedback reports.
The definition of the desired RTCP feedback message is described in The definition of the desired RTCP feedback message is described in
detail in <xref target="I-D.ietf-avtcore-cc-feedback-message"></xref> detail in <xref target="I-D.ietf-avtcore-cc-feedback-message"
format="default"/>
so as to support the successful operation of several congestion control so as to support the successful operation of several congestion control
schemes for real-time interactive media. </t> schemes for real-time interactive media. </t>
</section> </section>
<section anchor="sec-term" title="Terminology"> <section anchor="sec-term" numbered="true" toc="default">
<name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="sec-system-overview" <t>
title="System Overview"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<t><xref target="fig-system-overview"></xref> shows the end-to-end </section>
<section anchor="sec-system-overview" numbered="true" toc="default">
<name>System Overview</name>
<t><xref target="fig-system-overview" format="default"/> shows the
end-to-end
system for real-time media transport that NADA operates in. Note that system for real-time media transport that NADA operates in. Note that
there also exist network nodes along the reverse (potentially uncongested) there also exist network nodes along the reverse (potentially uncongested)
path that the RTCP feedback reports traverse. Those network nodes are not path that the RTCP feedback reports traverse. Those network nodes are not
shown in the figure for sake of brevity.</t> shown in the figure for the sake of brevity.</t>
<t><figure anchor="fig-system-overview"
title="System Overview">
<artwork><![CDATA[
<figure anchor="fig-system-overview">
<name>System Overview</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------+ 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
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t><list style="symbols"> <dl>
<t>Media encoder with rate control capabilities. It encodes raw media
(audio and video) frames into a compressed bitstream which is later
packetized into RTP packets. As discussed in <xref target="RFC8593"></xref>,
the actual output rate from the encoder r_vout may fluctuate around
the target r_vin. Furthermore, it is possible that the encoder can
only react to bit rate changes at rather coarse time intervals, e.g.,
once every 0.5 seconds. </t>
<t> RTP sender: responsible for calculating the NADA reference <dt>Media encoder with rate control capabilities:
rate based on network congestion indicators (delay, loss, or ECN </dt>
marking reports from the receiver), for updating the video encoder <dd>Encodes raw media (audio and video) frames into a compressed bitstream
with a new target rate r_vin, and for regulating the actual sending that is later packetized into RTP packets. As discussed in <xref
rate r_send accordingly. The RTP sender also generates a sending target="RFC8593"/>, the
timestamp for each outgoing packet. </t> actual output rate from the encoder r_vout may fluctuate around the target
r_vin. Furthermore, it is possible that the encoder can only react to bit rate
changes at rather coarse time intervals, e.g., once every 0.5 seconds.
</dd>
<t>RTP receiver: responsible for measuring and estimating <dt>RTP sender:
end-to-end delay (based on sender timestamp), packet loss </dt>
(based on RTP sequence number), ECN marking ratios (based <dd>Responsible for calculating the NADA reference rate based on network
on <xref target="RFC6679"></xref>), and receiving rate (r_recv) congestion indicators (delay, loss, or ECN marking reports from the receiver),
of the flow. It calculates the aggregated congestion signal for updating the video encoder with a new target rate r_vin and for
(x_curr) that accounts for queuing delay, ECN markings, and regulating the actual sending rate r_send accordingly. The RTP sender also
packet losses. The receiver also determines the mode for generates a sending timestamp for each outgoing packet.
sender rate adaptation (rmode) based on whether the flow has </dd>
encountered any standing non-zero congestion. The receiver
sends periodic RTCP reports back to the sender, containing
values of x_curr, rmode, and r_recv. </t>
<t> Network node with several modes of operation. The system <dt>RTP receiver:
can work with the default behavior of a simple drop tail queue. </dt>
It can also benefit from advanced AQM features such as <dd>Responsible for measuring and estimating end-to-end delay (based on sender
<xref target="RFC8033">PIE</xref>, <xref target="RFC8290">FQ-CoDel</xref>, timestamp), packet loss (based on RTP sequence number), ECN marking ratios
ECN marking based on <xref target="RFC7567">RED</xref>, and PCN (based on <xref target="RFC6679"/>), and receiving rate (r_recv) of the
marking using a token bucket algorithm (<xref target="RFC6660"></xref>). flow. It calculates
Note that network node operation is out of control for the design the aggregated congestion signal (x_curr) that accounts for queuing delay, ECN
of NADA. </t> markings, and packet losses. The receiver also 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_curr, rmode, and r_recv.
</dd>
</list></t> <dt>Network node with several modes of operation:
</dt>
<dd>The system can work with the default behavior of a simple drop-tail
queue. It can also benefit from advanced Active Queue Management (AQM)
features such as Proportional Integral Controller Enhanced <xref
target="RFC8033">(PIE)</xref>, Flow Queue Controlling Queue Delay <xref
target="RFC8290">(FQ-CoDel)</xref>, ECN
marking based on <xref target="RFC7567"> Random Early Detection (RED)</xref>,
and Pre-Congestion Notification (PCN) marking using a
token bucket algorithm <xref target="RFC6660"/>. Note that network node
operation is out of scope for the design of NADA.
</section> </dd>
<section anchor="sec-algorithm" </dl>
title="Core Congestion Control Algorithm">
<t>Like TCP-Friendly Rate Control (TFRC)<xref target="Floyd-CCR00"></xref> </section>
<xref target="RFC5348"></xref>, NADA is a rate-based congestion <section anchor="sec-algorithm" numbered="true" toc="default">
<name>Core Congestion Control Algorithm</name>
<t>Like TCP-Friendly Rate Control (TFRC) <xref target="FLOYD-CCR00"
format="default"/>
<xref target="RFC5348" format="default"/>, NADA is a rate-based
congestion
control algorithm. In its simplest form, the sender reacts to the control algorithm. In its simplest form, the sender reacts to the
collection of network congestion indicators in the form of an collection of network congestion indicators in the form of an
aggregated congestion signal, and operates in one of two modes: aggregated congestion signal and operates in one of two modes:
<list style="symbols"> </t>
<t>Accelerated ramp-up: when the bottleneck is deemed to <dl>
be underutilized, the rate increases multiplicatively with
respect to the rate of previously successful transmissions.
The rate increase multiplier (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 <dt>Accelerated ramp up:
congestion signal, the sending rate is adjusted in reaction to </dt>
both its value (x_curr) and its change in value (x_diff).</t> <dd>When the bottleneck is deemed to be underutilized, the rate increases
</list> multiplicatively with respect to the rate of previously successful
transmissions. The rate increase multiplier (gamma) is calculated based on
the observed round-trip time and target feedback interval, so as to limit
self-inflicted queuing delay.
</dd>
</t> <dt>Gradual rate update:
</dt>
<dd>In the presence of a non-zero aggregate congestion signal, the sending
rate
is adjusted in reaction to both its value (x_curr) and its change in value
(x_diff).
</dd>
<t>This section introduces the list of mathematical notations and </dl>
<t>This section introduces the list of mathematical notations and
describes the core congestion control algorithm at the sender and describes the core congestion control algorithm at the sender and
receiver, respectively. Additional details on recommended practical receiver, respectively. Additional details on recommended practical
implementations are described in <xref target="sec-receiver"></xref> implementations are described in Sections <xref target="sec-receiver"
and <xref target="sec-sender"></xref>. </t> format="counter"/>
and <xref target="sec-sender" format="counter"/>. </t>
<section anchor="sec-notation" <section anchor="sec-notation" numbered="true" toc="default">
title = "Mathematical Notations"> <name>Mathematical Notations</name>
<t>This section summarizes the list of variables and parameters <t>This section summarizes the list of variables and parameters used
used in the NADA algorithm. <xref target="tab-parameters"></xref> in the NADA algorithm. <xref target="tab-parameters"
also includes the default values for choosing the algorithm format="default"/> also includes the default values for choosing the
parameters either to represent a typical setting in practical algorithm parameters to represent either a typical setting in
applications or based on theoretical and simulation studies. practical applications or a setting based on theoretical and
See <xref target="sec-discussion-c"></xref> for some of the simulation studies. See <xref target="sec-discussion-c"
discussions on the impact of parameter values. Additional studies format="default"/> for some of the discussions on the impact of
in real-world settings suggested in <xref target="sec-experiments"></xref> parameter values. Additional studies in real-world settings suggested
could gather further insight on how to choose and adapt these in <xref target="sec-experiments" format="default"/> could gather
parameter values in practical deployment.</t> further insight on how to choose and adapt these parameter values in
practical deployment.</t>
<t><figure anchor="tab-variables" <table align="left" anchor="tab-variables">
title ="List of variables."> <name>List of Variables</name>
<artwork><![CDATA[ <thead>
+--------------+-------------------------------------------------+ <tr>
| Notation | Variable Name | <th align='left'>Notation</th>
+--------------+-------------------------------------------------+ <th align='left'>Variable Name</th>
| t_curr | Current timestamp | </tr>
| t_last | Last time sending/receiving a feedback | </thead>
| delta | Observed interval between current and previous |
| | feedback reports: delta = t_curr-t_last |
| r_ref | 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_queue | Estimated queuing delay |
| d_tilde | Equivalent delay after non-linear warping |
| p_mark | Estimated packet ECN marking ratio |
| p_loss | Estimated packet loss ratio |
| x_curr | 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_curr - x_prev |
| rmode | Rate update mode: (0 = accelerated ramp-up; |
| | 1 = gradual update) |
| gamma | Rate increase multiplier in accelerated ramp-up |
| | mode |
| loss_int | Measured average loss interval in packet count |
| loss_exp | Threshold value for setting the last observed |
| | packet loss to expiration |
| rtt | Estimated round-trip-time at sender |
| buffer_len | Rate shaping buffer occupancy measured in bytes |
+--------------+-------------------------------------------------+
]]></artwork>
</figure></t>
<t><figure anchor="tab-parameters" <tbody>
title ="List of algorithm parameters and their default values.">
<artwork><![CDATA[ <tr>
+--------------+----------------------------------+----------------+ <td align="left">t_curr</td>
| Notation | Parameter Name | Default Value | <td align="left">Current timestamp</td>
+--------------+----------------------------------+----------------+ </tr>
| PRIO | Weight of priority of the flow | 1.0
| RMIN | Minimum rate of application | 150Kbps | <tr>
| | supported by media encoder | | <td align="left">t_last</td>
| RMAX | Maximum rate of application | 1.5Mbps | <td align="left">Last time sending/receiving a feedback message</td>
| | supported by media encoder | | </tr>
| XREF | Reference congestion level | 10ms |
| KAPPA | Scaling parameter for gradual | 0.5 | <tr>
| | rate update calculation | | <td align="left">delta</td>
| ETA | Scaling parameter for gradual | 2.0 | <td align="left">Observed interval between current and previous
| | rate update calculation | | feedback reports: delta = t_curr-t_last</td>
| TAU | Upper bound of RTT in gradual | 500ms | </tr>
| | rate update calculation | |
| DELTA | Target feedback interval | 100ms | <tr>
+..............+..................................+................+ <td align="left">r_ref</td>
| LOGWIN | Observation window in time for | 500ms | <td align="left">Reference rate based on network congestion</td>
| | calculating packet summary | | </tr>
| | statistics at receiver | |
| QEPS | Threshold for determining queuing| 10ms | <tr>
| | delay build up at receiver | | <td align="left">r_send</td>
| DFILT | Bound on filtering delay | 120ms | <td align="left">Sending rate</td>
| GAMMA_MAX | Upper bound on rate increase | 0.5 | </tr>
| | ratio for accelerated ramp-up | |
| QBOUND | Upper bound on self-inflicted | 50ms | <tr>
| | queuing delay during ramp up | | <td align="left">r_recv</td>
+..............+..................................+................+ <td align="left">Receiving rate</td>
| MULTILOSS | Multiplier for self-scaling the | 7.0 | </tr>
| | expiration threshold of the last | |
| | observed loss (loss_exp) based on| | <tr>
| | measured average loss interval | | <td align="left">r_vin</td>
| | (loss_int) | | <td align="left">Target rate for video encoder</td>
| QTH | Delay threshold for invoking | 50ms | </tr>
| | non-linear warping | |
| LAMBDA | Scaling parameter in the | 0.5 | <tr>
| | exponent of non-linear warping | | <td align="left">r_vout</td>
+..............+..................................+................+ <td align="left">Output rate from video encoder</td>
| PLRREF | Reference packet loss ratio | 0.01 | </tr>
| PMRREF | Reference packet marking ratio | 0.01 |
| DLOSS | Reference delay penalty for loss | 10ms | <tr>
| | when packet loss ratio is at | | <td align="left">d_base</td>
| | PLRREF | | <td align="left">Estimated baseline delay</td>
| DMARK | Reference delay penalty for ECN | 2ms | </tr>
| | marking when packet marking | |
| | is at PMRREF | | <tr>
+..............+..................................+................+ <td align="left">d_fwd</td>
| FPS | Frame rate of incoming video | 30 | <td align="left">Measured and filtered one-way delay</td>
| BETA_S | Scaling parameter for modulating | 0.1 | </tr>
| | outgoing sending rate | |
| BETA_V | Scaling parameter for modulating | 0.1 | <tr>
| | video encoder target rate | | <td align="left">d_queue</td>
| ALPHA | Smoothing factor in exponential | 0.1 | <td align="left">Estimated queuing delay</td>
| | smoothing of packet loss and | | </tr>
| | marking ratios |
+--------------+----------------------------------+----------------+ <tr>
]]></artwork> <td align="left">d_tilde</td>
</figure></t> <td align="left">Equivalent delay after non-linear warping</td>
</tr>
<tr>
<td align="left">p_mark</td>
<td align="left">Estimated packet ECN marking ratio</td>
</tr>
<tr>
<td align="left">p_loss</td>
<td align="left">Estimated packet loss ratio</td>
</tr>
<tr>
<td align="left">x_curr</td>
<td align="left">Aggregate congestion signal</td>
</tr>
<tr>
<td align="left">x_prev</td>
<td align="left">Previous value of aggregate congestion signal</td>
</tr>
<tr>
<td align="left">x_diff</td>
<td align="left">Change in aggregate congestion signal w.r.t. its
previous value: x_diff = x_curr - x_prev</td>
</tr>
<tr>
<td align="left">rmode</td>
<td align="left">Rate update mode: (0 = accelerated ramp up; 1 =
gradual update)</td>
</tr>
<tr>
<td align="left">gamma</td>
<td align="left">Rate increase multiplier in accelerated ramp-up
mode</td>
</tr>
<tr>
<td align="left">loss_int</td>
<td align="left">Measured average loss interval in packet count</td>
</tr>
<tr>
<td align="left">loss_exp</td>
<td align="left">Threshold value for setting the last observed packet
loss to expiration</td>
</tr>
<tr>
<td align="left">rtt</td>
<td align="left">Estimated round-trip time at sender</td>
</tr>
<tr>
<td align="left">buffer_len</td>
<td align="left">Rate-shaping buffer occupancy measured in bytes</td>
</tr>
</tbody>
</table>
<table align="left" anchor="tab-parameters">
<name>List of Algorithm Parameters and Their Default Values</name>
<thead>
<tr>
<th align='left'>Notation</th>
<th align='left'>Parameter Name</th>
<th align='left'>Default Value</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">PRIO</td>
<td align="left">Weight of priority of the flow</td>
<td align="left">1.0</td>
</tr>
<tr>
<td align="left">RMIN</td>
<td align="left">Minimum rate of application supported by media
encoder</td>
<td align="left">150 Kbps</td>
</tr>
<tr>
<td align="left">RMAX</td>
<td align="left">Maximum rate of application supported by media
encoder</td>
<td align="left">1.5 Mbps</td>
</tr>
<tr>
<td align="left">XREF</td>
<td align="left">Reference congestion level</td>
<td align="left">10 ms</td>
</tr>
<tr>
<td align="left">KAPPA</td>
<td align="left">Scaling parameter for gradual rate update
calculation</td>
<td align="left">0.5</td>
</tr>
<tr>
<td align="left">ETA</td>
<td align="left">Scaling parameter for gradual rate update
calculation</td>
<td align="left">2.0</td>
</tr>
<tr>
<td align="left">TAU</td>
<td align="left">Upper bound of RTT in gradual rate update
calculation</td>
<td align="left">500 ms</td>
</tr>
<tr>
<td align="left">DELTA</td>
<td align="left">Target feedback interval</td>
<td align="left">100 ms</td>
</tr>
<tr>
<td align="left">LOGWIN</td>
<td align="left">Observation window in time for calculating packet
summary statistics at receiver</td>
<td align="left">500 ms</td>
</tr>
<tr>
<td align="left">QEPS</td>
<td align="left">Threshold for determining queuing delay buildup at
receiver</td>
<td align="left">10 ms</td>
</tr>
<tr>
<td align="left">DFILT</td>
<td align="left">Bound on filtering delay</td>
<td align="left">120 ms</td>
</tr>
<tr>
<td align="left">GAMMA_MAX</td>
<td align="left">Upper bound on rate increase ratio for accelerated ramp
up</td>
<td align="left">0.5</td>
</tr>
<tr>
<td align="left">QBOUND</td>
<td align="left">Upper bound on self-inflicted queuing delay during ramp
up</td>
<td align="left">50 ms</td>
</tr>
<tr>
<td align="left">MULTILOSS</td>
<td align="left">Multiplier for self-scaling the expiration threshold of
the last observed loss (loss_exp) based on measured average loss
interval (loss_int)</td>
<td align="left">7.0</td>
</tr>
<tr>
<td align="left">QTH</td>
<td align="left">Delay threshold for invoking non-linear warping</td>
<td align="left">50 ms</td>
</tr>
<tr>
<td align="left">LAMBDA</td>
<td align="left">Scaling parameter in the exponent of non-linear
warping</td>
<td align="left">0.5</td>
</tr>
<tr>
<td align="left">PLRREF</td>
<td align="left">Reference packet loss ratio</td>
<td align="left">0.01</td>
</tr>
<tr>
<td align="left">PMRREF</td>
<td align="left">Reference packet marking ratio</td>
<td align="left">0.01</td>
</tr>
<tr>
<td align="left">DLOSS</td>
<td align="left">Reference delay penalty for loss when packet loss ratio
is at PLRREF</td>
<td align="left">10 ms</td>
</tr>
<tr>
<td align="left">DMARK</td>
<td align="left">Reference delay penalty for ECN marking when packet
marking is at PMRREF</td>
<td align="left">2 ms</td>
</tr>
<tr>
<td align="left">FPS</td>
<td align="left">Frame rate of incoming video</td>
<td align="left">30</td>
</tr>
<tr>
<td align="left">BETA_S</td>
<td align="left">Scaling parameter for modulating outgoing sending
rate</td>
<td align="left">0.1</td>
</tr>
<tr>
<td align="left">BETA_V</td>
<td align="left">Scaling parameter for modulating video encoder target
rate</td>
<td align="left">0.1</td>
</tr>
<tr>
<td align="left">ALPHA</td>
<td align="left">Smoothing factor in exponential smoothing of packet
loss and marking ratios</td>
<td align="left">0.1</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor = "subsec-receiver-algorithm" <section anchor="subsec-receiver-algorithm" numbered="true"
title = "Receiver-Side Algorithm"> toc="default">
<name>Receiver-Side Algorithm</name>
<t>The receiver-side algorithm can be outlined as below:</t>
<t>The receiver-side algorithm can be outlined as below:</t> <ul empty="true">
<t><figure><artwork><![CDATA[ <li>On initialization:</li>
On initialization: <li>
set d_base = +INFINITY <ul empty="true">
set p_loss = 0 <li>set d_base = +INFINITY
set p_mark = 0 </li>
set r_recv = 0 <li>set p_loss = 0
set both t_last and t_curr as current time in milliseconds </li>
<li>set p_mark = 0
</li>
<li>set r_recv = 0
</li>
<li>set both t_last and t_curr as current time in milliseconds
</li>
</ul>
</li>
On receiving a media packet: <li>On receiving a media packet:
obtain current timestamp t_curr from system clock </li>
obtain from packet header sending time stamp t_sent <li>
obtain one-way delay measurement: d_fwd = t_curr - t_sent <ul empty="true">
update baseline delay: d_base = min(d_base, d_fwd)
update queuing delay: d_queue = 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): <li>obtain current timestamp t_curr from system clock
calculate non-linear warping of delay d_tilde if packet loss exists </li>
calculate current aggregate congestion signal x_curr
determine mode of rate adaptation for sender: rmode
send feedback containing values of: rmode, x_curr, 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 <li>obtain from packet header sending time stamp t_sent
</li>
<li>obtain one-way delay measurement: d_fwd = t_curr - t_sent
</li>
<li>update baseline delay: d_base = min(d_base, d_fwd)
</li>
<li>update queuing delay: d_queue = d_fwd - d_base
</li>
<li>update packet loss ratio estimate p_loss
</li>
<li>update packet marking ratio estimate p_mark
</li>
<li>update measurement of receiving rate r_recv
</li>
</ul>
</li>
<li>On time to send a new feedback report (t_curr - t_last > DELTA):
</li>
<li>
<ul empty="true">
<li>calculate non-linear warping of delay d_tilde if packet loss exists
</li>
<li>calculate current aggregate congestion signal x_curr
</li>
<li>determine mode of rate adaptation for sender: rmode
</li>
<li>send feedback containing values of: rmode, x_curr, and r_recv
</li>
<li>update t_last = t_curr
</li>
</ul>
</li>
</ul>
<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 against loss-based flows (e.g., loss-based TCP), it is important
to distinguish between different levels of observed queuing delay. to distinguish between different levels of observed queuing delay.
For instance, over wired connections, a moderate queuing delay value For instance, over wired connections, a moderate queuing delay value
on the order of tens of milliseconds is likely self-inflicted or on the order of tens of milliseconds is likely self-inflicted or
induced by other delay-based flows, whereas a high queuing delay induced by other delay-based flows, whereas a high queuing delay
value of several hundreds of milliseconds may indicate the presence value of several hundreds of milliseconds may indicate the presence
of a loss-based flow that does not refrain from increased delay.</t> of a loss-based flow that does not refrain from increased delay.</t>
<t> If the last observed packet loss is within the expiration
<t> If the last observed packet loss is within the expiration
window of loss_exp (measured in terms of packet counts), the window of loss_exp (measured in terms of packet counts), the
estimated queuing delay follows a non-linear warping: </t> estimated queuing delay follows a non-linear warping: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure><artwork><![CDATA[ / 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 ]]></artwork>
]]></artwork></figure></t>
<t> <t>
In (1), the queuing delay value is unchanged when it is below In Equation (1), the queuing delay value is unchanged when it is below
the first threshold QTH; otherwise it is scaled down following the first threshold QTH; otherwise, it is scaled down following
a non-linear curve. This non-linear warping is inspired by a non-linear curve. This non-linear warping is inspired by
the delay-adaptive congestion window backoff policy in the delay-adaptive congestion window backoff policy in
<xref target="Budzisz-TON11"></xref>, so as to "gradually nudge" <xref target="BUDZISZ-AIMD-CC" format="default"/> so as to "gradually nudge"
the controller to operate based on loss-induced congestion the controller to operate based on loss-induced congestion
signals when competing against loss-based flows. The exact form signals when competing against loss-based flows. The exact form
of the non-linear function has been simplified with respect to of the non-linear function has been simplified with respect to
<xref target="Budzisz-TON11"></xref>. The value of the threshold <xref target="BUDZISZ-AIMD-CC" format="default"/>. The value of the threshold
QTH should be carefully tuned for different operational environments, QTH should be carefully tuned for different operational environments
so as to avoid potential risks of prematurely discounting the congestion so as to avoid potential risks of prematurely discounting the congestion
signal level. Typically, a higher value of QTH is required in a signal level. Typically, a higher value of QTH is required in a
noisier environment (e.g., over wireless connections, or where the noisier environment (e.g., over wireless connections or where the
video stream encounters many time-varying background competing traffic) video stream encounters many time-varying background competing traffic)
so as to stay robust against occasional non-congestion-induced delay so as to stay robust against occasional non-congestion-induced delay
spikes. Additional insights on how this value can be tuned or auto-tuned spikes. Additional insights on how this value can be tuned or auto-tuned
should be gathered from carrying out experimental studies in different should be gathered from carrying out experimental studies in different
real-world deployment scenarios. real-world deployment scenarios.
</t> </t>
<t>The value of loss_exp is configured to self-scale with the average
<t>The value of loss_exp is configured to self-scale with the average
packet loss interval loss_int with a multiplier MULTILOSS: </t> packet loss interval loss_int with a multiplier MULTILOSS: </t>
<t><figure> <artwork name="" type="" align="left" alt=""><![CDATA[ loss_exp = MULTILOSS *
<artwork><![CDATA[ loss_int. ]]></artwork>
loss_exp = MULTILOSS * loss_int.
]]></artwork>
</figure></t>
<t>Estimation of the average loss interval loss_int, in turn, follows
Section 5.4 of the <xref target="RFC5348">TCP Friendly Rate Control
(TFRC) protocol</xref>. </t>
<t>In practice, it is recommended to linearly interpolate between the <t>Estimation of the average loss interval loss_int, in turn, follows
<xref target="RFC5348" sectionFormat ="of"
section="5.4">"TCP Friendly Rate Control
(TFRC): Protocol Specification"</xref>. </t>
<t>In practice, it is recommended to linearly interpolate between the
warped (d_tilde) and non-warped (d_queue) values of the queuing delay warped (d_tilde) and non-warped (d_queue) values of the queuing delay
during the transitional period lasting for the duration of loss_int. </t> during the transitional period lasting for the duration of loss_int. </t>
<t>The aggregate congestion signal is:</t>
<t>The aggregate congestion signal is:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure>
<artwork><![CDATA[
/ p_mark \^2 / p_loss \^2 / p_mark \^2 / p_loss \^2
x_curr = d_tilde + DMARK*|--------| + DLOSS*|--------|. (2) x_curr = d_tilde + DMARK*|--------| + DLOSS*|--------| (2)
\ PMRREF / \ PLRREF / \ PMRREF / \ PLRREF / ]]></artwork>
]]></artwork> <t>Here, DMARK is prescribed a reference delay penalty associated with
</figure></t> ECN markings at the reference marking ratio of PMRREF; DLOSS is
prescribed a reference delay penalty associated with packet losses at
the reference packet loss ratio of PLRREF. The value of DLOSS and
DMARK does not depend on configurations at the network node. Since
ECN-enabled active queue management schemes typically mark a packet
before dropping it, the value of DLOSS <bcp14>SHOULD</bcp14> be higher
than that of DMARK. Furthermore, the values of DLOSS and DMARK need to
be set consistently across all NADA flows sharing the same bottleneck
link so that they can compete fairly.</t>
<t>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
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 or not the network is
underutilized and then recommend the corresponding rate adaptation
mode for
the sender. The criteria for operating in accelerated ramp-up mode
are:</t>
<ul spacing="normal">
<li> No recent packet losses within the observation window LOGWIN;
and</li> <li> No buildup of queuing delay: d_fwd-d_base &lt; QEPS
for all previous delay samples within the observation window
LOGWIN.</li>
</ul>
<t>Otherwise, the algorithm operates in graduate update mode. </t>
</section>
<section anchor="subsec-sender-algorithm" numbered="true" toc="default">
<name>Sender-Side Algorithm</name>
<t>The sender-side algorithm is outlined as follows:</t>
<t>Here, DMARK is prescribed reference delay penalty associated <ul empty="true">
with ECN markings at the reference marking ratio of PMRREF;
DLOSS is prescribed reference delay penalty associated with
packet losses at the reference packet loss ratio of PLRREF.
The value of DLOSS and DMARK does not depend on configurations
at the network node. Since ECN-enabled active queue management
schemes typically mark a packet before dropping it, the value
of DLOSS SHOULD be higher than that of DMARK. Furthermore,
the values of DLOSS and DMARK need to be set consistently
across all NADA flows sharing the same bottleneck link,
so that they can compete fairly.</t>
<t>In the absence of packet marking and losses, <li>On initialization:</li>
the value of x_curr reduces to the observed queuing <li>
delay d_queue. In that case the NADA algorithm operates <ul empty="true">
in the regime of delay-based adaptation. </t> <li>set r_ref = RMIN
</li>
<li>set rtt = 0
</li>
<li>set x_prev = 0
</li>
<li>set t_last and t_curr as current system clock time
</li>
</ul>
</li>
<t>Given observed per-packet delay and loss information, <li>On receiving feedback report:
the receiver is also in a good position to determine </li>
whether the network is underutilized and recommend the <li>
corresponding rate adaptation mode for the sender. The <ul empty="true">
criteria for operating in accelerated ramp-up mode are:</t>
<t><list style="symbols"> <li>obtain current timestamp from system clock: t_curr
<t> No recent packet losses within the observation window LOGWIN; </li>
and</t>
<t> No build-up of queuing delay: d_fwd-d_base &lt; QEPS for all
previous delay samples within the observation window LOGWIN.</t>
</list></t>
<t>Otherwise the algorithm operates in graduate update mode. </t> <li>obtain values of rmode, x_curr, and r_recv from feedback report
</li>
</section> <li>update estimation of rtt
</li>
<section anchor = "subsec-sender-algorithm" <li>measure feedback interval: delta = t_curr - t_last
title = "Sender-Side Algorithm"> </li>
<t>The sender-side algorithm is outlined as follows:</t> <li>if rmode == 0:
</li>
<li>
<ul empty="true">
<li>update r_ref following accelerated ramp-up rules
</li>
</ul>
</li>
<t><figure> <li>else:
<artwork><![CDATA[ </li>
on initialization: <li>
set r_ref = RMIN <ul empty="true">
set rtt = 0 <li>update r_ref following gradual update rules
set x_prev = 0 </li>
set t_last and t_curr as current system clock time </ul>
</li>
on receiving feedback report: <li>clip rate r_ref within the range of minimum rate (RMIN) and maximum rate
obtain current timestamp from system clock: t_curr (RMAX).
obtain values of rmode, x_curr, and r_recv from feedback report </li>
update estimation of rtt <li>set x_prev = x_curr
measure feedback interval: delta = t_curr - t_last </li>
if rmode == 0: <li>set t_last = t_curr
update r_ref following accelerated ramp-up rules </li>
else:
update r_ref following gradual update rules
clip rate r_ref within the range of minimum rate (RMIN) </ul>
and maximum rate (RMAX). </li>
x_prev = x_curr
t_last = t_curr ]]></artwork>
</figure></t>
<t>In accelerated ramp-up mode, the rate r_ref is updated as follows:</t> </ul>
<t><figure> <t>In accelerated ramp-up mode, the rate r_ref is updated as
<artwork><![CDATA[ follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
QBOUND QBOUND
gamma = min(GAMMA_MAX, ------------------) (3) gamma = min(GAMMA_MAX, ------------------) (3)
rtt+DELTA+DFILT rtt+DELTA+DFILT
r_ref = max(r_ref, (1+gamma) r_recv) (4) r_ref = max(r_ref, (1+gamma) r_recv)
(4)
]]></artwork></figure></t> ]]></artwork>
<t>The rate increase multiplier gamma is calculated as a function
of upper bound of self-inflicted queuing delay (QBOUND),
round-trip-time (rtt), target feedback interval (DELTA) and
bound on filtering delay for calculating d_queue (DFILT). 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_ref is updated as:</t>
<t><figure>
<artwork><![CDATA[
<t>The rate increase multiplier gamma is calculated as a function of
the upper bound of self-inflicted queuing delay (QBOUND), round-trip
time (rtt), and target feedback interval (DELTA); it is bound on the
filtering delay for calculating d_queue (DFILT). It has a maximum
value of GAMMA_MAX. The rationale behind Equations (3)-(4) is that the
longer it takes for the sender to observe self-inflicted queuing delay
buildup, the more conservative the sender should be in increasing its
rate and, hence, the smaller the rate increase multiplier. </t>
<t>In gradual update mode, the rate r_ref is updated as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
x_offset = x_curr - PRIO*XREF*RMAX/r_ref (5) x_offset = x_curr - PRIO*XREF*RMAX/r_ref (5)
x_diff = x_curr - x_prev (6) x_diff = x_curr - x_prev (6)
delta x_offset delta x_offset
r_ref = r_ref - KAPPA*-------*------------*r_ref r_ref = r_ref - KAPPA*-------*------------*r_ref
TAU TAU TAU TAU
x_diff x_diff
- KAPPA*ETA*---------*r_ref (7) - KAPPA*ETA*---------*r_ref (7)
TAU TAU
]]></artwork>
]]></artwork></figure></t> <t>The rate changes in proportion to the previous rate decision.
It is affected by two terms: the offset of the aggregate congestion
<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 signal from its value at equilibrium (x_offset) and its change
(x_diff). Calculation of x_offset depends on maximum rate (x_diff). The calculation of x_offset depends on the maximum rate
of the flow (RMAX), its weight of priority (PRIO), as well of the flow (RMAX), its weight of priority (PRIO), as well
as a reference congestion signal (XREF). The value of as a reference congestion signal (XREF). The value of
XREF is chosen so that the maximum rate of RMAX can be achieved XREF is chosen so that the maximum rate of RMAX can be achieved
when the observed congestion signal level is below PRIO*XREF. </t> when the observed congestion signal level is below PRIO*XREF. </t>
<t>
<t>
At equilibrium, the aggregated congestion signal stabilizes at At equilibrium, the aggregated congestion signal stabilizes at
x_curr = PRIO*XREF*RMAX/r_ref. This ensures that when multiple x_curr = PRIO*XREF*RMAX/r_ref. This ensures that when multiple
flows share the same bottleneck and observe a common value of flows share the same bottleneck and observe a common value of
x_curr, their rates at equilibrium will be proportional to their x_curr, their rates at equilibrium will be proportional to their
respective priority levels (PRIO) and the range between minimum respective priority levels (PRIO) and the range between minimum
and maximum rate. Values of the minimum rate (RMIN) and and maximum rate. Values of the minimum rate (RMIN) and
maximum rate (RMAX) will be provided by the media codec, maximum rate (RMAX) will be provided by the media codec,
for instance, as outlined by <xref target="I-D.ietf-rmcat-cc-codec-interactions" for instance, as outlined by <xref
> target="I-D.ietf-rmcat-cc-codec-interactions" format="default">
</xref>. In the absence of such information, NADA sender will </xref>. In the absence of such information, the NADA sender will
choose a default value of 0 for RMIN, and 3Mbps for RMAX. </t> choose a default value of 0 for RMIN and 3 Mbps for RMAX. </t>
<t> As mentioned in the sender-side algorithm, the final rate
<t> As mentioned in the sender-side algorithm, the final rate
is always clipped within the dynamic range specified by the is always clipped within the dynamic range specified by the
application: </t> application: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
r_ref = min(r_ref, RMAX) (8)
<t><figure><artwork><![CDATA[ r_ref = max(r_ref, RMIN) (9)
]]></artwork>
r_ref = min(r_ref, RMAX) (8) <t>The above operations ignore many practical issues such as clock
r_ref = max(r_ref, RMIN) (9) synchronization between sender and receiver, the filtering of noise in
]]></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 delay measurements, and base delay expiration. These will be addressed
in <xref target="sec-practical-nada"></xref>.</t> in <xref target="sec-practical-nada" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-practical-nada" numbered="true" toc="default">
<section anchor="sec-practical-nada" <name>Practical Implementation of NADA</name>
title = "Practical Implementation of NADA"> <section anchor="sec-receiver" numbered="true" toc="default">
<name>Receiver-Side Operation</name>
<section anchor="sec-receiver" <t>The receiver continuously monitors end-to-end per-packet
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. statistics in terms of delay, loss, and/or ECN marking ratios.
It then aggregates all forms of congestion indicators into the It then aggregates all forms of congestion indicators into the
form of an equivalent delay and periodically reports this back form of an equivalent delay and periodically reports this back
to the sender. In addition, the receiver tracks the receiving to the sender. In addition, the receiver tracks the receiving
rate of the flow and includes that in the feedback message.</t> rate of the flow and includes that in the feedback message.</t>
<section anchor="sec-receiver-a" numbered="true" toc="default">
<section anchor="sec-receiver-a" <name>Estimation of One-Way Delay and Queuing Delay</name>
title="Estimation of one-way delay and queuing delay"> <t>
The delay estimation process in NADA follows an approach similar to that of
<t> earlier
The delay estimation process in NADA follows a similar approach delay-based congestion control schemes, such as Low Extra Delay Background
as in earlier delay-based congestion control schemes, such as Transport (LEDBAT) <xref target="RFC6817" format="default"></xref>. For
<xref target="RFC6817">LEDBAT</xref>. For experimental implementations, experimental implementations, instead of relying on RTP timestamps and the
instead of relying on RTP timestamps and the transmission time offset transmission time offset RTP header extension <xref target="RFC5450"
RTP header extension <xref target="RFC5450"></xref>, the NADA sender format="default"/>, the NADA sender can generate its own timestamp based on
can generate its own timestamp based on local system clock and embed the local system clock and embed that information in the transport packet
that information in the transport packet header. The NADA receiver header. The NADA receiver estimates the forward delay as having a constant
estimates the forward delay as having a constant base delay component base delay component plus a time-varying queuing delay component. The base
plus a time varying queuing delay component. The base delay is delay is estimated as the minimum value of one-way delay observed over a
estimated as the minimum value of one-way delay observed over a
relatively long period (e.g., tens of minutes), whereas the individual relatively long period (e.g., tens of minutes), whereas the individual
queuing delay value is taken to be the difference between one-way delay queuing delay value is taken to be the difference between one-way delay and
and base delay. By re-estimating the base delay periodically, one can base delay. By re-estimating the base delay periodically, one can avoid the
avoid the potential issue of base delay expiration, whereby an earlier potential issue of base delay expiration, whereby an earlier measured base
measured base delay value is no longer valid due to underlying route delay value is no longer valid due to underlying route changes or a cumulative
changes or cumulative timing difference introduced by the clock rate skew timing difference introduced by the clock-rate skew between sender and
between sender and receiver. All delay estimations are based on sender receiver. All delay estimations are based on sender timestamps with a
timestamps with a recommended granularity of 100 microseconds recommended granularity of 100 microseconds or finer. </t>
or finer. </t> <t>
<t>
The individual sample values of queuing delay should be further The individual sample values of queuing delay should be further
filtered against various non-congestion-induced noise, such as filtered against various non-congestion-induced noise, such as
spikes due to processing "hiccup" at the network nodes. Therefore, spikes due to a processing "hiccup" at the network nodes. Therefore,
in addition to calculating the value of queuing delay using in addition to calculating the value of queuing delay using
d_queue = d_fwd - d_base, as expressed in <xref target="sec-receiver"></xref>, d_queue = d_fwd - d_base, as expressed in <xref target="sec-receiver"
current implementation further employs a minimum filter with format="default"/>,
the current implementation further employs a minimum filter with
a window size of 15 samples over per-packet queuing delay values. a window size of 15 samples over per-packet queuing delay values.
</t> </t>
</section>
</section> <section anchor="sec-receiver-b" numbered="true" toc="default">
<name>Estimation of Packet Loss/Marking Ratio</name>
<section anchor="sec-receiver-b" <t>The receiver detects packet losses via gaps in the
title="Estimation of packet loss/marking ratio">
<t>The receiver detects packet losses via gaps in the
RTP sequence numbers of received packets. For interactive RTP sequence numbers of received packets. For interactive
real-time media application with stringent latency real-time media applications with stringent latency
constraint (e.g., video conferencing), the receiver avoids constraints (e.g., video conferencing), the receiver avoids
the packet re-ordering delay by treating out-of-order packets the packet reordering delay by treating out-of-order packets
as losses. The instantaneous packet loss ratio p_inst is estimated as losses. The instantaneous packet loss ratio p_inst is estimated
as the ratio between the number of missing packets over as the ratio between the number of missing packets over
the number of total transmitted packets within the the number of total transmitted packets within the
recent observation window LOGWIN. The packet loss ratio recent observation window LOGWIN. The packet loss ratio
p_loss is obtained after exponential smoothing: </t> p_loss is obtained after exponential smoothing: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure> p_loss = ALPHA*p_inst + (1-ALPHA)*p_loss (10)
<artwork><![CDATA[ ]]></artwork>
p_loss = ALPHA*p_inst + (1-ALPHA)*p_loss. (10) <t>The filtered result is reported back to the sender as
]]></artwork>
</figure></t>
<t>The filtered result is reported back to the sender as
the observed packet loss ratio p_loss. </t> the observed packet loss ratio p_loss. </t>
<t>
<t> The estimation of the 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 header as above. It is assumed that ECN marking information at the IP header
can be passed to the receiving endpoint, e.g., by following the mechanism can be passed to the receiving endpoint, e.g., by following the mechanism
described in <xref target="RFC6679"></xref>.</t> described in <xref target="RFC6679" format="default"/>.</t>
</section>
</section> <section anchor="sec-receiver-c" numbered="true" toc="default">
<name>Estimation of Receiving Rate</name>
<section anchor = "sec-receiver-c" <t>
title = "Estimation of receiving rate"> It is fairly straightforward to estimate the receiving rate r_recv. NADA
maintains a recent observation window with a time span of LOGWIN and simply
<t> divides the total size of packets arriving during that window over the time
It is fairly straightforward to estimate the receiving span. The receiving rate (r_recv) can be either calculated at the sender side
rate r_recv. NADA maintains a recent observation window based on the per-packet feedback from the receiver or included as part of the
with time span of LOGWIN, and simply divides the total feedback report.</t>
size of packets arriving during that window over the time </section>
span. The receiving rate (r_recv) can be calculated at </section>
either the sender side based on the per-packet feedback <section anchor="sec-sender" numbered="true" toc="default">
from the receiver, or included as part of the feedback <name>Sender-Side Operation</name>
report.</t> <t>
<xref target="fig-nada-sender" format="default"/> provides a detailed
</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 view of the NADA sender. Upon receipt of an RTCP feedback
report from the receiver, the NADA sender calculates the report from the receiver, the NADA sender calculates the
reference rate r_ref as specified in reference rate r_ref as specified in
<xref target="subsec-sender-algorithm"></xref>. <xref target="subsec-sender-algorithm" format="default"/>.
It further adjusts both the target rate for the live video It further adjusts both the target rate for the live video
encoder r_vin and the sending rate r_send over the network encoder r_vin and the sending rate r_send over the network
based on the updated value of r_ref and rate shaping buffer based on the updated value of r_ref and rate-shaping buffer
occupancy buffer_len. occupancy buffer_len.
</t> </t>
<t>
<t>
The NADA sender behavior stays the same in the presence The NADA sender behavior stays the same in the presence
of all types of congestion indicators: delay, loss, and of all types of congestion indicators: delay, loss, and
ECN marking. This unified approach allows a graceful ECN marking. This unified approach allows a graceful
transition of the scheme as the network shifts dynamically transition of the scheme as the network shifts dynamically
between light and heavy congestion levels. between light and heavy congestion levels.
</t> </t>
<figure anchor="fig-nada-sender">
<t><figure anchor="fig-nada-sender" <name>NADA Sender Structure</name>
title="NADA Sender Structure"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+----------------+ +----------------+
| Calculate | <---- RTCP report | Calculate | <---- RTCP report
| Reference Rate | | Reference Rate |
-----------------+ -----------------+
| r_ref | r_ref
+------------+-------------+ +------------+-------------+
| | | |
\|/ \|/ \|/ \|/
+-----------------+ +---------------+ +-----------------+ +---------------+
| Calculate Video | | Calculate | | Calculate Video | | Calculate |
| Target Rate | | Sending Rate | | Target Rate | | Sending Rate |
+-----------------+ +---------------+ +-----------------+ +---------------+
| /|\ /|\ | | /|\ /|\ |
r_vin | | | | r_vin | | | |
\|/ +-------------------+ | \|/ +-------------------+ |
+----------+ | buffer_len | r_send +----------+ | buffer_len | r_send
| Video | r_vout -----------+ \|/ | Video | r_vout -----------+ \|/
| Encoder |--------> |||||||||=================> | Encoder |--------> |||||||||=================>
+----------+ -----------+ RTP packets +----------+ -----------+ RTP packets
Rate Shaping Buffer Rate-Shaping Buffer
]]></artwork></figure></t> ]]></artwork>
</figure>
<section anchor = "sec-sender-c" <section anchor="sec-sender-c" numbered="true" toc="default">
title = "Rate shaping buffer"> <name>Rate-Shaping Buffer</name>
<t>
<t>
The operation of the live video encoder is out of the scope The operation of the live video encoder is out of the scope
of the design for the congestion control scheme in NADA. of the design for the congestion control scheme in NADA.
Instead, its behavior is treated as a black box. Instead, its behavior is treated as a black box.
</t> </t>
<t>
<t> A rate-shaping buffer is employed to absorb any instantaneous
A rate shaping buffer is employed to absorb any instantaneous mismatch between the encoder rate output r_vout and the regulated sending
mismatch between encoder rate output r_vout and regulated sending
rate r_send. Its current level of occupancy is measured in bytes rate r_send. Its current level of occupancy is measured in bytes
and is denoted as buffer_len. and is denoted as buffer_len.
</t> </t>
<t>A large rate-shaping buffer contributes to higher
<t>A large rate shaping buffer contributes to higher
end-to-end delay, which may harm the performance of end-to-end delay, which may harm the performance of
real-time media communications. Therefore, the sender real-time media communications. Therefore, the sender
has a strong incentive to prevent the rate shaping has a strong incentive to prevent the rate-shaping
buffer from building up. The mechanisms adopted are: buffer from building up. The mechanisms adopted are:
</t> </t>
<ul spacing="normal">
<t><list style="symbols"> <li>To deplete the rate-shaping buffer faster by
<t>To deplete the rate shaping buffer faster by increasing the sending rate r_send; and </li>
increasing the sending rate r_send; and </t> <li>To limit incoming packets of the rate-shaping
<t>To limit incoming packets of the rate shaping buffer by reducing the video encoder target rate
buffer by reducing the video encoder target rate r_vin. </li>
r_vin. </t> </ul>
</list></t> </section>
<section anchor="sec-sender-d" numbered="true" toc="default">
</section> <name>Adjusting Video Target Rate and Sending Rate</name>
<t>
<section anchor = "sec-sender-d" If the level of occupancy in the rate-shaping buffer is accessible
title = "Adjusting video target rate and sending rate">
<t>
If the level of occupancy in the rate shaping buffer is accessible
at the sender, such information can be leveraged to further adjust at the sender, such information can be leveraged to further adjust
the target rate of the live video encoder r_vin as well as the the target rate of the live video encoder r_vin as well as the
actual sending rate r_send. The purpose of such adjustments is to actual sending rate r_send. The purpose of such adjustments is to
mitigate the additional latencies introduced by the rate shaping mitigate the additional latencies introduced by the rate-shaping
buffer. The amount of rate adjustment can be calculated as follows: buffer. The amount of rate adjustment can be calculated as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure><artwork><![CDATA[ r_diff_v = min(0.05*r_ref, BETA_V*8*buffer_len*FPS) (11)
r_diff_s = min(0.05*r_ref, BETA_S*8*buffer_len*FPS) (12)
r_diff_v = min(0.05*r_ref, BETA_V*8*buffer_len*FPS). (11) r_vin = max(RMIN, r_ref - r_diff_v) (13)
r_diff_s = min(0.05*r_ref, BETA_S*8*buffer_len*FPS). (12) r_send = min(RMAX, r_ref + r_diff_s) (14)
r_vin = max(RMIN, r_ref - r_diff_v). (13) ]]></artwork>
r_send = min(RMAX, r_ref + r_diff_s). (14)
]]></artwork></figure></t>
<t> In (11) and (12), the amount of adjustment is calculated <t> In Equations (11) and (12), the amount of adjustment is calculated
as proportional to the size of the rate shaping buffer but is as proportional to the size of the rate-shaping buffer but is
bounded by 5% of the reference rate r_ref calculated from network bounded by 5% of the reference rate r_ref calculated from network
congestion feedback alone. This ensures that the adjustment congestion feedback alone. This ensures that the adjustment
introduced by the rate shaping buffer will not counteract with the core introduced by the rate-shaping buffer will not counteract with the core
congestion control process. Equations (13) and (14) indicate congestion control process. Equations (13) and (14) indicate
the influence of the rate shaping buffer. A large the influence of the rate-shaping buffer. A large
rate shaping buffer nudges the encoder target rate slightly rate-shaping buffer nudges the encoder target rate slightly
below -- and the sending rate slightly above -- the reference below (and the sending rate slightly above) the reference
rate r_ref. The final video target rate (r_vin) and sending rate r_ref. The final video target rate (r_vin) and sending
rate (r_send) are further bounded within the original range of rate (r_send) are further bounded within the original range of
[RMIN, RMAX]. </t> [RMIN, RMAX]. </t>
<t> <t>
Intuitively, the amount of extra rate offset needed to completely Intuitively, the amount of extra rate offset needed to completely
drain the rate shaping buffer within the duration of a single drain the rate-shaping buffer within the duration of a single
video frame is given by 8*buffer_len*FPS, where FPS stands video frame is given by 8*buffer_len*FPS, where FPS stands
for the reference frame rate of the video. The scaling parameters for the reference frame rate of the video. The scaling parameters
BETA_V and BETA_S can be tuned to balance between the competing BETA_V and BETA_S can be tuned to balance between the competing
goals of maintaining a small rate shaping buffer and deviating goals of maintaining a small rate-shaping buffer and deviating
from the reference rate point. Empirical observations show that from the reference rate point. Empirical observations show that
the rate shaping buffer for a responsive live video encoder typically the rate-shaping buffer for a responsive live video encoder typically
stays empty and only occasionally holds a large frame (e.g., when stays empty and only occasionally holds a large frame (e.g., when
an intra-frame is produced) in transit. Therefore, the rate adjustment an intra-frame is produced) in transit. Therefore, the rate adjustment
introduced by this mechanism is expected to be minor. For instance, introduced by this mechanism is expected to be minor. For instance,
a rate shaping buffer of 2000 Bytes will lead to a rate adjustment a rate-shaping buffer of 2000 bytes will lead to a rate adjustment
of 48Kbps given the recommended scaling parameters of BETA_V = 0.1 of 48 Kbps given the recommended scaling parameters of BETA_V = 0.1
and BETA_S = 0.1 and reference frame rate of FPS = 30. and BETA_S = 0.1, and the reference frame rate of FPS = 30.
</t> </t>
</section>
</section> </section>
<section anchor="sec-feedback" numbered="true" toc="default">
</section> <name>Feedback Message Requirements</name>
<t>The following list of information is required for
<section anchor = "sec-feedback"
title = "Feedback Message Requirements">
<t>The following list of information is required for
NADA congestion control to function properly: </t> NADA congestion control to function properly: </t>
<t><list style="symbols"> <dl newline="false" spacing="normal">
<dt>Recommended rate adaptation mode (rmode):
<t>Recommended rate adaptation mode (rmode): a 1-bit flag </dt>
indicating whether the sender should operate in <dd>A 1-bit flag indicating whether the sender should operate in accelerated
accelerated ramp-up mode (rmode=0) or gradual update ramp-up mode (rmode=0) or gradual update mode (rmode=1).
mode (rmode=1). </t> </dd>
<t>Aggregated congestion signal (x_curr): the most recently <dt>Aggregated congestion signal (x_curr):
updated value, calculated by the receiver according to </dt>
<xref target="subsec-receiver-algorithm"></xref>. This <dd>The most recently updated value, calculated by the receiver according to
information can be expressed with a unit of 100 microsecond <xref target="subsec-receiver-algorithm" format="default"/>. This information
(i.e., 1/10 of a millisecond) in 15 bits. This allows can be expressed with a unit of 100 microseconds (i.e., 1/10 of a millisecond)
a maximum value of x_curr at approximately 3.27 second.</t> in 15 bits. This allows a maximum value of x_curr at approximately 3.27
seconds.
</dd>
<t> <dt>Receiving rate (r_recv):
Receiving rate (r_recv): the most recently measured </dt>
receiving rate according to <xref target="sec-receiver-c"> <dd>The most recently measured receiving rate according to <xref
</xref>. This information is expressed with a unit of target="sec-receiver-c" format="default"> </xref>. This information is
bits per second (bps) in 32 bits (unsigned int). This expressed with a unit of bits per second (bps) in 32 bits (unsigned int). This
allows a maximum rate of approximately 4.3Gbps, approximately allows a maximum rate of approximately 4.3 Gbps, approximately 1000 times the
1000 times of the streaming rate of a typical high-definition streaming rate of a typical high-definition (HD) video conferencing session
(HD) video conferencing session today. This field can be today. This field can be expanded further by a few more bytes if an even
expanded further by a few more bytes, in case an even higher rate needs to be specified.
higher rate need to be specified.</t> </dd>
</list></t> </dl>
<t> <t>
The above list of information can be accommodated by 48 bits, The above list of information can be accommodated by 48 bits,
or 6 bytes, in total. They can be either included in the or 6 bytes, in total. They can be either included in the
feedback report from the receiver, or, in the case where all feedback report from the receiver or, in the case where all
receiver-side calculations are moved to the sender, derived receiver-side calculations are moved to the sender, derived
from per-packet information from the feedback message as defined from per-packet information from the feedback message as defined
in <xref target="I-D.ietf-avtcore-cc-feedback-message"></xref>. in <xref target="I-D.ietf-avtcore-cc-feedback-message" format="default"/>.
Choice of the feedback message interval DELTA is discussed in Choosing the feedback message interval DELTA is discussed in
<xref target="sec-discussion-c"></xref>. A target feedback interval <xref target="sec-discussion-c" format="default"/>. A target feedback
of DELTA=100ms is recommended. interval
</t> of DELTA = 100 ms is recommended.
</t>
</section>
</section>
<section anchor = "sec-discussions" </section>
title = "Discussions and Further Investigations"> </section>
<t>This section discussed the various design choices <section anchor="sec-discussions" numbered="true" toc="default">
<name>Discussions and Further Investigations</name>
<t>This section discusses the various design choices
made by NADA, potential alternative variants of its made by NADA, potential alternative variants of its
implementation, and guidelines on how the key algorithm implementation, and guidelines on how the key algorithm
parameters can be chosen. <xref target="sec-experiments"></xref> parameters can be chosen. <xref target="sec-experiments" format="default"/>
recommends additional experimental setups to recommends additional experimental setups to
further explore these topics. </t> further explore these topics. </t>
<section anchor="sec-discussion-a" numbered="true" toc="default">
<name>Choice of Delay Metrics</name>
<section anchor = "sec-discussion-a" <t>
title = "Choice of delay metrics"> 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
<t> maintaining the minimum value of observed OWD over a relatively long time
The current design works with relative one-way-delay (OWD) horizon and subtracting that out from the observed absolute OWD value. Such an
as the main indication of congestion. The value of the relative approach cancels out the fixed difference between the sender and receiver
OWD is obtained by maintaining the minimum value of observed clocks. It has been widely adopted by other delay-based congestion control
OWD over a relatively long time horizon and subtract that out approaches such as <xref target="RFC6817" format="default"/>. As discussed in
from the observed absolute OWD value. Such an approach cancels <xref target="RFC6817" format="default"/>, the time horizon for tracking the
out the fixed difference between the sender and receiver clocks. minimum OWD needs to be chosen with care; it must be long enough for an
It has been widely adopted by other delay-based congestion opportunity to observe the minimum OWD with zero standing queue along the
control approaches such as <xref target="RFC6817"></xref>. path,
As discussed in <xref target="RFC6817"></xref>, the time horizon and it must be sufficiently short enough to timely reflect "true" changes in
for tracking the minimum OWD needs to be chosen with care: it must minimum OWD introduced by route changes and other rare events and
be long enough for an opportunity to observe the minimum OWD with to mitigate the cumulative impact of clock rate skew over time.
zero standing queue along the path, and sufficiently short so as to </t>
timely reflect "true" changes in minimum OWD introduced by route <t>
changes and other rare events and to mitigate the cumulative impact
of clock rate skew over time.
</t>
<t>
The potential drawback in relying on relative OWD as the congestion The potential drawback in relying on relative OWD as the congestion
signal is that when multiple flows share the same bottleneck, the signal is that when multiple flows share the same bottleneck, the
flow arriving late at the network experiencing a non-empty queue may flow arriving late at the network experiencing a non-empty queue may
mistakenly consider the standing queuing delay as part of the fixed mistakenly consider the standing queuing delay as part of the fixed
path propagation delay. This will lead to slightly unfair bandwidth path propagation delay. This will lead to slightly unfair bandwidth
sharing among the flows. sharing among the flows.
</t> </t>
<t>Alternatively, one could move the per-packet statistical handling
<t>Alternatively, one could move the per-packet statistical handling to the sender instead and use relative round-trip time (RTT) in lieu
to the sender instead and use relative round-trip-time (RTT) in lieu
of relative OWD, assuming that per-packet acknowledgments are available. of relative OWD, assuming that per-packet acknowledgments are available.
The main drawback of RTT-based approach is the noise in the measured delay The main drawback of an RTT-based approach is the noise in the measured delay
in the reverse direction. in the reverse direction.
</t> </t>
<t>
<t> Note that the choice of either delay metric (relative OWD vs. RTT) involves no
Note that the choice of either delay metric (relative OWD vs. RTT) change in the proposed rate adaptation algorithm. Therefore, comparing the
involves no change in the proposed rate adaptation algorithm. pros and cons regarding which delay metric to adopt can be kept as an
Therefore, comparing the pros and cons regarding which delay metric orthogonal direction of investigation.
to adopt can be kept as an orthogonal direction of investigation. </t>
</t> </section>
<section anchor="sec-discussion-b" numbered="true" toc="default">
</section> <name>Method for Delay, Loss, and Marking Ratio Estimation</name>
<t>Like other delay-based congestion control schemes, performance of
<section anchor="sec-discussion-b" NADA depends on the accuracy of its delay measurement and estimation
title = "Method for delay, loss, and marking ratio estimation"> module. <xref target= "RFC6817" format="default" section="A"/>
provides an extensive discussion on this aspect.
<t>Like other delay-based congestion control schemes, </t>
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 applying
minimum filter with a window size of 15 samples
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> <t>The current recommended practice of applying minimum filter with a
window size of 15 samples 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 denoising, outlier rejection, and trend analysis may be
needed. </t>
<t>
More sophisticated methods in packet loss ratio calculation, More sophisticated methods in packet loss ratio calculation,
such as that adopted by <xref target="Floyd-CCR00"></xref>, such as that adopted by <xref target="FLOYD-CCR00" format="default"/>,
will likely be beneficial. These alternatives are part of will likely be beneficial. These alternatives are part of
the experiments this document proposes.</t> the experiments this document proposes.</t>
</section>
</section> <section anchor="sec-discussion-c" numbered="true" toc="default">
<name>Impact of Parameter Values</name>
<section anchor = "sec-discussion-c" <t>In the gradual rate update mode, the parameter TAU indicates the
title = "Impact of parameter values"> upper bound of round-trip time (RTT) in the feedback control loop.
Typically, the observed feedback interval delta is close to the target
<t>In the gradual rate update mode, the parameter TAU indicates feedback interval DELTA, and the relative ratio of delta/TAU versus
the upper bound of round-trip-time (RTT) in feedback control loop. ETA dictates the relative strength of influence from the aggregate
Typically, the observed feedback interval delta is close to the congestion signal offset term (x_offset) versus its recent change
target feedback interval DELTA, and the relative ratio of delta/TAU (x_diff), respectively. These two terms are analogous to the integral
versus ETA dictates the relative strength of influence from the and proportional terms in a proportional-integral (PI) controller. The
aggregate congestion signal offset term (x_offset) versus its recent recommended choice of TAU = 500 ms, DELTA = 100 ms, and ETA = 2.0
change (x_diff), respectively. These two terms are analogous to corresponds
the integral and proportional terms in a proportional-integral (PI) to a relative ratio of 1:10 between the gains of the integral and
controller. The recommended choice of TAU=500ms, DELTA=100ms and proportional terms. Consequently, the rate adaptation is mostly driven
ETA = 2.0 corresponds to a relative ratio of 1:10 between the gains by the change in the congestion signal with a long-term shift towards
of the integral and proportional terms. Consequently, the rate its equilibrium value driven by the offset term. Finally, the scaling
adaptation is mostly driven by the change in the congestion signal parameter KAPPA determines the overall speed of the adaptation and
with a long-term shift towards its equilibrium value driven by the needs to strike a balance between responsiveness and stability. </t>
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> <t>
The choice of the target feedback interval DELTA needs to strike The choice of the target feedback interval DELTA needs to strike the right
the right balance between timely feedback and low RTCP feedback balance between timely feedback and low RTCP feedback message counts. A target
message counts. A target feedback interval of DELTA=100ms is feedback interval of DELTA = 100 ms is recommended, corresponding to a
recommended, corresponding to a feedback bandwidth of 16Kbps feedback
with 200 bytes per feedback message --- approximately 1.6% bandwidth of 16 Kbps with 200 bytes per feedback message -- approximately 1.6%
overhead for a 1Mbps flow. Furthermore, both simulation overhead for a 1 Mbps flow. Furthermore, both simulation studies and
studies and frequency-domain analysis in <xref target="IETF-95"></xref> frequency-domain analysis in <xref target="IETF-95" format="default"/> have
have established that a feedback interval below 250ms (i.e., more established that a feedback interval below 250 ms (i.e., more frequently than
frequently than 4 feedback messages per second) will not break 4
up the feedback control loop of NADA congestion control. </t> feedback messages per second) will not break up the feedback control loop of
NADA congestion control. </t>
<t>In calculating the non-linear warping of delay in (1), <t>In calculating the non-linear warping of delay in Equation (1),
the current design uses fixed values of QTH for determining the current design uses fixed values of QTH for determining
whether to perform the non-linear warping). Its value should be whether to perform the non-linear warping. Its value should be
carefully tuned for different operational environments (e.g., carefully tuned for different operational environments (e.g.,
over wired vs. wireless connections), so as to avoid the potential over wired vs. wireless connections) so as to avoid the potential
risk of prematurely discounting the congestion signal level. risk of prematurely discounting the congestion signal level.
It is possible to adapt its value based on past observed patterns It is possible to adapt its value based on past observed patterns
of queuing delay in the presence of packet losses. It needs to be of queuing delay in the presence of packet losses. It needs to be
noted that the non-linear warping mechanism may lead to multiple noted that the non-linear warping mechanism may lead to multiple
NADA streams stuck in loss-based mode when competing against NADA streams stuck in loss-based mode when competing against
each other. </t> each other. </t>
<t>In calculating the aggregate congestion signal x_curr, the <t>In calculating the aggregate congestion signal x_curr, the
choice of DMARK and DLOSS influence the steady-state packet choice of DMARK and DLOSS influence the steady-state packet
loss/marking ratio experienced by the flow at a given loss/marking ratio experienced by the flow at a given
available bandwidth. Higher values of DMARK and DLOSS result available bandwidth. Higher values of DMARK and DLOSS result
in lower steady-state loss/marking ratios, but are more in lower steady-state loss/marking ratios but are more
susceptible to the impact of individual packet loss/marking susceptible to the impact of individual packet loss/marking
events. While the value of DMARK and DLOSS are fixed and events. While the value of DMARK and DLOSS are fixed and
predetermined in the current design, this document also encourages predetermined in the current design, this document also encourages
further explorations of a scheme for automatically further explorations of a scheme for automatically
tuning these values based on desired bandwidth sharing behavior tuning these values based on desired bandwidth sharing behavior
in the presence of other competing loss-based flows (e.g., in the presence of other competing loss-based flows (e.g.,
loss-based TCP).</t> loss-based TCP).</t>
</section>
</section> <section anchor="sec-discussion-d" numbered="true" toc="default">
<name>Sender-Based vs. Receiver-Based Calculation</name>
<section anchor="sec-discussion-d" <t>In the current design, the aggregated congestion
title = "Sender-based vs. receiver-based calculation">
<t>In the current design, the aggregated congestion
signal x_curr is calculated at the receiver, keeping signal x_curr is calculated at the receiver, keeping
the sender operation completely independent of the the sender operation completely independent of the
form of actual network congestion indications (delay, form of actual network congestion indications (delay,
loss, or marking) in use. </t> loss, or marking) in use. </t>
<t>Alternatively, one can shift receiver-side calculations
<t>Alternatively, one can shift receiver-side calculations
to the sender, whereby the receiver simply reports on per-packet to the sender, whereby the receiver simply reports on per-packet
information via periodic feedback messages as defined in information via periodic feedback messages as defined in
<xref target="I-D.ietf-avtcore-cc-feedback-message"></xref>. <xref target="I-D.ietf-avtcore-cc-feedback-message" format="default"/>.
Such an approach enables interoperability amongst senders operating Such an approach enables interoperability amongst senders operating
on different congestion control schemes, but requires slightly on different congestion control schemes but requires slightly
higher overhead in the feedback messages. See additional discussions higher overhead in the feedback messages. See additional discussions
in <xref target="I-D.ietf-avtcore-cc-feedback-message"></xref> in <xref target="I-D.ietf-avtcore-cc-feedback-message" format="default"/>
regarding the desired format of the feedback messages and the regarding the desired format of the feedback messages and the
recommended feedback intervals. </t> recommended feedback intervals. </t>
</section>
</section> <section anchor="sec-discussion-e" numbered="true" toc="default">
<name>Incremental Deployment</name>
<section anchor = "sec-discussion-e" <t>
title = "Incremental deployment">
<t>
One nice property of NADA is the consistent video endpoint One nice property of NADA is the consistent video endpoint
behavior irrespective of network node variations. This facilitates behavior irrespective of network node variations. This facilitates
gradual, incremental adoption of the scheme. gradual, incremental adoption of the scheme.
</t> </t>
<t>
<t>
Initially, the proposed congestion control mechanism can Initially, the proposed congestion control mechanism can
be implemented without any explicit support from the network, and be implemented without any explicit support from the network and
relies solely on observed relative one-way delay measurements relies solely on observed relative one-way delay measurements
and packet loss ratios as implicit congestion signals. and packet loss ratios as implicit congestion signals.
</t> </t>
<t>
<t>
When ECN is enabled at the network nodes with RED-based marking, When ECN is enabled at the network nodes with RED-based marking,
the receiver can fold its observations of ECN markings into the the receiver can fold its observations of ECN markings into the
calculation of the equivalent delay. The sender can react to these calculation of the equivalent delay. The sender can react to these
explicit congestion signals without any modification. explicit congestion signals without any modification.
</t> </t>
<t> <t>
Ultimately, networks equipped with proactive marking based on Ultimately, networks equipped with proactive marking based on the level of
token bucket level metering can reap the additional benefits of token bucket metering can reap the additional benefits of
zero standing queues and lower end-to-end delay and work zero standing queues and lower end-to-end delay and work
seamlessly with existing senders and receivers. seamlessly with existing senders and receivers.
</t> </t>
</section>
</section> </section>
<section anchor="sec-implementations" numbered="true" toc="default">
</section> <name>Reference Implementations</name>
<t>
<section anchor = "sec-implementations" The NADA scheme has been implemented in both ns-2 <xref target="NS-2"
title ="Reference Implementations"> format="default"/>
and ns-3 <xref target="NS-3" format="default"/> simulation platforms. The
<t> implementation
The NADA scheme has been implemented in both <xref target="ns-2"></xref>
and <xref target="ns-3"></xref> simulation platforms. The implementation
in ns-2 hosts the calculations as described in in ns-2 hosts the calculations as described in
<xref target="subsec-receiver-algorithm"></xref> at the receiver side, <xref target="subsec-receiver-algorithm" format="default"/> at the receiver
side,
whereas the implementation in ns-3 hosts these receiver-side calculations whereas the implementation in ns-3 hosts these receiver-side calculations
at the sender for the sake of interoperability. Extensive ns-2 simulation at the sender for the sake of interoperability. Extensive ns-2 simulation
evaluations of an earlier version of the draft are documented in evaluations of an earlier draft version of this document are recorded in
<xref target="Zhu-PV13"></xref>. <xref target="ZHU-PV13" format="default"/>.
An open source implementation of NADA as part of a ns-3 module is An open-source implementation of NADA as part of an ns-3 module is
available at <xref target="ns3-rmcat"></xref>. available at <xref target="NS3-RMCAT" format="default"/>.
Evaluation results of the current draft based on ns-3 are presented Evaluation results of this document based on ns-3 are presented
in <xref target="IETF-90"></xref> and <xref target="IETF-91"></xref> in <xref target="IETF-90" format="default"/> and <xref target="IETF-91"
for wired test cases as documented in <xref target="I-D.ietf-rmcat-eval-test"></ format="default"/>
xref>. for wired test cases as documented in <xref target="I-D.ietf-rmcat-eval-test"
Evaluation results of NADA over WiFi-based test cases as defined in format="default"/>.
<xref target="I-D.ietf-rmcat-wireless-tests"></xref> are Evaluation results of NADA over Wi-Fi-based test cases as defined in
presented in <xref target="IETF-93"></xref>. These simulation-based <xref target="I-D.ietf-rmcat-wireless-tests" format="default"/> are
presented in <xref target="IETF-93" format="default"/>. These simulation-based
evaluations have shown that NADA flows can obtain their fair share of evaluations have shown that NADA flows can obtain their fair share of
bandwidth when competing against each other. They typically adapt fast bandwidth when competing against each other. They typically adapt fast
in reaction to the arrival and departure of other flows, and can sustain in reaction to the arrival and departure of other flows and can sustain
a reasonable throughput when competing against loss-based TCP flows. </t> a reasonable throughput when competing against loss-based TCP flows. </t>
<t>
<t> <xref target="IETF-90" format="default"/> describes the implementation and
<xref target="IETF-90"></xref> describes the implementation and
evaluation of NADA in a lab setting. Preliminary evaluation evaluation of NADA in a lab setting. Preliminary evaluation
results of NADA in single-flow and multi-flow test scenarios results of NADA in single-flow and multi-flow test scenarios
have been presented in <xref target="IETF-91"></xref>. </t> are presented in <xref target="IETF-91" format="default"/>. </t>
<t>
<t>
A reference implementation of NADA has been carried out by A reference implementation of NADA has been carried out by
modifying the WebRTC module embedded in the Mozilla open source modifying the WebRTC module embedded in the Mozilla open-source
browser. Presentations from <xref target="IETF-103"></xref> browser. Presentations from <xref target="IETF-103" format="default"/>
and <xref target="IETF-105"></xref> document real-world evaluations and <xref target="IETF-105" format="default"/> document real-world evaluations
of the modified browser driven by NADA. The experimental setting of the modified browser driven by NADA. The experimental setting
involve remote connections with endpoints over either home or enterprise involves remote connections with endpoints over either home or enterprise
wireless networks. These evaluations validate the effectiveness of wireless networks. These evaluations validate the effectiveness of
NADA flows in recovering quickly from throughput drops caused by NADA flows in recovering quickly from throughput drops caused by
intermittent delay spikes over the last-hop wireless connections. </t> intermittent delay spikes over the last-hop wireless connections. </t>
</section>
<section anchor="sec-experiments" numbered="true" toc="default">
<name>Suggested Experiments</name>
<t>
NADA has been extensively evaluated under various test scenarios, including
the collection of test cases specified by <xref
target="I-D.ietf-rmcat-eval-test" format="default"/> and the subset of
Wi-Fi-based test cases in <xref target="I-D.ietf-rmcat-wireless-tests"
format="default"/>. Additional evaluations have been carried out to
characterize how NADA interacts with various AQM
schemes such as RED, Controlling Queue Delay (CoDel), and Proportional
Integral Controller Enhanced (PIE). Most of these evaluations have been
carried out in simulators. A few key test cases have been evaluated in lab
environments with implementations embedded in video conferencing clients. It
is strongly recommended to carry out implementation and experimentation of
NADA in real-world settings. Such exercises will provide insights on how to
choose or automatically adapt the values of the key algorithm parameters (see
list in <xref target="tab-parameters" format="default"/>) as discussed in
<xref target="sec-discussions" format="default"/>. </t>
<t>Additional experiments are suggested for the following scenarios,
preferably over real-world networks: </t>
<ul spacing="normal">
<li>Experiments reflecting the setup of a typical WAN
connection. </li>
<li>Experiments with ECN marking capability turned on at the network
for existing test cases.</li>
<li>Experiments with multiple NADA streams bearing different
user-specified priorities.</li>
<li>Experiments with additional access technologies, especially
over cellular networks such as 3G/LTE.</li>
<li>Experiments with various media source contents, including audio
only,
audio and video, and application content sharing (e.g., slideshows). </li>
</ul>
</section>
<section anchor="sec-iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="sec-security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The rate adaptation mechanism in NADA relies on feedback from the
receiver. As such, it is vulnerable to attacks where feedback messages
are hijacked, replaced, or intentionally injected with misleading
information resulting in denial of service, similar to those that can
affect TCP. Therefore, it is <bcp14>RECOMMENDED</bcp14> that the RTCP
feedback message is at least integrity checked. In addition, <xref
target="I-D.ietf-avtcore-cc-feedback-message" format="default"/>
discusses the potential risk of a receiver providing misleading
congestion feedback information and the mechanisms for mitigating such
risks.</t>
</section> <t>The modification of the sending rate based on the sender-side
rate-shaping
<section anchor = "sec-experiments" buffer may lead to temporary excessive congestion over the network in
title = "Suggested Experiments"> the presence of an unresponsive video encoder. However, this effect can
be mitigated by limiting the amount of rate modification introduced by
<t> the rate-shaping buffer, bounding the size of the rate-shaping buffer at
NADA has been extensively evaluated under various test the sender, and maintaining a maximum allowed sending rate by NADA.
scenarios, including the collection of test cases specified </t>
by <xref target="I-D.ietf-rmcat-eval-test"></xref> and the </section>
subset of WiFi-based test cases in
<xref target="I-D.ietf-rmcat-wireless-tests"></xref>.
Additional evaluations have been carried out to characterize
how NADA interacts with various active queue management (AQM)
schemes such as RED, CoDel, and PIE. Most of these evaluations
have been carried out in simulators. A few key test cases have
been evaluated in lab environments with implementations embedded
in video conferencing clients. It is strongly recommended to
carry out implementation and experimentation of NADA in real-world
settings. Such exercise will provide insights on how to choose or
automatically adapt the values of the key algorithm parameters
(see list in <xref target="tab-parameters"></xref>) as discussed
in <xref target="sec-discussions"></xref>. </t>
<t>Additional experiments are suggested for the following scenarios
and preferably over real-world networks: </t>
<t><list style="symbols">
<t>Experiments reflecting the setup of a typical WAN connection. </t>
<t>Experiments with ECN marking capability turned on at the network
for existing test cases.</t>
<t>Experiments with multiple NADA streams bearing different
user-specified priorities.</t>
<t>Experiments with additional access technologies, especially
over cellular networks such as 3G/LTE.</t>
<t>Experiments with various media source contents, including audio only,
audio and video, and application content sharing (e.g., slide shows). </t>
</list></t>
</section>
<section anchor = "sec-iana"
title = "IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor = "sec-security"
title = "Security Considerations">
<t>The rate adaptation mechanism in NADA relies on feedback
from the receiver. As such, it is vulnerable to attacks where
feedback messages are hijacked, replaced, or intentionally
injected with misleading information resulting in denial of
service, similar to those that can affect TCP. It is therefore
RECOMMENDED that the RTCP feedback message is at least integrity
checked. In addition, <xref target="I-D.ietf-avtcore-cc-feedback-message"></
xref>
discusses the potential risk of a receiver providing misleading
congestion feedback information and the mechanisms for mitigating
such risks.</t>
<t>The modification
of sending rate based on send-side rate shaping buffer may
lead to temporary excessive congestion over the network
in the presence of a unresponsive video encoder. However,
this effect can be mitigated by limiting the amount of
rate modification introduced by the rate shaping buffer,
bounding the size of the rate shaping buffer at the sender,
and maintaining a maximum allowed sending rate by NADA. </t>
</section>
<section anchor = "sec-acknowledgments"
title = "Acknowledgments">
<t>
The authors would like to thank Randell Jesup, Luca De Cicco, Piers O'Hanlon,
Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, Safiqul Islam,
Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede Nielsen, Julius Flohr,
Roland Bless, Andreas Smas, and Martin Stiemerling for their valuable review
comments and helpful input to this specification. </t>
</section>
<section title="Contributors"
anchor="sec-contributors">
<t>The following individuals have contributed to the implementation
and evaluation of the proposed scheme, and therefore have helped
to validate and substantially improve this specification.</t>
<t><list>
<t>Paul E. Jones &lt;paulej@packetizer.com&gt; of Cisco Systems implemented
an early version of the NADA congestion control scheme and helped with its
lab-based testbed evaluations. </t>
<t>Jiantao Fu &lt;jianfu@cisco.com&gt; of Cisco Systems helped with the
implementation and extensive evaluation of NADA both in Mozilla web browsers
and in earlier simulation-based evaluation efforts.
</t>
<t>Stefano D'Aronco &lt;stefano.daronco@geod.baug.ethz.ch&gt; of ETH Zurich
(previously at Ecole Polytechnique Federale de Lausanne when contributing
to this work) helped with implementation and evaluation of an early version
of NADA in <xref target="ns-3"></xref>. </t>
<t>Charles Ganzhorn &lt;charles.ganzhorn@gmail.com&gt; contributed to the
testbed-based evaluation of NADA during an early stage of its development.
</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119; <!-- RFCs -->
&rfc3168; <!-- ECN -->
&rfc3550; <!-- RTP -->
&rfc5348; <!-- TFRC -->
&rfc6679; <!--- ECN over RTP -->
&rfc8174; <!--- Ambiguity of Uppercase vs Lowercase -->
</references>
<references title="Informative References">
&rfc5450;
&rfc6660; <!-- PCN -->
&rfc6817; <!-- LEDBAT -->
&rfc7567; <!-- RED -->
&rfc8033; <!-- PIE -->
&rfc8290; <!-- FQ-CoDel -->
&rfc8593; <!-- Video Traffic Model -->
<!--RMCAT related -->
&I-D.ietf-rmcat-cc-requirements;
&I-D.ietf-rmcat-cc-codec-interactions;
&I-D.ietf-rmcat-eval-test;
&I-D.ietf-rmcat-wireless-tests;
&I-D.ietf-avtcore-cc-feedback-message;
<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 Interac
tive 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-i
nterim-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>
<reference anchor="IETF-93"
target="https://www.ietf.org/proceedings/93/slides/slides-93-rmcat-0.pd
f">
<front>
<title>Updates on NADA</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>
<author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization></organization>
</author>
<date month= "July" year = "2015"/>
</front>
</reference>
<reference anchor="IETF-95"
target="https://www.ietf.org/proceedings/95/slides/slides-95-rmcat-5.pd
f">
<front>
<title>Updates on NADA: Stability Analysis and Impact of Feedback Inte
rvals</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu"> </middle>
<organization></organization>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan"> <back>
<organization></organization>
</author>
<author fullname="Michael Ramalho" initials="M." surname="Ramalho"> <displayreference target="I-D.ietf-rmcat-cc-requirements" to="RMCAT-CC"/>
<organization></organization> <displayreference target="I-D.ietf-rmcat-cc-codec-interactions"
</author> to="RMCAT-CC-RTP"/>
<displayreference target="I-D.ietf-rmcat-eval-test" to="RMCAT-EVAL-TEST"/>
<displayreference target="I-D.ietf-rmcat-wireless-tests"
to="WIRELESS-TESTS"/>
<displayreference target="I-D.ietf-avtcore-cc-feedback-message"
to="RTCP-FEEDBACK"/>
<author fullname="Sergio Mena" initials="S." surname="Mena"> <references>
<organization></organization> <name>References</name>
</author> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml"/>
<author fullname="Paul E. Jones" initials="P. E." surname="Jones"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.3168.xml"/>
</author>
<author fullname="Jiantao Fu" initials="J." surname="Fu"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.3550.xml"/>
</author>
<author fullname="Stefano D'Aronco" initials="S." surname="D'Aronco"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.5348.xml"/>
</author>
<author fullname="Charles Ganzhorn" initials="C." surname="Ganzhorn"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.6679.xml"/>
</author>
<date month= "April" year = "2016"/>
</front>
</reference>
<reference anchor="IETF-103" <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
target="https://datatracker.ietf.org/meeting/103/materials/slides-103-r C.8174.xml"/>
mcat-nada-implementation-in-mozilla-browser-00">
<front>
<title>NADA Implementation in Mozilla Browser</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu"> </references>
<organization></organization> <references>
</author> <name>Informative References</name>
<author fullname="Rong Pan" initials="R." surname="Pan"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
<organization></organization> FC.5450.xml"/>
</author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
C.6660.xml"/>
<author fullname="Michael Ramalho" initials="M." surname="Ramalho"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.6817.xml"/>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.7567.xml"/>
</author>
<author fullname="Paul E. Jones" initials="P. E." surname="Jones"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.8033.xml"/>
</author>
<author fullname="Jiantao Fu" initials="J." surname="Fu"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.8290.xml"/>
</author>
<author fullname="Stefano D'Aronco" initials="S." surname="D'Aronco"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
<organization></organization> C.8593.xml"/>
</author>
<date month= "November" year = "2018"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.iet
</front> f-rmcat-cc-requirements.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.iet
f-rmcat-cc-codec-interactions.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.iet
f-rmcat-eval-test.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.iet
f-rmcat-wireless-tests.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.iet
f-avtcore-cc-feedback-message.xml"/>
<reference anchor="IETF-105" <reference anchor="FLOYD-CCR00" target="">
target="https://datatracker.ietf.org/meeting/105/materials/slides-105-r <front>
mcat-nada-update-02.pdf"> <title>
<front> Equation-based congestion control for unicast applications
<title>NADA Implementation in Mozilla Browser and Draft Update</title> </title>
<seriesInfo name="DOI" value="10.1145/347057.347397"/>
<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="Mark Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="Jitendra Padhye" initials="J." surname="Padhye">
<organization/>
</author>
<author fullname="Jörg Widmer" initials="J." surname="Widmer">
<organization/>
</author>
<date month="October" year="2000"/>
</front>
<refcontent>ACM SIGCOMM Computer Communications Review, vol. 30,
no. 4, pp. 43-56
</refcontent>
</reference>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu"> <reference anchor="BUDZISZ-AIMD-CC" target="">
<organization></organization> <front>
</author> <title>
On the Fair Coexistence of Loss- and Delay-Based TCP
</title>
<seriesInfo name="DOI" value="10.1109/TNET.2011.2159736"/>
<author fullname="Lukasz Budzisz" initials="L." surname="Budzisz">
<organization/>
</author>
<author fullname="Rade Stanojevic" initials="R."
surname="Stanojevic">
<organization/>
</author>
<author fullname="Arieh Schlote" initials="A." surname="Schlote">
<organization/>
</author>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization/>
</author>
<author fullname="Robert Shorten" initials="R." surname="Shorten">
<organization/>
</author>
<date month="December" year="2011"/>
</front>
<refcontent>IEEE/ACM Transactions on Networking, vol. 19, no. 6,
pp. 1811-1824
</refcontent>
</reference>
<author fullname="Rong Pan" initials="R." surname="Pan"> <reference anchor="ZHU-PV13" target="">
<organization></organization> <front>
</author> <title>
NADA: A Unified Congestion Control Scheme for Low-Latency
Interactive Video
</title>
<seriesInfo name="DOI" value=" 10.1109/PV.2013.6691448"/>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization/>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization/>
</author>
<date month="December" year="2013"/>
</front>
<refcontent>Proc. IEEE International Packet Video Workshop, San
Jose, CA, USA
</refcontent>
</reference>
<author fullname="Michael Ramalho" initials="M." surname="Ramalho"> <reference anchor="NS-2"
<organization></organization> target="http://nsnam.sourceforge.net/wiki/index.php/Main_Pa
</author> ge">
<front>
<title>ns-2</title>
<author>
<organization/>
</author>
<date month="December" year="2014"/>
</front>
</reference>
<author fullname="Sergio Mena" initials="S." surname="Mena"> <reference anchor="NS-3" target="https://www.nsnam.org/">
<organization></organization> <front>
</author> <title>ns-3 Network Simulator</title>
<author>
<organization/>
</author>
</front>
</reference>
<author fullname="Paul E. Jones" initials="P. E." surname="Jones"> <reference anchor="IETF-90"
<organization></organization> target="https://tools.ietf.org/agenda/90/slides/slides-90-rmca
</author> t-6.pdf">
<front>
<title>NADA Update: Algorithm, Implementation, and Test Case
Evaluation Results</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization/>
</author>
<author fullname="Michael Ramalho" initials="M."
surname="Ramalho">
<organization/>
</author>
<author fullname="Charles Ganzhorn" initials="C."
surname="Ganzhorn">
<organization/>
</author>
<author fullname="Paul E. Jones" initials="P." surname="Jones">
<organization/>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization/>
</author>
<date month="July" year="2014"/>
</front>
<refcontent>IETF 90
</refcontent>
</reference>
<author fullname="Jiantao Fu" initials="J." surname="Fu"> <reference anchor="IETF-91"
<organization></organization> target="https://www.ietf.org/proceedings/interim/2014/11/09/rm
</author> cat/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/>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization/>
</author>
<author fullname="Michael Ramalho" initials="M."
surname="Ramalho">
<organization/>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena">
<organization/>
</author>
<author fullname="Charles Ganzhorn" initials="C."
surname="Ganzhorn">
<organization/>
</author>
<author fullname="Paul E. Jones" initials="P." surname="Jones">
<organization/>
</author>
<author fullname="Stefano D'Aronco" initials="S."
surname="D'Aronco">
<organization/>
</author>
<date month="November" year="2014"/>
</front>
<refcontent>IETF 91
</refcontent>
</reference>
<author fullname="Stefano D'Aronco" initials="S." surname="D'Aronco"> <reference anchor="IETF-93"
<organization></organization> target="https://www.ietf.org/proceedings/93/slides/slides-93-r
</author> mcat-0.pdf">
<front>
<title>Updates on NADA</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization/>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization/>
</author>
<author fullname="Michael Ramalho" initials="M."
surname="Ramalho">
<organization/>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena">
<organization/>
</author>
<author fullname="Charles Ganzhorn" initials="C."
surname="Ganzhorn">
<organization/>
</author>
<author fullname="Paul E. Jones" initials="P." surname="Jones">
<organization/>
</author>
<author fullname="Stefano D'Aronco" initials="S."
surname="D'Aronco">
<organization/>
</author>
<author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization/>
</author>
<date month="July" year="2015"/>
</front>
<refcontent>IETF 93
</refcontent>
</reference>
<date month= "July" year = "2019"/> <reference anchor="IETF-95"
</front> target="https://www.ietf.org/proceedings/95/slides/slides-95-r
</reference> mcat-5.pdf">
<front>
<title>Updates on NADA: Stability Analysis and Impact of Feedback
Intervals</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization/>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization/>
</author>
<author fullname="Michael Ramalho" initials="M."
surname="Ramalho">
<organization/>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena">
<organization/>
</author>
<author fullname="Paul E. Jones" initials="P." surname="Jones">
<organization/>
</author>
<author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization/>
</author>
<author fullname="Stefano D'Aronco" initials="S."
surname="D'Aronco">
<organization/>
</author>
<author fullname="Charles Ganzhorn" initials="C."
surname="Ganzhorn">
<organization/>
</author>
<date month="April" year="2016"/>
</front>
<refcontent>IETF 95
</refcontent>
</reference>
<reference anchor="ns3-rmcat" <reference anchor="IETF-103"
target="https://github.com/cisco/ns3-rmcat"> target="https://datatracker.ietf.org/meeting/103/materials/sli
<front> des-103-rmcat-nada-implementation-in-mozilla-browser-00">
<title>NS3 open source module of IETF RMCAT congestion control protocols</titl <front>
e> <title>NADA Implementation in Mozilla Browser</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization/>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization/>
</author>
<author fullname="Michael Ramalho" initials="M."
surname="Ramalho">
<organization/>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena">
<organization/>
</author>
<author fullname="Paul E. Jones" initials="P." surname="Jones">
<organization/>
</author>
<author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization/>
</author>
<author fullname="Stefano D'Aronco" initials="S."
surname="D'Aronco">
<organization/>
</author>
<date month="November" year="2018"/>
</front>
<refcontent>IETF 103
</refcontent>
</reference>
<author fullname="Jiantao Fu" initials="J." surname="Fu"> <reference anchor="IETF-105"
<organization></organization> target="https://datatracker.ietf.org/meeting/105/materials/sli
</author> des-105-rmcat-nada-update-02.pdf">
<front>
<title>NADA Implementation in Mozilla Browser and Draft
Update</title>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization/>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization/>
</author>
<author fullname="Michael Ramalho" initials="M."
surname="Ramalho">
<organization/>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena">
<organization/>
</author>
<author fullname="Paul E. Jones" initials="P." surname="Jones">
<organization/>
</author>
<author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization/>
</author>
<author fullname="Stefano D'Aronco" initials="S."
surname="D'Aronco">
<organization/>
</author>
<date month="July" year="2019"/>
</front>
<refcontent>IETF 105
</refcontent>
</reference>
<author fullname="Sergio Mena" initials="S." surname="Mena"> <reference anchor="NS3-RMCAT"
<organization></organization> target="https://github.com/cisco/ns3-rmcat">
</author> <front>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu"> <title>Simulator of IETF RMCAT congestion control
<organization></organization> protocols</title>
</author> <author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization/>
</author>
<author fullname="Sergio Mena" initials="S." surname="Mena">
<organization/>
</author>
<author fullname="Xiaoqing Zhu" initials="X." surname="Zhu">
<organization/>
</author>
<date month="November" year="2017"/>
</front>
</reference>
<date month= "November" year = "2017"/> </references>
</front>
</reference>
</references> </references>
<section anchor="sec-network-nodes" numbered="true" toc="default">
<section anchor="sec-network-nodes" <name>Network Node Operations</name>
title="Network Node Operations"> <t>NADA can work with different network queue management
<t>NADA can work with different network queue management
schemes and does not assume any specific network node operation. schemes and does not assume any specific network node operation.
As an example, this appendix describes three variants of queue As an example, this appendix describes three variants of queue
management behavior at the network node, leading to either management behavior at the network node, leading to either
implicit or explicit congestion signals. It needs to be implicit or explicit congestion signals. It needs to be
acknowledged that NADA has not yet been tested with non-probabilistic acknowledged that NADA has not yet been tested with non-probabilistic
ECN marking behaviors. ECN marking behaviors.
</t> </t>
<t>
<t>
In all three flavors described below, the network queue In all three flavors described below, the network queue
operates with the simple first-in-first-out (FIFO) principle. operates with the simple First In, First Out (FIFO) principle.
There is no need to maintain per-flow state. The system There is no need to maintain per-flow state. The system
can scale easily with a large number of video flows and can scale easily with a large number of video flows and
at high link capacity. at high link capacity.
</t> </t>
<section anchor="sec-network-droptail" numbered="true" toc="default">
<section anchor="sec-network-droptail" <name>Default Behavior of Drop-Tail Queues</name>
title="Default behavior of drop tail queues"> <t>
In a conventional network with drop-tail or RED queues,
<t>
In a conventional network with drop tail or RED queues,
congestion is inferred from the estimation of end-to-end congestion is inferred from the estimation of end-to-end
delay and/or packet loss. Packet drops at the queue are delay and/or packet loss. Packet drops at the queue are
detected at the receiver, and contributes to the calculation detected at the receiver and contribute to the calculation
of the aggregated congestion signal x_curr. No special of the aggregated congestion signal x_curr. No special
action is required at network node. action is required at the network node.
</t> </t>
</section>
</section> <section anchor="sec-network-ecn" numbered="true" toc="default">
<name>RED-Based ECN Marking</name>
<section anchor="sec-network-ecn" <t>In this mode, the network node randomly marks
title="RED-based ECN marking">
<t>In this mode, the network node randomly marks
the ECN field in the IP packet header following the ECN field in the IP packet header following
the <xref target="RFC7567">Random Early Detection the <xref target="RFC7567" format="default">Random Early Detection
(RED) algorithm</xref>. Calculation of the marking (RED) algorithm</xref>. Calculation of the marking
probability involves the following steps:</t> probability involves the following steps on packet arrival:</t>
<t><figure><artwork><![CDATA[ <ol spacing="normal" type="1">
on packet arrival:
update smoothed queue size q_avg as:
q_avg = w*q + (1-w)*q_avg.
calculate marking probability p as: <li><t>update smoothed queue size q_avg as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
q_avg = w*q + (1-w)*q_avg
]]></artwork>
</li>
/ 0, if q < q_lo; <li><t>calculate marking probability p as:</t>
| <artwork name="" type="" align="left" alt=""><![CDATA[
| q_avg - q_lo / 0, if q < q_lo
p= < p_max*--------------, if q_lo <= q < q_hi; |
| q_hi - q_lo | q_avg - q_lo
| p= < p_max*--------------, if q_lo <= q < q_hi
\ p = 1, if q >= q_hi. | q_hi - q_lo
]]></artwork></figure></t> |
\ p = 1, if q >= q_hi
]]></artwork>
</li>
</ol>
<t> <t>
Here, q_lo and q_hi corresponds to the low Here, q_lo and q_hi correspond to the low
and high thresholds of queue occupancy. and high thresholds of queue occupancy.
The maximum marking probability is p_max. The maximum marking probability is p_max.
</t> </t>
<t>
<t> The ECN marking events will contribute
The ECN markings events will contribute
to the calculation of an equivalent delay to the calculation of an equivalent delay
x_curr at the receiver. No changes are required x_curr at the receiver. No changes are required
at the sender. at the sender.
</t> </t>
</section>
</section> <section anchor="sec-network-pcn" numbered="true" toc="default">
<name>Random Early Marking with Virtual Queues</name>
<section anchor = "sec-network-pcn" <t>
title = "Random Early Marking with Virtual Queues">
<t>
Advanced network nodes may support random early marking Advanced network nodes may support random early marking
based on a token bucket algorithm originally designed for based on a token bucket algorithm originally designed for
<xref target="RFC6660">Pre-Congestion Notification (PCN)</xref>. <xref target="RFC6660" format="default">Pre-Congestion Notification
(PCN)</xref>.
The early congestion notification (ECN) bit in the The early congestion notification (ECN) bit in the
IP header of packets are marked randomly. IP header of packets is marked randomly.
The marking probability is calculated based on a The marking probability is calculated based on a
token-bucket algorithm originally designed for the token bucket algorithm originally designed for
<xref target="RFC6660">Pre-Congestion Notification (PCN)</xref>. <xref target="RFC6660" format="default">PCN</xref>.
The target link utilization is set as 90%; the marking The target link utilization is set as 90%; the marking
probability is designed to grow linearly with the token probability is designed to grow linearly with the token
bucket size when it varies between 1/3 and 2/3 of the bucket size when it varies between 1/3 and 2/3 of the
full token bucket limit.</t> full token bucket limit.</t>
<t>Calculation of the marking probability involves
the following steps upon packet arrival:</t>
<t>Calculation of the marking probability involves <ol spacing="normal" type="1">
the following steps:</t>
<t><figure><artwork><![CDATA[
upon packet arrival:
meter packet against token bucket (r,b);
update token level b_tk; <li><t>meter packet against token bucket (r,b)</t></li>;
calculate the marking probability as: <li><t>update token level b_tk</t></li>
/ 0, if b-b_tk < b_lo; <li><t>calculate the marking probability as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
/ 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
]]></artwork> ]]></artwork>
</figure></t> </li>
</ol>
<t> <t>
Here, the token bucket lower and upper limits are denoted by Here, the token bucket lower and upper limits are denoted by
b_lo and b_hi, respectively. The parameter b indicates the size b_lo and b_hi, respectively. The parameter b indicates the size
of the token bucket. The parameter r is chosen to be below of the token bucket. The parameter r is chosen to be below
capacity, resulting in slight under-utilization of the link. capacity, resulting in slight underutilization of the link.
The maximum marking probability is p_max. The maximum marking probability is p_max.
</t> </t>
<t>The ECN markings events will contribute to the calculation <t>The ECN marking events will contribute to the calculation
of an equivalent delay x_curr at the receiver. No changes are of an equivalent delay x_curr at the receiver. No changes are
required at the sender. The virtual queuing mechanism from required at the sender. The virtual queuing mechanism from
the PCN-based marking algorithm will lead to additional the PCN-based marking algorithm will lead to additional
benefits such as zero standing queues. benefits such as zero standing queues.
</t> </t>
</section>
</section> </section>
<section anchor="sec-acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors would like to thank <contact fullname="Randell Jesup"/>, <contact
fullname="Luca De Cicco"/>, <contact fullname="Piers O'Hanlon"/>, <contact
fullname="Ingemar Johansson"/>, <contact fullname="Stefan Holmer"/>, <contact
fullname="Cesar Ilharco Magalhaes"/>, <contact fullname="Safiqul Islam"/>,
<contact fullname="Michael Welzl"/>, <contact fullname="Mirja Kuehlewind"/>,
<contact fullname="Karen Elisabeth Egede Nielsen"/>, <contact fullname="Julius
Flohr"/>, <contact fullname="Roland Bless"/>, <contact fullname="Andreas
Smas"/>, and <contact fullname="Martin Stiemerling"/> for their valuable
review comments and helpful input to this specification. </t>
</section>
<section anchor="sec-contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>The following individuals contributed to the implementation
and evaluation of the proposed scheme and, therefore, helped
to validate and substantially improve this specification.</t>
<t><contact fullname="Paul E.&nbsp;Jones"/>
&lt;paulej@packetizer.com&gt; of Cisco Systems implemented
an early version of the NADA congestion control scheme and helped with its
lab-based testbed evaluations. </t>
<t><contact fullname="Jiantao Fu"/> &lt;jianfu@cisco.com&gt; of Cisco
Systems helped with the
implementation and extensive evaluation of NADA both in Mozilla web browsers
and in earlier simulation-based evaluation efforts.
</t>
<t><contact fullname="Stefano D'Aronco"/>
&lt;stefano.daronco@geod.baug.ethz.ch&gt; of ETH Zurich
(previously at Ecole Polytechnique Federale de Lausanne when contributing
to this work) helped with the implementation and evaluation of an early
version
of NADA in <xref target="NS-3" format="default"/>. </t>
<t><contact fullname="Charles Ganzhorn"/>
&lt;charles.ganzhorn@gmail.com&gt; contributed to the
testbed-based evaluation of NADA during an early stage of its development.
</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 229 change blocks. 
1447 lines changed or deleted 1544 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/