rfc9049.original.xml   rfc9049.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- draft submitted in xml v3 -->
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc symrefs="yes"?> -irtf-panrg-what-not-to-do-19" number="9049" submissionType="IRTF" category="inf
<?rfc compact="yes"?> o"
<?rfc comments="yes"?> consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" sortRef
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft s="true"
-irtf-panrg-what-not-to-do-19" category="info" submissionType="IRTF" obsoletes=" symRefs="true" version="3">
" updates="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" vers
ion="3"> <!-- xml2rfc v2v3 conversion 2.45.2 -->
<!-- xml2rfc v2v3 conversion 2.45.2 -->
<front> <front>
<title abbrev="What Not To Do">Path Aware Networking: Obstacles to Deploymen <title abbrev="What Not to Do">Path Aware Networking: Obstacles to Deploymen
t (A Bestiary of Roads Not Taken)</title> t (A&nbsp;Bestiary&nbsp;of&nbsp;Roads&nbsp;Not&nbsp;Taken)</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-panrg-what-not-to-do-19" <seriesInfo name="RFC" value="9049"/>
/>
<author initials="S." surname="Dawkins" fullname="Spencer Dawkins" role="edi tor"> <author initials="S." surname="Dawkins" fullname="Spencer Dawkins" role="edi tor">
<organization>Tencent America</organization> <organization>Tencent America</organization>
<address> <address>
<postal>
<country>United States of America</country>
</postal>
<email>spencerdawkins.ietf@gmail.com</email> <email>spencerdawkins.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2021" month="April" day="15"/> <date year="2021" month="June"/>
<area>IRTF</area> <area>IRTF</area>
<workgroup>PANRG</workgroup> <workgroup>Path Aware Networking</workgroup>
<keyword>PAN</keyword> <keyword>PAN</keyword>
<abstract> <abstract>
<t>At the first meeting of the Path Aware Networking Research Group, the r esearch group agreed to catalog and analyze past efforts to develop and deploy P ath Aware techniques, most of which were unsuccessful or at most partially succe ssful, in order to extract insights and lessons for path-aware networking resear chers.</t> <t>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 catalo g 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 ins ights and lessons for Path Aware networking researchers.</t>
<t>This document contains that catalog and analysis.</t> <t>This document contains that catalog and analysis.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This document describes the lessons that IETF participants have learned <t>This document describes the lessons that IETF participants have learned
(and learned the hard way) about Path Aware Networking over a period of several (and learned the hard way) about Path Aware networking over a period of several
decades, and provides an analysis of reasons why various Path Aware Networking decades. It also provides an analysis of reasons why various Path Aware techniq
techniques have seen limited or no deployment.</t> ues have seen limited or no deployment.</t>
<t>This document represents the consensus of the Path Aware Networking Research
Group (PANRG).</t>
<section anchor="PANdef" numbered="true" toc="default"> <section anchor="PANdef" numbered="true" toc="default">
<name>What Do "Path" and "Path Awareness" Mean in this Document?</name> <name>What Do "Path" and "Path Awareness" Mean in This Document?</name>
<t>One of the first questions reviewers of this document have asked is " <t>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?" T What's the definition of a Path, and what's the definition of Path Awareness?" T
hat is not an easy question to answer for this document.</t> hat is not an easy question to answer for this document.</t>
<t>These terms have definitions in other <xref target="PANRG" format="de <t>These terms have definitions in other PANRG documents <xref target="P
fault"/> documents, and are still the subject of some discussion in the research ANRG" format="default"/> and are still the subject of some discussion in the Res
group, as of the date of this document. But because this document reflects work earch Group, as of the date of this document. But because this document reflects
performed over several decades, the technologies described in <xref target="Con work performed over several decades, the technologies described in <xref target
tributions" format="default"/> significantly predate the current definitions of ="Contributions" format="default"/> significantly predate the current definition
"path" and "path aware" in use in the Path Aware Networking Research Group, and s of "Path" and "Path Aware" in use in the Path Aware Networking Research Group,
it is unlikely that all the contributors to <xref target="Contributions" format= and it is unlikely that all the contributors to <xref target="Contributions" fo
"default"/> would have had the same understanding of these terms. Those technolo rmat="default"/> would have had the same understanding of these terms. Those tec
gies were considered "path aware" in early PANRG discussions, and so are include hnologies were considered "Path Aware" in early PANRG discussions and so are inc
d in this retrospective document.</t> luded in this retrospective document.</t>
<t>It is worth noting that the definitions of "path" and "path aware" in <t>It is worth noting that the definitions of "Path" and "Path Aware" in
<xref target="I-D.irtf-panrg-path-properties" format="default"/> would apply to <xref target="I-D.irtf-panrg-path-properties" format="default"/> would apply to
path aware networking techniques at a number of levels of the Internet protocol Path Aware techniques at a number of levels of the Internet protocol architectu
architecture (<xref target="RFC1122" format="default"/>, plus several decades o re (<xref target="RFC1122" format="default"/>, plus several decades of refinemen
f refinements), but the contributions received for this document tended to targe ts), but the contributions received for this document tended to target the trans
t the Transport Layer, and to treat a "path" constructed by routers as a "black port layer and to treat a "Path" constructed by routers as opaque. It would be u
box". It would be useful to consider how applicable the Lessons Learned cataloge seful to consider how applicable the Lessons Learned cataloged in this document
d in this document are, at other layers, and that would be a fine topic for foll are, at other layers, and that would be a fine topic for follow-on research.</t>
ow-on research.</t>
<t>The current definition of "Path" in the Path Aware Networking Researc h Group appears in Section 2 ("Terminology") in <xref target="I-D.irtf-panrg-pat h-properties" format="default"/>. That definition is included here as a convenie nce to the reader.</t> <t>The current definition of "Path" in the Path Aware Networking Researc h Group appears in Section 2 ("Terminology") in <xref target="I-D.irtf-panrg-pat h-properties" format="default"/>. That definition is included here as a convenie nce to the reader.</t>
<!-- DNE -->
<blockquote> <blockquote>
Path: A sequence of adjacent path elements over which a packet can Path: A sequence of adjacent path elements over which a packet can
be transmitted, starting and ending with a node. A path is be transmitted, starting and ending with a node. A path is
unidirectional. Paths are time-dependent, i.e., the sequence of unidirectional. Paths are time-dependent, i.e., the sequence of
path elements over which packets are sent from one node to another path elements over which packets are sent from one node to another
may change. A path is defined between two nodes. For multicast may change. A path is defined between two nodes. For multicast
or broadcast, a packet may be sent by one node and received by or broadcast, a packet may be sent by one node and received by
multiple nodes. In this case, the packet is sent over multiple multiple nodes. In this case, the packet is sent over multiple
paths at once, one path for each combination of sending and paths at once, one path for each combination of sending and
receiving node; these paths do not have to be disjoint. Note that receiving node; these paths do not have to be disjoint. Note that
an entity may have only partial visibility of the path elements an entity may have only partial visibility of the path elements
skipping to change at line 57 skipping to change at line 65
or broadcast, a packet may be sent by one node and received by or broadcast, a packet may be sent by one node and received by
multiple nodes. In this case, the packet is sent over multiple multiple nodes. In this case, the packet is sent over multiple
paths at once, one path for each combination of sending and paths at once, one path for each combination of sending and
receiving node; these paths do not have to be disjoint. Note that receiving node; these paths do not have to be disjoint. Note that
an entity may have only partial visibility of the path elements an entity may have only partial visibility of the path elements
that comprise a path and visibility may change over time. that comprise a path and visibility may change over time.
Different entities may have different visibility of a path and/or Different entities may have different visibility of a path and/or
treat path elements at different levels of abstraction. treat path elements at different levels of abstraction.
</blockquote> </blockquote>
<t>The current definition of "Path Awareness", used by the Path Aware Ne <t>The current definition of Path Awareness, used by the Path Aware Netw
tworking Research Group, appears in Section 1.1 ("Definition") in <xref target=" orking Research Group, appears in Section 1.1 ("Definition") in <xref target="I-
I-D.irtf-panrg-questions" format="default"/>. That definition is included here a D.irtf-panrg-questions" format="default"/>.
s a convenience to the reader.</t> That definition is included here as a convenience to the reader.</t>
<!-- DNE; fixed. Updates reviewed and OKed by author -->
<blockquote> <blockquote>
For purposes of this document, "path aware networking" describes <t>For purposes of this document, "path aware networking" describes
endpoint discovery of the properties of paths they use for endpoint discovery of the properties of paths they use for
communication, and endpoint reaction to these properties that affects communication across an internetwork, and endpoint reaction to these
routing and/or transmission; note that this can and already does properties that affects routing and/or data transfer. Note that this
happen to some extent in the current Internet architecture. can and already does happen to some extent in the current Internet
Expanding on this definition, a "path aware internetwork" is one in 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.</t>
<t>Expanding on this definition, a "path aware internetwork" is one in
which endpoint discovery of path properties and endpoint selection of which endpoint discovery of path properties and endpoint selection of
paths used by traffic exchanged by the endpoint are explicitly paths used by traffic exchanged by the endpoint are explicitly
supported, regardless of the specific design of the protocol features supported, regardless of the specific design of the protocol features
which enable this discovery and selection. which enable this discovery and selection.</t>
</blockquote> </blockquote>
</section> </section>
</section> </section>
<section anchor="perspective" numbered="true" toc="default"> <section anchor="perspective" numbered="true" toc="default">
<name>A Perspective On This Document</name> <name>A Perspective on This Document</name>
<t>At the first meeting of the Path Aware Networking Research Group <xref target="PANRG" format="default"/>, at IETF 99 <xref target="PANRG-99" format="de fault"/>, Olivier Bonaventure led a discussion of "A Decade of Path Awareness" < xref target="PATH-Decade" format="default"/>, on attempts, which were mostly uns uccessful 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 thi ngs were abundantly clear.</t> <t>At the first meeting of the Path Aware Networking Research Group <xref target="PANRG" format="default"/>, at IETF 99 <xref target="PANRG-99" format="de fault"/>, Olivier Bonaventure led a discussion of "A Decade of Path Awareness" < xref target="PATH-Decade" format="default"/>, on attempts, which were mostly uns uccessful 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 thi ngs were abundantly clear.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The Internet community has accumulated considerable experience with many Path Aware techniques over a long period of time, and</li> <li>The Internet community has accumulated considerable experience with many Path Aware techniques over a long period of time, and</li>
<li>Although some path aware techniques have been deployed (for example, Differentiated Services, or DiffServ <xref target="RFC2475" format="default"/>) , most of these techniques haven't seen widespread adoption and deplyment. Even "successful" techniques like DiffServ can face obstacles that prevents wider usa ge. The reasons for non-adoption and limited adoption and deployment are many, a nd are worthy of study.</li> <li>Although some Path Aware techniques have been deployed (for example, Differentiated Services, or Diffserv <xref target="RFC2475" format="default"/>) , most of these techniques haven't seen widespread adoption and deployment. Even "successful" techniques like Diffserv can face obstacles that prevent wider usa ge. The reasons for non-adoption and limited adoption and deployment are many an d are worthy of study.</li>
</ul> </ul>
<t>The meta-lessons from that experience were</t> <t>The meta-lessons from that experience were as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Path aware networking has been more Research than Engineering, so es <li>Path Aware networking has been more Research than Engineering, so es
tablishing an IRTF Research Group for Path Aware Networking is the right thing t tablishing an IRTF Research Group for Path Aware networking was the right thing
o do <xref target="RFC7418" format="default"/>.</li> to do <xref target="RFC7418" format="default"/>.
</li>
<li>Analyzing a catalog of past experience to learn the reasons for non- adoption would be a great first step for the Research Group.</li> <li>Analyzing a catalog of past experience to learn the reasons for non- adoption would be a great first step for the Research Group.</li>
</ul> </ul>
<t>Allison Mankin, as IRTF Chair, officially chartered the Path Aware Netw <t>Allison Mankin, as IRTF Chair, officially chartered the Path Aware Netw
orking Research Group in July, 2018.</t> orking Research Group in July 2018.</t>
<t>This document contains the analysis performed by that research group (< <t>This document contains the analysis performed by that Research Group (<
xref target="LessonsLearned" format="default"/>), based on that catalog (<xref t xref target="LessonsLearned" format="default"/>), based on that catalog (<xref t
arget="Contributions" format="default"/>).</t> arget="Contributions" format="default"/>).</t>
<t>This document represents the consensus of the Path Aware Networking Res
earch Group.</t>
<section anchor="notes-for-the-reader" numbered="true" toc="default"> <section anchor="notes-for-the-reader" numbered="true" toc="default">
<name>Notes for the Reader</name> <name>Notes for the Reader</name>
<t>This Informational document discusses Path Aware protocol mechanisms <t>This Informational document discusses Path Aware protocol mechanisms
considered, and in some cases standardized, by the Internet Engineering Task For considered, and in some cases standardized, by the Internet Engineering Task For
ce (IETF), and considers Lessons Learned from those mechanisms. The intention is ce (IETF), and it considers Lessons Learned from those mechanisms. The intention
to inform the work of protocol designers, whether in the IRTF, the IETF, or els is to inform the work of protocol designers, whether in the IRTF, the IETF, or
ewhere in the Internet ecosystem.</t> elsewhere in the Internet ecosystem.</t>
<t>As an Informational document published in the IRTF stream, this docum <t>As an Informational document published in the IRTF Stream, this docum
ent has no authority beyond the quality of the analysis it contains.</t> ent has no authority beyond the quality of the analysis it contains.</t>
</section> </section>
<section anchor="a-note-about-path-aware-techniques-included-in-this-docum ent" numbered="true" toc="default"> <section anchor="a-note-about-path-aware-techniques-included-in-this-docum ent" numbered="true" toc="default">
<name>A Note About Path-Aware Techniques Included In This Document</name <name>A Note about Path Aware Techniques Included in This Document</name
> >
<t>This document does not catalog every proposed path aware networking t <t>This document does not catalog every proposed Path Aware technique th
echnique that was not adopted and deployed. Instead, we limited our focus to tec at was not adopted and deployed. Instead, we limited our focus to technologies t
hnologies that passed through the IETF community, and still identified enough te hat passed through the IETF community and still identified enough techniques to
chniques to provide background for the lessons included in <xref target="Lessons provide background for the lessons included in <xref target="LessonsLearned" for
Learned" format="default"/> to inform researchers and protocol engineers in thei mat="default"/> to inform researchers and protocol engineers in their work.</t>
r work.</t> <t>No shame is intended for the techniques included in this document. As
<t>No shame is intended for the techniques included in this document. As shown in <xref target="LessonsLearned" format="default"/>, the quality of speci
shown in <xref target="LessonsLearned" format="default"/>, the quality of speci fic techniques had little to do with whether they were deployed or not. Based on
fic 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 techniq
the techniques cataloged in this document, it is likely that when these techniq ues were put forward, the proponents were trying to engineer something that coul
ues were put forward, the proponents were trying to engineer something that coul d not be engineered without first carrying out research. Actual shame would be f
d not be engineered without first carrying out research. Actual shame would be f ailing to learn from experience and failing to share that experience with other
ailing to learn from experience, and failing to share that experience with other networking researchers and engineers.</t>
networking researchers and engineers.</t>
</section>
<section anchor="venue-for-discussion-of-this-document" numbered="true" to
c="default">
<name>Venue for Discussion of this Document</name>
<t>(RFC Editor: please remove this section before publication)</t>
<t>Discussion of specific contributed experiences and this document in g
eneral should take place on the PANRG mailing list.</t>
</section> </section>
<section anchor="architectural-guidance" numbered="true" toc="default"> <section anchor="architectural-guidance" numbered="true" toc="default">
<name>Architectural Guidance</name> <name>Architectural Guidance</name>
<t>As background for understanding the Lessons Learned contained in this <t>As background for understanding the Lessons Learned contained in this
document, the reader is encouraged to become familiar with the Internet Archite document, the reader is encouraged to become familiar with the Internet Archite
cture Board's documents on "What Makes for a Successful Protocol?" <xref target= cture Board's documents on "<xref target="RFC5218" format="title"/>" <xref targe
"RFC5218" format="default"/> and "Planning for Protocol Adoption and Subsequent t="RFC5218" format="default"/>
Transitions" <xref target="RFC8170" format="default"/>.</t> and "<xref target="RFC8170" format="title"/>" <xref target="RFC8170" format="def
<t>Although these two documents do not specifically target path-aware ne ault"/>.</t>
tworking protocols, they are helpful resources for readers seeking to improve th <t>Although these two documents do not specifically target Path Aware ne
eir understanding of considerations for successful adoption and deployment of an tworking protocols, they are helpful resources for readers seeking to improve th
y protocol. For example, the Basic Success Factors described in Setion 2.1 of <x eir understanding of considerations for successful adoption and deployment of an
ref target="RFC5218" format="default"/> are helpful for readers of this document y protocol. For example, the basic success factors described in <xref target="RF
.</t> C5218" sectionFormat="of" section="2.1"/> are helpful for readers of this docume
nt.</t>
<t>Because there is an economic aspect to decisions about deployment, th e IAB Workshop on Internet Technology Adoption and Transition <xref target="ITAT " format="default"/> report <xref target="RFC7305" format="default"/> also provi des food for thought.</t> <t>Because there is an economic aspect to decisions about deployment, th e IAB Workshop on Internet Technology Adoption and Transition <xref target="ITAT " format="default"/> report <xref target="RFC7305" format="default"/> also provi des food for thought.</t>
<t>Several of the Lessons Learned in <xref target="LessonsLearned" forma t="default"/> reflect considerations described in <xref target="RFC5218" format= "default"/>, <xref target="RFC7305" format="default"/>, and <xref target="RFC817 0" format="default"/>.</t> <t>Several of the Lessons Learned in <xref target="LessonsLearned" forma t="default"/> reflect considerations described in <xref target="RFC5218" format= "default"/>, <xref target="RFC7305" format="default"/>, and <xref target="RFC817 0" format="default"/>.</t>
</section> </section>
<section anchor="terminology-used-in-this-document" numbered="true" toc="d efault"> <section anchor="terminology-used-in-this-document" numbered="true" toc="d efault">
<name>Terminology Used in this Document</name> <name>Terminology Used in This Document</name>
<t>The terms Node and Element in this document have the meaning defined <t>The terms "node" and "element" in this document have the meaning defi
in <xref target="I-D.irtf-panrg-path-properties" format="default"/>.</t> ned in <xref target="I-D.irtf-panrg-path-properties" format="default"/>.
</t>
</section> </section>
<section anchor="TemplateContributions" numbered="true" toc="default"> <section anchor="TemplateContributions" numbered="true" toc="default">
<name>Methodology for Contributions</name> <name>Methodology for Contributions</name>
<t>This document grew out of contributions by various IETF participants <t>This document grew out of contributions by various IETF participants
with experience with one or more Path Aware Networking techniques.</t> with experience with one or more Path Aware techniques.</t>
<t>There are many things that could be said about the Path Aware network <t>There are many things that could be said about the Path Aware techniq
ing techniques that have been developed. For the purposes of this document, cont ues that have been developed. For the purposes of this document, contributors we
ributors were requested to provide</t> re requested to provide</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the name of a technique, including an abbreviation if one was used <li>the name of a technique, including an abbreviation if one was used
</li> .</li>
<li>if available, a long-term pointer to the best reference describing <li>if available, a long-term pointer to the best reference describing
the technique</li> the technique.</li>
<li>a short description of the problem the technique was intended to s <li>a short description of the problem the technique was intended to s
olve</li> olve.</li>
<li>a short description of the reasons why the technique wasn't adopte <li>a short description of the reasons why the technique wasn't adopte
d</li> d.</li>
<li>a short statement of the lessons that researchers can learn from o ur experience with this technique.</li> <li>a short statement of the lessons that researchers can learn from o ur experience with this technique.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="applying" numbered="true" toc="default"> <section anchor="applying" numbered="true" toc="default">
<name>Applying the Lessons We've Learned</name> <name>Applying the Lessons We've Learned</name>
<t>The initial scope for this document was roughly "what mistakes have we <t>The initial scope for this document was roughly "What mistakes have we
made in the decade prior to <xref target="PANRG-99" format="default"/>, that we made in the decade prior to <xref target="PANRG-99" format="default"/>, that we
shouldn't make again". Some of the contributions in <xref target="Contributions" shouldn't make again?" Some of the contributions in <xref target="Contributions"
format="default"/> predate the initial scope. The earliest Path-Aware Networkin format="default"/> predate the initial scope. The earliest Path Aware technique
g technique referred to in <xref target="Contributions" format="default"/> is <x referred to in <xref target="Contributions" format="default"/> is <xref target=
ref target="ST2" format="default"/>, published in the late 1970s. Given that the "IEN-119"/>, which was published in the late 1970s; see <xref target="ST2" forma
networking ecosystem has evolved continuously, it seems reasonable to consider t="default"/>. Given that the networking ecosystem has evolved continuously, it
how to apply these lessons.</t> seems reasonable to consider how to apply these lessons.</t>
<t>The PANRG Research Group reviewed the Lessons Learned (<xref target="Le <t>The PANRG reviewed the Lessons Learned (<xref target="LessonsLearned" f
ssonsLearned" format="default"/>) contained in the May 23, 2019 version of this ormat="default"/>) contained in the May 23, 2019 draft version of this document
document at IETF 105 <xref target="PANRG-105-Min" format="default"/>, and carrie at IETF 105 <xref target="PANRG-105-Min" format="default"/> and carried out addi
d out additional discussion at IETF 106 <xref target="PANRG-106-Min" format="def tional discussion at IETF 106 <xref target="PANRG-106-Min" format="default"/>. <
ault"/>. <xref target="thefuture" format="default"/> provides the "sense of the xref target="thefuture" format="default"/> provides the "sense of the room" abou
room" about each lesson after those discussions. The intention was to capture wh t each lesson after those discussions. The intention was to capture whether a sp
ether a specific lesson seems to be</t> ecific lesson seems to be</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"Invariant" - well-understood and is likely to be applicable for any <li>"Invariant" - well-understood and is likely to be applicable for any
proposed Path Aware Networking solution.</li> proposed Path Aware networking solution.</li>
<li>"Variable" - has impeded deployment in the past, but might not be ap <li>"Variable" - has impeded deployment in the past but might not be app
plicable in a specific technique. Engineering analysis to understand whether the licable in a specific technique. Engineering analysis to understand whether the
lesson is applicable is prudent.</li> lesson is applicable is prudent.</li>
<li>"Not Now" - this characteristic tends to turn up a minefield full of <li>"Not Now" - a characteristic that tends to turn up a minefield full
dragons, and prudent network engineers will wish to avoid gambling on a techniq of dragons. Prudent network engineers will wish to avoid gambling on a technique
ue that relies on this, until something significant changes</li> that relies on this, until something significant changes.</li>
</ul> </ul>
<t><xref target="ecn" format="default"/> on ECN was added during the revie
w and approval process, based on a question from Martin Duke. That section, alon <t><xref target="ecn" format="default"/> on Explicit Congestion Notificati
g with its Lessons Learned and place in the "Invariant"/"Variable"/"Not Now" tax on (ECN) was added during the review and approval process, based on a question f
onomy, as contained in the March 8, 2021 version of this document, was discussed rom Martin Duke. <xref target="ecn" format="default"/>, as contained in the Marc
at <xref target="PANRG-110" format="default"/>.</t> h 8, 2021 draft version of this document, was discussed at <xref target="PANRG-1
10" format="default"/> and is summarized in <xref target="OneChance"/>, describi
ng a new Lesson Learned.
</t>
<table anchor="thefuture" align="center"> <table anchor="thefuture" align="center">
<thead> <thead>
<tr> <tr>
<th align="left">Lesson</th> <th align="left">Lesson</th>
<th align="left">Category</th> <th align="left">Category</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Justifying Deployment (<xref target="JustifyingDepl oyment" format="default"/>)</td> <td align="left">Justifying Deployment (<xref target="JustifyingDepl oyment" format="default"/>)</td>
skipping to change at line 157 skipping to change at line 173
</tr> </tr>
<tr> <tr>
<td align="left">Providing Benefits for Early Adopters (<xref target ="EarlyAdopters" format="default"/>)</td> <td align="left">Providing Benefits for Early Adopters (<xref target ="EarlyAdopters" format="default"/>)</td>
<td align="left">Invariant</td> <td align="left">Invariant</td>
</tr> </tr>
<tr> <tr>
<td align="left">Providing Benefits during Partial Deployment (<xref target="PartialDeployment" format="default"/>)</td> <td align="left">Providing Benefits during Partial Deployment (<xref target="PartialDeployment" format="default"/>)</td>
<td align="left">Invariant</td> <td align="left">Invariant</td>
</tr> </tr>
<tr> <tr>
<td align="left">Outperforming End-to-end Protocol Mechanisms (<xref target="Outperforming" format="default"/>)</td> <td align="left">Outperforming End-to-End Protocol Mechanisms (<xref target="Outperforming" format="default"/>)</td>
<td align="left">Variable</td> <td align="left">Variable</td>
</tr> </tr>
<tr> <tr>
<td align="left">Paying for Path Aware Techniques (<xref target="Pay ing" format="default"/>)</td> <td align="left">Paying for Path Aware Techniques (<xref target="Pay ing" format="default"/>)</td>
<td align="left">Invariant</td> <td align="left">Invariant</td>
</tr> </tr>
<tr> <tr>
<td align="left">Impact on Operational Practices (<xref target="Oper ationalImpact" format="default"/>)</td> <td align="left">Impact on Operational Practices (<xref target="Oper ationalImpact" format="default"/>)</td>
<td align="left">Invariant</td> <td align="left">Invariant</td>
</tr> </tr>
<tr> <tr>
<td align="left">Per-connection State (<xref target="Per-connectionS tate" format="default"/>)</td> <td align="left">Per-Connection State (<xref target="Per-connectionS tate" format="default"/>)</td>
<td align="left">Variable</td> <td align="left">Variable</td>
</tr> </tr>
<tr> <tr>
<td align="left">Keeping Traffic on Fast-paths (<xref target="Fast-p aths" format="default"/>)</td> <td align="left">Keeping Traffic on Fast Paths (<xref target="Fast-p aths" format="default"/>)</td>
<td align="left">Variable</td> <td align="left">Variable</td>
</tr> </tr>
<tr> <tr>
<td align="left">Endpoints Trusting Intermediate Nodes (<xref target ="EndpointsTrustingIDs" format="default"/>)</td> <td align="left">Endpoints Trusting Intermediate Nodes (<xref target ="EndpointsTrustingIDs" format="default"/>)</td>
<td align="left">Not Now</td> <td align="left">Not Now</td>
</tr> </tr>
<tr> <tr>
<td align="left">Intermediate Nodes Trusting Endpoints (<xref target ="IDsTrustingEndpoints" format="default"/>)</td> <td align="left">Intermediate Nodes Trusting Endpoints (<xref target ="IDsTrustingEndpoints" format="default"/>)</td>
<td align="left">Not Now</td> <td align="left">Not Now</td>
</tr> </tr>
skipping to change at line 198 skipping to change at line 214
<tr> <tr>
<td align="left">Support in Endpoint Protocol Stacks (<xref target=" ProtocolStackSupport" format="default"/>)</td> <td align="left">Support in Endpoint Protocol Stacks (<xref target=" ProtocolStackSupport" format="default"/>)</td>
<td align="left">Variable</td> <td align="left">Variable</td>
</tr> </tr>
<tr> <tr>
<td align="left">Planning for Failure (<xref target="OneChance" form at="default"/>)</td> <td align="left">Planning for Failure (<xref target="OneChance" form at="default"/>)</td>
<td align="left">Invariant</td> <td align="left">Invariant</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>"Justifying Deployment", "Providing Benefits for Early Adopters", "Payi
ng for Path Aware Techniques", "Impact on Operational Practice", and "Planning f <t>"Justifying Deployment", "Providing Benefits for Early Adopters", "Payi
or Failure" were considered to be invariant - the sense of the room was that the ng for Path Aware Techniques", "Impact on Operational Practices", and "Planning
se would always be considerations for any proposed Path Aware Technique.</t> for Failure" were considered to be Invariant -- the sense of the room was that t
<t>"Providing Benefits During Partial Deployment" was added after IETF 105 hese would always be considerations for any proposed Path Aware technique.</t>
, during research group last call, and is also considered to be invariant.</t> <t>"Providing Benefits during Partial Deployment" was added after IETF 105
<t>For "Outperforming End-to-end Protocol Mechanisms", there is a trade-of , during Research Group Last Call, and is also considered to be Invariant.</t>
f between improved performance from Path Aware Techniques and additional complex <t>For "Outperforming End-to-End Protocol Mechanisms", there is a trade-of
ity required by some Path Aware Techniques.</t> f between improved performance from Path Aware techniques and additional complex
ity required by some Path Aware techniques.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For example, if you can obtain the same understanding of path charac teristics from measurements obtained over a few more round trips, endpoint imple menters are unlikely to be eager to add complexity, and many attributes can be m easured from an endpoint, without assistance from intermediate nodes.</li> <li>For example, if you can obtain the same understanding of path charac teristics from measurements obtained over a few more round trips, endpoint imple menters are unlikely to be eager to add complexity, and many attributes can be m easured from an endpoint, without assistance from intermediate nodes.</li>
</ul> </ul>
<t>For "Per-connection State", the key questions discussed in the research group were "how much state" and "where state is maintained".</t> <t>For "Per-Connection State", the key questions discussed in the Research Group were "how much state" and "where state is maintained".</t>
<ul spacing="normal"> <ul spacing="normal">
<li>IntServ (<xref target="IntServ" format="default"/>) required state a t every intermediate node for every connection between two endpoints. As the Int ernet ecosystem has evolved, carrying many connections in a tunnel that appears to intermediate nodes as a single connection has become more common, so that add itional end-to-end connections don't add additional state to intermediate nodes between tunnel endpoints. If these tunnels are encrypted, intermediate nodes bet ween tunnel endpoints can't distinguish between connections, even if that were d esirable.</li> <li>Integrated Services (IntServ) (<xref target="IntServ" format="defaul t"/>) required state at every participating intermediate node for every connecti on between two endpoints. As the Internet ecosystem has evolved, carrying many c onnections 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 add itional state to intermediate nodes between tunnel endpoints. If these tunnels a re encrypted, intermediate nodes between tunnel endpoints can't distinguish betw een connections, even if that were desirable.</li>
</ul> </ul>
<t>For "Keeping Traffic on Fast-paths", we noted that this was true for ma ny platforms, but not for all.</t> <t>For "Keeping Traffic on Fast Paths", we noted that this was true for ma ny platforms, but not for all.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>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 Networking techniques.</li> <li>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.</li>
</ul> </ul>
<t>For "Endpoints Trusting Intermediate Nodes" and "Intermediate Nodes Tru sting Endpoints", these lessons point to the broader need to revisit the Interne t Threat Model.</t> <t>For "Endpoints Trusting Intermediate Nodes" and "Intermediate Nodes Tru sting Endpoints", these lessons point to the broader need to revisit the Interne t Threat Model.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>We noted with relief that discussions about this were already underw ay in the IETF community at IETF 105 (see the Security Area Open Meeting minutes <xref target="SAAG-105-Min" format="default"/> for discussion of <xref target=" I-D.arkko-arch-internet-threat-model" format="default"/> and <xref target="I-D.f arrell-etm" format="default"/>), and the Internet Architecture Board has created a mailing list for continued discussions (<xref target="model-t" format="defaul t"/>), but we recognize that there are Path Aware Networking aspects of this eff ort, requiring research.</li> <li>We noted with relief that discussions about this were already underw ay in the IETF community at IETF 105 (see the Security Area Open Meeting minutes <xref target="SAAG-105-Min" format="default"/> for discussion of <xref target=" I-D.arkko-arch-internet-threat-model" format="default"/> and <xref target="I-D.f arrell-etm" format="default"/>), and the Internet Architecture Board has created a mailing list for continued discussions <xref target="model-t" format="default "/>, but we recognize that there are Path Aware networking aspects of this effor t, requiring research.</li>
</ul> </ul>
<t>For "Reacting to Distant Signals", we noted that not all attributes are equal.</t> <t>For "Reacting to Distant Signals", we noted that not all attributes are equal.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If an attribute is stable over an extended period of time, is diffic ult 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 attrac tive.</li> <li>If an attribute is stable over an extended period of time, is diffic ult 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 attrac tive.</li>
<li>Analysis to help identify attributes that are useful enough to justi fy deployment of Path Aware techniques that make use of those attributes would b e helpful.</li> <li>Analysis to help identify attributes that are useful enough to justi fy deployment of Path Aware techniques that make use of those attributes would b e helpful.</li>
</ul> </ul>
<t>For "Support in Endpoint Protocol Stacks", we noted that Path Aware app lications must be able to identify and communicate requirements about path chara cteristics.</t> <t>For "Support in Endpoint Protocol Stacks", we noted that Path Aware app lications must be able to identify and communicate requirements about path chara cteristics.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The de-facto sockets API has no way of signaling application expecta tions for the network path to the protocol stack.</li> <li>The de facto sockets API has no way of signaling application expecta tions for the network path to the protocol stack.</li>
</ul> </ul>
</section> </section>
<section anchor="LessonsLearned" numbered="true" toc="default"> <section anchor="LessonsLearned" numbered="true" toc="default">
<name>Summary of Lessons Learned</name> <name>Summary of Lessons Learned</name>
<t>This section summarizes the Lessons Learned from the contributed subsec tions in <xref target="Contributions" format="default"/>.</t> <t>This section summarizes the Lessons Learned from the contributed subsec tions in <xref target="Contributions" format="default"/>.</t>
<t>Each Lesson Learned is tagged with one or more contributions that encou ntered this obstacle as a significant impediment to deployment. Other contribute d techniques may have also encountered this obstacle, but this obstacle may not have been the biggest impediment to deployment for those techniques.</t> <t>Each Lesson Learned is tagged with one or more contributions that encou ntered this obstacle as a significant impediment to deployment. Other contribute d techniques may have also encountered this obstacle, but this obstacle may not have been the biggest impediment to deployment for those techniques.</t>
<t>It is useful to notice that sometimes an obstacle might impede deployme <t>It is useful to notice that sometimes an obstacle might impede deployme
nt, while at other times, the same obstacle might prevent adoption and deploymen nt, while at other times, the same obstacle might prevent adoption and deploymen
t entirely. The research group discussed distinguishing between obstacles that i t entirely.
mpede and obstacles that prevent, but it appears that the boundary between "impe The Research Group discussed distinguishing between obstacles that impede and ob
de" and "prevent" can shift over time - some of the Lessons Learned are based on stacles that prevent, but it appears that the boundary between "impede" and
both Path Aware techniques that were not deployed, and Path Aware techniques th "prevent" can shift over time -- some of the Lessons Learned are based on both a
at were deployed, but were not deployed widely or quickly. See <xref target="Shi ) Path Aware techniques that were not deployed and b) Path Aware techniques that
m6" format="default"/> and <xref target="Addendum-MP-TCP" format="default"/> as were deployed but were not deployed widely or quickly. See Sections&nbsp;<xref
one example of this shifting boundary.</t> target="Shim6" format="counter"/> and <xref target="Addendum-MP-TCP" format="cou
nter"/> for examples of this shifting boundary.</t>
<section anchor="JustifyingDeployment" numbered="true" toc="default"> <section anchor="JustifyingDeployment" numbered="true" toc="default">
<name>Justifying Deployment</name> <name>Justifying Deployment</name>
<t>The benefit of Path Awareness must be great enough to justify making changes in an operational network. The colloquial U.S. American English expressi on, "If it ain't broke, don't fix it" is a "best current practice" on today's In ternet. (See <xref target="Quick-Start" format="default"/>, <xref target="Source -Quench" format="default"/>, <xref target="TRIGTRAN" format="default"/>, and <xr ef target="ecn" format="default"/>, in addition to <xref target="RFC5218" format ="default"/>).</t> <t>The benefit of Path Awareness must be great enough to justify making changes in an operational network. The colloquial U.S.&nbsp;American English exp ression, "If it ain't broke, don't fix it" is a "best current practice" on today 's Internet. (See Sections&nbsp;<xref target="Quick-Start" format="counter"/>, < xref target="Source-Quench" format="counter"/>, <xref target="TRIGTRAN" format=" counter"/>, and <xref target="ecn" format="counter"/>, in addition to <xref targ et="RFC5218" format="default"/>.)</t>
</section> </section>
<section anchor="EarlyAdopters" numbered="true" toc="default"> <section anchor="EarlyAdopters" numbered="true" toc="default">
<name>Providing Benefits for Early Adopters</name> <name>Providing Benefits for Early Adopters</name>
<t>Providing benefits for early adopters can be key - if everyone must d eploy a technique in order for the technique to provide benefits, or even to wor k at all, the technique is unlikely to be adopted widely or quickly. (See <xref target="IntServ" format="default"/> and <xref target="Quick-Start" format="defau lt"/>, in addition to <xref target="RFC5218" format="default"/>).</t> <t>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 wo rk at all, the technique is unlikely to be adopted widely or quickly. (See Secti ons&nbsp;<xref target="IntServ" format="counter"/> and <xref target="Quick-Start " format="counter"/>, in addition to <xref target="RFC5218" format="default"/>.) </t>
</section> </section>
<section anchor="PartialDeployment" numbered="true" toc="default"> <section anchor="PartialDeployment" numbered="true" toc="default">
<name>Providing Benefits During Partial Deployment</name> <name>Providing Benefits during Partial Deployment</name>
<t>Some proposals require that all path elements along the full length o <t>Some proposals require that all path elements along the full length o
f the path must be upgraded to support a new technique, before any benefits can f 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 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 upgrade subset of path elements, and between operators and end users if endpoint upgrade
s are required. If a technique provides benefits when only a part of the path ha s are required. If a technique provides benefits when only a part of the path ha
s been upgraded, this is likely to encourage adoption and deployment. (See <xref s been upgraded, this is likely to encourage adoption and deployment. (See Secti
target="IntServ" format="default"/>, <xref target="Quick-Start" format="default ons&nbsp;<xref target="IntServ" format="counter"/>, <xref target="Quick-Start" f
"/>, and <xref target="ecn" format="default"/>, in addition to <xref target="RFC ormat="counter"/>, and <xref target="ecn" format="counter"/>, in addition to <xr
5218" format="default"/>).</t> ef target="RFC5218" format="default"/>.)</t>
</section> </section>
<section anchor="Outperforming" numbered="true" toc="default"> <section anchor="Outperforming" numbered="true" toc="default">
<name>Outperforming End-to-end Protocol Mechanisms</name> <name>Outperforming End-to-End Protocol Mechanisms</name>
<t>Adaptive end-to-end protocol mechanisms may respond to feedback quick <t>Adaptive end-to-end protocol mechanisms may respond to feedback quick
ly enough that the additional realizable benefit from a new Path Aware mechanism ly 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 that tries to manipulate nodes along a path, or observe the attributes of nodes
along a path, may be much smaller than anticipated (See <xref target="Quick-Sta along a path, may be much smaller than anticipated. (See Sections&nbsp;<xref ta
rt" format="default"/> and <xref target="TRIGTRAN" format="default"/>).</t> rget="Quick-Start" format="counter"/> and <xref target="TRIGTRAN" format="counte
r"/>.)</t>
</section> </section>
<section anchor="Paying" numbered="true" toc="default"> <section anchor="Paying" numbered="true" toc="default">
<name>Paying for Path Aware Techniques</name> <name>Paying for Path Aware Techniques</name>
<t>"Follow the money." If operators can't charge for a Path Aware techni que to recover the costs of deploying it, the benefits to the operator must be r eally significant. Corollary: If operators charge for a Path Aware technique, th e benefits to users of that Path Aware technique must be significant enough to j ustify the cost. (See <xref target="ST2" format="default"/>, <xref target="IntSe rv" format="default"/>, <xref target="TRIGTRAN" format="default"/>, and <xref ta rget="ecn" format="default"/>).</t> <t>"Follow the money." If operators can't charge for a Path Aware techni que to recover the costs of deploying it, the benefits to the operator must be r eally significant. Corollary: if operators charge for a Path Aware technique, th e benefits to users of that Path Aware technique must be significant enough to j ustify the cost. (See Sections&nbsp;<xref target="ST2" format="counter"/>, <xref target="IntServ" format="counter"/>, <xref target="TRIGTRAN" format="counter"/> , and <xref target="ecn" format="counter"/>.)</t>
</section> </section>
<section anchor="OperationalImpact" numbered="true" toc="default"> <section anchor="OperationalImpact" numbered="true" toc="default">
<name>Impact on Operational Practices</name> <name>Impact on Operational Practices</name>
<t>Impact of a Path Aware technique requiring changes to operational pra ctices can affect how quickly or widely a promising technique is deployed. The i mpacts of these changes may make deployment more likely, but often discourage de ployment. (See <xref target="Shim6" format="default"/>, including <xref target=" Addendum-MP-TCP" format="default"/>).</t> <t>The impact of a Path Aware technique requiring changes to operational practices can affect how quickly or widely a promising technique is deployed. T he impacts of these changes may make deployment more likely, but they often disc ourage deployment. (See <xref target="Shim6" format="default"/>, including <xref target="Addendum-MP-TCP" format="default"/>.)</t>
</section> </section>
<section anchor="Per-connectionState" numbered="true" toc="default"> <section anchor="Per-connectionState" numbered="true" toc="default">
<name>Per-connection State</name> <name>Per-Connection State</name>
<t>Per-connection state in intermediate nodes has been an impediment to <t>Per-connection state in intermediate nodes has been an impediment to
adoption and deployment in the past, because of added cost and complexity. Often 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 , 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 routin especially true as we move from the edge of the network, further into the routin
g core (See <xref target="ST2" format="default"/> and <xref target="IntServ" for g core. (See Sections&nbsp;<xref target="ST2" format="counter"/> and <xref targe
mat="default"/>).</t> t="IntServ" format="counter"/>.)</t>
</section> </section>
<section anchor="Fast-paths" numbered="true" toc="default"> <section anchor="Fast-paths" numbered="true" toc="default">
<name>Keeping Traffic on Fast-paths</name> <name>Keeping Traffic on Fast Paths</name>
<t>Many modern platforms, especially high-end routers, have been designe <t>Many modern platforms, especially high-end routers, have been designe
d with hardware that can make simple per-packet forwarding decisions ("fast-path d with hardware that can make simple per-packet forwarding decisions ("fast path
s"), but have not been designed to make heavy use of in-band mechanisms such as s") but have not been designed to make heavy use of in-band mechanisms such as I
IPv4 and IPv6 Router Alert Options (RAO) that require more processing to make fo Pv4 and IPv6 Router Alert Options (RAOs) that require more processing to make fo
rwarding decisions. Packets carrying in-band mechanisms are diverted to other pr rwarding decisions. Packets carrying in-band mechanisms are diverted to other pr
ocessors in the router with much lower packet processing rates. Operators can be ocessors in the router with much lower packet-processing rates. Operators can be
reluctant to deploy techniques that rely heavily on in-band mechanisms because reluctant to deploy techniques that rely heavily on in-band mechanisms because
they may significantly reduce packet throughput. (See <xref target="NSIS" format they may significantly reduce packet throughput. (See <xref target="NSIS" format
="default"/>).</t> ="default"/>.)</t>
</section> </section>
<section anchor="EndpointsTrustingIDs" numbered="true" toc="default"> <section anchor="EndpointsTrustingIDs" numbered="true" toc="default">
<name>Endpoints Trusting Intermediate Nodes</name> <name>Endpoints Trusting Intermediate Nodes</name>
<t>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 trus t applies when a node issuing a message can confirm that it has visibility of th e packets on the path it is seeking to control <xref target="RFC8085" format="de fault"/> (e.g., an ICMP message included a quoted packet from the source). A hig her level of trust can arise when an endpoint has established a short term, or e ven long term, trust relationship with network nodes. (See <xref target="Source- Quench" format="default"/> and <xref target="TRIGTRAN" format="default"/>).</t> <t>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 mess age has visibility of the packets on the path it is seeking to control <xref tar get="RFC8085" format="default"/> (e.g., an ICMP Destination Unreachable message <xref target="RFC0792"/> 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&nbsp;<xref target="Source-Quench" format="coun ter"/> and <xref target="TRIGTRAN" format="counter"/>.)</t>
</section> </section>
<section anchor="IDsTrustingEndpoints" numbered="true" toc="default"> <section anchor="IDsTrustingEndpoints" numbered="true" toc="default">
<name>Intermediate Nodes Trusting Endpoints</name> <name>Intermediate Nodes Trusting Endpoints</name>
<t>If the endpoints do not have any trust relationship with the intermed iate nodes along a path, operators have been reluctant to deploy techniques that rely on endpoints sending unauthenticated control signals to routers. (See <xre f target="IntServ" format="default"/> and <xref target="NSIS" format="default"/> ). (We also note this still remains a factor hindering deployment of DiffServ).< /t> <t>If the endpoints do not have any trust relationship with the intermed iate nodes along a path, operators have been reluctant to deploy techniques that rely on endpoints sending unauthenticated control signals to routers. (See Sect ions&nbsp;<xref target="IntServ" format="counter"/> and <xref target="NSIS" form at="counter"/>.) (We also note that this still remains a factor hindering deploy ment of Diffserv.)</t>
</section> </section>
<section anchor="ReactionTimes" numbered="true" toc="default"> <section anchor="ReactionTimes" numbered="true" toc="default">
<name>Reacting to Distant Signals</name> <name>Reacting to Distant Signals</name>
<t>Because the Internet is a distributed system, if the distance that in formation from distant path elements travels to a Path Aware host is sufficientl y large, the information may no longer accurately represent the state and situat ion 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 inconsist ent, and may not always be beneficial. (See <xref target="Quick-Start" format="d efault"/>).</t> <t>Because the Internet is a distributed system, if the distance that in formation from distant path elements travels to a Path Aware host is sufficientl y large, the information may no longer accurately represent the state and situat ion 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 inconsist ent and may not always be beneficial. (See <xref target="Quick-Start" format="de fault"/>.)</t>
</section> </section>
<section anchor="ProtocolStackSupport" numbered="true" toc="default"> <section anchor="ProtocolStackSupport" numbered="true" toc="default">
<name>Support in Endpoint Protocol Stacks</name> <name>Support in Endpoint Protocol Stacks</name>
<t>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 ma y require information from applications to permit the technique to work effectiv ely, but applications may not a-priori know that information. Even if the applic ation does know that information, the de-facto sockets API has no way of signali ng application expectations for the network path to the protocol stack. In order for applications to provide these expectations to protocol stacks, we need an A PI that signals more than the packets to be sent. (See <xref target="ST2" format ="default"/> and <xref target="IntServ" format="default"/>).</t> <t>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 ma y require information from applications to permit the technique to work effectiv ely, but applications may not a&nbsp;priori know that information. Even if the a pplication does know that information, the de facto sockets API has no way of si gnaling 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&nbsp;<xref target="ST2" format="counter"/> and <xref target="IntServ" format="counter"/>.)< /t>
</section> </section>
<section anchor="OneChance" numbered="true" toc="default"> <section anchor="OneChance" numbered="true" toc="default">
<name>Planning For Failure</name> <name>Planning for Failure</name>
<t>If early implementers discover severe problems with a new feature, th <t>If early implementers discover severe problems with a new feature, th
at feature is likely to be disabled, and convincing implementers to re-enable th at feature is likely to be disabled, and convincing implementers to re-enable th
at feature can be very difficult, and can require years or decades. In addition at feature can be very difficult and can require years or decades. In addition t
to testing, partial deployment for a subset of users, implementing instrumentati o testing, partial deployment for a subset of users, implementing instrumentatio
on that will detect degraded user experience, and even "failback" to a previous n that will detect degraded user experience, and even "failback" to a previous v
version or "failover" to an entirely different implementation are likely to be h ersion or "failover" to an entirely different implementation are likely to be he
elpful. (See <xref target="ecn" format="default"/>).</t> lpful. (See <xref target="ecn" format="default"/>.)</t>
</section> </section>
</section> </section>
<section anchor="Futures" numbered="true" toc="default"> <section anchor="Futures" numbered="true" toc="default">
<name>Future Work</name> <name>Future Work</name>
<t>By its nature, this document has been retrospective. In addition to con sidering how the Lessons Learned to date apply to current and future Path Aware networking proposals, it's also worth considering whether there is deeper invest igation left to do.</t> <t>By its nature, this document has been retrospective. In addition to con sidering how the Lessons Learned to date apply to current and future Path Aware networking proposals, it's also worth considering whether there is deeper invest igation left to do.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>We note that this work was based on contributions from experts on va rious Path Aware networking techniques, and all of the contributed techniques in volved unicast protocols. We didn't consider how these lessons might apply to mu lticast, and, given anecdotal reports at the IETF 109 MOPS working group meeting of IP multicast offerings within data centers at one or more cloud providers (< xref target="MOPS-109-Min" format="default"/>), it might be useful to think abou t path awareness in multicast, before we have a history of unsuccessful deployme nts to document.</li> <li>We note that this work was based on contributions from experts on va rious Path Aware techniques, and all of the contributed techniques involved unic ast protocols. We didn't consider how these lessons might apply to multicast, an d, 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 prov iders <xref target="MOPS-109-Min" format="default"/>, it might be useful to thin k about Path Awareness in multicast, before we have a history of unsuccessful de ployments to document.</li>
<li> <li>
<t>The question of whether a mechanism supports admission control, bas ed on either endpoints or applications, is associated with Path Awareness. One o f the motivations of IntServ and a number of other architectures (e.g. Determini stic Networking, <xref target="RFC8655" format="default"/>) is the ability to "s ay no" to an application based on resource availability on a path, before the ap plication 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 n eeds. The question of whether admission control is needed comes up repeatedly, b ut we have learned a few useful lessons that, while covered implicitly in some o f the lessons learned of the document, might be explained explicitly: </t> <t>The question of whether a mechanism supports admission control, bas ed on either endpoints or applications, is associated with Path Awareness. One o f the motivations of IntServ and a number of other architectures (e.g., Determin istic Networking <xref target="RFC8655" format="default"/>) is the ability to "s ay no" to an application based on resource availability on a path, before the ap plication 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 n eeds. The question of whether admission control is needed comes up repeatedly, b ut we have learned a few useful lessons that, while covered implicitly in some o f the Lessons Learned provided in this document, might be explained explicitly:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li>We have gained a lot of experience with application-based adapta <li>We have gained a lot of experience with application-based adapta
tion since the days where applications just injected traffic in-elastically into tion since the days where applications just injected traffic inelastically into
the network. Such adaptations seem to work well enough that admission control i the network. Such adaptations seem to work well enough that admission control is
s of less value to these applications</li> of less value to these applications.</li>
<li>There are end-to-end measurement techniques that can steer traff <li>There are end-to-end measurement techniques that can steer traff
ic at the application layer (Content Distribution Networks, multi-CDNs like Conv ic at the application layer (Content Delivery Networks (CDNs), multi-CDNs like C
iva <xref target="Conviva" format="default"/>, etc.)</li> onviva <xref target="Conviva" format="default"/>, etc.).</li>
<li>We noted in <xref target="ProtocolStackSupport" format="default" <li>We noted in <xref target="ProtocolStackSupport" format="default"
/> that applications often don't know how to utilize Path Aware techniques. This /> 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 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 appli to ask accurately for the resources they need, whether this is because the appli
cation itself doesn't know, or because the application has no way to signal its cation itself doesn't know or because the application has no way to signal its e
expectations to the underlying protocol stack. To date, attempts to help them ha xpectations to the underlying protocol stack. To date, attempts to help them hav
ven't gotten anywhere (e.g. the multiple-TSPEC additions to RSVP to attempt to m en't gotten anywhere (e.g., the multiple-TSPEC (Traffic Specification) additions
irror codec selection by applications <xref target="I-D.ietf-tsvwg-intserv-multi to RSVP to attempt to mirror codec selection by applications <xref target="I-D.
ple-tspec" format="default"/> expired in 2013).</li> ietf-tsvwg-intserv-multiple-tspec" format="default"/> expired in 2013).</li>
</ul> </ul>
</li> </li>
<li>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 imp ede, Path Aware networking techniques. For example, there is limited ability in IP to constrain bidirectional paths to be symmetric, and information-centric net working protocols such as Named Data Networking (NDN) and Content-Centric Networ king (CCNx) (<xref target="RFC8793" format="default"/>) must force bidirectional path symmetry using protocol-specific mechanisms.</li> <li>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 imp ede, Path Aware techniques. For example, there is limited ability in IP to const rain bidirectional paths to be symmetric, and information-centric networking pro tocols such as Named Data Networking (NDN) and Content-Centric Networking (CCNx) <xref target="RFC8793" format="default"/> must force bidirectional path symmetr y using protocol-specific mechanisms.</li>
</ul> </ul>
</section> </section>
<section anchor="Contributions" numbered="true" toc="default"> <section anchor="Contributions" numbered="true" toc="default">
<name>Contributions</name> <name>Contributions</name>
<t>Contributions on these Path Aware networking techniques were analyzed t o arrive at the Lessons Learned captured in <xref target="LessonsLearned" format ="default"/>.</t> <t>Contributions on these Path Aware techniques were analyzed to arrive at the Lessons Learned captured in <xref target="LessonsLearned" format="default"/ >.</t>
<t>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 servi ce to others who may revisit this document, so they'll have the details close at hand.</t> <t>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 servi ce to others who may revisit this document, so they'll have the details close at hand.</t>
<section anchor="ST2" numbered="true" toc="default"> <section anchor="ST2" numbered="true" toc="default">
<name>Stream Transport (ST, ST2, ST2+)</name> <name>Stream Transport (ST, ST2, ST2+)</name>
<t>The suggested references for Stream Transport are:</t> <t>The suggested references for Stream Transport are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>ST - A Proposed Internet Stream Protocol <xref target="IEN-119" fo <li>"<xref target="IEN-119" format="title"/>" <xref target="IEN-119" f
rmat="default"/></li> ormat="default"/></li>
<li>Experimental Internet Stream Protocol, Version 2 (ST-II) <xref tar <li>"<xref target="RFC1190" format="title"/>" <xref target="RFC1190" f
get="RFC1190" format="default"/></li> ormat="default"/></li>
<li>Internet Stream Protocol Version 2 (ST2) Protocol Specification - <li>"<xref target="RFC1819" format="title"/>" <xref target="RFC1819" f
Version ST2+ <xref target="RFC1819" format="default"/></li> ormat="default"/></li>
</ul> </ul>
<t>The first version of Stream Transport, ST <xref target="IEN-119" form at="default"/>, was published in the late 1970's and was implemented and deploye d on the ARPANET at small scale. It was used throughout the 1980's for experimen tal transmission of voice, video, and distributed simulation.</t> <t>The first version of Stream Transport, ST <xref target="IEN-119" form at="default"/>, was published in the late 1970s and was implemented and deployed on the ARPANET at small scale. It was used throughout the 1980s for experimenta l transmission of voice, video, and distributed simulation.</t>
<t>The second version of the ST specification (ST2) <xref target="RFC119 0" format="default"/> <xref target="RFC1819" format="default"/> was an experimen tal connection-oriented internetworking protocol that operated at the same layer as connectionless IP. ST2 packets could be distinguished by their IP header ver sion numbers (IP, at that time, used version number 4, while ST2 used version nu mber 5).</t> <t>The second version of the ST specification (ST2) <xref target="RFC119 0" format="default"/> <xref target="RFC1819" format="default"/> was an experimen tal connection-oriented internetworking protocol that operated at the same layer as connectionless IP. ST2 packets could be distinguished by their IP header ver sion numbers (IP, at that time, used version number 4, while ST2 used version nu mber 5).</t>
<t>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 specifica tion communicated by a separate protocol. The flow specification could be associ ated with QoS state in routers, producing an experimental resource reservation p rotocol. This allowed ST2 routers along a path to offer end-to-end guarantees, p rimarily to satisfy the QoS requirements for realtime services over the Internet .</t> <t>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 specifica tion communicated by a separate protocol. The flow specification could be associ ated with QoS state in routers, producing an experimental resource reservation p rotocol. This allowed ST2 routers along a path to offer end-to-end guarantees, p rimarily to satisfy the QoS requirements for real-time services over the Interne t.</t>
<section anchor="reasons-for-non-deployment" numbered="true" toc="defaul t"> <section anchor="reasons-for-non-deployment" numbered="true" toc="defaul t">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>Although implemented in a range of equipment, ST2 was not widely us ed after completion of the experiments. It did not offer the scalability and fa te-sharing properties that have come to be desired by the Internet community.</t > <t>Although implemented in a range of equipment, ST2 was not widely us ed after completion of the experiments. It did not offer the scalability and fa te-sharing properties that have come to be desired by the Internet community.</t >
<t>The ST2 protocol is no longer in use.</t> <t>The ST2 protocol is no longer in use.</t>
</section> </section>
<section anchor="lessons-learned" numbered="true" toc="default"> <section anchor="lessons-learned" numbered="true" toc="default">
<name>Lessons Learned.</name> <name>Lessons Learned</name>
<t>As time passed, the trade-off between router processing and link ca <t>As time passed, the trade-off between router processing and link ca
pacity changed. Links became faster and the cost of router processing became com pacity changed. Links became faster, and the cost of router processing became co
paratively more expensive.</t> mparatively more expensive.</t>
<t>The ST2 control protocol used "hard state" - once a route was estab <t>The ST2 control protocol used "hard state" -- once a route was esta
lished, and resources were reserved, routes and resources existing until they we blished, and resources were reserved, routes and resources existed until they we
re explicitly released via signaling. A soft-state approach was thought superior re explicitly released via signaling. A soft-state approach was thought superior
to this hard-state approach, and led to development of the IntServ model descri to this hard-state approach and led to development of the IntServ model describ
bed in <xref target="IntServ" format="default"/>.</t> ed in <xref target="IntServ" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="IntServ" numbered="true" toc="default"> <section anchor="IntServ" numbered="true" toc="default">
<name>Integrated Services (IntServ)</name> <name>Integrated Services (IntServ)</name>
<t>The suggested references for IntServ are:</t> <t>The suggested references for IntServ are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>RFC 1633 Integrated Services in the Internet Architecture: an Over <li>"<xref target="RFC1633" format="title"/>" <xref target="RFC1633" f
view <xref target="RFC1633" format="default"/></li> ormat="default"/></li>
<li>RFC 2211 Specification of the Controlled-Load Network Element Serv <li>"<xref target="RFC2211" format="title"/>" <xref target="RFC2211" f
ice <xref target="RFC2211" format="default"/></li> ormat="default"/></li>
<li>RFC 2212 Specification of Guaranteed Quality of Service <xref targ <li>"<xref target="RFC2212" format="title"/>" <xref target="RFC2212" f
et="RFC2212" format="default"/></li> ormat="default"/></li>
<li>RFC 2215 General Characterization Parameters for Integrated Servic <li>"<xref target="RFC2215" format="title"/>" <xref target="RFC2215" f
e Network Elements <xref target="RFC2215" format="default"/></li> ormat="default"/></li>
<li>RFC 2205 Resource ReSerVation Protocol (RSVP) <xref target="RFC220 <li>"<xref target="RFC2205" format="title"/>" <xref target="RFC2205" f
5" format="default"/></li> ormat="default"/></li>
</ul> </ul>
<t>In 1994, when the IntServ architecture document <xref target="RFC1633 <t>In 1994, when the IntServ architecture document <xref target="RFC1633
" format="default"/> was published, real-time traffic was first appearing on the " format="default"/> was published, real-time traffic was first appearing on the
Internet. At that time, bandwidth was still a scarce commodity. Internet Servic Internet. At that time, bandwidth was still a scarce commodity. Internet Servic
e Providers built networks over DS3 (45 Mbps) infrastructure, and sub-rate (&lt; e Providers built networks over DS3 (45 Mbps) infrastructure, and sub-rate (&lt;
1 Mpbs) access was common. Therefore, the IETF anticipated a need for a fine-gr 1 Mbps) access was common. Therefore, the IETF anticipated a need for a fine-gr
ained QoS mechanism.</t> ained QoS mechanism.</t>
<t>In the IntServ architecture, some applications can require service g <t>In the IntServ architecture, some applications can require service gu
uarantees. Therefore, those applications use the Resource Reservation Protocol ( arantees. Therefore, those applications use RSVP <xref target="RFC2205" format="
RSVP) <xref target="RFC2205" format="default"/> to signal QoS reservations acr default"/> to signal QoS reservations across network paths. Every router in the
oss network paths. Every router in the network that participates in IntServ mai network that participates in IntServ maintains per-flow soft state to a) perfor
ntains per-flow soft-state to a) perform call admission control and b) deliver g m call admission control and b) deliver guaranteed service.</t>
uaranteed service.</t> <t>Applications use Flow Specifications (Flow Specs, or FLOWSPECs) <xref
<t>Applications use Flow Specification (Flow Specs) <xref target="RFC221 target="RFC2210" format="default"/> to describe the traffic that they emit. RSV
0" format="default"/> to describe the traffic that they emit. RSVP reserves capa P reserves capacity for traffic on a per-Flow-Spec basis.</t>
city for traffic on a per Flow Spec basis.</t>
<section anchor="reasons-for-non-deployment-1" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-1" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>Although IntServ has been used in enterprise and government network s, IntServ was never widely deployed on the Internet because of its cost. The fo llowing factors contributed to operational cost:</t> <t>Although IntServ has been used in enterprise and government network s, IntServ was never widely deployed on the Internet because of its cost. The fo llowing factors contributed to operational cost:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>IntServ must be deployed on every router that is on a path where <li>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 no IntServ is to be used. Although it is possible to include a router that does no
t participate in IntServ along the path being controlled, if that router is like t participate in IntServ along the path being controlled, if that router is like
ly to become a bottleneck, IntServ cannot be used to avoid that bottleneck along ly to become a bottleneck, IntServ cannot be used to avoid that bottleneck along
the path</li> the path.</li>
<li>IntServ maintained per flow state</li> <li>IntServ maintained per-flow state.</li>
</ul> </ul>
<t>As IntServ was being discussed, the following occurred:</t> <t>As IntServ was being discussed, the following occurred:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For many expected uses, it became more cost effective to solve t he QoS problem by adding bandwidth. Between 1994 and 2000, Internet Service Prov iders upgraded their infrastructures from DS3 (45 Mbps) to OC-48 (2.4 Gbps). Thi s 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 Servi ce Providers had little reason to enable IntServ.</li> <li>For many expected uses, it became more cost effective to solve t he QoS problem by adding bandwidth. Between 1994 and 2000, Internet Service Prov iders upgraded their infrastructures from DS3 (45 Mbps) to OC-48 (2.4 Gbps). Thi s 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 Servi ce Providers had little reason to enable IntServ.</li>
<li>DiffServ <xref target="RFC2475" format="default"/> offered a mor e cost-effective, albeit less fine-grained, solution to the QoS problem.</li> <li>Diffserv <xref target="RFC2475" format="default"/> offered a mor e cost-effective, albeit less fine-grained, solution to the QoS problem.</li>
</ul> </ul>
</section> </section>
<section anchor="lessons-learned-1" numbered="true" toc="default"> <section anchor="lessons-learned-1" numbered="true" toc="default">
<name>Lessons Learned.</name> <name>Lessons Learned</name>
<t>The following lessons were learned:</t> <t>The following lessons were learned:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Any mechanism that requires every participating onpath router to maintain per-flow state is not likely to succeed, unless the additional cost fo r offering the feature can be recovered from the user.</li> <li>Any mechanism that requires every participating on-path router t o maintain per-flow state is not likely to succeed, unless the additional cost f or offering the feature can be recovered from the user.</li>
<li>Any mechanism that requires an operator to upgrade all of its ro uters is not likely to succeed, unless the additional cost for offering the feat ure can be recovered from the user.</li> <li>Any mechanism that requires an operator to upgrade all of its ro uters is not likely to succeed, unless the additional cost for offering the feat ure can be recovered from the user.</li>
</ul> </ul>
<t>In environments where IntServ has been deployed, trust relationship <t>In environments where IntServ has been deployed, trust relationship
s with endpoints are very different from trust relationships on the Internet its s
elf, and there are often clearly-defined hierarchies in Service Level Agreements with endpoints are very different from trust relationships on the
(SLAs), and well-defined transport flows operating with pre-determined capacity Internet itself. There are often clearly defined hierarchies in
and latency requirements over paths where capacity or other attributes are cons Service Level Agreements (SLAs) governing well-defined transport flows
trained.</t> operating with predetermined capacity and latency requirements over
<t>IntServ was never widely deployed to manage capacity across the Int paths where capacity or other attributes are constrained.</t>
ernet. However, the technique that it produced was deployed for reasons other th <t>IntServ was never widely deployed to manage capacity across the Int
an bandwidth management. RSVP is widely deployed as an MPLS signaling mechanism. ernet. However, the technique that it produced was deployed for reasons other th
BGP reuses the RSVP concept of Filter Specs to distribute firewall filters, alt an bandwidth management. RSVP is widely deployed as an MPLS signaling mechanism.
hough they are called Flow Spec Component Types in BGP <xref target="RFC5575" fo BGP reuses the RSVP concept of Filter Specs to distribute firewall filters, alt
rmat="default"/>.</t> hough they are called "Flow Spec Component Types" in BGP <xref target="RFC5575"
format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="Quick-Start" numbered="true" toc="default"> <section anchor="Quick-Start" numbered="true" toc="default">
<name>Quick-Start TCP</name> <name>Quick-Start TCP</name>
<t>The suggested references for Quick-Start TCP are:</t> <t>The suggested references for Quick-Start TCP are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Quick-Start for TCP and IP <xref target="RFC4782" format="default" <li>"<xref target="RFC4782" format="title"/>" <xref target="RFC4782" f
/></li> ormat="default"/></li>
<li>Determining an appropriate initial sending rate over an underutili <li>"Determining an appropriate sending rate over an underutilized net
zed network path <xref target="SAF07" format="default"/></li> work path" <xref target="SAF07" format="default"/></li>
<li>Fast Startup Internet Congestion Control for Broadband Interactive <li>"Fast Startup Internet Congestion Control for Broadband Interactiv
Applications <xref target="Sch11" format="default"/></li> e Applications" <xref target="Sch11" format="default"/></li>
<li>Using Quick-Start to enhance TCP-friendly rate control performance <li>"Using Quick-Start to enhance TCP-friendly rate control performanc
in bidirectional satellite networks <xref target="QS-SAT" format="default"/></l e in bidirectional satellite networks" <xref target="QS-SAT" format="default"/><
i> /li>
</ul> </ul>
<t>Quick-Start <xref target="RFC4782" format="default"/> is an Experimen tal TCP extension that leverages support from the routers on the path to determi ne an allowed initial sending rate for a path through the Internet, either at th e start of data transfers or after idle periods. Without information about the p ath, a sender cannot easily determine an appropriate initial sending rate. The d efault TCP congestion control therefore uses the safe but time-consuming slow-st art algorithm <xref target="RFC5681" format="default"/>. With Quick-Start, conne ctions are allowed to use higher initial sending rates if there is significant u nused bandwidth along the path, and if the sender and all of the routers along t he path approve the request.</t> <t>Quick-Start is defined in an Experimental RFC <xref target="RFC4782" format="default"/> and is a TCP extension that leverages support from the router s on the path to determine an allowed initial sending rate for a path through th e Internet, either at the start of data transfers or after idle periods. Without information about the path, a sender cannot easily determine an appropriate ini tial sending rate. The default TCP congestion control therefore uses the safe bu t time-consuming slow-start algorithm <xref target="RFC5681" format="default"/>. With Quick-Start, connections are allowed to use higher initial sending rates i f there is significant unused bandwidth along the path and if the sender and all of the routers along the path approve the request.</t>
<t>By examining the Time To Live (TTL) field in Quick-Start packets, a s ender can determine if routers on the path have approved the Quick-Start reques t. However, this method is unable to take into account the routers hidden by tun nels or other network nodes invisible at the IP layer.</t> <t>By examining the Time To Live (TTL) field in Quick-Start packets, a s ender can determine if routers on the path have approved the Quick-Start reques t. However, this method is unable to take into account the routers hidden by tun nels or other network nodes invisible at the IP layer.</t>
<t>The protocol also includes a nonce that provides protection against c <t>The protocol also includes a nonce that provides protection against c
heating routers and receivers. If the Quick-Start request is explicitly approved heating 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 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 m ; otherwise, TCP would use the default congestion control. Quick-Start requires
odifications in the involved end-systems as well in routers. Due to the resultin modifications in the involved end systems as well as in routers. Due to the resu
g deployment challenges, Quick-Start was only proposed in <xref target="RFC4782" lting deployment challenges, Quick-Start was only proposed in <xref target="RFC4
format="default"/> for controlled environments.</t> 782" format="default"/> for controlled environments.</t>
<t>The Quick-Start mechanism is a lightweight, coarse-grained, in-band, <t>The Quick-Start mechanism is a lightweight, coarse-grained, in-band,
network-assisted fast startup mechanism. The benefits are studied by simulation network-assisted fast startup mechanism. The benefits are studied by simulation
in a research paper <xref target="SAF07" format="default"/> that complements the in a research paper <xref target="SAF07" format="default"/> that complements the
protocol specification. The study confirms that Quick-Start can significantly s protocol specification. The study confirms that Quick-Start can significantly s
peed up mid-sized data transfers. That paper also presents router algorithms tha peed up mid-sized data transfers. That paper also presents router algorithms tha
t do not require keeping per-flow state. Later studies <xref target="Sch11" form t do not require keeping per-flow state. Later studies <xref target="Sch11" form
at="default"/> comprehensively analyzes Quick-Start with a full Linux implementa at="default"/> comprehensively analyze Quick-Start with a full Linux implementat
tion and with a router fast path prototype using a network processor. In both ca ion and with a router fast-path prototype using a network processor. In both cas
ses, Quick-Start could be implemented with limited additional complexity.</t> es, Quick-Start could be implemented with limited additional complexity.</t>
<section anchor="reasons-for-non-deployment-2" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-2" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>However, experiments with Quick-Start in <xref target="Sch11" forma t="default"/> revealed several challenges:</t> <t>However, experiments with Quick-Start in <xref target="Sch11" forma t="default"/> revealed several challenges:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Having information from the routers along the path can reduce th <li>Having information from the routers along the path can reduce th
e risk of congestion, but cannot avoid it entirely. Determining whether there is e risk of congestion but cannot avoid it entirely. Determining whether there is
unused capacity is not trivial in actual router and host implementations. Data unused capacity is not trivial in actual router and host implementations. Data a
about available capacity visible at the IP layer may be imprecise, and due to th bout available capacity visible at the IP layer may be imprecise, and due to the
e propagation delay, information can already be outdated when it reaches a sende propagation delay, information can already be outdated when it reaches a sender
r. There is a trade-off between the speedup of data transfers and the risk of co . There is a trade-off between the speedup of data transfers and the risk of con
ngestion even with Quick-Start. This could be mitigated by only allowing Quick-S gestion even with Quick-Start. This could be mitigated by only allowing Quick-St
tart to access a proportion of the unused capacity along a path.</li> art to access a proportion of the unused capacity along a path.</li>
<li>For scalable router fast path implementation, it is important to <li>For scalable router fast-path implementations, it is important t
enable parallel processing of packets, as this is a widely used method e.g. in o enable parallel processing of packets, as this is a widely used method, e.g.,
network processors. One challenge is synchronization of information between pack in network processors. One challenge is synchronization of information between p
ets that are processed in parallel, which should be avoided as much as possible. ackets that are processed in parallel, which should be avoided as much as possib
</li> le.</li>
<li>Only some types of application traffic can benefit from Quick-St <li>Only some types of application traffic can benefit from Quick-St
art. Capacity needs to be requested and discovered. The discovered capacity need art. Capacity needs to be requested and discovered. The discovered capacity need
s to be utilized by the flow, or it implicitly becomes available for other flows s 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 Qu . Failing to use the requested capacity may have already reduced the pool of Qu
ick-Start capacity that was made available to other competing Quick-Start reques ick-Start capacity that was made available to other competing Quick-Start reques
ts. The benefit is greatest when senders use this only for bulk flows and avoid ts. 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 sending unnecessary Quick-Start requests, e.g., for flows that only send a smal
amount of data. Choosing an appropriate request size requires application-inter l amount of data. Choosing an appropriate request size requires application-inte
nal knowledge that is not commonly expressed by the transport API. How a sender rnal 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 uns can determine the rate for an initial Quick-Start request is still a largely un
olved problem.</li> solved problem.</li>
</ul> </ul>
<t>There is no known deployment of Quick-Start for TCP or other IETF t ransports.</t> <t>There is no known deployment of Quick-Start for TCP or other IETF t ransports.</t>
</section> </section>
<section anchor="lessons-learned-2" numbered="true" toc="default"> <section anchor="lessons-learned-2" numbered="true" toc="default">
<name>Lessons Learned</name> <name>Lessons Learned</name>
<t>Some lessons can be learned from Quick-Start. Despite being a very <t>Some lessons can be learned from Quick-Start. Despite being a very
light-weight protocol, Quick-Start suffers from poor incremental deployment prop lightweight protocol, Quick-Start suffers from poor incremental deployment prope
erties, both regarding the required modifications in network infrastructure as w rties regarding both a) the required modifications in network infrastructure and
ell as its interactions with applications. Except for corner cases, congestion c b) its interactions with applications. Except for corner cases, congestion cont
ontrol can be quite efficiently performed end-to-end in the Internet, and in mod rol can be quite efficiently performed end to end in the Internet, and in modern
ern stacks there is not much room for significant improvement by additional netw stacks there is not much room for significant improvement by additional network
ork support.</t> support.</t>
<t>After publication of the Quick-Start specification, there have been <t>After publication of the Quick-Start specification, there have been
large-scale experiments with an initial window of up to 10 MSS <xref target="RF large-scale experiments with an initial window of up to 10 segments <xref targe
C6928" format="default"/>. This alternative "IW10" approach can also ramp-up dat t="RFC6928" format="default"/>. This alternative "IW10" approach can also ramp u
a transfers faster than the standard congestion control, but it only requires se p data transfers faster than the standard congestion control, but it only requir
nder-side modifications. As a result, this approach can be easier and incrementa es sender-side modifications. As a result, this approach can be easier and incre
lly deployed in the Internet. While theoretically Quick-Start can outperform "IW mentally deployed in the Internet. While theoretically Quick-Start can outperfor
10", the improvement in completion time for data transfer times can, in many cas m "IW10", the improvement in completion time for data transfer times can, in man
es, be small. After publication of <xref target="RFC6928" format="default"/>, mo y cases, be small. After publication of <xref target="RFC6928" format="default"/
st modern TCP stacks have increased their default initial window.</t> >, most modern TCP stacks have increased their default initial window.</t>
</section> </section>
</section> </section>
<section anchor="Source-Quench" numbered="true" toc="default"> <section anchor="Source-Quench" numbered="true" toc="default">
<name>ICMP Source Quench</name> <name>ICMP Source Quench</name>
<t>The suggested references for ICMP Source Quench are:</t> <t>The suggested reference for ICMP Source Quench is:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>INTERNET CONTROL MESSAGE PROTOCOL <xref target="RFC0792" format="d efault"/></li> <li>"<xref target="RFC0792" format="title"/>" <xref target="RFC0792" f ormat="default"/></li>
</ul> </ul>
<t>The ICMP Source Quench message <xref target="RFC0792" format="default "/> allowed an on-path router to request the source of a flow to reduce its send ing rate. This method allowed a router to provide an early indication of impendi ng congestion on a path to the sources that contribute to that congestion.</t> <t>The ICMP Source Quench message <xref target="RFC0792" format="default "/> allowed an on-path router to request the source of a flow to reduce its send ing rate. This method allowed a router to provide an early indication of impendi ng congestion on a path to the sources that contribute to that congestion.</t>
<section anchor="reasons-for-non-deployment-3" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-3" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>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 li nks, with low multiplexing of flows the method could be used to regulate (moment arily reduce) the transmission rate. However, the simple signal does not scale w ith link speed, or the number of flows sharing a link.</t> <t>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 li nks, with low multiplexing of flows the method could be used to regulate (moment arily reduce) the transmission rate. However, the simple signal does not scale w ith link speed or with the number of flows sharing a link.</t>
<t>The approach was overtaken by the evolution of congestion control m ethods in TCP <xref target="RFC2001" format="default"/>, and later also by other IETF transports. Because these methods were based upon measurement of the end-t o-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 a nd endpoint stacks.</t> <t>The approach was overtaken by the evolution of congestion control m ethods in TCP <xref target="RFC2001" format="default"/>, and later also by other IETF transports. Because these methods were based upon measurement of the end-t o-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 a nd endpoint stacks.</t>
<t>After ICMP Source Quench was specified, the IETF began to recommend that transports provide end-to-end congestion control <xref target="RFC2001" fo rmat="default"/>. The Source Quench method has been obsoleted by the IETF <xref target="RFC6633" format="default"/>, and both hosts and routers must now silentl y discard this message.</t> <t>After ICMP Source Quench was specified, the IETF began to recommend that transports provide end-to-end congestion control <xref target="RFC2001" fo rmat="default"/>. The Source Quench method has been obsoleted by the IETF <xref target="RFC6633" format="default"/>, and both hosts and routers must now silentl y discard this message.</t>
</section> </section>
<section anchor="lessons-learned-3" numbered="true" toc="default"> <section anchor="lessons-learned-3" numbered="true" toc="default">
<name>Lessons Learned</name> <name>Lessons Learned</name>
<t>This method had several problems:</t> <t>This method had several problems.</t>
<t>First, <xref target="RFC0792" format="default"/> did not sufficient ly specify how the sender would react to the ICMP Source Quench signal from the path (e.g., <xref target="RFC1016" format="default"/>). There was ambiguity in h ow the sender should utilize this additional information. This could lead to unf airness in the way that receivers (or routers) responded to this message.</t> <t>First, <xref target="RFC0792" format="default"/> did not sufficient ly specify how the sender would react to the ICMP Source Quench signal from the path (e.g., <xref target="RFC1016" format="default"/>). There was ambiguity in h ow the sender should utilize this additional information. This could lead to unf airness in the way that receivers (or routers) responded to this message.</t>
<t>Second, while the message did provide additional information, the E xplicit Congestion Notification (ECN) mechanism <xref target="RFC3168" format="d efault"/> provided a more robust and informative signal for network nodes to pro vide early indication that a path has become congested.</t> <t>Second, while the message did provide additional information, the E xplicit Congestion Notification (ECN) mechanism <xref target="RFC3168" format="d efault"/> provided a more robust and informative signal for network nodes to pro vide early indication that a path has become congested.</t>
<t>The mechanism originated at a time when the Internet trust model wa <t>The mechanism originated at a time when the Internet trust model wa
s very different. Most endpoint implementations did not attempt to verify that t s very different. Most endpoint implementations did not attempt to verify that t
he message originated from an on-path node before they utilized the message. Thi he message originated from an on-path node before they utilized the message. Thi
s made it vulnerable to denial of service attacks. In theory, routers might hav s made it vulnerable to Denial-of-Service (DoS) attacks. In theory, routers mig
e chosen to use the quoted packet contained in the ICMP payload to validate that ht have chosen to use the quoted packet contained in the ICMP payload to validat
the message originated from an on-path node, but this would have increased per- e that the message originated from an on-path node, but this would have increase
packet processing overhead for each router along the path, would have required t d per-packet processing overhead for each router along the path and would have r
ransport functionality in the router to verify whether the quoted packet header equired transport functionality in the router to verify whether the quoted packe
corresponded to a packet the router had sent. In addition, section 5.2 of <xref t header corresponded to a packet the router had sent. In addition, <xref target
target="RFC4443" format="default"/> noted ICMPv6-based attacks on hosts that wou ="RFC4443" sectionFormat="of" section="5.2"/>
ld also have threatened routers processing ICMPv6 Source Quench payloads. As tim noted ICMPv6-based attacks on hosts that would also have threatened routers proc
e passed, it became increasingly obvious that the lack of validation of the mess essing ICMPv6 Source Quench payloads. As time passed, it became increasingly obv
ages exposed receivers to a security vulnerability where the messages could be f ious that the lack of validation of the messages exposed receivers to a security
orged to create a tangible denial of service opportunity.</t> vulnerability where the messages could be forged to create a tangible DoS oppor
tunity.</t>
</section> </section>
</section> </section>
<section anchor="TRIGTRAN" numbered="true" toc="default"> <section anchor="TRIGTRAN" numbered="true" toc="default">
<name>Triggers for Transport (TRIGTRAN)</name> <name>Triggers for Transport (TRIGTRAN)</name>
<t>The suggested references for TRIGTRAN are:</t> <t>The suggested references for TRIGTRAN are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>TRIGTRAN BOF at IETF 55 <xref target="TRIGTRAN-55" format="default "/></li> <li>TRIGTRAN BOF at IETF 55 <xref target="TRIGTRAN-55" format="default "/></li>
<li>TRIGTRAN BOF at IETF 56 <xref target="TRIGTRAN-56" format="default "/></li> <li>TRIGTRAN BOF at IETF 56 <xref target="TRIGTRAN-56" format="default "/></li>
</ul> </ul>
<t>TCP <xref target="RFC0793" format="default"/> has a well-known weakne <t>TCP <xref target="RFC0793" format="default"/> has a well-known weakne
ss - the end-to-end flow control mechanism has only a single signal, the loss of ss -- the end-to-end flow control mechanism has only a single signal, the loss o
a segment, and TCP implementations since the late 1980s have interpreted the lo f a segment,
ss of a segment as evidence that the path between two endpoints may have become detected when no acknowledgment for the lost segment is received at the sender.
congested enough to exhaust buffers on intermediate hops, so that the TCP sender There are multiple reasons why the sender might not have received an acknowledg
should "back off" - reduce its sending rate until it knows that its segments ar ment for the segment. To name several, the segment could have been trapped in a
e now being delivered without loss <xref target="RFC5681" format="default"/>. Mo routing loop, damaged in transmission and failed checksum verification at the
re modern TCP stacks have added a growing array of strategies about how to estab receiver, or lost because some intermediate device discarded the packet, or any
lish the sending rate <xref target="RFC5681" format="default"/>, but when a path of a variety of other things could have happened to the acknowledgment on the wa
is no longer operational, TCP would continue to retry transmissions, which woul y back from the receiver to the sender. TCP implementations since the late 1980s
d fail, again, and double their Retransmission Time Out (RTO) timers with each f have made the "safe" decision and have interpreted the loss of a segment as evi
ailed transmission, with the result that TCP would wait many seconds before retr dence
ying a segment, even if the path becomes operational while the sender is waiting that the path between two endpoints may have become congested enough to exhaust
for its next retry.</t> 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 witho
ut loss
<xref target="RFC5681" format="default"/>.
</t>
<t>The thinking behind TRIGTRAN was that if a path completely stopped wo rking 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) perio d.</t> <t>The thinking behind TRIGTRAN was that if a path completely stopped wo rking 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) perio d.</t>
<section anchor="reasons-for-non-deployment-4" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-4" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>The early dreams for TRIGTRAN were dashed because of an assumption <t>The early dreams for TRIGTRAN were dashed because of an assumption
that TRIGTRAN triggers would be unauthenticated. This meant that any "safe" TRIG that TRIGTRAN triggers would be unauthenticated. This meant that any "safe" TRIG
TRAN mechanism would have relied on a mechanism such as setting the IPv4 TTL or TRAN 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 t IPv6 Hop Count to 255 at a sender and testing that it was 254 upon receipt, so t
hat a receiver could verify that a signal was generated by an adjacent sender kn hat a receiver could verify that a signal was generated by an adjacent sender kn
own to be on the path being used, and not some unknown sender which might not ev own to be on the path being used and not some unknown sender that might not even
en be on the path (e.g., "The Generalized TTL Security Mechanism (GTSM)" <xref t be on the path (e.g.,
arget="RFC5082" format="default"/>). This situation is very similar to the case "<xref target="RFC5082" format="title"/>" <xref target="RFC5082" format="default
for ICMP Source Quench messages as described in <xref target="Source-Quench" for "/>). This situation is very similar to the case for ICMP Source Quench messages
mat="default"/>, which were also unauthenticated, and could be sent by an off-pa as described in <xref target="Source-Quench" format="default"/>, which were als
th attacker, resulting in deprecation of ICMP Source Quench message processing < o unauthenticated and could be sent by an off-path attacker, resulting in deprec
xref target="RFC6633" format="default"/>.</t> ation of ICMP Source Quench message processing <xref target="RFC6633" format="de
<t>TRIGTRAN's scope shrunk from "the path is down" to "the first-hop l fault"/>.</t>
ink is down".</t> <t>TRIGTRAN's scope shrunk from "the path is down" to "the first-hop l
ink is down."</t>
<t>But things got worse.</t> <t>But things got worse.</t>
<t>Because TRIGTRAN triggers would only be provided when the first-hop <t>Because TRIGTRAN triggers would only be provided when the first-hop
link was "down", TRIGTRAN triggers couldn't replace normal TCP retransmission b link was "down", TRIGTRAN triggers couldn't replace normal TCP retransmission b
ehavior if the path failed because some link further along the network path was ehavior 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 ma "down". So TRIGTRAN triggers added complexity to an already-complex TCP state ma
chine, and did not allow any existing complexity to be removed.</t> chine and did not allow any existing complexity to be removed.</t>
<t>There was also an issue that the TRIGTRAN signal was not sent in re <t>There was also an issue that the TRIGTRAN signal was not sent in re
sponse to a specific host that had been sending packets, and was instead a signa sponse to a specific host that had been sending packets and was instead a signal
l that stimulated a response by any sender on the link. This needs to scale when 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 t there are multiple flows trying to use the same resource, yet the sender of a tr
rigger has no understanding how many of the potential traffic sources will respo igger has no understanding of how many of the potential traffic sources will res
nd by sending packets - if recipients of the signal back-off their responses to pond by sending packets -- if recipients of the signal "back off" their response
a trigger to improve scaling, then that immediately mitigates the benefit of the s to a trigger to improve scaling, then that immediately mitigates the benefit o
signal.</t> f the signal.</t>
<t>Finally, intermediate forwarding nodes required modification to pro vide TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN triggers, so there was no way to recover the cost of modifying, testing, and deploying update d intermediate nodes.</t> <t>Finally, intermediate forwarding nodes required modification to pro vide TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN triggers, so there was no way to recover the cost of modifying, testing, and deploying update d intermediate nodes.</t>
<t>Two TRIGTRAN BOFs were held, at IETF 55 <xref target="TRIGTRAN-55" format="default"/> and IETF 56 <xref target="TRIGTRAN-56" format="default"/>, bu t this work was not chartered, and there was no interest in deploying TRIGTRAN u nless it was chartered and standardized in the IETF.</t> <t>Two TRIGTRAN BOFs were held, at IETF 55 <xref target="TRIGTRAN-55" format="default"/> and IETF 56 <xref target="TRIGTRAN-56" format="default"/>, bu t this work was not chartered, and there was no interest in deploying TRIGTRAN u nless it was chartered and standardized in the IETF.</t>
</section> </section>
<section anchor="lessons-learned-4" numbered="true" toc="default"> <section anchor="lessons-learned-4" numbered="true" toc="default">
<name>Lessons Learned.</name> <name>Lessons Learned</name>
<t>The reasons why this work was not chartered, much less deployed, pr ovide several useful lessons for researchers.</t> <t>The reasons why this work was not chartered, much less deployed, pr ovide several useful lessons for researchers.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>TRIGTRAN started with a plausible value proposition, but network ing 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.</li> <li>TRIGTRAN started with a plausible value proposition, but network ing realities in the early 2000s forced reductions in scope that led directly to reductions in potential benefits but no corresponding reductions in costs and c omplexity.</li>
<li>These reductions in scope were the direct result of an inability for hosts to trust or authenticate TRIGTRAN signals they received from the netw ork.</li> <li>These reductions in scope were the direct result of an inability for hosts to trust or authenticate TRIGTRAN signals they received from the netw ork.</li>
<li>Operators did not believe they could charge for TRIGTRAN signali ng, because first-hop links didn't fail frequently, and TRIGTRAN provided no red uction in operating expenses, so there was little incentive to purchase and depl oy TRIGTRAN-capable network equipment.</li> <li>Operators did not believe they could charge for TRIGTRAN signali ng, because first-hop links didn't fail frequently and TRIGTRAN provided no redu ction in operating expenses, so there was little incentive to purchase and deplo y TRIGTRAN-capable network equipment.</li>
</ul> </ul>
<t>It is also worth noting that the targeted environment for TRIGTRAN in the late 1990s contained links with a relatively small number of directly-con nected hosts - for instance, cellular or satellite links. The transport communit y was well aware of the dangers of sender synchronization based on multiple send ers 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 is common for a single "link" to support many senders and receivers on a single link, likely requiring TRIGTRAN senders to wait some r andom amount of time before sending after receiving a TRIGTRAN signal, which wou ld have reduced the benefits of TRIGTRAN even more.</t> <t>It is also worth noting that the targeted environment for TRIGTRAN in the late 1990s contained links with a relatively small number of directly con nected hosts -- for instance, cellular or satellite links. The transport communi ty was well aware of the dangers of sender synchronization based on multiple sen ders receiving the same stimulus at the same time, but the working assumption fo r 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 sende rs and receivers, likely requiring TRIGTRAN senders to wait some random amount o f time before sending after receiving a TRIGTRAN signal, which would have reduce d the benefits of TRIGTRAN even more.</t>
</section> </section>
</section> </section>
<section anchor="Shim6" numbered="true" toc="default"> <section anchor="Shim6" numbered="true" toc="default">
<name>Shim6</name> <name>Shim6</name>
<t>The suggested references for Shim6 are:</t> <t>The suggested reference for Shim6 is:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Shim6: Level 3 Multihoming Shim Protocol for IPv6 <xref target="RF C5533" format="default"/></li> <li>"<xref target="RFC5533" format="title"/>" <xref target="RFC5533" for mat="default"/></li>
</ul> </ul>
<t>The IPv6 routing architecture <xref target="RFC1887" format="default" /> assumed that most sites on the Internet would be identified by Provider Assig ned IPv6 prefixes, so that Default-Free Zone routers only contained routes to ot her providers, resulting in a very small IPv6 global routing table.</t> <t>The IPv6 routing architecture <xref target="RFC1887" format="default" /> assumed that most sites on the Internet would be identified by Provider Assig ned IPv6 prefixes, so that Default-Free Zone routers only contained routes to ot her providers, resulting in a very small IPv6 global routing table.</t>
<t>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.</t> <t>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.</t>
<t>IPv4 sites often multihomed by obtaining Provider Independent prefixe <t>IPv4 sites often multihomed by obtaining Provider Independent prefixe
s, and advertising these prefixes through multiple upstream providers. With the s and advertising these prefixes through multiple upstream providers. With the a
assumption that any multihomed IPv4 site would also multihome in IPv6, it seemed ssumption 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 Pro likely that IPv6 routing would be subject to the same pressures to announce Prov
vider Independent prefixes, resulting in a global IPv6 routing table that exhibi ider Independent prefixes, resulting in an IPv6 global routing table that exhibi
ted the same explosive growth as the global IPv4 routing table. During the early ted 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 w 2000s, work began on a protocol that would provide multihoming for IPv6 sites w
ithout requiring sites to advertise Provider Independent prefixes into the IPv6 ithout requiring sites to advertise Provider Independent prefixes into the IPv6
global routing table.</t> global routing table.</t>
<t>This protocol, called Shim6, allowed two endpoints to exchange multip <t>This protocol, called "Shim6", allowed two endpoints to exchange mult
le addresses ("Locators") that all mapped to the same endpoint ("Identity"). Aft iple addresses ("Locators") that all mapped to the same endpoint ("Identity"). A
er an endpoint learned multiple Locators for the other endpoint, it could send t fter an endpoint learned multiple Locators for the other endpoint, it could send
o any of those Locators with the expectation that those packets would all be del to any of those Locators with the expectation that those packets would all be d
ivered to the endpoint with the same Identity. Shim6 was an example of an "Ident elivered to the endpoint with the same Identity. Shim6 was an example of an "Ide
ity/Locator Split" protocol.</t> ntity/Locator Split" protocol.</t>
<t>Shim6, as defined in <xref target="RFC5533" format="default"/> and re <t>Shim6, as defined in <xref target="RFC5533" format="default"/> and re
lated RFCs, provided a workable solution for IPv6 multihoming using Provider Ass lated RFCs, provided a workable solution for IPv6 multihoming using Provider Ass
igned prefixes, including capability discovery and negotiation, and allowing end igned prefixes, including capability discovery and negotiation, and allowing end
-to-end application communication to continue even in the face of path failure, -to-end application communication to continue even in the face of path failure,
because applications don't see Locator failures, and continue to communicate wit because applications don't see Locator failures and continue to communicate with
h the same Identity using a different Locator.</t> the same Identity using a different Locator.</t>
<section anchor="reasons-for-non-deployment-5" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-5" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>Note that the problem being addressed was "site multihoming", but S him6 was providing "host multihoming". That meant that the decision about what p ath would be used was under host control, not under edge router control.</t> <t>Note that the problem being addressed was "site multihoming", but S him6 was providing "host multihoming". That meant that the decision about what p ath would be used was under host control, not under edge router control.</t>
<t>Although more work could have been done to provide a better technic al solution, the biggest impediments to Shim6 deployment were operational and bu siness considerations. These impediments were discussed at multiple network oper ator group meetings, including <xref target="Shim6-35" format="default"/> at <xr ef target="NANOG-35" format="default"/>.</t> <t>Although more work could have been done to provide a better technic al solution, the biggest impediments to Shim6 deployment were operational and bu siness considerations. These impediments were discussed at multiple network oper ator group meetings, including <xref target="Shim6-35" format="default"/> at <xr ef target="NANOG-35" format="default"/>.</t>
<t>The technical issues centered around concerns that Shim6 relied on the host to track all the connections, while also tracking Identity/Locator mapp ings in the kernel, and tracking failures to recognize that an available path ha s failed.</t> <t>The technical issues centered around concerns that Shim6 relied on the host to track all the connections, while also tracking Identity/Locator mapp ings in the kernel and tracking failures to recognize that an available path has failed.</t>
<t>The operational issues centered around concerns that operators were performing traffic engineering on traffic aggregates. With Shim6, these operato r traffic engineering policies must be pushed down to individual hosts.</t> <t>The operational issues centered around concerns that operators were performing traffic engineering on traffic aggregates. With Shim6, these operato r traffic engineering policies must be pushed down to individual hosts.</t>
<t>In addition, operators would have no visibility or control over the decision of hosts choosing to switch to another path. They expressed concerns t hat relying on hosts to steer traffic exposed operator networks to oscillation b ased 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 appear ed and disappeared on their networks.</t> <t>In addition, operators would have no visibility or control over the decision of hosts choosing to switch to another path. They expressed concerns t hat relying on hosts to steer traffic exposed operator networks to oscillation b ased 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 appear ed and disappeared on their networks.</t>
<t>In addition, firewalls that expected to find a TCP or UDP transport <t>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 inste -level protocol header in the IP payload would see a Shim6 Identity header inste
ad, and would not perform transport-protocol-based firewalling functions because ad, and they would not perform transport-protocol-based firewalling functions be
the firewall's normal processing logic would not look past the Identity header. cause the firewall's normal processing logic would not look past the Identity he
</t> ader.
The firewall would perform its default action, which would most likely be to dro
p packets that don't match any processing rule.</t>
<t>The business issues centered on reducing or removing the ability to sell BGP multihoming service to their own customers, which is often more expens ive than two single-homed connectivity services.</t> <t>The business issues centered on reducing or removing the ability to sell BGP multihoming service to their own customers, which is often more expens ive than two single-homed connectivity services.</t>
</section> </section>
<section anchor="lessons-learned-5" numbered="true" toc="default"> <section anchor="lessons-learned-5" numbered="true" toc="default">
<name>Lessons Learned</name> <name>Lessons Learned</name>
<t>It is extremely important to take operational concerns into account when a path-aware protocol is making decisions about path selection that may co nflict with existing operational practices and business considerations.</t> <t>It is extremely important to take operational concerns into account when a Path Aware protocol is making decisions about path selection that may co nflict with existing operational practices and business considerations.</t>
</section> </section>
<section anchor="Addendum-MP-TCP" numbered="true" toc="default"> <section anchor="Addendum-MP-TCP" numbered="true" toc="default">
<name>Addendum on MultiPath TCP</name> <name>Addendum on Multipath TCP</name>
<t>During discussions in the PANRG session at IETF 103 <xref target="P <t>During discussions in the PANRG session at IETF 103 <xref target="P
ANRG-103-Min" format="default"/>, Lars Eggert, past Transport Area Director, poi ANRG-103-Min" format="default"/>, Lars Eggert, past Transport Area Director, poi
nted out that during charter discussions for the Multipath TCP working group <xr nted out that during charter discussions for the Multipath TCP Working Group <xr
ef target="MP-TCP" format="default"/>, operators expressed concerns that custome ef target="MP-TCP" format="default"/>, operators expressed concerns that custome
rs could use Multipath TCP to loadshare TCP connections across operators simulta rs could use Multipath TCP to load-share TCP connections across operators simult
neously and compare passive performance measurements across network paths in rea aneously and compare passive performance measurements across network paths in re
l time, changing the balance of power in those business relationships. Although al time, changing the balance of power in those business relationships. Although
the Multipath TCP working group was chartered, this concern could have acted as the Multipath TCP Working Group was chartered, this concern could have acted as
an obstacle to deployment.</t> an obstacle to deployment.</t>
<t>Operator objections to Shim6 were focused on technical concerns, bu t this concern could have also been an obstacle to Shim6 deployment if the techn ical concerns had been overcome.</t> <t>Operator objections to Shim6 were focused on technical concerns, bu t this concern could have also been an obstacle to Shim6 deployment if the techn ical concerns had been overcome.</t>
</section> </section>
</section> </section>
<section anchor="NSIS" numbered="true" toc="default"> <section anchor="NSIS" numbered="true" toc="default">
<name>Next Steps in Signaling (NSIS)</name> <name>Next Steps in Signaling (NSIS)</name>
<t>The suggested references for Next Steps in Signaling (NSIS) are:</t> <t>The suggested references for Next Steps in Signaling (NSIS) are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the concluded working group charter <xref target="NSIS-CHARTER-200 1" format="default"/></li> <li>the concluded working group charter <xref target="NSIS-CHARTER-200 1" format="default"/></li>
<li>GIST: General Internet Signalling Transport <xref target="RFC5971" <li>"<xref target="RFC5971" format="title"/>" <xref target="RFC5971" f
format="default"/></li> ormat="default"/></li>
<li>NAT/Firewall NSIS Signaling Layer Protocol (NSLP) <xref target="RF <li>"<xref target="RFC5973" format="title"/>" <xref target="RFC5973" f
C5973" format="default"/></li> ormat="default"/></li>
<li>NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signal <li>"<xref target="RFC5974" format="title"/>" <xref target="RFC5974" f
ing <xref target="RFC5974" format="default"/></li> ormat="default"/></li>
<li>Authorization for NSIS Signaling Layer Protocols <xref target="RFC <li>"<xref target="RFC5981" format="title"/>" <xref target="RFC5981" f
5981" format="default"/></li> ormat="default"/></li>
</ul> </ul>
<t>The NSIS Working Group worked on signaling techniques for network lay <t>The NSIS Working Group worked on signaling techniques for network-lay
er resources (e.g., QoS resource reservations, Firewall and NAT traversal).</t> er resources (e.g., QoS resource reservations, Firewall and NAT traversal).</t>
<t>When RSVP <xref target="RFC2205" format="default"/> was used in deplo <t>When RSVP <xref target="RFC2205" format="default"/> was used in deplo
yments, a number of questions came up about its perceived limitations and potent yments, a number of questions came up about its perceived limitations and potent
ial missing features. The issues noted in the NSIS Working Group charter <xref t ial missing features. The issues noted in the NSIS Working Group charter <xref t
arget="NSIS-CHARTER-2001" format="default"/> include interworking between domain arget="NSIS-CHARTER-2001" format="default"/> include interworking between domain
s with different QoS architectures, mobility and roaming for IP interfaces, and s with different QoS architectures, mobility and roaming for IP interfaces, and
complexity. Later, the lack of security in RSVP was also recognized (<xref targe complexity. Later, the lack of security in RSVP was also recognized <xref target
t="RFC4094" format="default"/>).</t> ="RFC4094" format="default"/>.</t>
<t>The NSIS Working Group was chartered to tackle those issues and initi <t>The NSIS Working Group was chartered to tackle those issues and initi
ally focused on QoS signaling as its primary use case. However, over time a new ally focused on QoS signaling as its primary use case. However, over time a new
approach evolved that introduced a modular architecture using application-speci approach evolved that introduced a modular architecture using two application-sp
fic signaling protocols (the NSIS Signaling Layer Protocol (NSLP)) on top of a g ecific signaling protocols: a) the NSIS Signaling Layer Protocol (NSLP) on top o
eneric signaling transport protocol (the NSIS Transport Layer Protocol (NTLP)).< f b) a generic
/t> signaling transport protocol (the NSIS Transport Layer Protocol (NTLP)).
<t>The NTLP is defined in <xref target="RFC5971" format="default"/>. Two
NSLPs are defined: the NSIS Signaling Layer Protocol (NSLP) for Quality-of-Serv </t>
ice Signaling <xref target="RFC5974" format="default"/> as well as the NAT/Firew <t>NTLP is defined in <xref target="RFC5971" format="default"/>. Two typ
all NSIS Signaling Layer Protocol (NSLP) <xref target="RFC5973" format="default" es of NSLPs are defined: an NSLP for QoS signaling <xref target="RFC5974" format
/>.</t> ="default"/> and an NSLP for NATs/firewalls <xref target="RFC5973" format="defau
lt"/>.</t>
<section anchor="reasons-for-non-deployment-6" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-6" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>The obstacles for deployment can be grouped into implementation-rel ated aspects and operational aspects.</t> <t>The obstacles for deployment can be grouped into implementation-rel ated aspects and operational aspects.</t>
<ul spacing="normal">
<li>Implementation-related aspects:</li> <ul spacing="normal">
</ul> <li>
<t>Implementation-related aspects:</t>
<t>Although NSIS provides benefits <t>Although NSIS provides benefits
with respect to flexibility, mobility, and security compared to with respect to flexibility, mobility, and security compared to
other network signaling techniques, hardware vendors were reluctant other network signaling techniques, hardware vendors were reluctant
to deploy this solution, because it would require additional to deploy this solution, because it would require additional
implementation effort and would result in additional complexity for implementation effort and would result in additional complexity for
router implementations.</t> router implementations.</t>
<t>The NTLP mainly operates as path-coupled signaling protocol, i.e, <t>NTLP mainly operates as a path-coupled signaling protocol, i.e.,
its messages are processed at the intermediate node's control its messages are processed at the control plane of each intermediate node th
plane that are also forwarding the data flows. This requires a at is
also forwarding the data flows. This requires a
mechanism to intercept signaling packets while they are forwarded mechanism to intercept signaling packets while they are forwarded
in the same manner (especially along the same path) as data in the same manner (especially along the same path) as data
packets. NSIS uses packets. NSIS uses the
the IPv4 and IPv6 Router Alert Option (RAO) to allow for IPv4 and IPv6 Router Alert Option (RAO) to allow for
interception of those path-coupled signaling messages, and interception of those path-coupled signaling messages, and
this technique requires router implementations to correctly this technique requires router implementations to correctly
understand and implement the handling of RAOs, e.g., to only understand and implement the handling of RAOs, e.g., to only
process packet with RAOs of interest and to leave packets with process packets with RAOs of interest and to leave packets with
irrelevant RAOs in the fast forwarding processing path (a irrelevant RAOs in the fast forwarding processing path (a
comprehensive discussion of these issues can be found in comprehensive discussion of these issues can be found in
<xref target="RFC6398" format="default"/>). The latter was an issue with som e router <xref target="RFC6398" format="default"/>). The latter was an issue with som e router
implementations at the time of standardization.</t> implementations at the time of standardization.</t>
<t>Another reason is <t>Another reason is
that path-coupled signaling protocols that interact with routers that path-coupled signaling protocols that interact with routers
and request manipulation of state at these routers (or any and request manipulation of state at these routers (or any
other network element in general) are under scrutiny: a packet (or other network element in general) are under scrutiny: a packet (or
sequence of packets) out of the mainly untrusted data path is sequence of packets) out of the mainly untrusted data path is
requesting creation and manipulation of network state. This is requesting creation and manipulation of network state. This is
seen as potentially dangerous (e.g., opens up a Denial of Service (DoS) thre at to a seen as potentially dangerous (e.g., opens up a DoS threat to a
router's control plane) and difficult for an operator to control. router's control plane) and difficult for an operator to control.
Path-coupled signaling approaches were considered problematic (see also sect ion 3 of <xref target="RFC6398" format="default"/>). There are Path-coupled signaling approaches were considered problematic (see also <xre f target="RFC6398" sectionFormat="of" section="3"/>). There are
recommendations on how to secure NSIS nodes and recommendations on how to secure NSIS nodes and
deployments (e.g., <xref target="RFC5981" format="default"/>).</t> deployments (e.g., <xref target="RFC5981" format="default"/>).</t>
<ul spacing="normal"> </li>
<li>Operational Aspects:</li> </ul>
</ul> <ul spacing="normal">
<t>NSIS not only <li>
<t>Operational Aspects:</t>
<t>NSIS not only
required trust between customers and their provider, but also among required trust between customers and their provider, but also among
different providers. Especially, QoS signaling techniques would different providers. In particular, QoS signaling techniques would
require some kind of dynamic service level agreement support that require some kind of dynamic SLA support that
would imply (potentially quite complex) bilateral negotiations would imply (potentially quite complex) bilateral negotiations
between different Internet service providers. This complexity was between different Internet Service Providers. This complexity was
not considered to be justified and increasing the not considered to be justified, and increasing the
bandwidth (and thus avoiding bottlenecks) was bandwidth (and thus avoiding bottlenecks) was
cheaper than actively managing network resource bottlenecks by cheaper than actively managing network resource bottlenecks by
using path-coupled QoS signaling techniques. Furthermore, an using path-coupled QoS signaling techniques. Furthermore, an
end-to-end path typically involves several provider domains and end-to-end path typically involves several provider domains, and
these providers need to closely cooperate in cases of failures.</t> these providers need to closely cooperate in cases of failures.</t>
</li>
</ul>
</section> </section>
<section anchor="lessons-learned-6" numbered="true" toc="default"> <section anchor="lessons-learned-6" numbered="true" toc="default">
<name>Lessons Learned</name> <name>Lessons Learned</name>
<t>One goal of NSIS was to decrease the complexity of the signaling <t>One goal of NSIS was to decrease the complexity of the signaling
protocol, but a path-coupled signaling protocol comes with the protocol, but a path-coupled signaling protocol comes with the
intrinsic complexity of IP-based networks, beyond the complexity of the intrinsic complexity of IP-based networks, beyond the complexity of the
signaling protocol itself. Sources of intrinsic complexity include:</t> signaling protocol itself. Sources of intrinsic complexity include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the presence of asymmetric routes between endpoints and routers< <li>the presence of asymmetric routes between endpoints and routers.
/li> </li>
<li>the lack of security and trust at large in the Internet infrastr <li>the lack of security and trust at large in the Internet infrastr
ucture</li> ucture.</li>
<li>the presence of different trust boundaries</li> <li>the presence of different trust boundaries.</li>
<li>the effects of best-effort networks (e.g., robustness to packet <li>the effects of best-effort networks (e.g., robustness to packet
loss)</li> loss).</li>
<li>divergence from the fate sharing principle (e.g., state within t <li>divergence from the fate-sharing principle (e.g., state within t
he network).</li> he network).</li>
</ul> </ul>
<t>Any path-coupled signaling protocol has to deal with these realitie s.</t> <t>Any path-coupled signaling protocol has to deal with these realitie s.</t>
<t>Operators view the use of IPv4 and IPv6 Router Alert Option (RAO) t o signal routers along the path from end systems with suspicion, because these e nd systems are usually not authenticated and heavy use of RAOs can easily increa se the CPU load on routers that are designed to process most packets using a har dware "fast path" and diverting packets containing RAO to a slower, more capable processor.</t> <t>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 incr ease the CPU load on routers that are designed to process most packets using a h ardware "fast path" and diverting packets containing RAOs to a slower, more capa ble processor.</t>
</section> </section>
</section> </section>
<section anchor="FL" numbered="true" toc="default"> <section anchor="FL" numbered="true" toc="default">
<name>IPv6 Flow Label</name> <name>IPv6 Flow Labels</name>
<t>The suggested references for IPv6 Flow Label are:</t> <t>The suggested reference for IPv6 Flow Labels is:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>IPv6 Flow Label Specification <xref target="RFC6437" format="defau lt"/></li> <li>"<xref target="RFC6437" format="title"/>" <xref target="RFC6437" for mat="default"/></li>
</ul> </ul>
<t>IPv6 specifies a 20-bit field Flow Label field <xref target="RFC6437" <t>IPv6 specifies a 20-bit Flow Label field <xref target="RFC6437" forma
format="default"/>, included in the fixed part of the IPv6 header and hence pre t="default"/>, included in the fixed part of the IPv6 header and hence present i
sent in every IPv6 packet. An endpoint sets the value in this field to one of a n every IPv6 packet. An endpoint sets the value in this field to one of a set o
set of pseudo-randomly assigned values. If a packet is not part of any flow, th f pseudorandomly assigned values. If a packet is not part of any flow, the flow
e flow label value is set to zero <xref target="RFC3697" format="default"/>. A n label value is set to zero <xref target="RFC3697" format="default"/>. A number o
umber of Standards Track and Best Current Practice RFCs (e.g., <xref target="RFC f Standards Track and Best Current Practice RFCs (e.g., <xref target="RFC8085" f
8085" format="default"/>, <xref target="RFC6437" format="default"/>, <xref targe ormat="default"/>, <xref target="RFC6437" format="default"/>, <xref target="RFC6
t="RFC6438" format="default"/>) encourage IPv6 endpoints to set a non-zero value 438" format="default"/>) encourage IPv6 endpoints to set a non-zero value in thi
in this field. A multiplexing transport could choose to use multiple flow labe s field. A multiplexing transport could choose to use multiple flow labels to al
ls to allow the network to independently forward its subflows, or to use one com low the network to either independently forward its subflows or use one common v
mon value for the traffic aggregate. The flow label is present in all fragments alue for the traffic aggregate. The flow label is present in all fragments. IPse
. IPsec was originally put forward as one important use-case for this mechanism c was originally put forward as one important use case for this mechanism and do
and does encrypt the field <xref target="RFC6438" format="default"/>.</t> es encrypt the field <xref target="RFC6438" format="default"/>.</t>
<t>Once set, the flow label can provide information that can help inform <t>Once set, the flow label can provide information that can help inform
network nodes about subflows present at the transport layer, without needing to network nodes about subflows present at the transport layer, without needing to
interpret the setting of upper layer protocol fields <xref target="RFC6294" for interpret the setting of upper-layer protocol fields <xref target="RFC6294" for
mat="default"/>. This information can also be used to coordinate how aggregates mat="default"/>. This information can also be used to coordinate how aggregates
of transport subflows are grouped when queued in the network and to select appr of transport subflows are grouped when queued in the network and to select appr
opriate per-flow forwarding when choosing between alternate paths <xref target=" opriate per-flow forwarding when choosing between alternate paths <xref target="
RFC6438" format="default"/> (e.g. for Equal Cost Multipath Routing (ECMP) and Li RFC6438" format="default"/> (e.g., for Equal-Cost Multipath (ECMP) routing and L
nk Aggregation (LAG)).</t> ink Aggregation Groups (LAGs)).</t>
<section anchor="reasons-for-non-deployment-7" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-7" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>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:</t> <t>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:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Endpoint Implementation:</li> <li>
</ul> <t>Endpoint Implementation:</t>
<t>For network nodes along a path to utilize the flow label there need <t>For network nodes along a path to utilize the flow label, there nee
s to be a non-zero value inserted in the field <xref target="RFC6437" format="de ds to be a non-zero value inserted in the field <xref target="RFC6437" format="d
fault"/> at the sending endpoint. efault"/> at the sending endpoint.
There needs to be an incentive for an endpoint to set an appropriate non-zero va lue. There needs to be an incentive for an endpoint to set an appropriate non-zero va lue.
The value should appropriately reflect the level of aggregation the traffic expe The value should appropriately reflect the level of aggregation the traffic expe
cts to be provided by the network. However, this requires the stack to know gra cts to be provided by the network. However, this requires the stack to know gra
nularity at which flows should be identified (or conversely which flows should r nularity at which flows should be identified (or, conversely, which flows should
eceive aggregated treatment), i.e., which packets carry the same flow label. The receive aggregated treatment), i.e., which packets carry the same flow label. T
refore, setting a non-zero value may result in additional choices that need to b herefore, setting a non-zero value may result in additional choices that need to
e made by an application developer.</t> be made by an application developer.</t>
<t>Although the standard <xref target="RFC3697" format="default"/> for <t>Although the original flow label standard <xref target="RFC3697" fo
bids any encoding of meaning into the flow label value, the opportunity to use t rmat="default"/> forbids any encoding of meaning into the flow label value, the
he flow label as a covert channel or to signal other meta-information may have r opportunity to use the flow label as a covert channel or to signal other meta-in
aised concerns about setting a non-zero value <xref target="RFC6437" format="def formation may have raised concerns about setting a non-zero value <xref target="
ault"/>.</t> RFC6437" format="default"/>.</t>
<t>Before methods are widely deployed to use this method, there could be no incentive for an endpoint to set the field.</t> <t>Before methods are widely deployed to use this method, there could be no incentive for an endpoint to set the field.</t>
</li>
</ul>
<ul spacing="normal"> <ul spacing="normal">
<li>Operational support in network nodes:</li> <li>
</ul> <t>Operational support in network nodes:</t>
<t>A benefit can only be realized when a network node along the path a <t>A benefit can only be realized when a network node along the path a
lso uses this information to inform its decisions. Network equipment (routers a lso uses this information to inform its decisions. Network equipment (routers an
nd/or middleboxes) need to include appropriate support so they can utilize the f d/or middleboxes) need to include appropriate support in order to utilize the fi
ield when making decisions about how to classify flows, or to inform forwarding eld when making decisions about how to classify flows or forward packets. The us
choices. Use of any optional feature in a network node also requires correspondi e of any optional feature in a network node also requires corresponding updates
ng updates to operational procedures, and therefore is normally only introduced to operational procedures and therefore is normally only introduced when the cos
when the cost can be justified.</t> t can be justified.</t>
<t>A benefit from utilizing the flow label is expected to be increased <t>A benefit from utilizing the flow label is expected to be increased
quality of experience for applications - but this comes at some operational cos quality of experience for applications -- but this comes at some operational co
t to an operator, and requires endpoints to set the field.</t> st to an operator and requires endpoints to set the field.</t>
</li>
</ul>
</section> </section>
<section anchor="lessons-learned-7" numbered="true" toc="default"> <section anchor="lessons-learned-7" numbered="true" toc="default">
<name>Lessons Learned</name> <name>Lessons Learned</name>
<t>The flow label is a general purpose header field for use by the pat <t>The flow label is a general-purpose header field for use by the pat
h. Multiple uses have been proposed. One candidate use was to reduce the comple h. Multiple uses have been proposed. One candidate use was to reduce the comple
xity of forwarding decisions. However, modern routers can use a "fast path", of xity of forwarding decisions. However, modern routers can use a "fast path", of
ten taking advantage of hardware to accelerate processing. The method can assist ten taking advantage of hardware to accelerate processing. The method can assist
in more complex forwarding, such as ECMP and load balancing.</t> in more complex forwarding, such as ECMP routing and load balancing.</t>
<t>Although <xref target="RFC6437" format="default"/> recommended that <t>Although <xref target="RFC6437" format="default"/> recommended that
endpoints should by default choose uniformly-distributed labels for their traff endpoints should by default choose uniformly distributed labels for their traff
ic, the specification permitted an endpoint to choose to set a zero value. This ic, 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 ability of endpoints to choose to set a flow label of zero has had consequences
on deployability:</t> on deployability:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Before wide-scale support by endpoints, it would be impossible t o 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 m ethod is one assuming semantics of the source port field to provide entropy inpu t to a network-layer hash. This use of a 5-tuple to classify a packet represents a layering violation <xref target="RFC6294" format="default"/>. When other meth ods have been deployed, they increase the cost of deploying standards-based meth ods, even though they may offer less control to endpoints and result in potenti al interaction with other uses/interpretation of the field.</li> <li>Before wide-scale support by endpoints, it would be impossible t o 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 m ethod is one assuming semantics of the source port field to provide entropy inpu t to a network-layer hash. This use of a 5-tuple to classify a packet represents a layering violation <xref target="RFC6294" format="default"/>. When other meth ods have been deployed, they increase the cost of deploying standards-based meth ods, even though they may offer less control to endpoints and result in potenti al interaction with other uses/interpretation of the field.</li>
<li>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 labe l. This could result from non-conformant equipment, or could indicate that some operational networks have chosen to re-use the protocol field for other (e.g. in ternal 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 ne twork. The more recent practice of "greasing" <xref target="GREASE" format="def ault"/> would suggest that a different outcome could have been achieved if endpo ints were always required to set a non-zero value.</li> <li>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 labe l. This could result from non-conformant equipment or could indicate that some o perational networks have chosen to reuse the protocol field for other (e.g., int ernal) purposes. This results in lack of transparency, and a deployment hurdle t o endpoints expecting that they can set a flow label that is utilized by the net work. The more recent practice of "greasing" <xref target="I-D.iab-use-it-or-lo se-it" format="default"/> would suggest that a different outcome could have been achieved if endpoints were always required to set a non-zero value.</li>
<li> <li>
<xref target="RFC1809" format="default"/> noted that setting the c hoice of the flow label value can depend on the expectations of the traffic gene rated by an application, which suggests an API should be presented to control th e setting or policy that is used. However, many currently available APIs do not have this support.</li> <xref target="RFC1809" format="default"/> noted that setting the c hoice of the flow label value can depend on the expectations of the traffic gene rated by an application, which suggests that an API should be presented to contr ol the setting or policy that is used. However, many currently available APIs do not have this support.</li>
</ul> </ul>
<t>A growth in the use of encrypted transports, (e.g. QUIC <xref targe <t>A growth in the use of encrypted transports (e.g., QUIC <xref targe
t="QUIC-WG" format="default"/>) seems likely to raise similar issues to those di t="RFC9000"/>) seems likely to raise issues similar to those discussed above and
scussed above and could motivate renewed interest in utilizing the flow label.</ could motivate renewed interest in utilizing the flow label.
t> </t>
</section> </section>
</section> </section>
<section anchor="ecn" numbered="true" toc="default"> <section anchor="ecn" numbered="true" toc="default">
<name>Explicit Congestion Notification (ECN)</name> <name>Explicit Congestion Notification (ECN)</name>
<t>The suggested references for Explicit Congestion Notification (ECN) a re:</t> <t>The suggested references for Explicit Congestion Notification (ECN) a re:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Recommendations on Queue Management and Congestion Avoidance in th <li>"<xref target="RFC2309" format="title"/>" <xref target="RFC2309" f
e Internet <xref target="RFC2309" format="default"/></li> ormat="default"/></li>
<li>A Proposal to add Explicit Congestion Notification (ECN) to IP <xr <li>"<xref target="RFC2481" format="title"/>" <xref target="RFC2481" f
ef target="RFC2481" format="default"/></li> ormat="default"/></li>
<li>The Addition of Explicit Congestion Notification (ECN) to IP <xref <li>"<xref target="RFC3168" format="title"/>" <xref target="RFC3168" f
target="RFC3168" format="default"/></li> ormat="default"/></li>
<li>Implementation Report on Experiences with Various TCP RFCs <xref t <li>"Implementation Report on Experiences with Various TCP RFCs" <xref
arget="vista-impl" format="default"/>, slides 6 and 7</li> target="vista-impl" format="default"/>, slides 6 and 7</li>
<li>Implementation and Deployment of ECN <xref target="SallyFloyd" for <li>"Implementation and Deployment of ECN" (at <xref target="SallyFloy
mat="default"/></li> d" format="default"/>)</li>
</ul> </ul>
<t>In the early 1990s, the large majority of Internet traffic used TCP a <t>In the early 1990s, the large majority of Internet traffic used TCP a
s its transport protocol, but TCP had no way to detect path congestion before th s its transport protocol, but TCP had no way to detect path congestion before th
e path was so congested that packets were being dropped, and these congestion ev e path was so congested that packets were being dropped. These congestion events
ents could affect all senders using a path, either by "lockout", where long-live could affect all senders using a path, either by "lockout", where long-lived fl
d flows monopolized the queues along a path, or by "full queues", where queues r ows monopolized the queues along a path, or by "full queues", where queues remai
emain full, or almost full, for a long period of time.</t> n full, or almost full, for a long period of time.</t>
<t>In response to this situation, "Active Queue Management" (AQM) was de <t>In response to this situation, "Active Queue Management" (AQM) was de
ployed in the network. A number of AQM disciplines have been deployed, but one c ployed in the network. A number of AQM disciplines have been deployed, but one c
ommon approach was that routers dropped packets when a threshold buffer length w ommon approach was that routers dropped packets when a threshold buffer length w
as reached, so that transport protocols like TCP that were responsive to loss wo as reached, so that transport protocols like TCP that were responsive to loss wo
uld detect this loss and reduce their sending rates. Random Early Detection (RED uld 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 ) 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 threshol its AQM discipline that detected time-averaged queue lengths passing a threshol
d would choose incoming packets probabilistically to be dropped <xref target="RF d would choose incoming packets probabilistically to be dropped <xref target="RF
C2309" format="default"/>. C2309" format="default"/>.</t>
In response to this situation, "Active Queue Management" (AQM) was deployed in t <t>Researchers suggested providing "explicit congestion notifications" t
he network. A number of AQM disciplines have been deployed, but one common appro o senders when routers along the path detected that their queues were building,
ach was that routers dropped packets when a threshold buffer length was reached, giving senders an opportunity to "slow down" as if a loss had occurred, giving p
so that transport protocols like TCP that were responsive to loss would detect ath queues time to drain, while the path still had sufficient buffer capacity to
this loss and reduce their sending rates. Random Early Detection (RED) was one s accommodate bursty arrivals of packets from other senders. This was proposed as
uch proposal in the IETF. As the name suggests, a router using RED as its AQM di an experiment in <xref target="RFC2481" format="default"/> and standardized in
scipline that detected time-averaged queue lengths passing a threshold would cho <xref target="RFC3168" format="default"/>.</t>
ose incoming packets probabilistically to be dropped <xref target="RFC2309" form
at="default"/>.</t>
<t>Researchers suggested that providing "explicit congestion notificatio
ns" to senders when routers along the path detected their queues were building,
so that some senders would "slow down" as if a loss had occurred, so that the pa
th queues had time to drain, and the path still had sufficient buffer capacity t
o accommodate bursty arrivals of packets from other senders. This was proposed a
s an Experiment in <xref target="RFC2481" format="default"/>, and standardized i
n <xref target="RFC3168" format="default"/>.</t>
<t>A key aspect of ECN was the use of IP header fields rather than IP op tions to carry explicit congestion notifications, since the proponents recognize d that</t> <t>A key aspect of ECN was the use of IP header fields rather than IP op tions to carry explicit congestion notifications, since the proponents recognize d that</t>
<ul empty="true" spacing="normal"> <!-- DNE (too short for blockquote) -->
<li>Many routers process the "regular" headers in IP packets more <t indent="3">
Many routers process the "regular" headers in IP packets more
efficiently than they process the header information in IP efficiently than they process the header information in IP
options.</li> options.</t>
</ul> <t>Unlike most of the Path Aware technologies included in this document,
<t>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
the story of ECN continues to the present day, and encountered a large number o Lessons Learned during that time. The early history of ECN (non-)deployment pro
f Lessons Learned during that time. The early history of ECN (non-)deployment pr vides Lessons Learned that were not captured by other contributions in <xref tar
ovides Lessons Learned that were not captured by other contributions in <xref ta get="Contributions" format="default"/>, so that is the emphasis in this section
rget="Contributions" format="default"/>, so that is the emphasis in this section of the document.</t>
of the document.</t>
<section anchor="reasons-for-non-deployment-8" numbered="true" toc="defa ult"> <section anchor="reasons-for-non-deployment-8" numbered="true" toc="defa ult">
<name>Reasons for Non-deployment</name> <name>Reasons for Non-deployment</name>
<t>There are at least three sub-stories - ECN deployment in clients, E <t>ECN deployment relied on three factors -- support in client impleme
CN deployment in routers, and AQM deployment in operational networks. All three ntations, support in router implementations, and deployment decisions in operati
sub-stories mattered.</t> onal networks.</t>
<t>The proponents of ECN did so much right, anticipating many of the L <t>The proponents of ECN did so much right, anticipating many of the L
essons Learned now recognized in <xref target="LessonsLearned" format="default"/ essons Learned now recognized in <xref target="LessonsLearned" format="default"/
>. They recognized the need to support incremental deployment (<xref target="Ear >. They recognized the need to support incremental deployment (<xref target="Ear
lyAdopters" format="default"/>). They considered the impact on router throughput lyAdopters" format="default"/>). They considered the impact on router throughput
(<xref target="Fast-paths" format="default"/>). They even considered trust issu (<xref target="Fast-paths" format="default"/>). They even considered trust issu
es between end nodes and the network, both for non-compliant end nodes (<xref ta es between end nodes and the network, for both non-compliant end nodes (<xref ta
rget="IDsTrustingEndpoints" format="default"/>) and non-compliant routers (<xref rget="IDsTrustingEndpoints" format="default"/>) and non-compliant routers (<xref
target="EndpointsTrustingIDs" format="default"/>).</t> target="EndpointsTrustingIDs" format="default"/>).</t>
<t>They were rewarded with ECN being implemented in major operating sy <t>They were rewarded with ECN being implemented in major operating sy
stems, both for end nodes and for routers. A number of implementations are liste stems, for both end nodes and routers. A number of implementations are listed un
d under "Implementation and Deployment of ECN" at <xref target="SallyFloyd" form der "Implementation and Deployment of ECN" at <xref target="SallyFloyd" format="
at="default"/>.</t> default"/>.</t>
<t>What they did not anticipate, was routers that would crash, when th <t>What they did not anticipate was routers that would crash when they
ey saw bits 6 and 7 in the IPv4 TOS octet <xref target="RFC0791" format="default saw bits 6 and 7 in the IPv4 Type of Service (TOS) octet <xref target="RFC0791"
"/>/IPv6 Traffic Class field <xref target="RFC2460" format="default"/>, which <x format="default"/> / IPv6 Traffic Class field <xref target="RFC2460" format="de
ref target="RFC2481" format="default"/> redefined to be "currently unused", bein fault"/>, which <xref target="RFC2481" format="default"/> redefined to be "Curre
g set to a non-zero value.</t> ntly Unused", being set to a non-zero value.</t>
<t>As described in <xref target="vista-impl" format="default"/>,</t> <t>As described in <xref target="vista-impl" format="default"/> ("IGD"
<ul empty="true" spacing="normal"> stands for "Intermediate Gateway Device"),</t>
<li>Intermediate Gateway Device problem #1: one of the most popular <!-- DNE -->
versions from one of the most popular vendors. <blockquote>
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 E CN capability negotiation) indicated, router crashed. When a data packet arrives with either ECT(0) or ECT(1) (indicating successful E CN capability negotiation) indicated, router crashed.
Cannot be recovered at TCP layer (sic)</li> Cannot be recovered at TCP layer [sic]
</ul> </blockquote>
<t>This implementation, which would be run on a significant percentage <t>This implementation, which would be run on a significant percentage
of Internet end nodes, was shipped with ECN disabled, as was true for several o of Internet end nodes, was shipped with ECN disabled, as was true for several o
f the other implementations listed under "Implementation and Deployment of ECN" f the other implementations listed under "Implementation and Deployment of ECN"
at <xref target="SallyFloyd" format="default"/>. Even if subsequent router vendo at <xref target="SallyFloyd" format="default"/>. Even if subsequent router vendo
rs fixed these implementations, ECN was still disabled on end nodes, and given t rs fixed these implementations, ECN was still disabled on end nodes, and given t
he tradeoff between the benefits of enabling ECN (somewhat better behavior durin he trade-off between the benefits of enabling ECN (somewhat better behavior duri
g congestion) and the risks of enabling ECN (possibly crashing a router somewher ng congestion) and the risks of enabling ECN (possibly crashing a router somewhe
e along the path), ECN tended to stay disabled on implementations that supported re along the path), ECN tended to stay disabled on implementations that supporte
ECN for decades afterwards.</t> d ECN for decades afterwards.</t>
</section> </section>
<section anchor="lessons-learned-8" numbered="true" toc="default"> <section anchor="lessons-learned-8" numbered="true" toc="default">
<name>Lessons Learned</name> <name>Lessons Learned</name>
<t>Of the contributions included in <xref target="Contributions" forma t="default"/>, ECN may be unique in providing these lessons:</t> <t>Of the contributions included in <xref target="Contributions" forma t="default"/>, ECN may be unique in providing these lessons:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Even if you do everything right, you may trip over implementatio n bugs in devices you know nothing about, that will cause severe problems that p revent successful deployment of your path aware technology.</li> <li>Even if you do everything right, you may trip over implementatio n bugs in devices you know nothing about, that will cause severe problems that p revent successful deployment of your Path Aware technology.</li>
<li>After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by defaul t.</li> <li>After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by defaul t.</li>
</ul> </ul>
<t>These two lessons, taken together, could be summarized as "you get <t>These two lessons, taken together, could be summarized as "you get
one chance to get it right".</t> one chance to get it right."</t>
<t>During discussion of ECN at <xref target="PANRG-110" format="defaul <t>During discussion of ECN at <xref target="PANRG-110" format="defaul
t"/>, we noted that "you get one chance to get it right" isn't quite correct tod t"/>, we noted that "you get one chance to get it right" isn't quite correct tod
ay, because operating systems on so many host systems are frequently updated, an ay, because operating systems on so many host systems are frequently updated, an
d transport protocols like QUIC <xref target="I-D.ietf-quic-transport" format="d d transport protocols like QUIC <xref target="RFC9000" format="default"/> are be
efault"/> are being implemented in user space, and can be updated without touchi ing implemented in user space and can be updated without touching installed oper
ng installed operating systems. Neither of these factors were true in the early ating systems. Neither of these factors were true in the early 2000s.</t>
2000s.</t>
<t>We think that these restatements of the ECN Lessons Learned are mor e useful for current implementers:</t> <t>We think that these restatements of the ECN Lessons Learned are mor e useful for current implementers:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Even if you do everything right, you may trip over implementatio <li>Even if you do everything right, you may trip over implementatio
n bugs in devices you know nothing about, that will cause severe problems that p n bugs in devices you know nothing about, that will cause severe problems that p
revent successful deployment of your path aware technology. Testing before deplo revent successful deployment of your Path Aware technology. Testing before deplo
yment isn't enough to ensure successful deployment. It is also necessary to "dep yment isn't enough to ensure successful deployment. It is also necessary to "dep
loy gently", which often means deploying for a small subset of users to gain exp loy gently", which often means deploying for a small subset of users to gain exp
erience, and implementing feedback mechanisms to detect that user experience is erience and implementing feedback mechanisms to detect that user experience is b
being degraded.</li> eing degraded.</li>
<li>After implementations disable your Path Aware technology, it may <li>After implementations disable your Path Aware technology, it may
take years, or even decades, to convince implementers to re-enable it by defaul take years, or even decades, to convince implementers to re-enable it by defaul
t. This might be based on the difficulty of distributing implementations that en t. This might be based on the difficulty of distributing implementations that en
able it by default, but are just as likely to be based on the "bad taste in the able it by default, but it is just as likely to be based on the "bad taste in th
mouth" that implementers have after an unsuccessful deployment attempt that degr e mouth" that implementers have after an unsuccessful deployment attempt that de
aded user experience.</li> graded user experience.</li>
</ul> </ul>
<t>With these expansions, the two lessons, taken together, could be mo re helpfully summarized as "plan for failure" - anticipate what your next step w ill be, if initial deployment is unsuccessful.</t> <t>With these expansions, the two lessons, taken together, could be mo re helpfully summarized as "plan for failure" -- anticipate what your next step will be, if initial deployment is unsuccessful.</t>
<t>ECN deployment was also hindered by non-deployment of AQM in many d evices, because of operator interest in QoS features provided in the network, ra ther than using the network to assist end systems in providing for themselves. B ut that's another story, and the AQM Lessons Learned are already covered in othe r contributions in <xref target="Contributions" format="default"/>.</t> <t>ECN deployment was also hindered by non-deployment of AQM in many d evices, because of operator interest in QoS features provided in the network, ra ther than using the network to assist end systems in providing for themselves. B ut that's another story, and the AQM Lessons Learned are already covered in othe r contributions in <xref target="Contributions" format="default"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>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 Inter net.</t> <t>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 Inter net.</t>
<t>If this document meets its goals, we may develop new techniques for Pat h 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.</t> <t>If this document meets its goals, we may develop new techniques for Pat h 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.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no requests of IANA.</t> <t>This document has no IANA actions.</t>
</section>
<section anchor="acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name>
<t>Initial material for <xref target="ST2" format="default"/> on ST2 was p
rovided by Gorry Fairhurst.</t>
<t>Initial material for <xref target="IntServ" format="default"/> on IntSe
rv was provided by Ron Bonica.</t>
<t>Initial material for <xref target="Quick-Start" format="default"/> on Q
uick-Start TCP was provided by Michael Scharf, who also provided suggestions to
improve this section after it was edited.</t>
<t>Initial material for <xref target="Source-Quench" format="default"/> on
ICMP Source Quench was provided by Gorry Fairhurst.</t>
<t>Initial material for <xref target="TRIGTRAN" format="default"/> on Trig
gers for Transport (TRIGTRAN) was provided by Spencer Dawkins.</t>
<t><xref target="Shim6" format="default"/> on Shim6 builds on initial mate
rial describing obstacles provided by Erik Nordmark, with background added by Sp
encer Dawkins.</t>
<t>Initial material for <xref target="NSIS" format="default"/> on Next Ste
ps In Signaling (NSIS) was provided by Roland Bless and Martin Stiemerling.</t>
<t>Initial material for <xref target="FL" format="default"/> on IPv6 Flow
Labels was provided by Gorry Fairhurst.</t>
<t>Initial material for <xref target="ecn" format="default"/> on Explicit
Congestion Notification was provided by Spencer Dawkins.</t>
<t>Our thanks to Adrian Farrel, Bob Briscoe, C.M. Heard, David Black, Eric
Kinnear, Erik Auerswald, Gorry Fairhurst, Jake Holland, Joe Touch, Joeri de Rui
ter, Kireeti Kompella, Mohamed Boucadair, Roland Bless, Ruediger Geib, Theresa E
nghardt, and Wes Eddy, who provided review comments on this document as a "work
in process".</t>
<t>Mallory Knodel reviewed this document for the Internet Research Steerin
g Group, and provided many helpful suggestions.</t>
<t>David Oran also provided helpful comments and text suggestions on this
document during Internet Research Steering Group balloting. In particular, <xref
target="Futures" format="default"/> reflects his review.</t>
<t>Benjamin Kaduk and Rob Wilton provided helpful comments during Internet
Engineering Steering Group conflict review.</t>
<t>Special thanks to Adrian Farrel for helping Spencer 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 <xref target="Colossal-Cave"
format="default"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.irtf-panrg-questions" to="PANRG-QUESTIONS"/>
<displayreference target="I-D.irtf-panrg-path-properties" to="PANRG-PATH-PROPERT
IES"/>
<displayreference target="I-D.ietf-tsvwg-intserv-multiple-tspec" to="INTSERV-MUL
TIPLE-TSPEC"/>
<displayreference target="I-D.arkko-arch-internet-threat-model" to="INTERNET-THR
EAT-MODEL"/>
<displayreference target="I-D.farrell-etm" to="FARRELL-ETM"/>
<displayreference target="I-D.iab-use-it-or-lose-it" to="GREASE"/>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.irtf-panrg-questions" target="http://www.ietf.org/i
nternet-drafts/draft-irtf-panrg-questions-08.txt"> <!-- draft-irtf-panrg-questions (I-D Exists) -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-pa
<title>Current Open Questions in Path Aware Networking</title> nrg-questions.xml"/>
<seriesInfo name="Internet-Draft" value="draft-irtf-panrg-questions-08
"/> <!-- draft-irtf-panrg-path-properties (I-D Exists) -->
<author initials="B" surname="Trammell" fullname="Brian Trammell"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-pa
<organization/> nrg-path-properties.xml"/>
</author>
<date month="December" day="23" year="2020"/> <!-- draft-ietf-tsvwg-intserv-multiple-tspec (Expired) -->
<abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ts
<t>In contrast to the present Internet architecture, a path-aware in vwg-intserv-multiple-tspec.xml"/>
ternetworking architecture has two important properties: it exposes the properti
es of available Internet paths to endpoints, and provides for endpoints and appl <!-- draft-arkko-arch-internet-threat-model (Expired) -->
ications to use these properties to select paths through the Internet for their <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.arkko-a
traffic. While this property of "path awareness" already exists in many Interne rch-internet-threat-model.xml"/>
t-connected networks within single domains and via administrative interfaces to
the network layer, a fully path-aware internetwork expands these concepts across <!-- draft-farrell-etm (Replaced by draft-arkko-farrell-arch-model-t) (Expired)
layers and across the Internet. This document poses questions in path-aware ne HOWEVER - draft-farrell-etm is cited by [SAAG-105-Min] (Section 3), so we
tworking open as of 2021, that must be answered in the design, development, and have to keep the old listing -->
deployment of path-aware internetworks. It was originally written to frame disc <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.farrell
ussions in the Path Aware Networking proposed Research Group (PANRG), and has be -etm.xml"/>
en published to snapshot current thinking in this space.</t>
</abstract> <!-- draft-ietf-quic-transport (RFC 9000 / Published May 2021) -->
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
</reference> xml"/>
<reference anchor="I-D.irtf-panrg-path-properties" target="http://www.ietf
.org/internet-drafts/draft-irtf-panrg-path-properties-01.txt"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.
<front> xml"/>
<title>A Vocabulary of Path Properties</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.
<seriesInfo name="Internet-Draft" value="draft-irtf-panrg-path-propert xml"/>
ies-01"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.
<author initials="T" surname="Enghardt" fullname="Theresa Enghardt"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1016.
</author> xml"/>
<author initials="C" surname="Krahenbuhl" fullname="Cyrill Krahenbuhl" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.
> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1190.
</author> xml"/>
<date month="September" day="7" year="2020"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1633.
<abstract> xml"/>
<t>Path properties express information about paths across a network <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1809.
and the services provided via such paths. In a path-aware network, path propert xml"/>
ies may be fully or partially available to entities such as hosts. This documen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1819.
t defines and categorizes path properties. Furthermore, the document specifies s xml"/>
everal path properties which might be useful to hosts or other entities, e.g., f <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1887.
or selecting between paths or for invoking some of the provided services.</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2001.
</front> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2205.
<reference anchor="I-D.ietf-tsvwg-intserv-multiple-tspec" target="http://w xml"/>
ww.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-02.txt"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2210.
<front> xml"/>
<title>Integrated Services (IntServ) Extension to Allow Signaling of M <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2211.
ultiple Traffic Specifications and Multiple Flow Specifications in RSVPv1</title xml"/>
> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2212.
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-intserv-mult xml"/>
iple-tspec-02"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2215.
<author initials="J" surname="Polk" fullname="James Polk"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2309.
</author> xml"/>
<author initials="S" surname="Dhesikan" fullname="Subha Dhesikan"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2481.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2460.
<date month="February" day="25" year="2013"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2475.
<t>This document defines extensions to Integrated Services (IntServ) xml"/>
allowing multiple traffic specifications and multiple flow specifications to b <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.
e conveyed in the same Resource Reservation Protocol (RSVPv1) reservation messag xml"/>
e exchange. This ability helps optimize an agreeable bandwidth through a network <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3697.
between endpoints in a single round trip.</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4094.
</front> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.
<reference anchor="I-D.arkko-arch-internet-threat-model" target="http://ww xml"/>
w.ietf.org/internet-drafts/draft-arkko-arch-internet-threat-model-01.txt"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4782.
<front> xml"/>
<title>Changes in the Internet Threat Model</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5082.
<seriesInfo name="Internet-Draft" value="draft-arkko-arch-internet-thr xml"/>
eat-model-01"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5218.
<author initials="J" surname="Arkko" fullname="Jari Arkko"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5533.
</author> xml"/>
<date month="July" day="8" year="2019"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5575.
<abstract> xml"/>
<t>Communications security has been at the center of many security i <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.
mprovements in the Internet. The goal has been to ensure that communications ar xml"/>
e protected against outside observers and attackers. This memo suggests that th <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5971.
e existing threat model, while important and still valid, is no longer alone suf xml"/>
ficient to cater for the pressing security issues in the Internet. For instance <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5973.
, it is also necessary to protect systems against endpoints that are compromised xml"/>
, malicious, or whose interests simply do not align with the interests of the us <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5974.
ers. While such protection is difficult, there are some measures that can be ta xml"/>
ken. It is particularly important to ensure that as we continue to develop Inte <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5981.
rnet technology, non-communications security related threats are properly unders xml"/>
tood. While the consideration of these issues is relatively new in the IETF, th <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6294.
is memo provides some initial ideas about potential broader threat models to con xml"/>
sider when designing protocols for the Internet or when trying to defend against <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6398.
pervasive monitoring. Further down the road, updated threat models could resul xml"/>
t in changes in RFC 3552 (guidelines for writing security considerations) and RF <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6437.
C 7258 (pervasive monitoring), to include proper consideration of non-communicat xml"/>
ions security threats. It may also be necessary to have dedicated guidance on h <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6438.
ow systems design and architecture affects security.</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6633.
</front> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6928.
<reference anchor="I-D.farrell-etm" target="http://www.ietf.org/internet-d xml"/>
rafts/draft-farrell-etm-03.txt"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7305.
<front> xml"/>
<title>We're gonna need a bigger threat model</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7418.
<seriesInfo name="Internet-Draft" value="draft-farrell-etm-03"/> xml"/>
<author initials="S" surname="Farrell" fullname="Stephen Farrell"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8170.
<date month="July" day="6" year="2019"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.
<t>We argue that an expanded threat model is needed for Internet pro xml"/>
tocol development as protocol endpoints can no longer be considered to be genera <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8793.
lly trustworthy for any general definition of "trustworthy."</t> xml"/>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-quic-transport" target="http://www.ietf.org/in
ternet-drafts/draft-ietf-quic-transport-34.txt">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34"
/>
<author initials="J" surname="Iyengar" fullname="Jana Iyengar">
<organization/>
</author>
<author initials="M" surname="Thomson" fullname="Martin Thomson">
<organization/>
</author>
<date month="January" day="14" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol. Q
UIC provides applications with flow-controlled streams for structured communicat
ion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the in
tegration of TLS for key negotiation, loss detection, and an exemplary congestio
n control algorithm. DO NOT DEPLOY THIS VERSION OF QUIC DO NOT DEPLOY THIS VER
SION OF QUIC UNTIL IT IS IN AN RFC. This version is still a work in progress.
For trial deployments, please use earlier versions. Note to Readers Discussion
of this draft takes place on the QUIC working group mailing list (quic@ietf.org
(mailto:quic@ietf.org)), which is archived at https://mailarchive.ietf.org/arch
/search/?email_list=quic Working Group information can be found at https://gith
ub.com/quicwg; source code and issues list for this draft can be found at https:
//github.com/quicwg/base-drafts/labels/-transport.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791
">
<front>
<title>Internet Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="STD" value="5"/>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1981" month="September"/>
</front>
</reference>
<reference anchor="RFC0792" target="https://www.rfc-editor.org/info/rfc792
">
<front>
<title>Internet Control Message Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC0792"/>
<seriesInfo name="RFC" value="792"/>
<seriesInfo name="STD" value="5"/>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1981" month="September"/>
</front>
</reference>
<reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793
">
<front>
<title>Transmission Control Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC0793"/>
<seriesInfo name="RFC" value="793"/>
<seriesInfo name="STD" value="7"/>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1981" month="September"/>
</front>
</reference>
<reference anchor="RFC1016" target="https://www.rfc-editor.org/info/rfc101
6">
<front>
<title>Something a Host Could Do with Source Quench: The Source Quench
Introduced Delay (SQuID)</title>
<seriesInfo name="DOI" value="10.17487/RFC1016"/>
<seriesInfo name="RFC" value="1016"/>
<author initials="W." surname="Prue" fullname="W. Prue">
<organization/>
</author>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1987" month="July"/>
<abstract>
<t>The memo is intended to explore the issue of what a host could do
with a source quench. The proposal is for each source host IP module to introd
uce some delay between datagrams sent to the same destination host. This is a "
crazy idea paper" and discussion is essential.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1122" target="https://www.rfc-editor.org/info/rfc112
2">
<front>
<title>Requirements for Internet Hosts - Communication Layers</title>
<seriesInfo name="DOI" value="10.17487/RFC1122"/>
<seriesInfo name="RFC" value="1122"/>
<seriesInfo name="STD" value="3"/>
<author initials="R." surname="Braden" fullname="R. Braden" role="edit
or">
<organization/>
</author>
<date year="1989" month="October"/>
<abstract>
<t>This RFC is an official specification for the Internet community.
It incorporates by reference, amends, corrects, and supplements the primary pr
otocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1190" target="https://www.rfc-editor.org/info/rfc119
0">
<front>
<title>Experimental Internet Stream Protocol: Version 2 (ST-II)</title
>
<seriesInfo name="DOI" value="10.17487/RFC1190"/>
<seriesInfo name="RFC" value="1190"/>
<author initials="C." surname="Topolcic" fullname="C. Topolcic">
<organization/>
</author>
<date year="1990" month="October"/>
<abstract>
<t>This memo defines a revised version of the Internet Stream Protoc
ol, originally defined in IEN-119 [8], based on results from experiments with th
e original version, and subsequent requests, discussion, and suggestions for imp
rovements. This is a Limited-Use Experimental Protocol. Please refer to the cu
rrent edition of the "IAB Official Protocol Standards" for the standardization s
tate and status of this protocol.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1633" target="https://www.rfc-editor.org/info/rfc163
3">
<front>
<title>Integrated Services in the Internet Architecture: an Overview</
title>
<seriesInfo name="DOI" value="10.17487/RFC1633"/>
<seriesInfo name="RFC" value="1633"/>
<author initials="R." surname="Braden" fullname="R. Braden">
<organization/>
</author>
<author initials="D." surname="Clark" fullname="D. Clark">
<organization/>
</author>
<author initials="S." surname="Shenker" fullname="S. Shenker">
<organization/>
</author>
<date year="1994" month="June"/>
<abstract>
<t>This memo discusses a proposed extension to the Internet architec
ture and protocols to provide integrated services, i.e., to support real-time as
well as the current non-real-time service of IP. This memo provides informatio
n for the Internet community. This memo does not specify an Internet standard o
f any kind.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1809" target="https://www.rfc-editor.org/info/rfc180
9">
<front>
<title>Using the Flow Label Field in IPv6</title>
<seriesInfo name="DOI" value="10.17487/RFC1809"/>
<seriesInfo name="RFC" value="1809"/>
<author initials="C." surname="Partridge" fullname="C. Partridge">
<organization/>
</author>
<date year="1995" month="June"/>
<abstract>
<t>The purpose of this memo is to distill various opinions and sugge
stions of the End-to-End Research Group regarding the handling of Flow Labels in
to a set of suggestions for IPv6. This memo provides information for the Intern
et community. This memo does not specify an Internet standard of any kind.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1819" target="https://www.rfc-editor.org/info/rfc181
9">
<front>
<title>Internet Stream Protocol Version 2 (ST2) Protocol Specification
- Version ST2+</title>
<seriesInfo name="DOI" value="10.17487/RFC1819"/>
<seriesInfo name="RFC" value="1819"/>
<author initials="L." surname="Delgrossi" fullname="L. Delgrossi" role
="editor">
<organization/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger" role="edit
or">
<organization/>
</author>
<date year="1995" month="August"/>
<abstract>
<t>This memo contains a revised specification of the Internet STream
Protocol Version 2 (ST2). This memo defines an Experimental Protocol for the I
nternet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1887" target="https://www.rfc-editor.org/info/rfc188
7">
<front>
<title>An Architecture for IPv6 Unicast Address Allocation</title>
<seriesInfo name="DOI" value="10.17487/RFC1887"/>
<seriesInfo name="RFC" value="1887"/>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="ed
itor">
<organization/>
</author>
<author initials="T." surname="Li" fullname="T. Li" role="editor">
<organization/>
</author>
<date year="1995" month="December"/>
<abstract>
<t>This document provides an architecture for allocating IPv6 [1] un
icast addresses in the Internet. This document provides information for the Int
ernet community. This memo does not specify an Internet standard of any kind.</
t>
</abstract>
</front>
</reference>
<reference anchor="RFC2001" target="https://www.rfc-editor.org/info/rfc200
1">
<front>
<title>TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast
Recovery Algorithms</title>
<seriesInfo name="DOI" value="10.17487/RFC2001"/>
<seriesInfo name="RFC" value="2001"/>
<author initials="W." surname="Stevens" fullname="W. Stevens">
<organization/>
</author>
<date year="1997" month="January"/>
<abstract>
<t>Modern implementations of TCP contain four intertwined algorithms
that have never been fully documented as Internet standards: slow start, conges
tion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2205" target="https://www.rfc-editor.org/info/rfc220
5">
<front>
<title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Sp
ecification</title>
<seriesInfo name="DOI" value="10.17487/RFC2205"/>
<seriesInfo name="RFC" value="2205"/>
<author initials="R." surname="Braden" fullname="R. Braden" role="edit
or">
<organization/>
</author>
<author initials="L." surname="Zhang" fullname="L. Zhang">
<organization/>
</author>
<author initials="S." surname="Berson" fullname="S. Berson">
<organization/>
</author>
<author initials="S." surname="Herzog" fullname="S. Herzog">
<organization/>
</author>
<author initials="S." surname="Jamin" fullname="S. Jamin">
<organization/>
</author>
<date year="1997" month="September"/>
<abstract>
<t>This memo describes version 1 of RSVP, a resource reservation set
up protocol designed for an integrated services Internet. RSVP provides receive
r-initiated setup of resource reservations for multicast or unicast data flows,
with good scaling and robustness properties. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2210" target="https://www.rfc-editor.org/info/rfc221
0">
<front>
<title>The Use of RSVP with IETF Integrated Services</title>
<seriesInfo name="DOI" value="10.17487/RFC2210"/>
<seriesInfo name="RFC" value="2210"/>
<author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
<organization/>
</author>
<date year="1997" month="September"/>
<abstract>
<t>This note describes the use of the RSVP resource reservation prot
ocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2211" target="https://www.rfc-editor.org/info/rfc221
1">
<front>
<title>Specification of the Controlled-Load Network Element Service</t
itle>
<seriesInfo name="DOI" value="10.17487/RFC2211"/>
<seriesInfo name="RFC" value="2211"/>
<author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
<organization/>
</author>
<date year="1997" month="September"/>
<abstract>
<t>This memo specifies the network element behavior required to deli
ver Controlled-Load service in the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2212" target="https://www.rfc-editor.org/info/rfc221
2">
<front>
<title>Specification of Guaranteed Quality of Service</title>
<seriesInfo name="DOI" value="10.17487/RFC2212"/>
<seriesInfo name="RFC" value="2212"/>
<author initials="S." surname="Shenker" fullname="S. Shenker">
<organization/>
</author>
<author initials="C." surname="Partridge" fullname="C. Partridge">
<organization/>
</author>
<author initials="R." surname="Guerin" fullname="R. Guerin">
<organization/>
</author>
<date year="1997" month="September"/>
<abstract>
<t>This memo describes the network element behavior required to deli
ver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2215" target="https://www.rfc-editor.org/info/rfc221
5">
<front>
<title>General Characterization Parameters for Integrated Service Netw
ork Elements</title>
<seriesInfo name="DOI" value="10.17487/RFC2215"/>
<seriesInfo name="RFC" value="2215"/>
<author initials="S." surname="Shenker" fullname="S. Shenker">
<organization/>
</author>
<author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
<organization/>
</author>
<date year="1997" month="September"/>
<abstract>
<t>This memo defines a set of general control and characterization p
arameters for network elements supporting the IETF integrated services QoS contr
ol framework. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2309" target="https://www.rfc-editor.org/info/rfc230
9">
<front>
<title>Recommendations on Queue Management and Congestion Avoidance in
the Internet</title>
<seriesInfo name="DOI" value="10.17487/RFC2309"/>
<seriesInfo name="RFC" value="2309"/>
<author initials="B." surname="Braden" fullname="B. Braden">
<organization/>
</author>
<author initials="D." surname="Clark" fullname="D. Clark">
<organization/>
</author>
<author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
<organization/>
</author>
<author initials="B." surname="Davie" fullname="B. Davie">
<organization/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<author initials="D." surname="Estrin" fullname="D. Estrin">
<organization/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization/>
</author>
<author initials="G." surname="Minshall" fullname="G. Minshall">
<organization/>
</author>
<author initials="C." surname="Partridge" fullname="C. Partridge">
<organization/>
</author>
<author initials="L." surname="Peterson" fullname="L. Peterson">
<organization/>
</author>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan
">
<organization/>
</author>
<author initials="S." surname="Shenker" fullname="S. Shenker">
<organization/>
</author>
<author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
<organization/>
</author>
<author initials="L." surname="Zhang" fullname="L. Zhang">
<organization/>
</author>
<date year="1998" month="April"/>
<abstract>
<t>This memo presents two recommendations to the Internet community
concerning measures to improve and preserve Internet performance. It presents a
strong recommendation for testing, standardization, and widespread deployment o
f active queue management in routers, to improve the performance of today's Inte
rnet. It also urges a concerted effort of research, measurement, and ultimate d
eployment of router mechanisms to protect the Internet from flows that are not s
ufficiently responsive to congestion notification. This memo provides informati
on for the Internet community. It does not specify an Internet standard of any
kind.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2481" target="https://www.rfc-editor.org/info/rfc248
1">
<front>
<title>A Proposal to add Explicit Congestion Notification (ECN) to IP<
/title>
<seriesInfo name="DOI" value="10.17487/RFC2481"/>
<seriesInfo name="RFC" value="2481"/>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan
">
<organization/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<date year="1999" month="January"/>
<abstract>
<t>This note describes a proposed addition of ECN (Explicit Congesti
on Notification) to IP. This memo defines an Experimental Protocol for the Inte
rnet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc246
0">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<seriesInfo name="DOI" value="10.17487/RFC2460"/>
<seriesInfo name="RFC" value="2460"/>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization/>
</author>
<date year="1998" month="December"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv6)
, also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</
t>
</abstract>
</front>
</reference>
<reference anchor="RFC2475" target="https://www.rfc-editor.org/info/rfc247
5">
<front>
<title>An Architecture for Differentiated Services</title>
<seriesInfo name="DOI" value="10.17487/RFC2475"/>
<seriesInfo name="RFC" value="2475"/>
<author initials="S." surname="Blake" fullname="S. Blake">
<organization/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization/>
</author>
<author initials="M." surname="Carlson" fullname="M. Carlson">
<organization/>
</author>
<author initials="E." surname="Davies" fullname="E. Davies">
<organization/>
</author>
<author initials="Z." surname="Wang" fullname="Z. Wang">
<organization/>
</author>
<author initials="W." surname="Weiss" fullname="W. Weiss">
<organization/>
</author>
<date year="1998" month="December"/>
<abstract>
<t>This document defines an architecture for implementing scalable s
ervice differentiation in the Internet. This memo provides information for the
Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc316
8">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</t
itle>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
<seriesInfo name="RFC" value="3168"/>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan
">
<organization/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization/>
</author>
<date year="2001" month="September"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congestion
Notification) to TCP and IP, including ECN's use of two bits in the IP header.
[STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3697" target="https://www.rfc-editor.org/info/rfc369
7">
<front>
<title>IPv6 Flow Label Specification</title>
<seriesInfo name="DOI" value="10.17487/RFC3697"/>
<seriesInfo name="RFC" value="3697"/>
<author initials="J." surname="Rajahalme" fullname="J. Rajahalme">
<organization/>
</author>
<author initials="A." surname="Conta" fullname="A. Conta">
<organization/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<date year="2004" month="March"/>
<abstract>
<t>This document specifies the IPv6 Flow Label field and the minimum
requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labele
d packets, and flow state establishment methods. Even when mentioned as example
s of possible uses of the flow labeling, more detailed requirements for specific
use cases are out of scope for this document. The usage of the Flow Label fiel
d enables efficient IPv6 flow classification based only on IPv6 main header fiel
ds in fixed positions. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4094" target="https://www.rfc-editor.org/info/rfc409
4">
<front>
<title>Analysis of Existing Quality-of-Service Signaling Protocols</ti
tle>
<seriesInfo name="DOI" value="10.17487/RFC4094"/>
<seriesInfo name="RFC" value="4094"/>
<author initials="J." surname="Manner" fullname="J. Manner">
<organization/>
</author>
<author initials="X." surname="Fu" fullname="X. Fu">
<organization/>
</author>
<date year="2005" month="May"/>
<abstract>
<t>This document reviews some of the existing Quality of Service (Qo
S) signaling protocols for an IP network. The goal here is to learn from them a
nd to avoid common misconceptions. Further, we need to avoid mistakes during th
e design and implementation of any new protocol in this area. This memo provides
information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4443" target="https://www.rfc-editor.org/info/rfc444
3">
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet Pro
tocol Version 6 (IPv6) Specification</title>
<seriesInfo name="DOI" value="10.17487/RFC4443"/>
<seriesInfo name="RFC" value="4443"/>
<seriesInfo name="STD" value="89"/>
<author initials="A." surname="Conta" fullname="A. Conta">
<organization/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<author initials="M." surname="Gupta" fullname="M. Gupta" role="editor
">
<organization/>
</author>
<date year="2006" month="March"/>
<abstract>
<t>This document describes the format of a set of control messages u
sed in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Contr
ol Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</
t>
</abstract>
</front>
</reference>
<reference anchor="RFC4782" target="https://www.rfc-editor.org/info/rfc478
2">
<front>
<title>Quick-Start for TCP and IP</title>
<seriesInfo name="DOI" value="10.17487/RFC4782"/>
<seriesInfo name="RFC" value="4782"/>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization/>
</author>
<author initials="A." surname="Jain" fullname="A. Jain">
<organization/>
</author>
<author initials="P." surname="Sarolahti" fullname="P. Sarolahti">
<organization/>
</author>
<date year="2007" month="January"/>
<abstract>
<t>This document specifies an optional Quick-Start mechanism for tra
nsport protocols, in cooperation with routers, to determine an allowed sending r
ate at the start and, at times, in the middle of a data transfer (e.g., after an
idle period). While Quick-Start is designed to be used by a range of transport
protocols, in this document we only specify its use with TCP. Quick-Start is d
esigned to allow connections to use higher sending rates when there is significa
nt unused bandwidth along the path, and the sender and all of the routers along
the path approve the Quick-Start Request.</t>
<t>This document describes many paths where Quick-Start Requests wou
ld not be approved. These paths include all paths containing routers, IP tunnel
s, MPLS paths, and the like that do not support Quick- Start. These paths also
include paths with routers or middleboxes that drop packets containing IP option
s. Quick-Start Requests could be difficult to approve over paths that include m
ulti-access layer- two networks. This document also describes environments wher
e the Quick-Start process could fail with false positives, with the sender incor
rectly assuming that the Quick-Start Request had been approved by all of the rou
ters along the path. As a result of these concerns, and as a result of the diff
iculties and seeming absence of motivation for routers, such as core routers to
deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be o
f use in controlled environments, and not as a mechanism that would be intended
or appropriate for ubiquitous deployment in the global Internet. This memo defi
nes an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5082" target="https://www.rfc-editor.org/info/rfc508
2">
<front>
<title>The Generalized TTL Security Mechanism (GTSM)</title>
<seriesInfo name="DOI" value="10.17487/RFC5082"/>
<seriesInfo name="RFC" value="5082"/>
<author initials="V." surname="Gill" fullname="V. Gill">
<organization/>
</author>
<author initials="J." surname="Heasley" fullname="J. Heasley">
<organization/>
</author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization/>
</author>
<author initials="P." surname="Savola" fullname="P. Savola" role="edit
or">
<organization/>
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization/>
</author>
<date year="2007" month="October"/>
<abstract>
<t>The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv
6) to verify whether the packet was originated by an adjacent node on a connecte
d link has been used in many recent protocols. This document generalizes this t
echnique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5218" target="https://www.rfc-editor.org/info/rfc521
8">
<front>
<title>What Makes for a Successful Protocol?</title>
<seriesInfo name="DOI" value="10.17487/RFC5218"/>
<seriesInfo name="RFC" value="5218"/>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization/>
</author>
<author initials="B." surname="Aboba" fullname="B. Aboba">
<organization/>
</author>
<date year="2008" month="July"/>
<abstract>
<t>The Internet community has specified a large number of protocols
to date, and these protocols have achieved varying degrees of success. Based on
case studies, this document attempts to ascertain factors that contribute to or
hinder a protocol's success. It is hoped that these observations can serve as g
uidance for future protocol work. This memo provides information for the Inter
net community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5533" target="https://www.rfc-editor.org/info/rfc553
3">
<front>
<title>Shim6: Level 3 Multihoming Shim Protocol for IPv6</title>
<seriesInfo name="DOI" value="10.17487/RFC5533"/>
<seriesInfo name="RFC" value="5533"/>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization/>
</author>
<author initials="M." surname="Bagnulo" fullname="M. Bagnulo">
<organization/>
</author>
<date year="2009" month="June"/>
<abstract>
<t>This document defines the Shim6 protocol, a layer 3 shim for prov
iding locator agility below the transport protocols, so that multihoming can be
provided for IPv6 with failover and load-sharing properties, without assuming th
at a multihomed site will have a provider-independent IPv6 address prefix announ
ced in the global IPv6 routing table. The hosts in a site that has multiple pro
vider- allocated IPv6 address prefixes will use the Shim6 protocol specified in
this document to set up state with peer hosts so that the state can later be use
d to failover to a different locator pair, should the original one stop working.
[STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5575" target="https://www.rfc-editor.org/info/rfc557
5">
<front>
<title>Dissemination of Flow Specification Rules</title>
<seriesInfo name="DOI" value="10.17487/RFC5575"/>
<seriesInfo name="RFC" value="5575"/>
<author initials="P." surname="Marques" fullname="P. Marques">
<organization/>
</author>
<author initials="N." surname="Sheth" fullname="N. Sheth">
<organization/>
</author>
<author initials="R." surname="Raszuk" fullname="R. Raszuk">
<organization/>
</author>
<author initials="B." surname="Greene" fullname="B. Greene">
<organization/>
</author>
<author initials="J." surname="Mauch" fullname="J. Mauch">
<organization/>
</author>
<author initials="D." surname="McPherson" fullname="D. McPherson">
<organization/>
</author>
<date year="2009" month="August"/>
<abstract>
<t>This document defines a new Border Gateway Protocol Network Layer
Reachability Information (BGP NLRI) encoding format that can be used to distrib
ute traffic flow specifications. This allows the routing system to propagate in
formation regarding more specific components of the traffic aggregate defined by
an IP destination prefix.</t>
<t>Additionally, it defines two applications of that encoding format
: one that can be used to automate inter-domain coordination of traffic filterin
g, such as what is required in order to mitigate (distributed) denial-of-service
attacks, and a second application to provide traffic filtering in the context o
f a BGP/MPLS VPN service.</t>
<t>The information is carried via the BGP, thereby reusing protocol
algorithms, operational experience, and administrative processes such as inter-p
rovider peering agreements. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc568
1">
<front>
<title>TCP Congestion Control</title>
<seriesInfo name="DOI" value="10.17487/RFC5681"/>
<seriesInfo name="RFC" value="5681"/>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization/>
</author>
<author initials="V." surname="Paxson" fullname="V. Paxson">
<organization/>
</author>
<author initials="E." surname="Blanton" fullname="E. Blanton">
<organization/>
</author>
<date year="2009" month="September"/>
<abstract>
<t>This document defines TCP's four intertwined congestion control a
lgorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.
In addition, the document specifies how TCP should begin transmission after a
relatively long idle period, as well as discussing various acknowledgment genera
tion methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5971" target="https://www.rfc-editor.org/info/rfc597
1">
<front>
<title>GIST: General Internet Signalling Transport</title>
<seriesInfo name="DOI" value="10.17487/RFC5971"/>
<seriesInfo name="RFC" value="5971"/>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization/>
</author>
<author initials="R." surname="Hancock" fullname="R. Hancock">
<organization/>
</author>
<date year="2010" month="October"/>
<abstract>
<t>This document specifies protocol stacks for the routing and trans
port of per-flow signalling messages along the path taken by that flow through t
he network. The design uses existing transport and security protocols under a c
ommon messaging layer, the General Internet Signalling Transport (GIST), which p
rovides a common service for diverse signalling applications. GIST does not han
dle signalling application state itself, but manages its own internal state and
the configuration of the underlying transport and security protocols to enable t
he transfer of messages in both directions along the flow path. The combination
of GIST and the lower layer transport and security protocols provides a solutio
n for the base protocol component of the "Next Steps in Signalling" (NSIS) frame
work. This document defines an Experimental Protocol for the Internet communit
y.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5973" target="https://www.rfc-editor.org/info/rfc597
3">
<front>
<title>NAT/Firewall NSIS Signaling Layer Protocol (NSLP)</title>
<seriesInfo name="DOI" value="10.17487/RFC5973"/>
<seriesInfo name="RFC" value="5973"/>
<author initials="M." surname="Stiemerling" fullname="M. Stiemerling">
<organization/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization/>
</author>
<author initials="C." surname="Aoun" fullname="C. Aoun">
<organization/>
</author>
<author initials="E." surname="Davies" fullname="E. Davies">
<organization/>
</author>
<date year="2010" month="October"/>
<abstract>
<t>This memo defines the NSIS Signaling Layer Protocol (NSLP) for Ne
twork Address Translators (NATs) and firewalls. This NSLP allows hosts to signa
l on the data path for NATs and firewalls to be configured according to the need
s of the application data flows. For instance, it enables hosts behind NATs to
obtain a publicly reachable address and hosts behind firewalls to receive data t
raffic. The overall architecture is given by the framework and requirements def
ined by the Next Steps in Signaling (NSIS) working group. The network scenarios
, the protocol itself, and examples for path-coupled signaling are given in this
memo. This document defines an Experimental Protocol for the Internet communi
ty.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5974" target="https://www.rfc-editor.org/info/rfc597
4">
<front>
<title>NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Sig
naling</title>
<seriesInfo name="DOI" value="10.17487/RFC5974"/>
<seriesInfo name="RFC" value="5974"/>
<author initials="J." surname="Manner" fullname="J. Manner">
<organization/>
</author>
<author initials="G." surname="Karagiannis" fullname="G. Karagiannis">
<organization/>
</author>
<author initials="A." surname="McDonald" fullname="A. McDonald">
<organization/>
</author>
<date year="2010" month="October"/>
<abstract>
<t>This specification describes the NSIS Signaling Layer Protocol (N
SLP) for signaling Quality of Service (QoS) reservations in the Internet. It is
in accordance with the framework and requirements developed in NSIS. Together w
ith General Internet Signaling Transport (GIST), it provides functionality simil
ar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS sp
ecification or architecture and provides support for different reservation model
s. It is simplified by the elimination of support for multicast flows. This sp
ecification explains the overall protocol approach, describes the design decisio
ns made, and provides examples. It specifies object, message formats, and proce
ssing rules. This document defines an Experimental Protocol for the Internet c
ommunity.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5981" target="https://www.rfc-editor.org/info/rfc598
1">
<front>
<title>Authorization for NSIS Signaling Layer Protocols</title>
<seriesInfo name="DOI" value="10.17487/RFC5981"/>
<seriesInfo name="RFC" value="5981"/>
<author initials="J." surname="Manner" fullname="J. Manner">
<organization/>
</author>
<author initials="M." surname="Stiemerling" fullname="M. Stiemerling">
<organization/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization/>
</author>
<author initials="R." surname="Bless" fullname="R. Bless" role="editor
">
<organization/>
</author>
<date year="2011" month="February"/>
<abstract>
<t>Signaling layer protocols specified within the Next Steps in Sign
aling (NSIS) framework may rely on the General Internet Signaling Transport (GIS
T) protocol to handle authorization. Still, the signaling layer protocol above
GIST itself may require separate authorization to be performed when a node recei
ves a request for a certain kind of service or resources. This document present
s a generic model and object formats for session authorization within the NSIS s
ignaling layer protocols. The goal of session authorization is to allow the exc
hange of information between network elements in order to authorize the use of r
esources for a service and to coordinate actions between the signaling and trans
port planes. This document defines an Experimental Protocol for the Internet com
munity.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6294" target="https://www.rfc-editor.org/info/rfc629
4">
<front>
<title>Survey of Proposed Use Cases for the IPv6 Flow Label</title>
<seriesInfo name="DOI" value="10.17487/RFC6294"/>
<seriesInfo name="RFC" value="6294"/>
<author initials="Q." surname="Hu" fullname="Q. Hu">
<organization/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>The IPv6 protocol includes a flow label in every packet header, b
ut this field is not used in practice. This paper describes the flow label stan
dard and discusses the implementation issues that it raises. It then describes
various published proposals for using the flow label and shows that most of them
are inconsistent with the standard. Methods to address this problem are briefl
y reviewed. We also question whether the standard should be revised. This docu
ment is not an Internet Standards Track specification; it is published for info
rmational purposes.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6398" target="https://www.rfc-editor.org/info/rfc639
8">
<front>
<title>IP Router Alert Considerations and Usage</title>
<seriesInfo name="DOI" value="10.17487/RFC6398"/>
<seriesInfo name="RFC" value="6398"/>
<seriesInfo name="BCP" value="168"/>
<author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur"
role="editor">
<organization/>
</author>
<date year="2011" month="October"/>
<abstract>
<t>The IP Router Alert Option is an IP option that alerts transit ro
uters to more closely examine the contents of an IP packet. The Resource reSerV
ation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Man
agement Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Di
scovery (MRD), and General Internet Signaling Transport (GIST) are some of the p
rotocols that make use of the IP Router Alert Option. This document discusses s
ecurity aspects and usage guidelines around the use of the current IP Router Ale
rt Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides rec
ommendations against using the Router Alert in the end-to-end open Internet and
identifies controlled environments where protocols depending on Router Alert can
be used safely. It also provides recommendations about protection approaches f
or service providers. Finally, it provides brief guidelines for Router Alert im
plementation on routers. This memo documents an Internet Best Current Practice
.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6437" target="https://www.rfc-editor.org/info/rfc643
7">
<front>
<title>IPv6 Flow Label Specification</title>
<seriesInfo name="DOI" value="10.17487/RFC6437"/>
<seriesInfo name="RFC" value="6437"/>
<author initials="S." surname="Amante" fullname="S. Amante">
<organization/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/>
</author>
<author initials="S." surname="Jiang" fullname="S. Jiang">
<organization/>
</author>
<author initials="J." surname="Rajahalme" fullname="J. Rajahalme">
<organization/>
</author>
<date year="2011" month="November"/>
<abstract>
<t>This document specifies the IPv6 Flow Label field and the minimum
requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packe
ts, and flow state establishment methods. Even when mentioned as examples of po
ssible uses of the flow labeling, more detailed requirements for specific use ca
ses are out of the scope for this document.</t>
<t>The usage of the Flow Label field enables efficient IPv6 flow cla
ssification based only on IPv6 main header fields in fixed positions. [STANDARD
S-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6438" target="https://www.rfc-editor.org/info/rfc643
8">
<front>
<title>Using the IPv6 Flow Label for Equal Cost Multipath Routing and
Link Aggregation in Tunnels</title>
<seriesInfo name="DOI" value="10.17487/RFC6438"/>
<seriesInfo name="RFC" value="6438"/>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/>
</author>
<author initials="S." surname="Amante" fullname="S. Amante">
<organization/>
</author>
<date year="2011" month="November"/>
<abstract>
<t>The IPv6 flow label has certain restrictions on its use. This do
cument describes how those restrictions apply when using the flow label for load
balancing by equal cost multipath routing and for link aggregation, particularl
y for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6633" target="https://www.rfc-editor.org/info/rfc663
3">
<front>
<title>Deprecation of ICMP Source Quench Messages</title>
<seriesInfo name="DOI" value="10.17487/RFC6633"/>
<seriesInfo name="RFC" value="6633"/>
<author initials="F." surname="Gont" fullname="F. Gont">
<organization/>
</author>
<date year="2012" month="May"/>
<abstract>
<t>This document formally deprecates the use of ICMP Source Quench m
essages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 181
2. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc692
8">
<front>
<title>Increasing TCP's Initial Window</title>
<seriesInfo name="DOI" value="10.17487/RFC6928"/>
<seriesInfo name="RFC" value="6928"/>
<author initials="J." surname="Chu" fullname="J. Chu">
<organization/>
</author>
<author initials="N." surname="Dukkipati" fullname="N. Dukkipati">
<organization/>
</author>
<author initials="Y." surname="Cheng" fullname="Y. Cheng">
<organization/>
</author>
<author initials="M." surname="Mathis" fullname="M. Mathis">
<organization/>
</author>
<date year="2013" month="April"/>
<abstract>
<t>This document proposes an experiment to increase the permitted TC
P initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, t
o 10 segments with a fallback to the existing recommendation when performance is
sues are detected. It discusses the motivation behind the increase, the advanta
ges and disadvantages of the higher initial window, and presents results from se
veral large-scale experiments showing that the higher initial window improves th
e overall performance of many web services without resulting in a congestion col
lapse. The document closes with a discussion of usage and deployment for furthe
r experimental purposes recommended by the IETF TCP Maintenance and Minor Extens
ions (TCPM) working group.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7305" target="https://www.rfc-editor.org/info/rfc730
5">
<front>
<title>Report from the IAB Workshop on Internet Technology Adoption an
d Transition (ITAT)</title>
<seriesInfo name="DOI" value="10.17487/RFC7305"/>
<seriesInfo name="RFC" value="7305"/>
<author initials="E." surname="Lear" fullname="E. Lear" role="editor">
<organization/>
</author>
<date year="2014" month="July"/>
<abstract>
<t>This document provides an overview of a workshop held by the Inte
rnet Architecture Board (IAB) on Internet Technology Adoption and Transition (IT
AT). The workshop was hosted by the University of Cambridge on December 4th and
5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adopt
ion of Internet protocols, through examination of a variety of economic models,
with particular emphasis at the waist of the hourglass (e.g., the middle of the
protocol stack). This report summarizes contributions and discussions. As the
topics were wide ranging, there is no single set of recommendations for IETF par
ticipants to pursue at this time. Instead, in the classic sense of early researc
h, the workshop noted areas that deserve further exploration.</t>
<t>Note that this document is a report on the proceedings of the wor
kshop. The views and positions documented in this report are those of the works
hop participants and do not necessarily reflect IAB views and positions.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7418" target="https://www.rfc-editor.org/info/rfc741
8">
<front>
<title>An IRTF Primer for IETF Participants</title>
<seriesInfo name="DOI" value="10.17487/RFC7418"/>
<seriesInfo name="RFC" value="7418"/>
<author initials="S." surname="Dawkins" fullname="S. Dawkins" role="ed
itor">
<organization/>
</author>
<date year="2014" month="December"/>
<abstract>
<t>This document provides a high-level description of things for Int
ernet Engineering Task Force (IETF) participants to consider when bringing propo
sals for new research groups (RGs) into the Internet Research Task Force (IRTF).
This document emphasizes differences in expectations between the two organizat
ions.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc808
5">
<front>
<title>UDP Usage Guidelines</title>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="BCP" value="145"/>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-passi
ng transport that has no inherent congestion control mechanisms. This document
provides guidelines on the use of UDP for the designers of applications, tunnels
, and other protocols that use UDP. Congestion control guidelines are a primary
focus, but the document also provides guidance on other topics, including messa
ge sizes, reliability, checksums, middlebox traversal, the use of Explicit Conge
stion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports
.</t>
<t>Because congestion control is critical to the stable operation of
the Internet, applications and other protocols that choose to use UDP as an Int
ernet transport must employ mechanisms to prevent congestion collapse and to est
ablish some degree of fairness with concurrent traffic. They may also need to i
mplement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protocols
(e.g., protocols layered directly on IP or via IP-based tunnels), especially wh
en these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multicas
t UDP usage.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8170" target="https://www.rfc-editor.org/info/rfc817
0">
<front>
<title>Planning for Protocol Adoption and Subsequent Transitions</titl
e>
<seriesInfo name="DOI" value="10.17487/RFC8170"/>
<seriesInfo name="RFC" value="8170"/>
<author initials="D." surname="Thaler" fullname="D. Thaler" role="edit
or">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>Over the many years since the introduction of the Internet Protoc
ol, we have seen a number of transitions throughout the protocol stack, such as
deploying a new protocol, or updating or replacing an existing protocol. Many p
rotocols and technologies were not designed to enable smooth transition to alter
natives or to easily deploy extensions; thus, some transitions, such as the intr
oduction of IPv6, have been difficult. This document attempts to summarize some
basic principles to enable future transitions, and it also summarizes what make
s for a good transition plan.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc865
5">
<front>
<title>Deterministic Networking Architecture</title>
<seriesInfo name="DOI" value="10.17487/RFC8655"/>
<seriesInfo name="RFC" value="8655"/>
<author initials="N." surname="Finn" fullname="N. Finn">
<organization/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization/>
</author>
<author initials="B." surname="Varga" fullname="B. Varga">
<organization/>
</author>
<author initials="J." surname="Farkas" fullname="J. Farkas">
<organization/>
</author>
<date year="2019" month="October"/>
<abstract>
<t>This document provides the overall architecture for Deterministic
Networking (DetNet), which provides a capability to carry specified unicast or
multicast data flows for real-time applications with extremely low data loss rat
es and bounded latency within a network domain. Techniques used include 1) rese
rving data-plane resources for individual (or aggregated) DetNet flows in some o
r all of the intermediate nodes along the path of the flow, 2) providing explici
t routes for DetNet flows that do not immediately change with the network topolo
gy, and 3) distributing data from DetNet flow packets over time and/or space to
ensure delivery of each packet's data in spite of the loss of a path. DetNet op
erates at the IP layer and delivers service over lower-layer technologies such a
s MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8793" target="https://www.rfc-editor.org/info/rfc879
3">
<front>
<title>Information-Centric Networking (ICN): Content-Centric Networkin
g (CCNx) and Named Data Networking (NDN) Terminology</title>
<seriesInfo name="DOI" value="10.17487/RFC8793"/>
<seriesInfo name="RFC" value="8793"/>
<author initials="B." surname="Wissingh" fullname="B. Wissingh">
<organization/>
</author>
<author initials="C." surname="Wood" fullname="C. Wood">
<organization/>
</author>
<author initials="A." surname="Afanasyev" fullname="A. Afanasyev">
<organization/>
</author>
<author initials="L." surname="Zhang" fullname="L. Zhang">
<organization/>
</author>
<author initials="D." surname="Oran" fullname="D. Oran">
<organization/>
</author>
<author initials="C." surname="Tschudin" fullname="C. Tschudin">
<organization/>
</author>
<date year="2020" month="June"/>
<abstract>
<t>Information-Centric Networking (ICN) is a novel paradigm where ne
twork communications are accomplished by requesting named content instead of sen
ding packets to destination addresses. Named Data Networking (NDN) and Content-C
entric Networking (CCNx) are two prominent ICN architectures. This document prov
ides an overview of the terminology and definitions that have been used in descr
ibing concepts in these two implementations of ICN. While there are other ICN ar
chitectures, they are not part of the NDN and CCNx concepts and as such are out
of scope for this document. This document is a product of the Information-Centri
c Networking Research Group (ICNRG).</t>
</abstract>
</front>
</reference>
<reference anchor="Colossal-Cave" target="https://en.wikipedia.org/wiki/Co lossal_Cave_Adventure"> <reference anchor="Colossal-Cave" target="https://en.wikipedia.org/wiki/Co lossal_Cave_Adventure">
<front> <front>
<title>Wikipedia Page for Colossal Cave Adventure</title> <title>Colossal Cave Adventure</title>
<author> <author><organization>Wikipedia</organization></author>
<organization/> <date year="2021" month="June"/>
</author>
<date year="2019" month="January"/>
</front> </front>
</reference> </reference>
<!-- [Conviva] Keep space before colon; this is how it appears on page -->
<reference anchor="Conviva" target="https://www.conviva.com/datasheets/pre cision-delivery-intelligence/"> <reference anchor="Conviva" target="https://www.conviva.com/datasheets/pre cision-delivery-intelligence/">
<front> <front>
<title>Conviva Precision : Data Sheet</title> <title>Conviva Precision : Data Sheet</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="December"/> <date year="2021" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor="IEN-119" target="https://www.rfc-editor.org/ien/ien119. txt"> <reference anchor="IEN-119" target="https://www.rfc-editor.org/ien/ien119. txt">
<front> <front>
<title>ST - A Proposed Internet Stream Protocol</title> <title>ST - A Proposed Internet Stream Protocol</title>
<author initials="J." surname="Forgie" fullname="James W. Forgie"> <author initials="J." surname="Forgie" fullname="James W. Forgie">
<organization/> <organization/>
</author> </author>
<date year="1979" month="September"/> <date year="1979" month="September"/>
</front> </front>
</reference> </reference>
<reference anchor="GREASE" target="https://tools.ietf.org/html/draft-iab-u
se-it-or-lose-it-00"> <!-- draft-iab-use-it-or-lose-it (Expired) -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.iab-use
<title>Long-term Viability of Protocol Extension Mechanisms</title> -it-or-lose-it.xml"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization/>
</author>
<date year="2019" month="July"/>
</front>
</reference>
<reference anchor="ITAT" target="https://www.iab.org/activities/workshops/ itat/"> <reference anchor="ITAT" target="https://www.iab.org/activities/workshops/ itat/">
<front> <front>
<title>IAB Workshop on Internet Technology Adoption and Transition (IT AT)</title> <title>IAB Workshop on Internet Technology Adoption and Transition (IT AT) 2013</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2013" month="December"/> <date year="2013" month="December"/>
</front> </front>
</reference> </reference>
<reference anchor="MP-TCP" target="https://datatracker.ietf.org/wg/mptcp/a
bout/"> <reference anchor="MP-TCP" target="https://datatracker.ietf.org/wg/mptcp/"
>
<front> <front>
<title>Multipath TCP Working Group Home Page</title> <title>Multipath TCP Working Group Home Page</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="MOPS-109-Min" target="https://datatracker.ietf.org/meet ing/109/materials/minutes-109-mops-00"> <reference anchor="MOPS-109-Min" target="https://datatracker.ietf.org/meet ing/109/materials/minutes-109-mops-00">
<front> <front>
<title>Media Operations Working Group - IETF-109 Minutes</title> <title>Media Operations Working Group - IETF 109 Minutes</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="November"/> <date year="2020" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="model-t" target="https://www.iab.org/mailman/listinfo/m odel-t"> <reference anchor="model-t" target="https://www.iab.org/mailman/listinfo/m odel-t">
<front> <front>
<title>Model-t -- Discussions of changes in Internet deployment patter ns and their impact on the Internet threat model</title> <title>Model-t -- Discussions of changes in Internet deployment patter ns and their impact on the Internet threat model</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
<refcontent>model-t mailing list</refcontent>
</reference> </reference>
<reference anchor="NANOG-35" target="https://www.nanog.org/meetings/nanog3
5/agenda"> <reference anchor="NANOG-35" target="https://archive.nanog.org/meetings/na
nog35/agenda">
<front> <front>
<title>North American Network Operators Group NANOG-35 Agenda</title> <title>NANOG 35 Agenda</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2005" month="October"/> <date year="2005" month="October"/>
</front> </front>
<refcontent>North American Network Operators' Group (NANOG)</refcontent>
</reference> </reference>
<reference anchor="NSIS-CHARTER-2001" target="https://datatracker.ietf.org /doc/charter-ietf-nsis/"> <reference anchor="NSIS-CHARTER-2001" target="https://datatracker.ietf.org /doc/charter-ietf-nsis/">
<front> <front>
<title>Next Steps In Signaling Working Group Charter</title> <title>Next Steps In Signaling Working Group Charter</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2011" month="March"/> <date year="2011" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="PANRG-99" target="https://datatracker.ietf.org/meeting/
99/sessions/panrg"> <reference anchor="PANRG-99" target="https://datatracker.ietf.org/meeting/
99/session/panrg">
<front> <front>
<title>Path Aware Networking Research Group - IETF-99</title> <title>Path Aware Networking Research Group - IETF 99</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2017" month="July"/> <date year="2017" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="PANRG-103-Min" target="https://datatracker.ietf.org/doc /minutes-103-panrg/"> <reference anchor="PANRG-103-Min" target="https://datatracker.ietf.org/doc /minutes-103-panrg/">
<front> <front>
<title>Path Aware Networking Research Group - IETF-103 Minutes</title> <title>Path Aware Networking Research Group - IETF 103 Minutes</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2018" month="November"/> <date year="2018" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="PANRG-105-Min" target="https://datatracker.ietf.org/doc /minutes-105-panrg/"> <reference anchor="PANRG-105-Min" target="https://datatracker.ietf.org/doc /minutes-105-panrg/">
<front> <front>
<title>Path Aware Networking Research Group - IETF-105 Minutes</title> <title>Path Aware Networking Research Group - IETF 105 Minutes</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2019" month="July"/> <date year="2019" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="PANRG-106-Min" target="https://datatracker.ietf.org/doc /minutes-106-panrg/"> <reference anchor="PANRG-106-Min" target="https://datatracker.ietf.org/doc /minutes-106-panrg/">
<front> <front>
<title>Path Aware Networking Research Group - IETF-106 Minutes</title> <title>Path Aware Networking Research Group - IETF 106 Minutes</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2019" month="November"/> <date year="2019" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="PANRG-110" target="https://datatracker.ietf.org/meeting
/110/sessions/panrg"> <reference anchor="PANRG-110" target="https://datatracker.ietf.org/meeting
/110/session/panrg">
<front> <front>
<title>Path Aware Networking Research Group - IETF-110</title> <title>Path Aware Networking Research Group - IETF 110</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2017" month="July"/> <date year="2021" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="PATH-Decade" target="https://datatracker.ietf.org/doc/s lides-99-panrg-a-decade-of-path-awareness/"> <reference anchor="PATH-Decade" target="https://datatracker.ietf.org/doc/s lides-99-panrg-a-decade-of-path-awareness/">
<front> <front>
<title>A Decade of Path Awareness</title> <title>A Decade of Path Awareness</title>
<author initials="O." surname="Bonaventure" fullname="Olivier Bonavent ure"> <author initials="O." surname="Bonaventure" fullname="Olivier Bonavent ure">
<organization/> <organization/>
</author> </author>
<date year="2017" month="July"/> <date year="2017" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="PANRG" target="https://irtf.org/panrg"> <reference anchor="PANRG" target="https://irtf.org/panrg">
<front> <front>
<title>Path Aware Networking Research Group (Home Page)</title> <title>Path Aware Networking Research Group Home Page</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="QS-SAT" target="https://dl.acm.org/citation.cfm?id=3160 304.3160305"> <reference anchor="QS-SAT" target="https://dl.acm.org/citation.cfm?id=3160 304.3160305">
<front> <front>
<title>Using Quick-Start to enhance TCP-friendly rate control performa nce in bidirectional satellite networks</title> <title>Using Quick-Start to enhance TCP-friendly rate control performa nce in bidirectional satellite networks</title>
<author initials="R." surname="Secchi" fullname="Raffaello Secchi"> <author initials="R." surname="Secchi" fullname="Raffaello Secchi">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Sathiaseelan" fullname="Arjuna Sathiase elan"> <author initials="A." surname="Sathiaseelan" fullname="Arjuna Sathiase elan">
<organization/> <organization/>
</author> </author>
<author initials="F." surname="Potorti" fullname="Francesco Potorti"> <author initials="F." surname="Potortì" fullname="Francesco Potortì">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Gotta" fullname="Alberto Gotta"> <author initials="A." surname="Gotta" fullname="Alberto Gotta">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst"> <author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
<organization/> <organization/>
</author> </author>
<date year="2009"/> <date month="May" year="2009"/>
</front>
</reference>
<reference anchor="QUIC-WG" target="https://datatracker.ietf.org/wg/quic/a
bout/">
<front>
<title>QUIC Working Group Home Page</title>
<author>
<organization/>
</author>
<date>n.d.</date>
</front> </front>
<seriesInfo name="DOI" value="10.1002/sat.929"/>
</reference> </reference>
<reference anchor="SAAG-105-Min" target="https://datatracker.ietf.org/meet ing/105/materials/minutes-105-saag-00"> <reference anchor="SAAG-105-Min" target="https://datatracker.ietf.org/meet ing/105/materials/minutes-105-saag-00">
<front> <front>
<title>Security Area Open Meeting - IETF-105 Minutes</title> <title>Security Area Open Meeting - IETF 105 Minutes</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2019" month="July"/> <date year="2019" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="SAF07">
<reference anchor="SAF07" target="https://dl.acm.org/doi/10.1016/j.comnet.
2006.11.006">
<front> <front>
<title>Determining an appropriate sending rate over an underutilized n etwork path</title> <title>Determining an appropriate sending rate over an underutilized n etwork path</title>
<seriesInfo name="Computer Networking" value="Volume 51, Number 7"/>
<author initials="P." surname="Sarolahti" fullname="Pasi Sarolahti"> <author initials="P." surname="Sarolahti" fullname="Pasi Sarolahti">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Allman" fullname="Mark Allman"> <author initials="M." surname="Allman" fullname="Mark Allman">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Floyd" fullname="Sally Floyd"> <author initials="S." surname="Floyd" fullname="Sally Floyd">
<organization/> <organization/>
</author> </author>
<date year="2007" month="May"/> <date year="2007" month="May"/>
</front> </front>
<seriesInfo name="DOI" value="10.1016/j.comnet.2006.11.006"/>
<refcontent>Computer Networks: The International Journal of Computer and
Telecommunications Networking, Volume 51, Number 7</refcontent>
</reference> </reference>
<reference anchor="SallyFloyd" target="https://www.icir.org/floyd/ecn.html "> <reference anchor="SallyFloyd" target="https://www.icir.org/floyd/ecn.html ">
<front> <front>
<title>ECN (Explicit Congestion Notification) in TCP/IP</title> <title>ECN (Explicit Congestion Notification) in TCP/IP</title>
<author initials="S." surname="Floyd" fullname="Sally Floyd"> <author initials="S." surname="Floyd" fullname="Sally Floyd">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="June" year="2009"/>
</front> </front>
</reference> </reference>
<reference anchor="Sch11"> <reference anchor="Sch11">
<front> <front>
<title>Fast Startup Internet Congestion Control for Broadband Interact ive Applications</title> <title>Fast Startup Internet Congestion Control for Broadband Interact ive Applications</title>
<seriesInfo name="Ph.D." value="Thesis, University of Stuttgart"/>
<author initials="M." surname="Scharf" fullname="M. Scharf"> <author initials="M." surname="Scharf" fullname="M. Scharf">
<organization/> <organization/>
</author> </author>
<date year="2011" month="April"/> <date year="2011" month="April"/>
</front> </front>
<refcontent>Ph.D. Thesis, University of Stuttgart</refcontent>
</reference> </reference>
<reference anchor="Shim6-35" target="https://www.youtube.com/watch?v=ji6Y_ rYHAQs"> <reference anchor="Shim6-35" target="https://www.youtube.com/watch?v=ji6Y_ rYHAQs">
<front> <front>
<title>IAB IPv6 Multihoming Panel at NANOG 35</title> <title>IAB IPv6 Multihoming Panel at NANOG 35</title>
<seriesInfo name="NANOG" value="North American Network Operator Group" />
<author initials="D." surname="Meyer" fullname="David Meyer"> <author initials="D." surname="Meyer" fullname="David Meyer">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Huston" fullname="Geoff Huston"> <author initials="G." surname="Huston" fullname="Geoff Huston">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Schiller" fullname="Jason Schiller"> <author initials="J." surname="Schiller" fullname="Jason Schiller">
<organization/> <organization/>
</author> </author>
<author initials="V." surname="Gill" fullname="Vijay Gill"> <author initials="V." surname="Gill" fullname="Vijay Gill">
<organization/> <organization/>
</author> </author>
<date year="2005" month="October"/> <date year="2005" month="October"/>
</front> </front>
<refcontent>North American Network Operators' Group (NANOG)</refcontent>
</reference> </reference>
<reference anchor="TRIGTRAN-55" target="https://www.ietf.org/proceedings/5 5/239.htm"> <reference anchor="TRIGTRAN-55" target="https://www.ietf.org/proceedings/5 5/239.htm">
<front> <front>
<title>Triggers for Transport BOF at IETF 55</title> <title>Triggers for Transport BOF at IETF 55</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2003" month="July"/> <date year="2002" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="TRIGTRAN-56" target="https://www.ietf.org/proceedings/5 6/251.htm"> <reference anchor="TRIGTRAN-56" target="https://www.ietf.org/proceedings/5 6/251.htm">
<front> <front>
<title>Triggers for Transport BOF at IETF 56</title> <title>Triggers for Transport BOF at IETF 56</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2003" month="November"/> <date year="2003" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="vista-impl" target="https://www.ietf.org/proceedings/68 /slides/tsvarea-3/sld1.htm"> <reference anchor="vista-impl" target="https://www.ietf.org/proceedings/68 /slides/tsvarea-3/sld1.htm">
<front> <front>
<title>Implementation Report on Experiences with Various TCP RFCs</tit le> <title>Implementation Report on Experiences with Various TCP RFCs</tit le>
<author initials="M." surname="Sridharan" fullname="Murari Sridharan"> <author initials="M." surname="Sridharan" fullname="Murari Sridharan">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Bansal" fullname="Deepak Bansal"> <author initials="D." surname="Bansal" fullname="Deepak Bansal">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Thaler" fullname="Dave Thaler"> <author initials="D." surname="Thaler" fullname="Dave Thaler">
skipping to change at line 1946 skipping to change at line 1071
<title>Implementation Report on Experiences with Various TCP RFCs</tit le> <title>Implementation Report on Experiences with Various TCP RFCs</tit le>
<author initials="M." surname="Sridharan" fullname="Murari Sridharan"> <author initials="M." surname="Sridharan" fullname="Murari Sridharan">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Bansal" fullname="Deepak Bansal"> <author initials="D." surname="Bansal" fullname="Deepak Bansal">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Thaler" fullname="Dave Thaler"> <author initials="D." surname="Thaler" fullname="Dave Thaler">
<organization/> <organization/>
</author> </author>
<date year="2003" month="November"/> <date year="2007" month="March"/>
</front> </front>
</reference> </reference>
</references> </references>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Initial material for <xref target="ST2" format="default"/> on ST2 was p
rovided by <contact fullname="Gorry Fairhurst"/>.</t>
<t>Initial material for <xref target="IntServ" format="default"/> on IntSe
rv was provided by <contact fullname="Ron Bonica"/>.</t>
<t>Initial material for <xref target="Quick-Start" format="default"/> on Q
uick-Start TCP was provided by <contact fullname="Michael Scharf"/>, who also pr
ovided suggestions to improve this section after it was edited.</t>
<t>Initial material for <xref target="Source-Quench" format="default"/> on
ICMP Source Quench was provided by <contact fullname="Gorry Fairhurst"/>.</t>
<t>Initial material for <xref target="TRIGTRAN" format="default"/> on Trig
gers for Transport (TRIGTRAN) was provided by <contact fullname="Spencer Dawkins
"/>.</t>
<t><xref target="Shim6" format="default"/> on Shim6 builds on initial mate
rial describing obstacles, which was provided by <contact fullname="Erik Nordmar
k"/>, with background added by <contact fullname="Spencer Dawkins"/>.</t>
<t>Initial material for <xref target="NSIS" format="default"/> on Next Ste
ps in Signaling (NSIS) was provided by <contact fullname="Roland Bless"/> and <c
ontact fullname="Martin Stiemerling"/>.</t>
<t>Initial material for <xref target="FL" format="default"/> on IPv6 Flow
Labels was provided by <contact fullname="Gorry Fairhurst"/>.</t>
<t>Initial material for <xref target="ecn" format="default"/> on Explicit
Congestion Notification was provided by <contact fullname="Spencer Dawkins"/>.</
t>
<t>Our thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="B
ob Briscoe"/>, <contact fullname="C.M. Heard"/>, <contact fullname="David Black"
/>, <contact fullname="Eric Kinnear"/>, <contact fullname="Erik Auerswald"/>, <c
ontact fullname="Gorry Fairhurst"/>, <contact fullname="Jake Holland"/>, <contac
t fullname="
Joe Touch"/>, <contact fullname="Joeri de Ruiter"/>, <contact fullname="Kireeti
Kompella"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Randy P
resuhn"/>,
<contact fullname="Roland Bless"/>, <contact fullname="Ruediger Geib"/>, <contac
t fullname="Theresa Enghardt"/>, and <contact fullname="Wes Eddy"/>, who provide
d review comments on this document as a "work in process".</t>
<t><contact fullname="Mallory Knodel"/> reviewed this document for the Int
ernet Research Steering Group and provided many helpful suggestions.</t>
<t><contact fullname="David Oran"/> also provided helpful comments and tex
t suggestions on this document during Internet Research Steering Group balloting
. In particular, <xref target="Futures" format="default"/> reflects his review.<
/t>
<t><contact fullname="Benjamin Kaduk"/>, <contact fullname="Martin Duke"/>
,
and <contact fullname="Rob Wilton"/> provided helpful comments during Internet
Engineering Steering Group conflict review.</t>
<t>Special thanks to <contact fullname="Adrian Farrel"/> for helping <cont
act fullname="Spencer"/> navigate the twisty little passages of Flow Specs and F
ilter Specs in IntServ, RSVP, MPLS, and BGP. They are all alike, except when the
y are different <xref target="Colossal-Cave" format="default"/>.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAH9EeGAAA+29W3PbWLIm+l4R9R8QrIeS9pC0ZFu25T0zPbIku9RtyypJ
1RUzLztAEhRRAgE2AEpme9d/P/nlZV1ASHJ199lx4sQ8dLVFEgvrkivv+eVo
NPr+uzZvi+xtMrhI20VydJ/WWXKetfdVfZuXN2+Tz5OmTadF1iRtlZxkq6La
LLOyTXaOkndZ0+ZpvUmqeXJZpbMmOa/a5Dq9zcrdwfffpZNJnd29TX5dpK18
QwNU3383q6ZluqRXzup03o7yup2PVmlZ34zu6ZejsmpHbTWaVaP9Q/px2tIv
v/9uSv9/U9Wbt0lezmmQZj1Z5k2TV2W7WdEvzi6v33//3fff5av6bdLW66Z9
vrd3uPecplFnqX2PVd3U1Xr1Nrk4Or/88P13t9mGPpy9Td6nedEEf/s9CD7k
7Qn+xp6Ffx6dYw60YeXsP9KiKmlim4xGXeVYQ0JbONVPkqSp6rbO5o3/YLOM
/p5Wy1U6bcO/sfP2A1rZul1U9Vt8N8J/Etob+vZqnJyk9zTzRj6Uzb5aZeU0
q+OvqvomLfO/py3t49vkGr+goz1aZnU+TRP5TbaknXmbNPL8TB4f51k7/183
+GpM85Jf1hUIKZvlbVXzWdBJ1Usa/C57i7+T5Gx0Mg7O+29rUFBFk+79ekW7
O1rV1Sqr2zxreKHuZ/T+Udvc3d+MctqTrL4bLddFm6+KjD5eZdNgyLS+va1G
aT1d4LdZXWZEYQsii3a0rGZZEfx0ntZ1VhSjrF3iddHb/rbOp6O2TstmRUen
D12+P957fbgf/fXczVT+fhH+vb+3/8r/en//+fPwr8O96LevXsTPvtk7jP/e
7/z95rUfjS7Afvjt8+d7B0KG7oP9vfgH+50H9p93/j4Ihn/Bk7G/Xr7ZD/96
FY/88nXw5Iv9V2+Cv14dvg5/+3Lv8CWmaX++fBntwcvXb6JJHey9CXbw4Pn+
m+jbg3gHDw7CiRy8ehMt+ODw9b4du/z5Iv7zZfTn1sMvw79fPT+M/35xGKz6
1csX0arp72jirzpH/+rwefD06xd7B+G3r1/Gy36z9yb6/s3+671g6m9eHcRf
C43ir+OqqJomLUbHKd9a3Os2rW8y4kOLtl01b589y8rxfX6br+imp2NiIc/w
1zN78j/w5H8cze6IlazBLXkIFTK/2nPEOm+yhPiDe2OC5xL33EAeFP5/mbV1
nt1ls+TPabmGyHm+B+kgMy7v8rv0gbne398Tg+JfgFE9o/HSZpFlbfNsVWfT
HBJkRDyAeFS9YfZQFPkNWN2zeOb6muTCnkreEi9t0+QKoz0w25Nsmi0nxHWf
7z3fw3SZoZyej+imv03iF1xdJ6PkiMavVlVDz54pq0quSEykS3xB4qMqBsnD
K63n05HwXz6XPCvxP3rZuP3SymMqNHQQFRl/Hifv6YE8cx+L0Pgz/bdJfrVv
w0VeZatW1rZ/+FqP4sPl6dHVaXdhH6vyZkRrWSZ/zdNJXuQtawy2nuT0S5uV
vKOfsumC5FGzbB5aZFtVhQgfXuCiXRbPVI1IJ6N1k43ydlTVIyIp/ufe3iOr
/jROrhfVsqE3x8v+lJLAKe3LcNV/XhdGe/iQj/P66PoR4qN58VRJkud3OeTY
M+gVzaJaNc/yNm07dHZ29C75VX+Q0MwcGVzT5pR0V242dEmqFeRmQnpGcg2J
lPOfO5jLbkSLAQXuv5BT+nQxuj6+eGDKuB8k46a3We23+f7m2XLVTlfP0km1
7k74E4tdKI80Kk+ddKbkA7Ss5KdqmfFNHxi3+fT54mq0v3c4+pSXf2QKS7pk
NO4zevQZqRSkoKRF82yZl+s2a3jAJW2oO283OeY1n0mDYB2n6cxvRJfx+j0e
Tz7JUNHmnVd38fVNElYYRu03HDh0o2VaPity0nFIE3qmj3YmKB8mo1FykjfT
Nau0De4HrsIN3b48oIGZ179px/FhwzTQLrK8TnLWF0E09Ld/SFQdmflAVnF+
dP75w+jFwSPLKNOyugm3vnnGH704eEbnWc7SeB3npBItTHMsTXvWna/qRjfc
Xpwc8RjRbn+etpVs9t6BTvPq7Gp0/NPR5fXp5cipM99IMWRmPKM9rGkXRqy/
0S1pOrR7nn0Bf81WDW1XcpXflGkB6oip5FhGiSb7CeokLtW+TJXNidHh4T9C
04eHz5pMDv4Za77xJHsNMxIyTcZziCj58HDQx65eh5Pc33vxR28f9tLftRei
nz/7x6dJYzx14fbfJPGkD/65SR/8CyZ90DvpQCaE8331z8331b9gvq+e3OR4
zmoO/FGWvL/3L6NfGutxAr7+aUQiLZ09pJs+uLNNkc9oYw8P1bhMSevDOKNq
LoZmihmWtI7Olh8l8kLWWdxS8MNBpFvEKsRn0ihz2uN3VZlGmrDqHp/H2189
fGcfWCxsZV7gP7rrO05A76pk+PlqdPWgPjMrxul0yW+cQnWhEx9P58s/5bP/
QTbd3ou9l2P5/4N4Lr80ePfPZD/fjq5o0Ba+pKwkATfNoDWM5qQvlzNaNwmL
LCF9va1JMSTZwQ4E/Iqk4CSf5aR8461kLTQpq+r081KW1zkOp9KN3L/sbC7T
+TylhytSYqfTRe6/56O5HHc+3x7hqP5tXZLqT3ucp02WFWnZGeRoHH1r3z08
5Psa62ymVXJBejHpn50B34+7X/RMq6BrTVv7oWrbdHtC/PGjk/hQ1WRbvU/z
erGum7YzxIdx9yuhWHja/E+Zin45Ox79+hDZPqRjwsHSq2JiuCc1y6ujo39I
THjN8qBXszwYNWl6s6VZEomsa5gyR6RdQc+B+cIj/UF5cXX0fu+1kevTxHuR
NjmRFt2PdLFFJBfj7a+2hyDd5ZZoBdpp53myiOLPtx++Sgua/ntSQ2edh6/G
4ce2TycZTL+8xMbQPUhXcOjRHtPFbejO42O+9CSUavxgXc6yet2Smfh3MoL1
bkPbXegmNnRCWQON2rFcMs6XK9rnOmB1A3r3X6tiTWRysD9Mztcs8l53lDgc
xJ5yWl4Zr+DtI4y9Z/19q+8zDKa5mOVz/O5ZNi3HsF/j7To9Pk92Tr+sCvp1
C9/GjbhI4UDP56Rb449dsEPim8/OLpRtX00X+/tv+2lID32MH6X1vGMChx/a
JN6nDdRiYtR005wdEUzmWDk0/Dfv6iqdTWCF8C/Zzs2SoxWWIEbX9sG5uQ0u
FuOTMc7qekHfNcPklxKumEadBFftum1vaCLRuR0RARWqfMvdX+TLV96e6Rzc
NhGfpHf5jO7rJqs7RHwyjj/u4ZFZNZ8nP62btupeH2KQ8eej7sN/TuFtoD3P
i2Lr3X8eb32zNcBf89+IaD/QjzoP/3UcfBo6E84u7kgPhJG+qJa4bhdpmRUJ
YjIwxpIXB49cLP7J4Gn7TrjyI+bcQ5diQ9x+PcnYN3efttPFn+7+x2/5q//9
H/X//uno50bP9/ry7MP15dH56OAxk9WxdGIx0yybsdF6cPDs+YtD3LSOW+q6
zm9uiNKYiK/NrZ+8+/weewMOnhwc9DHuvRdbs3r1h2f16tnzg/1/cFavHlLn
99TDc5c3bTrKl6viWy/Ep3Wd1iRX6nxG7KBPLmx91XOrsmyV3ibvaNJplzzp
XsWfb1H2Cdy/14t0+16cjKPPv3mTX71Rrf9Z29whDDh6QR/MeNs794S2KoNb
hRkWacm86fQv4sS4FdDMkvucbsBfaZuqdcO+rsv3xw9aVkoko9EoSScNlI4W
Z3PUsm9mnpMKlajmAT6HD79FYx/yL2v7jGOZSXpT05KhUxPDTYvqhn1CKWnJ
m79nJDrpVdmc6KnlGO4su8uKasW/EX9S+OYWXsYcgblhsqzoSZrc/SKnd91n
9PW6bNZT2oxmvi4SolD2KzXwRpFiypLRfz+ElKpqEues7n/hTcCJ5jeLVvxW
Bf0S7i4QuzfCTOqzbqBLpSsxxgZeL/ImIXtuzU4wWAopjUi7QjPZWj0JFH4I
p7DMZ7OCDK0fIKbqarZmQ2J7SCKXaZ1PEO+mnbYJ8vh8+3il05wsLlrDAjRb
0ARL2v8dWZH8gYfpusyS+3Szm7BS+8ABi+IDYyevZtjuhg6oJgtH7FM6B4xL
dH0HUmYdSteGHxNV8wTvF5vkTmmz/z3+ZGXaZJiUSZEvyYSa4SjLKnAvjtn5
8sMPErw/qcSeHPBUBh0rmAQmTSqH15HmdKIb+afk6w9ku86y+e8Y6nOZGZ0L
8bvYLy2BLOV78Dz+QXgYPNG0uaUZ0scD5Af8KAdD45JOybeVnkqZemSnHvwR
+6idlf+nAZhKi3HLqsW20k5u3LRAssSvaFpMnNG0ZHOgsOC+1EvdUP82dtpW
NIM6+fqVDfjff3dP64HidOhNRcEzbdaT37Ip37YGls3M+YJlY7t3nsZobD9n
rD7Pu3N8RxQ3IRJaY5bRrtbZvKCXEdGwai1WNogAlLhFfXhFa7EHUhDcDZlh
al+/si6YT9a8cFonXe+SNdWyJXawqjOeH0Yhg6mWK+Y3iuY9WHnS8mc0wOiY
u67/27gjBsn5UNdlkd9mNAO+uqnu89QmC5c0HfH29O+rdTGTA12kco8bkk9i
l3Bmh2fZdv4cR2o628T8kt7X0LWlTdhaG82bZsfUERy3UkdTMYHk5bRYz2Sn
+QzrjHgX0htYyY4J8ozXfc+KGpE033msPb4JT23516+PZ2G4LSJLDrtbBfcq
ZNwBu8H+J6UYYPTyAgLIUa8zL1YWD8R5ElOawjGW7Hz9qmkSv/8+TFYFsbcO
hQoXpOWxAG92hwkdZnzYymamWY6g7NZ9prmWMxGgolvw0175+piSQSDngp9w
NCW1PcQJtzVJExpgskmIDFuwMrqe9JNJkU5vk0n1ZTBO6Hhk4yYZ6BoCFBJb
CSRZVPe8pXRxJoXcl48qfD6qTFH5FpCDWwFt/hD7LEynwISVkpgE3IvTBBtF
L17lU96IeVUU1f2I+IwxGBWzfdeVSUcEwR+4lVgW/clM8Ur8d8nzZGdwzX4B
jmgOdr+N9MbCs4MZ5Y2/JAvcON54RPyzkvU2PjLmn0QstdyU/z4pqunt39ZV
m/1P0Zh5IW+T5Iioi2gWz0GszH5LpxpsWySZqIiN8ElRiiB4prcZdA+nGNM2
c5YQSVYiiiFxeQ4ni16iLg/WJelSVLNsjLfyC/LGhliXoa9zLNNrmCW0+TIb
kaAGyZYt6VjjbCxMOpi5jfPgvGXWMmKDFc7rakkKb8ZTEuHHtGQjLcnqlIhk
OF85CVA+HT70CSIBHoFYInIGEs7JmqbelUifTeAwwGdDv30YfqJToVvkJoIt
cxd3snGz0VQv964zvRA0bCa7oQPnjQzKa7fHwu1h9lTRtg35rbwwXIwspW0i
q3SSl6nRvjmsaFY2hEwOH2Iq/65SQQaeVaxasCyhHZ2wWP+tysGw4c/J+HLa
SNBAyhZ+D2wGP1SVkKCiWsOoy332hCwxOF0bRjTharmq8yZTxYi3MXjeH6bs
C2hqbAOc5PN5xhefpwNR5iY0c9/Fs/GveVY5khFGGZMgLq8bwwsCM5EQUOAL
+qxzQ5/gR4E2OgRzZVb8B7SGbQa1P94nFnXiXvUAh3Ja7P9LvCmRa7Ra10gK
2taQh6H8DsTvwNsxPAgR7gqEx5oGztwTkWOvpiOz7rxh3Wuup4nUU+JJ4s8b
GiOTEWnyU9OYlfr9kKJ80YFPlUIhH/UKPYMcFkbJqs+/47ZkprPwZZYMl7TA
Bm1o0bqaBQ6MX8jKcoYEotZEkpGJUyxCfUKonKx60+NMkLpTG5po1z21jFFs
7ABHCi6RC7MXXtq/tzxEsBPRnjVZoXSmvFr23VFuTVtGAjr7IrfUkbMbADPL
1EtcCFts1itoK5A4dXZDpidsVztlqIxQykEWpJ8Hhy8615yuKm1PEy1LFRFs
j1sZK6c2+3HPTf0BOWykfZiO+hl5VIFdSGbhyn/9+7/CKeKNrKFzkh0e2qej
w0N80ROQJQZExBXaWuAnj8R7eUgXgcaoyMEiKb9cwawL/CRwihDvjtwlkCop
G+mZcE213YfiHiHTO2/7XTFyC4iKM5jD4RA3VVqoYBeJ0LSqF48T3VaiGdnM
tA2WOmRRTYdb3qipkk7IxBGjbQovhrCjUXIdKunKCFrIA5rWlM50XaTQfU2R
ZaLJnNtMNJ1lWj7gZTL3R1HRsXofCCTSUOQs5nBUtItqfbOQ+x7czq5TYwIl
RNwY8MiwIP+Swrs39IIt5wlfZfVdPoWFSz/Cd/ggYXMD6cq//77rPWBm60Uv
K39sxYlyD8fMCjyKNMYgMw/zUG/KKf08GXhiGISDwVD1MwDXm6dQ43zlBc6O
XnDHMvSe7YV1k0IXuxbx4bxoZVWOokmYh2drZppHhl3E8XivBFuQTF1Nu55t
nD2wzNp05Dx20Bd5XuFZZ0hlwIFd9NqEoBk+oWVFX7hLTMOUyWl5Q5okjVTe
DGH+klwlUsqbhQYOUcDRvfdYcD+DyMUBVMPVKFTOrs9Kzhfp0iSwlbbYT8pv
cR5E5t9NtDZ6nH17JrD7dzwwtG5Y/RGm1rTZSu3OrLMInsVRQStFAmxa0vTZ
ucPrPV6kOVmeFaSBuFc1o009jN/EHUkuInIx5KQq81094EXNvHPR+4Um6kTp
uJ3JNFcLVQ1UvjKTFEKM5Wrgkt3ZcrTs9s2kzlZ4CahcDXj6o1k3f0QaONcl
NOwm2HXoWO6VZ1abwskk3vsrDDKLnKhOSi5dfnLg2FGnUym8CQZIk7CfiEQw
YthDE96OiQaknlynzS1UPKKwHQiuXRnOhm+2nAB68eBu8tMRPgBVpTTNk+hV
6m/43ezpA1XbUkQPYC/B/SJjr4HqTyA8MaEwH+aOpKVn96zB5p3c0mxaNRui
7qXs+hH7px/Y29Wa77O5L+RNtFXIbh9uOX7hltW4FcTNJNtUkuia/G2dhlaQ
I9jcU7KjgSOxs46c/30kR3rtue+ZqehnHU2lJzZACiibdEbWGetEK0vZf8IT
pr6YVD3O4BlgzI4fZ7MxTYJ2MyWiuc+8c34NPw3RJavYoY9RBEPaNMwPahaR
dnJeVqtLkZ3NObwGpAlm0Ebl934r4MyTOANd4ylXypUzd4OM9YdOyW0WEBBe
ELuxGIYQX6YXoFFKyGsmUGaF56TUL+BwZetJPXM2hWCuW65R7wwlKmwW1X3Z
P8Fhl4icbhzJd0jOti0ylRusxthNYfuIlSanarAggNfds79oug/77obqsA7d
1fSiclvp4DeuiJBpO4jIZkNnwJFNwpoBftDWGxV3ts3MmVQIincAQgo0OMnc
j2hmWCPuicisaVrLSPjIOQeTI7KjkH7HZ+TE3TzNC32rSElmU158CgkGv6Ln
62xbgcAuiw+zPwaoZpSSz1hv+V+zci3FRCeRLt92r/MOCf/klAtk3iakFNJh
0ejL6k7tnEatskk2r3ivJ5bEsovH49Ed3Tg/My5VEDAW92vIQOjsb8iUqHkD
ee/alHS/VcH6nrpUOSKw1K1C9YAt88gbsjTAh3U+Q8qg8t3OhY3DFb3eZOGV
vRTpnRKgTFoNsaD0RlzkE+L5S5z4kmaY1nJmkVA4Ch347yqi1B/94DCgkwGH
FT/R2hs1i668nWSFQX8aiLaGmj7iKxJ6LNKSU8lY9TN+EtXDXK0n4gltg9KY
RsdCIZxqfs6m0Ht2XwVzVNedHTGrXhob6I9TG2+TgNmGFelFVqywIKJf2r+p
rlX2FbSW3eplyJdgu5mywq1IkzOtJJCBQQKz8iHFHm61cuMmxjVc3hjCgRGv
IurVnU/ep1OOikXhvatM3PXjfYwXHUewwHBZ24FIbPY7F4hkLYLVBKKjslrS
DFL2BkhugtTWNRox98tRjeSfKI76+hXVUTTzWrI7xBJ4sXeAxRRN5UPs86oy
kQMCkft3pVEn1Tq6t6lfFmqktXuCnQiq29RhOClhmV2qJTYQxE2SX5rg/saK
i8Wmz82PfipO2O3gkTio2cJL+XKZV/8bYzI6r08kY6qZzEsKO8Pw29cfrjMi
PTK9Y0NgW8siw+mehY6QfjDGxOc4bOdiMB/akiVIO6jF3nwqLcKF9eEMUavY
PCSB3ESYIs1nSqEdq6Q/AMpPh/4JzsCBuvdeFZtHHLxRyJolfJ2x21nYsVKt
2LIYCtlU4pN3MxiqtmQ5uAzMkEtYI5/zJkErhfsRo9BH6R3JH7hyhuqbkQJO
dj5KPg9eNaFZgMbhVZlmRtYmcNzrMWYKgVdbes2qdRKaFRh60TJ+hifk9D/2
9BZ3T40UJsNsjQZ3jerc4TDEaNvMGOZWyk+oesAxEyg30Mq75MZH5946Vn8o
AuVdKfxr9uNd5rjH1x9S/dHvdnnZHQ09YUqU0hOzxv6wwk+SiRNjkiWy/m7N
E3YPAp45i02cgrTXeVVL4kPoHBWlM1OlBDu1hF6S3pCCMBgnV9XSZe/EN7I3
AyTM+YiWIWYqEh9yUE5gj/VdSKGsWo6/90W0H1+/Xl1LakDXugSrQW3yXoPM
2Lus9NkQwS11BiybnNkdqEx0o7xcE6OB3yRnP9+yUfoSt3gndI+IqSREsDah
ROR8Z6LUdRwzmvg06xUofd6Vrs6WSQb7C3btHCacNx1ovj47QJ3iqEiwg9dK
CZMz0PZztjVxS2a5Ge9e4/WDvAoGeSWDjOkjms98DZ2PSUBlKSY5gBPHEVBd
VcuBck8OsspeJemcOQt7NoJ8mK5rA3TPmY4rVi/NJEu9Oq7jyZFJ3BXH8N+S
wVkJ8UHSYpCMiNyLYqS6FgQ+e3G8GcbPBQkZrKaWgbHfL06ITa01NEIvRLYo
nsb7QF+k6GXgZ4Gapge54ng4MleW7LNU6yyYAP0w7bFVx5E7yTlDaP5ejwwN
V9se6GDB4A0tbA3fgEwccD3n1T3mLaE4pP5OURzTtPz2cibeiDWxQ6R40LRL
0hoyEpCkEbKaNCOTwSU06eiuoMO7AO7hlrinq8t36K4i0XqTLieFhufSrv+k
zgoOVooWM6RltnkRmLhB/pnVUOP4v37NpkSonNR7fM5kRHSOs1jXxpzlQooj
HHUqd3QDOKG4aQLHZuqTBFkQKFrAyfo20xiwmpG0cg5rsGjI221fHm8M235K
BQGFPvPE88wfR5t+gdK8YRdxDzcAc3kDdvB8/0F2MOTFm6dzhovt7vO+6Zn/
qZNN/jM5Vuil5D/x8Z/XtPQ5y7MQDerrV/+F/xw86z8TtygZ4YJ5AwZ4l4Fm
WjFpTjkfjrV3kAWNyJ/YB986lB7nhWZNxHPUT5+Y4Od1q85vjHRazoBHhTCa
Mzg9UAVGjX4vI9rZ6TTTjbNZPdcIfJA8tY17ujOfM1fX74AMUpjJiLtP5eng
C/l1/3Zl9YiIplQvxxVUH3539Dl/3LeMv2TZin3WGp6mIVApNJLgNY3j/+p7
/FSD1w0NAFqhkdh+WwKjgSYCQ0XO3X5ovzs70QH1Hui2bD/sBvbvovHocfvC
fd4z3iUnMohFfgJdirZNIAF4lEvNc7jOl1nv+q4kAI/LaK/xFEObOr2Vg9aP
+BN9ppdoQlcH0Mk0HfJzmR1z5WzPEX99m/zgxTDu8aD3vg6GyeCbriH/8Anq
xW8eJ9HBsMd7o0sabCXKiujN3brErNnSIUQTUJWuMV9kWtynG0QZ+7wmD8nv
ay9Mec96tubkIbYyCESJqDCmag2NF3XiZkXK3tWiGJrOwe6Hh3dAZgVTcfBH
WNNgGLhbkFPCxe5zl6unXqdZVGfNEq2fSbFY9KohcsyK7Auc6DBI81oihY0U
5vYMIMv4t9gPRbbmplqzbVVNIM2ShzOuObwSayIaiF6SYk60pP7FiUpFTS2Y
k0hnB4B4R8mCWJE4d6k0udX+sHuZa1wiHTBLb8TipbUHi5bDYx9B2qr7V2zE
SWbz0WgdZ/bJ24bOyZ6SeovF2Z7nITfTtEZ37H2MW443uc02QS2Fl+q9ZQNy
1wYwWJZr+pCNX80DlwAffwKKWdIeyj4O7OCI4XKGAliq/BMsyB2+PAqHPkfF
thYkaZX8XbCWMHPUdqnhGE5/oDG004Y+SMEH4YdtRF1u1yVqHSULTZP82Jjs
7rWk5gGmoMjC2UnGAju8mYQQU4Ni11Q6qL8Pmb+M4TxmlTgeorsjW9U/E7ch
MvdgT85cIgp/JdSaldN6s+K0rz8wGAj1Rw53Q+KtoX3bT4PJD3Fc7CJSBwFH
vJqck3wC8nxUMRhwLBOpfbPE5/Yx8641asOHB98g2FAjZhAMIObZRREyDoQ5
JnBYaaK9Bo694calSMo4ZSQuLrPBnQ2xkQOtXERmpD44vuOSxE8HxH4QjbeJ
a1Q91PpipMaarZbMEeRL5kV6/0hqStfhyDv4TbqRXtRv0nuEO3hPhLjunOMO
KdgcZBNpA8Onydv4yl0LbhQjVNkR/GonyTYNm2JbqWWNc43mllqmCZzM0Uk+
uwSAKEwduSl2yHzn3zyCs6AYDfABBdgPZONh8+OsPnFjPwUEqlEm+XEABcqJ
LYqz9ViYi9nFFONxYmEYw+M5qVsJRmewW8ROFRpMEmjW7IqrieuQIft3lxBr
bul+qpIYivcfS8HnULlzqIUEVPeIxrt1azlloShCYcfsB4F0JyDm7F62X3Dy
fcsaraE7cKruTHSOKNWPk0zBPNYFU2k1AaZrltzlachZfcqLU57ISF+Lp7pf
bfEX3pKS/ASDhIc0chxMRO+LeD8eE3QDW+9R4G1BLMyyKyKVQF5Zu6IfS7uo
kt9ENe8E7frTJHkUZkZrU4PBq4L3uFi8RuXG7pi/wTDZOu5gFmkA5UBqQyPM
Tp2gfsUs9yxNPDO1QNP+mSH06W+2ldfsox7NEYQk6SrVKUcXZ5YJBK6BmLuD
aAtmxW74aRso+oGTV96qfM9loCCz8lb981fr5VJRrLsOmq8/dHywLlplmQIN
P0zXtOn14mq2VhblCDSIUE8fdqDzvE7hGlUfjAsy0kvSmxtjv2FwK3bLS14F
wvalJQsic10TSk3Z8eTOfslcauHiMuDP7DcMZx8QpasLYQPmwfdZRV44BZOb
PirGcgngB83D87GobJQXE1Y/+sI6VEBOlXmycxBme8Jmhk2BHa3iko0izfeL
vMh8NR0/OfR2SWcAzct9MA6P+wH2Y7m6kT7u9fVAFQN5mzbWSQLW2eIV/enB
std5oO5a0GMC6wd0bkMPZDArA5XnB2zC0Bzmra8NIhO8CUJAW27MOvPe0Qlt
2mM8jBUCnLylTgkjf+oJ/2uRj51BOCkaLL5OgCJ1i+2+Ig2CVANAwzjBfkR2
ejlbL0cCgorPpaJDDVInP3kH+CB021yYu98B+vWHXv+nxX9MnmzVFDiGKunC
28KBeD5eFaCBgoYDJ4vyOSGvKco5aQfo81/GV2MP2HJKlg20fGKVdaYVAAOS
16CUHKYAqYS3dFPFXJnnX+ibgXgOBhzmtbKalfl0WJxWs3TzY+N0onGyI7se
YL1JWsMVZ8CMfkaF4kI+MvgUn+rAHnqGjTBbSUKVLkFi13Igvs2H/PWH2IWM
h/2Tk/BJqcZO7Um142FcczyczVbQCR+XwmaEoQkHdbGVqhhlVeorJav2TmqY
WEpJjfqw82hUxy4RKc0a7aF33Xpnmuumdo7iH9vcB91fQHnYcqpzvgxXarCz
DQ5UVQcSV43fqQvkQAlXASF6VGTlDQRcUOdo92S9uoEnS3ICVLFJ6RLch+kO
mr8Hs9Kdsh4pKjbGkugbRftsgtOqgqWXRs6JysHY3i8qh0+YiiRvnW/KliP0
vP2w1oBBSiH3de6dULoq0anNo8IWf0hkLqrqFsWJolwmmnI2TLRlrtzC9mzL
WG4rn9z3kADbJqzhNlV98/01LvqHYixff4hDLJy+N0tXXGAWWAd9ifpQNIjj
rSqp3p+TxQsfgl0bx3FNTAZeGuLIRf531nSNf4s/j8ktkFjudTpMnWfqPCjz
FddHmZeJydzQSujympnDb/a6PJ1i3wNaJS2uu2UKoLCEi2dIh+M8KHCGPg6s
5+M5rj+IJ2NTuOAuM2XwnvECJFuM+OFmPACRehIXvxKUfIX3T3tFu9y4qStc
m1aNGK9Cd1zCozl/jtZVh7d3OY6AYwLwkNdnx8lxRRe0SNEvJp7eUxPbfqdc
Vqug612MzSRUqbclua3TXSjNXOncrAfEouPOT0UD6bJsBQNZQdbn5g8diXcV
mLIBOzx4x8q9gytzuaqXk1/sLlW1yaUUd3GZN3FCDxfaWqUDp3XwnKy8B743
fTMona3dQJFmO0cYl2iB1bxFNh1qU4WD9TAtVf/CDLgeLdCLvr4IKd2AngAp
KxPxz9V5XvZ5Yh0zTsuOefOQ4RBnhmgCLaNSzDhFqWnN6NaQBFlr2JEh0eEy
J+Lfkn1aQqrmI7MRLhJGtmexGZGQ4LgJL8PLyIyTTiQFGh7btOHkMiQsO/M2
m90480AV0iGJ8loLi6zOXYu/pzjJ8BKY281FFew8Hg85f/0hiDjjiU+Q+HCm
1WXoTw5WsCCbjWWF8x+HeZlcE6XbA/Sue1ekgB1kgmw4XgT/1UghJvq8w8nO
YO494OrV4zeJszh8m3mZF1l6tzH3Tl6OGFMzkGQNzguVgRd3L3nDGNnxkteR
HJEsaIkjiP2/c3n0edc8X6LX8O3RZBZ1+T3o2x4TgxAPjIuv9MwHezMDWKdm
ooq1rK+oXHGP7nRIcxVgtXT3gikBB5be/TkUJsLgi/WUnZPOGbBlJLKDDzuY
i6OvZ74eDCsTCIwYqYoUrvXU4YZoNdVq7VkJuhEEpPlt6QxkgvRlMzBDnvcG
opwmLO4ylqcMKbNuJMoDdLMY3cqHdTiZypydjSYvPBBf5N2soUIF/N5ppJOM
yDWnUxib01/eNeCJDAw3DfAoNYwkUgaGONmhwHowM8AvxVGXqaoqkDf0cLOW
itslnT1YN46aOOk8r1WJyqUIsA/1REizKv0u5Qr04ioqTEWX9Pm9N0jy38nG
N+MhFygef7pwb3aFZMjrYgeo3WtjblK9QSrTEbMPACzFS2RxyHgrskgf75Vo
pZUy80sk7RiH4a1AOXP+SEakIxR35iJfyc0xd6aGho17xmb1I3ret2XLfP2h
N1lGybUNIChieBtOlX9g5q3mb/YSutOF3aX3/Pib731VBtMykJ51iepReN+m
BlDAJGG3AhqoyIAHTWe78cnOr+rj1HvAgQ25akuunEbsD+UzRCCIcQk3Db36
Vt7v2Mdj2UZff4iTjToVND4Exf4ZeA6da5lj5EMJ2XIeraQYyJXydblC3DN9
b2yLt3XKuDxQTUJNcQGNAytfczl6xlyzgD491DP2w4t7l+kagZ/pdA3mzlxW
K7zlZknKAKpT83Ytjxpinc6N38o1yFuuAp423zi5/w4oqqi4YmvcAwtlhpz4
IfoVYWdmMzflTBxOzmladrBK3sdGI2KWbiQDQ8vod4K5g/+WNDHSOPuyxDDC
n8XWEGJIOxGNACaUbVSFdXkmNO/rl1Ho47IifHCH12tEFj879nNsZI62Bbcl
WQCaAp+xTUBnAOwTwXAPs/xDcNlAGncXISa7qC1bNBtNGK41VEO12y43yTL2
8xEVLI5l2SGOuCwil6V0r4qCd+iNCsNOvJ29zwit/ZfHs0Dv3gu5tVPqhBRL
K3qHfBser8QDM05S5nlLIEUZFCuT7HkIJbJ4KJvI/HpUu3f5gO+DFEeyX12G
o8odcc5GiVqGSCRokK6IqHHIep76tbxF/9rK8aeR4OKZOeCFO7rurPKG72N/
xchhIgXjqZLKeU0uhG1FFaUj5A1HY5CYILCVfFihm6zNWOgOHeBbJ+wVehvZ
JzH0MxQNHTiUHsRaYie40bMMWQr0f+o5xdNbtdmshwxQoQ332EC4P4JCXG7n
cslr+Q22Xn5TugBXgOyWx3jaqTPcdc8tRG1kEno4kvecvcp1nrDw+C+VgRtO
oy/dsXYhI1RtCDBSt7bZ0iwZj0Y9Wd2AFtQNFkwGcWrBDy5il+n1F/05h7fq
6aw0CCRr+OKgHqNWt0i2Ykv5DlRwI9tWZHNRfSrDYoo0ccmvwS4hmcoF4OJI
sK/DF5W5ByO6t2ZR4YAKV/D6QAiYZiwlUxz3bzyMq9gNs5yryeJSqSgvSYKo
bqcdYCRPYJjccOVWWmbTWdWyT3bFQOaqJWi+0CH3FUxsGRJbDZDEzi78wEDT
4VMQXkFiGG1hkqllgLZxXL2o1g59W8oSwhaGnLGTW9FOhOyKoW/DzAcHPQ3R
H6xTgxX3marSpEM2bSUJCRGAmGcIYrtFFdYC1OUqUxi23UqjvH9aIyZIWFbU
PdOLgwKXLOfnvErdESacrZPS8U0FSYtZbhzWJCveA34vK7qJqQMftjRSJrAA
F1j8ByFaXyM2W+J6yHDxkc960npptLNFJqqCPlmPUdqiQcMi3jhVKGPdaq06
32pe1dgsnWmi59OV/s7Ln5cM3d06F1WryaEOetOEVePVVqeKueLraUpyVOfd
kJKHXGh1IrMqJd+AqLtT+RG3qMyX6yVLbC2Z6yWF7qmzGZ9l4lBEggSXJa44
g810JiNMg7aXjGol9LBa1jIneK1IV1kaQKGDR+rU2NqQhmTuKpTcfQIunngl
PdyhtipOmB/y1G7kJyhVZvnYrcsNNmskB58ifCQH2eRiIQFJfcN+im7SEzz4
eszgfnrQeTnKkMuv8BDOy+kC8lfssHMvYgfF0ummqD+Mok+9h8N42Y1kuRle
aNOZntuOa5ckGKXMudz4LeuZcz1aQMTYotIt6hI06WQHSUoY48TMTXyndxHN
IsDQRscn54pnZ/2SObsJ/4ITPmun493w9CTjjJOg+utieqwUdftzokJofIQG
x1YqibmzxdnTOMuFa4DlEFxBf953UZAn2iyqwqozLAEO+F2BfWvausf8YHcj
7tgwEPviWQ9toHDHScnJijnzCFsk+4oe+n1gU4B5iLEHTamr5ONBTsKVgvSu
+XAtes/QYVq6xEZ6cOlAD2+qtmWhvJG7IkyaOb0CLI+ury5Oj53exeNcXv31
gjdMxmZmltc1p8WSThxgok428YErBgV6uLbN3f0NkncRNh2517VQ94hYaL1c
ikAEhX7Hu+NH1aa2qm7FcFxk5cjhxl44UytCoqc9ZmWEMUYBHdTaZeEUKS5l
juELrNSIsd97NASnFUXJu5jr/ZOzEb8vuzWqWtPChk9qddsgMGYQKUikSj/0
HL6wKbYIC3W6LypOsBh8m+USHc+nhoTnzOARlCr6ohcox8UzzlOADHIv9SCh
eef85HyXB1TGMzrWwcIfHR+ff9nVJgHoYg81gKOxc4bU2560zRaBlnA6I1dZ
HaLqiUHSBTLZBjCJf1EZdteTwCCSHS+NepixoAr/LjPC2m4AwEXvD6DNyHQ/
KyyFXntRiqxNj4H0sFkIFugLANIQQS5IcJ3S7JGT45WB+7Rs7alpVc90sYiX
jeYMmOPkuySaCtCqCxFJEo04eazsICpP5uKabPMjzdFpR2TDknbWQB/ntGf6
ppw55/YVgwgGLRt2rq6HydX1c/7Pf9ulQ4MnwrLxmjWnmWYzD14ifpatcWjx
b4WHXF2TxDqCF0zKB50PVp9x7jHiVqfno/39w99/x3PSQYpt4eLBh4bJX9XA
fo6pj87OdhNtfHG4J+M8+L7oyee7gS/RwKv4HEfuh9gRHf2NzFJ2RWDfgqrx
7m5gM8PlSSH5w8AbP0rG070AH6gvJQY8tCjO0eXF0fnpNQ6WE1uShpSqTJpm
KDKNkaeh7uwfvsEbBOI32OMQUhyruKty+Dhgv1VDU8e9wzxnAGP28znyADLV
LK6fz7D2JtpR2e7gmMJNlarQMp6aTxUYVVBPRffx+OKRTOZbK2ERKdJ3Ccii
kAkAgI7HOuIZ2n9eP3f+OIdXFOQWG5wrlBxi8QsBebOlijFGZtfZxVBeif9w
gQYfQfy75KVp/Hhr3w8ORAK7r1Pf27cgm15WYpWaInFEDZDQTKP9HyRHyhlI
CjdWjFjwCoAowKjrqhHHt3eURrANc2QuxWcYVCzwxoBbrVJuSOqB0/hy9D1r
WL8dU/jn6sqngrg8gxU3HVMIpogsnAUqK5XRw9dziTCi5jPeaddjJoigMXeF
YyNU/W/WaNhH+j2/PkehgnhZGnpHoylJmG1UrGHbK7urKNkeY9zn+grz5VCW
Q0M+J9oOHJcR0F7IBLg8s5YWFHNUEeUrYf5YoEGkajKRkA7XVkuyS4j55HeS
+4CgEE2wLWU3+NIQLzHNRmAo22wEAErz2IXNCljicNGPuodR7+huTQ8SusP4
4atnt5fD4xb/kk5WY9uvjlgfK4Ij77eAuWoe8FbJtqZSBDkTAvFd3vrboS0D
xslH+lhsDIZrbFouwZq5PDSGoN8aUH+PjcY9kFgOu8Kw06SwWvmTLdndaFs6
H9eAm99pffGIG6zgwPE6Pt4gJj60W64Gk2Kc8aVHM4OIE+hvsi/C0hT9pXWA
rN5LgNBwxpcfNWQu0IIofkMm5Ehjj8B5geouaAKivjRrLk9TnLO8Ed0mfkBm
Xai3WBDdQhgx83JxaV8X8c+FQsbcJVLD8zd1BExPXFh+BvXFnnhShXHeNae5
APN0/9WLF73v6AI6h0WNb8GpPt/hp9m9CjcaR/QRjPr8+f5+R83Q1WuDYNqe
0ceKVEvrF2sYhPp+hdunYaJBn28P+sFY2Sz52UP3dod5Hg1zkHxQsNVjV3T2
dxnxgv5eZq01Wt3eme6MG/eOg/AdewcA9RLufZnRs3/V8e0y7MDs3bWH9w5E
3TorSX05ZPGZlRG5REaei20Eex/rXMNAEJoLBz8QXU5qgBRIKebdR5FwR6oU
MdtWroGkNqTgm1gX17zPOL/QK6G6SxfOMT5Z54WDd1JxcXL1Itl5eZB8mqwa
9M+Z16n0SuPwDYf915MRS9ud/57sJ59WE/pdKnik96zgoNx+LI4teGE9MHmU
85yKISNhMmQzulxGSDdn0Y117x/a8KE4KWPvQxjEM1PGC9bO3Kqub87cNQGV
eBn/CJUEjhxeQ6gbOF0n1HQg/U45CKk8XW+2/UY90rVtGl99x6QU7IFR/0ei
63geCbt011BCGLmkxz/GFQ+7xOgKpAT6HZrZpomY6+7Ne7wrvu077rPGbQlw
qYTRCh81+cgEb7n7myRb5kTb7GlSAdLEaqN30kvLVf9+KIp5M/6jOo3toK+1
UPANDidpEy6oYrgQ5TKAQCOdzB5mfSfj7myi8XTNI3fvgjRgzuvldHLWTzkv
nzP5Fcc3CtjFidx4TIWDowBNYQ/fnIXk1GqzVBcYUUe5DZCbO2jNHi+v9PFT
ZDM3uZUMiw/W1AEd2gVEAhoNSbST9jPJJJHYxMzQoVQY+cdhftboUlQntgUJ
hemt33264IrgIGamodDxaP6BzgyizXNYKUxTcn9wdVSzC89ZJu7qPoWh+dOr
puz5m+nxvDd0DHHpSPCeg8umqGn1r/R41p5LBpfq9HuDWIWFM5PiN+P44+Sd
KpeQSEyrz/f29oaP8Xpfg8V2ZMzYNeYc836a0efj0cs3yc7z8cvkAz5Twwap
SCqLDGwkzJ8U61+Ta4XQSukxwX9pRsbMJ53jWihArtXE12nNCUBaxzcUOi9z
bs4YoM5IUvXDyw6aAggSqCTMciRA5wPVeNTbTUjsEcGFsCMbuSMDVCBRRuvz
8U2CDR2kpDnwgwN91KSI2YK55FhL1rjbW+uAs+mWMKnAa6zDhbuTokzwFbTb
Wzn6D6SHwQjhZvl7yMFsrGktHos2LrhiMgbHtRB9mIjms8EtvugSdJHQMn5q
JamvxONokdCwpTgw2ahd/V88bVZJsvIur6tSVM2YszrR4mugt1NtDf/a03Id
5CRJVo68uOfRrpSR+JODPNGYosTduDdYsRkZRvgipz2FDpVp/0S5NR85Q/oI
nellTTtXH48ahVFh6FUboHXOVlBOY4LKcDNXNdqdSvxfXOAizdn6IiIrp5vY
fcGap8QnZB/dIzghCYPHGCYuyJGpR/lpuSzFfZK4bhMSnSxWs3+q7oXldPIT
NcNdfEKZ+Ejd4OqA4euqEARItfNKurxacj9Y2cmbrRmK+/HTxcerIMnQa8LJ
uw/QkSBNRD/FMFOY6Ss2Yd+TNk8vZi2MFS/nM4Vtkd3j2sz5N0gVClopSOsD
KIk0Ca9dHVdL6VKSXG9WQiqYgdSGHoBBWlJgkDWbXB/TT34I82iftH+7j3s7
OPwGv+RvuYxGpvHy9Ru1H12+ieKlw+QnVU40EsWz1ixzNl4M3YZDqxqGnsUJ
m8Aoer/3WsZH1VLCE1mv/K07hrNIUjbUfOZpvgNW08SJJkGgSY7iAOnVdGE2
9C8sLcPFspTihEqseTSH63kGBwnm7tw3AQjgVrivQXCbRF/mDbyvX3++Gl2h
oQJ2N3xdsJna6SGKgWDbGQaocVmKBfdWQAWKVXQ7Hmk8Oaz2YDtAOQKfj/pG
e89GbEJ5LuyQpLs+tGyn1GWkSxU1J4Uxb5pnkrgpHsh8JtVfeYVEm18VzS9M
U/aNAcQDnfKE4LwURZNuds43NVzCEyQ2VoCceQp8JGzh1FOLT1FQSzRx17pJ
55mgr6BtNBjdmguuGzT9lrWmxQ1abC2WehlfvdlHLPFX9mT7Yx1GqHaMC6Tb
LjWyVhrTN/tGs6cl2BxWya5L6XnqWFusZGtEWXuYyi528hJjZ7ijEcFvzjQX
g9VB7USy4fi3XG58ixILZD58xLXaub7+uJsIjjXdgpCsNaoSn2dwijTLXmqV
pL6VYm2yAheM6uYWSArWitFLQ/AfLNOEWwVxllE6ZaSdaP2LHEWt7KZWdEAn
7qLSIWRs5mKLWQ7lhcRhnNLoPLmcvepSZlC75WpJXKEBfqyhYm4XgHKoRSYC
3J2N7+JdOxzDvm3gclPvwXW7BrsF1Ta9Zy3CFXeCa0U4pwnRjxSwCqY0u6FA
j/8uG3MP4xzPiZlgrhq7Zds3bLw1Z9Ys4R2bO2asfheXGIt4jJTlNFI6iy5s
pa89OnF5XfBZIKMlLh4iiV0ADwNmX/j6e0auKQJEW2smo7zXEOfEQI40THfU
4YBeceayogIJK/cZ/ou7n9ZNYJNoeeXQaGskcKZQXlLudymyLdA3rhdBWT23
nW/Xs1zO1gdhNS5kIEmrFPa0k52Ja27uapWiIojQjSRv5A6mVlioEZ5wzUws
URkoDQIrm+ae07mxII9FgWK8y9S0cZD2rFSLyHHUxlwbbE+YE/FWa5pjY2mc
fEzxsGxLINOlmXu2kNgLI1xyvkgTU4OUPTB6yse8XH/ZysEvZ/YjnSaflLWp
bquW9DI1tYMYqlXzch49Yztxh8uYFF0kNIzw8ct899ke3OBvjiA63hgE+zTU
GsyCyd82DWhWacHeR+nb5K/RW0Gc+ym9k7KJToHRI0JFXMFcJsy/yptbbVKk
jEJyZFTOixcpDxHAQsVyqwZAZaEzKNQMJbX7DgIVN0N67xmZ0YlKTV500mAp
IFhRQ1wjHz/uA+zf0EUAC41CcPXQzzx7AqNJtTaBjI0ULpVg97gKVpE+aRx6
+0xi4lqhh0bxi6xx8lNd5w/BU7PIx2Wku7itj1kgc/sMxI3UpQ71NjlKJbJE
mYXwHwHQMU9JR3XWcEQqfLYOo1zdEwsD8mOPWSvx5yLbvnjxyVknSPqU3qN1
r+pfQjCW6LcIQ7UMO2RKSeOyStMobq6aBKdoEgltXWxN1XfXgzW0TTklXbm0
aBnjEfiDthNydV+GcKmDiiiyGVtfdG14iHwJXAwxUZeaA2j+YYmHJv9GcyoU
S7xlexG4F1HyvfjxxbkSYPNER35sB8Np8eqf9t2zwtR8QyTxf/tjDZ921p3m
A8wLzc3N2zDfXRzOTXD95k4dYzfHOOGCNy0ANtXDz829PMBYlKslDEiof1VV
rAjHIs3qCKzbLPeB8jNxUA3gxFIi06OKNZHIBlUwQh2UNL7QeoktwpWrMoJl
TtbFrTpzWFlnPujLssmIQOl9vel97VBIFePIEJIHxeTAWp0miKVLVoGVM9BZ
L6qq6THYTbOEKA+cgUFBgGRgEV9FnnXBSCYW7OBevxyDLDYGnefP3nuuji7O
WIN/yDbgs3XWaOmMpAdUYAvAcnE1LnLZiC4Zun0d8ywrnnnZqTjvc3c4GuQI
qpt/85Af2QG5mfdYnZlFCG8aXbmTrFnBTyBhjlRckKxKjkSXdOparEKgqJyj
8RiRyBqG5FRcenEppM/XGYo+Umc3il9iN4jzdbaUcuN8cbTCqeRIUmyl5Vyd
Tq0eOq4doTtx+oU9ZKJb0x7Upg/12OO6WTQh2pAsKJr3rdWDZK1OJoZrK65w
Nlp13fpTb4V7ci8M7gkaA7rC3OEd06BPDBdpnhaJyrJnI+h2awIuOqFQu7bc
cQ/WwLQ64rTNbTUtIHkSsTO6KKhtY+Nsfy/5dHUlhsurw+dv4HvQjDe+luzt
Gpz9ur838Mk6omqQ6l2ny9UIOKqxdqDZTq5C2fqx95ySA0zlO+4YhFzjEfLz
Y1Li1gSpmmpqrUfz4pYRTa4KWkDFoXc27+Zj/Mp5lPRZVWdWUdQ1VCoHgqcb
orgLwVnnZZgix2khDIYebo8A2mJEhuqTzglCxMjmXzLifi9JBIc0lIRyJU7w
FiVQpgheddq4CKGZ1DEReGwS4LEIlEkiUCZI2I6gTZ7Oe9oew7t+z86vTy+R
X3z8+fz68vPH5NPp1dXRh9Pk4vLz9edj+oCXtvf68LnPh+4Z0TBjgl87NxgO
qBx1ImPG1JkIZSgGYGO7j79nayIPcEvM3ee9QO4NwcAOtry06nh62p8UCkJk
uIDifeheFXpfosRmdRnAottH+iypK99oq4UTj6IaedCu1/nJpENLFwxeGLlw
YU4PdVEtKTrI8jvh9+pNTAvBCkrRwlBqXDRdN5PsyGao5ig3PpGioS+qQpuW
kdmsnY1g6QAkYQTEcWdZ8VXmNFo5ul2vCVhGjBxgFPlR0LAuDIdwSzWUy1uZ
MGuTnLnjKmNlipaxmvKPnQsnymDEhsJPWJqOgk4pa9vHHhkla2YBycEWDljv
7e0b+mCRtubmgKHUqzwkATZNk7khOdIs6dfrFTBhgkLEyoEJOexOK5Zl1m4u
aeWTvn2Oz/Q0XVZ6wSgqC4t0afaTrvKZAGSVbkqwwjUdLhL0MVSrCMrQeenS
EYTJBUKzh0lwCp0IS8vv4B2bkKJSWtnMcpmV1g/F7aS71XEvme6ZBYckSnqX
STEZu7BxNSHtMWuDHGbMRng5pxQqXC2UqQXjcKYeH08Sg1Bl2ZCAYu0FJlJa
z8xRzRzxMQUy5AhIoTCPjEF2MI9+j4TFYcRYLZE7whuSjd046AZVtzXRAzzD
mFvPyej9c24epjmFBZMUy739Vwz4JMo113AsJ/nNWoviOm9Vk9YKT0UX8KpW
BCITuB8KLrZCg855mteGCIBxuYJTshbUW57sIBgsZ7FrQLbClqL9T6RHOQpX
rChDWJoILOylExm9MxRCPVXnexiMPK/aIDnv9Ph8N3AV87a92H/1xjd9dSku
dL5rBal0L7pzXBDyI45MBGJtS6YpXlOAa8wZXXo7gowXPzViITcAcpbqmVS0
oTDhVmSRJERImjYOPE6aGCefOLdqq1uYtXJXIg2qWmkAgXtVB5udQTAfawtm
CgOD4nmcgY13MwQDmFLAXZ3b5G5dILlZuSDymaQ7veWo0oyYVyWCgkWK5Wbo
bzWbYlLrgKTVMvRCxDB4W11G+WKt0k1RCRnfpUWu/Z7/2IqDvhByfzu6Y4Cx
GXq9aH9RtqSw7dOFd7vHUaFgTGcVBskm61Kj23q3vd83OMSwcW68LVo5RUZg
dClTDyDphhOmB1oKsGiGrsLyYPzcKdcvX75EjreUxWOj714ZYIEcJ0SXMGlx
72jTQxLPWirJThqclh11sHUyYIcp6klqz7WwBsUnGeqZoD0aKQETwQRyx10A
tAuVdkIIgf2ohMBBPQ5Reb7Ge9VYcycjZinSkbydaACnlNGp38hWS6MlXOy0
vGGP9vYlqNjI9XU6JKGuazQZ0cT/oGLUQBNRbeEAFJ80O+yXgbHhPnr3+b3r
aXVwEOAyjg60iKD/p6+in75Si8S0sz0uc2YmmEomlXh/7rP0lmXJqKtasbHh
FT7jjwsLILrGd8KZRRIUSGZiW6XJbpYO+A7T6PJAD6ChpZ9v9pwdyEnQWauc
bGvQhJv5oYnQNOAfmuHb0xjQu0O7AiAA3M6+LFJOZ1afUtUBZF5UaABpLfws
eBzL9MFEiHqO6qUHrDQtPsoFocE6tPCPbhSrkNuU3FvSr+TGa2wM0Rnejyjt
4lPFCmyvVa1NRgFvxIGKtK4VRa7FdG4QNpSoj8HxWZGVU1rc1IOXamG3wLNK
WCIsXgt04mEQLbdeZqLQoqA+NIIa8/rLjwEZNpT8AI0qVWsBUoN34DKL7CdO
yPhMU9q5vAaKMf1ZW3oj2D0GM1auzww90qg4ZuQs/GzvU4A0wdMhxb2NSVue
ulhVjs6zAO9PSVG8+aF54HUsJRxuapi3BqbPQGXZl1be4NQTRoWSOjtAhXoO
4LrZIgFaw43iyYEHuGmJk4FwtErYA0Cy4djFxKSxBjNiCgOpaFlwPYc1SO8G
NXmDVCnjHRMVCXlZGJvmvzZUNGWrvhme0ZRkJIkODlrIl3rZkHdt1B5uj4aq
6/jocdaVO3lxC3xLlNh2V9TGmRQER+xZmgilUgAdYKmXqN5dL1deyXSPtCYo
XGe1DqTsdgY7CGyAnKuBH8Yz3EghKXIrSw7RuSQa1mRtaw5tRvu+vv4IrwAD
fv9UrUg7X0t08DnJFVZug+QoBRI0dsTU8PzgpRjhLIBXbdDB1MlkPcBQfbW6
SR5D+mRaoTQ0md9SAHzYu0UMSZgsTIAS5rdurNKTbbqKG/zKI2bDMcMQzZTz
5HANO2OpsTbAYWtxH6vJ2CDXKdJ1Dkl2PlxffdodKLfbQ1qM1R14wNlcdX5D
zVf7ES7RhzyLTi1hB1dU2rnV6Ej5oPTBbKouERnspJJYYx576FBz0ZVF9YMv
yScI5RzuoaNz+tYj7spABQzMfi3jVTr9kbZkSgyOBGBNByMK+8BtPAN0EENh
VDUOfMJgH5EoFS5h32uSnej1wNi7QR13VWv5s3mKHrpkrI9MMm9KOnut876Q
xW0PxtsJqKKaWAQRKdETWZ/C3josx3DOI4avIsYYBVMrv9ZaGngeGmX5+lmN
6Sh6Jma9G1zrbAWm09iufmGSv0WfvCnto+VimLHJPVikLEjroOMhOcyNDg2z
IFTI3gxQIKIxxPQChctNNLjufE01piAmTpOp1m5QOZx9olXzM3E2mUDwiQmG
AFKSlpbOPEsRQNlWUr/Eu21vYfrfGF/Q+89OT7m7LiCvDlSlEa1TMAeveXZF
vgf2LYNoWC35MNmotWav455LcmCGrBW3Iuf22ZigIdJXwCfKBXuE0xJcKbtg
hEv3ocmmuzvSWwzZNqtcahc001V2CCoop8SImmTbo7aTTREVdRIB4u1gWMTW
ifBAELucF/F2By3p/DulaSjZ7Az4E2nNQaMIcdf0hlpDJ84W+WvbFt/fwa5p
0Jan5yHBA1IK9jhn3f5BWAlPZSN7YHi6Hm+G5dBKspJ6+q3zVbmvIqtM3diL
rJgNHzHmpJCg33qL3ByK1sqJBbRo7pYZFtroEnl2nA1QBnN3E9M6JBXubiAp
qdZYJ8vFoNGy16O6xWIOzsGKTu4Xm8fn61vH+JokO3Vz73YAIqWoRfI6kUXZ
sZU5YzRzKYrEtdeSpSbAh5LjmvscuwAxh9t0tbkHMxAtEFWMjeCAzcSCc6kA
Iui09ABsFZUO1gYu/KG/2b5znzQnDxw/MofwsanzosfJjozQ2GS9s7k3l4fM
xuwY0VHpQqprBNuo/p9KXZfQpgONosvMFYHQgeM777fDqcTEfNMVEzITqKh3
6o8U/aTvmrriIg/pHovqxkCAIVTp7YiIwpWv/gQbx0n8MjgEbqvo6sEEgCTr
cgQtyYQTorTy1xXx30WqtdfaOsJdSmRIgbRMdDv0mbCTbIDcjFaypk9ztA+7
0MYp1fGmxEhYh3tN4EWVPbFUXK7D47ReSWvyQT+jSmswlc304EdiX5bS2mGY
TLOiWENxRQ6IK9Th10h4yDs9fa/1e5f3ci+1fUJ7gI6RbmfmDumkAjo4JSdl
LQ8sjMuqjBXpvm4i9CpFnNASGd+/3Flhsd2WekcjztskBrIsxOFj7xfkTVeG
nrJdRkODCVnelLrCAQ6511i6pSR4Gca6eMIG2L6B1H5KRdLSaySdggax4vRB
PDe00lHfUc1fFx0BKLDwSbBqSeczg3vcpbSxG1Y9FKYzSPmR3+W0ewdjl4ua
mT5X0CXf0/juSbaxEKxx3SnQLw3ZF9w37WnAPP55gJKHv99q9eeL5BOIZFFx
yRG+8ogXczNntQJQYGU08QKfW6+wCBBFAdbevObGvUQxmcZQORmF5EO2Xczq
rHdtVa41B1bWnRw12oeLX0sm1Tz/kgX+wRPJXRm9r7Ms+T/ABvdVPsUmuNgK
VNQGnbCkcLxjt2lSnNx3fulNUU004sz3B9xJeNH7gCiJo2K9WKXmHQlXdmjC
gDZa6o7rD61RODfJQfNUQUtzc9MhjNnJOEFBJ2o0l8Ehav9LJfbt4TgHgeuE
uXnAMl8vnS9+B2KRq1B994h7jlT5PGA4e7dWa2XDVgf24Ms5s4AbAwaeKl8q
FuyN1AdPnXNSSlCIoWbVuim0MoFdL0pUvKZgACRDTHDwWJCjpTO63Ei8kURF
oyTOapghM0MbIrISYN8nVpboOOrWyrTQkBfRdVdxxzs/LzfnMDTkvhdg17tX
zPqARs3yyDcSi26euzjNeiII55Xn4pwKy2gPbMESKy4DrIQHNqJzDZTso5e2
vsFG9mWRT3ILHfBbURtWoQyGfeCtkAx96Ud62b1F2rm4oxcOhdolJUPyoiLc
RVm7qbTRDTDGJYRhvk3P6uVz7Ioe+RPb4oHDn+AFbPr67FktsWaOO/TFmFG0
hIMhAgjnySudzTiPGU0KP1ZT1voG2i0Qt2WZsqs5PG0X/t4ZnDEXbTeDXUsS
DOE6LDHYvcxe4ICxhTf6hJ7cyoc4u5uJSQ1rYCm5x51/P8S2VcUAPzSL2qi+
EJAPC7joYjysiA3Hy7M1jVWeOexO1xOe/nIrf6aTSq5WBZqke6RGzsHQ84Bp
NLeweSDkVHcQnwd92gzDvAlQJd8AB/rh6C0kQinT2hZh/qr5dqes7YrxYMUN
gp5QZjek2Gryh1bVGiC6ix2GRRceLDN3vVQkBiQRE3XUpZLk6BxpDKzlAhZh
3bpguBMfsnO23zeuGY+LMQVInQ+cnite84gXOuy3hhDOqzCLwYHmSCq73hrx
Zg2YxQZHMhCV1tPPyjVRH7CbLPytlhAGgQNWvrX9psbw7l0LCR9/sNezP0rL
XS2NGTabfM4lDJp74CpXI9QqlsDMAadeWRSMEagJYX4p4rCcE8HgFVNUditp
akO1nFXDoKctsx3ZiCA3lO3bMIDGOWc4MrgRDArdcqzFTg7HlACOwSbBonA8
xuw4B+8S9X9p4t6/PLHRC/bZAKvg/Oj88wf+28fo3FLZTdpobxi8lQYWupyS
cqmWiSzVR3SwK+IZhYWeMnJUoV4qV0FvSVosn/lXnKDRZTHgxexG18t1C522
UIeRPWWXxpxiN6Vko7F2EBT+uOQpcW+79Yan8k0r9h48PpWgkbs5QLPyhg42
c9iD1l3i5gblGtzmlTUa5ZaiEXl4np5RVhUS07LGIZWt1hzMm2nQCbliRLGo
j2Qz2ZBcgoSbYNqe6ssq6jHqbowHvHX3kpiaWOBTqzWCfUjMaLoQwaV6P6r/
QMFhyVC8gUEeqnPmxH04LGHG7YkD3oB90UzzougY5K6zfVFxfkNus+U4gBbW
aPK38GbnihknH7jNUkDO4rJvM8trcmZwIIUU8cZta7jDnv0546PyAZboBKQD
Kjc58QeRNt6ZvgaygcABkHrhC/fc33Lpcr9Jmq4enb7B1jSmXSqgGi1unnNh
mVZI/XJy4V0mI2n16rRDTfsyv6pPhLtXJQYsU7bQySX3DEdANCTCP2e8Oy3p
8K90PQnkbG3ifNU1ay3uHWK/+LGxQFcQ8SuqG4CCuvcV6HqBpuKygniS3hfs
WHOXI1RaA81nW0ucyTTsoPVSA+dS13wMWgHIgeHyEkdvqyXbyeLAyJ29FcEO
m8nYsRCNqd7hxQZX/aCz2zv4si8tktGlsaCvt2WUjRgsUW9uBL0RpMuMxIUW
Qj8v01tJ+LF24EEbMN/nRDwXqeATEHdTtdTF9MJZrDhXfapAyA/KTVu1dbjH
abEThltRCJySfTf6dDGiT9jtolaSytcQx+Li6PzyA01aoqUWAdnfe4GWPfhu
RP+WVmjD5CN6HJ4ibNMOhcZ8gt0RmbTJCTs1q5q+hR4OclqrCjSTKWiUIZqK
2Q68kpWtJO729vWrLuf3kA09xIAdzakChJsUj94iASqdoegiM8AdD3/T4Xwd
94Fz/TNdABrjLosAloJSiH4wVwm6IqLI3lI24eySkXnIg0DH5k7qfFIwghxZ
RPBuARjnU5sYRZOck4k3LtQUU2acYiRVE6SoWRKyqXvai8SEV8UOhFw7AamE
geowr6ZrlV9e67KjCgJnfZPgmpRM+m2Hs9hSPdVvtP0CH7aGsEeOlytJO0fq
1lWbrQTVziGo7aAnNFJEuTf0k/7RJ4bxjlNVD7UVeXwqdiWkIfXo+Kejy+vT
y5FUgODhD2dX128d2LVHsOTX8fv8NRRT9PC1Pnp+dP3svQG6Yfhgkh8ZFsKD
FJ9ffTSQYhpAccC/6RkBZuNU61E1HxlIoH/MBn0pgx6tiWAdWDdv5GOvsRzK
wzf73ovMT/yqG/lByJv+EmLzkHhBN56wIkEgMTzgvCYeSbOE7XYNRKtuF3H5
aVulj3bdpMWuqiO/QmYw0F4I9Oz6m+RhBTfjTPlgkDXzQ9kmMqdWKlHgz6dL
Zn2vgbZiENGoqXLhS852gf4goJQaGFLR7pqwtf3b9ij9OThfDln7/ERJ3p1V
0h+dBZu3y7GNUaNHlJMGHRrqKg2cbTI0/ArOL+CjqoyaoynLmofusspz3W6X
+eKso5n2jHq5d/iSc8KSx8gmirGzjjC9ZS8lmK5uolS5cHkrwyA4vsbdQHyb
Zykzl24cDNHBiWY0AVcwKIZHznjFaGPsCvwyRZTSbtOtgUei3GbGEcAoWKLu
kADpwCXu+Pn4dlw77vSfuM27zK2rlWTKcFZgNKQPNzqVyI/tGdHW2NcY2yug
+Fta43bcaMy7iIBJEcR8JMtaf/U2+dZV/CGeFKIE8Av+Ga75DRjjzjJXsSa/
CUHBpNCc5YMks1SdtPyR+RituRwINPK/yOeKU3P26MNvY/cRr9ghwFlgkbs6
yk1HZoRGDOa4qHK1/SVX8H+7p6oq4W7JIDFuXR+zHnJPjntBuS1nzhdBE19P
ocvLQE4pETXCu67MfMrN12/oXL46TkbowGhl8zn3BXMmnOZp5GU/xhUOTgYy
XPIOWFNE7mCWsJal6xOnl7KFQWrPisGstu4t2fnjbKhTbZsgMzXC41EX41bS
04+N+TtkCGnL5AB9mGkGiV+SI9CmhmHDIQkPqiJjBADMmsjEkBnB3M1Xbyn0
ghmr74GNxqspvYuXtGZAbewwWQmH9RmYEo+ibdplrztNT9cirxkLuQISU2nC
sqoF/PXuVXIpR3NUkN2SfJbg2s7l0WfGLZdkS3eMbkGuzEnCD72nZKfB9G5v
R4qCQwJ2m9dPHuL5riUTRAbwuYgic+wB8TvSR/xmmhktQNF0huw0Km0EJQur
VOMbix8LzpMmnqUSjSky6NruxHIA3/M21GivcwejmR91zn+BwjaCCfwQkr+t
ZxNh2gW2njqJvFhVRjdnL2ReytOSxPzi8I3V6iLTptXws8tu5XVJfgXvbd99
bqIenlxKY9lzaYB7cKSuPYV9zx0lqYv+kQvaOHHN5ebKHyWDQEaRgJDgRBCh
5yvDQpTptIbU1vjMgx2GEdr0McuscEggkrBfsJmhoYFmCnzicvPWFyruGGU3
7A604A0f+K6F0zl8LsxpXXLaWaa4iJodrjxOlsF2PKrzDHiwuyzH2VsPdmFj
NGzSNV55RUUH5yWh6FD18Ao+IVaDkxNX9GcifOekukI8EzPgGxwyYM/xhNnt
qjcRrkYwckVoCqHigxgKxrnoP3BT06yDlblmPGxTiu7lO+wiBF+1+s8XHlol
IGlJZrZtVcAA64BcWoUXi1BVeCQr1zGasFt8WOMuVtKuIq0Bai1QCo68vAfl
67htwDyCUlpxxIui7x0qmsua+wQYseMl9XxJXFvn56yBIM3h1DH4YUdxDrum
QvBGs5Frfgs3LjLnNiWZD1PnbRQXbmpY9M6XjYupSguLcrCGTbITEp5gN6k4
301Ie4G5wTBKLniqdOtMHrcuZ4jbRIKFKhyAUxPAuWQcwRxztCPZbOhALqlL
DlQotVwSfb2DUN6RE0DaHZDX2BxzXUzoSvtXAah3ZThJAiyONHGgy3Oat95S
Z/AGwyQTE0eOubs78dDBjZP3Uj6xrKT/k4zQBQFpNyvXUp0tniaEjJCIt9mV
gViVnBrr1WGNbblfLKdpqVLF+blAO2JgFY2cPQZfAXTEm0o4DN8HTkmEXil1
6uq6cScZ5dPnoHavq/E9eEpiJFJs6ILc338HW49WC7zD6D1nFxoi8C2FJtmm
cj3+unP6/ruet0mzh7GWDpkSsP0+tfMVPVUC5MC9VUgj1wXa8uDsPsTtVZzk
+7d+k10Cm2tprs2YYlst6mIAt77J+CuoTAraA8CB3Hul8QovdpJJIxZwBBdk
U4YpCBbsUuWoGQtMFO3uYqAZkktu+KUuqRq9JRPfW5I2jUPUOp6Ic5xs3J1L
2qSie8lTtLEw4mMULaEQzijXHPhx6HdFRC0TxBKtd/wDeq8WoTwAhcsLxpU1
aGvRttYN3d3IwJL5hb9kbaRZ8w3naqawHE5QbUnp3NiUWb2cMs4V4+YbPgTP
5fjiF3bTc1RKZ+qsF7TuvNHKVdN5OVHU1FlLGHGm5MBBsw5ULeAUrsBm0XRP
fEQT03oopF7VQ+3ro8nlAXKyoZxhy7kjxsd0QgLp6w/vP34DrlnnqQDUrPNN
3EVNFIqXL15rx0FOWVNUIiAHPN8bTQCaylD3wSjyQfC0pU94FyFSjGbcE8g1
u8ToGuaUAyyndiVZFZU2QpJhyzs5To6CtLEmUyxvqfaQF+WNToaNl8xwA/il
qyZbz6qRJE7DGrQMKB5AMOadhpv7xmKSy7VR2FZeDJZe8NLl5dz7nPXGv5PK
qQA3rw5fw+d0FLhkr9RSaODTQpIHrfsddPhjNPCiRV1oyI6zvCIV7M3emwNs
bLTL9gc0QNoZ4gFoiSF7FmX0YXaMxT/iCeqswx0jq+UoxjkLSwCkkqOqpJwP
tyyqmJPNaLzpG/ApTbSwHEbBe4WtJ7AH6wn7BQTBTIbGwWmCvUzUYnlbKSE0
6ev4PDjd0ZEQd5yhLdFWv2cXJDMk31hQZsBOVmtnfSaMbpEFwV2azsgV9Sp4
knkqBJMAQCXEXTarVuk8vApvrGL2M2i7ydot+gGTsrypEC9ZIo705SIrVvpN
B/pIvPm2gW7ZZpy60+OwhK+oh5ajeSgOakO0D60gZ5hNqHgSz3BihJemYZNX
z+ED5+2HGbaF6N24tn5iDFUw7QVH4z7I6GFe4CbqlgK2am5KDpqTJrj2vMS2
Qd0N2v07BPB1MPmBW4EHclk4pmkYYqjlmAQnJ9ePT/70b8gROoYc8KHQS023
3Tk9/nQhJiHaJydHujyWjB+PPuzufhMSIofUFQnXU5IkEj7GFYWkPFlaLZbW
mrhMec6kjCg/464eFZfzMaC3c1VogqEdIsph8rDBW3mjvaQYHu6+CrQn6Cu3
2aIqoFKr4ndqPDv2GL915Qodwu70KPdYadHVkeqeEGi7h8ORGdWGUqgjqFyV
kRbMGNPErb3eHr8MKsbU6HfyyLhsDCUdT0iH1dkpbEzwc67/mTM5s6bLRijE
T0BSISOUhCSbnssJVsw+V6wX94lxx8gLR1yKfd7AVaBbl5aICrFa3WpujUFJ
9hTF7EjyG2KWmHzP7x0Z2qWHrp6lLahglz3RY8vhcfpSWtcb76b1Rx41zjV2
tXXoyI7p97AvqtxBl5qxB1x/oKMpPkWQuqwNurXJTZQP4bCBA0kPgpjks0Zq
7EkWz5SZak2Zz9nvqg9ygwPYqbDwPPgxozdxMjYX1qJjj0pN1bvFq0cmVToK
WbLDP6rTPEprUQny0EYG90QhGqS6zJAxwaZ7mtw5cHf5ncE+O7gKLlV+4ha5
y6qhptDfZK6YAJ+b+YYGnFyROsMfKzYE2zp/N3GSRg9utYFixA3phtURbiwz
WRRDd3GpWsQ+z7t1oclOAAb6DGm5+WxWZJPqS9bsOupzfW0DlmHrk4LVDa8j
YoHMxHghD+SMqaNvWkDFnYvm6jQsXUAgGfVejJNfDOAG4STdbWtJmfdsW1N5
ZhLXNkvFvCSeRhlpZODMfLJ+67qP5ZaGWGhrjSBW7fA8ptarKfRujeNTZyNT
tsuiT7F6GCZxTkLowL/5HvECRi5WOgg0LEAYhRlG3K9BKzK73ZIVp8O8wkPn
tFcZ2lHPPck/loe4re6m5rNHATMSgM2oEjrB/NeCj2EUPlYlptCmbz6T39pC
aX8PYFcwSiMGUBdW0Mum4y0KKCq4GU72GEKZXQsma4ajCizooWZxtkLY6QzR
IoaFnHuLW1IqSetj35wPF0lYxxCZBaYpFzwEbZ8rSCl+okMHnwQdTsCL4RmQ
dDkMGbH+UHFw/nVLrvAHapJy49uCielEzB13D51QXWvMmdlOauTkLp9bYaAj
C32F5hCt+DwipumNMzH1Qp1DoPEtW70Djd19MCAu+ikPA/8Rst7gYdZ4D8cT
hOnrwKrqqYiAWFBgf2Nnk41/8dDH0KV7UNDqG3nuUl7nxFEwJ9GHGzgDzmMg
WMdKNG1ZOSxzqWzJ8XxtjOqjAvw6lgzMuGm/uCzfEqbF4RBUdAU99mAncl2l
zGeZwhvl0VjE+S2ooeaQ8EjNxNpWYHGwPdkdZC3RxOSiDV/osRnmWHIwauHg
i/i681bUmesnlorZhlnd5VUROnbUZuOUMqcqsCQPanl8v2DInshxZoApHlzE
9KBGfco6nsLhhQ1el4w6iE4CheYgS/vJKuk6e53m5jPRAtxtLU7m2YN5PXM2
bAQi6hgpGR/xVDrc04Fua2pqCIGZM4AL8/Y40dZvVzVBnEYoTRpvwZhN69jR
Eb82wnXW5bLUAr0jrZszfluvSgylxITDTYJurOkWW2LH+aI7KL11NjJ9Mjbn
gxZDO9ruSRvbqDBxPddlohy0Nwe8X+xUs3PSMN9osa5nCrfuTliEbx4gY2y0
+WKH91g3nW7vJGfTCK8XOMapRATVdUYzG9xorAswbh8uT4+uTpE1KeUW4jVV
l29guZJcUnjQuLwNaFoZzjgPWaeCs92nmwDV6AFP2xh0qDgEe4cOq1fOMMDt
E0XM0XDXyyj9geBHs5KxoLDVsR6zDbeg97wS49pryVYw4R9dnAUmnrITc9+4
XrHeSVRLddXGnxTrDU7cS4sQcWvC2eoqyuhFjbU3VPzhvIlby1iltlrtygPV
zZYFiMzEaYRsf/7l7Bjthen/Rr9+gDcUlepN0I+dbR+H16eZImyQQfwFRYKT
SjsDCB0sK7JTpClUmd0bCJTCLD2kZxoyxjdCo3/9IZuWT7v1v3E07+2/3M4B
+BmetOSTawbOKw3GO0L41xo6RyE0yT9+AfrldGukKxKHSAupW5996/To19Y9
+/nLN5pSjnUfqaWOs/7jYwmePMc44uy7y4ylcGUtpWU/WYz8Na0ZlRpFDexw
//r1jhQzsp5pCPjXm4KzFV/xLr3uGRyfn0QttGheqBiFIfOePp5pKCVEmWJ0
H0s/RrRymf5W1Raf9Rjzco/Zicp9xyUNeDtVVmLE3Mw2nQVgZ+glNm0NsdXt
o8eM9wCETRWgImuKkqZvcUcOwSKuGVDWmW5NFg4Lkd+aWEs5Vsr+d9/zLXde
PddBm1jToKimt8R7B0PF8IY1PioEd4o9ScuqrMBsDNuevcGxm5BFJAZjhFj5
gRtQf19niP8zhiz/PC04sCd/C5IPjxh3lhnr8YVwhm0EBjpMBkfSYL17uQbJ
ztHPn3a3etpEgiyMD9GvmRWRbYainF69jOHwfIQkauUihaJqYOlxBamT7PpA
jlMD/6xiXSdo4ahkIO02ZwHQ9RaxCU+VcidGvZAMWt4cBdJihGoRtkqCvGH8
sah4ZkKSsRP1/B4nlwJrdMoX5SSzNtE7l6cnu9q+OBOjbWXsJ8KrOxK3ZslQ
Uirehr4LkhAhDWa3Kd5xWZJMGsSGBuip9JmfCRnpbjVSosX05zf0PoyTkeos
BYy2/8joYmOpsWZd4oGwcwoY7Pj/ktz/Jbn/cpL7/rtLD7YYqCFB83bGprBu
6yH3LwPh3AgImvJ9poEHMkL8svlglFGLyFnnhbpoqsDacaMK4j7SKBRkGLs7
Zx7eiLuimrL6OYth+/m9+iL8ipN4ISxrBzTvfiY9NbkVh+snZCTsW6ZKgS/d
DHaVTdZ1g+BJXcOd0ASJsWLkibGly1DbSrE/pHpf7NBT1w7RFbGItjTsBewM
VCBVoW+RIS8VFaqV3GshikvriRyFDa7DwhL76EvxAIuPiAMyTx77MOjqwMsp
pcO5L6DiU8D8/idY1qbbb4SfHEjrtHqg02sEgMrtItt8SOALu2Na18ZNNJQr
ovcefB4LT+vyeLd+KZnBLNW/gUe59vlI3I3wF1UoiWfgpTCvhRGsp2sx0iUw
VNUb23CDomkMSsjCuLNU7WVO2TDUDFUGPWvuuH+t2llIGaoJq82iU9JUwlfv
wADdjVugSuVNd1DPUTmJNF3B2z/zjdtciz8r8P769Tj8iNXkylmBrOUuVwuy
vhu3R5a1bIiRumXfXtSkKM2MvSooBADWa9aTEVaNcxnxssMC3jKZFrlURW5/
pYQnp8AMOfq6z6eCkuii581LLiMIIXED2tfjQEyeMdXQeQhg9XgxsWQkEnDN
R4AM3T0ghGWDK8QnoL/Rn2hLt0180zLnAvUBs97uuDtfv7LsO5rRnaBNsWzy
TZRSvGA/LaoRXNpcoih08GLSIO/pZBh8PhiB/YDhMJxbqdZ3kO3pE9FDTUW7
9XKNLfvG0CybXWPuCXrv2UlzjWFpIy3RADPQvgHhY64UglZsv7RHaRSeth7i
xrQMKS8SexFHKaaQqwiRE2EDLkCd1bTFYP7xGue+QVusjW1VmsAeylkKSzHG
4FsM0IHAFIVG6FiKic3n5lDhjQqzoWhjYT6k6hZ12iyGLgi3SZr0PplAkVGz
2AOboOvE5ysSvK35C/ZeH5LMesbpKtdq0B7DfR2mYjx/+WrPdz0IZB3UNq3k
FL1l4B1K6xKGMSC0LCKgnvSu542E4VbDhdjKF4F0Fta5faD/wIo+ySwJn2G9
fth/G8LSSGJoteI6WuRACPIEi/kHf8WFh2Ot7E6tIIbd+Kw0mHNCLeTT4+ud
vV3Yq/jX/m6yYx3usOr1FMIO+TkscDxsW1BrsOu8xrOhg/iqua0JTeMYQIyt
xMiti722wZFgxE6TT3cdlmBMoDF8LMZYlwZt6xtLc7G5C+M5B4e7EkJ6wJ1Y
hTcNaD206zMGxmPlpdZcQEvt1w0WQdW9Ov+aayPhA1IsieVL8MvYiKshldTW
1tDHwkkMneIlqqQtCXsULB+zuVE0JXbgzjJA+LtuVosYiTcr0aGJjp8lPdRi
xn1T0DXXnMLAUZy2tuv4a503tz1DaRhuI+QhpoYuVt4iPu9Qhd+VJQagT226
ida5VZ3IuryIJPoFnpZC5WnK7BH4kGC6j+PxfJ5rSCrWTrxy1qOm4FWIQ3FX
Hq6kzMvArpETVOx59aDa6W+qNXzWnHwnHZFUjOMLjElvWkkVfqf4d7IWJLYZ
c5KGH+BUK5QH8hYjZWOoHBdEov1D8C7HeRozwtjLFt77WUTFNHqtWSyx7opu
UiMF39zuR8mnJQ/3Kb4bjtfyMoF0tKFjkHQSFu96ckMNFdyxDeAFZK1h1hHT
GldP+8i4k7fwctxXtvvDRBoSt9UN91IcBs1u1stlWrOOA0xFbOdNpu6JBTuu
6W34BAmLOCNtL7OFVmS6Gd95RSXaFzmUhQGab3kFaTRApbTKL669pR+xnu86
R3W1A8YUqUT3Y+y/sNjBA61Z9wkH4NfvHdEIyNnoZJxn7XxEc5mO3K+R6ej8
uB3lhSZH95tEkHaM0QQba3phecNttZ4uJI+taQVHdmtJCMqL2HI1ufN06lH/
mINvd1yQE/pVO505W51rVLj8ZRl2OsGhdZXk1Fo4a7YqOIrqChEpSo7Y/6/u
dXKt1bPq1w8tGabKoMlhCQSp/reMk6CHQZnhBwAboacGioZww+Q4MJmvcGtZ
WjZBRoAi4jNOOYtMnj5IjNkAuvkF2VXDuBxd0GYUktBlNDdBLIN3iwk2SNHK
G9cs8QaycybtKf4/yOyk9xt3K5tkHoaRjWKrJt5INZrmB0X3NZSgfS/QYsFa
suOSNIx/dt83mMD5RSabu5BLotfFQC35cEUCnWW4zeuyn0pdN2PxZ8pJdM9K
b7ovQqOviIBEV2Ll55uEAF91VEYgeLPpygTUaDMhaqkm2nF6Q0dAcvn4udci
7cBKLugkYwRMReSJL1K0bFlFx6vgAIPQozFTH0oZeTPM384WY7kx3hHIiLkv
Ig/jzKiONRgmn+Ydu/WHkQNvbZW+YRmO5sOFhXWRBqQpaMsmQwXtOHmnOHs/
Ng6olL1M3k2K1fTxYt+cTCyKvPxmd5J4hXxnvuMIrtAZIuZEcqZds3WbNccr
cnCl7OSQksFu7nKnCwT7teh+ocYHfFRjmpIFoZOzWjZ9RAFk57FrkFGFxfeP
ouCGNQwwGM0wZ8SmDqZYsJZz37Yo7N/89GyEHQSIOeFG6mFz7l9QJp8bCnpg
L4uiHab3crBcFHnOn+LcnKWe3NnR+dGTp7akq91I3x6Gf2Dpjid1kKMphCkp
GVK7JUFYuZdLlNPn2g2ezLXr56Td0NnRPwIUbbl/Hyp4rt+neb2AX94AfnsH
om0DGoQMpn9sDXhJ372rAAk4fmSon0n5uh1doT+VDBd8IBCKnWE/kURNUY8J
zLA5RKxmLrofaTjGXPLWvi3yrwqP1g5f2Sy3HvcP7VzcdpKXvd0Q8p/ZUtcT
mwd/uot2911XKwiNOjlJ74n+xVmvcNx65ozbyLEi7dncmYcSMqcsOWCs8BWn
dX6bnFf1jCTIrfYEhv5xIyDW0nzxgak8sGqGeeTpBVCOZz1QjtvEVXBFKKdI
4l+fUlQS0wg5CeO6sITkB977/qMeYlzk2/xTR4jMpN81e+bxlJynDk8KIdci
oASU+mhGbyppJkAGGtLFmiTvajQcIEl8PP40Tn4imUKWz0lKo9K+0LkMcWLT
5C95WdJ3Qzm/ozWR1X2KdM3O2obJn6HF/VQV2Fr6q8qSa1gy/M86JwJJLmG2
0VB/yWvAvyd/qZarjH4/TD5VixR4we/oiXRGYw6jM6K/1nTN0FHxQ5ZPhlKe
1KTJaXmDbHXtf/4rkdzpbLaRa+22iHR+VNpLilarTYhCHsn1PgMW3iKmoX4M
mAI+ocyW1vkXeJAKHYot1nAAq5t1LjeL74ImJUeY0Qplmm5iYpGKdhXyHTWk
+Sw+11bn6R6zJ9yCpLEwVKyAd22tUt1UT80ROfkFN1XjjlwozIa6DBIgyl+z
asQeYy6faxLJWcW2WO1S+RsAIpO/pLO11I5eErn9mhdtVT6yiO70TgN8+c4M
HSRz+N4rAad5iOilOR+9lMfTG1PSFt+kWgfa3ucIKGvHOuQAMFYbiUu+4hhf
tvp9jlpW/SB3ImzIeJZEyxcfr+Sg33240PCMqGoF/Y/shCH6vgB1zbv6GRHB
JchCVUN0PS1Gx2QSqKo2Go2YYX7/3f8DMtixzRtCAQA=
</rfc> </rfc>
 End of changes. 194 change blocks. 
2801 lines changed or deleted 997 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/