draft-ietf-taps-arch-00.txt   draft-ietf-taps-arch-01.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational B. Trammell, Ed. Intended status: Informational B. Trammell, Ed.
Expires: November 1, 2018 ETH Zurich Expires: January 2, 2019 ETH Zurich
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.
April 30, 2018 July 01, 2018
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-00 draft-ietf-taps-arch-01
Abstract Abstract
This document provides an overview of the architecture of Transport This document provides an overview of the architecture of Transport
Services, a system for exposing the features of transport protocols Services, a system for exposing the features of transport protocols
to applications. This architecture serves as a basis for Application to applications. This architecture serves as a basis for Application
Programming Interfaces (APIs) and implementations that provide Programming Interfaces (APIs) and implementations that provide
flexible transport networking services. It defines the common set of flexible transport networking services. It defines the common set of
terminology and concepts to be used in more detailed discussion of terminology and concepts to be used in more detailed discussion of
Transport Services. Transport Services.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 November 1, 2018. This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.3. Scope for API and Implementation Definitions . . . . . . 5 3.3. Scope for API and Implementation Definitions . . . . . . 5
4. Transport Services Architecture and Concepts . . . . . . . . 6 4. Transport Services Architecture and Concepts . . . . . . . . 6
4.1. Transport Services API Concepts . . . . . . . . . . . . . 7 4.1. Transport Services API Concepts . . . . . . . . . . . . . 7
4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 10 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 10
4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 11 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 11
4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 11 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 11
4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 12 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 12
4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 13 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 13
4.2. Transport System Implementation Concepts . . . . . . . . 13 4.2. Transport System Implementation Concepts . . . . . . . . 13
4.2.1. Gathering . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 14
4.2.2. Racing . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 14
4.2.3. Message Framing, Parsing, and Serialization . . . . . 14 4.3. Protocol Stack Equivalence . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4.3.1. Transport Security Equivalence . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4.4. Message Framing, Parsing, and Serialization . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Informative References . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Many APIs to perform transport networking have been deployed, perhaps Many APIs to perform transport networking have been deployed, perhaps
the most widely known and imitated being the BSD socket() interface. the most widely known and imitated being the BSD socket() [POSIX]
The names and functions between these APIs are not consistent, and interface. The names and functions between these APIs are not
vary depending on the protocol being used. For example, sending and consistent, and vary depending on the protocol being used. For
receiving on a stream of data is conceptually the same between example, sending and receiving on a stream of data is conceptually
operating on an unencrypted Transmission Control Protocol (TCP) the same between operating on an unencrypted Transmission Control
stream and operating on an encrypted Transport Layer Security (TLS) Protocol (TCP) stream and operating on an encrypted Transport Layer
[I-D.ietf-tls-tls13] stream over TCP, but applications cannot use the Security (TLS) [I-D.ietf-tls-tls13] stream over TCP, but applications
same socket send() and recv() calls on top of both kinds of cannot use the same socket send() and recv() calls on top of both
connections. Similarly, terminology for the implementation of kinds of connections. Similarly, terminology for the implementation
protocols offering transport services vary based on the context of of protocols offering transport services vary based on the context of
the protocols themselves. This variety can lead to confusion when the protocols themselves. This variety can lead to confusion when
trying to understand the similarities and differences between trying to understand the similarities and differences between
protocols, and how applications can use them effectively. protocols, and 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. application requirements and network conditions.
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.trammell-taps-interface] and Transport Services API [I-D.ietf-taps-interface] and Implementation
Implementation [draft-brunstrom-taps-impl] documents. [I-D.ietf-taps-impl] documents.
2. Background 2. 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]. This work has offered by transport protocols [I-D.ietf-taps-minset]. This work has
identified common features and patterns across all transport identified common features and patterns across all transport
protocols developed thus far in the IETF. 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.pauly-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 Features), or else can be handled (referred to as Functional Features), or else can be handled
automatically by a system implementing Transport Services (referred automatically by a system implementing Transport Services (referred
to as Automatable Features). Among the Functional Features, some to as Automatable Features). Among the Functional Features, some
were common across all or nearly all transport protocols, while were common across all or nearly all transport protocols, while
others could be seen as features that, if specified, would only be others could be seen as features that, if specified, would only be
useful with a subset of protocols, or perhaps even a single transport useful with a subset of protocols, or perhaps even a single transport
skipping to change at page 5, line 28 skipping to change at page 5, line 31
system's options. Since such options are not part of the core/common system's options. Since such options are not part of the core/common
features, it should be simple for an application to modify its set of features, it should be simple for an application to modify its set of
constraints and change the set of allowable protocol features without constraints and change the set of allowable protocol features without
changing the core implementation. 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.trammell-taps-interface] describes this interface and is aimed [I-D.ietf-taps-interface] describes this interface and is aimed at
at application developers. application developers.
Implementations that provide the Transport Services API Implementations that provide the Transport Services API
[draft-brunstrom-taps-impl] will vary due to system-specific support [I-D.ietf-taps-impl] will vary due to system-specific support and the
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, but that some features will not be functional in certain
implementations. All implementations must offer sufficient APIs to implementations. All implementations must offer sufficient APIs to
use the distilled minimal set of features offered by transport use the distilled minimal set of features offered by transport
protocols [I-D.ietf-taps-minset], including API support for TCP and protocols [I-D.ietf-taps-minset], including API support for TCP and
UDP transport, but it is possible that some very constrained devices UDP transport, but it is possible that some very constrained devices
might not have, for example, a full TCP implementation. might not have, for example, a full TCP implementation.
In order to preserve flexibility and compatibility with future In order to preserve flexibility and compatibility with future
protocols, top-level features in the Transport Services API should protocols, top-level features in the Transport Services API should
skipping to change at page 7, line 5 skipping to change at page 7, line 5
categories: categories:
1. API concepts, which are meant to be exposed to applications; and 1. API concepts, which are meant to be exposed to applications; and
2. System-implementation concepts, which are meant to be internally 2. System-implementation concepts, which are meant to be internally
used when building systems that implement Transport Services. used when building systems that implement Transport Services.
The following diagram summarizes the top-level concepts in the The following diagram summarizes the top-level concepts in the
architecture and how they relate to one another. architecture and how they relate to one another.
+------------------------------------------------------+ +-----------------------------------------------------+
| Application | | Application |
+-+----------------+------^-------+--------^-----------+ +-+----------------+------^-------+--------^----------+
| | | | | | | | | |
pre- | data | events pre- | data | events
establishment | transfer | | establishment | transfer | |
| establishment | termination | | establishment | termination |
| | | | | | | | | |
| +--v------v-------v+ | | +--v------v-------v+ |
+-v-------------+ Basic Objects +-------+----------+ +-v-------------+ Basic Objects +-------+----------+
| Transport +--------+---------+ | | Transport +--------+---------+ |
| Services | | | Services | |
| API | | | API | |
skipping to change at page 8, line 5 skipping to change at page 8, line 5
communication and send and receive data. These may be exposed as communication and send and receive data. These may be exposed as
handles or referenced objects, depending on the language. handles or referenced objects, depending on the language.
Beyond the basic objects, there are several high-level groups of Beyond the basic objects, there are several high-level groups of
actions that any Transport Services API must provide: actions that any Transport Services API 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 primarily offer knobs that are applicable to properties should primarily be defined to apply to multiple
multiple transports. Properties may have a large impact on the transports. Properties may have a large impact on the rest of the
rest of the aspects of the interface: they can modify how aspects of the interface: they can modify how establishment
establishment occurs, they can influence the expectations around occurs, they can influence the expectations around data transfer,
data transfer, and they determine the set of events that will be 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 basic 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 data to be sent and received, the functions required to represents data to be sent and received, the functions required to
send and receive that data, and how the application is notified of send and receive that data, and how the application is notified of
the status of its data transfer. 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 can also provide opportunities for of transport objects. Events can 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 ceased, 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 taken
during the lifetime of a connection. during the lifetime of a connection.
Pre-Establishment : Established : Termination Pre-Establishment : Established : Termination
----------------- : ----------- : ----------- ----------------- : ----------- : -----------
: Close() : : Close() :
+---------------+ Initiate() +------------+ Abort() : +---------------+ Initiate() +------------+ Abort() :
+-->| Preconnection |----------->| Connection |---------------> Closed +-->| Preconnection |----------->| Connection |---------------> Closed
| +---------------+ : +------------+ Connection: | +---------------+ : +------------+ Connection:
skipping to change at page 10, line 23 skipping to change at page 10, line 23
o Listener: A Listener object accepts incoming transport protocol o Listener: A Listener object accepts incoming transport protocol
connections from Remote Endpoints and generates corresponding connections from Remote Endpoints and generates corresponding
Connection objects. It is created from a Preconnection object Connection objects. It is created from a Preconnection object
that specifies the type of incoming connections it will accept. that specifies the type of incoming connections it will accept.
4.1.2. Pre-Establishment 4.1.2. Pre-Establishment
o Endpoint: An Endpoint represents one side of a transport o Endpoint: An Endpoint represents one side of a transport
connection. Endpoints can be Local Endpoints or Remote Endpoints, connection. Endpoints can be Local Endpoints or Remote Endpoints,
and respectively represent an identity that the application uses and respectively represent an identity that the application uses
for the source or destination of a connection. Endpoint can vary for the source or destination of a connection. An Endpoint may be
in levels of specificity, and can be resolved to more concrete specified at various levels, and an Endpoint with wider scope
identities. (such as a hostname) can be resolved to more concrete identities
(such as IP addresses).
o Remote Endpoint: The Remote Endpoint represents the application's o Remote Endpoint: The Remote Endpoint represents the application's
name for a peer that can participate in a transport connection. name for a peer that can participate in a transport connection.
For example, the combination of a DNS name for the peer and a For example, the combination of a DNS name for the peer and a
service name/port. service name/port.
o Local Endpoint: The Local Endpoint represents the application's o Local Endpoint: The Local Endpoint represents the application's
name for itself that it wants to use for transport connections. name for itself that it uses for transport connections. For
For example, a local IP address and port. example, a local IP address and port.
o Path Selection Properties: The Path Selection Properties consist o Path Selection Properties: The Path Selection Properties consist
of the options that an application may set to influence the of the options that an application may set to influence the
selection of paths between itself and the Remote Endpoint. These selection of paths between the Local Endpoint and the Remote
options can come in the form of requirements, prohibitions, or Endpoint. These options can take the form of requirements,
preferences. Examples of options which may influence path prohibitions, or preferences. Examples of options that may
selection include the interface type (such as a Wi-Fi Ethernet influence path selection include the interface type (such as a Wi-
connection, or a Cellular LTE connection), characteristics of the Fi Ethernet connection, or a Cellular LTE connection),
path that are locally known like Maximum Transmission Unit (MTU) characteristics of the path that are locally known like Maximum
or discovered like Path MTU (PMTU), or predicted based on cached Transmission Unit (MTU) or discovered like Path MTU (PMTU), or
information like expected throughput or latency. predicted based on cached information like expected throughput or
latency.
o Protocol Selection Properties: The Protocol Selection Properties o Protocol Selection Properties: The Protocol Selection Properties
consist of the options that an application may set to influence consist of the options that an application may set to influence
the selection of transport protocol, or to configure the behavior the selection of transport protocol, or to configure the behavior
of generic transport protocol features. These options come in the of generic transport protocol features. These options can take
form of requirements, prohibitions, and preferences. Examples the form of requirements, prohibitions, and preferences. Examples
include reliability, service class, multipath support, and fast include reliability, service class, multipath support, and fast
open support. open support.
o Specific Protocol Properties: The Specific Protocol Properties o Specific Protocol Properties: The Specific Protocol Properties
refer to the subset of Protocol Properties options that apply to a refer to the subset of Protocol Properties options that apply to a
single protocol (transport protocol, IP, or security protocol). single protocol (transport protocol, IP, or security protocol).
The presence of such Properties does not necessarily require that The presence of such Properties does not necessarily require that
a specific protocol must be used when a Connection is established, a specific protocol must be used when a Connection is established,
but that if this protocol is employed, a particular set of options but that if this protocol is employed, a particular set of options
should be used. should then be used..
4.1.3. Establishment Actions 4.1.3. Establishment Actions
o Initiate is 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 be able to send and/or receive Messages.
For some protocols, this may initiate a client-to-server style For some protocols, this may initiate a client-to-server style
handshake; for other protocols, this may just establish local handshake; for other protocols, this may 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 is 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 is the action of establishing a peer-to-peer connection o 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 whilst listening for an incoming
connection from that endpoint. This corresponds, for example, to connection from that endpoint. This corresponds, for example, to
a TCP simultaneous open. The process of identifying options for a TCP simultaneous open [RFC0793]. The process of identifying
the connection, such as resolution of the Remote Endpoint, occurs options for the connection, such as resolution of the Remote
during the Rendezvous call. If successful, the rendezvous call Endpoint, occurs during the Rendezvous call. If successful, the
returns a Connection object to represent the established peer-to- rendezvous call returns a Connection object to represent the
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 endpoints represented as bytes that can be transferred between two endpoints
over a transport connection. The bytes within a Message are over a transport connection. The bytes within a Message are
assumed to be ordered 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. Messages may or may not be usable if incomplete or Messages. If a received Message is incomplete or corrupted, it
corrupted. Boundaries of a Message may or may not be understood may or may not be usable by certain applications. Boundaries of a
or transmitted by transport protocols. Specifically, what one Message may or may not be understood or transmitted by transport
application considers to be two Messages sent on a stream-based protocols. Specifically, what one application considers to be two
transport may be treated as a single Message by the application on Messages sent on a stream-based transport may be treated as a
the other side. single Message by the application on the other side.
o Send is 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 a Remote Endpoint. The interface to Send may Connection to a Remote Endpoint. The interface to Send may
include options specific to how the Message's content is to be include options specific to how the Message's content is to be
sent. Status of the Send operation may be delivered back to the sent. Status of the Send operation may be delivered back to the
application in an event (Section 4.1.5). application in an event (Section 4.1.5).
o Receive is an action that indicates that the application is ready o Receive: An action that indicates that the application is ready to
to asynchronously accept a Message over a Connection from a Remote asynchronously accept a Message over a Connection from a Remote
Endpoint, while the Message content itself will be delivered in an Endpoint, while the Message content itself will be delivered in an
event (Section 4.1.5). The interface to Receive may include event (Section 4.1.5). The interface to Receive may include
options specific to the Message that is to be delivered to the options specific to the Message that is to be delivered to the
application. application.
4.1.5. Event Handling 4.1.5. Event Handling
This list of events that can be delivered to an application is not This list of events that can be delivered to an application is not
exhaustive, but gives the top-level categories of events. The API exhaustive, but gives the top-level categories of events. The API
may expand this list. may expand this list.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
o Message Sent: Notifies the application of the status of its Send o Message Sent: Notifies the application of the status of its Send
action. This may be an error if the Message cannot be sent, or an action. This may be an error if the Message cannot be sent, or an
indication that Message has been processed by the protocol stack. indication that Message has been processed by the protocol stack.
o Path Properties Changed: Notifies the application that some o Path Properties Changed: Notifies the application that some
property of the Connection has changed that may influence how and property of the Connection has changed that may influence how and
where data is sent and/or received. where data is sent and/or received.
4.1.6. Termination Actions 4.1.6. Termination Actions
o Close is the action an application may take on a Connection to o Close: The action an application may take on a Connection to
indicate that it no longer intends to send data, is no longer indicate that it no longer intends to send data, is no longer
willing to receive data, and that the protocol should signal this willing to receive data, and that the protocol should signal this
state to the remote endpoint if applicable. state to the remote endpoint if applicable.
o Abort is an action the application may take on a Connection to o Abort: The action the application may take on a Connection to
indicate a Close, but with the additional indication that the indicate a Close, but with the additional indication that the
transport system should not attempt to deliver any outstanding transport system should not attempt to deliver any outstanding
data. data.
4.2. Transport System Implementation Concepts 4.2. Transport System Implementation Concepts
The Transport System Implementation Concepts define the set of The Transport System Implementation Concepts define the set of
objects used internally to a system or library to provide the objects used internally to a system or library to provide the
functionality of transport networking, as required by the abstract functionality required to provide a transport service across a
interface. network, as required by the abstract interface.
o Connection Group: A Connections Group is a set of Connections that o Connection Group: A set of Connections that share properties. For
share properties. For multiplexing transport protocols, the multiplexing transport protocols, the Connection Group defines the
Connection Group defines the set of Connections that can be set of Connections that can be multiplexed together.
multiplexed together.
o Path: A Path represents an available set of properties of a o Path: Represents an available set of properties that a Local
network route on which packets may be sent or received. Endpoint may use to send or receive packets with a Remote
Endpoint.
o Protocol Instance: A Protocol Instance is a single instance of one o Protocol Instance: A single instance of one protocol, including
protocol, including any state it has necessary to establish any state it has necessary to establish connectivity or send and
connectivity or send and receive Messages. receive Messages.
o Protocol Stack: A Protocol Stack is a set of Protocol Instances o Protocol Stack: A set of Protocol Instances (including relevant
(including relevant application, security, transport, or Internet application, security, transport, or Internet protocols) that are
protocols) that are used together to establish connectivity or used together to establish connectivity or send and receive
send and receive Messages. A single stack may be simple (a single Messages. A single stack may be simple (a single transport
transport protocol instance over IP), or complex (multiple protocol instance over IP), or complex (multiple application
application protocol streams going through a single security and protocol streams going through a single security and transport
transport protocol, over IP; or, a multi-path transport protocol protocol, over IP; or, a multi-path transport protocol over
over multiple transport sub-flows). multiple transport sub-flows).
o System Policy: System Policy represents the input from an o Candidate Path: One path that is available to an application and
operating system or other global preferences that can constrain or conforms to the Path Selection Properties and System Policy.
influence how an implementation will gather candidate paths and Candidate Paths are identified during the gathering phase
protocols (Section 4.2.1) and race the candidates during (Section 4.2.1) and may be used during the racing phase
establishment (Section 4.2.2). Specific aspects of the System (Section 4.2.2).
Policy may apply to all Connections, or only certain ones
depending on the runtime context and properties of the Connection.
o Cached State: Cached State is the state and history that the o Candidate Protocol Stack: One protocol stack that may be used by
implementation keeps for each set of associated endpoints that an application for a connection, of which there may be several.
have been used previously. This can include DNS results, TLS
session state, previous success and quality of transport protocols
over certain paths.
4.2.1. Gathering Candidate Protocol Stacks are identified during the gathering
phase (Section 4.2.1) and may be started during the racing phase
(Section 4.2.2).
o System Policy: Represents the input from an operating system or
other global preferences that can constrain or influence how an
implementation will gather candidate paths and protocol stacks
(Section 4.2.1) and race the candidates during establishment
(Section 4.2.2). Specific aspects of the System Policy may apply
to all Connections, or only certain ones depending on the runtime
context and properties of the Connection.
o Cached State: The state and history that the implementation keeps
for each set of associated endpoints that have been used
previously. This can include DNS results, TLS session state,
previous success and quality of transport protocols over certain
paths.
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 Path or more paths that are available to use based on the Path
Selection Properties provided by the application, and a Transport Selection Properties provided by the application, and a Transport
Services system's policies and heuristics. Services system's policies and heuristics.
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 Protocol Properties provided by the to use based on the Protocol Properties provided by the
application, and a Transport Services system's policies and application, and a Transport Services system's policies and
heuristics. heuristics.
4.2.2. 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
differ based on a selection from the available Paths. differ based on a selection from the available Paths.
o Endpoint Racing: Endpoint Racing is the act of attempting to o Endpoint Racing: Endpoint Racing is the act of attempting to
establish, or scheduling attempts to establish, multiple Protocol establish, or scheduling attempts to establish, multiple Protocol
Stacks that differ based on the specific representation of the Stacks that differ based on the specific representation of the
Remote Endpoint and the Local Endpoint, such as IP addresses Remote Endpoint and the Local Endpoint, such as IP addresses
resolved from a DNS hostname. resolved from a DNS hostname.
4.2.3. Message Framing, Parsing, and Serialization 4.3. Protocol Stack Equivalence
The Transport Services architecture defines a mechanism that allows
applications to easily use different network paths and Protocol
Stacks. Transitioning between different Protocol Stacks may in some
cases be controlled by properties that only change when application
code is updated. For example, an application may enable the use of a
multipath or multistreaming transport protocol by modifying the
properties in its Pre-Connection configuration. In some cases,
however, the Transport Services system will be able to automatically
change Protocol Stacks without an update to the application, either
by selecting a new stack entirely, or racing multiple candidate
Protocol Stacks during connection establishment. This functionality
can be a powerful driver of new protocol adoption, but must be
constrained 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
parallel (see Section 4.2.2), then they are considered to be
"equivalent". Equivalent Protocol Stacks must meet the following
criteria:
1. Both stacks must offer the same interface to the application for
connection establishment and data transmission. For example, if
one Protocol Stack has UDP as the top-level interface to the
application, then it is not equivalent to a Protocol Stack that
runs TCP as the top-level interface. Among other differences,
the UDP stack would allow an application to read out message
boundaries based on datagrams sent from the Remote Endpoint,
whereas TCP does not preserve message boundaries on its own.
2. Both stacks must offer the same transport services, as required
by the application. For example, if an application specifies
that it requires reliable transmission of data, then a Protocol
Stack using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP. However, if the
application does not require reliability, then a Protocol Stack
that adds unnecessary reliability might be allowed as an
equivalent Protocol Stack as long as it does not conflict with
any other application-requested properties.
3. Both stacks must offer the same security properties. See the
security protocol equivalence section below for futher discussion
(Section 4.3.1).
4.3.1. Transport Security Equivalence
The inclusion of transport security protocols
[I-D.ietf-taps-transport-security] in a Protocol Stack adds extra
restrictions to Protocol Stack equivalence. Security features and
properties, such as cryptographic algorithms, peer authentication,
and identity privacy vary across security protocols, and across
versions of security protocols. Protocol equivalence should not be
assumed for different protocols or protocol versions, even if they
offer similar application configuration options.
To ensure that security protocols are not incorrectly swapped,
Transport Services systems should only automatically generate
equivalent Protocol Stacks when the transport security protocols
within the stacks are identical. Specifically, a system should
consider protocols identical only if they are of the same type and
version. For example, the same version of TLS running over two
different transport protocol stacks may be considered equivalent,
whereas TLS 1.2 and TLS 1.3 [I-D.ietf-tls-tls13] should not be
considered equivalent.
4.4. Message Framing, Parsing, and Serialization
While some transports expose a byte stream abstraction, most higher While some transports expose a byte stream abstraction, most higher
level protocols impose some structure onto that byte stream. That level protocols impose some structure onto that byte stream. That
is, the higher level protocol operates in terms of messages, protocol is, the higher level protocol operates in terms of messages, protocol
data units (PDUs), rather than using unstructured sequences of bytes, data units (PDUs), rather than using unstructured sequences of bytes,
with each message being processed in turn. Protocols are specified with each message being processed in turn. Protocols are specified
in terms of state machines acting on semantic messages, with parsing in terms of state machines acting on semantic messages, with parsing
the byte stream into messages being a necessary annoyance, rather the byte stream into messages being a necessary annoyance, rather
than a semantic concern. Accordingly, the Transport Services than a semantic concern. Accordingly, the Transport Services
architecture exposes messages as the primary abstraction. Protocols architecture exposes messages as the primary abstraction. Protocols
skipping to change at page 16, line 50 skipping to change at page 18, line 32
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. Informative References
[draft-brunstrom-taps-impl] [I-D.ietf-taps-impl]
Anna Brunstrom, . and . Tommy Pauly, "Implementing Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Interfaces to Transport Services", n.d.. Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", draft-
ietf-taps-impl-00 (work in progress), May 2018.
[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-00 (work in
progress), April 2018.
[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 TAPS Systems", draft-ietf-taps-minset-03 Services for End Systems", draft-ietf-taps-minset-04 (work
(work in progress), March 2018. in progress), June 2018.
[I-D.ietf-taps-transport-security]
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
of Transport Security Protocols", draft-ietf-taps-
transport-security-02 (work in progress), June 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[I-D.pauly-taps-transport-security] [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey -- Portable Operating System Interface (POSIX). Open
of Transport Security Protocols", draft-pauly-taps- group Technical Standard: Base Specifications, Issue 7",
transport-security-02 (work in progress), March 2018. n.d..
[I-D.trammell-taps-interface] [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., RFC 793, DOI 10.17487/RFC0793, September 1981,
Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An <https://www.rfc-editor.org/info/rfc793>.
Abstract Application Layer Interface to Transport
Services", draft-trammell-taps-interface-00 (work in
progress), March 2018.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <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>.
 End of changes. 41 change blocks. 
126 lines changed or deleted 219 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/