File: rfc8698.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2992 lines) | stat: -rw-r--r-- 145,600 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8698: Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media</title>
<meta content="Xiaoqing Zhu" name="author">
<meta content="Rong Pan" name="author">
<meta content="Michael A. Ramalho" name="author">
<meta content="Sergio Mena" name="author">
<meta content="
       This document describes Network-Assisted Dynamic Adaptation (NADA), a
      novel congestion control scheme for interactive real-time media
      applications such as video conferencing. In the proposed scheme, the
      sender regulates its sending rate, based on either implicit or explicit
      congestion signaling, in a unified approach. The scheme can benefit from
      Explicit Congestion Notification (ECN) markings from network nodes. It
      also maintains consistent sender behavior in the absence of such
      markings by reacting to queuing delays and packet losses instead.  
    " name="description">
<meta content="xml2rfc 2.39.0" name="generator">
<meta content="Multimedia" name="keyword">
<meta content="Congestion Control" name="keyword">
<meta content="8698" name="rfc.number">
<link href="rfc8698.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/*
  The margin-left: 0 on <dd> removes all distinction
  between levels from nested <dl>s.  Undo that.
*/
dl.olPercent > dd,
dd {
  margin-left: revert;
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8698" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada-13" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8698</td>
<td class="center">NADA</td>
<td class="right">February 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Zhu, et al.</td>
<td class="center">Experimental</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8698" class="eref">8698</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-02" class="published">February 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">X. Zhu</div>
<div class="org">Cisco Systems</div>
</div>
<div class="author">
      <div class="author-name">R. Pan</div>
<div class="org">Intel Corporation</div>
</div>
<div class="author">
      <div class="author-name">M. Ramalho</div>
<div class="org">AcousticComms</div>
</div>
<div class="author">
      <div class="author-name">S. Mena</div>
<div class="org">Cisco Systems</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8698</h1>
<h1 id="title">Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes Network-Assisted Dynamic Adaptation (NADA), a
      novel congestion control scheme for interactive real-time media
      applications such as video conferencing. In the proposed scheme, the
      sender regulates its sending rate, based on either implicit or explicit
      congestion signaling, in a unified approach. The scheme can benefit from
      Explicit Congestion Notification (ECN) markings from network nodes. It
      also maintains consistent sender behavior in the absence of such
      markings by reacting to queuing delays and packet losses instead.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This document is a product of the Internet Engineering
            Task Force (IETF).  It represents the consensus of the IETF community.
            It has received public review and has been approved for publication
            by the Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8698">https://www.rfc-editor.org/info/rfc8698</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-system-overview" class="xref">System Overview</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-core-congestion-control-alg" class="xref">Core Congestion Control Algorithm</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-mathematical-notations" class="xref">Mathematical Notations</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-receiver-side-algorithm" class="xref">Receiver-Side Algorithm</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-sender-side-algorithm" class="xref">Sender-Side Algorithm</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-practical-implementation-of" class="xref">Practical Implementation of NADA</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-receiver-side-operation" class="xref">Receiver-Side Operation</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1.2.1">
                    <p id="section-toc.1-1.5.2.1.2.1.1"><a href="#section-5.1.1" class="xref">5.1.1</a>.  <a href="#name-estimation-of-one-way-delay" class="xref">Estimation of One-Way Delay and Queuing Delay</a><a href="#section-toc.1-1.5.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1.2.2">
                    <p id="section-toc.1-1.5.2.1.2.2.1"><a href="#section-5.1.2" class="xref">5.1.2</a>.  <a href="#name-estimation-of-packet-loss-m" class="xref">Estimation of Packet Loss/Marking Ratio</a><a href="#section-toc.1-1.5.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1.2.3">
                    <p id="section-toc.1-1.5.2.1.2.3.1"><a href="#section-5.1.3" class="xref">5.1.3</a>.  <a href="#name-estimation-of-receiving-rat" class="xref">Estimation of Receiving Rate</a><a href="#section-toc.1-1.5.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-sender-side-operation" class="xref">Sender-Side Operation</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-rate-shaping-buffer" class="xref">Rate-Shaping Buffer</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-adjusting-video-target-rate" class="xref">Adjusting Video Target Rate and Sending Rate</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-feedback-message-requiremen" class="xref">Feedback Message Requirements</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-discussions-and-further-inv" class="xref">Discussions and Further Investigations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-choice-of-delay-metrics" class="xref">Choice of Delay Metrics</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-method-for-delay-loss-and-m" class="xref">Method for Delay, Loss, and Marking Ratio Estimation</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-impact-of-parameter-values" class="xref">Impact of Parameter Values</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-sender-based-vs-receiver-ba" class="xref">Sender-Based vs. Receiver-Based Calculation</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-incremental-deployment" class="xref">Incremental Deployment</a><a href="#section-toc.1-1.6.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-reference-implementations" class="xref">Reference Implementations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-suggested-experiments" class="xref">Suggested Experiments</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-network-node-operations" class="xref">Network Node Operations</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-default-behavior-of-drop-ta" class="xref">Default Behavior of Drop-Tail Queues</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-red-based-ecn-marking" class="xref">RED-Based ECN Marking</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12.2.3">
                <p id="section-toc.1-1.12.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-random-early-marking-with-v" class="xref">Random Early Marking with Virtual Queues</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="sec-intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Interactive real-time media applications introduce a unique set of
      challenges for congestion control. Unlike TCP, the mechanism used for
      real-time media needs to adapt quickly to instantaneous bandwidth
      changes, accommodate fluctuations in the output of video encoder rate
      control, and cause low queuing delay over the network. An ideal scheme
      should also make effective use of all types of congestion signals,
      including packet loss, queuing delay, and explicit congestion
      notification (ECN) <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span>
      markings. The requirements for the congestion control algorithm are
      outlined in <span>[<a href="#I-D.ietf-rmcat-cc-requirements" class="xref">RMCAT-CC</a>]</span>.

    The requirements highlight that the desired congestion control scheme
    should 1) avoid flow starvation and attain a reasonable fair share of
    bandwidth when competing against other flows, 2) adapt quickly, and 3)
    operate in a stable manner.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This document describes an experimental congestion control scheme
    called Network-Assisted Dynamic Adaptation (NADA). The design of NADA
    benefits from explicit congestion control signals (e.g., ECN markings)
    from the network, yet also operates when only implicit congestion
    indicators (delay and/or loss) are available. Such a unified sender
    behavior distinguishes NADA from other congestion control schemes for
    real-time media. In addition, its core congestion control algorithm is
    designed to guarantee stability for path round-trip times (RTTs) below
    a prescribed bound (e.g., 250 ms with default parameter choices). It
    further supports weighted bandwidth sharing among competing video flows
    with different priorities. The signaling mechanism consists of standard
    Real-time Transport Protocol (RTP) timestamp <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> and Real-time
    Transport Control Protocol (RTCP) feedback reports.
    The definition of the desired RTCP feedback message is described in
    detail in <span>[<a href="#I-D.ietf-avtcore-cc-feedback-message" class="xref">RTCP-FEEDBACK</a>]</span>
    so as to support the successful operation of several congestion control
    schemes for real-time interactive media.<a href="#section-1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-term">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-system-overview">
<section id="section-3">
      <h2 id="name-system-overview">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-system-overview" class="section-name selfRef">System Overview</a>
      </h2>
<p id="section-3-1"><a href="#fig-system-overview" class="xref">Figure 1</a> shows the
      end-to-end
    system for real-time media transport that NADA operates in. Note that
    there also exist network nodes along the reverse (potentially uncongested)
    path that the RTCP feedback reports traverse. Those network nodes are not
    shown in the figure for the sake of brevity.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span id="name-system-overview-2"></span><div id="fig-system-overview">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-3-2.1">
<pre>
  +---------+  r_vin  +--------+        +--------+     +----------+
  |  Media  |&lt;--------|  RTP   |        |Network |     |   RTP    |
  | Encoder |========&gt;| Sender |=======&gt;|  Node  |====&gt;| Receiver |  
  +---------+  r_vout +--------+ r_send +--------+     +----------+
                          /|\                                |
                           |                                 |
                           +---------------------------------+
                                 RTCP Feedback Report
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-system-overview-2" class="selfRef">System Overview</a>
        </figcaption></figure>
</div>
<dl class="dlParallel" id="section-3-3">
        <dt id="section-3-3.1">Media encoder with rate control capabilities:
</dt>
<dd id="section-3-3.2">Encodes raw media (audio and video) frames into a compressed bitstream
that is later packetized into RTP packets. As discussed in <span>[<a href="#RFC8593" class="xref">RFC8593</a>]</span>, 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.<a href="#section-3-3.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.3">RTP sender:
</dt>
<dd id="section-3-3.4">Responsible for calculating the NADA reference rate based on network
congestion indicators (delay, loss, or ECN marking reports from the receiver),
for updating the video encoder with a new target rate r_vin and for
regulating the actual sending rate r_send accordingly. The RTP sender also
generates a sending timestamp for each outgoing packet.<a href="#section-3-3.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.5">RTP receiver:
</dt>
<dd id="section-3-3.6">Responsible for measuring and estimating end-to-end delay (based on sender
timestamp), packet loss (based on RTP sequence number), ECN marking ratios
(based on <span>[<a href="#RFC6679" class="xref">RFC6679</a>]</span>), and receiving rate (r_recv) of the
flow. It calculates
the aggregated congestion signal (x_curr) that accounts for queuing delay, ECN
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.<a href="#section-3-3.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.7">Network node with several modes of operation:
</dt>
<dd id="section-3-3.8">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 <span><a href="#RFC8033" class="xref">(PIE)</a> [<a href="#RFC8033" class="xref">RFC8033</a>]</span>, Flow Queue Controlling Queue Delay <span><a href="#RFC8290" class="xref">(FQ-CoDel)</a> [<a href="#RFC8290" class="xref">RFC8290</a>]</span>, ECN
marking based on <span><a href="#RFC7567" class="xref">Random Early Detection (RED)</a> [<a href="#RFC7567" class="xref">RFC7567</a>]</span>,
and Pre-Congestion Notification (PCN) marking using a
token bucket algorithm <span>[<a href="#RFC6660" class="xref">RFC6660</a>]</span>. Note that network node
operation is out of scope for the design of NADA.<a href="#section-3-3.8" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<div id="sec-algorithm">
<section id="section-4">
      <h2 id="name-core-congestion-control-alg">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-core-congestion-control-alg" class="section-name selfRef">Core Congestion Control Algorithm</a>
      </h2>
<p id="section-4-1">Like TCP-Friendly Rate Control (TFRC) <span>[<a href="#FLOYD-CCR00" class="xref">FLOYD-CCR00</a>]</span>
        <span>[<a href="#RFC5348" class="xref">RFC5348</a>]</span>, NADA is a rate-based
 congestion
  control algorithm. In its simplest form, the sender reacts to the
  collection of network congestion indicators in the form of an
  aggregated congestion signal and operates in one of two modes:<a href="#section-4-1" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4-2">
        <dt id="section-4-2.1">Accelerated ramp up:
</dt>
<dd id="section-4-2.2">When the bottleneck is deemed to be underutilized, the rate increases
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.<a href="#section-4-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4-2.3">Gradual rate update:
</dt>
<dd id="section-4-2.4">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).<a href="#section-4-2.4" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-4-3">This section introduces the list of mathematical notations and
  describes the core congestion control algorithm at the sender and
  receiver, respectively. Additional details on recommended practical
  implementations are described in Sections <a href="#sec-receiver" class="xref">5.1</a>
  and <a href="#sec-sender" class="xref">5.2</a>.<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="sec-notation">
<section id="section-4.1">
        <h3 id="name-mathematical-notations">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-mathematical-notations" class="section-name selfRef">Mathematical Notations</a>
        </h3>
<p id="section-4.1-1">This section summarizes the list of variables and parameters used
        in the NADA algorithm. <a href="#tab-parameters" class="xref">Table 2</a> also includes the default values for choosing the
        algorithm parameters to represent either a typical setting in
        practical applications or a setting based on theoretical and
        simulation studies.  See <a href="#sec-discussion-c" class="xref">Section 6.3</a> for some of the discussions on the impact of
        parameter values. Additional studies in real-world settings suggested
        in <a href="#sec-experiments" class="xref">Section 8</a> could gather
        further insight on how to choose and adapt these parameter values in
        practical deployment.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<span id="name-list-of-variables"></span><div id="tab-variables">
<table class="left" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-list-of-variables" class="selfRef">List of Variables</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Notation</th>
              <th class="text-left" rowspan="1" colspan="1">Variable Name</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">t_curr</td>
              <td class="text-left" rowspan="1" colspan="1">Current timestamp</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">t_last</td>
              <td class="text-left" rowspan="1" colspan="1">Last time sending/receiving a feedback message</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">delta</td>
              <td class="text-left" rowspan="1" colspan="1">Observed interval between current and previous
      feedback reports: delta = t_curr-t_last</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">r_ref</td>
              <td class="text-left" rowspan="1" colspan="1">Reference rate based on network congestion</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">r_send</td>
              <td class="text-left" rowspan="1" colspan="1">Sending rate</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">r_recv</td>
              <td class="text-left" rowspan="1" colspan="1">Receiving rate</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">r_vin</td>
              <td class="text-left" rowspan="1" colspan="1">Target rate for video encoder</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">r_vout</td>
              <td class="text-left" rowspan="1" colspan="1">Output rate from video encoder</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">d_base</td>
              <td class="text-left" rowspan="1" colspan="1">Estimated baseline delay</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">d_fwd</td>
              <td class="text-left" rowspan="1" colspan="1">Measured and filtered one-way delay</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">d_queue</td>
              <td class="text-left" rowspan="1" colspan="1">Estimated queuing delay</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">d_tilde</td>
              <td class="text-left" rowspan="1" colspan="1">Equivalent delay after non-linear warping</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">p_mark</td>
              <td class="text-left" rowspan="1" colspan="1">Estimated packet ECN marking ratio</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">p_loss</td>
              <td class="text-left" rowspan="1" colspan="1">Estimated packet loss ratio</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">x_curr</td>
              <td class="text-left" rowspan="1" colspan="1">Aggregate congestion signal</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">x_prev</td>
              <td class="text-left" rowspan="1" colspan="1">Previous value of aggregate congestion signal</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">x_diff</td>
              <td class="text-left" rowspan="1" colspan="1">Change in aggregate congestion signal w.r.t. its
      previous value: x_diff = x_curr - x_prev</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">rmode</td>
              <td class="text-left" rowspan="1" colspan="1">Rate update mode: (0 = accelerated ramp up; 1 =
      gradual update)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">gamma</td>
              <td class="text-left" rowspan="1" colspan="1">Rate increase multiplier in accelerated ramp-up
      mode</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">loss_int</td>
              <td class="text-left" rowspan="1" colspan="1">Measured average loss interval in packet count</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">loss_exp</td>
              <td class="text-left" rowspan="1" colspan="1">Threshold value for setting the last observed packet
      loss to expiration</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">rtt</td>
              <td class="text-left" rowspan="1" colspan="1">Estimated round-trip time at sender</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">buffer_len</td>
              <td class="text-left" rowspan="1" colspan="1">Rate-shaping buffer occupancy measured in bytes</td>
            </tr>
          </tbody>
        </table>
</div>
<span id="name-list-of-algorithm-parameter"></span><div id="tab-parameters">
<table class="left" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-list-of-algorithm-parameter" class="selfRef">List of Algorithm Parameters and Their Default Values</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Notation</th>
              <th class="text-left" rowspan="1" colspan="1">Parameter Name</th>
              <th class="text-left" rowspan="1" colspan="1">Default Value</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PRIO</td>
              <td class="text-left" rowspan="1" colspan="1">Weight of priority of the flow</td>
              <td class="text-left" rowspan="1" colspan="1">1.0</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">RMIN</td>
              <td class="text-left" rowspan="1" colspan="1">Minimum rate of application supported by media
      encoder</td>
              <td class="text-left" rowspan="1" colspan="1">150 Kbps</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">RMAX</td>
              <td class="text-left" rowspan="1" colspan="1">Maximum rate of application supported by media
      encoder</td>
              <td class="text-left" rowspan="1" colspan="1">1.5 Mbps</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">XREF</td>
              <td class="text-left" rowspan="1" colspan="1">Reference congestion level</td>
              <td class="text-left" rowspan="1" colspan="1">10 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">KAPPA</td>
              <td class="text-left" rowspan="1" colspan="1">Scaling parameter for gradual rate update
      calculation</td>
              <td class="text-left" rowspan="1" colspan="1">0.5</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ETA</td>
              <td class="text-left" rowspan="1" colspan="1">Scaling parameter for gradual rate update
      calculation</td>
              <td class="text-left" rowspan="1" colspan="1">2.0</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">TAU</td>
              <td class="text-left" rowspan="1" colspan="1">Upper bound of RTT in gradual rate update
      calculation</td>
              <td class="text-left" rowspan="1" colspan="1">500 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DELTA</td>
              <td class="text-left" rowspan="1" colspan="1">Target feedback interval</td>
              <td class="text-left" rowspan="1" colspan="1">100 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LOGWIN</td>
              <td class="text-left" rowspan="1" colspan="1">Observation window in time for calculating packet
      summary statistics at receiver</td>
              <td class="text-left" rowspan="1" colspan="1">500 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">QEPS</td>
              <td class="text-left" rowspan="1" colspan="1">Threshold for determining queuing delay buildup at
      receiver</td>
              <td class="text-left" rowspan="1" colspan="1">10 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DFILT</td>
              <td class="text-left" rowspan="1" colspan="1">Bound on filtering delay</td>
              <td class="text-left" rowspan="1" colspan="1">120 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">GAMMA_MAX</td>
              <td class="text-left" rowspan="1" colspan="1">Upper bound on rate increase ratio for accelerated ramp
      up</td>
              <td class="text-left" rowspan="1" colspan="1">0.5</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">QBOUND</td>
              <td class="text-left" rowspan="1" colspan="1">Upper bound on self-inflicted queuing delay during ramp
      up</td>
              <td class="text-left" rowspan="1" colspan="1">50 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">MULTILOSS</td>
              <td class="text-left" rowspan="1" colspan="1">Multiplier for self-scaling the expiration threshold of
      the last observed loss (loss_exp) based on measured average loss
      interval (loss_int)</td>
              <td class="text-left" rowspan="1" colspan="1">7.0</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">QTH</td>
              <td class="text-left" rowspan="1" colspan="1">Delay threshold for invoking non-linear warping</td>
              <td class="text-left" rowspan="1" colspan="1">50 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LAMBDA</td>
              <td class="text-left" rowspan="1" colspan="1">Scaling parameter in the exponent of non-linear
      warping</td>
              <td class="text-left" rowspan="1" colspan="1">0.5</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PLRREF</td>
              <td class="text-left" rowspan="1" colspan="1">Reference packet loss ratio</td>
              <td class="text-left" rowspan="1" colspan="1">0.01</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PMRREF</td>
              <td class="text-left" rowspan="1" colspan="1">Reference packet marking ratio</td>
              <td class="text-left" rowspan="1" colspan="1">0.01</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DLOSS</td>
              <td class="text-left" rowspan="1" colspan="1">Reference delay penalty for loss when packet loss ratio
      is at PLRREF</td>
              <td class="text-left" rowspan="1" colspan="1">10 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DMARK</td>
              <td class="text-left" rowspan="1" colspan="1">Reference delay penalty for ECN marking when packet
      marking is at PMRREF</td>
              <td class="text-left" rowspan="1" colspan="1">2 ms</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">FPS</td>
              <td class="text-left" rowspan="1" colspan="1">Frame rate of incoming video</td>
              <td class="text-left" rowspan="1" colspan="1">30</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">BETA_S</td>
              <td class="text-left" rowspan="1" colspan="1">Scaling parameter for modulating outgoing sending
      rate</td>
              <td class="text-left" rowspan="1" colspan="1">0.1</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">BETA_V</td>
              <td class="text-left" rowspan="1" colspan="1">Scaling parameter for modulating video encoder target
      rate</td>
              <td class="text-left" rowspan="1" colspan="1">0.1</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ALPHA</td>
              <td class="text-left" rowspan="1" colspan="1">Smoothing factor in exponential smoothing of packet
      loss and marking ratios</td>
              <td class="text-left" rowspan="1" colspan="1">0.1</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="subsec-receiver-algorithm">
<section id="section-4.2">
        <h3 id="name-receiver-side-algorithm">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-receiver-side-algorithm" class="section-name selfRef">Receiver-Side Algorithm</a>
        </h3>
<p id="section-4.2-1">The receiver-side algorithm can be outlined as below:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2-2.1">On initialization:<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.2">
            <ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2-2.2.1.1">set d_base = +INFINITY<a href="#section-4.2-2.2.1.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.2.1.2">set p_loss = 0<a href="#section-4.2-2.2.1.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.2.1.3">set p_mark = 0<a href="#section-4.2-2.2.1.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.2.1.4">set r_recv = 0<a href="#section-4.2-2.2.1.4" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.2.1.5">set both t_last and t_curr as current time in milliseconds<a href="#section-4.2-2.2.1.5" class="pilcrow">¶</a>
</li>
</ul>
</li>
<li class="ulEmpty" id="section-4.2-2.3">On receiving a media packet:<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4">
            <ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2-2.4.1.1">obtain current timestamp t_curr from system clock<a href="#section-4.2-2.4.1.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4.1.2">obtain from packet header sending time stamp t_sent<a href="#section-4.2-2.4.1.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4.1.3">obtain one-way delay measurement: d_fwd = t_curr - t_sent<a href="#section-4.2-2.4.1.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4.1.4">update baseline delay: d_base = min(d_base, d_fwd)<a href="#section-4.2-2.4.1.4" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4.1.5">update queuing delay:  d_queue = d_fwd - d_base<a href="#section-4.2-2.4.1.5" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4.1.6">update packet loss ratio estimate p_loss<a href="#section-4.2-2.4.1.6" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4.1.7">update packet marking ratio estimate p_mark<a href="#section-4.2-2.4.1.7" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.4.1.8">update measurement of receiving rate r_recv<a href="#section-4.2-2.4.1.8" class="pilcrow">¶</a>
</li>
</ul>
</li>
<li class="ulEmpty" id="section-4.2-2.5">On time to send a new feedback report (t_curr - t_last &gt; DELTA):<a href="#section-4.2-2.5" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.6">
            <ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2-2.6.1.1">calculate non-linear warping of delay d_tilde if packet loss exists<a href="#section-4.2-2.6.1.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.6.1.2">calculate current aggregate congestion signal x_curr<a href="#section-4.2-2.6.1.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.6.1.3">determine mode of rate adaptation for sender: rmode<a href="#section-4.2-2.6.1.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.6.1.4">send feedback containing values of: rmode, x_curr, and r_recv<a href="#section-4.2-2.6.1.4" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.2-2.6.1.5">update t_last = t_curr<a href="#section-4.2-2.6.1.5" class="pilcrow">¶</a>
</li>
</ul>
</li>
</ul>
<p id="section-4.2-3">In order for a delay-based flow to hold its ground when competing
   against loss-based flows (e.g., loss-based TCP), it is important
   to distinguish between different levels of observed queuing delay.
   For instance, over wired connections, a moderate queuing delay value
   on the order of tens of milliseconds is likely self-inflicted or
   induced by other delay-based flows, whereas a high queuing delay
   value of several hundreds of milliseconds may indicate the presence
   of a loss-based flow that does not refrain from increased delay.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4"> If the last observed packet loss is within the expiration 
window of loss_exp (measured in terms of packet counts), the
estimated queuing delay follows a non-linear warping:<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.2-5">
<pre>
           / d_queue,                   if d_queue &lt; QTH
           |
d_tilde = &lt;                                           (1)
           |                  (d_queue-QTH)  
           \ QTH exp(-LAMBDA ---------------) , otherwise
                                 QTH    </pre><a href="#section-4.2-5" class="pilcrow">¶</a>
</div>
<p id="section-4.2-6">
In Equation (1), the queuing delay value is unchanged when it is below
the first threshold QTH; otherwise, it is scaled down following
a non-linear curve. This non-linear warping is inspired by
the delay-adaptive congestion window backoff policy in
<span>[<a href="#BUDZISZ-AIMD-CC" class="xref">BUDZISZ-AIMD-CC</a>]</span> so as to "gradually nudge"
the controller to operate based on loss-induced congestion
signals when competing against loss-based flows. The exact form
of the non-linear function has been simplified with respect to
<span>[<a href="#BUDZISZ-AIMD-CC" class="xref">BUDZISZ-AIMD-CC</a>]</span>. The value of the threshold
QTH should be carefully tuned for different operational environments
so as to avoid potential risks of prematurely discounting the congestion
signal level. Typically, a higher value of QTH is required in a
noisier environment (e.g., over wireless connections or where the
video stream encounters many time-varying background competing traffic)
so as to stay robust against occasional non-congestion-induced delay
spikes. Additional insights on how this value can be tuned or auto-tuned
should be gathered from carrying out experimental studies in different
real-world deployment scenarios.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<p id="section-4.2-7">The value of loss_exp is configured to self-scale with the average
  packet loss interval loss_int with a multiplier MULTILOSS:<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.2-8">
<pre> loss_exp = MULTILOSS *
loss_int.  </pre><a href="#section-4.2-8" class="pilcrow">¶</a>
</div>
<p id="section-4.2-9">Estimation of the average loss interval loss_int, in turn, follows
 <span><a href="https://www.rfc-editor.org/rfc/rfc5348#section-5.4" class="relref">Section 5.4</a> of "TCP Friendly Rate Control
   (TFRC): Protocol Specification" [<a href="#RFC5348" class="xref">RFC5348</a>]</span>.<a href="#section-4.2-9" class="pilcrow">¶</a></p>
<p id="section-4.2-10">In practice, it is recommended to linearly interpolate between the
warped (d_tilde) and non-warped (d_queue) values of the queuing delay
during the transitional period lasting for the duration of loss_int.<a href="#section-4.2-10" class="pilcrow">¶</a></p>
<p id="section-4.2-11">The aggregate congestion signal is:<a href="#section-4.2-11" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.2-12">
<pre>
                         / p_mark \^2        / p_loss \^2 
x_curr = d_tilde + DMARK*|--------|  + DLOSS*|--------|   (2) 
                         \ PMRREF /          \ PLRREF /         </pre><a href="#section-4.2-12" class="pilcrow">¶</a>
</div>
<p id="section-4.2-13">Here, DMARK is prescribed a reference delay penalty associated with
        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 <span class="bcp14">SHOULD</span> 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.<a href="#section-4.2-13" class="pilcrow">¶</a></p>
<p id="section-4.2-14">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.<a href="#section-4.2-14" class="pilcrow">¶</a></p>
<p id="section-4.2-15">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:<a href="#section-4.2-15" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.2-16.1"> No recent packet losses within the observation window LOGWIN;
          and<a href="#section-4.2-16.1" class="pilcrow">¶</a>
</li>
<li id="section-4.2-16.2"> No buildup of queuing delay: d_fwd-d_base &lt; QEPS
          for all previous delay samples within the observation window
          LOGWIN.<a href="#section-4.2-16.2" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-4.2-17">Otherwise, the algorithm operates in graduate update mode.<a href="#section-4.2-17" class="pilcrow">¶</a></p>
</section>
</div>
<div id="subsec-sender-algorithm">
<section id="section-4.3">
        <h3 id="name-sender-side-algorithm">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-sender-side-algorithm" class="section-name selfRef">Sender-Side Algorithm</a>
        </h3>
<p id="section-4.3-1">The sender-side algorithm is outlined as follows:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-4.3-2.1">On initialization:<a href="#section-4.3-2.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.2">
            <ul class="ulEmpty">
<li class="ulEmpty" id="section-4.3-2.2.1.1">set r_ref = RMIN<a href="#section-4.3-2.2.1.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.2.1.2">set rtt = 0<a href="#section-4.3-2.2.1.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.2.1.3">set x_prev = 0<a href="#section-4.3-2.2.1.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.2.1.4">set t_last and t_curr as current system clock time<a href="#section-4.3-2.2.1.4" class="pilcrow">¶</a>
</li>
</ul>
</li>
<li class="ulEmpty" id="section-4.3-2.3">On receiving feedback report:<a href="#section-4.3-2.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4">
            <ul class="ulEmpty">
<li class="ulEmpty" id="section-4.3-2.4.1.1">obtain current timestamp from system clock: t_curr<a href="#section-4.3-2.4.1.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.2">obtain values of rmode, x_curr, and r_recv from feedback report<a href="#section-4.3-2.4.1.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.3">update estimation of rtt<a href="#section-4.3-2.4.1.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.4">measure feedback interval: delta = t_curr - t_last<a href="#section-4.3-2.4.1.4" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.5">if rmode == 0:<a href="#section-4.3-2.4.1.5" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.6">
                <ul class="ulEmpty">
<li class="ulEmpty" id="section-4.3-2.4.1.6.1.1">update r_ref following accelerated ramp-up rules<a href="#section-4.3-2.4.1.6.1.1" class="pilcrow">¶</a>
</li>
</ul>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.7">else:<a href="#section-4.3-2.4.1.7" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.8">
                <ul class="ulEmpty">
<li class="ulEmpty" id="section-4.3-2.4.1.8.1.1">update r_ref following gradual update rules<a href="#section-4.3-2.4.1.8.1.1" class="pilcrow">¶</a>
</li>
</ul>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.9">clip rate r_ref within the range of minimum rate (RMIN) and maximum rate
(RMAX).<a href="#section-4.3-2.4.1.9" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.10">set x_prev = x_curr<a href="#section-4.3-2.4.1.10" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-4.3-2.4.1.11">set t_last = t_curr<a href="#section-4.3-2.4.1.11" class="pilcrow">¶</a>
</li>
</ul>
</li>
</ul>
<p id="section-4.3-3">In accelerated ramp-up mode, the rate r_ref is updated as
 follows:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-4">
<pre>
                                QBOUND
    gamma = min(GAMMA_MAX, ------------------)       (3)
                            rtt+DELTA+DFILT

                            r_ref = max(r_ref, (1+gamma) r_recv)
                            (4)    
</pre><a href="#section-4.3-4" class="pilcrow">¶</a>
</div>
<p id="section-4.3-5">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.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="section-4.3-6">In gradual update mode, the rate r_ref is updated as:<a href="#section-4.3-6" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-7">
<pre>
    x_offset = x_curr - PRIO*XREF*RMAX/r_ref          (5)

    x_diff   = x_curr - x_prev                        (6) 

                           delta    x_offset
    r_ref = r_ref - KAPPA*-------*------------*r_ref
                            TAU       TAU

                                x_diff
                  - KAPPA*ETA*---------*r_ref         (7)
                                 TAU    
</pre><a href="#section-4.3-7" class="pilcrow">¶</a>
</div>
<p id="section-4.3-8">The rate changes in proportion to the previous rate decision.
It is affected by two terms: the offset of the aggregate congestion
signal from its value at equilibrium (x_offset) and its change
(x_diff). The calculation of x_offset depends on the maximum rate
of the flow (RMAX), its weight of priority (PRIO), as well
as a reference congestion signal (XREF). The value of
XREF is chosen so that the maximum rate of RMAX can be achieved
when the observed congestion signal level is below PRIO*XREF.<a href="#section-4.3-8" class="pilcrow">¶</a></p>
<p id="section-4.3-9">
At equilibrium, the aggregated congestion signal stabilizes at
x_curr = PRIO*XREF*RMAX/r_ref. This ensures that when multiple
flows share the same bottleneck and observe a common value of
x_curr, their rates at equilibrium will be proportional to their
respective priority levels (PRIO) and the range between minimum
and maximum rate. Values of the minimum rate (RMIN) and 
maximum rate (RMAX) will be provided by the media codec,
for instance, as outlined by <span>[<a href="#I-D.ietf-rmcat-cc-codec-interactions" class="xref">RMCAT-CC-RTP</a>]</span>. In the absence of such information, the NADA sender will
choose a default value of 0 for RMIN and 3 Mbps for RMAX.<a href="#section-4.3-9" class="pilcrow">¶</a></p>
<p id="section-4.3-10"> As mentioned in the sender-side algorithm, the final rate
is always clipped within the dynamic range specified by the
application:<a href="#section-4.3-10" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-11">
<pre>
    r_ref = min(r_ref, RMAX)                         (8)

    r_ref = max(r_ref, RMIN)                         (9)
</pre><a href="#section-4.3-11" class="pilcrow">¶</a>
</div>
<p id="section-4.3-12">The above operations ignore many practical issues such as clock
synchronization between sender and receiver, the filtering of noise in
delay measurements, and base delay expiration. These will be addressed
in <a href="#sec-practical-nada" class="xref">Section 5</a>.<a href="#section-4.3-12" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-practical-nada">
<section id="section-5">
      <h2 id="name-practical-implementation-of">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-practical-implementation-of" class="section-name selfRef">Practical Implementation of NADA</a>
      </h2>
<div id="sec-receiver">
<section id="section-5.1">
        <h3 id="name-receiver-side-operation">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-receiver-side-operation" class="section-name selfRef">Receiver-Side Operation</a>
        </h3>
<p id="section-5.1-1">The receiver continuously monitors end-to-end per-packet
statistics in terms of delay, loss, and/or ECN marking ratios.
It then aggregates all forms of congestion indicators into the
form of an equivalent delay and periodically reports this back
to the sender. In addition, the receiver tracks the receiving
rate of the flow and includes that in the feedback message.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<div id="sec-receiver-a">
<section id="section-5.1.1">
          <h4 id="name-estimation-of-one-way-delay">
<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-estimation-of-one-way-delay" class="section-name selfRef">Estimation of One-Way Delay and Queuing Delay</a>
          </h4>
<p id="section-5.1.1-1">
The delay estimation process in NADA follows an approach similar to that of
earlier
delay-based congestion control schemes, such as Low Extra Delay Background
Transport (LEDBAT) <span>[<a href="#RFC6817" class="xref">RFC6817</a>]</span>. For
experimental implementations, instead of relying on RTP timestamps and the
transmission time offset RTP header extension <span>[<a href="#RFC5450" class="xref">RFC5450</a>]</span>, the NADA sender can generate its own timestamp based on
the local system clock and embed that information in the transport packet
header. The NADA receiver estimates the forward delay as having a constant
base delay component plus a time-varying queuing delay component. The base
delay is estimated as the minimum value of one-way delay observed over a
relatively long period (e.g., tens of minutes), whereas the individual
queuing delay value is taken to be the difference between one-way delay and
base delay. By re-estimating the base delay periodically, one can avoid the
potential issue of base delay expiration, whereby an earlier measured base
delay value is no longer valid due to underlying route changes or a cumulative
timing difference introduced by the clock-rate skew between sender and
receiver. All delay estimations are based on sender timestamps with a
recommended granularity of 100 microseconds or finer.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1.1-2">
The individual sample values of queuing delay should be further
filtered against various non-congestion-induced noise, such as
spikes due to a processing "hiccup" at the network nodes. Therefore,
in addition to calculating the value of queuing delay using
d_queue = d_fwd - d_base, as expressed in <a href="#sec-receiver" class="xref">Section 5.1</a>, 
the current implementation further employs a minimum filter with
a window size of 15 samples over per-packet queuing delay values.<a href="#section-5.1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-receiver-b">
<section id="section-5.1.2">
          <h4 id="name-estimation-of-packet-loss-m">
<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-estimation-of-packet-loss-m" class="section-name selfRef">Estimation of Packet Loss/Marking Ratio</a>
          </h4>
<p id="section-5.1.2-1">The receiver detects packet losses via gaps in the
RTP sequence numbers of received packets. For interactive
real-time media applications with stringent latency
constraints (e.g., video conferencing), the receiver avoids
the packet reordering delay by treating out-of-order packets
as losses. The instantaneous packet loss ratio p_inst is estimated
as the ratio between the number of missing packets over
the number of total transmitted packets within the
recent observation window LOGWIN. The packet loss ratio
p_loss is obtained after exponential smoothing:<a href="#section-5.1.2-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-5.1.2-2">
<pre>    
            p_loss = ALPHA*p_inst + (1-ALPHA)*p_loss        (10)
            </pre><a href="#section-5.1.2-2" class="pilcrow">¶</a>
</div>
<p id="section-5.1.2-3">The filtered result is reported back to the sender as
the observed packet loss ratio p_loss.<a href="#section-5.1.2-3" class="pilcrow">¶</a></p>
<p id="section-5.1.2-4">
The estimation of the packet marking ratio p_mark follows the same procedure
as above.  It is assumed that ECN marking information at the IP header
can be passed to the receiving endpoint, e.g., by following the mechanism
described in <span>[<a href="#RFC6679" class="xref">RFC6679</a>]</span>.<a href="#section-5.1.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-receiver-c">
<section id="section-5.1.3">
          <h4 id="name-estimation-of-receiving-rat">
<a href="#section-5.1.3" class="section-number selfRef">5.1.3. </a><a href="#name-estimation-of-receiving-rat" class="section-name selfRef">Estimation of Receiving Rate</a>
          </h4>
<p id="section-5.1.3-1">
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
divides the total size of packets arriving during that window over the time
span. The receiving rate (r_recv) can be either calculated at the sender side
based on the per-packet feedback from the receiver or included as part of the
feedback report.<a href="#section-5.1.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-sender">
<section id="section-5.2">
        <h3 id="name-sender-side-operation">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-sender-side-operation" class="section-name selfRef">Sender-Side Operation</a>
        </h3>
<p id="section-5.2-1">
<a href="#fig-nada-sender" class="xref">Figure 2</a> provides a detailed
view of the NADA sender. Upon receipt of an RTCP feedback
report from the receiver, the NADA sender calculates the
reference rate r_ref as specified in
<a href="#subsec-sender-algorithm" class="xref">Section 4.3</a>.
It further adjusts both the target rate for the live video
encoder r_vin and the sending rate r_send over the network
based on the updated value of r_ref and rate-shaping buffer
occupancy buffer_len.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
The NADA sender behavior stays the same in the presence
of all types of congestion indicators: delay, loss, and
ECN marking. This unified approach allows a graceful
transition of the scheme as the network shifts dynamically
between light and heavy congestion levels.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<span id="name-nada-sender-structure"></span><div id="fig-nada-sender">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-5.2-3.1">
<pre>
                   +----------------+             
                   |  Calculate     | &lt;---- RTCP report
                   | Reference Rate | 
                   -----------------+
                           | r_ref
              +------------+-------------+
              |                          |
             \|/                        \|/
      +-----------------+           +---------------+
      | Calculate Video |           |   Calculate   |
      |  Target Rate    |           | Sending Rate  |
      +-----------------+           +---------------+
          |        /|\                 /|\      |   
    r_vin |         |                   |       |
         \|/        +-------------------+       |       
      +----------+          | buffer_len        |  r_send
      |  Video   | r_vout  -----------+        \|/
      |  Encoder |--------&gt;   |||||||||=================&gt;  
      +----------+         -----------+    RTP packets     
      Rate-Shaping Buffer         
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-nada-sender-structure" class="selfRef">NADA Sender Structure</a>
          </figcaption></figure>
</div>
<div id="sec-sender-c">
<section id="section-5.2.1">
          <h4 id="name-rate-shaping-buffer">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-rate-shaping-buffer" class="section-name selfRef">Rate-Shaping Buffer</a>
          </h4>
<p id="section-5.2.1-1">
The operation of the live video encoder is out of the scope
of the design for the congestion control scheme in NADA.
Instead, its behavior is treated as a black box.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">
A rate-shaping buffer is employed to absorb any instantaneous
mismatch between the encoder rate output r_vout and the regulated sending
rate r_send. Its current level of occupancy is measured in bytes
and is denoted as buffer_len.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
<p id="section-5.2.1-3">A large rate-shaping buffer contributes to higher
end-to-end delay, which may harm the performance of
real-time media communications. Therefore, the sender
has a strong incentive to prevent the rate-shaping
buffer from building up. The mechanisms adopted are:<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-5.2.1-4.1">To deplete the rate-shaping buffer faster by
     increasing the sending rate r_send; and<a href="#section-5.2.1-4.1" class="pilcrow">¶</a>
</li>
<li id="section-5.2.1-4.2">To limit incoming packets of the rate-shaping
     buffer by reducing the video encoder target rate
     r_vin.<a href="#section-5.2.1-4.2" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<div id="sec-sender-d">
<section id="section-5.2.2">
          <h4 id="name-adjusting-video-target-rate">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-adjusting-video-target-rate" class="section-name selfRef">Adjusting Video Target Rate and Sending Rate</a>
          </h4>
<p id="section-5.2.2-1">
If the level of occupancy in the rate-shaping buffer is accessible
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
actual sending rate r_send. The purpose of such adjustments is to
mitigate the additional latencies introduced by the rate-shaping
buffer. The amount of rate adjustment can be calculated as follows:<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-5.2.2-2">
<pre>
    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_vin  = max(RMIN, r_ref - r_diff_v)                    (13) 
    r_send = min(RMAX, r_ref + r_diff_s)                    (14)
</pre><a href="#section-5.2.2-2" class="pilcrow">¶</a>
</div>
<p id="section-5.2.2-3"> In Equations (11) and (12), the amount of adjustment is calculated
as proportional to the size of the rate-shaping buffer but is
bounded by 5% of the reference rate r_ref calculated from network
congestion feedback alone. This ensures that the adjustment
introduced by the rate-shaping buffer will not counteract with the core
congestion control process. Equations (13) and (14) indicate
the influence of the rate-shaping buffer. A large
rate-shaping buffer nudges the encoder target rate slightly
below (and the sending rate slightly above) the reference
rate r_ref. The final video target rate (r_vin) and sending
rate (r_send) are further bounded within the original range of
[RMIN, RMAX].<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2.2-4">
Intuitively, the amount of extra rate offset needed to completely
drain the rate-shaping buffer within the duration of a single
video frame is given by 8*buffer_len*FPS, where FPS stands
for the reference frame rate of the video. The scaling parameters
BETA_V and BETA_S can be tuned to balance between the competing
goals of maintaining a small rate-shaping buffer and deviating
from the reference rate point. Empirical observations show that
the rate-shaping buffer for a responsive live video encoder typically
stays empty and only occasionally holds a large frame (e.g., when
an intra-frame is produced) in transit. Therefore, the rate adjustment
introduced by this mechanism is expected to be minor. For instance,
a rate-shaping buffer of 2000 bytes will lead to a rate adjustment
of 48 Kbps given the recommended scaling parameters of BETA_V = 0.1
and BETA_S = 0.1, and the reference frame rate of FPS = 30.<a href="#section-5.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-feedback">
<section id="section-5.3">
        <h3 id="name-feedback-message-requiremen">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-feedback-message-requiremen" class="section-name selfRef">Feedback Message Requirements</a>
        </h3>
<p id="section-5.3-1">The following list of information is required for
NADA congestion control to function properly:<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-5.3-2">
          <dt id="section-5.3-2.1">Recommended rate adaptation mode (rmode):
</dt>
<dd id="section-5.3-2.2">A 1-bit flag indicating whether the sender should operate in accelerated
ramp-up mode (rmode=0) or gradual update mode (rmode=1).<a href="#section-5.3-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-5.3-2.3">Aggregated congestion signal (x_curr):
</dt>
<dd id="section-5.3-2.4">The most recently updated value, calculated by the receiver according to
<a href="#subsec-receiver-algorithm" class="xref">Section 4.2</a>. This information
can be expressed with a unit of 100 microseconds (i.e., 1/10 of a millisecond)
in 15 bits. This allows a maximum value of x_curr at approximately 3.27
seconds.<a href="#section-5.3-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-5.3-2.5">Receiving rate (r_recv):
</dt>
<dd id="section-5.3-2.6">The most recently measured receiving rate according to <a href="#sec-receiver-c" class="xref">Section 5.1.3</a>. This information is
expressed with a unit of bits per second (bps) in 32 bits (unsigned int). This
allows a maximum rate of approximately 4.3 Gbps, approximately 1000 times the
streaming rate of a typical high-definition (HD) video conferencing session
today. This field can be expanded further by a few more bytes if an even
higher rate needs to be specified.<a href="#section-5.3-2.6" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-5.3-3">
  The above list of information can be accommodated by 48 bits,
  or 6 bytes, in total. They can be either included in the
  feedback report from the receiver or, in the case where all
  receiver-side calculations are moved to the sender, derived
  from per-packet information from the feedback message as defined
  in <span>[<a href="#I-D.ietf-avtcore-cc-feedback-message" class="xref">RTCP-FEEDBACK</a>]</span>. 
  Choosing the feedback message interval DELTA is discussed in
  <a href="#sec-discussion-c" class="xref">Section 6.3</a>. A target feedback
  interval
  of DELTA = 100 ms is recommended.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-discussions">
<section id="section-6">
      <h2 id="name-discussions-and-further-inv">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-discussions-and-further-inv" class="section-name selfRef">Discussions and Further Investigations</a>
      </h2>
<p id="section-6-1">This section discusses the various design choices
made by NADA, potential alternative variants of its
implementation, and guidelines on how the key algorithm
parameters can be chosen. <a href="#sec-experiments" class="xref">Section 8</a>
recommends additional experimental setups to 
further explore these topics.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="sec-discussion-a">
<section id="section-6.1">
        <h3 id="name-choice-of-delay-metrics">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-choice-of-delay-metrics" class="section-name selfRef">Choice of Delay Metrics</a>
        </h3>
<p id="section-6.1-1">
The current design works with relative one-way delay (OWD) as the main
indication of congestion. The value of the relative OWD is obtained by
maintaining the minimum value of observed OWD over a relatively long time
horizon and subtracting that out from the observed absolute OWD value. Such an
approach cancels out the fixed difference between the sender and receiver
clocks.  It has been widely adopted by other delay-based congestion control
approaches such as <span>[<a href="#RFC6817" class="xref">RFC6817</a>]</span>.  As discussed in
<span>[<a href="#RFC6817" class="xref">RFC6817</a>]</span>, the time horizon for tracking the
minimum OWD needs to be chosen with care; it must be long enough for an
opportunity to observe the minimum OWD with zero standing queue along the
path,
and it must be sufficiently short enough to timely reflect "true" changes in
minimum OWD introduced by route changes and other rare events and
to mitigate the cumulative impact of clock rate skew over time.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">
The potential drawback in relying on relative OWD as the congestion
signal is that when multiple flows share the same bottleneck, the
flow arriving late at the network experiencing a non-empty queue may
mistakenly consider the standing queuing delay as part of the fixed
path propagation delay. This will lead to slightly unfair bandwidth
sharing among the flows.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">Alternatively, one could move the per-packet statistical handling
to the sender instead and use relative round-trip time (RTT) in lieu
of relative OWD, assuming that per-packet acknowledgments are available.
The main drawback of an RTT-based approach is the noise in the measured delay
in the reverse direction.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">
Note that the choice of either delay metric (relative OWD vs. RTT) involves no
change in the proposed rate adaptation algorithm.  Therefore, comparing the
pros and cons regarding which delay metric to adopt can be kept as an
orthogonal direction of investigation.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-discussion-b">
<section id="section-6.2">
        <h3 id="name-method-for-delay-loss-and-m">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-method-for-delay-loss-and-m" class="section-name selfRef">Method for Delay, Loss, and Marking Ratio Estimation</a>
        </h3>
<p id="section-6.2-1">Like other delay-based congestion control schemes, performance of
        NADA depends on the accuracy of its delay measurement and estimation
        module. <span><a href="https://www.rfc-editor.org/rfc/rfc6817#appendix-A" class="relref">Appendix A</a> of [<a href="#RFC6817" class="xref">RFC6817</a>]</span>
        provides an extensive discussion on this aspect.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">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.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
<p id="section-6.2-3">
More sophisticated methods in packet loss ratio calculation,
such as that adopted by <span>[<a href="#FLOYD-CCR00" class="xref">FLOYD-CCR00</a>]</span>,
will likely be beneficial. These alternatives are part of
the experiments this document proposes.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-discussion-c">
<section id="section-6.3">
        <h3 id="name-impact-of-parameter-values">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-impact-of-parameter-values" class="section-name selfRef">Impact of Parameter Values</a>
        </h3>
<p id="section-6.3-1">In the gradual rate update mode, the parameter TAU indicates the
        upper bound of round-trip time (RTT) in the feedback control loop.
        Typically, the observed feedback interval delta is close to the target
        feedback interval DELTA, and the relative ratio of delta/TAU versus
        ETA dictates the relative strength of influence from the aggregate
        congestion signal offset term (x_offset) versus its recent change
        (x_diff), respectively. These two terms are analogous to the integral
        and proportional terms in a proportional-integral (PI) controller. The
        recommended choice of TAU = 500 ms, DELTA = 100 ms, and ETA = 2.0
 corresponds
        to a relative ratio of 1:10 between the gains of the integral and
        proportional terms. Consequently, the rate adaptation is mostly driven
        by the change in the congestion signal with a long-term shift towards
        its equilibrium value driven by the offset term. Finally, the scaling
        parameter KAPPA determines the overall speed of the adaptation and
        needs to strike a balance between responsiveness and stability.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">                                         
The choice of the target feedback interval DELTA needs to strike the right
balance between timely feedback and low RTCP feedback message counts. A target
feedback interval of DELTA = 100 ms is recommended, corresponding to a
feedback
bandwidth of 16 Kbps with 200 bytes per feedback message -- approximately 1.6%
overhead for a 1 Mbps flow. Furthermore, both simulation studies and
frequency-domain analysis in <span>[<a href="#IETF-95" class="xref">IETF-95</a>]</span> have
established that a feedback interval below 250 ms (i.e., more frequently than
4
feedback messages per second) will not break up the feedback control loop of
NADA congestion control.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3-3">In calculating the non-linear warping of delay in Equation (1), 
the current design uses fixed values of QTH for determining
whether to perform the non-linear warping. Its value should be
carefully tuned for different operational environments (e.g.,
over wired vs. wireless connections) so as to avoid the potential
risk of prematurely discounting the congestion signal level.
It is possible to adapt its value based on past observed patterns
of queuing delay in the presence of packet losses. It needs to be
noted that the non-linear warping mechanism may lead to multiple
NADA streams stuck in loss-based mode when competing against
each other.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
<p id="section-6.3-4">In calculating the aggregate congestion signal x_curr, the
choice of DMARK and DLOSS influence the steady-state packet
loss/marking ratio experienced by the flow at a given
available bandwidth. Higher values of DMARK and DLOSS result
in lower steady-state loss/marking ratios but are more 
susceptible to the impact of individual packet loss/marking
events.  While the value of DMARK and DLOSS are fixed and
predetermined in the current design, this document also encourages
further explorations of a scheme for automatically
tuning these values based on desired bandwidth sharing behavior
in the presence of other competing loss-based flows (e.g.,
loss-based TCP).<a href="#section-6.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-discussion-d">
<section id="section-6.4">
        <h3 id="name-sender-based-vs-receiver-ba">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-sender-based-vs-receiver-ba" class="section-name selfRef">Sender-Based vs. Receiver-Based Calculation</a>
        </h3>
<p id="section-6.4-1">In the current design, the aggregated congestion
signal x_curr is calculated at the receiver, keeping
the sender operation completely independent of the
form of actual network congestion indications (delay, 
loss, or marking) in use.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<p id="section-6.4-2">Alternatively, one can shift receiver-side calculations
to the sender, whereby the receiver simply reports on per-packet
information via periodic feedback messages as defined in
<span>[<a href="#I-D.ietf-avtcore-cc-feedback-message" class="xref">RTCP-FEEDBACK</a>]</span>. 
Such an approach enables interoperability amongst senders operating
on different congestion control schemes but requires slightly
higher overhead in the feedback messages. See additional discussions
in <span>[<a href="#I-D.ietf-avtcore-cc-feedback-message" class="xref">RTCP-FEEDBACK</a>]</span>
regarding the desired format of the feedback messages and the
recommended feedback intervals.<a href="#section-6.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-discussion-e">
<section id="section-6.5">
        <h3 id="name-incremental-deployment">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-incremental-deployment" class="section-name selfRef">Incremental Deployment</a>
        </h3>
<p id="section-6.5-1">
One nice property of NADA is the consistent video endpoint
behavior irrespective of network node variations. This facilitates
gradual, incremental adoption of the scheme.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<p id="section-6.5-2">
Initially, the proposed congestion control mechanism can
be implemented without any explicit support from the network and
relies solely on observed relative one-way delay measurements
and packet loss ratios as implicit congestion signals.<a href="#section-6.5-2" class="pilcrow">¶</a></p>
<p id="section-6.5-3">
When ECN is enabled at the network nodes with RED-based marking,
the receiver can fold its observations of ECN markings into the
calculation of the equivalent delay. The sender can react to these
explicit congestion signals without any modification.<a href="#section-6.5-3" class="pilcrow">¶</a></p>
<p id="section-6.5-4">
Ultimately, networks equipped with proactive marking based on the level of
token bucket metering can reap the additional benefits of
zero standing queues and lower end-to-end delay and work
seamlessly with existing senders and receivers.<a href="#section-6.5-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-implementations">
<section id="section-7">
      <h2 id="name-reference-implementations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-reference-implementations" class="section-name selfRef">Reference Implementations</a>
      </h2>
<p id="section-7-1">
The NADA scheme has been implemented in both ns-2 <span>[<a href="#NS-2" class="xref">NS-2</a>]</span>
and ns-3 <span>[<a href="#NS-3" class="xref">NS-3</a>]</span> simulation platforms.  The
implementation
in ns-2 hosts the calculations as described in
<a href="#subsec-receiver-algorithm" class="xref">Section 4.2</a> at the receiver
side,
whereas the implementation in ns-3 hosts these receiver-side calculations
at the sender for the sake of interoperability. Extensive ns-2 simulation
evaluations of an earlier draft version of this document are recorded in
<span>[<a href="#ZHU-PV13" class="xref">ZHU-PV13</a>]</span>. 
An open-source implementation of NADA as part of an ns-3 module is
available at <span>[<a href="#NS3-RMCAT" class="xref">NS3-RMCAT</a>]</span>.
Evaluation results of this document based on ns-3 are presented
in <span>[<a href="#IETF-90" class="xref">IETF-90</a>]</span> and <span>[<a href="#IETF-91" class="xref">IETF-91</a>]</span>
for wired test cases as documented in <span>[<a href="#I-D.ietf-rmcat-eval-test" class="xref">RMCAT-EVAL-TEST</a>]</span>.
Evaluation results of NADA over Wi-Fi-based test cases as defined in
<span>[<a href="#I-D.ietf-rmcat-wireless-tests" class="xref">WIRELESS-TESTS</a>]</span> are
presented in <span>[<a href="#IETF-93" class="xref">IETF-93</a>]</span>. These simulation-based
evaluations have shown that NADA flows can obtain their fair share of
bandwidth when competing against each other. They typically adapt fast
in reaction to the arrival and departure of other flows and can sustain
a reasonable throughput when competing against loss-based TCP flows.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2"> 
<span>[<a href="#IETF-90" class="xref">IETF-90</a>]</span> describes the  implementation and
evaluation of NADA in a lab setting. Preliminary evaluation
results of NADA in single-flow and multi-flow test scenarios
are presented in <span>[<a href="#IETF-91" class="xref">IETF-91</a>]</span>.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
A reference implementation of NADA has been carried out by
modifying the WebRTC module embedded in the Mozilla open-source
browser. Presentations from <span>[<a href="#IETF-103" class="xref">IETF-103</a>]</span>
and <span>[<a href="#IETF-105" class="xref">IETF-105</a>]</span> document real-world evaluations
of the modified browser driven by NADA. The experimental setting
involves remote connections with endpoints over either home or enterprise
wireless networks. These evaluations validate the effectiveness of
NADA flows in recovering quickly from throughput drops caused by
intermittent delay spikes over the last-hop wireless connections.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-experiments">
<section id="section-8">
      <h2 id="name-suggested-experiments">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-suggested-experiments" class="section-name selfRef">Suggested Experiments</a>
      </h2>
<p id="section-8-1">
NADA has been extensively evaluated under various test scenarios, including
the collection of test cases specified by <span>[<a href="#I-D.ietf-rmcat-eval-test" class="xref">RMCAT-EVAL-TEST</a>]</span> and the subset of
Wi-Fi-based test cases in <span>[<a href="#I-D.ietf-rmcat-wireless-tests" class="xref">WIRELESS-TESTS</a>]</span>.  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 <a href="#tab-parameters" class="xref">Table 2</a>) as discussed in
<a href="#sec-discussions" class="xref">Section 6</a>.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Additional experiments are suggested for the following scenarios,
      preferably over real-world networks:<a href="#section-8-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-8-3.1">Experiments reflecting the setup of a typical WAN
 connection.<a href="#section-8-3.1" class="pilcrow">¶</a>
</li>
<li id="section-8-3.2">Experiments with ECN marking capability turned on at the network
  for existing test cases.<a href="#section-8-3.2" class="pilcrow">¶</a>
</li>
<li id="section-8-3.3">Experiments with multiple NADA streams bearing different
  user-specified priorities.<a href="#section-8-3.3" class="pilcrow">¶</a>
</li>
<li id="section-8-3.4">Experiments with additional access technologies, especially
over cellular networks such as 3G/LTE.<a href="#section-8-3.4" class="pilcrow">¶</a>
</li>
<li id="section-8-3.5">Experiments with various media source contents, including audio
 only,
  audio and video, and application content sharing (e.g., slideshows).<a href="#section-8-3.5" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<div id="sec-iana">
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">This document has no IANA actions.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-security">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">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 <span class="bcp14">RECOMMENDED</span> that the RTCP
      feedback message is at least integrity checked. In addition, <span>[<a href="#I-D.ietf-avtcore-cc-feedback-message" class="xref">RTCP-FEEDBACK</a>]</span>
      discusses the potential risk of a receiver providing misleading
      congestion feedback information and the mechanisms for mitigating such
      risks.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">The modification of the sending rate based on the sender-side
      rate-shaping
      buffer may lead to temporary excessive congestion over the network in
      the presence of an 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.<a href="#section-10-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC3168">[RFC3168]</dt>
<dd>
<span class="refAuthor">Ramakrishnan, K.</span><span class="refAuthor">, Floyd, S.</span><span class="refAuthor">, and D. Black</span>, <span class="refTitle">"The Addition of Explicit Congestion Notification (ECN) to IP"</span>, <span class="seriesInfo">RFC 3168</span>, <span class="seriesInfo">DOI 10.17487/RFC3168</span>, <time datetime="2001-09">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3168">https://www.rfc-editor.org/info/rfc3168</a>&gt;</span>. </dd>
<dt id="RFC3550">[RFC3550]</dt>
<dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor">, Casner, S.</span><span class="refAuthor">, Frederick, R.</span><span class="refAuthor">, and V. Jacobson</span>, <span class="refTitle">"RTP: A Transport Protocol for Real-Time Applications"</span>, <span class="seriesInfo">STD 64</span>, <span class="seriesInfo">RFC 3550</span>, <span class="seriesInfo">DOI 10.17487/RFC3550</span>, <time datetime="2003-07">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3550">https://www.rfc-editor.org/info/rfc3550</a>&gt;</span>. </dd>
<dt id="RFC5348">[RFC5348]</dt>
<dd>
<span class="refAuthor">Floyd, S.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, Padhye, J.</span><span class="refAuthor">, and J. Widmer</span>, <span class="refTitle">"TCP Friendly Rate Control (TFRC): Protocol Specification"</span>, <span class="seriesInfo">RFC 5348</span>, <span class="seriesInfo">DOI 10.17487/RFC5348</span>, <time datetime="2008-09">September 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5348">https://www.rfc-editor.org/info/rfc5348</a>&gt;</span>. </dd>
<dt id="RFC6679">[RFC6679]</dt>
<dd>
<span class="refAuthor">Westerlund, M.</span><span class="refAuthor">, Johansson, I.</span><span class="refAuthor">, Perkins, C.</span><span class="refAuthor">, O'Hanlon, P.</span><span class="refAuthor">, and K. Carlberg</span>, <span class="refTitle">"Explicit Congestion Notification (ECN) for RTP over UDP"</span>, <span class="seriesInfo">RFC 6679</span>, <span class="seriesInfo">DOI 10.17487/RFC6679</span>, <time datetime="2012-08">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6679">https://www.rfc-editor.org/info/rfc6679</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
<dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="BUDZISZ-AIMD-CC">[BUDZISZ-AIMD-CC]</dt>
<dd>
<span class="refAuthor">Budzisz, L.</span><span class="refAuthor">, Stanojevic, R.</span><span class="refAuthor">, Schlote, A.</span><span class="refAuthor">, Baker, F.</span><span class="refAuthor">, and R. Shorten</span>, <span class="refTitle">"On the Fair Coexistence of Loss- and Delay-Based TCP"</span>, <span class="refContent">IEEE/ACM Transactions on Networking, vol. 19, no. 6,
   pp. 1811-1824
          </span>, <span class="seriesInfo">DOI 10.1109/TNET.2011.2159736</span>, <time datetime="2011-12">December 2011</time>, <span>&lt;<a href="https://doi.org/10.1109/TNET.2011.2159736">https://doi.org/10.1109/TNET.2011.2159736</a>&gt;</span>. </dd>
<dt id="FLOYD-CCR00">[FLOYD-CCR00]</dt>
<dd>
<span class="refAuthor">Floyd, S.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, Padhye, J.</span><span class="refAuthor">, and J. Widmer</span>, <span class="refTitle">"Equation-based congestion control for unicast applications"</span>, <span class="refContent">ACM SIGCOMM Computer Communications Review, vol. 30,
     no. 4, pp. 43-56 
          </span>, <span class="seriesInfo">DOI 10.1145/347057.347397</span>, <time datetime="2000-10">October 2000</time>, <span>&lt;<a href="https://doi.org/10.1145/347057.347397">https://doi.org/10.1145/347057.347397</a>&gt;</span>. </dd>
<dt id="IETF-103">[IETF-103]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Pan, R.</span><span class="refAuthor">, Ramalho, M.</span><span class="refAuthor">, Mena, S.</span><span class="refAuthor">, Jones, P.</span><span class="refAuthor">, Fu, J.</span><span class="refAuthor">, and S. D'Aronco</span>, <span class="refTitle">"NADA Implementation in Mozilla Browser"</span>, <span class="refContent">IETF 103
          </span>, <time datetime="2018-11">November 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-rmcat-nada-implementation-in-mozilla-browser-00">https://datatracker.ietf.org/meeting/103/materials/slides-103-rmcat-nada-implementation-in-mozilla-browser-00</a>&gt;</span>. </dd>
<dt id="IETF-105">[IETF-105]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Pan, R.</span><span class="refAuthor">, Ramalho, M.</span><span class="refAuthor">, Mena, S.</span><span class="refAuthor">, Jones, P.</span><span class="refAuthor">, Fu, J.</span><span class="refAuthor">, and S. D'Aronco</span>, <span class="refTitle">"NADA Implementation in Mozilla Browser and Draft Update"</span>, <span class="refContent">IETF 105
          </span>, <time datetime="2019-07">July 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/meeting/105/materials/slides-105-rmcat-nada-update-02.pdf">https://datatracker.ietf.org/meeting/105/materials/slides-105-rmcat-nada-update-02.pdf</a>&gt;</span>. </dd>
<dt id="IETF-90">[IETF-90]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Ramalho, M.</span><span class="refAuthor">, Ganzhorn, C.</span><span class="refAuthor">, Jones, P.</span><span class="refAuthor">, and R. Pan</span>, <span class="refTitle">"NADA Update: Algorithm, Implementation, and Test Case Evaluation Results"</span>, <span class="refContent">IETF 90
          </span>, <time datetime="2014-07">July 2014</time>, <span>&lt;<a href="https://tools.ietf.org/agenda/90/slides/slides-90-rmcat-6.pdf">https://tools.ietf.org/agenda/90/slides/slides-90-rmcat-6.pdf</a>&gt;</span>. </dd>
<dt id="IETF-91">[IETF-91]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Pan, R.</span><span class="refAuthor">, Ramalho, M.</span><span class="refAuthor">, Mena, S.</span><span class="refAuthor">, Ganzhorn, C.</span><span class="refAuthor">, Jones, P.</span><span class="refAuthor">, and S. D'Aronco</span>, <span class="refTitle">"NADA Algorithm Update and Test Case Evaluations"</span>, <span class="refContent">IETF 91
          </span>, <time datetime="2014-11">November 2014</time>, <span>&lt;<a href="https://www.ietf.org/proceedings/interim/2014/11/09/rmcat/slides/slides-interim-2014-rmcat-1-2.pdf">https://www.ietf.org/proceedings/interim/2014/11/09/rmcat/slides/slides-interim-2014-rmcat-1-2.pdf</a>&gt;</span>. </dd>
<dt id="IETF-93">[IETF-93]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Pan, R.</span><span class="refAuthor">, Ramalho, M.</span><span class="refAuthor">, Mena, S.</span><span class="refAuthor">, Ganzhorn, C.</span><span class="refAuthor">, Jones, P.</span><span class="refAuthor">, D'Aronco, S.</span><span class="refAuthor">, and J. Fu</span>, <span class="refTitle">"Updates on NADA"</span>, <span class="refContent">IETF 93
          </span>, <time datetime="2015-07">July 2015</time>, <span>&lt;<a href="https://www.ietf.org/proceedings/93/slides/slides-93-rmcat-0.pdf">https://www.ietf.org/proceedings/93/slides/slides-93-rmcat-0.pdf</a>&gt;</span>. </dd>
<dt id="IETF-95">[IETF-95]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Pan, R.</span><span class="refAuthor">, Ramalho, M.</span><span class="refAuthor">, Mena, S.</span><span class="refAuthor">, Jones, P.</span><span class="refAuthor">, Fu, J.</span><span class="refAuthor">, D'Aronco, S.</span><span class="refAuthor">, and C. Ganzhorn</span>, <span class="refTitle">"Updates on NADA: Stability Analysis and Impact of Feedback Intervals"</span>, <span class="refContent">IETF 95
          </span>, <time datetime="2016-04">April 2016</time>, <span>&lt;<a href="https://www.ietf.org/proceedings/95/slides/slides-95-rmcat-5.pdf">https://www.ietf.org/proceedings/95/slides/slides-95-rmcat-5.pdf</a>&gt;</span>. </dd>
<dt id="NS-2">[NS-2]</dt>
<dd>
<span class="refTitle">"ns-2"</span>, <time datetime="2014-12">December 2014</time>, <span>&lt;<a href="http://nsnam.sourceforge.net/wiki/index.php/Main_Page">http://nsnam.sourceforge.net/wiki/index.php/Main_Page</a>&gt;</span>. </dd>
<dt id="NS-3">[NS-3]</dt>
<dd>
<span class="refTitle">"ns-3 Network Simulator"</span>, <span>&lt;<a href="https://www.nsnam.org/">https://www.nsnam.org/</a>&gt;</span>. </dd>
<dt id="NS3-RMCAT">[NS3-RMCAT]</dt>
<dd>
<span class="refAuthor">Fu, J.</span><span class="refAuthor">, Mena, S.</span><span class="refAuthor">, and X. Zhu</span>, <span class="refTitle">"Simulator of IETF RMCAT congestion control protocols"</span>, <time datetime="2017-11">November 2017</time>, <span>&lt;<a href="https://github.com/cisco/ns3-rmcat">https://github.com/cisco/ns3-rmcat</a>&gt;</span>. </dd>
<dt id="RFC5450">[RFC5450]</dt>
<dd>
<span class="refAuthor">Singer, D.</span><span class="refAuthor"> and H. Desineni</span>, <span class="refTitle">"Transmission Time Offsets in RTP Streams"</span>, <span class="seriesInfo">RFC 5450</span>, <span class="seriesInfo">DOI 10.17487/RFC5450</span>, <time datetime="2009-03">March 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5450">https://www.rfc-editor.org/info/rfc5450</a>&gt;</span>. </dd>
<dt id="RFC6660">[RFC6660]</dt>
<dd>
<span class="refAuthor">Briscoe, B.</span><span class="refAuthor">, Moncaster, T.</span><span class="refAuthor">, and M. Menth</span>, <span class="refTitle">"Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)"</span>, <span class="seriesInfo">RFC 6660</span>, <span class="seriesInfo">DOI 10.17487/RFC6660</span>, <time datetime="2012-07">July 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6660">https://www.rfc-editor.org/info/rfc6660</a>&gt;</span>. </dd>
<dt id="RFC6817">[RFC6817]</dt>
<dd>
<span class="refAuthor">Shalunov, S.</span><span class="refAuthor">, Hazel, G.</span><span class="refAuthor">, Iyengar, J.</span><span class="refAuthor">, and M. Kuehlewind</span>, <span class="refTitle">"Low Extra Delay Background Transport (LEDBAT)"</span>, <span class="seriesInfo">RFC 6817</span>, <span class="seriesInfo">DOI 10.17487/RFC6817</span>, <time datetime="2012-12">December 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6817">https://www.rfc-editor.org/info/rfc6817</a>&gt;</span>. </dd>
<dt id="RFC7567">[RFC7567]</dt>
<dd>
<span class="refAuthor">Baker, F., Ed.</span><span class="refAuthor"> and G. Fairhurst, Ed.</span>, <span class="refTitle">"IETF Recommendations Regarding Active Queue Management"</span>, <span class="seriesInfo">BCP 197</span>, <span class="seriesInfo">RFC 7567</span>, <span class="seriesInfo">DOI 10.17487/RFC7567</span>, <time datetime="2015-07">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7567">https://www.rfc-editor.org/info/rfc7567</a>&gt;</span>. </dd>
<dt id="RFC8033">[RFC8033]</dt>
<dd>
<span class="refAuthor">Pan, R.</span><span class="refAuthor">, Natarajan, P.</span><span class="refAuthor">, Baker, F.</span><span class="refAuthor">, and G. White</span>, <span class="refTitle">"Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem"</span>, <span class="seriesInfo">RFC 8033</span>, <span class="seriesInfo">DOI 10.17487/RFC8033</span>, <time datetime="2017-02">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8033">https://www.rfc-editor.org/info/rfc8033</a>&gt;</span>. </dd>
<dt id="RFC8290">[RFC8290]</dt>
<dd>
<span class="refAuthor">Hoeiland-Joergensen, T.</span><span class="refAuthor">, McKenney, P.</span><span class="refAuthor">, Taht, D.</span><span class="refAuthor">, Gettys, J.</span><span class="refAuthor">, and E. Dumazet</span>, <span class="refTitle">"The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm"</span>, <span class="seriesInfo">RFC 8290</span>, <span class="seriesInfo">DOI 10.17487/RFC8290</span>, <time datetime="2018-01">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8290">https://www.rfc-editor.org/info/rfc8290</a>&gt;</span>. </dd>
<dt id="RFC8593">[RFC8593]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Mena, S.</span><span class="refAuthor">, and Z. Sarker</span>, <span class="refTitle">"Video Traffic Models for RTP Congestion Control Evaluations"</span>, <span class="seriesInfo">RFC 8593</span>, <span class="seriesInfo">DOI 10.17487/RFC8593</span>, <time datetime="2019-05">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8593">https://www.rfc-editor.org/info/rfc8593</a>&gt;</span>. </dd>
<dt id="I-D.ietf-rmcat-cc-requirements">[RMCAT-CC]</dt>
<dd>
<span class="refAuthor">Jesup, R.</span><span class="refAuthor"> and Z. Sarker</span>, <span class="refTitle">"Congestion Control Requirements for Interactive Real-Time Media"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rmcat-cc-requirements-09</span>, <time datetime="2014-12-12">12 December 2014</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-09">https://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-09</a>&gt;</span>. </dd>
<dt id="I-D.ietf-rmcat-cc-codec-interactions">[RMCAT-CC-RTP]</dt>
<dd>
<span class="refAuthor">Zanaty, M.</span><span class="refAuthor">, Singh, V.</span><span class="refAuthor">, Nandakumar, S.</span><span class="refAuthor">, and Z. Sarker</span>, <span class="refTitle">"Congestion Control and Codec interactions in RTP Applications"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rmcat-cc-codec-interactions-02</span>, <time datetime="2016-03-18">18 March 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-02">https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-02</a>&gt;</span>. </dd>
<dt id="I-D.ietf-rmcat-eval-test">[RMCAT-EVAL-TEST]</dt>
<dd>
<span class="refAuthor">Sarker, Z.</span><span class="refAuthor">, Singh, V.</span><span class="refAuthor">, Zhu, X.</span><span class="refAuthor">, and M. Ramalho</span>, <span class="refTitle">"Test Cases for Evaluating RMCAT Proposals"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rmcat-eval-test-10</span>, <time datetime="2019-05-23">23 May 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rmcat-eval-test-10">https://tools.ietf.org/html/draft-ietf-rmcat-eval-test-10</a>&gt;</span>. </dd>
<dt id="I-D.ietf-avtcore-cc-feedback-message">[RTCP-FEEDBACK]</dt>
<dd>
<span class="refAuthor">Sarker, Z.</span><span class="refAuthor">, Perkins, C.</span><span class="refAuthor">, Singh, V.</span><span class="refAuthor">, and M. Ramalho</span>, <span class="refTitle">"RTP Control Protocol (RTCP) Feedback for Congestion Control"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-avtcore-cc-feedback-message-05</span>, <time datetime="2019-11-04">4 November 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-05">https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-05</a>&gt;</span>. </dd>
<dt id="I-D.ietf-rmcat-wireless-tests">[WIRELESS-TESTS]</dt>
<dd>
<span class="refAuthor">Sarker, Z.</span><span class="refAuthor">, Johansson, I.</span><span class="refAuthor">, Zhu, X.</span><span class="refAuthor">, Fu, J.</span><span class="refAuthor">, Tan, W.</span><span class="refAuthor">, and M. Ramalho</span>, <span class="refTitle">"Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rmcat-wireless-tests-08</span>, <time datetime="2019-07-05">5 July 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rmcat-wireless-tests-08">https://tools.ietf.org/html/draft-ietf-rmcat-wireless-tests-08</a>&gt;</span>. </dd>
<dt id="ZHU-PV13">[ZHU-PV13]</dt>
<dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor"> and R. Pan</span>, <span class="refTitle">"NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Video"</span>, <span class="refContent">Proc. IEEE International Packet Video Workshop, San
   Jose, CA, USA
          </span>, <span class="seriesInfo">DOI 10.1109/PV.2013.6691448</span>, <time datetime="2013-12">December 2013</time>, <span>&lt;<a href="https://doi.org/10.1109/PV.2013.6691448">https://doi.org/10.1109/PV.2013.6691448</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="sec-network-nodes">
<section id="section-appendix.a">
      <h2 id="name-network-node-operations">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-network-node-operations" class="section-name selfRef">Network Node Operations</a>
      </h2>
<p id="section-appendix.a-1">NADA can work with different network queue management
schemes and does not assume any specific network node operation.
As an example, this appendix describes three variants of queue
management behavior at the network node, leading to either
implicit or explicit congestion signals. It needs to be
acknowledged that NADA has not yet been tested with non-probabilistic
ECN marking behaviors.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
In all three flavors described below, the network queue
operates with the simple First In, First Out (FIFO) principle.
There is no need to maintain per-flow state. The system
can scale easily with a large number of video flows and
at high link capacity.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<div id="sec-network-droptail">
<section id="section-a.1">
        <h2 id="name-default-behavior-of-drop-ta">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-default-behavior-of-drop-ta" class="section-name selfRef">Default Behavior of Drop-Tail Queues</a>
        </h2>
<p id="section-a.1-1">
In a conventional network with drop-tail or RED queues,
congestion is inferred from the estimation of end-to-end
delay and/or packet loss. Packet drops at the queue are
detected at the receiver and contribute to the calculation
of the aggregated congestion signal x_curr. No special
action is required at the network node.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-network-ecn">
<section id="section-a.2">
        <h2 id="name-red-based-ecn-marking">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-red-based-ecn-marking" class="section-name selfRef">RED-Based ECN Marking</a>
        </h2>
<p id="section-a.2-1">In this mode, the network node randomly marks
the ECN field in the IP packet header following
the <span><a href="#RFC7567" class="xref">Random Early Detection
(RED) algorithm</a> [<a href="#RFC7567" class="xref">RFC7567</a>]</span>. Calculation of the marking
probability involves the following steps on packet arrival:<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-a.2-2">
          <li id="section-a.2-2.1">
            <p id="section-a.2-2.1.1">update smoothed queue size q_avg as:<a href="#section-a.2-2.1.1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-a.2-2.1.2">
<pre>
   q_avg = w*q + (1-w)*q_avg
</pre><a href="#section-a.2-2.1.2" class="pilcrow">¶</a>
</div>
</li>
<li id="section-a.2-2.2">
            <p id="section-a.2-2.2.1">calculate marking probability p as:<a href="#section-a.2-2.2.1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-a.2-2.2.2">
<pre>
        / 0,                    if q &lt; q_lo
        |
        |        q_avg - q_lo
    p= &lt;  p_max*--------------, if q_lo &lt;= q &lt; q_hi
        |         q_hi - q_lo
        |
        \ p = 1,                if q &gt;= q_hi
</pre><a href="#section-a.2-2.2.2" class="pilcrow">¶</a>
</div>
</li>
</ol>
<p id="section-a.2-3">
Here, q_lo and q_hi correspond to the low
and high thresholds of queue occupancy.
The maximum marking probability is p_max.<a href="#section-a.2-3" class="pilcrow">¶</a></p>
<p id="section-a.2-4">
The ECN marking events will contribute
to the calculation of an equivalent delay
x_curr at the receiver. No changes are required
at the sender.<a href="#section-a.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-network-pcn">
<section id="section-a.3">
        <h2 id="name-random-early-marking-with-v">
<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-random-early-marking-with-v" class="section-name selfRef">Random Early Marking with Virtual Queues</a>
        </h2>
<p id="section-a.3-1">
Advanced network nodes may support random early marking
based on a token bucket algorithm originally designed for
<span><a href="#RFC6660" class="xref">Pre-Congestion Notification
(PCN)</a> [<a href="#RFC6660" class="xref">RFC6660</a>]</span>. 
The early congestion notification (ECN) bit in the
IP header of packets is marked randomly.
The marking probability is calculated based on a
token bucket algorithm originally designed for
<span><a href="#RFC6660" class="xref">PCN</a> [<a href="#RFC6660" class="xref">RFC6660</a>]</span>.
The target link utilization is set as 90%; the marking
probability is designed to grow linearly with the token
bucket size when it varies between 1/3 and 2/3 of the
full token bucket limit.<a href="#section-a.3-1" class="pilcrow">¶</a></p>
<p id="section-a.3-2">Calculation of the marking probability involves
the following steps upon packet arrival:<a href="#section-a.3-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-a.3-3">
          <li id="section-a.3-3.1">
            <p id="section-a.3-3.1.1">meter packet against token bucket (r,b)<a href="#section-a.3-3.1.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.3-3.2">
            <p id="section-a.3-3.2.1">update token level b_tk<a href="#section-a.3-3.2.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.3-3.3">
            <p id="section-a.3-3.3.1">calculate the marking probability as:<a href="#section-a.3-3.3.1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-a.3-3.3.2">
<pre>
         / 0,                     if b-b_tk &lt; b_lo 
         |
         |          b-b_tk-b_lo
    p = &lt;  p_max* --------------, if b_lo &lt;= b-b_tk &lt; b_hi
         |           b_hi-b_lo
         |
         \ 1,                     if b-b_tk &gt;= b_hi 
</pre><a href="#section-a.3-3.3.2" class="pilcrow">¶</a>
</div>
</li>
</ol>
<p id="section-a.3-4">
Here, the token bucket lower and upper limits are denoted by
b_lo and b_hi, respectively. The parameter b indicates the size
of the token bucket. The parameter r is chosen to be below
capacity, resulting in slight underutilization of the link.
The maximum marking probability is p_max.<a href="#section-a.3-4" class="pilcrow">¶</a></p>
<p id="section-a.3-5">The ECN marking events will contribute to the calculation
of an equivalent delay x_curr at the receiver. No changes are
required at the sender. The virtual queuing mechanism from
the PCN-based marking algorithm will lead to additional
benefits such as zero standing queues.<a href="#section-a.3-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-acknowledgments">
<section id="section-appendix.b">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.b-1">
The authors would like to thank <span class="contact-name">Randell Jesup</span>, <span class="contact-name">Luca De Cicco</span>, <span class="contact-name">Piers O'Hanlon</span>, <span class="contact-name">Ingemar Johansson</span>, <span class="contact-name">Stefan Holmer</span>, <span class="contact-name">Cesar Ilharco Magalhaes</span>, <span class="contact-name">Safiqul Islam</span>,
<span class="contact-name">Michael Welzl</span>, <span class="contact-name">Mirja Kühlewind</span>,
<span class="contact-name">Karen Elisabeth Egede Nielsen</span>, <span class="contact-name">Julius Flohr</span>, <span class="contact-name">Roland Bless</span>, <span class="contact-name">Andreas Smas</span>, and <span class="contact-name">Martin Stiemerling</span> for their valuable
review comments and helpful input to this specification.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-contributors">
<section id="section-appendix.c">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-appendix.c-1">The following individuals contributed to the implementation
  and evaluation of the proposed scheme and, therefore, helped
  to validate and substantially improve this specification.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<p id="section-appendix.c-2"><span class="contact-name">Paul E. Jones</span>
 &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.<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
<p id="section-appendix.c-3"><span class="contact-name">Jiantao Fu</span> &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.<a href="#section-appendix.c-3" class="pilcrow">¶</a></p>
<p id="section-appendix.c-4"><span class="contact-name">Stefano D'Aronco</span>
 &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 <span>[<a href="#NS-3" class="xref">NS-3</a>]</span>.<a href="#section-appendix.c-4" class="pilcrow">¶</a></p>
<p id="section-appendix.c-5"><span class="contact-name">Charles Ganzhorn</span>
 &lt;charles.ganzhorn@gmail.com&gt; contributed to the
    testbed-based evaluation of NADA during an early stage of its development.<a href="#section-appendix.c-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.d">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Xiaoqing Zhu</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems</span></div>
<div dir="auto" class="left"><span class="street-address">12515 Research Blvd., Building 4</span></div>
<div dir="auto" class="left">
<span class="locality">Austin</span>, <span class="region">TX</span> <span class="postal-code">78759</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:xiaoqzhu@cisco.com" class="email">xiaoqzhu@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Rong Pan</span></div>
<div dir="auto" class="left"><span class="org">Intel Corporation</span></div>
<div dir="auto" class="left"><span class="street-address">2200 Mission College Blvd</span></div>
<div dir="auto" class="left">
<span class="locality">Santa Clara</span>, <span class="region">CA</span> <span class="postal-code">95054</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rong.pan@intel.com" class="email">rong.pan@intel.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Michael A. Ramalho</span></div>
<div dir="auto" class="left"><span class="org">AcousticComms Consulting</span></div>
<div dir="auto" class="left"><span class="street-address">6310 Watercrest Way Unit 203</span></div>
<div dir="auto" class="left">
<span class="locality">Lakewood Ranch</span>, <span class="region">FL</span> <span class="postal-code">34202-5211</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20732%20832%209723" class="tel">+1 732 832 9723</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:mar42@cornell.edu" class="email">mar42@cornell.edu</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://ramalho.webhop.info/" class="url">http://ramalho.webhop.info/</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sergio Mena</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems</span></div>
<div dir="auto" class="left"><span class="street-address">EPFL, Quartier de l'Innovation, Batiment E</span></div>
<div dir="auto" class="left">
<span class="postal-code">1015</span> <span class="locality">Ecublens</span>
</div>
<div dir="auto" class="left"><span class="country-name">Switzerland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:semena@cisco.com" class="email">semena@cisco.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>