draft-ietf-taps-arch-05.txt | draft-ietf-taps-arch-06.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: May 7, 2020 Google | Expires: 25 June 2020 Google | |||
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 | P. Tiesel | |||
TU Berlin | TU Berlin | |||
C. Wood | C. Wood | |||
Apple Inc. | Apple Inc. | |||
November 04, 2019 | 23 December 2019 | |||
An Architecture for Transport Services | An Architecture for Transport Services | |||
draft-ietf-taps-arch-05 | draft-ietf-taps-arch-06 | |||
Abstract | Abstract | |||
This document provides an overview of the architecture of Transport | This document describes an architecture for exposing transport | |||
Services, a model for exposing transport protocol features to | protocol features to applications for network communication, the | |||
applications for network communication. In contrast to what is | Transport Services architecture. The Transport Services Application | |||
provided by most existing Application Programming Interfaces (APIs), | Programming Interface (API) is based on an asynchronous, event-driven | |||
Transport Services is based on an asynchronous, event-driven | interaction pattern. It uses messages for representing data transfer | |||
interaction pattern; it uses messages for representing data transfer | to applications, and it assumes an implementation that can use | |||
to applications; and it assumes an implementation that 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 | |||
the common set of terminology and concepts to be used in definitions | common terminology and concepts to be used in definitions of | |||
of Transport Services APIs and implementations. | Transport Services APIs and implementations. | |||
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 May 7, 2020. | This Internet-Draft will expire on 25 June 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
(https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
to this document. Code Components extracted from this document must | extracted from this document must include Simplified BSD License text | |||
include Simplified BSD License text as described in Section 4.e of | as described in Section 4.e of the Trust Legal Provisions and are | |||
the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Simplified BSD License. | |||
described in the Simplified BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 | 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 . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 | 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 | |||
2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 | 2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 | |||
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.1. Common APIs for Common Features . . . . . . . . . . . . . 9 | 3.1. Common APIs for Common Features . . . . . . . . . . . . . 9 | |||
3.2. Access to Specialized Features . . . . . . . . . . . . . 9 | 3.2. Access to Specialized Features . . . . . . . . . . . . . 9 | |||
3.3. Scope for API and Implementation Definitions . . . . . . 10 | 3.3. Scope for API and Implementation Definitions . . . . . . 10 | |||
4. Transport Services Architecture and Concepts . . . . . . . . 11 | 4. Transport Services Architecture and Concepts . . . . . . . . 11 | |||
4.1. Transport Services API Concepts . . . . . . . . . . . . . 12 | 4.1. Transport Services API Concepts . . . . . . . . . . . . . 12 | |||
4.1.1. Connection Objects . . . . . . . . . . . . . . . . . 14 | 4.1.1. Connections and Related Objects . . . . . . . . . . . 14 | |||
4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 15 | 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 15 | |||
4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 16 | 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 16 | |||
4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 17 | 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 17 | |||
4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 18 | 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 18 | |||
4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 18 | 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 18 | |||
4.2. Transport System Implementation Concepts . . . . . . . . 18 | 4.2. Transport System Implementation Concepts . . . . . . . . 19 | |||
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20 | 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20 | |||
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 20 | 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 20 | |||
4.2.3. Protocol Stack Equivalence . . . . . . . . . . . . . 20 | 4.2.3. Protocol Stack Equivalence . . . . . . . . . . . . . 21 | |||
4.2.4. Separating Connection Groups . . . . . . . . . . . . 22 | 4.2.4. Separating Connection Groups . . . . . . . . . . . . 22 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 24 | 8.2. Informative References . . . . . . . . . . . . . . . . . 24 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
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. The naming of | imitated being the BSD Socket [POSIX] interface. The naming of | |||
objects and functions across these APIs is not consistent, and varies | objects and functions across these APIs is not consistent, and varies | |||
depending on the protocol being used. For example, sending and | depending on the protocol being used. For example, sending and | |||
receiving streams of data is conceptually the same for both an | receiving streams of data is conceptually the same for both an | |||
unencrypted Transmission Control Protocol (TCP) stream and operating | unencrypted Transmission Control Protocol (TCP) stream and operating | |||
on an encrypted Transport Layer Security (TLS) [RFC8446] stream over | on an encrypted Transport Layer Security (TLS) [RFC8446] stream over | |||
TCP, but applications cannot use the same socket send() and recv() | TCP, but applications cannot use the same socket "send()" and | |||
calls on top of both kinds of connections. Similarly, terminology | "recv()" calls on top of both kinds of connections. Similarly, | |||
for the implementation of transport protocols varies based on the | terminology for the implementation of transport protocols varies | |||
context of the protocols themselves: terms such as "flow", "stream", | based on the context of the protocols themselves: terms such as | |||
"message", and "connection" can take on many different meanings. | "flow", "stream", "message", and "connection" can take on many | |||
This variety can lead to confusion when trying to understand the | different meanings. This variety can lead to confusion when trying | |||
similarities and differences between protocols, and how applications | to understand the similarities and differences between protocols, and | |||
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 | common, flexible, and reusable interface for transport protocols. As | |||
applications adopt this interface, they will benefit from a wide set | applications adopt this interface, they will benefit from a wide set | |||
of transport features that can evolve over time, and ensure that the | of transport features that can evolve over time, and ensure that the | |||
system providing the interface can optimize its behavior based on the | system providing the interface can optimize its behavior based on the | |||
application requirements and network conditions, without requiring | application requirements and network conditions, without requiring | |||
changes to the applications. This flexibility enables faster | changes to the applications. This flexibility enables faster | |||
deployment of new features and protocols. It can also support | deployment of new features and protocols. It can also support | |||
applications by offering racing and fallback mechanisms, which | applications by offering racing and fallback mechanisms, which | |||
otherwise need to be implemented in each application separately. | otherwise need to be implemented in each application separately. | |||
This document is 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 [I-D.ietf-taps-minset]. These | offered by transport protocols [I-D.ietf-taps-minset]. These | |||
documents identified common features and patterns across all | documents identified common features and patterns across all | |||
transport protocols developed thus far in the IETF. | transport protocols developed thus far in the IETF. | |||
Since transport security is an increasingly relevant aspect of using | Since transport security is an increasingly relevant aspect of using | |||
transport protocols on the Internet, this architecture also considers | transport protocols on the Internet, this architecture also considers | |||
the impact of transport security protocols on the feature-set exposed | the impact of transport security protocols on the feature-set exposed | |||
by transport services [I-D.ietf-taps-transport-security]. | by transport services [I-D.ietf-taps-transport-security]. | |||
One of the key insights to come from identifying the minimal set of | One of the key insights to come from identifying the minimal set of | |||
features provided by transport protocols [I-D.ietf-taps-minset] was | features provided by transport protocols [I-D.ietf-taps-minset] was | |||
that features either require application interaction and guidance | that features either require application interaction and guidance | |||
(referred to as Functional or Optimizing Features), or else can be | (referred to in that document as Functional or Optimizing Features), | |||
handled automatically by a system implementing Transport Services | or else can be handled automatically by a system implementing | |||
(referred to as Automatable Features). Among the Functional and | Transport Services (referred to as Automatable Features). Among the | |||
Optimizing Features, some were common across all or nearly all | Functional and Optimizing Features, some were common across all or | |||
transport protocols, while others could be seen as features that, if | nearly all transport protocols, while others could be seen as | |||
specified, would only be useful with a subset of protocols, but would | features that, if specified, would only be useful with a subset of | |||
not harm the functionality of other protocols. For example, some | protocols, but would not harm the functionality of other protocols. | |||
protocols can deliver messages faster for applications that do not | For example, some protocols can deliver messages faster for | |||
require messages to arrive in the order in which they were sent. | applications that do not require messages to arrive in the order in | |||
However, this functionality needs to be explicitly allowed by the | which they were sent. However, this functionality needs to be | |||
application, since reordering messages would be undesirable in many | explicitly allowed by the application, since reordering messages | |||
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: | |||
o 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 | differs from traditional socket-based APIs. Specifically, it | |||
offers asynchronous event-driven interaction, the use of messages | offers asynchronous event-driven interaction, the use of messages | |||
for data transfer, and the ability to easily adopt different | for data transfer, and the ability to easily adopt different | |||
transport protocols. | transport protocols. | |||
o Section 3 explains the design principles that guide the Transport | * Section 3 explains the design principles behind the Transport | |||
Services API. These principles are intended to make sure that | Services API. 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 too many changes by application developers. | requiring too many changes by application developers. | |||
o Section 4 presents the Transport Services architecture diagram and | * Section 4 presents the Transport Services architecture diagram and | |||
defines the concepts that are used by both the API and | defines the concepts that are used by both the API and | |||
implementation documents. The Preconnection allows applications | implementation documents. The Preconnection allows applications | |||
to configure connection properties, and the Connection represents | to configure connection properties, and the Connection represents | |||
an object that can be used to send and receive Messages. | an object that can be used to send and receive Messages. | |||
1.3. Specification of Requirements | 1.3. Specification of Requirements | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. API Model | 2. API Model | |||
The traditional model of using sockets for networking can be | The traditional model of using sockets for networking can be | |||
represented as follows: | represented as follows: | |||
o Applications create connections and transfer data using the socket | * Applications create connections and transfer data using the Socket | |||
API. | API. | |||
o The socket API provides the interface to the implementations of | * The Socket API provides the interface to the implementations of | |||
TCP and UDP (typically implemented in the system's kernel). | TCP and UDP (typically implemented in the system's kernel). | |||
o TCP and UDP in the kernel send and receive data over the available | * TCP and UDP in the kernel send and receive data over the available | |||
network layer interfaces. | network-layer interfaces. | |||
* Sockets are bound directly to transport-layer and network-layer | ||||
addresses, obtained via a separate resolution step, usually | ||||
performed by a system-provided stub resolver. | ||||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| Application | | | Application | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| | | | | | | |||
+---------------------+ +-----------------------+ | +------------+ +------------+ +--------------+ | |||
| Socket Stream API | | Socket Datagram API | | | stub | | Stream API | | Datagram API | | |||
+---------------------+ +-----------------------+ | | resolver | +------------+ +--------------+ | |||
| | | +------------+ | | | |||
+-----------------------------------------------------+ | +---------------------------------+ | |||
| TCP UDP | | | TCP UDP | | |||
| Kernel Protocol Implementation | | | Kernel Networking Stack | | |||
+-----------------------------------------------------+ | +---------------------------------+ | |||
| | | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| Network Layer Interface | | | Network Layer Interface | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
Figure 1: socket() API Model | Figure 1: Socket API Model | |||
The Transport Services architecture maintains this general model of | The Transport Services architecture evolves this general model of | |||
interaction, but aims to both modernize the API surface exposed for | interaction, aiming to both modernize the API surface presented to | |||
transport protocols and enrich the capabilities of the transport | applications by the transport layer and enrich the capabilities of | |||
system implementation. | the transport system implementation. It combines interfaces for | |||
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 | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| | | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| Transport System Implementation | | | Transport System Implementation | | |||
| (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 | mechanism for an application to create network connections and | |||
transfer data. The implementation [I-D.ietf-taps-impl] is | transfer data. The implementation [I-D.ietf-taps-impl] is | |||
responsible for mapping the API to the various available transport | responsible for mapping the API to the various available transport | |||
protocols and managing the available network interfaces and paths. | protocols and managing the available network interfaces and paths. | |||
There are key differences between the architecture of the Transport | There are key differences between the architecture of the Transport | |||
Services system and the architecture of the sockets API: it presents | Services system and the architecture of the sockets API: the | |||
an asynchronous, event-driven API; it uses messages for representing | Transport Services API is asynchronous and event-driven; it uses | |||
data transfer to applications; and it assumes an implementation that | messages for representing data transfer to applications, and it | |||
can use multiple IP addresses, multiple protocols, multiple paths, | assumes an implementation that can use multiple IP addresses, | |||
and provide multiple application streams. | multiple protocols, multiple paths, and provide multiple application | |||
streams. | ||||
2.1. Event-Driven API | 2.1. Event-Driven API | |||
Originally, sockets presented a blocking interface for establishing | Originally, sockets presented a blocking interface for establishing | |||
connections and transferring data. However, most modern applications | connections and transferring data. However, most modern applications | |||
interact with the network asynchronously. When sockets are presented | interact with the network asynchronously. Emulation of an | |||
as an asynchronous interface, they generally use a try-and-fail | asynchronous interface using sockets generally uses a try-and-fail | |||
model. If the application wants to read, but data has not yet been | 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 | received from the peer, the call to read will fail. The application | |||
then waits and can try again later. | then waits and can try again later. | |||
All interaction with a Transport Services system is expected to be | In contrast to sockets, all interaction with a Transport Services | |||
asynchronous, and use an event-driven model unlike sockets | system is expected to be asynchronous, and use an event-driven model | |||
Section 4.1.5. For example, if the application wants to read, its | (see Section 4.1.5). For example, if the application wants to read, | |||
call to read will not fail, but will deliver an event containing the | its call to read will not complete immediately, but will deliver an | |||
received data once it is available. | event containing the received data once it is available. Error | |||
handling is also asynchronous; a failure to send results in an | ||||
asynchronous send error as an event. | ||||
The Transport Services API also delivers events regarding the | The Transport Services API also delivers events regarding the | |||
lifetime of a connection and changes in the available network links, | lifetime of a connection and changes in the available network links, | |||
which were not previously made explicit in sockets. | which were not previously made explicit in sockets. | |||
Using asynchronous events allows for a much simpler 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 sockets represent network resources as file system | |||
objects that may be temporarily unavailable. | objects that may be temporarily unavailable. | |||
Separate from events, callbacks are also provided for asynchronous | ||||
interactions with the API not directly related to events on the | ||||
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, | Sockets provide a message interface for datagram protocols like UDP, | |||
but provide an unstructured stream abstraction for TCP. While TCP | but provide an unstructured stream abstraction for TCP. While TCP | |||
does indeed provide the ability to send and receive data as streams, | does indeed provide the ability to send and receive data as streams, | |||
most applications need to interpret structure within these streams. | most applications need to interpret structure within these streams. | |||
For example, HTTP/1.1 uses character delimiters to segment messages | For example, HTTP/1.1 uses character delimiters to segment messages | |||
over a stream [RFC7230]; TLS record headers carry a version, content | over a stream [RFC7230]; TLS record headers carry a version, content | |||
type, and length [RFC8446]; and HTTP/2 uses frames to segment its | type, and length [RFC8446]; and HTTP/2 uses frames to segment its | |||
headers and bodies [RFC7540]. | 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. Messages | more closely matches the way applications use the network. Providing | |||
seamlessly work with transport protocols that support datagrams or | a message-based abstraction provides many benefits, such as: | |||
records, but can also be used over a stream by defining an | ||||
application-layer framer Section 4.1.4. When framing protocols are | ||||
placed on top of unstructured streams, the messages used in the API | ||||
represent the framed messages within the stream. In the absence of a | ||||
framer, protocols that deal only in byte streams, such as TCP, | ||||
represent their data in each direction as a single, long message. | ||||
Providing a message-based abstraction provides many benefits, such | ||||
as: | ||||
o 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; | |||
o the ability to provide control of reliability, choosing which | * the ability to provide control of reliability, choosing which | |||
messages to retransmit in the event of packet loss, and how best | messages to retransmit when there is packet loss, and how best to | |||
to make use of the data that arrived; | make use of the data that arrived; | |||
o the ability to manage dependencies between messages, when the | * the ability to manage dependencies between messages, when the | |||
transport system could decide to not deliver a message, either | transport system could decide to not deliver a message, either | |||
following packet loss or because it has missed a deadline. In | following packet loss or because it has missed a deadline. In | |||
particular, this can avoid (re-)sending data that relies on a | particular, this can avoid (re-)sending data that relies on a | |||
previous transmission that was never received. | previous transmission that was never received. | |||
o the ability to automatically assign messages and connections to | * the ability to automatically assign messages and connections to | |||
underlaying 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 existings protocols and APIs, as it does not change | compatible with existings protocols and APIs, as it does not change | |||
the wire format of any protocol. Instead, it gives the protocol | the wire format of any protocol. Instead, it gives the protocol | |||
stack additional information to allow it to make better use of modern | stack additional information to allow it to make better use of modern | |||
transport services, while simplifying the application's role in | transport services, while simplifying the application's role in | |||
parsing data. | parsing data. For protocols which natively use a streaming | |||
abstraction, framers (Section 4.1.4) bridge the gap between the two | ||||
abstractions. | ||||
2.3. Flexibile Implementation | 2.3. Flexibile Implementation | |||
Sockets, for protocols like TCP, are generally limited to connecting | Sockets, for protocols like TCP, are generally limited to connecting | |||
to a single address over a single interface. They also present a | to a single address over a single interface. They also present a | |||
single stream to the application. Software layers built upon sockets | single stream to the application. Software layers built upon sockets | |||
often propagate this limitation of a single-address single-stream | often propagate this limitation of a single-address single-stream | |||
model. The Transport Services architecture is designed to handle | model. The Transport Services architecture is designed to handle | |||
multiple candidate endpoints, protocols, and paths; and support | multiple candidate endpoints, protocols, and paths; and support | |||
multipath and multistreaming protocols. | multipath and multistreaming protocols. | |||
skipping to change at page 9, line 41 ¶ | skipping to change at page 10, line 8 ¶ | |||
exposed differently from the common options to ensure flexibility. | exposed differently from the common options to ensure flexibility. | |||
A specialized feature could be required by an application only when | A specialized feature could be required 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 UDP, it could require control over the | if an application is using UDP, it could require control over the | |||
checksum or fragmentation behavior for UDP; if it used a protocol to | checksum or fragmentation behavior for UDP; if it used a protocol to | |||
frame its data over a byte stream like TCP, it would not need these | frame its data over a byte stream like TCP, it would not need these | |||
options. In such cases, the API ought to expose the features in such | options. In such cases, the API ought to expose the features in such | |||
a way that they take effect when a particular protocol is selected, | a way that they take effect when a particular protocol is selected, | |||
but do not imply that only that protocol could be used. For example, | but do not imply that only that protocol could be used. For example, | |||
if the API allows an application to specify a preference for | if the API allows an application to specify a preference to use a | |||
constrained checksum usage, communication would not fail when a | partial checksum, communication would not fail when a protocol such | |||
protocol such as TCP is selected, which uses a checksum covering the | as TCP is selected, which uses a checksum covering the entire | |||
entire payload. | payload. | |||
Other specialized features, however, could be strictly required by an | Other specialized features, however, could 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 encryption of its transport | For example, if an application requires support for automatic | |||
data, only protocol stacks that include a transport security function | handover or failover for a Connection, only protocol stacks that | |||
are eligible to be used. A Transport Services API MUST allow | provide this feature are eligible to be used, e.g., protocol stacks | |||
that include a multipath protocol or a protocol that supports | ||||
connection migration. A Transport Services API MUST allow | ||||
applications to define such requirements and constrain the system's | applications to define such requirements and constrain the system's | |||
options. Since such options are not part of the core/common | options. Since such options are not part of the core/common | |||
features, it will generally be simple for an application to modify | features, it will generally be simple for an application to modify | |||
its set of constraints and change the set of allowable protocol | its set of constraints and change the set of allowable protocol | |||
features without changing the core implementation. | features without changing the core implementation. | |||
3.3. Scope for API and Implementation Definitions | 3.3. Scope for API and Implementation Definitions | |||
The Transport Services API is envisioned as the abstract model for a | The Transport Services API is envisioned as the abstract model for a | |||
family of APIs that share a common way to expose transport features | family of APIs that share a common way to expose transport features | |||
skipping to change at page 10, line 41 ¶ | skipping to change at page 11, line 10 ¶ | |||
particular transport protocols. The mappings of these API features | particular transport protocols. The mappings of these API features | |||
to specific implementations of each feature is explained in the | to specific implementations of each feature is explained in the | |||
[I-D.ietf-taps-impl] along with the implications of the feature on | [I-D.ietf-taps-impl] along with the implications of the feature on | |||
existing protocols. It is expected that [I-D.ietf-taps-interface] | existing protocols. It is expected that [I-D.ietf-taps-interface] | |||
will be updated and supplemented as new protocols and protocol | will be updated and supplemented as new protocols and protocol | |||
features are developed. | features are developed. | |||
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 Implementation document | |||
[I-D.ietf-taps-impl] define new protocols or protocol capabilities | [I-D.ietf-taps-impl] define new protocols or protocol capabilities | |||
that affect what is communicated across the network. The Transport | that affect what is communicated across the network: this implies | |||
Services system MUST be deployable on one side only. A Transport | that a Transport Services system MUST be deployable on only one side | |||
Services system acting as a connection initiator can communicate with | of a connection. A Transport Services system acting as a connection | |||
any existing system that implements the transport protocol(s) | initiator can communicate with any existing system that implements | |||
selected by the Transport Services system. Similarly, a Transport | the transport protocol(s) selected by the Transport Services system. | |||
Services system acting as a listener can receive connections for any | Similarly, a Transport Services system acting as a listener can | |||
protocol that is supported by the system, from existing initiators. | receive connections for any protocol that is supported by the system, | |||
from existing initiators. | ||||
4. Transport Services Architecture and Concepts | 4. Transport Services Architecture and Concepts | |||
The concepts defined in this document are intended primarily for use | The concepts defined in this document are intended primarily for use | |||
in the documents and specifications that describe the Transport | in the documents and specifications that describe the Transport | |||
Services architecture and API. While the specific terminology can be | Services architecture and API. While the specific terminology can be | |||
used in some implementations, it is expected that there will remain a | 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 into two | |||
skipping to change at page 12, line 37 ¶ | skipping to change at page 12, line 37 ¶ | |||
| (Candidate Racing) | +-----------------+ | | | (Candidate Racing) | +-----------------+ | | |||
| | | System | | | | | | System | | | |||
| | | Policy | | | | | | Policy | | | |||
| +----------v-----+ +-----------------+ | | | +----------v-----+ +-----------------+ | | |||
| | Protocol | | | | | Protocol | | | |||
+-------------+ Stack(s) +----------------------+ | +-------------+ Stack(s) +----------------------+ | |||
+-------+--------+ | +-------+--------+ | |||
V | V | |||
Network Layer Interface | Network Layer Interface | |||
Figure 3: Concepts and Relationships in the Transport Services | Figure 3: Concepts and Relationships in the Transport Services | |||
Architecture | Architecture | |||
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.1) that allow applications to establish | objects (Section 4.1.1) 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 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 implementing this | actions that any Transport Services API implementing this | |||
specification MUST provide: | specification MUST provide: | |||
o Pre-Establishment (Section 4.1.2) encompasses the properties that | * Pre-Establishment (Section 4.1.2) 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. For | prohibitions, and preferences for its networking operations. For | |||
any system that provides generic Transport Services, these | any system that provides generic Transport Services, these | |||
properties SHOULD be defined to apply to multiple transport | properties SHOULD apply to multiple transport protocols. | |||
protocols. Properties specified during Pre-Establishment can have | Properties specified during Pre-Establishment can have a large | |||
a large impact on the rest of the interface: they modify how | impact on the rest of the interface: they modify how establishment | |||
establishment occurs, they influence the expectations around data | occurs, they influence the expectations around data transfer, and | |||
transfer, and they determine the set of events that will be | they determine the set of events that will be supported. | |||
supported. | ||||
o Establishment (Section 4.1.3) focuses on the actions that an | * Establishment (Section 4.1.3) 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. | |||
o Data Transfer (Section 4.1.4) consists of how an application | * Data Transfer (Section 4.1.4) consists of how an application | |||
represents the data to be sent and received, the functions | represents the data to be sent and received, the functions | |||
required to send and receive that data, and how the application is | required to send and receive that data, and how the application is | |||
notified of the status of its data transfer. | notified of the status of its data transfer. | |||
o Event Handling (Section 4.1.5) defines the set of properties about | * Event Handling (Section 4.1.5) defines categories of notifications | |||
which an application can receive notifications during the lifetime | which an application can receive during the lifetime of transport | |||
of transport objects. Events MAY also provide opportunities for | objects. Events MAY also provide opportunities for the | |||
the application to interact with the underlying transport by | application to interact with the underlying transport by querying | |||
querying state or updating maintenance options. | state or updating maintenance options. | |||
o Termination (Section 4.1.6) focuses on the methods by which data | * Termination (Section 4.1.6) focuses on the methods by which data | |||
transmission is stopped, and state is torn down in the transport. | transmission is stopped, and state is torn down in the transport. | |||
The diagram below provides a high-level view of the actions and | The diagram below provides a high-level view of the actions and | |||
events during the lifetime of a connection. Note that some actions | events during the lifetime of a connection. Note that some actions | |||
are alternatives (e.g., whether to initiate a connection or to listen | are alternatives (e.g., whether to initiate a connection or to listen | |||
for incoming connections), others are optional (e.g., setting | for incoming connections), while others are optional (e.g., setting | |||
Connection and Message Properties in Pre-Establishment), or have been | Connection and Message Properties in Pre-Establishment) or have been | |||
omitted for brevity. | omitted for brevity. | |||
Pre-Establishment : Established : Termination | Pre-Establishment : Established : Termination | |||
----------------- : ----------- : ----------- | ----------------- : ----------- : ----------- | |||
: Close() : | : : | |||
+---------------+ Initiate() +------------+ Abort() : | +-- Local Endpoint : Message : | |||
+-->| Preconnection |------------->| Connection |-----------> Closed | +-- Remote Endpoint : Receive() | : | |||
| +---------------+ Rendezvous() +------------+ Conn. : | +-- Transport Properties : Send() | : | |||
| : ^ | Finished : | | : | Close() : | |||
+-- Local Endpoint : | | : | | +---------------+ Initiate() +-----+------+ Abort() : | |||
| : | | : | +---+ Preconnection |------------->| Connection |-----------> Closed | |||
+-- Remote Endpoint : | v : | +---------------+ Rendezvous() +------------+ Conn. : | |||
| : | Connection : | | : ^ | Finished : | |||
+-- Selection Properties : | Ready : | Listen() | : | | : | |||
+-- Connection Properties : | : | | : | v : | |||
+-- Message Properties : | : | v : | Connection : | |||
| : | : | +----------+ : | Ready : | |||
| +----------+ : | : | | Listener |----------------------+ : | |||
+-->| Listener |----------------------+ : | +----------+ Connection Received : | |||
+----------+ Connection Received : | : : | |||
^ : : | ||||
| : : | ||||
Listen() : : | ||||
Figure 4: The lifetime of a connection | Figure 4: The lifetime of a connection | |||
4.1.1. Connection Objects | 4.1.1. Connections and Related Objects | |||
o 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 | potential connection. It has state that describes parameters of a | |||
Connection that might exist in the future: the Local Endpoint from | Connection that might exist in the future: 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.2) to which it will connect, and Selection Properties | (Section 4.1.2) to which it will connect, and Transport Properties | |||
(Section 4.1.2) that influence the paths and protocols a | that influence the paths and protocols a Connection will use. A | |||
Connection will use. A Preconnection can be fully specified such | Preconnection can be fully specified such that it represents a | |||
that it represents a single possible Connection, or it can be | single possible Connection, or it can be partially specified such | |||
partially specified such that it represents a family of possible | that it represents a family of possible Connections. The Local | |||
Connections. The Local Endpoint (Section 4.1.2) MUST be specified | Endpoint (Section 4.1.2) MUST be specified if the Preconnection is | |||
if the Preconnection is used to Listen for incoming connections. | used to Listen for incoming connections. The Local Endpoint is | |||
The Local Endpoint is OPTIONAL if it is used to Initiate | OPTIONAL if it is used to Initiate connections. The Remote | |||
connections. The Remote Endpoint MUST be specified in the | Endpoint MUST be specified in the Preconnection that is used to | |||
Preconnection that is used to Initiate connections. The Remote | Initiate connections. The Remote Endpoint is OPTIONAL if it is | |||
Endpoint is OPTIONAL if it is used to Listen for incoming | used to Listen for incoming connections. The Local Endpoint and | |||
connections. The Local Endpoint and the Remote Endpoint MUST both | the Remote Endpoint MUST both be specified if a peer-to-peer | |||
be specified if a peer-to-peer Rendezvous is to occur based on the | Rendezvous is to occur based on the Preconnection. | |||
Preconnection. | ||||
o Transport Properties: Transport Properties can be specified as | * Transport Properties: Transport Properties allow the application | |||
part of a Preconnection to allow the application to configure the | to express their requirements, prohibitions, and preferences and | |||
Transport System and express their requirements, prohibitions, and | configure the Transport System. There are three kinds of | |||
preferences. There are three kinds of Transport Properties: | Transport Properties: | |||
* Selection Properties (Section 4.1.2) | - Selection Properties (Section 4.1.2) that can only be specified | |||
on a Preconnection. | ||||
* Connection Properties (Section 4.1.2) | - Connection Properties (Section 4.1.2) that can be specified on | |||
a Preconnection and changed on the Connection. | ||||
* and Message Properties (Section 4.1.4); note that Message | - Message Properties (Section 4.1.4) that can be specified as | |||
Properties can also be specified during data transfer to affect | defaults on a Preconnection or a Connection, and can also be | |||
specific Messages. | specified during data transfer to affect specific Messages. | |||
o 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 systems. It holds state pertaining to | |||
the underlying transport protocol instances and any ongoing data | the underlying transport protocol instances and any ongoing data | |||
transfers. This represents, for example, an active connection in | transfers. This represents, for example, an active connection in | |||
a connection-oriented protocol such as TCP, or a fully-specified | a connection-oriented protocol such as TCP, or a fully-specified | |||
5-tuple for a connectionless protocol such as UDP. It can also | 5-tuple for a connectionless protocol such as UDP. It can also | |||
represent a pool of transport protocol instance, e.g., a set of | represent a pool of transport protocol instances, e.g., a set of | |||
TCP and QUIC connections to equivalent endpoints, or a stream of a | TCP and QUIC connections to equivalent endpoints, or a stream of a | |||
multi-streaming transport protocol instance. | multi-streaming transport protocol instance. Connections can be | |||
created from a Preconnection or by a Listener. | ||||
o 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 systems 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.2. Pre-Establishment | 4.1.2. Pre-Establishment | |||
o 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, and an Endpoint | An Endpoint can be specified at various levels of abstraction, and | |||
with wider scope (such as a hostname) can be resolved to more | an Endpoint at a higher level of abstraction (such as a hostname) | |||
concrete identities (such as IP addresses). | can be resolved to more concrete identities (such as IP | |||
addresses). | ||||
o 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. | |||
o 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. | |||
o Selection Properties: The Selection Properties consist of the | * Selection Properties: The Selection Properties consist of the | |||
options that an application can set to influence the selection of | options that an application can set to influence the selection of | |||
paths between the local and remote systems, to influence the | paths between the local and remote systems, 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 options can take the | generic transport protocol features. These options can take the | |||
form of requirements, prohibitions, or preferences. Examples of | form of requirements, prohibitions, or preferences. Examples of | |||
options that influence path selection include the interface type | options that influence path selection include the interface type | |||
(such as a Wi-Fi Ethernet connection, or a Cellular LTE | (such as a Wi-Fi connection, or a Cellular LTE connection), | |||
connection), requirements around the Maximum Transmission Unit | requirements around the Maximum Transmission Unit (MTU) or path | |||
(MTU) or path MTU (PMTU), or preferences for throughput and | MTU (PMTU), or preferences for throughput and latency properties. | |||
latency properties. Examples of options that influence protocol | Examples of options that influence protocol selection and | |||
selection and configuration of transport protocol features include | configuration of transport protocol features include reliability, | |||
reliability, service class, multipath support, and fast open | service class, multipath support, and fast open support. | |||
support. | ||||
o 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 System. For example, a protocol- | behavior of the Transport System; for example, a protocol-specific | |||
specific Connection Property can express that if UDP is used, the | Connection Property can express that if UDP is used, the | |||
implementation ought to use checksums. Note that the presence of | implementation ought to use checksums. Note that the presence of | |||
such a property does not require that a specific protocol will be | such a property does not require that a specific protocol will be | |||
used. In general, these properties do not explicitly determine | used. In general, these properties do not explicitly determine | |||
the selection of paths or protocols, but MAY be used in this way | the selection of paths or protocols, but can be used in this way | |||
by an implementation during connection establishment. Connection | by an implementation during connection establishment. Connection | |||
Properties SHOULD be specified on a Preconnection prior to | Properties are specified on a Preconnection prior to Connection | |||
Connection establishment, but MAY be modified later. Changes made | establishment, and can be modified on the Connection later. | |||
to Connection Properties after establishment take effect on a | Changes made to Connection Properties after Connection | |||
best-effort basis. Such changes do not affect protocol or path | establishment take effect on a best-effort basis. | |||
selection, but only modify the manner in which a connection sends | ||||
and receives data. | ||||
4.1.3. Establishment Actions | 4.1.3. Establishment Actions | |||
o 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. The process of identifying options for connecting, such as | state (e.g., with connectionless protocols such as UDP). The | |||
resolution of the Remote Endpoint, occurs in response the Initiate | process of identifying options for connecting, such as resolution | |||
call. | of the Remote Endpoint, occurs in response to the Initiate call. | |||
o Listen: The action of marking a Listener as willing to accept | * Listen: Enables a listener to accept incoming Connections. The | |||
incoming Connections. The Listener will then create Connection | Listener will then create Connection objects as incoming | |||
objects as incoming connections are accepted (Section 4.1.5). | connections are accepted (Section 4.1.5). Listeners by default | |||
register with multiple paths, protocols, and local endpoints, | ||||
unless constrained by Selection Properties and/or the specified | ||||
Local Endpoint(s). Connections can be accepted on any of the | ||||
available paths or endpoints. | ||||
o Rendezvous: The action of establishing a peer-to-peer connection | * Rendezvous: The action of establishing a peer-to-peer connection | |||
with a Remote Endpoint. It simultaneously attempts to initiate a | with a Remote Endpoint. It simultaneously attempts to initiate a | |||
connection to a Remote Endpoint whilst listening for an incoming | connection to a Remote Endpoint while listening for an incoming | |||
connection from that endpoint. This corresponds, for example, to | connection from that endpoint. The process of identifying options | |||
a TCP simultaneous open [RFC0793]. The process of identifying | for the connection, such as resolution of the Remote Endpoint, | |||
options for the connection, such as resolution of the Remote | occurs during the Rendezvous call. As with Listeners, the set of | |||
Endpoint, occurs during the Rendezvous call. If successful, the | local paths and endpoints is constrained by Selection Properties. | |||
rendezvous call returns a Connection object to represent the | If successful, the Rendezvous call returns a Connection object to | |||
established peer-to-peer connection. | represent the established peer-to-peer connection. The processes | |||
by which connections are initiated during a Rendezvous action will | ||||
depend on the set of Local and Remote Endpoints configured on the | ||||
Preconnection. For example, if the Local and Remote Endpoints are | ||||
TCP host candidates, then a TCP simultaneous open [RFC0793] will | ||||
be performed. However, if the set of Local Endpoints includes | ||||
server reflexive candidates, such as those provided by STUN, a | ||||
Rendezvous action will race candidates in the style of the ICE | ||||
algorithm [RFC8445] to perform NAT binding discovery and initiate | ||||
a peer-to-peer connection. | ||||
4.1.4. Data Transfer Objects and Actions | 4.1.4. Data Transfer Objects and Actions | |||
o 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 systems | |||
over a transport connection. The bytes within a Message are | over a transport connection. The bytes within a Message are | |||
assumed to be ordered within the Message. If an application does | assumed to be ordered within the Message. If an application does | |||
not care about the order in which a peer receives two distinct | not care about the order in which a peer receives two distinct | |||
spans of bytes, those spans of bytes are considered independent | spans of bytes, those spans of bytes are considered independent | |||
Messages. Boundaries of a Message might or might not be | Messages. | |||
understood or transmitted by transport protocols. Specifically, | ||||
what one application considers to be two Messages sent on a | ||||
stream-based transport can be treated as a single Message by the | ||||
application on the other side. | ||||
o Message Properties: Message Properties can be used to annotate | * Message Properties: Message Properties are used to specify details | |||
specific Messages. These properties might only apply to how | about Message transmission. They can be specified directly on | |||
Message is sent (such as how the transport will treat | individual Messages, or can be set on a Preconnection or | |||
Connection as defaults. These properties might only apply to how | ||||
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. Message Properties MAY be set on a Preconnection to | Endpoint. When receiving Messages, Message Properties can contain | |||
define defaults properties for sending. When receiving Messages, | information about the received Message, such as metadata generated | |||
Message Properties can contain per-protocol properties for | at the receiver and information signalled by the remote endpoint. | |||
properties that are sent between the endpoints. | ||||
o Send: The action to transmit a Message or partial Message over a | * Send: The action to transmit a Message over a Connection to the | |||
Connection to the remote system. The interface to Send MAY | remote system. The interface to Send MAY include Message | |||
include Message Properties specific to how the Message content is | Properties specific to how the Message content is to be sent. The | |||
to be sent. The status of the Send operation can be delivered | status of the Send operation MUST be delivered back to the sending | |||
back to the sending application in an event (Section 4.1.5). | application in an event (Section 4.1.5). | |||
o 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 | system, while the Message content itself will be delivered in an | |||
event (Section 4.1.5). The interface to Receive MAY include | event (Section 4.1.5). The interface to Receive MAY 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. | |||
o 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-level Messages are | a Connection to define how application-layer Messages are | |||
transmitted over a transport protocol. This is particularly | transmitted over a transport protocol. This is particularly | |||
relevant for protocols that otherwise present unstructured | relevant for protocols that otherwise present unstructured | |||
streams, such as TCP. | streams, such as TCP. | |||
4.1.5. Event Handling | 4.1.5. Event Handling | |||
This section provides the top-level categories of events events that | The following categories of events can be delivered to an | |||
can be delivered to an application. This list is not exhaustive. | application: | |||
o Connection Ready: Signals to an application that a given | * Connection Ready: Signals to an application that a given | |||
Connection is ready to send and/or receive Messages. If the | Connection is ready to send and/or receive Messages. If the | |||
Connection relies on handshakes to establish state between peers, | Connection relies on handshakes to establish state between peers, | |||
then it is assumed that these steps have been taken. | then it is assumed that these steps have been taken. | |||
o Connection Finished: Signals to an application that a given | * Connection Finished: Signals to an application that a given | |||
Connection is no longer usable for sending or receiving Messages. | Connection is no longer usable for sending or receiving Messages. | |||
The event SHOULD deliver a reason or error to the application that | The event SHOULD deliver a reason or error to the application that | |||
describes the nature of the termination. | describes the nature of the termination. | |||
o Connection Received: Signals to an application that a given | * Connection Received: Signals to an application that a given | |||
Listener has passively received a Connection. | Listener has received a Connection. | |||
o Message Received: Delivers received Message content to the | * Message Received: Delivers received Message content to the | |||
application, based on a Receive action. This MAY include an error | application, based on a Receive action. This MAY 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. | |||
o 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 Message has been processed by the | sent, or an indication that Message has been processed by the | |||
protocol stack. | protocol stack. | |||
o Path Properties Changed: Notifies the application that some | * Path Properties Changed: Notifies the application that some | |||
property of the Connection has changed that might influence how | property of the Connection has changed that might influence how | |||
and where data is sent and/or received. | and where data is sent and/or received. | |||
4.1.6. Termination Actions | 4.1.6. Termination Actions | |||
o 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. | the remote system if the transport protocol allows this. (Note | |||
that this is distinct from the concept of "half-closing" a | ||||
bidirectional connection, such as when a FIN is sent in one | ||||
direction of a TCP connection. Indicating the end of a stream in | ||||
the Transport Services architecture is possible using Message | ||||
Properties when sending.) | ||||
o 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 system | indicate a Close and also indicate that the transport system | |||
SHOULD NOT attempt to deliver any outstanding data. | SHOULD NOT attempt to deliver any outstanding data. This is | |||
intended for immediate termination of a connection, without | ||||
cleaning up state. | ||||
4.2. Transport System Implementation Concepts | 4.2. Transport System Implementation Concepts | |||
This section defines the set of objects used internally to a system | This section defines the set of objects used internally to a system | |||
or library to implement the functionality needed to provide a | or library to implement the functionality needed to provide a | |||
transport service across a network, as required by the abstract | transport service across a network, as required by the abstract | |||
interface. | interface. | |||
o Connection Group: A set of Connections that share properties and | * Connection Group: A set of Connections that share properties and | |||
caches. For multiplexing transport protocols, only Connections | caches. 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. An application can explicitly define Connection Groups | together. An application can explicitly define Connection Groups | |||
to control caching boundaries, as discussed in Section 4.2.4. | to control caching boundaries, as discussed in Section 4.2.4. | |||
o 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 | system can use to communicate with a remote system, such as | |||
routes, addresses, and physical and virtual network interfaces. | routes, addresses, and physical and virtual network interfaces. | |||
o 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. | |||
o 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 | |||
protocol instance over IP), or complex (multiple application | protocol instance over IP), or complex (multiple application | |||
protocol streams going through a single security and transport | protocol streams going through a single security and transport | |||
protocol, over IP; or, a multi-path transport protocol over | protocol, over IP; or, a multi-path transport protocol over | |||
multiple transport sub-flows). | multiple transport sub-flows). | |||
o 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. Candidate | conforms to the Selection Properties and System Policy. Candidate | |||
Paths are identified during the gathering phase (Section 4.2.1) | Paths are identified during the gathering phase (Section 4.2.1) | |||
and can be used during the racing phase (Section 4.2.2). | and can be used during the racing phase (Section 4.2.2). | |||
o 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, of which there can be several. | |||
Candidate Protocol Stacks are identified during the gathering | Candidate Protocol Stacks are identified during the gathering | |||
phase (Section 4.2.1) and are started during the racing phase | phase (Section 4.2.1) and are started during the racing phase | |||
(Section 4.2.2). | (Section 4.2.2). | |||
o 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. | |||
o Cached State: The state and history that the implementation keeps | * Cached State: The state and history that the implementation keeps | |||
for each set of associated Endpoints that have been used | for each set of associated Endpoints that have been used | |||
previously. This can include DNS results, TLS session state, | previously. This can include DNS results, TLS session state, | |||
previous success and quality of transport protocols over certain | previous success and quality of transport protocols over certain | |||
paths. | paths. | |||
4.2.1. Candidate Gathering | 4.2.1. Candidate Gathering | |||
o Path Selection: Path Selection represents the act of choosing one | * Candidate Path Selection: Candidate Path Selection represents the | |||
or more paths that are available to use based on the Selection | act of choosing one or more paths that are available to use based | |||
Properties provided by the application, the policies and | on the Selection Properties and any available Local and Remote | |||
Endpoints provided by the application, as well as the policies and | ||||
heuristics of a Transport Services system. | heuristics of a Transport Services system. | |||
o Protocol Selection: Protocol Selection represents the act of | * Candidate Protocol Selection: Candidate Protocol Selection | |||
choosing one or more sets of protocol options that are available | represents the act of choosing one or more sets of protocol stacks | |||
to use based on the Transport Properties provided by the | that are available to use based on the Transport Properties | |||
application, and the heuristics or policies within the Transport | provided by the application, and the heuristics or policies within | |||
Services system. | the Transport Services system. | |||
4.2.2. Candidate Racing | 4.2.2. Candidate Racing | |||
o Protocol Option Racing: Protocol Racing is the act of attempting | Connection establishment attempts for a set of candidates may be | |||
to establish, or scheduling attempts to establish, multiple | performed simultaneously, synchronously, serially, or some | |||
Protocol Stacks that differ based on the composition of protocols | combination of all of these. We refer to this process as racing, | |||
or the options used for protocols. | borrowing terminology from Happy Eyeballs [RFC8305]. | |||
o Path Racing: Path Racing is the act of attempting to establish, or | * Protocol Option Racing: Protocol Option Racing is the act of | |||
attempting to establish, or scheduling attempts to establish, | ||||
multiple Protocol Stacks that differ based on the composition of | ||||
protocols or the options used for protocols. | ||||
* 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 | |||
differ based on a selection from the available Paths. Since | differ based on a selection from the available Paths. Since | |||
different Paths will have distinct configurations for local | different Paths will have distinct configurations for local | |||
addresses and DNS servers, attempts across different Paths will | addresses and DNS servers, attempts across different Paths will | |||
perform separate DNS resolution stepss, which can lead to further | perform separate DNS resolution steps, which can lead to further | |||
racing of the resolved Remote Endpoints. | racing of the resolved Remote Endpoints. | |||
o Remote Endpoint Racing: Remote Endpoint Racing is the act of | * Remote Endpoint Racing: Remote Endpoint 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 specific | multiple Protocol Stacks that differ based on the specific | |||
representation of the Remote Endpoint, such as IP addresses | representation of the Remote Endpoint, such as IP addresses | |||
resolved from a DNS hostname. | resolved from a DNS hostname. | |||
4.2.3. Protocol Stack Equivalence | 4.2.3. Protocol Stack Equivalence | |||
The Transport Services architecture defines a mechanism that allows | The Transport Services architecture defines a mechanism that allows | |||
applications to easily use different network paths and Protocol | applications to easily use different network paths and Protocol | |||
Stacks. In some cases, changing which Protocol Stacks or network | Stacks. In some cases, changing which Protocol Stacks or network | |||
skipping to change at page 21, line 16 ¶ | skipping to change at page 21, line 36 ¶ | |||
establishment. This functionality in the API can be a powerful | establishment. This functionality in the API can be a powerful | |||
driver of new protocol adoption, but needs to be constrained | driver of new protocol adoption, but needs to be constrained | |||
carefully to avoid unexpected behavior that can lead to functional or | carefully to avoid unexpected behavior that can lead to functional or | |||
security problems. | security problems. | |||
If two different Protocol Stacks can be safely swapped, or raced in | If two different Protocol Stacks can be safely swapped, or raced in | |||
parallel (see Section 4.2.2), then they are considered to be | parallel (see Section 4.2.2), then they are considered to be | |||
"equivalent". Equivalent Protocol Stacks need to meet the following | "equivalent". Equivalent Protocol Stacks need to meet the following | |||
criteria: | criteria: | |||
1. Both stacks MUST offer the same interface to the application for | 1. Both stacks MUST offer the interface requested by the application | |||
connection establishment and data transmission. For example, if | for connection establishment and data transmission. For example, | |||
one Protocol Stack has UDP as the top-level interface to the | if an application requires preservation of message boundaries, a | |||
application, then it is not equivalent to a Protocol Stack that | Protocol Stack that runs UDP as the top-level interface to the | |||
runs TCP as the top-level interface. Among other differences, | application is not equivalent to a Protocol Stack that runs TCP | |||
the UDP stack would allow an application to read out message | as the top-level interface. A UDP stack would allow an | |||
boundaries based on datagrams sent from the remote system, | application to read out message boundaries based on datagrams | |||
whereas TCP does not preserve message boundaries on its own. | sent from the remote system, whereas TCP does not preserve | |||
message boundaries on its own, but needs a framing protocol on | ||||
top to determine message boundaries. | ||||
2. Both stacks MUST offer the transport services that are required | 2. Both stacks MUST offer the transport services that are requested | |||
by the application. For example, if an application specifies | by the application. For example, if an application specifies | |||
that it requires reliable transmission of data, then a Protocol | that it requires reliable transmission of data, then a Protocol | |||
Stack using UDP without any reliability layer on top would not be | Stack using UDP without any reliability layer on top would not be | |||
allowed to replace a Protocol Stack using TCP. However, if the | allowed to replace a Protocol Stack using TCP. However, if the | |||
application does not require reliability, then a Protocol Stack | application does not require reliability, then a Protocol Stack | |||
that adds reliability could be regarded as an equivalent Protocol | that adds reliability could be regarded as an equivalent Protocol | |||
Stack as long providing this would not conflict with any other | Stack as long as providing this would not conflict with any other | |||
application-requested properties. | application-requested properties. | |||
3. Both stacks MUST offer the same security properties. The | 3. Both stacks MUST offer security protocols and parameters as | |||
inclusion of transport security protocols | requested by the application [I-D.ietf-taps-transport-security]. | |||
[I-D.ietf-taps-transport-security] in a Protocol Stack adds | Security features and properties, such as cryptographic | |||
additional restrictions to Protocol Stack equivalence. Security | algorithms, peer authentication, and identity privacy vary across | |||
features and properties, such as cryptographic algorithms, peer | security protocols, and across versions of security protocols. | |||
authentication, and identity privacy vary across security | Protocol equivalence ought not to be assumed for different | |||
protocols, and across versions of security protocols. Protocol | protocols or protocol versions, even if they offer similar | |||
equivalence ought not to be assumed for different protocols or | application configuration options. To ensure that security | |||
protocol versions, even if they offer similar application | protocols are not incorrectly swapped, Transport Services systems | |||
configuration options. To ensure that security protocols are not | SHOULD only automatically generate equivalent Protocol Stacks | |||
incorrectly swapped, Transport Services systems SHOULD only | when the transport security protocols within the stacks are | |||
automatically generate equivalent Protocol Stacks when the | identical. Specifically, a transport system would consider | |||
transport security protocols within the stacks are identical. | protocols identical only if they are of the same type and | |||
Specifically, a transport system would consider protocols | version. For example, the same version of TLS running over two | |||
identical only if they are of the same type and version. For | different transport protocol stacks are considered equivalent, | |||
example, the same version of TLS running over two different | whereas TLS 1.2 and TLS 1.3 [RFC8446] are not considered | |||
transport protocol stacks are considered equivalent, whereas TLS | equivalent. However, Transport Services systems MAY allow | |||
1.2 and TLS 1.3 [RFC8446] are not considered equivalent. | applications to indicate that they consider two different | |||
transport protocols equivalent, e.g., to allow fallback to TLS | ||||
1.2 if TLS 1.3 is not available. | ||||
4.2.4. Separating Connection Groups | 4.2.4. Separating Connection Groups | |||
By default, all stored properties of the implementation are shared | By default, stored properties of the implementation, such as cached | |||
within a process, such as cached protocol state, cached path state, | protocol state, cached path state, and heuristics, may be shared | |||
and heuristics. This provides efficiency and convenience for the | (e.g. across multiple connections in an application). This provides | |||
application, since the Transport System implementation can | efficiency and convenience for the application, since the Transport | |||
automatically optimize behavior. | System implementation can automatically optimize behavior. | |||
There are several reasons, however, that an application might want to | There are several reasons, however, that an application might want to | |||
isolate some Connections within a single process. These reasons | explicitly isolate some Connections. These reasons include: | |||
include: | ||||
o 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 may include TLS session | |||
state [RFC8446] and HTTP cookies [RFC6265]. | state [RFC8446] and HTTP cookies [RFC6265]. | |||
o 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 (for example, when Connections | |||
are multiplexed HTTP/2 or QUIC streams). | are multiplexed HTTP/2 or QUIC streams). | |||
o Performance concerns about Connections introducing head-of-line | * Performance concerns about Connections introducing head-of-line | |||
blocking due to multiplexing or needing to share state on a single | blocking due to multiplexing or needing to share state on a single | |||
thread. | thread. | |||
The Transport Services API SHOULD allow applications to explicitly | The Transport Services API SHOULD allow applications to explicitly | |||
define Connection Groups that force separation of Cached State and | define Connection Groups that force separation of Cached State and | |||
Protocol Stacks. For example, a web browser application might use | Protocol Stacks. For example, a web browser application might use | |||
Connection Groups with separate caches for different tabs in the | Connection Groups with separate caches for different tabs in the | |||
browser to decrease linkability. | browser to decrease linkability. | |||
The interface to specify these groups MAY expose fine-grained tuning | The interface to specify these groups MAY expose fine-grained tuning | |||
skipping to change at page 23, line 20 ¶ | skipping to change at page 23, line 40 ¶ | |||
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. Transport Services APIs will expose similar functionality | |||
[I-D.ietf-taps-transport-security]. | [I-D.ietf-taps-transport-security]. | |||
As described above in Section 4.2.3, if a Transport Services system | As described above in Section 4.2.3, if a Transport Services system | |||
races between two different Protocol Stacks, both MUST use the same | races between two different Protocol Stacks, both MUST use the same | |||
security protocols and options. | security protocols and options. | |||
Clients need to ensure that security APIs are used appropriately. In | Applications need to ensure that they use security APIs | |||
cases where clients use an interface to provide sensitive keying | appropriately. In cases where applications use an interface to | |||
material, e.g., access to private keys or copies of pre-shared keys | provide sensitive keying material, e.g., access to private keys or | |||
(PSKs), key use needs to be validated. For example, clients ought | copies of pre-shared keys (PSKs), key use needs to be validated. For | |||
not to use PSK material created for the Encapsulating Security | example, applications ought not to use PSK material created for the | |||
Protocol (ESP, part of IPsec) [RFC4303] with QUIC, and clients ought | Encapsulating Security Protocol (ESP, part of IPsec) [RFC4303] with | |||
not to use private keys intended for server authentication as a keys | QUIC, and applications ought not to use private keys intended for | |||
for client authentication. | server authentication as keys for client authentication. | |||
Moreover, Transport Services systems MUST NOT automatically fall back | Moreover, Transport Services systems MUST NOT automatically fall back | |||
from secure protocols to insecure protocols, or to weaker versions of | from secure protocols to insecure protocols, or to weaker versions of | |||
secure protocols. For example, if a client requests TLS, but the | secure protocols. For example, if an application requests TLS, but | |||
desired version of TLS is not available, its connection will fail. | the desired version of TLS is not available, its connection will | |||
Clients are thus responsible for implementing security protocol | fail. Applications are thus responsible for implementing security | |||
fallback or version fallback by creating multiple Transport Services | protocol fallback or version fallback by creating multiple Transport | |||
Connections, if so desired. | Services Connections, if so desired. | |||
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) and No. 688421 (MAMI). | |||
This work has been supported by Leibniz Prize project funds of DFG - | This work has been supported by Leibniz Prize project funds of DFG - | |||
German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ | German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ | |||
FE 570/4-1). | FE 570/4-1). | |||
skipping to change at page 24, line 13 ¶ | skipping to change at page 24, line 34 ¶ | |||
Eyeballs, that heavily influenced this work. | 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., Wood, C., and T. | Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. | |||
Pauly, "An Abstract Application Layer Interface to | Pauly, "An Abstract Application Layer Interface to | |||
Transport Services", draft-ietf-taps-interface-04 (work in | Transport Services", Work in Progress, Internet-Draft, | |||
progress), July 2019. | draft-ietf-taps-interface-05, 4 November 2019, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-taps- | ||||
interface-05.txt>. | ||||
[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/info/rfc2119>. | <https://www.rfc-editor.org/info/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/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/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., Perkins, C., and M. Welzl, | Jones, T., Tiesel, P., Perkins, C., and M. Welzl, | |||
"Implementing Interfaces to Transport Services", draft- | "Implementing Interfaces to Transport Services", Work in | |||
ietf-taps-impl-04 (work in progress), July 2019. | Progress, Internet-Draft, draft-ietf-taps-impl-05, 4 | |||
November 2019, <http://www.ietf.org/internet-drafts/draft- | ||||
ietf-taps-impl-05.txt>. | ||||
[I-D.ietf-taps-minset] | [I-D.ietf-taps-minset] | |||
Welzl, M. and S. Gjessing, "A Minimal Set of Transport | Welzl, M. and S. Gjessing, "A Minimal Set of Transport | |||
Services for End Systems", draft-ietf-taps-minset-11 (work | Services for End Systems", Work in Progress, Internet- | |||
in progress), September 2018. | Draft, draft-ietf-taps-minset-11, 27 September 2018, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-taps- | ||||
minset-11.txt>. | ||||
[I-D.ietf-taps-transport-security] | [I-D.ietf-taps-transport-security] | |||
Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. | Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. | |||
Rose, "A Survey of Transport Security Protocols", draft- | Wood, "A Survey of the Interaction Between Security | |||
ietf-taps-transport-security-09 (work in progress), | Protocols and Transport Services", Work in Progress, | |||
September 2019. | Internet-Draft, draft-ietf-taps-transport-security-10, 17 | |||
November 2019, <http://www.ietf.org/internet-drafts/draft- | ||||
ietf-taps-transport-security-10.txt>. | ||||
[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", | |||
n.d.. | 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/info/rfc793>. | <https://www.rfc-editor.org/info/rfc793>. | |||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | |||
RFC 4303, DOI 10.17487/RFC4303, December 2005, | RFC 4303, DOI 10.17487/RFC4303, December 2005, | |||
<https://www.rfc-editor.org/info/rfc4303>. | <https://www.rfc-editor.org/info/rfc4303>. | |||
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, | |||
skipping to change at page 25, line 29 ¶ | skipping to change at page 26, line 11 ¶ | |||
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | |||
DOI 10.17487/RFC7540, May 2015, | DOI 10.17487/RFC7540, May 2015, | |||
<https://www.rfc-editor.org/info/rfc7540>. | <https://www.rfc-editor.org/info/rfc7540>. | |||
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, | [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, | |||
Ed., "Services Provided by IETF Transport Protocols and | Ed., "Services Provided by IETF Transport Protocols and | |||
Congestion Control Mechanisms", RFC 8095, | Congestion Control Mechanisms", RFC 8095, | |||
DOI 10.17487/RFC8095, March 2017, | DOI 10.17487/RFC8095, March 2017, | |||
<https://www.rfc-editor.org/info/rfc8095>. | <https://www.rfc-editor.org/info/rfc8095>. | |||
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: | ||||
Better Connectivity Using Concurrency", RFC 8305, | ||||
DOI 10.17487/RFC8305, December 2017, | ||||
<https://www.rfc-editor.org/info/rfc8305>. | ||||
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive | ||||
Connectivity Establishment (ICE): A Protocol for Network | ||||
Address Translator (NAT) Traversal", RFC 8445, | ||||
DOI 10.17487/RFC8445, July 2018, | ||||
<https://www.rfc-editor.org/info/rfc8445>. | ||||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
Authors' Addresses | Authors' Addresses | |||
Tommy Pauly (editor) | Tommy Pauly (editor) | |||
Apple Inc. | Apple Inc. | |||
One Apple Park Way | One Apple Park Way | |||
Cupertino, California 95014 | Cupertino, California 95014, | |||
United States of America | United States of America | |||
Email: tpauly@apple.com | Email: tpauly@apple.com | |||
Brian Trammell (editor) | Brian Trammell (editor) | |||
Gustav-Gull-Platz 1 | Gustav-Gull-Platz 1 | |||
8004 Zurich | CH- 8004 Zurich | |||
Switzerland | Switzerland | |||
Email: ietf@trammell.ch | Email: ietf@trammell.ch | |||
Anna Brunstrom | Anna Brunstrom | |||
Karlstad University | Karlstad University | |||
Universitetsgatan 2 | Universitetsgatan 2 | |||
651 88 Karlstad | SE- 651 88 Karlstad | |||
Sweden | Sweden | |||
Email: anna.brunstrom@kau.se | Email: anna.brunstrom@kau.se | |||
Godred Fairhurst | Godred Fairhurst | |||
University of Aberdeen | University of Aberdeen | |||
Fraser Noble Building | Fraser Noble Building | |||
Aberdeen, AB24 3UE | Aberdeen, AB24 3UE | |||
Scotland | ||||
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 | |||
skipping to change at page 26, line 40 ¶ | skipping to change at page 27, line 31 ¶ | |||
TU Berlin | TU Berlin | |||
Einsteinufer 25 | Einsteinufer 25 | |||
10587 Berlin | 10587 Berlin | |||
Germany | Germany | |||
Email: philipp@tiesel.net | Email: philipp@tiesel.net | |||
Chris Wood | Chris Wood | |||
Apple Inc. | Apple Inc. | |||
One Apple Park Way | One Apple Park Way | |||
Cupertino, California 95014 | Cupertino, California 95014, | |||
United States of America | United States of America | |||
Email: cawood@apple.com | Email: cawood@apple.com | |||
End of changes. 140 change blocks. | ||||
361 lines changed or deleted | 410 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |