rfc9623.original.xml   rfc9623.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-taps-impl-18" number="9623" submissionType="IETF" updates="" obsoletes=""
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft consensus="true" category="info" tocInclude="true" sortRefs="true" symRefs="true
-ietf-taps-impl-18" category="info" tocInclude="true" sortRefs="true" symRefs="t " version="3" xml:lang="en">
rue" version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<front> <front>
<title abbrev="TAPS Implementation">Implementing Interfaces to Transport Ser vices</title> <title abbrev="TAPS Implementation">Implementing Interfaces to Transport Ser vices</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-impl-18"/> <seriesInfo name="RFC" value="9623"/>
<author initials="A." surname="Brunstrom" fullname="Anna Brunstrom" role="ed itor"> <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom" role="ed itor">
<organization>Karlstad University</organization> <organization>Karlstad University</organization>
<address> <address>
<postal> <postal>
<street>Universitetsgatan 2</street> <street>Universitetsgatan 2</street>
<city>651 88 Karlstad</city> <city>651 88 Karlstad</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>anna.brunstrom@kau.se</email> <email>anna.brunstrom@kau.se</email>
</address> </address>
</author> </author>
<author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor"> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino, California 95014</city> <city>Cupertino</city><region>CA</region><code>95014</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Enghardt" fullname="Reese Enghardt"> <author initials="R." surname="Enghardt" fullname="Reese Enghardt">
<organization>Netflix</organization> <organization>Netflix</organization>
<address> <address>
<postal> <postal>
<street>121 Albright Way</street> <street>121 Albright Way</street>
<city>Los Gatos, CA 95032</city> <city>Los Gatos</city><region>California</region><code>95032</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>ietf@tenghardt.net</email> <email>ietf@tenghardt.net</email>
</address> </address>
</author> </author>
<author initials="P." surname="Tiesel" fullname="Philipp S. Tiesel"> <author initials="P.S." surname="Tiesel" fullname="Philipp S. Tiesel">
<organization>SAP SE</organization> <organization>SAP SE</organization>
<address> <address>
<postal> <postal>
<street>George-Stephenson-Straße 7-13</street> <street>George-Stephenson-Str. 7-13</street>
<city>10557 Berlin</city> <city>Berlin</city><code>10557</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>philipp@tiesel.net</email> <email>philipp@tiesel.net</email>
</address> </address>
</author> </author>
<author initials="M." surname="Welzl" fullname="Michael Welzl"> <author initials="M." surname="Welzl" fullname="Michael Welzl">
<organization>University of Oslo</organization> <organization>University of Oslo</organization>
<address> <address>
<postal> <postal>
<street>PO Box 1080 Blindern</street> <street>PO Box 1080 Blindern</street>
<city>0316 Oslo</city> <city>Oslo</city><code>0316</code>
<country>Norway</country> <country>Norway</country>
</postal> </postal>
<email>michawe@ifi.uio.no</email> <email>michawe@ifi.uio.no</email>
</address> </address>
</author> </author>
<date year="2023" month="December" day="14"/> <date year="2024" month="November"/>
<area>Transport</area> <area>WIT</area>
<workgroup>TAPS Working Group</workgroup> <workgroup>taps</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <!-- [rfced] Please insert any keywords (beyond those that appear in
<?line 100?> the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>The Transport Services system enables applications to use transport protocols flexibly for network communication <t>The Transport Services system enables applications to use transport protocols flexibly for network communication
and defines a protocol-independent Transport Services Application Programming In terface (API) that is based on an asynchronous, and defines a protocol-independent Transport Services Application Programming In terface (API) that is based on an asynchronous,
event-driven interaction pattern. This document serves as a guide to implementin g such a system.</t> event-driven interaction pattern. This document serves as a guide to implementin g such a system.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 106?> <?line 106?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Transport Services architecture <xref target="I-D.ietf-taps-arch"/> <t>The Transport Services architecture <xref target="RFC9621"/> defines a
defines a system that allows applications to flexibly use transport networking system that allows applications to flexibly use transport networking protocols.
protocols. The API that such a system exposes to applications is defined as the The API that such a system exposes to applications is defined as the Transport S
Transport Services API <xref target="I-D.ietf-taps-interface"/>. This API is des ervices API <xref target="RFC9622"/>. This API is designed to be generic across
igned to be generic across multiple transport protocols and sets of protocol fea multiple transport protocols and sets of protocol features.</t>
tures.</t> <t>This document serves as a guide to implementing a system that provides
<t>This document serves as a guide to implementing a system that provides a Transport Services API. This guide offers suggestions to developers, but it is
a Transport Services API. This guide offers suggestions to developers, but it is not prescriptive: implementations are free to take any desired form as long as
not prescriptive: implementations are free to take any desired form as long as the API specification defined in <xref target="RFC9622"/> is honored. It is the
the API specification in <xref target="I-D.ietf-taps-interface"/> is honored. It job of an implementation of a Transport Services system to turn the requests of
is the job of an implementation of a Transport Services system to turn the requ an application into decisions on how to establish connections and how to transfe
ests of an application into decisions on how to establish connections, and how t r data over those connections once established. The terminology used in this doc
o transfer data over those connections once established. The terminology used in ument is based on the terminology defined in the Transport Services architecture
this document is based on the Transport Services architecture <xref target="I-D <xref target="RFC9621"/>.</t>
.ietf-taps-arch"/>.</t>
</section> </section>
<section anchor="implementing-connection-objects"> <section anchor="implementing-connection-objects">
<name>Implementing Connection Objects</name> <name>Implementing Connection Objects</name>
<t>The connection objects that are exposed to applications for Transport S ervices are:</t> <t>The Connection objects that are exposed to applications for Transport S ervices are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>the Preconnection, the bundle of properties that describes the appl ication constraints on, and preferences for, the transport;</t> <t>the Preconnection, the bundle of properties that describes the appl ication constraints on, and preferences for, the transport;</t>
</li> </li>
<li> <li>
<t>the Connection, the basic object that represents a flow of data as Messages in either direction between the Local and Remote Endpoints;</t> <t>the Connection, the basic object that represents a flow of data as Messages in either direction between the Local and Remote Endpoints;</t>
</li> </li>
<li> <li>
<t>and the Listener, a passive waiting object that delivers new Connec tions.</t> <t>and the Listener, a passive waiting object that delivers new Connec tions.</t>
</li> </li>
</ul> </ul>
<t>Preconnection objects should be implemented as bundles of properties th at an application can both read and write. A Preconnection object influences a C onnection only at one point in time: when the Connection is created. Connection objects represent the interface between the application and the implementation t o manage transport state, and conduct data transfer. During the process of estab lishment (<xref target="conn-establish"/>), the Connection will not necessarily be immediately bound to a transport protocol instance, since multiple candidate Protocol Stacks might be raced.</t> <t>Preconnection objects should be implemented as bundles of properties th at an application can both read and write. A Preconnection object influences a C onnection only at one point in time: when the Connection is created. Connection objects represent the interface between the application and the implementation t o manage transport state and conduct data transfer. During the process of establ ishment (<xref target="conn-establish"/>), the Connection will not necessarily b e immediately bound to a transport protocol instance, since multiple candidate P rotocol Stacks might be raced.</t>
<t>Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the properties hel d by the Connection or Listener cannot be mutated by the application making chan ges to the original Preconnection object. This may involve the implementation pe rforming a deep-copy, copying the object with all the objects that it references .</t> <t>Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the properties hel d by the Connection or Listener cannot be mutated by the application making chan ges to the original Preconnection object. This may involve the implementation pe rforming a deep-copy, copying the object with all the objects that it references .</t>
<t>Once the Connection is established, the Transport Services Implementati on maps actions and events to the details of the chosen Protocol Stack. For exam ple, the same Connection object may ultimately represent a single transport prot ocol instance (e.g., a TCP connection, a TLS session over TCP, a UDP flow with f ully-specified Local and Remote Endpoint Identifiers, a DTLS session, a SCTP str eam, a QUIC stream, or an HTTP/2 stream). <t>Once the Connection is established, the Transport Services Implementati on maps actions and events to the details of the chosen Protocol Stack. For exam ple, the same Connection object may ultimately represent a single transport prot ocol instance (e.g., a TCP connection, a TLS session over TCP, a UDP flow with f ully specified Local and Remote Endpoint Identifiers, a DTLS session, an Stream Control Transmission Protocol (SCTP) stream, a QUIC stream, or an HTTP/2 stream) .
The Connection Properties held by a Connection or Listener are independent of ot her Connections that are not part of the same Connection Group.</t> The Connection Properties held by a Connection or Listener are independent of ot her Connections that are not part of the same Connection Group.</t>
<t>Connection establishment is only a local operation for a connectionless <t>Connection establishment is only a local operation for connectionless p
protocols, which serves to simplify the local send/receive functions and to fil rotocols, which serves to simplify the local send/receive functions and to filte
ter the traffic for the specified addresses and ports <xref target="RFC8085"/> ( r the traffic for the specified addresses and ports <xref target="RFC8085"/> (fo
for example using UDP or UDP-Lite transport without a connection handshake proce r example, using UDP or UDP-Lite transport without a connection handshake proced
dure).</t> ure).</t>
<t>Once <tt>Initiate</tt> has been called, the Selection Properties and En <t>Once <tt>Initiate</tt> has been called, the Selection Properties and En
dpoint information of the created Connection are immutable (i.e, an application dpoint information of the created Connection are immutable (i.e., an application
is not able to later modify the properties of a Connection by manipulating the o is not able to later modify the properties of a Connection by manipulating the
riginal Preconnection object). original Preconnection object).
Listener objects are created with a Preconnection, at which point their configur ation should be considered immutable by the implementation. The process of liste ning is described in <xref target="listen"/>.</t> Listener objects are created with a Preconnection, at which point their configur ation should be considered immutable by the implementation. The process of liste ning is described in <xref target="listen"/>.</t>
</section> </section>
<section anchor="implementing-pre-establishment"> <section anchor="implementing-pre-establishment">
<name>Implementing Pre-Establishment</name> <name>Implementing Preestablishment</name>
<t>The pre-establishment phase allows applications to specify properties f <t>The preestablishment phase allows applications to specify properties fo
or the Connections that they are about to make, or to query the API about potent r the Connections that they are about to make or to query the API about potentia
ial Connections they could make.</t> l Connections they could make.</t>
<t>During pre-establishment the application specifies one or more Endpoint <t>During preestablishment, the application specifies one or more Endpoint
s to be used for communication as well as protocol preferences and constraints v s to be used for communication as well as protocol preferences and constraints v
ia Selection Properties and, if desired, also Connection Properties. <xref secti ia Selection Properties and, if desired, also Connection Properties. <xref secti
on="4" sectionFormat="of" target="I-D.ietf-taps-interface"/> states that Connect on="4" sectionFormat="of" target="RFC9622"/> states that Connection Properties s
ion Properties should preferably be configured during pre-establishment, because hould preferably be configured during preestablishment because they can serve as
they can serve as input to decisions that are made by the implementation (e.g., input to decisions that are made by the implementation (e.g., the capacity prof
the capacity profile can guide usage of a protocol offering scavenger-type cong ile can guide usage of a protocol offering scavenger-type congestion control).</
estion control).</t> t>
<t>The implementation stores these properties as a part of the Preconnecti <t>The implementation stores these properties as a part of the Preconnecti
on object for use during connection establishment. For Selection Properties that on object for use during connection establishment. For Selection Properties that
are not provided by the application, the implementation uses the default values are not provided by the application, the implementation uses the default values
specified in the Transport Services API (<xref target="I-D.ietf-taps-interface" specified in the Transport Services API (<xref target="RFC9622"/>).</t>
/>).</t>
<section anchor="configuration-time-errors"> <section anchor="configuration-time-errors">
<name>Configuration-time errors</name> <name>Configuration-Time Errors</name>
<t>The Transport Services system should have a list of supported protoco <t>The Transport Services system should have a list of supported protoco
ls available, which each have transport features reflecting the capabilities of ls available, each of which have transport features reflecting the capabilities
the protocol. Once an application specifies its Transport Properties, the Transp of the protocol. Once an application specifies its Transport Properties, the Tra
ort Services system matches the required and prohibited properties against the t nsport Services system matches the required and prohibited properties against th
ransport features of the available protocols (see <xref section="6.2" sectionFor e transport features of the available protocols (see <xref section="6.2" section
mat="of" target="I-D.ietf-taps-interface"/> for the definition of property prefe Format="of" target="RFC9622"/> for the definition of property preferences).</t>
rences).</t> <t>In the following cases, failure should be detected during preestablis
<t>In the following cases, failure should be detected during pre-establi hment:</t>
shment:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A request by an application for properties that cannot be satisfi ed by any of the available protocols. For example, if an application requires <t t>perMsgReliability</tt>, but no such feature is available in any protocol on th e host running the Transport Services system this should result in an error.</t> <t>A request by an application for properties that cannot be satisfi ed by any of the available protocols. For example, if an application requires <t t>perMsgReliability</tt>, but no such feature is available in any protocol on th e host running the Transport Services system, this should result in an error.</t >
</li> </li>
<li> <li>
<t>A request by an application for properties that are in conflict w ith each other, such as specifying required and prohibited properties that canno t be satisfied by any protocol. For example, if an application prohibits <tt>rel iability</tt> but then requires <tt>perMsgReliability</tt>, this mismatch should result in an error.</t> <t>A request by an application for properties that are in conflict w ith each other, such as specifying required and prohibited properties that canno t be satisfied by any protocol. For example, if an application prohibits <tt>rel iability</tt> but then requires <tt>perMsgReliability</tt>, this mismatch should result in an error.</t>
</li> </li>
</ul> </ul>
<!-- [rfced] We are having trouble understanding "finally" - perhaps
"finally" can be removed? Otherwise, perhaps "ultimately" would
be more clear?
Original:
To avoid allocating resources that are not finally needed, it is
important that configuration-time errors fail as early as possible.
-->
<t>To avoid allocating resources that are not finally needed, it is impo rtant that configuration-time errors fail as early as possible.</t> <t>To avoid allocating resources that are not finally needed, it is impo rtant that configuration-time errors fail as early as possible.</t>
</section> </section>
<section anchor="role-of-system-policy"> <section anchor="role-of-system-policy">
<name>Role of system policy</name> <name>Role of System Policy</name>
<t>The properties specified during pre-establishment have a close relati <t>The properties specified during preestablishment have a close relatio
onship to system policy. The implementation is responsible for combining and rec nship to system policy. The implementation is responsible for combining and reco
onciling several different sources of preferences when establishing Connections. nciling several different sources of preferences when establishing Connections.
These include, but are not limited to:</t> These include, but are not limited to:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Application preferences, i.e., preferences specified during the p re-establishment via Selection Properties.</t> <t>Application preferences, i.e., preferences specified during prees tablishment via Selection Properties.</t>
</li> </li>
<li> <li>
<t>Dynamic system policy, i.e., policy compiled from internally and externally acquired information about available network interfaces, supported tr ansport protocols, and current/previous Connections. Examples of ways to externa lly retrieve policy-support information are through OS-specific statistics/measu rement tools and tools that reside on middleboxes and routers.</t> <t>Dynamic system policy, i.e., policy compiled from internally and externally acquired information about available network interfaces, supported tr ansport protocols, and current/previous Connections. Examples of ways to externa lly retrieve policy-support information are through OS-specific statistics/measu rement tools and tools that reside on middleboxes and routers.</t>
</li> </li>
<li> <li>
<t>Default implementation policy, i.e., predefined policy by OS or a pplication.</t> <t>Default implementation policy, i.e., predefined policy by the OS or application.</t>
</li> </li>
</ol> </ol>
<t>In general, any protocol or path used for a Connection must conform t <t>In general, any protocol or path used for a Connection must conform t
o all three sources of constraints. A violation that occurs at any of the policy o all three sources of constraints. A violation that occurs at any of the policy
layers should cause a protocol or path to be considered ineligible for use. If layers should cause a protocol or path to be considered ineligible for use. If
such a violation prevents a Connection from being established, this should be co such a violation prevents a Connection from being established, this should be co
mmunicated to the application, e.g. via the <tt>EstablishmentError</tt> event. F mmunicated to the application, e.g., via the <tt>EstablishmentError</tt> event.
or an example of application preferences leading to constraints, an application For an example of application preferences leading to constraints, an application
may prohibit the use of metered network interfaces for a given Connection to avo may prohibit the use of metered network interfaces for a given Connection to av
id user cost. Similarly, the system policy at a given time may prohibit the use oid user cost. Similarly, the system policy at a given time may prohibit the use
of such a metered network interface from the application's process. Lastly, the of such a metered network interface from the application's process. Lastly, the
implementation itself may default to disallowing certain network interfaces unle implementation itself may default to disallowing certain network interfaces unl
ss explicitly requested by the application.</t> ess explicitly requested by the application.</t>
<t>It is expected that the database of system policies and the method of <t>It is expected that the database of system policies and the method of
looking up these policies will vary across various platforms. An implementation looking up these policies will vary across various platforms. An implementation
should attempt to look up the relevant policies for the system in a dynamic way should attempt to look up the relevant policies for the system in a dynamic way
to make sure it is reflecting an accurate version of the system policy, since t to make sure it reflects an accurate version of the system policy, since the sy
he system's policy regarding the application's traffic may change over time due stem's policy regarding the application's traffic may change over time due to us
to user or administrative changes.</t> er or administrative changes.</t>
</section> </section>
</section> </section>
<section anchor="conn-establish"> <section anchor="conn-establish">
<name>Implementing Connection Establishment</name> <name>Implementing Connection Establishment</name>
<t>The process of establishing a network connection begins when an applica tion expresses intent to communicate with a Remote Endpoint by calling <tt>Initi ate</tt>, at which point the Preconnection object contains all constraints or re quirements the application has configured. The establishment process can be cons idered complete once there is at least one Protocol Stack that has completed any required setup to the point that it can transmit and receive the application's data.</t> <t>The process of establishing a network connection begins when an applica tion expresses intent to communicate with a Remote Endpoint by calling <tt>Initi ate</tt>, at which point the Preconnection object contains all constraints or re quirements the application has configured. The establishment process can be cons idered complete once there is at least one Protocol Stack that has completed any required setup to the point that it can transmit and receive the application's data.</t>
<t>Connection establishment is divided into two top-level steps: Candidate
Gathering (defined in <xref section="4.2.1" sectionFormat="of" target="I-D.ietf <!-- [rfced] We are having trouble parsing "only after waiting for
-taps-arch"/>), to identify the paths, protocols, and endpoints to use (see <xre failures". Please consider whether the suggested text conveys
f target="gathering"/>); and Candidate Racing (defined in <xref section="4.2.2" the intended meaning.
sectionFormat="of" target="I-D.ietf-taps-arch"/>), in which the necessary protoc
ol handshakes are conducted so that the Transport Services system can select whi Original:
ch set to use (see <xref target="racing"/>). Candidate Racing involves attemptin These attempts are usually staggered, starting each next option
g multiple options for connection establishment, and choosing the first option t after a delay, but they can also be performed in parallel or only
o succeed as the Protocol Stack to use for the connection. These attempts are us after waiting for failures.
ually staggered, starting each next option after a delay, but they can also be p
erformed in parallel or only after waiting for failures.</t> Perhaps:
These attempts are usually staggered, with each next option
starting after a delay; however, they can also be performed in
parallel or after failures occur.
-->
<t>Connection establishment is divided into two top-level steps:</t>
<ul>
<li>Candidate Gathering (defined in <xref section="4.2.1" sectionFormat="of" t
arget="RFC9621"/>) to identify the paths, protocols, and endpoints to use (see <
xref target="gathering"/>) and</li>
<li>Candidate Racing (defined in <xref section="4.2.2" sectionFormat="of" targ
et="RFC9621"/>), in which the necessary protocol handshakes are conducted so tha
t the Transport Services system can select which set to use (see <xref target="r
acing"/>).</li>
</ul>
<t>Candidate Racing involves attempting multiple options for connection establis
hment and choosing the first option to succeed as the Protocol Stack to use for
the connection. These attempts are usually staggered, starting each next option
after a delay; however, they can also be performed in parallel or only after wai
ting for failures.</t>
<t>For ease of illustration, this document structures the candidates for r acing as a tree (see <xref target="tree-structure"/>). <t>For ease of illustration, this document structures the candidates for r acing as a tree (see <xref target="tree-structure"/>).
This is not meant to restrict implementations from structuring racing candidates This is not meant to restrict implementations from structuring racing cand
differently.</t> idates differently.</t>
<t>The most simple example of this process might involve identifying the s
ingle IP address to which the implementation wishes to connect, using the system <!--[rfced] We have attempted to break this long sentence up using a
's current default path (i.e., using the default interface), and starting a TCP list for the ease of the reader. Please review and let us know
handshake to establish a stream to the specified IP address. However, each step if further updates are necessary (particularly, is the second
may also differ depending on the requirements of the connection: if the Endpoint bullet also talking about cases of a hostname and port?):
Identifier is a hostname and port, then there may be multiple resolved addresse
s that are available; there may also be multiple paths available, (in this case Original:
using an interface other than the default system interface); and some protocols However, each step may also differ depending on the requirements of
may not need any transport handshake to be considered "established" (such as UDP the connection: if the Endpoint Identifier is a hostname and port,
), while other connections may utilize layered protocol handshakes, such as TLS then there may be multiple resolved addresses that are available;
over TCP.</t> there may also be multiple paths available, (in this case using an
<t>Whenever an implementation has multiple options for connection establis interface other than the default system interface); and some
hment, it can view the set of all individual connection establishment options as protocols may not need any transport handshake to be considered
a single, aggregate connection establishment. The aggregate set conceptually in "established" (such as UDP), while other connections may utilize
cludes every valid combination of endpoints, paths, and protocols. As an example layered protocol handshakes, such as TLS over TCP.
, consider an implementation that initiates a TCP connection to a hostname + por
t Endpoint Identifier, and has two valid interfaces available (Wi-Fi and LTE). T Current:
he hostname resolves to a single IPv4 address on the Wi-Fi network, and resolves However, each step may also differ depending on the requirements of
to the same IPv4 address on the LTE network, as well as a single IPv6 address. the connection:
The aggregate set of connection establishment options can be viewed as follows:<
/t> * if the Endpoint Identifier is a hostname and port, then there may
be multiple resolved addresses that are available;
* there may also be multiple paths available (in this case using an
interface other than the default system interface); and
* some protocols may not need any transport handshake to be
considered "established" (such as UDP), while other connections
may utilize layered protocol handshakes, such as TLS over TCP.
-->
<t>The simplest example of this process might involve identifying the single IP
address to which the implementation wishes to connect, using the system's curren
t default path (i.e., using the default interface), and starting a TCP handshake
to establish a stream to the specified IP address. However, each step may also
differ depending on the requirements of the connection:</t>
<ul>
<li>if the Endpoint Identifier is a hostname and port, then there may be multi
ple resolved addresses that are available;</li>
<li>there may also be multiple paths available (in this case using an interfac
e other than the default system interface); and</li>
<li>some protocols may not need any transport handshake to be considered "establ
ished" (such as UDP), while other connections may utilize layered protocol hands
hakes, such as TLS over TCP.</li></ul>
<!--[rfced] Can we update this list as follows?
Original:
The hostname resolves to a single IPv4 address on the Wi-Fi network,
and resolves to the same IPv4 address on the LTE network, as well as a
single IPv6 address.
Perhaps:
The hostname resolves to a single IPv4 address on the Wi-Fi network,
to the same IPv4 address on the LTE network, and to a single IPv6
address.
-->
<t>Whenever an implementation has multiple options for connection establishment,
it can view the set of all individual connection establishment options as a sin
gle aggregate connection establishment. The aggregate set conceptually includes
every valid combination of endpoints, paths, and protocols. As an example, consi
der an implementation that initiates a TCP connection to a hostname + port Endpo
int Identifier and that has two valid interfaces available (Wi-Fi and LTE). The
hostname resolves to a single IPv4 address on the Wi-Fi network, and resolves to
the same IPv4 address on the LTE network, as well as a single IPv6 address. The
aggregate set of connection establishment options can be viewed as follows:</t>
<!-- [rfced] The following extends beyond the 72 character margin.
Please review and let us know how the artwork may be adjusted.
FYI: This is a 72 character ruler:
123456789012345678901234567890123456789012345678901234567890123456789012
A) Section 4:
Aggregate [Endpoint Identifier: www.example.com:443] [Interface: Any] [Protoco
l: TCP]
|-> [Endpoint Identifier: [2001:db8:23::1]:443] [Interface: Wi-Fi] [Proto
col: TCP]
|-> [Endpoint Identifier: 192.0.2.1:443] [Interface: LTE] [Protoco
l: TCP]
|-> [Endpoint Identifier: [2001:db8:42::1]:443] [Interface: LTE] [Proto
col: TCP]
B) Section 4.1:
||
+==============================+
| www.example.com:443/any path |
+==============================+
// \\
+===========================+ +===========================+
| www.example.com:443/Wi-Fi | | www.example.com:443/LTE |
+===========================+ +===========================+
|| // \\
+============================+ +=====================+ +======================
====+
| [2001:db8:23::1]:443/Wi-Fi | | 192.0.2.1:443/LTE | | [2001:db8:42::1]:443/
LTE |
+============================+ +=====================+ +======================
====+
C) Section 6.3:
MessageFramer.AdvanceReceiveCursor(connection, length)
MessageFramer.DeliverAndAdvanceReceiveCursor(connection, messageContext, length,
endOfMessage)
MessageFramer.Deliver(connection, messageContext, messageData, endOfMessage)
-->
<artwork><![CDATA[ <artwork><![CDATA[
Aggregate [Endpoint Identifier: www.example.com:443] [Interface: Any] [Protoco l: TCP] Aggregate [Endpoint Identifier: www.example.com:443] [Interface: Any] [Protoco l: TCP]
|-> [Endpoint Identifier: [2001:db8:23::1]:443] [Interface: Wi-Fi] [Proto col: TCP] |-> [Endpoint Identifier: [2001:db8:23::1]:443] [Interface: Wi-Fi] [Proto col: TCP]
|-> [Endpoint Identifier: 192.0.2.1:443] [Interface: LTE] [Protoco l: TCP] |-> [Endpoint Identifier: 192.0.2.1:443] [Interface: LTE] [Protoco l: TCP]
|-> [Endpoint Identifier: [2001:db8:42::1]:443] [Interface: LTE] [Proto col: TCP] |-> [Endpoint Identifier: [2001:db8:42::1]:443] [Interface: LTE] [Proto col: TCP]
]]></artwork> ]]></artwork>
<t>Any one of these sub-entries on the aggregate connection attempt would satisfy the original application intent. The concern of this section is the algo rithm defining which of these options to try, when, and in what order.</t> <t>Any one of these subentries on the aggregate connection attempt would s atisfy the original application intent. The concern of this section is the algor ithm defining which of these options to try, when to try them, and in what order .</t>
<t>During Candidate Gathering (<xref target="gathering"/>), an implementat ion prunes and sorts branches according <t>During Candidate Gathering (<xref target="gathering"/>), an implementat ion prunes and sorts branches according
to the Selection Property preferences (<xref section="6.2" sectionFormat="of" ta to the Selection Property preferences (<xref section="6.2" sectionFormat="of" ta
rget="I-D.ietf-taps-interface"/>. rget="RFC9622"/>).
It first excludes all protocols and paths that match a Prohibit property or do n First, it excludes all protocols and paths that match a Prohibit property or do
ot not
match all Require properties. Then it will sort branches according to Preferred match all Require properties. Then, it will sort branches according to Preferred
properties, Avoided properties, and possibly other criteria.</t> properties, Avoided properties, and, possibly, other criteria.</t>
<section anchor="tree-structure"> <section anchor="tree-structure">
<name>Structuring Candidates as a Tree</name> <name>Structuring Candidates as a Tree</name>
<t>As noted above, the consideration of multiple candidates in a gatheri ng and racing process can be conceptually structured as a tree; this terminologi cal convention is used throughout this document.</t> <t>As noted above, the consideration of multiple candidates in a gatheri ng and racing process can be conceptually structured as a tree; this terminologi cal convention is used throughout this document.</t>
<t>Each leaf node of the tree represents a single, coherent connection a ttempt, with an endpoint, a network path, and a set of protocols that can direct ly negotiate and send data on the network. Each node in the tree that is not a l eaf represents a connection attempt that is either underspecified, or else inclu des multiple distinct options. For example, when connecting on an IP network, a connection attempt to a hostname and port is underspecified, because the connect ion attempt requires a resolved IP address as its Remote Endpoint Identifier. In this case, the node represented by the connection attempt to the hostname is a parent node, with child nodes for each IP address. Similarly, an implementation that is allowed to connect using multiple interfaces will have a parent node of the tree for the decision between the network paths, with a branch for each inte rface.</t> <t>Each leaf node of the tree represents a single coherent connection at tempt with an endpoint, a network path, and a set of protocols that can directly negotiate and send data on the network. Each node in the tree that is not a lea f represents a connection attempt that is either underspecified or includes mult iple distinct options. For example, when connecting on an IP network, a connecti on attempt to a hostname and port is underspecified because the connection attem pt requires a resolved IP address as its Remote Endpoint Identifier. In this cas e, the node represented by the connection attempt to the hostname is a parent no de with child nodes for each IP address. Similarly, an implementation that is al lowed to connect using multiple interfaces will have a parent node of the tree f or the decision between the network paths with a branch for each interface.</t>
<t>The example aggregate connection attempt above can be drawn as a tree by grouping the addresses resolved on the same interface into branches:</t> <t>The example aggregate connection attempt above can be drawn as a tree by grouping the addresses resolved on the same interface into branches:</t>
<artwork><![CDATA[ <artwork><![CDATA[
|| ||
+==============================+ +==============================+
| www.example.com:443/any path | | www.example.com:443/any path |
+==============================+ +==============================+
// \\ // \\
+===========================+ +===========================+ +===========================+ +===========================+
| www.example.com:443/Wi-Fi | | www.example.com:443/LTE | | www.example.com:443/Wi-Fi | | www.example.com:443/LTE |
+===========================+ +===========================+ +===========================+ +===========================+
|| // \\ || // \\
+============================+ +=====================+ +====================== ====+ +============================+ +=====================+ +====================== ====+
| [2001:db8:23::1]:443/Wi-Fi | | 192.0.2.1:443/LTE | | [2001:db8:42::1]:443/ LTE | | [2001:db8:23::1]:443/Wi-Fi | | 192.0.2.1:443/LTE | | [2001:db8:42::1]:443/ LTE |
+============================+ +=====================+ +====================== ====+ +============================+ +=====================+ +====================== ====+
]]></artwork> ]]></artwork>
<t>The rest of this section will use a notation scheme to represent this
tree. The root node (or parent node) of the tree will be represented by a singl <!--[rfced] We have updated to match the way characters appear in
e integer, such as "1". ("1" is used assuming that this is the first connection RFC-to-be 9622. Please note that RFC-to-be 9622 enclosing these
made by the system; future connections created by the application would allocate types of characters in tt tags. Should the same convention be
numbers in an increasing manner.) Each child of that node will have an integer applied here?
that identifies it, from 1 to the number of children. That child node will be un
iquely identified by concatenating its integer to its parent's identifier with a Original:
dot in between, such as "1.1" and "1.2". Each node will be summarized by a tupl That child node will be uniquely identified by concatenating its
e of three elements: endpoint, path (labeled here by interface), and protocol. I integer to its parent's identifier with a dot in between, such as
n Protocol Stacks, the layers are separated by '/' and ordered with the protocol "1.1" and "1.2".
closest to the application first. The above example can now be written more suc
cinctly as:</t> and
In Protocol Stacks, the layers are separated by '/' and ordered with
the protocol closest to the application first.
Current:
That child node will be uniquely identified by concatenating its
integer to its parent's identifier with a dot character (".") in
between, such as "1.1" and "1.2".
and
In Protocol Stacks, the layers are separated by a slash character
("/") and ordered with the protocol closest to the application first.
-->
<t>The rest of this section will use a notation scheme to represent this
tree. The root node (or parent node) of the tree will be represented by a singl
e integer, such as "1". ("1" is used assuming that this is the first connection
made by the system; future connections created by the application would allocate
numbers in an increasing manner.) Each child of that node will have an integer
that identifies it, from 1 to the number of children. That child node will be un
iquely identified by concatenating its integer to its parent's identifier with a
dot character (".") in between, such as "1.1" and "1.2". Each node will be summ
arized by a tuple of three elements: endpoint, path (labeled here by interface),
and protocol. In Protocol Stacks, the layers are separated by a slash character
("/") and ordered with the protocol closest to the application first. The above
example can now be written more succinctly as:</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [www.example.com:443, any path, TCP] 1 [www.example.com:443, any path, TCP]
1.1 [www.example.com:443, Wi-Fi, TCP] 1.1 [www.example.com:443, Wi-Fi, TCP]
1.1.1 [[2001:db8:23::1]:443, Wi-Fi, TCP] 1.1.1 [[2001:db8:23::1]:443, Wi-Fi, TCP]
1.2 [www.example.com:443, LTE, TCP] 1.2 [www.example.com:443, LTE, TCP]
1.2.1 [192.0.2.1:443, LTE, TCP] 1.2.1 [192.0.2.1:443, LTE, TCP]
1.2.2 [[2001:db8.42::1]:443, LTE, TCP] 1.2.2 [[2001:db8.42::1]:443, LTE, TCP]
]]></artwork> ]]></artwork>
<t>When an implementation is asked to establish a single connection, onl y one of the leaf nodes in the candidate set is needed to transfer data. Thus, o nce a single leaf node becomes ready to use, then the connection establishment t ree is considered ready. One way to implement this is by having every leaf node update the state of its parent node when it becomes ready, until the root node o f the tree is ready, which then notifies the application that the Connection as a whole is ready to use.</t> <t>When an implementation is asked to establish a single connection, onl y one of the leaf nodes in the candidate set is needed to transfer data. Thus, o nce a single leaf node becomes ready to use, the connection establishment tree i s considered ready. One way to implement this is by having every leaf node updat e the state of its parent node when it becomes ready until the root node of the tree is ready, which then notifies the application that the Connection as a whol e is ready to use.</t>
<t>A connection establishment tree may consist of only a single node, su ch as a connection attempt to an IP address over a single interface with a singl e protocol.</t> <t>A connection establishment tree may consist of only a single node, su ch as a connection attempt to an IP address over a single interface with a singl e protocol.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [[2001:db8:23::1]:443, Wi-Fi, TCP] 1 [[2001:db8:23::1]:443, Wi-Fi, TCP]
]]></artwork> ]]></artwork>
<t>A root node may also only have one child (or leaf) node, such as a wh en a hostname resolves to only a single IP address.</t> <t>A root node may also only have one child (or leaf) node, such as a wh en a hostname resolves to only a single IP address.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [www.example.com:443, Wi-Fi, TCP] 1 [www.example.com:443, Wi-Fi, TCP]
1.1 [[2001:db8:23::1]:443, Wi-Fi, TCP] 1.1 [[2001:db8:23::1]:443, Wi-Fi, TCP]
]]></artwork> ]]></artwork>
<section anchor="branch-types"> <section anchor="branch-types">
<!--[rfced] Might it be helpful to the reader to list the three types
of branching here?
Original:
4.1.1. Branch Types
There are three types of branching from a parent node into one or
more child nodes. Any parent node of the tree must only use one type
of branching.
4.1.1.1. Derived Endpoints
-->
<name>Branch Types</name> <name>Branch Types</name>
<t>There are three types of branching from a parent node into one or m ore child nodes. Any parent node of the tree must only use one type of branching .</t> <t>There are three types of branching from a parent node into one or m ore child nodes. Any parent node of the tree must only use one type of branching .</t>
<section anchor="derived-endpoints"> <section anchor="derived-endpoints">
<name>Derived Endpoints</name> <name>Derived Endpoints</name>
<t>If a connection originally targets a single Endpoint Identifer, t <t>If a connection originally targets a single Endpoint Identifier,
here may be multiple endpoint candidates of different types that can be derived there may be multiple endpoint candidates of different types that can be derived
from the original. This creates an ordered list of the derived endpoint candidat from the original. This creates an ordered list of the derived endpoint candida
es according to application preference, system policy and expected performance.< tes according to application preference, system policy, and expected performance
/t> .</t>
<t>DNS hostname-to-address resolution is the most common method of e <t>DNS hostname-to-address resolution is the most common method of e
ndpoint derivation. When trying to connect to a hostname Endpoint Identifer on a ndpoint derivation. When trying to connect to a hostname Endpoint Identifier on
traditional IP network, the implementation should send all applicable DNS queri a traditional IP network, the implementation should send all applicable DNS quer
es. Commonly, this will include both A (IPv4) and AAAA (IPv6) records if both ad ies. Commonly, this will include both A (IPv4) and AAAA (IPv6) records if both a
dress families are supported on the local interface. This can also include SRV r ddress families are supported on the local interface. This can also include SRV
ecords <xref target="RFC2782"/>, SVCB and HTTPS records <xref target="I-D.ietf-d records <xref target="RFC2782"/>, SVCB and HTTPS records <xref target="RFC9460"/
nsop-svcb-https"/>, or other future record types. The algorithm for ordering and >, or other future record types. The algorithm for ordering and racing these add
racing these addresses should follow the recommendations in Happy Eyeballs <xre resses should follow the recommendations in Happy Eyeballs <xref target="RFC8305
f target="RFC8305"/>.</t> "/>.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [www.example.com:443, Wi-Fi, TCP] 1 [www.example.com:443, Wi-Fi, TCP]
1.1 [[2001:db8::1]:443, Wi-Fi, TCP] 1.1 [[2001:db8::1]:443, Wi-Fi, TCP]
1.2 [192.0.2.1:443, Wi-Fi, TCP] 1.2 [192.0.2.1:443, Wi-Fi, TCP]
1.3 [[2001:db8::2]:443, Wi-Fi, TCP] 1.3 [[2001:db8::2]:443, Wi-Fi, TCP]
1.4 [[2001:db8::3]:443, Wi-Fi, TCP] 1.4 [[2001:db8::3]:443, Wi-Fi, TCP]
]]></artwork> ]]></artwork>
<t>DNS-Based Service Discovery <xref target="RFC6763"/> can also pro vide an endpoint derivation step. When trying to connect to a named service, the client may discover one or more hostname and port pairs on the local network us ing multicast DNS <xref target="RFC6762"/>. These hostnames should each be treat ed as a branch that can be attempted independently from other hostnames. Each of these hostnames might resolve to one or more addresses, which would create mult iple layers of branching.</t> <t>DNS-Based Service Discovery <xref target="RFC6763"/> can also pro vide an endpoint derivation step. When trying to connect to a named service, the client may discover one or more hostname and port pairs on the local network us ing multicast DNS <xref target="RFC6762"/>. These hostnames should each be treat ed as a branch that can be attempted independently from other hostnames. Each of these hostnames might resolve to one or more addresses, which would create mult iple layers of branching.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [term-printer._ipp._tcp.meeting.example.com, Wi-Fi, TCP] 1 [term-printer._ipp._tcp.meeting.example.com, Wi-Fi, TCP]
1.1 [term-printer.meeting.example.com:631, Wi-Fi, TCP] 1.1 [term-printer.meeting.example.com:631, Wi-Fi, TCP]
1.1.1 [31.133.160.18:631, Wi-Fi, TCP] 1.1.1 [31.133.160.18:631, Wi-Fi, TCP]
]]></artwork> ]]></artwork>
<t>Applications can influence which derived Endpoints are allowed an d preferred via Selection Properties set on the Preconnection. For example, sett ing a preference for <tt>useTemporaryLocalAddress</tt> would prefer the use of I Pv6 over IPv4, and requiring <tt>useTemporaryLocalAddress</tt> would eliminate I Pv4 options, since IPv4 does not support temporary addresses.</t> <t>Applications can influence which derived Endpoints are allowed an d preferred via Selection Properties set on the Preconnection. For example, sett ing a preference for <tt>useTemporaryLocalAddress</tt> would prefer the use of I Pv6 over IPv4, and requiring <tt>useTemporaryLocalAddress</tt> would eliminate I Pv4 options since IPv4 does not support temporary addresses.</t>
</section> </section>
<section anchor="network-paths"> <section anchor="network-paths">
<name>Network Paths</name> <name>Network Paths</name>
<t>If a client has multiple network paths available to it, e.g., a m obile client with interfaces for both Wi-Fi and Cellular connectivity, it can at tempt a connection over any of the paths. This represents a branch point in the connection establishment. Similar to a derived endpoint, the paths should be ran ked based on preference, system policy, and performance. Attempts should be star ted on one path (e.g., a specific interface), and then successively on other pat hs (or interfaces) after delays based on the expected path round-trip-time or ot her available metrics.</t> <t>If a client has multiple network paths available to it, e.g., a m obile client with interfaces for both Wi-Fi and Cellular connectivity, it can at tempt a connection over any of the paths. This represents a branch point in the connection establishment. Similar to a derived endpoint, the paths should be ran ked based on preference, system policy, and performance. Attempts should be star ted on one path (e.g., a specific interface) and then successively on other path s (or interfaces) after delays based on the expected path RTT or other available metrics.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [192.0.2.1:443, any path, TCP] 1 [192.0.2.1:443, any path, TCP]
1.1 [192.0.2.1:443, Wi-Fi, TCP] 1.1 [192.0.2.1:443, Wi-Fi, TCP]
1.2 [192.0.2.1:443, LTE, TCP] 1.2 [192.0.2.1:443, LTE, TCP]
]]></artwork> ]]></artwork>
<t>The same approach applies to any situation in which the client is aware of multiple links or views of the network. A single interface may be shar ed by <t>The same approach applies to any situation in which the client is aware of multiple links or views of the network. A single interface may be shar ed by
multiple network paths, each with a coherent set of addresses, routes, DNS serve r, and more. A path may also represent a virtual interface service such as a Vir tual Private Network (VPN).</t> multiple network paths, each with a coherent set of addresses, routes, DNS serve r, and more. A path may also represent a virtual interface service such as a Vir tual Private Network (VPN).</t>
<t>The list of available paths should be constrained by any requirem ents the application sets, as well as by the system policy.</t> <t>The list of available paths should be constrained by any requirem ents the application sets as well as by the system policy.</t>
</section> </section>
<section anchor="protocol-options"> <section anchor="protocol-options">
<name>Protocol Options</name> <name>Protocol Options</name>
<t>Differences in possible protocol compositions and options can als o provide a branching point in connection establishment. This allows clients to be resilient to situations in which a certain protocol is not functioning on a s erver or network.</t> <t>Differences in possible protocol compositions and options can als o provide a branching point in connection establishment. This allows clients to be resilient to situations in which a certain protocol is not functioning on a s erver or network.</t>
<t>This approach is commonly used for connections with optional prox y server configurations. A single connection might have several options availabl e: an HTTP-based proxy, a SOCKS-based proxy, or no proxy. As above, these option s should be ranked based on preference, system policy, and performance and attem pted in succession.</t> <t>This approach is commonly used for connections with optional prox y server configurations. A single connection might have several options availabl e: an HTTP-based proxy, a SOCKS-based proxy, or no proxy. As above, these option s should be ranked based on preference, system policy, and performance, and shou ld be attempted in succession.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [www.example.com:443, any path, HTTP/TCP] 1 [www.example.com:443, any path, HTTP/TCP]
1.1 [192.0.2.8:443, any path, HTTP/HTTP Proxy/TCP] 1.1 [192.0.2.8:443, any path, HTTP/HTTP Proxy/TCP]
1.2 [192.0.2.7:10234, any path, HTTP/SOCKS/TCP] 1.2 [192.0.2.7:10234, any path, HTTP/SOCKS/TCP]
1.3 [www.example.com:443, any path, HTTP/TCP] 1.3 [www.example.com:443, any path, HTTP/TCP]
1.3.1 [192.0.2.1:443, any path, HTTP/TCP] 1.3.1 [192.0.2.1:443, any path, HTTP/TCP]
]]></artwork> ]]></artwork>
<t>This approach also allows a client to attempt different sets of a pplication and transport protocols that, when available, could provide preferabl e features. For example, the protocol options could involve QUIC <xref target="R FC9000"/> over UDP on one branch, and HTTP/2 <xref target="RFC7540"/> over TLS o ver TCP on the other:</t> <t>This approach also allows a client to attempt different sets of a pplication and transport protocols that, when available, could provide preferabl e features. For example, the protocol options could involve QUIC <xref target="R FC9000"/> over UDP on one branch and HTTP/2 <xref target="RFC7540"/> over TLS ov er TCP on the other:</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [www.example.com:443, any path, HTTP] 1 [www.example.com:443, any path, HTTP]
1.1 [www.example.com:443, any path, HTTP3/QUIC/UDP] 1.1 [www.example.com:443, any path, HTTP3/QUIC/UDP]
1.1.1 [192.0.2.1:443, any path, HTTP3/QUIC/UDP] 1.1.1 [192.0.2.1:443, any path, HTTP3/QUIC/UDP]
1.2 [www.example.com:443, any path, HTTP2/TLS/TCP] 1.2 [www.example.com:443, any path, HTTP2/TLS/TCP]
1.2.1 [192.0.2.1:443, any path, HTTP2/TLS/TCP] 1.2.1 [192.0.2.1:443, any path, HTTP2/TLS/TCP]
]]></artwork> ]]></artwork>
<t>Another example is racing SCTP with TCP:</t> <t>Another example is racing SCTP with TCP:</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [www.example.com:4740, any path, reliable-inorder-stream] 1 [www.example.com:4740, any path, reliable-inorder-stream]
1.1 [www.example.com:4740, any path, SCTP] 1.1 [www.example.com:4740, any path, SCTP]
1.1.1 [192.0.2.1:4740, any path, SCTP] 1.1.1 [192.0.2.1:4740, any path, SCTP]
1.2 [www.example.com:4740, any path, TCP] 1.2 [www.example.com:4740, any path, TCP]
1.2.1 [192.0.2.1:4740, any path, TCP] 1.2.1 [192.0.2.1:4740, any path, TCP]
]]></artwork> ]]></artwork>
<t>Implementations that support racing protocols and protocol option s should maintain a history of which protocols and protocol options were success fully established, on a per-network and per-endpoint basis (see <xref target="pe rformance-caches"/>). This information can influence future racing decisions to prioritize or prune branches.</t> <t>Implementations that support racing protocols and protocol option s should maintain a history of which protocols and protocol options were success fully established on a per-network and per-endpoint basis (see <xref target="per formance-caches"/>). This information can influence future racing decisions to p rioritize or prune branches.</t>
</section> </section>
</section> </section>
<section anchor="branching-order-of-operations"> <section anchor="branching-order-of-operations">
<name>Branching Order-of-Operations</name> <name>Branching Order-of-Operations</name>
<t>Branch types ought to occur in a specific order relative to one ano ther to avoid creating leaf nodes with invalid or incompatible settings. In the example above, it would be invalid to branch for derived endpoints (the DNS resu lts for www.example.com) before branching between interface paths, since there a re situations when the results will be different across networks due to private names or different supported IP versions. Implementations need to be careful to branch in a consistent order that results in usable leaf nodes whenever there ar e multiple branch types that could be used from a single node.</t> <t>Branch types ought to occur in a specific order relative to one ano ther to avoid creating leaf nodes with invalid or incompatible settings. In the example above, it would be invalid to branch for derived endpoints (the DNS resu lts for www.example.com) before branching between interface paths since there ar e situations when the results will be different across networks due to private n ames or different supported IP versions. Implementations need to be careful to b ranch in a consistent order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node.</t>
<t>This document recommends the following order of operations for bran ching:</t> <t>This document recommends the following order of operations for bran ching:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Network Paths</t> <t>Network Paths</t>
</li> </li>
<li> <li>
<t>Protocol Options</t> <t>Protocol Options</t>
</li> </li>
<li> <li>
<t>Derived Endpoints</t> <t>Derived Endpoints</t>
</li> </li>
</ol> </ol>
<t>where a lower number indicates higher precedence and therefore high <t>where a lower number indicates higher precedence and, therefore, hi
er placement in the tree. Branching between paths is the first in the list becau gher placement in the tree. Branching between paths is the first in the list bec
se results across multiple interfaces are likely not related to one another: end ause results across multiple interfaces are likely not related to one another: e
point resolution may return different results, especially when using locally res ndpoint resolution may return different results, especially when using locally r
olved host and service names, and which protocols are supported and preferred ma esolved host and service names and the protocols that are supported and preferre
y differ across interfaces. Thus, if multiple paths are attempted, the overall c d may differ across interfaces. Thus, if multiple paths are attempted, the overa
onnection establishment process can be seen as a race between the available path ll connection establishment process can be seen as a race between the available
s or interfaces.</t> paths or interfaces.</t>
<t>Protocol options are next checked in order. Whether or not a set of <t>Protocol options are next checked in order. Whether or not a set of
protocols, or protocol-specific options, can successfully connect is generally protocols, or protocol-specific options, can successfully connect is generally
not dependent on which specific IP address is used. Furthermore, the Protocol St not dependent on which specific IP address is used. Furthermore, the Protocol St
acks being attempted may influence or altogether change the Endpoint Identifers acks being attempted may influence or altogether change the Endpoint Identifiers
being used. Adding a proxy to a connection's branch will change the Endpoint Ide being used. Adding a proxy to a connection's branch will change the Endpoint Id
ntifer to the proxy's IP address or hostname. Choosing an alternate protocol may entifier to the proxy's IP address or hostname. Choosing an alternate protocol m
also modify the ports that should be selected.</t> ay also modify the ports that should be selected.</t>
<t>Branching for derived endpoints is the final step, and may have mul <t>Branching for derived endpoints is the final step and may have mult
tiple layers of derivation or resolution, such as DNS service resolution and DNS iple layers of derivation or resolution, such as DNS service resolution and DNS
hostname resolution.</t> hostname resolution.</t>
<t>For example, if the application has indicated both a preference for
WiFi over LTE and for a feature only available in SCTP, branches will be first <!--[rfced] Please review the multiple uses of "first" in this
sorted accord to path selection, with WiFi attempted first. Then, branches with sentence about ordering. It may be helpful to the reader to
SCTP will be attempted first within their subtree according to the properties in clarify.
fluencing protocol selection. However, if the implementation has current cache i
nformation that SCTP is not available on the path over WiFi, there would be no S Original:
CTP node in the WiFi subtree. Here, the path over WiFi will be attempted first,
and, if connection establishment succeeds, TCP will be used. Thus, the Selection ..branches
Property preferring WiFi takes precedence over the Property that led to a prefe will be first sorted accord to path selection, with WiFi
rence for SCTP.</t> attempted first. Then, branches with SCTP will be attempted first
within their subtree according to the properties influencing protocol
selection.
-->
<t>For example, if the application has indicated both a preference for
Wi-Fi over LTE and for a feature only available in SCTP, branches will first be
sorted according to path selection, with Wi-Fi attempted first. Then, branches
with SCTP will be attempted first within their subtree according to the properti
es influencing protocol selection. However, if the implementation has current ca
che information that SCTP is not available on the path over Wi-Fi, there would b
e no SCTP node in the Wi-Fi subtree. Here, the path over Wi-Fi will be attempted
first, and, if connection establishment succeeds, TCP will be used. Thus, the S
election Property preferring Wi-Fi takes precedence over the Property that led t
o a preference for SCTP.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1. [www.example.com:80, any path, reliable-inorder-stream] 1. [www.example.com:80, any path, reliable-inorder-stream]
1.1 [192.0.2.1:443, Wi-Fi, reliable-inorder-stream] 1.1 [192.0.2.1:443, Wi-Fi, reliable-inorder-stream]
1.1.1 [192.0.2.1:443, Wi-Fi, TCP] 1.1.1 [192.0.2.1:443, Wi-Fi, TCP]
1.2 [192.0.3.1:443, LTE, reliable-inorder-stream] 1.2 [192.0.3.1:443, LTE, reliable-inorder-stream]
1.2.1 [192.0.3.1:443, LTE, SCTP] 1.2.1 [192.0.3.1:443, LTE, SCTP]
1.2.2 [192.0.3.1:443, LTE, TCP] 1.2.2 [192.0.3.1:443, LTE, TCP]
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="branch-sorting"> <section anchor="branch-sorting">
<name>Sorting Branches</name> <name>Sorting Branches</name>
<t>Implementations should sort the branches of the tree of connection <t>Implementations should sort the branches of the tree of connection
options in order of their preference rank, from most preferred to least preferre options in order of their preference rank from most preferred to least preferred
d as as
specified by Selection Properties <xref target="I-D.ietf-taps-interface"/>. specified by Selection Properties <xref target="RFC9622"/>.
Leaf nodes on branches with higher rankings represent connection attempts that w ill be raced first.</t> Leaf nodes on branches with higher rankings represent connection attempts that w ill be raced first.</t>
<t>In addition to the properties provided by the application, an imple mentation may include additional criteria such as cached performance estimates, see <xref target="performance-caches"/>, or system policy, see <xref target="rol e-of-system-policy"/>, in the ranking. <t>In addition to the properties provided by the application, an imple mentation may include additional criteria such as cached performance estimates ( see <xref target="performance-caches"/>) or system policy (see <xref target="rol e-of-system-policy"/>) in the ranking.
Two examples of how Selection and Connection Properties may be used to sort bran ches are provided below:</t> Two examples of how Selection and Connection Properties may be used to sort bran ches are provided below:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>"Interface Instance or Type" (property name <tt>interface</tt>) <dt>"Interface Instance or Type" (property name <tt>interface</tt>
: ):</dt>
If the application specifies an interface type to be preferred or avoided, imple <dd>If the application specifies an interface type to be preferred or avoided, i
mentations should accordingly rank the paths. mplementations should accordingly rank the paths.
If the application specifies an interface type to be required or prohibited, an If the application specifies an interface type to be required or prohibited, an
implementation is expected to exclude the non-conforming paths.</t> implementation is expected to exclude the nonconforming paths.</dd>
</li>
<li> <dt>"Capacity Profile" (property name <tt>connCapacityProfile</tt>
<t>"Capacity Profile" (property name <tt>connCapacityProfile</tt>) ):</dt>
: <dd><t>An implementation can use the capacity profile to prefer paths that match
An implementation can use the capacity profile to prefer paths that match an app an application's expected traffic profile. This match will use cached performan
lication's expected traffic profile. This match will use cached performance esti ce estimates; see <xref target="performance-caches"/>. Some examples of path pre
mates, see <xref target="performance-caches"/>. Some examples of path preference ferences based on capacity profiles include:</t>
s based on capacity profiles include: </t> <dl spacing="normal">
<ul spacing="normal">
<li> <dt>Low Latency/Interactive:</dt>
<t>Low Latency/Interactive: <dd>Prefer paths with the lowest expected Round-Trip Time (RTT), based on observ
Prefer paths with the lowest expected Round Trip Time, based on observed Round T ed RTT estimates;</dd>
rip Time estimates;</t>
</li> <dt>Low Latency/Non-Interactive:</dt>
<li> <!-- [rfced] May we update this text for clarity?
<t>Low Latency/Non-Interactive:
Prefer paths with a low expected Round Trip Time, but can tolerate delay variati Original:
on;</t> - Low Latency/Non-Interactive: Prefer paths with a low expected
</li> Round Trip Time, but can tolerate delay variation;
<li>
<t>Constant-Rate Streaming: Perhaps:
Prefer paths that are expected to satisfy the requested stream send or receive b - Low Latency/Non-Interactive: Prefer paths with a low expected
itrate, based on the observed maximum throughput;</t> Round Trip Time (RTT) that can tolerate delay variation;
</li> -->
<li>
<t>Capacity-Seeking: <dd>Prefer paths with a low expected Round-Trip Time (RTT), but can tolerate del
Prefer adapting to paths to determine the highest available capacity, based on t ay variation;</dd>
he observed maximum throughput.</t>
</li> <dt>Constant-Rate Streaming:</dt>
</ul> <dd>Prefer paths that are expected to satisfy the requested stream send or recei
</li> ve bitrate based on the observed maximum throughput;</dd>
</ul>
<t>As another example, branch sorting can also be influenced by bounds <dt>Capacity-Seeking:</dt>
on the send or receive rate (Selection Properties <tt>minSendRate</tt> / <tt>mi <dd>Prefer adapting to paths to determine the highest available capacity based o
nRecvRate</tt> / <tt>maxSendRate</tt> / <tt>maxRecvRate</tt>): if the applicatio n the observed maximum throughput.</dd>
n indicates a bound on the expected send or receive bitrate, an implementation m </dl>
ay prefer a path that can likely provide the desired bandwidth, based on cached </dd>
maximum throughput, see <xref target="performance-caches"/>. The application may </dl>
know the send or receive bitrate from metadata in adaptive HTTP streaming, such <t>As another example, branch sorting can also be influenced by bounds
as MPEG-DASH.</t> on the send or receive rate (Selection Properties <tt>minSendRate</tt> / <tt>mi
<t>Implementations process the Properties (<xref section="6.2" section nRecvRate</tt> / <tt>maxSendRate</tt> / <tt>maxRecvRate</tt>): if the applicatio
Format="of" target="I-D.ietf-taps-interface"/>) in the following order: Prohibit n indicates a bound on the expected send or receive bitrate, an implementation m
, Require, Prefer, Avoid. ay prefer a path that can likely provide the desired bandwidth, based on cached
If Selection Properties contain any prohibited properties, the implementation sh maximum throughput (see <xref target="performance-caches"/>). The application ma
ould first purge branches containing nodes with these properties. For required p y know the send or receive bitrate from metadata in adaptive HTTP streaming, suc
roperties, it should only keep branches that satisfy these requirements. Finally h as MPEG-DASH.</t>
, it should order the branches according to the preferred properties, and finall
y use any avoided properties as a tiebreaker. <t>Implementations process the Properties (<xref section="6.2" section
When ordering branches, an implementation can give more weight to properties tha Format="of" target="RFC9622"/>) in the following order: Prohibit, Require, Prefe
t the application has explicitly set, than to the properties that are default.</ r, Avoid.
t> If Selection Properties contain any prohibited properties, the implementation sh
ould first purge branches containing nodes with these properties. For required p
roperties, it should only keep branches that satisfy these requirements. Finally
, it should order the branches according to the preferred properties and use any
avoided properties as a tiebreaker.
When ordering branches, an implementation can give more weight to properties tha
t the application has explicitly set rather than to the properties that are set
by default.</t>
<t>The available protocols and paths on a specific system and in a spe cific context can change; therefore, the result of sorting and the outcome of ra cing may vary, even when using the same Selection and Connection Properties. How ever, an implementation ought to provide a consistent outcome to applications, e .g., by preferring protocols and paths that are already used by existing Connect ions that specified similar Properties.</t> <t>The available protocols and paths on a specific system and in a spe cific context can change; therefore, the result of sorting and the outcome of ra cing may vary, even when using the same Selection and Connection Properties. How ever, an implementation ought to provide a consistent outcome to applications, e .g., by preferring protocols and paths that are already used by existing Connect ions that specified similar Properties.</t>
</section> </section>
</section> </section>
<section anchor="gathering"> <section anchor="gathering">
<name>Candidate Gathering</name> <name>Candidate Gathering</name>
<!--[rfced] Are the terms in the following sentence related to those
mentioned two paragraphs above (from RFC-to-be 9622)? If so,
should they take the same form and/or should avoidance be added?
Original:
This list is determined by the requirements, prohibitions, and
preferences of the application as specified in the Selection
Properties.
Two paragraphs before:
Original:
Implementations process the Properties (Section 6.2 of
[I-D.ietf-taps-interface]) in the following order: Prohibit, Require,
Prefer, Avoid.
A few sentences later includes "avoid":
Original:
Finally, it should order the branches according to the preferred
properties, and finally use any avoided properties as a tiebreaker.
-->
<t>The step of gathering candidates involves identifying which paths, pr otocols, and endpoints may be used for a given Connection. This list is determin ed by the requirements, prohibitions, and preferences of the application as spec ified in the Selection Properties.</t> <t>The step of gathering candidates involves identifying which paths, pr otocols, and endpoints may be used for a given Connection. This list is determin ed by the requirements, prohibitions, and preferences of the application as spec ified in the Selection Properties.</t>
<section anchor="gathering-endpoint-candidates"> <section anchor="gathering-endpoint-candidates">
<name>Gathering Endpoint Candidates</name> <name>Gathering Endpoint Candidates</name>
<t>Both Local and Remote Endpoint Candidates must be discovered during connection establishment. To support Interactive Connectivity Establishment (I CE) <xref target="RFC8445"/>, or similar protocols that involve out-of-band indi rect signalling to exchange candidates with the Remote Endpoint, it is important to query the set of candidate Local Endpoints, and provide the Protocol Stack w ith a set of candidate Remote Endpoints, before the Local Endpoint attempts to e stablish connections.</t> <t>Both Local and Remote Endpoint Candidates must be discovered during connection establishment. To support Interactive Connectivity Establishment (I CE) <xref target="RFC8445"/>, or similar protocols that involve out-of-band indi rect signaling to exchange candidates with the Remote Endpoint, it is important to query the set of candidate Local Endpoints and provide the Protocol Stack wit h a set of candidate Remote Endpoints before the Local Endpoint attempts to esta blish connections.</t>
<section anchor="local-endpoint-candidates"> <section anchor="local-endpoint-candidates">
<name>Local Endpoint candidates</name> <name>Local Endpoint Candidates</name>
<t>The set of possible Local Endpoints is gathered. In a simple cas <t>The set of possible Local Endpoints is gathered. In a simple cas
e, this merely enumerates the local interfaces and protocols, and allocates ephe e, this merely enumerates the local interfaces and protocols and allocates ephem
meral source ports. For example, a system that has WiFi and Ethernet and suppor eral source ports. For example, a system that has Wi-Fi and Ethernet and suppor
ts IPv4 and IPv6 might gather four candidate Local Endpoints (IPv4 on Ethernet, ts IPv4 and IPv6 might gather four candidate Local Endpoints (IPv4 on Ethernet,
IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on WiFi) that can form the source for a IPv6 on Ethernet, IPv4 on Wi-Fi, and IPv6 on Wi-Fi) that can form the source for
transient.</t> a transient.</t>
<t>If NAT traversal is required, the process of gathering Local Endp <t>If NAT traversal is required, the process of gathering Local Endp
oints becomes broadly equivalent to the ICE Candidate Gathering phase (see <xref oints becomes broadly equivalent to the ICE Candidate Gathering phase (see <xref
section="5.1.1" sectionFormat="of" target="RFC8445"/>). The endpoint determine section="5.1.1" sectionFormat="of" target="RFC8445"/>). The endpoint determine
s its server reflexive Local Endpoints (i.e., the translated address of a Local s its server-reflexive Local Endpoints (i.e., the translated address of a Local
Endpoint, on the other side of a NAT, e.g via a STUN sever <xref target="RFC5389 Endpoint, on the other side of a NAT, e.g., via a STUN server <xref target="RFC5
"/>) and relayed Local Endpoints (e.g., via a TURN server <xref target="RFC5766" 389"/>) and relayed Local Endpoints (e.g., via a TURN server <xref target="RFC57
/> or other relay), for each interface and network protocol. These are added to 66"/> or other relay) for each interface and network protocol. These are added
the set of candidate Local Endpoint Identifers for this connection.</t> to the set of candidate Local Endpoint Identifiers for this connection.</t>
<t>Gathering Local Endpoints is primarily a local operation, althoug <t>Gathering Local Endpoints is primarily a local operation, althoug
h it might involve exchanges with a STUN server to derive server reflexive Local h it might involve exchanges with a STUN server to derive server-reflexive Local
Endpoints, or with a TURN server or other relay to derive relayed Local Endpoin Endpoints or with a TURN server or other relay to derive relayed Local Endpoint
ts. However, it does not involve communication with the Remote Endpoint.</t> s. However, it does not involve communication with the Remote Endpoint.</t>
</section> </section>
<section anchor="remote-endpoint-candidates"> <section anchor="remote-endpoint-candidates">
<name>Remote Endpoint Candidates</name> <name>Remote Endpoint Candidates</name>
<t>The Remote Endpoint Identifer is typically a name that needs to b <t>The Remote Endpoint Identifier is typically a name that needs to
e resolved into a set of possible addresses that can be used for communication. be resolved into a set of possible addresses that can be used for communication.
Resolving the Remote Endpoint is the process of recursively performing such nam Resolving the Remote Endpoint is the process of recursively performing such na
e lookups, until fully resolved, to return the set of candidates for the Remote me lookups, until fully resolved, to return the set of candidates for the Remote
Endpoint of this Connection.</t> Endpoint of this Connection.</t>
<t>How this resolution is done will depend on the type of the Remote
Endpoint, and can also be specific to each Local Endpoint. A common case is wh <t>How this resolution is done will depend on the type of the Remote
en the Remote Endpoint Identifer is a DNS name, in which case it is resolved to Endpoint and can also be specific to each Local Endpoint. A common case is whe
give a set of IPv4 and IPv6 addresses representing that name. Some types of Rem n the Remote Endpoint Identifier is a DNS name, in which case, it is resolved to
ote Endpoint Identifers might require more complex resolution. Resolving the Re give a set of IPv4 and IPv6 addresses representing that name. Some types of Re
mote Endpoint for a peer-to-peer connection might involve communication with a r mote Endpoint Identifiers might require more complex resolution. Resolving the
endezvous server, which in turn contacts the peer to gain consent to communicate Remote Endpoint for a peer-to-peer connection might involve communication with a
and retrieve its set of candidate Local Endpoints, which are returned and form rendezvous server. The server, in turn, contacts the peer to gain consent to c
the candidate remote addresses for contacting that peer.</t> ommunicate and retrieve its set of candidate Local Endpoints. These Endpoints ar
<t>Resolving the Remote Endpoint is not a local operation. It will e returned and form the candidate remote addresses for contacting that peer.</t>
involve a directory service, and can require communication with the Remote Endpo
int to rendezvous and exchange peer addresses. This can expose some or all of t <!--[rfced] Is "to rendezvous" the rendezvous server? We are a bit
he candidate Local Endpoints to the Remote Endpoint.</t> confused by the second part of the sentence. If our suggestion
does not capture your intent, please rephrase.
Original:
It will involve a directory service, and can require communication
with the Remote Endpoint to rendezvous and exchange peer addresses.
Perhaps:
It will involve a directory service and can require communication
between the Remote Endpoint and a rendezvous server as well as the
exchange of peer addresses.
-->
<t>Resolving the Remote Endpoint is not a local operation. It will
involve a directory service and can require communication with the Remote Endpoi
nt to rendezvous and exchange peer addresses. This can expose some or all of th
e candidate Local Endpoints to the Remote Endpoint.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="racing"> <section anchor="racing">
<name>Candidate Racing</name> <name>Candidate Racing</name>
<t>The primary goal of the Candidate Racing process is to successfully n egotiate a Protocol Stack to an endpoint over an interface to connect a single l eaf node of the tree with as little delay and as few unnecessary connections att empts as possible. Optimizing these two factors improves the user experience, wh ile minimizing network load.</t> <t>The primary goal of the Candidate Racing process is to successfully n egotiate a Protocol Stack to an endpoint over an interface to connect a single l eaf node of the tree with as little delay and as few unnecessary connections att empts as possible. Optimizing these two factors improves the user experience, wh ile minimizing network load.</t>
<t>This section covers the dynamic aspect of connection establishment. T he tree described above is a useful conceptual and architectural model. However, an implementation is unable to know all of the nodes that will be used until st eps like name resolution have occurred, and many of the possible branches ultima tely might not be attempted.</t> <t>This section covers the dynamic aspect of connection establishment. T he tree described above is a useful conceptual and architectural model. However, an implementation is unable to know all of the nodes that will be used until st eps like name resolution have occurred; many of the possible branches ultimately might not be attempted.</t>
<t>There are three different approaches to racing the attempts for diffe rent nodes of the connection establishment tree:</t> <t>There are three different approaches to racing the attempts for diffe rent nodes of the connection establishment tree:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Simultaneous</t> <t>Simultaneous</t>
</li> </li>
<li> <li>
<t>Staggered</t> <t>Staggered</t>
</li> </li>
<li> <li>
<t>Failover</t> <t>Failover</t>
</li> </li>
</ol> </ol>
<t>Each approach is appropriate in different use-cases and branch types. <t>Each approach is appropriate in different use cases and branch types.
However, to avoid consuming unnecessary network resources, implementations shou However, to avoid consuming unnecessary network resources, implementations shou
ld not use simultaneous racing as a default approach.</t> ld not use simultaneous racing as a default approach.</t>
<t>The timing algorithms for racing should remain independent across bra <t>The timing algorithms for racing should remain independent across bra
nches of the tree. Any timer or racing logic is isolated to a given parent node, nches of the tree. Any timer or racing logic is isolated to a given parent node
and is not ordered precisely with regards to children of other nodes.</t> and is not ordered precisely with regard to children of other nodes.</t>
<section anchor="simultaneous"> <section anchor="simultaneous">
<name>Simultaneous</name> <name>Simultaneous</name>
<t>Simultaneous racing is when multiple alternate branches are started without waiting for any one branch to make progress before starting the next al ternative. This means the attempts are effectively simultaneous. Simultaneous ra cing should be avoided by implementations, since it consumes extra network resou rces and establishes state that might not be used.</t> <t>Simultaneous racing is when multiple alternate branches are started without waiting for any one branch to make progress before starting the next al ternative. This means the attempts are effectively simultaneous. Simultaneous ra cing should be avoided by implementations since it consumes extra network resour ces and establishes state that might not be used.</t>
</section> </section>
<section anchor="staggered"> <section anchor="staggered">
<name>Staggered</name> <name>Staggered</name>
<t>Staggered racing can be used whenever a single node of the tree has multiple child nodes. Based on the order determined when building the tree, the first child node will be initiated immediately, followed by the next child node after some delay. Once that second child node is initiated, the third child nod e (if present) will begin after another delay, and so on until all child nodes h ave been initiated, or one of the child nodes successfully completes its negotia tion.</t> <t>Staggered racing can be used whenever a single node of the tree has multiple child nodes. Based on the order determined when building the tree, the first child node will be initiated immediately, followed by the next child node after some delay. Once that second child node is initiated, the third child nod e (if present) will begin after another delay, and so on until all child nodes h ave been initiated or one of the child nodes successfully completes its negotiat ion.</t>
<t>Staggered racing attempts can proceed in parallel. Implementations should not terminate an earlier child connection attempt upon starting a seconda ry child.</t> <t>Staggered racing attempts can proceed in parallel. Implementations should not terminate an earlier child connection attempt upon starting a seconda ry child.</t>
<t>If a child node fails to establish connectivity (as in <xref target ="determining-successful-establishment"/>) before the delay time has expired for the next child, the next child should be started immediately.</t> <t>If a child node fails to establish connectivity (as in <xref target ="determining-successful-establishment"/>) before the delay time has expired for the next child, the next child should be started immediately.</t>
<t>Staggered racing between IP addresses for a generic Connection shou <t>Staggered racing between IP addresses for a generic Connection shou
ld follow the Happy Eyeballs algorithm described in <xref target="RFC8305"/>. <x ld follow the Happy Eyeballs algorithm described in <xref target="RFC8305"/>. Gu
ref target="RFC8421"/> provides guidance for racing when performing Interactive idance for racing when performing ICE can be found in <xref target="RFC8421"/>.<
Connectivity Establishment (ICE).</t> /t>
<t>Generally, the delay before starting a given child node ought to be <t>Generally, the delay before starting a given child node ought to be
based on the length of time the previously started child node is expected to ta based on the length of time the previously started child node is expected to ta
ke before it succeeds or makes progress in connection establishment. Algorithms ke before it succeeds or makes progress in connection establishment. Algorithms
like Happy Eyeballs choose a delay based on how long the transport connection ha like Happy Eyeballs choose a delay based on how long the transport connection ha
ndshake is expected to take. When performing staggered races in multiple branch ndshake is expected to take. When performing staggered races in multiple branch
types (such as racing between network interfaces, and then racing between IP add types (such as racing between network interfaces and then racing between IP addr
resses), a longer delay may be chosen for some branch types. For example, when r esses), a longer delay may be chosen for some branch types. For example, when ra
acing between network interfaces, the delay should also take into account the am cing between network interfaces, the delay should also take into account the amo
ount of time it takes to prepare the network interface (such as radio associatio unt of time it takes to prepare the network interface (such as radio association
n) and name resolution over that interface, in addition to the delay that would ) and name resolution over that interface in addition to the delay that would be
be added for a single transport connection handshake.</t> added for a single transport connection handshake.</t>
<t>Since the staggered delay can be chosen based on dynamic informatio <t>Since the staggered delay can be chosen based on dynamic informatio
n, such as predicted Round Trip Time, implementations should define upper and lo n, such as predicted RTT, implementations should define upper and lower bounds f
wer bounds for delay times. These bounds are implementation-specific, and may di or delay times. These bounds are implementation specific and may differ based on
ffer based on which branch type is being used.</t> which branch type is being used.</t>
</section> </section>
<section anchor="failover"> <section anchor="failover">
<name>Failover</name> <name>Failover</name>
<t>If an implementation or application has a strong preference for one branch over another, the branching node may choose to wait until one child has failed before starting the next. Failure of a leaf node is determined by its pro tocol negotiation failing or timing out; failure of a parent branching node is d etermined by all of its children failing.</t> <t>If an implementation or application has a strong preference for one branch over another, the branching node may choose to wait until one child has failed before starting the next. Failure of a leaf node is determined by its pro tocol negotiation failing or timing out; failure of a parent branching node is d etermined by all of its children failing.</t>
<t>An example in which failover is recommended is a race between a pre ferred Protocol Stack that uses a proxy and an alternate Protocol Stack that byp asses the proxy. Failover is useful in case the proxy is down or misconfigured, but any more aggressive type of racing may end up unnecessarily avoiding a proxy that was preferred by policy.</t> <t>An example in which failover is recommended is a race between a pre ferred Protocol Stack that uses a proxy and an alternate Protocol Stack that byp asses the proxy. Failover is useful if the proxy is down or misconfigured, but a ny more aggressive type of racing may end up unnecessarily avoiding a proxy that was preferred by policy.</t>
</section> </section>
</section> </section>
<section anchor="completing-establishment"> <section anchor="completing-establishment">
<name>Completing Establishment</name> <name>Completing Establishment</name>
<t>The process of connection establishment completes when one leaf node
of the tree has successfully completed negotiation with the Remote Endpoint, or <!-- [rfced] For clarity, may we update "or else" to "otherwise" here?
else all nodes of the tree have failed to connect. The first leaf node to comple
te its connection is then used by the application to send and receive data. This Original:
is signalled to the application using the <tt>Ready</tt> event in the API (<xre The process of connection establishment completes when one leaf
f section="7.1" sectionFormat="of" target="I-D.ietf-taps-interface"/>).</t> node of the tree has successfully completed negotiation with the
<t>Successes and failures of a given attempt should be reported up to pa Remote Endpoint, or else all nodes of the tree have failed to
rent nodes (towards the root of the tree). For example, in the following case, i connect.
f 1.1.1 fails to connect, it reports the failure to 1.1. Since 1.1 has no other
child nodes, it also has failed and reports that failure to 1. Because 1.2 has n Perhaps:
ot yet failed, 1 is not considered to have failed. Since 1.2 has not yet started The process of connection establishment completes when one leaf
, it is started and the process continues. Similarly, if 1.1.1 successfully conn node of the tree has successfully completed negotiation with the
ects, then it marks 1.1 as connected, which propagates to the root node 1. At th Remote Endpoint; otherwise, all nodes of the tree have failed to
is point, the Connection as a whole is considered to be successfully connected a connect.
nd ready to process application data.</t> -->
<t>The process of connection establishment completes when one leaf node
of the tree has successfully completed negotiation with the Remote Endpoint, or
else all nodes of the tree have failed to connect. The first leaf node to comple
te its connection is then used by the application to send and receive data. This
is signaled to the application using the <tt>Ready</tt> event in the API (<xref
section="7.1" sectionFormat="of" target="RFC9622"/>).</t>
<t>Successes and failures of a given attempt should be reported up to pa
rent nodes (toward the root of the tree). For example, in the following case, if
1.1.1 fails to connect, it reports the failure to 1.1. Since 1.1 has no other c
hild nodes, it also has failed and reports that failure to 1. Because 1.2 has no
t yet failed, 1 is not considered to have failed. Since 1.2 has not yet started,
it is started and the process continues. Similarly, if 1.1.1 successfully conne
cts, then it marks 1.1 as connected, which propagates to the root node 1. At thi
s point, the Connection as a whole is considered to be successfully connected an
d ready to process application data.</t>
<artwork><![CDATA[ <artwork><![CDATA[
1 [www.example.com:443, Any, TCP] 1 [www.example.com:443, Any, TCP]
1.1 [www.example.com:443, Wi-Fi, TCP] 1.1 [www.example.com:443, Wi-Fi, TCP]
1.1.1 [192.0.2.1:443, Wi-Fi, TCP] 1.1.1 [192.0.2.1:443, Wi-Fi, TCP]
1.2 [www.example.com:443, LTE, TCP] 1.2 [www.example.com:443, LTE, TCP]
... ...
]]></artwork> ]]></artwork>
<t>If a leaf node has successfully completed its connection, all other a ttempts should be made ineligible for use by the application for the original re quest. <t>If a leaf node has successfully completed its connection, all other a ttempts should be made ineligible for use by the application for the original re quest.
New connection attempts that involve transmitting data on the network ought not to be started after another leaf node has already successfully completed, becaus e the Connection as a whole has now been established. New connection attempts that involve transmitting data on the network ought not to be started after another leaf node has already successfully completed because the Connection as a whole has now been established.
An implementation could choose to let certain handshakes and negotiations comple te to gather metrics that influence future connections. An implementation could choose to let certain handshakes and negotiations comple te to gather metrics that influence future connections.
Keeping additional connections is generally not recommended, because those attem pts were slower to connect and may exhibit less desirable properties.</t> Keeping additional connections is generally not recommended because those attemp ts were slower to connect and may exhibit less desirable properties.</t>
<section anchor="determining-successful-establishment"> <section anchor="determining-successful-establishment">
<name>Determining Successful Establishment</name> <name>Determining Successful Establishment</name>
<t>On a per-protocol basis, implementations may select different crite <t>On a per-protocol basis, implementations may select different crite
ria by which a leaf node is considered to be successfully connected. If the only ria by which a leaf node is considered to be successfully connected. If the only
protocol being used is a transport protocol with a clear handshake, like TCP, t protocol being used is a transport protocol with a clear handshake, like TCP, t
hen the obvious choice is to declare that node "connected" when the three-way ha hen the obvious choice is to declare that node "connected" when the three-way ha
ndshake has been completed. If the only protocol being used is an connectionless ndshake completes. If the only protocol being used is a connectionless protocol,
protocol, like UDP, the implementation may consider the node fully "connected" like UDP, the implementation may consider the node fully "connected" the moment
the moment it determines a route is present, before sending any packets on the n it determines a route is present, before sending any packets on the network, se
etwork, see further <xref target="connectionless-racing"/>.</t> e further in <xref target="connectionless-racing"/>.</t>
<!-- [rfced] For readability, may we update the text as follows?
Original:
When the Initiate action is called without any Messages being sent
at the same time, depending on the protocols involved, it is not
guaranteed that the Remote Endpoint will be notified of this, and
hence a passive endpoint's application may not receive a
ConnectionReceived event until it receives the first Message on the
new Connection.
Perhaps:
Depending on the protocols involved, there is no guarantee that the
Remote Endpoint will be notified when the Initiate action is called
without any Messages being sent at the same time. Therefore, a
passive endpoint's application may not receive a ConnectionReceived
event until it receives the first Message on the new Connection.
-->
<t>When the <tt>Initiate</tt> action is called without any Messages be ing sent at the same time, depending on the <t>When the <tt>Initiate</tt> action is called without any Messages be ing sent at the same time, depending on the
protocols involved, it is not guaranteed that the Remote Endpoint will be notifi ed of this, and hence a passive protocols involved, it is not guaranteed that the Remote Endpoint will be notifi ed; hence, a passive
endpoint's application may not receive a <tt>ConnectionReceived</tt> event until it receives the first Message on the new Connection.</t> endpoint's application may not receive a <tt>ConnectionReceived</tt> event until it receives the first Message on the new Connection.</t>
<t>For Protocol Stacks with multiple handshakes, the decision becomes more nuanced. If the Protocol Stack involves both TLS and TCP, an implementation could determine that a leaf node is connected after the TCP handshake is comple te, or it can wait for the TLS handshake to complete as well. The benefit of dec laring completion when the TCP handshake finishes, and thus stopping the race fo r other branches of the tree, is reduced burden on the network and Remote Endpoi nts from further connection attempts that are likely to be abandoned. On the oth er hand, by waiting until the TLS handshake is complete, an implementation avoid s the scenario in which a TCP handshake completes quickly, but TLS negotiation i s either very slow or fails altogether in particular network conditions or to a particular endpoint. To avoid the issue of TLS possibly failing, the implementat ion should not generate a <tt>Ready</tt> event for the Connection until the TLS handshake is complete.</t> <t>For Protocol Stacks with multiple handshakes, the decision becomes more nuanced. If the Protocol Stack involves both TLS and TCP, an implementation could determine that a leaf node is connected after the TCP handshake is comple te, or it can wait for the TLS handshake to complete as well. The benefit of dec laring completion when the TCP handshake finishes, and thus stopping the race fo r other branches of the tree, is reduced burden on the network and Remote Endpoi nts from further connection attempts that are likely to be abandoned. On the oth er hand, by waiting until the TLS handshake is complete, an implementation avoid s the scenario in which a TCP handshake completes quickly, but TLS negotiation i s either very slow or fails altogether in particular network conditions or to a particular endpoint. To avoid the issue of TLS possibly failing, the implementat ion should not generate a <tt>Ready</tt> event for the Connection until the TLS handshake is complete.</t>
<t>If all of the leaf nodes fail to connect during racing, i.e. none o f the configurations that satisfy all requirements given in the Transport Proper ties actually work over the available paths, then the Transport Services system should report an <tt>EstablishmentError</tt> to the application. An <tt>Establis hmentError</tt> event should also be generated in case the Transport Services sy stem finds no usable candidates to race.</t> <t>If all of the leaf nodes fail to connect during racing, i.e., none of the configurations that satisfy all requirements given in the Transport Prope rties actually work over the available paths, then the Transport Services system should report an <tt>EstablishmentError</tt> to the application. An <tt>Establi shmentError</tt> event should also be generated if the Transport Services system finds no usable candidates to race.</t>
</section> </section>
</section> </section>
<section anchor="establish-mux"> <section anchor="establish-mux">
<name>Establishing multiplexed connections</name> <name>Establishing Multiplexed Connections</name>
<!-- [rfced] We are having trouble parsing this sentence. Are words
missing? Or perhaps the Connections are to "be multiplexed and
belong to the same Connection Group" or that the "multiplexed
Connections belong to the same Connection Group"?
Original:
Multiplexing several Connections over a single underlying transport
connection requires that the Connections to be multiplexed belong to
the same Connection Group (as is indicated by the application using
the Clone action).
-->
<t>Multiplexing several Connections over a single underlying transport c onnection requires that the Connections to be multiplexed belong to the same Con nection Group (as is indicated by the application using the <tt>Clone</tt> actio n). When the underlying transport connection supports multi-streaming, the Trans port Services System can map each Connection in the Connection Group to a differ ent stream of this connection.</t> <t>Multiplexing several Connections over a single underlying transport c onnection requires that the Connections to be multiplexed belong to the same Con nection Group (as is indicated by the application using the <tt>Clone</tt> actio n). When the underlying transport connection supports multi-streaming, the Trans port Services System can map each Connection in the Connection Group to a differ ent stream of this connection.</t>
<t>For such streams, there is often no explicit connection <t>For such streams, there is often no explicit connection
establishment procedure for the new stream prior to sending data on it (e.g., wi th SCTP). In this case, the same establishment procedure for the new stream prior to sending data on it (e.g., wi th SCTP). In this case, the same
considerations apply to determining stream establishment as apply to establishin g a UDP connection, as considerations apply to determining stream establishment as apply to establishin g a UDP connection, as
discussed in <xref target="determining-successful-establishment"/>. discussed in <xref target="determining-successful-establishment"/>.
This means that there might not This means that there might not
be any "establishment" message (like a TCP SYN).</t> be any "establishment" message (like a TCP SYN).</t>
</section> </section>
<section anchor="connectionless-racing"> <section anchor="connectionless-racing">
<name>Handling connectionless protocols</name> <name>Handling Connectionless Protocols</name>
<t>While protocols that use an explicit handshake to validate a connecti on to a peer can be used for racing multiple establishment attempts in parallel, connectionless protocols such as raw UDP do not offer a way to validate the pre sence of a peer or the usability of a Connection without application feedback. A n implementation should consider such a Protocol Stack to be established as soon as the Transport Services system has selected a path on which to send data.</t> <t>While protocols that use an explicit handshake to validate a connecti on to a peer can be used for racing multiple establishment attempts in parallel, connectionless protocols such as raw UDP do not offer a way to validate the pre sence of a peer or the usability of a Connection without application feedback. A n implementation should consider such a Protocol Stack to be established as soon as the Transport Services system has selected a path on which to send data.</t>
<t>However, this can cause a problem if a specific peer is not reachable over the network using the connectionless protocol, or data cannot be exchanged with the peer for any other reason. To handle the lack of an explicit handshake in the underlying protocol, an application can use a Message Framer (<xref targ et="message-framers"/>) on top of a connectionless protocol to only mark a speci fic connection attempt as ready when some data has been received, or after some application-level handshake has been performed by the Message Framer.</t> <t>However, this can cause a problem if a specific peer is not reachable over the network using the connectionless protocol or data cannot be exchanged with the peer for any other reason. To handle the lack of an explicit handshake in the underlying protocol, an application can use a Message Framer (<xref targe t="message-framers"/>) on top of a connectionless protocol to only mark a specif ic connection attempt as ready when some data has been received or after some ap plication-level handshake has been performed by the Message Framer.</t>
</section> </section>
<section anchor="listen"> <section anchor="listen">
<name>Implementing Listeners</name> <name>Implementing Listeners</name>
<t>When an implementation is asked to Listen, it registers with the syst <t>When an implementation is asked to Listen, it registers with the syst
em to wait for incoming traffic to the Local Endpoint. If no Local Endpoint Iden em to wait for incoming traffic to the Local Endpoint. If no Local Endpoint Iden
tifer is specified, the implementation should use an ephemeral port.</t> tifier is specified, the implementation should use an ephemeral port.</t>
<t>If the Selection Properties do not require a single network interface <t>If the Selection Properties do not require a single network interface
or path, but allow the use of multiple paths, the Listener object should regist or path but allow the use of multiple paths, the Listener object should registe
er for incoming traffic on all of the network interfaces or paths that conform t r for incoming traffic on all of the network interfaces or paths that conform to
o the Properties. The set of available paths can change over time, so the implem the Properties. The set of available paths can change over time, so the impleme
entation should monitor network path changes, and change the registration of the ntation should monitor network path changes and change the registration of the L
Listener across all usable paths as appropriate. When using multiple paths, the istener across all usable paths as appropriate. When using multiple paths, the L
Listener is generally expected to use the same port for listening on each.</t> istener is generally expected to use the same port for listening on each.</t>
<t>If the Selection Properties allow multiple protocols to be used for l <t>If the Selection Properties allow multiple protocols to be used for l
istening, and the implementation supports it, the Listener object should support istening and the implementation supports it, the Listener object should support
receiving inbound connections for each eligible protocol on each eligible path. receiving inbound connections for each eligible protocol on each eligible path.<
</t> /t>
<section anchor="implementing-listeners-for-connected-protocols"> <section anchor="implementing-listeners-for-connected-protocols">
<name>Implementing Listeners for Connected Protocols</name> <name>Implementing Listeners for Connected Protocols</name>
<t>Connected protocols such as TCP and TLS-over-TCP have a strong mapp ing between the Local and Remote Endpoint Identifers (four-tuple) and their prot ocol connection state. These map into Connection objects. Whenever a new inbound handshake is being started, the Listener should generate a new Connection objec t and pass it to the application.</t> <t>Connected protocols such as TCP and TLS-over-TCP have a strong mapp ing between the Local and Remote Endpoint Identifiers (four-tuple) and their pro tocol connection state. These map to Connection objects. Whenever a new inbound handshake is being started, the Listener should generate a new Connection object and pass it to the application.</t>
</section> </section>
<section anchor="implementing-listeners-for-connectionless-protocols"> <section anchor="implementing-listeners-for-connectionless-protocols">
<name>Implementing Listeners for Connectionless Protocols</name> <name>Implementing Listeners for Connectionless Protocols</name>
<t>Connectionless protocols such as UDP and UDP-lite generally do not provide the same mechanisms that connected protocols do to offer Connection obje cts. Implementations should wait for incoming packets for connectionless protoc ols on a listening port and should perform four-tuple matching of packets to exi sting Connection objects if possible. If a matching Connection object does not e xist, an incoming packet from a connectionless protocol should cause a new Conne ction object to be created.</t> <t>Connectionless protocols such as UDP and UDP-Lite generally do not provide the same mechanisms that Connected protocols do to offer Connection obje cts. Implementations should wait for incoming packets for connectionless protoc ols on a listening port and should perform four-tuple matching of packets to exi sting Connection objects if possible. If a matching Connection object does not e xist, an incoming packet from a connectionless protocol should cause a new Conne ction object to be created.</t>
</section> </section>
<section anchor="implementing-listeners-for-multiplexed-protocols"> <section anchor="implementing-listeners-for-multiplexed-protocols">
<name>Implementing Listeners for Multiplexed Protocols</name> <name>Implementing Listeners for Multiplexed Protocols</name>
<t>Protocols that provide multiplexing of streams can listen for entir ely new connections as well as for new sub-connections (streams of an already ex isting connection). A new stream arrival on an existing connection is presented to the application as a new Connection. This new Connection is grouped with all other Connections that are multiplexed via the same protocol.</t> <t>Protocols that provide multiplexing of streams can listen for entir ely new connections as well as for new subconnections (streams of an already-exi sting connection). A new stream arrival on an existing connection is presented t o the application as a new Connection. This new Connection is grouped with all o ther Connections that are multiplexed via the same protocol.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="implementing-sending-and-receiving-data"> <section anchor="implementing-sending-and-receiving-data">
<name>Implementing Sending and Receiving Data</name> <name>Implementing Sending and Receiving Data</name>
<t>The most basic mapping for sending a Message is an abstraction of datag rams, in which the transport protocol naturally deals in discrete packets (such as UDP). Each Message here corresponds to a single datagram.</t> <t>The most basic mapping for sending a Message is an abstraction of datag rams, in which the transport protocol naturally deals in discrete packets (such as UDP). Each Message here corresponds to a single datagram.</t>
<t>For protocols that expose byte-streams (such as TCP), the only delineat ion provided by the protocol is the end of the stream in a given direction. Each Message in this case corresponds to the entire stream of bytes in a direction. These Messages may be quite long, in which case they can be sent in multiple par ts.</t> <t>For protocols that expose byte-streams (such as TCP), the only delineat ion provided by the protocol is the end of the stream in a given direction. Each Message in this case corresponds to the entire stream of bytes in a direction. These Messages may be quite long, in which case they can be sent in multiple par ts.</t>
<t>Protocols that provide framing (such as length-value protocols, or prot ocols that use delimiters like HTTP/1.1) may support Message sizes that do not f it within a single datagram. Each Message for framing protocols corresponds to a single frame, which may be sent either as a complete Message in the underlying protocol, or in multiple parts.</t> <t>Protocols that provide framing (such as length-value protocols, or prot ocols that use delimiters like HTTP/1.1) may support Message sizes that do not f it within a single datagram. Each Message for framing protocols corresponds to a single frame, which may be sent either as a complete Message in the underlying protocol or in multiple parts.</t>
<t>Messages themselves generally consist of bytes passed in the messageDat a parameter intended to be processed at an application layer. However, Message o bjects presented through the API <t>Messages themselves generally consist of bytes passed in the messageDat a parameter intended to be processed at an application layer. However, Message o bjects presented through the API
can carry associated Message Properties passed through the messageContext parame ter. can carry associated Message Properties passed through the messageContext parame ter.
When these are Protocol Specific Properties, they can include metadata that exis When these are Protocol-specific Properties, they can include metadata that exis
ts separately from a byte ts separately from a byte
encoding. For example, these Properties can include name-value pairs of informat encoding. For example, these Properties can include name-value pairs of informat
ion, like HTTP header fields. In such cases, Messages might be "empty", ion, like HTTP header fields. In such cases, Messages might be "empty"
insofar as they contain zero bytes in the messageData parameter, but can still i insofar as they contain zero bytes in the messageData parameter, but they can st
nclude data in the messageContext that is interpreted by the Protocol Stack.</t> ill include data in the messageContext that is interpreted by the Protocol Stack
.</t>
<section anchor="sending-messages"> <section anchor="sending-messages">
<name>Sending Messages</name> <name>Sending Messages</name>
<t>The effect of the application sending a Message is determined by the top-level protocol in the established Protocol Stack. That is, if the top-level protocol provides an abstraction of framed Messages over a connection, the recei ving application will be able to obtain multiple Messages on that connection, ev en if the framing protocol is built on a byte-stream protocol like TCP.</t> <t>The effect of the application sending a Message is determined by the top-level protocol in the established Protocol Stack. That is, if the top-level protocol provides an abstraction of framed Messages over a connection, the recei ving application will be able to obtain multiple Messages on that connection, ev en if the framing protocol is built on a byte-stream protocol like TCP.</t>
<section anchor="msg-properties"> <section anchor="msg-properties">
<name>Message Properties</name> <name>Message Properties</name>
<t>The API allows various properties to be associated with each Messag e, which should be implemented as discussed below.</t> <t>The API allows various properties to be associated with each Messag e, which should be implemented as discussed below.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t><tt>msgLifetime</tt>: this should be implemented by removing th <dt><tt>msgLifetime</tt>:</dt><dd>this should be implemented by re
e Message from the queue of pending Messages after the Lifetime has expired. A q moving the Message from the queue of pending Messages after the Lifetime has exp
ueue of pending Messages within the Transport Services Implementation that have ired. A queue of pending Messages within the Transport Services Implementation t
yet to be handed to the Protocol Stack can always support this property, but onc hat have yet to be handed to the Protocol Stack can always support this property
e a Message has been sent into the send buffer of a protocol, only certain proto , but once a Message has been sent into the send buffer of a protocol, only cert
cols may support removing it from their send buffer. For example, a Transport Se ain protocols may support removing it from their send buffer. For example, a Tra
rvices Implementation cannot remove bytes from a TCP send buffer, while it can r nsport Services Implementation cannot remove bytes from a TCP send buffer, while
emove data from a SCTP send buffer using the partial reliability extension <xref it can remove data from an SCTP send buffer using the partial reliability exten
target="RFC8303"/>. When there is no standing queue of Messages within the syst sion <xref target="RFC8303"/>. When there is no standing queue of Messages withi
em, and the Protocol Stack does not support the removal of a Message from the st n the system, and the Protocol Stack does not support the removal of a Message f
ack's send buffer, this property may be ignored.</t> rom the stack's send buffer, this property may be ignored.</dd>
</li>
<li> <dt><tt>msgPriority</tt>:</dt><dd>this represents the ability to p
<t><tt>msgPriority</tt>: this represents the ability to prioritize rioritize a Message over other Messages. This can be implemented by the Transpor
a Message over other Messages. This can be implemented by the Transport Service t Services system by reordering Messages that have yet to be handed to the Proto
s system by re-ordering Messages that have yet to be handed to the Protocol Stac col Stack or by giving relative priority hints to protocols that support priorit
k, or by giving relative priority hints to protocols that support priorities per ies per Message. For example, an implementation of HTTP/2 could choose to send M
Message. For example, an implementation of HTTP/2 could choose to send Messages essages of different priority on streams of different priority.</dd>
of different priority on streams of different priority.</t>
</li> <!--[rfced] The double use of "this" seems strange in these sentences.
<li> Please rephrase.
<t><tt>msgOrdered</tt>: when this is false, this disables the requ
irement of in-order-delivery for protocols that support configurable ordering. W Original:
hen the Protocol Stack does not support configurable ordering, this property may when this is false, this disables the requirement of
be ignored.</t> in-order-delivery for protocols that support configurable ordering.
</li>
<li> and
<t><tt>safelyReplayable</tt>: when this is true, this means that t
he Message can be used by a transport mechanism that might deliver it multiple t Original:
imes -- e.g., as a result of racing multiple transports or as part of TCP Fast O when this is true, this means that the Message can be used by a
pen. Also, protocols that do not protect against duplicated Messages, such as UD transport mechanism that might deliver it multiple times...
P (when used directly, without a protocol layered atop), can only be used with M
essages that are Safely Replayable. When a Transport Services system is permitte and
d to replay Messages, replay protection could be provided by the application.</t
> Original:
</li> when this is true, this means that the sender will not send any
<li> further Messages.
<t><tt>final</tt>: when this is true, this means that the sender w
ill not send any further Messages. The Connection need not be closed (in case th -->
e Protocol Stack supports half-close operation, like TCP). Any Messages sent aft
er a Message marked <tt>final</tt> will result in a SendError.</t> <dt><tt>msgOrdered</tt>:</dt><dd>When this is false, this disables
</li> the requirement of in-order delivery for protocols that support configurable or
<li> dering. When the Protocol Stack does not support configurable ordering, this pro
<t><tt>msgChecksumLen</tt>: when this is set to any value other th perty may be ignored.</dd>
an <tt>Full Coverage</tt>, it sets the minimum protection in protocols that allo
w limiting the checksum length (e.g. UDP-Lite). If the Protocol Stack does not s <dt><tt>safelyReplayable</tt>:</dt><dd>When this is true, this mea
upport checksum length limitation, this property may be ignored.</t> ns that the Message can be used by a transport mechanism that might deliver it m
</li> ultiple times -- e.g., as a result of racing multiple transports or as part of T
<li> CP Fast Open (TFO). Also, protocols that do not protect against duplicated Messa
<t><tt>msgReliable</tt>: When true, the property specifies that th ges, such as UDP (when used directly, without a protocol layered atop), can only
e Message must be reliably transmitted. When false, and if unreliable transmissi be used with Messages that are Safely Replayable. When a Transport Services sys
on is supported by the underlying protocol, then the Message should be unreliabl tem is permitted to replay Messages, replay protection could be provided by the
y transmitted. If the underlying application.</dd>
protocol does not support unreliable transmission, the Message should be reliabl
y transmitted.</t> <dt><tt>final</tt>:</dt><dd>When this is true, this means that the
</li> sender will not send any further Messages. The Connection need not be closed (i
<li> f the Protocol Stack supports half-closed operations, like TCP). Any Messages se
<t><tt>msgCapacityProfile</tt>: When true, this expresses a wish t nt after a Message marked <tt>final</tt> will result in a SendError.</dd>
o override the
<dt><tt>msgChecksumLen</tt>:</dt><dd>When this is set to any value
other than <tt>Full Coverage</tt>, it sets the minimum protection in protocols
that allow limiting the checksum length (e.g., UDP-Lite). If the Protocol Stack
does not support checksum length limitation, this property may be ignored.</dd>
<dt><tt>msgReliable</tt>:</dt><dd>When true, the property specifie
s that the Message must be reliably transmitted. When false, and if unreliable t
ransmission is supported by the underlying protocol, then the Message should be
unreliably transmitted. If the underlying
protocol does not support unreliable transmission, the Message should be reliabl
y transmitted.</dd>
<dt><tt>msgCapacityProfile</tt>:</dt><dd>When true, this expresses
a wish to override the
Generic Connection Property <tt>connCapacityProfile</tt> for this Message. Depen ding on the Generic Connection Property <tt>connCapacityProfile</tt> for this Message. Depen ding on the
value, this can, for example, be implemented by changing the DSCP value of the value, this can, for example, be implemented by changing the Differentiated Serv
associated packet (note that the guidelines in <xref section="6" sectionFormat=" ices Code Point (DSCP) value of the
of" target="RFC7657"/> apply; e.g., associated packet (note that the guidelines in <xref section="6" sectionFormat="
of" target="RFC7657"/> apply; for example,
the DSCP value should not be changed for different packets within a reliable the DSCP value should not be changed for different packets within a reliable
transport protocol session or DCCP connection).</t> transport protocol session or DCCP connection).</dd>
</li>
<li> <dt><tt>noFragmentation</tt>:</dt><dd>Setting this avoids network-
<t><tt>noFragmentation</tt>: Setting this avoids network-layer fra layer fragmentation. Messages exceeding the transport's current estimate of its
gmentation. Messages exceeding the transport’s current estimate of its maximum p maximum packet size (the <tt>singularTransmissionMsgMaxLen</tt> Connection Prope
acket size (the <tt>singularTransmissionMsgMaxLen</tt> Connection Property) can rty) can result in transport segmentation when permitted or generate an error. W
result in transport segmentation when permitted, or generate an error. When used hen used with transports running over IPv4, the Don't Fragment (DF) bit should b
with transports running over IP version 4, the Don't Fragment bit should be set e set to avoid on-path IP fragmentation <xref target="RFC8304"/>.</dd>
to avoid on-path IP fragmentation (<xref target="RFC8304"/>).</t>
</li> <dt><tt>noSegmentation</tt>:</dt><dd>When set, this property limit
<li> s the Message size to the transport's current estimate of its maximum packet siz
<t><tt>noSegmentation</tt>: When set, this property limits the Mes e (the <tt>singularTransmissionMsgMaxLen</tt> Connection Property). Messages lar
sage size to the transport’s current estimate of its maximum packet size (the <t ger than this size generate an error. Setting this avoids transport-layer segmen
t>singularTransmissionMsgMaxLen</tt> Connection Property). Messages larger than tation and network-layer fragmentation. When used with transports running over I
this size generate an error. Setting this avoids transport-layer segmentation an Pv4, the DF bit should be set to avoid on-path IP fragmentation (<xref target="R
d network-layer fragmentation. When used with transports running over IP version FC8304"/>).</dd>
4, the Don't Fragment bit should be set to avoid on-path IP fragmentation (<xre </dl>
f target="RFC8304"/>).</t>
</li>
</ul>
</section> </section>
<section anchor="send-completion"> <section anchor="send-completion">
<name>Send Completion</name> <name>Send Completion</name>
<t>The application should be notified (using a <tt>Sent</tt>, <tt>Expi red</tt> or <tt>SendError</tt> event) whenever a Message or partial Message has been consumed by the Protocol Stack, or has failed to send. The time at which a Message is considered to have been consumed by the Protocol Stack may vary depen ding on the protocol. For example, for a basic datagram protocol like UDP, this may correspond to the time when the packet is sent into the interface driver. Fo r a protocol that buffers data in queues, like TCP, this may correspond to when the data has entered the send buffer. The time at which a Message failed to send is when the Transport Services Implementation (including the Protocol Stack) ha s experienced a failure related to sending; this can depend on protocol-specific timeouts.</t> <t>The application should be notified (using a <tt>Sent</tt>, <tt>Expi red</tt>, or <tt>SendError</tt> event) whenever a Message or partial Message has been consumed by the Protocol Stack or has failed to send. The time at which a Message is considered to have been consumed by the Protocol Stack may vary depen ding on the protocol. For example, for a basic datagram protocol like UDP, this may correspond to the time when the packet is sent into the interface driver. Fo r a protocol that buffers data in queues, like TCP, this may correspond to when the data has entered the send buffer. The time at which a Message failed to send is when the Transport Services Implementation (including the Protocol Stack) ha s experienced a failure related to sending; this can depend on protocol-specific timeouts.</t>
</section> </section>
<section anchor="batching-sends"> <section anchor="batching-sends">
<name>Batching Sends</name> <name>Batching Sends</name>
<t>Sending multiple Messages can incur high overhead if each needs to be enqueued separately (e.g., each Message might involve a context switch betwee n the <t>Sending multiple Messages can incur high overhead if each needs to be enqueued separately (e.g., each Message might involve a context switch betwee n the
application and the Transport Services System). To avoid this, the application c an indicate a batch of <tt>Send</tt> actions through the API. When this is used, application and the Transport Services System). To avoid this, the application c an indicate a batch of <tt>Send</tt> actions through the API. When this is used,
the implementation can defer the processing of Messages until the batch is compl ete.</t> the implementation can defer the processing of Messages until the batch is compl ete.</t>
</section> </section>
</section> </section>
<section anchor="receiving-messages"> <section anchor="receiving-messages">
<name>Receiving Messages</name> <name>Receiving Messages</name>
<t>Similar to sending, receiving a Message is determined by the top-leve <t>Similar to sending, receiving a Message is determined by the top-leve
l protocol in the established Protocol Stack. The main difference with receiving l protocol in the established Protocol Stack. The main difference with receiving
is that the size and boundaries of the Message are not known beforehand. The ap is that the size and boundaries of the Message are not known beforehand. The ap
plication can communicate in its <tt>Receive</tt> action the parameters for the plication can communicate the parameters for the Message in its <tt>Receive</tt>
Message, which can help the Transport Services Implementation know how much data action, which can help the Transport Services Implementation know how much data
to deliver and when. For example, if the application only wants to receive a co to deliver and when. For example, if the application only wants to receive a co
mplete Message, the implementation should wait until an entire Message (datagram mplete Message, the implementation should wait until an entire Message (datagram
, stream, or frame) is read before delivering any Message content to the applica , stream, or frame) is read before delivering any Message content to the applica
tion. This requires the implementation to understand where Messages end, either tion. This requires the implementation to understand where Messages end, either
via a supplied Message Framer or because the top-level protocol in the establish via a supplied Message Framer or because the top-level protocol in the establish
ed Protocol Stack preserves message boundaries. The application can also control ed Protocol Stack preserves message boundaries. The application can also control
the flow of received data by specifying the minimum and maximum number of bytes the flow of received data by specifying the minimum and maximum number of bytes
of Message content it wants to receive at one time.</t> of Message content it wants to receive at one time.</t>
<!-- [rfced] For readability, please consider whether the suggested
text correctly conveys the intended meaning.
Original:
If a Connection finishes before a requested Receive action can be
satisfied, the Transport Services system should deliver any partial
Message content outstanding, or if none is available, an indication
that there will be no more received Messages.
Perhaps:
If a Connection finishes before a requested Receive action can be
satisfied, the Transport Services system should deliver any
outstanding partial Message content; if none is available, the
system should indicate that there will be no additional received
Messages.
-->
<t>If a Connection finishes before a requested <tt>Receive</tt> action c an be satisfied, the Transport Services system should deliver any partial Messag e content outstanding, or if none is available, an indication that there will be no more received Messages.</t> <t>If a Connection finishes before a requested <tt>Receive</tt> action c an be satisfied, the Transport Services system should deliver any partial Messag e content outstanding, or if none is available, an indication that there will be no more received Messages.</t>
</section> </section>
<section anchor="fastopen"> <section anchor="fastopen">
<name>Handling of data for fast-open protocols</name> <name>Handling of Data for Fast-Open Protocols</name>
<t>Several protocols allow sending higher-level protocol or application <t>Several protocols allow sending higher-level protocol or application
data during their protocol establishment, such as TCP Fast Open <xref target="RF data during their protocol establishment, such as TFO <xref target="RFC7413"/> a
C7413"/> and TLS 1.3 <xref target="RFC8446"/>. This approach is referred to as s nd TLS 1.3 <xref target="RFC8446"/>. This approach is referred to as sending Zer
ending Zero-RTT (0-RTT) data. This is a desirable feature, but poses challenges o-RTT (0-RTT) data. This is a desirable feature, but it poses challenges to an i
to an implementation that uses racing during connection establishment.</t> mplementation that uses racing during connection establishment.</t>
<t>The application can express its preference for sending messagess as 0 <t>The application can express its preference for sending messages as 0-
-RTT data by using the <tt>zeroRttMsg</tt> Selection Property on the Preconnecti RTT data by using the <tt>zeroRttMsg</tt> Selection Property on the Preconnectio
on. Then, the application can provide the message to send as 0-RTT data via the n. Then, the application can provide the message to send as 0-RTT data via the <
<tt>InitiateWithSend</tt> action. In order to be sent as 0-RTT data, the message tt>InitiateWithSend</tt> action. In order to be sent as 0-RTT data, the message
needs to be marked with the <tt>safelyReplayable</tt> send paramteter. In gener needs to be marked with the <tt>safelyReplayable</tt> send parameter. In general
al, 0-RTT data may be replayed (for example, if a TCP SYN contains data, and the , 0-RTT data may be replayed (for example, if a TCP SYN contains data, and the S
SYN is retransmitted, the data will be retransmitted as well but may be conside YN is retransmitted, the data will be retransmitted as well but may be considere
red as a new connection instead of a retransmission). When racing connections, d d a new connection instead of a retransmission). When racing connections, differ
ifferent leaf nodes have the opportunity to send the same data independently. If ent leaf nodes have the opportunity to send the same data independently. If data
data is truly safely replayable, this is permissible.</t> is truly safely replayable, this is permissible.</t>
<t>Once the application has provided its 0-RTT data, a Transport Service <t>Once the application has provided its 0-RTT data, a Transport Service
s Implementation should keep a copy of this data and provide it to each new leaf s Implementation should keep a copy of this data and provide it to each new leaf
node that is started and for which a protocol instance supporting 0-RTT is bein node that is started and for which a protocol instance supporting 0-RTT is bein
g used. Note that the amount of data that can actually be sent as 0-RTT data var g used. Note that the amount of data that can actually be sent as 0-RTT data var
ies by protocol, so any given Protocol Stack might only consume part of the save ies by protocol, so any given Protocol Stack might only consume part of the save
d data prior to becoming established. The implementation needs to keep track of d data prior to becoming established. The implementation needs to keep track of
how much data a particular Protocol Stack has consumed, and ensure that any pend how much data a particular Protocol Stack has consumed and ensure that any pendi
ing 0-RTT-eligible data from the application is handled before subsequent Messag ng 0-RTT-eligible data from the application is handled before subsequent Message
es.</t> s.</t>
<t>It is also possible for Protocol Stacks within a particular leaf node <t>It is also possible for Protocol Stacks within a particular leaf node
to use a 0-RTT handshakes in a lower-level protocol without any safely replayab to use a 0-RTT handshake in a lower-level protocol without any safely replayabl
le application data if a higher-level protocol in the stack has idempotent hands e application data if a higher-level protocol in the stack has idempotent handsh
hake data to send. For example, TCP Fast Open could use a Client Hello from TLS ake data to send. For example, TFO could use a Client Hello from TLS as its 0-RT
as its 0-RTT data, without any data being provided by the application.</t> T data without any data being provided by the application.</t>
<t>0-RTT handshakes often rely on previous state, such as TCP Fast Open
cookies, previously established TLS tickets, or out-of-band distributed pre-shar <!-- [rfced] For clarity, may we replace "yet" with "but the data will
ed keys (PSKs). Implementations should be aware of security concerns around usin be"?
g these tokens across multiple addresses or paths when racing. In the case of TL
S, any given ticket or PSK should only be used on one leaf node, since servers w Original:
ill likely reject duplicate tickets in order to prevent replays (see <xref secti In effect, each leaf node will send the same
on="8.1" sectionFormat="of" target="RFC8446"/>). If implementations have multipl early application data, yet encoded (encrypted) differently on the
e tickets available from a previous connection, each leaf node attempt can use a wire.
different ticket. In effect, each leaf node will send the same early applicatio
n data, yet encoded (encrypted) differently on the wire.</t> Perhaps:
In effect, each leaf node will send the same early application
data, but the data will be encoded (encrypted) differently on the
wire.
-->
<t>0-RTT handshakes often rely on previous state, such as TFO cookies, p
reviously established TLS tickets, or out-of-band distributed pre-shared keys (P
SKs). Implementations should be aware of security concerns around using these to
kens across multiple addresses or paths when racing. In the case of TLS, any giv
en ticket or PSK should only be used on one leaf node, since servers will likely
reject duplicate tickets in order to prevent replays (see <xref section="8.1" s
ectionFormat="of" target="RFC8446"/>). If implementations have multiple tickets
available from a previous connection, each leaf node attempt can use a different
ticket. In effect, each leaf node will send the same early application data, ye
t encoded (encrypted) differently on the wire.</t>
</section> </section>
</section> </section>
<section anchor="message-framers"> <section anchor="message-framers">
<name>Implementing Message Framers</name> <name>Implementing Message Framers</name>
<t>Message Framers are functions that define <t>Message Framers are functions that define
simple transformations between application Message data and raw transport simple transformations between application Message data and raw transport
protocol data. Generally, a Message Framer implements a simple protocol data. Generally, a Message Framer implements a simple
application protocol that can either be provided by the Transport Services application protocol that can be provided either by the Transport Services
implementation or by the application. It is optional for Transport Services syst implementation or by the application. It is optional for Transport Services syst
em implementations to provide Message Framers: the specification <xref target="I em implementations to provide Message Framers: the API specification <xref targe
-D.ietf-taps-interface"/> does not prescribe any particular Message Framers to b t="RFC9622"/> does not prescribe any particular Message Framers to be implemente
e implemented. d.
A Framer can encapsulate or encode outbound Messages, A Framer can encapsulate or encode outbound Messages,
decapsulate or decode inbound data into Messages, and implement parts of decapsulate or decode inbound data into Messages, and implement parts of
protocols that do not directly map to application Messages (such as protocols that do not directly map to application Messages (such as
protocol handshakes or preludes before Message exchange).</t> protocol handshakes or preludes before Message exchange).</t>
<t>While many protocols can be represented as Message Framers, for the <t>While many protocols can be represented as Message Framers, for the
purposes of the Transport Services API, these are ways for applications purposes of the Transport Services API, these are ways for applications
or application frameworks to define their own Message parsing to be or application frameworks to define their own Message parsing to be
included within a Connection's Protocol Stack. As an example, TLS included within a Connection's Protocol Stack. As an example, TLS
is a protocol that is by default built into the Transport Services is a protocol that is by default built into the Transport Services
API, even though it could also serve the purpose of framing data over TCP.</t> API, even though it could also serve the purpose of framing data over TCP.</t>
skipping to change at line 564 skipping to change at line 872
<li> <li>
<t>Header-prefixed record formats, such as a basic Type-Length-Value ( TLV) structure</t> <t>Header-prefixed record formats, such as a basic Type-Length-Value ( TLV) structure</t>
</li> </li>
<li> <li>
<t>Delimiter-separated formats, such as HTTP/1.1</t> <t>Delimiter-separated formats, such as HTTP/1.1</t>
</li> </li>
</ul> </ul>
<t>Common Message Framers can be provided by a Transport Services Implemen tation, <t>Common Message Framers can be provided by a Transport Services Implemen tation,
but an implementation ought to allow custom Message Framers to be defined by but an implementation ought to allow custom Message Framers to be defined by
the application or some other piece of software. This section describes one the application or some other piece of software. This section describes one
possible API for defining Message Framers, as an example.</t> possible API for defining Message Framers as an example.</t>
<section anchor="defining-message-framers"> <section anchor="defining-message-framers">
<name>Defining Message Framers</name> <name>Defining Message Framers</name>
<!--[rfced] Looking at the following text, is this defining what
Message Framer means? If so, please review the fact that the
paragraph also starts out with a definition. Please let us know
what revisions may be needed.
Original:
The Message Framer refers to the object or function within
the main Connection implementation that delivers events to the custom
framer implementation whenever data is ready to be parsed or framed.
The paragraph starts with:
A Message Framer is primarily defined by the code that handles events
for a framer implementation, specifically how it handles inbound and
outbound data parsing.
-->
<t>A Message Framer is primarily defined by the code that handles events <t>A Message Framer is primarily defined by the code that handles events
for a framer implementation, specifically how it handles inbound and outbound da ta for a framer implementation, specifically how it handles inbound and outbound da ta
parsing. The function that implements custom framing logic will be referred to parsing. The function that implements custom framing logic will be referred to
as the "framer implementation", which may be provided by a Transport Services as the "framer implementation", which may be provided by a Transport Services
implementation or the application itself. The Message Framer refers to the objec t implementation or the application itself. The Message Framer refers to the objec t
or function within the main Connection implementation that delivers events or function within the main Connection implementation that delivers events
to the custom framer implementation whenever data is ready to be parsed or frame d.</t> to the custom framer implementation whenever data is ready to be parsed or frame d.</t>
<t>The API examples in this section use the notation conventions for the Transport <t>The API examples in this section use the notation conventions for the Transport
Services API defined in <xref section="1.1" sectionFormat="of" target="I-D.ietf- taps-interface"/>.</t> Services API defined in <xref section="1.1" sectionFormat="of" target="RFC9622"/ >.</t>
<t>The Transport Services Implementation needs to ensure that all of the <t>The Transport Services Implementation needs to ensure that all of the
events and actions taken on a Message Framer are synchronized to ensure events and actions taken on a Message Framer are synchronized to ensure
consistent behavior. For example, some of the actions defined below (such as consistent behavior. For example, some of the actions defined below (such as
PrependFramer and StartPassthrough) modify how data flows in a protocol PrependFramer and StartPassthrough) modify how data flows in a Protocol
stack, and require synchronization with sending and parsing data in the Stack and require synchronization with sending and parsing data in the
Message Framer.</t> Message Framer.</t>
<!-- [rfced] Please confirm that "stop event" should be "<tt>Stop</tt>
event".
Original (no caps or <tt>):
Similarly, a stop event can be delivered when a
Connection is being torn down.
-->
<t>When a Connection establishment attempt begins, an event can be deliv ered to <t>When a Connection establishment attempt begins, an event can be deliv ered to
notify the framer implementation that a new Connection is being created. notify the framer implementation that a new Connection is being created.
Similarly, a stop event can be delivered when a Connection is being torn down. Similarly, a stop event can be delivered when a Connection is being torn down.
The framer implementation can use the Connection object to look up specific The framer implementation can use the Connection object to look up specific
properties of the Connection or the network being used that may influence how properties of the Connection or the network being used that may influence how
to frame Messages.</t> to frame Messages.</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer -> Start<connection> MessageFramer -> Start<connection>
MessageFramer -> Stop<connection> MessageFramer -> Stop<connection>
]]></artwork> ]]></artwork>
<t>When a Message Framer generates a <tt>Start</tt> event, the framer im plementation <t>When a Message Framer generates a <tt>Start</tt> event, the framer im plementation
has the opportunity to start writing some data prior to the Connection deliverin g has the opportunity to start writing some data prior to the Connection deliverin g
its <tt>Ready</tt> event. This allows the implementation to communicate control data to the its <tt>Ready</tt> event. This allows the implementation to communicate control data to the
Remote Endpoint that can be used to parse Messages.</t> Remote Endpoint that can be used to parse Messages.</t>
<t>Once the framer implementation has completed its setup or handshake, it can indicate to <t>Once the framer implementation has completed its setup or handshake, it can indicate to
the application that it is ready for handling data with this call.</t> the application that it is ready for handling data with this call.</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer.MakeConnectionReady(connection) MessageFramer.MakeConnectionReady(connection)
]]></artwork> ]]></artwork>
<t>Similarly, when a Message Framer generates a <tt>Stop</tt> event, the framer implementation has the opportunity to write some final data or clear up its local state before the <tt>Closed</tt> event is delivered to the Application . The framer implementation can indicate that it has finished with this call.</t > <t>Similarly, when a Message Framer generates a <tt>Stop</tt> event, the framer implementation has the opportunity to write some final data or clear up its local state before the <tt>Closed</tt> event is delivered to the application . The framer implementation can indicate that it has finished with this call.</t >
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer.MakeConnectionClosed(connection) MessageFramer.MakeConnectionClosed(connection)
]]></artwork> ]]></artwork>
<t>At any time if the implementation encounters a fatal error, it can al so cause the Connection <t>If the implementation encounters a fatal error at any time, it can al so cause the Connection
to fail and provide an error.</t> to fail and provide an error.</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer.FailConnection(connection, error) MessageFramer.FailConnection(connection, error)
]]></artwork> ]]></artwork>
<t>Should the framer implementation deem the candidate selected during r acing unsuitable, it can signal this to the Transport Services API by failing th e Connection prior to marking it as ready. <t>Should the framer implementation deem the candidate selected during r acing unsuitable, it can signal this to the Transport Services API by failing th e Connection prior to marking it as ready.
If there are no other candidates available, the Connection will fail. Otherwise, the Connection will select a different candidate and the Message Framer will ge nerate a new <tt>Start</tt> event.</t> If there are no other candidates available, the Connection will fail. Otherwise, the Connection will select a different candidate and the Message Framer will ge nerate a new <tt>Start</tt> event.</t>
<t>Before an implementation marks a Message Framer as ready, it can also dynamically <t>Before an implementation marks a Message Framer as ready, it can also dynamically
add a protocol or framer above it in the stack. This allows protocols that need to add TLS conditionally, add a protocol or framer above it in the stack. This allows protocols that need to add TLS conditionally,
like STARTTLS <xref target="RFC3207"/>, to modify the Protocol Stack based on a handshake result.</t> like STARTTLS <xref target="RFC3207"/>, to modify the Protocol Stack based on a handshake result.</t>
<artwork><![CDATA[ <artwork><![CDATA[
otherFramer := NewMessageFramer() otherFramer := NewMessageFramer()
MessageFramer.PrependFramer(connection, otherFramer) MessageFramer.PrependFramer(connection, otherFramer)
]]></artwork> ]]></artwork>
<!-- [rfced] Does "at first" mean "initially"?
Original:
In such cases, a Message Framer implementation can intercept
sending and receiving of Messages at first, but then indicate that
no more processing is needed.
Perhaps:
In such cases, a Message Framer implementation can initially
intercept Messages being sent and received and subsequently
indicate that no further processing is needed.
-->
<t>A Message Framer might also choose to go into a passthrough mode once an initial exchange or handshake has been completed, such as the STARTTLS case mentioned above. <t>A Message Framer might also choose to go into a passthrough mode once an initial exchange or handshake has been completed, such as the STARTTLS case mentioned above.
This can also be useful for proxy protocols like SOCKS <xref target="RFC1928"/> or HTTP CONNECT <xref target="RFC7230"/>. In such cases, a Message Framer implem entation can intercept This can also be useful for proxy protocols like SOCKS <xref target="RFC1928"/> or HTTP CONNECT <xref target="RFC7230"/>. In such cases, a Message Framer implem entation can intercept
sending and receiving of Messages at first, but then indicate that no more proce ssing is needed.</t> sending and receiving of Messages at first, but then indicate that no more proce ssing is needed.</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer.StartPassthrough() MessageFramer.StartPassthrough()
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="send-framing"> <section anchor="send-framing">
<name>Sender-side Message Framing</name> <name>Sender-Side Message Framing</name>
<t>Message Framers generate an event whenever a Connection sends a new M essage. The parameters to the event <t>Message Framers generate an event whenever a Connection sends a new M essage. The parameters to the event
align with the <tt>Send</tt> action in the API (<xref section="9.2" sectionForma t="of" target="I-D.ietf-taps-interface"/>).</t> align with the <tt>Send</tt> action in the API (<xref section="9.2" sectionForma t="of" target="RFC9622"/>).</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer MessageFramer
| |
V V
NewSentMessage<connection, messageData, messageContext, endOfMessage> NewSentMessage<connection, messageData, messageContext, endOfMessage>
]]></artwork> ]]></artwork>
<t>Upon receiving this event, a framer implementation is responsible for <t>Upon receiving this event, a framer implementation is responsible for
performing any necessary transformations and sending the resulting data back to the Message Framer, which will in turn send it to the next protocol. performing any necessary transformations and sending the resulting data back to the Message Framer, which, in turn, will send it to the next protocol.
To improve performance, implementations should ensure that there is a way to pas s the original data To improve performance, implementations should ensure that there is a way to pas s the original data
through without copying.</t> through without copying.</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer.Send(connection, messageData) MessageFramer.Send(connection, messageData)
]]></artwork> ]]></artwork>
<t>To provide an example, a simple protocol that adds the length of the Message data as a header would receive <t>To provide an example, a simple protocol that adds the length of the Message data as a header would receive
the <tt>NewSentMessage</tt> event, create a data representation of the length of the Message the <tt>NewSentMessage</tt> event, create a data representation of the length of the Message
data, and then send a block of data that is the concatenation of the length head er and the original data, and then send a block of data that is the concatenation of the length head er and the original
Message data.</t> Message data.</t>
</section> </section>
<section anchor="receive-framing"> <section anchor="receive-framing">
<name>Receiver-side Message Framing</name> <name>Receiver-Side Message Framing</name>
<t>In order to parse a received flow of data into Messages, the Message Framer <t>In order to parse a received flow of data into Messages, the Message Framer
notifies the framer implementation whenever new data is available to parse.</t> notifies the framer implementation whenever new data is available to parse.</t>
<t>The parameters to the events and calls for receiving data with a fram er <t>The parameters to the events and calls for receiving data with a fram er
align with the <tt>Receive</tt> action in the API (<xref section="9.3" sectionFo rmat="of" target="I-D.ietf-taps-interface"/>).</t> align with the <tt>Receive</tt> action in the API (<xref section="9.3" sectionFo rmat="of" target="RFC9622"/>).</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer -> HandleReceivedData<connection> MessageFramer -> HandleReceivedData<connection>
]]></artwork> ]]></artwork>
<t>Upon receiving this event, the framer implementation can inspect the inbound data. The <t>Upon receiving this event, the framer implementation can inspect the inbound data. The
data is parsed from a particular cursor representing the unprocessed data. The data is parsed from a particular cursor representing the unprocessed data. The
application requests a specific amount of data it needs to have available in ord er to parse. application requests a specific amount of data it needs to have available in ord er to parse.
If the data is not available, the parse fails.</t> If the data is not available, the parse fails.</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer.Parse(connection, minimumIncompleteLength, maximumLength) MessageFramer.Parse(connection, minimumIncompleteLength, maximumLength)
| |
V V
(messageData, messageContext, endOfMessage) (messageData, messageContext, endOfMessage)
]]></artwork> ]]></artwork>
<t>The framer implementation can directly advance the receive cursor onc e it has <t>The framer implementation can directly advance the receive cursor onc e it has
parsed data to effectively discard data (for example, discard a header parsed data to effectively discard data (for example, discard a header
once the content has been parsed).</t> once the content has been parsed).</t>
<t>To deliver a Message to the application, the framer implementation ca n either directly <t>To deliver a Message to the application, the framer implementation ca n either directly
deliver data that it has allocated, or deliver a range of data directly from the underlying deliver data that it has allocated or deliver a range of data directly from the underlying
transport and simultaneously advance the receive cursor.</t> transport and simultaneously advance the receive cursor.</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageFramer.AdvanceReceiveCursor(connection, length) MessageFramer.AdvanceReceiveCursor(connection, length)
MessageFramer.DeliverAndAdvanceReceiveCursor(connection, messageContext, length, endOfMessage) MessageFramer.DeliverAndAdvanceReceiveCursor(connection, messageContext, length, endOfMessage)
MessageFramer.Deliver(connection, messageContext, messageData, endOfMessage) MessageFramer.Deliver(connection, messageContext, messageData, endOfMessage)
]]></artwork> ]]></artwork>
<t>Note that <tt>MessageFramer.DeliverAndAdvanceReceiveCursor</tt> allow s the framer implementation <t>Note that <tt>MessageFramer.DeliverAndAdvanceReceiveCursor</tt> allow s the framer implementation
to earmark bytes as part of a Message even before they are received by the trans port. This allows the delivery to earmark bytes as part of a Message even before they are received by the trans port. This allows the delivery
of very large Messages without requiring the implementation to directly inspect all of the bytes.</t> of very large Messages without requiring the implementation to directly inspect all of the bytes.</t>
<t>To provide an example, a simple protocol that parses the length of th e Message data as a header value would <t>To provide an example, a simple protocol that parses the length of th e Message data as a header value would
receive the <tt>HandleReceivedData</tt> event, and call <tt>Parse</tt> with a mi nimum and maximum receive the <tt>HandleReceivedData</tt> event and call <tt>Parse</tt> with a min imum and maximum
set to the length of the header field. Once the parse succeeded, it would call set to the length of the header field. Once the parse succeeded, it would call
<tt>AdvanceReceiveCursor</tt> with the length of the header field, and then call <tt>AdvanceReceiveCursor</tt> with the length of the header field and then call
<tt>DeliverAndAdvanceReceiveCursor</tt> with the length of the body that was par sed from <tt>DeliverAndAdvanceReceiveCursor</tt> with the length of the body that was par sed from
the header, marking the new Message as complete.</t> the header, marking the new Message as complete.</t>
</section> </section>
</section> </section>
<section anchor="implementing-connection-management"> <section anchor="implementing-connection-management">
<name>Implementing Connection Management</name> <name>Implementing Connection Management</name>
<t>Once a Connection is established, the Transport Services API allows app lications to interact with the Connection by modifying or inspecting <t>Once a Connection is established, the Transport Services API allows app lications to interact with the Connection by modifying or inspecting
Connection Properties. A Connection can also generate error events in the form o f <tt>SoftError</tt> events.</t> Connection Properties. A Connection can also generate error events in the form o f <tt>SoftError</tt> events.</t>
<t>The set of Connection Properties that are supported for setting and get <t>The set of Connection Properties that are supported for setting and get
ting on a Connection are described in <xref target="I-D.ietf-taps-interface"/>. ting on a Connection are described in <xref target="RFC9622"/>. For
For any properties that are generic and, thus, could apply to all protocols being us
any properties that are generic, and thus could apply to all protocols being use ed by a Connection, the Transport Services Implementation should store the prope
d by a Connection, the Transport Services Implementation should store the proper rties
ties in storage common to all protocols and notify the Protocol Stack as a whole when
in storage common to all protocols, and notify the Protocol Stack as a whole whe ever the properties have been modified by the application. <xref target="RFC8303
never the properties have been modified by the application. <xref target="RFC830 "/> and <xref target="RFC8304"/> offer guidance on how to do this for TCP, Multi
3"/> and <xref target="RFC8304"/> offer guidance on how to do this for TCP, MPTC path TCP (MPTCP), SCTP, UDP, and UDP-Lite; see <xref target="specific-protocol-c
P, SCTP, UDP and UDP-Lite; see <xref target="specific-protocol-considerations"/> onsiderations"/> for a description of a backtracking method to find the relevant
for a description of a back-tracking method to find the relevant protocol primi protocol primitives using these documents.
tives using these documents. For Protocol-specific Properties, such as the User Timeout that applies to
For Protocol-specific Properties, such as the User Timeout that applies to TCP, TCP, the Transport Services Implementation only needs to update the relevant pr
the Transport Services Implementation only needs to update the relevant protocol otocol instance.</t>
instance.</t>
<!-- [rfced] Section 7: We note that this document uses "keepalives"
and refers to a "keepAlive" property. The other documents seem
to use "keep-alive" to refer to packets. Please review the use
of "keepalives" and let us know if any updates are needed.
Original:
For example, if the application has
requested to use keepalives with the keepAlive property, and the
Protocol Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can
choose to enable its own keepalives to satisfy the application
request, and disable TCP-level keepalives.
-->
<t>Some Connection Properties might apply to multiple protocols within a P rotocol Stack. Depending on the specific property, <t>Some Connection Properties might apply to multiple protocols within a P rotocol Stack. Depending on the specific property,
it might be appropriate to apply the property across multiple protocols simultan eously, or else only apply it to one protocol. it might be appropriate to apply the property across multiple protocols simultan eously or only apply it to one protocol.
In general, the Transport Services Implementation should allow the protocol clos est to the application to interpret In general, the Transport Services Implementation should allow the protocol clos est to the application to interpret
Connection Properties, and potentially modify the set of Connection Properties p assed down to the next protocol in the Connection Properties and, potentially, modify the set of Connection Properties passed down to the next protocol in the
stack. For example, if the application has requested to use keepalives with the <tt>keepAlive</tt> property, and the Protocol stack. For example, if the application has requested to use keepalives with the <tt>keepAlive</tt> property, and the Protocol
Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can choose to enable its own keepalives to satisfy the application Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can choose to enable its own keepalives to satisfy the application
request, and disable TCP-level keepalives. For cases where the application needs to have fine-grained per-protocol control, request and disable TCP-level keepalives. For cases where the application needs to have fine-grained per-protocol control,
the Transport Services Implementation can expose Protocol-specific Properties.</ t> the Transport Services Implementation can expose Protocol-specific Properties.</ t>
<t>If an error is encountered in setting a property (for example, if the a pplication tries to set a TCP-specific property on a Connection that is <t>If an error is encountered in setting a property (for example, if the a pplication tries to set a TCP-specific property on a Connection that is
not using TCP), the action must fail gracefully. The application must be informe d of the error, but the Connection itself must not be terminated.</t> not using TCP), the action must fail gracefully. The application must be informe d of the error but the Connection itself must not be terminated.</t>
<t>When protocol instances in the Protocol Stack report generic or protoco l-specific <t>When protocol instances in the Protocol Stack report generic or protoco l-specific
errors, the API will deliver them to the application as <tt>SoftError</tt> event s. These allow the application to be informed of ICMP errors, and other similar events.</t> errors, the API will deliver them to the application as <tt>SoftError</tt> event s. These allow the application to be informed of ICMP errors and other similar e vents.</t>
<section anchor="pooled-connections"> <section anchor="pooled-connections">
<name>Pooled Connection</name> <name>Pooled Connection</name>
<t>For applications that do not need in-order delivery of Messages, the Transport Services Implementation may distribute Messages of a single Connection across several underlying transport connections or multiple streams of multi-st reaming connections between endpoints, as long as all of these satisfy the Selec tion Properties. <t>For applications that do not need in-order delivery of Messages, the Transport Services Implementation may distribute Messages of a single Connection across several underlying transport connections or multiple streams of multi-st reaming connections between endpoints, as long as all of these satisfy the Selec tion Properties.
The Transport Services Implementation will then hide this connection management and only expose a single Connection object, which we here call a "Pooled Connect ion". This is in contrast to Connection Groups, which explicitly expose combined treatment of Connections, giving the application control over multiplexing, for example.</t> The Transport Services Implementation will then hide this connection management and only expose a single Connection object, which we call a "Pooled Connection". This is in contrast to Connection Groups, which explicitly expose combined trea tment of Connections, giving the application control over multiplexing, for exam ple.</t>
<t>Pooled Connections can be useful when the application using the Trans port Services system implements a protocol such as HTTP, which employs request/r esponse pairs and does not require in-order delivery of responses. <t>Pooled Connections can be useful when the application using the Trans port Services system implements a protocol such as HTTP, which employs request/r esponse pairs and does not require in-order delivery of responses.
This enables implementations of Transport Services systems to realize transparen t connection coalescing, connection migration, and to perform per-message endpoi nt and path selection by choosing among multiple underlying connections.</t> This enables implementations of Transport Services systems to realize transparen t connection coalescing and connection migration and to perform per-message endp oint and path selection by choosing among multiple underlying connections.</t>
</section> </section>
<section anchor="handling-path-changes"> <section anchor="handling-path-changes">
<name>Handling Path Changes</name> <name>Handling Path Changes</name>
<t>When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services Implementat ion is responsible for notifying the Protocol Instance of the change. The path c hange may interrupt connectivity on a path for an active Connection or provide a n opportunity for a transport that supports multipath or migration to adapt to t he new paths. Note that, in the model of the Transport Services API, migration i s considered a part of multipath connectivity; it is just a limiting policy on m ultipath usage. If the <tt>multipath</tt> Selection Property is set to <tt>Disab led</tt>, migration is disallowed.</t> <t>When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services Implementat ion is responsible for notifying the Protocol Instance of the change. The path c hange may interrupt connectivity on a path for an active Connection or provide a n opportunity for a transport that supports multipath or migration to adapt to t he new paths. Note that, in the model of the Transport Services API, migration i s considered a part of multipath connectivity; it is just a limiting policy on m ultipath usage. If the <tt>multipath</tt> Selection Property is set to <tt>Disab led</tt>, migration is disallowed.</t>
<t>For protocols that do not support multipath or migration, the Protoco <t>For protocols that do not support multipath or migration, the Protoco
l Instances should be informed of the path change, but should not be forcibly di l Instances should be informed of the path change but should not be forcibly dis
sconnected if the previously used path becomes unavailable. There are many commo connected if the previously used path becomes unavailable. There are many common
n usage scenarios that can lead to a path becoming temporarily unavailable, and usage scenarios that can lead to a path becoming temporarily unavailable and th
then recovering before the transport protocol reaches a timeout error. These are en recovering before the transport protocol reaches a timeout error. These are p
particularly common using mobile devices. Examples include: an Ethernet cable b articularly common using mobile devices. Examples include:</t>
ecoming unplugged and then plugged back in; a device losing a Wi-Fi signal while <ul>
a user is in an elevator, and reattaching when the user leaves the elevator; an <li>an Ethernet cable becoming unplugged and then plugged back in;</li>
d a user losing the radio signal while riding a train through a tunnel. If the d <li>a device losing a Wi-Fi signal while a user is in an elevator and r
evice is able to rejoin a network with the same IP address, a stateful transport eattaching when the user leaves the elevator; and</li>
connection can generally resume. Thus, while it is useful for a Protocol Instan <li>a user losing the radio signal while riding a train through a tunne
ce to be aware of a temporary loss of connectivity, the Transport Services Imple l.</li></ul>
mentation should not aggressively close Connections in these scenarios.</t> <t>If the device is able to rejoin a network with the same IP address,
a stateful transport connection can generally resume. Thus, while it is useful f
or a Protocol Instance to be aware of a temporary loss of connectivity, the Tran
sport Services Implementation should not aggressively close Connections in these
scenarios.</t>
<!-- [rfced] We are having trouble parsing the text following "is
still available or". Please review and let us know how the
text may be clarified.
Original:
A protocol can then establish new subflows over new paths while an
active path is still available or, if migration is supported, also
after a break has been detected, and should attempt to tear down
subflows over paths that are no longer used.
Perhaps (but this leaves out "after a break has been detected"):
A protocol can then establish new subflows over new paths while an
active path is still available, or it should attempt to tear down
subflows over paths that are no longer used if migration is supported.
-->
<t>If the Protocol Stack includes a transport protocol that supports mul tipath connectivity, the Transport Services Implementation should also inform th e Protocol Instance about potentially new paths that become permissible based on the <tt>multipath</tt> Selection Property and the <tt>multipathPolicy</tt> Conn ection Property choices made by the application. <t>If the Protocol Stack includes a transport protocol that supports mul tipath connectivity, the Transport Services Implementation should also inform th e Protocol Instance about potentially new paths that become permissible based on the <tt>multipath</tt> Selection Property and the <tt>multipathPolicy</tt> Conn ection Property choices made by the application.
A protocol can then establish new subflows over new paths while an active path i s still available or, if migration is supported, also after a break has been det ected, and should attempt to tear down subflows over paths that are no longer us ed. The Connection Property <tt>multipathPolicy</tt> of the Transport Services A PI A protocol can then establish new subflows over new paths while an active path i s still available or, if migration is supported, also after a break has been det ected, and should attempt to tear down subflows over paths that are no longer us ed. The Connection Property <tt>multipathPolicy</tt> of the Transport Services A PI
allows an application to indicate when and how different paths should be used. H allows an application to indicate when and how different paths should be used. H
owever, detailed handling of these policies is implementation-specific. owever, detailed handling of these policies is implementation specific.
For example, if the <tt>multipath</tt> Selection Property is set to <tt>active</ For example, if the <tt>multipath</tt> Selection Property is set to <tt>active</
tt>, the decision about when to create a new path or to announce a new path or s tt>, the decision about when to create a new path or to announce a new path or s
et of paths to the Remote Endpoint, e.g., in the form of additional IP addresses et of paths to the Remote Endpoint, e.g., in the form of additional IP addresses
, is implementation-specific. , is implementation specific.
If the Protocol Stack includes a transport protocol that does not support multip If the Protocol Stack includes a transport protocol that does not support multip
ath, but does support migrating between paths, the update to the set of availabl ath but does support migrating between paths, the update to the set of available
e paths can trigger the connection to be migrated.</t> paths can trigger the connection to be migrated.</t>
<t>In the case of a Pooled Connection <xref target="pooled-connections"/ <t>In the case of a Pooled Connection (<xref target="pooled-connections"
>, the Transport Services Implementation may add connections over new paths to t />), the Transport Services Implementation may add connections over new paths to
he pool if permissible based on the multipath policy and Selection Properties. the pool if permissible based on the multipath policy and Selection Properties.
In the case that a previously used path becomes unavailable, the Transport Servi If a previously used path becomes unavailable, the Transport Services system may
ces system may disconnect all connections that require this path, but should not disconnect all connections that require this path, but it should not disconnect
disconnect the pooled Connection object exposed to the application. the pooled Connection object exposed to the application.
The strategy to do so is implementation-specific, but should be consistent with The strategy to do so is implementation specific, but it should be consistent wi
the behavior of multipath transports.</t> th the behavior of multipath transports.</t>
</section> </section>
</section> </section>
<section anchor="implementing-connection-termination"> <section anchor="implementing-connection-termination">
<name>Implementing Connection Termination</name> <name>Implementing Connection Termination</name>
<t>For <tt>Close</tt> (which leads to a <tt>Closed</tt> event) and <tt>Abo rt</tt> (which leads to a <tt>ConnectionError</tt> event), <t>For <tt>Close</tt> (which leads to a <tt>Closed</tt> event) and <tt>Abo rt</tt> (which leads to a <tt>ConnectionError</tt> event),
the application might find it useful to be informed when a peer closes or aborts a the application might find it useful to be informed when a peer closes or aborts a
Connection. Whether this is possible depends on the underlying protocol, and no guarantees Connection. Whether this is possible depends on the underlying protocol, and no guarantees
can be given. When an underlying transport connection supports multi-streaming ( such as SCTP), the Transport Services system can use a stream reset procedure to cause a Finish event upon a <tt>Close</tt> action from the peer <xref target="N EAT-flow-mapping"/>.</t> can be given. When an underlying transport connection supports multi-streaming ( such as SCTP), the Transport Services system can use a stream reset procedure to cause a Finish event upon a <tt>Close</tt> action from the peer <xref target="N EAT-flow-mapping"/>.</t>
</section> </section>
<section anchor="cached-state"> <section anchor="cached-state">
<name>Cached State</name> <name>Cached State</name>
<t>Beyond a single Connection's lifetime, it is useful for an implementati on to keep state and history. This cached <t>Beyond a single Connection's lifetime, it is useful for an implementati on to keep state and history. This cached
state can help improve future Connection establishment due to re-using results a nd credentials, and favoring paths and protocols that performed well in the past .</t> state can help improve future Connection establishment due to reusing results an d credentials and favoring paths and protocols that performed well in the past.< /t>
<t>Cached state may be associated with different endpoints for the same Co nnection, depending on the protocol generating the cached content. <t>Cached state may be associated with different endpoints for the same Co nnection, depending on the protocol generating the cached content.
For example, session tickets for TLS are associated with specific endpoints, and For example, session tickets for TLS are associated with specific endpoints; thu
thus should be cached based on a connection's s, they should be cached based on a connection's
hostname Endpoint Identifer (if applicable). However, performance characteristic hostname Endpoint Identifier (if applicable). However, performance characteristi
s of a path are more likely tied to the IP address cs of a path are more likely tied to the IP address
and subnet being used.</t> and subnet being used.</t>
<section anchor="protocol-state-caches"> <section anchor="protocol-state-caches">
<name>Protocol state caches</name> <name>Protocol State Caches</name>
<t>Some protocols will have long-term state to be cached in association with endpoints. This state often has some time after which <t>Some protocols will have long-term state to be cached in association with endpoints. This state often has some time after which
it is expired, so the implementation should allow each protocol to specify an ex piration for cached content.</t> it is expired, so the implementation should allow each protocol to specify an ex piration for cached content.</t>
<t>Examples of cached protocol state include:</t> <t>Examples of cached protocol state include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The DNS protocol can cache resolved addresses (such as those retr ieved from A and AAAA queries), associated with a Time To Live (TTL) to <t>The DNS protocol can cache resolved addresses (such as those retr ieved from A and AAAA queries) associated with a Time To Live (TTL) to
be used for future hostname resolutions without requiring asking the DNS resolve r again.</t> be used for future hostname resolutions without requiring asking the DNS resolve r again.</t>
</li> </li>
<li> <li>
<t>TLS caches session state and tickets based on a hostname, which c an be used for resuming sessions with a server.</t> <t>TLS caches session state and tickets based on a hostname, which c an be used for resuming sessions with a server.</t>
</li> </li>
<li> <li>
<t>TCP can cache cookies for use in TCP Fast Open.</t> <t>TCP can cache cookies for use in TFO</t>
</li> </li>
</ul> </ul>
<t>Cached protocol state is primarily used during Connection establishme <t>Cached protocol state is primarily used during Connection establishme
nt for a single Protocol Stack, but may be used to influence an nt for a single Protocol Stack, but it may be used to influence an
implementation's preference between several candidate Protocol Stacks. For examp implementation's preference between several candidate Protocol Stacks. For examp
le, if two IP address Endpoint Identifers are otherwise le, if two IP address Endpoint Identifiers are otherwise
equally preferred, an implementation may choose to attempt a connection to an ad equally preferred, an implementation may choose to attempt a connection to an ad
dress for which it has a TCP Fast Open cookie.</t> dress for which it has a TFO cookie.</t>
<t>Applications can use the Transport Services API to request that a Con nection Group maintain a separate cache for <t>Applications can use the Transport Services API to request that a Con nection Group maintain a separate cache for
protocol state. Connections in the group will not use cached state protocol state. Connections in the group will not use cached state
from Connections outside the group, and Connections outside the group will not from Connections outside the group, and Connections outside the group will not
use state cached from Connections inside the group. This may be necessary, for use state cached from Connections inside the group. This may be necessary, for
example, if application-layer identifiers rotate and clients wish to avoid example, if application-layer identifiers rotate and clients wish to avoid
linkability via trackable TLS tickets or TFO cookies.</t> linkability via trackable TLS tickets or TFO cookies.</t>
</section> </section>
<section anchor="performance-caches"> <section anchor="performance-caches">
<name>Performance caches</name> <name>Performance Caches</name>
<t>In addition to protocol state, Protocol Instances should provide data into a performance-oriented cache to help guide future protocol and path select ion. Some performance information can be gathered generically across several pro tocols to allow predictive comparisons between protocols on given paths:</t> <t>In addition to protocol state, Protocol Instances should provide data into a performance-oriented cache to help guide future protocol and path select ion. Some performance information can be gathered generically across several pro tocols to allow predictive comparisons between protocols on given paths:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Observed Round Trip Time</t> <t>Observed RTT</t>
</li> </li>
<li> <li>
<t>Connection establishment latency</t> <t>Connection establishment latency</t>
</li> </li>
<li> <li>
<t>Connection establishment success rate</t> <t>Connection establishment success rate</t>
</li> </li>
</ul> </ul>
<t>These items can be cached on a per-address and per-subnet granularity , and averaged between different values. The information should be cached on a p er-network basis, since it is expected that different network attachments will h ave different performance characteristics. Besides Protocol Instances, other sys tem entities may also provide data into performance-oriented caches. This could for instance be signal strength information reported by radio modems like Wi-Fi and mobile broadband or information about the battery-level of the device. Furth ermore, the system may cache the observed maximum throughput on a path as an est imate of the available bandwidth.</t> <t>These items can be cached on a per-address and per-subnet granularity and averaged between different values. The information should be cached on a pe r-network basis since it is expected that different network attachments will hav e different performance characteristics. Besides Protocol Instances, other syste m entities may also provide data into performance-oriented caches. This could fo r instance be signal strength information reported by radio modems like Wi-Fi an d mobile broadband or information about the battery-level of the device. Further more, the system may cache the observed maximum throughput on a path as an estim ate of the available bandwidth.</t>
<t>An implementation should use this information, when possible, to infl uence preference between candidate paths, endpoints, and protocol options. Eligi ble options that historically had significantly better performance than others s hould be selected first when gathering candidates (see <xref target="gathering"/ >) to ensure better performance for the application.</t> <t>An implementation should use this information, when possible, to infl uence preference between candidate paths, endpoints, and protocol options. Eligi ble options that historically had significantly better performance than others s hould be selected first when gathering candidates (see <xref target="gathering"/ >) to ensure better performance for the application.</t>
<t>The reasonable lifetime for cached performance values will vary depen ding on the nature of the value. Certain information, like the connection establ ishment success rate to a Remote Endpoint using a given Protocol Stack, can be s tored for a long period of time (hours or longer), since it is expected that the capabilities of the Remote Endpoint are not changing very quickly. On the other hand, the Round Trip Time observed by TCP over a particular network path may va ry over a relatively short time interval. For such values, the implementation sh ould remove them from the cache more quickly, or treat older values with less co nfidence/weight.</t> <t>The reasonable lifetime for cached performance values will vary depen ding on the nature of the value. Certain information, like the connection establ ishment success rate to a Remote Endpoint using a given Protocol Stack, can be s tored for a long period of time (hours or longer) since it is expected that the capabilities of the Remote Endpoint are not changing very quickly. On the other hand, the RTT observed by TCP over a particular network path may vary over a rel atively short time interval. For such values, the implementation should remove t hem from the cache more quickly or treat older values with less confidence/weigh t.</t>
<t><xref target="RFC9040"/> provides guidance about sharing of TCP Contr ol Block information between connections on initialization.</t> <t><xref target="RFC9040"/> provides guidance about sharing of TCP Contr ol Block information between connections on initialization.</t>
</section> </section>
</section> </section>
<section anchor="specific-protocol-considerations"> <section anchor="specific-protocol-considerations">
<name>Specific Transport Protocol Considerations</name> <name>Specific Transport Protocol Considerations</name>
<t>Each protocol that is supported by a Transport Services Implementation should have a well-defined API mapping. <t>Each protocol that is supported by a Transport Services Implementation should have a well-defined API mapping.
API mappings for a protocol are important for Connections in which a given proto col is the "top" of the Protocol Stack. API mappings for a protocol are important for Connections in which a given proto col is the "top" of the Protocol Stack.
For example, the mapping of the <tt>Send</tt> function for TCP applies to Connec tions in which the application directly sends over TCP.</t> For example, the mapping of the <tt>Send</tt> function for TCP applies to Connec tions in which the application directly sends over TCP.</t>
<t>Each protocol has a notion of Connectedness. Possible definitions of <t>Each protocol has a notion of "Connectedness". Possible definitions of
Connectedness for various types of protocols are:</t> Connectedness for various types of protocols are:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Connectionless. Connectionless protocols do not establish explicit <dt>Connectionless:</dt><dd>Connectionless protocols do not establish
state between endpoints, and do not perform a handshake during Connection establ explicit state between endpoints and do not perform a handshake during Connectio
ishment.</t> n establishment.</dd>
</li>
<li> <dt>Connected:</dt><dd>Connected (also called "connection-oriented") p
<t>Connected. Connected (also called "connection-oriented") protocols rotocols establish state between endpoints and perform a handshake during connec
establish state between endpoints, and perform a handshake during connection est tion establishment. The handshake may be 0-RTT to send data or resume a session,
ablishment. The handshake may be 0-RTT to send data or resume a session, but bid but bidirectional traffic is required to confirm Connectedness.</dd>
irectional traffic is required to confirm connectedness.</t>
</li> <dt>Multiplexing Connected:</dt><dd>Multiplexing Connected protocols s
<li> hare properties with Connected protocols but also explicitly support opening mul
<t>Multiplexing Connected. Multiplexing Connected protocols share prop tiple application-level flows. This means that they can support cloning new Conn
erties with Connected protocols, but also explictly support opening multiple app ection objects without a new explicit handshake.</dd>
lication-level flows. This means that they can support cloning new Connection ob </dl>
jects without a new explicit handshake.</t>
</li> <t>Protocols also have a notion of "Data Unit". Possible values for Data U
</ul> nit are:</t>
<t>Protocols also have a notion of Data Unit. Possible values for Data Uni <dl spacing="normal">
t are:</t>
<ul spacing="normal"> <dt>Byte-stream:</dt><dd>Byte-stream protocols do not define any messa
<li> ge boundaries of their own apart from the end of a stream in each direction.</dd
<t>Byte-stream. Byte-stream protocols do not define any message bounda >
ries of their own apart from the end of a stream in each direction.</t>
</li> <dt>Datagram:</dt><dd>Datagram protocols define message boundaries at
<li> the same level of transmission, such that only complete (not partial) messages a
<t>Datagram. Datagram protocols define message boundaries at the same re supported.</dd>
level of transmission, such that only complete (not partial) messages are suppor
ted.</t> <dt>Message:</dt><dd>Message protocols support message boundaries that
</li> can be sent and received either as complete or partial messages. Maximum messag
<li> e lengths can be defined, and messages can be partially reliable.</dd>
<t>Message. Message protocols support message boundaries that can be s </dl>
ent and received either as complete or partial messages. Maximum message lengths
can be defined, and messages can be partially reliable.</t> <!-- [rfced] There is no Appendix D in draft-ietf-taps-interface
</li> <https://www.ietf.org/archive/id/draft-ietf-taps-impl-18.html#I-D.ietf-taps
</ul> -interface>.
<t>Below, terms in capitals with a dot (e.g., "CONNECT.SCTP") refer to the We see "callbacks," "fallback," and "backpressure," but we don't
primitives with the same name in <xref section="4" sectionFormat="of" target="R see "backtrack", "back track", or "back-track." Please review
FC8303"/>. For further implementation details, the description of these primitiv and let us know what section is intended.
es in <xref target="RFC8303"/> points to <xref section="3" sectionFormat="of" ta
rget="RFC8303"/> and <xref section="3" sectionFormat="of" target="RFC8304"/>, wh Original:
ich refers back to the relevant specifications for each protocol. This back-trac This back-tracking method applies to all elements of
king method applies to all elements of <xref target="RFC8923"/> (see appendix D [RFC8923] (see appendix D of [I-D.ietf-taps-interface]): they are
of <xref target="I-D.ietf-taps-interface"/>): they are listed in appendix A of < listed in appendix A of [RFC8923] with an implementation hint in the
xref target="RFC8923"/> with an implementation hint in the same style, pointing same style, pointing back to Section 4 of [RFC8303].
back to <xref section="4" sectionFormat="of" target="RFC8303"/>.</t> -->
<t>Below, terms in capitals with a dot character (".") (e.g., "CONNECT.SCT
P") refer to the primitives with the same name in <xref section="4" sectionForma
t="of" target="RFC8303"/>. For further implementation details, the description o
f these primitives in <xref target="RFC8303"/> points to <xref section="3" secti
onFormat="of" target="RFC8303"/> and <xref section="3" sectionFormat="of" target
="RFC8304"/>, which refers back to the relevant specifications for each protocol
. This backtracking method applies to all elements of <xref target="RFC8923"/> (
see <xref target="RFC9622" sectionFormat="of" section="D"/>): they are listed in
<xref target="RFC8923" sectionFormat="of" section="A"/> with an implementation
hint in the same style, pointing back to <xref section="4" sectionFormat="of" ta
rget="RFC8303"/>.</t>
<t>This document presents the protocol mappings defined in <xref target="R FC8923"/>. Other protocol mappings can be provided as separate documents, follow ing the mapping template in <xref target="appendix-mapping-template"/>.</t> <t>This document presents the protocol mappings defined in <xref target="R FC8923"/>. Other protocol mappings can be provided as separate documents, follow ing the mapping template in <xref target="appendix-mapping-template"/>.</t>
<section anchor="tcp"> <section anchor="tcp">
<name>TCP</name> <name>TCP</name>
<t>Connectedness: Connected</t> <dl>
<t>Data Unit: Byte-stream</t>
<dl> <dt>Connectedness:</dt><dd>Connected</dd>
<dt>Data Unit:</dt><dd>Byte-stream</dd>
<dt>Connection Object:</dt> <dt>Connection Object:</dt>
<dd> <dd>
<t>TCP connections between two hosts map directly to Connection obje cts.</t> <t>TCP connections between two hosts map directly to Connection obje cts.</t>
</dd> </dd>
<dt>Initiate:</dt> <dt>Initiate:</dt>
<dd> <dd>
<t>CONNECT.TCP. Calling <tt>Initiate</tt> on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint.</t> <t>CONNECT.TCP. Calling <tt>Initiate</tt> on a TCP Connection causes it to reserve a local port and send a SYN to the Remote Endpoint.</t>
</dd> </dd>
<dt>InitiateWithSend:</dt> <dt>InitiateWithSend:</dt>
<dd> <dd>
<t>CONNECT.TCP with parameter <tt>user message</tt>. Early safely re playable data is sent on a TCP Connection in the SYN, as TCP Fast Open data.</t> <t>CONNECT.TCP with parameter <tt>user message</tt>. Early safely re playable data is sent on a TCP Connection in the SYN, as TFO data.</t>
</dd> </dd>
<dt>Ready:</dt> <dt>Ready:</dt>
<dd> <dd>
<t>A TCP Connection is ready once the three-way handshake is complet e.</t> <t>A TCP Connection is ready once the three-way handshake is complet e.</t>
</dd> </dd>
<dt>EstablishmentError:</dt> <dt>EstablishmentError:</dt>
<dd> <dd>
<t>Failure of CONNECT.TCP. TCP can throw various errors during conne ction setup. Specifically, it is important to handle a RST being sent by the pee r during the handshake.</t> <t>Failure of CONNECT.TCP. TCP can throw various errors during conne ction setup. Specifically, it is important to handle a RST being sent by the pee r during the handshake.</t>
</dd> </dd>
<dt>ConnectionError:</dt> <dt>ConnectionError:</dt>
skipping to change at line 863 skipping to change at line 1257
<dt>Listen:</dt> <dt>Listen:</dt>
<dd> <dd>
<t>LISTEN.TCP. Calling <tt>Listen</tt> for TCP binds a local port an d prepares it to receive inbound SYN packets from peers.</t> <t>LISTEN.TCP. Calling <tt>Listen</tt> for TCP binds a local port an d prepares it to receive inbound SYN packets from peers.</t>
</dd> </dd>
<dt>ConnectionReceived:</dt> <dt>ConnectionReceived:</dt>
<dd> <dd>
<t>TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK.</t> <t>TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK.</t>
</dd> </dd>
<dt>Clone:</dt> <dt>Clone:</dt>
<dd> <dd>
<t>Calling <tt>Clone</tt> on a TCP Connection creates a new Connecti on with equivalent parameters. These Connections, and Connections generated via later calls to <tt>Clone</tt> on an Established Connection, form a Connection Gr oup. To realize entanglement for these Connections, with the exception of <tt>co nnPriority</tt>, changing a Connection Property on one of them must affect the C onnection Properties of the others too. No guarantees of honoring the Connection Property <tt>connPriority</tt> are given, and thus it is safe for an implementa tion of a Transport Services system to ignore this property. When it is reasonab le to assume that Connections traverse the same path (e.g., when they share the same encapsulation), support for it can also experimentally be implemented using a congestion control coupling mechanism (see for example <xref target="TCP-COUP LING"/> or <xref target="RFC3124"/>).</t> <t>Calling <tt>Clone</tt> on a TCP Connection creates a new Connecti on with equivalent parameters. These Connections, and Connections generated via later calls to <tt>Clone</tt> on an Established Connection, form a Connection Gr oup. To realize entanglement for these Connections, with the exception of <tt>co nnPriority</tt>, changing a Connection Property on one of them must affect the C onnection Properties of the others too. No guarantees of honoring the Connection Property <tt>connPriority</tt> are given; thus, it is safe for an implementatio n of a Transport Services system to ignore this property. When it is reasonable to assume that Connections traverse the same path (e.g., when they share the sam e encapsulation), support for it can also experimentally be implemented using a congestion control coupling mechanism (for example, see <xref target="TCP-COUPLI NG"/> or <xref target="RFC3124"/>).</t>
</dd> </dd>
<dt>Send:</dt> <dt>Send:</dt>
<dd> <dd>
<t>SEND.TCP. TCP does not on its own preserve message boundaries. Ca lling <tt>Send</tt> on a TCP connection lays out the bytes on the TCP send strea m without any other delineation. Any Message marked as Final will cause TCP to s end a FIN once the Message has been completely written, by calling CLOSE.TCP imm ediately upon successful termination of SEND.TCP. Note that transmitting a Messa ge marked as Final should not cause the <tt>Closed</tt> event to be delivered to the application, as it will still be possible to receive data until the peer cl oses or aborts the TCP connection.</t> <t>SEND.TCP. On its own, TCP does not preserve message boundaries. C alling <tt>Send</tt> on a TCP connection lays out the bytes on the TCP send stre am without any other delineation. Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written, by calling CLOSE.TCP im mediately upon successful termination of SEND.TCP. Note that transmitting a Mess age marked as Final should not cause the <tt>Closed</tt> event to be delivered t o the application as it will still be possible to receive data until the peer cl oses or aborts the TCP connection.</t>
</dd> </dd>
<dt>Receive:</dt> <dt>Receive:</dt>
<dd> <dd>
<t>With RECEIVE.TCP, TCP delivers a stream of bytes without any Mess age delineation. All data delivered in the <tt>Received</tt> or <tt>ReceivedPart ial</tt> event will be part of a single stream-wide Message that is marked Final (unless a Message Framer is used). EndOfMessage will be delivered when the TCP Connection has received a FIN (CLOSE-EVENT.TCP) from the peer. Note that recepti on of a FIN should not cause the <tt>Closed</tt> event to be delivered to the ap plication, as it will still be possible for the application to send data.</t> <t>With RECEIVE.TCP, TCP delivers a stream of bytes without any Mess age delineation. All data delivered in the <tt>Received</tt> or <tt>ReceivedPart ial</tt> event will be part of a single stream-wide Message that is marked Final (unless a Message Framer is used). EndOfMessage will be delivered when the TCP Connection has received a FIN (CLOSE-EVENT.TCP) from the peer. Note that recepti on of a FIN should not cause the <tt>Closed</tt> event to be delivered to the ap plication, as it will still be possible for the application to send data.</t>
</dd> </dd>
<dt>Close:</dt> <dt>Close:</dt>
<dd> <dd>
<t>Calling <tt>Close</tt> on a TCP Connection indicates that the Con nection should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It will then still be possible to receive data until the peer closes or aborts the TCP connection. The <tt>Closed</tt> event will be issued upon reception of a FI N.</t> <t>Calling <tt>Close</tt> on a TCP Connection indicates that the Con nection should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It will then still be possible to receive data until the peer closes or aborts the TCP connection. The <tt>Closed</tt> event will be issued upon reception of a FI N.</t>
</dd> </dd>
<dt>Abort:</dt> <dt>Abort:</dt>
skipping to change at line 893 skipping to change at line 1287
<t>Calling <tt>CloseGroup</tt> on a TCP Connection (CLOSE.TCP) is id entical to calling <tt>Close</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t> <t>Calling <tt>CloseGroup</tt> on a TCP Connection (CLOSE.TCP) is id entical to calling <tt>Close</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t>
</dd> </dd>
<dt>AbortGroup:</dt> <dt>AbortGroup:</dt>
<dd> <dd>
<t>Calling <tt>AbortGroup</tt> on a TCP Connection (ABORT.TCP) is id entical to calling <tt>Abort</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t> <t>Calling <tt>AbortGroup</tt> on a TCP Connection (ABORT.TCP) is id entical to calling <tt>Abort</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="mptcp"> <section anchor="mptcp">
<name>MPTCP</name> <name>MPTCP</name>
<t>Connectedness: Connected</t> <dl>
<t>Data Unit: Byte-stream</t> <dt>Connectedness:</dt><dd>Connected</dd>
<dt>Data Unit:</dt><dd>Byte-stream</dd>
</dl>
<t>The Transport Services API mappings for MPTCP are identical to TCP. M PTCP adds support for multipath properties, <t>The Transport Services API mappings for MPTCP are identical to TCP. M PTCP adds support for multipath properties,
such as <tt>multipath</tt> and <tt>multipathPolicy</tt>, and actions for managin g paths, such as <tt>AddRemote</tt> and <tt>RemoveRemote</tt>.</t> such as <tt>multipath</tt> and <tt>multipathPolicy</tt>, and actions for managin g paths, such as <tt>AddRemote</tt> and <tt>RemoveRemote</tt>.</t>
</section> </section>
<section anchor="udp"> <section anchor="udp">
<name>UDP</name> <name>UDP</name>
<t>Connectedness: Connectionless</t>
<t>Data Unit: Datagram</t> <dl>
<dl> <dt>Connectedness:</dt><dd>Connectionless</dd>
<dt>Data Unit:</dt><dd>Datagram</dd>
<dt>Connection Object:</dt> <dt>Connection Object:</dt>
<dd> <dd>
<t>UDP Connections represent a pair of specific IP addresses and por ts on two hosts.</t> <t>UDP Connections represent a pair of specific IP addresses and por ts on two hosts.</t>
</dd> </dd>
<dt>Initiate:</dt> <dt>Initiate:</dt>
<dd> <dd>
<t>CONNECT.UDP. Calling <tt>Initiate</tt> on a UDP Connection causes it to reserve a local port, but does not generate any traffic.</t> <t>CONNECT.UDP. Calling <tt>Initiate</tt> on a UDP Connection causes it to reserve a local port but does not generate any traffic.</t>
</dd> </dd>
<dt>InitiateWithSend:</dt> <dt>InitiateWithSend:</dt>
<dd> <dd>
<t>Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is <tt>Ready</tt>.</t> <t>Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is <tt>Ready</tt>.</t>
</dd> </dd>
<dt>Ready:</dt> <dt>Ready:</dt>
<dd> <dd>
<t>A UDP Connection is ready once the system has reserved a local po rt and has a path to send to the Remote Endpoint.</t> <t>A UDP Connection is ready once the system has reserved a local po rt and has a path to send to the Remote Endpoint.</t>
</dd> </dd>
<dt>EstablishmentError:</dt> <dt>EstablishmentError:</dt>
skipping to change at line 941 skipping to change at line 1340
<dt>ConnectionReceived:</dt> <dt>ConnectionReceived:</dt>
<dd> <dd>
<t>UDP Listeners will deliver new connections once they have receive d traffic from a new Remote Endpoint.</t> <t>UDP Listeners will deliver new connections once they have receive d traffic from a new Remote Endpoint.</t>
</dd> </dd>
<dt>Clone:</dt> <dt>Clone:</dt>
<dd> <dd>
<t>Calling <tt>Clone</tt> on a UDP Connection creates a new Connecti on with equivalent parameters. The two Connections are otherwise independent.</t > <t>Calling <tt>Clone</tt> on a UDP Connection creates a new Connecti on with equivalent parameters. The two Connections are otherwise independent.</t >
</dd> </dd>
<dt>Send:</dt> <dt>Send:</dt>
<dd> <dd>
<t>SEND.UDP. Calling <tt>Send</tt> on a UDP connection sends the dat a as the payload of a complete UDP datagram. Marking Messages as Final does not change anything in the datagram's contents. Upon sending a UDP datagram, some re levant fields and flags in the IP header can be controlled: DSCP (SET_DSCP.UDP), DF in IPv4 (SET_DF.UDP) and ECN flag (SET_ECN.UDP).</t> <t>SEND.UDP. Calling <tt>Send</tt> on a UDP connection sends the dat a as the payload of a complete UDP datagram. Marking Messages as Final does not change anything in the datagram's contents. Upon sending a UDP datagram, some re levant fields and flags in the IP header can be controlled: DSCP (SET_DSCP.UDP), DF in IPv4 (SET_DF.UDP), and ECN flag (SET_ECN.UDP).</t>
</dd> </dd>
<dt>Receive:</dt> <dt>Receive:</dt>
<dd> <dd>
<t>RECEIVE.UDP. UDP only delivers complete Messages to <tt>Received< /tt>, each of which represents a single datagram received in a UDP packet. Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_E CN.UDP).</t> <t>RECEIVE.UDP. UDP only delivers complete Messages to <tt>Received< /tt>, each of which represents a single datagram received in a UDP packet. Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_E CN.UDP).</t>
</dd> </dd>
<dt>Close:</dt> <dt>Close:</dt>
<dd> <dd>
<t>Calling <tt>Close</tt> on a UDP Connection (ABORT.UDP) releases t he local port reservation. The Connection then issues a <tt>Closed</tt> event.</ t> <t>Calling <tt>Close</tt> on a UDP Connection (ABORT.UDP) releases t he local port reservation. The Connection then issues a <tt>Closed</tt> event.</ t>
</dd> </dd>
<dt>Abort:</dt> <dt>Abort:</dt>
<dd> <dd>
<t>Calling <tt>Abort</tt> on a UDP Connection (ABORT.UDP) is identic al to calling <tt>Close</tt>, except that the Connection will send a <tt>Connect ionError</tt> event rather than a <tt>Closed</tt> event.</t> <t>Calling <tt>Abort</tt> on a UDP Connection (ABORT.UDP) is identic al to calling <tt>Close</tt> except that the Connection will send a <tt>Connecti onError</tt> event rather than a <tt>Closed</tt> event.</t>
</dd> </dd>
<dt>CloseGroup:</dt> <dt>CloseGroup:</dt>
<dd> <dd>
<t>Calling <tt>CloseGroup</tt> on a UDP Connection (ABORT.UDP) is id entical to calling <tt>Close</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t> <t>Calling <tt>CloseGroup</tt> on a UDP Connection (ABORT.UDP) is id entical to calling <tt>Close</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t>
</dd> </dd>
<dt>AbortGroup:</dt> <dt>AbortGroup:</dt>
<dd> <dd>
<t>Calling <tt>AbortGroup</tt> on a UDP Connection (ABORT.UDP) is id entical to calling <tt>Close</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t> <t>Calling <tt>AbortGroup</tt> on a UDP Connection (ABORT.UDP) is id entical to calling <tt>Close</tt> on this Connection and on all Connections in t he same ConnectionGroup.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="udp-lite"> <section anchor="udp-lite">
<name>UDP-Lite</name> <name>UDP-Lite</name>
<t>Connectedness: Connectionless</t> <dl>
<t>Data Unit: Datagram</t> <dt>Connectedness:</dt><dd>Connectionless</dd>
<dt>Data Unit:</dt><dd>Datagram</dd>
</dl>
<t>The Transport Services API mappings for UDP-Lite are identical to UDP . In addition, <t>The Transport Services API mappings for UDP-Lite are identical to UDP . In addition,
UDP-Lite supports the <tt>msgChecksumLen</tt> and <tt>recvChecksumLen</tt> Prope rties UDP-Lite supports the <tt>msgChecksumLen</tt> and <tt>recvChecksumLen</tt> Prope rties
that allow an application to specify the minimum number of bytes in a Message th at that allow an application to specify the minimum number of bytes in a Message th at
need to be covered by a checksum.</t> need to be covered by a checksum.</t>
<t>This includes: CONNECT.UDP-Lite; LISTEN.UDP-Lite; SEND.UDP-Lite; RECE IVE.UDP-Lite; ABORT.UDP-Lite; ERROR.UDP-Lite; SET_DSCP.UDP-Lite; SET_DF.UDP-Lite ; SET_ECN.UDP-Lite; GET_ECN.UDP-Lite.</t> <t>This includes: CONNECT.UDP-Lite; LISTEN.UDP-Lite; SEND.UDP-Lite; RECE IVE.UDP-Lite; ABORT.UDP-Lite; ERROR.UDP-Lite; SET_DSCP.UDP-Lite; SET_DF.UDP-Lite ; SET_ECN.UDP-Lite; GET_ECN.UDP-Lite.</t>
</section> </section>
<section anchor="udp-multicast-receive"> <section anchor="udp-multicast-receive">
<name>UDP Multicast Receive</name> <name>UDP Multicast Receive</name>
<t>Connectedness: Connectionless</t> <dl>
<t>Data Unit: Datagram</t> <dt>Connectedness:</dt><dd>Connectionless</dd>
<dl> <dt>Data Unit:</dt><dd>Datagram</dd>
<dt>Connection Object:</dt> <dt>Connection Object:</dt>
<dd> <dd>
<t>Established UDP Multicast Receive connections represent a pair of specific IP addresses and ports. The <tt>direction</tt> Selection Property mus t be set to <tt>unidirectional receive</tt>, and the Local Endpoint must be conf igured with a group IP address and a port.</t> <t>Established UDP Multicast Receive connections represent a pair of specific IP addresses and ports. The <tt>direction</tt> Selection Property mus t be set to <tt>unidirectional receive</tt>, and the Local Endpoint must be conf igured with a group IP address and a port.</t>
</dd> </dd>
<dt>Initiate:</dt> <dt>Initiate:</dt>
<dd> <dd>
<t>Calling <tt>Initiate</tt> on a UDP Multicast Receive Connection c auses an immediate <tt>EstablishmentError</tt>. This is an unsupported operatio n.</t> <t>Calling <tt>Initiate</tt> on a UDP Multicast Receive Connection c auses an immediate <tt>EstablishmentError</tt>. This is an unsupported operatio n.</t>
</dd> </dd>
<dt>InitiateWithSend:</dt> <dt>InitiateWithSend:</dt>
<dd> <dd>
skipping to change at line 1006 skipping to change at line 1409
<dt>EstablishmentError:</dt> <dt>EstablishmentError:</dt>
<dd> <dd>
<t>UDP Multicast Receive Connections generate an <tt>EstablishmentEr ror</tt> indicating that joining a multicast group failed if <tt>Initiate</tt> i s called.</t> <t>UDP Multicast Receive Connections generate an <tt>EstablishmentEr ror</tt> indicating that joining a multicast group failed if <tt>Initiate</tt> i s called.</t>
</dd> </dd>
<dt>ConnectionError:</dt> <dt>ConnectionError:</dt>
<dd> <dd>
<t>The only <tt>ConnectionError</tt> generated by a UDP Multicast Re ceive Connection is in response to an <tt>Abort</tt> call.</t> <t>The only <tt>ConnectionError</tt> generated by a UDP Multicast Re ceive Connection is in response to an <tt>Abort</tt> call.</t>
</dd> </dd>
<dt>Listen:</dt> <dt>Listen:</dt>
<dd> <dd>
<t>LISTEN.UDP. Calling <tt>Listen</tt> for UDP Multicast Receive bin ds a local port, prepares it to receive inbound UDP datagrams from peers, and is sues a multicast host join. If a Remote Endpoint Identifer with an address is s upplied, the join is Source-specific Multicast, and the path selection is based on the route to the Remote Endpoint. If a Remote Endpoint Identifer is not supp lied, the join is Any-source Multicast, and the path selection is based on the o utbound route to the group supplied in the Local Endpoint.</t> <t>LISTEN.UDP. Calling <tt>Listen</tt> for UDP Multicast Receive bin ds a local port, prepares it to receive inbound UDP datagrams from peers, and is sues a multicast host join. If a Remote Endpoint Identifier with an address is supplied, the join is Source-Specific Multicast, and the path selection is based on the route to the Remote Endpoint. If a Remote Endpoint Identifier is not su pplied, the join is Any-Source Multicast, and the path selection is based on the outbound route to the group supplied in the Local Endpoint.</t>
</dd> </dd>
</dl> </dl>
<!--[rfced] This text may have gotten garbled along the way (see "for
a multicast group to for a multicast control bus"). Please
rephrase.
Original:
For example, one Connection might be opened for a multicast group to
for a multicast control bus, and another application later opens a
separate Connection to the same group to send signals to and/or
receive signals from the common bus.
-->
<t>There are cases where it is required to open multiple connections for the same address(es). <t>There are cases where it is required to open multiple connections for the same address(es).
For example, one Connection might be opened for a multicast group to for a multi cast control bus, For example, one Connection might be opened for a multicast group to for a multi cast control bus,
and another application later opens a separate Connection to the same group to s end signals to and/or receive signals from the common bus. and another application later opens a separate Connection to the same group to s end signals to and/or receive signals from the common bus.
In such cases, the Transport Services system needs to explicitly enable re-use o In such cases, the Transport Services system needs to explicitly enable reuse of
f the same set of addresses (equivalent to setting SO_REUSEADDR the same set of addresses (equivalent to setting SO_REUSEADDR
in the socket API).</t> in the Socket API).</t>
<dl> <dl>
<dt>ConnectionReceived:</dt> <dt>ConnectionReceived:</dt>
<dd> <dd>
<t>UDP Multicast Receive Listeners will deliver new Connections once they have received traffic from a new Remote Endpoint.</t> <t>UDP Multicast Receive Listeners will deliver new Connections once they have received traffic from a new Remote Endpoint.</t>
</dd> </dd>
<dt>Clone:</dt> <dt>Clone:</dt>
<dd> <dd>
<t>Calling <tt>Clone</tt> on a UDP Multicast Receive Connection crea tes a new Connection with equivalent parameters. The two Connections are otherwi se independent.</t> <t>Calling <tt>Clone</tt> on a UDP Multicast Receive Connection crea tes a new Connection with equivalent parameters. The two Connections are otherwi se independent.</t>
</dd> </dd>
<dt>Send:</dt> <dt>Send:</dt>
skipping to change at line 1037 skipping to change at line 1451
<dt>Receive:</dt> <dt>Receive:</dt>
<dd> <dd>
<t>RECEIVE.UDP. The <tt>Receive</tt> operation in a UDP Multicast Re ceive connection only delivers complete Messages to <tt>Received</tt>, each of w hich represents a single datagram received in a UDP packet. Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_ECN.UDP).</t> <t>RECEIVE.UDP. The <tt>Receive</tt> operation in a UDP Multicast Re ceive connection only delivers complete Messages to <tt>Received</tt>, each of w hich represents a single datagram received in a UDP packet. Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_ECN.UDP).</t>
</dd> </dd>
<dt>Close:</dt> <dt>Close:</dt>
<dd> <dd>
<t>Calling <tt>Close</tt> on a UDP Multicast Receive Connection (ABO RT.UDP) releases the local port reservation and leaves the group. The Connection then issues a <tt>Closed</tt> event.</t> <t>Calling <tt>Close</tt> on a UDP Multicast Receive Connection (ABO RT.UDP) releases the local port reservation and leaves the group. The Connection then issues a <tt>Closed</tt> event.</t>
</dd> </dd>
<dt>Abort:</dt> <dt>Abort:</dt>
<dd> <dd>
<t>Calling <tt>Abort</tt> on a UDP Multicast Receive Connection (ABO RT.UDP) is identical to calling <tt>Close</tt>, except that the Connection will send a <tt>ConnectionError</tt> event rather than a <tt>Closed</tt> event.</t> <t>Calling <tt>Abort</tt> on a UDP Multicast Receive Connection (ABO RT.UDP) is identical to calling <tt>Close</tt> except that the Connection will s end a <tt>ConnectionError</tt> event rather than a <tt>Closed</tt> event.</t>
</dd> </dd>
<dt>CloseGroup:</dt> <dt>CloseGroup:</dt>
<dd> <dd>
<t>Calling <tt>CloseGroup</tt> on a UDP Multicast Receive Connection (ABORT.UDP) is identical to calling <tt>Close</tt> on this Connection and on al l Connections in the same ConnectionGroup.</t> <t>Calling <tt>CloseGroup</tt> on a UDP Multicast Receive Connection (ABORT.UDP) is identical to calling <tt>Close</tt> on this Connection and on al l Connections in the same ConnectionGroup.</t>
</dd> </dd>
<dt>AbortGroup:</dt> <dt>AbortGroup:</dt>
<dd> <dd>
<t>Calling <tt>AbortGroup</tt> on a UDP Multicast Receive Connection (ABORT.UDP) is identical to calling <tt>Close</tt> <t>Calling <tt>AbortGroup</tt> on a UDP Multicast Receive Connection (ABORT.UDP) is identical to calling <tt>Close</tt>
on this Connection and on all Connections in the same ConnectionGroup.</t> on this Connection and on all Connections in the same ConnectionGroup.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sctp"> <section anchor="sctp">
<name>SCTP</name> <name>SCTP</name>
<t>Connectedness: Connected</t> <dl>
<t>Data Unit: Message</t> <dt>Connectedness:</dt><dd>Connected</dd>
<dl> <dt>Data Unit:</dt><dd>Message</dd>
<dt>Connection Object:</dt> <dt>Connection Object:</dt>
<dd> <dd>
<!-- [rfced] Section 10.6: We find "requirements as follows" and the
"following explanation" in the subsequent sentence confusing -
what directly follows the paragraph? Does the "requirements as
follows" refer to following paragraph that starts with "Stream
mapping requires..."? If yes, should this text (all of the text
until "Initiate:") be indented under "Connection Object"?
Original:
Connection Object: Connection objects can be mapped to an SCTP
association or a stream in an SCTP association. Mapping
Connection objects to SCTP streams is called "stream mapping" and
has additional requirements as follows. The following explanation
assumes a client-server communication model.
Stream mapping requires ...
-->
<t>Connection objects can be mapped to an SCTP association or a stre am in an SCTP association. Mapping Connection objects to SCTP streams is called "stream mapping" and has additional requirements as follows. The following expla nation assumes a client-server communication model.</t> <t>Connection objects can be mapped to an SCTP association or a stre am in an SCTP association. Mapping Connection objects to SCTP streams is called "stream mapping" and has additional requirements as follows. The following expla nation assumes a client-server communication model.</t>
</dd> </dd>
</dl> </dl>
<t>Stream mapping requires an association to already be in place between
the client and the server, and it requires the server to understand that a new <!-- [rfced] Please confirm that "stream id" (lowercase "id") is
incoming stream should be represented as a new Connection object by the Transpor correct, as we see the following (using "stream IDs") in
t Services system. A new SCTP stream is created by sending an SCTP message with draft-ietf-taps-interface (RFC-to-be 9622):
a new stream id. Thus, to implement stream mapping, the Transport Services API m
ust provide a newly created Connection object to the application upon the recept The optional connectionProperties parameter allows passing Transport
ion of such a message. The necessary semantics to implement a Transport Services Properties that control the behavior of the underlying stream or
system's <tt>Close</tt> and <tt>Abort</tt> primitives are provided by the strea connection to be created, e.g., Protocol-specific Properties to
m reconfiguration (reset) procedure described in <xref target="RFC6525"/>. This request specific stream IDs for SCTP or QUIC.
also allows to re-use a stream id after resetting ("closing") the stream. To imp -->
lement this functionality, SCTP stream reconfiguration <xref target="RFC6525"/>
must be supported by both the client and the server side.</t> <t>Stream mapping requires an association to already be in place between the cli
ent and the server, and it requires the server to understand that a new incoming
stream should be represented as a new Connection object by the Transport Servic
es system. A new SCTP stream is created by sending an SCTP message with a new st
ream id. Thus, to implement stream mapping, the Transport Services API must prov
ide a newly created Connection object to the application upon the reception of s
uch a message. The necessary semantics to implement a Transport Services system'
s <tt>Close</tt> and <tt>Abort</tt> primitives are provided by the stream reconf
iguration (reset) procedure described in <xref target="RFC6525"/>. This also all
ows a stream id to be reused after resetting ("closing") the stream. To implemen
t this functionality, SCTP stream reconfiguration <xref target="RFC6525"/> must
be supported by both the client and the server side.</t>
<!-- [rfced] We wonder if "might block" should be "will block" because
"without risking" implies that blocking should not happen? Or is
the intent to say the risk of blocking is reduced?
Original:
This allows a sender to schedule transmissions between multiple
streams without risking that transmission of a large message on one
stream might block transmissions on other streams for a long time.
-->
<t>To avoid head-of-line blocking, stream mapping should only be impleme nted when both sides support message interleaving <xref target="RFC8260"/>. This allows a sender to schedule transmissions between multiple streams without risk ing that transmission of a large message on one stream might block transmissions on other streams for a long time.</t> <t>To avoid head-of-line blocking, stream mapping should only be impleme nted when both sides support message interleaving <xref target="RFC8260"/>. This allows a sender to schedule transmissions between multiple streams without risk ing that transmission of a large message on one stream might block transmissions on other streams for a long time.</t>
<t>To avoid conflicts between stream ids, the following procedure is rec
ommended: the first Connection, for which the SCTP association has been created, <!-- [rfced] Does "growing order" mean "ascending order"?
must always use stream id zero. All additional Connections are assigned to unus
ed stream ids in growing order. To avoid a conflict when both endpoints map new Original:
Connections simultaneously, the peer which initiated association must use even s All additional
tream ids whereas the remote side must map its Connections to odd stream ids. Bo Connections are assigned to unused stream ids in growing order.
th sides maintain a status map of the assigned stream ids. Generally, new stream -->
s should consume the lowest available (even or odd, depending on the side) strea <t>To avoid conflicts between stream ids, the following procedure is rec
m id; this rule is relevant when lower ids become available because Connection o ommended: the first Connection, for which the SCTP association has been created,
bjects associated with the streams are closed.</t> must always use stream id zero. All additional Connections are assigned to unus
<t>SCTP stream mapping as described here has been implemented in a resea ed stream ids in growing order. To avoid a conflict when both endpoints map new
rch prototype; a desription of this implementation is given in <xref target="NEA Connections simultaneously, the peer that initiated association must use even st
T-flow-mapping"/>.</t> ream ids whereas the remote side must map its Connections to odd stream ids. Bot
h sides maintain a status map of the assigned stream ids. Generally, new streams
should consume the lowest available (even or odd, depending on the side) stream
id; this rule is relevant when lower ids become available because Connection ob
jects associated with the streams are closed.</t>
<t>SCTP stream mapping as described here has been implemented in a resea
rch prototype; a description of this implementation is given in <xref target="NE
AT-flow-mapping"/>.</t>
<dl> <dl>
<dt>Initiate:</dt> <dt>Initiate:</dt>
<dd> <dd>
<t>If this is the only Connection object that is assigned to the SCT P Association or stream mapping is <t>If this is the only Connection object that is assigned to the SCT P Association or stream mapping is
not used, CONNECT.SCTP is called. Else, unless the Selection Property <tt>active ReadBeforeSend</tt> not used, CONNECT.SCTP is called. Else, unless the Selection Property <tt>active ReadBeforeSend</tt>
is Preferred or Required, a new stream is used: if there are enough streams is Preferred or Required, a new stream is used: if there are enough streams
available, <tt>Initiate</tt> is a local operation that assigns a new stream id t o the Connection object. available, <tt>Initiate</tt> is a local operation that assigns a new stream id t o the Connection object.
The number of streams is negotiated as a parameter of the prior CONNECT.SCTP cal l, and it represents a The number of streams is negotiated as a parameter of the prior CONNECT.SCTP cal l, and it represents a
trade-off between local resource usage and the number of Connection objects that can be mapped trade-off between local resource usage and the number of Connection objects that can be mapped
without requiring a reconfiguration signal. When running out of streams, ADD_STR EAM.SCTP must be called.</t> without requiring a reconfiguration signal. When running out of streams, ADD_STR EAM.SCTP must be called.</t>
</dd> </dd>
<dt>InitiateWithSend:</dt> <dt>InitiateWithSend:</dt>
<dd> <dd>
<t>If this is the only Connection object that is assigned to the SCT P association or stream mapping is not used, CONNECT.SCTP is called with the "us er message" parameter. Else, a new stream <t>If this is the only Connection object that is assigned to the SCT P association or stream mapping is not used, CONNECT.SCTP is called with the "us er message" parameter. Else, a new stream
is used (see <tt>Initiate</tt> for how to handle running out of streams), and th is just sends the first message is used (see <tt>Initiate</tt> for how to handle running out of streams), and th is just sends the first message
on a new stream.</t> on a new stream.</t>
</dd> </dd>
<dt>Ready:</dt> <dt>Ready:</dt>
<dd> <dd>
<t><tt>Initiate</tt> or <tt>InitiateWithSend</tt> returns without an error, i.e. SCTP's four-way handshake has completed. If an association with the peer already exists, stream mapping is used and enough streams are available, a Connection object instantly becomes <tt>Ready</tt> after calling <tt>Initiate</ tt> or <tt>InitiateWithSend</tt>.</t> <t><tt>Initiate</tt> or <tt>InitiateWithSend</tt> returns without an error, i.e., SCTP's four-way handshake has completed. If an association with th e peer already exists, stream mapping is used, and enough streams are available, a Connection object instantly becomes <tt>Ready</tt> after calling <tt>Initiate </tt> or <tt>InitiateWithSend</tt>.</t>
</dd> </dd>
<dt>EstablishmentError:</dt> <dt>EstablishmentError:</dt>
<dd> <dd>
<t>Failure of CONNECT.SCTP.</t> <t>Failure of CONNECT.SCTP.</t>
</dd> </dd>
<dt>ConnectionError:</dt> <dt>ConnectionError:</dt>
<dd> <dd>
<t>TIMEOUT.SCTP or ABORT-EVENT.SCTP.</t> <t>TIMEOUT.SCTP or ABORT-EVENT.SCTP.</t>
</dd> </dd>
<dt>Listen:</dt> <dt>Listen:</dt>
<dd> <dd>
<t>LISTEN.SCTP. If an association with the peer already exists and s tream mapping is used, <tt>Listen</tt> just expects to receive a new message wit h a new stream id (chosen in accordance with the stream id assignment procedure described above).</t> <t>LISTEN.SCTP. If an association with the peer already exists and s tream mapping is used, <tt>Listen</tt> just expects to receive a new message wit h a new stream id (chosen in accordance with the stream id assignment procedure described above).</t>
</dd> </dd>
<dt>ConnectionReceived:</dt> <dt>ConnectionReceived:</dt>
<dd> <dd>
<t>LISTEN.SCTP returns without an error (a result of successful CONN ECT.SCTP from the peer), or, in case of stream mapping, the first message has ar rived on a new stream (in this case, <tt>Receive</tt> is also invoked).</t> <t>LISTEN.SCTP returns without an error (a result of successful CONN ECT.SCTP from the peer) or, in the case of stream mapping, the first message has arrived on a new stream (in this case, <tt>Receive</tt> is also invoked).</t>
</dd> </dd>
<dt>Clone:</dt> <dt>Clone:</dt>
<dd> <dd>
<t>Calling <tt>Clone</tt> on an SCTP association creates a new Conne ction object and assigns it a new stream id in accordance with the stream id ass ignment procedure described above. If there are not enough streams available, AD D_STREAM.SCTP must be called.</t> <t>Calling <tt>Clone</tt> on an SCTP association creates a new Conne ction object and assigns it a new stream id in accordance with the stream id ass ignment procedure described above. If there are not enough streams available, AD D_STREAM.SCTP must be called.</t>
</dd> </dd>
<dt>Send:</dt> <dt>Send:</dt>
<dd> <dd>
<t>SEND.SCTP. Message Properties such as <tt>msgLifetime</tt> and <t t>msgOrdered</tt> map to parameters of this primitive.</t> <t>SEND.SCTP. Message Properties such as <tt>msgLifetime</tt> and <t t>msgOrdered</tt> map to parameters of this primitive.</t>
</dd> </dd>
<dt>Receive:</dt> <dt>Receive:</dt>
<dd> <dd>
<t>RECEIVE.SCTP. The "partial flag" of RECEIVE.SCTP invokes a <tt>Re ceivedPartial</tt> event.</t> <t>RECEIVE.SCTP. The "partial flag" of RECEIVE.SCTP invokes a <tt>Re ceivedPartial</tt> event.</t>
</dd> </dd>
</dl>
<t>Close: <dt>Close:</dt>
If this is the only Connection object that is assigned to the SCTP association,
CLOSE.SCTP is called, and the <tt>Closed</tt> event will be delivered to the app <!-- [rfced] Will "fire" be clear for readers? Perhaps "be initiated"
lication upon the ensuing CLOSE-EVENT.SCTP. Else, the Connection object is one o or "be triggered" would be more accurate?
ut of several Connection objects that are assigned to the same SCTP assocation,
and RESET_STREAM.SCTP must be called, which informs the peer that the stream wil Original:
l no longer be used for mapping and can be used by future <tt>Initiate</tt>, <tt At the peer, the event
>InitiateWithSend</tt> or <tt>Listen</tt> calls. At the peer, the event RESET_ST RESET_STREAM-EVENT.SCTP will fire, which the peer must answer by
REAM-EVENT.SCTP will fire, which the peer must answer by issuing RESET_STREAM.SC issuing RESET_STREAM.SCTP too.
TP too. The resulting local RESET_STREAM-EVENT.SCTP informs the Transport Servic
es system that the stream id can now be re-used by the next <tt>Initiate</tt>, < Perhaps:
tt>InitiateWithSend</tt> or <tt>Listen</tt> calls, and invokes a <tt>Closed</tt> At the peer, the event
event towards the application.</t> RESET_STREAM-EVENT.SCTP will be triggered, and the peer must respond by
<t>Abort: also issuing a RESET_STREAM.SCTP.
If this is the only Connection object that is assigned to the SCTP association, -->
ABORT.SCTP is called. Else, the Connection object is one out of several Connecti
on objects that are assigned to the same SCTP assocation, and shutdown proceeds <dd>If this is the only Connection object that is assigned to the SCTP associati
as described under <tt>Close</tt>.</t> on, CLOSE.SCTP is called and the <tt>Closed</tt> event will be delivered to the
<t>CloseGroup: application upon the ensuing CLOSE-EVENT.SCTP. Else, the Connection object is on
Calling <tt>CloseGroup</tt> calls CLOSE.SCTP, closing all Connections in the SCT e out of several Connection objects that are assigned to the same SCTP associati
P association.</t> on, and RESET_STREAM.SCTP must be called, which informs the peer that the stream
<t>AbortGroup: will no longer be used for mapping and can be used by future <tt>Initiate</tt>,
Calling <tt>AbortGroup</tt> calls ABORT.SCTP, immediately closing all Connection <tt>InitiateWithSend</tt>, or <tt>Listen</tt> calls. At the peer, the event RES
s in the SCTP association.</t> ET_STREAM-EVENT.SCTP will fire, which the peer must answer by issuing RESET_STRE
AM.SCTP too. The resulting local RESET_STREAM-EVENT.SCTP informs the Transport S
ervices system that the stream id can now be reused by the next <tt>Initiate</tt
>, <tt>InitiateWithSend</tt>, or <tt>Listen</tt> calls, and invokes a <tt>Closed
</tt> event toward the application.</dd>
<dt>Abort:</dt>
<dd>If this is the only Connection object that is assigned to the SCTP associati
on, ABORT.SCTP is called. Else, the Connection object is one out of several Conn
ection objects that are assigned to the same SCTP association, and shutdown proc
eeds as described under <tt>Close</tt>.</dd>
<dt>CloseGroup:</dt>
<dd>Calling <tt>CloseGroup</tt> calls CLOSE.SCTP, which closes all Connections i
n the SCTP association.</dd>
<dt>AbortGroup:</dt>
<dd>Calling <tt>AbortGroup</tt> calls ABORT.SCTP, which immediately closes all C
onnections in the SCTP association.</dd>
</dl>
<t>In addition to the API mappings described above, when there are multi ple Connection objects assigned to the same SCTP association, SCTP can support C onnection properties such as <tt>connPriority</tt> and <tt>connScheduler</tt> wh ere CONFIGURE_STREAM_SCHEDULER.SCTP can be called to adjust the priorities of st reams in the SCTP association.</t> <t>In addition to the API mappings described above, when there are multi ple Connection objects assigned to the same SCTP association, SCTP can support C onnection properties such as <tt>connPriority</tt> and <tt>connScheduler</tt> wh ere CONFIGURE_STREAM_SCHEDULER.SCTP can be called to adjust the priorities of st reams in the SCTP association.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no actions for IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t><xref target="I-D.ietf-taps-arch"/> outlines general security considera tion and requirements for any system that implements the Transport Services arch tecture. <xref target="I-D.ietf-taps-interface"/> provides further discussion on security and privacy implications of the Transport Services API. This document provides additional guidance on implementation specifics for the Transport Servi ces API and as such the security considerations in both of these documents apply . The next two subsections discuss further considerations that are specific to m echanisms specified in this document.</t> <t><xref target="RFC9621"/> outlines general security considerations and r equirements for any system that implements the Transport Services architecture. <xref target="RFC9622"/> provides further discussion on security and privacy imp lications of the Transport Services API. This document provides additional guida nce on implementation specifics for the Transport Services API; as such, the sec urity considerations in both of these documents apply. The next two subsections discuss further considerations that are specific to mechanisms specified in this document.</t>
<section anchor="considerations-for-candidate-gathering"> <section anchor="considerations-for-candidate-gathering">
<name>Considerations for Candidate Gathering</name> <name>Considerations for Candidate Gathering</name>
<t>The Security Considerations of the Transport Services Architecture <x
ref target="I-D.ietf-taps-arch"/> forbids gathering and racing with Protocol Sta <!-- [rfced] For readability, may we update the sentence as follows?
cks that do not have equivalent security properties. Therefore, implementations It is difficult to locate the information in RFC 9621 otherwise.
need to avoid downgrade attacks that allow network interference to cause the imp
lementation to select less secure, or entirely insecure, combinations of paths a Original:
nd protocols.</t> The Security Considerations of the Transport Services Architecture
[I-D.ietf-taps-arch] forbids gathering and racing with Protocol
Stacks that do not have equivalent security properties.
Perhaps:
As discussed in Sections 3.3 and 6 of [RFC9621], gathering
and racing with Protocol Stacks that do not have equivalent security
properties are forbidden.
-->
<t>The Security Considerations of the Transport Services architecture <x
ref target="RFC9621"/> forbids gathering and racing with Protocol Stacks that do
not have equivalent security properties. Therefore, implementations need to avo
id downgrade attacks that allow network interference to cause the implementation
to select less secure, or entirely insecure, combinations of paths and protocol
s.</t>
</section> </section>
<section anchor="considerations-for-candidate-racing"> <section anchor="considerations-for-candidate-racing">
<name>Considerations for Candidate Racing</name> <name>Considerations for Candidate Racing</name>
<t>See <xref target="fastopen"/> for security considerations around raci ng with 0-RTT data.</t> <t>See <xref target="fastopen"/> for security considerations around raci ng with 0-RTT data.</t>
<t>An attacker that knows a particular device is racing several options during connection establishment may be able to block packets for the first conne ction attempt, thus inducing the device to fall back to a secondary attempt. Thi s is a problem if the secondary attempts have worse security properties that ena ble further attacks. Implementations should ensure that all options have equival ent security properties to avoid incentivizing attacks.</t> <t>An attacker that knows a particular device is racing several options during connection establishment may be able to block packets for the first conne ction attempt, thus inducing the device to fall back to a secondary attempt. Thi s is a problem if the secondary attempts have worse security properties that ena ble further attacks. Implementations should ensure that all options have equival ent security properties to avoid incentivizing attacks.</t>
<t>Since results from the network can determine how a connection attempt tree is built, such as when DNS returns a list of resolved endpoints, it is pos sible for the network to cause an implementation to consume significant on-devic e resources. Implementations should limit the maximum amount of state allowed fo r any given node, including the number of child nodes, especially when the state is based on results from the network.</t> <t>Since results from the network can determine how a connection attempt tree is built, such as when DNS returns a list of resolved endpoints, it is pos sible for the network to cause an implementation to consume significant on-devic e resources. Implementations should limit the maximum amount of state allowed fo r any given node, including the number of child nodes, especially when the state is based on results from the network.</t>
</section> </section>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>This work has received funding from the European Union's Horizon 2020 r
esearch and
innovation programme under grant agreement No. 644334 (NEAT) and No. 815178 (5GE
NESIS).</t>
<t>This work has been supported by Leibniz Prize project funds of DFG - Ge
rman
Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</t>
<t>This work has been supported by the UK Engineering and Physical Science
s
Research Council under grant EP/R04144X/1.</t>
<t>This work has been supported by the Research Council of Norway under it
s "Toppforsk"
programme through the "OCARINA" project.</t>
<t>Thanks to Colin Perkins, Tom Jones, Karl-Johan Grinnemo, Gorry Fairhurs
t, for their contributions to the design of this specification.
Thanks also to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear
for their implementation and design efforts, including Happy Eyeballs, that hea
vily influenced this work.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="I-D.ietf-taps-arch">
<front>
<title>Architecture and Requirements for Transport Services</title>
<author fullname="Tommy Pauly" initials="T." surname="Pauly">
<organization>Apple Inc.</organization>
</author>
<author fullname="Brian Trammell" initials="B." surname="Trammell">
<organization>Google Switzerland GmbH</organization>
</author>
<author fullname="Anna Brunstrom" initials="A." surname="Brunstrom">
<organization>Karlstad University</organization>
</author>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"
>
<organization>University of Aberdeen</organization>
</author>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>University of Glasgow</organization>
</author>
<date day="9" month="November" year="2023"/>
<abstract>
<t> This document describes an architecture for exposing transpo
rt
protocol features to applications for network communication. This
system exposes transport protocol features to applications for
network communication. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. This API uses messages for representing data
transfer to applications, and describes how a Transport Services
Implementation can use multiple IP addresses, multiple protocols, and
multiple paths, and provide multiple application streams. This
document provides the architecture and requirements. It defines
common terminology and concepts to be used in definitions of a
Transport Service API and a Transport Services Implementation.
</t> <!-- [I-D.ietf-taps-arch] companion RFC 9621 -->
</abstract> <reference anchor="RFC9621" target="https://www.rfc-editor.org/info/rfc
</front> 9621">
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-19"/> <front>
</reference> <title>Architecture and Requirements for Transport Services </title>
<reference anchor="I-D.ietf-taps-interface"> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="ed
<front> itor">
<title>An Abstract Application Layer Interface to Transport Services <organization>Apple Inc.</organization>
</title> </author>
<author fullname="Brian Trammell" initials="B." surname="Trammell"> <author initials="B." surname="Trammell" fullname="Brian Trammell" ro
<organization>Google Switzerland GmbH</organization> le="editor">
</author> <organization>Google Switzerland GmbH</organization>
<author fullname="Michael Welzl" initials="M." surname="Welzl"> </author>
<organization>University of Oslo</organization> <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
</author> <organization>Karlstad University</organization>
<author fullname="Reese Enghardt" initials="R." surname="Enghardt"> </author>
<organization>Netflix</organization> <author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
</author> <organization>University of Aberdeen</organization>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst" </author>
> <author initials="C. S." surname="Perkins" fullname="Colin S. Perkins
<organization>University of Aberdeen</organization> ">
</author> <organization>University of Glasgow</organization>
<author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind" </author>
> <date month="November" year="2024"/>
<organization>Ericsson</organization> </front>
</author> <seriesInfo name="RFC" value="9621"/>
<author fullname="Colin Perkins" initials="C." surname="Perkins"> <seriesInfo name="DOI" value="10.17487/RFC9621"/>
<organization>University of Glasgow</organization> </reference>
</author>
<author fullname="Philipp S. Tiesel" initials="P. S." surname="Tiese <!-- [I-D.ietf-taps-interface] companion document RFC 9622 -->
l"> <reference anchor="RFC9622" target="https://www.rfc-editor.org/info/rfc9
<organization>SAP SE</organization> 622">
</author> <front>
<author fullname="Tommy Pauly" initials="T." surname="Pauly"> <title>The Transport Services Application Programming Interface</titl
<organization>Apple Inc.</organization> e>
</author> <author initials="B." surname="Trammell" fullname="Brian Trammell" ro
<date day="14" month="November" year="2023"/> le="editor">
<abstract> <organization>Google Switzerland GmbH</organization>
<t> This document describes an abstract application programming </author>
interface, API, to the transport layer that enables the selection of <author initials="M." surname="Welzl" fullname="Michael Welzl" role="
transport protocols and network paths dynamically at runtime. This editor">
API enables faster deployment of new protocols and protocol features <organization>University of Oslo</organization>
without requiring changes to the applications. The specified API </author>
follows the Transport Services architecture by providing <author initials="R." surname="Enghardt" fullname="Reese Enghardt">
asynchronous, atomic transmission of messages. It is intended to <organization>Netflix</organization>
replace the BSD sockets API as the common interface to the transport </author>
layer, in an environment where endpoints could select from multiple <author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
network paths and potential transport protocols. <organization>University of Aberdeen</organization>
</author>
<author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind">
<organization>Ericsson</organization>
</author>
<author initials="C. S." surname="Perkins" fullname="Colin S. Perkins
">
<organization>University of Glasgow</organization>
</author>
<author initials="P. S." surname="Tiesel" fullname="Philipp S. Tiesel
">
<organization>SAP SE</organization>
</author>
<author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization>
</author>
<date month="November" year="2024"/>
</front>
<seriesInfo name="RFC" value="9622"/>
<seriesInfo name="DOI" value="10.17487/RFC9622"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
05.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
40.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
21.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
03.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
04.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
13.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
23.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-23"
/>
</reference>
<reference anchor="RFC8305">
<front>
<title>Happy Eyeballs Version 2: Better Connectivity Using Concurren
cy</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<date month="December" year="2017"/>
<abstract>
<t>Many communication protocols operating over the modern Internet
use hostnames. These often resolve to multiple IP addresses, each of which may
have different performance and connectivity characteristics. Since specific addr
esses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal
on a network, clients that attempt multiple connections in parallel have a chanc
e of establishing a connection more quickly. This document specifies requirement
s for algorithms that reduce this user-visible delay and provides an example alg
orithm, referred to as "Happy Eyeballs". This document obsoletes the original al
gorithm description in RFC 6555.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8305"/>
<seriesInfo name="DOI" value="10.17487/RFC8305"/>
</reference>
<reference anchor="RFC7540">
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author fullname="M. Belshe" initials="M." surname="Belshe"/>
<author fullname="R. Peon" initials="R." surname="Peon"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2015"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced
perception of latency by introducing header field compression and allowing mult
iple concurrent exchanges on the same connection. It also introduces unsolicited
push of representations from servers to clients.</t>
<t>This specification is an alternative to, but does not obsolete,
the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7540"/>
<seriesInfo name="DOI" value="10.17487/RFC7540"/>
</reference>
<reference anchor="RFC8421">
<front>
<title>Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactiv
e Connectivity Establishment (ICE)</title>
<author fullname="P. Martinsen" initials="P." surname="Martinsen"/>
<author fullname="T. Reddy" initials="T." surname="Reddy"/>
<author fullname="P. Patil" initials="P." surname="Patil"/>
<date month="July" year="2018"/>
<abstract>
<t>This document provides guidelines on how to make Interactive Co
nnectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-
stack scenarios where broken paths exist. The provided guidelines are backward c
ompatible with the original ICE specification (see RFC 5245).</t>
</abstract>
</front>
<seriesInfo name="BCP" value="217"/>
<seriesInfo name="RFC" value="8421"/>
<seriesInfo name="DOI" value="10.17487/RFC8421"/>
</reference>
<reference anchor="RFC8303">
<front>
<title>On the Usage of Transport Features Provided by IETF Transport
Protocols</title>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<author fullname="M. Tuexen" initials="M." surname="Tuexen"/>
<author fullname="N. Khademi" initials="N." surname="Khademi"/>
<date month="February" year="2018"/>
<abstract>
<t>This document describes how the transport protocols Transmissio
n Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Pro
tocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protoc
ol (UDP-Lite) expose services to applications and how an application can configu
re and use the features that make up these services. It also discusses the servi
ce provided by the Low Extra Delay Background Transport (LEDBAT) congestion cont
rol mechanism. The description results in a set of transport abstractions that c
an be exported in a transport services (TAPS) API.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8303"/>
<seriesInfo name="DOI" value="10.17487/RFC8303"/>
</reference>
<reference anchor="RFC8304">
<front>
<title>Transport Features of the User Datagram Protocol (UDP) and Li
ghtweight UDP (UDP-Lite)</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="T. Jones" initials="T." surname="Jones"/>
<date month="February" year="2018"/>
<abstract>
<t>This is an informational document that describes the transport
protocol interface primitives provided by the User Datagram Protocol (UDP) and t
he Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identif
ies the datagram services exposed to applications and how an application can con
figure and use the features offered by the Internet datagram transport service.
RFC 8303 documents the usage of transport features provided by IETF transport pr
otocols, describing the way UDP, UDP-Lite, and other transport protocols expose
their services to applications and how an application can configure and use the
features that make up these services. This document provides input to and contex
t for that document, as well as offers a road map to documentation that may help
users of the UDP and UDP-Lite protocols.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8304"/>
<seriesInfo name="DOI" value="10.17487/RFC8304"/>
</reference>
<reference anchor="RFC7413">
<front>
<title>TCP Fast Open</title>
<author fullname="Y. Cheng" initials="Y." surname="Cheng"/>
<author fullname="J. Chu" initials="J." surname="Chu"/>
<author fullname="S. Radhakrishnan" initials="S." surname="Radhakris
hnan"/>
<author fullname="A. Jain" initials="A." surname="Jain"/>
<date month="December" year="2014"/>
<abstract>
<t>This document describes an experimental TCP mechanism called TC
P Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
and consumed by the receiving end during the initial connection handshake, and s
aves up to one full round-trip time (RTT) compared to the standard TCP, which re
quires a three-way handshake (3WHS) to complete before data can be exchanged. Ho
wever, TFO deviates from the standard TCP semantics, since the data in the SYN c
ould be replayed to an application in some rare circumstances. Applications shou
ld not use TFO unless they can tolerate this issue, as detailed in the Applicabi
lity section.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7413"/>
<seriesInfo name="DOI" value="10.17487/RFC7413"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8923">
<front>
<title>A Minimal Set of Transport Services for End Systems</title>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<author fullname="S. Gjessing" initials="S." surname="Gjessing"/>
<date month="October" year="2020"/>
<abstract>
<t>This document recommends a minimal set of Transport Services of
fered by end systems and gives guidance on choosing among the available mechanis
ms and protocols. It is based on the set of transport features in RFC 8303.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8923"/>
<seriesInfo name="DOI" value="10.17487/RFC8923"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="NEAT-flow-mapping">
<!-- [rfced] Please note that we have updated the following
references. Please let us know if any corrections are needed.
[NEAT-flow-mapping] updated based on the information found at
<https://ieeexplore.ieee.org/document/8264876>.
[TCP-COUPLING] updated based on the information found at
<https://ieeexplore.ieee.org/document/8406887>.
-->
<reference anchor="NEAT-flow-mapping" target="https://ieeexplore.ieee.or
g/document/8264876">
<front> <front>
<title>Transparent Flow Mapping for NEAT</title> <title>Transparent flow mapping for NEAT</title>
<author> <author initials="F." surname="Weinrank" fullname="F. Weinrank">
<organization/> <organization/>
</author> </author>
<date year="2017"/> <author initials="M." surname="Tuxen" fullname="M. Tuxen">
</front>
<seriesInfo name="IFIP NETWORKING 2017 Workshop on Future of Internet
Transport (FIT 2017)" value=""/>
</reference>
<reference anchor="TCP-COUPLING">
<front>
<title>ctrlTCP: Reducing Latency through Coupled, Heterogeneous Mult
i-Flow TCP Congestion Control</title>
<author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="June" year="2017"/>
</front>
<seriesInfo name="IEEE INFOCOM Global Internet Symposium (GI) workshop
(GI 2018)" value=""/>
</reference>
<reference anchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This document
provides guidelines on the use of UDP for the designers of applications, tunnel
s, 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 I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC2782">
<front>
<title>A DNS RR for specifying the location of services (DNS SRV)</t
itle>
<author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen
"/>
<author fullname="P. Vixie" initials="P." surname="Vixie"/>
<author fullname="L. Esibov" initials="L." surname="Esibov"/>
<date month="February" year="2000"/>
<abstract>
<t>This document describes a DNS RR which specifies the location o
f the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="2782"/> <refcontent>2017 IFIP Networking Conference (IFIP Networking) and Work
<seriesInfo name="DOI" value="10.17487/RFC2782"/> shops</refcontent>
<seriesInfo name="DOI" value="10.23919/IFIPNetworking.2017.8264876"/>
</reference> </reference>
<reference anchor="I-D.ietf-dnsop-svcb-https">
<reference anchor="TCP-COUPLING" target="https://ieeexplore.ieee.org/doc
ument/8406887">
<front> <front>
<title>Service Binding and Parameter Specification via the DNS (SVCB <title>ctrlTCP: Reducing latency through coupled, heterogeneous mult
and HTTPS Resource Records)</title> i-flow TCP congestion control</title>
<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc <author initials="S." surname="Islam" fullname="S. Islam">
hwartz"> <organization/>
<organization>Google</organization>
</author> </author>
<author fullname="Mike Bishop" initials="M." surname="Bishop"> <author initials="M." surname="Welzl" fullname="M. Welzl">
<organization>Akamai Technologies</organization> <organization/>
</author> </author>
<author fullname="Erik Nygren" initials="E." surname="Nygren"> <author initials="K." surname="Hiorth" fullname="K. Hiorth">
<organization>Akamai Technologies</organization> <organization/>
</author> </author>
<date day="11" month="March" year="2023"/> <author initials="D." surname="Hayes" fullname="D. Hayes">
<abstract> <organization/>
<t>This document specifies the "SVCB" ("Service Binding") and "HTT </author>
PS" DNS resource record (RR) types to facilitate the lookup of information neede <author initials="G." surname="Armitage" fullname="G. Armitage">
d to make connections to network services, such as for HTTP origins. SVCB recor <organization/>
ds allow a service to be provided from multiple alternative endpoints, each with </author>
associated parameters (such as transport protocol configuration), and are exten <author initials="S." surname="Gjessing" fullname="S. Gjessing">
sible to support future uses (such as keys for encrypting the TLS ClientHello). <organization/>
They also enable aliasing of apex domains, which is not possible with CNAME. T </author>
he HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semant <date year="2018"/>
ics"). By providing more information to the client before it attempts to establ
ish a connection, these records offer potential benefits to both performance and
privacy.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-1
2"/>
</reference>
<reference anchor="RFC6763">
<front>
<title>DNS-Based Service Discovery</title>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
<date month="February" year="2013"/>
<abstract>
<t>This document specifies how DNS resource records are named and
structured to facilitate service discovery. Given a type of service that a clien
t is looking for, and a domain in which the client is looking for that service,
this mechanism allows clients to discover a list of named instances of that desi
red service, using standard DNS queries. This mechanism is referred to as DNS-ba
sed Service Discovery, or DNS-SD.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6763"/>
<seriesInfo name="DOI" value="10.17487/RFC6763"/>
</reference>
<reference anchor="RFC6762">
<front>
<title>Multicast DNS</title>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
<date month="February" year="2013"/>
<abstract>
<t>As networked devices become smaller, more portable, and more ub
iquitous, the ability to operate with less configured infrastructure is increasi
ngly important. In particular, the ability to look up DNS resource record data t
ypes (including, but not limited to, host names) in the absence of a conventiona
l managed DNS server is useful.</t>
<t>Multicast DNS (mDNS) provides the ability to perform DNS-like o
perations on the local link in the absence of any conventional Unicast DNS serve
r. In addition, Multicast DNS designates a portion of the DNS namespace to be fr
ee for local use, without the need to pay any annual fee, and without the need t
o set up delegations or otherwise configure a conventional DNS server to answer
for those names.</t>
<t>The primary benefits of Multicast DNS names are that (i) they r
equire little or no administration or configuration to set them up, (ii) they wo
rk when no infrastructure is present, and (iii) they work during infrastructure
failures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6762"/>
<seriesInfo name="DOI" value="10.17487/RFC6762"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, 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 int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC8445">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal</title>
<author fullname="A. Keranen" initials="A." surname="Keranen"/>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<date month="July" year="2018"/>
<abstract>
<t>This document describes a protocol for Network Address Translat
or (NAT) traversal for UDP-based communication. This protocol is called Interact
ive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Uti
lities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TUR
N).</t>
<t>This document obsoletes RFC 5245.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>
<reference anchor="RFC5389">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="R. Mahy" initials="R." surname="Mahy"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<date month="October" year="2008"/>
<abstract>
<t>Session Traversal Utilities for NAT (STUN) is a protocol that s
erves as a tool for other protocols in dealing with Network Address Translator (
NAT) traversal. It can be used by an endpoint to determine the IP address and po
rt allocated to it by a NAT. It can also be used to check connectivity between t
wo endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works
with many existing NATs, and does not require any special behavior from them.</t
>
<t>STUN is not a NAT traversal solution by itself. Rather, it is a
tool to be used in the context of a NAT traversal solution. This is an importan
t change from the previous version of this specification (RFC 3489), which prese
nted STUN as a complete solution.</t>
<t>This document obsoletes RFC 3489. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5389"/>
<seriesInfo name="DOI" value="10.17487/RFC5389"/>
</reference>
<reference anchor="RFC5766">
<front>
<title>Traversal Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)</title>
<author fullname="R. Mahy" initials="R." surname="Mahy"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<date month="April" year="2010"/>
<abstract>
<t>If a host is located behind a NAT, then in certain situations i
t can be impossible for that host to communicate directly with other hosts (peer
s). In these situations, it is necessary for the host to use the services of an
intermediate node that acts as a communication relay. This specification defines
a protocol, called TURN (Traversal Using Relays around NAT), that allows the ho
st to control the operation of the relay and to exchange packets with its peers
using the relay. TURN differs from some other relay control protocols in that it
allows a client to communicate with multiple peers using a single relay address
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5766"/>
<seriesInfo name="DOI" value="10.17487/RFC5766"/>
</reference>
<reference anchor="RFC7657">
<front>
<title>Differentiated Services (Diffserv) and Real-Time Communicatio
n</title>
<author fullname="D. Black" initials="D." role="editor" surname="Bla
ck"/>
<author fullname="P. Jones" initials="P." surname="Jones"/>
<date month="November" year="2015"/>
<abstract>
<t>This memo describes the interaction between Differentiated Serv
ices (Diffserv) network quality-of-service (QoS) functionality and real- time ne
twork communication, including communication based on the Real-time Transport Pr
otocol (RTP). Diffserv is based on network nodes applying different forwarding t
reatments to packets whose IP headers are marked with different Diffserv Codepoi
nts (DSCPs). WebRTC applications, as well as some conferencing applications, hav
e begun using the Session Description Protocol (SDP) bundle negotiation mechanis
m to send multiple traffic streams with different QoS requirements using the sam
e network 5-tuple. The results of using multiple DSCPs to obtain different QoS t
reatments within a single network 5-tuple have transport protocol interactions,
particularly with congestion control functionality (e.g., reordering). In additi
on, DSCP markings may be changed or removed between the traffic source and desti
nation. This memo covers the implications of these Diffserv aspects for real-tim
e network communication, including WebRTC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7657"/>
<seriesInfo name="DOI" value="10.17487/RFC7657"/>
</reference>
<reference anchor="RFC3207">
<front>
<title>SMTP Service Extension for Secure SMTP over Transport Layer S
ecurity</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="February" year="2002"/>
<abstract>
<t>This document describes an extension to the SMTP (Simple Mail T
ransfer Protocol) service that allows an SMTP server and client to use TLS (Tran
sport Layer Security) to provide private, authenticated communication over the I
nternet. This gives SMTP agents the ability to protect some or all of their comm
unications from eavesdroppers and attackers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3207"/>
<seriesInfo name="DOI" value="10.17487/RFC3207"/>
</reference>
<reference anchor="RFC1928">
<front>
<title>SOCKS Protocol Version 5</title>
<author fullname="M. Leech" initials="M." surname="Leech"/>
<author fullname="M. Ganis" initials="M." surname="Ganis"/>
<author fullname="Y. Lee" initials="Y." surname="Lee"/>
<author fullname="R. Kuris" initials="R." surname="Kuris"/>
<author fullname="D. Koblas" initials="D." surname="Koblas"/>
<author fullname="L. Jones" initials="L." surname="Jones"/>
<date month="March" year="1996"/>
<abstract>
<t>This memo describes a protocol that is an evolution of the prev
ious version of the protocol, version 4 [1]. This new protocol stems from active
discussions and prototype implementations. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1928"/>
<seriesInfo name="DOI" value="10.17487/RFC1928"/>
</reference>
<reference anchor="RFC7230">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Ro
uting</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2014"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document provides an overview of HTTP architecture and its associated term
inology, defines the "http" and "https" Uniform Resource Identifier (URI) scheme
s, defines the HTTP/1.1 message syntax and parsing requirements, and describes r
elated security concerns for implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7230"/>
<seriesInfo name="DOI" value="10.17487/RFC7230"/>
</reference>
<reference anchor="RFC9040">
<front>
<title>TCP Control Block Interdependence</title>
<author fullname="J. Touch" initials="J." surname="Touch"/>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<author fullname="S. Islam" initials="S." surname="Islam"/>
<date month="July" year="2021"/>
<abstract>
<t>This memo provides guidance to TCP implementers that is intende
d to help improve connection convergence to steady-state operation without affec
ting interoperability. It updates and replaces RFC 2140's description of sharing
TCP state, as typically represented in TCP Control Blocks, among similar concur
rent or consecutive connections.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9040"/>
<seriesInfo name="DOI" value="10.17487/RFC9040"/>
</reference>
<reference anchor="RFC3124">
<front>
<title>The Congestion Manager</title>
<author fullname="H. Balakrishnan" initials="H." surname="Balakrishn
an"/>
<author fullname="S. Seshan" initials="S." surname="Seshan"/>
<date month="June" year="2001"/>
<abstract>
<t>This document describes the Congestion Manager (CM), an end-sys
tem module that enables an ensemble of multiple concurrent streams from a sender
destined to the same receiver and sharing the same congestion properties to per
form proper congestion avoidance and control, and allows applications to easily
adapt to network congestion. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3124"/>
<seriesInfo name="DOI" value="10.17487/RFC3124"/>
</reference>
<reference anchor="RFC6525">
<front>
<title>Stream Control Transmission Protocol (SCTP) Stream Reconfigur
ation</title>
<author fullname="R. Stewart" initials="R." surname="Stewart"/>
<author fullname="M. Tuexen" initials="M." surname="Tuexen"/>
<author fullname="P. Lei" initials="P." surname="Lei"/>
<date month="February" year="2012"/>
<abstract>
<t>Many applications that use the Stream Control Transmission Prot
ocol (SCTP) want the ability to "reset" a stream. The intention of resetting a s
tream is to set the numbering sequence of the stream back to 'zero' with a corre
sponding notification to the application layer that the reset has been performed
. Applications requiring this feature want it so that they can "reuse" streams f
or different purposes but still utilize the stream sequence number so that the a
pplication can track the message flows. Thus, without this feature, a new use of
an old stream would result in message numbers greater than expected, unless the
re is a protocol mechanism to "reset the streams back to zero". This document al
so includes methods for resetting the transmission sequence numbers, adding addi
tional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6525"/>
<seriesInfo name="DOI" value="10.17487/RFC6525"/>
</reference>
<reference anchor="RFC8260">
<front>
<title>Stream Schedulers and User Message Interleaving for the Strea
m Control Transmission Protocol</title>
<author fullname="R. Stewart" initials="R." surname="Stewart"/>
<author fullname="M. Tuexen" initials="M." surname="Tuexen"/>
<author fullname="S. Loreto" initials="S." surname="Loreto"/>
<author fullname="R. Seggelmann" initials="R." surname="Seggelmann"/
>
<date month="November" year="2017"/>
<abstract>
<t>The Stream Control Transmission Protocol (SCTP) is a message-or
iented transport protocol supporting arbitrarily large user messages. This docum
ent adds a new chunk to SCTP for carrying payload data. This allows a sender to
interleave different user messages that would otherwise result in head-of-line b
locking at the sender. The interleaving of user messages is required for WebRTC
data channels.</t>
<t>Whenever an SCTP sender is allowed to send user data, it may ch
oose from multiple outgoing SCTP streams. Multiple ways for performing this sele
ction, called stream schedulers, are defined in this document. A stream schedule
r can choose to either implement, or not implement, user message interleaving.</
t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8260"/> <refcontent>IEEE INFOCOM 2018 - IEEE Conference on Computer Communicat
<seriesInfo name="DOI" value="10.17487/RFC8260"/> ions Workshops (INFOCOM WKSHPS)</refcontent>
<seriesInfo name="DOI" value="10.1109/INFCOMW.2018.8406887"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
85.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.27
82.xml"/>
<!-- [I-D.ietf-dnsop-svcb-https] Published as RFC 9460 as of 04/24/24-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
460.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
763.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
762.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
000.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
445.xml"/>
<!-- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/refe
rence.RFC.5389.xml"/>-->
<!--[rfced] The following RFCs have been obsoleted. We will update to
point the reader to the one on the right unless we hear
objection.
RFC 5389 becomes RFC 8489
RFC 5766 becomes RFC 8656
RFC 7230 becomes RFC 9110
RFC 7540 becomes RFC 9113
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
389.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
766.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
657.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
207.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
928.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
230.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
124.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
525.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
260.xml"/>
</references> </references>
</references> </references>
<?line 1189?>
<section anchor="appendix-mapping-template"> <section anchor="appendix-mapping-template">
<name>API Mapping Template</name> <name>API Mapping Template</name>
<t>Any protocol mapping for the Transport Services API should follow a com mon template.</t> <t>Any protocol mapping for the Transport Services API should follow a com mon template.</t>
<t>Connectedness: (Connectionless/Connected/Multiplexing Connected)</t> <t>Connectedness: (Connectionless/Connected/Multiplexing Connected)</t>
<t>Data Unit: (Byte-stream/Datagram/Message)</t> <t>Data Unit: (Byte-stream/Datagram/Message)</t>
<t>Connection Object:</t> <t>Connection Object:</t>
<t>Initiate:</t> <t>Initiate:</t>
<t>InitiateWithSend:</t> <t>InitiateWithSend:</t>
<t>Ready:</t> <t>Ready:</t>
skipping to change at line 1656 skipping to change at line 1828
<t>ConnectionReceived:</t> <t>ConnectionReceived:</t>
<t>Clone:</t> <t>Clone:</t>
<t>Send:</t> <t>Send:</t>
<t>Receive:</t> <t>Receive:</t>
<t>Close:</t> <t>Close:</t>
<t>Abort:</t> <t>Abort:</t>
<t>CloseGroup:</t> <t>CloseGroup:</t>
<t>AbortGroup:</t> <t>AbortGroup:</t>
</section> </section>
<section anchor="appendix-reasons-errors"> <section anchor="appendix-reasons-errors">
<name>Reasons for errors</name> <name>Reasons for Errors</name>
<t>The Transport Services API <xref target="I-D.ietf-taps-interface"/> all <t>The Transport Services API <xref target="RFC9622"/> allows for several
ows for the several generic error types to specify a more detailed reason about generic error types to specify a more detailed reason about why an error occurre
why an error occurred. This appendix lists some of the possible reasons.</t> d. This appendix lists some of the possible reasons.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>InvalidConfiguration: <dt>InvalidConfiguration:</dt><dd>
The transport properties and Endpoint Identifers provided by the application are The transport properties and Endpoint Identifiers provided by the application ar
either contradictory or incomplete. Examples include the lack of a Remote Endpo e either contradictory or incomplete. Examples include the lack of a Remote Endp
int Identifer on an active open or using a multicast group address while not req oint Identifier on an active open or using a multicast group address while not r
uesting a unidirectional receive.</t> equesting a unidirectional receive.</dd>
</li>
<li> <dt>NoCandidates:</dt><dd>
<t>NoCandidates: The configuration is valid, but none of the available transport protocols can sa
The configuration is valid, but none of the available transport protocols can sa tisfy the transport properties provided by the application.</dd>
tisfy the transport properties provided by the application.</t>
</li> <dt>ResolutionFailed:</dt><dd>
<li> The remote or local specifier provided by the application cannot be resolved.</d
<t>ResolutionFailed: d>
The remote or local specifier provided by the application can not be resolved.</
t> <dt>EstablishmentFailed:</dt><dd>
</li> The Transport Services system was unable to establish a transport-layer connecti
<li> on to the Remote Endpoint specified by the application.</dd>
<t>EstablishmentFailed:
The Transport Services system was unable to establish a transport-layer connecti <dt>PolicyProhibited:</dt><dd>
on to the Remote Endpoint specified by the application.</t> The system policy prevents the Transport Services system from performing the act
</li> ion requested by the application.</dd>
<li>
<t>PolicyProhibited: <dt>NotCloneable:</dt><dd>
The system policy prevents the Transport Services system from performing the act The Protocol Stack is not capable of being cloned.</dd>
ion requested by the application.</t>
</li> <dt>MessageTooLarge:</dt><dd>
<li> The Message is too big for the Transport Services system to handle.</dd>
<t>NotCloneable:
The Protocol Stack is not capable of being cloned.</t> <dt>ProtocolFailed:</dt><dd>
</li> The underlying Protocol Stack failed.</dd>
<li>
<t>MessageTooLarge: <dt>InvalidMessageProperties:</dt><dd>
The Message is too big for the Transport Services system to handle.</t> The Message Properties either contradict the Transport Properties or cannot be s
</li> atisfied by the Transport Services system.</dd>
<li>
<t>ProtocolFailed: <dt>DeframingFailed:</dt><dd>
The underlying Protocol Stack failed.</t> The data that was received by the underlying Protocol Stack could not be process
</li> ed by the Message Framer.</dd>
<li>
<t>InvalidMessageProperties: <dt>ConnectionAborted:</dt><dd>
The Message Properties either contradict the Transport Properties or they can no The connection was aborted by the peer.</dd>
t be satisfied by the Transport Services system.</t>
</li> <dt>Timeout:</dt><dd>
<li> Delivery of a Message was not possible after a timeout.</dd>
<t>DeframingFailed:
The data that was received by the underlying Protocol Stack could not be process </dl>
ed by the Message Framer.</t>
</li>
<li>
<t>ConnectionAborted:
The connection was aborted by the peer.</t>
</li>
<li>
<t>Timeout:
Delivery of a Message was not possible after a timeout.</t>
</li>
</ul>
</section> </section>
<section anchor="appendix-implementations"> <section anchor="appendix-implementations">
<name>Existing Implementations</name> <name>Existing Implementations</name>
<t>This appendix gives an overview of existing implementations, at the tim e of writing, of Transport Services systems that are (to some degree) in line wi th this document.</t> <t>This appendix gives an overview of existing implementations, at the tim e of writing, of Transport Services systems that are (to some degree) in line wi th this document.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Apple's Network.framework: <t>Apple's Network.framework:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Network.framework is a transport-level API built for C, Objecti ve-C, and Swift. It a connect-by-name API that supports transport security proto cols. It provides userspace implementations of TCP, UDP, TLS, DTLS, proxy protoc ols, and allows extension via custom framers.</t> <t>Network.framework is a transport-level API built for C, Objecti ve-C, and Swift. It is a connect-by-name API that supports transport security pr otocols. It provides user-space implementations of TCP, UDP, TLS, DTLS, and prox y protocols, and it allows extension via custom framers.</t>
</li> </li>
<li> <li>
<t>Documentation: <eref target="https://developer.apple.com/docume ntation/network">https://developer.apple.com/documentation/network</eref></t> <t>Documentation: <eref target="https://developer.apple.com/docume ntation/network"/></t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>NEAT and NEATPy: <t>NEAT and NEATPy:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>NEAT is the output of the European H2020 research project "NEAT "; it is a user-space library for protocol-independent communication on top of T CP, UDP and SCTP, with many more features, such as a policy manager.</t> <t>NEAT is the output of the European H2020 research project "NEAT "; it is a user-space library for protocol-independent communication on top of T CP, UDP, and SCTP, with many more features, such as a policy manager.</t>
</li> </li>
<li> <li>
<t>Code: <eref target="https://github.com/NEAT-project/neat">https ://github.com/NEAT-project/neat</eref></t> <t>Code: <eref target="https://github.com/NEAT-project/neat"/></t>
</li> </li>
<li> <li>
<t>Code at the Software Heritage Archive: <eref target="https://ar chive.softwareheritage.org/swh:1:dir:737820840f83c4ec9493a8c0cc89b3159e2e1a57;or igin=https://github.com/NEAT-project/neat;visit=swh:1:snp:bbb611b04e355439d47e42 6e8ad5d07cdbf647e0;anchor=swh:1:rev:652ee991043ce3560a6e5715fa2a5c211139d15c">ht tps://archive.softwareheritage.org/swh:1:dir:737820840f83c4ec9493a8c0cc89b3159e2 e1a57;origin=https://github.com/NEAT-project/neat;visit=swh:1:snp:bbb611b04e3554 39d47e426e8ad5d07cdbf647e0;anchor=swh:1:rev:652ee991043ce3560a6e5715fa2a5c211139 d15c</eref></t> <t>Code at the Software Heritage Archive: <eref target="https://ar chive.softwareheritage.org/swh:1:dir:737820840f83c4ec9493a8c0cc89b3159e2e1a57;or igin=https://github.com/NEAT-project/neat;visit=swh:1:snp:bbb611b04e355439d47e42 6e8ad5d07cdbf647e0;anchor=swh:1:rev:652ee991043ce3560a6e5715fa2a5c211139d15c"/>< /t>
</li> </li>
<li> <li>
<t>NEAT project: <eref target="https://www.neat-project.org">https <!-- [rfced] Appendix C: The URL for the NEAT project
://www.neat-project.org</eref></t> (https://www.neat-project.org) does not appear to be working
("Unable to connect"). Please let us know how this should be
updated.
Original:
- NEAT project: https://www.neat-project.org
-->
<t>NEAT project: <eref target="https://www.neat-project.org"/></t>
</li> </li>
<li> <li>
<t>NEATPy is a Python shim over NEAT which updates the NEAT API to be in line with version 6 of the Transport Services API draft.</t> <t>NEATPy is a Python shim over NEAT that updates the NEAT API to be in line with version 6 of the Transport Services API <xref target="RFC9622"/> .</t>
</li> </li>
<li> <li>
<t>Code: <eref target="https://github.com/theagilepadawan/NEATPy"> https://github.com/theagilepadawan/NEATPy</eref></t> <t>Code: <eref target="https://github.com/theagilepadawan/NEATPy"/ ></t>
</li> </li>
<li> <li>
<t>Code at the Software Heritage Archive: <eref target="https://ar chive.softwareheritage.org/swh:1:dir:295ccd148cf918ccb9ed7ad14b5ae968a8d2c370;or igin=https://github.com/theagilepadawan/NEATPy;visit=swh:1:snp:6e1a3a9dd4c532ba6 c0f52c8f734c1256a06cedc;anchor=swh:1:rev:cd0788d7f7f34a0e9b8654516da7c002c44d2e9 5">https://archive.softwareheritage.org/swh:1:dir:295ccd148cf918ccb9ed7ad14b5ae9 68a8d2c370;origin=https://github.com/theagilepadawan/NEATPy;visit=swh:1:snp:6e1a 3a9dd4c532ba6c0f52c8f734c1256a06cedc;anchor=swh:1:rev:cd0788d7f7f34a0e9b8654516d a7c002c44d2e95</eref></t> <t>Code at the Software Heritage Archive: <eref target="https://ar chive.softwareheritage.org/swh:1:dir:295ccd148cf918ccb9ed7ad14b5ae968a8d2c370;or igin=https://github.com/theagilepadawan/NEATPy;visit=swh:1:snp:6e1a3a9dd4c532ba6 c0f52c8f734c1256a06cedc;anchor=swh:1:rev:cd0788d7f7f34a0e9b8654516da7c002c44d2e9 5"/></t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>PyTAPS: <t>PyTAPS:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A TAPS implementation based on Python asyncio, offering protoco l-independent communication to applications on top of TCP, UDP and TLS, with sup port for multicast.</t> <t>A Transport Services (TAPS) implementation based on Python asyn cio, offering protocol-independent communication to applications on top of TCP, UDP, and TLS, with support for multicast.</t>
</li> </li>
<li> <li>
<t>Code: <eref target="https://github.com/fg-inet/python-asyncio-t aps">https://github.com/fg-inet/python-asyncio-taps</eref></t> <t>Code: <eref target="https://github.com/fg-inet/python-asyncio-t aps"/></t>
</li> </li>
<li> <li>
<t>Code at the Software Heritage Archive: <eref target="https://ar chive.softwareheritage.org/swh:1:dir:a7151096d91352b439b092ef116d04f38e52e556;or igin=https://github.com/fg-inet/python-asyncio-taps;visit=swh:1:snp:4841e59b53b2 8bb385726e7d3a569bee0fea7fc4;anchor=swh:1:rev:63571fd7545da25142bc1a6371b8f13097 cba38e">https://archive.softwareheritage.org/swh:1:dir:a7151096d91352b439b092ef1 16d04f38e52e556;origin=https://github.com/fg-inet/python-asyncio-taps;visit=swh: 1:snp:4841e59b53b28bb385726e7d3a569bee0fea7fc4;anchor=swh:1:rev:63571fd7545da251 42bc1a6371b8f13097cba38e</eref></t> <t>Code at the Software Heritage Archive: <eref target="https://ar chive.softwareheritage.org/swh:1:dir:a7151096d91352b439b092ef116d04f38e52e556;or igin=https://github.com/fg-inet/python-asyncio-taps;visit=swh:1:snp:4841e59b53b2 8bb385726e7d3a569bee0fea7fc4;anchor=swh:1:rev:63571fd7545da25142bc1a6371b8f13097 cba38e"/></t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
</back> <section anchor="acknowledgements" numbered="false">
<!-- ##markdown-source: <name>Acknowledgements</name>
H4sIAAAAAAAAA+S96XIbWZYm+B9P4S39CLILgNZYktFdXQyKUtBCIXFERoZN <t>This work has received funding from the European Union's Horizon 2020 r
Z6clHYCD9BTgjnJ3iEIo1dav0b/mYeZN5knm7PdcX0AqKmsZm7DuLBGAX7/L esearch and
uWc/35lMJqMmb1bZUXK23qyydVY0eXGdnBVNVi3TeVYnTZlcVmlRb8qqSS6y innovation programme under grant agreement No. 644334 (NEAT) and No. 815178 (5GE
6kMOn47S2azKPhwll8fnF+HRtMnLYrQo50W6hiEXVbpsJnnWLCdNuqknOfxu NESIS).</t>
8uS70SJtsqPRHP73uqx2R0leLMvRKN9UR0lTbevm6ePHf3j8dJRWWXoUXj66 <t>This work has been supported by:</t>
Lav311W53chrf4W/cbKv8LPR+2wHP1gc8dyLrJm8wNePRnWTFou/pKuygCnt <ul>
YO6b/Cj5U1POx0kNw1bZsoZ/7db4jz+PRum2uSmro1GSTOD/JzC5+ig5niY/ <li>Leibniz Prize project funds from the DFG - German
VNuibqpyTZ/yAo+LIm19UZW4mdkib8qKPiir66Pkp7RawTwWyS9F/iGr6rzZ Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</li>
0ZfwXJY1R+HjrKmvU5hw8pS+n8MPj5Jvvn6SfPedDcLflNuiwc27uM0WWUGf <li>the UK Engineering and Physical Sciences
Zes0Xx0lKcxqOtNZ/dP7dDuts3g9l9PkPN2udm4tl+V6vXOf9i/keANHDVs8 Research Council under grant EP/R04144X/1.</li>
n0bzf1tk8tV5Wr1Pfk13bvon201WAVmV4+QkXeXLsiryNPnD14+fPI+XArvQ <li>the Research Council of Norway under its "Toppforsk"
ZIvkAugICK9cJsfrrMrnqV9cs8EZ/lOKL5vOadPdut5Nk9Pi+iatFo1b2rss programme through the "OCARINA" project.</li></ul>
q7P4C1rMG6DMVf4xWsmTp0+S49Wsyq9vmtY6Xpd18iptSiCXk2Oc/7OnXz5/ <t>Thanks to <contact fullname="Colin S. Perkins"/>, <contact fullname="To
vA3/1GQylynQabyC82lymcN0V27+5zf5Kt9skovoO1rCxfF5cnEareBVBt9k m Jones"/>, <contact fullname="Karl-Johan Grinnemo"/>, and <contact fullname="Go
k4sm29xkRV0W8M8q/b//ryz5dvLkmVvPk8dff/1t8kNWrfIiXsirrFqnxc7P rry Fairhurst"/> for their contributions to the design of this specification.
e8Nz+KeGJtCd98/T5Nds9Zuf9s/5/CbNVu5zmnK4ArhFb+tVGU3//G3yQ/kR Thanks also to <contact fullname="Stuart Cheshire"/>, <contact fullname="Josh Gr
Jvfd4+QHmNkCLrOb9ONnT75JwlM25TdldZtGM17j62+zf8qX+XSbl9MCeExR aessley"/>, <contact fullname="David Schinazi"/>, and <contact fullname="Eric Ki
wsIaeP8R/fJs8mIa2FNazW/6Ps+VGR4BkwJWFQ3x5vT4crJclbeTNdAksCP+ nnear"/> for their implementation and design efforts, including Happy Eyeballs,
OEmErTL7AlZWNMlL+FnyM/8sgXHoYfl5DZSS1Tg8cLCXZ+fw3eWvb9/9dPbm that heavily influenced this work.</t>
VfL08ZNvidvVN+UmKYvk5bbZVhlunzI7x6MPXp5d0iOHMjRztFonpsfG/9Hh </section>
vcTDywsY4v3wj+CEL7fZR+E1SUJcnF5EH1yenE9O3v5y/hpm3NqDB/OmWsH3
eBMX2zmu/jU8XMx3SXMDzPv6JjkBFr7KFuPkxwwWVF5nRVZu6+Tn7arJJ7Rv <!--[rfced] We had the following questions/comments related to
8Dz8qrjOahQy+E/gbqsH3e1z8z47PT1Nzt68fHvy9ufk1aqcpauwYxe79aas abbreviation use:
8+06OXh1dpjc6v7CX7iq7wa2L+wL7QrcybN6la7tU6b9i3SZ//N2FX3XejK6
MftuTefJn6bJjzkc9U3r0Z+qHDYHhEf0bevhF/BwimIwfvZF+iFfRN+0nns1 a) Please note that we have expanded abbreviations in this document.
TY6rdd6k11nr0VdA3B/yFTD/1g+6W/Xqr1kNp3Td3q0GqC/+0qjru8nj55Mn Please review and let us know any objections. Examples include:
X49Go8lkkqQz4BPpHMT65U3Wo5iAIK+bbJ1kRTpbwZ8oJ4ADI8mQKrMFQdDY
U5uqBD2gXNXJcpV9zGerHV1LoA6kBmAu6/W2kMdHoEUki2yZFzisPTpBDrXJ Differentiated Services Code Point (DSCP)
4H+Kpm8+x2ECyTkQdpWu15GGlRwcnwP5NTdpk+R1MktrECHwYzjGtN4Vc7gg Multipath TCP (MPTCP)
BVyF8Sj7AK+YLCpgPUVCPAn2AYfdpA2SNFzPGxgAtK8t6mJ4JT7gVHG219t8 Stream Control Transmission Protocol (SCTP)
keH6c6/l1dv5DXzJWzblDV7ni8UqG40e4gyrEq4rLX5ou5FngtCbEz/69KnL
UD9/dpsmh0NrTVdwq7sHZAcRn5QcCc7aDg0XDDR3fsYDRqtJso9wuVl9jV6B b) We also introduced these abbreviations where the expansions were
O0TzWeDONP2rwjHbizEp8Pmz7DT+ioar82scD141yxJkXSD0k3RelXWdrJGD first used because the abbreviations were used later in the document.
oWLUR3VIUjWofMjJ9dNkmaW4m/UUN/3LDjTeYRgR7jRtfP8aZR08VrlcglSG
XbwWFkt7twCqW5Wgv4HSM9sChRKRFiWOntXzKt+QKAzTkG0GgZcsQaDjGE36 TFO
PoOl7minKtgoFKG4DFDJr/UUcDPrTTYHaS23BTjCnjPAadzAzYDxgAPTrHCY DF
v5Yz3Ey4PPGM6MM9/AKnua0KGqPK/nkLW1DLQI588NrhnszzmlYJn9yAaILP TAPS
4PfAcPL6BphGUWR0aWDL8IDlF3T+sMXI2dKkBBUIXgYk6h+AAYEh2Fi4NCRx
WDTwjHJVXtO1WODWNBFpeMYxQNP3uKlTuvaeoE5sbsnb2V/hXzVzgjDnpOTP
5VLD2HzzFp2bh5y1d16oV01o2udVFkYe00ezbQH8SC4I2RGZvGtB9DfL+OD9
KcEYKCXgsHBH+RSAXGHzQefIaCY8uN3J72UCJ+23pzVcZV4iv7XKkPAzHDpN
UO/DqdGRAiH/DAIMxF+NB5TlMACcNlA8b9QMWFiW8fm8LuegiuC83mXrskHj
ZLEpccI4E/ycfgXiHLnJGOVNCrLxQ5bcpjmdjJ/TIluRSg1c8tYtATlItKN2
VqDnbFcL5FZ2S5gf8m7Xfdvduglz+HtWNjewIWDW4oxvKyAvUBKSvneijb/a
8vannqzKAng9DA/WeUI7QMSdo1ZweyO75X4OhD6HNzZ4NU66C7PToeeMXUR7
71ehO91iFkC6YP/ASTquXaNVx7QEq0O5yMeu93qavNhWeDI4HmwerJT20W4z
XdSDT59wbyb26efPh+P2Im9BmSIeCx8gRVU57BEd1hrscZgG/gmGD9+xHsmC
+laTwmaPE1CoYP0mheDYFjnqVqiM8G/BXJ2/B0FFFi+8BdQK2N3R6C0+mLZO
8waJBHdyK1ecTwOpo9w2PCl/LhWMEMi4Z6uFFMFQRb5ElNYQg9mQeSibqZR4
kyHZ7tobBq/Rl+AKcetmuGg8Mvu9P/d1SqoEaNpoUBB7hl+UYPXnBVzMPgoW
YblOd7C7H8rVh6xvOTBRlG4sjBdZtpngSsa0HiUOuRG3wCBQC3KfyVXLkc0o
t9KT6F4EJyfGQ1w/ds3B7Ddw/0TYICmTUmkbsMgaMJ1r3fg5yqeiRSnT5CVs
d/YxxZH5vTUo8d3bSFuFdLdmig13M0WqvO7ViYxyk4Nsej1FzoeGn5cK8Mnr
C1CG6prehYIUfoKf//LinFkybe1yu1rtJqJTABkM8tzkDJV3/BFqOWnywo2P
f1+cXJ6TeyJd45//xy9nJ/YnEjjYW5eX54+eyoeHUxKRbj/OuwScDpEvSlBv
UsBRlCRIHF8PspYUsbRq9MTaJ0GuUaAg91HMj/JaODAoY7g9OFEmlSXd3bDx
K+RnprqOgTuDoao6KdBPjTchX/Jd48HgsBeP4CplKLiW28LRHWr6+aohJYjo
YAl6H72TlmGHli4WQDSoyJMQB1KpQXn5b+9ennz3+LuvQQ08WAZqBKaEdwzJ
AD6E/zN5DSLJURnSBbCpaF3A0opFfYM6KnHtBfChQ710V2cFiFug36vA+WBl
K71xF9mqe8Y4U6MtcxixDkrXigWYPyc69TUyLLBak4N8SpImVj1Z7aYfwO6t
Uty8dbnQLXdcknRdNzrQG4izfLOFh4wJ7eN1sH4jSOVMOEWdObOutroGNMlE
wSuHt+QVbvQyv95WEbefkQZZg9mB5kBYuHDqmKeyDuwk6oqmhgth64u0wAXb
C/xdnyoLk52cetpnTRZ40iS+Ehs46WzIPGXK3PndVqLtXFD4cEfbls6Q6Eip
eJ8Rz4B/g41R7cz04Z9sgC3BbOFU4sFgnDltHA4ASxNNozv3tpzTi1STflUi
wVRO2RSTlWQ5LiNyeKA+eJuBfErDvY/UaFGFTNX+kKeDF2Kc5Eu1/4BSVnXZ
zyCncIYX8ulzcnAOGoA1u9lpq/uZrVAbzzmdsRKlBAlLXgxsI5i62TwlBwRt
PdxE4nO4E3mx4bMMVqBx43W6GKBhlWZ0/dNNir5s3FTggaSTiQ2+ReuBr6/t
ONnl5K2ZpyCsr7Nq0uw2tA71hc7ZF3o4ZZJua1gNnDlRUR1xCfIjeOHRq7cj
WeBOyF7NBwQJawW9px8LK/ZJ9Cllverhthb7bpEtU1Amkg8pmBG1kxD5oMWL
9+pgjwsB9+vhQ6SdwKEmaHokWVWVVX2Xj1HI6yZFyiCuhDtZbzf462zh/Twf
QK1CDqdiM0vhf+jBIJzU74O6H22jcGqkl1m+ypW1C7OnoacJa+nFwK3P4VqG
BYRDGdQXZWkgsOY3svPoDiG3DZvR5U0+y2V5RkrXKeptsU0dFiSTtl1wO3NQ
Z5m78t9Mn+6/9MpsyYeXq1SVqew8e8LTPWPaWJbIzIl8gbXD4pcwETQ3gjgC
zRemsIcnkI/iWH1DpMLFm44za9vMwRap4Uc10Ss9uduzJy0FO+84oeRA6uQK
XvZzff0OzH+mkN0Ve+mKkr2hcgIoJ8OL8oImEBgMbxLo+mB2bItC6W6PswwN
Idk7mAdeSxqU7830d2wUa73Em+F3YhvRJSHldyzOXb33ZErdgy7vOoRwje7Y
ch0e9rxyu02b3aCbYv+Z0Iat85qu1b6dG12CQf+hzBekf8xZXYMflttq3mal
S1TfQKYVWbZAocquWeCfcGRpIa6h+RBzozuAO5qlFer/IONLsHiAQJgrvivZ
6yZHvilhL3aqMgUJa2x46N4oe5yv0NcJm8e61E2+IXXKj86KXksA5MgPgQwL
mptqKbOcyBRPnoTWHHYaRSSYsxVoT6AUExtoEt05YhJBdSHXks0z9nRyXKFG
gpyvtouMr5Tu+ipfE5U1JXCEJ9MovuPeAMcxzUDg+5d2Nqvp1T+H1Kjp6Ok0
ebEr0jVYStHG2cvoL9yfDegVoNJV5ZqdYEwpZPB/DH/O5QJ5G4UV0cAtNBZm
TBiTZUzE9QQ1xEW2rXD/H8HyPuQYyY3295RvGh3LbbojPdRNrMqaKoejlAVN
5H3xPMlbxMHjtxdq5s9JK8Qo6Lx+tM5SdCqxYlxqvIX/Jb7cmiIfhUS9ZuVH
UWthXJgNbPkz2HLRPNqennjrYR8lrCSnACzm7QX5BwKFsEiiCFG6GrfYcIWB
vJugjEcm3Hpb82XG0Al6/chvhAEWR+FOGUc/LGz8SvyZuNpyDodSJ+TKDb41
nuwq3VHwhzkT675pd25sLnjTrQA+d203Ex6bJmdLDcWFCSAZiM/cLYroc5bh
VWj5svI6MhXVKmGXY0dvRN2arg1+cxUZeafI7K7YzcVcHpmtuAtQ0e6/vskq
Sxd0RUu/qx2jHF1cKhvo7bhxMOwasxhgtt3bI0d7TVFctxeNMn4YAVlcDdO9
AF6zQvYsbjZ/5+kcZRhi60NTkbMYnBGfQmtPv6rV4J4mr9O60Sm0mXNTZ6sl
vVr1c7SM8jo1hQt4F2xd30Zs2aWUfcS35g3de9IZeq0DvDok4OD3rKmZrxjd
8Bj9aosr9cXgb2D5N+WCvAdlSb7f7UZNIv0tud0/pNVOY7fwb+JdG6BivHh4
qzqBRaFTjMGvN7R+fIMMjwIv+4DS2N5iPi6eKYr/ZCFcHXihugkS8oezTHcG
AdIf3mP0uVMWVXArtUQCO/7DF3ikTDlVdp1WCxVA8amrJw6PlL3jEqpEElts
M8mhqIixLdYghvFuYAxYnel7g4jR3Uw+PWzFQky/6ARP2KEeEjOCbyu7BtOD
BXrrcgKliO8QqY6EgOcl6sVqe4NnO3Lx4RuD+6/Pu9VvMKMxjtYQsegoElmp
lrhmn3vLV4MOxuCcYGWo5ZmSjaHYW8SHUeSv4IZzABlVZlb6G2RkNUfXYjc+
Xx9+Jz+7ILlgWnWdNduNsltdMwcn8P0k+UEVUh2MfLxdesK7eYf/eZGzR4Bi
63C+8M7NZIV5ByDMs019lJxY0OpVimvDozlQcUtuP3MZTZ9On3QtSA5vY6Ct
THJ29ovTFMarx23lJfP+MWSjYqVe69thrO/pl2Fm79L5/mn1GLY2Lfgx0xbO
SYN+TjcwF7W4YTn+iIdUBjY4bK+xA2tFQSfx2jetpVU0ffSJdNck4a5aeRx+
ZgHFchOi+0POIVEJb8qyVq6zzCsky43KPpBS8yzk5LRpleeqrDO8R1V1mRlv
z7bekhoJU7i+zsjhCP+saN5kUxaga+q70yX60TFWBzrQWA06dvqRmxIumgT1
+FQ3aYUBAFKKOHRCI2hcHuco7gVkhWRXimwC8bJlbsnOrii3p6m2c/aWsM9H
zoA3lk+HPXaYJqunhv+e2KPk0aIgpcQKQAFmrgfDgkY9b+uwNct+HYBsTX6T
e7/ZUqud+BfX6CmgcE/mVSlakLIojiZroFTvnJ6+hP/OzjW+g5MMN6AlYW9R
LaxFFcODH0ugJxJuYnGYIkIK6wFr5+Hn+q3pIYdMnEYgHG8MMaEotyeVEJ+y
xWDRhaVMkx/LW7RDx0xsyMNInBI18W4mHN+jPI6Qc2SSQeNERuZH6JLAj3pC
lsTnyXuDuZQWJhuzX4JFAb5+5rIA0KMA5+LDa+ZaMNPve/ew3gQbgRin92se
aE4Suthkw9PCqZkcxYTXFNFBmBqk58GMtS7X3k2Ic+CECBFTwfCMjiqWig+c
VfEA7oz4kH55cX5IjtiVzsqnYFHUuslX+W8Zm0XOk+sYcXBJYbRYo9BwQ36F
bcfj78lBQ2n7hYxTpO2HPLtlisvIyYy6RV6Q5AReN/i8vYQ4B986oPfra1QB
m2yPNx/vefgdvhW9LNmmYdYqrpEaDSsQVB/SVb4Qv4yFOk2KjlXMiqNO3ZzH
tTPGxnZwPRvHiofoYnUnJ4DTYOwK/ANdgL67Igl5KGRAz+BZO4skeD0Ofs0n
L3P69evL00PeD3uBXB9OLg3M7MNzY2dyq3kU0VrHoiqFZy1i3/csvNc9GUJx
/oXfBKbTPTB2COynC9EkkbxY+LKrvD4ajf6n/Tc6tnH/1LOpR8nt7e1UjhFL
co6eP3/25+RPluGMdVK7PydJ8icV60d4gH8e/W3yjwMj/unp48dPjhaz746e
Pjs6evJnHlL+8yPTDv/5C0Z+8oen08eoJUZDdsaF3f+9M37+dO+MB0Z22z06
Rv9MIUIV1Zt6O5vAqyoO5LKa3XeJ1Qi9JZOU3d27ONzfyma1y07XuypMkNch
z4het7qGIZqbtURegLuzvLY5KklRqutuTBYZkzxpt+iAquB2h+h1r1YfK9nj
Hl6wqbaFGPY1pYPMQBRQsAoM45Ls2pHcrY4XNQoQ4cvuG3eaovOBddbso7A+
5MFxKjcLRWJW7OnHFAnxyFiICtj9okRhNpLfwDDvWPo7zzodCjpY2CuBK+1Z
KG72Oa0IpNRo48J7x+hLioIhwn7Zyb9TwYc5m1Wess//wimCJ0EDTDmDHDXO
hy2NE2iVVE1kHjMQgmNVXIiTmyjoph/W7Piww2beyMpn18wNgsdevQja8PdM
sSFLOp+zTESnn9Awpyuyv5iSMbz2Das/RVUNbOUlrGahN4917SjjV2XovLzh
AEP39o3FsVCYBBw71wXSCB9Fqlw6EJHGqyRrmII71yVJPakVwBoUyh8vxFak
UacJzZ+mLvFwmroWlVDiEC8vWk0P69BHJH15i/V3puZS7kq2CrERp88s0Ote
zE22tGJq5KDR97HeC+sEtTnIuN7plH3KLZ1oa2YuZaNvIAvQpUH7dfZHyrHy
4czAaXLmFFymc9pv29DgtuxfR+NViFySL5CEcBghmjkopQv6gBVDsiC8beFc
wkNqUs25S5Key1MRhdwOyyk9xF8kSOcmFF2BEHXnnJcon9pTdq3EL8wqLMLe
KEakGo575RjxFOUDiyq9LZwNDJtN1eDmyDRbxg5YbgnpWMESIUeTMtNY00n2
/fe3v7W+/4f/uve/f2j9/G99itIjCgKhrfovHB3+e/Sod97/43+M9o31D3e/
7h9G/XNn/fZvurze36AeC2v7F8+gdRT7DqqzD3fsAE6g//vBL2xb+jTVsC/w
/yKFU3YD/1+fwkhf79+r3z9Xr2FeksuhbjrqHnEDjv6B0JAIB9yTdcZ+pFBe
gRIXriFrj1VZCts4oFihsZHDiI/Q6LMOzzSTBu/otU/3ePDkwTQ5gP81GZ7W
9XbNVz6VaYiKyuqZ4yI+HY/dDN8nS66c9ga/JrX2lAmwHi2pGMDptusZhkk5
ZQOEHTzJfDWF4arpIYthZuK07lR2xTHZQlcp7FolDAqgMTvknqi44BeSJYdj
wq7idqOOYHLC9nRb5P+8xTx7G5GWhNoT1lpzKgnKOHt9SX/yYX1Vh+cq5eGL
ktJThNn7U5nCiaAwhn89feC1D50NHNI6rfLf9ICbrXkJkRAyFlv1kdOR2GEH
9neGuQvkeprtOo66kLJz1q5MkKw2iWWjL6vO0Fsrh/vVo69oBDJDNInZJ9Nx
jkrd9MSYmbjEyiahpPILhVNR3uKasQAKdppzbNGhjeoQ5dbEQuZJ8qceRinp
AKQekkUIrGM69FNiMPY7+iX+to8ZtX8MJzYwKDCfaEgMpfwpYl99v3nqXjsN
rMz/1HOeXyVQ103zSev3rLNE/lZmDD7NnJzuwTwOWnutum8ockING/VfSpHq
VGHieW7rMQfN7F3BCgCVslyTPpEudhKECH7VYe8K8bq89q5IGmJKOCkS5LUN
MCYGNAosgqIU5FULE9luaDXEyDDrmaIJdnfl5om9GE16DGyhybnEKPBoz5Jz
+6X535GghSW1r4EFm3ztAmpktzeYL5bHewWq3vEdu0RxZtwmlkVSiyInwYqx
cp1B+6Dwijx5YiOBwkqfsDT53LhI+2LefYMiR43bVHOT0xqI1yORMqdGqYjH
edhZEweu+32L8W44M+Be7KR97b94dQ8fPkx+YDX+crfJOB8aIwSceoX2JX6M
58baNMW/UIDFlgTp277+wFk5mFGxG7Q7KOuJdoGSWQp+Y/RC8lzARF9kCIwQ
Cm9gtmfLmGbUBwbDNWl1nTmDvmPxSbViT+xEBZb3ZWAJsKUc8qaYKU/JxTw3
y7TRmUhNIWsg5A1X4aTZ5Gx18eN9b45cQf3JTON24hBlAUoSjYQ2seIOPXNv
LowSJ0050UtFRLn1/kCKAWIyBepZlltjM6QpS/UOcfym2oV0KrJIY8u+u//k
IUB+vaA0b0Rucc6CnjChJOKQjwSdarIb6M7HdWG9DTnWTmjWnNGUi/0r7gyu
aD5ODtAhf0g7dQz/0d/fHFKqabWoMRhHP9TtWaZglOcSnA/JkWJ9ci1csH/l
zDW+rK++ePdHewFXuD399runnz+Pk4s/nvxAc8Eywwv/I/NXLoq63EzqD/PZ
5KZpNjU+hvFp8uGIzsvPMXmKJmNOXTTTifRarjh27QbLWvaYowQSuEQqgD1X
fI0i+RF2fpec7rIZHAPO8z9hud6zx19TWda/lHPtU2taykr7F8+icZ4OjPM8
+tWzO5gkkNbkB4JekKyL5EVez0sS4HyM33z7zbPPn8OBSwmMdxC6+0Lx4v2X
Bi/MgiqS8rl6XIH8Cq64XcjrI47b9aBtUtBoYxJVR47zFc0xeQhvjy3lKcOf
IFnooEYW5OiZEe9OG/XQiiPI80MR3pRPYZWuiL2D/JFp1sYW48LCDOGlnGIg
8jJpiRgjWdVr2JSTanVj5mIrtARKTKLoV55sKrrA07/km830L818M11nGZpU
nnp7KTd6vOeho2+ePRlU6J/B/z57Nn3yzePpk++6v4x0EV+pOCczUxAXZAcW
bQnJ4X7xFQaMDBQ/g6V85LIuutlvLW8v/EyyKYIcIiZzBYL8MsMahbTaUUX2
MZ/UlZwQ/94nsFKckygaubJGUdGbSyl6dw2YYcZ+gadOUVbxTmt+JH22KDP2
kWuieaMDBjpSPeONXJJz9HaqjsG3LwrvR15RF1kmq5tTltHlvS5nVALII5CS
2soVJkkTwtEn2Wq1XaUhZ+BD3uwsT8Acp5Hew9kIIecbpyRiKAoHyFUNMBx7
jBxzRTNPauso4/Aml8mNAHNojCtUzaCSIra+U06SY03xCsNR0g6PRPAh5EDQ
nbWKgLYHgSwcyjcjRBUyJoXr8HxRWQ+HcCgJXpQg1oLZCWoUvrpC9ItJU+Ub
LrQxARxOf42VDfOuAt8SXP2egDukW1f+9Vvgl+oRBzFdlchcSVOSdAZ4c503
W4NgCllZQqNoqd+mjD4Y+GhevKcMV8wksAQmi04dd+0xUavrm7Qi98yo/+ZI
EpVYbxZ10zSYwOWpYgP+LworKtaVZA+UBjgBOiGz0TwWxYe8wuCim5uIVmel
/VF+c05iOjMucPDH8zdadqsquyvpa5G/ZQOHCrS9GcEIDRblfkTOTK2aEsZk
vrC3zOFANRGTZM6eEa3vcv6ukhAQJUUIXWMuLSTWVZyFZ+xhX/aQRqFqIRst
NceSG6YjgowQQqsDpaVWMhAgQZg5K4CERg/lmJMA2KeIaUbY5INhbd8XuQff
L9EVrzqlaP7HnQ4bVc7Vjoa9h5lUELL1tfTMMq6UCo4UIGTCrINeQrAib09+
uog/xKWU/AenR1lM3SVY/D3YKQegnRpmDJEqLb7IWUngJ3186rveX+L/ILF+
3D3qY13fHj15/PTZ885jtFuPvCr/BdOiJ3pYaN+vY1bpqYluhOJCKDtEnilC
11UdCqZfB2qqBwMQFWMJj7t0yrkoQ3z9DMEgC+iAXRieUK6l15gG0SRcwq1h
Pf4Pjx8/BpOEFANCS2EBynd8bLbmo6divH379XP7vU93VDlIYu5Lndz4hv1e
7vi3zx7hCh7BfCMVee+Rxs8Mu77jp54+gkU+usMTPvhIpJQXrAFotAA1Lras
CVSI2A8C4965dd8+f+xfyUXIq2ySF2S2TzgveXg7W8/j24d2ceCn/ZvX+vGe
Pev7pd+qGKlKHGiqkIfMIJ9u1aZ34YxrrLdJKb8I7m9TVqT5SvHO/hFuMwnd
ACsk/Ki4MJHEDrDRieoowlYnZsgjYKChGjiGO5mnmG1ABRacou9qWWNrTd01
vGQHM4KSIUeHDaYmUxH91i6tGijisMUn3xJhlMvJW8V0Ap1A/LniuN2i+ELL
GUvKOCPL1GaiKynYDvZ1KgRt5YpkUePrXBhGzBjOryVlGjUN+BkyMDENa0mo
cZkgLOxyTV9EwDsZw/I1SIC3bQ3YbxwHNT+uqWfDqUWrhzDgEl0DQZPRLJag
+YnOabVz4u12ioqBEuqrNOIZuL9UDwqN1Fo2txHdkb0XuI4gL8xneHauZX24
Qa0rQdnvkuUO0wICdTtDpyehFErxpfPTOmeaao54KiRF/GFpvnpYrqniM08t
gicgR8PqFDv7XbimA1pr/kEJ0hsUB88PYz5Gnmzv6vFwfX1sbz+ddvVcKtHu
OP9veTUJejcqDaRjyvyc/OY3oLmhwYeVa4tMNSLaAiIS/X4FVMGFaiGtbuou
mZIQq/pRJoI8QWaBJqfpSbTBgX0SeoXPvEe7FLVeuoB87O7+hbi5982jeVNl
hGMbaEteCYYUXW0KfxARs5uPXH9Ueys5U4QDwsmGbAURvbJS0OGhkb87diGx
L5KqXWS1YZEaeM2XnYqSyrkHWa0pSbHeU+TQyhet8TzIaqs60J8t0ywy9Akt
tSUPCPUBq8WAw87fs6bMaczooSVOSDp705PNOWYeLTDhga+qA4qq8ryoUScv
QjIzRIDQgEMDVDPJhnOhT0mRAc1wW+HU0PQd95TT1VJzH/R/BrVUAYSlvaum
vOb1SRVwX/URuk55KH7v8WKhTj80pMgxFE7tK03VZpa5d1yrO8WB4EEf4A3O
4WlyojWFZLASgETjFGGz9z1OHiWNs3YRPEnk6yTY03C3+2WN3XG0GNFZL36G
VIK+Pb5l592nImC9sCEOrF4LvG/uQuPAPibnvtPaQodZ03Yf3BBc2UKAEzhi
1fbH/pq/zFmdx9QzfB/jEyhyEIegPXYQ6oPjkIuu4o95Xi2cYM6hppLdLrV6
kiU7lF4aqC/k1hTRwPBL0ZL5Fa0n6BfMZPMKSyQoZBwFRJsYrUZJ3KuSYXKu
cE82s6d8S6sMSZ2LlDiiKJqvJlzbromVRHtBe40boPFlU3bA8qfHfRY37ZQs
DeaX6YWOhxraobEh7w3yTqm7rUkhD7lkNRegb+sBmEstpCAXPE2hoepkJ08F
4TwLj9AOrQQZvE2IuPSW52HatTe+u58VtMdduu+ZO5yszk/xLHKx7hnTWUHx
M2xWSQJV3w960zEuSq5S/UFvyaeHfGEmNX/zuWtIaVycAhs3wWCIMi3iYjEV
fyrt5Kd55U8NvU+SsEjZAEH0IwYGwQ6Ej9J6FIplZ7v+4NK+lguj10FlxQT0
iE2ItoYzQtPCuXe7KUPC+y0VFdGuhQUROg/ImVyLClv8Yy94YTenjaUqR/d1
VCxMkZobY/7ES2L3HAI7Imwy2iKDpiQpGG3UD67mL4EYwfLjLyf8JT4gbEU2
ajq6vC1VhBA9YK+CcDRpDObtTkq89woC3ipP4kom2aoMNHBQ5f9z8iC0PDlT
kGdsCQDGxYPkwOqjSM5d2dFfHR5hkK3jGjeIw6jImNKD2EIKtIcCjcuhxp0C
eEVvUamBmjBsjouT/b63G4wG64CCTddHJRGkTanlZVJfUkwE84lEFs8Ht/JE
MUTPGUO0u4FI+Por+RFuZRe/BtVQq5tpQ5OS2UoB2W5tW9GC+girEAwZGcSA
0xtV/fB1v5fop8AD11lEtCQMfWGfOcTb66n1PlIzp/+cvAZyl05Uj860o452
9pLKOlm5ZQujQUllgLLad4R5f1nlm+QyXyNanL69nFEoofOTsNDvu9N4A2d+
n6mQZbtvFlvBaQFWQGhBFL8kSCM6MHn1SUlXsZm8w99ckNzKrYnZeefspcGH
kauvMQ3wTYKSQKlYpPEyPAzcgYqaKERBVNumdfoxX2/XWqa32TY6STnGyUWW
ve/MLl2kjEki6qb0reFyQKZrkg+1V8mUMu4/lynVOqaxQ1f11UTEbwQbYhYV
CQzqjWAZN+2toSM66JWKV7CMC/j5O4Ihf0R/v8vmH8Lf6cf4+/SjfX941GcZ
BD9IKo0k2gHtwaPrF3PCJFKBidNcH/FjaBiDkxm5B9AMhMttvkA1zl1X4gnd
vd/PEC5bq8MJvS/K296NloWI3pI1KZVTovOMyAh+QQGqWm9CsNF+Pj99NXlx
fPHjtKtjqQvC6bv5l1UYH6psbnnIjqyEeKxlwmOhfKnyJQnVSzkCRaU4g12A
1H15lGxjbbbVtVMZZUScnXP1Ni1oaY5NmQj078vN6ibL8n2WbcLobJQHjlLH
uCgwLKfvRsOImzMbKI9mFU5VgXY5tGKoUsVTsVM9oQOTDf+aAUG8x/p1Ss2z
ZEl9a9/NIGBvJClKSbvNcnG3txFq+wx3B4tXZ5ROk/appMaUBU9FchH6oJZD
hXoZOfpFg5RKffcFHjb5vuDN7K35PnhIx84JTsB7wgAVcK/cNliHgF9JJGPN
4gdOD9EYvQ+y0YyUe6iezkrvafK1DTsseQveIy5TajWm0mSsWWTUDlb2c9Ic
lzmQ/gvPZR+p+Pm62wMgGD21pEt5QFfGH+/BQfj0MMAgSMYOwgjBZoaK+aiW
XhC6PNCSOGvvQDjzmnw/NKXob+THpoYLIlnNDPJ3dGyMJrcGaF41K7vCKO1B
c+/HvyUTOGySuQ0DVsFo9AO6uYZbvThYAyouoMANJ8xmi7tB7pPL0mKSTkuz
3cJkvBbI4cHZyemh9ix5/vxrtduEHFrF/xqsB1pFA27Gt5LhABLsMyjIhGwp
sAvVEYJpqa1196BD+w4UChdjlMgbeBoQfCRaamK8BdCm1TXtcdrdzcYahMMx
4pc4+3ygnZ5mOrWem7vTvwyLsXSn1lrIvU40hD4uDEKmCmamlf1orcDXGP0t
tmtSn+u+VP44iCy7pNWiwMI3WDeLSUGM0cuuZ3hn5LiNezYi62f3KDaRwVli
q1oKxzDZ1QIWVCw4MZZTkHhBcIG31fApclkDcn8deCzJta1P6Dfso7T3yCeH
QbljKOIbRSAW7kEpLjmDaoBe8ub4Ej/CmGa64vow1gosZUWhPgNja09bK9pm
VZku8FBghA/pSrJvcBi4Yr1slFu5tHoMfE2OPnijXchDvNg3mU/HFx7HqBCS
EUYwrB/xunc2lmHm2JsG6+eQnUUsMEc4fmQcZc4kDEONP4P9InlEGdhpcnH5
yxtOLRMO8vWz7/6AyiInQWOIYdGdDcszHuHyl3dvdAEyxLfffIPJPJqdSsMc
jnugGugtlo5phbeKuchp9gGT+Q4u4qNGDCjBJZIqZkajV4MkQMiC+Zo74XV6
VWFDGWzsdH2DbC6GHlQuaWazbCltCBmKGOC584iJZ8sIfkvjXXQDDhwO7F6I
MjQh81ynG3fgGWLnygmHpRuzwgE4EwYNbHabnGO/XFLCNxtzDFyyJseEqYIv
7XDWFnqgxF/7uwnBwt/RcKrwtecmcTXHEUDmbStJ0XZ99cgeowkj0PJ2U2uR
K0dRddJjBiywrq5t6gxIzO2ZKCbCiafNH8mezNu1cAsMypNTi4O0eq+1TrFX
FhMaqnMUmMaNkg9vYEw0sHXHWmtH6Iq5S0PZe8QpRQ9xrxzGLA8hwNJywPBi
MlTsjGMh46FVxLNuEAwciGWvnNWDDs4qlO0w4hXXgxIC8Ucf3byLWljYbDLs
hlRO8P9283L33CkEASoW2W8fEN5b08V5e1ADRZohU3cuWdn0AtyklPOe6x44
aWbJ0rmAxcZdWpWkPFNxHr5UkihMsoZHK15/OAjJZMYp2lHgLIFU77xnAgcV
M1HUhRqthuSNSwWHCjPorNxMiVdP8H4ciy+jbTnXoIr+SpsbCm2SUCDJrYQZ
DJSyElaGjTqo5Igw6uOYXWjjTw8F+FiRx1HG7JLrMrU3dZ5RDpXXBlysGRwO
rasHwtgX/JWKEBqCB6HKrweKIEZRacghtcqbZqWOXVI9gSyyW+CGAULaJ7sH
kGTX7IXSqNb5b6HaE6ExYUYNNokBvRiUftF+CfcdPYRA4pRjzhCqCAIvA6iu
sAJFTTPBFFmGbCzp5SVw9ykyvr1AldL/GlcdGv0xAAexN5gSZsEFiDjeh9Dq
Gj5Zw/6t9roNCE1Mq7PIc+gojf1cUcyQJBzLHEIoJz9n0krQEAiAOWUMLDRJ
xHfeEClqfivXK5UZmLQtsqj+tFuB77IOJU2d63hC/W449mWUcyih1DbUcA9I
AyfiXeSY2ZIWGdxfzMO7UHRtTMB7meYrPF8B0vMFGPTvTUW3IveJabCLE+rH
RVvjUw3dYYU8U6BgBv7x5K0EZy2SBiN8uJfo5avdMiJcbQUk1rmLJw0vB/5E
S6UjQG7r5IQpx1HbVkl564u1M+QBVoiR+ihDEWwhmeh1aRl/6oyJgOLIJcBM
XNECMO0ir5FwiDdwgwdGzBbcoNBHlmEXJJ3An+noomdrVNWwrKaQZRXFe7UU
Tzusejj0VOBM9YilwQVs8zXZR+ISMAhuunXoeNR3wR5oEDFLizqmaopIAU2R
Iwa9pW4VMdW2Tg1vlrh7EWcoJhvNAc4boTy05z+CcdclORZmliZeC0QLh0r9
PaasGtl4uzwj+6fDXjcmY8m5UZJtJA2iqtMIWeOHKLJFfnLnvKNjnW3h97rn
ONzYJbD2gEwpBvPC9yIfS8wieAQlZdIe5wpKEuMkraRtIXtIsYp44X9N2fHy
HjGqb/Iq+slBTv28UA071Mld54bmL0E6wfRnqFjcCObZlEzqgBaJUc84Edxe
W1YeY8j/vJWzyc0z2FGg8p9Nhs7JGs3iEZMakUUtBboZ34558cFJr3Vs2pZT
cibOqwcXZ7shKAEDteddJo0AH5lq5XLY0iV1/u71vZFX84CyCZNPn5SGYOBJ
2Iu4iRm6KJynj1UUKoqV2AYFhtQAC+QybpNPt9jXEV7fHmu6b8gYDT2XMKkW
mKyLK3TxLFrgFR73OGo07DAt9K/nT598/qxe0ppauqaa3iazo0vnbNkv8SGj
g0TTgsduW9vsU4WGO1uLi8A+RvHuVVZcN4yukK8zDZZRxzZuoEFbHt9NH/7H
rD+dQB6yCQmGQRIChcnvrRc9DtKVVKnWIVDnkEybdIQVYLbSqjTupbV17j2h
OUDPxAVlw7sWPDVx1Wx/LYT1EmhRXV+3PKs530OhWJpOS1GupXEZWDowOSIh
Yp+xmtRF2L3HfALlaPITuiHoJNnPM5+XW+0lvaZ/Kn1gZzE6Vs4L2qRyv7tN
xdwGLfISURvLOTNG9l22lWXJFk1dZ44xR+XjbDzhJKSNmxQnJyTfcZGS+4kB
+UbojmVnzmMr6jRvvNGa2iwu5TekBmD3v7w/D2dAHeU2QcCmNySvFlKnIkki
nHmuPNMaUsq33CzeD2vVBSEXXUovbP7sanDkQ4hzIXmf9ZKgx58t++KrVSdO
TS1RSjKLo3xep/CJrSudXEOoXrMIpNkY3XHsAwOqo0jqAKCGr0IJRRmF/eoi
WyHbSjzpwXbuBC0JOk/Ncyez6Q2ceaF6P+iy31u7YG7Mzbp4awmdd4gFia8y
HVyGx0yi0ITQ/HJL2Xt2zEnVVLZgQzcqZUldRkNfVy9qmq1VGGQQ++qIvidm
u01aa6ttqT9/6eYjdnYuDkj7FbtAb4ky1hhH1fZl0jQVNH+G47kmKUCFhOIZ
dVkB6DfdbpxhR15+1M2jchK69HzbZPEYsg8gCIjshcoYxYa9gOm0lRs0d4M6
R9wU6a/fB4P02KsILiKCGo7HKpA60klkisvwHzKl9+AYYm8IK+dhWuyG5PZv
RG5hcexTLyxPoR16R/8VwaW5Hm4KjMmYlBJyzvoab7rsjat3mA8hfTY1iC/9
1zXu9m1fZzafAYVsmbdUjCrto8UXj7UaVXAdCkIm9Wfcrs7ZylgYWt6yKXwj
AJhulw/bbZ/7uoVT+QTXBpiGbG2o8kbeLjVBwifgJ/hEwkIGH0VyKUptuhCM
CRqC5K9jcHwark4pGjf5QWoJsRyBx22SXdbI0+PkiXoHHPxoU3qSCjOLRxB9
T5MFVP3TlB6rsyvR/b/NYjh626a+mrZaYFMxPJdiTSz+MDVaxXdabeEmveaA
exlOjQgduy0LWqrDGBpEIo2XP8t6J2bbLailukZP5tLD8B7gBsfF7veD994N
73MHau90Oo0r6mMxuIdlxWxjzMKLaDXtoi4RrHa38W8ff1EDz7rPSIrwdPQm
ux2uzdD4g/aYJI7e0/ZC7BqyjktvI8ZugHgLNHerfyviPhL9tMVX5pZdBg4f
YNqXXc+wc6bcrLCTlgDc+K6ORSQ3QlNODjrRMgQ7SreoBRcQ5cn8lGXUFsFX
nbhAQKfA1KkbfgNK31mRoRFYTfWxCtE3s4/c54Z6+lKSr6YfxulbL4L3ILmw
I+g0hr2Xk2E0equADKbOEQBDV+3GKUoLzOCBtkqc2c7QhyK18Z4shHpeE50X
K9e1M2jXrMN10V8M1wreWgV6GLMVDJfaoU2XM26kDrSEVaK5pLnPV2yEKdL8
A5vVgxAkpljB5JZKVNUgRiomCjbav98yvB1Ph60/lFn/8uK8N63YkJ41X5e9
TrSTftL41brkmvsoEydljC/OBSHXn2WT1dJMkUsD5+8JfidiFZxBvuTC6OTT
p3gNE21/Kv37WKex5r9JaurUnJUhdXPjC39GlRUTTHijGFWsCUmtDdmB7Y6P
o5D4J+zO5C7eyOttCtTSEOCDpgi3Q6rqlBW07oUmLkiXO0Y1SFCxB81ppKHH
r+pOsrywgIwzAK4C13vHHy5UsWOrLLdfe7gD2Yaw77dxAgWqWu06dCJ/87D4
5ops61u3GU4AI1Oi2KJTLRBry5yxVFiqd0awItwMuko9Cdpii4dakbTp4QGq
KJBUwXfGLULzwK5JrxcsRrJjVQLiRKJOlcbgBd6NdfsZsOVl3nDROF5tTkdl
s6Yswo2OZ4Ad2eqb4GzCpIam3FhrHLIel5ar1BeVGrPZudhSucq2WpD5E0nb
nnxa6SCr92pQojtQC2akKWa2gnm1wFCAy4S7oYpl5McSQAr49fEWRpvePVmy
Hpk863lWYCN3jzEXb1+w+v55m8/fr6QPML7QG3OhKxah+6IsTKTbb+0RE9ij
3+Rzwul0PcsXArVXCmim+1VmuT6XGvEkHlrXWzI8cS7Wu038CPuqN4iHkIyn
ZITYPlOidOrNPbZZYgYhMu5AZHBGXitY+G7CQFrTbIrVjJmLNztwvSQq/MA3
RLCIbPiJdRa6XLtCF+DP3B6OtUKtPG/BfThhOtwr20K69C0Q1lWkmpxWVVld
9RjDGNXt/y3vufe1Av3r2Swin8rwtOCGL8iEFAAfl8bG0f6MXSA2AYNwxsyq
bBHpf58emh41WW8/gh71s/6SJRhDGfpihritAvVeWzE4dZ+n1Zqt9fSL0ORC
PzksEg7lOiQ1HW2+wi5fHH+KAC269oZzSJzAiCa5DxVQ++buuVueNU1w4grB
Bk7oIjRZX6cbTuBzsxe67ayHYXMDBBSXTGru4bwtOsnVzD+qFToiRw7eUL8O
qxdyT456YHIWaCuEuNutvpeQxdQf5M0tGFHyiQ2Q47CvFx4e2ihq/Mh6xs5X
Y3KMhV4Yzy11P848CaeETxjZpvUIKza2da2huPsFJKU1umYQMF1iBqKG6Ecz
rgF7ED34AJ5gxeaA1FuWHRf/J8G+woX7ES7iKi4aibRivG39yiaqmnlUoaXO
24RT3/g8I62B4NCYpbfbH3MOZCsFV52s1rwi3nWV0S4GPR5eSAjp3NKpcBtT
IEEu/ZS+NjZFCSbWjAay1CmWCu6dzkCKNTv+yl0P0629IwEU4Rmod8Rl+yWe
2RY8zZ78u1nmrXWqOyrZst/Pe8lxIgBBWuJqERV1oYqTKCQuaQ4jG9PkxAbG
vUY/mauxoy0Rnb9C1sGAMSrBYkj+OFOrZXyV3NMI3yn5Jppg6VtdZVQlIjk5
DSeupzUVeZVEais+uBXuWbkcoMS8w0rDPGJcAIMXSM1AeFmlmPp08OmT3KzJ
kj5BcERSOcsN08TAUq0zDnoSW/WKnQaS2pCIFGdOQMFNMuNXDBlO+HBpKm4J
kxWc6KrPcpbIcZBF8RKZQVhKB9U1UCki5kF+eriif3++V0ssfk4cztf4R+WK
vbSAqAw2B0EuioxbSmo5/rSdWX6GGtxgoQZ5gUOL1WF1U5mWVTzhRWKFER/q
rU4W9qF5xCHDqRNMLisB/KGYkqVqSH+AGEGOZ6n7nJSzv1LlnGp1vHf9W4R0
4/I+O6FznYdBIRacqF2qHep7NxtEeQtyLhTTyi0n70Bd7tncdVnkTUC5ZgYk
VS2Sjx2w1HiJofVytBuSlZgSBoebVBqlaYqy1GoZ27e7kSPRp1eoA5VUOWKq
uONM8eIDyTjHch+F8FGHGQRBWUZSzsa1ZIvOTqpSlzd7CcTwZoktUAJkwQAJ
Xn+2SinzgQcg2aL9DWybuD4HOAGOdmJOBhVb9WgUPuzKYFRCyLHx+mKCdDRh
i5ZLODggD8roxueChOvfVxjrKjQOsIxwQh0bD3VD81CpGinLDdELpyeg9ksZ
JE6Y8/bWTFKSyYhqp25rZGmKA02jUNE5yQE5mzb2MOlBcrU2Jhz19XG890mo
0Okex7BehDoRvh7+7wQ0m8zdDeF1voKWrsY6w6ub1+vAUzpHDs+ixCMtq29n
h5IGu7JAXaMxCn5rNQQOEG6qmMGWiScyLwk0wsg+dKuX9gqqT+4UxeukUQkK
FQgUp7JBukdqRXI0Int74iUpEO2QxqAqoqhi/ZQjwLrcu4hr8/dSys/OgHVk
ch6r83rka29hI14Cm3ICk4LjMluBN1HlcREFyGrfBWJJsuAWcQEn/icHOibr
bRrosnMIvz3EdgbO+ksrBKhcSVP2ngec070/FYDCYy2fLycRtDYbRQbav6qV
hlBjBzvBQxHjJmNBaxAqoYNj65QuLBiAXE75+AtQ+zgPhMDqMEw0NxZJ6XX6
mGlxHO1IZyhO5ypPUX28rsgIj7qj9AR3ipQKUPD6Zyn5+QlroEKvr96TA8c8
DqXXlb6fzNN5WcG+b8qC8/lNS9J5iHugZURK4dRs12QTpYoDJzsOxyHQswBZ
VWTaNTBGuLO1SHUmVTiyxBbSIcgQ9tBxsRidfLSO3DkL2uvhQZHmnQcEp81d
lv2YLGQs2iIJkqA8NhmlTrZLHGFoy+arJS3FaTNYij94W9EiQWKwPeNE2Qlc
kq1TRCKIX2e/L6jpFCnpnM+KzRSeTJ8cchxSlAzdnzr/TV1lIicwBCDopt0D
jzcXSVdnG2YyRDVkaWmuhbbgwb0Rx7a0WZXQRHSAA+YeyZfuvtoxwYNrMJ4x
IhPE4Tx0fOWzpuwzQ/8QuxCvLPkl1ujgIUW8WFgoVjI10CRv2kYnQe+6KiKL
TYn4cayMMaYSyVcascVeYecvSVmFH+njTjWVCfvHZdYngppjE59aSFGK5oNn
Qi3X8xiRaScdARgJ0ECq5GbDxtXW2Vq75qW0kaMM5CJysW53kDqavh+fmn0K
YXNTwGWc5WokDBwpRQ8LWIOrBQP40/2gKq6xu5rkUoMzeoBG+O7BeJQXdblM
K/G17AyZ6resKsN1Hzz7AGcHgsm161Tsrp7t5ywJAR3fVJnzGMeeIbbSVWjo
GlhUcF1RH2hNr7ToQuM05UbcB4GTCtKa80S1JsQt3vPacIh7RrEqg66Eoju+
CKchrnvvQ2VDUUVj1PFekYSlGrKc0TnZ/Q6jFpHGSsMSrpPMuc2TSL/f5quG
FUwnmcJPNOtBtPSea/fp4bq+noSkEqnbxUxDacyDAIeYJuExsjjiGO4zKR6Z
46LKEUOSk9mP7CgMHmfCM4UJTpIrmMprsJjQgr86YhHXP8BsR/XbVpJtvFv7
Af/zNuMw36ZFhi7mrK/yFTSoxg0/G/Cx+5ybsdWQCPoMGJCYCchbhsZZUPda
DlUGMLjFnnjWNpFS8wSHlO+stFY3lUZdZyKQDTkEK0C3ZOKwpzjIF1RR2i3B
6kiO2t7mjW1pXvlBp23Inbv3Q9yoNHYmLEo4LZrabnCtg5awvzxBrEkeIFhv
v8bgzqUQMCXGIYQ0O8SBfWUFJT4IatSzx8+wzEjFCEd+ihItZT5yo4G+s2fv
YHCNtM6x2/zyhuEGPnANfNol1xof/KqONyE6fNUt8uuirMia4vtyzg1sdnpf
XPtJ4rCyA3GrmzAD7mtLmoqu1LVT7t66/X59upYTQ/JzKsuXXQVSgmCwa2an
1jJHlrBLbhSYoKUq6o7rWlGvCEtrE223GmOpXbraWYZ0MIFV++7kNiny3pi9
2P2BndlbLjKGI5PsE84MX4JJo2hZwB5RYEiadYjdsyrBWzxBpZgSJ5ZdpVl3
wvICKAoiJ+OCt3fRbu/z96HNOl2CLvUu24DqiA+3V9tU2wAN5iOIRps+9Ib1
H84iNC9P4oqCZTsoJVqlK1X7JJOJtoelpDeDWGwH8+wF5JnGwghgJpQsAgzq
JeKvvwWZgNV1dTlu73jwSDXkNkNkkxoTN1gXcArEOHJwHdxaQQHbZpgtYyE7
J8tRBSflvNwccrMTYuVW2YwyOL5yqBtf0Dkk4SDk8HtZttzjnK4N5gnzDa3o
YTd/+UDWGhK/ZlnH4I19hUAYhBB6f2rAm5dVrEYRYXJ5xc5SpDzfirICqLmT
RO7mqxL36MDnhrRI3zzaN+lqOaEHPCCWqlKHjDZgG83ZiZwebaSLgTR4nayV
Jy9kRxYoKseUzGI84QTb4dTb9eusaO9NzTwT18xGhTQMQ/zSq5fbFeaVYH7J
dXbFOK6ZMH/CEdmu/TFFIp9phEICZF1bRFTmosWslK5ATtjXYIIfDiUKdnlH
axx6SaoK8z2E2ztpAwE7Iu3bt6EzIz8ZgOM7/EPhKKWZxC5kv6OeRwMKyyUA
iCWY49p3Qn9K7TvpDKwnk5B1r+lu2VDmiDDt1cZuTUO2Mgxnaazd/RyY33jg
lb0vNHprIdm3dpiLe6XYOwUCrikwj3RWib+da6fj6u9zPZZetPwAUmcC+UU7
iZcoPAT7BUTPsME7CgkF6pRwX1wAn5Y7Qvs6cjaKOLYPilKxJPARrCknd53U
4hu6NI6AuuK333z97efPnEzzPYuRUetdLkOQ6lw5RSAGh1H3pDmh9ChHPX7O
mvvGohB6cXJyHvmZ6QCL8iXcd1Nc4PQupD88bZzkakp4c0KSA+3H8MQ0MLDs
I1aYB8gKmc3/87/+d2jOo/j6WoCpgOKyp+hv45aBV6iHY/7lpSPQn+vrn9OP
yNn6aOVQlHzljmE/6ixM2Ar9mY5JQwyhqyLJiJtqnNUyNIJAr7YFB0q57702
BUye8/V5URZfNYnuKoKaR82smoCbUxYTihfDGNGWYv6FYBg859o7OqiLLDon
mqDgT3sOSLyxjm8y7qrox/8Ox+JIBB68VonDVjmO3LP9fVRoUxc6jE7V4WH2
k+l/qAN9KH4tq4stC0EH944se4uVERyweZomV/B0A1L66pTdDVdIxlemDUhq
66FHqTFLrTLTtmP7C6DOgD+O7oqrhhRzRpDA0AGCZcCSx+2cbz3Vjvd4m6GS
dwo0HOBpZIcxzgDHj9Qn33JhSQlMXkvRi/ri7XrgKiyVX8g/r1tOkZD/skBE
UXFiOBWbK7fJ/K7NFUqugDquIOqdiL3fEqJQStH2xR6Z/Tsfn1IETXm3k+WA
HbnKzeOjOVRPl+DNYe6dVsK6rpjiif3ehLBD4tStCt0XcRlgqVi3XI06I1Ej
BJaQQNffKR7zbUXNROgaozccFTHyJHrc1KygU1h4L70k0XqvYwumMjXA/RqY
B4I1hMSNUaeT+L5c5MOoiiCXrJ12Vp5mUhM14/uALdPl1qzpuh0dMUM8t2aT
rF309D1YUEMQuUfUWZ7j3rahoeKA3x5XGhC4rTqog1Ne6o3duY+9I/tfxxmf
UUdp047mmaKsWY6QNwDJY4WXB/Nb0ioPZTY6OWoqCtoXIg0WUsKG/qVuJxOK
RjmIUQSZA1lyJXVZVpgmnkQOlgRg25Z3G0e7yVabe15OAkK8oQQseJgjUKW5
LbgdLLoX7mpDSWb/bSousFBn1g4z7ssvdJgghKJJAWPdzwNlw2PxaJEIoTDI
IVc1pYYaItPXYkFz3uDNK3ozhti/6CoaOnPEfDc0iMgdm3Dj4aCvYj2Tlg0R
IjfaR6vchRUlIRadiK72+PdQKwc2Kwy2atZ6IMN+8qKCFFx+VfJtXFJZ09Iy
Y/nkZ2q77pRZq7nOBcCsyUmbZQvrhvtuO4yR7Q4tNIS0gbxZgcmciqfFbXqE
qWs01bkJGu+nWiJLWr2z3CdQ9a6jt+jMUWyIw53D3ksuaSLdUZI8JTlpYQAb
oc4gVGtyHaPtr3mE4noCyTXhAH9aNxNQdL075NND/BQ//Ixyi0t2wtfsKNEw
JTdIbNNTC86HXieVW62Uv6huYBxlIZqjUWDQvn3+5BlaoJycmDyZPjN8tOff
cLsmRQUVhFDfNzKtbc7/PavKybvLy+TgMf6fwxYySeqqzKVbLYecMPMFy6Sx
nIGA3xl6t31pDShH3Kp39f7oqs6CUMzwZo3i0hgCkq5DbmJNOVy0FLtSrl4J
I+HvmgasnKu+dqul+r+zeZRglRX9wt1nGiorMLSXaBqaVWXlzr8Cs/JqAMX5
pc1SaQkj0SDj6D1eFRLXoqWqdx3tPCeSXg2lS+DrJFVk7CcqXjd25qKZsmwJ
HivN0fSCWianChN+RfTmXEzjoANbS1D/vSXeIWkpKFswNSzvzefKFcBa0gUH
z2wwMmK1EE2hPkPK29h5X1xhJdkxOMOSnGqgCHB4jDat0WQ4Uf4Nfna1I1cd
f0zuakTzY9d6ZVs/Nk2OHBWSjomgCgKN1sb6Mmc5Urs//fsEVIXTUscvFP6b
nRW70Tx9hxnO3RW9+tZjHUlWh4emQTJQq8SJSukwKt5I3G2ecQx7lryJ/GsB
7y5k3JCU1ALTXvKnpAMUUDvnXa3ZB86pcW2jkxR/Dm2zeWqxGz5Tk7tWl0c1
8DhtDzhCEr3F2Oz20U5jYsh77ewaFLmo9rg1uRvG5SGjWbtF1VsFmSAJKZyN
dmBiqe4h5N0mnryW2qKA3rad1SjFi8bLvzM6XFJJDB57OYAbQG5Jt4oIEIvz
fPmEHMwKPUMQJm1R6AEdOhelKyWJ2/QLVY26214CQa83JakQIdtd1Wl2bUQq
dCxU56G+JjlZYWOd5EdgRyVvNOEb1J376FfDsiYT1/+eYFdnt7i2lLKRyZZm
XFDO+R/SAeZl+Z7S2ByMqNdXccJwYuhcZoxd1+dqgYUrOfBZSn/PJjANZLHv
s12dHJxf/FQfDgLkYn7PbcoQfTW2DUE2SajwFeZOV1RrYNKWguTvM/yGC2IC
urVBxlqtj4PVlLpXbhQlVfljd8t5YfgozDbqc6hRz7KFKacw09yComYRJEAJ
VcbZ7xqR1X0LXbkZhZPKy5lY63avo+8Yc+2/mfrF4bA2Og5JGReF5veE0iXJ
YzESiJK+kEuHy6eVd6HuL8g1Hph2kTPrOk/T+mPZhlDHu84NHFNuBqU7oioA
/6h2CJF/GF63Mq3pFiy3bp54bH5RblmrHtHSWO03SGLLbeGz1BnJcyQtxEjY
W+5kHSAb3fx1UBN7WFBrrmIXUSN912H+dmoo7RwJh5P+ijxFsauQ9FW2RHsi
310JPuqif/YwjoSZNreMBxME+fWeWH2L8prQq7G110dMAuK44xnsaRAf4o+o
kBNSc7DmWEK0D5M1VBehm46OdWdpr4o5vGS7opBFJcSGHItLlyy/YLTIoh/C
n4QdIyVOopzB20JGAoVw9cWcNA331GEC+RwNzbOgAqum7KOlkN0fyMdzcjTl
MkyZNStaN0OLhA+nWo++lnaxmkrOFrVlarHS29rLsfqcRpttxQaY6DI9pHB8
fqYpyXifKIVwGdui9ahlm9KVxLiLwF4tpbUzGKnoRNPpwE4yk8ejHUma8CLo
C8Gt8FXd8fRRe2cnh19fjPK643DPSc/TbhGc0mo++55LRKulzNjQomwesECI
87MDj3dOU3gDCAM6Jjgr9ufSAS0pGS9TyoimqmiOJN+WCQoMxNTO6iOM7P1I
idsTtFBzLKVBM7LiRkNp4zJ8NLBxudtkk9dc8/BHihofXL7+4yH617bYViXD
QV9olcNE/dw9I2rpA9bPUQer9vSFvjw7uoc5MR4xvuxgB1j2f8y3dQOiq//m
MxXhG0cdn6WUgXPuyibPGMKgBpUI1QzxQmhrG4WGx6xouAGquWJWMiM5Lxn6
onNpUk9x7P95MfDjEfCmNvf3TfHCYlhDMWuJFe+aY3X1iMNXy5b8UDxr5bZo
6qDFkIfnlZ0h6zIeiAQ6kksn6LQiHeWyBAElR6Gkzf1OgsltLqCR4DE86J3j
g1bxyl1k0yPDOsZJU2erJc++tcM0LatT4uoR5Ey2SJdmSzECX+jW428SN6Md
hgzstqaz4BBcVWvesEpnzO+yhbm7pUMQUZ5QVW3lV0qt6mAG0aIoaAVOJ9fS
5oiRjTzbNiqLkk+e3AHsK5O620VgpmtkcFpJ/oh3jRGtVQUD+VZwSUHr7Kgr
za6Y31Rlkf/G3kUedzQPPaFnGei+ednOEK+ldTXRirzKbhhWAAR5e16R10Xf
CnO7QOfEeVrXEj47xBZU+ZJvFBvJVKrAFqwIl1HNwW9Go2VIhDB9hyYdsA4X
Ju5cHUxLZVVAw8ij3osCwx1UuI852xTCmYVo+XJSkgCzmH5yFQi9btUnm6BW
XuuQg1MCqxt66W1n+jZYU1YFwY9PicD6J6SGSBOnW4aiX+wiidjRyvxGrnRE
e8C552JgFgeOybm9wJYCNiscON5xmpj3cyA8r/wpdDP5Ryab/xJMq3/s+0m5
iX5BOL9ywC3613yXmhI5cGzJ1xgPn97oRphv29uIjye3FSddBhgV8061NilE
2UYSrwzocxoA4HKd/nCaj3lqbEo9JkjjneaC7fajjANeR5tubs1+OmG3l0dE
rrMGyKKMgFmlyMNi53Al2vKEBV8TWPVShljZVRV3uOCJ9hHE9Gd4nQfihIEO
XGIdn7y7RLf3IYJyczcNJAM0gKcvrRgpT1iU00rAa2GncM+4qSR3wHINgBCO
rQ44ohSeD1yF8wvimOu+6xx2X7aa0oU4TLj48s3luXV395gdaNz5ZNlHqmgS
bguKuWNuSgNLp9QyoxOOrvbgSRNbSPNV5Pa2zLS+OWM7hvD8QeSCwYeUJNjr
NHy8iyxrNxc1cKsItjHZgrTMG44UyHq4HQDv7qDJQ5rCzGAq28zBmAbGhqRs
S3GapoIHU2mWhELmB7hDF2ttDUzKJL50mrzFp27zeuBHggTtfVNhNzRa1LpK
9GALfiTiq3BqP0iEuqP9Meh9V0eRZcf0Iq1mUAkfpYuFt0BV0au0CWYT+Ztj
3tryJlCBAVpGC3bDGiApOZdGlDB2cXn87hK/5MqzZ08ff/v5M3VhFBWmJ4PO
Wsykzr/NCbJCyHSGsuSj/5q8yW4j0j44bJF6pFJFlO5G0kva3lOOrfDFs4Ko
61J7WG+CXkadQaVCUXu/rUJbWs/4e9Cyg4lLoUXdOHINr1mdzqRXqUAP+pbP
0lBFSqE+eocLH8Tbk5/0FJ784el33LCdirBP3r55c3pyKV9++/TZY4yqt2qx
h12Fno0C58K+qSOvU4a0Jp+thV0oEOaZQ+wN9XKIuLCmNbhsLwL/yBZklXT5
WVtLPpADlaRV9Cq0vYI46KeHONmJmJE9Ltooz5ekjUtPdYwAh9HgrSX4X8aJ
VApQgcOM0hUwPxfJ9jHygZYnf5g+vbPlCS46Gfgv2rHBX/F/f7vj+z9izwVM
6JVB/4u/V67qftyqpB9jCtPbpTwlKucv2F4wUApXYLBiMeBckHbjGzS9JKw3
cp3XUNCGtq5tLzrhDwmN4jYzdzF1aiYAj12urd4CaWvNnb05UdWSvajbYICT
uSy167FiHaXU7HigkZc3VRutzTUwTEKiImVKO2CQx0QZkMbpMBqeU2OonnsC
sz0YOCu5MpdlpEKEMmcJSsQOTOD/PCfX/M9tHEclcA2C9nAr0HmUrkTa7lVM
SaZTsnGHYhXHMI9xhEXX+9JRlKchJwTnCtrk+zgYLzg0GNqDVxV9Q8u0VYzr
zo/8An2G6TCnkTU7ZuMzYdjASEMil2bO9Tn8u6Q5knz7eo+uZpwLmZT6f0JY
TichDpYBxlVLy3bspEiYsHZtgy2il7bD5Nr5dUN87tm9+FzHoKVst0zbDCBJ
d83bPbxmeOdYvnF/cVLcXTCG2PxIt1NcaBriDOGi+baqabuEjJX5bIsAPROG
8xag5CfWHpy0lVmSN8HbxbB9dqp5m8ZUKTYKwKBQSw1mYiQo+l4uco7fx2yE
8zfPCtVo2N0/1mRO/vPwDqlyD8FDsif68+De4kYZ3N5ztvhYuviQqpGvuaVy
iqU0c77BCBmfuDoUfPNoxPlIK/kuTjDTr5Qvjkp9lSaIBlxYegES/aVLmLb7
300yvouSJWqrCx3pmI4vNtLcCA1wrTgLr65YoxXisw2zZB1X0BkK2kjquv7Z
e3e4l+qO+edyv0/ohxERroTI4sde8LyPi8WdA7SJZyVEHBNR7/B7x4kotIci
Q9rY1ZfM/cr7vfpdcJT4VhG2MSdRu8L+QEMUUAwOlh2ZyyaJtOBBj7Lrc1Mw
hhGMSqAMVDQX9H3VTNgVrayv66kzUlJm6xB0afrTL1VP6PJ8kYLCZa2kpoyU
KEl4daWLqSoqEpMr4oxXKgZ7stpHUn7XnZGHw7KW5sqLpReytPW5FQDK1Wp0
1U8YJnOH3+E0JB7pLmIbGHNWLnw7zSAAR+GNY3PPsI5sRlKSxoU6cVKNM7B+
Tgv4OffffMswQLET3+WFDabpO2Qnnx6A55FL7+ywSjf8bCceCzJkKyVPZHDd
6lEqjjj2j5upbtYk+dhUobJOkdWaq6bKZdTtoxaNTDCge9+YGOZFqNbntHEu
SsWjvpZ/l60ISEqVLFE/8uHoG0a2RpLT0Xm39ER3jYMkN0G7MeAdCb4JF+6g
gOuJY6EDJ9ifBlw36hoOsxrlBX3ORReULNCeAM/TBaFavijXpc905/glrjKU
CCTvT4cMHd61mMFX1woar3V4L7kXOfLDkhVUyoLC6sufz+n/IATUOEIIRnCK
7xNO11Mt0drYTeJOGvBGjtvzoW/U6mHTd0JJvlxqAFybnHzYL0ak9CoD1uDK
9TFnIG+oe5fPiFyU8+2aade36gqlkx6k0Lu+fqkxP4XrKoWwqMCJLqn2sLsH
ZVCipCnF2401keguQbO7sWNsGTeLcRdMPIFKyT044pYX1E4FagM9uIYNCm82
ypsAdOjQ0zVDa+cJb9fJNA2TiFWs0BmY9oNHYmcFpvcEP4WvkviiqxcA9G0/
CT6m7it/M0aLEIr9rJPvJGc455Q54nzFezmggGhSA+k+Z4yGtMW3fVeh4U1a
u9IwyQLHLPh0RdQerFr88HhFdm2Aq2vjo40E505rSaihnABuWU85fEA+C7tJ
EP/qes4Ktuowww/W6eaDgVXpedVaykiWwZMSdC18oSSbh0F4V8jpK5WH7V2J
zUxMYZhcVyllMkSNMyXOygW998LHU5Thfaxiqp3kWX6i1NeYGUsuE3fhqnQK
ezo0WQl3Qeqiqp9J5352ZKa4j9DtInwv4CCLc4MgeCgqd40dtag3ZbdqUoF6
GCM1M0BkifyJfzzSdSjDiB8U2BWuTRakcQrgd5ibqRktGSetyURyewRi24UR
zUXcTqhCkf9TzUH4cN131eH69GgygrscuEaLO7R24uzk5/NEX0+5YmS61lK4
berRw4fJeVliRYjbqE8PN/SZhzX/zADXsfbnsmMprKUgc2bX+ODFffkj5m6E
GoRgC5GgFQBlr4QxR9duaXf0FaMkXOP+Dnmv1WYsekSzx7U7IKcMUq80NvaF
9uos4iR9zTSm98zBIkohE+OG6wejZmSYHCxKPR9uwY0/qFNwzx5xlo154RXT
HGeeJg86BPAglHfmBXOklMWSG5Pap9U6pnYnCvMA1XFG7A23tFEYQocuP1ak
xjY1a6oJZdx6wP4I1wlRw9sTr132Ccb1DAOjvzvdPfLjo8Rjn0xrC4dfljuT
eI8kuKIgziQ4NCVeE8p6r4k+WEuYkgVW3Ql4YL3L0LylnBtk0m/qdkg5rO5s
qjKFYbkhpKeo/FpB61JGJtEWEyietKZUb4CkvVEe3CrYeiRuSYysSw/f4S6l
u1etSutzHO6E++lYNpVrspOUc/RxjQWV0c727FzrhaTjQkBske48VGEt/U70
K21m23Lg3n0zuwE0MYQ68ClnWvyo3TZpNhrdDOviZDWYWLXdhKP6kKv0pN9y
tzASkR/amXDOreOzhdhWCVzQQ3yqCkxN1Kpw+pyZkG5cWO6WK7BcjebYwL5L
oOC7SgzC2DE8UGr+tDAVv/jvJXvrryiv0wA2uCnhKtPWhOe2HDcWB/2VfdFb
xB3QEa9esE63uGpNE3U9lLSkF/Q0dhChpxh7/Xs57ieHCJ66pbw4smAVJkaJ
gx/PqfUsesGtR42oZq7UjzwDNJaS+bYwQicClMweKjIRI3/L+GHSplc74WBf
FKyilqwNHZKIHQsqK857d+M79xjWNwjMh8tC68Guo557lB4nyECKDXZp9Skh
JLRyUyZzu5xhwcwiI6KbJqch5ZoKT47wYpyi/lNkuCK8traIbbFZba+vpYiZ
Zq0fzLiR9fdk8OPYIPIFkuvXfPIy1zQsxp1OcdcrkZmoaaO13KAqyukcaQNq
I4EcGeeiB2B3tYO3PvI951bL96XJqypd5GX81ioX/PsGjYlEI9rw9xbIY2VX
QhaA3mcJWVbZX0syujWHNvSxwzTZwFU5Mxh0ZJSovb1akUhCVwnMClgTlW1r
B8rNSEWabZP2sEkBiNcC0tQIbIebQNzd84cvtLcpWnd9jSviIBODtXrlIdf2
EHYJQme0lvYvpFVHDDb2oPdw2n/B9MkNmkuru14pk85Kgt0IDgDj3Twh5gUe
ZSAkjd2DbaphHn52Tpy4FwgQVQFazTpdZL2FzsexpU43z1zR2liJM/RLjb1r
KTDdNxOGtLWERoBKc4jgUgLoMmbs5uQd844qBu8MLuj7EDpE1Kp5o4X3egSS
oY+SEXNtyWEST9LttiROopVAUPOKE9ALfNrZ0r0ydaSu+KLrI5JkMM5Dxs5u
WOzgAEVxfg5glqZlDVpg2YwjZ3nSZtiQ1EV7P2+rpGbussey7TG4vzDm47wS
KBAYk5AZmayZZ5Yht0XJQbu4F0W55eiG/0b8XnIsrNG0stZVn2wFE4D5SVam
Y4VoxO5b/+/mFR3UXts0VgPoe/uOCboIPQVdU0h12GpHh8Hul2BfX1+LX97x
csGLoVeQ9tOqtU/7/AWfevwFn7/E3sdk2MhIj2+8rAbfQj3rhjhY4LSiJFId
UK8Z7pclxTL3VaDuArMSB4ash/wDfm30NjUFGc/VztnJKjeCrj3edSmdYXO7
rxsc+xqoC2l2vZOwCEqRQQqOJqEIO1yhZdqBlmrFinuAWN0bjLwUfxs6V4lb
cEXCFeLZ5wxBoK2y4loF7oB5dTwrMdG779f2kggUddypC+FgAQVm8kZVkpYD
Tao4uJf3qhQginRG4jx1/nfCEWoYWF0wfLTslFGAaiXNgSbNeNbJ9TaF7Wsy
sHvFf0FAFoq5X9zl1GqpGs6LZY3TqGH8XYQbwCKkJRBmXPmO9Y1WUaTJS6rz
kNTe7YYMVT1M8eNaWgvt46dPb06PLycoLCfS8I9qEh8mJ6j7U71ek2Hy/q4k
7bfjxvoKk7K5+864R6Ps1noK+A6XwZAwzDGwubNmJfjeEX9tqIyadbrcYoH1
cL3eYitq9IStEE6GlSw/sG9ZCxPv6zL9UJIZJI1+i0XbogxNrAnmKlc0yRqz
92WHeKZScttupBSEvLkprYyUNHofJB5E2dVIu6H685slt6ol4RVxXJFKKNqK
UDhVd3oWGfBOVA12O47D73PFDHN3/qObsm6wUVpfk+wDRAPiiw7379CpNS6B
GI1rzFYAoxTUxbl4lYmFkT2MNqoAvzR54KpBBRiRQridoSnpAKzYk26OQiEp
tGklNuqjnasVR4FQN5xgCEIeYC4kW4C2mexhrkWntnda+d4wjjcCBKHuSmVh
DBFMei2xyRFfFelVdUeTa44vEBxM0FBKBZ2UPvS56NPUwLZFICOzvtFc4y83
8b6oWY7gBSihXry5aEXt8DG8UAjIu3BoQAch4I22G4K65dkHTRs9JoI6hv8Q
fhmDU4fjDh2mFCNHYN7XaDscXF6+PsTyQd/IWq6+ERvNZMvSu5uRldaWn4Mr
kWlX3MtlimukehTyb+iNCSxJ744v35H3esBYPz0ysKkClEerdWUMX0SvRPx/
20lBg6KHkXsDacW9aYzDtE/KQxtwsxkuTRvkimzbC+tuI4o77D4tDw1FumnR
Agn4KoJyVFVX4zyhUKyFStYToL4tvZO4r9c2uRwaKVYbwdGS/bxRPIS+tk8E
5W3hZbUN05YujSaavDcA5GmWaC9oFxzGsQ+y+cLpgcwsEkMUflBVth2nIVgE
6t2WGhq2EAdVgETHPu1xinC34NBQB2c0d1JpRDfQP4c4rQp9SQ8zv9/7Ext/
hOM7Lio3PJ5X/KywRKEvK2KhmNEowqcMuyvdA3ImhBwpoSrtas4J5622PiaE
5D0Cs/i9Nkgj0E7M+uHEgACqhuri5cu3evNEPHgxJLLhrDBLU0CY3EGM9ziP
1ecfqhxSL+cmCDpDKEF8yph4gNoNdS5RBmdv60ZzpsmF+Ipsyq4ZqbKk6xTv
TLbQKDjdmlZA1uk5CgcD92qRs+8GUxiBvdQ+zBqegDcxpBupTSQw3s6Iyy2S
d1RIcFnlG+Lo8NUgU0JEqGK+2/cTShOtEYUWdVD2OucUUZOlChlyQCarJnqr
aeuwdoVVAjCbC/RR55rKknKTpYWtLuhplDAreNB+czvakL3U4A7SGuHkGbTO
xDtHA9ifYC/RR9j9vBaCVg3EeYaGdaRp8kNWU5fTLjmONbGALQi8R5z0hUY9
AUh26HSYSq2LIK1/yfmi7NxEwE/2e6NpQlm0fss4GYNzCNlLjqGptVRxsree
cok5VDCrynRBYIf0jjAOO5vIzEWOXu0k06f0XnSQMNxFDLVFtqmc5S/37QaB
aoRUFZdbvPObbeMCewI+5JqykMVqHhuc5m2+aG5QMHSkkNAKCwiKPbiOwdz9
RgzScSxue0RrEKniT2qp6qH8ecPx2+RUMUflEyY+trIUvihd0MkRnhGhAcLr
UDf1BEc9YoiQ6qjfitTDU8krr4Y5DgWSQy26oC3ad58/Hzr4mp73qV0UI29e
ktKZAi+ijVdb06u5fhC+vnyZ+luXUOd5O1L6PchWaaLa7e3c8sQNMyh2ebTR
N7RdTB/U7dgQ2THhdyFqGmWwYF+PkgOQuNgD2P6K5Bd7rg/3sRm2EDcsDh1Q
S3tq2mrB+m5R0gMo0PP3mNr1lreLOQm6nvlStTh8uE9wyVFzko7KrlZMmR1d
LGspI7/ThqCIwXxD8XBClMDAOxwNq41kX/DB7uuDIM1lKYPLvBx88cmClJVR
EimlvyTlykokRF1f4WnOsVHmAm/ho9sMHVNAhlxQ/ofHzx9//qzssw5Jzsyi
EJRV/PO4FSeSMvMDlWp6jmaX2+tdVmYvkEbkhrE26EHLNCI6ifKgsfr7rlRp
MARjI1Iho31PvC8ArObqPHKOTBQCCnVfcSVNR+4PwTF0+k1FJwmvScVGaWm4
Clwt2oZrlo0n+6ApNw+Utls5yrFHhJzQPAn9vRSoG1aZpKT77OzeybT9llbi
wxXzDo4w3mi2LDAlhZPTTzRPoACCmybnwT+5JCLgnKJR9DOapLbwbnYbvtlB
L4P9JGUsTHxFg8d/uwckXyLE9zRfzDBquhl2lDnFUKKSieSRLe4wRKdhdhjh
sn8mB4IFs0Jv+oNwK0wVeXDo5h0mvHeeeyY4xNBZ7Qs/F7uF0Z8VWV6xfTik
TrabNG9EU3qWM01wlArskCXe3tAlZcEYTsBhYGrziAxgd352iXV+q/o/94ny
N2kVlXIQO+v5Jc+S9puPm6hXgljYMSNq8RSZZaR0UVxVzbqov+uOUXC0YyhI
KhyqBXbG8ZHgseHIoBGebT0mErp+HbVWArs7hDVryS9wW9z9EV6ON8W+tovx
w67JxA0/9X90r4RgqGIeTrdXjPAQQVdNKV/K5A0111oGZz1wDvLbGVHgKb+Q
njxT+5efAr+7573aRQm9X0EDjtqHkqikAxEAfWkjdEA3lpu3HFrXjbjCiuhP
wT4MNDZQmAY6uxPzEGO1pr9awaUU6LrSON8BT+cCrxSFXF/AdXlm64l84btt
K1CEVB6NEl24GSchDgGtjimdnHNm003epCvzzC1gT6T12AMBjpliSAaYTcUd
uiTCGYqC4nQc8kNGcI/P8Uj+k+tL/5I8l9zeuAM2hXH9WiPrUfGShPfDi/Mi
rrqSWALMMLz8Wfxyqczq+/Y5BoJZogmMp4cJsZqiCGCab1XkhBY20Ftn5SQp
xlozzdyFSchC/vAUJ0lmAvwYlfSPyQv+fhgs4Yg5TUoRAaplyYvw+HFneD7q
joWGXecNHQpPsW52qCrQtlIQX/Zj+GhHnBGspWGJICHUceTGlJ8IHTRMUOC4
eh5oY/9S9x9xElo9GjrS0HtjjadEzUG/50q6on36pPujIb6Jfs2xvoek+nx6
2Mw3n0exznEURMhoZBz1yHPPka98ekvs/Wh0xM7unnR99PuiL70mxG7Tn+I0
dpESlOjAjXdwSL2jqGAlJ0BVuFJrzXPF5rso3iELjvoYcZGYNAAjIwuh+JCf
jQ1ABz7GJjj9CSluKtoDqDUlJjXDGUmuKFFQGNUVmOWUI9ntn6HAFcQ4+5Yg
ZApzG3d7SghgC2Eg4oSOO08r0qJBMjQ3VZZNEIQnKDpxg8FTrxNR5B6Hfin9
JVF99SehYQ10pNyagsplLj0KFyFHTs2wYfR+tmODNUAlWVigjib1xaUE9WiL
JG2NwtehIVekObTSDnDyVGQdFVXjtGnKNteoKnYebaFP7Q0VnhZtDk0WcbJR
iB2m85qyNXAWr88uLk/ftAiYv74yG2SWM/hWoFFx9ODtd7TMxfwK3oKkq52p
aQL48jraDC321+vJL7bWGloCFXdsqo1wdqyCIelKEJbS+sPrRazCPyfHJz/h
q0EH5Jura6VPBm4qJZEp6liESohBVlCeQbnjdDmF8tFM5Kh+pR3P0Cr1BQUG
kOtVAviD6W1uQkVyGugjCsyLGdGO31AnUS3sQNGC8TULuDXdqZn2gI26TdZT
g/VzBH7Mm93VOPhjojeeu9o9xbJHTwcVzqUE00JD91eTitkr3rymLLFwwKW4
cBekorTr1JsQGU2US+TRNHc5A3yPkckNpH+Qbjyc7ILe0OuitBwsebUk3Rhw
rHoDkQZrssJIBfXHDvoIoolnQcST/+kgrlPZieFkPwp9LWAUdLOJ1kt+b4dD
ya13aV3S+sp3s1ev3xy9dTWTtziD5iX2rCE9CQ86r9esArkiKpDYWLZ58vaX
89dnb14xvKGATj55Kg2sVQJdnL55EfiwpSxyZSVZKNr3srftpd1MdojYxXTs
j3rnmAeee1dKE2P4IUlOMXZ8ayX2GyJPKTKBDTh2TUWl9x0w0ZcE/UYciNOY
iDFrO77k5dmbILp62mWz0MIuqhX2pEMrfEf3myzl128vTkk45+t1tsi53TAl
RonrlvLMQv4b0mfYUdf/TJve5VEr3fYqXKZgALZt4ftqf4UWxG+EeERtqwSO
tZE2AJbD5pg/6Q6hWXB/apyeVDhSUhhoBKQg1GeSd6cnp2d/pL1i0Whw/GbK
WudSf8wGPBMd9EoQkMMqRYlRzDRpl65/nbP5pluknQ8CtI/kLvBMJrcekk59
mHIWfBAHW3Z2daE+uTXz4RQ1OwMusje2oNV16xw35EJ6MW2ZPA+IzCanfzx9
QyrRYUsDcHSETzqECnz634RmemIrkT+LhXXdEdb1gLDWlHbX3Nl9G6JFoVac
6XIhm8XbNNsFxH7aCzW4adfOGldw+69yDcjb19pqpYQc5ApycgXYi08Nw344
bLRfkgf7L9kvz6Zkw6JNQvXSbVJycPzD23dMdHqEpJp0z5E+7p+cP5K8lsQL
1D2b0jipIwaSzL7Wm/vJo5Xfk6LSynJkxUl2rzvV8PHAVMN6h6cazuHvMlWw
jwmo5veYxpfD+UFRWIRewBERvySSQvIdIpN6bcSl1Qe4kZGaJr7Ag5K028Us
46hVCA2I5euWDhusnKvjxYKtYRnqHQXa5CPeoF9eDG6PxB2iPVK354DvAKGA
/PkYzCQFFnPKcrfUVV8IImgr1DHMuRoG/AjwmmE/QjyH+/gRrCQEWblDWt5p
FGDAh8COAY4q9LzZhmQHeCHNxsl1mqKLndlY5EaILNnYGSD9JmKfQeuVXZ+B
qOcs/CTg27FQOcjFlQfahXfImdLvYmgfPKrb5MiOocZcsJS3iO1wTcBfYlTD
lFTpukAL6PcN3P1WH9DiCeSFYQOQHSk8hwzLaXLwlnOzUNcY944fA6h1oUWS
g9N3796+Qxo9DEKIvQwEI8IIueqa1bbq8O2S3TTG1ST8Pj3scUTEN8A7InDO
v88RgU8u5H7fyxWBD/xeV4ToYRpmE6BafKxLcvu9Ee37/ju9EcR0/GFHSay+
D3XbhovPwpljOLPIf1YIRrWCPXJNwm5Val9ti7P4s8AAC4MWBuB6tVuMxwj4
AXCZhqqihYZ0jK9qzSmH1RL2cFBN/LukSZQFEgihkbnzcpVeG20C7xYMR03o
Yyt5BZSRvLgAsXdwcXr5F/wX3YRx8uIlPnt2/uG5fPWSrwgOfXryhobnb+Av
+io2dtTOod3GKdNFN2PHds72CC+3GS3SkxU2WYMn5vU3G0X3IFBnrqfI/jnZ
Oe81jPcOd8bWYqZEZ6/KWcNQVQev4uXu1+RbhC4aFW0inldqAKPh1jPLd+1n
3POknZOyXHfqw+7UkvfM5Q5FdCw+tF59OnTKHaxBw5QtrhBLi75531eV/v0r
+DdXpf8DTJU1RYJ3/H3q4n31aX1LV6Wmi+8SvMcj+60V7JEFvq6vT26y+fua
4L5F9YVL+yH6NPhYR9qRr7ztqQHXWh0K0gmObrFdz7Iq+FVy36QKRxtpWxri
jGz6U4LWXKagQUgtZo50W0HRDKJePlBpI386jiifGGHI36aJ2ACBJfuPXrY+
EJYkn7xqfWLkwMktcwxpCaP9O5oS3qXf+65Iv/gdhsY0YS+CJXj0FtQrLp5W
1W+LKE1IRMVVAFp8TdzXcjX1eUocut5WoXCKSzRcJQ2jlBCydcvs2WPpdLel
a/uQM1/cE8lVV4G/oq3gglsqjw1ZhbgLmtPYG0ZtT02//PeZYssy2vvmO2yl
toIa/HCGiconqAS11zbaN5O4u0/f4r2VQMwKsWZYAVnbwDybJSNO5EtPLdI1
jgore8wovAakTXVFbojBEfu6z6a2DCxckrOx+qKq+42Z7vu65s3499o20rRc
taCwm+h+oG0GwkOsz04SdqiU1UwVvceSlouxVlYJCRkIPr0ot9U8C6ietrLA
PVogcHkdIzLAEQc0irahdOdE8wCK0Z3ccbGb1DTB3zEva50cTZApUl+nGkbM
ILlQQPCzPOKrhgxD7iXmOIYER8/9o8JsOYaDrD5spRNj9NXRquEc48CWxd++
UAg73fpCI4KzbT2mAua04KCZVx04Xo1D175K0CvgZZi0vYujclSbwylYxeKR
tbfJ7JuQJs/QXTAVAuHw3dKavegEoS2xw5rk4CwV4VuhBWdZCfJJqB12ljRj
1hJ3unj7l3env1ycHr948W6kKmWJxhOqeod7XQndi77HuRAVPv7rOhf2y6//
WO6GfVpSv6zFAb5MxPab5Jc3vrGSPRFs6L1T+/+lMb+XsL7QvCdO7cDvrIj3
72vz33vK/x/yAvy91vTv4hf4e01+9Hf0FGAq9j1jbtoqr98G7Ck/kFuHPgNL
ZcP3RegejJpgefw9P0GfKifc9rwDRqXfK561qc/JAxlUXBYPQvQk4JuJyiJw
x7Xk+QrXD0m/KHbTQjHKMRUKryQXyU8YesJ1DCd9BeFhURpEc9D3MX6d2wTK
32YLh8CYEnifK08l5YHeZkoev1VU4iYMHL6j/gOInoR1xFK1qFDAggAqOxQi
48adOd+mIygFeEuyQwcVFuxlg0+6k6GDIfkbB9vluNeWIkL2NmEgynMLxdNs
ypD+lcSHu7d7D5n1BhSMY2PcX+bSXVwPLj2Fhjhp3+UocOhWp840U1gH0Tpb
pwXh7ETz3pOX91UdYKQc4perT5DqI05Vl0MwvCr1WvCUDwjA6tAhWLXa9WCi
2zdfP/0as+OlN1ddWoOuUhXLcDcXgqxDA5MCefBgzhCtDw7dVChhMyyYm9FI
CWC6InQATxftifuZBY+OL52kNhiDVyLBUkzu+UWoFaQCTMrlBFOnuKEnEUxM
QHoHSLdp5RlSkhK9lKEA2jU6VDmB4hzH4el/9/Sbx25jGbKSiJ7vZY0l1dtV
FhUWhfT9Dkq/Qe/kirgT0uUYVodCUtxCTeclOay6ULagqEo2fmtZKJKBvM2V
SGOhsN/MEPg1VBolD7FiAtcMpEfGITJI3IDFEf+OKttbCcCuALQjKEI6Il/d
sWTlrm4xdZJRU5RSf8uqkjPkHLNva/AwOFho0qilIFiesBi8JKCX0UIIsZ7I
mjchtW1wtBGgx7Dkom32tFvsWG6RwOKI+2cRrZjWhwujXntubmR1S0yyYiuJ
EGHoAXw9ZqVGebpgkS/88qbJD4GgPUJOkzZbXoLCMegu+YdfKeTx2LFqAzCA
3ZF0YdSAbxGcJ4A6HNBiEERxsehBY8MZHYZ3fc/8o8K7QlQksU7adxy7og0R
fF8HHZFxml+PxtCGxQqci8mCM8JQdjsupWwC6xGMj5Lvw8jSswzaS2SUaaWV
XFhLzHjadVSC1oGkxHVyMTbx6X7oQO9yPtNhpNEzsrAesSYZnJ7q7Z4dxwpZ
a9HWswYvna/hc87K5HSFWRiSEUoDdx30gnOLnt8fCBSdLOJRjvAqgjeFr38n
jqRxSxPgrNIjgdcVP1RWEOy3nODIQZXGTlV1QQZrlzUi2o66rXPo7nT2kZFF
Q1DJ6Z1Fdl3aLWZ0BqlSUoh7zOqPNxB3zylxwTbGLqiLDOTW0jgtzx9B1sjz
x6D1KvzCjPqUZFc6ytr4qAfMrSOK2YElZQHVtiA3Nj4U1j1Ojl+8+MvF5bvT
4595RRZEUSd2Xyji70Cy6R0km9xFsuH2P/BFZA/CuSlRe9oYCRVyPYEjMZRe
0oJPiqr6d+xQHbXa3yGkmrBIlHmMyiJ6sY+Y+OBS1RfPqTLsM++TyLU5VD4F
TRU34iuU89uqVaJ24wqIFwSh37JUbNNIeqnRkn3Ma6yT7J4C7RUuOL6nLIBd
34Se42cEJMbNYSRiSasTRXTeE2rr240vqbXDnRkIvJz9fPr2FyEieA+Z65KO
Lk91giX0+RduIldK9u7jOARciHIYkab2MRSmmH3WVHIwRwRJdvbN56DbELZK
SxSSuk/XTspuu1ZEOis/ZMNeYrcFg+SYHKQCHiv2lBaLRDc2yvM/HDO4fWGw
3H2WYHST2OivKvIstm5VcpCLLwWHGzuvqFpEefGhfM+9tPe6n3tcG4P+ZiFw
CkeI/MmbzkH9XQ5I22CItCQoktZNDLfwTl4eObeZujWVwtXBhfTo+vq1QElp
gnR9/baiJjhXpGQ2pXO2m0JkJm+/D5tfjHL4gQIcoOOXcGr8b+TsyH3aXwQT
XL9/X4k0lqKoWOKEEN1AOcS+2pPghEBwL6u78hxIxFWv3oKzoIpGEUYCUTik
LLTtI3MihpW6llnvTjETZZhyxmbmYJFnHVifeZStto1AMLV1hId+NQ2c+mYH
WNjZTjEdgxwY9+Y4VIF9SgbxcWNT4W3j4/DLcfvLswPWYvC0tg62RIsa7ZHZ
jrz2ONfuvlBR6CWZbcj28Ees1g2902/ZnorO1j7mvEcF6CMzjRGax4g6nH7p
ZomSGi5Uu3bqNq1EjYmh5SRO8fe+X+wt7zdC/u0vQH2zbRZcBlrOKVgbGYrk
hlXnXivi0Rvv4NLpwEPGyVwbMPU7+Ds+8zgy0RuX4JeEjRx3CqO+7IUtQFf8
VZQy2JJMoT5YO3Kp16vfaN93FEoVYlMFgCQ31KZHQM3jWmuUUPjRhbjnsIE9
TQ/0kZdnr355dyo39C8XJz+evvjl9em7qb3SuB03kiMNzaw+wwg0e3FwGx8m
Z8dvjlu4c20cFFRpgE/6yiJ8itHssvkWF9QZog35gs4JrHveNugb1dQmDOfJ
AHM/gOANuYAJF5/vIibk2kcOsCx8K7YYApY93YdCEwAAFdoH8SG24u4swiy5
XCL/kM539Hqr19jbSUicsw5ZRt7mPIa+vXobDlESg0JCy0D0gZU8xYzKBjaX
CIL8iIZLZPAz3IJb4wvAuzEdod7Oar2Ssi+2T62RjZ9ZMhMQqBXG1/qxZv24
TeEQYUxGjCFoeKmvFHmU04YHaG/fUQA55EIPHXIQCoVXztDNFyBQiRZTbOXJ
inELCT3xrQop0cRld9gJBI4gjQGXhGrbbjuq+cHs/EU2f42+GcYV1ndxSrKi
cDIZC8istQ7BHeg26uBMLQbFpKll3IG9aOCiYev1Qj/lvrJhR3s6atzjxN7R
tqEuj/u9TOsGE594lwepM604ZcxtOeP1SV3zcSHboUrd+4JjHg6iNDTik2FU
BiuE7h24gdb+QwqTOZZhcCxyDdn0c2MIPj2qBVuq4drOFX9DZoRpYyjmFI4K
IzUwwALDePJ0aAtM2Jowg7V2+er8tmaKA0Kosz5i4w2S/C29s0JM0xYGqPnU
BdFXac327B7EHWgX0WwL7MH3G90heSWQAsHcahsXs7eVmlG6YVs4BHDIyMmV
9mwwwr3S6c62+aoJla0k5bk9BHsBUgIVk8a/3OfCgUpyLmGnpl7nEvrw9DW9
0ciDg10G3j2Rc1bX6fAuU6dVep8CV6dr7BXPkpuyfrk3qsk+9tQX5QIZBxUI
KHEFjywwOMIeWGCmXyaFpQimoegH1nLCEjWHzoIE/PEcbxdoGtwHW5UD2p8o
IXq55diKjXK6RaqArfulyKnNxI+gmvwG73v6+OnjELAAXjHKi6KUdCUgJUyz
WksrJ0J6x46ScN50L9+ATfPN8+fPnj1PDjBcwYVi+Ol3T75+8u13ycHXr07f
nF6cXRxO23Ol0EkU3n2d5bMi/w1YOiL+wLtJe8elENN78fJVMkleZQhFPXqn
M35JaCs426PkVdk0ywrl2a/56iZbrXXIyXmVwbufPn7yJDl4+dN/T16eJl9/
+/jR88mT+0wMN/CXn5JTxA3Kghg6v9nVlKhzMc+R39dhVifYmC9fRdt2ev7o
3ePnT/7f2q6kt20cCt/zK4zMpS1iW/viTAMESWe6DDJBm8NcSYqKhaaWITl1
NYP+93kLKVHe2ksvgeFY1NPT4+NbyO+Lon/m/k/edG88UMNd3WDllkfGdt/5
Q71eg1W2n8/PhhdmWVGpzP33zfXHd3fX51apcHu4v1h9NlC8EAUiU8PnCmGU
HsBk3kPCBB8/iOZp+r7G7Vt/wmOv9Jf6ArTcgMv7Q1TN8rnB7cdmplYN77lF
Cnvbe2Rfi5OyL/GMUA9nVgyquOGWns0zopLcQCC0pHz7fd0u4eYCFskn3V1M
bgUEa6DxJayH/1achL1pILT5gPLBYjNIs+MlCFyXZdFliYdL3In7FmKtbvKm
05KTXkZ1x94+rcQGQt6U782EnE6ntHTQ1ISIz+5WerDwgP/9dhwbEJfObg+Y
8EdBpXFX3Gvns6i4s9iOOtvb0fVifLhn3v97fhj09uVo59cLB25hbs8CzU3l
7+XBDWFOh/JAB8i2Mg4W5ver731l/WCt2dZlz/qxTcXQ1vZsDWKUd4/yY3x1
HwnxygBw8vlz58UxHlY75f98P3lI7lRSYzaD9LvgTQhkWERMWZxxp13yKQZX
70lKWZqeILQbKurEFN8w42rVDqCdT9RboAPDthtpl1jzaGA0rybvVhBHVMWN
2wdc0LOO+DttZEHT7gCp0O4mJbeOSU3byiYq2OasFFLTMSFFD5C4x2XN2wkw
RKtPH53garxhyKWDCET+dPgMjj0Iwsy6mC4YPiH++eEjZKSqu7qPqVtW0bh7
CtonXTJmxWqAk3O2KeyTovKuyRaGaM1BxoOKP6FgEu5jz9v1B1nMwlA8kM6I
4YDwGkzm15x8YVxJ3HAlkQM2usdo7rq3OV6n3AqiEzUB/AAx7tDDGmIiJ748
fITGSVuP6IAxWCAzXFYSMkwjnJHEsKQi8empYoX5tTmERFDnNr4zVI/GXI6L
cVdvyEHhU7MIuyS5BhUA2SSeyEgYiBPBvY2qjat9qOu/cIsXD2M7LxVhDU5k
dXLZGLD/uD3NKjKSuG/PYdzcEZTPq7l+wogw9H7Gkjk9ob0ZvyOnC6NIz9C5
dsfzwXnXx7eeonS3umyIBdR9LgJyoPV868bIZsDjT6165DAGCsYe5XDdGPmM
7j6sUbTE2Ps7Fo0CCDmK8QyK6Svi+wCvvji75WZQx+6ux1ATbC2997Y03hu+
jhKEN9hJJhCTnTTHWdB2qhzfTSjaLxiPvON0RXQLXyu9RTm0HXjn6gsLm07E
InjYAyue2I1Flo5j78opTb3AxQ4Xp0JjWvESS1G0YdO0PcdFKVATEsVpSGDu
TF6EL1zjp8XZZPJq/2tO3R0vQ9DuuFpTuso1kgsTvsCjT284qPy0rcoNwaT1
Oe9UdlMCJScCuhHf/eCr3TzclGZwkL7KiFtO2jVu8t4tNzGvCQHaXCCxGgS7
9Bcu/eYMZ6ClOJzQ3yA8osIowq+q53ZTo9NCk4R1HRVya7RncqTfl5vNul3M
5wXqAafeDP2WnsH6Oy/c385N5nlFvgyyO07u4MN9Z3SNX9q+zvNmzQ2WUbr5
dpxf2qTuHC89vzQ5vyClTFkrT5VssKaC76UnWnFOWu3st6dlYu3qjt8etTXI
hr4QzwBGUaUmciIHfEvY5YDQuXAi4nPdQMLuaOoRRnmWpCDak2ceYo6AjFf9
BXYiINbQFi37LcR1G5y5VOj86o4o+JtZa367ND+d1c3jvN0uF/4Cgo9FGqZZ
4GWRV2ahirTKozwUmfKUynIZ+nGuA+2LOL2EXB5S09c/I/Dl16qtNq/5Ju1q
vZBSJr4vvUiHcRyFeRGlOgoSnYkiLrxUFbJM4CvvUqzUsm7MlbB6LpI40DrP
fS8KFVyceCLRcerHpQhErALf92E0P1ZXg7EYSRxVbLfbGcplhUQVDBfcd2wf
991mibX3ZfWFWWBoNO7FMvs7WyF9begh+TzF4Evw0BpaTHK6PTApGvCsPzIE
uF48whKzFoXYitWchf2l1hDksVKFH2WqzP1MKZnrIhXwhYyFzpNMZEWgwtQ7
YQ2Hpd4ziQSsKhR5UUQqDgMpEuWVcaCyMg0j5QdxIrwEcmG1bxIKLCbLirRM
yzASns5llsRR7CeFSJXnBSqKikDnMfmU++7h+v4Tu5LrCX7eTdn7qph5/6Lt
VqqqcXEpuQ7zEx4Ci6AuuegRj0Gulmmbd2EAFTFSnzaI8hFE0Jv5miSdGkkp
DfylViFgwvlenhS5H8aBhAksvTzQpQ8696IyzDTM0jhOTljFCdH3TCPKIl/H
uYxDGWRShlmcgq9Ii1DESS619sDHpqWKDniLEHxDWaRgDoUIYj8KpPJFEqa+
zEo/9PJUSQHiXp39D5dDlYYaqAEA
c) Please also review the use of TAPS in the running header (this was
removed form the short title of RFC-to-be 9622). Please let us know
if it should also be changed for this document. Note that it does
appear in the body of this document and we have now expanded it there.
-->
<!--[rfced] Please review any uses of the slash character like the
following and let us know if "and", "or", or "and/or" would be
clearer for the reader.
Original:
...which serves to simplify the local send/receive functions and to
filter the traffic for the specified addresses and ports...
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
In addition, please consider whether "traditional" (Section 4.1.1)
should be updated for clarity. While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
uthor-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
Original:
When trying to connect to a hostname Endpoint
Identifer on a traditional IP network, the implementation should send
all applicable DNS queries.
Note that the resolution in RFC-to-be 9622 was to simily delete
"traditional".
--> -->
</back>
</rfc> </rfc>
 End of changes. 173 change blocks. 
2223 lines changed or deleted 1589 lines changed or added

This html diff was produced by rfcdiff 1.48.