draft-ietf-taps-arch-15.txt   draft-ietf-taps-arch-16.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: 23 April 2023 Google Switzerland GmbH Expires: 10 September 2023 Google Switzerland GmbH
A. Brunstrom A. Brunstrom
Karlstad University Karlstad University
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
C. Perkins C. Perkins
University of Glasgow University of Glasgow
20 October 2022 9 March 2023
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-15 draft-ietf-taps-arch-16
Abstract Abstract
This document describes an architecture for exposing transport This document describes an architecture for exposing transport
protocol features to applications for network communication, a protocol features to applications for network communication, a
Transport Services system. The Transport Services Application Transport Services system. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. This API uses messages for representing data interaction pattern. This API uses messages for representing data
transfer to applications, and describes how implementations can use transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and multiple IP addresses, multiple protocols, and multiple paths, and
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2023. This Internet-Draft will expire on 10 September 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . 5 1.3. Specification of Requirements . . . . . . . . . . . . . . 5
2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Glossary of Key Terms . . . . . . . . . . . . . . . . . . 5
2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 8 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 9
2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 9 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 10
3. API and Implementation Requirements . . . . . . . . . . . . . 10 2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 11
3.1. Provide Common APIs for Common Features . . . . . . . . . 10 3. API and Implementation Requirements . . . . . . . . . . . . . 12
3.2. Allow Access to Specialized Features . . . . . . . . . . 11 3.1. Provide Common APIs for Common Features . . . . . . . . . 13
3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 12 3.2. Allow Access to Specialized Features . . . . . . . . . . 14
3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 13 3.3. Select Between Equivalent Protocol Stacks . . . . . . . . 15
4. Transport Services Architecture and Concepts . . . . . . . . 13 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 16
4.1. Transport Services API Concepts . . . . . . . . . . . . . 15 4. Transport Services Architecture and Concepts . . . . . . . . 16
4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16 4.1. Transport Services API Concepts . . . . . . . . . . . . . 18
4.1.2. Connections and Related Objects . . . . . . . . . . . 16 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 19
4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 18 4.1.2. Connections and Related Objects . . . . . . . . . . . 20
4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 21
4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 22
4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 23
4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 24
4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 24
4.2. Transport Services Implementation . . . . . . . . . . . . 22 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 25
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23 4.2. Transport Services Implementation . . . . . . . . . . . . 25
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 23 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 27
4.2.3. Separating Connection Contexts . . . . . . . . . . . 24 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4.2.3. Separating Connection Contexts . . . . . . . . . . . 28
6. Security and Privacy Considerations . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 6. Security and Privacy Considerations . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Many application programming interfaces (APIs) to perform transport Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and networking have been deployed, perhaps the most widely known and
imitated being the BSD Socket [POSIX] interface (Socket API). The imitated being the BSD Socket [POSIX] interface (Socket API). The
naming of objects and functions across these APIs is not consistent, naming of objects and functions across these APIs is not consistent,
and varies depending on the protocol being used. For example, and varies depending on the protocol being used. For example,
sending and receiving streams of data is conceptually the same for sending and receiving streams of data is conceptually the same for
both an unencrypted Transmission Control Protocol (TCP) stream and both an unencrypted Transmission Control Protocol (TCP) stream and
skipping to change at page 5, line 24 skipping to change at page 5, line 24
to send and receive messages. to send and receive messages.
1.3. Specification of Requirements 1.3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.4. Glossary of Key Terms
This subsection provides a glossary of key terms related to the
Transport Services architecture.
* Application: An entity that uses the transport layer for end-to-
end delivery of data across the network [RFC8095].
* Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used
previously.
* Candidate Path: One path that is available to an application and
conforms to the Selection Properties and System Policy during
racing.
* Candidate Protocol Stack: One Protocol Stack that can be used by
an application for a Connection during racing.
* Client: The peer responsible for initiating a Connection.
* Clone: A Connection that was created from another Connection, and
forms a part of a Connection Group.
* Connection: Shared state of two or more endpoints that persists
across Messages that are transmitted and received between these
Endpoints [RFC8303].
* Connection Group: A set of Connections that shares properties and
caches.
* Connection Property: A Transport Property that controls per-
Connection behavior of a Transport Services implementation.
* Endpoint: An identifier for one side of a Connection (local or
remote), such as a hostnames or URL.
* Equivalent Protocol Stacks: Protocol stacks that can be safely
swapped or raced in parallel during establishment of a Connection.
* Event: A primitive that is invoked by an endpoint [RFC8303].
* Framer: A data translation layer that can be added to a Connection
to define how application-layer Messages are transmitted over a
Protocol Stack.
* Local Endpoint: A representation of the application's identifier
for itself that it uses for a Connection.
* Message: A unit of data that can be transferred between two
Endpoints over a Connection.
* Message Property: A property than can be used to specify details
about Message transmission, or obtain details about the
transmission after receiving a Message.
* Parameter: A value passed between an application and a transport
protocol by a primitive [RFC8303].
* Path: A representation of an available set of properties that a
Local Endpoint can use to communicate with a Remote Endpoint.
* Peer: An endpoint application party to a Connection.
* Preconnection: an object that repesents a Connection that has not
yet been established.
* Preference: A preference to prohibit, avoid, ignore prefer or
require a specific Transport Feature.
* Primitive: A function call that is used to locally communicate
between an application and an endpoint, which is related to one or
more Transport Features [RFC8303].
* Protocol Instance: A single instance of one protocol, including
any state necessary to establish connectivity or send and receive
Messages.
* Protocol Stack: A set of Protocol Instances that are used together
to establish connectivity or send and receive Messages.
* Racing: The attempt to select between multiple Protocol Stacks
based on the Selection and Connection Properties communicated by
the application, along with any security parameters.
* Remote Endpoint: A representation of the application's identifier
for a peer that can participate in establishing a Connection.
* Rendezvous: The action of establishing a peer-to-peer Connection
with a Remote Endpoint.
* Security Parameters: Parameters that define an application's
requirements for authentication and encryption on a Connection.
* Server: The peer responsible for responding to a Connection
initiation.
* Socket: The combination of a destination IP address and a
destination port number [RFC8303].
* System Policy: The input from an operating system or other global
preferences that can constrain or influence how an implementation
will gather Candidate Paths and Protocol Stacks and race the
candidates during establishment of a Connection.
* Selection Property: A Transport Property that can be set to
influence the selection of paths between the Local and Remote
Endpoints.
* Transport Feature: A specific end-to-end feature that the
transport layer provides to an application.
* Transport Property: A property that expresses requirements,
prohibitions and preferences [RFC8095].
* Transport Service: A set of transport features, without an
association to any given framing protocol, that provides a
complete service to an application.
* Transport Service System: The Transport Service implementation and
the Transport Services API
2. API Model 2. API Model
The traditional model of using sockets for networking can be The traditional model of using sockets for networking can be
represented as follows: represented as follows:
* Applications create connections and transfer data using the Socket * Applications create connections and transfer data using the Socket
API. API.
* The Socket API provides the interface to the implementations of * The Socket API provides the interface to the implementations of
TCP and UDP (typically implemented in the system's kernel). TCP and UDP (typically implemented in the system's kernel).
skipping to change at page 8, line 27 skipping to change at page 10, line 45
The Socket API provides a message interface for datagram protocols The Socket API provides a message interface for datagram protocols
like UDP, but provides an unstructured stream abstraction for TCP. like UDP, but provides an unstructured stream abstraction for TCP.
While TCP has the ability to send and receive data as a byte-stream, While TCP has the ability to send and receive data as a byte-stream,
most applications need to interpret structure within this byte- most applications need to interpret structure within this byte-
stream. For example, HTTP/1.1 uses character delimiters to segment stream. For example, HTTP/1.1 uses character delimiters to segment
messages over a byte-stream [RFC9112]; TLS record headers carry a messages over a byte-stream [RFC9112]; TLS record headers carry a
version, content type, and length [RFC8446]; and HTTP/2 uses frames version, content type, and length [RFC8446]; and HTTP/2 uses frames
to segment its headers and bodies [RFC9113]. to segment its headers and bodies [RFC9113].
The Transport Services API represents data as messages, so that it The Transport Services API represents data as messages, so that it
more closely matches the way applications use the network. Providing more closely matches the way applications use the network. A
a message-based abstraction provides many benefits, such as: message-based abstraction provides many benefits, such as:
* providing additional information to the protocol stack;
* the ability to associate deadlines with messages, for applications * the ability to associate deadlines with messages, for applications
that care about timing; that care about timing;
* the ability to control reliability, which messages to retransmit * the ability to control reliability, which messages to retransmit
when there is packet loss, and how best to make use of the data when there is packet loss, and how best to make use of the data
that arrived; that arrived;
* the ability to automatically assign messages and connections to * the ability to automatically assign messages and connections to
underlying transport connections to utilize multi-streaming and underlying transport connections to utilize multi-streaming and
pooled connections. pooled connections.
Allowing applications to interact with messages is backwards- Allowing applications to interact with messages is backwards-
compatible with existing protocols and APIs because it does not compatible with existing protocols and APIs because it does not
change the wire format of any protocol. Instead, it gives the change the wire format of any protocol. Instead, it provides the
protocol stack additional information to allow it to make better use protocol stack with additional information to allow it to make better
of modern transport services, while simplifying the application's use of modern transport services, while simplifying the application's
role in parsing data. For protocols which natively use a streaming role in parsing data. For protocols that natively use a streaming
abstraction, framers (Section 4.1.5) bridge the gap between the two abstraction, framers (Section 4.1.5) bridge the gap between the two
abstractions. abstractions.
2.3. Flexible Implementation 2.3. Flexible Implementation
The Socket API for protocols like TCP is generally limited to The Socket API for protocols like TCP is generally limited to
connecting to a single address over a single interface. It also connecting to a single address over a single interface. It also
presents a single stream to the application. Software layers built presents a single stream to the application. Software layers built
upon this API often propagate this limitation of a single-address upon this API often propagate this limitation of a single-address
single-stream model. The Transport Services architecture is single-stream model. The Transport Services architecture is
skipping to change at page 10, line 39 skipping to change at page 13, line 11
Services APIs and Transport Services implementation to provide this Services APIs and Transport Services implementation to provide this
functionality without causing incompatibility or introducing security functionality without causing incompatibility or introducing security
vulnerabilities. vulnerabilities.
3.1. Provide Common APIs for Common Features 3.1. Provide Common APIs for Common Features
Any functionality that is common across multiple transport protocols Any functionality that is common across multiple transport protocols
SHOULD be made accessible through a unified set of calls using the SHOULD be made accessible through a unified set of calls using the
Transport Services API. As a baseline, any Transport Services API Transport Services API. As a baseline, any Transport Services API
SHOULD allow access to the minimal set of features offered by SHOULD allow access to the minimal set of features offered by
transport protocols [RFC8923]. transport protocols [RFC8923]. If that minimal set is updated or
expanded in the future, the Transport Services API ought to be
extended to match.
An application can specify constraints and preferences for the An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via protocols, features, and network interfaces it will use via
Properties. Properties are used by an application to declare its Properties. Properties are used by an application to declare its
preferences for how the transport service should operate at each preferences for how the transport service should operate at each
stage in the lifetime of a connection. Transport Properties are stage in the lifetime of a connection. Transport Properties are
subdivided into Selection Properties, which specify which paths and subdivided into Selection Properties, which specify which paths and
protocol stacks can be used and are preferred by the application; protocol stacks can be used and are preferred by the application;
Connection Properties, which inform decisions made during connection Connection Properties, which inform decisions made during connection
establishment and fine-tune the established connection; and Message establishment and fine-tune the established connection; and Message
skipping to change at page 12, line 19 skipping to change at page 14, line 38
that provide this feature are eligible to be used, e.g., protocol that provide this feature are eligible to be used, e.g., protocol
stacks that include a multipath protocol or a protocol that supports stacks that include a multipath protocol or a protocol that supports
connection migration. A Transport Services API needs to allow connection migration. A Transport Services API needs to allow
applications to define such requirements and constrain the options applications to define such requirements and constrain the options
available to a Transport Services implementation. Since such options available to a Transport Services implementation. Since such options
are not part of the core/common features, it will generally be simple are not part of the core/common features, it will generally be simple
for an application to modify its set of constraints and change the for an application to modify its set of constraints and change the
set of allowable protocol features without changing the core set of allowable protocol features without changing the core
implementation. implementation.
3.3. Select Equivalent Protocol Stacks To control these specialized features, the application can declare
its preference – whether the presence of a specific feature is
prohibited, should be avoided, can be ignored, is preferred, or is
required in the Pre-Establishment phase. An implementation of a
Transport Services API would honor this preference and allow the
application to query the availability of each specialized feature
after a successful establishment.
A Transport Services implementation can select Protocol Stacks based 3.3. Select Between Equivalent Protocol Stacks
on the Selection and Connection Properties communicated by the
application, along with any security parameters. If two different A Transport Services implementation can attempt and select between
Protocol Stacks can be safely swapped, or raced in parallel (see multiple Protocol Stacks based on the Selection and Connection
Section 4.2.2), then they are considered to be "equivalent". Properties communicated by the application, along with any security
Equivalent Protocol Stacks are defined as stacks that can provide the parameters. The implementation can only attempt to use multiple
same Transport Properties and interface expectations as requested by Protocol Stacks when they are "equivalent", which means that the
the application. stacks can provide the same Transport Properties and interface
expectations as requested by the application. Equivalent Protocol
Stacks can be safely swapped or raced in parallel (see Section 4.2.2)
during connection establishment.
The following two examples show non-equivalent Protocol Stacks: The following two examples show non-equivalent Protocol Stacks:
* If the application requires preservation of message boundaries, a * If the application requires preservation of message boundaries, a
Protocol Stack that runs UDP as the top-level interface to the Protocol Stack that runs UDP as the top-level interface to the
application is not equivalent to a Protocol Stack that runs TCP as application is not equivalent to a Protocol Stack that runs TCP as
the top-level interface. A UDP stack would allow an application the top-level interface. A UDP stack would allow an application
to read out message boundaries based on datagrams sent from the to read out message boundaries based on datagrams sent from the
remote system, whereas TCP does not preserve message boundaries on remote system, whereas TCP does not preserve message boundaries on
its own, but needs a framing protocol on top to determine message its own, but needs a framing protocol on top to determine message
skipping to change at page 15, line 5 skipping to change at page 17, line 40
| +----------v-----+ +-----------------+ | | +----------v-----+ +-----------------+ |
| | Protocol | | | | Protocol | |
+-------------+ Stack(s) +----------------------+ +-------------+ Stack(s) +----------------------+
+-------+--------+ +-------+--------+
V V
Network Layer Interface Network Layer Interface
Figure 3: Concepts and Relationships in the Transport Services Figure 3: Concepts and Relationships in the Transport Services
Architecture Architecture
The Transport Services Implementation includes the Cached State and
System Policy. The System Policy provides input from an operating
system or other global preferences that can constrain or influence
how an implementation will gather Candidate Paths and Protocol Stacks
and race the candidates when establishing a Connection. The Cached
State is the state and history that the implementation keeps for each
set of associated endpoints that have previously been used.
4.1. Transport Services API Concepts 4.1. Transport Services API Concepts
Fundamentally, a Transport Services API needs to provide connection Fundamentally, a Transport Services API needs to provide connection
objects (Section 4.1.2) that allow applications to establish objects (Section 4.1.2) that allow applications to establish
communication, and then send and receive data. These could be communication, and then send and receive data. These could be
exposed as handles or referenced objects, depending on the chosen exposed as handles or referenced objects, depending on the chosen
programming language. programming language.
Beyond the connection objects, there are several high-level groups of Beyond the connection objects, there are several high-level groups of
actions that any Transport Services API needs to provide: actions that any Transport Services API needs to provide:
skipping to change at page 15, line 36 skipping to change at page 18, line 36
* Establishment (Section 4.1.4) focuses on the actions that an * Establishment (Section 4.1.4) focuses on the actions that an
application takes on the connection objects to prepare for data application takes on the connection objects to prepare for data
transfer. transfer.
* Data Transfer (Section 4.1.5) consists of how an application * Data Transfer (Section 4.1.5) consists of how an application
represents the data to be sent and received, the functions represents the data to be sent and received, the functions
required to send and receive that data, and how the application is required to send and receive that data, and how the application is
notified of the status of its data transfer. notified of the status of its data transfer.
* Event Handling (Section 4.1.6) defines categories of notifications * Event Handling (Section 4.1.6) defines categories of notifications
that an application can receive during the lifetime of transport that an application can receive during the lifetime of a
objects. Events also provide opportunities for the application to Connection. Events also provide opportunities for the application
interact with the underlying transport by querying state or to interact with the underlying transport by querying state or
updating maintenance options. updating maintenance options.
* Termination (Section 4.1.7) focuses on the methods by which data * Termination (Section 4.1.7) focuses on the methods by which data
transmission is stopped, and state is torn down in the transport. transmission is stopped, and connection state is torn down.
The diagram below provides a high-level view of the actions and The diagram below provides a high-level view of the actions and
events during the lifetime of a Connection object. Note that some events during the lifetime of a Connection object. Note that some
actions are alternatives (e.g., whether to initiate a connection or actions are alternatives (e.g., whether to initiate a connection or
to listen for incoming connections), while others are optional (e.g., to listen for incoming connections), while others are optional (e.g.,
setting Connection and Message Properties in Pre-Establishment) or setting Connection and Message Properties in Pre-Establishment) or
have been omitted for brevity and simplicity. have been omitted for brevity and simplicity.
Pre-Establishment : Established : Termination Pre-Establishment : Established : Termination
----------------- : ----------- : ----------- ----------------- : ----------- : -----------
skipping to change at page 16, line 27 skipping to change at page 19, line 27
Listen() | : | | : Listen() | : | | :
| : | v : | : | v :
v : | Connection : v : | Connection :
+----------+ : | Ready : +----------+ : | Ready :
| Listener |----------------------+ : | Listener |----------------------+ :
+----------+ Connection Received : +----------+ Connection Received :
: : : :
Figure 4: The lifetime of a Connection object Figure 4: The lifetime of a Connection object
In this diagram, the lifetime of a Connection object is broken into
three phases: Pre-Establishment, the Established state, and
Termination.
Pre-Establishment is based around a Preconnection object, that
contains various sub-objects that describe the properties and
parameters of desired Connections (Local and Remote Endpoints,
Transport Properties, and Security Parameters). A Preconnection can
be used to start listening for inbound connections, in which case a
Listener object is created, or can be used to establish a new
connection directly using Initiate() (for outbound connections) or
Rendezvous() (for peer-to-peer connections).
Once a Connection is in the Established state, an application can
send and receive Message objects, and receive state updates.
Closing or aborting a connection, either locally or from the peer,
can terminate a connection.
4.1.1. Endpoint Objects 4.1.1. Endpoint Objects
* Endpoint: An Endpoint represents an identifier for one side of a * Endpoint: An endpoint represents an identifier for one side of a
transport connection. Endpoints can be Local Endpoints or Remote transport connection. Endpoints can be Local Endpoints or Remote
Endpoints, and respectively represent an identity that the Endpoints, and respectively represent an identity that the
application uses for the source or destination of a connection. application uses for the source or destination of a connection.
An Endpoint can be specified at various levels of abstraction. An An endpoint can be specified at various levels of abstraction. An
Endpoint at a higher level of abstraction (such as a hostname) can endpoint at a higher level of abstraction (such as a hostname) can
be resolved to more concrete identities (such as IP addresses). be resolved to more concrete identities (such as IP addresses).
An endpoint may also represent a multicast group, in which case it An endpoint may also represent a multicast group, in which case it
selects a multicast transport for communication. selects a multicast transport for communication.
* Remote Endpoint: The Remote Endpoint represents the application's * Remote Endpoint: The Remote Endpoint represents the application's
identifier for a peer that can participate in a transport identifier for a peer that can participate in a transport
connection; for example, the combination of a DNS name for the connection; for example, the combination of a DNS name for the
peer and a service name/port. peer and a service name/port.
* Local Endpoint: The Local Endpoint represents the application's * Local Endpoint: The Local Endpoint represents the application's
identifier for itself that it uses for transport connections; for identifier for itself that it uses for transport connections; for
example, a local IP address and port. example, a local IP address and port.
4.1.2. Connections and Related Objects 4.1.2. Connections and Related Objects
* Connection: A Connection object represents one or more active
transport protocol instances that can send and/or receive Messages
between Local and Remote Endpoints. It is an abstraction that
represents the communication. The Connection object holds state
pertaining to the underlying transport protocol instances and any
ongoing data transfers. For example, an active Connection can
represent a connection-oriented protocol such as TCP, or can
represent a fully-specified 5-tuple for a connectionless protocol
such as UDP, where the Connection remains an abstraction at the
endpoints. It can also represent a pool of transport protocol
instances, e.g., a set of TCP and QUIC connections to equivalent
endpoints, or a stream of a multi-streaming transport protocol
instance. Connections can be created from a Preconnection or by a
Listener.
* Preconnection: A Preconnection object is a representation of a * Preconnection: A Preconnection object is a representation of a
Connection that has not yet been established. It has state that Connection that has not yet been established. It has state that
describes parameters of the Connection: the Local Endpoint from describes parameters of the Connection: the Local Endpoint from
which that Connection will be established, the Remote Endpoint which that Connection will be established, the Remote Endpoint
(Section 4.1.3) to which it will connect, and Transport Properties (Section 4.1.3) to which it will connect, and Transport Properties
that influence the paths and protocols a Connection will use. A that influence the paths and protocols a Connection will use. A
Preconnection can be either fully specified (representing a single Preconnection can be either fully specified (representing a single
possible Connection), or it can be partially specified possible Connection), or it can be partially specified
(representing a family of possible Connections). The Local (representing a family of possible Connections). The Local
Endpoint (Section 4.1.3) is required for a Preconnection used to Endpoint (Section 4.1.3) is required for a Preconnection used to
skipping to change at page 17, line 35 skipping to change at page 21, line 22
- Connection Properties (Section 4.1.3): Connection Properties - Connection Properties (Section 4.1.3): Connection Properties
can be specified on a Preconnection and changed on the can be specified on a Preconnection and changed on the
Connection. Connection.
- Message Properties (Section 4.1.5): Message Properties can be - Message Properties (Section 4.1.5): Message Properties can be
specified as defaults on a Preconnection or a Connection, and specified as defaults on a Preconnection or a Connection, and
can also be specified during data transfer to affect specific can also be specified during data transfer to affect specific
Messages. Messages.
* Connection: A Connection object represents one or more active
transport protocol instances that can send and/or receive Messages
between Local and Remote Endpoints. It is an abstraction that
represents the communication. The Connection object holds state
pertaining to the underlying transport protocol instances and any
ongoing data transfers. For example, an active Connection can
represent a connection-oriented protocol such as TCP, or can
represent a fully-specified 5-tuple for a connectionless protocol
such as UDP, where the Connection remains an abstraction at the
endpoints. It can also represent a pool of transport protocol
instances, e.g., a set of TCP and QUIC connections to equivalent
endpoints, or a stream of a multi-streaming transport protocol
instance. Connections can be created from a Preconnection or by a
Listener.
* Listener: A Listener object accepts incoming transport protocol * Listener: A Listener object accepts incoming transport protocol
connections from Remote Endpoints and generates corresponding connections from Remote Endpoints and generates corresponding
Connection objects. It is created from a Preconnection object Connection objects. It is created from a Preconnection object
that specifies the type of incoming Connections it will accept. that specifies the type of incoming Connections it will accept.
4.1.3. Pre-Establishment 4.1.3. Pre-Establishment
* Selection Properties: The Selection Properties consist of the * Selection Properties: The Selection Properties consist of the
properties that an application can set to influence the selection properties that an application can set to influence the selection
of paths between the Local and Remote Endpoints, to influence the of paths between the Local and Remote Endpoints, to influence the
skipping to change at page 19, line 4 skipping to change at page 22, line 19
requirements for authentication and encryption on a Connection. requirements for authentication and encryption on a Connection.
They are used by Transport Security protocols (such as those They are used by Transport Security protocols (such as those
described in [RFC8922]) to establish secure Connections. Examples described in [RFC8922]) to establish secure Connections. Examples
of parameters that can be set include local identities, private of parameters that can be set include local identities, private
keys, supported cryptographic algorithms, and requirements for keys, supported cryptographic algorithms, and requirements for
validating trust of remote identities. Security Parameters are validating trust of remote identities. Security Parameters are
primarily associated with a Preconnection object, but properties primarily associated with a Preconnection object, but properties
related to identities can be associated directly with endpoints. related to identities can be associated directly with endpoints.
4.1.4. Establishment Actions 4.1.4. Establishment Actions
* Initiate: The primary action that an application can take to * Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required create a Connection to a Remote Endpoint, and prepare any required
local or remote state to enable the transmission of Messages. For local or remote state to enable the transmission of Messages. For
some protocols, this will initiate a client-to-server style some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local handshake; for other protocols, this will just establish local
state (e.g., with connectionless protocols such as UDP). The state (e.g., with connectionless protocols such as UDP). The
process of identifying options for connecting, such as resolution process of identifying options for connecting, such as resolution
of the Remote Endpoint, occurs in response to the Initiate call. of the Remote Endpoint, occurs in response to the Initiate call.
* Listen: Enables a listener to accept incoming Connections. The * Listen: Enables a listener to accept incoming connections. The
Listener will then create Connection objects as incoming Listener will then create Connection objects as incoming
connections are accepted (Section 4.1.6). Listeners by default connections are accepted (Section 4.1.6). Listeners by default
register with multiple paths, protocols, and Local Endpoints, register with multiple paths, protocols, and Local Endpoints,
unless constrained by Selection Properties and/or the specified unless constrained by Selection Properties and/or the specified
Local Endpoint(s). Connections can be accepted on any of the Local Endpoint(s). Connections can be accepted on any of the
available paths or endpoints. available paths or endpoints.
* Rendezvous: The action of establishing a peer-to-peer connection * Rendezvous: The action of establishing a peer-to-peer connection
with a Remote Endpoint. It simultaneously attempts to initiate a with a Remote Endpoint. It simultaneously attempts to initiate a
connection to a Remote Endpoint while listening for an incoming connection to a Remote Endpoint while listening for an incoming
skipping to change at page 19, line 47 skipping to change at page 23, line 15
candidates in the style of the ICE algorithm [RFC8445] to perform candidates in the style of the ICE algorithm [RFC8445] to perform
NAT binding discovery and initiate a peer-to-peer connection. NAT binding discovery and initiate a peer-to-peer connection.
4.1.5. Data Transfer Objects and Actions 4.1.5. Data Transfer Objects and Actions
* Message: A Message object is a unit of data that can be * Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two endpoints represented as bytes that can be transferred between two endpoints
over a transport connection. The bytes within a Message are over a transport connection. The bytes within a Message are
assumed to be ordered. If an application does not care about the assumed to be ordered. If an application does not care about the
order in which a peer receives two distinct spans of bytes, those order in which a peer receives two distinct spans of bytes, those
spans of bytes are considered independent Messages. spans of bytes are considered independent Messages. Messages are
sent in the payload of IP packet. One packet can carry one or
more Messages or parts of a Message.
* Message Properties: Message Properties are used to specify details * Message Properties: Message Properties are used to specify details
about Message transmission. They can be specified directly on about Message transmission. They can be specified directly on
individual Messages, or can be set on a Preconnection or individual Messages, or can be set on a Preconnection or
Connection as defaults. These properties might only apply to how Connection as defaults. These properties might only apply to how
a Message is sent (such as how the transport will treat a Message is sent (such as how the transport will treat
prioritization and reliability), but can also include properties prioritization and reliability), but can also include properties
that specific protocols encode and communicate to the Remote that specific protocols encode and communicate to the Remote
Endpoint. When receiving Messages, Message Properties can contain Endpoint. When receiving Messages, Message Properties can contain
information about the received Message, such as metadata generated information about the received Message, such as metadata generated
skipping to change at page 20, line 28 skipping to change at page 23, line 46
application in an Event (Section 4.1.6). application in an Event (Section 4.1.6).
* Receive: An action that indicates that the application is ready to * Receive: An action that indicates that the application is ready to
asynchronously accept a Message over a Connection from a Remote asynchronously accept a Message over a Connection from a Remote
Endpoint, while the Message content itself will be delivered in an Endpoint, while the Message content itself will be delivered in an
Event (Section 4.1.6). The interface to Receive can include Event (Section 4.1.6). The interface to Receive can include
Message Properties specific to the Message that is to be delivered Message Properties specific to the Message that is to be delivered
to the application. to the application.
* Framer: A Framer is a data translation layer that can be added to * Framer: A Framer is a data translation layer that can be added to
a Connection to define how application-layer Messages are a Connection. Framers allow extending a Connection's protocol
transmitted over a transport stack. This is particularly relevant stack to define how to encapsulate or encode outbound Messages,
when using a protocol that otherwise presents unstructured and how to decapsulate or decode inbound data into Messages. In
streams, such as TCP. this way, message boundaries can be preserved when using a
Connection object, even with a protocol that otherwise presents
unstructured streams, such as TCP. This is designed based on the
fact that many of the current application protocols evolved over
TCP, which does not provide message boundary preservation, and
since many of these protocols require message boundaries to
function, each application layer protocol has defined its own
framing. For example, when an HTTP application sends and receives
HTTP messages over a byte-stream transport, it must parse the
boundaries of HTTP messages from the stream of bytes.
4.1.6. Event Handling 4.1.6. Event Handling
The following categories of events can be delivered to an The following categories of events can be delivered to an
application: application:
* Connection Ready: Signals to an application that a given * Connection Ready: Signals to an application that a given
Connection is ready to send and/or receive Messages. If the Connection is ready to send and/or receive Messages. If the
Connection relies on handshakes to establish state between peers, Connection relies on handshakes to establish state between peers,
then it is assumed that these steps have been taken. then it is assumed that these steps have been taken.
skipping to change at page 21, line 20 skipping to change at page 25, line 4
* Message Sent: Notifies the application of the status of its Send * Message Sent: Notifies the application of the status of its Send
action. This might indicate a failure if the Message cannot be action. This might indicate a failure if the Message cannot be
sent, or an indication that the Message has been processed by the sent, or an indication that the Message has been processed by the
Transport Services system. Transport Services system.
* Path Properties Changed: Notifies the application that a property * Path Properties Changed: Notifies the application that a property
of the Connection has changed that might influence how and where of the Connection has changed that might influence how and where
data is sent and/or received. data is sent and/or received.
4.1.7. Termination Actions 4.1.7. Termination Actions
* Close: The action an application takes on a Connection to indicate * Close: The action an application takes on a Connection to indicate
that it no longer intends to send data, is no longer willing to that it no longer intends to send data, is no longer willing to
receive data, and that the protocol should signal this state to receive data, and that the protocol should signal this state to
the Remote Endpoint if the transport protocol allows this. (Note the Remote Endpoint if the transport protocol allows this. (Note
that this is distinct from the concept of "half-closing" a that this is distinct from the concept of "half-closing" a
bidirectional connection, such as when a FIN is sent in one bidirectional connection, such as when a FIN is sent in one
direction of a TCP connection. The end of a stream can also be direction of a TCP connection [RFC9293]. The end of a stream can
indicated using Message Properties when sending.) also be indicated using Message Properties when sending.)
* Abort: The action the application takes on a Connection to * Abort: The action the application takes on a Connection to
indicate a Close and also indicate that a Transport Services indicate a Close and also indicate that a Transport Services
system should not attempt to deliver any outstanding data, and system should not attempt to deliver any outstanding data, and
immediately drop the connection. This is intended for immediate, immediately drop the connection. This is intended for immediate,
usually abnormal, termination of a connection. usually abnormal, termination of a connection.
4.1.8. Connection Groups 4.1.8. Connection Groups
A Connection Group is a set of Connections that shares properties and A Connection Group is a set of Connections that shares Connection
caches. A Connection Group represents state for managing Connections Properties and cached state generated by protocols. A Connection
within a single application, and does not require end-to-end protocol Group represents state for managing Connections within a single
signaling. For multiplexing transport protocols, only Connections application, and does not require end-to-end protocol signaling. For
within the same Connection Group are allowed to be multiplexed multiplexing transport protocols, only Connections within the same
together. Connection Group are allowed to be multiplexed together.
When the API clones an existing Connection, this adds a new The API allows a Connection to be created from another Connection.
Connection to the Connection Group. A change to one of the This adds the new Connection to the Connection Group. A change to
Connection Properties on any Connection in the Connection Group one of the Connection Properties on any Connection in the Connection
automatically changes the Connection Property for all others. All Group automatically changes the Connection Property for all others.
Connections in a Connection Group share the same set of Connection All Connections in a Connection Group share the same set of
Properties except for the Connection Priority. These Connection Connection Properties except for the Connection Priority. These
Properties are said to be entangled. Connection Properties are said to be entangled.
For multiplexing transport protocols, only Connections within the For multiplexing transport protocols, only Connections within the
same Connection Group are allowed to be multiplexed together. same Connection Group are allowed to be multiplexed together.
Passive Connections can also be added to a Connection Group, e.g., Passive Connections can also be added to a Connection Group, e.g.,
when a Listener receives a new Connection that is just a new stream when a Listener receives a new Connection that is just a new stream
of an already active multi-streaming protocol instance. of an already active multi-streaming protocol instance.
While Connection Groups are managed by the Transport Services system, While Connection Groups are managed by the Transport Services system,
an application can define Connection Contexts to control caching an application can define different Connection Contexts for different
boundaries, as discussed in Section 4.2.3. Connection Groups to explicitly control caching boundaries, as
discussed in Section 4.2.3.
4.2. Transport Services Implementation 4.2. Transport Services Implementation
This section defines the key concepts of the Transport Services This section defines the key concepts of the Transport Services
architecture. architecture.
* Transport Service implementation: This consists of all objects and * Transport Service implementation: This consists of all objects and
protocol instances used internally to a system or library to protocol instances used internally to a system or library to
implement the functionality needed to provide a transport service implement the functionality needed to provide a transport service
across a network, as required by the abstract interface. across a network, as required by the abstract interface.
skipping to change at page 23, line 6 skipping to change at page 26, line 37
transport protocol, over IP; or, a multi-path transport protocol transport protocol, over IP; or, a multi-path transport protocol
over multiple transport sub-flows). over multiple transport sub-flows).
* Candidate Path: One path that is available to an application and * Candidate Path: One path that is available to an application and
conforms to the Selection Properties and System Policy, of which conforms to the Selection Properties and System Policy, of which
there can be several. Candidate Paths are identified during the there can be several. Candidate Paths are identified during the
gathering phase (Section 4.2.1) and can be used during the racing gathering phase (Section 4.2.1) and can be used during the racing
phase (Section 4.2.2). phase (Section 4.2.2).
* Candidate Protocol Stack: One Protocol Stack that can be used by * Candidate Protocol Stack: One Protocol Stack that can be used by
an application for a Connection, which there can be several an application for a Connection, for which there can be several
candidates. Candidate Protocol Stacks are identified during the candidates. Candidate Protocol Stacks are identified during the
gathering phase (Section 4.2.1) and are started during the racing gathering phase (Section 4.2.1) and are started during the racing
phase (Section 4.2.2). phase (Section 4.2.2).
* System Policy: Represents the input from an operating system or * System Policy: The input from an operating system or other global
other global preferences that can constrain or influence how an preferences that can constrain or influence how an implementation
implementation will gather candidate paths and Protocol Stacks will gather candidate paths and Protocol Stacks (Section 4.2.1)
(Section 4.2.1) and race the candidates during establishment and race the candidates during establishment (Section 4.2.2).
(Section 4.2.2). Specific aspects of the System Policy either Specific aspects of the System Policy either apply to all
apply to all Connections or only certain ones, depending on the Connections or only certain ones, depending on the runtime context
runtime context and properties of the Connection. and properties of the Connection.
* Cached State: The state and history that the implementation keeps * Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used for each set of associated Endpoints that have been used
previously. This can include DNS results, TLS session state, previously. This can include DNS results, TLS session state,
previous success and quality of transport protocols over certain previous success and quality of transport protocols over certain
paths, as well as other information. paths, as well as other information. This caching does not imply
that the same decisions are necessarily made for subsequent
connections, rather, it means that cached state is used by the
Transport Services architecture to inform functions such as
choosing the candidates to be raced, selecting appropriate
transport parameters, etc. An application SHOULD NOT depend on
specific caching behaviour, instead it ought to explicitly request
any required or desired properties via the Transport Services API.
4.2.1. Candidate Gathering 4.2.1. Candidate Gathering
* Candidate Path Selection: Candidate Path Selection represents the * Candidate Path Selection: Candidate Path Selection represents the
act of choosing one or more paths that are available to use based act of choosing one or more paths that are available to use based
on the Selection Properties and any available Local and Remote on the Selection Properties and any available Local and Remote
Endpoints provided by the application, as well as the policies and Endpoints provided by the application, as well as the policies and
heuristics of a Transport Services implementation. heuristics of a Transport Services implementation.
* Candidate Protocol Selection: Candidate Protocol Selection * Candidate Protocol Selection: Candidate Protocol Selection
skipping to change at page 25, line 46 skipping to change at page 29, line 37
application provides a certificate to only be used as client application provides a certificate to only be used as client
authentication for outbound TLS and QUIC connections, the Transport authentication for outbound TLS and QUIC connections, the Transport
Services system MUST NOT use this automatically in other contexts Services system MUST NOT use this automatically in other contexts
(such as server authentication for inbound connections, or in other (such as server authentication for inbound connections, or in other
another security protocol handshake that is not equivalent to TLS). another security protocol handshake that is not equivalent to TLS).
A Transport Services system must not automatically fall back from A Transport Services system must not automatically fall back from
secure protocols to insecure protocols, or to weaker versions of secure protocols to insecure protocols, or to weaker versions of
secure protocols (see Section 3.3). For example, if an application secure protocols (see Section 3.3). For example, if an application
requests a specific version of TLS, but the desired version of TLS is requests a specific version of TLS, but the desired version of TLS is
not available, its connection will fail. The Transport Services API not available, its connection will fail. As described in
MAY allow applications to specify minimum versions that are allowed Section 3.3, the Transport Services API can allow applications to
to be used by the Transport Services system. specify minimum versions that are allowed to be used by the Transport
Services system.
7. Acknowledgements 7. Acknowledgements
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreements No. 644334 research and innovation programme under grant agreements No. 644334
(NEAT), No. 688421 (MAMI) and No 815178 (5GENESIS). (NEAT), No. 688421 (MAMI) and No 815178 (5GENESIS).
This work has been supported by Leibniz Prize project funds of DFG - This work has been supported by Leibniz Prize project funds of DFG -
German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ
FE 570/4-1). FE 570/4-1).
skipping to change at page 26, line 46 skipping to change at page 30, line 36
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and
M. Welzl, "Implementing Interfaces to Transport Services", M. Welzl, "Implementing Interfaces to Transport Services",
Work in Progress, Internet-Draft, draft-ietf-taps-impl-13, Work in Progress, Internet-Draft, draft-ietf-taps-impl-14,
31 August 2022, <https://datatracker.ietf.org/doc/html/ 20 October 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-taps-impl-13>. draft-ietf-taps-impl-14>.
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
Kühlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly, Kühlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
"An Abstract Application Layer Interface to Transport "An Abstract Application Layer Interface to Transport
Services", Work in Progress, Internet-Draft, draft-ietf- Services", Work in Progress, Internet-Draft, draft-ietf-
taps-interface-17, 27 September 2022, taps-interface-18, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps- <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
interface-17>. interface-18>.
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open -- Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7", group Technical Standard: Base Specifications, Issue 7",
2008. 2008.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/rfc/rfc8095>. <https://www.rfc-editor.org/rfc/rfc8095>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols",
RFC 8303, DOI 10.17487/RFC8303, February 2018,
<https://www.rfc-editor.org/rfc/rfc8303>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/rfc/rfc8305>. <https://www.rfc-editor.org/rfc/rfc8305>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/rfc/rfc8445>. <https://www.rfc-editor.org/rfc/rfc8445>.
 End of changes. 37 change blocks. 
114 lines changed or deleted 302 lines changed or added

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