File: rfc9040.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 (3487 lines) | stat: -rw-r--r-- 172,549 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 9040: TCP Control Block Interdependence</title>
<meta content="Joe Touch" name="author">
<meta content="Michael Welzl" name="author">
<meta content="Safiqul Islam" name="author">
<meta content="
       
   This memo provides guidance to TCP implementers that is intended to
   help improve connection convergence to steady-state operation
   without affecting interoperability. It updates and replaces RFC
   2140's description of sharing TCP state, as typically represented in
   TCP Control Blocks, among similar concurrent or consecutive
   connections. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="9040" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    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="rfc9040.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9040" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis-11" 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 9040</td>
<td class="center">TCP Control Block Interdependence</td>
<td class="right">July 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Touch, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9040" class="eref">9040</a></dd>
<dt class="label-obsoletes">Obsoletes:</dt>
<dd class="obsoletes">
<a href="https://www.rfc-editor.org/rfc/rfc2140" class="eref">2140</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-07" class="published">July 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">J. Touch</div>
<div class="org">Independent</div>
</div>
<div class="author">
      <div class="author-name">M. Welzl</div>
<div class="org">University of Oslo</div>
</div>
<div class="author">
      <div class="author-name">S. Islam</div>
<div class="org">University of Oslo</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9040</h1>
<h1 id="title">TCP Control Block Interdependence</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   This memo provides guidance to TCP implementers that is intended to
   help improve connection convergence to steady-state operation
   without affecting interoperability. It updates and replaces RFC
   2140's description of sharing TCP state, as typically represented in
   TCP Control Blocks, among similar concurrent or consecutive
   connections.<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 document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9040">https://www.rfc-editor.org/info/rfc9040</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 ulBare ulEmpty">
<li class="compact toc ulBare 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></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-used-in-this-do" class="xref">Conventions Used in This Document</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="compact toc ulBare 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-the-tcp-control-block-tcb" class="xref">The TCP Control Block (TCB)</a></p>
</li>
          <li class="compact toc ulBare 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-tcb-interdependence" class="xref">TCB Interdependence</a></p>
</li>
          <li class="compact toc ulBare 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-temporal-sharing" class="xref">Temporal Sharing</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare 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-initialization-of-a-new-tcb" class="xref">Initialization of a New TCB</a></p>
</li>
              <li class="compact ulBare 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-updates-to-the-tcb-cache" class="xref">Updates to the TCB Cache</a></p>
</li>
              <li class="compact ulBare 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-discussion" class="xref">Discussion</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-ensemble-sharing" class="xref">Ensemble Sharing</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare 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-initialization-of-a-new-tcb-2" class="xref">Initialization of a New TCB</a></p>
</li>
              <li class="compact ulBare 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-updates-to-the-tcb-cache-2" class="xref">Updates to the TCB Cache</a></p>
</li>
              <li class="compact ulBare 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-discussion-2" class="xref">Discussion</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-issues-with-tcb-information" class="xref">Issues with TCB Information Sharing</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-traversing-the-same-network" class="xref">Traversing the Same Network Path</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-state-dependence" class="xref">State Dependence</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-problems-with-sharing-based" class="xref">Problems with Sharing Based on IP Address</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-implications" class="xref">Implications</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare 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-layering" class="xref">Layering</a></p>
</li>
              <li class="compact ulBare 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-other-possibilities" class="xref">Other Possibilities</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-implementation-observations" class="xref">Implementation Observations</a></p>
</li>
          <li class="compact toc ulBare 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-changes-compared-to-rfc-214" class="xref">Changes Compared to RFC 2140</a></p>
</li>
          <li class="compact toc ulBare 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.14.2.1">
                <p id="section-toc.1-1.14.2.1.1"><a href="#section-14.1" class="xref">14.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.14.2.2">
                <p id="section-toc.1-1.14.2.2.1"><a href="#section-14.2" class="xref">14.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-tcb-sharing-history" class="xref">TCB Sharing History</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-tcp-option-sharing-and-cach" class="xref">TCP Option Sharing and Caching</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#appendix-C" class="xref">Appendix C</a>.  <a href="#name-automating-the-initial-wind" class="xref">Automating the Initial Window in TCP over Long Timescales</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.17.2.1">
                <p id="section-toc.1-1.17.2.1.1"><a href="#appendix-C.1" class="xref">C.1</a>.  <a href="#name-introduction-2" class="xref">Introduction</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.17.2.2">
                <p id="section-toc.1-1.17.2.2.1"><a href="#appendix-C.2" class="xref">C.2</a>.  <a href="#name-design-considerations" class="xref">Design Considerations</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.17.2.3">
                <p id="section-toc.1-1.17.2.3.1"><a href="#appendix-C.3" class="xref">C.3</a>.  <a href="#name-proposed-iw-algorithm" class="xref">Proposed IW Algorithm</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.17.2.4">
                <p id="section-toc.1-1.17.2.4.1"><a href="#appendix-C.4" class="xref">C.4</a>.  <a href="#name-discussion-3" class="xref">Discussion</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.17.2.5">
                <p id="section-toc.1-1.17.2.5.1"><a href="#appendix-C.5" class="xref">C.5</a>.  <a href="#name-observations" class="xref">Observations</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.18">
            <p id="section-toc.1-1.18.1"><a href="#appendix-D" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.19">
            <p id="section-toc.1-1.19.1"><a href="#appendix-E" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sect-1">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
   TCP is a connection-oriented reliable transport protocol layered over IP
   <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>. Each TCP connection maintains
   state, usually in a data structure called the "TCP Control Block (TCB)". The
   TCB contains information about the connection state, its associated local
   process, and feedback parameters about the connection's transmission
   properties. As originally specified and usually implemented, most TCB
   information is maintained on a per-connection basis. Some implementations
   share certain TCB information across connections to the same host <span>[<a href="#RFC2140" class="xref">RFC2140</a>]</span>. Such sharing is intended to lead to
   better overall transient performance, especially for numerous short-lived
   and simultaneous connections, as can be used in the World Wide Web and
   other applications <span>[<a href="#Be94" class="xref">Be94</a>]</span> <span>[<a href="#Br02" class="xref">Br02</a>]</span>. This sharing of state is intended to help
   TCP connections converge to long-term behavior (assuming stable application
   load, i.e., so-called "steady-state") more quickly without affecting TCP
   interoperability.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   This document updates RFC 2140's discussion of TCB state sharing and
   provides a complete replacement for that document. This state sharing
   affects only TCB initialization <span>[<a href="#RFC2140" class="xref">RFC2140</a>]</span>
   and thus has no effect on the long-term behavior of TCP after a connection
   has been established or on interoperability. Path information shared
   across SYN destination port numbers assumes that TCP segments having the
   same host-pair experience the same path properties, i.e., that traffic is
   not routed differently based on port numbers or other connection parameters
   (also addressed further in <a href="#sect-8.1" class="xref">Section 8.1</a>). The
   observations about TCB sharing in this document apply similarly to any
   protocol with congestion state, including the Stream Control Transmission
   Protocol (SCTP) <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span> and the Datagram
   Congestion Control Protocol (DCCP) <span>[<a href="#RFC4340" class="xref">RFC4340</a>]</span>, as well as to individual subflows in Multipath TCP
   <span>[<a href="#RFC8684" class="xref">RFC8684</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-conventions-used-in-this-do">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-used-in-this-do" class="section-name selfRef">Conventions Used in This Document</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
   The core of this document describes behavior that is already permitted by
   TCP standards. As a result, this document provides informative guidance but does not
   use normative language except when quoting other documents. Normative
   language is used in <a href="#sect-c" class="xref">Appendix C</a> as examples of requirements for
   future consideration.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-terminology">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-3-1">
   The following terminology is used frequently in this document.  Items
   preceded with a "+" may be part of the state maintained as TCP connection
   state in the TCB of associated connections and are the focus of sharing as
   described in this document.  Note that terms are used as originally
   introduced where possible; in some cases, direction is indicated with a
   suffix (_S for send, _R for receive) and in other cases spelled out
   (sendcwnd).<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-2">
        <dt id="section-3-2.1">+cwnd:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.2">TCP congestion window size <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span><a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">host:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.4">a source or sink of TCP segments associated with a single IP
 address<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.5">host-pair:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.6">a pair of hosts and their corresponding IP addresses<a href="#section-3-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.7">ISN: 
        </dt>
        <dd style="margin-left: 3.0em" id="section-3-2.8">Initial Sequence Number<a href="#section-3-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.9">+MMS_R:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.10">maximum message size that can be received, the largest
 received transport payload of an IP datagram <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span><a href="#section-3-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.11">+MMS_S:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.12">maximum message size that can be sent, the largest
 transmitted transport payload of an IP datagram <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span><a href="#section-3-2.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.13">path:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.14">an Internet path between the IP addresses of two hosts<a href="#section-3-2.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.15">PCB:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.16">protocol control block, the data associated with a protocol as
        maintained by an endpoint; a TCP PCB is called a "TCB"<a href="#section-3-2.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.17">PLPMTUD:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.18">packetization-layer path MTU discovery, a mechanism that
        uses transport packets to discover the Path Maximum Transmission Unit (PMTU) <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span><a href="#section-3-2.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.19">+PMTU:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.20">largest IP datagram that can traverse a path
 <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span><a href="#section-3-2.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.21">PMTUD:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.22">path-layer MTU discovery, a mechanism that
 relies on ICMP error messages to discover the PMTU <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span><a href="#section-3-2.22" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.23">+RTT:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.24">round-trip time of a TCP packet exchange <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span><a href="#section-3-2.24" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.25">+RTTVAR:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.26">variation of round-trip times of a TCP packet
 exchange <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span><a href="#section-3-2.26" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.27">+rwnd:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.28">TCP receive window size <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span><a href="#section-3-2.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.29">+sendcwnd:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.30">TCP send-side congestion window (cwnd) size
 <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span><a href="#section-3-2.30" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.31">+sendMSS:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.32">TCP maximum segment size, a value
 transmitted in a TCP option that represents the largest TCP user data
 payload that can be received <span>[<a href="#RFC6691" class="xref">RFC6691</a>]</span><a href="#section-3-2.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.33">+ssthresh:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.34">TCP slow-start threshold <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span><a href="#section-3-2.34" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.35">TCB:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.36">TCP Control Block, the data associated with a TCP
 connection as maintained by an endpoint<a href="#section-3-2.36" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.37">TCP-AO:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.38">TCP Authentication Option <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span><a href="#section-3-2.38" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.39">TFO:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.40">TCP Fast Open option <span>[<a href="#RFC7413" class="xref">RFC7413</a>]</span><a href="#section-3-2.40" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.41">+TFO_cookie:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.42">TCP Fast Open cookie, state that is used
 as part of the TFO mechanism, when TFO is supported <span>[<a href="#RFC7413" class="xref">RFC7413</a>]</span><a href="#section-3-2.42" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.43">+TFO_failure:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.44">an indication of when TFO option
 negotiation failed, when TFO is supported<a href="#section-3-2.44" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.45">+TFOinfo:</dt>
        <dd style="margin-left: 3.0em" id="section-3-2.46">information cached when a TFO connection is
 established, which includes the TFO_cookie <span>[<a href="#RFC7413" class="xref">RFC7413</a>]</span><a href="#section-3-2.46" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-the-tcp-control-block-tcb">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-the-tcp-control-block-tcb" class="section-name selfRef">The TCP Control Block (TCB)</a>
      </h2>
<p id="section-4-1">
   A TCB describes the data associated with each connection, i.e., with
   each association of a pair of applications across the network. The
   TCB contains at least the following information <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4-2.1">
          <p id="section-4-2.1.1">Local process state<a href="#section-4-2.1.1" class="pilcrow">¶</a></p>
<ul class="compact normal ulEmpty">
<li class="compact normal ulEmpty" id="section-4-2.1.2.1">pointers to send and receive buffers<a href="#section-4-2.1.2.1" class="pilcrow">¶</a>
</li>
            <li class="compact normal ulEmpty" id="section-4-2.1.2.2">pointers to retransmission queue and current segment<a href="#section-4-2.1.2.2" class="pilcrow">¶</a>
</li>
            <li class="compact normal ulEmpty" id="section-4-2.1.2.3">pointers to Internet Protocol (IP) PCB<a href="#section-4-2.1.2.3" class="pilcrow">¶</a>
</li>
          </ul>
</li>
        <li class="normal ulEmpty" id="section-4-2.2">
          <p id="section-4-2.2.1">Per-connection shared state<a href="#section-4-2.2.1" class="pilcrow">¶</a></p>
<ul class="compact normal ulEmpty">
<li class="compact normal ulEmpty" id="section-4-2.2.2.1">
              <p id="section-4-2.2.2.1.1">macro-state<a href="#section-4-2.2.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact normal ulEmpty">
<li class="compact normal ulEmpty" id="section-4-2.2.2.1.2.1">connection state<a href="#section-4-2.2.2.1.2.1" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.1.2.2">timers<a href="#section-4-2.2.2.1.2.2" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.1.2.3">flags<a href="#section-4-2.2.2.1.2.3" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.1.2.4">local and remote host numbers and ports<a href="#section-4-2.2.2.1.2.4" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.1.2.5">TCP option state<a href="#section-4-2.2.2.1.2.5" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="compact normal ulEmpty" id="section-4-2.2.2.2">
              <p id="section-4-2.2.2.2.1">micro-state<a href="#section-4-2.2.2.2.1" class="pilcrow">¶</a></p>
<ul class="compact normal ulEmpty">
<li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.1">send and receive window state (size*, current number)<a href="#section-4-2.2.2.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.2">congestion window size (sendcwnd)*<a href="#section-4-2.2.2.2.2.2" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.3">congestion window size threshold (ssthresh)*<a href="#section-4-2.2.2.2.2.3" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.4">max window size seen*<a href="#section-4-2.2.2.2.2.4" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.5">sendMSS#<a href="#section-4-2.2.2.2.2.5" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.6">MMS_S#<a href="#section-4-2.2.2.2.2.6" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.7">MMS_R#<a href="#section-4-2.2.2.2.2.7" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.8">PMTU#<a href="#section-4-2.2.2.2.2.8" class="pilcrow">¶</a>
</li>
                <li class="compact normal ulEmpty" id="section-4-2.2.2.2.2.9">round-trip time and its variation#<a href="#section-4-2.2.2.2.2.9" class="pilcrow">¶</a>
</li>
              </ul>
</li>
          </ul>
</li>
      </ul>
<p id="section-4-3">
   The per-connection information is shown as split into macro-state and
   micro-state, terminology borrowed from <span>[<a href="#Co91" class="xref">Co91</a>]</span>. Macro-state describes the protocol for establishing the
   initial shared state about the connection; we include the endpoint numbers
   and components (timers, flags) required upon commencement that are later
   used to help maintain that state. Micro-state describes the protocol after
   a connection has been established, to maintain the reliability and
   congestion control of the data transferred in the connection.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
   We distinguish two other classes of shared micro-state that are associated
   more with host-pairs than with application pairs.

   One class is clearly host-pair dependent (shown above as "#", e.g.,
   sendMSS, MMS_R, MMS_S, PMTU, RTT), because these parameters are defined by
   the endpoint or endpoint pair (of the given example: sendMSS, MMS_R, MMS_S,
   RTT) or are already cached and shared on that basis (of the given example:
   PMTU <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>).




The other is host-pair dependent in its aggregate (shown above as "*", e.g.,
congestion window information, current window sizes, etc.) because they depend
on the total capacity between the two endpoints.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
   Not all of the TCB state is necessarily shareable. In particular,
   some TCP options are negotiated only upon request by the application
   layer, so their use may not be correlated across connections. Other
   options negotiate connection-specific parameters, which are
   similarly not shareable. These are discussed further in <a href="#sect-b" class="xref">Appendix B</a>.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
   Finally, we exclude rwnd from further discussion because its value
   should depend on the send window size, so it is already addressed by
   send window sharing and is not independently affected by sharing.<a href="#section-4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-tcb-interdependence">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-tcb-interdependence" class="section-name selfRef">TCB Interdependence</a>
      </h2>
<p id="section-5-1">
   There are two cases of TCB interdependence. Temporal sharing occurs
   when the TCB of an earlier (now CLOSED) connection to a host is used
   to initialize some parameters of a new connection to that same host,
   i.e., in sequence. Ensemble sharing occurs when a currently active
   connection to a host is used to initialize another (concurrent)
   connection to that host.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6">
<section id="section-6">
      <h2 id="name-temporal-sharing">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-temporal-sharing" class="section-name selfRef">Temporal Sharing</a>
      </h2>
<p id="section-6-1">
   The TCB data cache is accessed in two ways: it is read to initialize
   new TCBs and written when more current per-host state is available.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="sect-6.1">
<section id="section-6.1">
        <h3 id="name-initialization-of-a-new-tcb">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-initialization-of-a-new-tcb" class="section-name selfRef">Initialization of a New TCB</a>
        </h3>
<p id="section-6.1-1">
   TCBs for new connections can be initialized using cached context
   from past connections as follows:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<span id="name-temporal-sharing-tcb-initia"></span><div id="TCB_initialization">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-temporal-sharing-tcb-initia" class="selfRef">Temporal Sharing - TCB Initialization</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached TCB</th>
              <th class="text-left" rowspan="1" colspan="1">New TCB</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_S</td>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_S or not cached (2)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_R</td>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_R or not cached (2)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_sendMSS</td>
              <td class="text-left" rowspan="1" colspan="1">old_sendMSS</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_PMTU</td>
              <td class="text-left" rowspan="1" colspan="1">old_PMTU (1)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTT</td>
              <td class="text-left" rowspan="1" colspan="1">old_RTT</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTTVAR</td>
              <td class="text-left" rowspan="1" colspan="1">old_RTTVAR</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_option</td>
              <td class="text-left" rowspan="1" colspan="1">(option specific)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_ssthresh</td>
              <td class="text-left" rowspan="1" colspan="1">old_ssthresh</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_sendcwnd</td>
              <td class="text-left" rowspan="1" colspan="1">old_sendcwnd</td>
            </tr>
          </tbody>
        </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-6.1-3">
          <dt id="section-6.1-3.1">(1)</dt>
          <dd style="margin-left: 1.5em" id="section-6.1-3.2">Note that PMTU is cached at the IP layer <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>.<a href="#section-6.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.1-3.3">(2)</dt>
          <dd style="margin-left: 1.5em" id="section-6.1-3.4">Note that some values are not cached when they are computed locally
   (MMS_R) or indicated in the connection itself (MMS_S in the SYN).<a href="#section-6.1-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-6.1-4">

   <a href="#Option_Info_Initialization" class="xref">Table 2</a> gives an overview of
   option-specific information that can be shared. Additional information on
   some specific TCP options and sharing is provided in <a href="#sect-b" class="xref">Appendix B</a>.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<span id="name-temporal-sharing-option-inf"></span><div id="Option_Info_Initialization">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-temporal-sharing-option-inf" class="selfRef">Temporal Sharing - Option Info Initialization</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached</th>
              <th class="text-left" rowspan="1" colspan="1">New</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="sect-6.2">
<section id="section-6.2">
        <h3 id="name-updates-to-the-tcb-cache">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-updates-to-the-tcb-cache" class="section-name selfRef">Updates to the TCB Cache</a>
        </h3>
<p id="section-6.2-1">
   During a connection, the TCB cache can be updated based on events of
   current connections and their TCBs as they progress over time, as shown in
   <a href="#Cache_Updates" class="xref">Table 3</a>.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<span id="name-temporal-sharing-cache-upda"></span><div id="Cache_Updates">
<table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-temporal-sharing-cache-upda" class="selfRef">Temporal Sharing - Cache Updates</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached TCB</th>
              <th class="text-left" rowspan="1" colspan="1">Current TCB</th>
              <th class="text-left" rowspan="1" colspan="1">When?</th>
              <th class="text-left" rowspan="1" colspan="1">New Cached TCB</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_S</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_S</td>
              <td class="text-left" rowspan="1" colspan="1">OPEN</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_S</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_R</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_R</td>
              <td class="text-left" rowspan="1" colspan="1">OPEN</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_R</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_sendMSS</td>
              <td class="text-left" rowspan="1" colspan="1">curr_sendMSS</td>
              <td class="text-left" rowspan="1" colspan="1">MSSopt</td>
              <td class="text-left" rowspan="1" colspan="1">curr_sendMSS</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_PMTU</td>
              <td class="text-left" rowspan="1" colspan="1">curr_PMTU</td>
              <td class="text-left" rowspan="1" colspan="1">PMTUD (1) / PLPMTUD (1)</td>
              <td class="text-left" rowspan="1" colspan="1">curr_PMTU</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTT</td>
              <td class="text-left" rowspan="1" colspan="1">curr_RTT</td>
              <td class="text-left" rowspan="1" colspan="1">CLOSE</td>
              <td class="text-left" rowspan="1" colspan="1">merge(curr,old)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTTVAR</td>
              <td class="text-left" rowspan="1" colspan="1">curr_RTTVAR</td>
              <td class="text-left" rowspan="1" colspan="1">CLOSE</td>
              <td class="text-left" rowspan="1" colspan="1">merge(curr,old)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_option</td>
              <td class="text-left" rowspan="1" colspan="1">curr_option</td>
              <td class="text-left" rowspan="1" colspan="1">ESTAB</td>
              <td class="text-left" rowspan="1" colspan="1">(depends on option)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_ssthresh</td>
              <td class="text-left" rowspan="1" colspan="1">curr_ssthresh</td>
              <td class="text-left" rowspan="1" colspan="1">CLOSE</td>
              <td class="text-left" rowspan="1" colspan="1">merge(curr,old)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_sendcwnd</td>
              <td class="text-left" rowspan="1" colspan="1">curr_sendcwnd</td>
              <td class="text-left" rowspan="1" colspan="1">CLOSE</td>
              <td class="text-left" rowspan="1" colspan="1">merge(curr,old)</td>
            </tr>
          </tbody>
        </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-6.2-3">
          <dt id="section-6.2-3.1">(1)</dt>
          <dd style="margin-left: 1.5em" id="section-6.2-3.2">Note that PMTU is cached at the IP layer <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>.<a href="#section-6.2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-6.2-4">
   Merge() is the function that combines the current and previous (old)
   values and may vary for each parameter of the TCB cache. The
   particular function is not specified in this document; examples
   include windowed averages (mean of the past N values, for some N)
   and exponential decay (new = (1-alpha)*old + alpha *new, where alpha
   is in the range [0..1]).<a href="#section-6.2-4" class="pilcrow">¶</a></p>
<p id="section-6.2-5">
   <a href="#Option_Info_Updates" class="xref">Table 4</a> gives an overview of option-specific
   information that can be similarly shared. The TFO cookie is maintained
   until the client explicitly requests it be updated as a separate event.<a href="#section-6.2-5" class="pilcrow">¶</a></p>
<span id="name-temporal-sharing-option-info"></span><div id="Option_Info_Updates">
<table class="center" id="table-4">
          <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-temporal-sharing-option-info" class="selfRef">Temporal Sharing - Option Info Updates</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached</th>
              <th class="text-left" rowspan="1" colspan="1">Current</th>
              <th class="text-left" rowspan="1" colspan="1">When?</th>
              <th class="text-left" rowspan="1" colspan="1">New Cached</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
              <td class="text-left" rowspan="1" colspan="1">ESTAB</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
              <td class="text-left" rowspan="1" colspan="1">ESTAB</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="sect-6.3">
<section id="section-6.3">
        <h3 id="name-discussion">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-discussion" class="section-name selfRef">Discussion</a>
        </h3>
<p id="section-6.3-1">
   As noted, there is no particular benefit to caching MMS_S and MMS_R as
   these are reported by the local IP stack. Caching sendMSS and PMTU is
   trivial; reported values are cached (PMTU at the IP layer), and the most
   recent values are used. The cache is updated when the MSS option is
   received in a SYN or after PMTUD (i.e., when an ICMPv4 Fragmentation Needed
   <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> or ICMPv6 Packet Too Big message
   is received <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> or the equivalent is
   inferred, e.g., as from PLPMTUD <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>),
   respectively, so the cache always has the most recent values from any
   connection. For sendMSS, the cache is consulted only at connection
   establishment and not otherwise updated, which means that MSS options do
   not affect current connections. The default sendMSS is never saved; only
   reported MSS values update the cache, so an explicit override is required
   to reduce the sendMSS. Cached sendMSS affects only data sent in the SYN
   segment, i.e., during client connection initiation or during simultaneous
   open; the MSS of all other segments are constrained by the value updated as
   included in the SYN.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
   RTT values are updated by formulae that merge the old and new values, as
   noted in <a href="#sect-6.2" class="xref">Section 6.2</a>. Dynamic RTT estimation
   requires a sequence of RTT measurements. As a result, the cached RTT (and
   its variation) is an average of its previous value with the contents of the
   currently active TCB for that host, when a TCB is closed. RTT values are
   updated only when a connection is closed. The method for merging old and
   current values needs to attempt to reduce the transient effects of the new
   connections.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3-3">
   The updates for RTT, RTTVAR, and ssthresh rely on existing
   information, i.e., old values. Should no such values exist, the
   current values are cached instead.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
<p id="section-6.3-4">
   TCP options are copied or merged depending on the details of each
   option. For example, TFO state is updated when a connection is established
   and read before establishing a new connection.<a href="#section-6.3-4" class="pilcrow">¶</a></p>
<p id="section-6.3-5">
Sections <a href="#sect-8" class="xref">8</a> and <a href="#sect-9" class="xref">9</a> discuss compatibility issues and implications of sharing
the specific information listed above. <a href="#sect-10" class="xref">Section 10</a> gives an overview of known implementations.<a href="#section-6.3-5" class="pilcrow">¶</a></p>
<p id="section-6.3-6">
   Most cached TCB values are updated when a connection closes. The exceptions
   are MMS_R and MMS_S, which are reported by IP <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span>; PMTU, which is updated after Path MTU Discovery and
   also reported by IP <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span> <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span>; and sendMSS, which is updated if the MSS option is
   received in the TCP SYN header.<a href="#section-6.3-6" class="pilcrow">¶</a></p>
<p id="section-6.3-7">
   Sharing sendMSS information affects only data in the SYN of the next
   connection, because sendMSS information is typically included in
   most TCP SYN segments. Caching PMTU can accelerate the efficiency of
   PMTUD but can also result in black-holing until corrected if in
   error. Caching MMS_R and MMS_S may be of little direct value as they
   are reported by the local IP stack anyway.<a href="#section-6.3-7" class="pilcrow">¶</a></p>
<p id="section-6.3-8">
   The way in which state related to other TCP options can be shared depends on the
   details of that option. For example, TFO state includes the TCP Fast Open
   cookie <span>[<a href="#RFC7413" class="xref">RFC7413</a>]</span> or, in case TFO fails, a negative TCP Fast Open
   response. RFC 7413 states,<a href="#section-6.3-8" class="pilcrow">¶</a></p>
<blockquote id="section-6.3-9">The client <span class="bcp14">MUST</span> cache negative responses from the server in order to avoid potential connection failures. Negative responses include the server not acknowledging the data in the SYN, ICMP error messages, and (most importantly) no response (SYN-ACK) from the server at all, i.e., connection timeout.<a href="#section-6.3-9" class="pilcrow">¶</a>
</blockquote>
<p id="section-6.3-10">TFOinfo is cached when a connection is established.<a href="#section-6.3-10" class="pilcrow">¶</a></p>
<p id="section-6.3-11">
   State related to other TCP options might not be as readily cached. For
   example, TCP-AO <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span> success or
   failure between a host-pair for a single SYN destination port might be
   usefully cached. TCP-AO success or failure to other SYN destination ports
   on that host-pair is never useful to cache because TCP-AO security
   parameters can vary per service.<a href="#section-6.3-11" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-7">
<section id="section-7">
      <h2 id="name-ensemble-sharing">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-ensemble-sharing" class="section-name selfRef">Ensemble Sharing</a>
      </h2>
<p id="section-7-1">
   Sharing cached TCB data across concurrent connections requires
   attention to the aggregate nature of some of the shared state. For
   example, although MSS and RTT values can be shared by copying, it
   may not be appropriate to simply copy congestion window or ssthresh
   information; instead, the new values can be a function (f) of the
   cumulative values and the number of connections (N).<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="sect-7.1">
<section id="section-7.1">
        <h3 id="name-initialization-of-a-new-tcb-2">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-initialization-of-a-new-tcb-2" class="section-name selfRef">Initialization of a New TCB</a>
        </h3>
<p id="section-7.1-1">
   TCBs for new connections can be initialized using cached context
   from concurrent connections as follows:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<span id="name-ensemble-sharing-tcb-initia"></span><div id="TCB_Initialization">
<table class="center" id="table-5">
          <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-ensemble-sharing-tcb-initia" class="selfRef">Ensemble Sharing - TCB Initialization</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached TCB</th>
              <th class="text-left" rowspan="1" colspan="1">New TCB</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_S</td>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_S</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_R</td>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_R</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_sendMSS</td>
              <td class="text-left" rowspan="1" colspan="1">old_sendMSS</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_PMTU</td>
              <td class="text-left" rowspan="1" colspan="1">old_PMTU (1)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTT</td>
              <td class="text-left" rowspan="1" colspan="1">old_RTT</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTTVAR</td>
              <td class="text-left" rowspan="1" colspan="1">old_RTTVAR</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">sum(old_ssthresh)</td>
              <td class="text-left" rowspan="1" colspan="1">f(sum(old_ssthresh), N)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">sum(old_sendcwnd)</td>
              <td class="text-left" rowspan="1" colspan="1">f(sum(old_sendcwnd), N)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_option</td>
              <td class="text-left" rowspan="1" colspan="1">(option specific)</td>
            </tr>
          </tbody>
        </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-7.1-3">
          <dt id="section-7.1-3.1">(1)</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-3.2">Note that PMTU is cached at the IP layer <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>.<a href="#section-7.1-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.1-4">
   In <a href="#TCB_Initialization" class="xref">Table 5</a>, the cached sum() is a total across all active
   connections because these parameters act in aggregate; similarly, f()
   is a function that updates that sum based on the new connection's
   values, represented as "N".<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<p id="section-7.1-5">
   <a href="#Ensemble_Option_Info_Initialization" class="xref">Table 6</a> gives an overview of
   option-specific information that can be similarly shared. Again, the
   TFO_cookie is updated upon explicit client request, which is a separate
   event.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
<span id="name-ensemble-sharing-option-inf"></span><div id="Ensemble_Option_Info_Initialization">
<table class="center" id="table-6">
          <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-ensemble-sharing-option-inf" class="selfRef">Ensemble Sharing - Option Info Initialization</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached</th>
              <th class="text-left" rowspan="1" colspan="1">New</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="sect-7.2">
<section id="section-7.2">
        <h3 id="name-updates-to-the-tcb-cache-2">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-updates-to-the-tcb-cache-2" class="section-name selfRef">Updates to the TCB Cache</a>
        </h3>
<p id="section-7.2-1">
   During a connection, the TCB cache can be updated based on changes to
   concurrent connections and their TCBs, as shown below:<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<span id="name-ensemble-sharing-cache-upda"></span><div id="Ensemble_Cache_Updates">
<table class="center" id="table-7">
          <caption>
<a href="#table-7" class="selfRef">Table 7</a>:
<a href="#name-ensemble-sharing-cache-upda" class="selfRef">Ensemble Sharing - Cache Updates</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached TCB</th>
              <th class="text-left" rowspan="1" colspan="1">Current TCB</th>
              <th class="text-left" rowspan="1" colspan="1">When?</th>
              <th class="text-left" rowspan="1" colspan="1">New Cached TCB</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_S</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_S</td>
              <td class="text-left" rowspan="1" colspan="1">OPEN</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_S</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_MMS_R</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_R</td>
              <td class="text-left" rowspan="1" colspan="1">OPEN</td>
              <td class="text-left" rowspan="1" colspan="1">curr_MMS_R</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_sendMSS</td>
              <td class="text-left" rowspan="1" colspan="1">curr_sendMSS</td>
              <td class="text-left" rowspan="1" colspan="1">MSSopt</td>
              <td class="text-left" rowspan="1" colspan="1">curr_sendMSS</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_PMTU</td>
              <td class="text-left" rowspan="1" colspan="1">curr_PMTU</td>
              <td class="text-left" rowspan="1" colspan="1">PMTUD+ / PLPMTUD+</td>
              <td class="text-left" rowspan="1" colspan="1">curr_PMTU</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTT</td>
              <td class="text-left" rowspan="1" colspan="1">curr_RTT</td>
              <td class="text-left" rowspan="1" colspan="1">update</td>
              <td class="text-left" rowspan="1" colspan="1">rtt_update(old, curr)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_RTTVAR</td>
              <td class="text-left" rowspan="1" colspan="1">curr_RTTVAR</td>
              <td class="text-left" rowspan="1" colspan="1">update</td>
              <td class="text-left" rowspan="1" colspan="1">rtt_update(old, curr)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_ssthresh</td>
              <td class="text-left" rowspan="1" colspan="1">curr_ssthresh</td>
              <td class="text-left" rowspan="1" colspan="1">update</td>
              <td class="text-left" rowspan="1" colspan="1">adjust sum as appropriate</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_sendcwnd</td>
              <td class="text-left" rowspan="1" colspan="1">curr_sendcwnd</td>
              <td class="text-left" rowspan="1" colspan="1">update</td>
              <td class="text-left" rowspan="1" colspan="1">adjust sum as appropriate</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_option</td>
              <td class="text-left" rowspan="1" colspan="1">curr_option</td>
              <td class="text-left" rowspan="1" colspan="1">(depends)</td>
              <td class="text-left" rowspan="1" colspan="1">(option specific)</td>
            </tr>
          </tbody>
        </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-7.2-3">
          <dt id="section-7.2-3.1">+</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-3.2">Note that the PMTU is cached at the IP layer <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>.<a href="#section-7.2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.2-4">
   In <a href="#Ensemble_Cache_Updates" class="xref">Table 7</a>, rtt_update() is the function
   used to combine old and current values, e.g., as a windowed average or
   exponentially decayed average.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<p id="section-7.2-5">
   <a href="#Ensemble_Option_Info_Updates" class="xref">Table 8</a> gives an overview of option-specific information
   that can be similarly shared.<a href="#section-7.2-5" class="pilcrow">¶</a></p>
<span id="name-ensemble-sharing-option-info"></span><div id="Ensemble_Option_Info_Updates">
<table class="center" id="table-8">
          <caption>
<a href="#table-8" class="selfRef">Table 8</a>:
<a href="#name-ensemble-sharing-option-info" class="selfRef">Ensemble Sharing - Option Info Updates</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cached</th>
              <th class="text-left" rowspan="1" colspan="1">Current</th>
              <th class="text-left" rowspan="1" colspan="1">When?</th>
              <th class="text-left" rowspan="1" colspan="1">New Cached</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
              <td class="text-left" rowspan="1" colspan="1">ESTAB</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_cookie</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
              <td class="text-left" rowspan="1" colspan="1">ESTAB</td>
              <td class="text-left" rowspan="1" colspan="1">old_TFO_failure</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="sect-7.3">
<section id="section-7.3">
        <h3 id="name-discussion-2">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-discussion-2" class="section-name selfRef">Discussion</a>
        </h3>
<p id="section-7.3-1">
   For ensemble sharing, TCB information should be cached as early as
   possible, sometimes before a connection is closed. Otherwise,
   opening multiple concurrent connections may not result in TCB data
   sharing if no connection closes before others open. The amount of
   work involved in updating the aggregate average should be minimized,
   but the resulting value should be equivalent to having all values
   measured within a single connection. 


The function "rtt_update" in <a href="#Ensemble_Cache_Updates" class="xref">Table 7</a> indicates this operation, which occurs whenever the RTT
would have been updated in the individual TCP connection. As a result, the
cache contains the shared RTT variables, which no longer need to reside in the
TCB.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">
   Congestion window size and ssthresh aggregation are more complicated
   in the concurrent case. When there is an ensemble of connections, we
   need to decide how that ensemble would have shared these variables,
   in order to derive initial values for new TCBs.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
<p id="section-7.3-3">
Sections <a href="#sect-8" class="xref">8</a> and <a href="#sect-9" class="xref">9</a> discuss compatibility issues and implications of sharing
the specific information listed above.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<p id="section-7.3-4">
   There are several ways to initialize the congestion window in a new TCB
   among an ensemble of current connections to a host. Current TCP
   implementations initialize it to 4 segments as standard <span>[<a href="#RFC3390" class="xref">RFC3390</a>]</span> and 10 segments experimentally <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span>. These approaches assume that new
   connections should behave as conservatively as possible.  The algorithm
   described in <span>[<a href="#Ba12" class="xref">Ba12</a>]</span> adjusts the initial
   cwnd depending on the cwnd values of ongoing connections. It is also
   possible to use sharing mechanisms over long timescales to adapt TCP's
   initial window automatically, as described further in <a href="#sect-c" class="xref">Appendix C</a>.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-8">
<section id="section-8">
      <h2 id="name-issues-with-tcb-information">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-issues-with-tcb-information" class="section-name selfRef">Issues with TCB Information Sharing</a>
      </h2>
<p id="section-8-1">
   Here, we discuss various types of problems that may arise with TCB
   information sharing.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">
   For the congestion and current window information, the initial
   values computed by TCB interdependence may not be consistent with
   the long-term aggregate behavior of a set of concurrent connections
   between the same endpoints. 



   Under conventional TCP congestion control, if the congestion window of a
   single existing connection has converged to 40 segments, two newly joining
   concurrent connections will assume initial windows of 10 segments <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span> and the existing connection's window will not decrease
   to accommodate this additional load. As a consequence, the three
   connections can mutually interfere.

   One example of this is seen on low-bandwidth, high-delay links, where
   concurrent connections supporting Web traffic can collide because their
   initial windows were too large, even when set at 1 segment.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">
   The authors of <span>[<a href="#Hu12" class="xref">Hu12</a>]</span> recommend caching
   ssthresh for temporal sharing only when flows are long. Some studies
   suggest that sharing ssthresh between short flows can deteriorate the
   performance of individual connections <span>[<a href="#Hu12" class="xref">Hu12</a>]</span> <span>[<a href="#Du16" class="xref">Du16</a>]</span>, although this may benefit aggregate
   network performance.<a href="#section-8-3" class="pilcrow">¶</a></p>
<div id="sect-8.1">
<section id="section-8.1">
        <h3 id="name-traversing-the-same-network">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-traversing-the-same-network" class="section-name selfRef">Traversing the Same Network Path</a>
        </h3>
<p id="section-8.1-1">
   TCP is sometimes used in situations where packets of the same host-pair do
   not always take the same path, such as when connection-specific parameters
   are used for routing (e.g., for load balancing).  Multipath routing that
   relies on examining transport headers, such as ECMP and Link Aggregation
   Group (LAG) <span>[<a href="#RFC7424" class="xref">RFC7424</a>]</span>, may not result in
   repeatable path selection when TCP segments are encapsulated, encrypted, or
   altered -- for example, in some Virtual Private Network (VPN) tunnels that
   rely on proprietary encapsulation. Similarly, such approaches cannot
   operate deterministically when the TCP header is encrypted, e.g., when
   using IPsec Encapsulating Security Payload (ESP) (although TCB
   interdependence among the entire set sharing the same endpoint IP addresses
   should work without problems when the TCP header is encrypted). Measures to
   increase the probability that connections use the same path could be
   applied; for example, the connections could be given the same IPv6 flow
   label <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>. TCB interdependence can
   also be extended to sets of host IP address pairs that share the same
   network path conditions, such as when a group of addresses is on the same
   LAN (see <a href="#sect-9" class="xref">Section 9</a>).<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">
   Traversing the same path is not important for host-specific information
   (e.g., rwnd), TCP option state (e.g., TFOinfo), or for information that is
   already cached per-host (e.g., path MTU).

   When TCB information is shared across different SYN destination
   ports, path-related information can be incorrect; however, the
   impact of this error is potentially diminished if (as discussed
   here) TCB sharing affects only the transient event of a connection
   start or if TCB information is shared only within connections to the
   same SYN destination port.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<p id="section-8.1-3">
   In the case of temporal sharing, TCB information could also become invalid
   over time, i.e., indicating that although the path remains the same, path
   properties have changed. Because this is similar to the case when a
   connection becomes idle, mechanisms that address idle TCP connections
   (e.g., <span>[<a href="#RFC7661" class="xref">RFC7661</a>]</span>) could also be applied to
   TCB cache management, especially when TCP Fast Open is used <span>[<a href="#RFC7413" class="xref">RFC7413</a>]</span>.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8.2">
<section id="section-8.2">
        <h3 id="name-state-dependence">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-state-dependence" class="section-name selfRef">State Dependence</a>
        </h3>
<p id="section-8.2-1">
 There may be additional considerations to the way in which TCB
 interdependence rebalances congestion feedback among the current
 connections. For example, it may be appropriate to consider the impact of a
 connection being in Fast Recovery <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>
 or some other similar unusual feedback state that could inhibit or affect the
 calculations described herein.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8.3">
<section id="section-8.3">
        <h3 id="name-problems-with-sharing-based">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-problems-with-sharing-based" class="section-name selfRef">Problems with Sharing Based on IP Address</a>
        </h3>
<p id="section-8.3-1">

   It can be wrong to share TCB information between TCP connections on the
   same host as identified by the IP address if an IP address is assigned to a
   new host (e.g., IP address spinning, as is used by ISPs to inhibit running
   servers). 

   It can be wrong if Network Address Translation (NAT) <span>[<a href="#RFC2663" class="xref">RFC2663</a>]</span>, Network Address and Port Translation (NAPT) <span>[<a href="#RFC2663" class="xref">RFC2663</a>]</span>, or any other IP sharing mechanism is
   used.

   Such mechanisms are less likely to be used with IPv6. Other methods to
   identify a host could also be considered to make correct TCB sharing more
   likely. Moreover, some TCB information is about dominant path properties
   rather than the specific host. IP addresses may differ, yet the relevant
   part of the path may be the same.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-9">
<section id="section-9">
      <h2 id="name-implications">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-implications" class="section-name selfRef">Implications</a>
      </h2>
<p id="section-9-1">
   There are several implications to incorporating TCB interdependence in TCP
   implementations. First, it may reduce the need for application-layer
   multiplexing for performance enhancement <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>. Protocols like HTTP/2
   <span>[<a href="#RFC7540" class="xref">RFC7540</a>]</span> avoid connection re-establishment costs by serializing or
   multiplexing a set of per-host connections across a single TCP
   connection. This avoids TCP's per-connection OPEN handshake and also avoids
   recomputing the MSS, RTT, and congestion window values. By avoiding the
   so-called "slow-start restart", performance can be optimized <span>[<a href="#I-D.hughes-restart" class="xref">Hu01</a>]</span>. TCB
   interdependence can provide the "slow-start restart avoidance" of
   multiplexing, without requiring a multiplexing mechanism at the application
   layer.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">

   Like the initial version of this document <span>[<a href="#RFC2140" class="xref">RFC2140</a>]</span>, this update's approach to TCB interdependence focuses
   on sharing a set of TCBs by updating the TCB state to reduce the impact of
   transients when connections begin, end, or otherwise significantly change
   state.  

   Other mechanisms have since been proposed to continuously share information
   between all ongoing communication (including connectionless protocols) and
   update the congestion state during any congestion-related event (e.g.,
   timeout, loss confirmation, etc.)  <span>[<a href="#RFC3124" class="xref">RFC3124</a>]</span>.

   By dealing exclusively with transients, the approach in this document is
   more likely to exhibit the "steady-state" behavior as unmodified,
   independent TCP connections.<a href="#section-9-2" class="pilcrow">¶</a></p>
<div id="sect-9.1">
<section id="section-9.1">
        <h3 id="name-layering">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-layering" class="section-name selfRef">Layering</a>
        </h3>
<p id="section-9.1-1">


TCB interdependence pushes some of the TCP implementation from its typical
placement solely within the transport layer (in the ISO model) to the
network layer.


   This acknowledges that some components of state are, in fact, per-host-pair
   or can be per-path as indicated solely by that host-pair.

Transport protocols typically manage per-application-pair associations (per
stream), and network protocols manage per-host-pair and path associations
(routing). Round-trip time, MSS, and congestion information could be more
appropriately handled at the network layer, aggregated among concurrent
connections, and shared across connection instances <span>[<a href="#RFC3124" class="xref">RFC3124</a>]</span>.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1-2">
   An earlier version of RTT sharing suggested implementing RTT state at the
   IP layer rather than at the TCP layer. Our observations describe sharing
   state among TCP connections, which avoids some of the difficulties in an
   IP-layer solution. One such problem of an IP-layer solution is determining
   the correspondence between packet exchanges using IP header information
   alone, where such correspondence is needed to compute RTT. Because TCB
   sharing computes RTTs inside the TCP layer using TCP header information, it
   can be implemented more directly and simply than at the IP layer.  This is
   a case where information should be computed at the transport layer but
   could be shared at the network layer.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-9.2">
<section id="section-9.2">
        <h3 id="name-other-possibilities">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-other-possibilities" class="section-name selfRef">Other Possibilities</a>
        </h3>
<p id="section-9.2-1">
   Per-host-pair associations are not the limit of these techniques. It is
   possible that TCBs could be similarly shared between hosts on a subnet or
   within a cluster, because the predominant path can be subnet-subnet rather
   than host-host. Additionally, TCB interdependence can be applied to any
   protocol with congestion state, including SCTP <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span> and DCCP <span>[<a href="#RFC4340" class="xref">RFC4340</a>]</span>, as
   well as to individual subflows in Multipath TCP <span>[<a href="#RFC8684" class="xref">RFC8684</a>]</span>.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<p id="section-9.2-2">


   There may be other information that can be shared between concurrent
   connections. For example, knowing that another connection has just
   tried to expand its window size and failed, a connection may not
   attempt to do the same for some period. The idea is that existing
   TCP implementations infer the behavior of all competing connections,
   including those within the same host or subnet. One possible
   optimization is to make that implicit feedback explicit, via
   extended information associated with the endpoint IP address and its
   TCP implementation, rather than per-connection state in the TCB.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
<p id="section-9.2-3">
   This document focuses on sharing TCB information at connection
   initialization. Subsequent to RFC 2140, there have been numerous approaches
   that attempt to coordinate ongoing state across concurrent connections,
   both within TCP and other congestion-reactive protocols, which are
   summarized in <span>[<a href="#Is18" class="xref">Is18</a>]</span>. These approaches are
   more complex to implement, and their comparison to steady-state TCP
   equivalence can be more difficult to establish, sometimes intentionally
   (i.e., they sometimes intend to provide a different kind of "fairness" than
   emerges from TCP operation).<a href="#section-9.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-10">
<section id="section-10">
      <h2 id="name-implementation-observations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-implementation-observations" class="section-name selfRef">Implementation Observations</a>
      </h2>
<p id="section-10-1">
   The observation that some TCB state is host-pair specific rather than
   application-pair dependent is not new and is a common engineering decision
   in layered protocol implementations. Although now deprecated, T/TCP <span>[<a href="#RFC1644" class="xref">RFC1644</a>]</span> was the first to propose using caches
   in order to maintain TCB states (see <a href="#sect-a" class="xref">Appendix A</a>).<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">
 <a href="#Known_Implementation_Status" class="xref">Table 9</a> describes the current
 implementation status for TCB temporal sharing in Windows as of
 December 2020, Apple variants (macOS, iOS, iPadOS, tvOS, and watchOS)
 as of January 2021, Linux kernel version 5.10.3, and FreeBSD
 12. Ensemble sharing is not yet implemented.<a href="#section-10-2" class="pilcrow">¶</a></p>
<span id="name-known-implementation-status"></span><div id="Known_Implementation_Status">
<table class="center" id="table-9">
        <caption>
<a href="#table-9" class="selfRef">Table 9</a>:
<a href="#name-known-implementation-status" class="selfRef">KNOWN IMPLEMENTATION STATUS</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">TCB data</th>
            <th class="text-left" rowspan="1" colspan="1">Status</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_MMS_S</td>
            <td class="text-left" rowspan="1" colspan="1">Not shared</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_MMS_R</td>
            <td class="text-left" rowspan="1" colspan="1">Not shared</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_sendMSS</td>
            <td class="text-left" rowspan="1" colspan="1">Cached and shared in Apple, Linux (MSS)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_PMTU</td>
            <td class="text-left" rowspan="1" colspan="1">Cached and shared in Apple, FreeBSD, Windows (PMTU)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_RTT</td>
            <td class="text-left" rowspan="1" colspan="1">Cached and shared in Apple, FreeBSD, Linux, Windows</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_RTTVAR</td>
            <td class="text-left" rowspan="1" colspan="1">Cached and shared in Apple, FreeBSD, Windows</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_TFOinfo</td>
            <td class="text-left" rowspan="1" colspan="1">Cached and shared in Apple, Linux, Windows</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_sendcwnd</td>
            <td class="text-left" rowspan="1" colspan="1">Not shared</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">old_ssthresh</td>
            <td class="text-left" rowspan="1" colspan="1">Cached and shared in Apple, FreeBSD*, Linux*</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">TFO failure</td>
            <td class="text-left" rowspan="1" colspan="1">Cached and shared in Apple</td>
          </tr>
        </tbody>
      </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-10-4">
        <dt id="section-10-4.1">*</dt>
        <dd style="margin-left: 1.5em" id="section-10-4.2">Note: 

 In FreeBSD, new ssthresh is the mean of curr_ssthresh and its previous value
 if a previous value exists; in Linux, the calculation depends on state and is
 max(curr_cwnd/2, old_ssthresh) in most cases.<a href="#section-10-4.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-10-5">In <a href="#Known_Implementation_Status" class="xref">Table 9</a>, "Apple" refers to all
Apple OSes, i.e., macOS (desktop/laptop), iOS (phone), iPadOS (tablet), tvOS
(video player), and watchOS (smart watch), which all share the same Internet
protocol stack.<a href="#section-10-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-11">
<section id="section-11">
      <h2 id="name-changes-compared-to-rfc-214">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-changes-compared-to-rfc-214" class="section-name selfRef">Changes Compared to RFC 2140</a>
      </h2>
<p id="section-11-1">
   This document updates the description of TCB sharing in RFC 2140 and its
   associated impact on existing and new connection state, providing a
   complete replacement for that document <span>[<a href="#RFC2140" class="xref">RFC2140</a>]</span>. It clarifies the previous description and terminology
   and extends the mechanism to its impact on new protocols and mechanisms,
   including multipath TCP, Fast Open, PLPMTUD, NAT, and the TCP
   Authentication Option.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">
   The detailed impact on TCB state addresses TCB parameters with greater
   specificity. It separates the way MSS is used in both send and receive
   directions, it separates the way both of these MSS values differ from
   sendMSS, it adds both path MTU and ssthresh, and it addresses the impact on
   state associated with TCP options.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">
   New sections have been added to address compatibility issues and
   implementation observations. 

   The relation of this work to T/TCP has been moved to <a href="#sect-a" class="xref">Appendix A</a> (which describes the history to TCB sharing) partly to
   reflect the deprecation of that protocol.<a href="#section-11-3" class="pilcrow">¶</a></p>
<p id="section-11-4">
   <a href="#sect-c" class="xref">Appendix C</a> has been added to discuss the potential to use temporal
   sharing over long timescales to adapt TCP's initial window
   automatically, avoiding the need to periodically revise a single
   global constant value.<a href="#section-11-4" class="pilcrow">¶</a></p>
<p id="section-11-5">
   Finally, this document updates and significantly expands the
   referenced literature.<a href="#section-11-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-12">
<section id="section-12">
      <h2 id="name-security-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-12-1">
   These presented implementation methods do not have additional ramifications
   for direct (connection-aborting or information-injecting) attacks on
   individual connections. Individual connections, whether using sharing or
   not, also may be susceptible to denial-of-service attacks that reduce
   performance or completely deny connections and transfers if not otherwise
   secured.<a href="#section-12-1" class="pilcrow">¶</a></p>
<p id="section-12-2">
   TCB sharing may create additional denial-of-service attacks that affect the
   performance of other connections by polluting the cached information. This
   can occur across any set of connections in which the TCB is shared,
   between connections in a single host, or between hosts if TCB sharing is
   implemented within a subnet (see <span><a href="#sect-9" class="xref">"Implications"</a> (<a href="#sect-9" class="xref">Section 9</a>)</span>). Some shared TCB parameters are
   used only to create new TCBs; others are shared among the TCBs of ongoing
   connections. New connections can join the ongoing set, e.g., to optimize
   send window size among a set of connections to the same host. PMTU is
   defined as shared at the IP layer and is already susceptible in this
   way.<a href="#section-12-2" class="pilcrow">¶</a></p>
<p id="section-12-3">
   Options in client SYNs can be easier to forge than complete, two-way
   connections. As a result, their values may not be safely
   incorporated in shared values until after the three-way handshake
   completes.<a href="#section-12-3" class="pilcrow">¶</a></p>
<p id="section-12-4">
   Attacks on parameters used only for initialization affect only the
   transient performance of a TCP connection. For short connections, the
   performance ramification can approach that of a denial-of-service
   attack. For example, if an application changes its TCB to have a false and small
   window size, subsequent connections will experience performance degradation
   until their window grows appropriately.<a href="#section-12-4" class="pilcrow">¶</a></p>
<p id="section-12-5">
   TCB sharing reuses and mixes information from past and current
   connections. Although reusing information could create a potential
   for fingerprinting to identify hosts, the mixing reduces that
   potential. There has been no evidence of fingerprinting based on
   this technique, and it is currently considered safe in that regard.
   Further, information about the performance of a TCP connection has
   not been considered as private.<a href="#section-12-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-13">
<section id="section-13">
      <h2 id="name-iana-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-13-1">
   This document has no IANA actions.<a href="#section-13-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-14">
      <h2 id="name-references">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-14.1">
        <h3 id="name-normative-references">
<a href="#section-14.1" class="section-number selfRef">14.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC0793">[RFC0793]</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="RFC1122">[RFC1122]</dt>
        <dd>
<span class="refAuthor">Braden, R., Ed.</span>, <span class="refTitle">"Requirements for Internet Hosts - Communication Layers"</span>, <span class="seriesInfo">STD 3</span>, <span class="seriesInfo">RFC 1122</span>, <span class="seriesInfo">DOI 10.17487/RFC1122</span>, <time datetime="1989-10" class="refDate">October 1989</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1122">https://www.rfc-editor.org/info/rfc1122</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1191">[RFC1191]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span> and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"Path MTU discovery"</span>, <span class="seriesInfo">RFC 1191</span>, <span class="seriesInfo">DOI 10.17487/RFC1191</span>, <time datetime="1990-11" class="refDate">November 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1191">https://www.rfc-editor.org/info/rfc1191</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="RFC4821">[RFC4821]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span> and <span class="refAuthor">J. Heffner</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery"</span>, <span class="seriesInfo">RFC 4821</span>, <span class="seriesInfo">DOI 10.17487/RFC4821</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4821">https://www.rfc-editor.org/info/rfc4821</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>, and <span class="refAuthor">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>, and <span class="refAuthor">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="RFC7413">[RFC7413]</dt>
        <dd>
<span class="refAuthor">Cheng, Y.</span>, <span class="refAuthor">Chu, J.</span>, <span class="refAuthor">Radhakrishnan, S.</span>, and <span class="refAuthor">A. Jain</span>, <span class="refTitle">"TCP Fast Open"</span>, <span class="seriesInfo">RFC 7413</span>, <span class="seriesInfo">DOI 10.17487/RFC7413</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7413">https://www.rfc-editor.org/info/rfc7413</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8201">[RFC8201]</dt>
      <dd>
<span class="refAuthor">McCann, J.</span>, <span class="refAuthor">Deering, S.</span>, <span class="refAuthor">Mogul, J.</span>, and <span class="refAuthor">R. Hinden, Ed.</span>, <span class="refTitle">"Path MTU Discovery for IP version 6"</span>, <span class="seriesInfo">STD 87</span>, <span class="seriesInfo">RFC 8201</span>, <span class="seriesInfo">DOI 10.17487/RFC8201</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8201">https://www.rfc-editor.org/info/rfc8201</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-14.2">
        <h3 id="name-informative-references">
<a href="#section-14.2" class="section-number selfRef">14.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.allman-tcpm-bump-initcwnd">[Al10]</dt>
        <dd>
<span class="refAuthor">Allman, M.</span>, <span class="refTitle">"Initial Congestion Window Specification"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-allman-tcpm-bump-initcwnd-00</span>, <time datetime="2010-11-15" class="refDate">15 November 2010</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-allman-tcpm-bump-initcwnd-00">https://datatracker.ietf.org/doc/html/draft-allman-tcpm-bump-initcwnd-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Ba12">[Ba12]</dt>
        <dd>
<span class="refAuthor">Barik, R.</span>, <span class="refAuthor">Welzl, M.</span>, <span class="refAuthor">Ferlin, S.</span>, and <span class="refAuthor">O. Alay</span>, <span class="refTitle">"LISA: A linked slow-start algorithm for MPTCP"</span>, <span class="refContent">IEEE ICC
</span>, <span class="seriesInfo">DOI 10.1109/ICC.2016.7510786</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://doi.org/10.1109/ICC.2016.7510786">https://doi.org/10.1109/ICC.2016.7510786</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tcpm-generalized-ecn">[Ba20]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span> and <span class="refAuthor">B. Briscoe</span>, <span class="refTitle">"ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tcpm-generalized-ecn-07</span>, <time datetime="2021-02-16" class="refDate">16 February 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07">https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Be94">[Be94]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Cailliau, C.</span>, <span class="refAuthor">Luotonen, A.</span>, <span class="refAuthor">Nielsen, H.</span>, and <span class="refAuthor">A. Secret</span>, <span class="refTitle">"The World-Wide Web"</span>, <span class="refContent">Communications of the ACM V37, pp. 76-82</span>, <span class="seriesInfo">DOI 10.1145/179606.179671</span>, <time datetime="1994-08" class="refDate">August 1994</time>, <span>&lt;<a href="https://doi.org/10.1145/179606.179671">https://doi.org/10.1145/179606.179671</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Br02">[Br02]</dt>
        <dd>
<span class="refAuthor">Brownlee, N.</span> and <span class="refAuthor">KC. Claffy</span>, <span class="refTitle">"Understanding Internet traffic streams: dragonflies and tortoises"</span>, <span class="refContent">IEEE Communications Magazine, pp. 110-117</span>, <span class="seriesInfo">DOI 10.1109/MCOM.2002.1039865</span>, <time datetime="2002" class="refDate">2002</time>, <span>&lt;<a href="https://doi.org/10.1109/MCOM.2002.1039865">https://doi.org/10.1109/MCOM.2002.1039865</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Br94">[Br94]</dt>
        <dd>
<span class="refAuthor">Braden, B.</span>, <span class="refTitle">"T/TCP -- Transaction TCP: Source Changes for Sun OS 4.1.3"</span>, <span class="refContent">USC/ISI Release 1.0</span>, <time datetime="1994-09" class="refDate">September 1994</time>. </dd>
<dd class="break"></dd>
<dt id="Co91">[Co91]</dt>
        <dd>
<span class="refAuthor">Comer, D.</span> and <span class="refAuthor">D. Stevens</span>, <span class="refTitle">"Internetworking with TCP/IP"</span>, <span class="seriesInfo">ISBN 10: 0134685059</span>, <span class="seriesInfo">ISBN 13: 9780134685052</span>, <time datetime="1991" class="refDate">1991</time>. </dd>
<dd class="break"></dd>
<dt id="Du16">[Du16]</dt>
        <dd>
<span class="refAuthor">Dukkipati, N.</span>, <span class="refAuthor">Cheng, Y.</span>, and <span class="refAuthor">A. Vahdat</span>, <span class="refTitle">"Research Impacting the Practice of Congestion Control"</span>, <span class="refContent">Computer Communication Review</span>, <span class="refContent">The ACM SIGCOMM newsletter</span>, <time datetime="2016-07" class="refDate">July 2016</time>. </dd>
<dd class="break"></dd>
<dt id="FreeBSD">[FreeBSD]</dt>
        <dd>
<span class="refAuthor">FreeBSD</span>, <span class="refTitle">"The FreeBSD Project"</span>, <span>&lt;<a href="https://www.freebsd.org/">https://www.freebsd.org/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.hughes-restart">[Hu01]</dt>
        <dd>
<span class="refAuthor">Hughes, A.</span>, <span class="refAuthor">Touch, J.</span>, and <span class="refAuthor">J. Heidemann</span>, <span class="refTitle">"Issues in TCP Slow-Start Restart After Idle"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-hughes-restart-00</span>, <time datetime="2001-12" class="refDate">December 2001</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-hughes-restart-00">https://datatracker.ietf.org/doc/html/draft-hughes-restart-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Hu12">[Hu12]</dt>
        <dd>
<span class="refAuthor">Hurtig, P.</span> and <span class="refAuthor">A. Brunstrom</span>, <span class="refTitle">"Enhanced metric caching for short TCP flows"</span>, <span class="refContent">IEEE International Conference on Communications</span>, <span class="seriesInfo">DOI 10.1109/ICC.2012.6364516</span>, <time datetime="2012" class="refDate">2012</time>, <span>&lt;<a href="https://doi.org/10.1109/ICC.2012.6364516">https://doi.org/10.1109/ICC.2012.6364516</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA">[IANA]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Transmission Control Protocol (TCP) Parameters"</span>, <span>&lt;<a href="https://www.iana.org/assignments/tcp-parameters">https://www.iana.org/assignments/tcp-parameters</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Is18">[Is18]</dt>
        <dd>
<span class="refAuthor">Islam, S.</span>, <span class="refAuthor">Welzl, M.</span>, <span class="refAuthor">Hiorth, K.</span>, <span class="refAuthor">Hayes, D.</span>, <span class="refAuthor">Armitage, G.</span>, and <span class="refAuthor">S. Gjessing</span>, <span class="refTitle">"ctrlTCP: Reducing latency through coupled, heterogeneous multi-flow TCP congestion control"</span>, <span class="refContent">IEEE INFOCOM 2018 - IEEE Conference on Computer
          Communications Workshops (INFOCOM WKSHPS)</span>, <span class="seriesInfo">DOI 10.1109/INFCOMW.2018.8406887</span>, <time datetime="2018-04" class="refDate">April 2018</time>, <span>&lt;<a href="https://doi.org/10.1109/INFCOMW.2018.8406887">https://doi.org/10.1109/INFCOMW.2018.8406887</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Ja88">[Ja88]</dt>
        <dd>
<span class="refAuthor">Jacobson, V.</span> and <span class="refAuthor">M. Karels</span>, <span class="refTitle">"Congestion Avoidance and Control"</span>, <span class="refContent">SIGCOMM Symposium proceedings on Communications
   architectures and protocols
          </span>, <time datetime="1988-11" class="refDate">November 1988</time>. </dd>
<dd class="break"></dd>
<dt id="RFC1379">[RFC1379]</dt>
        <dd>
<span class="refAuthor">Braden, R.</span>, <span class="refTitle">"Extending TCP for Transactions -- Concepts"</span>, <span class="seriesInfo">RFC 1379</span>, <span class="seriesInfo">DOI 10.17487/RFC1379</span>, <time datetime="1992-11" class="refDate">November 1992</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1379">https://www.rfc-editor.org/info/rfc1379</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1644">[RFC1644]</dt>
        <dd>
<span class="refAuthor">Braden, R.</span>, <span class="refTitle">"T/TCP -- TCP Extensions for Transactions Functional Specification"</span>, <span class="seriesInfo">RFC 1644</span>, <span class="seriesInfo">DOI 10.17487/RFC1644</span>, <time datetime="1994-07" class="refDate">July 1994</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1644">https://www.rfc-editor.org/info/rfc1644</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2001">[RFC2001]</dt>
        <dd>
<span class="refAuthor">Stevens, W.</span>, <span class="refTitle">"TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms"</span>, <span class="seriesInfo">RFC 2001</span>, <span class="seriesInfo">DOI 10.17487/RFC2001</span>, <time datetime="1997-01" class="refDate">January 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2001">https://www.rfc-editor.org/info/rfc2001</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2140">[RFC2140]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refTitle">"TCP Control Block Interdependence"</span>, <span class="seriesInfo">RFC 2140</span>, <span class="seriesInfo">DOI 10.17487/RFC2140</span>, <time datetime="1997-04" class="refDate">April 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2140">https://www.rfc-editor.org/info/rfc2140</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2414">[RFC2414]</dt>
        <dd>
<span class="refAuthor">Allman, M.</span>, <span class="refAuthor">Floyd, S.</span>, and <span class="refAuthor">C. Partridge</span>, <span class="refTitle">"Increasing TCP's Initial Window"</span>, <span class="seriesInfo">RFC 2414</span>, <span class="seriesInfo">DOI 10.17487/RFC2414</span>, <time datetime="1998-09" class="refDate">September 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2414">https://www.rfc-editor.org/info/rfc2414</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2663">[RFC2663]</dt>
        <dd>
<span class="refAuthor">Srisuresh, P.</span> and <span class="refAuthor">M. Holdrege</span>, <span class="refTitle">"IP Network Address Translator (NAT) Terminology and Considerations"</span>, <span class="seriesInfo">RFC 2663</span>, <span class="seriesInfo">DOI 10.17487/RFC2663</span>, <time datetime="1999-08" class="refDate">August 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2663">https://www.rfc-editor.org/info/rfc2663</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3124">[RFC3124]</dt>
        <dd>
<span class="refAuthor">Balakrishnan, H.</span> and <span class="refAuthor">S. Seshan</span>, <span class="refTitle">"The Congestion Manager"</span>, <span class="seriesInfo">RFC 3124</span>, <span class="seriesInfo">DOI 10.17487/RFC3124</span>, <time datetime="2001-06" class="refDate">June 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3124">https://www.rfc-editor.org/info/rfc3124</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3390">[RFC3390]</dt>
        <dd>
<span class="refAuthor">Allman, M.</span>, <span class="refAuthor">Floyd, S.</span>, and <span class="refAuthor">C. Partridge</span>, <span class="refTitle">"Increasing TCP's Initial Window"</span>, <span class="seriesInfo">RFC 3390</span>, <span class="seriesInfo">DOI 10.17487/RFC3390</span>, <time datetime="2002-10" class="refDate">October 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3390">https://www.rfc-editor.org/info/rfc3390</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4340">[RFC4340]</dt>
        <dd>
<span class="refAuthor">Kohler, E.</span>, <span class="refAuthor">Handley, M.</span>, and <span class="refAuthor">S. Floyd</span>, <span class="refTitle">"Datagram Congestion Control Protocol (DCCP)"</span>, <span class="seriesInfo">RFC 4340</span>, <span class="seriesInfo">DOI 10.17487/RFC4340</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4340">https://www.rfc-editor.org/info/rfc4340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4960">[RFC4960]</dt>
        <dd>
<span class="refAuthor">Stewart, R., Ed.</span>, <span class="refTitle">"Stream Control Transmission Protocol"</span>, <span class="seriesInfo">RFC 4960</span>, <span class="seriesInfo">DOI 10.17487/RFC4960</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4960">https://www.rfc-editor.org/info/rfc4960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5925">[RFC5925]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refAuthor">Mankin, A.</span>, and <span class="refAuthor">R. Bonica</span>, <span class="refTitle">"The TCP Authentication Option"</span>, <span class="seriesInfo">RFC 5925</span>, <span class="seriesInfo">DOI 10.17487/RFC5925</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5925">https://www.rfc-editor.org/info/rfc5925</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6437">[RFC6437]</dt>
        <dd>
<span class="refAuthor">Amante, S.</span>, <span class="refAuthor">Carpenter, B.</span>, <span class="refAuthor">Jiang, S.</span>, and <span class="refAuthor">J. Rajahalme</span>, <span class="refTitle">"IPv6 Flow Label Specification"</span>, <span class="seriesInfo">RFC 6437</span>, <span class="seriesInfo">DOI 10.17487/RFC6437</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6437">https://www.rfc-editor.org/info/rfc6437</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6691">[RFC6691]</dt>
        <dd>
<span class="refAuthor">Borman, D.</span>, <span class="refTitle">"TCP Options and Maximum Segment Size (MSS)"</span>, <span class="seriesInfo">RFC 6691</span>, <span class="seriesInfo">DOI 10.17487/RFC6691</span>, <time datetime="2012-07" class="refDate">July 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6691">https://www.rfc-editor.org/info/rfc6691</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6928">[RFC6928]</dt>
        <dd>
<span class="refAuthor">Chu, J.</span>, <span class="refAuthor">Dukkipati, N.</span>, <span class="refAuthor">Cheng, Y.</span>, and <span class="refAuthor">M. Mathis</span>, <span class="refTitle">"Increasing TCP's Initial Window"</span>, <span class="seriesInfo">RFC 6928</span>, <span class="seriesInfo">DOI 10.17487/RFC6928</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6928">https://www.rfc-editor.org/info/rfc6928</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7231">[RFC7231]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span> and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"</span>, <span class="seriesInfo">RFC 7231</span>, <span class="seriesInfo">DOI 10.17487/RFC7231</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</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>, and <span class="refAuthor">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="RFC7424">[RFC7424]</dt>
        <dd>
<span class="refAuthor">Krishnan, R.</span>, <span class="refAuthor">Yong, L.</span>, <span class="refAuthor">Ghanwani, A.</span>, <span class="refAuthor">So, N.</span>, and <span class="refAuthor">B. Khasnabish</span>, <span class="refTitle">"Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks"</span>, <span class="seriesInfo">RFC 7424</span>, <span class="seriesInfo">DOI 10.17487/RFC7424</span>, <time datetime="2015-01" class="refDate">January 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7424">https://www.rfc-editor.org/info/rfc7424</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7540">[RFC7540]</dt>
        <dd>
<span class="refAuthor">Belshe, M.</span>, <span class="refAuthor">Peon, R.</span>, and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol Version 2 (HTTP/2)"</span>, <span class="seriesInfo">RFC 7540</span>, <span class="seriesInfo">DOI 10.17487/RFC7540</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7540">https://www.rfc-editor.org/info/rfc7540</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7661">[RFC7661]</dt>
        <dd>
<span class="refAuthor">Fairhurst, G.</span>, <span class="refAuthor">Sathiaseelan, A.</span>, and <span class="refAuthor">R. Secchi</span>, <span class="refTitle">"Updating TCP to Support Rate-Limited Traffic"</span>, <span class="seriesInfo">RFC 7661</span>, <span class="seriesInfo">DOI 10.17487/RFC7661</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7661">https://www.rfc-editor.org/info/rfc7661</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8684">[RFC8684]</dt>
      <dd>
<span class="refAuthor">Ford, A.</span>, <span class="refAuthor">Raiciu, C.</span>, <span class="refAuthor">Handley, M.</span>, <span class="refAuthor">Bonaventure, O.</span>, and <span class="refAuthor">C. Paasch</span>, <span class="refTitle">"TCP Extensions for Multipath Operation with Multiple Addresses"</span>, <span class="seriesInfo">RFC 8684</span>, <span class="seriesInfo">DOI 10.17487/RFC8684</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8684">https://www.rfc-editor.org/info/rfc8684</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="sect-a">
<section id="appendix-A">
      <h2 id="name-tcb-sharing-history">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-tcb-sharing-history" class="section-name selfRef">TCB Sharing History</a>
      </h2>
<p id="appendix-A-1">
   T/TCP proposed using caches to maintain TCB information across instances
   (temporal sharing), e.g., smoothed RTT, RTT variation, congestion-avoidance
   threshold, and MSS <span>[<a href="#RFC1644" class="xref">RFC1644</a>]</span>. These values
   were in addition to connection counts used by T/TCP to accelerate data
   delivery prior to the full three-way handshake during an OPEN. The goal was
   to aggregate TCB components where they reflect one association -- that of the
   host-pair rather than artificially separating those components by
   connection.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">
   At least one T/TCP implementation saved the MSS and aggregated the
   RTT parameters across multiple connections but omitted caching the
   congestion window information <span>[<a href="#Br94" class="xref">Br94</a>]</span>, as originally specified in
   <span>[<a href="#RFC1379" class="xref">RFC1379</a>]</span>. Some T/TCP implementations immediately updated MSS when
   the TCP MSS header option was received <span>[<a href="#Br94" class="xref">Br94</a>]</span>, although this was not
   addressed specifically in the concepts or functional specification
   <span>[<a href="#RFC1379" class="xref">RFC1379</a>]</span> <span>[<a href="#RFC1644" class="xref">RFC1644</a>]</span>. In later T/TCP implementations, RTT values were
   updated only after a CLOSE, which does not benefit concurrent
   sessions.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">
   Temporal sharing of cached TCB data was originally implemented in the Sun
   OS 4.1.3 T/TCP extensions <span>[<a href="#Br94" class="xref">Br94</a>]</span> and the
   FreeBSD port of same <span>[<a href="#FreeBSD" class="xref">FreeBSD</a>]</span>. As
   mentioned before, only the MSS and RTT parameters were cached, as originally
   specified in <span>[<a href="#RFC1379" class="xref">RFC1379</a>]</span>. Later discussion of
   T/TCP suggested including congestion control parameters in this cache; for
   example, <span><a href="https://www.rfc-editor.org/rfc/rfc1644#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC1644" class="xref">RFC1644</a>]</span> hints at initializing the congestion window to the old
   window size.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-b">
<section id="appendix-B">
      <h2 id="name-tcp-option-sharing-and-cach">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-tcp-option-sharing-and-cach" class="section-name selfRef">TCP Option Sharing and Caching</a>
      </h2>
<p id="appendix-B-1">
   In addition to the options that can be cached and shared, this memo also
   lists known TCP options <span>[<a href="#IANA" class="xref">IANA</a>]</span> for which
   state is unsafe to be kept. This list is not intended to be authoritative
   or exhaustive.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">Obsolete (unsafe to keep state):<a href="#appendix-B-2" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="appendix-B-3.1">Echo<a href="#appendix-B-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.2">Echo Reply<a href="#appendix-B-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.3">Partial Order Connection Permitted<a href="#appendix-B-3.3" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.4">Partial Order Service Profile<a href="#appendix-B-3.4" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.5">CC<a href="#appendix-B-3.5" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.6">CC.NEW<a href="#appendix-B-3.6" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.7">CC.ECHO<a href="#appendix-B-3.7" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.8">TCP Alternate Checksum Request<a href="#appendix-B-3.8" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-3.9">TCP Alternate Checksum Data<a href="#appendix-B-3.9" class="pilcrow">¶</a>
</li>
      </ul>
<p id="appendix-B-4">No state to keep:<a href="#appendix-B-4" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="appendix-B-5.1">End of Option List (EOL)<a href="#appendix-B-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.2">No-Operation (NOP)<a href="#appendix-B-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.3">Window Scale (WS)<a href="#appendix-B-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.4">SACK<a href="#appendix-B-5.4" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.5">Timestamps (TS)<a href="#appendix-B-5.5" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.6">MD5 Signature Option<a href="#appendix-B-5.6" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.7">TCP Authentication Option (TCP-AO)<a href="#appendix-B-5.7" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.8">RFC3692-style Experiment 1<a href="#appendix-B-5.8" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-5.9">RFC3692-style Experiment 2<a href="#appendix-B-5.9" class="pilcrow">¶</a>
</li>
      </ul>
<p id="appendix-B-6">Unsafe to keep state:<a href="#appendix-B-6" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="appendix-B-7.1">Skeeter (DH exchange, known to be vulnerable)<a href="#appendix-B-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.2">Bubba (DH exchange, known to be vulnerable)<a href="#appendix-B-7.2" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.3">Trailer Checksum Option<a href="#appendix-B-7.3" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.4">SCPS capabilities<a href="#appendix-B-7.4" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.5">Selective Negative Acknowledgements (S-NACK)<a href="#appendix-B-7.5" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.6">Records Boundaries<a href="#appendix-B-7.6" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.7">Corruption experienced<a href="#appendix-B-7.7" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.8">SNAP<a href="#appendix-B-7.8" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.9">TCP Compression Filter<a href="#appendix-B-7.9" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.10">Quick-Start Response<a href="#appendix-B-7.10" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.11">User Timeout Option (UTO)<a href="#appendix-B-7.11" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.12">Multipath TCP (MPTCP) negotiation success (see below for negotiation failure)<a href="#appendix-B-7.12" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-7.13">TCP Fast Open (TFO) negotiation success (see below for negotiation failure)<a href="#appendix-B-7.13" class="pilcrow">¶</a>
</li>
      </ul>
<p id="appendix-B-8">Safe but optional to keep state:<a href="#appendix-B-8" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="appendix-B-9.1">Multipath TCP (MPTCP) negotiation failure (to avoid negotiation retries)<a href="#appendix-B-9.1" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-9.2">Maximum Segment Size (MSS)<a href="#appendix-B-9.2" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="appendix-B-9.3">TCP Fast Open (TFO) negotiation failure (to avoid negotiation retries)<a href="#appendix-B-9.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="appendix-B-10">Safe and necessary to keep state:<a href="#appendix-B-10" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="appendix-B-11.1">TCP Fast Open (TFO) Cookie (if TFO succeeded in the past)<a href="#appendix-B-11.1" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="sect-c">
<section id="appendix-C">
      <h2 id="name-automating-the-initial-wind">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-automating-the-initial-wind" class="section-name selfRef">Automating the Initial Window in TCP over Long Timescales</a>
      </h2>
<div id="sect-c.1">
<section id="appendix-C.1">
        <h3 id="name-introduction-2">
<a href="#appendix-C.1" class="section-number selfRef">C.1. </a><a href="#name-introduction-2" class="section-name selfRef">Introduction</a>
        </h3>
<p id="appendix-C.1-1">
   Temporal sharing, as described earlier in this document, builds on
   the assumption that multiple consecutive connections between the
   same host-pair are somewhat likely to be exposed to similar
   environment characteristics. The stored information can become less
   accurate over time and suitable precautions should take this aging
   into consideration (this is discussed further in <a href="#sect-8.1" class="xref">Section 8.1</a>).
   However, there are also cases where it can make sense to track these
   values over longer periods, observing properties of TCP connections
   to gradually influence evolving trends in TCP parameters. This
   appendix describes an example of such a case.<a href="#appendix-C.1-1" class="pilcrow">¶</a></p>
<p id="appendix-C.1-2">
   TCP's congestion control algorithm uses an initial window value
   (IW) both as a starting point for new connections and as an upper
   limit for restarting after an idle period <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> <span>[<a href="#RFC7661" class="xref">RFC7661</a>]</span>. This
   value has evolved over time; it was originally 1 maximum segment size
   (MSS) and increased to the lesser of 4 MSSs or 4,380 bytes
   <span>[<a href="#RFC3390" class="xref">RFC3390</a>]</span> <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>. For a typical Internet connection with a maximum
   transmission unit (MTU) of 1500 bytes, this permits 3 segments
   of 1,460 bytes each.<a href="#appendix-C.1-2" class="pilcrow">¶</a></p>
<p id="appendix-C.1-3">
   The IW value was originally implied in the original TCP congestion control
   description and documented as a standard in 1997 <span>[<a href="#RFC2001" class="xref">RFC2001</a>]</span> <span>[<a href="#Ja88" class="xref">Ja88</a>]</span>. The value was
   updated in 1998 experimentally and moved to the Standards Track in 2002
   <span>[<a href="#RFC2414" class="xref">RFC2414</a>]</span> <span>[<a href="#RFC3390" class="xref">RFC3390</a>]</span>. In 2013, it was experimentally increased to 10 <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span>.<a href="#appendix-C.1-3" class="pilcrow">¶</a></p>
<p id="appendix-C.1-4">
   This appendix discusses how TCP can objectively measure when an IW
   is too large and that such feedback should be used over long
   timescales to adjust the IW automatically. The result should be
   safer to deploy and might avoid the need to repeatedly revisit IW
   over time.<a href="#appendix-C.1-4" class="pilcrow">¶</a></p>
<p id="appendix-C.1-5">
   Note that this mechanism attempts to make the IW more adaptive over
   time. It can increase the IW beyond that which is currently
   recommended for wide-scale deployment, so its use should be
   carefully monitored.<a href="#appendix-C.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-c.2">
<section id="appendix-C.2">
        <h3 id="name-design-considerations">
<a href="#appendix-C.2" class="section-number selfRef">C.2. </a><a href="#name-design-considerations" class="section-name selfRef">Design Considerations</a>
        </h3>
<p id="appendix-C.2-1">
   TCP's IW value has existed statically for over two decades, so any
   solution to adjusting the IW dynamically should have similarly
   stable, non-invasive effects on the performance and complexity of
   TCP. In order to be fair, the IW should be similar for most machines
   on the public Internet. Finally, a desirable goal is to develop a
   self-correcting algorithm so that IW values that cause network
   problems can be avoided. To that end, we propose the following
   design goals:<a href="#appendix-C.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C.2-2.1">Impart little to no impact to TCP in the absence of loss, i.e.,
      it should not increase the complexity of default packet
      processing in the normal case.<a href="#appendix-C.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.2-2.2">Adapt to network feedback over long timescales, avoiding values
      that persistently cause network problems.<a href="#appendix-C.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.2-2.3">Decrease the IW in the presence of sustained loss of IW segments,
          as determined over a number of different connections.<a href="#appendix-C.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.2-2.4">Increase the IW in the absence of sustained loss of IW segments,
          as determined over a number of different connections.<a href="#appendix-C.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.2-2.5">Operate conservatively, i.e., tend towards leaving the IW the
      same in the absence of sufficient information, and give greater
      consideration to IW segment loss than IW segment success.<a href="#appendix-C.2-2.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="appendix-C.2-3">
   We expect that, without other context, a good IW algorithm will
   converge to a single value, but this is not required. An endpoint
   with additional context or information, or deployed in a constrained
   environment, can always use a different value. In particular,
   information from previous connections, or sets of connections with a
   similar path, can already be used as context for such decisions (as
   noted in the core of this document).<a href="#appendix-C.2-3" class="pilcrow">¶</a></p>
<p id="appendix-C.2-4">
   However, if a given IW value persistently causes packet loss during
   the initial burst of packets, it is clearly inappropriate and could
   be inducing unnecessary loss in other competing connections. This
   might happen for sites behind very slow boxes with small buffers,
   which may or may not be the first hop.<a href="#appendix-C.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-c.3">
<section id="appendix-C.3">
        <h3 id="name-proposed-iw-algorithm">
<a href="#appendix-C.3" class="section-number selfRef">C.3. </a><a href="#name-proposed-iw-algorithm" class="section-name selfRef">Proposed IW Algorithm</a>
        </h3>
<p id="appendix-C.3-1">
   Below is a simple description of the proposed IW algorithm. It
   relies on the following parameters:<a href="#appendix-C.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C.3-2.1">MinIW = 3 MSS or 4,380 bytes (as per <span>[<a href="#RFC3390" class="xref">RFC3390</a>]</span>)<a href="#appendix-C.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.3-2.2">MaxIW = 10 MSS (as per <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span>)<a href="#appendix-C.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.3-2.3">MulDecr = 0.5<a href="#appendix-C.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.3-2.4">AddIncr = 2 MSS<a href="#appendix-C.3-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="appendix-C.3-2.5">Threshold = 0.05<a href="#appendix-C.3-2.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="appendix-C.3-3">
   We assume that the minimum IW (MinIW) should be as currently specified as
   standard <span>[<a href="#RFC3390" class="xref">RFC3390</a>]</span>. The maximum IW (MaxIW) can be
   set to a fixed value (we suggest using the experimental and now somewhat de
   facto standard in <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span>) or set based
   on a schedule if trusted time references are available <span>[<a href="#I-D.allman-tcpm-bump-initcwnd" class="xref">Al10</a>]</span>; here, we prefer
   a fixed value.  We also propose to use an Additive Increase Multiplicative
   Decrease (AIMD) algorithm, with increase and decreases as noted.<a href="#appendix-C.3-3" class="pilcrow">¶</a></p>
<p id="appendix-C.3-4">
   Although these parameters are somewhat arbitrary, their initial
   values are not important except that the algorithm is AIMD and the
   MaxIW should not exceed that recommended for other systems on the
   Internet (here, we selected the current de facto standard rather than
   the actual standard). Current proposals, including default current
   operation, are degenerate cases of the algorithm below for given
   parameters, notably MulDec = 1.0 and AddIncr = 0 MSS, thus
   disabling the automatic part of the algorithm.<a href="#appendix-C.3-4" class="pilcrow">¶</a></p>
<p id="appendix-C.3-5">
   The proposed algorithm is as follows:<a href="#appendix-C.3-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-C.3-6">

<li id="appendix-C.3-6.1">
            <p id="appendix-C.3-6.1.1">On boot:<a href="#appendix-C.3-6.1.1" class="pilcrow">¶</a></p>
<div id="appendix-C.3-6.1.2">
<pre class="sourcecode lang-pseudocode">
   IW = MaxIW; # assume this is in bytes and indicates an integer
               # multiple of 2 MSS (an even number to support
               # ACK compression)
</pre><a href="#appendix-C.3-6.1.2" class="pilcrow">¶</a>
</div>
</li>
          <li id="appendix-C.3-6.2">
            <p id="appendix-C.3-6.2.1">Upon starting a new connection:<a href="#appendix-C.3-6.2.1" class="pilcrow">¶</a></p>
<div id="appendix-C.3-6.2.2">
<pre class="sourcecode lang-pseudocode">
   CWND = IW;
   conncount++;
   IWnotchecked = 1; # true
</pre><a href="#appendix-C.3-6.2.2" class="pilcrow">¶</a>
</div>
</li>
          <li id="appendix-C.3-6.3">
            <p id="appendix-C.3-6.3.1">During a connection's SYN-ACK processing, if SYN-ACK includes ECN (as
similarly addressed in Section 5 of ECN++ for TCP <span>[<a href="#I-D.ietf-tcpm-generalized-ecn" class="xref">Ba20</a>]</span>), treat as if the IW is too large:<a href="#appendix-C.3-6.3.1" class="pilcrow">¶</a></p>
<div id="appendix-C.3-6.3.2">
<pre class="sourcecode lang-pseudocode">
   if (IWnotchecked &amp;&amp; (synackecn == 1)) {
      losscount++;
      IWnotchecked = 0; # never check again
   }
</pre><a href="#appendix-C.3-6.3.2" class="pilcrow">¶</a>
</div>
</li>
          <li id="appendix-C.3-6.4">
            <p id="appendix-C.3-6.4.1">During a connection, if retransmission occurs, check the seqno of the
outgoing packet (in bytes) to see if the re-sent segment fixes an IW loss:<a href="#appendix-C.3-6.4.1" class="pilcrow">¶</a></p>
<div id="appendix-C.3-6.4.2">
<pre class="sourcecode lang-pseudocode">
   if (Retransmitting &amp;&amp; IWnotchecked &amp;&amp; ((seqno - ISN) &lt; IW))) {
      losscount++;
      IWnotchecked = 0; # never do this entire "if" again
   } else {
      IWnotchecked = 0; # you're beyond the IW so stop checking
   }
</pre><a href="#appendix-C.3-6.4.2" class="pilcrow">¶</a>
</div>
</li>
          <li id="appendix-C.3-6.5">
            <p id="appendix-C.3-6.5.1">Once every 1000 connections, as a separate process (i.e., not as part of
processing a given connection):<a href="#appendix-C.3-6.5.1" class="pilcrow">¶</a></p>
<div id="appendix-C.3-6.5.2">
<pre class="sourcecode lang-pseudocode">
   if (conncount &gt; 1000) {
      if (losscount/conncount &gt; threshold) {
         # the number of connections with errors is too high
         IW = IW * MulDecr;
      } else {
         IW = IW + AddIncr;
      }
   }
</pre><a href="#appendix-C.3-6.5.2" class="pilcrow">¶</a>
</div>
</li>
        </ol>
<p id="appendix-C.3-7">
   As presented, this algorithm can yield a false positive when the sequence
   number wraps around, e.g., the code might increment losscount in step 4
   when no loss occurred or fail to increment losscount when a loss did
   occur. This can be avoided using either Protection Against Wrapped
   Sequences (PAWS) <span>[<a href="#RFC7323" class="xref">RFC7323</a>]</span> context or
   internal extended sequence number representations (as in TCP Authentication
   Option (TCP-AO) <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span>). Alternately,
   false positives can be tolerated because they are expected to be infrequent
   and thus will not significantly impact the algorithm.<a href="#appendix-C.3-7" class="pilcrow">¶</a></p>
<p id="appendix-C.3-8">
   A number of additional constraints need to be imposed if this
   mechanism is implemented to ensure that it defaults to values that
   comply with current Internet standards, is conservative in how it
   extends those values, and returns to those values in the absence of
   positive feedback (i.e., success). To that end, we recommend the
   following list of example constraints:<a href="#appendix-C.3-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C.3-9.1">
            <p id="appendix-C.3-9.1.1"> The automatic IW algorithm <span class="bcp14">MUST</span> initialize MaxIW a
   value no larger than the currently recommended Internet default in the
   absence of other context information.<a href="#appendix-C.3-9.1.1" class="pilcrow">¶</a></p>
<p id="appendix-C.3-9.1.2">
   Thus, if there are too few connections to make a decision or if
   there is otherwise insufficient information to increase the IW, then
   the MaxIW defaults to the current recommended value.<a href="#appendix-C.3-9.1.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="appendix-C.3-9.2">
            <p id="appendix-C.3-9.2.1">
   An implementation <span class="bcp14">MAY</span> allow the MaxIW to grow beyond the
   currently recommended Internet default but not more than 2 segments
   per calendar year.<a href="#appendix-C.3-9.2.1" class="pilcrow">¶</a></p>
<p id="appendix-C.3-9.2.2">
   Thus, if an endpoint has a persistent history of successfully transmitting
   IW segments without loss, then it is allowed to probe the Internet to
   determine if larger IW values have similar success.  This probing is
   limited and requires a trusted time source; otherwise, the MaxIW remains
   constant.<a href="#appendix-C.3-9.2.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="appendix-C.3-9.3">
            <p id="appendix-C.3-9.3.1">
   An implementation <span class="bcp14">MUST</span> adjust the IW based on loss statistics at
   least once every 1000 connections.<a href="#appendix-C.3-9.3.1" class="pilcrow">¶</a></p>
<p id="appendix-C.3-9.3.2">
   An endpoint needs to be sufficiently reactive to IW loss.<a href="#appendix-C.3-9.3.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="appendix-C.3-9.4">
            <p id="appendix-C.3-9.4.1">
   An implementation <span class="bcp14">MUST</span> decrease the IW by at least 1 MSS when
   indicated during an evaluation interval.<a href="#appendix-C.3-9.4.1" class="pilcrow">¶</a></p>
<p id="appendix-C.3-9.4.2">
   An endpoint that detects loss needs to decrease its IW by at least
   1 MSS; otherwise, it is not participating in an automatic reactive
   algorithm.<a href="#appendix-C.3-9.4.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="appendix-C.3-9.5">
            <p id="appendix-C.3-9.5.1">
   An implementation <span class="bcp14">MUST</span> increase by no more than 2 MSSs per
   evaluation interval.<a href="#appendix-C.3-9.5.1" class="pilcrow">¶</a></p>
<p id="appendix-C.3-9.5.2">
   An endpoint that does not experience IW loss needs to probe the
   network incrementally.<a href="#appendix-C.3-9.5.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="appendix-C.3-9.6">
            <p id="appendix-C.3-9.6.1">
   An implementation <span class="bcp14">SHOULD</span> use an IW that is an integer multiple of
   2 MSSs.<a href="#appendix-C.3-9.6.1" class="pilcrow">¶</a></p>
<p id="appendix-C.3-9.6.2">
   The IW should remain a multiple of 2 MSS segments to enable
   efficient ACK compression without incurring unnecessary timeouts.<a href="#appendix-C.3-9.6.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="appendix-C.3-9.7">
            <p id="appendix-C.3-9.7.1">
   An implementation <span class="bcp14">MUST</span> decrease the IW if more than 95% of
   connections have IW losses.<a href="#appendix-C.3-9.7.1" class="pilcrow">¶</a></p>
<p id="appendix-C.3-9.7.2">
   Again, this is to ensure an implementation is sufficiently reactive.<a href="#appendix-C.3-9.7.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="appendix-C.3-9.8">
            <p id="appendix-C.3-9.8.1">
   An implementation <span class="bcp14">MAY</span> group IW values and statistics within
   subsets of connections. Such grouping <span class="bcp14">MAY</span> use any information about
   connections to form groups except loss statistics.<a href="#appendix-C.3-9.8.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="appendix-C.3-10"> 
   There are some TCP connections that might not be counted at all,
   such as those to/from loopback addresses or those within the same
   subnet as that of a local interface (for which congestion control is
   sometimes disabled anyway). This may also include connections that
   terminate before the IW is full, i.e., as a separate check at the
   time of the connection closing.<a href="#appendix-C.3-10" class="pilcrow">¶</a></p>
<p id="appendix-C.3-11">
   The period over which the IW is updated is intended to be a long timescale,
   e.g., a month or so, or 1,000 connections, whichever is longer. An
   implementation might check the IW once a month and simply not update the IW
   or clear the connection counts in months where the number of connections is
   too small.<a href="#appendix-C.3-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-c.4">
<section id="appendix-C.4">
        <h3 id="name-discussion-3">
<a href="#appendix-C.4" class="section-number selfRef">C.4. </a><a href="#name-discussion-3" class="section-name selfRef">Discussion</a>
        </h3>
<p id="appendix-C.4-1">
   There are numerous parameters to the above algorithm that are
   compliant with the given requirements; this is intended to allow
   variation in configuration and implementation while ensuring that
   all such algorithms are reactive and safe.<a href="#appendix-C.4-1" class="pilcrow">¶</a></p>
<p id="appendix-C.4-2">
   This algorithm continues to assume segments because that is the
   basis of most TCP implementations. It might be useful to consider
   revising the specifications to allow byte-based congestion given
   sufficient experience.<a href="#appendix-C.4-2" class="pilcrow">¶</a></p>
<p id="appendix-C.4-3">
   The algorithm checks for IW losses only during the first IW after a
   connection start; it does not check for IW losses elsewhere the IW
   is used, e.g., during slow-start restarts.<a href="#appendix-C.4-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C.4-4.1">
            <p id="appendix-C.4-4.1.1"> An implementation <span class="bcp14">MAY</span> detect IW losses during
     slow-start restarts in addition to losses during the first IW of a
     connection. In this case, the implementation <span class="bcp14">MUST</span> count
     each restart as a "connection" for the purposes of connection counts and
     periodic rechecking of the IW value.<a href="#appendix-C.4-4.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="appendix-C.4-5">
   False positives can occur during some kinds of segment reordering,
   e.g., that might trigger spurious retransmissions even without a
   true segment loss. These are not expected to be sufficiently common
   to dominate the algorithm and its conclusions.<a href="#appendix-C.4-5" class="pilcrow">¶</a></p>
<p id="appendix-C.4-6">
   This mechanism does require additional per-connection state, which is
   currently common in some implementations and is useful for other reasons
   (e.g., the ISN is used in TCP-AO <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span>). 


The mechanism in this appendix also benefits from persistent state kept across
reboots, which would also be useful to other state sharing mechanisms (e.g.,
TCP Control Block Sharing per the main body of this document).<a href="#appendix-C.4-6" class="pilcrow">¶</a></p>
<p id="appendix-C.4-7">
   The receive window (rwnd) is not involved in this calculation. The
   size of rwnd is determined by receiver resources and provides space
   to accommodate segment reordering.

Also, rwnd is not involved with congestion control, which is the focus of the way
this appendix manages the IW.<a href="#appendix-C.4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-c.5">
<section id="appendix-C.5">
        <h3 id="name-observations">
<a href="#appendix-C.5" class="section-number selfRef">C.5. </a><a href="#name-observations" class="section-name selfRef">Observations</a>
        </h3>
<p id="appendix-C.5-1">
   The IW may not converge to a single global value. It also may not
   converge at all but rather may oscillate by a few MSSs as it
   repeatedly probes the Internet for larger IWs and fails. Both
   properties are consistent with TCP behavior during each individual
   connection.<a href="#appendix-C.5-1" class="pilcrow">¶</a></p>
<p id="appendix-C.5-2">
   This mechanism assumes that losses during the IW are due to IW size.
   Persistent errors that drop packets for other reasons, e.g., OS
   bugs, can cause false positives. Again, this is consistent with
   TCP's basic assumption that loss is caused by congestion and
   requires backoff. This algorithm treats the IW of new connections as
   a long-timescale backoff system.<a href="#appendix-C.5-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="acknowledgments">
<section id="appendix-D">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-D-1">
   The authors would like to thank <span class="contact-name">Praveen    Balasubramanian</span> for information regarding TCB sharing in Windows;
   <span class="contact-name">Christoph Paasch</span> for information regarding TCB
   sharing in Apple OSs; <span class="contact-name">Yuchung Cheng</span>, <span class="contact-name">Lars Eggert</span>, <span class="contact-name">Ilpo Jarvinen</span>, and <span class="contact-name">Michael Scharf</span> for comments on earlier draft versions of this
   document; as well as members of the TCPM WG.  Earlier revisions of this
   work received funding from a collaborative research project between the
   University of Oslo and Huawei Technologies Co., Ltd. and were partly
   supported by USC/ISI's Postel Center.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-E">
      <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">Joe Touch</span></div>
<div dir="auto" class="left">
<span class="locality">Manhattan Beach</span>, <span class="region">CA</span> <span class="postal-code">90266</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20(310)%20560-0334" class="tel">+1 (310) 560-0334</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:touch@strayalpha.com" class="email">touch@strayalpha.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Michael Welzl</span></div>
<div dir="auto" class="left"><span class="org">University of Oslo</span></div>
<div dir="auto" class="left"><span class="street-address">PO Box 1080 Blindern</span></div>
<div dir="auto" class="left">
<span class="postal-code">N-0316</span> <span class="locality">Oslo</span>
</div>
<div dir="auto" class="left"><span class="country-name">Norway</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+47%2022%2085%2024%2020" class="tel">+47 22 85 24 20</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:michawe@ifi.uio.no" class="email">michawe@ifi.uio.no</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Safiqul Islam</span></div>
<div dir="auto" class="left"><span class="org">University of Oslo</span></div>
<div dir="auto" class="left"><span class="street-address">PO Box 1080 Blindern<br>Oslo N-0316<br>Norway</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+47%2022%2084%2008%2037" class="tel">+47 22 84 08 37</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:safiquli@ifi.uio.no" class="email">safiquli@ifi.uio.no</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>