File: rfc9049.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 (2791 lines) | stat: -rw-r--r-- 211,716 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 9049: Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)</title>
<meta content="Spencer Dawkins" name="author">
<meta content="
       This document is a product of the Path Aware Networking Research Group (PANRG).  At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers. 
       This document contains that catalog and analysis. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="PAN" name="keyword">
<meta content="9049" 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="rfc9049.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/rfc9049" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do-19" 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 9049</td>
<td class="center">What Not to Do</td>
<td class="right">June 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Dawkins</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 Research Task Force (IRTF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9049" class="eref">9049</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-06" class="published">June 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">S. Dawkins, <span class="editor">Ed.</span>
</div>
<div class="org">Tencent America</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9049</h1>
<h1 id="title">Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document is a product of the Path Aware Networking Research Group (PANRG).  At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document contains that catalog and analysis.<a href="#section-abstract-2" 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 Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the Path Aware Networking
            Research Group of the Internet Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not
            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/rfc9049">https://www.rfc-editor.org/info/rfc9049</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.<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="ulBare compact toc ulEmpty">
<li class="ulBare compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-what-do-path-and-path-aware" class="xref">What Do "Path" and "Path Awareness" Mean in This Document?</a></p>
</li>
            </ul>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-a-perspective-on-this-docum" class="xref">A Perspective on This Document</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-notes-for-the-reader" class="xref">Notes for the Reader</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-a-note-about-path-aware-tec" class="xref">A Note about Path Aware Techniques Included in This Document</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-architectural-guidance" class="xref">Architectural Guidance</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-terminology-used-in-this-do" class="xref">Terminology Used in This Document</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-methodology-for-contributio" class="xref">Methodology for Contributions</a></p>
</li>
            </ul>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-applying-the-lessons-weve-l" class="xref">Applying the Lessons We've Learned</a></p>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-summary-of-lessons-learned" class="xref">Summary of Lessons Learned</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-justifying-deployment" class="xref">Justifying Deployment</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-providing-benefits-for-earl" class="xref">Providing Benefits for Early Adopters</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-providing-benefits-during-p" class="xref">Providing Benefits during Partial Deployment</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-outperforming-end-to-end-pr" class="xref">Outperforming End-to-End Protocol Mechanisms</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-paying-for-path-aware-techn" class="xref">Paying for Path Aware Techniques</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-impact-on-operational-pract" class="xref">Impact on Operational Practices</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-per-connection-state" class="xref">Per-Connection State</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-keeping-traffic-on-fast-pat" class="xref">Keeping Traffic on Fast Paths</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.9">
                <p id="section-toc.1-1.4.2.9.1"><a href="#section-4.9" class="xref">4.9</a>.  <a href="#name-endpoints-trusting-intermed" class="xref">Endpoints Trusting Intermediate Nodes</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.10">
                <p id="section-toc.1-1.4.2.10.1"><a href="#section-4.10" class="xref">4.10</a>. <a href="#name-intermediate-nodes-trusting" class="xref">Intermediate Nodes Trusting Endpoints</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.11">
                <p id="section-toc.1-1.4.2.11.1"><a href="#section-4.11" class="xref">4.11</a>. <a href="#name-reacting-to-distant-signals" class="xref">Reacting to Distant Signals</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.12">
                <p id="section-toc.1-1.4.2.12.1"><a href="#section-4.12" class="xref">4.12</a>. <a href="#name-support-in-endpoint-protoco" class="xref">Support in Endpoint Protocol Stacks</a></p>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.4.2.13">
                <p id="section-toc.1-1.4.2.13.1"><a href="#section-4.13" class="xref">4.13</a>. <a href="#name-planning-for-failure" class="xref">Planning for Failure</a></p>
</li>
            </ul>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-future-work" class="xref">Future Work</a></p>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-contributions" class="xref">Contributions</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" 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-stream-transport-st-st2-st2" class="xref">Stream Transport (ST, ST2, ST2+)</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.1.2.1">
                    <p id="section-toc.1-1.6.2.1.2.1.1"><a href="#section-6.1.1" class="xref">6.1.1</a>.  <a href="#name-reasons-for-non-deployment" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.1.2.2">
                    <p id="section-toc.1-1.6.2.1.2.2.1"><a href="#section-6.1.2" class="xref">6.1.2</a>.  <a href="#name-lessons-learned" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" 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-integrated-services-intserv" class="xref">Integrated Services (IntServ)</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.2.2.1">
                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-reasons-for-non-deployment-2" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.2.2.2">
                    <p id="section-toc.1-1.6.2.2.2.2.1"><a href="#section-6.2.2" class="xref">6.2.2</a>.  <a href="#name-lessons-learned-2" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" 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-quick-start-tcp" class="xref">Quick-Start TCP</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.3.2.1">
                    <p id="section-toc.1-1.6.2.3.2.1.1"><a href="#section-6.3.1" class="xref">6.3.1</a>.  <a href="#name-reasons-for-non-deployment-3" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.3.2.2">
                    <p id="section-toc.1-1.6.2.3.2.2.1"><a href="#section-6.3.2" class="xref">6.3.2</a>.  <a href="#name-lessons-learned-3" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-icmp-source-quench" class="xref">ICMP Source Quench</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.4.2.1">
                    <p id="section-toc.1-1.6.2.4.2.1.1"><a href="#section-6.4.1" class="xref">6.4.1</a>.  <a href="#name-reasons-for-non-deployment-4" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.4.2.2">
                    <p id="section-toc.1-1.6.2.4.2.2.1"><a href="#section-6.4.2" class="xref">6.4.2</a>.  <a href="#name-lessons-learned-4" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-triggers-for-transport-trig" class="xref">Triggers for Transport (TRIGTRAN)</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.5.2.1">
                    <p id="section-toc.1-1.6.2.5.2.1.1"><a href="#section-6.5.1" class="xref">6.5.1</a>.  <a href="#name-reasons-for-non-deployment-5" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.5.2.2">
                    <p id="section-toc.1-1.6.2.5.2.2.1"><a href="#section-6.5.2" class="xref">6.5.2</a>.  <a href="#name-lessons-learned-5" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-shim6" class="xref">Shim6</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.6.2.1">
                    <p id="section-toc.1-1.6.2.6.2.1.1"><a href="#section-6.6.1" class="xref">6.6.1</a>.  <a href="#name-reasons-for-non-deployment-6" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.6.2.2">
                    <p id="section-toc.1-1.6.2.6.2.2.1"><a href="#section-6.6.2" class="xref">6.6.2</a>.  <a href="#name-lessons-learned-6" class="xref">Lessons Learned</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.6.2.3">
                    <p id="section-toc.1-1.6.2.6.2.3.1"><a href="#section-6.6.3" class="xref">6.6.3</a>.  <a href="#name-addendum-on-multipath-tcp" class="xref">Addendum on Multipath TCP</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.7">
                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-next-steps-in-signaling-nsi" class="xref">Next Steps in Signaling (NSIS)</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.7.2.1">
                    <p id="section-toc.1-1.6.2.7.2.1.1"><a href="#section-6.7.1" class="xref">6.7.1</a>.  <a href="#name-reasons-for-non-deployment-7" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.7.2.2">
                    <p id="section-toc.1-1.6.2.7.2.2.1"><a href="#section-6.7.2" class="xref">6.7.2</a>.  <a href="#name-lessons-learned-7" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.8">
                <p id="section-toc.1-1.6.2.8.1"><a href="#section-6.8" class="xref">6.8</a>.  <a href="#name-ipv6-flow-labels" class="xref">IPv6 Flow Labels</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.8.2.1">
                    <p id="section-toc.1-1.6.2.8.2.1.1"><a href="#section-6.8.1" class="xref">6.8.1</a>.  <a href="#name-reasons-for-non-deployment-8" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.8.2.2">
                    <p id="section-toc.1-1.6.2.8.2.2.1"><a href="#section-6.8.2" class="xref">6.8.2</a>.  <a href="#name-lessons-learned-8" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.9">
                <p id="section-toc.1-1.6.2.9.1"><a href="#section-6.9" class="xref">6.9</a>.  <a href="#name-explicit-congestion-notific" class="xref">Explicit Congestion Notification (ECN)</a></p>
<ul class="ulEmpty ulBare compact toc">
<li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.9.2.1">
                    <p id="section-toc.1-1.6.2.9.2.1.1"><a href="#section-6.9.1" class="xref">6.9.1</a>.  <a href="#name-reasons-for-non-deployment-9" class="xref">Reasons for Non-deployment</a></p>
</li>
                  <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.6.2.9.2.2">
                    <p id="section-toc.1-1.6.2.9.2.2.1"><a href="#section-6.9.2" class="xref">6.9.2</a>.  <a href="#name-lessons-learned-9" class="xref">Lessons Learned</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document describes the lessons that IETF participants have learned (and learned the hard way) about Path Aware networking over a period of several decades. It also provides an analysis of reasons why various Path Aware techniques have seen limited or no deployment.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This document represents the consensus of the Path Aware Networking Research Group (PANRG).<a href="#section-1-2" class="pilcrow">¶</a></p>
<div id="PANdef">
<section id="section-1.1">
        <h3 id="name-what-do-path-and-path-aware">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-what-do-path-and-path-aware" class="section-name selfRef">What Do "Path" and "Path Awareness" Mean in This Document?</a>
        </h3>
<p id="section-1.1-1">One of the first questions reviewers of this document have asked is "What's the definition of a Path, and what's the definition of Path Awareness?" That is not an easy question to answer for this document.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">These terms have definitions in other PANRG documents <span>[<a href="#PANRG" class="xref">PANRG</a>]</span> and are still the subject of some discussion in the Research Group, as of the date of this document. But because this document reflects work performed over several decades, the technologies described in <a href="#Contributions" class="xref">Section 6</a> significantly predate the current definitions of "Path" and "Path Aware" in use in the Path Aware Networking Research Group, and it is unlikely that all the contributors to <a href="#Contributions" class="xref">Section 6</a> would have had the same understanding of these terms. Those technologies were considered "Path Aware" in early PANRG discussions and so are included in this retrospective document.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">It is worth noting that the definitions of "Path" and "Path Aware" in <span>[<a href="#I-D.irtf-panrg-path-properties" class="xref">PANRG-PATH-PROPERTIES</a>]</span> would apply to Path Aware techniques at a number of levels of the Internet protocol architecture (<span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span>, plus several decades of refinements), but the contributions received for this document tended to target the transport layer and to treat a "Path" constructed by routers as opaque. It would be useful to consider how applicable the Lessons Learned cataloged in this document are, at other layers, and that would be a fine topic for follow-on research.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">The current definition of "Path" in the Path Aware Networking Research Group appears in Section 2 ("Terminology") in <span>[<a href="#I-D.irtf-panrg-path-properties" class="xref">PANRG-PATH-PROPERTIES</a>]</span>. That definition is included here as a convenience to the reader.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<blockquote id="section-1.1-5">
   Path:  A sequence of adjacent path elements over which a packet can
      be transmitted, starting and ending with a node.  A path is
      unidirectional.  Paths are time-dependent, i.e., the sequence of
      path elements over which packets are sent from one node to another
      may change.  A path is defined between two nodes.  For multicast
      or broadcast, a packet may be sent by one node and received by
      multiple nodes.  In this case, the packet is sent over multiple
      paths at once, one path for each combination of sending and
      receiving node; these paths do not have to be disjoint.  Note that
      an entity may have only partial visibility of the path elements
      that comprise a path and visibility may change over time.
      Different entities may have different visibility of a path and/or
      treat path elements at different levels of abstraction.<a href="#section-1.1-5" class="pilcrow">¶</a>
</blockquote>
<p id="section-1.1-6">The current definition of Path Awareness, used by the Path Aware Networking Research Group, appears in Section 1.1 ("Definition") in <span>[<a href="#I-D.irtf-panrg-questions" class="xref">PANRG-QUESTIONS</a>]</span>. 
That definition is included here as a convenience to the reader.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<blockquote id="section-1.1-7">
          <p id="section-1.1-7.1">For purposes of this document, "path aware networking" describes
   endpoint discovery of the properties of paths they use for
   communication across an internetwork, and endpoint reaction to these
   properties that affects routing and/or data transfer.  Note that this
   can and already does happen to some extent in the current Internet
   architecture; this definition expands current techniques of path
   discovery and manipulation to cross administrative domain boundaries
   and up to the transport and application layers at the endpoints.<a href="#section-1.1-7.1" class="pilcrow">¶</a></p>
<p id="section-1.1-7.2">Expanding on this definition, a "path aware internetwork" is one in
   which endpoint discovery of path properties and endpoint selection of
   paths used by traffic exchanged by the endpoint are explicitly
   supported, regardless of the specific design of the protocol features
   which enable this discovery and selection.<a href="#section-1.1-7.2" class="pilcrow">¶</a></p>
</blockquote>
</section>
</div>
</section>
</div>
<div id="perspective">
<section id="section-2">
      <h2 id="name-a-perspective-on-this-docum">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-a-perspective-on-this-docum" class="section-name selfRef">A Perspective on This Document</a>
      </h2>
<p id="section-2-1">At the first meeting of the Path Aware Networking Research Group <span>[<a href="#PANRG" class="xref">PANRG</a>]</span>, at IETF 99 <span>[<a href="#PANRG-99" class="xref">PANRG-99</a>]</span>, Olivier Bonaventure led a discussion of "A Decade of Path Awareness" <span>[<a href="#PATH-Decade" class="xref">PATH-Decade</a>]</span>, on attempts, which were mostly unsuccessful for a variety of reasons, to exploit Path Aware techniques and achieve a variety of goals over the past decade. At the end of that discussion, two things were abundantly clear.<a href="#section-2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-2.1">The Internet community has accumulated considerable experience with many Path Aware techniques over a long period of time, and<a href="#section-2-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.2">Although some Path Aware techniques have been deployed (for example, Differentiated Services, or Diffserv <span>[<a href="#RFC2475" class="xref">RFC2475</a>]</span>), most of these techniques haven't seen widespread adoption and deployment. Even "successful" techniques like Diffserv can face obstacles that prevent wider usage. The reasons for non-adoption and limited adoption and deployment are many and are worthy of study.<a href="#section-2-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-3">The meta-lessons from that experience were as follows:<a href="#section-2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-4.1">Path Aware networking has been more Research than Engineering, so establishing an IRTF Research Group for Path Aware networking was the right thing to do <span>[<a href="#RFC7418" class="xref">RFC7418</a>]</span>.<a href="#section-2-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.2">Analyzing a catalog of past experience to learn the reasons for non-adoption would be a great first step for the Research Group.<a href="#section-2-4.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-5">Allison Mankin, as IRTF Chair, officially chartered the Path Aware Networking Research Group in July 2018.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">This document contains the analysis performed by that Research Group (<a href="#LessonsLearned" class="xref">Section 4</a>), based on that catalog (<a href="#Contributions" class="xref">Section 6</a>).<a href="#section-2-6" class="pilcrow">¶</a></p>
<div id="notes-for-the-reader">
<section id="section-2.1">
        <h3 id="name-notes-for-the-reader">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-notes-for-the-reader" class="section-name selfRef">Notes for the Reader</a>
        </h3>
<p id="section-2.1-1">This Informational document discusses Path Aware protocol mechanisms considered, and in some cases standardized, by the Internet Engineering Task Force (IETF), and it considers Lessons Learned from those mechanisms. The intention is to inform the work of protocol designers, whether in the IRTF, the IETF, or elsewhere in the Internet ecosystem.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">As an Informational document published in the IRTF Stream, this document has no authority beyond the quality of the analysis it contains.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="a-note-about-path-aware-techniques-included-in-this-document">
<section id="section-2.2">
        <h3 id="name-a-note-about-path-aware-tec">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-a-note-about-path-aware-tec" class="section-name selfRef">A Note about Path Aware Techniques Included in This Document</a>
        </h3>
<p id="section-2.2-1">This document does not catalog every proposed Path Aware technique that was not adopted and deployed. Instead, we limited our focus to technologies that passed through the IETF community and still identified enough techniques to provide background for the lessons included in <a href="#LessonsLearned" class="xref">Section 4</a> to inform researchers and protocol engineers in their work.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">No shame is intended for the techniques included in this document. As shown in <a href="#LessonsLearned" class="xref">Section 4</a>, the quality of specific techniques had little to do with whether they were deployed or not. Based on the techniques cataloged in this document, it is likely that when these techniques were put forward, the proponents were trying to engineer something that could not be engineered without first carrying out research. Actual shame would be failing to learn from experience and failing to share that experience with other networking researchers and engineers.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="architectural-guidance">
<section id="section-2.3">
        <h3 id="name-architectural-guidance">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-architectural-guidance" class="section-name selfRef">Architectural Guidance</a>
        </h3>
<p id="section-2.3-1">As background for understanding the Lessons Learned contained in this document, the reader is encouraged to become familiar with the Internet Architecture Board's documents on "<a href="#RFC5218" class="xref">What Makes for a Successful Protocol?</a>" <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span> 
and "<a href="#RFC8170" class="xref">Planning for Protocol Adoption and Subsequent Transitions</a>" <span>[<a href="#RFC8170" class="xref">RFC8170</a>]</span>.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">Although these two documents do not specifically target Path Aware networking protocols, they are helpful resources for readers seeking to improve their understanding of considerations for successful adoption and deployment of any protocol. For example, the basic success factors described in <span><a href="https://www.rfc-editor.org/rfc/rfc5218#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC5218" class="xref">RFC5218</a>]</span> are helpful for readers of this document.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3">Because there is an economic aspect to decisions about deployment, the IAB Workshop on Internet Technology Adoption and Transition <span>[<a href="#ITAT" class="xref">ITAT</a>]</span> report <span>[<a href="#RFC7305" class="xref">RFC7305</a>]</span> also provides food for thought.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<p id="section-2.3-4">Several of the Lessons Learned in <a href="#LessonsLearned" class="xref">Section 4</a> reflect considerations described in <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span>, <span>[<a href="#RFC7305" class="xref">RFC7305</a>]</span>, and <span>[<a href="#RFC8170" class="xref">RFC8170</a>]</span>.<a href="#section-2.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terminology-used-in-this-document">
<section id="section-2.4">
        <h3 id="name-terminology-used-in-this-do">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-terminology-used-in-this-do" class="section-name selfRef">Terminology Used in This Document</a>
        </h3>
<p id="section-2.4-1">The terms "node" and "element" in this document have the meaning defined in <span>[<a href="#I-D.irtf-panrg-path-properties" class="xref">PANRG-PATH-PROPERTIES</a>]</span>.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TemplateContributions">
<section id="section-2.5">
        <h3 id="name-methodology-for-contributio">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-methodology-for-contributio" class="section-name selfRef">Methodology for Contributions</a>
        </h3>
<p id="section-2.5-1">This document grew out of contributions by various IETF participants with experience with one or more Path Aware techniques.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<p id="section-2.5-2">There are many things that could be said about the Path Aware techniques that have been developed. For the purposes of this document, contributors were requested to provide<a href="#section-2.5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.5-3.1">the name of a technique, including an abbreviation if one was used.<a href="#section-2.5-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.5-3.2">if available, a long-term pointer to the best reference describing the technique.<a href="#section-2.5-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.5-3.3">a short description of the problem the technique was intended to solve.<a href="#section-2.5-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.5-3.4">a short description of the reasons why the technique wasn't adopted.<a href="#section-2.5-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.5-3.5">a short statement of the lessons that researchers can learn from our experience with this technique.<a href="#section-2.5-3.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="applying">
<section id="section-3">
      <h2 id="name-applying-the-lessons-weve-l">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-applying-the-lessons-weve-l" class="section-name selfRef">Applying the Lessons We've Learned</a>
      </h2>
<p id="section-3-1">The initial scope for this document was roughly "What mistakes have we made in the decade prior to <span>[<a href="#PANRG-99" class="xref">PANRG-99</a>]</span>, that we shouldn't make again?" Some of the contributions in <a href="#Contributions" class="xref">Section 6</a> predate the initial scope. The earliest Path Aware technique referred to in <a href="#Contributions" class="xref">Section 6</a> is <span>[<a href="#IEN-119" class="xref">IEN-119</a>]</span>, which was published in the late 1970s; see <a href="#ST2" class="xref">Section 6.1</a>. Given that the networking ecosystem has evolved continuously, it seems reasonable to consider how to apply these lessons.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The PANRG reviewed the Lessons Learned (<a href="#LessonsLearned" class="xref">Section 4</a>) contained in the May 23, 2019 draft version of this document at IETF 105 <span>[<a href="#PANRG-105-Min" class="xref">PANRG-105-Min</a>]</span> and carried out additional discussion at IETF 106 <span>[<a href="#PANRG-106-Min" class="xref">PANRG-106-Min</a>]</span>. <a href="#thefuture" class="xref">Table 1</a> provides the "sense of the room" about each lesson after those discussions. The intention was to capture whether a specific lesson seems to be<a href="#section-3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-3.1">"Invariant" - well-understood and is likely to be applicable for any proposed Path Aware networking solution.<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.2">"Variable" - has impeded deployment in the past but might not be applicable in a specific technique. Engineering analysis to understand whether the lesson is applicable is prudent.<a href="#section-3-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.3">"Not Now" - a characteristic that tends to turn up a minefield full of dragons. Prudent network engineers will wish to avoid gambling on a technique that relies on this, until something significant changes.<a href="#section-3-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-4"><a href="#ecn" class="xref">Section 6.9</a> on Explicit Congestion Notification (ECN) was added during the review and approval process, based on a question from Martin Duke. <a href="#ecn" class="xref">Section 6.9</a>, as contained in the March 8, 2021 draft version of this document, was discussed at <span>[<a href="#PANRG-110" class="xref">PANRG-110</a>]</span> and is summarized in <a href="#OneChance" class="xref">Section 4.13</a>, describing a new Lesson Learned.<a href="#section-3-4" class="pilcrow">¶</a></p>
<div id="thefuture">
<table class="center" id="table-1">
        <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Lesson</th>
            <th class="text-left" rowspan="1" colspan="1">Category</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Justifying Deployment (<a href="#JustifyingDeployment" class="xref">Section 4.1</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Invariant</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Providing Benefits for Early Adopters (<a href="#EarlyAdopters" class="xref">Section 4.2</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Invariant</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Providing Benefits during Partial Deployment (<a href="#PartialDeployment" class="xref">Section 4.3</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Invariant</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Outperforming End-to-End Protocol Mechanisms (<a href="#Outperforming" class="xref">Section 4.4</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Variable</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Paying for Path Aware Techniques (<a href="#Paying" class="xref">Section 4.5</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Invariant</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Impact on Operational Practices (<a href="#OperationalImpact" class="xref">Section 4.6</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Invariant</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Per-Connection State (<a href="#Per-connectionState" class="xref">Section 4.7</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Variable</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Keeping Traffic on Fast Paths (<a href="#Fast-paths" class="xref">Section 4.8</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Variable</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Endpoints Trusting Intermediate Nodes (<a href="#EndpointsTrustingIDs" class="xref">Section 4.9</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Not Now</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Intermediate Nodes Trusting Endpoints (<a href="#IDsTrustingEndpoints" class="xref">Section 4.10</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Not Now</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Reacting to Distant Signals (<a href="#ReactionTimes" class="xref">Section 4.11</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Variable</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Support in Endpoint Protocol Stacks (<a href="#ProtocolStackSupport" class="xref">Section 4.12</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Variable</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Planning for Failure (<a href="#OneChance" class="xref">Section 4.13</a>)</td>
            <td class="text-left" rowspan="1" colspan="1">Invariant</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-3-6">"Justifying Deployment", "Providing Benefits for Early Adopters", "Paying for Path Aware Techniques", "Impact on Operational Practices", and "Planning for Failure" were considered to be Invariant -- the sense of the room was that these would always be considerations for any proposed Path Aware technique.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">"Providing Benefits during Partial Deployment" was added after IETF 105, during Research Group Last Call, and is also considered to be Invariant.<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">For "Outperforming End-to-End Protocol Mechanisms", there is a trade-off between improved performance from Path Aware techniques and additional complexity required by some Path Aware techniques.<a href="#section-3-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-9.1">For example, if you can obtain the same understanding of path characteristics from measurements obtained over a few more round trips, endpoint implementers are unlikely to be eager to add complexity, and many attributes can be measured from an endpoint, without assistance from intermediate nodes.<a href="#section-3-9.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-10">For "Per-Connection State", the key questions discussed in the Research Group were "how much state" and "where state is maintained".<a href="#section-3-10" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-11.1">Integrated Services (IntServ) (<a href="#IntServ" class="xref">Section 6.2</a>) required state at every participating intermediate node for every connection between two endpoints. As the Internet ecosystem has evolved, carrying many connections in a tunnel that appears to intermediate nodes as a single connection has become more common, so that additional end-to-end connections don't add additional state to intermediate nodes between tunnel endpoints. If these tunnels are encrypted, intermediate nodes between tunnel endpoints can't distinguish between connections, even if that were desirable.<a href="#section-3-11.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-12">For "Keeping Traffic on Fast Paths", we noted that this was true for many platforms, but not for all.<a href="#section-3-12" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-13.1">For backbone routers, this is likely an Invariant, but for platforms that rely more on general-purpose computers to make forwarding decisions, this may not be a fatal flaw for Path Aware techniques.<a href="#section-3-13.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-14">For "Endpoints Trusting Intermediate Nodes" and "Intermediate Nodes Trusting Endpoints", these lessons point to the broader need to revisit the Internet Threat Model.<a href="#section-3-14" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-15.1">We noted with relief that discussions about this were already underway in the IETF community at IETF 105 (see the Security Area Open Meeting minutes <span>[<a href="#SAAG-105-Min" class="xref">SAAG-105-Min</a>]</span> for discussion of <span>[<a href="#I-D.arkko-arch-internet-threat-model" class="xref">INTERNET-THREAT-MODEL</a>]</span> and <span>[<a href="#I-D.farrell-etm" class="xref">FARRELL-ETM</a>]</span>), and the Internet Architecture Board has created a mailing list for continued discussions <span>[<a href="#model-t" class="xref">model-t</a>]</span>, but we recognize that there are Path Aware networking aspects of this effort, requiring research.<a href="#section-3-15.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-16">For "Reacting to Distant Signals", we noted that not all attributes are equal.<a href="#section-3-16" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-17.1">If an attribute is stable over an extended period of time, is difficult to observe via end-to-end mechanisms, and is valuable, Path Aware techniques that rely on that attribute to provide a significant benefit become more attractive.<a href="#section-3-17.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-17.2">Analysis to help identify attributes that are useful enough to justify deployment of Path Aware techniques that make use of those attributes would be helpful.<a href="#section-3-17.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-18">For "Support in Endpoint Protocol Stacks", we noted that Path Aware applications must be able to identify and communicate requirements about path characteristics.<a href="#section-3-18" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-19.1">The de facto sockets API has no way of signaling application expectations for the network path to the protocol stack.<a href="#section-3-19.1" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="LessonsLearned">
<section id="section-4">
      <h2 id="name-summary-of-lessons-learned">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-summary-of-lessons-learned" class="section-name selfRef">Summary of Lessons Learned</a>
      </h2>
<p id="section-4-1">This section summarizes the Lessons Learned from the contributed subsections in <a href="#Contributions" class="xref">Section 6</a>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">Each Lesson Learned is tagged with one or more contributions that encountered this obstacle as a significant impediment to deployment. Other contributed techniques may have also encountered this obstacle, but this obstacle may not have been the biggest impediment to deployment for those techniques.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">It is useful to notice that sometimes an obstacle might impede deployment, while at other times, the same obstacle might prevent adoption and deployment entirely.
The Research Group discussed distinguishing between obstacles that impede and obstacles that prevent, but it appears that the boundary between "impede" and
"prevent" can shift over time -- some of the Lessons Learned are based on both a) Path Aware techniques that were not deployed and b) Path Aware techniques that were deployed but were not deployed widely or quickly. See Sections <a href="#Shim6" class="xref">6.6</a> and <a href="#Addendum-MP-TCP" class="xref">6.6.3</a> for examples of this shifting boundary.<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="JustifyingDeployment">
<section id="section-4.1">
        <h3 id="name-justifying-deployment">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-justifying-deployment" class="section-name selfRef">Justifying Deployment</a>
        </h3>
<p id="section-4.1-1">The benefit of Path Awareness must be great enough to justify making changes in an operational network. The colloquial U.S. American English expression, "If it ain't broke, don't fix it" is a "best current practice" on today's Internet. (See Sections <a href="#Quick-Start" class="xref">6.3</a>, <a href="#Source-Quench" class="xref">6.4</a>, <a href="#TRIGTRAN" class="xref">6.5</a>, and <a href="#ecn" class="xref">6.9</a>, in addition to <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span>.)<a href="#section-4.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EarlyAdopters">
<section id="section-4.2">
        <h3 id="name-providing-benefits-for-earl">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-providing-benefits-for-earl" class="section-name selfRef">Providing Benefits for Early Adopters</a>
        </h3>
<p id="section-4.2-1">Providing benefits for early adopters can be key -- if everyone must deploy a technique in order for the technique to provide benefits, or even to work at all, the technique is unlikely to be adopted widely or quickly. (See Sections <a href="#IntServ" class="xref">6.2</a> and <a href="#Quick-Start" class="xref">6.3</a>, in addition to <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span>.)<a href="#section-4.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="PartialDeployment">
<section id="section-4.3">
        <h3 id="name-providing-benefits-during-p">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-providing-benefits-during-p" class="section-name selfRef">Providing Benefits during Partial Deployment</a>
        </h3>
<p id="section-4.3-1">Some proposals require that all path elements along the full length of the path must be upgraded to support a new technique, before any benefits can be seen. This is likely to require coordination between operators who control a subset of path elements, and between operators and end users if endpoint upgrades are required. If a technique provides benefits when only a part of the path has been upgraded, this is likely to encourage adoption and deployment. (See Sections <a href="#IntServ" class="xref">6.2</a>, <a href="#Quick-Start" class="xref">6.3</a>, and <a href="#ecn" class="xref">6.9</a>, in addition to <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span>.)<a href="#section-4.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Outperforming">
<section id="section-4.4">
        <h3 id="name-outperforming-end-to-end-pr">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-outperforming-end-to-end-pr" class="section-name selfRef">Outperforming End-to-End Protocol Mechanisms</a>
        </h3>
<p id="section-4.4-1">Adaptive end-to-end protocol mechanisms may respond to feedback quickly enough that the additional realizable benefit from a new Path Aware mechanism that tries to manipulate nodes along a path, or observe the attributes of nodes along a path, may be much smaller than anticipated. (See Sections <a href="#Quick-Start" class="xref">6.3</a> and <a href="#TRIGTRAN" class="xref">6.5</a>.)<a href="#section-4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Paying">
<section id="section-4.5">
        <h3 id="name-paying-for-path-aware-techn">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-paying-for-path-aware-techn" class="section-name selfRef">Paying for Path Aware Techniques</a>
        </h3>
<p id="section-4.5-1">"Follow the money." If operators can't charge for a Path Aware technique to recover the costs of deploying it, the benefits to the operator must be really significant. Corollary: if operators charge for a Path Aware technique, the benefits to users of that Path Aware technique must be significant enough to justify the cost. (See Sections <a href="#ST2" class="xref">6.1</a>, <a href="#IntServ" class="xref">6.2</a>, <a href="#TRIGTRAN" class="xref">6.5</a>, and <a href="#ecn" class="xref">6.9</a>.)<a href="#section-4.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="OperationalImpact">
<section id="section-4.6">
        <h3 id="name-impact-on-operational-pract">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-impact-on-operational-pract" class="section-name selfRef">Impact on Operational Practices</a>
        </h3>
<p id="section-4.6-1">The impact of a Path Aware technique requiring changes to operational practices can affect how quickly or widely a promising technique is deployed. The impacts of these changes may make deployment more likely, but they often discourage deployment. (See <a href="#Shim6" class="xref">Section 6.6</a>, including <a href="#Addendum-MP-TCP" class="xref">Section 6.6.3</a>.)<a href="#section-4.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Per-connectionState">
<section id="section-4.7">
        <h3 id="name-per-connection-state">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-per-connection-state" class="section-name selfRef">Per-Connection State</a>
        </h3>
<p id="section-4.7-1">Per-connection state in intermediate nodes has been an impediment to adoption and deployment in the past, because of added cost and complexity. Often, similar benefits can be achieved with much less finely grained state. This is especially true as we move from the edge of the network, further into the routing core. (See Sections <a href="#ST2" class="xref">6.1</a> and <a href="#IntServ" class="xref">6.2</a>.)<a href="#section-4.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Fast-paths">
<section id="section-4.8">
        <h3 id="name-keeping-traffic-on-fast-pat">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-keeping-traffic-on-fast-pat" class="section-name selfRef">Keeping Traffic on Fast Paths</a>
        </h3>
<p id="section-4.8-1">Many modern platforms, especially high-end routers, have been designed with hardware that can make simple per-packet forwarding decisions ("fast paths") but have not been designed to make heavy use of in-band mechanisms such as IPv4 and IPv6 Router Alert Options (RAOs) that require more processing to make forwarding decisions. Packets carrying in-band mechanisms are diverted to other processors in the router with much lower packet-processing rates. Operators can be reluctant to deploy techniques that rely heavily on in-band mechanisms because they may significantly reduce packet throughput. (See <a href="#NSIS" class="xref">Section 6.7</a>.)<a href="#section-4.8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EndpointsTrustingIDs">
<section id="section-4.9">
        <h3 id="name-endpoints-trusting-intermed">
<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-endpoints-trusting-intermed" class="section-name selfRef">Endpoints Trusting Intermediate Nodes</a>
        </h3>
<p id="section-4.9-1">If intermediate nodes along the path can't be trusted, it's unlikely that endpoints will rely on signals from intermediate nodes to drive changes to endpoint behaviors. We note that "trust" is not binary -- one low level of trust applies when a node receiving a message can confirm that the sender of the message has visibility of the packets on the path it is seeking to control <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span> (e.g., an ICMP Destination Unreachable message <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span> that includes the Internet Header + 64 bits of Original Data Datagram payload from the source). A higher level of trust can arise when an endpoint has established a short-term, or even long-term, trust relationship with network nodes. (See Sections <a href="#Source-Quench" class="xref">6.4</a> and <a href="#TRIGTRAN" class="xref">6.5</a>.)<a href="#section-4.9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IDsTrustingEndpoints">
<section id="section-4.10">
        <h3 id="name-intermediate-nodes-trusting">
<a href="#section-4.10" class="section-number selfRef">4.10. </a><a href="#name-intermediate-nodes-trusting" class="section-name selfRef">Intermediate Nodes Trusting Endpoints</a>
        </h3>
<p id="section-4.10-1">If the endpoints do not have any trust relationship with the intermediate nodes along a path, operators have been reluctant to deploy techniques that rely on endpoints sending unauthenticated control signals to routers. (See Sections <a href="#IntServ" class="xref">6.2</a> and <a href="#NSIS" class="xref">6.7</a>.) (We also note that this still remains a factor hindering deployment of Diffserv.)<a href="#section-4.10-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ReactionTimes">
<section id="section-4.11">
        <h3 id="name-reacting-to-distant-signals">
<a href="#section-4.11" class="section-number selfRef">4.11. </a><a href="#name-reacting-to-distant-signals" class="section-name selfRef">Reacting to Distant Signals</a>
        </h3>
<p id="section-4.11-1">Because the Internet is a distributed system, if the distance that information from distant path elements travels to a Path Aware host is sufficiently large, the information may no longer accurately represent the state and situation at the distant host or elements along the path when it is received locally. In this case, the benefit that a Path Aware technique provides will be inconsistent and may not always be beneficial. (See <a href="#Quick-Start" class="xref">Section 6.3</a>.)<a href="#section-4.11-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ProtocolStackSupport">
<section id="section-4.12">
        <h3 id="name-support-in-endpoint-protoco">
<a href="#section-4.12" class="section-number selfRef">4.12. </a><a href="#name-support-in-endpoint-protoco" class="section-name selfRef">Support in Endpoint Protocol Stacks</a>
        </h3>
<p id="section-4.12-1">Just because a protocol stack provides a new feature/signal does not mean that applications will use the feature/signal. Protocol stacks may not know how to effectively utilize Path Aware techniques, because the protocol stack may require information from applications to permit the technique to work effectively, but applications may not a priori know that information. Even if the application does know that information, the de facto sockets API has no way of signaling application expectations for the network path to the protocol stack. In order for applications to provide these expectations to protocol stacks, we need an API that signals more than the packets to be sent. (See Sections <a href="#ST2" class="xref">6.1</a> and <a href="#IntServ" class="xref">6.2</a>.)<a href="#section-4.12-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="OneChance">
<section id="section-4.13">
        <h3 id="name-planning-for-failure">
<a href="#section-4.13" class="section-number selfRef">4.13. </a><a href="#name-planning-for-failure" class="section-name selfRef">Planning for Failure</a>
        </h3>
<p id="section-4.13-1">If early implementers discover severe problems with a new feature, that feature is likely to be disabled, and convincing implementers to re-enable that feature can be very difficult and can require years or decades. In addition to testing, partial deployment for a subset of users, implementing instrumentation that will detect degraded user experience, and even "failback" to a previous version or "failover" to an entirely different implementation are likely to be helpful. (See <a href="#ecn" class="xref">Section 6.9</a>.)<a href="#section-4.13-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Futures">
<section id="section-5">
      <h2 id="name-future-work">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-future-work" class="section-name selfRef">Future Work</a>
      </h2>
<p id="section-5-1">By its nature, this document has been retrospective. In addition to considering how the Lessons Learned to date apply to current and future Path Aware networking proposals, it's also worth considering whether there is deeper investigation left to do.<a href="#section-5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-2.1">We note that this work was based on contributions from experts on various Path Aware techniques, and all of the contributed techniques involved unicast protocols. We didn't consider how these lessons might apply to multicast, and, given anecdotal reports at the IETF 109 Media Operations (MOPS) Working Group meeting of IP multicast offerings within data centers at one or more cloud providers <span>[<a href="#MOPS-109-Min" class="xref">MOPS-109-Min</a>]</span>, it might be useful to think about Path Awareness in multicast, before we have a history of unsuccessful deployments to document.<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.2">
          <p id="section-5-2.2.1">The question of whether a mechanism supports admission control, based on either endpoints or applications, is associated with Path Awareness. One of the motivations of IntServ and a number of other architectures (e.g., Deterministic Networking <span>[<a href="#RFC8655" class="xref">RFC8655</a>]</span>) is the ability to "say no" to an application based on resource availability on a path, before the application tries to inject traffic onto that path and discovers the path does not have the capacity to sustain enough utility to meet the application's minimum needs. The question of whether admission control is needed comes up repeatedly, but we have learned a few useful lessons that, while covered implicitly in some of the Lessons Learned provided in this document, might be explained explicitly:<a href="#section-5-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-2.2.2.1">We have gained a lot of experience with application-based adaptation since the days where applications just injected traffic inelastically into the network. Such adaptations seem to work well enough that admission control is of less value to these applications.<a href="#section-5-2.2.2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5-2.2.2.2">There are end-to-end measurement techniques that can steer traffic at the application layer (Content Delivery Networks (CDNs), multi-CDNs like Conviva <span>[<a href="#Conviva" class="xref">Conviva</a>]</span>, etc.).<a href="#section-5-2.2.2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5-2.2.2.3">We noted in <a href="#ProtocolStackSupport" class="xref">Section 4.12</a> that applications often don't know how to utilize Path Aware techniques. This includes not knowing enough about their admission control threshold to be able to ask accurately for the resources they need, whether this is because the application itself doesn't know or because the application has no way to signal its expectations to the underlying protocol stack. To date, attempts to help them haven't gotten anywhere (e.g., the multiple-TSPEC (Traffic Specification) additions to RSVP to attempt to mirror codec selection by applications <span>[<a href="#I-D.ietf-tsvwg-intserv-multiple-tspec" class="xref">INTSERV-MULTIPLE-TSPEC</a>]</span> expired in 2013).<a href="#section-5-2.2.2.3" class="pilcrow">¶</a>
</li>
          </ul>
</li>
        <li class="normal" id="section-5-2.3">We note that this work took the then-current IP network architecture as given, at least at the time each technique was proposed. It might be useful to consider aspects of the now-current IP network architecture that ease, or impede, Path Aware techniques. For example, there is limited ability in IP to constrain bidirectional paths to be symmetric, and information-centric networking protocols such as Named Data Networking (NDN) and Content-Centric Networking (CCNx) <span>[<a href="#RFC8793" class="xref">RFC8793</a>]</span> must force bidirectional path symmetry using protocol-specific mechanisms.<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="Contributions">
<section id="section-6">
      <h2 id="name-contributions">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-contributions" class="section-name selfRef">Contributions</a>
      </h2>
<p id="section-6-1">Contributions on these Path Aware techniques were analyzed to arrive at the Lessons Learned captured in <a href="#LessonsLearned" class="xref">Section 4</a>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Our expectation is that most readers will not need to read through this section carefully, but we wanted to record these hard-fought lessons as a service to others who may revisit this document, so they'll have the details close at hand.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="ST2">
<section id="section-6.1">
        <h3 id="name-stream-transport-st-st2-st2">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-stream-transport-st-st2-st2" class="section-name selfRef">Stream Transport (ST, ST2, ST2+)</a>
        </h3>
<p id="section-6.1-1">The suggested references for Stream Transport are:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.1-2.1">"<a href="#IEN-119" class="xref">ST - A Proposed Internet Stream Protocol</a>" <span>[<a href="#IEN-119" class="xref">IEN-119</a>]</span><a href="#section-6.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-2.2">"<a href="#RFC1190" class="xref">Experimental Internet Stream Protocol: Version 2 (ST-II)</a>" <span>[<a href="#RFC1190" class="xref">RFC1190</a>]</span><a href="#section-6.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-2.3">"<a href="#RFC1819" class="xref">Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+</a>" <span>[<a href="#RFC1819" class="xref">RFC1819</a>]</span><a href="#section-6.1-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.1-3">The first version of Stream Transport, ST <span>[<a href="#IEN-119" class="xref">IEN-119</a>]</span>, was published in the late 1970s and was implemented and deployed on the ARPANET at small scale. It was used throughout the 1980s for experimental transmission of voice, video, and distributed simulation.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">The second version of the ST specification (ST2) <span>[<a href="#RFC1190" class="xref">RFC1190</a>]</span> <span>[<a href="#RFC1819" class="xref">RFC1819</a>]</span> was an experimental connection-oriented internetworking protocol that operated at the same layer as connectionless IP. ST2 packets could be distinguished by their IP header version numbers (IP, at that time, used version number 4, while ST2 used version number 5).<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">ST2 used a control plane layered over IP to select routes and reserve capacity for real-time streams across a network path, based on a flow specification communicated by a separate protocol. The flow specification could be associated with QoS state in routers, producing an experimental resource reservation protocol. This allowed ST2 routers along a path to offer end-to-end guarantees, primarily to satisfy the QoS requirements for real-time services over the Internet.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment">
<section id="section-6.1.1">
          <h4 id="name-reasons-for-non-deployment">
<a href="#section-6.1.1" class="section-number selfRef">6.1.1. </a><a href="#name-reasons-for-non-deployment" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.1.1-1">Although implemented in a range of equipment, ST2 was not widely used after completion of the experiments.  It did not offer the scalability and fate-sharing properties that have come to be desired by the Internet community.<a href="#section-6.1.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1.1-2">The ST2 protocol is no longer in use.<a href="#section-6.1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lessons-learned">
<section id="section-6.1.2">
          <h4 id="name-lessons-learned">
<a href="#section-6.1.2" class="section-number selfRef">6.1.2. </a><a href="#name-lessons-learned" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.1.2-1">As time passed, the trade-off between router processing and link capacity changed. Links became faster, and the cost of router processing became comparatively more expensive.<a href="#section-6.1.2-1" class="pilcrow">¶</a></p>
<p id="section-6.1.2-2">The ST2 control protocol used "hard state" -- once a route was established, and resources were reserved, routes and resources existed until they were explicitly released via signaling. A soft-state approach was thought superior to this hard-state approach and led to development of the IntServ model described in <a href="#IntServ" class="xref">Section 6.2</a>.<a href="#section-6.1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="IntServ">
<section id="section-6.2">
        <h3 id="name-integrated-services-intserv">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-integrated-services-intserv" class="section-name selfRef">Integrated Services (IntServ)</a>
        </h3>
<p id="section-6.2-1">The suggested references for IntServ are:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">"<a href="#RFC1633" class="xref">Integrated Services in the Internet Architecture: an Overview</a>" <span>[<a href="#RFC1633" class="xref">RFC1633</a>]</span><a href="#section-6.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.2">"<a href="#RFC2211" class="xref">Specification of the Controlled-Load Network Element Service</a>" <span>[<a href="#RFC2211" class="xref">RFC2211</a>]</span><a href="#section-6.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.3">"<a href="#RFC2212" class="xref">Specification of Guaranteed Quality of Service</a>" <span>[<a href="#RFC2212" class="xref">RFC2212</a>]</span><a href="#section-6.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.4">"<a href="#RFC2215" class="xref">General Characterization Parameters for Integrated Service Network Elements</a>" <span>[<a href="#RFC2215" class="xref">RFC2215</a>]</span><a href="#section-6.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.5">"<a href="#RFC2205" class="xref">Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification</a>" <span>[<a href="#RFC2205" class="xref">RFC2205</a>]</span><a href="#section-6.2-2.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.2-3">In 1994, when the IntServ architecture document <span>[<a href="#RFC1633" class="xref">RFC1633</a>]</span> was published, real-time traffic was first appearing on the Internet. At that time, bandwidth was still a scarce commodity. Internet Service Providers built networks over DS3 (45 Mbps) infrastructure, and sub-rate (&lt; 1 Mbps) access was common. Therefore, the IETF anticipated a need for a fine-grained QoS mechanism.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
<p id="section-6.2-4">In the IntServ architecture, some applications can require service guarantees. Therefore, those applications use RSVP <span>[<a href="#RFC2205" class="xref">RFC2205</a>]</span> to signal QoS reservations across network paths.  Every router in the network that participates in IntServ maintains per-flow soft state to a) perform call admission control and b) deliver guaranteed service.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
<p id="section-6.2-5">Applications use Flow Specifications (Flow Specs, or FLOWSPECs) <span>[<a href="#RFC2210" class="xref">RFC2210</a>]</span> to describe the traffic that they emit. RSVP reserves capacity for traffic on a per-Flow-Spec basis.<a href="#section-6.2-5" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-1">
<section id="section-6.2.1">
          <h4 id="name-reasons-for-non-deployment-2">
<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-reasons-for-non-deployment-2" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.2.1-1">Although IntServ has been used in enterprise and government networks, IntServ was never widely deployed on the Internet because of its cost. The following factors contributed to operational cost:<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2.1-2.1">IntServ must be deployed on every router that is on a path where IntServ is to be used. Although it is possible to include a router that does not participate in IntServ along the path being controlled, if that router is likely to become a bottleneck, IntServ cannot be used to avoid that bottleneck along the path.<a href="#section-6.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.2.1-2.2">IntServ maintained per-flow state.<a href="#section-6.2.1-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.2.1-3">As IntServ was being discussed, the following occurred:<a href="#section-6.2.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2.1-4.1">For many expected uses, it became more cost effective to solve the QoS problem by adding bandwidth. Between 1994 and 2000, Internet Service Providers upgraded their infrastructures from DS3 (45 Mbps) to OC-48 (2.4 Gbps). This meant that even if an endpoint was using IntServ in an IntServ-enabled network, its requests would rarely, if ever, be denied, so endpoints and Internet Service Providers had little reason to enable IntServ.<a href="#section-6.2.1-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.2.1-4.2">Diffserv <span>[<a href="#RFC2475" class="xref">RFC2475</a>]</span> offered a more cost-effective, albeit less fine-grained, solution to the QoS problem.<a href="#section-6.2.1-4.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="lessons-learned-1">
<section id="section-6.2.2">
          <h4 id="name-lessons-learned-2">
<a href="#section-6.2.2" class="section-number selfRef">6.2.2. </a><a href="#name-lessons-learned-2" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.2.2-1">The following lessons were learned:<a href="#section-6.2.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2.2-2.1">Any mechanism that requires every participating on-path router to maintain per-flow state is not likely to succeed, unless the additional cost for offering the feature can be recovered from the user.<a href="#section-6.2.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.2.2-2.2">Any mechanism that requires an operator to upgrade all of its routers is not likely to succeed, unless the additional cost for offering the feature can be recovered from the user.<a href="#section-6.2.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.2.2-3">In environments where IntServ has been deployed, trust relationships
 with endpoints are very different from trust relationships on the
 Internet itself.  There are often clearly defined hierarchies in
 Service Level Agreements (SLAs) governing well-defined transport flows
 operating with predetermined capacity and latency requirements over
 paths where capacity or other attributes are constrained.<a href="#section-6.2.2-3" class="pilcrow">¶</a></p>
<p id="section-6.2.2-4">IntServ was never widely deployed to manage capacity across the Internet. However, the technique that it produced was deployed for reasons other than bandwidth management. RSVP is widely deployed as an MPLS signaling mechanism. BGP reuses the RSVP concept of Filter Specs to distribute firewall filters, although they are called "Flow Spec Component Types" in BGP <span>[<a href="#RFC5575" class="xref">RFC5575</a>]</span>.<a href="#section-6.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Quick-Start">
<section id="section-6.3">
        <h3 id="name-quick-start-tcp">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-quick-start-tcp" class="section-name selfRef">Quick-Start TCP</a>
        </h3>
<p id="section-6.3-1">The suggested references for Quick-Start TCP are:<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3-2.1">"<a href="#RFC4782" class="xref">Quick-Start for TCP and IP</a>" <span>[<a href="#RFC4782" class="xref">RFC4782</a>]</span><a href="#section-6.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.3-2.2">"Determining an appropriate sending rate over an underutilized network path" <span>[<a href="#SAF07" class="xref">SAF07</a>]</span><a href="#section-6.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.3-2.3">"Fast Startup Internet Congestion Control for Broadband Interactive Applications" <span>[<a href="#Sch11" class="xref">Sch11</a>]</span><a href="#section-6.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.3-2.4">"Using Quick-Start to enhance TCP-friendly rate control performance in bidirectional satellite networks" <span>[<a href="#QS-SAT" class="xref">QS-SAT</a>]</span><a href="#section-6.3-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.3-3">Quick-Start is defined in an Experimental RFC <span>[<a href="#RFC4782" class="xref">RFC4782</a>]</span> and is a TCP extension that leverages support from the routers on the path to determine an allowed initial sending rate for a path through the Internet, either at the start of data transfers or after idle periods. Without information about the path, a sender cannot easily determine an appropriate initial sending rate. The default TCP congestion control therefore uses the safe but time-consuming slow-start algorithm <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>. With Quick-Start, connections are allowed to use higher initial sending rates if there is significant unused bandwidth along the path and if the sender and all of the routers along the path approve the request.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
<p id="section-6.3-4">By examining the Time To Live (TTL) field in Quick-Start packets, a sender can determine if  routers on the path have approved the Quick-Start request. However, this method is unable to take into account the routers hidden by tunnels or other network nodes invisible at the IP layer.<a href="#section-6.3-4" class="pilcrow">¶</a></p>
<p id="section-6.3-5">The protocol also includes a nonce that provides protection against cheating routers and receivers. If the Quick-Start request is explicitly approved by all routers along the path, the TCP host can send at up to the approved rate; otherwise, TCP would use the default congestion control. Quick-Start requires modifications in the involved end systems as well as in routers. Due to the resulting deployment challenges, Quick-Start was only proposed in <span>[<a href="#RFC4782" class="xref">RFC4782</a>]</span> for controlled environments.<a href="#section-6.3-5" class="pilcrow">¶</a></p>
<p id="section-6.3-6">The Quick-Start mechanism is a lightweight, coarse-grained, in-band, network-assisted fast startup mechanism. The benefits are studied by simulation in a research paper <span>[<a href="#SAF07" class="xref">SAF07</a>]</span> that complements the protocol specification. The study confirms that Quick-Start can significantly speed up mid-sized data transfers. That paper also presents router algorithms that do not require keeping per-flow state. Later studies <span>[<a href="#Sch11" class="xref">Sch11</a>]</span> comprehensively analyze Quick-Start with a full Linux implementation and with a router fast-path prototype using a network processor. In both cases, Quick-Start could be implemented with limited additional complexity.<a href="#section-6.3-6" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-2">
<section id="section-6.3.1">
          <h4 id="name-reasons-for-non-deployment-3">
<a href="#section-6.3.1" class="section-number selfRef">6.3.1. </a><a href="#name-reasons-for-non-deployment-3" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.3.1-1">However, experiments with Quick-Start in <span>[<a href="#Sch11" class="xref">Sch11</a>]</span> revealed several challenges:<a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3.1-2.1">Having information from the routers along the path can reduce the risk of congestion but cannot avoid it entirely. Determining whether there is unused capacity is not trivial in actual router and host implementations. Data about available capacity visible at the IP layer may be imprecise, and due to the propagation delay, information can already be outdated when it reaches a sender. There is a trade-off between the speedup of data transfers and the risk of congestion even with Quick-Start. This could be mitigated by only allowing Quick-Start to access a proportion of the unused capacity along a path.<a href="#section-6.3.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.1-2.2">For scalable router fast-path implementations, it is important to enable parallel processing of packets, as this is a widely used method, e.g., in network processors. One challenge is synchronization of information between packets that are processed in parallel, which should be avoided as much as possible.<a href="#section-6.3.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.1-2.3">Only some types of application traffic can benefit from Quick-Start. Capacity needs to be requested and discovered. The discovered capacity needs to be utilized by the flow, or it implicitly becomes available for other flows.  Failing to use the requested capacity may have already reduced the pool of Quick-Start capacity that was made available to other competing Quick-Start requests. The benefit is greatest when  senders use this only for bulk flows and avoid sending unnecessary Quick-Start requests, e.g., for flows that only send a small amount of data. Choosing an appropriate request size requires application-internal knowledge that is not commonly expressed by the transport API. How a sender can determine the rate for an initial Quick-Start request is still a largely unsolved problem.<a href="#section-6.3.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.3.1-3">There is no known deployment of Quick-Start for TCP or other IETF transports.<a href="#section-6.3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lessons-learned-2">
<section id="section-6.3.2">
          <h4 id="name-lessons-learned-3">
<a href="#section-6.3.2" class="section-number selfRef">6.3.2. </a><a href="#name-lessons-learned-3" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.3.2-1">Some lessons can be learned from Quick-Start. Despite being a very lightweight protocol, Quick-Start suffers from poor incremental deployment properties regarding both a) the required modifications in network infrastructure and b) its interactions with applications. Except for corner cases, congestion control can be quite efficiently performed end to end in the Internet, and in modern stacks there is not much room for significant improvement by additional network support.<a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
<p id="section-6.3.2-2">After publication of the Quick-Start specification, there have been large-scale experiments with an initial window of up to 10 segments <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span>. This alternative "IW10" approach can also ramp up data transfers faster than the standard congestion control, but it only requires sender-side modifications. As a result, this approach can be easier and incrementally deployed in the Internet. While theoretically Quick-Start can outperform "IW10", the improvement in completion time for data transfer times can, in many cases, be small. After publication of <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span>, most modern TCP stacks have increased their default initial window.<a href="#section-6.3.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Source-Quench">
<section id="section-6.4">
        <h3 id="name-icmp-source-quench">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-icmp-source-quench" class="section-name selfRef">ICMP Source Quench</a>
        </h3>
<p id="section-6.4-1">The suggested reference for ICMP Source Quench is:<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.4-2.1">"<a href="#RFC0792" class="xref">Internet Control Message Protocol</a>" <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span><a href="#section-6.4-2.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.4-3">The ICMP Source Quench message <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span> allowed an on-path router to request the source of a flow to reduce its sending rate. This method allowed a router to provide an early indication of impending congestion on a path to the sources that contribute to that congestion.<a href="#section-6.4-3" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-3">
<section id="section-6.4.1">
          <h4 id="name-reasons-for-non-deployment-4">
<a href="#section-6.4.1" class="section-number selfRef">6.4.1. </a><a href="#name-reasons-for-non-deployment-4" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.4.1-1">This method was deployed in Internet routers over a period of time; the reaction of endpoints to receiving this signal has varied. For low-speed links, with low multiplexing of flows the method could be used to regulate (momentarily reduce) the transmission rate. However, the simple signal does not scale with link speed or with the number of flows sharing a link.<a href="#section-6.4.1-1" class="pilcrow">¶</a></p>
<p id="section-6.4.1-2">The approach was overtaken by the evolution of congestion control methods in TCP <span>[<a href="#RFC2001" class="xref">RFC2001</a>]</span>, and later also by other IETF transports. Because these methods were based upon measurement of the end-to-end path and an algorithm in the endpoint, they were able to evolve and mature more rapidly than methods relying on interactions between operational routers and endpoint stacks.<a href="#section-6.4.1-2" class="pilcrow">¶</a></p>
<p id="section-6.4.1-3">After ICMP Source Quench was specified, the IETF began to recommend that transports provide end-to-end congestion control <span>[<a href="#RFC2001" class="xref">RFC2001</a>]</span>. The Source Quench method has been obsoleted by the IETF <span>[<a href="#RFC6633" class="xref">RFC6633</a>]</span>, and both hosts and routers must now silently discard this message.<a href="#section-6.4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lessons-learned-3">
<section id="section-6.4.2">
          <h4 id="name-lessons-learned-4">
<a href="#section-6.4.2" class="section-number selfRef">6.4.2. </a><a href="#name-lessons-learned-4" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.4.2-1">This method had several problems.<a href="#section-6.4.2-1" class="pilcrow">¶</a></p>
<p id="section-6.4.2-2">First, <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span> did not sufficiently specify how the sender would react to the ICMP Source Quench signal from the path (e.g., <span>[<a href="#RFC1016" class="xref">RFC1016</a>]</span>). There was ambiguity in how the sender should utilize this additional information. This could lead to unfairness in the way that receivers (or routers) responded to this message.<a href="#section-6.4.2-2" class="pilcrow">¶</a></p>
<p id="section-6.4.2-3">Second, while the message did provide additional information, the Explicit Congestion Notification (ECN) mechanism <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span> provided a more robust and informative signal for network nodes to provide early indication that a path has become congested.<a href="#section-6.4.2-3" class="pilcrow">¶</a></p>
<p id="section-6.4.2-4">The mechanism originated at a time when the Internet trust model was very different. Most endpoint implementations did not attempt to verify that the message originated from an on-path node before they utilized the message. This made it vulnerable to Denial-of-Service (DoS) attacks.  In theory, routers might have chosen to use the quoted packet contained in the ICMP payload to validate that the message originated from an on-path node, but this would have increased per-packet processing overhead for each router along the path and would have required transport functionality in the router to verify whether the quoted packet header corresponded to a packet the router had sent. In addition, <span><a href="https://www.rfc-editor.org/rfc/rfc4443#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC4443" class="xref">RFC4443</a>]</span>
noted ICMPv6-based attacks on hosts that would also have threatened routers processing ICMPv6 Source Quench payloads. As time passed, it became increasingly obvious that the lack of validation of the messages exposed receivers to a security vulnerability where the messages could be forged to create a tangible DoS opportunity.<a href="#section-6.4.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="TRIGTRAN">
<section id="section-6.5">
        <h3 id="name-triggers-for-transport-trig">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-triggers-for-transport-trig" class="section-name selfRef">Triggers for Transport (TRIGTRAN)</a>
        </h3>
<p id="section-6.5-1">The suggested references for TRIGTRAN are:<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.5-2.1">TRIGTRAN BOF at IETF 55 <span>[<a href="#TRIGTRAN-55" class="xref">TRIGTRAN-55</a>]</span><a href="#section-6.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.5-2.2">TRIGTRAN BOF at IETF 56 <span>[<a href="#TRIGTRAN-56" class="xref">TRIGTRAN-56</a>]</span><a href="#section-6.5-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.5-3">TCP <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span> has a well-known weakness -- the end-to-end flow control mechanism has only a single signal, the loss of a segment,
detected when no acknowledgment for the lost segment is received at the sender.  There are multiple reasons why the sender might not have received an acknowledgment for the segment.  To name several, the segment could have been trapped in a routing loop, damaged in transmission and failed checksum verification at the
receiver, or lost because some intermediate device discarded the packet, or any of a variety of other things could have happened to the acknowledgment on the way back from the receiver to the sender. TCP implementations since the late 1980s have made the "safe" decision and have interpreted the loss of a segment as evidence
that the path between two endpoints may have become congested enough to exhaust buffers on intermediate hops, so that the TCP sender should "back off" -- reduce its sending rate until it knows that its segments are now being delivered without loss 
<span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>.<a href="#section-6.5-3" class="pilcrow">¶</a></p>
<p id="section-6.5-4">The thinking behind TRIGTRAN was that if a path completely stopped working because a link along the path was "down", somehow something along the path could signal TCP when that link returned to service, and the sending TCP could retry immediately, without waiting for a full retransmission timeout (RTO) period.<a href="#section-6.5-4" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-4">
<section id="section-6.5.1">
          <h4 id="name-reasons-for-non-deployment-5">
<a href="#section-6.5.1" class="section-number selfRef">6.5.1. </a><a href="#name-reasons-for-non-deployment-5" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.5.1-1">The early dreams for TRIGTRAN were dashed because of an assumption that TRIGTRAN triggers would be unauthenticated. This meant that any "safe" TRIGTRAN mechanism would have relied on a mechanism such as setting the IPv4 TTL or IPv6 Hop Count to 255 at a sender and testing that it was 254 upon receipt, so that a receiver could verify that a signal was generated by an adjacent sender known to be on the path being used and not some unknown sender that might not even be on the path (e.g., 
"<a href="#RFC5082" class="xref">The Generalized TTL Security Mechanism (GTSM)</a>" <span>[<a href="#RFC5082" class="xref">RFC5082</a>]</span>). This situation is very similar to the case for ICMP Source Quench messages as described in <a href="#Source-Quench" class="xref">Section 6.4</a>, which were also unauthenticated and could be sent by an off-path attacker, resulting in deprecation of ICMP Source Quench message processing <span>[<a href="#RFC6633" class="xref">RFC6633</a>]</span>.<a href="#section-6.5.1-1" class="pilcrow">¶</a></p>
<p id="section-6.5.1-2">TRIGTRAN's scope shrunk from "the path is down" to "the first-hop link is down."<a href="#section-6.5.1-2" class="pilcrow">¶</a></p>
<p id="section-6.5.1-3">But things got worse.<a href="#section-6.5.1-3" class="pilcrow">¶</a></p>
<p id="section-6.5.1-4">Because TRIGTRAN triggers would only be provided when the first-hop link was "down", TRIGTRAN triggers couldn't replace normal TCP retransmission behavior if the path failed because some link further along the network path was "down". So TRIGTRAN triggers added complexity to an already-complex TCP state machine and did not allow any existing complexity to be removed.<a href="#section-6.5.1-4" class="pilcrow">¶</a></p>
<p id="section-6.5.1-5">There was also an issue that the TRIGTRAN signal was not sent in response to a specific host that had been sending packets and was instead a signal that stimulated a response by any sender on the link. This needs to scale when there are multiple flows trying to use the same resource, yet the sender of a trigger has no understanding of how many of the potential traffic sources will respond by sending packets -- if recipients of the signal "back off" their responses to a trigger to improve scaling, then that immediately mitigates the benefit of the signal.<a href="#section-6.5.1-5" class="pilcrow">¶</a></p>
<p id="section-6.5.1-6">Finally, intermediate forwarding nodes required modification to provide TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN triggers, so there was no way to recover the cost of modifying, testing, and deploying updated intermediate nodes.<a href="#section-6.5.1-6" class="pilcrow">¶</a></p>
<p id="section-6.5.1-7">Two TRIGTRAN BOFs were held, at IETF 55 <span>[<a href="#TRIGTRAN-55" class="xref">TRIGTRAN-55</a>]</span> and IETF 56 <span>[<a href="#TRIGTRAN-56" class="xref">TRIGTRAN-56</a>]</span>, but this work was not chartered, and there was no interest in deploying TRIGTRAN unless it was chartered and standardized in the IETF.<a href="#section-6.5.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lessons-learned-4">
<section id="section-6.5.2">
          <h4 id="name-lessons-learned-5">
<a href="#section-6.5.2" class="section-number selfRef">6.5.2. </a><a href="#name-lessons-learned-5" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.5.2-1">The reasons why this work was not chartered, much less deployed, provide several useful lessons for researchers.<a href="#section-6.5.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.5.2-2.1">TRIGTRAN started with a plausible value proposition, but networking realities in the early 2000s forced reductions in scope that led directly to reductions in potential benefits but no corresponding reductions in costs and complexity.<a href="#section-6.5.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.5.2-2.2">These reductions in scope were the direct result of an inability for hosts to trust or authenticate TRIGTRAN signals they received from the network.<a href="#section-6.5.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.5.2-2.3">Operators did not believe they could charge for TRIGTRAN signaling, because first-hop links didn't fail frequently and TRIGTRAN provided no reduction in operating expenses, so there was little incentive to purchase and deploy TRIGTRAN-capable network equipment.<a href="#section-6.5.2-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.5.2-3">It is also worth noting that the targeted environment for TRIGTRAN in the late 1990s contained links with a relatively small number of directly connected hosts -- for instance, cellular or satellite links. The transport community was well aware of the dangers of sender synchronization based on multiple senders receiving the same stimulus at the same time, but the working assumption for TRIGTRAN was that there wouldn't be enough senders for this to be a meaningful problem. In the 2010s, it was  common for a single "link" to support many senders and receivers, likely requiring TRIGTRAN senders to wait some random amount of time before sending after receiving a TRIGTRAN signal, which would have reduced the benefits of TRIGTRAN even more.<a href="#section-6.5.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Shim6">
<section id="section-6.6">
        <h3 id="name-shim6">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-shim6" class="section-name selfRef">Shim6</a>
        </h3>
<p id="section-6.6-1">The suggested reference for Shim6 is:<a href="#section-6.6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.6-2.1">"<a href="#RFC5533" class="xref">Shim6: Level 3 Multihoming Shim Protocol for IPv6</a>" <span>[<a href="#RFC5533" class="xref">RFC5533</a>]</span><a href="#section-6.6-2.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.6-3">The IPv6 routing architecture <span>[<a href="#RFC1887" class="xref">RFC1887</a>]</span> assumed that most sites on the Internet would be identified by Provider Assigned IPv6 prefixes, so that Default-Free Zone routers only contained routes to other providers, resulting in a very small IPv6 global routing table.<a href="#section-6.6-3" class="pilcrow">¶</a></p>
<p id="section-6.6-4">For a single-homed site, this could work well. A multihomed site with only one upstream provider could also work well, although BGP multihoming from a single upstream provider was often a premium service (costing more than twice as much as two single-homed sites), and if the single upstream provider went out of service, all of the multihomed paths could fail simultaneously.<a href="#section-6.6-4" class="pilcrow">¶</a></p>
<p id="section-6.6-5">IPv4 sites often multihomed by obtaining Provider Independent prefixes and advertising these prefixes through multiple upstream providers. With the assumption that any multihomed IPv4 site would also multihome in IPv6, it seemed likely that IPv6 routing would be subject to the same pressures to announce Provider Independent prefixes, resulting in an IPv6 global routing table that exhibited the same explosive growth as the IPv4 global routing table. During the early 2000s, work began on a protocol that would provide multihoming for IPv6 sites without requiring sites to advertise Provider Independent prefixes into the IPv6 global routing table.<a href="#section-6.6-5" class="pilcrow">¶</a></p>
<p id="section-6.6-6">This protocol, called "Shim6", allowed two endpoints to exchange multiple addresses ("Locators") that all mapped to the same endpoint ("Identity"). After an endpoint learned multiple Locators for the other endpoint, it could send to any of those Locators with the expectation that those packets would all be delivered to the endpoint with the same Identity. Shim6 was an example of an "Identity/Locator Split" protocol.<a href="#section-6.6-6" class="pilcrow">¶</a></p>
<p id="section-6.6-7">Shim6, as defined in <span>[<a href="#RFC5533" class="xref">RFC5533</a>]</span> and related RFCs, provided a workable solution for IPv6 multihoming using Provider Assigned prefixes, including capability discovery and negotiation, and allowing end-to-end application communication to continue even in the face of path failure, because applications don't see Locator failures and continue to communicate with the same Identity using a different Locator.<a href="#section-6.6-7" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-5">
<section id="section-6.6.1">
          <h4 id="name-reasons-for-non-deployment-6">
<a href="#section-6.6.1" class="section-number selfRef">6.6.1. </a><a href="#name-reasons-for-non-deployment-6" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.6.1-1">Note that the problem being addressed was "site multihoming", but Shim6 was providing "host multihoming". That meant that the decision about what path would be used was under host control, not under edge router control.<a href="#section-6.6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.6.1-2">Although more work could have been done to provide a better technical solution, the biggest impediments to Shim6 deployment were operational and business considerations. These impediments were discussed at multiple network operator group meetings, including <span>[<a href="#Shim6-35" class="xref">Shim6-35</a>]</span> at <span>[<a href="#NANOG-35" class="xref">NANOG-35</a>]</span>.<a href="#section-6.6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.6.1-3">The technical issues centered around concerns that Shim6 relied on the host to track all the connections, while also tracking Identity/Locator mappings in the kernel and tracking failures to recognize that an available path has failed.<a href="#section-6.6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.6.1-4">The operational issues centered around concerns that operators were performing traffic engineering on traffic aggregates. With Shim6, these operator traffic engineering policies must be pushed down to individual hosts.<a href="#section-6.6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.6.1-5">In addition, operators would have no visibility or control over the decision of hosts choosing to switch to another path. They expressed concerns that relying on hosts to steer traffic exposed operator networks to oscillation based on feedback loops, if hosts moved from path to path frequently. Given that Shim6 was intended to support multihoming across operators, operators providing only one of the paths would have even less visibility as traffic suddenly appeared and disappeared on their networks.<a href="#section-6.6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.6.1-6">In addition, firewalls that expected to find a TCP or UDP transport-level protocol header in the IP payload would see a Shim6 Identity header instead, and they would not perform transport-protocol-based firewalling functions because the firewall's normal processing logic would not look past the Identity header.
The firewall would perform its default action, which would most likely be to drop packets that don't match any processing rule.<a href="#section-6.6.1-6" class="pilcrow">¶</a></p>
<p id="section-6.6.1-7">The business issues centered on reducing or removing the ability to sell BGP multihoming service to their own customers, which is often more expensive than two single-homed connectivity services.<a href="#section-6.6.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lessons-learned-5">
<section id="section-6.6.2">
          <h4 id="name-lessons-learned-6">
<a href="#section-6.6.2" class="section-number selfRef">6.6.2. </a><a href="#name-lessons-learned-6" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.6.2-1">It is extremely important to take operational concerns into account when a Path Aware protocol is making decisions about path selection that may conflict with existing operational practices and business considerations.<a href="#section-6.6.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Addendum-MP-TCP">
<section id="section-6.6.3">
          <h4 id="name-addendum-on-multipath-tcp">
<a href="#section-6.6.3" class="section-number selfRef">6.6.3. </a><a href="#name-addendum-on-multipath-tcp" class="section-name selfRef">Addendum on Multipath TCP</a>
          </h4>
<p id="section-6.6.3-1">During discussions in the PANRG session at IETF 103 <span>[<a href="#PANRG-103-Min" class="xref">PANRG-103-Min</a>]</span>, Lars Eggert, past Transport Area Director, pointed out that during charter discussions for the Multipath TCP Working Group <span>[<a href="#MP-TCP" class="xref">MP-TCP</a>]</span>, operators expressed concerns that customers could use Multipath TCP to load-share TCP connections across operators simultaneously and compare passive performance measurements across network paths in real time, changing the balance of power in those business relationships. Although the Multipath TCP Working Group was chartered, this concern could have acted as an obstacle to deployment.<a href="#section-6.6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.6.3-2">Operator objections to Shim6 were focused on technical concerns, but this concern could have also been an obstacle to Shim6 deployment if the technical concerns had been overcome.<a href="#section-6.6.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="NSIS">
<section id="section-6.7">
        <h3 id="name-next-steps-in-signaling-nsi">
<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-next-steps-in-signaling-nsi" class="section-name selfRef">Next Steps in Signaling (NSIS)</a>
        </h3>
<p id="section-6.7-1">The suggested references for Next Steps in Signaling (NSIS) are:<a href="#section-6.7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.7-2.1">the concluded working group charter <span>[<a href="#NSIS-CHARTER-2001" class="xref">NSIS-CHARTER-2001</a>]</span><a href="#section-6.7-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.7-2.2">"<a href="#RFC5971" class="xref">GIST: General Internet Signalling Transport</a>" <span>[<a href="#RFC5971" class="xref">RFC5971</a>]</span><a href="#section-6.7-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.7-2.3">"<a href="#RFC5973" class="xref">NAT/Firewall NSIS Signaling Layer Protocol (NSLP)</a>" <span>[<a href="#RFC5973" class="xref">RFC5973</a>]</span><a href="#section-6.7-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.7-2.4">"<a href="#RFC5974" class="xref">NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling</a>" <span>[<a href="#RFC5974" class="xref">RFC5974</a>]</span><a href="#section-6.7-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.7-2.5">"<a href="#RFC5981" class="xref">Authorization for NSIS Signaling Layer Protocols</a>" <span>[<a href="#RFC5981" class="xref">RFC5981</a>]</span><a href="#section-6.7-2.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.7-3">The NSIS Working Group worked on signaling techniques for network-layer resources (e.g., QoS resource reservations, Firewall and NAT traversal).<a href="#section-6.7-3" class="pilcrow">¶</a></p>
<p id="section-6.7-4">When RSVP <span>[<a href="#RFC2205" class="xref">RFC2205</a>]</span> was used in deployments, a number of questions came up about its perceived limitations and potential missing features. The issues noted in the NSIS Working Group charter <span>[<a href="#NSIS-CHARTER-2001" class="xref">NSIS-CHARTER-2001</a>]</span> include interworking between domains with different QoS architectures, mobility and roaming for IP interfaces, and complexity. Later, the lack of security in RSVP was also recognized <span>[<a href="#RFC4094" class="xref">RFC4094</a>]</span>.<a href="#section-6.7-4" class="pilcrow">¶</a></p>
<p id="section-6.7-5">The NSIS Working Group was chartered to tackle those issues and initially focused on QoS signaling as its primary use case. However, over time a new approach evolved that introduced a modular architecture using two application-specific signaling protocols: a) the NSIS Signaling Layer Protocol (NSLP) on top of b) a generic
signaling transport protocol (the NSIS Transport Layer Protocol (NTLP)).<a href="#section-6.7-5" class="pilcrow">¶</a></p>
<p id="section-6.7-6">NTLP is defined in <span>[<a href="#RFC5971" class="xref">RFC5971</a>]</span>. Two types of NSLPs are defined: an NSLP for QoS signaling <span>[<a href="#RFC5974" class="xref">RFC5974</a>]</span> and an NSLP for NATs/firewalls <span>[<a href="#RFC5973" class="xref">RFC5973</a>]</span>.<a href="#section-6.7-6" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-6">
<section id="section-6.7.1">
          <h4 id="name-reasons-for-non-deployment-7">
<a href="#section-6.7.1" class="section-number selfRef">6.7.1. </a><a href="#name-reasons-for-non-deployment-7" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.7.1-1">The obstacles for deployment can be grouped into implementation-related aspects and operational aspects.<a href="#section-6.7.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.7.1-2.1">
              <p id="section-6.7.1-2.1.1">Implementation-related aspects:<a href="#section-6.7.1-2.1.1" class="pilcrow">¶</a></p>
<p id="section-6.7.1-2.1.2">Although NSIS provides benefits
    with respect to flexibility, mobility, and security compared to
    other network signaling techniques, hardware vendors were reluctant
    to deploy this solution, because it would require additional
    implementation effort and would result in additional complexity for
    router implementations.<a href="#section-6.7.1-2.1.2" class="pilcrow">¶</a></p>
<p id="section-6.7.1-2.1.3">NTLP mainly operates as a path-coupled signaling protocol, i.e.,
    its messages are processed at the control plane of each intermediate node that is 
    also forwarding the data flows. This requires a
    mechanism to intercept signaling packets while they are forwarded
    in the same manner (especially along the same path) as data
    packets. NSIS uses the
    IPv4 and IPv6 Router Alert Option (RAO) to allow for
    interception of those path-coupled signaling messages, and
    this technique requires router implementations to correctly
    understand and implement the handling of RAOs, e.g., to only
    process packets with RAOs of interest and to leave packets with
    irrelevant RAOs in the fast forwarding processing path (a
    comprehensive discussion of these issues can be found in
    <span>[<a href="#RFC6398" class="xref">RFC6398</a>]</span>). The latter was an issue with some router
    implementations at the time of standardization.<a href="#section-6.7.1-2.1.3" class="pilcrow">¶</a></p>
<p id="section-6.7.1-2.1.4">Another reason is
    that path-coupled signaling protocols that interact with routers
    and request manipulation of state at these routers (or any
    other network element in general) are under scrutiny: a packet (or
    sequence of packets) out of the mainly untrusted data path is
    requesting creation and manipulation of network state. This is
    seen as potentially dangerous (e.g., opens up a DoS threat to a
    router's control plane) and difficult for an operator to control. 
    Path-coupled signaling approaches were considered problematic (see also <span><a href="https://www.rfc-editor.org/rfc/rfc6398#section-3" class="relref">Section 3</a> of [<a href="#RFC6398" class="xref">RFC6398</a>]</span>). There are
    recommendations on how to secure NSIS nodes and
    deployments (e.g., <span>[<a href="#RFC5981" class="xref">RFC5981</a>]</span>).<a href="#section-6.7.1-2.1.4" class="pilcrow">¶</a></p>
</li>
          </ul>
<ul class="normal">
<li class="normal" id="section-6.7.1-3.1">
              <p id="section-6.7.1-3.1.1">Operational Aspects:<a href="#section-6.7.1-3.1.1" class="pilcrow">¶</a></p>
<p id="section-6.7.1-3.1.2">NSIS not only
    required trust between customers and their provider, but also among
    different providers. In particular, QoS signaling techniques would
    require some kind of dynamic SLA support that
    would imply (potentially quite complex) bilateral negotiations
    between different Internet Service Providers. This complexity was 
    not considered to be justified, and increasing the
    bandwidth (and thus avoiding bottlenecks) was 
    cheaper than actively managing network resource bottlenecks by
    using path-coupled QoS signaling techniques. Furthermore, an
    end-to-end path typically involves several provider domains, and
    these providers need to closely cooperate in cases of failures.<a href="#section-6.7.1-3.1.2" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="lessons-learned-6">
<section id="section-6.7.2">
          <h4 id="name-lessons-learned-7">
<a href="#section-6.7.2" class="section-number selfRef">6.7.2. </a><a href="#name-lessons-learned-7" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.7.2-1">One goal of NSIS was to decrease the complexity of the signaling
protocol, but a path-coupled signaling protocol comes with the 
intrinsic complexity of IP-based networks, beyond the complexity of the 
signaling protocol itself. Sources of intrinsic complexity include:<a href="#section-6.7.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.7.2-2.1">the presence of asymmetric routes between endpoints and routers.<a href="#section-6.7.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.7.2-2.2">the lack of security and trust at large in the Internet infrastructure.<a href="#section-6.7.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.7.2-2.3">the presence of different trust boundaries.<a href="#section-6.7.2-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.7.2-2.4">the effects of best-effort networks (e.g., robustness to packet loss).<a href="#section-6.7.2-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.7.2-2.5">divergence from the fate-sharing principle (e.g., state within the network).<a href="#section-6.7.2-2.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.7.2-3">Any path-coupled signaling protocol has to deal with these realities.<a href="#section-6.7.2-3" class="pilcrow">¶</a></p>
<p id="section-6.7.2-4">Operators view the use of IPv4 and IPv6 Router Alert Options (RAOs) to signal routers along the path from end systems with suspicion, because these end systems are usually not authenticated and heavy use of RAOs can easily increase the CPU load on routers that are designed to process most packets using a hardware "fast path" and diverting packets containing RAOs to a slower, more capable processor.<a href="#section-6.7.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="FL">
<section id="section-6.8">
        <h3 id="name-ipv6-flow-labels">
<a href="#section-6.8" class="section-number selfRef">6.8. </a><a href="#name-ipv6-flow-labels" class="section-name selfRef">IPv6 Flow Labels</a>
        </h3>
<p id="section-6.8-1">The suggested reference for IPv6 Flow Labels is:<a href="#section-6.8-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.8-2.1">"<a href="#RFC6437" class="xref">IPv6 Flow Label Specification</a>" <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span><a href="#section-6.8-2.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.8-3">IPv6 specifies a 20-bit Flow Label field <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>, included in the fixed part of the IPv6 header and hence present in every IPv6 packet. An endpoint sets the value  in this field to one of a set of pseudorandomly assigned values. If a packet is not part of any flow, the flow label value is set to zero <span>[<a href="#RFC3697" class="xref">RFC3697</a>]</span>. A number of Standards Track and Best Current Practice RFCs (e.g., <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>, <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>, <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span>) encourage IPv6 endpoints to set a non-zero value in this field. A multiplexing transport could choose to use multiple flow labels to allow the network to either independently forward its subflows or use one common value for the traffic aggregate. The flow label is present in all fragments. IPsec was originally put forward as one important use case for this mechanism and does encrypt the field <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span>.<a href="#section-6.8-3" class="pilcrow">¶</a></p>
<p id="section-6.8-4">Once set, the flow label can provide information that can help inform network nodes about subflows present at the transport layer, without needing to interpret the setting of upper-layer protocol fields <span>[<a href="#RFC6294" class="xref">RFC6294</a>]</span>.  This information can also be used to coordinate how aggregates of transport subflows are grouped when queued in the network and to select appropriate per-flow forwarding when choosing between alternate paths <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span> (e.g., for Equal-Cost Multipath (ECMP) routing and Link Aggregation Groups (LAGs)).<a href="#section-6.8-4" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-7">
<section id="section-6.8.1">
          <h4 id="name-reasons-for-non-deployment-8">
<a href="#section-6.8.1" class="section-number selfRef">6.8.1. </a><a href="#name-reasons-for-non-deployment-8" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.8.1-1">Despite the field being present in every IPv6 packet, the mechanism did not receive as much use as originally envisioned.  One reason is that to be useful it requires engagement by two different  stakeholders:<a href="#section-6.8.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.8.1-2.1">
              <p id="section-6.8.1-2.1.1">Endpoint Implementation:<a href="#section-6.8.1-2.1.1" class="pilcrow">¶</a></p>
<p id="section-6.8.1-2.1.2">For network nodes along a path to utilize the flow label, there needs to be a non-zero value inserted in the field <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span> at the sending endpoint. 
There needs to be an incentive for an endpoint to set an appropriate non-zero value. 
The value should appropriately reflect the level of aggregation the traffic expects to be provided by the network. However, this requires the stack  to know granularity at which flows should be identified (or, conversely, which flows should receive aggregated treatment), i.e., which packets carry the same flow label. Therefore, setting a non-zero value may result in additional choices that need to be made by an application developer.<a href="#section-6.8.1-2.1.2" class="pilcrow">¶</a></p>
<p id="section-6.8.1-2.1.3">Although the original flow label standard <span>[<a href="#RFC3697" class="xref">RFC3697</a>]</span> forbids any encoding of meaning into the flow label value, the opportunity to use the flow label as a covert channel or to signal other meta-information may have raised concerns about setting a non-zero value <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>.<a href="#section-6.8.1-2.1.3" class="pilcrow">¶</a></p>
<p id="section-6.8.1-2.1.4">Before methods are widely deployed to use this method, there could be no incentive for an endpoint to set the field.<a href="#section-6.8.1-2.1.4" class="pilcrow">¶</a></p>
</li>
          </ul>
<ul class="normal">
<li class="normal" id="section-6.8.1-3.1">
              <p id="section-6.8.1-3.1.1">Operational support in network nodes:<a href="#section-6.8.1-3.1.1" class="pilcrow">¶</a></p>
<p id="section-6.8.1-3.1.2">A benefit can only be realized when a network node along the path also uses this information to inform its decisions. Network equipment (routers and/or middleboxes) need to include appropriate support in order to utilize the field when making decisions about how to classify flows or forward packets. The use of any optional feature in a network node also requires corresponding updates to operational procedures and therefore is normally only introduced when the cost can be justified.<a href="#section-6.8.1-3.1.2" class="pilcrow">¶</a></p>
<p id="section-6.8.1-3.1.3">A benefit from utilizing the flow label is expected to be increased quality of experience for applications -- but this comes at some operational cost to an operator and requires endpoints to set the field.<a href="#section-6.8.1-3.1.3" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="lessons-learned-7">
<section id="section-6.8.2">
          <h4 id="name-lessons-learned-8">
<a href="#section-6.8.2" class="section-number selfRef">6.8.2. </a><a href="#name-lessons-learned-8" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.8.2-1">The flow label is a general-purpose header field for use by the path. Multiple uses have been proposed. One candidate use was to reduce the  complexity of forwarding decisions. However,  modern routers can use a "fast path", often taking advantage of hardware to accelerate processing. The method can assist in more complex forwarding, such as ECMP routing and load balancing.<a href="#section-6.8.2-1" class="pilcrow">¶</a></p>
<p id="section-6.8.2-2">Although <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span> recommended that endpoints should by default choose uniformly distributed labels for their traffic, the specification permitted an endpoint to choose to set a zero value. This ability of endpoints to choose to set a flow label of zero has had consequences on deployability:<a href="#section-6.8.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.8.2-3.1">Before wide-scale support by endpoints, it would be impossible to rely on a non-zero flow label being set. Network nodes therefore would need to also employ other techniques to realize equivalent functions. An example of a method is one assuming semantics of the source port field to provide entropy input to a network-layer hash. This use of a 5-tuple to classify a packet represents a layering violation <span>[<a href="#RFC6294" class="xref">RFC6294</a>]</span>. When other methods have been deployed, they increase the cost of deploying standards-based methods, even though they may offer less control to  endpoints and result in potential interaction with other uses/interpretation of the field.<a href="#section-6.8.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.8.2-3.2">Even though the flow label is specified as an end-to-end field, some network paths have been observed to not transparently forward the flow label. This could result from non-conformant equipment or could indicate that some operational networks have chosen to reuse the protocol field for other (e.g., internal) purposes. This results in lack of transparency, and a deployment hurdle to endpoints expecting that they can set a flow label that is utilized by the network.  The more recent practice of "greasing" <span>[<a href="#I-D.iab-use-it-or-lose-it" class="xref">GREASE</a>]</span> would suggest that a different outcome could have been achieved if endpoints were always required to set a non-zero value.<a href="#section-6.8.2-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.8.2-3.3">
              <span>[<a href="#RFC1809" class="xref">RFC1809</a>]</span> noted that setting the choice of the flow label value can depend on the expectations of the traffic generated by an application, which suggests that an API should be presented to control the setting or policy that is used. However, many currently available APIs do not have this support.<a href="#section-6.8.2-3.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.8.2-4">A growth in the use of encrypted transports (e.g., QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>) seems likely to raise issues similar to those discussed above and could motivate renewed interest in utilizing the flow label.<a href="#section-6.8.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="ecn">
<section id="section-6.9">
        <h3 id="name-explicit-congestion-notific">
<a href="#section-6.9" class="section-number selfRef">6.9. </a><a href="#name-explicit-congestion-notific" class="section-name selfRef">Explicit Congestion Notification (ECN)</a>
        </h3>
<p id="section-6.9-1">The suggested references for Explicit Congestion Notification (ECN) are:<a href="#section-6.9-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.9-2.1">"<a href="#RFC2309" class="xref">Recommendations on Queue Management and Congestion Avoidance in the Internet</a>" <span>[<a href="#RFC2309" class="xref">RFC2309</a>]</span><a href="#section-6.9-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.9-2.2">"<a href="#RFC2481" class="xref">A Proposal to add Explicit Congestion Notification (ECN) to IP</a>" <span>[<a href="#RFC2481" class="xref">RFC2481</a>]</span><a href="#section-6.9-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.9-2.3">"<a href="#RFC3168" class="xref">The Addition of Explicit Congestion Notification (ECN) to IP</a>" <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span><a href="#section-6.9-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.9-2.4">"Implementation Report on Experiences with Various TCP RFCs" <span>[<a href="#vista-impl" class="xref">vista-impl</a>]</span>, slides 6 and 7<a href="#section-6.9-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.9-2.5">"Implementation and Deployment of ECN" (at <span>[<a href="#SallyFloyd" class="xref">SallyFloyd</a>]</span>)<a href="#section-6.9-2.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.9-3">In the early 1990s, the large majority of Internet traffic used TCP as its transport protocol, but TCP had no way to detect path congestion before the path was so congested that packets were being dropped. These congestion events could affect all senders using a path, either by "lockout", where long-lived flows monopolized the queues along a path, or by "full queues", where queues remain full, or almost full, for a long period of time.<a href="#section-6.9-3" class="pilcrow">¶</a></p>
<p id="section-6.9-4">In response to this situation, "Active Queue Management" (AQM) was deployed in the network. A number of AQM disciplines have been deployed, but one common approach was that routers dropped packets when a threshold buffer length was reached, so that transport protocols like TCP that were responsive to loss would detect this loss and reduce their sending rates. Random Early Detection (RED) was one such proposal in the IETF. As the name suggests, a router using RED as its AQM discipline that detected time-averaged queue lengths passing a threshold would choose incoming packets probabilistically to be dropped <span>[<a href="#RFC2309" class="xref">RFC2309</a>]</span>.<a href="#section-6.9-4" class="pilcrow">¶</a></p>
<p id="section-6.9-5">Researchers suggested providing "explicit congestion notifications" to senders when routers along the path detected that their queues were building,
giving senders an opportunity to "slow down" as if a loss had occurred, giving path queues time to drain, while the path still had sufficient buffer capacity to accommodate bursty arrivals of packets from other senders. This was proposed as an experiment in <span>[<a href="#RFC2481" class="xref">RFC2481</a>]</span> and standardized in <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span>.<a href="#section-6.9-5" class="pilcrow">¶</a></p>
<p id="section-6.9-6">A key aspect of ECN was the use of IP header fields rather than IP options to carry explicit congestion notifications, since the proponents recognized that<a href="#section-6.9-6" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-6.9-7">
        Many routers process the "regular" headers in IP packets more 
  efficiently than they process the header information in IP
  options.<a href="#section-6.9-7" class="pilcrow">¶</a></p>
<p id="section-6.9-8">Unlike most of the Path Aware technologies included in this document, the story of ECN continues to the present day and encountered a large number of Lessons Learned during that time. The early history of ECN (non-)deployment provides Lessons Learned that were not captured by other contributions in <a href="#Contributions" class="xref">Section 6</a>, so that is the emphasis in this section of the document.<a href="#section-6.9-8" class="pilcrow">¶</a></p>
<div id="reasons-for-non-deployment-8">
<section id="section-6.9.1">
          <h4 id="name-reasons-for-non-deployment-9">
<a href="#section-6.9.1" class="section-number selfRef">6.9.1. </a><a href="#name-reasons-for-non-deployment-9" class="section-name selfRef">Reasons for Non-deployment</a>
          </h4>
<p id="section-6.9.1-1">ECN deployment relied on three factors -- support in client implementations, support in router implementations, and deployment decisions in operational networks.<a href="#section-6.9.1-1" class="pilcrow">¶</a></p>
<p id="section-6.9.1-2">The proponents of ECN did so much right, anticipating many of the Lessons Learned now recognized in <a href="#LessonsLearned" class="xref">Section 4</a>. They recognized the need to support incremental deployment (<a href="#EarlyAdopters" class="xref">Section 4.2</a>). They considered the impact on router throughput (<a href="#Fast-paths" class="xref">Section 4.8</a>). They even considered trust issues between end nodes and the network, for both non-compliant end nodes (<a href="#IDsTrustingEndpoints" class="xref">Section 4.10</a>) and non-compliant routers (<a href="#EndpointsTrustingIDs" class="xref">Section 4.9</a>).<a href="#section-6.9.1-2" class="pilcrow">¶</a></p>
<p id="section-6.9.1-3">They were rewarded with ECN being implemented in major operating systems, for both end nodes and routers. A number of implementations are listed under "Implementation and Deployment of ECN" at <span>[<a href="#SallyFloyd" class="xref">SallyFloyd</a>]</span>.<a href="#section-6.9.1-3" class="pilcrow">¶</a></p>
<p id="section-6.9.1-4">What they did not anticipate was routers that would crash when they saw bits 6 and 7 in the IPv4 Type of Service (TOS) octet <span>[<a href="#RFC0791" class="xref">RFC0791</a>]</span> / IPv6 Traffic Class field <span>[<a href="#RFC2460" class="xref">RFC2460</a>]</span>, which <span>[<a href="#RFC2481" class="xref">RFC2481</a>]</span> redefined to be "Currently Unused", being set to a non-zero value.<a href="#section-6.9.1-4" class="pilcrow">¶</a></p>
<p id="section-6.9.1-5">As described in <span>[<a href="#vista-impl" class="xref">vista-impl</a>]</span> ("IGD" stands for "Intermediate Gateway Device"),<a href="#section-6.9.1-5" class="pilcrow">¶</a></p>
<blockquote id="section-6.9.1-6">
          IGD problem #1: one of the most popular versions from one of the most popular vendors.
When a data packet arrives with either ECT(0) or ECT(1) (indicating successful ECN capability negotiation) indicated, router crashed.
Cannot be recovered at TCP layer [sic]<a href="#section-6.9.1-6" class="pilcrow">¶</a>
</blockquote>
<p id="section-6.9.1-7">This implementation, which would be run on a significant percentage of Internet end nodes, was shipped with ECN disabled, as was true for several of the other implementations listed under "Implementation and Deployment of ECN" at <span>[<a href="#SallyFloyd" class="xref">SallyFloyd</a>]</span>. Even if subsequent router vendors fixed these implementations, ECN was still disabled on end nodes, and given the trade-off between the benefits of enabling ECN (somewhat better behavior during congestion) and the risks of enabling ECN (possibly crashing a router somewhere along the path), ECN tended to stay disabled on implementations that supported ECN for decades afterwards.<a href="#section-6.9.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lessons-learned-8">
<section id="section-6.9.2">
          <h4 id="name-lessons-learned-9">
<a href="#section-6.9.2" class="section-number selfRef">6.9.2. </a><a href="#name-lessons-learned-9" class="section-name selfRef">Lessons Learned</a>
          </h4>
<p id="section-6.9.2-1">Of the contributions included in <a href="#Contributions" class="xref">Section 6</a>, ECN may be unique in providing these lessons:<a href="#section-6.9.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.9.2-2.1">Even if you do everything right, you may trip over implementation bugs in devices you know nothing about, that will cause severe problems that prevent successful deployment of your Path Aware technology.<a href="#section-6.9.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.9.2-2.2">After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by default.<a href="#section-6.9.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.9.2-3">These two lessons, taken together, could be summarized as "you get one chance to get it right."<a href="#section-6.9.2-3" class="pilcrow">¶</a></p>
<p id="section-6.9.2-4">During discussion of ECN at <span>[<a href="#PANRG-110" class="xref">PANRG-110</a>]</span>, we noted that "you get one chance to get it right" isn't quite correct today, because operating systems on so many host systems are frequently updated, and transport protocols like QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span> are being implemented in user space and can be updated without touching installed operating systems. Neither of these factors were true in the early 2000s.<a href="#section-6.9.2-4" class="pilcrow">¶</a></p>
<p id="section-6.9.2-5">We think that these restatements of the ECN Lessons Learned are more useful for current implementers:<a href="#section-6.9.2-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.9.2-6.1">Even if you do everything right, you may trip over implementation bugs in devices you know nothing about, that will cause severe problems that prevent successful deployment of your Path Aware technology. Testing before deployment isn't enough to ensure successful deployment. It is also necessary to "deploy gently", which often means deploying for a small subset of users to gain experience and implementing feedback mechanisms to detect that user experience is being degraded.<a href="#section-6.9.2-6.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.9.2-6.2">After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by default. This might be based on the difficulty of distributing implementations that enable it by default, but it is just as likely to be based on the "bad taste in the mouth" that implementers have after an unsuccessful deployment attempt that degraded user experience.<a href="#section-6.9.2-6.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.9.2-7">With these expansions, the two lessons, taken together, could be more helpfully summarized as "plan for failure" -- anticipate what your next step will be, if initial deployment is unsuccessful.<a href="#section-6.9.2-7" class="pilcrow">¶</a></p>
<p id="section-6.9.2-8">ECN deployment was also hindered by non-deployment of AQM in many devices, because of operator interest in QoS features provided in the network, rather than using the network to assist end systems in providing for themselves. But that's another story, and the AQM Lessons Learned are already covered in other contributions in <a href="#Contributions" class="xref">Section 6</a>.<a href="#section-6.9.2-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="security-considerations">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">This document describes Path Aware techniques that were not adopted and widely deployed on the Internet, so it doesn't affect the security of the Internet.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">If this document meets its goals, we may develop new techniques for Path Aware networking that would affect the security of the Internet, but security considerations for those techniques will be described in the corresponding RFCs that specify them.<a href="#section-7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-informative-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="Colossal-Cave">[Colossal-Cave]</dt>
      <dd>
<span class="refAuthor">Wikipedia</span>, <span class="refTitle">"Colossal Cave Adventure"</span>, <time datetime="2021-06" class="refDate">June 2021</time>, <span>&lt;<a href="https://en.wikipedia.org/w/index.php?title=Colossal_Cave_Adventure&amp;oldid=1027119625">https://en.wikipedia.org/w/index.php?title=Colossal_Cave_Adventure&amp;oldid=1027119625</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Conviva">[Conviva]</dt>
      <dd>
<span class="refTitle">"Conviva Precision : Data Sheet"</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.conviva.com/datasheets/precision-delivery-intelligence/">https://www.conviva.com/datasheets/precision-delivery-intelligence/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.farrell-etm">[FARRELL-ETM]</dt>
      <dd>
<span class="refAuthor">Farrell, S.</span>, <span class="refTitle">"We're gonna need a bigger threat model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-farrell-etm-03</span>, <time datetime="2019-07-06" class="refDate">6 July 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-farrell-etm-03">https://datatracker.ietf.org/doc/html/draft-farrell-etm-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.iab-use-it-or-lose-it">[GREASE]</dt>
      <dd>
<span class="refAuthor">Thomson, M.</span>, <span class="refTitle">"Long-term Viability of Protocol Extension Mechanisms"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-iab-use-it-or-lose-it-00</span>, <time datetime="2019-08-07" class="refDate">7 August 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it-00">https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEN-119">[IEN-119]</dt>
      <dd>
<span class="refAuthor">Forgie, J.</span>, <span class="refTitle">"ST - A Proposed Internet Stream Protocol"</span>, <time datetime="1979-09" class="refDate">September 1979</time>, <span>&lt;<a href="https://www.rfc-editor.org/ien/ien119.txt">https://www.rfc-editor.org/ien/ien119.txt</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.arkko-arch-internet-threat-model">[INTERNET-THREAT-MODEL]</dt>
      <dd>
<span class="refAuthor">Arkko, J.</span>, <span class="refTitle">"Changes in the Internet Threat Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-arkko-arch-internet-threat-model-01</span>, <time datetime="2019-07-08" class="refDate">8 July 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-arkko-arch-internet-threat-model-01">https://datatracker.ietf.org/doc/html/draft-arkko-arch-internet-threat-model-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tsvwg-intserv-multiple-tspec">[INTSERV-MULTIPLE-TSPEC]</dt>
      <dd>
<span class="refAuthor">Polk, J.</span> and <span class="refAuthor">S. Dhesikan</span>, <span class="refTitle">"Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tsvwg-intserv-multiple-tspec-02</span>, <time datetime="2013-02-25" class="refDate">25 February 2013</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-intserv-multiple-tspec-02">https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-intserv-multiple-tspec-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ITAT">[ITAT]</dt>
      <dd>
<span class="refTitle">"IAB Workshop on Internet Technology Adoption and Transition (ITAT) 2013"</span>, <time datetime="2013-12" class="refDate">December 2013</time>, <span>&lt;<a href="https://www.iab.org/activities/workshops/itat/">https://www.iab.org/activities/workshops/itat/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="model-t">[model-t]</dt>
      <dd>
<span class="refTitle">"Model-t -- Discussions of changes in Internet deployment patterns and their impact on the Internet threat model"</span>, <span class="refContent">model-t mailing list</span>, <span>&lt;<a href="https://www.iab.org/mailman/listinfo/model-t">https://www.iab.org/mailman/listinfo/model-t</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MOPS-109-Min">[MOPS-109-Min]</dt>
      <dd>
<span class="refTitle">"Media Operations Working Group - IETF 109 Minutes"</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="https://datatracker.ietf.org/meeting/109/materials/minutes-109-mops-00">https://datatracker.ietf.org/meeting/109/materials/minutes-109-mops-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MP-TCP">[MP-TCP]</dt>
      <dd>
<span class="refTitle">"Multipath TCP Working Group Home Page"</span>, <span>&lt;<a href="https://datatracker.ietf.org/wg/mptcp/">https://datatracker.ietf.org/wg/mptcp/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NANOG-35">[NANOG-35]</dt>
      <dd>
<span class="refTitle">"NANOG 35 Agenda"</span>, <span class="refContent">North American Network Operators' Group (NANOG)</span>, <time datetime="2005-10" class="refDate">October 2005</time>, <span>&lt;<a href="https://archive.nanog.org/meetings/nanog35/agenda">https://archive.nanog.org/meetings/nanog35/agenda</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NSIS-CHARTER-2001">[NSIS-CHARTER-2001]</dt>
      <dd>
<span class="refTitle">"Next Steps In Signaling Working Group Charter"</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/charter-ietf-nsis/">https://datatracker.ietf.org/doc/charter-ietf-nsis/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PANRG">[PANRG]</dt>
      <dd>
<span class="refTitle">"Path Aware Networking Research Group Home Page"</span>, <span>&lt;<a href="https://irtf.org/panrg">https://irtf.org/panrg</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PANRG-103-Min">[PANRG-103-Min]</dt>
      <dd>
<span class="refTitle">"Path Aware Networking Research Group - IETF 103 Minutes"</span>, <time datetime="2018-11" class="refDate">November 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/minutes-103-panrg/">https://datatracker.ietf.org/doc/minutes-103-panrg/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PANRG-105-Min">[PANRG-105-Min]</dt>
      <dd>
<span class="refTitle">"Path Aware Networking Research Group - IETF 105 Minutes"</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/minutes-105-panrg/">https://datatracker.ietf.org/doc/minutes-105-panrg/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PANRG-106-Min">[PANRG-106-Min]</dt>
      <dd>
<span class="refTitle">"Path Aware Networking Research Group - IETF 106 Minutes"</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/minutes-106-panrg/">https://datatracker.ietf.org/doc/minutes-106-panrg/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PANRG-110">[PANRG-110]</dt>
      <dd>
<span class="refTitle">"Path Aware Networking Research Group - IETF 110"</span>, <time datetime="2021-03" class="refDate">March 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/meeting/110/session/panrg">https://datatracker.ietf.org/meeting/110/session/panrg</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PANRG-99">[PANRG-99]</dt>
      <dd>
<span class="refTitle">"Path Aware Networking Research Group - IETF 99"</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://datatracker.ietf.org/meeting/99/session/panrg">https://datatracker.ietf.org/meeting/99/session/panrg</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-panrg-path-properties">[PANRG-PATH-PROPERTIES]</dt>
      <dd>
<span class="refAuthor">Enghardt, T.</span> and <span class="refAuthor">C. Krähenbühl</span>, <span class="refTitle">"A Vocabulary of Path Properties"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-panrg-path-properties-02</span>, <time datetime="2021-02-22" class="refDate">22 February 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-irtf-panrg-path-properties-02">https://datatracker.ietf.org/doc/html/draft-irtf-panrg-path-properties-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-panrg-questions">[PANRG-QUESTIONS]</dt>
      <dd>
<span class="refAuthor">Trammell, B.</span>, <span class="refTitle">"Current Open Questions in Path Aware Networking"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-panrg-questions-09</span>, <time datetime="2021-04-16" class="refDate">16 April 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-irtf-panrg-questions-09">https://datatracker.ietf.org/doc/html/draft-irtf-panrg-questions-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PATH-Decade">[PATH-Decade]</dt>
      <dd>
<span class="refAuthor">Bonaventure, O.</span>, <span class="refTitle">"A Decade of Path Awareness"</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/slides-99-panrg-a-decade-of-path-awareness/">https://datatracker.ietf.org/doc/slides-99-panrg-a-decade-of-path-awareness/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="QS-SAT">[QS-SAT]</dt>
      <dd>
<span class="refAuthor">Secchi, R.</span>, <span class="refAuthor">Sathiaseelan, A.</span>, <span class="refAuthor">Potortì, F.</span>, <span class="refAuthor">Gotta, A.</span>, and <span class="refAuthor">G. Fairhurst</span>, <span class="refTitle">"Using Quick-Start to enhance TCP-friendly rate control performance in bidirectional satellite networks"</span>, <span class="seriesInfo">DOI 10.1002/sat.929</span>, <time datetime="2009-05" class="refDate">May 2009</time>, <span>&lt;<a href="https://dl.acm.org/citation.cfm?id=3160304.3160305">https://dl.acm.org/citation.cfm?id=3160304.3160305</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0791">[RFC0791]</dt>
      <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 791</span>, <span class="seriesInfo">DOI 10.17487/RFC0791</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc791">https://www.rfc-editor.org/info/rfc791</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0792">[RFC0792]</dt>
      <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Control Message Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 792</span>, <span class="seriesInfo">DOI 10.17487/RFC0792</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc792">https://www.rfc-editor.org/info/rfc792</a>&gt;</span>. </dd>
<dd class="break"></dd>
<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="RFC1016">[RFC1016]</dt>
      <dd>
<span class="refAuthor">Prue, W.</span> and <span class="refAuthor">J. Postel</span>, <span class="refTitle">"Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)"</span>, <span class="seriesInfo">RFC 1016</span>, <span class="seriesInfo">DOI 10.17487/RFC1016</span>, <time datetime="1987-07" class="refDate">July 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1016">https://www.rfc-editor.org/info/rfc1016</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="RFC1190">[RFC1190]</dt>
      <dd>
<span class="refAuthor">Topolcic, C.</span>, <span class="refTitle">"Experimental Internet Stream Protocol: Version 2 (ST-II)"</span>, <span class="seriesInfo">RFC 1190</span>, <span class="seriesInfo">DOI 10.17487/RFC1190</span>, <time datetime="1990-10" class="refDate">October 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1190">https://www.rfc-editor.org/info/rfc1190</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1633">[RFC1633]</dt>
      <dd>
<span class="refAuthor">Braden, R.</span>, <span class="refAuthor">Clark, D.</span>, and <span class="refAuthor">S. Shenker</span>, <span class="refTitle">"Integrated Services in the Internet Architecture: an Overview"</span>, <span class="seriesInfo">RFC 1633</span>, <span class="seriesInfo">DOI 10.17487/RFC1633</span>, <time datetime="1994-06" class="refDate">June 1994</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1633">https://www.rfc-editor.org/info/rfc1633</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1809">[RFC1809]</dt>
      <dd>
<span class="refAuthor">Partridge, C.</span>, <span class="refTitle">"Using the Flow Label Field in IPv6"</span>, <span class="seriesInfo">RFC 1809</span>, <span class="seriesInfo">DOI 10.17487/RFC1809</span>, <time datetime="1995-06" class="refDate">June 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1809">https://www.rfc-editor.org/info/rfc1809</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1819">[RFC1819]</dt>
      <dd>
<span class="refAuthor">Delgrossi, L., Ed.</span> and <span class="refAuthor">L. Berger, Ed.</span>, <span class="refTitle">"Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+"</span>, <span class="seriesInfo">RFC 1819</span>, <span class="seriesInfo">DOI 10.17487/RFC1819</span>, <time datetime="1995-08" class="refDate">August 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1819">https://www.rfc-editor.org/info/rfc1819</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1887">[RFC1887]</dt>
      <dd>
<span class="refAuthor">Rekhter, Y., Ed.</span> and <span class="refAuthor">T. Li, Ed.</span>, <span class="refTitle">"An Architecture for IPv6 Unicast Address Allocation"</span>, <span class="seriesInfo">RFC 1887</span>, <span class="seriesInfo">DOI 10.17487/RFC1887</span>, <time datetime="1995-12" class="refDate">December 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1887">https://www.rfc-editor.org/info/rfc1887</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="RFC2205">[RFC2205]</dt>
      <dd>
<span class="refAuthor">Braden, R., Ed.</span>, <span class="refAuthor">Zhang, L.</span>, <span class="refAuthor">Berson, S.</span>, <span class="refAuthor">Herzog, S.</span>, and <span class="refAuthor">S. Jamin</span>, <span class="refTitle">"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"</span>, <span class="seriesInfo">RFC 2205</span>, <span class="seriesInfo">DOI 10.17487/RFC2205</span>, <time datetime="1997-09" class="refDate">September 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2205">https://www.rfc-editor.org/info/rfc2205</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2210">[RFC2210]</dt>
      <dd>
<span class="refAuthor">Wroclawski, J.</span>, <span class="refTitle">"The Use of RSVP with IETF Integrated Services"</span>, <span class="seriesInfo">RFC 2210</span>, <span class="seriesInfo">DOI 10.17487/RFC2210</span>, <time datetime="1997-09" class="refDate">September 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2210">https://www.rfc-editor.org/info/rfc2210</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2211">[RFC2211]</dt>
      <dd>
<span class="refAuthor">Wroclawski, J.</span>, <span class="refTitle">"Specification of the Controlled-Load Network Element Service"</span>, <span class="seriesInfo">RFC 2211</span>, <span class="seriesInfo">DOI 10.17487/RFC2211</span>, <time datetime="1997-09" class="refDate">September 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2211">https://www.rfc-editor.org/info/rfc2211</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2212">[RFC2212]</dt>
      <dd>
<span class="refAuthor">Shenker, S.</span>, <span class="refAuthor">Partridge, C.</span>, and <span class="refAuthor">R. Guerin</span>, <span class="refTitle">"Specification of Guaranteed Quality of Service"</span>, <span class="seriesInfo">RFC 2212</span>, <span class="seriesInfo">DOI 10.17487/RFC2212</span>, <time datetime="1997-09" class="refDate">September 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2212">https://www.rfc-editor.org/info/rfc2212</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2215">[RFC2215]</dt>
      <dd>
<span class="refAuthor">Shenker, S.</span> and <span class="refAuthor">J. Wroclawski</span>, <span class="refTitle">"General Characterization Parameters for Integrated Service Network Elements"</span>, <span class="seriesInfo">RFC 2215</span>, <span class="seriesInfo">DOI 10.17487/RFC2215</span>, <time datetime="1997-09" class="refDate">September 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2215">https://www.rfc-editor.org/info/rfc2215</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2309">[RFC2309]</dt>
      <dd>
<span class="refAuthor">Braden, B.</span>, <span class="refAuthor">Clark, D.</span>, <span class="refAuthor">Crowcroft, J.</span>, <span class="refAuthor">Davie, B.</span>, <span class="refAuthor">Deering, S.</span>, <span class="refAuthor">Estrin, D.</span>, <span class="refAuthor">Floyd, S.</span>, <span class="refAuthor">Jacobson, V.</span>, <span class="refAuthor">Minshall, G.</span>, <span class="refAuthor">Partridge, C.</span>, <span class="refAuthor">Peterson, L.</span>, <span class="refAuthor">Ramakrishnan, K.</span>, <span class="refAuthor">Shenker, S.</span>, <span class="refAuthor">Wroclawski, J.</span>, and <span class="refAuthor">L. Zhang</span>, <span class="refTitle">"Recommendations on Queue Management and Congestion Avoidance in the Internet"</span>, <span class="seriesInfo">RFC 2309</span>, <span class="seriesInfo">DOI 10.17487/RFC2309</span>, <time datetime="1998-04" class="refDate">April 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2309">https://www.rfc-editor.org/info/rfc2309</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2460">[RFC2460]</dt>
      <dd>
<span class="refAuthor">Deering, S.</span> and <span class="refAuthor">R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">RFC 2460</span>, <span class="seriesInfo">DOI 10.17487/RFC2460</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2460">https://www.rfc-editor.org/info/rfc2460</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2475">[RFC2475]</dt>
      <dd>
<span class="refAuthor">Blake, S.</span>, <span class="refAuthor">Black, D.</span>, <span class="refAuthor">Carlson, M.</span>, <span class="refAuthor">Davies, E.</span>, <span class="refAuthor">Wang, Z.</span>, and <span class="refAuthor">W. Weiss</span>, <span class="refTitle">"An Architecture for Differentiated Services"</span>, <span class="seriesInfo">RFC 2475</span>, <span class="seriesInfo">DOI 10.17487/RFC2475</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2475">https://www.rfc-editor.org/info/rfc2475</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2481">[RFC2481]</dt>
      <dd>
<span class="refAuthor">Ramakrishnan, K.</span> and <span class="refAuthor">S. Floyd</span>, <span class="refTitle">"A Proposal to add Explicit Congestion Notification (ECN) to IP"</span>, <span class="seriesInfo">RFC 2481</span>, <span class="seriesInfo">DOI 10.17487/RFC2481</span>, <time datetime="1999-01" class="refDate">January 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2481">https://www.rfc-editor.org/info/rfc2481</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3168">[RFC3168]</dt>
      <dd>
<span class="refAuthor">Ramakrishnan, K.</span>, <span class="refAuthor">Floyd, S.</span>, and <span class="refAuthor">D. Black</span>, <span class="refTitle">"The Addition of Explicit Congestion Notification (ECN) to IP"</span>, <span class="seriesInfo">RFC 3168</span>, <span class="seriesInfo">DOI 10.17487/RFC3168</span>, <time datetime="2001-09" class="refDate">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3168">https://www.rfc-editor.org/info/rfc3168</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3697">[RFC3697]</dt>
      <dd>
<span class="refAuthor">Rajahalme, J.</span>, <span class="refAuthor">Conta, A.</span>, <span class="refAuthor">Carpenter, B.</span>, and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"IPv6 Flow Label Specification"</span>, <span class="seriesInfo">RFC 3697</span>, <span class="seriesInfo">DOI 10.17487/RFC3697</span>, <time datetime="2004-03" class="refDate">March 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3697">https://www.rfc-editor.org/info/rfc3697</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4094">[RFC4094]</dt>
      <dd>
<span class="refAuthor">Manner, J.</span> and <span class="refAuthor">X. Fu</span>, <span class="refTitle">"Analysis of Existing Quality-of-Service Signaling Protocols"</span>, <span class="seriesInfo">RFC 4094</span>, <span class="seriesInfo">DOI 10.17487/RFC4094</span>, <time datetime="2005-05" class="refDate">May 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4094">https://www.rfc-editor.org/info/rfc4094</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4443">[RFC4443]</dt>
      <dd>
<span class="refAuthor">Conta, A.</span>, <span class="refAuthor">Deering, S.</span>, and <span class="refAuthor">M. Gupta, Ed.</span>, <span class="refTitle">"Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 89</span>, <span class="seriesInfo">RFC 4443</span>, <span class="seriesInfo">DOI 10.17487/RFC4443</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4443">https://www.rfc-editor.org/info/rfc4443</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4782">[RFC4782]</dt>
      <dd>
<span class="refAuthor">Floyd, S.</span>, <span class="refAuthor">Allman, M.</span>, <span class="refAuthor">Jain, A.</span>, and <span class="refAuthor">P. Sarolahti</span>, <span class="refTitle">"Quick-Start for TCP and IP"</span>, <span class="seriesInfo">RFC 4782</span>, <span class="seriesInfo">DOI 10.17487/RFC4782</span>, <time datetime="2007-01" class="refDate">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4782">https://www.rfc-editor.org/info/rfc4782</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5082">[RFC5082]</dt>
      <dd>
<span class="refAuthor">Gill, V.</span>, <span class="refAuthor">Heasley, J.</span>, <span class="refAuthor">Meyer, D.</span>, <span class="refAuthor">Savola, P., Ed.</span>, and <span class="refAuthor">C. Pignataro</span>, <span class="refTitle">"The Generalized TTL Security Mechanism (GTSM)"</span>, <span class="seriesInfo">RFC 5082</span>, <span class="seriesInfo">DOI 10.17487/RFC5082</span>, <time datetime="2007-10" class="refDate">October 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5082">https://www.rfc-editor.org/info/rfc5082</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5218">[RFC5218]</dt>
      <dd>
<span class="refAuthor">Thaler, D.</span> and <span class="refAuthor">B. Aboba</span>, <span class="refTitle">"What Makes for a Successful Protocol?"</span>, <span class="seriesInfo">RFC 5218</span>, <span class="seriesInfo">DOI 10.17487/RFC5218</span>, <time datetime="2008-07" class="refDate">July 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5218">https://www.rfc-editor.org/info/rfc5218</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5533">[RFC5533]</dt>
      <dd>
<span class="refAuthor">Nordmark, E.</span> and <span class="refAuthor">M. Bagnulo</span>, <span class="refTitle">"Shim6: Level 3 Multihoming Shim Protocol for IPv6"</span>, <span class="seriesInfo">RFC 5533</span>, <span class="seriesInfo">DOI 10.17487/RFC5533</span>, <time datetime="2009-06" class="refDate">June 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5533">https://www.rfc-editor.org/info/rfc5533</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5575">[RFC5575]</dt>
      <dd>
<span class="refAuthor">Marques, P.</span>, <span class="refAuthor">Sheth, N.</span>, <span class="refAuthor">Raszuk, R.</span>, <span class="refAuthor">Greene, B.</span>, <span class="refAuthor">Mauch, J.</span>, and <span class="refAuthor">D. McPherson</span>, <span class="refTitle">"Dissemination of Flow Specification Rules"</span>, <span class="seriesInfo">RFC 5575</span>, <span class="seriesInfo">DOI 10.17487/RFC5575</span>, <time datetime="2009-08" class="refDate">August 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5575">https://www.rfc-editor.org/info/rfc5575</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="RFC5971">[RFC5971]</dt>
      <dd>
<span class="refAuthor">Schulzrinne, H.</span> and <span class="refAuthor">R. Hancock</span>, <span class="refTitle">"GIST: General Internet Signalling Transport"</span>, <span class="seriesInfo">RFC 5971</span>, <span class="seriesInfo">DOI 10.17487/RFC5971</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5971">https://www.rfc-editor.org/info/rfc5971</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5973">[RFC5973]</dt>
      <dd>
<span class="refAuthor">Stiemerling, M.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Aoun, C.</span>, and <span class="refAuthor">E. Davies</span>, <span class="refTitle">"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)"</span>, <span class="seriesInfo">RFC 5973</span>, <span class="seriesInfo">DOI 10.17487/RFC5973</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5973">https://www.rfc-editor.org/info/rfc5973</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5974">[RFC5974]</dt>
      <dd>
<span class="refAuthor">Manner, J.</span>, <span class="refAuthor">Karagiannis, G.</span>, and <span class="refAuthor">A. McDonald</span>, <span class="refTitle">"NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling"</span>, <span class="seriesInfo">RFC 5974</span>, <span class="seriesInfo">DOI 10.17487/RFC5974</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5974">https://www.rfc-editor.org/info/rfc5974</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5981">[RFC5981]</dt>
      <dd>
<span class="refAuthor">Manner, J.</span>, <span class="refAuthor">Stiemerling, M.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">R. Bless, Ed.</span>, <span class="refTitle">"Authorization for NSIS Signaling Layer Protocols"</span>, <span class="seriesInfo">RFC 5981</span>, <span class="seriesInfo">DOI 10.17487/RFC5981</span>, <time datetime="2011-02" class="refDate">February 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5981">https://www.rfc-editor.org/info/rfc5981</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6294">[RFC6294]</dt>
      <dd>
<span class="refAuthor">Hu, Q.</span> and <span class="refAuthor">B. Carpenter</span>, <span class="refTitle">"Survey of Proposed Use Cases for the IPv6 Flow Label"</span>, <span class="seriesInfo">RFC 6294</span>, <span class="seriesInfo">DOI 10.17487/RFC6294</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6294">https://www.rfc-editor.org/info/rfc6294</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6398">[RFC6398]</dt>
      <dd>
<span class="refAuthor">Le Faucheur, F., Ed.</span>, <span class="refTitle">"IP Router Alert Considerations and Usage"</span>, <span class="seriesInfo">BCP 168</span>, <span class="seriesInfo">RFC 6398</span>, <span class="seriesInfo">DOI 10.17487/RFC6398</span>, <time datetime="2011-10" class="refDate">October 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6398">https://www.rfc-editor.org/info/rfc6398</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="RFC6438">[RFC6438]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span> and <span class="refAuthor">S. Amante</span>, <span class="refTitle">"Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels"</span>, <span class="seriesInfo">RFC 6438</span>, <span class="seriesInfo">DOI 10.17487/RFC6438</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6438">https://www.rfc-editor.org/info/rfc6438</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6633">[RFC6633]</dt>
      <dd>
<span class="refAuthor">Gont, F.</span>, <span class="refTitle">"Deprecation of ICMP Source Quench Messages"</span>, <span class="seriesInfo">RFC 6633</span>, <span class="seriesInfo">DOI 10.17487/RFC6633</span>, <time datetime="2012-05" class="refDate">May 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6633">https://www.rfc-editor.org/info/rfc6633</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="RFC7305">[RFC7305]</dt>
      <dd>
<span class="refAuthor">Lear, E., Ed.</span>, <span class="refTitle">"Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)"</span>, <span class="seriesInfo">RFC 7305</span>, <span class="seriesInfo">DOI 10.17487/RFC7305</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7305">https://www.rfc-editor.org/info/rfc7305</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7418">[RFC7418]</dt>
      <dd>
<span class="refAuthor">Dawkins, S., Ed.</span>, <span class="refTitle">"An IRTF Primer for IETF Participants"</span>, <span class="seriesInfo">RFC 7418</span>, <span class="seriesInfo">DOI 10.17487/RFC7418</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7418">https://www.rfc-editor.org/info/rfc7418</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8085">[RFC8085]</dt>
      <dd>
<span class="refAuthor">Eggert, L.</span>, <span class="refAuthor">Fairhurst, G.</span>, and <span class="refAuthor">G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8170">[RFC8170]</dt>
      <dd>
<span class="refAuthor">Thaler, D., Ed.</span>, <span class="refTitle">"Planning for Protocol Adoption and Subsequent Transitions"</span>, <span class="seriesInfo">RFC 8170</span>, <span class="seriesInfo">DOI 10.17487/RFC8170</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8170">https://www.rfc-editor.org/info/rfc8170</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8655">[RFC8655]</dt>
      <dd>
<span class="refAuthor">Finn, N.</span>, <span class="refAuthor">Thubert, P.</span>, <span class="refAuthor">Varga, B.</span>, and <span class="refAuthor">J. Farkas</span>, <span class="refTitle">"Deterministic Networking Architecture"</span>, <span class="seriesInfo">RFC 8655</span>, <span class="seriesInfo">DOI 10.17487/RFC8655</span>, <time datetime="2019-10" class="refDate">October 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8655">https://www.rfc-editor.org/info/rfc8655</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8793">[RFC8793]</dt>
      <dd>
<span class="refAuthor">Wissingh, B.</span>, <span class="refAuthor">Wood, C.</span>, <span class="refAuthor">Afanasyev, A.</span>, <span class="refAuthor">Zhang, L.</span>, <span class="refAuthor">Oran, D.</span>, and <span class="refAuthor">C. Tschudin</span>, <span class="refTitle">"Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology"</span>, <span class="seriesInfo">RFC 8793</span>, <span class="seriesInfo">DOI 10.17487/RFC8793</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8793">https://www.rfc-editor.org/info/rfc8793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[RFC9000]</dt>
      <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SAAG-105-Min">[SAAG-105-Min]</dt>
      <dd>
<span class="refTitle">"Security Area Open Meeting - IETF 105 Minutes"</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/meeting/105/materials/minutes-105-saag-00">https://datatracker.ietf.org/meeting/105/materials/minutes-105-saag-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SAF07">[SAF07]</dt>
      <dd>
<span class="refAuthor">Sarolahti, P.</span>, <span class="refAuthor">Allman, M.</span>, and <span class="refAuthor">S. Floyd</span>, <span class="refTitle">"Determining an appropriate sending rate over an underutilized network path"</span>, <span class="refContent">Computer Networks: The International Journal of Computer and Telecommunications Networking, Volume 51, Number 7</span>, <span class="seriesInfo">DOI 10.1016/j.comnet.2006.11.006</span>, <time datetime="2007-05" class="refDate">May 2007</time>, <span>&lt;<a href="https://dl.acm.org/doi/10.1016/j.comnet.2006.11.006">https://dl.acm.org/doi/10.1016/j.comnet.2006.11.006</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SallyFloyd">[SallyFloyd]</dt>
      <dd>
<span class="refAuthor">Floyd, S.</span>, <span class="refTitle">"ECN (Explicit Congestion Notification) in TCP/IP"</span>, <time datetime="2009-06" class="refDate">June 2009</time>, <span>&lt;<a href="https://www.icir.org/floyd/ecn.html">https://www.icir.org/floyd/ecn.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Sch11">[Sch11]</dt>
      <dd>
<span class="refAuthor">Scharf, M.</span>, <span class="refTitle">"Fast Startup Internet Congestion Control for Broadband Interactive Applications"</span>, <span class="refContent">Ph.D. Thesis, University of Stuttgart</span>, <time datetime="2011-04" class="refDate">April 2011</time>. </dd>
<dd class="break"></dd>
<dt id="Shim6-35">[Shim6-35]</dt>
      <dd>
<span class="refAuthor">Meyer, D.</span>, <span class="refAuthor">Huston, G.</span>, <span class="refAuthor">Schiller, J.</span>, and <span class="refAuthor">V. Gill</span>, <span class="refTitle">"IAB IPv6 Multihoming Panel at NANOG 35"</span>, <span class="refContent">North American Network Operators' Group (NANOG)</span>, <time datetime="2005-10" class="refDate">October 2005</time>, <span>&lt;<a href="https://www.youtube.com/watch?v=ji6Y_rYHAQs">https://www.youtube.com/watch?v=ji6Y_rYHAQs</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="TRIGTRAN-55">[TRIGTRAN-55]</dt>
      <dd>
<span class="refTitle">"Triggers for Transport BOF at IETF 55"</span>, <time datetime="2002-11" class="refDate">November 2002</time>, <span>&lt;<a href="https://www.ietf.org/proceedings/55/239.htm">https://www.ietf.org/proceedings/55/239.htm</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="TRIGTRAN-56">[TRIGTRAN-56]</dt>
      <dd>
<span class="refTitle">"Triggers for Transport BOF at IETF 56"</span>, <time datetime="2003-03" class="refDate">March 2003</time>, <span>&lt;<a href="https://www.ietf.org/proceedings/56/251.htm">https://www.ietf.org/proceedings/56/251.htm</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="vista-impl">[vista-impl]</dt>
    <dd>
<span class="refAuthor">Sridharan, M.</span>, <span class="refAuthor">Bansal, D.</span>, and <span class="refAuthor">D. Thaler</span>, <span class="refTitle">"Implementation Report on Experiences with Various TCP RFCs"</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld1.htm">https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld1.htm</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="acknowledgments">
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">Initial material for <a href="#ST2" class="xref">Section 6.1</a> on ST2 was provided by <span class="contact-name">Gorry Fairhurst</span>.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">Initial material for <a href="#IntServ" class="xref">Section 6.2</a> on IntServ was provided by <span class="contact-name">Ron Bonica</span>.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">Initial material for <a href="#Quick-Start" class="xref">Section 6.3</a> on Quick-Start TCP was provided by <span class="contact-name">Michael Scharf</span>, who also provided suggestions to improve this section after it was edited.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<p id="appendix-A-4">Initial material for <a href="#Source-Quench" class="xref">Section 6.4</a> on ICMP Source Quench was provided by <span class="contact-name">Gorry Fairhurst</span>.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<p id="appendix-A-5">Initial material for <a href="#TRIGTRAN" class="xref">Section 6.5</a> on Triggers for Transport (TRIGTRAN) was provided by <span class="contact-name">Spencer Dawkins</span>.<a href="#appendix-A-5" class="pilcrow">¶</a></p>
<p id="appendix-A-6"><a href="#Shim6" class="xref">Section 6.6</a> on Shim6 builds on initial material describing obstacles, which was provided by <span class="contact-name">Erik Nordmark</span>, with background added by <span class="contact-name">Spencer Dawkins</span>.<a href="#appendix-A-6" class="pilcrow">¶</a></p>
<p id="appendix-A-7">Initial material for <a href="#NSIS" class="xref">Section 6.7</a> on Next Steps in Signaling (NSIS) was provided by <span class="contact-name">Roland Bless</span> and <span class="contact-name">Martin Stiemerling</span>.<a href="#appendix-A-7" class="pilcrow">¶</a></p>
<p id="appendix-A-8">Initial material for <a href="#FL" class="xref">Section 6.8</a> on IPv6 Flow Labels was provided by <span class="contact-name">Gorry Fairhurst</span>.<a href="#appendix-A-8" class="pilcrow">¶</a></p>
<p id="appendix-A-9">Initial material for <a href="#ecn" class="xref">Section 6.9</a> on Explicit Congestion Notification was provided by <span class="contact-name">Spencer Dawkins</span>.<a href="#appendix-A-9" class="pilcrow">¶</a></p>
<p id="appendix-A-10">Our thanks to <span class="contact-name">Adrian Farrel</span>, <span class="contact-name">Bob Briscoe</span>, <span class="contact-name">C.M. Heard</span>, <span class="contact-name">David Black</span>, <span class="contact-name">Eric Kinnear</span>, <span class="contact-name">Erik Auerswald</span>, <span class="contact-name">Gorry Fairhurst</span>, <span class="contact-name">Jake Holland</span>, <span class="contact-name">Joe Touch</span>, <span class="contact-name">Joeri de Ruiter</span>, <span class="contact-name">Kireeti Kompella</span>, <span class="contact-name">Mohamed Boucadair</span>, <span class="contact-name">Randy Presuhn</span>, 
<span class="contact-name">Roland Bless</span>, <span class="contact-name">Ruediger Geib</span>, <span class="contact-name">Theresa Enghardt</span>, and <span class="contact-name">Wes Eddy</span>, who provided review comments on this document as a "work in process".<a href="#appendix-A-10" class="pilcrow">¶</a></p>
<p id="appendix-A-11"><span class="contact-name">Mallory Knodel</span> reviewed this document for the Internet Research Steering Group and provided many helpful suggestions.<a href="#appendix-A-11" class="pilcrow">¶</a></p>
<p id="appendix-A-12"><span class="contact-name">David Oran</span> also provided helpful comments and text suggestions on this document during Internet Research Steering Group balloting. In particular, <a href="#Futures" class="xref">Section 5</a> reflects his review.<a href="#appendix-A-12" class="pilcrow">¶</a></p>
<p id="appendix-A-13"><span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Martin Duke</span>, 
 and <span class="contact-name">Rob Wilton</span> provided helpful comments during Internet Engineering Steering Group conflict review.<a href="#appendix-A-13" class="pilcrow">¶</a></p>
<p id="appendix-A-14">Special thanks to <span class="contact-name">Adrian Farrel</span> for helping <span class="contact-name">Spencer</span> navigate the twisty little passages of Flow Specs and Filter Specs in IntServ, RSVP, MPLS, and BGP. They are all alike, except when they are different <span>[<a href="#Colossal-Cave" class="xref">Colossal-Cave</a>]</span>.<a href="#appendix-A-14" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Spencer Dawkins (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Tencent America</span></div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:spencerdawkins.ietf@gmail.com" class="email">spencerdawkins.ietf@gmail.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>