File: rfc8836.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 (1856 lines) | stat: -rw-r--r-- 72,743 bytes
<!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 8836: Congestion Control Requirements for Interactive Real-Time Media</title>
<meta content="Randell Jesup" name="author">
<meta content="Zaheduzzaman Sarker" name="author">
<meta content="
       Congestion control is needed for all data transported across the
      Internet, in order to promote fair usage and prevent congestion
      collapse. The requirements for interactive, point-to-point real-time
      multimedia, which needs low-delay, semi-reliable data delivery, are
      different from the requirements for bulk transfer like FTP or bursty
      transfers like web pages. Due to an increasing amount of RTP-based
      real-time media traffic on the Internet (e.g., with the introduction of
      the Web Real-Time Communication (WebRTC)), it is especially important to
      ensure that this kind of traffic is congestion controlled. 
       This document describes a set of requirements that can be used to
      evaluate other congestion control mechanisms in order to figure out
      their fitness for this purpose, and in particular to provide a set of
      possible requirements for a real-time media congestion avoidance
      technique. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="Interactive multimedia" name="keyword">
<meta content="webrtc" name="keyword">
<meta content="video communication" name="keyword">
<meta content="RTP/RTCP" name="keyword">
<meta content="8836" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8836.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;
  }

}
/* 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-bottom: 0.25em;
  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;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8836" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements-09" 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 8836</td>
<td class="center">RTP Media Congestion Control      Requir</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Jesup &amp; Sarker</td>
<td class="center">Informational</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/rfc8836" class="eref">8836</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-01" class="published">January 2021</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">R. Jesup</div>
<div class="org">Mozilla</div>
</div>
<div class="author">
      <div class="author-name">Z. Sarker, <span class="editor">Ed.</span>
</div>
<div class="org">Ericsson AB</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8836</h1>
<h1 id="title">Congestion Control Requirements for Interactive Real-Time Media</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Congestion control is needed for all data transported across the
      Internet, in order to promote fair usage and prevent congestion
      collapse. The requirements for interactive, point-to-point real-time
      multimedia, which needs low-delay, semi-reliable data delivery, are
      different from the requirements for bulk transfer like FTP or bursty
      transfers like web pages. Due to an increasing amount of RTP-based
      real-time media traffic on the Internet (e.g., with the introduction of
      the Web Real-Time Communication (WebRTC)), it is especially important to
      ensure that this kind of traffic is congestion controlled.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document describes a set of requirements that can be used to
      evaluate other congestion control mechanisms in order to figure out
      their fitness for this purpose, and in particular to provide a set of
      possible requirements for a real-time media congestion avoidance
      technique.<a href="#section-abstract-2" 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 informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            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/rfc8836">https://www.rfc-editor.org/info/rfc8836</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) 2021 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="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><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>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-requirements" class="xref">Requirements</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact 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-deficiencies-of-existing-me" class="xref">Deficiencies of Existing Mechanisms</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact 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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact 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-references" class="xref">References</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact 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-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact 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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<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">Most of today's TCP congestion control schemes were developed with a
      focus on a use of the Internet for reliable bulk transfer of
      non-time-critical data, such as transfer of large files. They have also
      been used successfully to govern the reliable transfer of smaller chunks
      of data in as short a time as possible, such as when fetching web
      pages.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">These algorithms have also been used for transfer of media streams
      that are viewed in a non-interactive manner, such as "streaming" video,
      where having the data ready when the viewer wants it is important, but
      the exact timing of the delivery is not.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">When handling real-time interactive media, the requirements are
      different. One needs to provide the data continuously, within a very
      limited time window (no more delay than hundreds of milliseconds
      end-to-end). In addition, the sources of data may be able to adapt the
      amount of data that needs sending within fairly wide margins, but they can be rate limited by the
      application -- even not always having data to send. They may tolerate some
      amount of packet loss, but since the data is generated in real time,
      sending "future" data is impossible, and since it's consumed in
      real time, data delivered late is commonly useless.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">While the requirements for real-time interactive media differ from
      the requirements for the other flow types, these other flow types will
      be present in the network. The congestion control algorithm for
      real-time interactive media must work properly when these other flow
      types are present as cross traffic on the network.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">One particular protocol portfolio being developed for this use case
      is WebRTC <span>[<a href="#RFC8825" class="xref">RFC8825</a>]</span>, where one
      envisions sending multiple flows using the Real-time Transport Protocol
      (RTP) <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> between two peers, in conjunction
      with data flows, all at the same time, without having special
      arrangements with the intervening service providers. As RTP does not
      provide any congestion control mechanism, a set of circuit breakers,
      such as those described in <span>[<a href="#RFC8083" class="xref">RFC8083</a>]</span>,
      are required to protect the network from excessive congestion caused by
      non-congestion-controlled flows. When the real-time interactive
      media is congestion controlled, it is recommended that the
      congestion control mechanism operate within the constraints defined by
      these
      circuit breakers when a circuit breaker is present and that it should not
      cause congestion collapse when a circuit breaker is not implemented.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Given that this use case is the focus of this document, use cases
      involving non-interactive media such as video streaming and those
      using multicast/broadcast-type technologies, are out of scope.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">The terminology defined in <span>[<a href="#RFC8825" class="xref">RFC8825</a>]</span>
      is used in this memo.<a href="#section-1-7" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-requirements-language">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.1-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">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>.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-2">
      <h2 id="name-requirements">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements" class="section-name selfRef">Requirements</a>
      </h2>
<ol start="1" type="1" class="normal type-1" id="section-2-1">
        <li id="section-2-1.1">
          <p id="section-2-1.1.1">The congestion control algorithm <span class="bcp14">MUST</span> attempt to provide
          as-low-as-possible-delay transit for interactive real-time traffic
          while still providing a useful amount of bandwidth. There may be
          lower limits on the amount of bandwidth that is useful, but this is
          largely application specific, and the application may be able to
          modify or remove flows in order to allow some useful flows to get
          enough bandwidth. For example, although there might not be enough bandwidth
   for low-latency video+audio, there could be enough for audio only.<a href="#section-2-1.1.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.1.2">
            <li id="section-2-1.1.2.1">Jitter (variation in the bitrate over short timescales) is also
              relevant, though moderate amounts of jitter will be absorbed
              by jitter buffers. Transit delay should be considered to track

              the short-term maximums of delay, including jitter.<a href="#section-2-1.1.2.1" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.1.2.2">The algorithm should provide this as-low-as-possible-delay transit and
              minimize self-induced latency even when faced with intermediate
              bottlenecks and competing flows. Competing flows may limit
              what's possible to achieve.<a href="#section-2-1.1.2.2" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.1.2.3">The algorithm should be resilient to the effects of events, such as
              routing changes, which may alter or remove bottlenecks or change
              the bandwidth available, especially if there is a reduction in
              available bandwidth or increase in observed delay. It is
              expected that the mechanism reacts quickly to such events to
              avoid delay buildup. In the context of this memo, a "quick"
              reaction is on the order of a few RTTs, subject to the
              constraints of the media codec, but is likely within a second.
              Reaction on the next RTT is explicitly not required, since many
              codecs cannot adapt their sending rate that quickly, but 
              at the same time a response cannot be arbitrarily delayed.<a href="#section-2-1.1.2.3" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.1.2.4">The algorithm should react quickly to handle both local and remote
              interface changes (e.g., WLAN to 3G data) that may radically
              change the bandwidth available or bottlenecks, especially if
              there is a reduction in available bandwidth or an increase in
              bottleneck delay. It is assumed that an interface change can
              generate a notification to the algorithm.<a href="#section-2-1.1.2.4" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.1.2.5">The real-time interactive media applications can be rate
              limited. This means the offered loads can be less than the
              available bandwidth at any given moment and may vary
              dramatically over time, including dropping to no load and then
              resuming a high load, such as in a mute/unmute operation. Hence,
              the algorithm must be designed to handle such behavior from
              a media source or application. Note that the reaction time between
              a change in the bandwidth available from the algorithm and a
              change in the offered load is variable, and it may be different
              when increasing versus decreasing.<a href="#section-2-1.1.2.5" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.1.2.6">The algorithm is required to avoid building up queues when
              competing with short-term bursts of traffic (for example,
              traffic generated by web browsing), which can quickly saturate a
              local-bottleneck router or link but clear quickly. The
              algorithm should also react quickly to regain its previous share
              of the bandwidth when the local bottleneck or link is
              cleared.<a href="#section-2-1.1.2.6" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.1.2.7">Similarly, periodic bursty flows such as MPEG DASH <span>[<a href="#MPEG_DASH" class="xref">MPEG_DASH</a>]</span> or proprietary media
     streaming
              algorithms may compete in bursts with the algorithm and may not
              be adaptive within a burst. They are often layered on top of TCP
              but use TCP in a bursty manner that can interact poorly with
              competing flows during the bursts. The algorithm must not
              increase the already existing delay buildup during those bursts.
              Note that this competing traffic may be on a shared access link,
              or the traffic burst may cause a shift in the location of the
              bottleneck for the duration of the burst.<a href="#section-2-1.1.2.7" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.2">
          <p id="section-2-1.2.1">The algorithm <span class="bcp14">MUST</span> be fair to other flows, both real-time flows
          (such as other instances of itself) and TCP flows, both long-lived flows
          and bursts such as the traffic generated by a typical web-browsing
          session. Note that "fair" is a rather hard-to-define term. It <span class="bcp14">SHOULD</span>
          be fair with itself, giving a fair share of the bandwidth to multiple
          flows with similar RTTs, and if possible to multiple flows with
          different RTTs.<a href="#section-2-1.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.2.2">
            <li id="section-2-1.2.2.1">Existing flows at a bottleneck must also be fair to new flows
              to that bottleneck and must allow new flows to ramp up to a
              useful share of the bottleneck bandwidth as quickly as possible.
              A useful share will depend on the media types involved, total
              bandwidth available, and the user-experience requirements of a
              particular service. Note that relative RTTs may affect the rate
       at which new flows can ramp up to a reasonable share.<a href="#section-2-1.2.2.1" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.3">
          <p id="section-2-1.3.1">The algorithm <span class="bcp14">SHOULD NOT</span> starve competing TCP flows and <span class="bcp14">SHOULD</span>,
          as best as possible, avoid starvation by TCP flows.<a href="#section-2-1.3.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.3.2">
            <li id="section-2-1.3.2.1">The congestion control should prioritize achieving a useful
              share of the bandwidth depending on the media types and total
              available bandwidth over achieving as-low-as-possible transit
              delay, when these two requirements are in conflict.<a href="#section-2-1.3.2.1" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.4">
          <p id="section-2-1.4.1">The algorithm <span class="bcp14">SHOULD</span> adapt as quickly as possible to initial
          network conditions at the start of a flow. This <span class="bcp14">SHOULD</span> occur whether
          the initial bandwidth is above or below the bottleneck bandwidth.<a href="#section-2-1.4.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.4.2">
            <li id="section-2-1.4.2.1">The algorithm should allow different modes of adaptation; for
              example, the startup adaptation may be faster than adaptation
              later in a flow. It should allow for both slow-start operation
              (adapt up) and history-based startup (start at a point expected
              to be at or below channel bandwidth from historical information,
              which may need to adapt down quickly if the initial guess is
              wrong). Starting too low and/or adapting up too slowly can cause
              a critical point in a personal communication to be poor
              ("Hello!"). 
              Starting too high above the available bandwidth causes other problems for
              user experience, so there's a tension here. Alternative methods
              to help startup, such as probing during setup with dummy data, may be
              useful in some applications; in some cases, there will be a
              considerable gap in time between flow creation and the initial
              flow of data. Again, a flow may need to change adaptation rates
              due to network conditions or changes in the provided flows (such
              as unmuting or sending data after a gap).<a href="#section-2-1.4.2.1" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.5">
          <p id="section-2-1.5.1">The algorithm <span class="bcp14">SHOULD</span> be stable if the RTP streams are halted or
          discontinuous (for example, when using Voice Activity Detection).<a href="#section-2-1.5.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.5.2">
            <li id="section-2-1.5.2.1">After stream resumption, the algorithm should attempt to
              rapidly regain its previous share of the bandwidth; the
              aggressiveness with which this is done will decay with the
              length of the pause.<a href="#section-2-1.5.2.1" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.6">
          <p id="section-2-1.6.1">Where possible, the algorithm <span class="bcp14">SHOULD</span> merge information across
          multiple RTP streams sent between two endpoints when those RTP
          streams share a common bottleneck, whether or not those streams are
          multiplexed onto the same ports. This will allow congestion
          control of the set of streams together instead of as multiple
          independent streams. It will also allow better overall bandwidth
          management, faster response to changing conditions, and fairer
          sharing of bandwidth with other network users.<a href="#section-2-1.6.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.6.2">
            <li id="section-2-1.6.2.1">The algorithm should also share information and adaptation
              with other non-RTP flows between the same endpoints, such as a
              WebRTC data channel <span>[<a href="#RFC8831" class="xref">RFC8831</a>]</span>, when
              possible.<a href="#section-2-1.6.2.1" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.6.2.2">When there are multiple streams across the same 5-tuple
              coordinating their bandwidth use and congestion control, the
              algorithm should allow the application to control the relative
              split of available bandwidth. The most correlated bandwidth
              usage would be with other flows on the same 5-tuple, but there
              may be use in coordinating measurement and control of the local
              link(s). Use of information about previous flows, especially on
              the same 5-tuple, may be useful input to the algorithm,
              especially regarding startup performance of a new flow.<a href="#section-2-1.6.2.2" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.7">
          <p id="section-2-1.7.1">The algorithm <span class="bcp14">SHOULD NOT</span> require any special support from network
          elements to be able to convey congestion-related information.
          As much as possible, it <span class="bcp14">SHOULD</span> leverage available information about
          the incoming flow to provide feedback to the sender. Examples of
          this information are the packet arrival times, acknowledgements and
          feedback, packet timestamps, packet losses, and Explicit Congestion
          Notification (ECN) <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span>; all of these can
          provide information about the state of the path and any bottlenecks.
          However, the use of available information is algorithm
          dependent.<a href="#section-2-1.7.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.7.2">
            <li id="section-2-1.7.2.1">Extra information could be added to the packets to provide
              more detailed information on actual send times (as opposed to
              sampling times), but such information should not be required.<a href="#section-2-1.7.2.1" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.8">
          <p id="section-2-1.8.1">Since the assumption here is a set of RTP streams, the
          backchannel typically <span class="bcp14">SHOULD</span> be done via the RTP Control Protocol
   (RTCP) <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>; instead, one alternative
   would be to include it
          in a reverse-RTP channel using header extensions.<a href="#section-2-1.8.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2-1.8.2">
            <li id="section-2-1.8.2.1">In order to react sufficiently quickly when using RTCP for a
              backchannel, an RTP profile such as RTP/AVPF <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span> or RTP/SAVPF <span>[<a href="#RFC5124" class="xref">RFC5124</a>]</span> that allows sufficiently frequent
              feedback must be used. Note that in some cases, backchannel
              messages may be delayed until the RTCP channel can be allocated
              enough bandwidth, even under AVPF rules. This may also imply
              negotiating a higher maximum percentage for RTCP data or
              allowing solutions to violate or modify the rules specified for
              AVPF.<a href="#section-2-1.8.2.1" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.8.2.2">Bandwidth for the feedback messages should be minimized
     using techniques such as those in <span>[<a href="#RFC5506" class="xref">RFC5506</a>]</span>, to allow RTCP
              without Sender/Receiver Reports.<a href="#section-2-1.8.2.2" class="pilcrow">¶</a>
</li>
            <li id="section-2-1.8.2.3">Backchannel data should be minimized to avoid taking too much
              reverse-channel bandwidth (since this will often be used in a
              bidirectional set of flows). In areas of stability, backchannel
              data may be sent more infrequently so long as algorithm
              stability and fairness are maintained. When the channel is
              unstable or has not yet reached equilibrium after a change,
              backchannel feedback may be more frequent and use more
              reverse-channel bandwidth. This is an area with considerable
              flexibility of design, and different approaches to backchannel
              messages and frequency are expected to be evaluated.<a href="#section-2-1.8.2.3" class="pilcrow">¶</a>
</li>
          </ol>
</li>
        <li id="section-2-1.9">
          <p id="section-2-1.9.1">Flows managed by this algorithm and flows competing against each
   other at a
          bottleneck may have different Differentiated Services Code Point
   (DSCP) <span>[<a href="#RFC5865" class="xref">RFC5865</a>]</span>
          markings depending on the type of traffic or may be subject to
          flow-based QoS. A particular bottleneck or section of the network
          path may or may not honor DSCP markings. The algorithm <span class="bcp14">SHOULD</span>
          attempt to leverage DSCP markings when they're available.<a href="#section-2-1.9.1" class="pilcrow">¶</a></p>
</li>
        <li id="section-2-1.10">The algorithm <span class="bcp14">SHOULD</span> sense the unexpected lack of backchannel
          information as a possible indication of a channel-overuse problem
          and react accordingly to avoid burst events causing a congestion
          collapse.<a href="#section-2-1.10" class="pilcrow">¶</a>
</li>
        <li id="section-2-1.11">The algorithm <span class="bcp14">SHOULD</span> be stable and maintain low delay when faced
          with Active Queue Management (AQM) algorithms. Also note that these
          algorithms may apply across multiple queues in the bottleneck or to
          a single queue.<a href="#section-2-1.11" class="pilcrow">¶</a>
</li>
      </ol>
</section>
<section id="section-3">
      <h2 id="name-deficiencies-of-existing-me">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-deficiencies-of-existing-me" class="section-name selfRef">Deficiencies of Existing Mechanisms</a>
      </h2>
<p id="section-3-1">Among the existing congestion control mechanisms, TCP Friendly Rate
      Control (TFRC) <span>[<a href="#RFC5348" class="xref">RFC5348</a>]</span> is the one that claims to
      be suitable for real-time interactive media. TFRC is an equation-based
      congestion control mechanism that provides a reasonably fair share of 
      bandwidth when competing with TCP flows and offers much lower throughput
      variations than TCP. This is achieved by a slower response to the
      available bandwidth change than TCP. TFRC is designed to perform best
      with applications that have a fixed packet size and do not have a fixed
      period between sending packets.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">TFRC detects loss events and reacts to congestion-caused loss by
      reducing its sending rate. It allows applications to
      increase the sending rate until loss is observed in the flows. As
      noted in IAB/IRTF report <span>[<a href="#RFC7295" class="xref">RFC7295</a>]</span>, large buffers
      are available in the network elements, which introduce additional delay
      in the communication. It becomes important to take all possible
      congestion indications into consideration. Looking at the current
      Internet deployment, TFRC's biggest deficiency is that it only considers
      loss events as a congestion indication.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">A typical real-time interactive communication includes live-encoded
      audio and video flow(s). In such a communication scenario, an audio 
      source typically needs a fixed interval between packets and needs to
      vary the segment size of the packets instead of the packet rate in
      response to congestion; therefore, it sends smaller packets.
      A variant of TFRC, Small-Packet
      TFRC (TFRC-SP) <span>[<a href="#RFC4828" class="xref">RFC4828</a>]</span>, addresses the issues
      related to such kind of sources. A video source generally varies video
      frame sizes, can produce large frames that need to be further
      fragmented to fit into path Maximum Transmission Unit (MTU) size, and
      has an almost fixed interval between producing frames under a certain
      frame rate. TFRC is known to be less optimal when using such video
      sources.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">There are also some mismatches between TFRC's design assumptions and
      how the media sources in a typical real-time interactive application
      work. TFRC is designed to maintain a smooth sending rate; however, media
      sources can change rates in steps for both rate increase and rate
      decrease. TFRC can operate in two modes: i) bytes per second and ii)
      packets per second, where typical real-time interactive media sources
      operate on bit per second. There are also limitations on how quickly
      the media sources can adapt to specific sending rates. Modern video
      encoders can operate in a mode in which they can vary the output bitrate a
      lot depending on the way they are configured, the current scene they are
      encoding, and more. Therefore, it is possible that the video source will
      not always output at an allowable bitrate. TFRC tries to increase
      its sending rate when transmitting at the maximum allowed rate, and it increases
      only twice the current transmission rate; hence, it may create issues when
      the video sources vary their bitrates.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">Moreover, there are a number of studies on TFRC that show its
      limitations, including TFRC's unfairness to low statistically 
      multiplexed links, oscillatory behavior, performance issues in highly
      dynamic loss-rate conditions, and more <span>[<a href="#CH09" class="xref">CH09</a>]</span>.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">Looking at all these deficiencies, it can be concluded that the
      requirements for a congestion control mechanism for real-time interactive
      media cannot be met by TFRC as defined in the standard.<a href="#section-3-6" class="pilcrow">¶</a></p>
</section>
<div id="IANA">
<section id="section-4">
      <h2 id="name-iana-considerations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-4-1">This document has no IANA actions.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">An attacker with the ability to delete, delay, or insert messages into
      the flow can fake congestion signals, unless they are passed on a
      tamper-proof path. Since some possible algorithms depend on the timing
      of packet arrival, even a traditional, protected channel does not fully
      mitigate such attacks.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">An attack that reduces bandwidth is not necessarily significant,
      since an on-path attacker could break the connection by discarding all
      packets. Attacks that increase the perceived available bandwidth are
      conceivable and need to be evaluated. Such attacks could result in
      starvation of competing flows and permit amplification attacks.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">Algorithm designers should consider the possibility of malicious
      on-path attackers.<a href="#section-5-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6">
      <h2 id="name-references">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-6.1">
        <h3 id="name-normative-references">
<a href="#section-6.1" class="section-number selfRef">6.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" class="refDate">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>
<dd class="break"></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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC4585">[RFC4585]</dt>
        <dd>
<span class="refAuthor">Ott, J.</span><span class="refAuthor">, Wenger, S.</span><span class="refAuthor">, Sato, N.</span><span class="refAuthor">, Burmeister, C.</span><span class="refAuthor">, and J. Rey</span>, <span class="refTitle">"Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"</span>, <span class="seriesInfo">RFC 4585</span>, <span class="seriesInfo">DOI 10.17487/RFC4585</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4585">https://www.rfc-editor.org/info/rfc4585</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5124">[RFC5124]</dt>
        <dd>
<span class="refAuthor">Ott, J.</span><span class="refAuthor"> and E. Carrara</span>, <span class="refTitle">"Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"</span>, <span class="seriesInfo">RFC 5124</span>, <span class="seriesInfo">DOI 10.17487/RFC5124</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5124">https://www.rfc-editor.org/info/rfc5124</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8825">[RFC8825]</dt>
      <dd>
<span class="refAuthor">Alvestrand, H.</span>, <span class="refTitle">"Overview: Real-Time Protocols for Browser-Based Applications"</span>, <span class="seriesInfo">RFC 8825</span>, <span class="seriesInfo">DOI 10.17487/RFC8825</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8825">https://www.rfc-editor.org/info/rfc8825</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-6.2">
        <h3 id="name-informative-references">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CH09">[CH09]</dt>
        <dd>
<span class="refAuthor">Choi, S.</span><span class="refAuthor"> and M. Handley</span>, <span class="refTitle">"Designing TCP-Friendly Window-based Congestion Control for Real-time Multimedia Applications"</span>, <span class="refContent">Proceedings of PFLDNeT</span>, <time datetime="2009-05" class="refDate">May 2009</time>. </dd>
<dd class="break"></dd>
<dt id="MPEG_DASH">[MPEG_DASH]</dt>
        <dd>
<span class="refAuthor">ISO</span>, <span class="refTitle">"Information Technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats"</span>, <span class="seriesInfo">ISO/IEC 23009-1:2019</span>, <time datetime="2019-12" class="refDate">December 2019</time>, <span>&lt;<a href="https://www.iso.org/standard/79329.html">https://www.iso.org/standard/79329.html</a>&gt;</span>. </dd>
<dd class="break"></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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC4828">[RFC4828]</dt>
        <dd>
<span class="refAuthor">Floyd, S.</span><span class="refAuthor"> and E. Kohler</span>, <span class="refTitle">"TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant"</span>, <span class="seriesInfo">RFC 4828</span>, <span class="seriesInfo">DOI 10.17487/RFC4828</span>, <time datetime="2007-04" class="refDate">April 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4828">https://www.rfc-editor.org/info/rfc4828</a>&gt;</span>. </dd>
<dd class="break"></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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC5506">[RFC5506]</dt>
        <dd>
<span class="refAuthor">Johansson, I.</span><span class="refAuthor"> and M. Westerlund</span>, <span class="refTitle">"Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences"</span>, <span class="seriesInfo">RFC 5506</span>, <span class="seriesInfo">DOI 10.17487/RFC5506</span>, <time datetime="2009-04" class="refDate">April 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5506">https://www.rfc-editor.org/info/rfc5506</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5865">[RFC5865]</dt>
        <dd>
<span class="refAuthor">Baker, F.</span><span class="refAuthor">, Polk, J.</span><span class="refAuthor">, and M. Dolly</span>, <span class="refTitle">"A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic"</span>, <span class="seriesInfo">RFC 5865</span>, <span class="seriesInfo">DOI 10.17487/RFC5865</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5865">https://www.rfc-editor.org/info/rfc5865</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7295">[RFC7295]</dt>
        <dd>
<span class="refAuthor">Tschofenig, H.</span><span class="refAuthor">, Eggert, L.</span><span class="refAuthor">, and Z. Sarker</span>, <span class="refTitle">"Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication"</span>, <span class="seriesInfo">RFC 7295</span>, <span class="seriesInfo">DOI 10.17487/RFC7295</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7295">https://www.rfc-editor.org/info/rfc7295</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8083">[RFC8083]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and V. Singh</span>, <span class="refTitle">"Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions"</span>, <span class="seriesInfo">RFC 8083</span>, <span class="seriesInfo">DOI 10.17487/RFC8083</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8083">https://www.rfc-editor.org/info/rfc8083</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8831">[RFC8831]</dt>
      <dd>
<span class="refAuthor">Jesup, R.</span><span class="refAuthor">, Loreto, S.</span><span class="refAuthor">, and M. Tüxen</span>, <span class="refTitle">"WebRTC Data Channels"</span>, <span class="seriesInfo">RFC 8831</span>, <span class="seriesInfo">DOI 10.17487/RFC8831</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8831">https://www.rfc-editor.org/info/rfc8831</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">This document is the result of discussions in various fora of the
      WebRTC effort, in particular on the &lt;rtp-congestion@alvestrand.no&gt; mailing
      list. Many people contributed their thoughts to this.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <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">Randell Jesup</span></div>
<div dir="auto" class="left"><span class="org">Mozilla</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:randell-ietf@jesup.org" class="email">randell-ietf@jesup.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Zaheduzzaman Sarker (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Ericsson AB</span></div>
<div dir="auto" class="left"><span class="street-address">Torshamnsgatan 23</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">164 83</span> <span class="locality">Stockholm</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+46%2010%20717%2037%2043" class="tel">+46 10 717 37 43</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:zaheduzzaman.sarker@ericsson.com" class="email">zaheduzzaman.sarker@ericsson.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>