File: rfc8985.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 (2409 lines) | stat: -rw-r--r-- 153,448 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP</title>
<meta content="Yuchung Cheng" name="author">
<meta content="Neal Cardwell" name="author">
<meta content="Nandita Dukkipati" name="author">
<meta content="Priyaranjan Jha" name="author">
<meta content="
       
This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach.  
       
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="TCP" name="keyword">
<meta content="Loss Recovery" name="keyword">
<meta content="Reordering" name="keyword">
<meta content="8985" 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="rfc8985.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/rfc8985" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack-15" 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 8985</td>
<td class="center">RACK</td>
<td class="right">February 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Cheng, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8985" class="eref">8985</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-02" class="published">February 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">Y. Cheng</div>
<div class="org">Google, Inc.</div>
</div>
<div class="author">
      <div class="author-name">N. Cardwell</div>
<div class="org">Google, Inc.</div>
</div>
<div class="author">
      <div class="author-name">N. Dukkipati</div>
<div class="org">Google, Inc.</div>
</div>
<div class="author">
      <div class="author-name">P. Jha</div>
<div class="org">Google, Inc.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8985</h1>
<h1 id="title">The RACK-TLP Loss Detection Algorithm for TCP</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach.<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/rfc8985">https://www.rfc-editor.org/info/rfc8985</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-background" class="xref">Background</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-motivation" class="xref">Motivation</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-rack-tlp-high-level-design" class="xref">RACK-TLP High-Level Design</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-rack-time-based-loss-infere" class="xref">RACK: Time-Based Loss Inferences from ACKs</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-tlp-sending-one-segment-to-" class="xref">TLP: Sending One Segment to Probe Losses Quickly with RACK</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-rack-tlp-reordering-resilie" class="xref">RACK-TLP: Reordering Resilience with a Time Threshold</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.3.2.1">
                    <p id="section-toc.1-1.3.2.3.2.1.1"><a href="#section-3.3.1" class="xref">3.3.1</a>.  <a href="#name-reordering-design-rationale" class="xref">Reordering Design Rationale</a><a href="#section-toc.1-1.3.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.3.2.2">
                    <p id="section-toc.1-1.3.2.3.2.2.1"><a href="#section-3.3.2" class="xref">3.3.2</a>.  <a href="#name-reordering-window-adaptatio" class="xref">Reordering Window Adaptation</a><a href="#section-toc.1-1.3.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-an-example-of-rack-tlp-in-a" class="xref">An Example of RACK-TLP in Action: Fast Recovery</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-an-example-of-rack-tlp-in-ac" class="xref">An Example of RACK-TLP in Action: RTO</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-design-summary" class="xref">Design Summary</a><a href="#section-toc.1-1.3.2.6.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-requirements" class="xref">Requirements</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-definitions" class="xref">Definitions</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact 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-terms" class="xref">Terms</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact 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-per-segment-variables" class="xref">Per-Segment Variables</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact 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-per-connection-variables" class="xref">Per-Connection Variables</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-per-connection-timers" class="xref">Per-Connection Timers</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-rack-algorithm-details" class="xref">RACK Algorithm Details</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-upon-transmitting-a-data-se" class="xref">Upon Transmitting a Data Segment</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-upon-receiving-an-ack" class="xref">Upon Receiving an ACK</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-upon-rto-expiration" class="xref">Upon RTO Expiration</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-tlp-algorithm-details" class="xref">TLP Algorithm Details</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-initializing-state" class="xref">Initializing State</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-scheduling-a-loss-probe" class="xref">Scheduling a Loss Probe</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-sending-a-loss-probe-upon-p" class="xref">Sending a Loss Probe upon PTO Expiration</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-detecting-losses-using-the-" class="xref">Detecting Losses Using the ACK of the Loss Probe</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.4.2.1">
                    <p id="section-toc.1-1.7.2.4.2.1.1"><a href="#section-7.4.1" class="xref">7.4.1</a>.  <a href="#name-general-case-detecting-pack" class="xref">General Case: Detecting Packet Losses Using RACK</a><a href="#section-toc.1-1.7.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.4.2.2">
                    <p id="section-toc.1-1.7.2.4.2.2.1"><a href="#section-7.4.2" class="xref">7.4.2</a>.  <a href="#name-special-case-detecting-a-si" class="xref">Special Case: Detecting a Single Loss Repaired by the Loss Probe</a><a href="#section-toc.1-1.7.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact 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-managing-rack-tlp-timers" class="xref">Managing RACK-TLP Timers</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact 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-discussion" class="xref">Discussion</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-advantages-and-disadvantage" class="xref">Advantages and Disadvantages</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-relationships-with-other-lo" class="xref">Relationships with Other Loss Recovery Algorithms</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-interaction-with-congestion" class="xref">Interaction with Congestion Control</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-tlp-recovery-detection-with" class="xref">TLP Recovery Detection with Delayed ACKs</a><a href="#section-toc.1-1.9.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.5">
                <p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5" class="xref">9.5</a>.  <a href="#name-rack-tlp-for-other-transpor" class="xref">RACK-TLP for Other Transport Protocols</a><a href="#section-toc.1-1.9.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact 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="compact 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="compact toc ulEmpty">
<li class="compact 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="compact 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="compact toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact 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-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.14.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">This document presents RACK-TLP, a TCP loss detection algorithm that improves upon the widely implemented duplicate acknowledgment (DupAck) counting approach described in <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> and <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>; it is <span class="bcp14">RECOMMENDED</span> as an alternative to that earlier approach. RACK-TLP has two parts. Recent Acknowledgment (RACK) detects losses quickly using time-based inferences derived from ACK feedback. Tail Loss Probe (TLP) triggers ACK feedback by quickly sending a probe segment to avoid retransmission timeout (RTO) events.<a href="#section-1-1" class="pilcrow">¶</a></p>
<div id="background">
<section id="section-1.1">
        <h3 id="name-background">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-background" class="section-name selfRef">Background</a>
        </h3>
<p id="section-1.1-1">In traditional TCP loss recovery algorithms <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>, a sender starts fast recovery when the number of DupAcks received reaches a threshold (DupThresh) that defaults to 3 (this approach is referred to as "DupAck counting" in the rest of the document). The sender also halves the congestion window during the recovery. The rationale behind the partial window reduction is that congestion does not seem severe since ACK clocking is still maintained. The time elapsed in fast recovery can be just one round trip, e.g., if the sender uses SACK-based recovery <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span> and the number of lost segments is small.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">If fast recovery is not triggered or is triggered but fails to repair all the losses, then the sender resorts to RTO recovery. The RTO timer interval is conservatively the smoothed RTT (SRTT) plus four times the RTT variation, and is lower bounded to 1 second <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>. Upon RTO timer expiration, the sender retransmits the first unacknowledged segment and resets the congestion window to the loss window value (by default, 1 full-sized segment <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>). The rationale behind the congestion window reset is that an entire flight of data and the ACK clock were lost, so this deserves a cautious response. The sender then retransmits the rest of the data following the slow start algorithm <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>. The time elapsed in RTO recovery is one RTO interval plus the number of round trips needed to repair all the losses.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="motivation">
<section id="section-1.2">
        <h3 id="name-motivation">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-motivation" class="section-name selfRef">Motivation</a>
        </h3>
<p id="section-1.2-1">Fast recovery is the preferred form of loss recovery because it can potentially recover all losses in the timescale of a single round trip, with only a fractional congestion window reduction. RTO recovery and congestion window reset should ideally be the last resort and should ideally be used only when the entire flight is lost. However, in addition to losing an entire flight of data, the following situations can unnecessarily resort to RTO recovery with traditional TCP loss recovery algorithms <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>:<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1.2-2">
<li id="section-1.2-2.1">Packet drops for short flows or at the end of an application data flight. When the sender is limited by the application (e.g., structured request/response traffic), segments lost at the end of the application data transfer often can only be recovered by RTO. Consider an example where only the last segment in a flight of 100 segments is lost. Lacking any DupAck, the sender RTO expires, reduces the congestion window to 1, and raises the congestion window to just 2 after the loss repair is acknowledged. In contrast, any single segment loss occurring between the first and the 97th segment would result in fast recovery, which would only cut the window in half.<a href="#section-1.2-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-1.2-2.2">Lost retransmissions. Heavy congestion or traffic policers can cause retransmissions to be lost. Lost retransmissions cause a resort to RTO recovery since DupAck counting does not detect the loss of the retransmissions. Then the slow start after RTO recovery could cause burst losses again, which severely degrades performance <span>[<a href="#POLICER16" class="xref">POLICER16</a>]</span>.<a href="#section-1.2-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-1.2-2.3">Packet reordering. In this document, "reordering" refers to the events where segments are delivered at the TCP receiver in a chronological order different from their chronological transmission order. Link-layer protocols (e.g., 802.11 block ACK), link bonding, or routers' internal load balancing (e.g., ECMP) can deliver TCP segments out of order. The degree of such reordering is usually within the order of the path round-trip time.

 If the reordering degree is beyond DupThresh, DupAck counting can cause a spurious fast recovery and unnecessary congestion window reduction. To mitigate the issue, Non-Congestion Robustness (NCR) for TCP <span>[<a href="#RFC4653" class="xref">RFC4653</a>]</span> increases the DupThresh from the current fixed value of three duplicate ACKs <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> to approximate a congestion window of data having left the network.<a href="#section-1.2-2.3" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
     The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
     "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
     described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
     when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rack-tlp-high-level-design">
<section id="section-3">
      <h2 id="name-rack-tlp-high-level-design">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-rack-tlp-high-level-design" class="section-name selfRef">RACK-TLP High-Level Design</a>
      </h2>
<p id="section-3-1">RACK-TLP allows senders to recover losses more effectively in all three scenarios described in the <a href="#motivation" class="xref">previous</a> section. There are two design principles behind RACK-TLP. The first principle is to detect losses via ACK events as much as possible, to repair losses at round-trip timescales. The second principle is to gently probe the network to solicit additional ACK feedback, to avoid RTO expiration and subsequent congestion window reset. At a high level, the two principles are implemented in RACK and TLP, respectively.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="rack-time-based-loss-inferences-from-acks">
<section id="section-3.1">
        <h3 id="name-rack-time-based-loss-infere">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-rack-time-based-loss-infere" class="section-name selfRef">RACK: Time-Based Loss Inferences from ACKs</a>
        </h3>
<p id="section-3.1-1">
 The rationale behind RACK is that if a segment is delivered out of order, then the segments sent chronologically before that were either lost or reordered. This concept is not fundamentally different from those described in <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>, <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>, or <span>[<a href="#FACK" class="xref">FACK</a>]</span>. RACK's key innovation is using per-segment transmission timestamps and widely deployed SACK <span>[<a href="#RFC2018" class="xref">RFC2018</a>]</span> options to conduct time-based inferences instead of inferring losses by counting ACKs or SACKed sequences. Time-based inferences are more robust than DupAck counting approaches because they do not depend on flight size and thus are effective for application-limited traffic.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Conceptually, RACK keeps a virtual timer for every data segment sent (including retransmissions). Each timer expires dynamically based on the latest RTT measurements plus an additional delay budget to accommodate potential packet reordering (called the 
 "reordering window"). When a segment's timer expires, RACK marks the corresponding segment as lost for retransmission.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">In reality, as an algorithm, RACK does not arm a timer for every segment sent because it's not necessary. Instead, the sender records the most recent transmission time of every data segment sent, including retransmissions. For each ACK received, the sender calculates the latest RTT measurement (if eligible) and adjusts the expiration time of every segment sent but not yet delivered. If a segment has expired, RACK marks it as lost.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">Since the time-based logic of RACK applies equally to retransmissions and original transmissions, 
 it can detect lost retransmissions as well. If a segment has been retransmitted but its most recent (re)transmission timestamp has expired, then, after a reordering window, it's marked as lost.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tlp-sending-one-segment-to-probe-losses-quickly-with-rack">
<section id="section-3.2">
        <h3 id="name-tlp-sending-one-segment-to-">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-tlp-sending-one-segment-to-" class="section-name selfRef">TLP: Sending One Segment to Probe Losses Quickly with RACK</a>
        </h3>
<p id="section-3.2-1">RACK infers losses from ACK feedback; however, in some cases, ACKs are sparse, particularly when the inflight is small or when the losses are high. In some challenging cases, the last few segments in a flight are lost. With the operations described in <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> or <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>, the sender's RTO would expire and reset the congestion window when, in reality, most of the flight has been delivered.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">Consider an example where a sender with a large congestion window transmits 100 new data segments after an application write and only the last three segments are lost. Without RACK-TLP, the RTO expires, the sender retransmits the first unacknowledged segment, and the congestion window slow starts from 1. After all the retransmits are acknowledged, the congestion window is increased to 4. The total delivery time for this application transfer is three RTTs plus one RTO, a steep cost given that only a tiny fraction of the flight was lost. If instead the losses had occurred three segments sooner in the flight, then fast recovery would have recovered all losses within one round trip and would have avoided resetting the congestion window.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">Fast recovery would be preferable in such scenarios; TLP is designed to trigger the feedback RACK needed to enable that. After the last (100th) segment was originally sent, TLP sends the next available (new) segment or retransmits the last (highest-sequenced) segment in two round trips to probe the network, hence the name "Tail Loss Probe". The successful delivery of the probe would solicit an ACK. RACK uses this ACK to detect that the 98th and 99th segments were lost, trigger fast recovery, and retransmit both successfully. The total recovery time is four RTTs, and the congestion window is only partially reduced instead of being fully reset. If the probe was also lost, then the sender would invoke RTO recovery, resetting the congestion window.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rack-tlp-reordering-resilience-with-a-time-threshold">
<section id="section-3.3">
        <h3 id="name-rack-tlp-reordering-resilie">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-rack-tlp-reordering-resilie" class="section-name selfRef">RACK-TLP: Reordering Resilience with a Time Threshold</a>
        </h3>
<div id="reordering-design-rationale">
<section id="section-3.3.1">
          <h4 id="name-reordering-design-rationale">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-reordering-design-rationale" class="section-name selfRef">Reordering Design Rationale</a>
          </h4>
<p id="section-3.3.1-1">Upon receiving an ACK indicating a SACKed segment, a sender cannot tell immediately whether that was a result of reordering or loss. It can only distinguish between the two in hindsight if the missing sequence ranges are filled in later without retransmission. Thus, a loss detection algorithm needs to budget some wait time -- a reordering window -- to try to disambiguate packet reordering from packet loss.<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.3.1-2">The reordering window in the DupAck counting approach is implicitly defined as the elapsed time to receive DupThresh SACKed segments or duplicate acknowledgments. This approach is effective if the network reordering degree (in sequence distance) is smaller than DupThresh and at least DupThresh segments after the loss is acknowledged. For cases where the reordering degree is larger than the default DupThresh of 3 packets, one alternative is to dynamically adapt DupThresh based on the FlightSize (e.g., the sender adjusts the DupThresh to half of the FlightSize). However, this does not work well with the following two types of reordering:<a href="#section-3.3.1-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.3.1-3">
<li id="section-3.3.1-3.1">Application-limited flights where the last non-full-sized segment is delivered first and then the remaining full-sized segments in the flight are delivered in order. This reordering pattern can occur when segments traverse parallel forwarding paths. In such scenarios, the degree of reordering in packet distance is one segment less than the flight size.<a href="#section-3.3.1-3.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.3.1-3.2">A flight of segments that are delivered partially out of order. One cause for this pattern is wireless link-layer retransmissions with an inadequate reordering buffer at the receiver. In such scenarios, the wireless sender sends the data packets in order initially, but some are lost and then recovered by link-layer retransmissions; the wireless receiver delivers the TCP data packets in the order they are received due to the inadequate reordering buffer. The random wireless transmission errors in such scenarios cause the reordering degree, expressed in packet distance, to have highly variable values up to the flight size.<a href="#section-3.3.1-3.2" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.3.1-4">In the above two cases, the degree of reordering in packet distance is highly variable. This makes the DupAck counting approach ineffective, including dynamic adaptation variants as in <span>[<a href="#RFC4653" class="xref">RFC4653</a>]</span>. Instead, the degree of reordering in time difference in such cases is usually within a single round-trip time. 
This is because the packets either traverse disjoint paths with similar propagation delays or are repaired quickly by the local access technology. Hence, using a time threshold instead of a packet threshold strikes a middle ground, allowing a bounded degree of reordering resilience while still allowing fast recovery. This is the rationale behind the RACK-TLP reordering resilience design.<a href="#section-3.3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.3.1-5">Specifically, RACK-TLP introduces a new dynamic reordering window parameter in time units, and the sender considers a data segment S lost if both of these conditions are met:<a href="#section-3.3.1-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.3.1-6">
<li id="section-3.3.1-6.1">Another data segment sent later than S has been delivered.<a href="#section-3.3.1-6.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.3.1-6.2">S has not been delivered after the estimated round-trip time plus the reordering window.<a href="#section-3.3.1-6.2" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.3.1-7">
 Note that condition (1) implies at least one round trip of time has elapsed since S has been sent.<a href="#section-3.3.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="reordering-window-adaptation">
<section id="section-3.3.2">
          <h4 id="name-reordering-window-adaptatio">
<a href="#section-3.3.2" class="section-number selfRef">3.3.2. </a><a href="#name-reordering-window-adaptatio" class="section-name selfRef">Reordering Window Adaptation</a>
          </h4>
<p id="section-3.3.2-1">The RACK reordering window adapts to the measured duration of reordering events within reasonable and specific bounds to disincentivize excessive reordering. More specifically, the sender sets the reordering window as follows:<a href="#section-3.3.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.3.2-2">
<li id="section-3.3.2-2.1">
<div id="rule1">The reordering window <span class="bcp14">SHOULD</span> be set to  zero if no reordering has been observed on the connection so far, and either (a) three segments have been SACKed since the last recovery or (b) the sender is already in fast or RTO recovery. Otherwise, the reordering window <span class="bcp14">SHOULD</span> start from a small fraction of the round-trip time or zero if no round-trip time estimate is available.<a href="#rule1" class="pilcrow">¶</a>
</div>
            </li>
<li id="section-3.3.2-2.2">
<div id="rule2">The RACK reordering window <span class="bcp14">SHOULD</span> adaptively increase (using the <a href="#step4alg" class="xref">algorithm</a> in <a href="#step4" class="xref">"Step 4: Update RACK reordering window"</a> below) if the sender receives a Duplicate Selective Acknowledgment (DSACK) option <span>[<a href="#RFC2883" class="xref">RFC2883</a>]</span>. Receiving a DSACK suggests the sender made a spurious retransmission, which may have been due to the reordering window being too small.<a href="#rule2" class="pilcrow">¶</a>
</div>
            </li>
<li id="section-3.3.2-2.3">
<div id="rule3">The RACK reordering window <span class="bcp14">MUST</span> be bounded, and this bound <span class="bcp14">SHOULD</span> be SRTT.<a href="#rule3" class="pilcrow">¶</a>
</div>
          </li>
</ol>
<p id="section-3.3.2-3">Rules <a href="#rule2" class="xref">2</a> and <a href="#rule3" class="xref">3</a> are required to adapt to reordering caused by dynamics such as the prolonged link-layer loss recovery episodes described earlier. Each increase in the reordering window requires a new round trip where the sender receives a DSACK; thus, depending on the extent of reordering, it may take multiple round trips to fully adapt.<a href="#section-3.3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.3.2-4">For short flows, the low initial reordering window helps recover losses quickly, at the risk of spurious retransmissions. The rationale is that spurious retransmissions for short flows are not expected to produce excessive additional network traffic. For long flows, the design tolerates reordering within a round trip. This handles reordering in small timescales (reordering within the round-trip time of the shortest path).<a href="#section-3.3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.3.2-5">However, the fact that the initial reordering window is low and the reordering window's adaptive growth is bounded means that there will continue to be a cost to reordering that disincentivizes excessive reordering.<a href="#section-3.3.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="an-example-of-rack-tlp-in-action-fast-recovery">
<section id="section-3.4">
        <h3 id="name-an-example-of-rack-tlp-in-a">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-an-example-of-rack-tlp-in-a" class="section-name selfRef">An Example of RACK-TLP in Action: Fast Recovery</a>
        </h3>
<p id="section-3.4-1">The following example in <a href="#fig1" class="xref">Figure 1</a> illustrates the RACK-TLP algorithm in action:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<span id="name-rack-tlp-protocol-example"></span><div id="fig1">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-3.4-2.1">
<pre>
 Event  TCP DATA SENDER                            TCP DATA RECEIVER
 _____  ____________________________________________________________
   1.   Send P0, P1, P2, P3          --&gt;
        [P1, P2, P3 dropped by network]

   2.                                &lt;--          Receive P0, ACK P0

   3a.  2RTTs after (2), TLP timer fires
   3b.  TLP: retransmits P3          --&gt;

   4.                                &lt;--         Receive P3, SACK P3

   5a.  Receive SACK for P3
   5b.  RACK: marks P1, P2 lost
   5c.  Retransmit P1, P2            --&gt;
        [P1 retransmission dropped by network]

   6.                                &lt;--    Receive P2, SACK P2 &amp; P3

   7a.  RACK: marks P1 retransmission lost
   7b.  Retransmit P1                --&gt;

   8.                                &lt;--          Receive P1, ACK P3
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-rack-tlp-protocol-example" class="selfRef">RACK-TLP Protocol Example</a>
          </figcaption></figure>
</div>
<div id="fig1desc">
<p id="section-3.4-3"><a href="#fig1" class="xref">Figure 1</a> illustrates a sender sending four segments (P0, P1, P2, P3) and losing the last three segments. After two round trips, TLP sends a loss probe, retransmitting the last segment, P3, to solicit SACK feedback and restore the ACK clock (Event 3). The delivery of P3 enables RACK to infer (Event 5b) that P1 and P2 were likely lost because they were sent before P3. The sender then retransmits P1 and P2. Unfortunately, the retransmission of P1 is lost again. However, the delivery of the retransmission of P2 allows RACK to infer that the retransmission of P1 was likely lost (Event 7a); hence, P1 should be retransmitted (Event 7b). Note that <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> mandates a principle that loss in two successive windows of data or the loss of a retransmission must be taken as two indications of congestion and therefore results in two separate congestion control reactions.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
</div>
</section>
</div>
<div id="an-example-of-rack-tlp-in-action-rto">
<section id="section-3.5">
        <h3 id="name-an-example-of-rack-tlp-in-ac">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-an-example-of-rack-tlp-in-ac" class="section-name selfRef">An Example of RACK-TLP in Action: RTO</a>
        </h3>
<p id="section-3.5-1">In addition to enhancing fast recovery, RACK improves the accuracy of RTO recovery by reducing spurious retransmissions.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">Without RACK, upon RTO timer expiration, the sender marks all the unacknowledged segments as lost.  This approach can lead to spurious retransmissions.  For example, consider a simple case where one segment was sent with an RTO of 1 second and then the application writes more data, causing a second and third segment to be sent right before the RTO of the first segment expires.  Suppose none of the segments were lost.  Without RACK, if there is a spurious RTO, then the sender marks all three segments as lost and retransmits the first segment. If the ACK for the original copy of the first segment arrives right after the spurious RTO retransmission, then the sender continues slow start and spuriously retransmits the second and third segments since it (erroneously) presumed they are lost.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<p id="section-3.5-3">With RACK, upon RTO timer expiration, the only segment automatically marked as lost is the first segment (since it was sent an RTO ago); for all the other segments, RACK only marks the segment as lost if at least one round trip has elapsed since the segment was transmitted. Consider the previous example scenario, but this time with RACK.  With RACK, when the RTO expires, the sender only marks the first segment as lost and retransmits that segment.  The other two very recently sent segments are not marked as lost because they were sent less than one round trip ago and there were no ACKs providing evidence that they were lost. Upon receiving the ACK for the RTO retransmission, the RACK sender would not yet retransmit the second or third segment, but rather would re-arm the RTO timer and wait for a new RTO interval to elapse before marking the second or third segment as lost.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="design-summary">
<section id="section-3.6">
        <h3 id="name-design-summary">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-design-summary" class="section-name selfRef">Design Summary</a>
        </h3>
<p id="section-3.6-1">To summarize, RACK-TLP aims to adapt to small time-varying degrees of reordering, quickly recover most losses within one to two round trips, and avoid costly RTO recoveries. In the presence of reordering, the adaptation algorithm can impose sometimes needless delays when it waits to disambiguate loss from reordering, but the penalty for waiting is bounded to one round trip, and such delays are confined to flows long enough to have observed reordering.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="requirements">
<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">The reader is expected to be familiar with the definitions given in the TCP congestion control <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>, selective acknowledgment <span>[<a href="#RFC2018" class="xref">RFC2018</a>]</span>, and loss recovery <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span> RFCs. RACK-TLP has the following requirements:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4-2">
<li id="section-4-2.1">The connection <span class="bcp14">MUST</span> use selective acknowledgment (SACK) options <span>[<a href="#RFC2018" class="xref">RFC2018</a>]</span>, and the sender <span class="bcp14">MUST</span> keep SACK scoreboard information on a per-connection basis ("SACK scoreboard" has the same meaning here as in <span>[<a href="#RFC6675" class="xref">RFC6675</a>], <a href="https://www.rfc-editor.org/rfc/rfc6675#section-3" class="relref">Section 3</a></span>).<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">For each data segment sent, the sender <span class="bcp14">MUST</span> store its most recent transmission time with a timestamp whose granularity is finer than 1/4 of the minimum RTT of the connection. At the time of writing, microsecond resolution is suitable for intra-data center traffic, and millisecond granularity or finer is suitable for the Internet.

 Note that RACK-TLP can be implemented with TSO (TCP Segmentation Offload) support by having multiple segments in a TSO aggregate share the same timestamp.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">RACK DSACK-based reordering window adaptation is <span class="bcp14">RECOMMENDED</span> but is not required.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.4">TLP requires RACK.<a href="#section-4-2.4" class="pilcrow">¶</a>
</li>
      </ol>
</section>
</div>
<div id="definitions">
<section id="section-5">
      <h2 id="name-definitions">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-definitions" class="section-name selfRef">Definitions</a>
      </h2>
<p id="section-5-1">The reader is expected to be familiar with the variables SND.UNA, SND.NXT, SEG.ACK, and SEG.SEQ in <span>[<a href="#RFC0793" class="xref">RFC793</a>]</span>; Sender Maximum Segment Size (SMSS) and FlightSize in <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>; DupThresh in <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>; and RTO and SRTT in <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>. A RACK-TLP implementation uses several new terms and needs to store new per-segment and per-connection state, described below.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="terms">
<section id="section-5.1">
        <h3 id="name-terms">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-terms" class="section-name selfRef">Terms</a>
        </h3>
<p id="section-5.1-1">These terms are used to explain the variables and algorithms below:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.1-2">
          <dt id="section-5.1-2.1">RACK.segment</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.2">Among all the segments that have been either selectively or cumulatively acknowledged, the term "RACK.segment" denotes the segment that was sent most recently (including retransmissions).<a href="#section-5.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-2.3">RACK.ack_ts</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.4">Denotes the time when the full sequence range of RACK.segment was selectively or cumulatively acknowledged.<a href="#section-5.1-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="per-segment-variables">
<section id="section-5.2">
        <h3 id="name-per-segment-variables">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-per-segment-variables" class="section-name selfRef">Per-Segment Variables</a>
        </h3>
<p id="section-5.2-1">These variables indicate the status of the most recent transmission of a data segment:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.2-2">
          <dt id="section-5.2-2.1">Segment.lost</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-2.2">True if the most recent (re)transmission of the segment has been marked as lost and needs to be retransmitted. False otherwise.<a href="#section-5.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-2.3">Segment.retransmitted</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-2.4">True if the segment has ever been retransmitted. False otherwise.<a href="#section-5.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-2.5">Segment.xmit_ts</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-2.6">The time of the last transmission of a data segment, including retransmissions, if any, with a clock granularity specified in the <a href="#requirements" class="xref">"Requirements"</a> section. A maximum value INFINITE_TS indicates an invalid timestamp that represents that the segment is not currently in flight.<a href="#section-5.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-2.7">Segment.end_seq</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-2.8">The next sequence number after the last sequence number of the data segment.<a href="#section-5.2-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="per-connection-variables">
<section id="section-5.3">
        <h3 id="name-per-connection-variables">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-per-connection-variables" class="section-name selfRef">Per-Connection Variables</a>
        </h3>
<span class="break"></span><dl class="dlNewline" id="section-5.3-1">
          <dt id="section-5.3-1.1">RACK.xmit_ts</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.2">The latest transmission timestamp of RACK.segment.<a href="#section-5.3-1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.3">RACK.end_seq</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.4">The Segment.end_seq of RACK.segment.<a href="#section-5.3-1.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.5">RACK.segs_sacked</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.6">Returns the total number of segments selectively acknowledged in the SACK scoreboard.<a href="#section-5.3-1.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.7">RACK.fack</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.8">The highest selectively or cumulatively acknowledged sequence (i.e., forward acknowledgment).<a href="#section-5.3-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.9">RACK.min_RTT</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.10">The estimated minimum round-trip time (RTT) of the connection.<a href="#section-5.3-1.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.11">RACK.rtt</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.12">The RTT of the most recently delivered segment on the connection (either cumulatively acknowledged or selectively acknowledged) that was not marked as invalid as a possible spurious retransmission.<a href="#section-5.3-1.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.13">RACK.reordering_seen</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.14">Indicates whether the sender has detected data segment reordering event(s).<a href="#section-5.3-1.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.15">RACK.reo_wnd</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.16">A reordering window computed in the unit of time used for recording segment transmission times. It is used to defer the moment at which RACK marks a segment as lost.<a href="#section-5.3-1.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.17">RACK.dsack_round</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.18">Indicates if a DSACK option has been received in the latest round trip.<a href="#section-5.3-1.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.19">RACK.reo_wnd_mult</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.20">The multiplier applied to adjust RACK.reo_wnd.<a href="#section-5.3-1.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.21">RACK.reo_wnd_persist</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.22">The number of loss recoveries before resetting RACK.reo_wnd.<a href="#section-5.3-1.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.23">
         TLP.is_retrans</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.24">A boolean indicating whether there is an unacknowledged TLP retransmission.<a href="#section-5.3-1.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.25">TLP.end_seq</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.26">The value of SND.NXT at the time of sending a TLP probe.<a href="#section-5.3-1.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.27">
        TLP.max_ack_delay:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.28">The sender's budget for the maximum delayed ACK interval.<a href="#section-5.3-1.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="per-connection-timers">
<section id="section-5.4">
        <h3 id="name-per-connection-timers">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-per-connection-timers" class="section-name selfRef">Per-Connection Timers</a>
        </h3>
<span class="break"></span><dl class="dlNewline" id="section-5.4-1">
          <dt id="section-5.4-1.1">RACK reordering timer</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-1.2">A timer that allows RACK to wait for reordering to resolve in order to try to disambiguate reordering from loss when some segments are marked as SACKed.<a href="#section-5.4-1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-1.3">TLP PTO</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-1.4">A timer event indicating that an ACK is overdue and the sender should transmit a TLP segment to solicit SACK or ACK feedback.<a href="#section-5.4-1.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.4-2">These timers augment the existing timers maintained by a sender, including the RTO timer <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>. A RACK-TLP sender arms one of these three timers -- RACK reordering timer, TLP PTO timer, or RTO timer -- when it has unacknowledged segments in flight. The implementation can simplify managing all three timers by multiplexing a single timer among them with an additional variable to indicate the event to invoke upon the next timer expiration.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="rack-algorithm-details">
<section id="section-6">
      <h2 id="name-rack-algorithm-details">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-rack-algorithm-details" class="section-name selfRef">RACK Algorithm Details</a>
      </h2>
<div id="upon-transmitting-a-data-segment">
<section id="section-6.1">
        <h3 id="name-upon-transmitting-a-data-se">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-upon-transmitting-a-data-se" class="section-name selfRef">Upon Transmitting a Data Segment</a>
        </h3>
<p id="section-6.1-1">Upon transmitting a new segment or retransmitting an old segment, record the time in Segment.xmit_ts and set Segment.lost to FALSE. Upon retransmitting a segment, set Segment.retransmitted to TRUE.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<div id="section-6.1-2">
<pre class="sourcecode lang-pseudocode">
RACK_transmit_new_data(Segment):
        Segment.xmit_ts = Now()
        Segment.lost = FALSE

RACK_retransmit_data(Segment):
        Segment.retransmitted = TRUE
        Segment.xmit_ts = Now()
        Segment.lost = FALSE
</pre><a href="#section-6.1-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="upon-receiving-an-ack">
<section id="section-6.2">
        <h3 id="name-upon-receiving-an-ack">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-upon-receiving-an-ack" class="section-name selfRef">Upon Receiving an ACK</a>
        </h3>
<div id="step1">
<p id="section-6.2-1">Step 1: Update RACK.min_RTT.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
</div>
<p id="section-6.2-2">Use the RTT measurements obtained via <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span> or <span>[<a href="#RFC7323" class="xref">RFC7323</a>]</span> to update the estimated minimum RTT in RACK.min_RTT. The sender <span class="bcp14">SHOULD</span> track a windowed min-filtered estimate of recent RTT measurements that can adapt when migrating to significantly longer paths rather than tracking a simple global minimum of all RTT measurements.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
<div id="step2">
<p id="section-6.2-3">
Step 2: Update the state for the most recently sent segment that has been delivered.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
</div>
<p id="section-6.2-4">In this step, RACK updates the state that tracks the most recently sent segment that has been delivered: RACK.segment. RACK maintains its latest transmission timestamp in RACK.xmit_ts and its highest sequence number in RACK.end_seq. These two variables are used in later steps to estimate if some segments not yet delivered were likely lost.

Given the information provided in an ACK, each segment cumulatively ACKed or SACKed is marked as delivered in the scoreboard. Because an ACK can also acknowledge retransmitted data segments and because retransmissions can be spurious, the sender needs to take care to avoid spurious inferences. For example, if the sender were to use timing information from a spurious retransmission, the RACK.rtt could be vastly underestimated.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
<p id="section-6.2-5">To avoid spurious inferences, ignore a segment as invalid if any of its sequence range has been retransmitted before and if either of two conditions is true:<a href="#section-6.2-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.2-6">
<li id="section-6.2-6.1">The Timestamp Echo Reply field (TSecr) of the ACK's timestamp option <span>[<a href="#RFC7323" class="xref">RFC7323</a>]</span>, if available, indicates the ACK was not acknowledging the last retransmission of the segment.<a href="#section-6.2-6.1" class="pilcrow">¶</a>
</li>
          <li id="section-6.2-6.2">The segment was last retransmitted less than RACK.min_rtt ago.<a href="#section-6.2-6.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-6.2-7">
The second check is a heuristic when the TCP Timestamp option is not available or when the round-trip time is less than the TCP Timestamp clock granularity.<a href="#section-6.2-7" class="pilcrow">¶</a></p>
<p id="section-6.2-8">Among all the segments newly ACKed or SACKed by this ACK that pass the checks above, update the RACK.rtt to be the RTT sample calculated using this ACK. Furthermore, record the most recent Segment.xmit_ts in RACK.xmit_ts if it is ahead of RACK.xmit_ts. If Segment.xmit_ts equals RACK.xmit_ts (e.g., due to clock granularity limits), then compare Segment.end_seq and RACK.end_seq to break the tie when deciding whether to update the RACK.segment's associated state.<a href="#section-6.2-8" class="pilcrow">¶</a></p>
<p id="section-6.2-9">Step 2 may be summarized in pseudocode as:<a href="#section-6.2-9" class="pilcrow">¶</a></p>
<div id="section-6.2-10">
<pre class="sourcecode lang-pseudocode">
RACK_sent_after(t1, seq1, t2, seq2):
    If t1 &gt; t2:
        Return true
    Else if t1 == t2 AND seq1 &gt; seq2:
        Return true
    Else:
        Return false

RACK_update():
    For each Segment newly acknowledged, cumulatively or selectively,
    in ascending order of Segment.xmit_ts:
        rtt = Now() - Segment.xmit_ts
        If Segment.retransmitted is TRUE:
            If ACK.ts_option.echo_reply &lt; Segment.xmit_ts:
               Continue
            If rtt &lt; RACK.min_rtt:
               Continue

        RACK.rtt = rtt
        If RACK_sent_after(Segment.xmit_ts, Segment.end_seq
                           RACK.xmit_ts, RACK.end_seq):
            RACK.xmit_ts = Segment.xmit_ts
            RACK.end_seq = Segment.end_seq

</pre><a href="#section-6.2-10" class="pilcrow">¶</a>
</div>
<div id="step3">
<p id="section-6.2-11">Step 3: Detect data segment reordering.<a href="#section-6.2-11" class="pilcrow">¶</a></p>
</div>
<p id="section-6.2-12">To detect reordering, the sender looks for original data segments being delivered out of order. To detect such cases, the sender tracks the highest sequence selectively or cumulatively acknowledged in the RACK.fack variable. ".fack" stands for the most "Forward ACK" (this term is adopted from <span>[<a href="#FACK" class="xref">FACK</a>]</span>). If a never-retransmitted segment that's below RACK.fack is (selectively or cumulatively) acknowledged, it has been delivered out of order. The sender sets RACK.reordering_seen to TRUE if such a segment is identified.<a href="#section-6.2-12" class="pilcrow">¶</a></p>
<div id="section-6.2-13">
<pre class="sourcecode lang-pseudocode">
RACK_detect_reordering():
    For each Segment newly acknowledged, cumulatively or selectively,
    in ascending order of Segment.end_seq:
        If Segment.end_seq &gt; RACK.fack:
            RACK.fack = Segment.end_seq
        Else if Segment.end_seq &lt; RACK.fack AND
                Segment.retransmitted is FALSE:
            RACK.reordering_seen = TRUE
</pre><a href="#section-6.2-13" class="pilcrow">¶</a>
</div>
<div id="step4">
<p id="section-6.2-14">Step 4: Update the RACK reordering window.<a href="#section-6.2-14" class="pilcrow">¶</a></p>
</div>
<p id="section-6.2-15">The RACK reordering window, RACK.reo_wnd, serves as an adaptive allowance for settling time before marking a segment as lost. This step documents a detailed algorithm that follows the principles outlined in the <a href="#reordering-window-adaptation" class="xref">"Reordering Window Adaptation"</a> section.<a href="#section-6.2-15" class="pilcrow">¶</a></p>
<p id="section-6.2-16">If no reordering has been observed based on the <a href="#step3" class="xref">previous step</a>, then one way the sender can enter fast recovery is when the number of SACKed segments matches or exceeds DupThresh (similar to <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>). Furthermore, when no reordering has been observed, the RACK.reo_wnd is set to 0 both upon entering and during fast recovery or RTO recovery.<a href="#section-6.2-16" class="pilcrow">¶</a></p>
<p id="section-6.2-17">Otherwise, if some reordering has been observed, then RACK does not trigger fast recovery based on DupThresh.<a href="#section-6.2-17" class="pilcrow">¶</a></p>
<p id="section-6.2-18">Whether or not reordering has been observed, RACK uses the reordering window to assess whether any segments can be marked as lost. As a consequence, the sender also enters fast recovery when there are any number of SACKed segments, as long as the reorder window has passed for some non-SACKed segments.<a href="#section-6.2-18" class="pilcrow">¶</a></p>
<p id="section-6.2-19">When the reordering window is not set to 0, it starts with a conservative RACK.reo_wnd of RACK.min_RTT/4. This value was chosen because Linux TCP used the same factor in its implementation to delay Early Retransmit <span>[<a href="#RFC5827" class="xref">RFC5827</a>]</span> to reduce spurious loss detections in the presence of reordering, and experience showed this worked reasonably well <span>[<a href="#DMCG11" class="xref">DMCG11</a>]</span>.<a href="#section-6.2-19" class="pilcrow">¶</a></p>
<p id="section-6.2-20">However, the reordering detection in the previous step, <a href="#step3" class="xref">Step 3</a>, has a self-reinforcing drawback when the reordering window is too small to cope with the actual reordering. When that happens, RACK could spuriously mark reordered segments as lost, causing them to be retransmitted. In turn, the retransmissions can prevent the necessary conditions for <a href="#step3" class="xref">Step 3</a> to detect reordering since this mechanism requires ACKs or SACKs only for segments that have never been retransmitted. In some cases, such scenarios can persist, causing RACK to continue to spuriously mark segments as lost without realizing the reordering window is too small.<a href="#section-6.2-20" class="pilcrow">¶</a></p>
<p id="section-6.2-21">To avoid the issue above, RACK dynamically adapts to higher degrees of reordering using DSACK options from the receiver. Receiving an ACK with a DSACK option indicates a possible spurious retransmission, suggesting that RACK.reo_wnd may be too small. The RACK.reo_wnd increases linearly for every round trip in which the sender receives some DSACK option so that after N round trips in which a DSACK is received, the RACK.reo_wnd becomes (N+1) * min_RTT / 4, with an upper-bound of SRTT.<a href="#section-6.2-21" class="pilcrow">¶</a></p>
<p id="section-6.2-22">If the reordering is temporary, then a large adapted reordering window would unnecessarily delay loss recovery later. Therefore, RACK persists using the inflated RACK.reo_wnd for up to 16 loss recoveries, after which it resets RACK.reo_wnd to its starting value, min_RTT / 4. The downside of resetting the reordering window is the risk of triggering spurious fast recovery episodes if the reordering remains high. The rationale for this approach is to bound such spurious recoveries to approximately once every 16 recoveries (less than 7%).<a href="#section-6.2-22" class="pilcrow">¶</a></p>
<p id="section-6.2-23">To track the linear scaling factor for the adaptive reordering window, RACK uses the variable RACK.reo_wnd_mult, which is initialized to 1 and adapts with the observed reordering.<a href="#section-6.2-23" class="pilcrow">¶</a></p>
<p id="section-6.2-24">The following pseudocode implements the above algorithm for updating the RACK reordering window:<a href="#section-6.2-24" class="pilcrow">¶</a></p>
<div id="step4alg">
<div id="section-6.2-25">
<pre class="sourcecode lang-pseudocode">
RACK_update_reo_wnd():

    /* DSACK-based reordering window adaptation */
    If RACK.dsack_round is not None AND
       SND.UNA &gt;= RACK.dsack_round:
        RACK.dsack_round = None
    /* Grow the reordering window per round that sees DSACK.
       Reset the window after 16 DSACK-free recoveries */
    If RACK.dsack_round is None AND
       any DSACK option is present on latest received ACK:
        RACK.dsack_round = SND.NXT
        RACK.reo_wnd_mult += 1
        RACK.reo_wnd_persist = 16
    Else if exiting Fast or RTO recovery:
        RACK.reo_wnd_persist -= 1
        If RACK.reo_wnd_persist &lt;= 0:
            RACK.reo_wnd_mult = 1

    If RACK.reordering_seen is FALSE:
        If in Fast or RTO recovery:
            Return 0
        Else if RACK.segs_sacked &gt;= DupThresh:
            Return 0
    Return min(RACK.reo_wnd_mult * RACK.min_RTT / 4, SRTT)
</pre><a href="#section-6.2-25" class="pilcrow">¶</a>
</div>
</div>
<div id="step5">
<p id="section-6.2-26">Step 5: Detect losses.<a href="#section-6.2-26" class="pilcrow">¶</a></p>
</div>
<p id="section-6.2-27">For each segment that has not been SACKed, RACK considers that segment lost if another segment that was sent later has been delivered and the reordering window has passed. RACK considers the reordering window to have passed if the RACK.segment was sent a sufficient time after the segment in question, if a sufficient time has elapsed since the RACK.segment was S/ACKed, or some combination of the two. More precisely, RACK marks a segment as lost if:<a href="#section-6.2-27" class="pilcrow">¶</a></p>
<div id="section-6.2-28">
<pre class="sourcecode lang-pseudocode">
 RACK.xmit_ts &gt;= Segment.xmit_ts
        AND
 RACK.xmit_ts - Segment.xmit_ts + (now - RACK.ack_ts) &gt;= RACK.reo_wnd
</pre><a href="#section-6.2-28" class="pilcrow">¶</a>
</div>
<p id="section-6.2-29">Solving this second condition for "now", the moment at which a segment is marked as lost, yields:<a href="#section-6.2-29" class="pilcrow">¶</a></p>
<div id="section-6.2-30">
<pre class="sourcecode lang-pseudocode">
now &gt;= Segment.xmit_ts + RACK.reo_wnd + (RACK.ack_ts - RACK.xmit_ts)
</pre><a href="#section-6.2-30" class="pilcrow">¶</a>
</div>
<p id="section-6.2-31">Then (RACK.ack_ts - RACK.xmit_ts) is the round-trip time of the most recently (re)transmitted segment that's been delivered. When segments are delivered in order, the most recently (re)transmitted segment that's been delivered is also the most recently delivered; hence, RACK.rtt == RACK.ack_ts - RACK.xmit_ts. But if segments were reordered, then the segment delivered most recently was sent before the most recently (re)transmitted segment. Hence, RACK.rtt &gt; (RACK.ack_ts - RACK.xmit_ts).<a href="#section-6.2-31" class="pilcrow">¶</a></p>
<p id="section-6.2-32">Since RACK.RTT &gt;= (RACK.ack_ts - RACK.xmit_ts), the previous equation reduces to saying that the sender can declare a segment lost when:<a href="#section-6.2-32" class="pilcrow">¶</a></p>
<div id="section-6.2-33">
<pre class="sourcecode lang-pseudocode">
now &gt;= Segment.xmit_ts + RACK.reo_wnd + RACK.rtt
</pre><a href="#section-6.2-33" class="pilcrow">¶</a>
</div>
<p id="section-6.2-34">In turn, that is equivalent to stating that a RACK sender should declare a segment lost when:<a href="#section-6.2-34" class="pilcrow">¶</a></p>
<div id="section-6.2-35">
<pre class="sourcecode lang-pseudocode">
Segment.xmit_ts + RACK.rtt + RACK.reo_wnd - now &lt;= 0
</pre><a href="#section-6.2-35" class="pilcrow">¶</a>
</div>
<p id="section-6.2-36">Note that if the value on the left-hand side is positive, it represents the remaining wait time before the segment is deemed lost. But this risks a timeout (RTO) if no more ACKs come back (e.g., due to losses or application-limited transmissions) to trigger the marking. For timely loss detection, it is <span class="bcp14">RECOMMENDED</span> that the sender install a reordering timer. This timer expires at the earliest moment when RACK would conclude that all the unacknowledged segments within the reordering window were lost.<a href="#section-6.2-36" class="pilcrow">¶</a></p>
<p id="section-6.2-37">The following pseudocode implements the algorithm above. When an ACK is received or the RACK reordering timer expires, call RACK_detect_loss_and_arm_timer(). The algorithm breaks timestamp ties by using the TCP sequence space since high-speed networks often have multiple segments with identical timestamps.<a href="#section-6.2-37" class="pilcrow">¶</a></p>
<div id="section-6.2-38">
<pre class="sourcecode lang-pseudocode">
RACK_detect_loss():
    timeout = 0
    RACK.reo_wnd = RACK_update_reo_wnd()
    For each segment, Segment, not acknowledged yet:
        If RACK_sent_after(RACK.xmit_ts, RACK.end_seq,
                           Segment.xmit_ts, Segment.end_seq):
            remaining = Segment.xmit_ts + RACK.rtt +
                        RACK.reo_wnd - Now()
            If remaining &lt;= 0:
                Segment.lost = TRUE
                Segment.xmit_ts = INFINITE_TS
            Else:
                timeout = max(remaining, timeout)
    Return timeout

RACK_detect_loss_and_arm_timer():
    timeout = RACK_detect_loss()
    If timeout != 0
        Arm the RACK timer to call
        RACK_detect_loss_and_arm_timer() after timeout
</pre><a href="#section-6.2-38" class="pilcrow">¶</a>
</div>
<p id="section-6.2-39">As an optimization, an implementation can choose to check only segments that have been sent before RACK.xmit_ts. This can be more efficient than scanning the entire SACK scoreboard, especially when there are many segments in flight. The implementation can use a separate doubly linked list ordered by Segment.xmit_ts, insert a segment at the tail of the list when it is (re)transmitted, and remove a segment from the list when it is delivered or marked as lost. In Linux TCP, this optimization improved CPU usage by orders of magnitude during some fast recovery episodes on high-speed WAN networks.<a href="#section-6.2-39" class="pilcrow">¶</a></p>
</section>
</div>
<div id="upon-rto-expiration">
<section id="section-6.3">
        <h3 id="name-upon-rto-expiration">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-upon-rto-expiration" class="section-name selfRef">Upon RTO Expiration</a>
        </h3>
<p id="section-6.3-1">Upon RTO timer expiration, RACK marks the first outstanding segment as lost (since it was sent an RTO ago); for all the other segments, RACK only marks the segment as lost if the time elapsed since the segment was transmitted is at least the sum of the recent RTT and the reordering window.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<div id="section-6.3-2">
<pre class="sourcecode lang-pseudocode">
RACK_mark_losses_on_RTO():
    For each segment, Segment, not acknowledged yet:
        If SEG.SEQ == SND.UNA OR
           Segment.xmit_ts + RACK.rtt + RACK.reo_wnd - Now() &lt;= 0:
            Segment.lost = TRUE
</pre><a href="#section-6.3-2" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="tlp-algorithm-details">
<section id="section-7">
      <h2 id="name-tlp-algorithm-details">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-tlp-algorithm-details" class="section-name selfRef">TLP Algorithm Details</a>
      </h2>
<div id="initializing-state">
<section id="section-7.1">
        <h3 id="name-initializing-state">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-initializing-state" class="section-name selfRef">Initializing State</a>
        </h3>
<p id="section-7.1-1">Reset TLP.is_retrans and TLP.end_seq when initiating a connection, fast recovery, or RTO recovery.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<div id="section-7.1-2">
<pre class="sourcecode lang-pseudocode">
TLP_init():
    TLP.end_seq = None
    TLP.is_retrans = false
</pre><a href="#section-7.1-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="scheduling-a-loss-probe">
<section id="section-7.2">
        <h3 id="name-scheduling-a-loss-probe">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-scheduling-a-loss-probe" class="section-name selfRef">Scheduling a Loss Probe</a>
        </h3>
<p id="section-7.2-1">
The sender schedules a loss probe timeout (PTO) to transmit a segment during the normal transmission process. The sender <span class="bcp14">SHOULD</span> start or restart a loss probe PTO timer after transmitting new data (that was not itself a loss probe) or upon receiving an ACK that cumulatively acknowledges new data unless it is already in fast recovery, RTO recovery, or segments have been SACKed (i.e., RACK.segs_sacked is not zero). These conditions are excluded because they are addressed by similar mechanisms, like Limited Transmit <span>[<a href="#RFC3042" class="xref">RFC3042</a>]</span>, the RACK reordering timer, and Forward RTO-Recovery (F-RTO) <span>[<a href="#RFC5682" class="xref">RFC5682</a>]</span>.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">The sender calculates the PTO interval by taking into account a number of factors.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">First, the default PTO interval is 2*SRTT. By that time, it is prudent to declare that an ACK is overdue since under normal circumstances, i.e., no losses, an ACK typically arrives in one SRTT.  Choosing the PTO to be exactly an SRTT would risk causing spurious probes given that network and end-host delay variance can cause an ACK to be delayed beyond the SRTT. Hence, the PTO is conservatively chosen to be the next integral multiple of SRTT.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p id="section-7.2-4">Second, when there is no SRTT estimate available, the PTO <span class="bcp14">SHOULD</span> be 1 second. This conservative value corresponds to the RTO value when no SRTT is available, per <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<p id="section-7.2-5">Third, when the FlightSize is one segment, the sender <span class="bcp14">MAY</span> inflate the PTO by TLP.max_ack_delay to accommodate a potentially delayed acknowledgment and reduce the risk of spurious retransmissions. The actual value of TLP.max_ack_delay is implementation specific.<a href="#section-7.2-5" class="pilcrow">¶</a></p>
<p id="section-7.2-6">Finally, if the time at which an RTO would fire (here denoted as "TCP_RTO_expiration()") is sooner than the computed time for the PTO, then the sender schedules a TLP to be sent at that RTO time.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
<p id="section-7.2-7">Summarizing these considerations in pseudocode form, a sender <span class="bcp14">SHOULD</span> use the following logic to select the duration of a PTO:<a href="#section-7.2-7" class="pilcrow">¶</a></p>
<div id="section-7.2-8">
<pre class="sourcecode lang-pseudocode">
TLP_calc_PTO():
    If SRTT is available:
        PTO = 2 * SRTT
        If FlightSize is one segment:
           PTO += TLP.max_ack_delay
    Else:
        PTO = 1 sec

    If Now() + PTO &gt; TCP_RTO_expiration():
        PTO = TCP_RTO_expiration() - Now()
</pre><a href="#section-7.2-8" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="sending-a-loss-probe-upon-pto-expiration">
<section id="section-7.3">
        <h3 id="name-sending-a-loss-probe-upon-p">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-sending-a-loss-probe-upon-p" class="section-name selfRef">Sending a Loss Probe upon PTO Expiration</a>
        </h3>
<p id="section-7.3-1">
When the PTO timer expires, the sender <span class="bcp14">MUST</span> check whether both of the following conditions are met before sending a loss probe:<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7.3-2">
<li id="section-7.3-2.1">First, there is no other previous loss probe still in flight. This ensures that, at any given time, the sender has at most one additional packet in flight beyond the congestion window limit. This invariant is maintained using the state variable TLP.end_seq, which indicates the latest unacknowledged TLP loss probe's ending sequence. It is reset when the loss probe has been acknowledged or is deemed lost or irrelevant.<a href="#section-7.3-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-7.3-2.2">Second, the sender has obtained an RTT measurement since the last loss probe transmission or the start of the connection, whichever was later. This condition ensures that loss probe retransmissions do not prevent taking the RTT samples necessary to adapt SRTT to an increase in path RTT.<a href="#section-7.3-2.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-7.3-3">If either one of these two conditions is not met, then the sender <span class="bcp14">MUST</span> skip sending a loss probe and <span class="bcp14">MUST</span> proceed to re-arm the RTO timer, as specified at the end of this section.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<p id="section-7.3-4">If both conditions are met, then the sender <span class="bcp14">SHOULD</span> transmit a previously unsent data segment, if one exists and the receive window allows, and increment the FlightSize accordingly. Note that the FlightSize could be one packet greater than the congestion window temporarily until the next ACK arrives.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
<p id="section-7.3-5">If such an unsent segment is not available, then the sender <span class="bcp14">SHOULD</span> retransmit the highest-sequence segment sent so far and set TLP.is_retrans to true. This segment is chosen to deal with the retransmission ambiguity problem in TCP. Suppose a sender sends N segments and then retransmits the last segment (segment N) as a loss probe, after which the sender receives a SACK for segment N. As long as the sender waits for the RACK reordering window to expire, it doesn't matter if that SACK was for the original transmission of segment N or the TLP retransmission; in either case, the arrival of the SACK for segment N provides evidence that the N-1 segments preceding segment N were likely lost.<a href="#section-7.3-5" class="pilcrow">¶</a></p>
<p id="section-7.3-6">In a case where there is only one original outstanding segment of data (N=1), the same logic (trivially) applies: an ACK for a single outstanding segment tells the sender that the N-1=0 segments preceding that segment were lost. Furthermore, whether there are N&gt;1 or N=1 outstanding segments, there is a question about whether the original last segment or its TLP retransmission were lost; the sender estimates whether there was such a loss using TLP recovery detection (see below).<a href="#section-7.3-6" class="pilcrow">¶</a></p>
<p id="section-7.3-7">The sender <span class="bcp14">MUST</span> follow the RACK transmission procedures in the <a href="#upon-transmitting-a-data-segment" class="xref">"Upon Transmitting a Data Segment"</a> section upon sending either a retransmission or a new data loss probe. This is critical for detecting losses using the ACK for the loss probe.<a href="#section-7.3-7" class="pilcrow">¶</a></p>
<p id="section-7.3-8">
After attempting to send a loss probe, regardless of whether a loss probe was sent, the sender <span class="bcp14">MUST</span> re-arm the RTO timer, not the PTO timer, if the FlightSize is not zero. This ensures RTO recovery remains the last resort if TLP fails. The following pseudocode summarizes the operations.<a href="#section-7.3-8" class="pilcrow">¶</a></p>
<div id="section-7.3-9">
<pre class="sourcecode lang-pseudocode">
TLP_send_probe():

    If TLP.end_seq is None and
       Sender has taken a new RTT sample since last probe or
       the start of connection:
        TLP.is_retrans = false
        Segment = send buffer segment starting at SND.NXT
        If Segment exists and fits the peer receive window limit:
           /* Transmit the lowest-sequence unsent Segment */
           Transmit Segment
           RACK_transmit_data(Segment)
           TLP.end_seq = SND.NXT
           Increase FlightSize by Segment length
        Else:
           /* Retransmit the highest-sequence Segment sent */
           Segment = send buffer segment ending at SND.NXT
           Transmit Segment
           RACK_retransmit_data(Segment)
           TLP.end_seq = SND.NXT
           TLP.is_retrans = true

    If FlightSize is not zero:
        Rearm RTO timer to fire at timeout = now + RTO
</pre><a href="#section-7.3-9" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="detecting-losses-using-the-ack-of-the-loss-probe">
<section id="section-7.4">
        <h3 id="name-detecting-losses-using-the-">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-detecting-losses-using-the-" class="section-name selfRef">Detecting Losses Using the ACK of the Loss Probe</a>
        </h3>
<p id="section-7.4-1">When there is packet loss in a flight ending with a loss probe, the feedback solicited by a loss probe will reveal one of two scenarios, depending on the pattern of losses.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<div id="general-case-detecting-packet-losses-using-rack-">
<section id="section-7.4.1">
          <h4 id="name-general-case-detecting-pack">
<a href="#section-7.4.1" class="section-number selfRef">7.4.1. </a><a href="#name-general-case-detecting-pack" class="section-name selfRef">General Case: Detecting Packet Losses Using RACK</a>
          </h4>
<p id="section-7.4.1-1">If the loss probe and the ACK that acknowledges the probe are delivered successfully, RACK-TLP uses this ACK -- just as it would with any other ACK -- to detect if any segments sent prior to the probe were dropped. RACK would typically infer that any unacknowledged data segments sent before the loss probe were lost, since they were sent sufficiently far in the past (where at least one PTO has elapsed, plus one round trip for the loss probe to be ACKed). More specifically, RACK_detect_loss() (<a href="#step5" class="xref">Step 5</a>) would mark those earlier segments as lost. Then the sender would trigger a fast recovery to recover those losses.<a href="#section-7.4.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="special-case-detecting-a-single-loss-repaired-by-the-loss-probe">
<section id="section-7.4.2">
          <h4 id="name-special-case-detecting-a-si">
<a href="#section-7.4.2" class="section-number selfRef">7.4.2. </a><a href="#name-special-case-detecting-a-si" class="section-name selfRef">Special Case: Detecting a Single Loss Repaired by the Loss Probe</a>
          </h4>
<p id="section-7.4.2-1">If the TLP retransmission repairs all the lost in-flight sequence ranges (i.e., only the last segment in the flight was lost), the ACK for the loss probe appears to be a regular cumulative ACK, which would not normally trigger the congestion control response to this packet loss event. The following TLP recovery detection mechanism examines ACKs to detect this special case to make congestion control respond properly <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>.<a href="#section-7.4.2-1" class="pilcrow">¶</a></p>
<p id="section-7.4.2-2">After a TLP retransmission, the sender checks for this special case of a single loss that is recovered by the loss probe itself. To accomplish this, the sender checks for a duplicate ACK or DSACK indicating that both the original segment and TLP retransmission arrived at the receiver, which means there was no loss. If the TLP sender does not receive such an indication, then it <span class="bcp14">MUST</span> assume that the original data segment, the TLP retransmission, or a corresponding ACK was lost for congestion control purposes.<a href="#section-7.4.2-2" class="pilcrow">¶</a></p>
<p id="section-7.4.2-3">
If the TLP retransmission is spurious, a receiver that uses DSACK would return an ACK that covers TLP.end_seq with a DSACK option (Case 1). If the receiver does not support DSACK, it would return a DupAck without any SACK option (Case 2). If the sender receives an ACK matching either case, then the sender estimates that the receiver received both the original data segment and the TLP probe retransmission. The sender considers the TLP episode to be done and records that fact by setting TLP.end_seq to None.<a href="#section-7.4.2-3" class="pilcrow">¶</a></p>
<p id="section-7.4.2-4">Upon receiving an ACK that covers some sequence number after TLP.end_seq, the sender should have received any ACKs for the original segment and TLP probe retransmission segment. At that time, if the TLP.end_seq is still set and thus indicates that the TLP probe retransmission remains unacknowledged, then the sender should presume that at least one of its data segments was lost. The sender then <span class="bcp14">SHOULD</span> invoke a congestion control response equivalent to a fast recovery.<a href="#section-7.4.2-4" class="pilcrow">¶</a></p>
<p id="section-7.4.2-5">More precisely, on each ACK, the sender executes the following:<a href="#section-7.4.2-5" class="pilcrow">¶</a></p>
<div id="section-7.4.2-6">
<pre class="sourcecode lang-pseudocode">
TLP_process_ack(ACK):
    If TLP.end_seq is not None AND ACK's ack. number &gt;= TLP.end_seq:
        If not TLP.is_retrans:
            TLP.end_seq = None    /* TLP of new data delivered */
        Else if ACK has a DSACK option matching TLP.end_seq:
            TLP.end_seq = None    /* Case 1, above */
        Else If ACK's ack. number &gt; TLP.end_seq:
            TLP.end_seq = None    /* Repaired the single loss */
            (Invoke congestion control to react to
             the loss event the probe has repaired)
        Else If ACK is a DupAck without any SACK option:
            TLP.end_seq = None     /* Case 2, above */
</pre><a href="#section-7.4.2-6" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="managing-rack-tlp-timers">
<section id="section-8">
      <h2 id="name-managing-rack-tlp-timers">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-managing-rack-tlp-timers" class="section-name selfRef">Managing RACK-TLP Timers</a>
      </h2>
<p id="section-8-1">The RACK reordering timer, the TLP PTO timer, the RTO, and Zero Window Probe (ZWP) timer <span>[<a href="#RFC0793" class="xref">RFC793</a>]</span> are mutually exclusive and are used in different scenarios. When arming a RACK reordering timer or TLP PTO timer, the sender <span class="bcp14">SHOULD</span> cancel any other pending timers. An implementation is expected to have one timer with an additional state variable indicating the type of the timer.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="discussion">
<section id="section-9">
      <h2 id="name-discussion">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-discussion" class="section-name selfRef">Discussion</a>
      </h2>
<div id="advantages-and-disadvantages">
<section id="section-9.1">
        <h3 id="name-advantages-and-disadvantage">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-advantages-and-disadvantage" class="section-name selfRef">Advantages and Disadvantages</a>
        </h3>
<p id="section-9.1-1">The biggest advantage of RACK-TLP is that every data segment, whether it is an original data transmission or a retransmission, can be used to detect losses of the segments sent chronologically prior to it. This enables RACK-TLP to use fast recovery in cases with application-limited flights of data, lost retransmissions, or data segment reordering events. Consider the following examples:<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-9.1-2">
<li id="section-9.1-2.1">Packet drops at the end of an application data flight: Consider a sender that transmits an application-limited flight of three data segments (P1, P2, P3), and P1 and P3 are lost. Suppose the transmission of each segment is at least RACK.reo_wnd after the transmission of the previous segment. RACK will mark P1 as lost when the SACK of P2 is received, and this will trigger the retransmission of P1 as R1. When R1 is cumulatively acknowledged, RACK will mark P3 as lost, and the sender will retransmit P3 as R3. This example illustrates how RACK is able to repair certain drops at the tail of a transaction without an RTO recovery. Notice that neither the conventional duplicate ACK threshold <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>, nor the loss recovery algorithm <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>, nor the Forward Acknowledgment <span>[<a href="#FACK" class="xref">FACK</a>]</span> algorithm can detect such losses because of the required segment or sequence count.<a href="#section-9.1-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-9.1-2.2">Lost retransmission: Consider a flight of three data segments (P1, P2, P3) that are sent; P1 and P2 are dropped. Suppose the transmission of each segment is at least RACK.reo_wnd after the transmission of the previous segment. When P3 is SACKed, RACK will mark P1 and P2 as lost, and they will be retransmitted as R1 and R2. Suppose R1 is lost again but R2 is SACKed; RACK will mark R1 as lost and trigger retransmission again.  Again, neither the conventional three-duplicate ACK threshold approach, nor the loss recovery algorithm <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>, nor the Forward Acknowledgment <span>[<a href="#FACK" class="xref">FACK</a>]</span> algorithm can detect such losses. And such a lost retransmission can happen when TCP is being rate-limited, particularly by token bucket policers with a large bucket depth and low rate limit; in such cases, retransmissions are often lost repeatedly because standard congestion control requires multiple round trips to reduce the rate below the policed rate.<a href="#section-9.1-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-9.1-2.3">Packet reordering:  Consider a simple reordering event where a flight of segments are sent as (P1, P2, P3). P1 and P2 carry a full payload of Maximum Sender Size (MSS) octets, but P3 has only a 1-octet payload. Suppose the sender has detected reordering previously and thus RACK.reo_wnd is min_RTT/4. Now P3 is reordered and delivered first, before P1 and P2. As long as P1 and P2 are delivered within min_RTT/4, RACK will not consider P1 and P2 lost. But if P1 and P2 are delivered outside the reordering window, then RACK will still spuriously mark P1 and P2 as lost.<a href="#section-9.1-2.3" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-9.1-3">The examples above show that RACK-TLP is particularly useful when the sender is limited by the application, which can happen with interactive or request/response traffic. Similarly, RACK still works when the sender is limited by the receive window, which can happen with applications that use the receive window to throttle the sender.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
<p id="section-9.1-4">RACK-TLP works more efficiently with TCP Segmentation Offload (TSO) compared to DupAck counting. RACK always marks the entire TSO aggregate as lost because the segments in the same TSO aggregate have the same transmission timestamp. By contrast, the algorithms based on sequence counting (e.g., <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>, <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>) may mark only a subset of segments in the TSO aggregate as lost, forcing the stack to perform expensive fragmentation of the TSO aggregate or to selectively tag individual segments as lost in the scoreboard.<a href="#section-9.1-4" class="pilcrow">¶</a></p>
<p id="section-9.1-5">The main drawback of RACK-TLP is the additional state required compared to DupAck counting. RACK requires the sender to record the transmission time of each segment sent at a clock granularity that is finer than 1/4 of the minimum RTT of the connection. TCP implementations that already record this for RTT estimation do not require any new per-packet state. But implementations that are not yet recording segment transmission times will need to add per-packet internal state (expected to be either 4 or 8 octets per segment or TSO aggregate) to track transmission times. In contrast, the loss detection approach described in <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span> does not require any per-packet state beyond the SACK scoreboard; this is particularly useful on ultra-low RTT networks where the RTT may be less than the sender TCP clock granularity (e.g., inside data centers). Another disadvantage is that the reordering timer may expire prematurely (like any other retransmission timer) and cause higher spurious retransmissions, especially if DSACK is not supported.<a href="#section-9.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="relationships-with-other-loss-recovery-algorithms">
<section id="section-9.2">
        <h3 id="name-relationships-with-other-lo">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-relationships-with-other-lo" class="section-name selfRef">Relationships with Other Loss Recovery Algorithms</a>
        </h3>
<p id="section-9.2-1">The primary motivation of RACK-TLP is to provide a general alternative to some of the standard loss recovery algorithms <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span> <span>[<a href="#RFC5827" class="xref">RFC5827</a>]</span> <span>[<a href="#RFC4653" class="xref">RFC4653</a>]</span>. In particular, the SACK loss recovery algorithm for TCP <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span> is not designed to handle lost retransmissions, so its NextSeg() does not work for lost retransmissions, and it does not specify the corresponding required additional congestion response. Therefore, the algorithm <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span> <span class="bcp14">MUST NOT</span> be used with RACK-TLP; instead, a modified recovery algorithm that carefully addresses such a case is needed.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<p id="section-9.2-2">The Early Retransmit mechanism <span>[<a href="#RFC5827" class="xref">RFC5827</a>]</span> and NCR for TCP <span>[<a href="#RFC4653" class="xref">RFC4653</a>]</span> dynamically adjust the duplicate ACK threshold based on the current or previous flight sizes. RACK-TLP takes a different approach by using a time-based reordering window. RACK-TLP can be seen as an extended Early Retransmit <span>[<a href="#RFC5827" class="xref">RFC5827</a>]</span> without a FlightSize limit but with an additional reordering window. <span>[<a href="#FACK" class="xref">FACK</a>]</span> considers an original segment to be lost when its sequence range is sufficiently far below the highest SACKed sequence. In some sense, RACK-TLP can be seen as a generalized form of FACK that operates in time space instead of sequence space, enabling it to better handle reordering, application-limited traffic, and lost retransmissions.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
<p id="section-9.2-3">RACK-TLP is compatible with the standard RTO <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>, RTO Restart <span>[<a href="#RFC7765" class="xref">RFC7765</a>]</span>, F-RTO <span>[<a href="#RFC5682" class="xref">RFC5682</a>]</span>, and Eifel algorithms <span>[<a href="#RFC3522" class="xref">RFC3522</a>]</span>. This is because RACK-TLP only detects loss by using ACK events. It neither changes the RTO timer calculation nor detects spurious RTOs. RACK-TLP slightly changes the behavior of <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span> by preceding the RTO with a TLP and reducing potential spurious retransmissions after RTO.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="interaction-with-congestion-control">
<section id="section-9.3">
        <h3 id="name-interaction-with-congestion">
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-interaction-with-congestion" class="section-name selfRef">Interaction with Congestion Control</a>
        </h3>
<p id="section-9.3-1">RACK-TLP intentionally decouples loss detection from congestion control. RACK-TLP only detects losses; it does not modify the congestion control algorithm <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> <span>[<a href="#RFC6937" class="xref">RFC6937</a>]</span>. A segment marked as lost by RACK-TLP <span class="bcp14">MUST NOT</span> be retransmitted until congestion control deems this appropriate. As mentioned in the paragraph following <a href="#fig1" class="xref">Figure 1</a> (<a href="#fig1desc" class="xref">Section 3.4, Paragraph 3</a>), <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> mandates a principle that loss in two successive windows of data or the loss of a retransmission must be taken as two indications of congestion and therefore trigger two separate reactions. The Proportional Rate Reduction (PRR) algorithm <span>[<a href="#RFC6937" class="xref">RFC6937</a>]</span> is <span class="bcp14">RECOMMENDED</span> for the specific congestion control actions taken upon the losses detected by RACK-TLP. 

In the absence of PRR <span>[<a href="#RFC6937" class="xref">RFC6937</a>]</span>, when RACK-TLP detects a lost retransmission, the congestion control <span class="bcp14">MUST</span> trigger an additional congestion response per the aforementioned principle in <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>. If multiple original transmissions or retransmissions were lost in a window, the congestion control specified in <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> only reacts once per window. The congestion control implementer is advised to carefully consider this subtle situation introduced by RACK-TLP.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
<p id="section-9.3-2">The only exception -- the only way in which RACK-TLP modulates the congestion control algorithm -- is that one outstanding loss probe can be sent even if the congestion window is fully used. However, this temporary overcommit is accounted for and credited in the in-flight data tracked for congestion control, so that congestion control will erase the overcommit upon the next ACK.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
<p id="section-9.3-3">If packet losses happen after reordering has been observed, RACK-TLP may take longer to detect losses than the pure DupAck counting approach. In this case, TCP may continue to increase the congestion window upon receiving ACKs during this time, making the sender more aggressive.<a href="#section-9.3-3" class="pilcrow">¶</a></p>
<p id="section-9.3-4">
The following simple example compares how RACK-TLP and non-RACK-TLP loss detection interact with congestion control: suppose a sender has a congestion window (cwnd) of 20 segments on a SACK-enabled connection. It sends 10 data segments, and all of them are lost.<a href="#section-9.3-4" class="pilcrow">¶</a></p>
<p id="section-9.3-5">Without RACK-TLP, the sender would time out, reset cwnd to 1, and retransmit the first segment. It would take four round trips (1 + 2 + 4 + 3 = 10) to retransmit all the 10 lost segments using slow start. The recovery latency would be RTO + 4*RTT, with an ending cwnd of 4 segments due to congestion window validation.<a href="#section-9.3-5" class="pilcrow">¶</a></p>
<p id="section-9.3-6">With RACK-TLP, a sender would send the TLP after 2*RTT and get a DupAck, enabling RACK to detect the losses and trigger fast recovery. If the sender implements Proportional Rate Reduction <span>[<a href="#RFC6937" class="xref">RFC6937</a>]</span>, it would slow start to retransmit the remaining 9 lost segments since the number of segments in flight (0) is lower than the slow start threshold (10). The slow start would again take four round trips (1 + 2 + 4 + 3 = 10) to retransmit all the lost segments. The recovery latency would be 2*RTT + 4*RTT, with an ending cwnd set to the slow-start threshold of 10 segments.<a href="#section-9.3-6" class="pilcrow">¶</a></p>
<p id="section-9.3-7">The difference in recovery latency (RTO + 4*RTT vs 6*RTT) can be significant if the RTT is much smaller than the minimum RTO (1 second in <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>) or if the RTT is large. The former case can happen in local area networks, data center networks, or content distribution networks with deep deployments. The latter case can happen in developing regions with highly congested and/or high-latency networks.<a href="#section-9.3-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tlp-recovery-detection-with-delayed-acks">
<section id="section-9.4">
        <h3 id="name-tlp-recovery-detection-with">
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-tlp-recovery-detection-with" class="section-name selfRef">TLP Recovery Detection with Delayed ACKs</a>
        </h3>
<p id="section-9.4-1">Delayed or stretched ACKs complicate the detection of repairs done by TLP since, with such ACKs, the sender takes a longer time to receive fewer ACKs than would normally be expected. To mitigate this complication, before sending a TLP loss probe retransmission, the sender should attempt to wait long enough that the receiver has sent any delayed ACKs that it is withholding. The sender algorithm described above features such a delay in the form of TLP.max_ack_delay. Furthermore, if the receiver supports DSACK, then, in the case of a delayed ACK, the sender's TLP recovery detection mechanism (see above) can use the DSACK information to infer that the original and TLP retransmission both arrived at the receiver.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
<p id="section-9.4-2">If there is ACK loss or a delayed ACK without a DSACK, then this algorithm is conservative because the sender will reduce the congestion window when, in fact, there was no packet loss.  In practice, this is acceptable and potentially even desirable: if there is reverse path congestion, then reducing the congestion window can be prudent.<a href="#section-9.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rack-tlp-for-other-transport-protocols">
<section id="section-9.5">
        <h3 id="name-rack-tlp-for-other-transpor">
<a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-rack-tlp-for-other-transpor" class="section-name selfRef">RACK-TLP for Other Transport Protocols</a>
        </h3>
<p id="section-9.5-1">RACK-TLP can be implemented in other transport protocols (e.g., <span>[<a href="#I-D.ietf-quic-recovery" class="xref">QUIC-LR</a>]</span>). The <span>[<a href="#SPROUT" class="xref">SPROUT</a>]</span> loss detection algorithm was also independently designed to use a 10 ms reordering window to improve its loss detection similar to RACK.<a href="#section-9.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="security-considerations">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">RACK-TLP algorithm behavior is based on information conveyed in SACK options, so it has security considerations similar to those described in the Security Considerations section of <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">Additionally, RACK-TLP has a lower risk profile than the loss recovery algorithm <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span> because it is not vulnerable to ACK-splitting attacks <span>[<a href="#SCWA99" class="xref">SCWA99</a>]</span>: for an MSS-sized segment sent, the receiver or the attacker might send MSS ACKs that selectively or cumulatively acknowledge one additional byte per ACK. This would not fool RACK. In such a scenario, RACK.xmit_ts would not advance because all the sequence ranges within the segment were transmitted at the same time and thus carry the same transmission timestamp. In other words, SACKing only one byte of a segment or SACKing the segment in entirety have the same effect with RACK.<a href="#section-10-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<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>
</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="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="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="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="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="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>
<dt id="RFC0793">[RFC793]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</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-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="DMCG11">[DMCG11]</dt>
        <dd>
<span class="refAuthor">Dukkipati, N.</span><span class="refAuthor">, Matthis, M.</span><span class="refAuthor">, Cheng, Y.</span><span class="refAuthor">, and M. Ghobadi</span>, <span class="refTitle">"Proportional Rate Reduction for TCP"</span>, <span class="seriesInfo">Proceedings of the 2011 ACM SIGCOMM Conference on Internet Measurement Conference pp. 155-170</span>, <span class="seriesInfo">DOI 10.1145/2068816.2068832</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://doi.org/10.1145/2068816.2068832">https://doi.org/10.1145/2068816.2068832</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="FACK">[FACK]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span><span class="refAuthor"> and J. Mahdavi</span>, <span class="refTitle">"Forward acknowledgement: refining TCP congestion control"</span>, <span class="seriesInfo">ACM SIGCOMM Computer Communication Review Volume 26, Issue 4</span>, <span class="seriesInfo">DOI 10.1145/248157.248181</span>, <time datetime="1996-08" class="refDate">August 1996</time>, <span>&lt;<a href="https://doi.org/10.1145/248157.248181">https://doi.org/10.1145/248157.248181</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="POLICER16">[POLICER16]</dt>
        <dd>
<span class="refAuthor">Flach, T.</span><span class="refAuthor">, Papageorge, P.</span><span class="refAuthor">, Terzis, A.</span><span class="refAuthor">, Pedrosa, L.</span><span class="refAuthor">, Cheng, Y.</span><span class="refAuthor">, Karim, T.</span><span class="refAuthor">, Katz-Bassett, E.</span><span class="refAuthor">, and R. Govindan</span>, <span class="refTitle">"An Internet-Wide Analysis of Traffic Policing"</span>, <span class="refContent">Proceedings of the 2016 ACM SIGCOMM Conference pp. 468-482</span>, <span class="seriesInfo">DOI 10.1145/2934872.2934873</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://doi.org/10.1145/2934872.2934873">https://doi.org/10.1145/2934872.2934873</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-quic-recovery">[QUIC-LR]</dt>
        <dd>
<span class="refAuthor">Iyengar, J.</span><span class="refAuthor"> and I. Swett</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-34</span>, <time datetime="2021-01-14" class="refDate">14 January 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-recovery-34">https://tools.ietf.org/html/draft-ietf-quic-recovery-34</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3042">[RFC3042]</dt>
        <dd>
<span class="refAuthor">Allman, M.</span><span class="refAuthor">, Balakrishnan, H.</span><span class="refAuthor">, and S. Floyd</span>, <span class="refTitle">"Enhancing TCP's Loss Recovery Using Limited Transmit"</span>, <span class="seriesInfo">RFC 3042</span>, <span class="seriesInfo">DOI 10.17487/RFC3042</span>, <time datetime="2001-01" class="refDate">January 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3042">https://www.rfc-editor.org/info/rfc3042</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="RFC4653">[RFC4653]</dt>
        <dd>
<span class="refAuthor">Bhandarkar, S.</span><span class="refAuthor">, Reddy, A. L. N.</span><span class="refAuthor">, Allman, M.</span><span class="refAuthor">, and E. Blanton</span>, <span class="refTitle">"Improving the Robustness of TCP to Non-Congestion Events"</span>, <span class="seriesInfo">RFC 4653</span>, <span class="seriesInfo">DOI 10.17487/RFC4653</span>, <time datetime="2006-08" class="refDate">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4653">https://www.rfc-editor.org/info/rfc4653</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="RFC5827">[RFC5827]</dt>
        <dd>
<span class="refAuthor">Allman, M.</span><span class="refAuthor">, Avrachenkov, K.</span><span class="refAuthor">, Ayesta, U.</span><span class="refAuthor">, Blanton, J.</span><span class="refAuthor">, and P. Hurtig</span>, <span class="refTitle">"Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)"</span>, <span class="seriesInfo">RFC 5827</span>, <span class="seriesInfo">DOI 10.17487/RFC5827</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5827">https://www.rfc-editor.org/info/rfc5827</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6937">[RFC6937]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span><span class="refAuthor">, Dukkipati, N.</span><span class="refAuthor">, and Y. Cheng</span>, <span class="refTitle">"Proportional Rate Reduction for TCP"</span>, <span class="seriesInfo">RFC 6937</span>, <span class="seriesInfo">DOI 10.17487/RFC6937</span>, <time datetime="2013-05" class="refDate">May 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6937">https://www.rfc-editor.org/info/rfc6937</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7765">[RFC7765]</dt>
        <dd>
<span class="refAuthor">Hurtig, P.</span><span class="refAuthor">, Brunstrom, A.</span><span class="refAuthor">, Petlund, A.</span><span class="refAuthor">, and M. Welzl</span>, <span class="refTitle">"TCP and Stream Control Transmission Protocol (SCTP) RTO Restart"</span>, <span class="seriesInfo">RFC 7765</span>, <span class="seriesInfo">DOI 10.17487/RFC7765</span>, <time datetime="2016-02" class="refDate">February 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7765">https://www.rfc-editor.org/info/rfc7765</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SCWA99">[SCWA99]</dt>
        <dd>
<span class="refAuthor">Savage, S.</span><span class="refAuthor">, Cardwell, N.</span><span class="refAuthor">, Wetherall, D.</span><span class="refAuthor">, and T. Anderson</span>, <span class="refTitle">"TCP congestion control with a misbehaving receiver"</span>, <span class="seriesInfo">ACM Computer Communication Review 29(5)</span>, <span class="seriesInfo">DOI 10.1145/505696.505704</span>, <time datetime="1999-10" class="refDate">October 1999</time>, <span>&lt;<a href="https://doi.org/10.1145/505696.505704">https://doi.org/10.1145/505696.505704</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SPROUT">[SPROUT]</dt>
      <dd>
<span class="refAuthor">Winstein, K.</span><span class="refAuthor">, Sivaraman, A.</span><span class="refAuthor">, and H. Balakrishnan</span>, <span class="refTitle">"Stochastic Forecasts Achieve High Throughput and Low Delay over Cellular Networks"</span>, <span class="refContent">10th USENIX Symposium on Networked Systems Design and Implementation (NSDI '13)"</span>, <time datetime="2013" class="refDate">2013</time>. </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">The authors thank <span class="contact-name">Matt Mathis</span> for his insights in FACK and <span class="contact-name">Michael Welzl</span> for his per-packet timer idea that inspired this work. <span class="contact-name">Eric Dumazet</span>, <span class="contact-name">Randy Stewart</span>, <span class="contact-name">Van Jacobson</span>, <span class="contact-name">Ian Swett</span>, <span class="contact-name">Rick Jones</span>, <span class="contact-name">Jana Iyengar</span>, <span class="contact-name">Hiren Panchasara</span>, <span class="contact-name">Praveen Balasubramanian</span>, <span class="contact-name">Yoshifumi Nishida</span>, <span class="contact-name">Bob Briscoe</span>, <span class="contact-name">Felix Weinrank</span>, <span class="contact-name">Michael Tüxen</span>, <span class="contact-name">Martin Duke</span>, <span class="contact-name">Ilpo Jarvinen</span>, <span class="contact-name">Theresa Enghardt</span>, <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Gorry Fairhurst</span>, <span class="contact-name">Markku Kojo</span>, and <span class="contact-name">Yi Huang</span> contributed to this document or the implementations in Linux, FreeBSD, Windows, and QUIC.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Yuchung Cheng</span></div>
<div dir="auto" class="left"><span class="org">Google, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ycheng@google.com" class="email">ycheng@google.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Neal Cardwell</span></div>
<div dir="auto" class="left"><span class="org">Google, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ncardwell@google.com" class="email">ncardwell@google.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Nandita Dukkipati</span></div>
<div dir="auto" class="left"><span class="org">Google, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:nanditad@google.com" class="email">nanditad@google.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Priyaranjan Jha</span></div>
<div dir="auto" class="left"><span class="org">Google, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:priyarjha@google.com" class="email">priyarjha@google.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>