draft-ietf-taps-arch-04.txt | draft-ietf-taps-arch-05.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: January 9, 2020 Google | Expires: May 7, 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. | |||
July 08, 2019 | November 04, 2019 | |||
An Architecture for Transport Services | An Architecture for Transport Services | |||
draft-ietf-taps-arch-04 | draft-ietf-taps-arch-05 | |||
Abstract | Abstract | |||
This document provides an overview of the architecture of Transport | This document provides an overview of the architecture of Transport | |||
Services, a model for exposing transport protocol features to | Services, a model for exposing transport protocol features to | |||
applications for network communication. In contrast to what is | applications for network communication. In contrast to what is | |||
provided by most existing Application Programming Interfaces (APIs), | provided by most existing Application Programming Interfaces (APIs), | |||
Transport Services 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 | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
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 January 9, 2020. | This Internet-Draft will expire on May 7, 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/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Event-Driven API . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.3. Data Transfer Using Messages . . . . . . . . . . . . . . 5 | 1.3. Specification of Requirements . . . . . . . . . . . . . . 5 | |||
1.4. Flexibile Implementation . . . . . . . . . . . . . . . . 6 | 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 6 | |||
2.1. Specification of Requirements . . . . . . . . . . . . . . 7 | 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 | |||
2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 | ||||
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.1. Common APIs for Common Features . . . . . . . . . . . . . 8 | 3.1. Common APIs for Common Features . . . . . . . . . . . . . 9 | |||
3.2. Access to Specialized Features . . . . . . . . . . . . . 8 | 3.2. Access to Specialized Features . . . . . . . . . . . . . 9 | |||
3.3. Scope for API and Implementation Definitions . . . . . . 9 | 3.3. Scope for API and Implementation Definitions . . . . . . 10 | |||
4. Transport Services Architecture and Concepts . . . . . . . . 10 | 4. Transport Services Architecture and Concepts . . . . . . . . 11 | |||
4.1. Transport Services API Concepts . . . . . . . . . . . . . 11 | 4.1. Transport Services API Concepts . . . . . . . . . . . . . 12 | |||
4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 13 | 4.1.1. Connection Objects . . . . . . . . . . . . . . . . . 14 | |||
4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 14 | 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 15 | |||
4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 15 | 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 16 | |||
4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 16 | 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 17 | |||
4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 16 | 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 18 | |||
4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 17 | 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 18 | |||
4.2. Transport System Implementation Concepts . . . . . . . . 17 | 4.2. Transport System Implementation Concepts . . . . . . . . 18 | |||
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 19 | 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20 | |||
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 19 | 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 20 | |||
4.2.3. Protocol Stack Equivalence . . . . . . . . . . . . . 19 | 4.2.3. Protocol Stack Equivalence . . . . . . . . . . . . . 20 | |||
4.2.4. Separating Connection Groups . . . . . . . . . . . . 21 | 4.2.4. Separating Connection Groups . . . . . . . . . . . . 22 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | |||
8. Informative References . . . . . . . . . . . . . . . . . . . 23 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 24 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
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 | |||
skipping to change at page 3, line 30 ¶ | skipping to change at page 3, line 33 ¶ | |||
This variety can lead to confusion when trying to understand the | This variety can lead to confusion when trying to understand the | |||
similarities and differences between protocols, and how applications | similarities and differences between protocols, and how applications | |||
can use them effectively. | 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 does not only enable | changes to the applications. This flexibility enables faster | |||
faster deployment of new feature and protocols, but it can also | deployment of new features and protocols. It can also support | |||
support applications with 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 is 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 of course not mean that all APIs and | Services Architecture does not require that all APIs and | |||
implementations have to be identical, a common minimal set of | implementations are identical, a common minimal set of features | |||
features represented in a consistent fashion will enable applications | represented in a consistent fashion will enable applications to be | |||
to be easily ported from one system to the another. | easily ported from one system to another. | |||
1.1. Overview | 1.1. Background | |||
The model of using sockets for networking can be represented as | The Transport Services architecture is based on the survey of | |||
follows: applications create connections and transfer data using the | Services Provided by IETF Transport Protocols and Congestion Control | |||
socket API, which provides the interface to the implementations of | Mechanisms [RFC8095], and the distilled minimal set of the features | |||
UDP and TCP (typically implemented in the system's kernel), which in | offered by transport protocols [I-D.ietf-taps-minset]. These | |||
turn send data over the available network layer interfaces. | documents identified common features and patterns across all | |||
transport protocols developed thus far in the IETF. | ||||
Since transport security is an increasingly relevant aspect of using | ||||
transport protocols on the Internet, this architecture also considers | ||||
the impact of transport security protocols on the feature-set exposed | ||||
by transport services [I-D.ietf-taps-transport-security]. | ||||
One of the key insights to come from identifying the minimal set of | ||||
features provided by transport protocols [I-D.ietf-taps-minset] was | ||||
that features either require application interaction and guidance | ||||
(referred to as Functional or Optimizing Features), or else can be | ||||
handled automatically by a system implementing Transport Services | ||||
(referred to as Automatable Features). Among the Functional and | ||||
Optimizing Features, some were common across all or nearly all | ||||
transport protocols, while others could be seen as features that, if | ||||
specified, would only be useful with a subset of protocols, but would | ||||
not harm the functionality of other protocols. For example, some | ||||
protocols can deliver messages faster for applications that do not | ||||
require messages to arrive in the order in which they were sent. | ||||
However, this functionality needs to be explicitly allowed by the | ||||
application, since reordering messages would be undesirable in many | ||||
cases. | ||||
1.2. Overview | ||||
This document describes the Transport Services architecture in three | ||||
sections: | ||||
o Section 2 describes how the API model of Transport Services | ||||
differs from traditional socket-based APIs. Specifically, it | ||||
offers asynchronous event-driven interaction, the use of messages | ||||
for data transfer, and the ability to easily adopt different | ||||
transport protocols. | ||||
o Section 3 explains the design principles that guide the Transport | ||||
Services API. These principles are intended to make sure that | ||||
transport protocols can continue to be enhanced and evolve without | ||||
requiring too many changes by application developers. | ||||
o Section 4 presents the Transport Services architecture diagram and | ||||
defines the concepts that are used by both the API and | ||||
implementation documents. The Preconnection allows applications | ||||
to configure connection properties, and the Connection represents | ||||
an object that can be used to send and receive Messages. | ||||
1.3. Specification of Requirements | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | ||||
"OPTIONAL" in this document are to be interpreted as described in BCP | ||||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
2. API Model | ||||
The traditional model of using sockets for networking can be | ||||
represented as follows: | ||||
o Applications create connections and transfer data using the socket | ||||
API. | ||||
o The socket API provides the interface to the implementations of | ||||
TCP and UDP (typically implemented in the system's kernel). | ||||
o TCP and UDP in the kernel send and receive data over the available | ||||
network layer interfaces. | ||||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| Application | | | Application | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| | | | | | |||
+---------------------+ +-----------------------+ | +---------------------+ +-----------------------+ | |||
| Socket Stream API | | Socket Datagram API | | | Socket Stream API | | Socket Datagram API | | |||
+---------------------+ +-----------------------+ | +---------------------+ +-----------------------+ | |||
| | | | | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
skipping to change at page 4, line 50 ¶ | skipping to change at page 6, line 26 ¶ | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| | | | |||
+-----------------------------------------------------+ | +-----------------------------------------------------+ | |||
| 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 into 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 a few key departures that Transport Services makes from the | There are key differences between the architecture of the Transport | |||
sockets API: it presents an asynchronous, event-driven API; it uses | Services system and the architecture of the sockets API: it presents | |||
messages for representing data transfer to applications; and it | an asynchronous, event-driven API; it uses messages for representing | |||
assumes an implementation that can use multiple IP addresses, | data transfer to applications; and it assumes an implementation that | |||
multiple protocols, multiple paths, and provide multiple application | can use multiple IP addresses, multiple protocols, multiple paths, | |||
streams. | and provide multiple application streams. | |||
1.2. 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. When sockets are presented | |||
as an asynchronous interface, they generally use a try-and-fail | as an asynchronous interface, they generally use 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 | All interaction with a Transport Services system is expected to be | |||
asynchronous, and use an event-driven model unlike sockets | asynchronous, and use an event-driven model unlike sockets | |||
Section 4.1.5. For example, if the application wants to read, its | Section 4.1.5. For example, if the application wants to read, its | |||
call to read will not fail, but will deliver an event containing the | call to read will not fail, but will deliver an event containing the | |||
received data once it is available. | received data once it is available. | |||
The Transport Services API also delivers events regarding the | The Transport Services API also delivers events regarding the | |||
lifetime of a connection and changes to 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 much simpler 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. | |||
1.3. 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; TLS record headers carry a version, content type, and | over a stream [RFC7230]; TLS record headers carry a version, content | |||
length; and HTTP/2 uses frames to segment its headers and bodies. | type, and length [RFC8446]; and HTTP/2 uses frames to segment its | |||
headers and bodies [RFC7540]. | ||||
The Transport Services API represents data as messages, so that it | The Transport Services API represents data as messages, so that it | |||
more closely matches the way applications use the network. Messages | more closely matches the way applications use the network. Messages | |||
seamlessly work with transport protocols that support datagrams or | seamlessly work with transport protocols that support datagrams or | |||
records, but can also be used over a stream by defining an | records, but can also be used over a stream by defining an | |||
application-layer framer Section 4.1.4. When framing protocols are | application-layer framer Section 4.1.4. When framing protocols are | |||
placed on top of unstructured streams, the messages used in the API | placed on top of unstructured streams, the messages used in the API | |||
represent the framed messages within the stream. In the absence of a | represent the framed messages within the stream. In the absence of a | |||
framer, protocols that deal only in byte streams, such as TCP, | framer, protocols that deal only in byte streams, such as TCP, | |||
represent their data in each direction as a single, long message. | represent their data in each direction as a single, long message. | |||
skipping to change at page 6, line 39 ¶ | skipping to change at page 8, line 16 ¶ | |||
underlaying transport connections to utilize multi-streaming and | underlaying 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. | |||
1.4. 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. | |||
Transport Services implementations are meant to be flexible at | Transport Services implementations are meant to be flexible at | |||
skipping to change at page 7, line 16 ¶ | skipping to change at page 8, line 41 ¶ | |||
used by a Transport Services implementation for resolution, path | used by a Transport Services implementation for resolution, path | |||
selection, and racing. | selection, and racing. | |||
Flexibility after connection establishment is also important. | Flexibility after connection establishment is also important. | |||
Transport protocols that can migrate between multiple network-layer | Transport protocols that can migrate between multiple network-layer | |||
interfaces need to be able to process and react to interface changes. | interfaces need to be able to process and react to interface changes. | |||
Protocols that support multiple application-layer streams need to | Protocols that support multiple application-layer streams need to | |||
support initiating and receiving new streams using existing | support initiating and receiving new streams using existing | |||
connections. | connections. | |||
2. Background | ||||
The Transport Services architecture is based on the survey of | ||||
Services Provided by IETF Transport Protocols and Congestion Control | ||||
Mechanisms [RFC8095], and the distilled minimal set of the features | ||||
offered by transport protocols [I-D.ietf-taps-minset]. These | ||||
documents identified common features and patterns across all | ||||
transport protocols developed thus far in the IETF. | ||||
Since transport security is an increasingly relevant aspect of using | ||||
transport protocols on the Internet, this architecture also considers | ||||
the impact of transport security protocols on the feature-set exposed | ||||
by transport services [I-D.ietf-taps-transport-security]. | ||||
One of the key insights to come from identifying the minimal set of | ||||
features provided by transport protocols [I-D.ietf-taps-minset] was | ||||
that features either require application interaction and guidance | ||||
(referred to as Functional Features), or else can be handled | ||||
automatically by a system implementing Transport Services (referred | ||||
to as Automatable Features). Among the Functional Features, some | ||||
were common across all or nearly all transport protocols, while | ||||
others could be seen as features that, if specified, would only be | ||||
useful with a subset of protocols, but would not harm the | ||||
functionality of other protocols. For example, some protocols can | ||||
deliver messages faster for applications that do not require messages | ||||
to arrive in the order in which they were sent. However, this | ||||
functionality needs to be explicitly allowed by the application, | ||||
since reordering messages would be undesirable in many cases. | ||||
2.1. Specification of Requirements | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | ||||
"OPTIONAL" in this document are to be interpreted as described in BCP | ||||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
3. Design Principles | 3. Design Principles | |||
The goal of the Transport Services architecture is to redefine the | The goal of the Transport Services architecture is to redefine the | |||
interface between applications and transports in a way that allows | interface between applications and transports in a way that allows | |||
the transport layer to evolve and improve without fundamentally | the transport layer to evolve and improve without fundamentally | |||
changing the contract with the application. This requires a careful | changing the contract with the application. This requires a careful | |||
consideration of how to expose the capabilities of protocols. | consideration of how to expose the capabilities of protocols. | |||
There are several degrees in which a Transport Services system can | There are several degrees in which a Transport Services system is | |||
offer flexibility to an application: it can provide access to | intended to offer flexibility to an application: it can provide | |||
multiple sets of protocols and protocol features; it can use these | access to multiple sets of protocols and protocol features; it can | |||
protocols across multiple paths that could have different performance | use these protocols across multiple paths that could have different | |||
and functional characteristics; and it can communicate with different | performance and functional characteristics; and it can communicate | |||
remote systems to optimize performance, robustness to failure, or | with different remote systems to optimize performance, robustness to | |||
some other metric. Beyond these, if the API for the system remains | failure, or some other metric. Beyond these, if the API for the | |||
the same over time, new protocols and features could be added to the | system remains the same over time, new protocols and features could | |||
system's implementation without requiring changes in applications for | be added to the system's implementation without requiring changes in | |||
adoption. | applications for adoption. | |||
The following considerations were used in the design of this | ||||
architecture. | ||||
3.1. Common APIs for Common Features | 3.1. Common APIs for Common Features | |||
Functionality that is common across multiple transport protocols | Functionality that is common across multiple transport protocols | |||
SHOULD be accessible through a unified set of API calls. An | SHOULD be accessible through a unified set of API calls. An | |||
application ought to be able to implement logic for its basic use of | application ought to be able to implement logic for its basic use of | |||
transport networking (establishing the transport, and sending and | transport networking (establishing the transport, and sending and | |||
receiving data) once, and expect that implementation to continue to | receiving data) once, and expect that implementation to continue to | |||
function as the transports change. | function as the transports change. | |||
Any Transport Services API is REQUIRED to allow access to the | Any Transport Services API is REQUIRED to allow access to the | |||
distilled minimal set of features offered by transport protocols | distilled minimal set of features offered by transport protocols | |||
[I-D.ietf-taps-minset]. | [I-D.ietf-taps-minset]. | |||
3.2. Access to Specialized Features | 3.2. Access to Specialized Features | |||
There are applications that will need to control fine-grained details | There are applications that will need to control fine-grained details | |||
of transport protocols to optimize their behavior and ensure | of transport protocols to optimize their behavior and ensure | |||
compatibility with remote systems. A Transport Services system | compatibility with remote systems. A Transport Services system | |||
therefore SHOULD also permit more specialized protocol features to be | therefore SHOULD also permit more specialized protocol features to be | |||
used. The interface for these specialized options should be exposed | used. The interface for these specialized options ought to be | |||
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 for | |||
constrained checksum usage, communication would not fail when a | constrained checksum usage, communication would not fail when a | |||
protocol such as TCP is selected, which uses a checksum covering the | protocol such as TCP is selected, which uses a checksum covering the | |||
entire payload. | entire 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 encryption of its transport | |||
data, only protocol stacks that include some transport security | data, only protocol stacks that include a transport security function | |||
protocol are eligible to be used. A Transport Services API MUST | are eligible to be used. A Transport Services API MUST allow | |||
allow applications to define such requirements and constrain the | applications to define such requirements and constrain the system's | |||
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 | |||
and encourage flexibility. The abstract API definition | and encourage flexibility. The abstract API definition | |||
[I-D.ietf-taps-interface] describes this interface and is aimed at | [I-D.ietf-taps-interface] describes this interface and how it can be | |||
application developers. | exposed to application developers. | |||
Implementations that provide the Transport Services API | Implementations that provide the Transport Services API | |||
[I-D.ietf-taps-impl] will vary due to system-specific support and the | [I-D.ietf-taps-impl] will vary due to system-specific support and the | |||
needs of the deployment scenario. It is expected that all | needs of the deployment scenario. It is expected that all | |||
implementations of Transport Services will offer the entire mandatory | implementations of Transport Services will offer the entire mandatory | |||
API, but that some features will not be functional in certain | API. All implementations are REQUIRED to offer an API that is | |||
implementations. All implementations are REQUIRED to offer | sufficient to use the distilled minimal set of features offered by | |||
sufficient APIs to use the distilled minimal set of features offered | transport protocols [I-D.ietf-taps-minset], including API support for | |||
by transport protocols [I-D.ietf-taps-minset], including API support | TCP and UDP transport. However, some features provided by this API | |||
for TCP and UDP transport, but it is possible that some very | will not be functional in certain implementations. For example, it | |||
constrained devices might not have, for example, a full TCP | is possible that some very constrained devices might not have a full | |||
implementation beneath the API. | TCP implementation beneath the API. | |||
To preserve flexibility and compatibility with future protocols, top- | To preserve flexibility and compatibility with future protocols, top- | |||
level features in the Transport Services API SHOULD avoid referencing | level features in the Transport Services API SHOULD avoid referencing | |||
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 this document will be | existing protocols. It is expected that [I-D.ietf-taps-interface] | |||
updated and supplemented as new protocols and protocol features are | will be updated and supplemented as new protocols and protocol | |||
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] defines new protocols that require any changes | [I-D.ietf-taps-impl] define new protocols or protocol capabilities | |||
to a remote system. The Transport Services system MUST be deployable | that affect what is communicated across the network. The Transport | |||
on one side only. | Services system MUST be deployable on one side only. A Transport | |||
Services system acting as a connection initiator can communicate with | ||||
any existing system that implements the transport protocol(s) | ||||
selected by the Transport Services system. Similarly, a Transport | ||||
Services system acting as a listener can 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 11, line 42 ¶ | skipping to change at page 12, line 42 ¶ | |||
+-------------+ 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 basic | 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 send and receive data. These could be exposed as | communication, and then send and receive data. These could be | |||
handles or referenced objects, depending on the language. | exposed as handles or referenced objects, depending on the language. | |||
Beyond the basic 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 | o 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 be defined to apply to multiple transport | |||
protocols. Properties specified during Pre-Establishment can have | protocols. Properties specified during Pre-Establishment can have | |||
a large impact on the rest of the interface: they modify how | a large impact on the rest of the interface: they modify how | |||
establishment occurs, they influence the expectations around data | establishment occurs, they influence the expectations around data | |||
transfer, and they determine the set of events that will be | transfer, and they determine the set of events that will be | |||
supported. | supported. | |||
o Establishment (Section 4.1.3) focuses on the actions that an | o Establishment (Section 4.1.3) focuses on the actions that an | |||
application takes on the basic 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 | o 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 | o Event Handling (Section 4.1.5) defines the set of properties about | |||
which an application can receive notifications during the lifetime | which an application can receive notifications during the lifetime | |||
of transport objects. Events MAY also provide opportunities for | of transport objects. Events MAY also provide opportunities for | |||
the application to interact with the underlying transport by | the application to interact with the underlying transport by | |||
querying state or updating maintenance options. | querying state or updating maintenance options. | |||
o Termination (Section 4.1.6) focuses on the methods by which data | o 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 taken | The diagram below provides a high-level view of the actions and | |||
during the lifetime of a connection. Note that some actions are | events during the lifetime of a connection. Note that some actions | |||
alternatives (e.g., whether to initiate a connection or to listen for | are alternatives (e.g., whether to initiate a connection or to listen | |||
incoming connections), others are optional (e.g., setting Connection | for incoming connections), others are optional (e.g., setting | |||
and Message Properties in Pre-Establishment), or have been omitted | Connection and Message Properties in Pre-Establishment), or have been | |||
for brevity. | omitted for brevity. | |||
Pre-Establishment : Established : Termination | Pre-Establishment : Established : Termination | |||
----------------- : ----------- : ----------- | ----------------- : ----------- : ----------- | |||
: Close() : | : Close() : | |||
+---------------+ Initiate() +------------+ Abort() : | +---------------+ Initiate() +------------+ Abort() : | |||
+-->| Preconnection |----------->| Connection |---------------> Closed | +-->| Preconnection |------------->| Connection |-----------> Closed | |||
| +---------------+ : +------------+ Connection: | | +---------------+ Rendezvous() +------------+ Conn. : | |||
| : ^ ^ ^ | Finished : | | : ^ | Finished : | |||
+-- Local Endpoint : | | | | : | +-- Local Endpoint : | | : | |||
| : | | | +---------+ : | | : | | : | |||
+-- Remote Endpoint : +----+ | +-----+ | : | +-- Remote Endpoint : | v : | |||
| : | |Send() | | : | | : | Connection : | |||
+-- Selection Properties : | +---------+ | v : | +-- Selection Properties : | Ready : | |||
+-- Connection Properties ---+ | Message | | Message : | +-- Connection Properties : | : | |||
+-- Message Properties -------->| to send | | Received : | +-- Message Properties : | : | |||
| : +---------+ | : | | : | : | |||
| +----------+ : | : | | +----------+ : | : | |||
+-->| Listener |------------------------------+ : | +-->| Listener |----------------------+ : | |||
+----------+ Connection Received : | +----------+ Connection Received : | |||
^ : : | ^ : : | |||
| : : | | : : | |||
Listen() : : | Listen() : : | |||
Figure 4: The lifetime of a connection | Figure 4: The lifetime of a connection | |||
4.1.1. Basic Objects | 4.1.1. Connection Objects | |||
o Preconnection: A Preconnection object is a representation of a | o 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 Selection Properties | |||
(Section 4.1.2) that influence the paths and protocols a | (Section 4.1.2) that influence the paths and protocols a | |||
Connection will use. A Preconnection can be fully specified and | Connection will use. A Preconnection can be fully specified such | |||
represent a single possible Connection, or it can be partially | that it represents a single possible Connection, or it can be | |||
specified such that it represents a family of possible | partially specified such that it represents a family of possible | |||
Connections. The Local Endpoint (Section 4.1.2) MUST be specified | Connections. The Local Endpoint (Section 4.1.2) MUST be specified | |||
if the Preconnection is used to Listen for incoming connections. | if the Preconnection is used to Listen for incoming connections. | |||
The Local Endpoint is OPTIONAL if it is used to Initiate | The Local Endpoint is OPTIONAL if it is used to Initiate | |||
connections. The Remote Endpoint MUST be specified in the | connections. The Remote Endpoint MUST be specified in the | |||
Preconnection is used to Initiate connections. The Remote | Preconnection that is used to Initiate connections. The Remote | |||
Endpoint is OPTIONAL if it is used to Listen for incoming | Endpoint is OPTIONAL if it is used to Listen for incoming | |||
connections. The Local Endpoint and the Remote Endpoint MUST both | connections. The Local Endpoint and the Remote Endpoint MUST both | |||
be specified if a peer-to-peer Rendezvous is to occur based on the | be specified if a peer-to-peer Rendezvous is to occur based on the | |||
Preconnection. | Preconnection. | |||
* Transport Properties: Transport Properties can be specified as | o Transport Properties: Transport Properties can be specified as | |||
part of a Preconnection to allow the application to configure | part of a Preconnection to allow the application to configure the | |||
the Transport System and express their requirements, | Transport System and express their requirements, prohibitions, and | |||
prohibitions, and preferences. There are three kinds of | preferences. There are three kinds of Transport Properties: | |||
Transport Properties: Selection Properties (Section 4.1.2), | ||||
Connection Properties (Section 4.1.2), and Message Properties | * Selection Properties (Section 4.1.2) | |||
(Section 4.1.4). Message Properties can also be specified | ||||
during data transfer to affect specific Messages. | * Connection Properties (Section 4.1.2) | |||
* and Message Properties (Section 4.1.4); note that Message | ||||
Properties can also be specified during data transfer to affect | ||||
specific Messages. | ||||
o Connection: A Connection object represents one or more active | o 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 instance, 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 | |||
skipping to change at page 15, line 24 ¶ | skipping to change at page 16, line 29 ¶ | |||
behavior of the Transport System. For example, a protocol- | behavior of the Transport System. For example, a protocol- | |||
specific Connection Property can express that if UDP is used, the | specific 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 MAY 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 SHOULD be specified on a Preconnection prior to | |||
Connection establishment, but MAY be modified later. Changes made | Connection establishment, but MAY be modified later. Changes made | |||
to Connection Properties after establishment take effect on a | to Connection Properties after establishment take effect on a | |||
best-effort basis. | best-effort basis. Such changes do not affect protocol or path | |||
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 | o 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 be able to send and/or receive Messages. | local or remote state to enable the transmission of Messages. For | |||
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. The process of identifying options for connecting, such as | |||
resolution of the Remote Endpoint, occurs in response the Initiate | resolution of the Remote Endpoint, occurs in response the Initiate | |||
call. | call. | |||
o Listen: The action of marking a Listener as willing to accept | o Listen: The action of marking a Listener as willing to accept | |||
incoming Connections. The Listener will then create Connection | incoming Connections. The Listener will then create Connection | |||
objects as incoming connections are accepted (Section 4.1.5). | objects as incoming connections are accepted (Section 4.1.5). | |||
o Rendezvous: The action of establishing a peer-to-peer connection | o Rendezvous: The action of establishing a peer-to-peer connection | |||
skipping to change at page 16, line 13 ¶ | skipping to change at page 17, line 18 ¶ | |||
established peer-to-peer connection. | established 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 | o 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. If a received Message is incomplete or corrupted, it | Messages. Boundaries of a Message might or might not be | |||
might or might not be usable by certain applications. Boundaries | understood or transmitted by transport protocols. Specifically, | |||
of a Message might or might not be understood or transmitted by | what one application considers to be two Messages sent on a | |||
transport protocols. Specifically, what one application considers | stream-based transport can be treated as a single Message by the | |||
to be two Messages sent on a stream-based transport can be treated | application on the other side. | |||
as a single Message by the application on the other side. | ||||
o Message Properties: Message Properties can be used to annotate | o Message Properties: Message Properties can be used to annotate | |||
specific Messages. These properties can specify how the transport | specific Messages. These properties might only apply to how | |||
will send the Message (for prioritization and reliability), along | Message is sent (such as how the transport will treat | |||
with any per-protocol properties to send with the Message. | prioritization and reliability), but can also include properties | |||
Message Properties MAY be set on a Preconnection to define | that specific protocols encode and communicate to the Remote | |||
defaults properties for sending. When receiving Messages, Message | Endpoint. Message Properties MAY be set on a Preconnection to | |||
Properties can contain per-protocol properties. | define defaults properties for sending. When receiving Messages, | |||
Message Properties can contain per-protocol properties for | ||||
properties that are sent between the endpoints. | ||||
o Send: The action to transmit a Message or partial Message over a | o Send: The action to transmit a Message or partial Message over a | |||
Connection to the remote system. The interface to Send MAY | Connection to the remote system. The interface to Send MAY | |||
include Message Properties specific to how the Message's content | include Message Properties specific to how the Message content is | |||
is to be sent. Status of the Send operation can be delivered back | to be sent. The status of the Send operation can be delivered | |||
to the application in an event (Section 4.1.5). | back to the sending application in an event (Section 4.1.5). | |||
o Receive: An action that indicates that the application is ready to | o 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 | o 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-level 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 list of events that can be delivered to an application is not | This section provides the top-level categories of events events that | |||
exhaustive, but gives the top-level categories of events. The API | can be delivered to an application. This list is not exhaustive. | |||
MAY expand this list. | ||||
o Connection Ready: Signals to an application that a given | o 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 | o 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. | |||
skipping to change at page 17, line 45 ¶ | skipping to change at page 18, line 50 ¶ | |||
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. | |||
o Abort: The action the application takes on a Connection to | o 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. | |||
4.2. Transport System Implementation Concepts | 4.2. Transport System Implementation Concepts | |||
The Transport System Implementation Concepts define the set of | This section defines the set of objects used internally to a system | |||
objects used internally to a system or library to implement the | or library to implement the functionality needed to provide a | |||
functionality needed to provide a transport service across a network, | transport service across a network, as required by the abstract | |||
as required by the abstract interface. | interface. | |||
o Connection Group: A set of Connections that share properties and | o 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 be multiplexed | within the same Connection Group are allowed to be multiplexed | |||
together. Applications can use their explicitly defined | together. An application can explicitly define Connection Groups | |||
Connection Groups to control caching boundaries, as discussed in | to control caching boundaries, as discussed in Section 4.2.4. | |||
Section 4.2.4. | ||||
o Path: Represents an available set of properties that a local | o 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 | o Protocol Instance: A single instance of one protocol, including | |||
any state it has necessary to establish connectivity or send and | any state necessary to establish connectivity or send and receive | |||
receive Messages. | Messages. | |||
o Protocol Stack: A set of Protocol Instances (including relevant | o 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). | |||
skipping to change at page 19, line 15 ¶ | skipping to change at page 20, line 17 ¶ | |||
4.2.1. Candidate Gathering | 4.2.1. Candidate Gathering | |||
o Path Selection: Path Selection represents the act of choosing one | o Path Selection: Path Selection represents the act of choosing one | |||
or more paths that are available to use based on the Selection | or more paths that are available to use based on the Selection | |||
Properties provided by the application, the policies and | Properties provided by the application, the policies and | |||
heuristics of a Transport Services system. | heuristics of a Transport Services system. | |||
o Protocol Selection: Protocol Selection represents the act of | o Protocol Selection: Protocol Selection represents the act of | |||
choosing one or more sets of protocol options that are available | choosing one or more sets of protocol options that are available | |||
to use based on the Transport Properties provided by the | to use based on the Transport Properties provided by the | |||
application, and a Transport Services system's policies and | application, and the heuristics or policies within the Transport | |||
heuristics. | Services system. | |||
4.2.2. Candidate Racing | 4.2.2. Candidate Racing | |||
o Protocol Option Racing: Protocol Racing is the act of attempting | o Protocol Option Racing: Protocol Racing is the act of attempting | |||
to establish, or scheduling attempts to establish, multiple | to establish, or scheduling attempts to establish, multiple | |||
Protocol Stacks that differ based on the composition of protocols | Protocol Stacks that differ based on the composition of protocols | |||
or the options used for protocols. | or the options used for protocols. | |||
o Path Racing: Path Racing is the act of attempting to establish, or | o Path Racing: Path Racing is the act of attempting to establish, or | |||
scheduling attempts to establish, multiple Protocol Stacks that | scheduling attempts to establish, multiple Protocol Stacks that | |||
skipping to change at page 19, line 43 ¶ | skipping to change at page 20, line 45 ¶ | |||
o Remote Endpoint Racing: Remote Endpoint Racing is the act of | o 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. Transitioning between different Protocol Stacks is in some | Stacks. In some cases, changing which Protocol Stacks or network | |||
cases controlled by properties that only change when application code | paths are used will require updating the preferences expressed by the | |||
is updated. For example, an application can enable the use of a | application that uses the Transport Services system. For example, an | |||
multipath or multistreaming transport protocol by modifying the | application can enable the use of a multipath or multistreaming | |||
properties in its Pre-Connection configuration. In some cases, | transport protocol by modifying the properties in its Pre-Connection | |||
however, the Transport Services system will be able to automatically | configuration. In some cases, however, the Transport Services system | |||
change Protocol Stacks without an update to the application, either | will be able to automatically change Protocol Stacks without an | |||
by selecting a new stack entirely, or by racing multiple candidate | update to the application, either by selecting a new stack entirely, | |||
Protocol Stacks during connection establishment. This functionality | or by racing multiple candidate Protocol Stacks during connection | |||
can be a powerful driver of new protocol adoption, but needs to be | establishment. This functionality in the API can be a powerful | |||
constrained carefully to avoid unexpected behavior that can lead to | driver of new protocol adoption, but needs to be constrained | |||
functional or security problems. | carefully to avoid unexpected behavior that can lead to functional or | |||
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 same interface to the application for | |||
connection establishment and data transmission. For example, if | connection establishment and data transmission. For example, if | |||
one Protocol Stack has UDP as the top-level interface to the | one Protocol Stack has UDP as the top-level interface to the | |||
application, then it is not equivalent to a Protocol Stack that | application, then it is not equivalent to a Protocol Stack that | |||
runs TCP as the top-level interface. Among other differences, | runs TCP as the top-level interface. Among other differences, | |||
the UDP stack would allow an application to read out message | the UDP stack would allow an application to read out message | |||
boundaries based on datagrams sent from the remote system, | boundaries based on datagrams sent from the remote system, | |||
whereas TCP does not preserve message boundaries on its own. | whereas TCP does not preserve message boundaries on its own. | |||
2. Both stacks MUST offer the same transport services, as required | 2. Both stacks MUST offer the transport services that are required | |||
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 unnecessary reliability might be allowed as an | that adds reliability could be regarded as an equivalent Protocol | |||
equivalent Protocol Stack as long as it does not conflict with | Stack as long providing this would not conflict with any other | |||
any other application-requested properties. | application-requested properties. | |||
3. Both stacks MUST offer the same security properties. The | 3. Both stacks MUST offer the same security properties. The | |||
inclusion of transport security protocols | inclusion of transport security protocols | |||
[I-D.ietf-taps-transport-security] in a Protocol Stack adds | [I-D.ietf-taps-transport-security] in a Protocol Stack adds | |||
additional restrictions to Protocol Stack equivalence. Security | additional restrictions to Protocol Stack equivalence. Security | |||
features and properties, such as cryptographic algorithms, peer | features and properties, such as cryptographic algorithms, peer | |||
authentication, and identity privacy vary across security | authentication, and identity privacy vary across security | |||
protocols, and across versions of security protocols. Protocol | protocols, and across versions of security protocols. Protocol | |||
equivalence ought not to be assumed for different protocols or | equivalence ought not to be assumed for different protocols or | |||
protocol versions, even if they offer similar application | protocol versions, even if they offer similar application | |||
skipping to change at page 21, line 7 ¶ | skipping to change at page 22, line 9 ¶ | |||
automatically generate equivalent Protocol Stacks when the | automatically generate equivalent Protocol Stacks when the | |||
transport security protocols within the stacks are identical. | transport security protocols within the stacks are identical. | |||
Specifically, a transport system would consider protocols | Specifically, a transport system would consider protocols | |||
identical only if they are of the same type and version. For | identical only if they are of the same type and version. For | |||
example, the same version of TLS running over two different | example, the same version of TLS running over two different | |||
transport protocol stacks are considered equivalent, whereas TLS | transport protocol stacks are considered equivalent, whereas TLS | |||
1.2 and TLS 1.3 [RFC8446] are not considered equivalent. | 1.2 and TLS 1.3 [RFC8446] are not considered equivalent. | |||
4.2.4. Separating Connection Groups | 4.2.4. Separating Connection Groups | |||
By default, all stored properties of the Implementation are shared | By default, all stored properties of the implementation are shared | |||
within a process, such as cached protocol state, cached path state, | within a process, such as cached protocol state, cached path state, | |||
and heuristics. This provides efficiency and convenience for the | and heuristics. This provides efficiency and convenience for the | |||
application, since the Transport System Implementation can | application, since the Transport System implementation can | |||
automatically optimize behavior. | 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 | isolate some Connections within a single process. These reasons | |||
include: | include: | |||
o Privacy concerns about re-using cached protocol state that can | o 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]. | |||
skipping to change at page 21, line 36 ¶ | skipping to change at page 22, line 38 ¶ | |||
o Performance concerns about Connections introducing head-of-line | o 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 | |||
for which properties and cached state is allowed to be shared with | for which properties and cached state is allowed to be shared with | |||
other Connections. For example, an application might want to allow | other Connections. For example, an application might want to allow | |||
sharing TCP Fast Open cookies across groups, but not TLS session | sharing TCP Fast Open cookies across groups, but not TLS session | |||
state. | state. | |||
5. IANA Considerations | 5. IANA Considerations | |||
RFC-EDITOR: Please remove this section before publication. | RFC-EDITOR: Please remove this section before publication. | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
skipping to change at page 22, line 23 ¶ | skipping to change at page 23, line 29 ¶ | |||
Clients need to ensure that security APIs are used appropriately. In | Clients need to ensure that security APIs are used appropriately. In | |||
cases where clients use an interface to provide sensitive keying | cases where clients use an interface to provide sensitive keying | |||
material, e.g., access to private keys or copies of pre-shared keys | material, e.g., access to private keys or copies of pre-shared keys | |||
(PSKs), key use needs to be validated. For example, clients ought | (PSKs), key use needs to be validated. For example, clients ought | |||
not to use PSK material created for the Encapsulating Security | not to use PSK material created for the Encapsulating Security | |||
Protocol (ESP, part of IPsec) [RFC4303] with QUIC, and clients ought | Protocol (ESP, part of IPsec) [RFC4303] with QUIC, and clients ought | |||
not to use private keys intended for server authentication as a keys | not to use private keys intended for server authentication as a keys | |||
for client authentication. | for client authentication. | |||
Moreover, unlike certain transport features such as TCP Fast Open | Moreover, Transport Services systems MUST NOT automatically fall back | |||
(TFO) [RFC7413] or Explicit Congestion Notification (ECN) [RFC3168] | from secure protocols to insecure protocols, or to weaker versions of | |||
which can fall back to standard configurations, Transport Services | secure protocols. For example, if a client requests TLS, but the | |||
systems MUST prohibit fallback for security protocols. For example, | desired version of TLS is not available, its connection will fail. | |||
if a client requests TLS, yet TLS or the desired version are not | Clients are thus responsible for implementing security protocol | |||
available, its connection will fail. Clients are thus responsible | fallback or version fallback by creating multiple Transport Services | |||
for implementing security protocol fallback or version fallback by | Connections, if so desired. | |||
creating multiple Transport 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). | |||
This work has been supported by the UK Engineering and Physical | This work has been supported by the UK Engineering and Physical | |||
Sciences Research Council under grant EP/R04144X/1. | Sciences Research Council under grant EP/R04144X/1. | |||
Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric | Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric | |||
Kinnear for their implementation and design efforts, including Happy | Kinnear for their implementation and design efforts, including Happy | |||
Eyeballs, that heavily influenced this work. | Eyeballs, that heavily influenced this work. | |||
8. Informative References | 8. References | |||
8.1. Normative References | ||||
[I-D.ietf-taps-interface] | ||||
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., | ||||
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. | ||||
Pauly, "An Abstract Application Layer Interface to | ||||
Transport Services", draft-ietf-taps-interface-04 (work in | ||||
progress), July 2019. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, | ||||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
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", draft- | |||
ietf-taps-impl-03 (work in progress), March 2019. | ietf-taps-impl-04 (work in progress), July 2019. | |||
[I-D.ietf-taps-interface] | ||||
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., | ||||
Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An | ||||
Abstract Application Layer Interface to Transport | ||||
Services", draft-ietf-taps-interface-03 (work in | ||||
progress), March 2019. | ||||
[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", draft-ietf-taps-minset-11 (work | |||
in progress), September 2018. | in progress), September 2018. | |||
[I-D.ietf-taps-transport-security] | [I-D.ietf-taps-transport-security] | |||
Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. | Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. | |||
Rose, "A Survey of Transport Security Protocols", draft- | Rose, "A Survey of Transport Security Protocols", draft- | |||
ietf-taps-transport-security-06 (work in progress), March | ietf-taps-transport-security-09 (work in progress), | |||
2019. | September 2019. | |||
[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.. | n.d.. | |||
[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>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, | ||||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | ||||
of Explicit Congestion Notification (ECN) to IP", | ||||
RFC 3168, DOI 10.17487/RFC3168, September 2001, | ||||
<https://www.rfc-editor.org/info/rfc3168>. | ||||
[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, | |||
DOI 10.17487/RFC6265, April 2011, | DOI 10.17487/RFC6265, April 2011, | |||
<https://www.rfc-editor.org/info/rfc6265>. | <https://www.rfc-editor.org/info/rfc6265>. | |||
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
<https://www.rfc-editor.org/info/rfc7413>. | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7230>. | ||||
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | ||||
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | ||||
DOI 10.17487/RFC7540, May 2015, | ||||
<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>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[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 | |||
End of changes. 58 change blocks. | ||||
257 lines changed or deleted | 302 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/ |