File: rfc8888.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 (2140 lines) | stat: -rw-r--r-- 95,141 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 8888: RTP Control Protocol (RTCP) Feedback for Congestion Control</title>
<meta content="Zaheduzzaman Sarker" name="author">
<meta content="Colin Perkins" name="author">
<meta content="Varun Singh" name="author">
<meta content="Michael A. Ramalho" name="author">
<meta content="
       
        An effective RTP congestion control algorithm requires more fine-grained
        feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the
        standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver
        Report (RR) packets.
        This document describes an RTCP feedback message intended to enable
        congestion control for interactive real-time traffic using RTP. The
        feedback message is designed for use with a sender-based congestion
        control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP
        feedback packets containing the information the sender
        needs to perform congestion control.
       
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="Congestion control" name="keyword">
<meta content="feedback message" name="keyword">
<meta content="RTP" name="keyword">
<meta content="RTCP" name="keyword">
<meta content="8888" 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="rfc8888.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/rfc8888" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-avtcore-cc-feedback-message-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 8888</td>
<td class="center">Congestion Control Feedback in RTCP</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Sarker, et al.</td>
<td class="center">Standards Track</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/rfc8888" class="eref">8888</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</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">Z. Sarker</div>
<div class="org">Ericsson AB</div>
</div>
<div class="author">
      <div class="author-name">C. Perkins</div>
<div class="org">University of Glasgow</div>
</div>
<div class="author">
      <div class="author-name">V. Singh</div>
<div class="org">callstats.io</div>
</div>
<div class="author">
      <div class="author-name">M. Ramalho</div>
<div class="org">AcousticComms</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8888</h1>
<h1 id="title">RTP Control Protocol (RTCP) Feedback for Congestion Control</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        An effective RTP congestion control algorithm requires more fine-grained
        feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the
        standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver
        Report (RR) packets.
        This document describes an RTCP feedback message intended to enable
        congestion control for interactive real-time traffic using RTP. The
        feedback message is designed for use with a sender-based congestion
        control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP
        feedback packets containing the information the sender
        needs to perform congestion control.<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 is an Internet Standards Track document.<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).  Further
            information on Internet Standards is available in 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/rfc8888">https://www.rfc-editor.org/info/rfc8888</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="toc ulEmpty compact">
<li class="toc ulEmpty compact" 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>
</li>
          <li class="toc ulEmpty compact" 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-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" 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-rtcp-feedback-for-congestio" class="xref">RTCP Feedback for Congestion Control</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-rtcp-congestion-control-fee" class="xref">RTCP Congestion Control Feedback Report</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" 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-feedback-frequency-and-over" class="xref">Feedback Frequency and Overhead</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" 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-response-to-loss-of-feedbac" class="xref">Response to Loss of Feedback Packets</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" 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-sdp-signaling" class="xref">SDP Signaling</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" 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-relationship-to-rfc-6679" class="xref">Relationship to RFC 6679</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" 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-design-rationale" class="xref">Design Rationale</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" 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 compact" 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 compact" 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 compact ulEmpty">
<li class="toc compact 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 compact 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 compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" 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-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.13.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">For interactive real-time traffic, such as video conferencing
      flows, the typical protocol choice is the Real-time Transport
      Protocol (RTP) <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> running over the User Datagram Protocol (UDP). RTP
      does not provide any guarantee of Quality of Service (QoS), reliability,
      or timely delivery, and expects the underlying transport protocol to
      do so.  UDP alone certainly does not meet that expectation. However,
      the RTP Control Protocol (RTCP) <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> provides a mechanism by which the
      receiver of an RTP flow can periodically send transport and media
      quality metrics to the sender of that RTP flow. This information can
      be used by the sender to perform congestion control.  In the absence
      of standardized messages for this purpose, designers of congestion
      control algorithms have developed proprietary RTCP messages that
      convey only those parameters needed for their respective designs.
      As a direct result, the different congestion control
      designs are not interoperable.  To enable algorithm
      evolution as well as interoperability across designs (e.g., different
      rate adaptation algorithms), it is highly desirable to have a generic
      congestion control feedback format.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">To help achieve interoperability for unicast RTP congestion control,
      this memo specifies a common RTCP feedback packet format that can be used by
      Network-Assisted Dynamic Adaptation
      (NADA) <span>[<a href="#RFC8698" class="xref">RFC8698</a>]</span>, 
      Self-Clocked Rate Adaptation for Multimedia (SCReAM) <span>[<a href="#RFC8298" class="xref">RFC8298</a>]</span>, Google Congestion Control
      <span>[<a href="#Google-GCC" class="xref">Google-GCC</a>]</span>, and Shared Bottleneck
      Detection <span>[<a href="#RFC8382" class="xref">RFC8382</a>]</span>, and, hopefully,
      also by future RTP congestion control algorithms.<a href="#section-1-2" class="pilcrow">¶</a></p>
</section>
<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>
<p id="section-2-2">In addition, the terminology defined in <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>,
      <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>, and <span>[<a href="#RFC5506" class="xref">RFC5506</a>]</span> applies.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
<div id="feedback_message">
<section id="section-3">
      <h2 id="name-rtcp-feedback-for-congestio">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-rtcp-feedback-for-congestio" class="section-name selfRef">RTCP Feedback for Congestion Control</a>
      </h2>
<p id="section-3-1">Based on an analysis of NADA <span>[<a href="#RFC8698" class="xref">RFC8698</a>]</span>,
      SCReAM <span>[<a href="#RFC8298" class="xref">RFC8298</a>]</span>, Google
      Congestion Control <span>[<a href="#Google-GCC" class="xref">Google-GCC</a>]</span>, and
      Shared Bottleneck Detection <span>[<a href="#RFC8382" class="xref">RFC8382</a>]</span>,
      the following per-RTP packet congestion control feedback information
      has been determined to be necessary:<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-2">
        <dt id="section-3-2.1">RTP Sequence Number:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.2">The receiver of an RTP flow needs to feed
          the sequence numbers of the received RTP packets back to the sender, so the
          sender can determine which packets were received and which were lost.
          Packet loss is used as an indication of congestion by many congestion
          control algorithms.<a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">Packet Arrival Time:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.4">The receiver of an RTP flow needs to feed
          the arrival time of each RTP packet back to the sender. Packet delay and/or
          delay variation (jitter) is used as a congestion signal by some congestion
          control algorithms.<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.5">Packet Explicit Congestion Notification (ECN) Marking:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.6">If ECN
          <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span> <span>[<a href="#RFC6679" class="xref">RFC6679</a>]</span> is
          used, it is necessary to feed back the 2-bit ECN mark in received
          RTP packets, indicating for each RTP packet whether it is marked
          not-ECT, ECT(0), ECT(1), or ECN Congestion Experienced (ECN-CE).
          ("ECT" stands for "ECN-Capable Transport".) If the path used by the RTP
          traffic is ECN capable, the sender can use ECN-CE marking information as a congestion control signal.<a href="#section-3-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-3">Every RTP flow is identified by its Synchronization Source (SSRC)
      identifier. Accordingly, the RTCP feedback format needs to group its
      reports by SSRC, sending one report block per received SSRC.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">As a practical matter, we note that host operating system (OS)
      process interruptions can occur at inopportune times. Accordingly,
      recording RTP packet send times at the sender, and the corresponding
      RTP packet arrival times at the
      receiver, needs to be done with deliberate care. This is because the time
      duration of host OS interruptions can be significant relative to the
      precision desired in the one-way delay estimates. Specifically, the send
      time needs to be recorded at the last opportunity prior to transmitting
      the RTP packet at the sender, and the arrival time at the receiver needs
      to be recorded at the earliest available opportunity.<a href="#section-3-4" class="pilcrow">¶</a></p>
<div id="sec_ccfb">
<section id="section-3.1">
        <h3 id="name-rtcp-congestion-control-fee">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-rtcp-congestion-control-fee" class="section-name selfRef">RTCP Congestion Control Feedback Report</a>
        </h3>
<p id="section-3.1-1">Congestion control feedback can be sent as part of a regular
        scheduled RTCP report or in an RTP/AVPF early feedback packet. 
        If sent as early feedback, congestion control feedback <span class="bcp14">MAY</span> be 
        sent in a non-compound RTCP packet <span>[<a href="#RFC5506" class="xref">RFC5506</a>]</span> 
        if the RTP/AVPF profile <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span> or the 
        RTP/SAVPF profile <span>[<a href="#RFC5124" class="xref">RFC5124</a>]</span> is used.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Irrespective of how it is transported, the congestion control 
        feedback is sent as a Transport-Layer Feedback Message (RTCP packet 
        type 205). The format of this RTCP packet is shown in 
        <a href="#rtcp-packet" class="xref">Figure 1</a>:<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<span id="name-rtcp-congestion-control-feed"></span><div id="rtcp-packet">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-3.1-3.1">
<pre>
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V=2|P| FMT=11  |   PT = 205    |          length               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 SSRC of RTCP packet sender                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   SSRC of 1st RTP Stream                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          begin_seq            |          num_reports          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|ECN|  Arrival time offset    | ...                           .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                               .
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   SSRC of nth RTP Stream                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          begin_seq            |          num_reports          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|ECN|  Arrival time offset    | ...                           |
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Report Timestamp (32 bits)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-rtcp-congestion-control-feed" class="selfRef">RTCP Congestion Control Feedback Packet Format</a>
          </figcaption></figure>
</div>
<p id="section-3.1-4">The first 8 octets comprise a standard RTCP header, with
        PT=205 and FMT=11 indicating that this is a congestion control
        feedback packet, and with the SSRC set to that of the sender of
        the RTCP packet.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5"><span><a href="https://www.rfc-editor.org/rfc/rfc4585#section-6.1" class="relref">Section 6.1</a> of [<a href="#RFC4585" class="xref">RFC4585</a>]</span>
        requires the RTCP
        header to be followed by the SSRC of the RTP flow being reported 
        upon.  Accordingly, the RTCP header is followed by a report block
        for each SSRC from which RTP packets have been received, followed
        by a Report Timestamp.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">Each report block begins with the SSRC of the received RTP stream
        on which it is reporting. Following this, the report block contains a
        16-bit packet metric block for each RTP packet that has a sequence number
        in the range begin_seq to begin_seq+num_reports inclusive (calculated using
        arithmetic modulo 65536 to account for possible sequence number wrap-around).
        If the number of 16-bit packet metric blocks included in the report
        block is not a multiple of two, then 16 bits of zero padding <span class="bcp14">MUST</span> be
        added after the last packet metric block, to align the end of the
        packet metric blocks with the next 32-bit boundary.
        The value of num_reports <span class="bcp14">MAY</span> be 0, indicating that there are no
        packet metric blocks included for that SSRC.
        Each report block <span class="bcp14">MUST NOT</span> include more than 16384 packet metric blocks
        (i.e., it <span class="bcp14">MUST NOT</span> report on more than one quarter of the sequence
        number space in a single report).<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">
        The contents of each 16-bit packet metric block comprise the R, ECN,
        and ATO fields as follows:<a href="#section-3.1-7" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1-8">
          <dt id="section-3.1-8.1">Received (R, 1 bit):</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-8.2">A boolean that indicates whether the packet was
              received.  0 indicates that the packet was not yet received and
              the subsequent 15 bits (ECN and ATO) in this 16-bit packet
              metric block are also set to 0 and <span class="bcp14">MUST</span> be ignored.
              1 indicates that the packet was received and the subsequent
              bits in the block need to be parsed.<a href="#section-3.1-8.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-8.3">ECN (2 bits):</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-8.4">The echoed ECN mark of the packet. These bits
              are set to 00 if not received or if ECN is not used.<a href="#section-3.1-8.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-8.5">Arrival time offset (ATO, 13 bits):</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-8.6">The arrival time of
              the RTP packet at the receiver, as an offset before the time
              represented by the Report Timestamp (RTS) field of this RTCP congestion control
              feedback report. The ATO field is in units of 1/1024 seconds
              (this unit is chosen to give exact offsets from the RTS field)
              so, for example, an ATO value of 512 indicates that the
              corresponding RTP packet arrived exactly half a second before
              the time instant represented by the RTS field.
              If the measured value is greater than 8189/1024 seconds (the
              value that would be coded as 0x1FFD), the value 0x1FFE <span class="bcp14">MUST</span>
              be reported to indicate an over-range measurement.
              If the measurement is unavailable or if the arrival time of
              the RTP packet is after the time represented by the RTS field,
              then an ATO value of 0x1FFF <span class="bcp14">MUST</span> be reported for the packet.<a href="#section-3.1-8.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-3.1-9">The RTCP congestion control feedback report packet concludes with
        the Report Timestamp field (RTS, 32 bits). This denotes the time
        instant on which this packet is reporting and is the instant from
        which the arrival time offset values are calculated.
        The value of the RTS field is derived from the same clock used to generate
        the NTP timestamp field in RTCP Sender Report (SR) packets. It
        is formatted as the middle 32 bits of an NTP format timestamp, as 
        described in <span><a href="https://www.rfc-editor.org/rfc/rfc3550#section-4" class="relref">Section 4</a> of [<a href="#RFC3550" class="xref">RFC3550</a>]</span>.<a href="#section-3.1-9" class="pilcrow">¶</a></p>
<p id="section-3.1-10">RTCP Congestion Control Feedback Packets <span class="bcp14">SHOULD</span> include a report
        block for every active SSRC. The sequence
        number ranges reported on in consecutive reports for a given SSRC will
        generally be contiguous, but overlapping reports <span class="bcp14">MAY</span> be sent (and need
        to be sent in cases where RTP packet reordering occurs across the
        boundary between consecutive reports).
        If an RTP packet was reported as received in one report, that packet
        <span class="bcp14">MUST</span> also be reported as received in any overlapping reports sent later that cover its sequence number range.
If feedback reports covering overlapping sequence number ranges are sent,
information in later feedback reports may update any data sent in previous
reports for RTP packets included in both feedback reports.<a href="#section-3.1-10" class="pilcrow">¶</a></p>
<p id="section-3.1-11">RTCP Congestion Control Feedback Packets can be large if they are
        sent infrequently relative to the number of RTP data packets.  If an
        RTCP Congestion Control Feedback Packet is too large to fit within the
        path MTU, its sender <span class="bcp14">SHOULD</span> split it into multiple feedback packets.
        The RTCP reporting interval <span class="bcp14">SHOULD</span> be chosen such that feedback packets
        are sent often enough that they are small enough to fit within the path
        MTU. (<span>[<a href="#I-D.ietf-rmcat-rtp-cc-feedback" class="xref">RTCP-Multimedia-Feedback</a>]</span> discusses how to
        choose the reporting interval; specifications for RTP congestion control
        algorithms can also provide guidance.)<a href="#section-3.1-11" class="pilcrow">¶</a></p>
<p id="section-3.1-12">If duplicate copies of a particular RTP packet are received, then the
        arrival time of the first copy to arrive <span class="bcp14">MUST</span> be reported. If any of the
        copies of the duplicated packet are ECN-CE marked, then an ECN-CE mark
        <span class="bcp14">MUST</span> be reported for that packet; otherwise, the ECN mark of the first
        copy to arrive is reported.<a href="#section-3.1-12" class="pilcrow">¶</a></p>
<p id="section-3.1-13">If no packets are received from an SSRC in a reporting interval,
        a report block <span class="bcp14">MAY</span> be sent with begin_seq set to the highest sequence
        number previously received from that SSRC and num_reports set to 0
        (or the report can simply be omitted). The corresponding 
        Sender Report / Receiver Report (SR/RR) packet 
        will have a non-increased extended highest sequence number received
        field that will inform the sender that no packets have been received,
        but it can ease processing to have that information available in the
        congestion control feedback reports too.<a href="#section-3.1-13" class="pilcrow">¶</a></p>
<p id="section-3.1-14">A report block indicating that certain RTP packets were lost is
        not to be interpreted as a request to retransmit the lost packets.
        The receiver of such a report might choose to retransmit such packets,
        provided a retransmission payload format has been negotiated, but
        there is no requirement that it do so.<a href="#section-3.1-14" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-4">
      <h2 id="name-feedback-frequency-and-over">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-feedback-frequency-and-over" class="section-name selfRef">Feedback Frequency and Overhead</a>
      </h2>
<p id="section-4-1">There is a trade-off between speed and accuracy of reporting, and the
      overhead of the reports. <span>[<a href="#I-D.ietf-rmcat-rtp-cc-feedback" class="xref">RTCP-Multimedia-Feedback</a>]</span>
      discusses this trade-off, suggests desirable RTCP feedback rates, and
      provides guidance on how to configure, for example, the RTCP bandwidth fraction 
      to make appropriate use of the reporting block described in this memo.
      Specifications for RTP congestion control algorithms can also provide
      guidance.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">It is generally understood that congestion control algorithms work
      better with more frequent feedback.
      However, RTCP bandwidth and transmission rules put some upper limits
      on how frequently the RTCP feedback messages can be sent from an RTP
      receiver to the RTP sender.
      
      In many cases, sending feedback once per frame is an upper bound
      before the reporting overhead becomes excessive, although this will
      depend on the media rate and more frequent feedback might be needed
      with high-rate media flows <span>[<a href="#I-D.ietf-rmcat-rtp-cc-feedback" class="xref">RTCP-Multimedia-Feedback</a>]</span>.
      Analysis <span>[<a href="#feedback-requirements" class="xref">feedback-requirements</a>]</span> has also shown
      that some candidate congestion control algorithms can operate with less
      frequent feedback, using a feedback interval range of 50-200 ms.
      Applications need to negotiate an appropriate congestion control
      feedback interval at session setup time, based on the choice of
      congestion control algorithm, the expected media bitrate, and
      the acceptable feedback overhead.<a href="#section-4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-5">
      <h2 id="name-response-to-loss-of-feedbac">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-response-to-loss-of-feedbac" class="section-name selfRef">Response to Loss of Feedback Packets</a>
      </h2>
<p id="section-5-1">
        Like all RTCP packets, RTCP Congestion Control Feedback Packets
        might be lost. All RTP congestion control algorithms <span class="bcp14">MUST</span> specify
        how they respond to the loss of feedback packets.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
        RTCP packets do not contain a sequence number, so loss of feedback
        packets has to be inferred based on the time since the last feedback
        packet.
        If only a single congestion control feedback packet is lost, an
        appropriate response is to assume that the level of congestion
        has remained roughly the same as the previous report. However,
        if multiple consecutive congestion control feedback packets are
        lost, then the media sender <span class="bcp14">SHOULD</span> rapidly reduce its sending rate as
        this likely indicates a path failure. The RTP circuit
        breaker specification <span>[<a href="#RFC8083" class="xref">RFC8083</a>]</span> provides further guidance.<a href="#section-5-2" class="pilcrow">¶</a></p>
</section>
<section id="section-6">
      <h2 id="name-sdp-signaling">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-sdp-signaling" class="section-name selfRef">SDP Signaling</a>
      </h2>
<p id="section-6-1">
        A new "ack" feedback parameter, "ccfb", is defined for use with the
        "a=rtcp-fb:" Session Description Protocol (SDP) extension to indicate the use of the RTP Congestion
        Control Feedback Packet format defined in <a href="#feedback_message" class="xref">Section 3</a>.
        The ABNF definition <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span> of this SDP parameter extension is:<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="section-6-2">
<pre class="sourcecode lang-abnf">
        rtcp-fb-ack-param = &lt;See Section 4.2 of [RFC4585]&gt;
        rtcp-fb-ack-param =/ ccfb-par
        ccfb-par          = SP "ccfb"</pre><a href="#section-6-2" class="pilcrow">¶</a>
</div>
<p id="section-6-3">
        The payload type used with "ccfb" feedback <span class="bcp14">MUST</span> be the wildcard type ("*").
        This implies that the congestion control feedback is sent
        for all payload types in use in the session, including any Forward Error Correction (FEC) and
        retransmission payload types.
        An example of the resulting SDP attribute is:<a href="#section-6-3" class="pilcrow">¶</a></p>
<div id="section-6-4">
<pre class="sourcecode lang-sdp">
        a=rtcp-fb:* ack ccfb</pre><a href="#section-6-4" class="pilcrow">¶</a>
</div>
<p id="section-6-5">
        The offer/answer rules for these SDP feedback parameters are
        specified in <span><a href="https://www.rfc-editor.org/rfc/rfc4585#section-4.2" class="relref">Section 4.2</a> of the RTP/AVPF profile [<a href="#RFC4585" class="xref">RFC4585</a>]</span>.<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">
        An SDP offer might indicate support for both the congestion control
        feedback mechanism specified in this memo and one or more alternative
        congestion control feedback mechanisms that offer substantially the
        same semantics. In this case, the answering party <span class="bcp14">SHOULD</span> include
        only one of the offered congestion control feedback mechanisms in its
        answer.  If a subsequent offer containing the same set of congestion control
        feedback mechanisms is received, the generated answer <span class="bcp14">SHOULD</span> choose
        the same congestion control feedback mechanism as in the original
        answer where possible.<a href="#section-6-6" class="pilcrow">¶</a></p>
<p id="section-6-7">
        When the SDP BUNDLE extension <span>[<a href="#RFC8843" class="xref">RFC8843</a>]</span>
        is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing category
        IDENTICAL-PER-PT <span>[<a href="#RFC8859" class="xref">RFC8859</a>]</span>.<a href="#section-6-7" class="pilcrow">¶</a></p>
</section>
<section id="section-7">
      <h2 id="name-relationship-to-rfc-6679">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-relationship-to-rfc-6679" class="section-name selfRef">Relationship to RFC 6679</a>
      </h2>
<p id="section-7-1">
        The use of Explicit Congestion Notification (ECN) with RTP is
        described in <span>[<a href="#RFC6679" class="xref">RFC6679</a>]</span>, which specifies how
        to negotiate the use of ECN with RTP and defines an RTCP ECN
        Feedback Packet to carry ECN feedback reports. It uses an SDP
        "a=ecn-capable-rtp:" attribute to negotiate the use of ECN, and
        the "a=rtcp-fb:" attribute with the "nack" parameter "ecn" to
        negotiate the use of RTCP ECN Feedback Packets.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
        The RTCP ECN Feedback Packet is not useful when ECN is used with
        the RTP Congestion Control Feedback Packet defined in this memo,
        since it provides duplicate information. When
        congestion control feedback is to be used with RTP and ECN,
        the SDP offer generated <span class="bcp14">MUST</span> include an "a=ecn-capable-rtp:"
        attribute to negotiate ECN support, along with an "a=rtcp-fb:"
        attribute with the "ack" parameter "ccfb" to indicate that the
        RTP Congestion Control Feedback Packet can be used.
        The "a=rtcp-fb:" attribute <span class="bcp14">MAY</span> also include the "nack" parameter
        "ecn" to indicate that the RTCP ECN Feedback Packet is also
        supported. If an SDP offer signals support for both RTP
        Congestion Control Feedback Packets and the RTCP ECN Feedback
        Packet, the answering party <span class="bcp14">SHOULD</span> signal support for one, but
        not both, formats in its SDP answer to avoid sending duplicate
        feedback.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
        When using ECN with RTP, the guidelines in <span><a href="https://www.rfc-editor.org/rfc/rfc6679#section-7.2" class="relref">Section 7.2</a> of [<a href="#RFC6679" class="xref">RFC6679</a>]</span>
        <span class="bcp14">MUST</span> be followed to initiate the use of ECN in an
        RTP session. The guidelines in <span><a href="https://www.rfc-editor.org/rfc/rfc6679#section-7.3" class="relref">Section 7.3</a> of [<a href="#RFC6679" class="xref">RFC6679</a>]</span> regarding the ongoing use of ECN within an RTP
        session <span class="bcp14">MUST</span> also be followed, with the exception that feedback is sent using the RTCP
        Congestion Control Feedback Packets described in this memo rather
        than using RTP ECN Feedback Packets. Similarly, the guidance
        in <span><a href="https://www.rfc-editor.org/rfc/rfc6679#section-7.4" class="relref">Section 7.4</a> of [<a href="#RFC6679" class="xref">RFC6679</a>]</span>
 related to detecting failures
        <span class="bcp14">MUST</span> be followed, with the exception that the necessary information is
        retrieved from the RTCP Congestion Control Feedback Packets rather than
        from RTP ECN Feedback Packets.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
<section id="section-8">
      <h2 id="name-design-rationale">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-design-rationale" class="section-name selfRef">Design Rationale</a>
      </h2>
<p id="section-8-1">The primary function of RTCP SR/RR packets is to report statistics
      on the reception of RTP packets. The reception report blocks sent in
      these packets contain information about observed jitter, fractional
      packet loss, and cumulative packet loss. It was intended that this
      information could be used to  support congestion control algorithms,
      but experience has shown that it is not sufficient for that purpose.
      An efficient congestion control algorithm requires more fine-grained
      information on per-packet reception quality than is provided by SR/RR
      packets to react effectively. The feedback format defined in this memo
      provides such fine-grained feedback.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Several other RTCP extensions also provide more detailed feedback
      than SR/RR packets:<a href="#section-8-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8-3">
        <dt id="section-8-3.1">TMMBR:</dt>
        <dd style="margin-left: 1.5em" id="section-8-3.2">The codec control messages for the RTP/AVPF profile 
          <span>[<a href="#RFC5104" class="xref">RFC5104</a>]</span> include a 
          Temporary Maximum Media Stream Bit Rate Request (TMMBR) message. This is used to convey a temporary maximum bitrate limitation from a receiver of RTP packets to their sender. Even
          though it was not designed to replace congestion control, TMMBR has
          been used as a means to do receiver-based congestion control where
          the session bandwidth is high enough to send frequent TMMBR messages,
            especially when used with non-compound RTCP packets <span>[<a href="#RFC5506" class="xref">RFC5506</a>]</span>.
          This approach requires the receiver of the RTP packets to monitor
          their reception, determine the level of congestion, and recommend 
          a maximum bitrate suitable for current available bandwidth on the
          path; it also assumes that the RTP sender can⁠/will respect that bitrate.  This is the opposite of the sender-based congestion control
          approach suggested in this memo, so TMMBR cannot be used to convey
          the information needed for sender-based congestion control.  TMMBR
          could, however, be viewed as a complementary mechanism that can inform
          the sender of the receiver's current view of an acceptable maximum bitrate. Mechanisms that convey the receiver's estimate of the maximum
          available bitrate provide similar feedback.<a href="#section-8-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-3.3">RTCP Extended Reports (XRs):</dt>
        <dd style="margin-left: 1.5em" id="section-8-3.4">Numerous RTCP XR blocks have been defined to report details of packet
          loss, arrival times <span>[<a href="#RFC3611" class="xref">RFC3611</a>]</span>, delay 
          <span>[<a href="#RFC6843" class="xref">RFC6843</a>]</span>, and ECN marking <span>[<a href="#RFC6679" class="xref">RFC6679</a>]</span>. 
          It is possible to combine several such XR blocks into a compound
          RTCP packet, to report the detailed loss, arrival time, and ECN
          marking information needed for effective sender-based
          congestion control. However, the result has high overhead 
          in terms of both bandwidth and complexity, due to the need to stack
          multiple reports.<a href="#section-8-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-3.5">Transport-wide Congestion Control:</dt>
        <dd style="margin-left: 1.5em" id="section-8-3.6">The format
          defined in this memo provides individual feedback on each SSRC.
          An alternative is to add a header extension to each RTP packet,
          containing a single, transport-wide, packet sequence number,
          then have the receiver send RTCP reports giving feedback on
          these additional sequence numbers
          <span>[<a href="#I-D.holmer-rmcat-transport-wide-cc-extensions" class="xref">RTP-Ext-for-CC</a>]</span>.
          Such an approach increases the size of each RTP packet by 8 octets, due to 
          the header extension, but reduces the size of the RTCP feedback packets,
          and can simplify
          the rate calculation at the sender if it maintains a single
          rate limit that applies to all RTP packets sent, irrespective
          of their SSRC.

 Equally, the use of transport-wide feedback makes
          it more difficult to adapt the sending rate, or respond to lost
          packets, based on the reception and/or loss patterns observed
          on a per-SSRC basis (for example, to perform differential rate
          control and repair for audio and video flows, based on knowledge
          of what packets from each flow were lost). Transport-wide 
          feedback is also a less natural fit with the wider RTP framework,
          which makes extensive use of per-SSRC sequence numbers and
          feedback.<a href="#section-8-3.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-8-4">Considering these issues, we believe it appropriate to design a
      new RTCP feedback mechanism to convey information for sender-based
      congestion control algorithms. The new congestion control feedback
      RTCP packet described in <a href="#feedback_message" class="xref">Section 3</a>
      provides such a mechanism.<a href="#section-8-4" class="pilcrow">¶</a></p>
</section>
<div id="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">
        The IANA has registered one new RTP/AVPF Transport-Layer
        Feedback Message in the "FMT Values for RTPFB Payload Types" table 
        <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span> as defined in <a href="#sec_ccfb" class="xref">Section 3.1</a>:<a href="#section-9-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9-2">
        <dt id="section-9-2.1">Name:</dt>
        <dd style="margin-left: 7.0em" id="section-9-2.2">CCFB<a href="#section-9-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.3">Long name:</dt>
        <dd style="margin-left: 7.0em" id="section-9-2.4">RTP Congestion Control Feedback<a href="#section-9-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.5">Value:</dt>
        <dd style="margin-left: 7.0em" id="section-9-2.6">11<a href="#section-9-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.7">Reference:</dt>
        <dd style="margin-left: 7.0em" id="section-9-2.8">RFC 8888<a href="#section-9-2.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-9-3">
        The IANA has also registered one new SDP "rtcp-fb" attribute
        "ack" parameter, "ccfb", in the SDP '"ack" and "nack" Attribute Values'
        registry:<a href="#section-9-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9-4">
        <dt id="section-9-4.1">Value name:</dt>
        <dd style="margin-left: 7.0em" id="section-9-4.2">ccfb<a href="#section-9-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.3">Long name:</dt>
        <dd style="margin-left: 7.0em" id="section-9-4.4">Congestion Control Feedback<a href="#section-9-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.5">Usable with:</dt>
        <dd style="margin-left: 7.0em" id="section-9-4.6">ack<a href="#section-9-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.7">Mux:</dt>
        <dd style="margin-left: 7.0em" id="section-9-4.8">IDENTICAL-PER-PT<a href="#section-9-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.9">Reference:</dt>
        <dd style="margin-left: 7.0em" id="section-9-4.10">RFC 8888<a href="#section-9-4.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="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 security considerations of the RTP specification
      <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>, the applicable RTP profile (e.g.,
      <span>[<a href="#RFC3551" class="xref">RFC3551</a>]</span>, <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span>, or
      <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>), and the RTP congestion control algorithm
      being used (e.g., <span>[<a href="#RFC8698" class="xref">RFC8698</a>]</span>,
      <span>[<a href="#RFC8298" class="xref">RFC8298</a>]</span>,
      <span>[<a href="#Google-GCC" class="xref">Google-GCC</a>]</span>, or
      <span>[<a href="#RFC8382" class="xref">RFC8382</a>]</span>) apply.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">A receiver that intentionally generates inaccurate RTCP congestion
      control feedback reports might be able to trick the sender into sending
      at a greater rate than the path can support, thereby causing congestion on the
      path. 
      This scenario will negatively impact the quality of experience
      of that receiver, potentially causing both denial of service
      to other traffic sharing the path and excessively increased resource
      usage at the media sender.
      Since RTP is an unreliable transport, a sender can intentionally drop a packet,
      leaving a gap in the RTP sequence number space without causing serious harm, to
      check that the receiver is correctly reporting losses. (This needs to be done with
      care and some awareness of the media data being sent, to limit impact on the user
      experience.)<a href="#section-10-2" class="pilcrow">¶</a></p>
<p id="section-10-3">An on-path attacker that can modify RTCP Congestion Control Feedback
      Packets can change the reports to trick the sender into sending at either
      an excessively high or excessively low rate, leading to denial of service.
      The secure RTCP profile <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> can be used to authenticate
      RTCP packets to protect against this attack.<a href="#section-10-3" class="pilcrow">¶</a></p>
<p id="section-10-4">An off-path attacker that can spoof RTCP Congestion Control Feedback
      Packets can similarly trick a sender into sending at an incorrect
      rate, leading to denial of service.  This attack is difficult, since the
      attacker needs to guess the SSRC and sequence number in addition to the
      destination transport address. As with on-path attacks, the secure RTCP
      profile <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> can be used to authenticate RTCP packets
      to protect against this attack.<a href="#section-10-4" 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" 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="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="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="RFC3551">[RFC3551]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor"> and S. Casner</span>, <span class="refTitle">"RTP Profile for Audio and Video Conferences with Minimal Control"</span>, <span class="seriesInfo">STD 65</span>, <span class="seriesInfo">RFC 3551</span>, <span class="seriesInfo">DOI 10.17487/RFC3551</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3551">https://www.rfc-editor.org/info/rfc3551</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3711">[RFC3711]</dt>
        <dd>
<span class="refAuthor">Baugher, M.</span><span class="refAuthor">, McGrew, D.</span><span class="refAuthor">, Naslund, M.</span><span class="refAuthor">, Carrara, E.</span><span class="refAuthor">, and K. Norrman</span>, <span class="refTitle">"The Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 3711</span>, <span class="seriesInfo">DOI 10.17487/RFC3711</span>, <time datetime="2004-03" class="refDate">March 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3711">https://www.rfc-editor.org/info/rfc3711</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="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</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="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" class="refDate">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>
<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="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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC8843">[RFC8843]</dt>
        <dd>
<span class="refAuthor">Holmberg, C.</span><span class="refAuthor">, Alvestrand, H.</span><span class="refAuthor">, and C. Jennings</span>, <span class="refTitle">"Negotiating Media Multiplexing Using the Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 8843</span>, <span class="seriesInfo">DOI 10.17487/RFC8843</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8843">https://www.rfc-editor.org/info/rfc8843</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8859">[RFC8859]</dt>
      <dd>
<span class="refAuthor">Nandakumar, S.</span>, <span class="refTitle">"A Framework for Session Description Protocol (SDP) Attributes When Multiplexing"</span>, <span class="seriesInfo">RFC 8859</span>, <span class="seriesInfo">DOI 10.17487/RFC8859</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8859">https://www.rfc-editor.org/info/rfc8859</a>&gt;</span>. </dd>
<dd class="break"></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="feedback-requirements">[feedback-requirements]</dt>
        <dd>
<span class="refTitle">"RMCAT Feedback Requirements"</span>, <span class="refContent">IETF 95</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://www.ietf.org/proceedings/95/slides/slides-95-rmcat-1.pdf">https://www.ietf.org/proceedings/95/slides/slides-95-rmcat-1.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Google-GCC">[Google-GCC]</dt>
        <dd>
<span class="refAuthor">Holmer, S.</span><span class="refAuthor">, Lundin, H.</span><span class="refAuthor">, Carlucci, G.</span><span class="refAuthor">, De Cicco, L.</span><span class="refAuthor">, and S. Mascolo</span>, <span class="refTitle">"A Google Congestion Control Algorithm for Real-Time Communication"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rmcat-gcc-02</span>, <time datetime="2016-07-08" class="refDate">8 July 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02">https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3611">[RFC3611]</dt>
        <dd>
<span class="refAuthor">Friedman, T., Ed.</span><span class="refAuthor">, Caceres, R., Ed.</span><span class="refAuthor">, and A. Clark, Ed.</span>, <span class="refTitle">"RTP Control Protocol Extended Reports (RTCP XR)"</span>, <span class="seriesInfo">RFC 3611</span>, <span class="seriesInfo">DOI 10.17487/RFC3611</span>, <time datetime="2003-11" class="refDate">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3611">https://www.rfc-editor.org/info/rfc3611</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5104">[RFC5104]</dt>
        <dd>
<span class="refAuthor">Wenger, S.</span><span class="refAuthor">, Chandra, U.</span><span class="refAuthor">, Westerlund, M.</span><span class="refAuthor">, and B. Burman</span>, <span class="refTitle">"Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"</span>, <span class="seriesInfo">RFC 5104</span>, <span class="seriesInfo">DOI 10.17487/RFC5104</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5104">https://www.rfc-editor.org/info/rfc5104</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6843">[RFC6843]</dt>
        <dd>
<span class="refAuthor">Clark, A.</span><span class="refAuthor">, Gross, K.</span><span class="refAuthor">, and Q. Wu</span>, <span class="refTitle">"RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting"</span>, <span class="seriesInfo">RFC 6843</span>, <span class="seriesInfo">DOI 10.17487/RFC6843</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6843">https://www.rfc-editor.org/info/rfc6843</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8298">[RFC8298]</dt>
        <dd>
<span class="refAuthor">Johansson, I.</span><span class="refAuthor"> and Z. Sarker</span>, <span class="refTitle">"Self-Clocked Rate Adaptation for Multimedia"</span>, <span class="seriesInfo">RFC 8298</span>, <span class="seriesInfo">DOI 10.17487/RFC8298</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8298">https://www.rfc-editor.org/info/rfc8298</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8382">[RFC8382]</dt>
        <dd>
<span class="refAuthor">Hayes, D., Ed.</span><span class="refAuthor">, Ferlin, S.</span><span class="refAuthor">, Welzl, M.</span><span class="refAuthor">, and K. Hiorth</span>, <span class="refTitle">"Shared Bottleneck Detection for Coupled Congestion Control for RTP Media"</span>, <span class="seriesInfo">RFC 8382</span>, <span class="seriesInfo">DOI 10.17487/RFC8382</span>, <time datetime="2018-06" class="refDate">June 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8382">https://www.rfc-editor.org/info/rfc8382</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8698">[RFC8698]</dt>
        <dd>
<span class="refAuthor">Zhu, X.</span><span class="refAuthor">, Pan, R.</span><span class="refAuthor">, Ramalho, M.</span><span class="refAuthor">, and S. Mena</span>, <span class="refTitle">"Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media"</span>, <span class="seriesInfo">RFC 8698</span>, <span class="seriesInfo">DOI 10.17487/RFC8698</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8698">https://www.rfc-editor.org/info/rfc8698</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rmcat-rtp-cc-feedback">[RTCP-Multimedia-Feedback]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span>, <span class="refTitle">"RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rmcat-rtp-cc-feedback-05</span>, <time datetime="2019-11-04" class="refDate">4 November 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-05">https://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.holmer-rmcat-transport-wide-cc-extensions">[RTP-Ext-for-CC]</dt>
      <dd>
<span class="refAuthor">Holmer, S.</span><span class="refAuthor">, Flodman, M.</span><span class="refAuthor">, and E. Sprang</span>, <span class="refTitle">"RTP Extensions for Transport-wide Congestion Control"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-holmer-rmcat-transport-wide-cc-extensions-01</span>, <time datetime="2015-10-19" class="refDate">19 October 2015</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01">https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01</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 based on the outcome of a design team discussion
      in the RTP Media Congestion Avoidance Techniques (RMCAT) Working Group.
      The authors would like to thank
      <span class="contact-name">David Hayes</span>,
      <span class="contact-name">Stefan Holmer</span>,
      <span class="contact-name">Randell Jesup</span>,
      <span class="contact-name">Ingemar Johansson</span>,
      <span class="contact-name">Jonathan Lennox</span>,
      <span class="contact-name">Sergio Mena</span>,
      <span class="contact-name">Nils Ohlmeier</span>,
      <span class="contact-name">Magnus Westerlund</span>,
      and
      <span class="contact-name">Xiaoqing Zhu</span>
      for their valuable feedback.<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">Zaheduzzaman Sarker</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>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Colin Perkins</span></div>
<div dir="auto" class="left"><span class="org">University of Glasgow</span></div>
<div dir="auto" class="left"><span class="street-address">School of Computing Science</span></div>
<div dir="auto" class="left"><span class="locality">Glasgow</span></div>
<div dir="auto" class="left"><span class="postal-code">G12 8QQ</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:csp@csperkins.org" class="email">csp@csperkins.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Varun Singh</span></div>
<div dir="auto" class="left"><span class="org">CALLSTATS I/O Oy</span></div>
<div dir="auto" class="left"><span class="street-address">Annankatu 31-33 C 42</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">00100</span> <span class="locality">Helsinki</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:varun.singh@iki.fi" class="email">varun.singh@iki.fi</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://www.callstats.io/" class="url">https://www.callstats.io/</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-5122</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>
</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>