draft-ietf-taps-arch-11.txt   draft-ietf-taps-arch-12.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: 13 January 2022 Google Switzerland GmbH Expires: 7 July 2022 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
P. Tiesel 3 January 2022
SAP SE
C.A. Wood
Cloudflare
12 July 2021
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-11 draft-ietf-taps-arch-12
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, the protocol features to applications for network communication, a
Transport Services architecture. 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. It uses messages for representing data transfer interaction pattern. This API uses messages for representing data
to applications, and it 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
provide multiple application streams. This document further defines provide multiple application streams. This document further defines
common terminology and concepts to be used in definitions of common terminology and concepts to be used in definitions of a
Transport Services APIs and implementations. Transport Service API and a Transport Services implementation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 13 January 2022.
This Internet-Draft will expire on 7 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Simplified BSD License text extracted from this document must include Revised BSD License text as
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 Simplified 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 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7
2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 8 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 8
2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 9 2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 8
3. API and Implementation Requirements . . . . . . . . . . . . . 9 3. API and Implementation Requirements . . . . . . . . . . . . . 9
3.1. Provide Common APIs for Common Features . . . . . . . . . 10 3.1. Provide Common APIs for Common Features . . . . . . . . . 10
3.2. Allow Access to Specialized Features . . . . . . . . . . 10 3.2. Allow Access to Specialized Features . . . . . . . . . . 11
3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 12
3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 13
4. Transport Services Architecture and Concepts . . . . . . . . 13 4. Transport Services Architecture and Concepts . . . . . . . . 13
4.1. Transport Services API Concepts . . . . . . . . . . . . . 14 4.1. Transport Services API Concepts . . . . . . . . . . . . . 14
4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16
4.1.2. Connections and Related Objects . . . . . . . . . . . 16 4.1.2. Connections and Related Objects . . . . . . . . . . . 16
4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 17 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 18
4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18
4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19
4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20
4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21
4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21
4.2. Transport Services Implementation Concepts . . . . . . . 22 4.2. Transport Services Implementation . . . . . . . . . . . . 22
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 23 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 23
4.2.3. Separating Connection Contexts . . . . . . . . . . . 24 4.2.3. Separating Connection Contexts . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security and Privacy Considerations . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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
operating on an encrypted Transport Layer Security (TLS) [RFC8446] operating on an encrypted Transport Layer Security (TLS) [RFC8446]
stream over TCP, but applications cannot use the same socket "send()" stream over TCP, but applications cannot use the same socket send()
and "recv()" calls on top of both kinds of connections. Similarly, and recv() calls on top of both kinds of connections. Similarly,
terminology for the implementation of transport protocols varies terminology for the implementation of transport protocols varies
based on the context of the protocols themselves: terms such as based on the context of the protocols themselves: terms such as
"flow", "stream", "message", and "connection" can take on many "flow", "stream", "message", and "connection" can take on many
different meanings. This variety can lead to confusion when trying different meanings. This variety can lead to confusion when trying
to understand the similarities and differences between protocols, and to understand the similarities and differences between protocols, and
how applications can use them effectively. how applications can use them effectively.
The goal of the Transport Services architecture is to provide a The goal of the Transport Services architecture is to provide a
common, flexible, and reusable interface for transport protocols. As flexible and reusable architecture that provides a common interface
applications adopt this interface, they will benefit from a wide set for transport protocols. As applications adopt this interface, they
of transport features that can evolve over time, and ensure that the will benefit from a wide set of transport features that can evolve
system providing the interface can optimize its behavior based on the over time, and ensure that the system providing the interface can
application requirements and network conditions, without requiring optimize its behavior based on the application requirements and
changes to the applications. This flexibility enables faster network conditions, without requiring changes to the applications.
deployment of new features and protocols. It can also support This flexibility enables faster deployment of new features and
applications by offering racing and fallback mechanisms, which protocols. It can also support applications by offering racing
otherwise need to be implemented in each application separately. mechanisms (attempting multiple IP addresses, protocols, or network
paths in parallel), which otherwise need to be implemented in each
application separately (see Section 4.2.2).
This document was developed in parallel with the specification of the This document was developed in parallel with the specification of the
Transport Services API [I-D.ietf-taps-interface] and Implementation Transport Services API [I-D.ietf-taps-interface] and implementation
Guidelines [I-D.ietf-taps-impl]. Although following the Transport guidelines [I-D.ietf-taps-impl]. Although following the Transport
Services Architecture does not require that all APIs and Services architecture does not require that all APIs and
implementations are identical, a common minimal set of features implementations are identical, a common minimal set of features
represented in a consistent fashion will enable applications to be represented in a consistent fashion will enable applications to be
easily ported from one system to another. easily ported from one system to another.
1.1. Background 1.1. Background
The Transport Services architecture is based on the survey of The Transport Services architecture is based on the survey of
services provided by IETF transport protocols and congestion control services provided by IETF transport protocols and congestion control
mechanisms [RFC8095], and the distilled minimal set of the features mechanisms [RFC8095], and the distilled minimal set of the features
offered by transport protocols [RFC8923]. These documents identified offered by transport protocols [RFC8923]. These documents identified
skipping to change at page 4, line 41 skipping to change at page 4, line 41
which they were sent. However, this functionality needs to be which they were sent. However, this functionality needs to be
explicitly allowed by the application, since reordering messages explicitly allowed by the application, since reordering messages
would be undesirable in many cases. would be undesirable in many cases.
1.2. Overview 1.2. Overview
This document describes the Transport Services architecture in three This document describes the Transport Services architecture in three
sections: sections:
* Section 2 describes how the API model of Transport Services * Section 2 describes how the API model of Transport Services
differs from traditional socket-based APIs. Specifically, it architecture differs from traditional socket-based APIs.
offers asynchronous event-driven interaction, the use of messages Specifically, it offers asynchronous event-driven interaction, the
for data transfer, and the flexibility to use different transport use of messages for data transfer, and the flexibility to use
protocols and paths without requiring major changes to the different transport protocols and paths without requiring major
application. changes to the application.
* Section 3 explains the fundamental requirements for a Transport * Section 3 explains the fundamental requirements for a Transport
Services API. These principles are intended to make sure that Services system. These principles are intended to make sure that
transport protocols can continue to be enhanced and evolve without transport protocols can continue to be enhanced and evolve without
requiring significant changes by application developers. requiring significant changes by application developers.
* Section 4 presents the Transport Services architecture diagram and * Section 4 presents a diagram showing the Transport Services
defines the concepts that are used by both the API and architecture and defines the concepts that are used by both the
implementation documents. The Preconnection allows applications API [I-D.ietf-taps-interface] and implementation guidelines
to configure Connection Properties, and the Connection represents [I-D.ietf-taps-impl]. The Preconnection allows applications to
an object that can be used to send and receive Messages. configure Connection Properties.
* A Connection is an abstraction that represents the communication. * Section 4 also presents how an abstract Connection is used to
If the transport services interface selects a protocol such as TCP select a transport protocol instance such as TCP, UDP, or another
for the communication, a Connection will correspond to an transport. The Connection represents an object that can be used
underlying protocol connection. If however a protocol such as UDP to send and receive messages.
is selected, the Connection remains an abstraction at the end
points.
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.
2. API Model 2. API Model
skipping to change at page 6, line 25 skipping to change at page 6, line 25
| Kernel Networking Stack | | Kernel Networking Stack |
+---------------------------------+ +---------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Network Layer Interface | | Network Layer Interface |
+-----------------------------------------------------+ +-----------------------------------------------------+
Figure 1: Socket API Model Figure 1: Socket API Model
The Transport Services architecture evolves this general model of The Transport Services architecture evolves this general model of
interaction, aiming to both modernize the API surface presented to interaction, to both modernize the API surface presented to
applications by the transport layer and enrich the capabilities of applications by the transport layer and to enrich the capabilities of
the Transport Services implementation. It combines interfaces for the implementation below the API.
multiple interaction patterns into a unified whole. By combining
name resolution with connection establishment and data transfer in a
single API, it allows for more flexible implementations to provide
path and transport protocol agility on the application's behalf.
+-----------------------------------------------------+ +-----------------------------------------------------+
| Application | | Application |
+-----------------------------------------------------+ +-----------------------------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Transport Services API | | Transport Services API |
+-----------------------------------------------------+ +-----------------------------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
skipping to change at page 7, line 6 skipping to change at page 7, line 6
| (Using: DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) | | (Using: DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Network Layer Interface | | Network Layer Interface |
+-----------------------------------------------------+ +-----------------------------------------------------+
Figure 2: Transport Services API Model Figure 2: Transport Services API Model
The Transport Services API [I-D.ietf-taps-interface] defines the The Transport Services API [I-D.ietf-taps-interface] defines the
mechanism for an application to create network connections and interface for an application to create Connections and transfer data.
transfer data. The implementation [I-D.ietf-taps-impl] is It combines interfaces for multiple interaction patterns into a
responsible for mapping the API to the various available transport unified whole. By combining name resolution with connection
protocols and managing the available network interfaces and paths. establishment and data transfer in a single API, it allows for more
flexible implementations to provide path and transport protocol
agility on the application's behalf.
There are key differences between the architecture of the Transport The Transport Services implementation [I-D.ietf-taps-impl] implements
Services system and the architecture of the Socket API: the Transport the transport layer protocols and other functions needed to send and
Services API is asynchronous and event-driven; it uses messages for receive data. It is is responsible for mapping the API to a specific
representing data transfer to applications; and it describes how available transport protocol stack and managing the available network
implementations can use multiple IP addresses, multiple protocols, interfaces and paths.
multiple paths, and provide multiple application streams.
2.1. Event-Driven API There are key differences between the Transport Services architecture
and the architecture of the Socket API: the API of the Transport
Services architecture is asynchronous and event-driven; it uses
messages for representing data transfer to applications; and it
describes how implementations can use multiple IP addresses, multiple
protocols, multiple paths, and provide multiple application streams.
Originally, sockets presented a blocking interface for establishing 2.1. Event-Driven API
connections and transferring data. However, most modern applications
interact with the network asynchronously. Emulation of an
asynchronous interface using sockets generally uses a try-and-fail
model. If the application wants to read, but data has not yet been
received from the peer, the call to read will fail. The application
then waits and can try again later.
In contrast to sockets, all interaction with a Transport Services Originally, the Socket API presented a blocking interface for
system is expected to be asynchronous, and use an event-driven model establishing connections and transferring data. However, most modern
(see Section 4.1.6). For example, if the application wants to read, applications interact with the network asynchronously. Emulation of
its call to read will not complete immediately, but will deliver an an asynchronous interface using the Socket API generally uses a try-
event containing the received data once it is available. Error and-fail model. If the application wants to read, but data has not
handling is also asynchronous; a failure to send results in an yet been received from the peer, the call to read will fail. The
asynchronous send error as an event. application then waits and can try again later. In contrast to the
Socket API, all interaction using the Transport Services API is
expected to be asynchronous and use an event-driven model (see
Section 4.1.6). For example, an application first issues a call to
receive new data from the connection. When delivered data becomes
available, this data is delivered to the application using
asynchronous events that contain the data. Error handling is also
asynchronous; a failure to send data results in an asynchronous error
event.
The Transport Services API also delivers events regarding the This API also delivers events regarding the lifetime of a connection
lifetime of a connection and changes in the available network links, and changes in the available network links, which were not previously
which were not previously made explicit in sockets. made explicit in the Socket API.
Using asynchronous events allows for a more natural interaction model Using asynchronous events allows for a more natural interaction model
when establishing connections and transferring data. Events in time when establishing connections and transferring data. Events in time
more closely reflect the nature of interactions over networks, as more closely reflect the nature of interactions over networks, as
opposed to how sockets represent network resources as file system opposed to how the Socket API represent network resources as file
objects that may be temporarily unavailable. system objects that may be temporarily unavailable.
Separate from events, callbacks are also provided for asynchronous Separate from events, callbacks are also provided for asynchronous
interactions with the API not directly related to events on the interactions with the API not directly related to events on the
network or network interfaces. network or network interfaces.
2.2. Data Transfer Using Messages 2.2. Data Transfer Using Messages
Sockets provide a message interface for datagram protocols like UDP, The Socket API provides a message interface for datagram protocols
but provide an unstructured stream abstraction for TCP. While TCP like UDP, but provides an unstructured stream abstraction for TCP.
does indeed provide the ability to send and receive data as streams, While TCP has the ability to send and receive data as a byte-stream,
most applications need to interpret structure within these streams. most applications need to interpret structure within this byte-
For example, HTTP/1.1 uses character delimiters to segment messages stream. For example, HTTP/1.1 uses character delimiters to segment
over a stream [RFC7230]; TLS record headers carry a version, content messages over a byte-stream [RFC7230]; TLS record headers carry a
type, and length [RFC8446]; and HTTP/2 uses frames to segment its version, content type, and length [RFC8446]; and HTTP/2 uses frames
headers and bodies [RFC7540]. to segment its headers and bodies [RFC7540].
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. Providing
a message-based abstraction provides many benefits, such as: a message-based abstraction provides many benefits, such as:
* 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 provide control of reliability, choosing which * the ability control reliability, which messages to retransmit when
messages to retransmit when there is packet loss, and how best to there is packet loss, and how best to make use of the data that
make use of the data that arrived; arrived;
* the ability to manage dependencies between messages, when the
Transport Services system could decide to not deliver a message,
either following packet loss or because it has missed a deadline.
In particular, this can avoid (re-)sending data that relies on a
previous transmission that was never received.
* 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 gives the
protocol stack additional information to allow it to make better use protocol stack additional information to allow it to make better use
of modern transport services, while simplifying the application's 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 which 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. Flexibile Implementation 2.3. Flexible Implementation
Sockets, for protocols like TCP, are generally limited to connecting The Socket API for protocols like TCP is generally limited to
to a single address over a single interface. They also present a connecting to a single address over a single interface. It also
single stream to the application. Software layers built upon sockets presents a single stream to the application. Software layers built
often propagate this limitation of a single-address single-stream upon this API often propagate this limitation of a single-address
model. The Transport Services architecture is designed to handle single-stream model. The Transport Services architecture is
multiple candidate endpoints, protocols, and paths; and support designed:
multipath and multistreaming protocols.
Transport Services implementations are meant to be flexible at * to handle multiple candidate endpoints, protocols, and paths;
* to support candidate protocol racing to select the most optimal
stack in each situation;
* to support multipath and multistreaming protocols;
* to provide state caching and application control over it.
A Transport Services implementation is intended to be flexible at
connection establishment time, considering many different options and connection establishment time, considering many different options and
trying to select the most optimal combinations (Section 4.2.1 and trying to select the most optimal combinations by racing them and
Section 4.2.2). This requires applications to provide higher-level measuring the results (see Section 4.2.1 and Section 4.2.2). This
endpoints than IP addresses, such as hostnames and URLs, which are requires applications to provide higher-level endpoints than IP
used by a Transport Services implementation for resolution, path addresses, such as hostnames and URLs, which are used by a Transport
selection, and racing. Transport services implementations can Services implementation for resolution, path selection, and racing.
further implement fallback mechanisms if connection establishment of An implementation can further implement fallback mechanisms if
one protocol fails or performance is detected to be unsatisfactory. connection establishment of one protocol fails or performance is
detected to be unsatisfactory.
Information used in connection establishment (e.g. cryptographic
resumption tokens, information about usability of certain protocols
on the path, results of racing in previous connections) are cached in
the Transport Services implementation. Applications have control
over whether this information is used for a specific establishment,
in order to allow tradeoffs between efficiency and linkability.
Flexibility after connection establishment is also important. Flexibility after connection establishment is also important.
Transport protocols that can migrate between multiple network-layer Transport protocols that can migrate between multiple network-layer
interfaces need to be able to process and react to interface changes. interfaces need to be able to process and react to interface changes.
Protocols that support multiple application-layer streams need to Protocols that support multiple application-layer streams need to
support initiating and receiving new streams using existing support initiating and receiving new streams using existing
connections. connections.
3. API and Implementation Requirements 3. API and Implementation Requirements
The goal of the Transport Services architecture is to redefine the A goal of the Transport Services architecture is to redefine the
interface between applications and transports in a way that allows interface between applications and transports in a way that allows
the transport layer to evolve and improve without fundamentally the transport layer to evolve and improve without fundamentally
changing the contract with the application. This requires a careful changing the contract with the application. This requires a careful
consideration of how to expose the capabilities of protocols. consideration of how to expose the capabilities of protocols. This
architecture also encompasses system policies that can influence and
inform how transport protocols use a network path or interface.
There are several degrees in which a Transport Services system is There are several ways the Transport Services system can offer
intended to offer flexibility to an application: it can provide flexibility to an application: it can provide access to transport
access to multiple sets of protocols and protocol features; it can protocols and protocol features; it can use these protocols across
use these protocols across multiple paths that could have different multiple paths that could have different performance and functional
performance and functional characteristics; and it can communicate characteristics; and it can communicate with different remote systems
with different remote systems to optimize performance, robustness to to optimize performance, robustness to failure, or some other metric.
failure, or some other metric. Beyond these, if the API for the Beyond these, if the Transport Services API remains the same over
system remains the same over time, new protocols and features can be time, new protocols and features can be added to the Transport
added to the system's implementation without requiring changes in Services implementation without requiring changes in applications for
applications for adoption. adoption. Similarly, this can provide a common basis for utilizing
information about a network path or interface, enabling evolution
below the transport layer.
The normative requirements described here allow Transport Services The normative requirements described in this section allow Transport
APIs and Implementations to provide this functionality without Services APIs and Transport Services implementation to provide this
causing incompatibility or introducing security vulnerabilities. The functionality without causing incompatibility or introducing security
rest of this document describes the architecture non-normatively. 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 Transport Services SHOULD be made accessible through a unified set of calls using the
API calls. As a baseline, any Transport Services API MUST allow Transport Services API. As a baseline, any Transport Services API
access to the minimal set of features offered by transport protocols SHOULD allow access to the minimal set of features offered by
[RFC8923]. transport protocols [RFC8923].
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. A Transport Services API SHOULD offer Properties that Properties. Properties are used by an application to declare its
are common to multiple transport protocols, which enables the system preferences for how the transport service should operate at each
to appropriately select between protocols that offer equivalent stage in the lifetime of a connection. Transport Properties are
features. Similarly, a Transport Services API SHOULD offer subdivided into Selection Properties, which specify which paths and
Properties that are applicable to a variety of network layer protocol stacks can be used and are preferred by the application;
interfaces and paths, which permits racing of different network paths Connection Properties, which inform decisions made during connection
without affecting the applications using the system. Each Property establishment and fine-tune the established connection; and Message
is expected to have a default value. Properties, set on individual Messages.
The default values for Properties SHOULD be selected to ensure It is RECOMMENDED that the Transport Services API offers properties
correctness for the widest set of applications, while providing the that are common to multiple transport protocols. This enables a
widest set of options for selection. For example, since both Transport Services implementation to appropriately select between
applications that require reliability and those that do not require protocols that offer equivalent features. Similarly, it is
reliability can function correctly when a protocol provides RECOMMENDED that the Properties offered by the Transport Services API
reliability, reliability ought to be enabled by default. As another are applicable to a variety of network layer interfaces and paths,
example, the default value for a Property regarding the selection of which permits racing of different network paths without affecting the
network interfaces ought to permit as many interfaces as possible. applications using the API. Each is expected to have a default
value.
Applications using a Transport Services system interface are REQUIRED It is RECOMMENDED that the default values for Properties are selected
to be robust to the automated selection provided by the system, where to ensure correctness for the widest set of applications, while
the automated selection is constrained by the requirements and providing the widest set of options for selection. For example,
preferences expressed by the application. since both applications that require reliability and those that do
not require reliability can function correctly when a protocol
provides reliability, reliability ought to be enabled by default. As
another example, the default value for a Property regarding the
selection of network interfaces ought to permit as many interfaces as
possible.
Applications using the Transport Services API are REQUIRED to be
robust to the automated selection provided by the Transport Services
implementation. This automated selection is constrained by the
properties and preferences expressed by the application and requires
applications to explictly set properties that define any necssary
constraints on protocol, path, and interface selection.
3.2. Allow Access to Specialized Features 3.2. Allow Access to Specialized Features
There are applications that will need to control fine-grained details There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure of transport protocols to optimize their behavior and ensure
compatibility with remote systems. A Transport Services system compatibility with remote systems. It is therefore RECOMMENDED that
therefore SHOULD permit more specialized protocol features to be the Transport Services API and the Transport Services implementation
used. permit more specialized protocol features to be used.
A specialized feature could be required by an application only when A specialized feature could be needed by an application only when
using a specific protocol, and not when using others. For example, using a specific protocol, and not when using others. For example,
if an application is using TCP, it could require control over the if an application is using TCP, it could require control over the
User Timeout Option for TCP; these options would not take effect for User Timeout Option for TCP; these options would not take effect for
other transport protocols. In such cases, the API ought to expose other transport protocols. In such cases, the API ought to expose
the features in such a way that they take effect when a particular the features in such a way that they take effect when a particular
protocol is selected, but do not imply that only that protocol could protocol is selected, but do not imply that only that protocol could
be used. For example, if the API allows an application to specify a be used. For example, if the API allows an application to specify a
preference to use the User Timeout Option, communication would not preference to use the User Timeout Option, communication would not
fail when a protocol such as QUIC is selected. fail when a protocol such as QUIC is selected.
Other specialized features, however, can be strictly required by an Other specialized features, however, can be strictly required by an
application and thus constrain the set of protocols that can be used. application and thus constrain the set of protocols that can be used.
For example, if an application requires support for automatic For example, if an application requires support for automatic
handover or failover for a connection, only protocol stacks that handover or failover for a connection, only protocol stacks that
provide this feature are eligible to be used, e.g., protocol stacks provide this feature are eligible to be used, e.g., protocol stacks
that include a multipath protocol or a protocol that supports 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 system's applications to define such requirements and constrain the options
options. Since such options are not part of the core/common available to a Transport Services implementation. Since such options
features, it will generally be simple for an application to modify are not part of the core/common features, it will generally be simple
its set of constraints and change the set of allowable protocol for an application to modify its set of constraints and change the
features without changing the core implementation. set of allowable protocol features without changing the core
implementation.
3.3. Select Equivalent Protocol Stacks 3.3. Select Equivalent Protocol Stacks
A Transport Services implementation can select Protocol Stacks based A Transport Services implementation can select Protocol Stacks based
on the Properties communicated by the application. If two different on the Selection and Connection Properties communicated by the
application, along with any security parameters. If two different
Protocol Stacks can be safely swapped, or raced in parallel (see Protocol Stacks can be safely swapped, or raced in parallel (see
Section 4.2.2), then they are considered to be "equivalent". Section 4.2.2), then they are considered to be "equivalent".
Equivalent Protocol Stacks are defined as stacks that can provide the Equivalent Protocol Stacks are defined as stacks that can provide the
same transport properties and interface expectations as requested by same Transport Properties and interface expectations as requested by
the application. the application.
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
skipping to change at page 12, line 17 skipping to change at page 12, line 39
reliability layer on top would not be allowed to replace a reliability layer on top would not be allowed to replace a
Protocol Stack using TCP. Protocol Stack using TCP.
The following example shows equivalent Protocol Stacks: The following example shows equivalent Protocol Stacks:
* If the application does not require reliable transmission of data, * If the application does not require reliable transmission of data,
then a Protocol Stack that adds reliability could be regarded as then a Protocol Stack that adds reliability could be regarded as
an equivalent Protocol Stack as long as providing this would not an equivalent Protocol Stack as long as providing this would not
conflict with any other application-requested properties. conflict with any other application-requested properties.
To ensure that security protocols are not incorrectly swapped, To ensure that security protocols are not incorrectly swapped, a
Transport Services systems MUST only select Protocol Stacks that meet Transport Services implementation MUST only select Protocol Stacks
application requirements ([RFC8922]). Systems SHOULD only race that meet application requirements ([RFC8922]). A Transport Services
Protocol Stacks where the transport security protocols within the implementation SHOULD only race Protocol Stacks where the transport
stacks are identical. Transport Services systems MUST NOT security protocols within the stacks are identical. A Transport
automatically fall back from secure protocols to insecure protocols, Services implementation MUST NOT automatically fall back from secure
or to weaker versions of secure protocols. A Transport Services protocols to insecure protocols, or to weaker versions of secure
system MAY allow applications to explicitly specify that fallback to protocols. A Transport Services implementation MAY allow
a specific other version of a protocol is allowed, e.g., to allow applications to explicitly specify that fallback to a specific other
fallback to TLS 1.2 if TLS 1.3 is not available. version of a protocol \, e.g., to allow fallback to TLS 1.2 if TLS
1.3 is not available.
3.4. Maintain Interoperability 3.4. Maintain Interoperability
It is important to note that neither the Transport Services API It is important to note that neither the Transport Services API
[I-D.ietf-taps-interface] nor the Implementation document [I-D.ietf-taps-interface] nor the guidelines for the Transport
[I-D.ietf-taps-impl] define new protocols or protocol capabilities Service implementation [I-D.ietf-taps-impl] define new protocols or
that affect what is communicated across the network. Use of a protocol capabilities that affect what is communicated across the
Transport Services system MUST NOT require that a peer on the other network. A Transport Services system MUST NOT require that a peer on
side of a connection uses the same API or implementation. A the other side of a connection uses the same API or implementation.
Transport Services system acting as a connection initiator is able to A Transport Services implementation acting as a connection initiator
communicate with any existing system that implements the transport is able to communicate with any existing endpoint that implements the
protocol(s) and all the required properties selected by the Transport transport protocol(s) and all the required properties selected.
Services system. Similarly, a Transport Services system acting as a Similarly, a Transport Services implementation acting as a listener
listener can receive connections for any protocol that is supported can receive connections for any protocol that is supported from an
by the system from existing initiators that implement the protocol, existing initiator that implements the protocol, independent of
independent of whether the initiator uses a Transport Services system whether the initiator uses the Transport Services architecture or
or not. not.
In normal use, a Transport Services system SHOULD result in A Transport Services system makes decisions that select protocols and
consistent protocol and interface selection decisions for the same interfaces. In normal use, a given version of a Transport Services
network conditions given the same set of Properties. This is system SHOULD result in consistent protocol and interface selection
intended to provide predictable outcomes to the application using the decisions for the same network conditions given the same set of
API. Properties. This is intended to provide predictable outcomes to the
application using the API.
4. Transport Services Architecture and Concepts 4. Transport Services Architecture and Concepts
The concepts defined in this document are intended primarily for use This section and the remainder of this document describe the
in the documents and specifications that describe the Transport architecture non-normatively. The concepts defined in this document
Services architecture and API. While the specific terminology can be are intended primarily for use in the documents and specifications
used in some implementations, it is expected that there will remain a that describe the Transport Services system. This includes the
architecture, the Transport Services API and the associated Transport
Services implementation. While the specific terminology can be used
in some implementations, it is expected that there will remain a
variety of terms used by running code. variety of terms used by running code.
The architecture divides the concepts for Transport Services into two The architecture divides the concepts for Transport Services system
categories: into two categories:
1. API concepts, which are intended to be exposed to applications; 1. API concepts, which are intended to be exposed to applications;
and and
2. System-implementation concepts, which are intended to be 2. System-implementation concepts, which are intended to be
internally used when building systems that implement Transport internally used by aTransport Services implementation.
Services.
The following diagram summarizes the top-level concepts in the The following diagram summarizes the top-level concepts in the
architecture and how they relate to one another. architecture and how they relate to one another.
+-----------------------------------------------------+ +-----------------------------------------------------+
| Application | | Application |
+-+----------------+------^-------+--------^----------+ +-+----------------+------^-------+--------^----------+
| | | | | | | | | |
pre- | data | events pre- | data | events
establishment | transfer | | establishment | transfer | |
skipping to change at page 14, line 45 skipping to change at page 14, line 45
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
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 language. exposed as handles or referenced objects, depending on the chosen
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:
* Pre-Establishment (Section 4.1.3) encompasses the properties that * Pre-Establishment (Section 4.1.3) encompasses the properties that
an application can pass to describe its intent, requirements, an application can pass to describe its intent, requirements,
prohibitions, and preferences for its networking operations. prohibitions, and preferences for its networking operations.
These properties apply to multiple transport protocols, unless These properties apply to multiple transport protocols, unless
otherwise specified. Properties specified during Pre- otherwise specified. Properties specified during Pre-
Establishment can have a large impact on the rest of the Establishment can have a large impact on the rest of the
interface: they modify how establishment occurs, they influence interface: they modify how establishment occurs, they influence
the expectations around data transfer, and they determine the set the expectations around data transfer, and they determine the set
of events that will be supported. of events that will be supported.
* 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.
skipping to change at page 16, line 33 skipping to change at page 16, line 33
: : : :
Figure 4: The lifetime of a Connection object Figure 4: The lifetime of a Connection object
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, and An Endpoint can be specified at various levels of abstraction. An
an Endpoint at a higher level of abstraction (such as a hostname) Endpoint at a higher level of abstraction (such as a hostname) can
can be resolved to more concrete identities (such as IP be resolved to more concrete identities (such as IP addresses).
addresses). An endpoint may also represent a multicast group, in which case it
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
* Preconnection: A Preconnection object is a representation of a * Preconnection: A Preconnection object is a representation of a
potential Connection. It has state that describes parameters of a Connection that has not yet been established. It has state that
Connection that might exist in the future: 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 fully specified such that it represents a Preconnection can be either fully specified (representing a single
single possible Connection, or it can be partially specified such possible Connection), or it can be partially specified
that it represents a family of possible Connections. The Local (representing a family of possible Connections). The Local
Endpoint (Section 4.1.3) is required if the Preconnection is used Endpoint (Section 4.1.3) is required for a Preconnection used to
to Listen for incoming Connections. The Local Endpoint is Listen for incoming Connections, but optional if it is used to
optional if it is used to Initiate Connections. The Remote Initiate a Connection. The Remote Endpoint is required in a
Endpoint is required in the Preconnection that is used to Initiate Preconnection that used to Initiate a Connection, but is optional
Connections. The Remote Endpoint is optional if it is used to if it is used to Listen for incoming Connections. The Local
Listen for incoming Connections. The Local Endpoint and the Endpoint and the Remote Endpoint are both required if a peer-to-
Remote Endpoint are both required if a peer-to-peer Rendezvous is peer Rendezvous is to occur based on the Preconnection.
to occur based on the Preconnection.
* Transport Properties: Transport Properties allow the application * Transport Properties: Transport Properties allow the application
to express their requirements, prohibitions, and preferences and to express their requirements, prohibitions, and preferences and
configure the Transport Services system. There are three kinds of configure a Transport Services system. There are three kinds of
Transport Properties: Transport Properties:
- Selection Properties (Section 4.1.3) that can only be specified - Selection Properties (Section 4.1.3): Selection Properties can
on a Preconnection. only be specified on a Preconnection.
- Connection Properties (Section 4.1.3) that can be specified on - Connection Properties (Section 4.1.3): Connection Properties
a Preconnection and changed on the Connection. can be specified on a Preconnection and changed on the
Connection.
- Message Properties (Section 4.1.5) that can be specified as - Message Properties (Section 4.1.5): Message Properties can be
defaults on a Preconnection or a Connection, and can also be specified as defaults on a Preconnection or a Connection, and
specified during data transfer to affect specific Messages. can also be specified during data transfer to affect specific
Messages.
* Connection: A Connection object represents one or more active * Connection: A Connection object represents one or more active
transport protocol instances that can send and/or receive Messages transport protocol instances that can send and/or receive Messages
between local and remote systems. It holds state pertaining to between Local and Remote Endpoints. It is an abstraction that
the underlying transport protocol instances and any ongoing data represents the communication. The Connection object holds state
transfers. This represents, for example, an active Connection in pertaining to the underlying transport protocol instances and any
a connection-oriented protocol such as TCP, or a fully-specified ongoing data transfers. For example, an active Connection can
5-tuple for a connectionless protocol such as UDP. It can also represent a connection-oriented protocol such as TCP, or can
represent a pool of transport protocol instances, e.g., a set of represent a fully-specified 5-tuple for a connectionless protocol
TCP and QUIC connections to equivalent endpoints, or a stream of a such as UDP, where the Connection remains an abstraction at the
multi-streaming transport protocol instance. Connections can be end points. It can also represent a pool of transport protocol
created from a Preconnection or by a Listener. 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 systems 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 systems, to influence the of paths between the Local and Remote Endpoints, to influence the
selection of transport protocols, or to configure the behavior of selection of transport protocols, or to configure the behavior of
generic transport protocol features. These properties can take generic transport protocol features. These properties can take
the form of requirements, prohibitions, or preferences. Examples the form of requirements, prohibitions, or preferences. Examples
of properties that influence path selection include the interface of properties that influence path selection include the interface
type (such as a Wi-Fi connection, or a Cellular LTE connection), type (such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the largest Message that can be sent, or requirements around the largest Message that can be sent, or
preferences for throughput and latency. Examples of properties preferences for throughput and latency. Examples of properties
that influence protocol selection and configuration of transport that influence protocol selection and configuration of transport
protocol features include reliability, multipath support, and fast protocol features include reliability, multipath support, and fast
open support. open support.
* Connection Properties: The Connection Properties are used to * Connection Properties: The Connection Properties are used to
configure protocol-specific options and control per-connection configure protocol-specific options and control per-connection
behavior of the Transport Services system; for example, a behavior of a Transport Services implementation; for example, a
protocol-specific Connection Property can express that if TCP is protocol-specific Connection Property can express that if TCP is
used, the implementation ought to use the User Timeout Option. used, the implementation ought to use the User Timeout Option.
Note that the presence of such a property does not require that a Note that the presence of such a property does not require that a
specific protocol will be used. In general, these properties do specific protocol will be used. In general, these properties do
not explicitly determine the selection of paths or protocols, but not explicitly determine the selection of paths or protocols, but
can be used by an implementation during connection establishment. can be used by an implementation during connection establishment.
Connection Properties are specified on a Preconnection prior to Connection Properties are specified on a Preconnection prior to
Connection establishment, and can be modified on the Connection Connection establishment, and can be modified on the Connection
later. Changes made to Connection Properties after Connection later. Changes made to Connection Properties after Connection
establishment take effect on a best-effort basis. establishment take effect on a best-effort basis.
* Security Parameters: Security Parameters define an application's * Security Parameters: Security Parameters define an application's
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
skipping to change at page 19, line 35 skipping to change at page 19, line 43
the Local and Remote Endpoints are TCP host candidates, then a TCP the Local and Remote Endpoints are TCP host candidates, then a TCP
simultaneous open [RFC0793] will be performed. However, if the simultaneous open [RFC0793] will be performed. However, if the
set of Local Endpoints includes server reflexive candidates, such set of Local Endpoints includes server reflexive candidates, such
as those provided by STUN, a Rendezvous action will race as those provided by STUN, a Rendezvous action will race
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 systems 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.
* 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
at the receiver and information signalled by the remote endpoint. at the receiver and information signalled by the Remote Endpoint.
For example, a Message can be marked with a Message Property For example, a Message can be marked with a Message Property
indicating that it is the final message on a connection if the indicating that it is the final message on a connection.
peer sent a TCP FIN.
* Send: The action to transmit a Message over a Connection to the * Send: The action to transmit a Message over a Connection to the
remote system. The interface to Send can accept Message Remote Endpoint. The interface to Send can accept Message
Properties specific to how the Message content is to be sent. The Properties specific to how the Message content is to be sent. The
status of the Send operation is delivered back to the sending status of the Send operation is delivered back to the sending
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
system, 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 to define how application-layer Messages are
transmitted over a transport protocol. This is particularly transmitted over a transport stack. This is particularly relevant
relevant for protocols that otherwise present unstructured when using a protocol that otherwise presents unstructured
streams, such as TCP. streams, such as TCP.
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,
skipping to change at page 21, line 16 skipping to change at page 21, line 13
Listener has received a Connection. Listener has received a Connection.
* Message Received: Delivers received Message content to the * Message Received: Delivers received Message content to the
application, based on a Receive action. This can include an error application, based on a Receive action. This can include an error
if the Receive action cannot be satisfied due to the Connection if the Receive action cannot be satisfied due to the Connection
being closed. being closed.
* 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
protocol stack. Transport Services system.
* Path Properties Changed: Notifies the application that some * Path Properties Changed: Notifies the application that a property
property of the Connection has changed that might influence how of the Connection has changed that might influence how and where
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 system 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. Indicating the end of a stream in direction of a TCP connection. The end of a stream can also be
the Transport Services architecture is possible using Message indicated using Message Properties when sending.)
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 the Transport Services indicate a Close and also indicate that a Transport Services
system should not attempt to deliver any outstanding data. This system should not attempt to deliver any outstanding data, and
is intended for immediate termination of a connection, without immediately drop the connection. This is intended for immediate,
cleaning up state. 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 properties and
caches. For multiplexing transport protocols, only Connections caches. A Connection Group represents state for managing Connections
within a single application, and does not require end-to-end protocol
signaling. For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed within the same Connection Group are allowed to be multiplexed
together. While Connection Groups are managed by the transport together.
system, an application can define Connection Contexts to control
caching boundaries, as discussed in Section 4.2.3.
4.2. Transport Services Implementation Concepts When the API clones an existing Connection, this adds a new
Connection to the Connection Group. A change to one of the
Connection Properties on any Connection in the Connection Group
automatically changes the Connection Property for all others. All
Connections in a Connection Group share the same set of Connection
Properties except for the Connection Priority. These Connection
Properties are said to be entangled.
This section defines the set of objects used internally to a system For multiplexing transport protocols, only Connections within the
or library to implement the functionality needed to provide a same Connection Group are allowed to be multiplexed together.
transport service across a network, as required by the abstract Passive Connections can also be added to a Connection Group, e.g.,
interface. when a Listener receives a new Connection that is just a new stream
of an already active multi-streaming protocol instance.
While Connection Groups are managed by the Transport Services system,
an application can define Connection Contexts to control caching
boundaries, as discussed in Section 4.2.3.
4.2. Transport Services Implementation
This section defines the key concepts of the Transport Services
architecture.
* Transport Service implementaion: This consists of all objects and
protocol instances used internally to a system or library to
implement the functionality needed to provide a transport service
across a network, as required by the abstract interface.
* Transport Service system: This consists of the Transport Service
implementaion and the Transport Services API.
* Path: Represents an available set of properties that a local * Path: Represents an available set of properties that a local
system can use to communicate with a remote system, such as endpoint can use to communicate with a Remote Endpoint, such as
routes, addresses, and physical and virtual network interfaces. routes, addresses, and physical and virtual network interfaces.
* Protocol Instance: A single instance of one protocol, including * Protocol Instance: A single instance of one protocol, including
any state necessary to establish connectivity or send and receive any state necessary to establish connectivity or send and receive
Messages. Messages.
* Protocol Stack: A set of Protocol Instances (including relevant * Protocol Stack: A set of Protocol Instances (including relevant
application, security, transport, or Internet protocols) that are application, security, transport, or Internet protocols) that are
used together to establish connectivity or send and receive used together to establish connectivity or send and receive
Messages. A single stack can be simple (a single transport Messages. A single stack can be simple (a single transport
skipping to change at page 22, line 36 skipping to change at page 23, line 6
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, of which there can be several. an application for a Connection, which there can be several
Candidate Protocol Stacks are identified during the gathering candidates. Candidate Protocol Stacks are identified during the
phase (Section 4.2.1) and are started during the racing phase gathering phase (Section 4.2.1) and are started during the racing
(Section 4.2.2). phase (Section 4.2.2).
* System Policy: Represents the input from an operating system or * System Policy: Represents the input from an operating system or
other global preferences that can constrain or influence how an other global preferences that can constrain or influence how an
implementation will gather candidate paths and Protocol Stacks implementation will gather candidate paths and Protocol Stacks
(Section 4.2.1) and race the candidates during establishment (Section 4.2.1) and race the candidates during establishment
(Section 4.2.2). Specific aspects of the System Policy either (Section 4.2.2). Specific aspects of the System Policy either
apply to all Connections or only certain ones, depending on the apply to all Connections or only certain ones, depending on the
runtime context and properties of the Connection. runtime context 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
skipping to change at page 23, line 17 skipping to change at page 23, line 31
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.
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 system. heuristics of a Transport Services implementation.
* Candidate Protocol Selection: Candidate Protocol Selection * Candidate Protocol Selection: Candidate Protocol Selection
represents the act of choosing one or more sets of Protocol Stacks represents the act of choosing one or more sets of Protocol Stacks
that are available to use based on the Transport Properties that are available to use based on the Transport Properties
provided by the application, and the heuristics or policies within provided by the application, and the heuristics or policies within
the Transport Services system. the Transport Services implementation.
4.2.2. Candidate Racing 4.2.2. Candidate Racing
Connection establishment attempts for a set of candidates may be Connection establishment attempts for a set of candidates may be
performed simultaneously, synchronously, serially, or some performed simultaneously, synchronously, serially, or using some
combination of all of these. We refer to this process as racing, combination of all of these. We refer to this process as racing,
borrowing terminology from Happy Eyeballs [RFC8305]. borrowing terminology from Happy Eyeballs [RFC8305].
* Protocol Option Racing: Protocol Option Racing is the act of * Protocol Option Racing: Protocol Option Racing is the act of
attempting to establish, or scheduling attempts to establish, attempting to establish, or scheduling attempts to establish,
multiple Protocol Stacks that differ based on the composition of multiple Protocol Stacks that differ based on the composition of
protocols or the options used for protocols. protocols or the options used for protocols.
* Path Racing: Path Racing is the act of attempting to establish, or * Path Racing: Path Racing is the act of attempting to establish, or
scheduling attempts to establish, multiple Protocol Stacks that scheduling attempts to establish, multiple Protocol Stacks that
skipping to change at page 24, line 11 skipping to change at page 24, line 25
multiple Protocol Stacks that differ based on the specific multiple Protocol Stacks that differ based on the specific
representation of the Remote Endpoint, such as a particular IP representation of the Remote Endpoint, such as a particular IP
address that was resolved from a DNS hostname. address that was resolved from a DNS hostname.
4.2.3. Separating Connection Contexts 4.2.3. Separating Connection Contexts
By default, stored properties of the implementation, such as cached By default, stored properties of the implementation, such as cached
protocol state, cached path state, and heuristics, may be shared protocol state, cached path state, and heuristics, may be shared
(e.g. across multiple connections in an application). This provides (e.g. across multiple connections in an application). This provides
efficiency and convenience for the application, since the Transport efficiency and convenience for the application, since the Transport
Services implementation can automatically optimize behavior. Services system can automatically optimize behavior.
There are several reasons, however, that an application might want to The Transport Services API can allow applications to explicitly
explicitly isolate some Connections. These reasons include: define Connection Contexts that force separation of Cached State and
Protocol Stacks. For example, a web browser application could use
Connection Contexts with separate caches when implementing different
tabs. Possible reasons to isolate Connections using separate
Connection Contexts include:
* Privacy concerns about re-using cached protocol state that can * Privacy concerns about re-using cached protocol state that can
lead to linkability. Sensitive state may include TLS session lead to linkability. Sensitive state could include TLS session
state [RFC8446] and HTTP cookies [RFC6265]. state [RFC8446] and HTTP cookies [RFC6265]. These concerns could
be addressed using Connection Contexts with separate caches, such
as for different browser tabs.
* Privacy concerns about allowing Connections to multiplex together, * Privacy concerns about allowing Connections to multiplex together,
which can tell a Remote Endpoint that all of the Connections are which can tell a Remote Endpoint that all of the Connections are
coming from the same application (for example, when Connections coming from the same application. Using Connection Contexts
are multiplexed HTTP/2 or QUIC streams). avoids the Connections being multiplexed in a HTTP/2 or QUIC
stream.
* Performance concerns about Connections introducing head-of-line
blocking due to multiplexing or needing to share state on a single
thread.
The Transport Services API can allow applications to explicitly
define Connection Contexts that force separation of Cached State and
Protocol Stacks. For example, a web browser application might use
Connection Contexts with separate caches for different tabs in the
browser to decrease linkability.
5. IANA Considerations 5. IANA Considerations
RFC-EDITOR: Please remove this section before publication. RFC-EDITOR: Please remove this section before publication.
This document has no actions for IANA. This document has no actions for IANA.
6. Security Considerations 6. Security and Privacy Considerations
The Transport Services architecture does not recommend use of The Transport Services architecture does not recommend use of
specific security protocols or algorithms. Its goal is to offer ease specific security protocols or algorithms. Its goal is to offer ease
of use for existing protocols by providing a generic security-related of use for existing protocols by providing a generic security-related
interface. Each provided interface translates to an existing interface. Each provided interface translates to an existing
protocol-specific interface provided by supported security protocols. protocol-specific interface provided by supported security protocols.
For example, trust verification callbacks are common parts of TLS For example, trust verification callbacks are common parts of TLS
APIs. Transport Services APIs will expose similar functionality APIs; a Transport Services API exposes similar functionality
[RFC8922]. [RFC8922].
As described above in Section 3.3, if a Transport Services system As described above in Section 3.3, if a Transport Services
races between two different Protocol Stacks, both need to use the implementation races between two different Protocol Stacks, both need
same security protocols and options. However, a Transport Services to use the same security protocols and options. However, a Transport
system can race different security protocols, e.g., if the Services implementation can race different security protocols, e.g.,
application explicitly specifies that it considers them equivalent. if the application explicitly specifies that it considers them
equivalent.
The application controls whether information from previous racing
attempts, or other information about past communications that was
cached by the Transport Services system is used during establishment.
This allows applications to make tradeoffs between efficiency
(through racing) and privacy (via information that might leak from
the cache toward an on-path observer). Some applications have native
concepts (e.g. "incognito mode") that align with this functionality.
Applications need to ensure that they use security APIs Applications need to ensure that they use security APIs
appropriately. In cases where applications use an interface to appropriately. In cases where applications use an interface to
provide sensitive keying material, e.g., access to private keys or provide sensitive keying material, e.g., access to private keys or
copies of pre-shared keys (PSKs), key use needs to be validated. For copies of pre-shared keys (PSKs), key use needs to be validated. For
example, applications ought not to use PSK material created for the example, applications ought not to use PSK material created for the
Encapsulating Security Protocol (ESP, part of IPsec) [RFC4303] with Encapsulating Security Protocol (ESP, part of IPsec) [RFC4303] with
QUIC, and applications ought not to use private keys intended for QUIC, and applications ought not to use private keys intended for
server authentication as keys for client authentication. server authentication as keys for client authentication.
Moreover, Transport Services systems must not automatically fall back A Transport Services system must not automatically fall back from
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. Applications are thus not available, its connection will fail. Applications are thus
responsible for implementing security protocol fallback or version responsible for implementing security protocol fallback or version
fallback by creating multiple Transport Services Connections, if so fallback by creating multiple Connections, if so desired.
desired. Alternatively, a Transport Services system MAY allow Alternatively, the Transport Services API MAY allow applications to
applications to specify that fallback to a specific other version of specify that fallback to a specific other version of a protocol is
a protocol is allowed. allowed 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) and No. 688421 (MAMI). (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).
This work has been supported by the UK Engineering and Physical This work has been supported by the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
Thanks to Theresa Enghardt, Max Franke, Mirja Kuehlewind, Jonathan Thanks to Theresa Enghardt, Max Franke, Mirja Kuehlewind, Jonathan
Lennox, and Michael Welzl for the discussions and feedback that Lennox, and Michael Welzl for the discussions and feedback that
helped shape the architecture described here. Thanks as well to helped shape the architecture described here. Particular thanks is
Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for also due to Philipp S. Tiesel and Christopher A. Wood, who were
their implementation and design efforts, including Happy Eyeballs, both co-authors of this architecture specification as it progressed
that heavily influenced this work. through the TAPS working group. Thanks as well to Stuart Cheshire,
Josh Graessley, David Schinazi, and Eric Kinnear for their
implementation and design efforts, including Happy Eyeballs, that
heavily influenced this work.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A.,
Pauly, T., and K. Rose, "An Abstract Application Layer Pauly, T., and K. Rose, "An Abstract Application Layer
Interface to Transport Services", Work in Progress, Interface to Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-interface-12, 9 April Internet-Draft, draft-ietf-taps-interface-14, 3 January
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
taps-interface-12>. taps-interface-14>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[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, T., Grinnemo, K., Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Jones, T., Tiesel, P. S., Perkins, C., and M. Welzl, Jones, T., Tiesel, P. S., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", Work in "Implementing Interfaces to Transport Services", Work in
Progress, Internet-Draft, draft-ietf-taps-impl-09, 30 Progress, Internet-Draft, draft-ietf-taps-impl-10, 12 July
April 2021, <https://datatracker.ietf.org/doc/html/draft- 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
ietf-taps-impl-09>. taps-impl-10>.
[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.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/rfc/rfc793>. <https://www.rfc-editor.org/rfc/rfc793>.
skipping to change at page 28, line 43 skipping to change at line 1298
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/ URI: http://www.erg.abdn.ac.uk/
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Philipp S. Tiesel
SAP SE
Konrad-Zuse-Ring 10
14469 Potsdam
Germany
Email: philipp@tiesel.net
Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco,
United States of America
Email: caw@heapingbits.net
 End of changes. 107 change blocks. 
338 lines changed or deleted 409 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/