File: rfc8680.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (2239 lines) | stat: -rw-r--r-- 95,399 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8680: Forward Error Correction (FEC) Framework Extension to Sliding Window Codes</title>
<meta content="Vincent Roca" name="author">
<meta content="Ali Begen" name="author">
<meta content="
       
RFC 6363 describes a framework for using Forward Error Correction (FEC)
codes to provide protection against packet loss. The framework
supports applying FEC to arbitrary packet flows over unreliable
transport and is primarily intended for real-time, or streaming, media.
However, FECFRAME as per RFC 6363 is restricted to block FEC codes.
This document updates RFC 6363 to support FEC codes based on a
sliding encoding window, in addition to block FEC codes, in a
backward-compatible way.
During multicast/broadcast real-time content delivery, the use of
sliding window codes significantly improves robustness in harsh
environments, with less repair traffic and lower FEC-related added latency.
       
    " name="description">
<meta content="xml2rfc 2.38.0" name="generator">
<meta content="FEC" name="keyword">
<meta content="FECFRAME" name="keyword">
<meta content="packet loss recovery" name="keyword">
<meta content="RLC" name="keyword">
<meta content="Sliding Window FEC Codes" name="keyword">
<meta content="8680" name="rfc.number">
<link href="rfc8680.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/*
  The margin-left: 0 on <dd> removes all distinction
  between levels from nested <dl>s.  Undo that.
*/
dl.olPercent > dd,
dd {
  margin-left: revert;
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8680" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext-08" 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 8680</td>
<td class="center">FEC Framework Extension</td>
<td class="right">January 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Roca &amp; Begen</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/rfc8680" class="eref">8680</a></dd>
<dt class="label-updates">Updates:</dt>
<dd class="updates">
<a href="https://www.rfc-editor.org/rfc/rfc6363" class="eref">6363</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="2020-01" class="published">January 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">V. Roca</div>
<div class="org">INRIA</div>
</div>
<div class="author">
      <div class="author-name">A. Begen</div>
<div class="org">Networked Media</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8680</h1>
<h1 id="title">Forward Error Correction (FEC) Framework Extension to Sliding Window Codes</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
RFC 6363 describes a framework for using Forward Error Correction (FEC)
codes to provide protection against packet loss. The framework
supports applying FEC to arbitrary packet flows over unreliable
transport and is primarily intended for real-time, or streaming, media.
However, FECFRAME as per RFC 6363 is restricted to block FEC codes.
This document updates RFC 6363 to support FEC codes based on a
sliding encoding window, in addition to block FEC codes, in a
backward-compatible way.
During multicast/broadcast real-time content delivery, the use of
sliding window codes significantly improves robustness in harsh
environments, with less repair traffic and lower FEC-related added latency.<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/rfc8680">https://www.rfc-editor.org/info/rfc8680</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-definitions-and-abbreviatio" class="xref">Definitions and Abbreviations</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-summary-of-architecture-ove" class="xref">Summary of Architecture Overview</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-procedural-overview" class="xref">Procedural Overview</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-general" class="xref">General</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-sender-operation-with-slidi" class="xref">Sender Operation with Sliding Window FEC Codes</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-receiver-operation-with-sli" class="xref">Receiver Operation with Sliding Window FEC Codes</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-protocol-specification" class="xref">Protocol Specification</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-general-2" class="xref">General</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-fec-framework-configuration" class="xref">FEC Framework Configuration Information</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-fec-scheme-requirements" class="xref">FEC Scheme Requirements</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-feedback" class="xref">Feedback</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-transport-protocols" class="xref">Transport Protocols</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-congestion-control" class="xref">Congestion Control</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-operations-and-management-c" class="xref">Operations and Management Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-about-sliding-encoding-wind" class="xref">About Sliding Encoding Window Management (Informational)</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="introduction">
<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"> Many applications need to transport a continuous stream
of packetized data from a source (sender) to one or more destinations
(receivers) over networks that do not provide guaranteed packet delivery.
In particular, packets may be lost, which is strictly the focus of this
document: we assume that transmitted packets are either lost (e.g.,
because of a congested router, a poor signal-to-noise ratio in a
wireless network, or because the number of bit errors exceeds the
correction capabilities of the physical-layer error-correcting code) or
were received by the transport protocol without any corruption (i.e., the bit errors,
if any, have been fixed by the physical-layer error-correcting code and therefore
are hidden to the upper layers).<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">For these use cases, Forward Error Correction (FEC) applied within
the transport or application layer is an efficient
technique to improve packet transmission robustness in the presence of packet
losses (or "erasures") without going through packet retransmissions that
create a delay often incompatible with real-time constraints.
The FEC Building Block defined in <span>[<a href="#RFC5052" class="xref">RFC5052</a>]</span> provides a
framework for the definition of Content Delivery Protocols (CDPs) 
that make use of separately defined FEC schemes. Any CDP
defined according to the requirements of the FEC Building Block can then
easily be used with any FEC scheme that is also defined according to
the requirements of the FEC Building Block.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
Then, FECFRAME <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span> provides a framework to define
Content Delivery Protocols (CDPs) that provide FEC protection for arbitrary
packet flows over an unreliable datagram service transport, such as UDP.
It is primarily intended for real-time or streaming media applications
that are using broadcast, multicast, or on-demand delivery. A subset of
FECFRAME is currently part of the 3GPP Evolved Multimedia Broadcast/Multicast Service
(eMBMS) standard <span>[<a href="#MBMSTS" class="xref">MBMSTS</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
However, <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span> only considers block FEC schemes defined in
accordance with the FEC Building Block <span>[<a href="#RFC5052" class="xref">RFC5052</a>]</span>
(e.g., <span>[<a href="#RFC6681" class="xref">RFC6681</a>]</span>, <span>[<a href="#RFC6816" class="xref">RFC6816</a>]</span>, or <span>[<a href="#RFC6865" class="xref">RFC6865</a>]</span>).
These codes require the input flow(s) to be segmented into a sequence of blocks.
Then, FEC encoding (at a sender or an encoding middlebox) and decoding (at a receiver
or a decoding middlebox) are both performed on a per-block basis.
For instance, if the current block encompasses the 100's to 119's source symbols
(i.e., a block of size 20 symbols) of an input flow, encoding (and decoding) will
be performed on this block independently of other blocks.
This approach has major impacts on FEC encoding and decoding delays.
The data packets of continuous media flow(s) may be passed to the transport layer
immediately, without delay.
But the block creation time, which depends on the number of source symbols in
this block, impacts both the FEC encoding delay (since encoding requires that all
source symbols be known) and, mechanically, the packet loss recovery delay at a
receiver (since no repair symbol for the current block can be generated and
therefore received before that time).
Therefore, a good value for the block size is necessarily a balance between the
maximum FEC decoding latency at the receivers (which must be in line with the most
stringent real-time requirement of the protected flow(s), hence an incentive to
reduce the block size) and the desired robustness against long loss bursts (which
increases with the block size, hence an incentive to increase this size).<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
This document updates <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span> in order to also support FEC codes
based on a sliding encoding window (a.k.a., convolutional codes) <span>[<a href="#RFC8406" class="xref">RFC8406</a>]</span>.
This encoding window, either fixed or variable size, slides over the set of
source symbols.
FEC encoding is launched whenever needed from the set of source symbols present
in the sliding encoding window at that time.
This approach significantly reduces FEC-related latency, since repair symbols can
be generated and passed to the transport layer on the fly at any time and can be
regularly received by receivers to quickly recover packet losses.
Using sliding window FEC codes is therefore highly beneficial to real-time flows,
one of the primary targets of FECFRAME.
<span>[<a href="#RFC8681" class="xref">RFC8681</a>]</span> provides an  example of such a FEC scheme for FECFRAME,
which is built upon the simple sliding window Random Linear Code (RLC).<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">
This document is fully backward compatible with <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>. Indeed:<a href="#section-1-6" class="pilcrow">¶</a></p>
<ul>
<li id="section-1-7.1"> This FECFRAME update does not prevent or compromise in any way the support
 of block FEC codes. Both types of codes can nicely coexist, just like different
 block FEC schemes can coexist.<a href="#section-1-7.1" class="pilcrow">¶</a>
</li>
<li id="section-1-7.2"> Each sliding window FEC scheme is associated with a specific FEC Encoding ID subject
 to IANA registration, just like block FEC schemes.<a href="#section-1-7.2" class="pilcrow">¶</a>
</li>
<li id="section-1-7.3"> Any receiver -- for instance, a legacy receiver that only supports
 block FEC schemes -- can easily identify the FEC scheme used in a FECFRAME session.
 Indeed, the FEC Encoding ID that identifies the FEC scheme is carried in
 FEC Framework Configuration Information (see <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-5.5" class="relref">Section 5.5</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span>).
 For instance, when the Session Description Protocol (SDP) is used to carry the
 FEC Framework Configuration Information, the FEC Encoding ID can be communicated
 in the "encoding-id=" parameter of a "fec-repair-flow" attribute <span>[<a href="#RFC6364" class="xref">RFC6364</a>]</span>.
 This mechanism is the basic approach for a FECFRAME receiver to determine
 whether or not it supports the FEC scheme used in a given FECFRAME session.<a href="#section-1-7.3" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-1-8">
This document leverages on <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span> and reuses its structure.
It proposes new sections specific to sliding window FEC codes whenever required.
The only exception is <a href="#ArchitectureOverview" class="xref">Section 3</a>, which provides a quick
summary of FECFRAME in order to facilitate the understanding of this document to readers
not familiar with the concepts and terminology.<a href="#section-1-8" class="pilcrow">¶</a></p>
</section>
</div>
<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>
<div id="definitionsAndAbbreviations">
<section id="section-2.1">
        <h3 id="name-definitions-and-abbreviatio">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-definitions-and-abbreviatio" class="section-name selfRef">Definitions and Abbreviations</a>
        </h3>
<p id="section-2.1-1">The following list of definitions and abbreviations is copied from <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>,
adding only the Block FEC Code, Sliding Window FEC Code, and Encoding/Decoding Window definitions (tagged
with "ADDED"):<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<dl class="dlNewline" id="section-2.1-2">
          <dt id="section-2.1-2.1">Application Data Unit (ADU):</dt>
<dd id="section-2.1-2.2"> The unit of source data provided as
a payload to the transport layer. 
For instance, it can be a payload containing the result of the RTP packetization of a compressed video frame.<a href="#section-2.1-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.3">ADU Flow:</dt>
<dd id="section-2.1-2.4"> A sequence of ADUs associated with a transport-layer flow
      identifier (such as the standard 5-tuple {source IP address, source
      port, destination IP address, destination port, transport
      protocol}).<a href="#section-2.1-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.5">AL-FEC:</dt>
<dd id="section-2.1-2.6"> Application-Layer Forward Error Correction.<a href="#section-2.1-2.6" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.7">Application Protocol:</dt>
<dd id="section-2.1-2.8"> Control protocol used to establish and control
      the source flow being protected, e.g., the Real-Time Streaming Protocol
      (RTSP).<a href="#section-2.1-2.8" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.9">Content Delivery Protocol (CDP):</dt>
<dd id="section-2.1-2.10"> A complete application protocol
      specification that, through the use of the framework defined in this
      document, is able to make use of FEC schemes to provide FEC
      capabilities.<a href="#section-2.1-2.10" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.11">FEC Code:</dt>
<dd id="section-2.1-2.12"> An algorithm for encoding data such that the encoded data
      flow is resilient to data loss. Note that, in general, FEC codes may also
      be used to make a data flow resilient to corruption, but that is not
      considered in this document.<a href="#section-2.1-2.12" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.13">Block FEC Code: (ADDED)</dt>
<dd id="section-2.1-2.14"> A FEC code that operates on blocks, i.e., for
which the input flow <span class="bcp14">MUST</span> be segmented into a sequence of blocks,
with FEC encoding and decoding being performed independently on a
per-block basis.<a href="#section-2.1-2.14" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.15">Sliding Window FEC Code: (ADDED)</dt>
<dd id="section-2.1-2.16"> A FEC code that can generate repair symbols
on the fly, at any time, from the set of source symbols present in the sliding
encoding window at that time.
These codes are also known as convolutional codes.<a href="#section-2.1-2.16" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.17">FEC Framework:</dt>
<dd id="section-2.1-2.18"> A protocol framework for the definition of Content
      Delivery Protocols using FEC, such as the framework defined in this
      document.<a href="#section-2.1-2.18" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.19">FEC Framework Configuration Information:</dt>
<dd id="section-2.1-2.20"> Information that controls
      the operation of the FEC Framework.<a href="#section-2.1-2.20" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.21">FEC Payload ID:</dt>
<dd id="section-2.1-2.22"> Information that identifies the contents and provides positional information of a packet
with respect to the FEC scheme.<a href="#section-2.1-2.22" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.23">FEC Repair Packet:</dt>
<dd id="section-2.1-2.24"> At a sender (respectively, at a receiver), a
      payload submitted to (respectively, received from) the transport
      protocol containing one or more repair symbols along with a Repair FEC
      Payload ID and possibly an RTP header.<a href="#section-2.1-2.24" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.25">FEC Scheme:</dt>
<dd id="section-2.1-2.26"> A specification that defines the additional protocol
      aspects required to use a particular FEC code with the FEC
      Framework.<a href="#section-2.1-2.26" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.27">FEC Source Packet:</dt>
<dd id="section-2.1-2.28"> At a sender (respectively, at a receiver), a
      payload submitted to (respectively, received from) the transport
      protocol containing an ADU along with an optional Explicit Source FEC
      Payload ID.<a href="#section-2.1-2.28" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.29">Repair Flow:</dt>
<dd id="section-2.1-2.30"> The packet flow carrying FEC data.<a href="#section-2.1-2.30" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.31">Repair FEC Payload ID:</dt>
<dd id="section-2.1-2.32"> A FEC Payload ID specifically for use with
      repair packets.<a href="#section-2.1-2.32" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.33">Source Flow:</dt>
<dd id="section-2.1-2.34"> The packet flow to which FEC protection is to be
      applied. A source flow consists of ADUs.<a href="#section-2.1-2.34" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.35">Source FEC Payload ID:</dt>
<dd id="section-2.1-2.36"> A FEC Payload ID specifically for use with
      source packets.<a href="#section-2.1-2.36" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.37">Source Protocol:</dt>
<dd id="section-2.1-2.38"> A protocol used for the source flow being protected,
      e.g., RTP.<a href="#section-2.1-2.38" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.39">Transport Protocol:</dt>
<dd id="section-2.1-2.40"> The protocol used for the transport of the source and
      repair flows. This protocol needs to provide an unreliable datagram
      service, as UDP does (<span>[<a href="#RFC6363" class="xref">RFC6363</a>], <a href="https://www.rfc-editor.org/rfc/rfc6363#section-7" class="relref">Section 7</a></span>).<a href="#section-2.1-2.40" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.41">Encoding Window: (ADDED)</dt>
<dd id="section-2.1-2.42"> Set of source symbols available at the sender/coding node
      that are used (with a Sliding Window FEC code) to generate a repair symbol.<a href="#section-2.1-2.42" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.43">Decoding Window: (ADDED)</dt>
<dd id="section-2.1-2.44"> Set of received or decoded source and repair symbols available
          at a receiver that are used (with a Sliding Window FEC code) to
          decode lost source symbols.<a href="#section-2.1-2.44" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.45">Code Rate:</dt>
<dd id="section-2.1-2.46"> The ratio between the number of source symbols and the
      number of encoding symbols. By definition, the code rate is such that 0
      &lt; code rate &lt;= 1. A code rate close to 1 indicates that a small
      number of repair symbols have been produced during the encoding
      process.<a href="#section-2.1-2.46" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.47">Encoding Symbol:</dt>
<dd id="section-2.1-2.48"> Unit of data generated by the encoding process. With
      systematic codes, source symbols are part of the encoding symbols.<a href="#section-2.1-2.48" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.49">Packet Erasure Channel:</dt>
<dd id="section-2.1-2.50"> A communication path where packets are either
      lost (e.g., in our case, by a congested router, or because the number of
      transmission errors exceeds the correction capabilities of the
      physical-layer code) or received. When a packet is received, it is
      assumed that this packet is not corrupted (i.e., in our case, the bit errors,
      if any, are fixed by the physical-layer code and are therefore hidden to
      the upper layers).<a href="#section-2.1-2.50" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.51">Repair Symbol:</dt>
<dd id="section-2.1-2.52"> Encoding symbol that is not a source symbol.<a href="#section-2.1-2.52" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.53">Source Block:</dt>
<dd id="section-2.1-2.54"> Group of ADUs that are to be FEC protected as a single
      block.
This notion is restricted to Block FEC codes.<a href="#section-2.1-2.54" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.55">Source Symbol:</dt>
<dd id="section-2.1-2.56"> Unit of data used during the encoding process.<a href="#section-2.1-2.56" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-2.57">Systematic Code:</dt>
<dd id="section-2.1-2.58"> FEC code in which the source symbols are part of the
      encoding symbols.<a href="#section-2.1-2.58" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<section id="section-2.2">
        <h3 id="name-requirements-language">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-2.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.2-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="ArchitectureOverview">
<section id="section-3">
      <h2 id="name-summary-of-architecture-ove">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-summary-of-architecture-ove" class="section-name selfRef">Summary of Architecture Overview</a>
      </h2>
<p id="section-3-1">
The architecture of <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-3" class="relref">Section 3</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> equally applies to this
FECFRAME extension and is not repeated here.
However, this section includes a quick summary to facilitate the understanding of this
document to readers not familiar with the concepts and terminology.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span id="name-fecframe-architecture-at-a-"></span><div id="fig_archi">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-3-2.1">
<pre>
+----------------------+
|     Application      |
+----------------------+
           |
           | (1) Application Data Units (ADUs)
           |
           v
+----------------------+                           +----------------+
|    FEC Framework     |                           |                |
|                      |--------------------------&gt;|   FEC Scheme   |
|(2) Construct source  |(3) Source Block           |                |
|    blocks            |                           |(4) FEC Encoding|
|(6) Construct FEC     |&lt;--------------------------|                |
|    Source and Repair |                           |                |
|    Packets           |(5) Explicit Source FEC    |                |
+----------------------+    Payload IDs            +----------------+
           |                Repair FEC Payload IDs
           |                Repair symbols
           |
           |(7) FEC Source and Repair Packets
           v
+----------------------+
|  Transport Protocol  |
+----------------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-fecframe-architecture-at-a-" class="selfRef">FECFRAME Architecture at a Sender</a>
        </figcaption></figure>
</div>
<p id="section-3-3">
The FECFRAME architecture is illustrated in <a href="#fig_archi" class="xref">Figure 1</a> for a block FEC scheme from the sender's
point of view.
It shows an application generating an ADU flow (other flows from other applications may coexist).
These ADUs of variable size must be somehow mapped to source symbols of a fixed size (this fixed size
is a requirement of all FEC schemes, which comes from the way mathematical
operations are applied to the symbols' content).
This is the goal of an ADU-to-symbols mapping process that is FEC scheme specific (see below).
Once the source block is built, taking into account both the FEC scheme constraints (e.g., in terms
of maximum source block size) and the application's flow constraints (e.g., in terms of real-time constraints),
the associated source symbols are handed to the FEC scheme in order to produce an appropriate number
of repair symbols.
FEC Source Packets (containing ADUs) and FEC Repair Packets (containing one or more repair symbols each)
are then generated and sent using an appropriate transport protocol (more
precisely, <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-7" class="relref">Section 7</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> requires a
transport protocol providing an unreliable datagram service, such as UDP).
In practice, FEC Source Packets may be passed to the transport layer as soon
as available without having to wait for
FEC encoding to take place.
In that case, a copy of the associated source symbols needs to be kept within FECFRAME for future
FEC encoding purposes.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
At a receiver (not shown), FECFRAME processing operates in a similar way,
taking as input the incoming FEC Source and Repair Packets received.  In case
of FEC Source Packet losses, the FEC decoding of the associated block may
recover all (in case of successful decoding) or a subset that is potentially empty
(if decoding fails) of the missing source symbols.  After source-symbol-to-ADU
mapping, when lost ADUs are recovered, they are then assigned to their
respective flow (see below).

ADUs are returned to the application(s), either in their initial transmission
order (in which case all ADUs received after a lost ADU will be delayed until
FEC decoding has taken place) or not (in which case each ADU is returned as
soon as it is received or recovered), depending on the application
requirements.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
FECFRAME features two subtle mechanisms whose details are FEC scheme dependent:<a href="#section-3-5" class="pilcrow">¶</a></p>
<ul>
<li id="section-3-6.1"> ADUs-to-source-symbols mapping:
 in order to manage variable size ADUs, FECFRAME and FEC schemes can use small, fixed-size
 symbols and create a mapping between ADUs and symbols.
 The mapping details are
      FEC scheme dependent and must be defined in the associated document.
      For instance, with certain FEC schemes, to each ADU, this mechanism prepends a length field (plus a flow identifier; see below) and
 pads the result to a multiple of the symbol size.
 A small ADU may be mapped to a single source symbol, while a large one may be mapped to
 multiple symbols.<a href="#section-3-6.1" class="pilcrow">¶</a>
</li>
<li id="section-3-6.2"> Assignment of decoded ADUs to flows in multi-flow configurations:
        when multiple flows are multiplexed over the same FECFRAME instance, a
        problem is to assign a decoded ADU to the right flow (UDP port numbers
        and IP addresses traditionally used to map incoming ADUs to flows are
        not recovered during FEC decoding).        The mapping details are FEC
 scheme dependent and must be 
      defined in the associated document. For instance, with certain FEC 
     schemes, to make it possible, at the
        FECFRAME sending instance, each ADU is prepended with a flow
        identifier (1 byte) during the ADU-to-source-symbols mapping (see
        above).  The flow identifiers are also shared between all FECFRAME
        instances as part of the FEC Framework Configuration Information.

   The ADU Information (ADUI), which includes the flow identifier, length,
   application payload, and padding, is then FEC protected.  Therefore, a
   decoded ADUI contains enough information to assign the ADU to the right
   flow. Note that a FEC scheme may also be restricted to the particular
      case of a single flow over a FECFRAME instance; that would make
      the above mechanism pointless.<a href="#section-3-6.2" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-3-7">
A few aspects are not covered by FECFRAME, namely:<a href="#section-3-7" class="pilcrow">¶</a></p>
<ul>
<li id="section-3-8.1">
          <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-8" class="relref">Section 8</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> does not detail any congestion control mechanisms and
        only provides high-level normative requirements.<a href="#section-3-8.1" class="pilcrow">¶</a>
</li>
<li id="section-3-8.2"> The possibility of having feedback from receiver(s) is considered
        out of scope, although such a mechanism may exist within the
        application (e.g., through RTP Control Protocol (RTCP)
        messages).<a href="#section-3-8.2" class="pilcrow">¶</a>
</li>
<li id="section-3-8.3"> Flow adaptation at a FECFRAME sender (e.g., how to set the FEC
        code rate based on transmission conditions) is not detailed, but it
        needs to comply with the congestion control normative requirements
        (see above).<a href="#section-3-8.3" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<section id="section-4">
      <h2 id="name-procedural-overview">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-procedural-overview" class="section-name selfRef">Procedural Overview</a>
      </h2>
<div id="generalProceduralOverview">
<section id="section-4.1">
        <h3 id="name-general">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-general" class="section-name selfRef">General</a>
        </h3>
<p id="section-4.1-1">
The general considerations of <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> that
are specific to block FEC codes are not repeated here.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
With a Sliding Window FEC code, the FEC Source Packet <span class="bcp14">MUST</span>
contain information to identify the position occupied by
the ADU within the source flow in terms specific to the
FEC scheme.
This information is known as the Source FEC Payload ID, and
the FEC scheme is responsible for defining and interpreting it.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">
With a Sliding Window FEC code, the FEC Repair
Packets <span class="bcp14">MUST</span> contain information that identifies the relationship
between the contained repair payloads and the original source symbols
used during encoding.
This information is known as the Repair FEC Payload ID, and
the FEC scheme is responsible for defining and interpreting it.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">
The sender operation (<span>[<a href="#RFC6363" class="xref">RFC6363</a>], <a href="https://www.rfc-editor.org/rfc/rfc6363#section-4.2" class="relref">Section 4.2</a></span>)
and receiver operation (<span>[<a href="#RFC6363" class="xref">RFC6363</a>], <a href="https://www.rfc-editor.org/rfc/rfc6363#section-4.3" class="relref">Section 4.3</a></span>) are
both specific to block FEC codes and are therefore omitted below.
The following two sections detail similar operations for Sliding Window
FEC codes.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="senderoperation-convolutional">
<section id="section-4.2">
        <h3 id="name-sender-operation-with-slidi">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-sender-operation-with-slidi" class="section-name selfRef">Sender Operation with Sliding Window FEC Codes</a>
        </h3>
<p id="section-4.2-1">
With a Sliding Window FEC scheme, the following operations, illustrated in
<a href="#senderfigure-convolutional" class="xref">Figure 2</a>
for the generic case (non-RTP repair flows) and in
<a href="#senderfigurertp-convolutional" class="xref">Figure 3</a>
for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-4.2-2">
          <li id="section-4.2-2.1">A new ADU is provided by the application.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.2">The FEC Framework communicates this ADU to the FEC scheme.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.3">The sliding encoding window is updated by the FEC scheme.
    The ADU-to-source-symbol mapping as well as the encoding window management details
    are both the responsibility of the FEC scheme and <span class="bcp14">MUST</span> be detailed there.
    <a href="#codingwindow-possibleManagement" class="xref">Appendix A</a> provides non-normative hints about what
 FEC scheme designers need to consider.<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.4">The Source FEC Payload ID information of the source packet is
    determined by the FEC scheme. If required by the FEC scheme, the
    Source FEC Payload ID is encoded into the Explicit Source FEC
    Payload ID field and returned to the FEC Framework.<a href="#section-4.2-2.4" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.5">The FEC Framework constructs the FEC Source Packet according to
Figure 6 in <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>,
    using the Explicit Source FEC Payload ID
    provided by the FEC scheme if applicable.<a href="#section-4.2-2.5" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.6">The FEC Source Packet is sent using normal transport-layer procedures.
    This packet is sent using
    the same ADU flow identification information as would have been
    used for the original source packet if the FEC Framework were not
    present (e.g., the source and destination addresses and UDP port numbers on the IP datagram carrying the
    source packet will be the same whether or not the FEC Framework is applied).<a href="#section-4.2-2.6" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.7">When the FEC Framework needs to send one or several FEC Repair Packets (e.g., according
    to the target code rate), it asks the FEC scheme to create one
    or several repair packet payloads from the current sliding encoding window
    along with their Repair FEC Payload ID.<a href="#section-4.2-2.7" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.8">The Repair FEC Payload IDs and repair packet payloads are provided back by the
    FEC scheme to the FEC Framework.<a href="#section-4.2-2.8" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.9">The FEC Framework constructs FEC Repair Packets
    according to Figure 7 in <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>, 
    using the FEC Payload IDs and repair packet payloads provided by the FEC scheme.<a href="#section-4.2-2.9" class="pilcrow">¶</a>
</li>
<li id="section-4.2-2.10">The FEC Repair Packets are sent using normal transport-layer procedures.
    The port(s) and multicast group(s) to be used for FEC Repair Packets are defined
    in the FEC Framework Configuration Information.<a href="#section-4.2-2.10" class="pilcrow">¶</a>
</li>
</ol>
<span id="name-sender-operation-with-slidin"></span><div id="senderfigure-convolutional">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-4.2-3.1">
<pre>
+----------------------+
|     Application      |
+----------------------+
           |
           | (1) New Application Data Unit (ADU)
           v 
+---------------------+                           +----------------+
|    FEC Framework    |                           |   FEC Scheme   |
|                     |--------------------------&gt;|                |
|                     | (2) New ADU               |(3) Update of   |
|                     |                           |    encoding    |
|                     |&lt;--------------------------|    window      |
|(5) Construct FEC    | (4) Explicit Source       |                |
|    Source Packet    |     FEC Payload ID(s)     |(7) FEC         |
|                     |&lt;--------------------------|    encoding    |
|(9) Construct FEC    | (8) Repair FEC Payload ID |                |
|    Repair Packet(s) |     + Repair symbol(s)    +----------------+
+---------------------+ 
           | 
           | (6)  FEC Source Packet 
           | (10) FEC Repair Packets
           v 
+----------------------+ 
|  Transport Protocol  |
+----------------------+ 
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-sender-operation-with-slidin" class="selfRef">Sender Operation with Sliding Window FEC Codes</a>
          </figcaption></figure>
</div>
<span id="name-sender-operation-with-sliding"></span><div id="senderfigurertp-convolutional">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-4.2-4.1">
<pre>
+----------------------+
|     Application      |
+----------------------+
           |
           | (1) New Application Data Unit (ADU)
           v 
+---------------------+                           +----------------+
|    FEC Framework    |                           |   FEC Scheme   |
|                     |--------------------------&gt;|                |
|                     | (2) New ADU               |(3) Update of   |
|                     |                           |    encoding    |
|                     |&lt;--------------------------|    window      |
|(5) Construct FEC    | (4) Explicit Source       |                |
|    Source Packet    |     FEC Payload ID(s)     |(7) FEC         |
|                     |&lt;--------------------------|    encoding    |
|(9) Construct FEC    | (8) Repair FEC Payload ID |                |
|    Repair Packet(s) |     + Repair symbol(s)    +----------------+
+---------------------+
    |             |
    |(6) Source   |(10) Repair payloads
    |    packets  |
    |      + -- -- -- -- -+
    |      |     RTP      |
    |      +-- -- -- -- --+
    v             v                 
+----------------------+ 
|  Transport Protocol  |
+----------------------+ 
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-sender-operation-with-sliding" class="selfRef">Sender Operation with Sliding Window FEC Codes and RTP Repair Flows</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="receiveroperation-convolutional">
<section id="section-4.3">
        <h3 id="name-receiver-operation-with-sli">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-receiver-operation-with-sli" class="section-name selfRef">Receiver Operation with Sliding Window FEC Codes</a>
        </h3>
<p id="section-4.3-1">
With a Sliding Window FEC scheme, the following operations are illustrated in
<a href="#receiverfigure" class="xref">Figure 4</a> 
for the generic case (non-RTP repair flows) and in
<a href="#receiverfigurertp" class="xref">Figure 5</a>
for the case of RTP repair flows.
The only differences with respect to block FEC codes lie in steps (4) and (5).
Therefore, this section does not repeat the other steps of
<span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-4.3" class="relref">Section 4.3</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> ("Receiver Operation").
The new steps (4) and (5) are:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<ol start="4" type="1" class="normal" id="section-4.3-2">
          <li id="section-4.3-2.1"> The FEC scheme uses the received FEC Payload IDs (and derived
 FEC Source Payload IDs when the Explicit Source FEC Payload ID field is not used)
 to insert source and repair packets into the decoding window in the right way.
 If at least one source packet is missing and at least one repair packet
        has been received, then FEC decoding is attempted to recover the missing source payloads.
 The FEC scheme determines whether source packets have been lost and whether
 enough repair packets have been received to decode any or all of the missing
 source payloads.<a href="#section-4.3-2.1" class="pilcrow">¶</a>
</li>
<li id="section-4.3-2.2"> The FEC scheme returns the received and decoded ADUs to the
 FEC Framework, along with indications of any ADUs that were missing and could
 not be decoded.<a href="#section-4.3-2.2" class="pilcrow">¶</a>
</li>
</ol>
<span id="name-receiver-operation-with-slid"></span><div id="receiverfigure">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-4.3-3.1">
<pre>
+----------------------+
|     Application      |
+----------------------+
           ^
           |(6) ADUs
           |
+----------------------+                           +----------------+
|    FEC Framework     |                           |   FEC Scheme   |
|                      |&lt;--------------------------|                |
|(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding|
|   IDs and pass IDs &amp; |--------------------------&gt;|                |
|   payloads to FEC    |(3) Explicit Source FEC    +----------------+
|   scheme             |            Payload IDs
+----------------------+    Repair FEC Payload IDs
           ^                Source payloads       
           |                Repair payloads
           |(1) FEC Source
           |    and Repair Packets
+----------------------+ 
|  Transport Protocol  |
+----------------------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-receiver-operation-with-slid" class="selfRef">Receiver Operation with Sliding Window FEC Codes</a>
          </figcaption></figure>
</div>
<span id="name-receiver-operation-with-slidi"></span><div id="receiverfigurertp">
<figure id="figure-5">
          <div class="artwork art-text alignLeft" id="section-4.3-4.1">
<pre>
+----------------------+
|     Application      |
+----------------------+
           ^
           |(6) ADUs
           |
+----------------------+                           +----------------+
|    FEC Framework     |                           |   FEC Scheme   |
|                      |&lt;--------------------------|                |
|(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding|
|   IDs and pass IDs &amp; |--------------------------&gt;|                |
|   payloads to FEC    |(3) Explicit Source FEC    +----------------+
|   scheme             |            Payload IDs
+----------------------+    Repair FEC Payload IDs
    ^             ^         Source payloads
    |             |         Repair payloads
    |Source pkts  |Repair payloads
    |             |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing | 
|   | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux        | |
+-- -- -- -- -- -- -- -+ 
           ^
           |(1) FEC Source and Repair Packets
           |         
+----------------------+ 
|  Transport Protocol  |
+----------------------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-receiver-operation-with-slidi" class="selfRef">Receiver Operation with Sliding Window FEC Codes and RTP Repair Flows</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
<section id="section-5">
      <h2 id="name-protocol-specification">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-protocol-specification" class="section-name selfRef">Protocol Specification</a>
      </h2>
<div id="generalProtocolSpecification">
<section id="section-5.1">
        <h3 id="name-general-2">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-general-2" class="section-name selfRef">General</a>
        </h3>
<p id="section-5.1-1">
This section discusses the protocol elements for the FEC Framework specific to Sliding Window FEC schemes.
The global formats of source data packets (i.e., <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>, Figure 6) and repair data packets (i.e., <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>, Figures 7 and 8) remain the same with Sliding Window FEC codes.
They are not repeated here.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="config">
<section id="section-5.2">
        <h3 id="name-fec-framework-configuration">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-fec-framework-configuration" class="section-name selfRef">FEC Framework Configuration Information</a>
        </h3>
<p id="section-5.2-1">
The FEC Framework Configuration Information considerations of <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-5.5" class="relref">Section 5.5</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> equally
apply to this FECFRAME extension and are not repeated here.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="fecscheme">
<section id="section-5.3">
        <h3 id="name-fec-scheme-requirements">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-fec-scheme-requirements" class="section-name selfRef">FEC Scheme Requirements</a>
        </h3>
<p id="section-5.3-1">
The FEC scheme requirements of <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-5.6" class="relref">Section 5.6</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> mostly apply to this FECFRAME extension and
are not repeated here.  An exception, though, is the "full specification of
the FEC code", item (4), which is specific to block FEC codes.  
In case of a Sliding Window FEC scheme, then the
following item (4-bis) applies:<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<dl class="dlNewline" id="section-5.3-2">
          <dt id="section-5.3-2.1">4-bis.</dt>
<dd style="margin-left: 2.0em" id="section-5.3-2.2">
            <p id="section-5.3-2.2.1">A full specification of the Sliding Window FEC code.<a href="#section-5.3-2.2.1" class="pilcrow">¶</a></p>
<p id="section-5.3-2.2.2">
      This specification <span class="bcp14">MUST</span> precisely define the
      valid FEC-Scheme-Specific Information values, the valid FEC
      Payload ID values, and the valid packet payload sizes (where "packet
      payload" refers to the space within a packet dedicated to carrying
      encoding symbols).<a href="#section-5.3-2.2.2" class="pilcrow">¶</a></p>
<p id="section-5.3-2.2.3">
      Furthermore, given valid values of the FEC-Scheme-Specific Information, a
      valid Repair FEC Payload ID value, a valid packet payload size, and a valid
      encoding window (i.e., a set of source symbols), the specification
      <span class="bcp14">MUST</span> uniquely define the values of the encoding symbol (or
      symbols) to be included in the repair packet payload with the given Repair
      FEC Payload ID value.<a href="#section-5.3-2.2.3" class="pilcrow">¶</a></p>
</dd>
</dl>
<p id="section-5.3-3">
Additionally, the FEC scheme associated with a Sliding Window FEC code:<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-5.3-4.1">
            <span class="bcp14">MUST</span> define the relationships between ADUs and the associated source symbols (mapping).<a href="#section-5.3-4.1" class="pilcrow">¶</a>
</li>
<li id="section-5.3-4.2">
            <span class="bcp14">MUST</span> define the management of the encoding window that slides over the set of ADUs.
 <a href="#codingwindow-possibleManagement" class="xref">Appendix A</a> provides non-normative hints about what 
       FEC scheme designers need to consider.<a href="#section-5.3-4.2" class="pilcrow">¶</a>
</li>
<li id="section-5.3-4.3">
            <span class="bcp14">MUST</span> define the management of the decoding window.
 This usually consists of managing a system of linear equations (for a linear FEC code).<a href="#section-5.3-4.3" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
</section>
<section id="section-6">
      <h2 id="name-feedback">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-feedback" class="section-name selfRef">Feedback</a>
      </h2>
<p id="section-6-1">
The discussion in <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-6" class="relref">Section 6</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> equally applies to this FECFRAME extension and is not repeated
here.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
<div id="TransportProtocols">
<section id="section-7">
      <h2 id="name-transport-protocols">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-transport-protocols" class="section-name selfRef">Transport Protocols</a>
      </h2>
<p id="section-7-1">
The discussion in <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-7" class="relref">Section 7</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> equally applies to this
FECFRAME extension and is not repeated here.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_congestion">
<section id="section-8">
      <h2 id="name-congestion-control">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-congestion-control" class="section-name selfRef">Congestion Control</a>
      </h2>
<p id="section-8-1">
The discussion in <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-8" class="relref">Section 8</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> equally applies to this
FECFRAME extension and is not repeated here.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-9-1">
This FECFRAME extension does not add any new security considerations.  All the
considerations of <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-9" class="relref">Section 9</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> apply to this document as well.  However, for the sake of
completeness, the following goal can be added to the list provided in <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-9.1" class="relref">Section 9.1</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> ("Problem
Statement"):<a href="#section-9-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-9-2.1"> Attacks can try to corrupt source flows in order to modify the receiver application's behavior
 (as opposed to just denying service).<a href="#section-9-2.1" class="pilcrow">¶</a>
</li>
</ul>
</section>
<section id="section-10">
      <h2 id="name-operations-and-management-c">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-operations-and-management-c" class="section-name selfRef">Operations and Management Considerations</a>
      </h2>
<p id="section-10-1">
This FECFRAME extension does not add any new Operations and Management Considerations.
All the considerations of <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-10" class="relref">Section 10</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> apply to this document as well.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
<div id="iana">
<section id="section-11">
      <h2 id="name-iana-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-11-1">
This document has no IANA actions.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">A FEC scheme for use with this FEC Framework is identified via its FEC Encoding ID.
It is subject to IANA registration in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry.
All the rules of <span><a href="https://www.rfc-editor.org/rfc/rfc6363#section-11" class="relref">Section 11</a> of [<a href="#RFC6363" class="xref">RFC6363</a>]</span> apply and are not repeated here.<a href="#section-11-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-12">
      <h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-normative-references">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC6363">[RFC6363]</dt>
<dd>
<span class="refAuthor">Watson, M.</span><span class="refAuthor">, Begen, A.</span><span class="refAuthor">, and V. Roca</span>, <span class="refTitle">"Forward Error Correction (FEC) Framework"</span>, <span class="seriesInfo">RFC 6363</span>, <span class="seriesInfo">DOI 10.17487/RFC6363</span>, <time datetime="2011-10">October 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6363">https://www.rfc-editor.org/info/rfc6363</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
<dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-12.2">
        <h3 id="name-informative-references">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="MBMSTS">[MBMSTS]</dt>
<dd>
<span class="refAuthor">3GPP</span>, <span class="refTitle">"Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs"</span>, <span class="seriesInfo">3GPP TS 26.346</span>, <time datetime="2009-03">March 2009</time>, <span>&lt;<a href="http://ftp.3gpp.org/specs/html-info/26346.htm">http://ftp.3gpp.org/specs/html-info/26346.htm</a>&gt;</span>. </dd>
<dt id="RFC5052">[RFC5052]</dt>
<dd>
<span class="refAuthor">Watson, M.</span><span class="refAuthor">, Luby, M.</span><span class="refAuthor">, and L. Vicisano</span>, <span class="refTitle">"Forward Error Correction (FEC) Building Block"</span>, <span class="seriesInfo">RFC 5052</span>, <span class="seriesInfo">DOI 10.17487/RFC5052</span>, <time datetime="2007-08">August 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5052">https://www.rfc-editor.org/info/rfc5052</a>&gt;</span>. </dd>
<dt id="RFC6364">[RFC6364]</dt>
<dd>
<span class="refAuthor">Begen, A.</span>, <span class="refTitle">"Session Description Protocol Elements for the Forward Error Correction (FEC) Framework"</span>, <span class="seriesInfo">RFC 6364</span>, <span class="seriesInfo">DOI 10.17487/RFC6364</span>, <time datetime="2011-10">October 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6364">https://www.rfc-editor.org/info/rfc6364</a>&gt;</span>. </dd>
<dt id="RFC6681">[RFC6681]</dt>
<dd>
<span class="refAuthor">Watson, M.</span><span class="refAuthor">, Stockhammer, T.</span><span class="refAuthor">, and M. Luby</span>, <span class="refTitle">"Raptor Forward Error Correction (FEC) Schemes for FECFRAME"</span>, <span class="seriesInfo">RFC 6681</span>, <span class="seriesInfo">DOI 10.17487/RFC6681</span>, <time datetime="2012-08">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6681">https://www.rfc-editor.org/info/rfc6681</a>&gt;</span>. </dd>
<dt id="RFC6816">[RFC6816]</dt>
<dd>
<span class="refAuthor">Roca, V.</span><span class="refAuthor">, Cunche, M.</span><span class="refAuthor">, and J. Lacan</span>, <span class="refTitle">"Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME"</span>, <span class="seriesInfo">RFC 6816</span>, <span class="seriesInfo">DOI 10.17487/RFC6816</span>, <time datetime="2012-12">December 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6816">https://www.rfc-editor.org/info/rfc6816</a>&gt;</span>. </dd>
<dt id="RFC6865">[RFC6865]</dt>
<dd>
<span class="refAuthor">Roca, V.</span><span class="refAuthor">, Cunche, M.</span><span class="refAuthor">, Lacan, J.</span><span class="refAuthor">, Bouabdallah, A.</span><span class="refAuthor">, and K. Matsuzono</span>, <span class="refTitle">"Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME"</span>, <span class="seriesInfo">RFC 6865</span>, <span class="seriesInfo">DOI 10.17487/RFC6865</span>, <time datetime="2013-02">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6865">https://www.rfc-editor.org/info/rfc6865</a>&gt;</span>. </dd>
<dt id="RFC8406">[RFC8406]</dt>
<dd>
<span class="refAuthor">Adamson, B.</span><span class="refAuthor">, Adjih, C.</span><span class="refAuthor">, Bilbao, J.</span><span class="refAuthor">, Firoiu, V.</span><span class="refAuthor">, Fitzek, F.</span><span class="refAuthor">, Ghanem, S.</span><span class="refAuthor">, Lochin, E.</span><span class="refAuthor">, Masucci, A.</span><span class="refAuthor">, Montpetit, M-J.</span><span class="refAuthor">, Pedersen, M.</span><span class="refAuthor">, Peralta, G.</span><span class="refAuthor">, Roca, V., Ed.</span><span class="refAuthor">, Saxena, P.</span><span class="refAuthor">, and S. Sivakumar</span>, <span class="refTitle">"Taxonomy of Coding Techniques for Efficient Network Communications"</span>, <span class="seriesInfo">RFC 8406</span>, <span class="seriesInfo">DOI 10.17487/RFC8406</span>, <time datetime="2018-06">June 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8406">https://www.rfc-editor.org/info/rfc8406</a>&gt;</span>. </dd>
<dt id="RFC8681">[RFC8681]</dt>
<dd>
<span class="refAuthor">Roca, V.</span><span class="refAuthor"> and B. Teibi</span>, <span class="refTitle">"Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME"</span>, <span class="seriesInfo">RFC 8681</span>, <span class="seriesInfo">DOI 10.17487/RFC8681</span>, <time datetime="2020-01">January 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8681">https://www.rfc-editor.org/info/rfc8681</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="codingwindow-possibleManagement">
<section id="section-appendix.a">
      <h2 id="name-about-sliding-encoding-wind">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-about-sliding-encoding-wind" class="section-name selfRef">About Sliding Encoding Window Management (Informational)</a>
      </h2>
<p id="section-appendix.a-1">
The FEC Framework does not specify the management of the sliding encoding window, which is the responsibility of the FEC scheme.
This annex only provides a few informational hints.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
   Source symbols are added to the sliding encoding window each time a
   new ADU is available at the sender after the ADU-to-source-symbol
   mapping specific to the FEC scheme has been done.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">
Source symbols are removed from the sliding encoding window. For instance:<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-appendix.a-4.1"> After a certain delay, when an "old" ADU of a real-time flow times out.
 The source symbol retention delay in the sliding encoding window should therefore be initialized according to the real-time features of incoming flow(s) when applicable.<a href="#section-appendix.a-4.1" class="pilcrow">¶</a>
</li>
<li id="section-appendix.a-4.2"> Once the sliding encoding window has reached its maximum size (there is usually an upper limit to the sliding encoding window size).
 In that case, the oldest symbol is removed each time a new source symbol is added.<a href="#section-appendix.a-4.2" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-appendix.a-5">
Several considerations can impact the management of this sliding encoding window:<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
<ul>
<li id="section-appendix.a-6.1"> At the source flows level: real-time constraints can limit the
 total time during which source symbols can remain in the encoding window.<a href="#section-appendix.a-6.1" class="pilcrow">¶</a>
</li>
<li id="section-appendix.a-6.2"> At the FEC code level: theoretical or practical limitations (e.g., because of computational complexity) can limit the number of source symbols in the encoding window.<a href="#section-appendix.a-6.2" class="pilcrow">¶</a>
</li>
<li id="section-appendix.a-6.3"> At the FEC scheme level: signaling and window management are intrinsically related.
 For instance, an encoding window composed of a nonsequential set of source symbols requires appropriate signaling to inform a receiver of the composition of the encoding window, and the associated transmission overhead can limit the maximum encoding window size.
 On the contrary, an encoding window always composed of a sequential set of source symbols simplifies signaling: providing the identity of the first source symbol plus its number is sufficient, which creates a fixed and relatively small transmission overhead.<a href="#section-appendix.a-6.3" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<section id="section-appendix.b">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.b-1">
The authors would like to thank Christer Holmberg, David Black, Gorry
Fairhurst, Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin Kaduk,
Eric Rescorla, Adam Roach, and Greg Skinner for their valuable feedback on
this document.  This document being an extension of <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>, the authors would also like to thank Mark Watson as the
main author of that RFC.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.c">
      <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">Vincent Roca</span></div>
<div dir="auto" class="left"><span class="org">INRIA</span></div>
<div dir="auto" class="left"><span class="extended-address">Univ. Grenoble Alpes</span></div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:vincent.roca@inria.fr" class="email">vincent.roca@inria.fr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ali Begen</span></div>
<div dir="auto" class="left"><span class="org">Networked Media</span></div>
<div dir="auto" class="left">
<span class="locality">Konya</span>/</div>
<div dir="auto" class="left"><span class="country-name">Turkey</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ali.begen@networked.media" class="email">ali.begen@networked.media</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

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

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

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