File: rfc8961.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2037 lines) | stat: -rw-r--r-- 86,583 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC BCP">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8961: Requirements for Time-Based Loss Detection</title>
<meta content="Mark Allman" name="author">
<meta content='
       Many protocols must detect packet loss for various reasons
    (e.g., to ensure reliability using retransmissions or to understand the
    level of congestion along a network path).  While many mechanisms have
    been designed to detect loss, ultimately, protocols can only count on the
    passage of time without delivery confirmation to declare a packet "lost".
    Each implementation of a time-based loss detection mechanism represents a
    balance between correctness and timeliness; therefore, no implementation
    suits all situations.  This document provides high-level requirements for
    time-based loss detectors appropriate for general use in unicast
    communication across the Internet.  Within the requirements,
    implementations have latitude to define particulars that best address each
    situation. 
    ' name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="retransmission timeout" name="keyword">
<meta content="packet loss" name="keyword">
<meta content="loss detection" name="keyword">
<meta content="requirements" name="keyword">
<meta content="8961" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8961.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8961" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider-17" 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 8961</td>
<td class="center">Requirements for Time-Based Loss Detecti</td>
<td class="right">November 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Allman</td>
<td class="center">Best Current Practice</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/rfc8961" class="eref">8961</a></dd>
<dt class="label-bcp">BCP:</dt>
<dd class="bcp">233</dd>
<dt class="label-category">Category:</dt>
<dd class="category">Best Current Practice</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-11" class="published">November 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Allman</div>
<div class="org">ICSI</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8961</h1>
<h1 id="title">Requirements for Time-Based Loss Detection</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Many protocols must detect packet loss for various reasons
    (e.g., to ensure reliability using retransmissions or to understand the
    level of congestion along a network path).  While many mechanisms have
    been designed to detect loss, ultimately, protocols can only count on the
    passage of time without delivery confirmation to declare a packet "lost".
    Each implementation of a time-based loss detection mechanism represents a
    balance between correctness and timeliness; therefore, no implementation
    suits all situations.  This document provides high-level requirements for
    time-based loss detectors appropriate for general use in unicast
    communication across the Internet.  Within the requirements,
    implementations have latitude to define particulars that best address each
    situation.<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 memo documents an Internet Best Current Practice.<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 BCPs 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/rfc8961">https://www.rfc-editor.org/info/rfc8961</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="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-context" class="xref">Context</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" 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-scope" class="xref">Scope</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" 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-requirements" class="xref">Requirements</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" 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-discussion" class="xref">Discussion</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" 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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" 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-references" class="xref">References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sect-1">
<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">
   As a network of networks, the Internet consists of a large variety
   of links and systems that support a wide variety of tasks and
   workloads.  The service provided by the network varies from
   best-effort delivery among loosely connected components to highly
   predictable delivery within controlled environments (e.g., between
   physically connected nodes, within a tightly controlled data
   center).  Each path through the network has a set of path
   properties, e.g., available capacity, delay, and packet loss.  Given
   the range of networks that make up the Internet, these properties
   range from largely static to highly dynamic.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   This document provides guidelines for developing an understanding of one
   path property: packet loss.  In particular, we offer guidelines for
   developing and implementing time-based loss detectors that have been
   gradually learned over the last several decades.  We focus on the general
   case where the loss properties of a path are (a) unknown a priori and (b)
   dynamically varying over time.  Further, while there are numerous root
   causes of packet loss, we leverage the conservative notion that loss is an
   implicit indication of congestion <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>.  While this stance is not always correct, as a general
   assumption it has historically served us well <span>[<a href="#Jac88" class="xref">Jac88</a>]</span>.  As we discuss further in <a href="#sect-2" class="xref">Section 2</a>, the
   guidelines in this document should be viewed as a general default for
   unicast communication across best-effort networks and not as optimal -- or
   even applicable -- for all situations.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   Given that packet loss is routine in best-effort networks, loss
   detection is a crucial activity for many protocols and applications
   and is generally undertaken for two major reasons:<a href="#section-1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-1-4">
          <dt>(1)</dt>
<dd id="section-1-4.1">
          <p id="section-1-4.1.1">Ensuring reliable data delivery<a href="#section-1-4.1.1" class="pilcrow">¶</a></p>
<p id="section-1-4.1.2">This requires a data sender to develop an understanding of
              which transmitted packets have not arrived at the receiver.
              This knowledge allows the sender to retransmit missing
       data.<a href="#section-1-4.1.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-1-4.2">
          <p id="section-1-4.2.1"> Congestion control<a href="#section-1-4.2.1" class="pilcrow">¶</a></p>
<p id="section-1-4.2.2"> As we mention above, packet loss is often taken as an
              implicit indication that the sender is transmitting too fast and
              is overwhelming some portion of the network path.  Data senders
              can therefore use loss to trigger transmission rate
              reductions.<a href="#section-1-4.2.2" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-5">
   Various mechanisms are used to detect losses in a packet stream.
   Often, we use continuous or periodic acknowledgments from the
   recipient to inform the sender's notion of which pieces of data are
   missing.  However, despite our best intentions and most robust
   mechanisms, we cannot place ultimate faith in receiving such
   acknowledgments but can only truly depend on the passage of time.
   Therefore, our ultimate backstop to ensuring that we detect all loss
   is a timeout.  That is, the sender sets some expectation for how
   long to wait for confirmation of delivery for a given piece of data.
   When this time period passes without delivery confirmation, the
   sender concludes the data was lost in transit.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">The specifics of time-based loss detection schemes represent a
   tradeoff between correctness and responsiveness.  In other words, we
   wish to simultaneously:<a href="#section-1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-7.1">wait long enough to ensure the detection of loss is correct,
   and<a href="#section-1-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-7.2">minimize the amount of delay we impose on applications (before
     repairing loss) and the network (before we reduce the
     congestion).<a href="#section-1-7.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-8">
   Serving both of these goals is difficult, as they pull in opposite
   directions <span>[<a href="#AP99" class="xref">AP99</a>]</span>.  By not waiting long
   enough to accurately determine a packet has been lost, we may provide a
   needed retransmission in a timely manner but risk both sending unnecessary
   ("spurious") retransmissions and needlessly lowering the transmission rate.
   By waiting long enough that we are unambiguously certain a packet has been
   lost, we cannot repair losses in a timely manner and we risk prolonging
   network congestion.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">
   Many protocols and applications -- such as TCP <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>, SCTP <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span>, and SIP
   <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> -- use their own time-based loss detection mechanisms.
   At
   this point, our experience leads to a recognition that often specific
   tweaks that deviate from standardized time-based loss detectors do not
   materially impact network safety with respect to congestion control <span>[<a href="#AP99" class="xref">AP99</a>]</span>.  Therefore, in this document we outline a
   set of high-level, protocol-agnostic requirements for time-based loss
   detection.  The intent is to provide a safe foundation on which
   implementations have the flexibility to instantiate mechanisms that best
   realize their specific goals.<a href="#section-1-9" class="pilcrow">¶</a></p>
<div id="sect-1.1">
<section id="section-1.1">
        <h3 id="name-terminology">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">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-1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-context">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-context" class="section-name selfRef">Context</a>
      </h2>
<p id="section-2-1">
   This document is different from the way we ideally like to engineer
   systems.  Usually, we strive to understand high-level requirements
   as a starting point.  We then methodically engineer specific
   protocols, algorithms, and systems that meet these requirements.
   Within the IETF standards process, we have derived many time-based
   loss detection schemes without the benefit of some over-arching
   requirements document -- because we had no idea how to write such a
   document!  Therefore, we made the best specific decisions we could
   in response to specific needs.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
   At this point, however, the community's experience has matured to
   the point where we can define a set of general, high-level
   requirements for time-based loss detection schemes.  We now
   understand how to separate the strategies these mechanisms use that
   are crucial for network safety from those small details that do not
   materially impact network safety.  The requirements in this document
   may not be appropriate in all cases.  In particular, the guidelines
   in <a href="#sect-4" class="xref">Section 4</a> are concerned with the general case, but
   specific
   situations may allow for more flexibility in terms of loss detection
   because specific facets of the environment are known (e.g., when
   operating over a single physical link or within a tightly controlled
   data center).  Therefore, variants, deviations, or wholly different
   time-based loss detectors may be necessary or useful in some cases.
   The correct way to view this document is as the default case and not
   as one-size-fits-all guidance that is optimal in all cases.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">
   Adding a requirements umbrella to a body of existing specifications
   is inherently messy and we run the risk of creating inconsistencies
   with both past and future mechanisms.  Therefore, we make the
   following statements about the relationship of this document to past
   and future specifications:<a href="#section-2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-4.1">This document does not update or obsolete any existing RFC.  These
        previous specifications -- while generally consistent with the
        requirements in this document -- reflect community consensus, and this
        document does not change that consensus.<a href="#section-2-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.2">The requirements in this document are meant to provide for network
        safety and, as such, <span class="bcp14">SHOULD</span> be used by all future
        time-based loss detection mechanisms.<a href="#section-2-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.3">The requirements in this document may not be appropriate in all
        cases; therefore, deviations and variants may be necessary in the
        future (hence the "<span class="bcp14">SHOULD</span>" in the last bullet).
        However, inconsistencies <span class="bcp14">MUST</span> be (a) explained and (b)
        gather consensus.<a href="#section-2-4.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-scope">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-scope" class="section-name selfRef">Scope</a>
      </h2>
<p id="section-3-1">
   The principles we outline in this document are protocol-agnostic and
   widely applicable.  We make the following scope statements about
   the application of the requirements discussed in <a href="#sect-4" class="xref">Section 4</a>:<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-3-2">
        <dt>(S.1)</dt>
<dd style="margin-left: 3.0em" id="section-3-2.1">While there are a bevy of uses for timers in
   protocols -- from rate-based pacing to connection failure detection
     and beyond -- this document is focused only on loss
 detection.<a href="#section-3-2.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(S.2)</dt>
<dd style="margin-left: 3.0em" id="section-3-2.2">
          <p id="section-3-2.2.1"> The requirements for time-based loss detection
     mechanisms in this document are for the primary or "last resort"
       loss detection mechanism, whether the mechanism is the sole loss
         repair strategy or works in concert with other mechanisms.<a href="#section-3-2.2.1" class="pilcrow">¶</a></p>
<p id="section-3-2.2.2">
          While a straightforward time-based loss detector is sufficient
            for simple protocols like DNS <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>, more
            complex protocols often use more advanced loss detectors to aid
            performance.  For instance, TCP and SCTP have methods to detect
            (and repair) loss based on explicit endpoint state sharing <span>[<a href="#RFC2018" class="xref">RFC2018</a>]</span> <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span> <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>.
            Such mechanisms often provide more timely and precise loss
            detection than time-based loss detectors.  However, these
            mechanisms do not obviate the need for a "retransmission timeout"
            or "RTO" because, as we discuss in <a href="#sect-1" class="xref">Section 1</a>, only
     the passage
            of time can ultimately be relied upon to detect loss.  In other
            words, we ultimately cannot count on acknowledgments to arrive at
            the data sender to indicate which packets never arrived at the
            receiver.  In cases such as these, we need a time-based loss
            detector to function as a "last resort".<a href="#section-3-2.2.2" class="pilcrow">¶</a></p>
<p id="section-3-2.2.3">Also, note that some recent proposals have incorporated time
            as a component of advanced loss detection methods either as an
            aggressive first loss detector in certain situations or in
            conjunction with endpoint state sharing <span>[<a href="#I-D.dukkipati-tcpm-tcp-loss-probe" class="xref">DCCM13</a>]</span> <span>[<a href="#I-D.ietf-tcpm-rack" class="xref">CCDJ20</a>]</span> <span>[<a href="#I-D.ietf-quic-recovery" class="xref">IS20</a>]</span>.  While these mechanisms can aid timely loss
            recovery, the protocol ultimately leans on another more
            conservative timer to ensure reliability when these mechanisms
            break down.  The requirements in this document are only directly
            applicable to last-resort loss detection.  However, we expect that
            many of the requirements can serve as useful guidelines for more
            aggressive non-last-resort timers as well.<a href="#section-3-2.2.3" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt>(S.3)</dt>
<dd style="margin-left: 3.0em" id="section-3-2.3">
          <p id="section-3-2.3.1"> The requirements in this document apply only to
     endpoint-to-endpoint unicast communication.  Reliable multicast
       (e.g., <span>[<a href="#RFC5740" class="xref">RFC5740</a>]</span>) protocols are
       explicitly outside
         the scope of this document.<a href="#section-3-2.3.1" class="pilcrow">¶</a></p>
<p id="section-3-2.3.2">Protocols such as SCTP <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span> and Multipath TCP (MP-TCP) <span>[<a href="#RFC6182" class="xref">RFC6182</a>]</span> that communicate in a unicast fashion with
            multiple specific endpoints can leverage the requirements in this
            document provided they track state and follow the requirements for
            each endpoint independently.  That is, if host A communicates with
            addresses B and C, A needs to use independent time-based loss
            detector instances for traffic sent to B and C.<a href="#section-3-2.3.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt>(S.4)</dt>
<dd style="margin-left: 3.0em" id="section-3-2.4"> There are cases where state is shared across connections or flows
        (e.g., <span>[<a href="#RFC2140" class="xref">RFC2140</a>]</span> and <span>[<a href="#RFC3124" class="xref">RFC3124</a>]</span>).  State pertaining to time-based
        loss detection is often discussed as sharable.  These situations raise
        issues that the simple flow-oriented time-based loss detection
        mechanism discussed in this document does not consider (e.g., how long
        to preserve state between connections).  Therefore, while the general
        principles given in <a href="#sect-4" class="xref">Section 4</a> are
        likely applicable, sharing time-based loss detection information
        across flows is outside the scope of this document.<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-requirements">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-requirements" class="section-name selfRef">Requirements</a>
      </h2>
<p id="section-4-1">
   We now list the requirements that apply when designing primary or
   last-resort time-based loss detection mechanisms.  For historical
   reasons and ease of exposition, we refer to the time between sending
   a packet and determining the packet has been lost due to lack of
   delivery confirmation as the "retransmission timeout" or "RTO".
   After the RTO passes without delivery confirmation, the sender may
   safely assume the packet is lost.  However, as discussed above, the
   detected loss need not be repaired (i.e., the loss could be detected
   only for congestion control and not reliability purposes).<a href="#section-4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-4-2">
        <dt>(1)</dt>
<dd id="section-4-2.1">
          <p id="section-4-2.1.1">As we note above, loss detection happens when a sender does not
   receive delivery confirmation within some expected period of
   time.  In the absence of any knowledge about the latency of a
   path, the initial RTO <span class="bcp14">MUST</span> be conservatively set to no less
   than
   1 second.<a href="#section-4-2.1.1" class="pilcrow">¶</a></p>
<p id="section-4-2.1.2">Correctness is of the utmost importance when transmitting
              into a network with unknown properties because:<a href="#section-4-2.1.2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-2.1.3.1">Premature loss detection can trigger spurious retransmits
                that could cause issues when a network is already
                congested.<a href="#section-4-2.1.3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4-2.1.3.2">Premature loss detection can needlessly cause congestion
                control to dramatically lower the sender's allowed
                transmission rate, especially since the rate is already
                likely low at this stage of the communication.  Recovering
                from such a rate change can take a relatively long time.<a href="#section-4-2.1.3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4-2.1.3.3">Finally, as discussed below, sometimes using time-based
                loss detection and retransmissions can cause ambiguities in
                assessing the latency of a network path.  Therefore, it is
                especially important for the first latency sample to be free
                of ambiguities such that there is a baseline for the remainder
                of the communication.<a href="#section-4-2.1.3.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4-2.1.4">
            The specific constant (1 second) comes from the analysis of
     Internet
      round-trip times (RTTs) found in <span><a href="https://www.rfc-editor.org/rfc/rfc6298#appendix-A" class="relref">Appendix A</a> of [<a href="#RFC6298" class="xref">RFC6298</a>]</span>.<a href="#section-4-2.1.4" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-4-2.2">
          <p id="section-4-2.2.1"> We now specify four requirements that pertain to setting an
   expected time interval for delivery confirmation.<a href="#section-4-2.2.1" class="pilcrow">¶</a></p>
<p id="section-4-2.2.2">
        Often, measuring the time required for delivery confirmation is
 framed as assessing the RTT of the network path.
 The RTT is the minimum amount of time required to receive delivery
 confirmation and also often follows protocol behavior whereby
 acknowledgments are generated quickly after data arrives.  For
 instance, this is the case for the RTO used by TCP <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span> and SCTP <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span>.  However, this
 is somewhat misleading, and the expected latency is better framed as
 the "feedback time" (FT).  In other words, the expectation is not
 always simply a network property; it can include additional time
 before a sender should reasonably expect a response.<a href="#section-4-2.2.2" class="pilcrow">¶</a></p>
<p id="section-4-2.2.3">For instance, consider a UDP-based DNS request from a client to
     a
     recursive resolver <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>.
     When the request can be
     served from the resolver's cache, the feedback time (FT) likely
     well approximates the
     network RTT between the client and resolver.  However, on a cache
     miss,
     the resolver will request the needed information from one or more
     authoritative DNS servers, which will non-trivially increase the
     FT
     compared to the network RTT between the client and resolver.<a href="#section-4-2.2.3" class="pilcrow">¶</a></p>
<p id="section-4-2.2.4">Therefore, we express the requirements in terms of FT.  Again,
     for
     ease of exposition, we use "RTO" to indicate the interval between
     a
     packet transmission and the decision that the packet has been
     lost, regardless of whether the packet will be retransmitted.<a href="#section-4-2.2.4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-4-2.2.5">
            <dt>(a)</dt>
<dd id="section-4-2.2.5.1">
              <p id="section-4-2.2.5.1.1">The RTO <span class="bcp14">SHOULD</span> be set based on multiple
              observations of the FT when available.<a href="#section-4-2.2.5.1.1" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.1.2">In other words, the RTO should represent an empirically
 derived
      reasonable amount of time that the sender should wait for delivery
      confirmation before deciding the given data is lost.  Network paths are
      inherently dynamic; therefore, it is crucial to incorporate multiple
      recent FT samples in the RTO to take into account the delay variation
      across time.<a href="#section-4-2.2.5.1.2" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.1.3">For example, TCP's RTO <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span> would satisfy this requirement due to its
                use of an exponentially weighted moving average (EWMA) to
                combine multiple FT samples into a "smoothed RTT".  In the
                name of conservativeness, TCP goes further to also include an
                explicit variance term when computing the RTO.<a href="#section-4-2.2.5.1.3" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.1.4">While multiple FT samples are crucial for capturing the
 delay
      dynamics of a path, we explicitly do not tightly specify the
      process -- including the number of FT samples to use and how/when to age
      samples out of the RTO calculation -- as the particulars could depend on
      the situation and/or goals of each specific loss detector.<a href="#section-4-2.2.5.1.4" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.1.5">Finally, FT samples come from packet exchanges between
 peers.  We
      encourage protocol designers -- especially for new protocols -- to
      strive
      to ensure the feedback is not easily spoofable by on- or off-path
      attackers such that they can perturb a host's notion of the FT.
      Ideally, all messages would be cryptographically secure, but given that
      this is not always possible -- especially in legacy protocols -- using a
      healthy amount of randomness in the packets is encouraged.<a href="#section-4-2.2.5.1.5" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-4-2.2.5.2">
              <p id="section-4-2.2.5.2.1">FT observations <span class="bcp14">SHOULD</span> be taken and
       incorporated into the RTO at
      least once per RTT or as frequently as data is exchanged in cases where
      that happens less frequently than once per RTT.<a href="#section-4-2.2.5.2.1" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.2.2">Internet measurements show that taking only a single FT
 sample per
      TCP connection results in a relatively poorly performing RTO mechanism
      <span>[<a href="#AP99" class="xref">AP99</a>]</span>, hence this requirement that the
      FT be sampled
      continuously throughout the lifetime of communication.<a href="#section-4-2.2.5.2.2" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.2.3">As an example, TCP takes an FT sample roughly once per RTT,
                or, if using the timestamp option <span>[<a href="#RFC7323" class="xref">RFC7323</a>]</span>, on each acknowledgment arrival.  <span>[<a href="#AP99" class="xref">AP99</a>]</span> shows that both these
                approaches result in roughly equivalent performance for the
                RTO estimator.<a href="#section-4-2.2.5.2.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt>(c)</dt>
<dd id="section-4-2.2.5.3">
              <p id="section-4-2.2.5.3.1">FT observations <span class="bcp14">MAY</span> be taken from non-data
       exchanges.<a href="#section-4-2.2.5.3.1" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.3.2">Some protocols use non-data exchanges for various reasons,
 e.g.,
      keepalives, heartbeats, and control messages.  To the extent that the
      latency of these exchanges mirrors data exchange, they can be leveraged
      to take FT samples within the RTO mechanism.  Such samples can help
      protocols keep their RTO accurate during lulls in data transmission.
      However, given that these messages may not be subject to the same delays
      as data transmission, we do not take a general view on whether this is
      useful or not.<a href="#section-4-2.2.5.3.2" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt>(d)</dt>
<dd id="section-4-2.2.5.4">
              <p id="section-4-2.2.5.4.1">An RTO mechanism <span class="bcp14">MUST NOT</span> use ambiguous FT
       samples.<a href="#section-4-2.2.5.4.1" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.4.2">Assume two copies of some packet X are transmitted at
                times t0 and t1. Then, at time t2, the sender receives
                confirmation that X in fact arrived.  In some cases, it is not
                clear which copy of X triggered the confirmation; hence, the
                actual FT is either t2-t1 or t2-t0, but which is a mystery.
                Therefore, in this situation, an implementation <span class="bcp14">MUST NOT</span> use either version of the FT sample and hence not
                update the RTO (as discussed in <span>[<a href="#KP87" class="xref">KP87</a>]</span> and <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>).<a href="#section-4-2.2.5.4.2" class="pilcrow">¶</a></p>
<p id="section-4-2.2.5.4.3">There are cases where two copies of some data are
      transmitted in a way whereby the sender can tell which is
      being acknowledged by an incoming ACK. For example, TCP's
      timestamp option <span>[<a href="#RFC7323" class="xref">RFC7323</a>]</span> allows for
      packets to be
      uniquely identified and hence avoid the ambiguity.  In such
      cases, there is no ambiguity and the resulting samples can
      update the RTO.<a href="#section-4-2.2.5.4.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
<dt>(3)</dt>
<dd id="section-4-2.3">
          <p id="section-4-2.3.1">Loss detected by the RTO mechanism <span class="bcp14">MUST</span> be taken
          as an indication of network congestion and the sending rate adapted
          using a standard mechanism (e.g., TCP collapses the congestion
          window to one packet <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>).<a href="#section-4-2.3.1" class="pilcrow">¶</a></p>
<p id="section-4-2.3.2">This ensures network safety.<a href="#section-4-2.3.2" class="pilcrow">¶</a></p>
<p id="section-4-2.3.3">An exception to this rule is if an IETF standardized mechanism
      determines that a particular loss is due to a non-congestion event
      (e.g., packet corruption).  In such a case, a congestion control action
      is not required.  Additionally, congestion control actions taken based
      on time-based loss detection could be reversed when a standard mechanism
      post facto determines that the cause of the loss was not congestion
      (e.g., <span>[<a href="#RFC5682" class="xref">RFC5682</a>]</span>).<a href="#section-4-2.3.3" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt>(4)</dt>
<dd id="section-4-2.4">
          <p id="section-4-2.4.1">Each time the RTO is used to detect a loss, the value of the RTO
   <span class="bcp14">MUST</span>
      be exponentially backed off such that the next firing requires a longer
      interval.  The backoff <span class="bcp14">SHOULD</span> be removed after either (a)
      the subsequent
      successful transmission of non-retransmitted data, or (b) an RTO passes
      without detecting additional losses.  The former will generally be
      quicker.  The latter covers cases where loss is detected but not
      repaired.<a href="#section-4-2.4.1" class="pilcrow">¶</a></p>
<p id="section-4-2.4.2">A maximum value <span class="bcp14">MAY</span> be placed on the RTO.  The
            maximum RTO <span class="bcp14">MUST NOT</span> be less than 60 seconds (as
            specified in <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>).<a href="#section-4-2.4.2" class="pilcrow">¶</a></p>
<p id="section-4-2.4.3">This ensures network safety.<a href="#section-4-2.4.3" class="pilcrow">¶</a></p>
<p id="section-4-2.4.4">As with guideline (3), an exception to this rule exists if an
     IETF
      standardized mechanism determines that a particular loss is not due to
      congestion.<a href="#section-4-2.4.4" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-discussion">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-discussion" class="section-name selfRef">Discussion</a>
      </h2>
<p id="section-5-1">
   We note that research has shown the tension between the
   responsiveness and correctness of time-based loss detection seems to
   be a fundamental tradeoff in the context of TCP <span>[<a href="#AP99" class="xref">AP99</a>]</span>.  That is,
   making the RTO more aggressive (e.g., via changing TCP's
   exponentially weighted moving average (EWMA) gains, lowering the
   minimum RTO, etc.) can reduce the time required to detect actual
   loss.  However, at the same time, such aggressiveness leads to more
   cases of mistakenly declaring packets lost that ultimately arrived
   at the receiver.  Therefore, being as aggressive as the requirements
   given in the previous section allow in any particular situation may
   not be the best course of action because detecting loss, even if
   falsely, carries a requirement to invoke a congestion response
   that will ultimately reduce the transmission rate.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
   While the tradeoff between responsiveness and correctness seems
   fundamental, the tradeoff can be made less relevant if the sender can
   detect and recover from mistaken loss detection.  Several mechanisms have
   been proposed for this purpose, such as Eifel <span>[<a href="#RFC3522" class="xref">RFC3522</a>]</span>, Forward RTO-Recovery (F-RTO) <span>[<a href="#RFC5682" class="xref">RFC5682</a>]</span>, and Duplicate Selective Acknowledgement (DSACK) <span>[<a href="#RFC2883" class="xref">RFC2883</a>]</span> <span>[<a href="#RFC3708" class="xref">RFC3708</a>]</span>.  Using such
   mechanisms may allow a data originator to tip towards being more responsive
   without incurring (as much of) the attendant costs of mistakenly declaring
   packets to be lost.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
   Also, note that, in addition to the experiments discussed in <span>[<a href="#AP99" class="xref">AP99</a>]</span>,
   the Linux TCP implementation has been using various non-standard RTO
   mechanisms for many years seemingly without large-scale problems
   (e.g., using different EWMA gains than specified in <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>).
   Further, a number of TCP implementations use a steady-state minimum
   RTO that is less than the 1 second specified in <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>.  While
   the implication of these deviations from the standard may be more
   spurious retransmits (per <span>[<a href="#AP99" class="xref">AP99</a>]</span>), we are
   aware of no large-scale
   network safety issues caused by this change to the minimum RTO.
   This informs the guidelines in the last section (e.g., there is no
   minimum RTO specified).<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">
   Finally, we note that while allowing implementations to be more
   aggressive could in fact increase the number of needless
   retransmissions, the above requirements fail safely in that they
   insist on exponential backoff and a transmission rate reduction.
   Therefore, providing implementers more latitude than they have
   traditionally been given in IETF specifications of RTO mechanisms
   does not somehow open the flood gates to aggressive behavior.  Since
   there is a downside to being aggressive, the incentives for proper
   behavior are retained in the mechanism.<a href="#section-5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">
   This document does not alter the security properties of time-based
   loss detection mechanisms.  See <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>
   for a discussion of these
   within the context of TCP.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-7">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">
   This document has no IANA actions.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
      <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="AP99">[AP99]</dt>
        <dd>
<span class="refAuthor">Allman, M.</span><span class="refAuthor"> and V. Paxson</span>, <span class="refTitle">"On Estimating End-to-End Network Path Properties"</span>, <span class="refContent">Proceedings of the ACM SIGCOMM Technical Symposium</span>, <time datetime="1999-09" class="refDate">September 1999</time>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tcpm-rack">[CCDJ20]</dt>
        <dd>
<span class="refAuthor">Cheng, Y.</span><span class="refAuthor">, Cardwell, N.</span><span class="refAuthor">, Dukkipati, N.</span><span class="refAuthor">, and P. Jha</span>, <span class="refTitle">"The RACK-TLP loss detection algorithm for TCP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tcpm-rack-13</span>, <time datetime="2020-11-02" class="refDate">2 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-tcpm-rack-13">https://tools.ietf.org/html/draft-ietf-tcpm-rack-13</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.dukkipati-tcpm-tcp-loss-probe">[DCCM13]</dt>
        <dd>
<span class="refAuthor">Dukkipati, N.</span><span class="refAuthor">, Cardwell, N.</span><span class="refAuthor">, Cheng, Y.</span><span class="refAuthor">, and M. Mathis</span>, <span class="refTitle">"Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-dukkipati-tcpm-tcp-loss-probe-01</span>, <time datetime="2013-02-25" class="refDate">25 February 2013</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01">https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-quic-recovery">[IS20]</dt>
        <dd>
<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and I. Swett, Ed.</span>, <span class="refTitle">"QUIC Loss Detection and Congestion Control"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-recovery-32</span>, <time datetime="2020-10-20" class="refDate">20 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-recovery-32">https://tools.ietf.org/html/draft-ietf-quic-recovery-32</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Jac88">[Jac88]</dt>
        <dd>
<span class="refAuthor">Jacobson, V.</span>, <span class="refTitle">"Congestion avoidance and control"</span>, <span class="refContent">ACM SIGCOMM</span>, <span class="seriesInfo">DOI 10.1145/52325.52356</span>, <time datetime="1988-08" class="refDate">August 1988</time>, <span>&lt;<a href="https://doi.org/10.1145/52325.52356">https://doi.org/10.1145/52325.52356</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="KP87">[KP87]</dt>
        <dd>
<span class="refAuthor">Karn, P.</span><span class="refAuthor"> and C. Partridge</span>, <span class="refTitle">"Improving Round-Trip Time Estimates in Reliable Transport Protocols"</span>, <span class="refContent">SIGCOMM 87</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1034">[RFC1034]</dt>
        <dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - concepts and facilities"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1034</span>, <span class="seriesInfo">DOI 10.17487/RFC1034</span>, <time datetime="1987-11" class="refDate">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1034">https://www.rfc-editor.org/info/rfc1034</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1035">[RFC1035]</dt>
        <dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11" class="refDate">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2018">[RFC2018]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span><span class="refAuthor">, Mahdavi, J.</span><span class="refAuthor">, Floyd, S.</span><span class="refAuthor">, and A. Romanow</span>, <span class="refTitle">"TCP Selective Acknowledgment Options"</span>, <span class="seriesInfo">RFC 2018</span>, <span class="seriesInfo">DOI 10.17487/RFC2018</span>, <time datetime="1996-10" class="refDate">October 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2018">https://www.rfc-editor.org/info/rfc2018</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2140">[RFC2140]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refTitle">"TCP Control Block Interdependence"</span>, <span class="seriesInfo">RFC 2140</span>, <span class="seriesInfo">DOI 10.17487/RFC2140</span>, <time datetime="1997-04" class="refDate">April 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2140">https://www.rfc-editor.org/info/rfc2140</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2883">[RFC2883]</dt>
        <dd>
<span class="refAuthor">Floyd, S.</span><span class="refAuthor">, Mahdavi, J.</span><span class="refAuthor">, Mathis, M.</span><span class="refAuthor">, and M. Podolsky</span>, <span class="refTitle">"An Extension to the Selective Acknowledgement (SACK) Option for TCP"</span>, <span class="seriesInfo">RFC 2883</span>, <span class="seriesInfo">DOI 10.17487/RFC2883</span>, <time datetime="2000-07" class="refDate">July 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2883">https://www.rfc-editor.org/info/rfc2883</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3124">[RFC3124]</dt>
        <dd>
<span class="refAuthor">Balakrishnan, H.</span><span class="refAuthor"> and S. Seshan</span>, <span class="refTitle">"The Congestion Manager"</span>, <span class="seriesInfo">RFC 3124</span>, <span class="seriesInfo">DOI 10.17487/RFC3124</span>, <time datetime="2001-06" class="refDate">June 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3124">https://www.rfc-editor.org/info/rfc3124</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3261">[RFC3261]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3522">[RFC3522]</dt>
        <dd>
<span class="refAuthor">Ludwig, R.</span><span class="refAuthor"> and M. Meyer</span>, <span class="refTitle">"The Eifel Detection Algorithm for TCP"</span>, <span class="seriesInfo">RFC 3522</span>, <span class="seriesInfo">DOI 10.17487/RFC3522</span>, <time datetime="2003-04" class="refDate">April 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3522">https://www.rfc-editor.org/info/rfc3522</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3708">[RFC3708]</dt>
        <dd>
<span class="refAuthor">Blanton, E.</span><span class="refAuthor"> and M. Allman</span>, <span class="refTitle">"Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions"</span>, <span class="seriesInfo">RFC 3708</span>, <span class="seriesInfo">DOI 10.17487/RFC3708</span>, <time datetime="2004-02" class="refDate">February 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3708">https://www.rfc-editor.org/info/rfc3708</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4960">[RFC4960]</dt>
        <dd>
<span class="refAuthor">Stewart, R., Ed.</span>, <span class="refTitle">"Stream Control Transmission Protocol"</span>, <span class="seriesInfo">RFC 4960</span>, <span class="seriesInfo">DOI 10.17487/RFC4960</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4960">https://www.rfc-editor.org/info/rfc4960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5681">[RFC5681]</dt>
        <dd>
<span class="refAuthor">Allman, M.</span><span class="refAuthor">, Paxson, V.</span><span class="refAuthor">, and E. Blanton</span>, <span class="refTitle">"TCP Congestion Control"</span>, <span class="seriesInfo">RFC 5681</span>, <span class="seriesInfo">DOI 10.17487/RFC5681</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5681">https://www.rfc-editor.org/info/rfc5681</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5682">[RFC5682]</dt>
        <dd>
<span class="refAuthor">Sarolahti, P.</span><span class="refAuthor">, Kojo, M.</span><span class="refAuthor">, Yamamoto, K.</span><span class="refAuthor">, and M. Hata</span>, <span class="refTitle">"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP"</span>, <span class="seriesInfo">RFC 5682</span>, <span class="seriesInfo">DOI 10.17487/RFC5682</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5682">https://www.rfc-editor.org/info/rfc5682</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5740">[RFC5740]</dt>
        <dd>
<span class="refAuthor">Adamson, B.</span><span class="refAuthor">, Bormann, C.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and J. Macker</span>, <span class="refTitle">"NACK-Oriented Reliable Multicast (NORM) Transport Protocol"</span>, <span class="seriesInfo">RFC 5740</span>, <span class="seriesInfo">DOI 10.17487/RFC5740</span>, <time datetime="2009-11" class="refDate">November 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5740">https://www.rfc-editor.org/info/rfc5740</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6182">[RFC6182]</dt>
        <dd>
<span class="refAuthor">Ford, A.</span><span class="refAuthor">, Raiciu, C.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, Barre, S.</span><span class="refAuthor">, and J. Iyengar</span>, <span class="refTitle">"Architectural Guidelines for Multipath TCP Development"</span>, <span class="seriesInfo">RFC 6182</span>, <span class="seriesInfo">DOI 10.17487/RFC6182</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6182">https://www.rfc-editor.org/info/rfc6182</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6298">[RFC6298]</dt>
        <dd>
<span class="refAuthor">Paxson, V.</span><span class="refAuthor">, Allman, M.</span><span class="refAuthor">, Chu, J.</span><span class="refAuthor">, and M. Sargent</span>, <span class="refTitle">"Computing TCP's Retransmission Timer"</span>, <span class="seriesInfo">RFC 6298</span>, <span class="seriesInfo">DOI 10.17487/RFC6298</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6298">https://www.rfc-editor.org/info/rfc6298</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6675">[RFC6675]</dt>
        <dd>
<span class="refAuthor">Blanton, E.</span><span class="refAuthor">, Allman, M.</span><span class="refAuthor">, Wang, L.</span><span class="refAuthor">, Jarvinen, I.</span><span class="refAuthor">, Kojo, M.</span><span class="refAuthor">, and Y. Nishida</span>, <span class="refTitle">"A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP"</span>, <span class="seriesInfo">RFC 6675</span>, <span class="seriesInfo">DOI 10.17487/RFC6675</span>, <time datetime="2012-08" class="refDate">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6675">https://www.rfc-editor.org/info/rfc6675</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7323">[RFC7323]</dt>
      <dd>
<span class="refAuthor">Borman, D.</span><span class="refAuthor">, Braden, B.</span><span class="refAuthor">, Jacobson, V.</span><span class="refAuthor">, and R. Scheffenegger, Ed.</span>, <span class="refTitle">"TCP Extensions for High Performance"</span>, <span class="seriesInfo">RFC 7323</span>, <span class="seriesInfo">DOI 10.17487/RFC7323</span>, <time datetime="2014-09" class="refDate">September 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7323">https://www.rfc-editor.org/info/rfc7323</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acknowledgments">
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1">
   This document benefits from years of discussions with <span class="contact-name">Ethan Blanton</span>, <span class="contact-name">Sally Floyd</span>, <span class="contact-name">Jana Iyengar</span>, <span class="contact-name">Shawn Ostermann</span>, <span class="contact-name">Vern Paxson</span>, and the members of the TCPM and TCPIMPL Working
   Groups.  <span class="contact-name">Ran Atkinson</span>, <span class="contact-name">Yuchung    Cheng</span>, <span class="contact-name">David Black</span>, <span class="contact-name">Stewart    Bryant</span>, <span class="contact-name">Martin Duke</span>, <span class="contact-name">Wesley    Eddy</span>, <span class="contact-name">Gorry Fairhurst</span>, <span class="contact-name">Rahul    Arvind Jadhav</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Nicolas Kuhn</span>, <span class="contact-name">Jonathan Looney</span>, and <span class="contact-name">Michael Scharf</span>
   provided useful comments on
   previous draft versions of this document.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mark Allman</span></div>
<div dir="auto" class="left"><span class="org">International Computer Science Institute</span></div>
<div dir="auto" class="left"><span class="street-address">2150 Shattuck Ave., Suite 1100</span></div>
<div dir="auto" class="left">
<span class="locality">Berkeley</span>, <span class="region">CA</span> <span class="postal-code">94704</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mallman@icir.org" class="email">mallman@icir.org</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://www.icir.org/mallman" class="url">https://www.icir.org/mallman</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>