draft-ietf-taps-impl-08.txt   draft-ietf-taps-impl-09.txt 
TAPS Working Group A. Brunstrom, Ed. TAPS Working Group A. Brunstrom, Ed.
Internet-Draft Karlstad University Internet-Draft Karlstad University
Intended status: Informational T. Pauly, Ed. Intended status: Informational T. Pauly, Ed.
Expires: 6 May 2021 Apple Inc. Expires: 1 November 2021 Apple Inc.
T. Enghardt T. Enghardt
Netflix Netflix
K-J. Grinnemo K-J. Grinnemo
Karlstad University Karlstad University
T. Jones T. Jones
University of Aberdeen University of Aberdeen
P. Tiesel P. Tiesel
TU Berlin SAP SE
C. Perkins C. Perkins
University of Glasgow University of Glasgow
M. Welzl M. Welzl
University of Oslo University of Oslo
2 November 2020 30 April 2021
Implementing Interfaces to Transport Services Implementing Interfaces to Transport Services
draft-ietf-taps-impl-08 draft-ietf-taps-impl-09
Abstract Abstract
The Transport Services (TAPS) system enables applications to use The Transport Services system enables applications to use transport
transport protocols flexibly for network communication and defines a protocols flexibly for network communication and defines a protocol-
protocol-independent TAPS Application Programming Interface (API) independent Transport Services Application Programming Interface
that is based on an asynchronous, event-driven interaction pattern. (API) that is based on an asynchronous, event-driven interaction
This document serves as a guide to implementation on how to build pattern. This document serves as a guide to implementation on how to
such a system. build such a system.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 May 2021. This Internet-Draft will expire on 1 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2. Implementing Connection Objects . . . . . . . . . . . . . . . 4 2. Implementing Connection Objects . . . . . . . . . . . . . . . 4
3. Implementing Pre-Establishment . . . . . . . . . . . . . . . 5 3. Implementing Pre-Establishment . . . . . . . . . . . . . . . 5
3.1. Configuration-time errors . . . . . . . . . . . . . . . . 5 3.1. Configuration-time errors . . . . . . . . . . . . . . . . 5
3.2. Role of system policy . . . . . . . . . . . . . . . . . . 6 3.2. Role of system policy . . . . . . . . . . . . . . . . . . 6
4. Implementing Connection Establishment . . . . . . . . . . . . 7 4. Implementing Connection Establishment . . . . . . . . . . . . 7
4.1. Candidate Gathering . . . . . . . . . . . . . . . . . . . 8 4.1. Candidate Gathering . . . . . . . . . . . . . . . . . . . 8
4.1.1. Gathering Endpoint Candidates . . . . . . . . . . . . 8 4.1.1. Gathering Endpoint Candidates . . . . . . . . . . . . 8
4.1.2. Structuring Options as a Tree . . . . . . . . . . . . 9 4.1.2. Structuring Options as a Tree . . . . . . . . . . . . 9
4.1.3. Branch Types . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Branch Types . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Branching Order-of-Operations . . . . . . . . . . . . 13 4.1.4. Branching Order-of-Operations . . . . . . . . . . . . 13
4.1.5. Sorting Branches . . . . . . . . . . . . . . . . . . 14 4.1.5. Sorting Branches . . . . . . . . . . . . . . . . . . 15
4.2. Candidate Racing . . . . . . . . . . . . . . . . . . . . 16 4.2. Candidate Racing . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Simultaneous . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Simultaneous . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Staggered . . . . . . . . . . . . . . . . . . . . . . 17 4.2.2. Staggered . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Failover . . . . . . . . . . . . . . . . . . . . . . 18 4.2.3. Failover . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Completing Establishment . . . . . . . . . . . . . . . . 18 4.3. Completing Establishment . . . . . . . . . . . . . . . . 18
4.3.1. Determining Successful Establishment . . . . . . . . 19 4.3.1. Determining Successful Establishment . . . . . . . . 19
4.4. Establishing multiplexed connections . . . . . . . . . . 20 4.4. Establishing multiplexed connections . . . . . . . . . . 20
4.5. Handling racing with "unconnected" protocols . . . . . . 20 4.5. Handling connectionless protocols . . . . . . . . . . . . 20
4.6. Implementing listeners . . . . . . . . . . . . . . . . . 20 4.6. Implementing listeners . . . . . . . . . . . . . . . . . 21
4.6.1. Implementing listeners for Connected Protocols . . . 21 4.6.1. Implementing listeners for Connected Protocols . . . 21
4.6.2. Implementing listeners for Unconnected Protocols . . 21 4.6.2. Implementing listeners for Connectionless
4.6.3. Implementing listeners for Multiplexed Protocols . . 21 Protocols . . . . . . . . . . . . . . . . . . . . . . 21
4.6.3. Implementing listeners for Multiplexed Protocols . . 22
5. Implementing Sending and Receiving Data . . . . . . . . . . . 22 5. Implementing Sending and Receiving Data . . . . . . . . . . . 22
5.1. Sending Messages . . . . . . . . . . . . . . . . . . . . 22 5.1. Sending Messages . . . . . . . . . . . . . . . . . . . . 22
5.1.1. Message Properties . . . . . . . . . . . . . . . . . 22 5.1.1. Message Properties . . . . . . . . . . . . . . . . . 22
5.1.2. Send Completion . . . . . . . . . . . . . . . . . . . 24 5.1.2. Send Completion . . . . . . . . . . . . . . . . . . . 24
5.1.3. Batching Sends . . . . . . . . . . . . . . . . . . . 24 5.1.3. Batching Sends . . . . . . . . . . . . . . . . . . . 24
5.2. Receiving Messages . . . . . . . . . . . . . . . . . . . 24 5.2. Receiving Messages . . . . . . . . . . . . . . . . . . . 25
5.3. Handling of data for fast-open protocols . . . . . . . . 25 5.3. Handling of data for fast-open protocols . . . . . . . . 25
6. Implementing Message Framers . . . . . . . . . . . . . . . . 26 6. Implementing Message Framers . . . . . . . . . . . . . . . . 26
6.1. Defining Message Framers . . . . . . . . . . . . . . . . 26 6.1. Defining Message Framers . . . . . . . . . . . . . . . . 27
6.2. Sender-side Message Framing . . . . . . . . . . . . . . . 28 6.2. Sender-side Message Framing . . . . . . . . . . . . . . . 28
6.3. Receiver-side Message Framing . . . . . . . . . . . . . . 28 6.3. Receiver-side Message Framing . . . . . . . . . . . . . . 29
7. Implementing Connection Management . . . . . . . . . . . . . 29 7. Implementing Connection Management . . . . . . . . . . . . . 30
7.1. Pooled Connection . . . . . . . . . . . . . . . . . . . . 30 7.1. Pooled Connection . . . . . . . . . . . . . . . . . . . . 30
7.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 30 7.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 31
8. Implementing Connection Termination . . . . . . . . . . . . . 31 8. Implementing Connection Termination . . . . . . . . . . . . . 32
9. Cached State . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Cached State . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Protocol state caches . . . . . . . . . . . . . . . . . . 33 9.1. Protocol state caches . . . . . . . . . . . . . . . . . . 33
9.2. Performance caches . . . . . . . . . . . . . . . . . . . 33 9.2. Performance caches . . . . . . . . . . . . . . . . . . . 34
10. Specific Transport Protocol Considerations . . . . . . . . . 34 10. Specific Transport Protocol Considerations . . . . . . . . . 35
10.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.2. MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.4. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 38 10.4. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 40
10.5. UDP Multicast Receive . . . . . . . . . . . . . . . . . 38 10.5. UDP Multicast Receive . . . . . . . . . . . . . . . . . 40
10.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12. Security Considerations . . . . . . . . . . . . . . . . . . . 42 12. Security Considerations . . . . . . . . . . . . . . . . . . . 44
12.1. Considerations for Candidate Gathering . . . . . . . . . 43 12.1. Considerations for Candidate Gathering . . . . . . . . . 44
12.2. Considerations for Candidate Racing . . . . . . . . . . 43 12.2. Considerations for Candidate Racing . . . . . . . . . . 44
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
14.1. Normative References . . . . . . . . . . . . . . . . . . 44 14.1. Normative References . . . . . . . . . . . . . . . . . . 45
14.2. Informative References . . . . . . . . . . . . . . . . . 45 14.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. API Mapping Template . . . . . . . . . . . . . . . . 46 Appendix A. API Mapping Template . . . . . . . . . . . . . . . . 48
Appendix B. Additional Properties . . . . . . . . . . . . . . . 47 Appendix B. Additional Properties . . . . . . . . . . . . . . . 49
B.1. Properties Affecting Sorting of Branches . . . . . . . . 47 B.1. Properties Affecting Sorting of Branches . . . . . . . . 49
Appendix C. Reasons for errors . . . . . . . . . . . . . . . . . 47 Appendix C. Reasons for errors . . . . . . . . . . . . . . . . . 49
Appendix D. Existing Implementations . . . . . . . . . . . . . . 48 Appendix D. Existing Implementations . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
The Transport Services architecture [I-D.ietf-taps-arch] defines a The Transport Services architecture [I-D.ietf-taps-arch] defines a
system that allows applications to use transport networking protocols system that allows applications to use transport networking protocols
flexibly. The interface such a system exposes to applications is flexibly. The interface such a system exposes to applications is
defined as the Transport Services API [I-D.ietf-taps-interface]. defined as the Transport Services API [I-D.ietf-taps-interface].
This API is designed to be generic across multiple transport This API is designed to be generic across multiple transport
protocols and sets of protocols features. protocols and sets of protocols features.
skipping to change at page 4, line 11 skipping to change at page 4, line 19
how to transfer data over those connections once established. The how to transfer data over those connections once established. The
terminology used in this document is based on the Architecture terminology used in this document is based on the Architecture
[I-D.ietf-taps-arch]. [I-D.ietf-taps-arch].
2. Implementing Connection Objects 2. Implementing Connection Objects
The connection objects that are exposed to applications for Transport The connection objects that are exposed to applications for Transport
Services are: Services are:
* the Preconnection, the bundle of Properties that describes the * the Preconnection, the bundle of Properties that describes the
application constraints on the transport; application constraints on, and preferences for, the transport;
* the Connection, the basic object that represents a flow of data as * the Connection, the basic object that represents a flow of data as
Messages in either direction between the Local and Remote Messages in either direction between the Local and Remote
Endpoints; Endpoints;
* and the Listener, a passive waiting object that delivers new * and the Listener, a passive waiting object that delivers new
Connections. Connections.
Preconnection objects should be implemented as bundles of properties Preconnection objects should be implemented as bundles of properties
that an application can both read and write. Once a Preconnection that an application can both read and write. Once a Preconnection
has been used to create an outbound Connection or a Listener, the has been used to create an outbound Connection or a Listener, the
implementation should ensure that the copy of the properties held by implementation should ensure that the copy of the properties held by
the Connection or Listener is immutable. This may involve performing the Connection or Listener is immutable. This may involve performing
a deep-copy if the application is still able to modify properties on a deep-copy, copying the object with all the objects it references,
the original Preconnection object. if the application is still able to modify properties on the original
Preconnection object.
Connection objects represent the interface between the application Connection objects represent the interface between the application
and the implementation to manage transport state, and conduct data and the implementation to manage transport state, and conduct data
transfer. During the process of establishment (Section 4), the transfer. During the process of establishment (Section 4), the
Connection will be unbound to a specific transport flow, since there Connection will not be bound to a specific transport flow, since
may be multiple candidate Protocol Stacks being raced. Once the there may be multiple candidate Protocol Stacks being raced. Once
Connection is established, the object should be considered mapped to the Connection is established, its interface maps actions and events
a specific Protocol Stack. The notion of a Connection maps to many to the details of the chosen Protocol Stack. For example, the same
different protocols, depending on the Protocol Stack. For example, Connection object may ultimately represent the interface into a TCP
the Connection may ultimately represent the interface into a TCP
connection, a TLS session over TCP, a UDP flow with fully-specified connection, a TLS session over TCP, a UDP flow with fully-specified
local and remote endpoints, a DTLS session, a SCTP stream, a QUIC local and remote endpoints, a DTLS session, a SCTP stream, a QUIC
stream, or an HTTP/2 stream. stream, or an HTTP/2 stream.
Listener objects are created with a Preconnection, at which point Listener objects are created with a Preconnection, at which point
their configuration should be considered immutable by the their configuration should be considered immutable by the
implementation. The process of listening is described in implementation. The process of listening is described in
Section 4.6. Section 4.6.
3. Implementing Pre-Establishment 3. Implementing Pre-Establishment
During pre-establishment the application specifies the Endpoints to During pre-establishment the application specifies one or more
be used for communication as well as its preferences via Selection Endpoints to be used for communication as well as protocol
Properties and, if desired, also Connection Properties. Generally, preferences and constraints via Selection Properties and, if desired,
Connection Properties should be configured as early as possible, also Connection Properties. Generally, Connection Properties should
because they can serve as input to decisions that are made by the be configured as early as possible, because they can serve as input
implementation (e.g., the Capacity Profile can guide usage of a to decisions that are made by the implementation (e.g., the Capacity
protocol offering scavenger-type congestion control). Profile can guide usage of a protocol offering scavenger-type
congestion control).
The implementation stores these properties as a part of the The implementation stores these properties as a part of the
Preconnection object for use during connection establishment. For Preconnection object for use during connection establishment. For
Selection Properties that are not provided by the application, the Selection Properties that are not provided by the application, the
implementation must use the default values specified in the Transport implementation must use the default values specified in the Transport
Services API ([I-D.ietf-taps-interface]). Services API ([I-D.ietf-taps-interface]).
3.1. Configuration-time errors 3.1. Configuration-time errors
The transport system should have a list of supported protocols The Transport Services system should have a list of supported
available, which each have transport features reflecting the protocols available, which each have transport features reflecting
capabilities of the protocol. Once an application specifies its the capabilities of the protocol. Once an application specifies its
Transport Properties, the transport system matches the required and Transport Properties, the transport system matches the required and
prohibited properties against the transport features of the available prohibited properties against the transport features of the available
protocols. protocols.
In the following cases, failure should be detected during pre- In the following cases, failure should be detected during pre-
establishment: establishment:
* A request by an application for Protocol Properties that include * A request by an application for Protocol Properties that include
requirements or prohibitions that cannot be satisfied by any of requirements or prohibitions that cannot be satisfied by any of
the available protocols. For example, if an application requires the available protocols. For example, if an application requires
skipping to change at page 5, line 49 skipping to change at page 5, line 50
operating system. operating system.
* A request by an application for Protocol Properties that are in * A request by an application for Protocol Properties that are in
conflict with each other, i.e., the required and prohibited conflict with each other, i.e., the required and prohibited
properties cannot be satisfied by the same protocol. For example, properties cannot be satisfied by the same protocol. For example,
if an application prohibits "Reliable Data Transfer" but then if an application prohibits "Reliable Data Transfer" but then
requires "Configure Reliability per Message", this mismatch should requires "Configure Reliability per Message", this mismatch should
result in an error. result in an error.
To avoid allocating resources, it is important that such cases fail To avoid allocating resources, it is important that such cases fail
as early as possible, e.g., to endpoint resolution, only to find out as early as possible, e.g., prior to endpoint resolution, only to
later that there is no protocol that satisfies the requirements. find out later that there is no protocol that satisfies the
requirements.
3.2. Role of system policy 3.2. Role of system policy
The properties specified during pre-establishment have a close The properties specified during pre-establishment have a close
relationship to system policy. The implementation is responsible for relationship to system policy. The implementation is responsible for
combining and reconciling several different sources of preferences combining and reconciling several different sources of preferences
when establishing Connections. These include, but are not limited when establishing Connections. These include, but are not limited
to: to:
1. Application preferences, i.e., preferences specified during the 1. Application preferences, i.e., preferences specified during the
skipping to change at page 7, line 17 skipping to change at page 7, line 17
The process of establishing a network connection begins when an The process of establishing a network connection begins when an
application expresses intent to communicate with a remote endpoint by application expresses intent to communicate with a remote endpoint by
calling Initiate. (At this point, any constraints or requirements calling Initiate. (At this point, any constraints or requirements
the application may have on the connection are available from pre- the application may have on the connection are available from pre-
establishment.) The process can be considered complete once there is establishment.) The process can be considered complete once there is
at least one Protocol Stack that has completed any required setup to at least one Protocol Stack that has completed any required setup to
the point that it can transmit and receive the application's data. the point that it can transmit and receive the application's data.
Connection establishment is divided into two top-level steps: Connection establishment is divided into two top-level steps:
Candidate Gathering, to identify the paths, protocols, and endpoints Candidate Gathering, to identify the paths, protocols, and endpoints
to use, and Candidate Racing, in which the necessary protocol to use, and Candidate Racing (see Section 4.2.2 of
handshakes are conducted so that the transport system can select [I-D.ietf-taps-arch]), in which the necessary protocol handshakes are
which set to use. This document structures candidates for racing as conducted so that the transport system can select which set to use.
a tree. This document structures candidates for racing as a tree.
The most simple example of this process might involve identifying the The most simple example of this process might involve identifying the
single IP address to which the implementation wishes to connect, single IP address to which the implementation wishes to connect,
using the system's current default interface or path, and starting a using the system's current default interface or path, and starting a
TCP handshake to establish a stream to the specified IP address. TCP handshake to establish a stream to the specified IP address.
However, each step may also vary depending on the requirements of the However, each step may also vary depending on the requirements of the
connection: if the endpoint is defined as a hostname and port, then connection: if the endpoint is defined as a hostname and port, then
there may be multiple resolved addresses that are available; there there may be multiple resolved addresses that are available; there
may also be multiple interfaces or paths available, other than the may also be multiple interfaces or paths available, other than the
default system interface; and some protocols may not need any default system interface; and some protocols may not need any
skipping to change at page 8, line 26 skipping to change at page 8, line 26
The step of gathering candidates involves identifying which paths, The step of gathering candidates involves identifying which paths,
protocols, and endpoints may be used for a given Connection. This protocols, and endpoints may be used for a given Connection. This
list is determined by the requirements, prohibitions, and preferences list is determined by the requirements, prohibitions, and preferences
of the application as specified in the Selection Properties. of the application as specified in the Selection Properties.
4.1.1. Gathering Endpoint Candidates 4.1.1. Gathering Endpoint Candidates
Both Local and Remote Endpoint Candidates must be discovered during Both Local and Remote Endpoint Candidates must be discovered during
connection establishment. To support Interactive Connectivity connection establishment. To support Interactive Connectivity
Establishment (ICE) [RFC8445], or similar protocols, that involve Establishment (ICE) [RFC8445], or similar protocols that involve out-
out-of-band indirect signalling to exchange candidates with the of-band indirect signalling to exchange candidates with the Remote
Remote Endpoint, it's important to be able to query the set of Endpoint, it's important to be able to query the set of candidate
candidate Local Endpoints, and give the protocol stack a set of Local Endpoints, and give the protocol stack a set of candidate
candidate Remote Endpoints, before it attempts to establish Remote Endpoints, before it attempts to establish connections.
connections.
4.1.1.1. Local Endpoint candidates 4.1.1.1. Local Endpoint candidates
The set of possible Local Endpoints is gathered. In the simple case, The set of possible Local Endpoints is gathered. In the simple case,
this merely enumerates the local interfaces and protocols, allocates this merely enumerates the local interfaces and protocols, allocates
ephemeral source ports. For example, a system that has WiFi and ephemeral source ports. For example, a system that has WiFi and
Ethernet and supports IPv4 and IPv6 might gather four candidate Ethernet and supports IPv4 and IPv6 might gather four candidate
locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on
WiFi) that can form the source for a transient. WiFi) that can form the source for a transient.
skipping to change at page 9, line 30 skipping to change at page 9, line 30
can also be specific to each Local Endpoint. A common case is when can also be specific to each Local Endpoint. A common case is when
the Remote Endpoint is a DNS name, in which case it is resolved to the Remote Endpoint is a DNS name, in which case it is resolved to
give a set of IPv4 and IPv6 addresses representing that name. Some give a set of IPv4 and IPv6 addresses representing that name. Some
types of remote might require more complex resolution. Resolving the types of remote might require more complex resolution. Resolving the
Remote Endpoint for a peer-to-peer connection might involve Remote Endpoint for a peer-to-peer connection might involve
communication with a rendezvous server, which in turn contacts the communication with a rendezvous server, which in turn contacts the
peer to gain consent to communicate and retrieve its set of candidate peer to gain consent to communicate and retrieve its set of candidate
locals, which are returned and form the candidate remote addresses locals, which are returned and form the candidate remote addresses
for contacting that peer. for contacting that peer.
Resolving the remote is not a local operation. It will involve a Resolving the Remote Endpoint is not a local operation. It will
directory service, and can require communication with the remote to involve a directory service, and can require communication with the
rendezvous and exchange peer addresses. This can expose some or all remote to rendezvous and exchange peer addresses. This can expose
of the candidate locals to the remote. some or all of the candidate locals to the remote.
4.1.2. Structuring Options as a Tree 4.1.2. Structuring Options as a Tree
When an implementation responsible for connection establishment needs When an implementation responsible for connection establishment needs
to consider multiple options, it should logically structure these to consider multiple options, it should logically structure these
options as a hierarchical tree. Each leaf node of the tree options as a hierarchical tree. Each leaf node of the tree
represents a single, coherent connection attempt, with an Endpoint, a represents a single, coherent connection attempt, with an Endpoint, a
Path, and a set of protocols that can directly negotiate and send Path, and a set of protocols that can directly negotiate and send
data on the network. Each node in the tree that is not a leaf data on the network. Each node in the tree that is not a leaf
represents a connection attempt that is either underspecified, or represents a connection attempt that is either underspecified, or
skipping to change at page 13, line 37 skipping to change at page 13, line 37
Branch types must occur in a specific order relative to one another Branch types must occur in a specific order relative to one another
to avoid creating leaf nodes with invalid or incompatible settings. to avoid creating leaf nodes with invalid or incompatible settings.
In the example above, it would be invalid to branch for derived In the example above, it would be invalid to branch for derived
endpoints (the DNS results for www.example.com) before branching endpoints (the DNS results for www.example.com) before branching
between interface paths, since there are situations when the results between interface paths, since there are situations when the results
will be different across networks due to private names or different will be different across networks due to private names or different
supported IP versions. Implementations must be careful to branch in supported IP versions. Implementations must be careful to branch in
an order that results in usable leaf nodes whenever there are an order that results in usable leaf nodes whenever there are
multiple branch types that could be used from a single node. multiple branch types that could be used from a single node.
The order of operations for branching, where lower numbers are acted The order of operations for branching should be:
upon first, should be:
1. Alternate Paths 1. Alternate Paths
2. Protocol Options 2. Protocol Options
3. Derived Endpoints 3. Derived Endpoints
where a lower number indicates higher precedence and therefore higher
Branching between paths is the first in the list because results placement in the tree. Branching between paths is the first in the
across multiple interfaces are likely not related to one another: list because results across multiple interfaces are likely not
endpoint resolution may return different results, especially when related to one another: endpoint resolution may return different
using locally resolved host and service names, and which protocols results, especially when using locally resolved host and service
are supported and preferred may differ across interfaces. Thus, if names, and which protocols are supported and preferred may differ
multiple paths are attempted, the overall connection can be seen as a across interfaces. Thus, if multiple paths are attempted, the
race between the available paths or interfaces. overall connection can be seen as a race between the available paths
or interfaces.
Protocol options are next checked in order. Whether or not a set of Protocol options are next checked in order. Whether or not a set of
protocol, or protocol-specific options, can successfully connect is protocol, or protocol-specific options, can successfully connect is
generally not dependent on which specific IP address is used. generally not dependent on which specific IP address is used.
Furthermore, the protocol stacks being attempted may influence or Furthermore, the protocol stacks being attempted may influence or
altogether change the endpoints being used. Adding a proxy to a altogether change the endpoints being used. Adding a proxy to a
connection's branch will change the endpoint to the proxy's IP connection's branch will change the endpoint to the proxy's IP
address or hostname. Choosing an alternate protocol may also modify address or hostname. Choosing an alternate protocol may also modify
the ports that should be selected. the ports that should be selected.
skipping to change at page 17, line 20 skipping to change at page 17, line 34
followed by the next child node after some delay. Once that second followed by the next child node after some delay. Once that second
child node is initiated, the third child node (if present) will begin child node is initiated, the third child node (if present) will begin
after another delay, and so on until all child nodes have been after another delay, and so on until all child nodes have been
initiated, or one of the child nodes successfully completes its initiated, or one of the child nodes successfully completes its
negotiation. negotiation.
Staggered racing attempts can proceed in parallel. Implementations Staggered racing attempts can proceed in parallel. Implementations
should not terminate an earlier child connection attempt upon should not terminate an earlier child connection attempt upon
starting a secondary child. starting a secondary child.
If a child node fails to connect before the delay time has expired If a child node fails to establish connectivity (as in Section 4.3.1)
for the next child, the next child should be started immediately. before the delay time has expired for the next child, the next child
should be started immediately.
Staggered racing between IP addresses for a generic Connection should Staggered racing between IP addresses for a generic Connection should
follow the Happy Eyeballs algorithm described in [RFC8305]. follow the Happy Eyeballs algorithm described in [RFC8305].
[RFC8421] provides guidance for racing when performing Interactive [RFC8421] provides guidance for racing when performing Interactive
Connectivity Establishment (ICE). Connectivity Establishment (ICE).
Generally, the delay before starting a given child node ought to be Generally, the delay before starting a given child node ought to be
based on the length of time the previously started child node is based on the length of time the previously started child node is
expected to take before it succeeds or makes progress in connection expected to take before it succeeds or makes progress in connection
establishment. Algorithms like Happy Eyeballs choose a delay based establishment. Algorithms like Happy Eyeballs choose a delay based
skipping to change at page 18, line 37 skipping to change at page 18, line 46
Successes and failures of a given attempt should be reported up to Successes and failures of a given attempt should be reported up to
parent nodes (towards the trunk of the tree). For example, in the parent nodes (towards the trunk of the tree). For example, in the
following case, if 1.1.1 fails to connect, it reports the failure to following case, if 1.1.1 fails to connect, it reports the failure to
1.1. Since 1.1 has no other child nodes, it also has failed and 1.1. Since 1.1 has no other child nodes, it also has failed and
reports that failure to 1. Because 1.2 has not yet failed, 1 is not reports that failure to 1. Because 1.2 has not yet failed, 1 is not
considered to have failed. Since 1.2 has not yet started, it is considered to have failed. Since 1.2 has not yet started, it is
started and the process continues. Similarly, if 1.1.1 successfully started and the process continues. Similarly, if 1.1.1 successfully
connects, then it marks 1.1 as connected, which propagates to the connects, then it marks 1.1 as connected, which propagates to the
trunk node 1. At this point, the connection as a whole is considered trunk node 1. At this point, the connection as a whole is considered
to be successfully connected and ready to process application data to be successfully connected and ready to process application data.
1 [www.example.com:80, Any, TCP] 1 [www.example.com:80, Any, TCP]
1.1 [www.example.com:80, Wi-Fi, TCP] 1.1 [www.example.com:80, Wi-Fi, TCP]
1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP]
1.2 [www.example.com:80, LTE, TCP] 1.2 [www.example.com:80, LTE, TCP]
... ...
If a leaf node has successfully completed its connection, all other If a leaf node has successfully completed its connection, all other
attempts should be made ineligible for use by the application for the attempts should be made ineligible for use by the application for the
original request. New connection attempts that involve transmitting original request. New connection attempts that involve transmitting
skipping to change at page 19, line 24 skipping to change at page 19, line 30
slower to connect and may exhibit less desirable properties. slower to connect and may exhibit less desirable properties.
4.3.1. Determining Successful Establishment 4.3.1. Determining Successful Establishment
Implementations may select the criteria by which a leaf node is Implementations may select the criteria by which a leaf node is
considered to be successfully connected differently on a per-protocol considered to be successfully connected differently on a per-protocol
basis. If the only protocol being used is a transport protocol with basis. If the only protocol being used is a transport protocol with
a clear handshake, like TCP, then the obvious choice is to declare a clear handshake, like TCP, then the obvious choice is to declare
that node "connected" when the last packet of the three-way handshake that node "connected" when the last packet of the three-way handshake
has been received. If the only protocol being used is an has been received. If the only protocol being used is an
"unconnected" protocol, like UDP, the implementation may consider the connectionless protocol, like UDP, the implementation may consider
node fully "connected" the moment it determines a route is present, the node fully "connected" the moment it determines a route is
before sending any packets on the network, see further Section 4.5. present, before sending any packets on the network, see further
Section 4.5.
For protocol stacks with multiple handshakes, the decision becomes For protocol stacks with multiple handshakes, the decision becomes
more nuanced. If the protocol stack involves both TLS and TCP, an more nuanced. If the protocol stack involves both TLS and TCP, an
implementation could determine that a leaf node is connected after implementation could determine that a leaf node is connected after
the TCP handshake is complete, or it can wait for the TLS handshake the TCP handshake is complete, or it can wait for the TLS handshake
to complete as well. The benefit of declaring completion when the to complete as well. The benefit of declaring completion when the
TCP handshake finishes, and thus stopping the race for other branches TCP handshake finishes, and thus stopping the race for other branches
of the tree, is that there will be less burden on the network from of the tree, is reduced burden on the network and remote endpoints
other connection attempts. On the other hand, by waiting until the from further connection attempts that are likely to be abandoned. On
TLS handshake is complete, an implementation avoids the scenario in the other hand, by waiting until the TLS handshake is complete, an
which a TCP handshake completes quickly, but TLS negotiation is implementation avoids the scenario in which a TCP handshake completes
either very slow or fails altogether in particular network conditions quickly, but TLS negotiation is either very slow or fails altogether
or to a particular endpoint. To avoid the issue of TLS possibly in particular network conditions or to a particular endpoint. To
failing, the implementation should not generate a Ready event for the avoid the issue of TLS possibly failing, the implementation should
Connection until TLS is established. not generate a Ready event for the Connection until TLS is
established.
If all of the leaf nodes fail to connect during racing, i.e. none of If all of the leaf nodes fail to connect during racing, i.e. none of
the configurations that satisfy all requirements given in the the configurations that satisfy all requirements given in the
Transport Properties actually work over the available paths, then the Transport Properties actually work over the available paths, then the
transport system should notify the application with an InitiateError transport system should notify the application with an InitiateError
event. An InitiateError event should also be generated in case the event. An InitiateError event should also be generated in case the
transport system finds no usable candidates to race. transport system finds no usable candidates to race.
4.4. Establishing multiplexed connections 4.4. Establishing multiplexed connections
skipping to change at page 20, line 27 skipping to change at page 20, line 34
connection establishment procedure. This, then, also means that connection establishment procedure. This, then, also means that
there may not be any "establishment" message (like a TCP SYN), but there may not be any "establishment" message (like a TCP SYN), but
the application can simply start sending or receiving. Therefore, the application can simply start sending or receiving. Therefore,
when the Initiate action of a Transport System is called without when the Initiate action of a Transport System is called without
Messages being handed over, it cannot be guaranteed that the other Messages being handed over, it cannot be guaranteed that the other
endpoint will have any way to know about this, and hence a passive endpoint will have any way to know about this, and hence a passive
endpoint's ConnectionReceived event may not be called upon an active endpoint's ConnectionReceived event may not be called upon an active
endpoint's Inititate. Instead, calling the ConnectionReceived event endpoint's Inititate. Instead, calling the ConnectionReceived event
may be delayed until the first Message arrives. may be delayed until the first Message arrives.
4.5. Handling racing with "unconnected" protocols 4.5. Handling connectionless protocols
While protocols that use an explicit handshake to validate a While protocols that use an explicit handshake to validate a
Connection to a peer can be used for racing multiple establishment Connection to a peer can be used for racing multiple establishment
attempts in parallel, "unconnected" protocols such as raw UDP do not attempts in parallel, connectionless protocols such as raw UDP do not
offer a way to validate the presence of a peer or the usability of a offer a way to validate the presence of a peer or the usability of a
Connection without application feedback. An implementation should Connection without application feedback. An implementation should
consider such a protocol stack to be established as soon as a local consider such a protocol stack to be established as soon as the
route to the peer endpoint is confirmed. Transport Services system has selected a path on which to send data.
However, if a peer is not reachable over the network using the However, if a peer is not reachable over the network using the
unconnected protocol, or data cannot be exchanged for any other connectionless protocol, or data cannot be exchanged for any other
reason, the application may want to attempt using another candidate reason, the application may want to attempt using another candidate
Protocol Stack. The implementation should maintain the list of other Protocol Stack. The implementation should maintain the list of other
candidate Protocol Stacks that were eligible to use. candidate Protocol Stacks that were eligible to use.
4.6. Implementing listeners 4.6. Implementing listeners
When an implementation is asked to Listen, it registers with the When an implementation is asked to Listen, it registers with the
system to wait for incoming traffic to the Local Endpoint. If no system to wait for incoming traffic to the Local Endpoint. If no
Local Endpoint is specified, the implementation should use an Local Endpoint is specified, the implementation should use an
ephemeral port. ephemeral port.
If the Selection Properties do not require a single network interface If the Selection Properties do not require a single network interface
or path, but allow the use of multiple paths, the Listener object or path, but allow the use of multiple paths, the Listener object
should register for incoming traffic on all of the network interfaces should register for incoming traffic on all of the network interfaces
or paths that conform to the Properties. The set of available paths or paths that conform to the Properties. The set of available paths
can change over time, so the implementation should monitor network can change over time, so the implementation should monitor network
path changes and register and de-register the Listener across all path changes, and change the registration of the Listener across all
usable paths. When using multiple paths, the Listener is generally usable paths as appropriate. When using multiple paths, the Listener
expected to use the same port for listening on each. is generally expected to use the same port for listening on each.
If the Selection Properties allow multiple protocols to be used for If the Selection Properties allow multiple protocols to be used for
listening, and the implementation supports it, the Listener object listening, and the implementation supports it, the Listener object
should support receiving inbound connections for each eligible should support receiving inbound connections for each eligible
protocol on each eligible path. protocol on each eligible path.
4.6.1. Implementing listeners for Connected Protocols 4.6.1. Implementing listeners for Connected Protocols
Connected protocols such as TCP and TLS-over-TCP have a strong Connected protocols such as TCP and TLS-over-TCP have a strong
mapping between the Local and Remote Endpoints (five-tuple) and their mapping between the Local and Remote Endpoints (four-tuple) and their
protocol connection state. These map into Connection objects. protocol connection state. These map into Connection objects.
Whenever a new inbound handshake is being started, the Listener Whenever a new inbound handshake is being started, the Listener
should generate a new Connection object and pass it to the should generate a new Connection object and pass it to the
application. application.
4.6.2. Implementing listeners for Unconnected Protocols 4.6.2. Implementing listeners for Connectionless Protocols
Unconnected protocols such as UDP and UDP-lite generally do not Connectionless protocols such as UDP and UDP-lite generally do not
provide the same mechanisms that connected protocols do to offer provide the same mechanisms that connected protocols do to offer
Connection objects. Implementations should wait for incoming packets Connection objects. Implementations should wait for incoming packets
for unconnected protocols on a listening port and should perform for connectionless protocols on a listening port and should perform
five-tuple matching of packets to either existing Connection objects four-tuple matching of packets to either existing Connection objects
or the creation of new Connection objects. On platforms with or the creation of new Connection objects. On platforms with
facilities to create a "virtual connection" for unconnected protocols facilities to create a "virtual connection" for connectionless
implementations should use these mechanisms to minimise the handling protocols implementations should use these mechanisms to minimise the
of datagrams intended for already created Connection objects. handling of datagrams intended for already created Connection
objects.
4.6.3. Implementing listeners for Multiplexed Protocols 4.6.3. Implementing listeners for Multiplexed Protocols
Protocols that provide multiplexing of streams into a single five- Protocols that provide multiplexing of streams into a single four-
tuple can listen both for entirely new connections (a new HTTP/2 tuple can listen both for entirely new connections (a new HTTP/2
stream on a new TCP connection, for example) and for new sub- stream on a new TCP connection, for example) and for new sub-
connections (a new HTTP/2 stream on an existing connection). If the connections (a new HTTP/2 stream on an existing connection). If the
abstraction of Connection presented to the application is mapped to abstraction of Connection presented to the application is mapped to
the multiplexed stream, then the Listener should deliver new the multiplexed stream, then the Listener should deliver new
Connection objects in the same way for either case. The Connection objects in the same way for either case. The
implementation should allow the application to introspect the implementation should allow the application to introspect the
Connection Group marked on the Connections to determine the grouping Connection Group marked on the Connections to determine the grouping
of the multiplexing. of the multiplexing.
skipping to change at page 22, line 20 skipping to change at page 22, line 33
datagram. Generally, these will be short enough that sending and datagram. Generally, these will be short enough that sending and
receiving will always use a complete Message. receiving will always use a complete Message.
For protocols that expose byte-streams, the only delineation provided For protocols that expose byte-streams, the only delineation provided
by the protocol is the end of the stream in a given direction. Each by the protocol is the end of the stream in a given direction. Each
Message in this case corresponds to the entire stream of bytes in a Message in this case corresponds to the entire stream of bytes in a
direction. These Messages may be quite long, in which case they can direction. These Messages may be quite long, in which case they can
be sent in multiple parts. be sent in multiple parts.
Protocols that provide the framing (such as length-value protocols, Protocols that provide the framing (such as length-value protocols,
or protocols that use delimiters) provide data boundaries that may be or protocols that use delimiters) may support Message sizes that do
longer than a traditional packet datagram. Each Message for framing not fit within a single datagram. Each Message for framing protocols
protocols corresponds to a single frame, which may be sent either as corresponds to a single frame, which may be sent either as a complete
a complete Message, or in multiple parts. Message in the underlying protocol, or in multiple parts.
5.1. Sending Messages 5.1. Sending Messages
The effect of the application sending a Message is determined by the The effect of the application sending a Message is determined by the
top-level protocol in the established Protocol Stack. That is, if top-level protocol in the established Protocol Stack. That is, if
the top-level protocol provides an abstraction of framed messages the top-level protocol provides an abstraction of framed messages
over a connection, the receiving application will be able to obtain over a connection, the receiving application will be able to obtain
multiple Messages on that connection, even if the framing protocol is multiple Messages on that connection, even if the framing protocol is
built on a byte-stream protocol like TCP. built on a byte-stream protocol like TCP.
skipping to change at page 23, line 11 skipping to change at page 23, line 24
* Priority: this represents the ability to prioritize a Message over * Priority: this represents the ability to prioritize a Message over
other Messages. This can be implemented by the system re-ordering other Messages. This can be implemented by the system re-ordering
Messages that have yet to be handed to the Protocol Stack, or by Messages that have yet to be handed to the Protocol Stack, or by
giving relative priority hints to protocols that support giving relative priority hints to protocols that support
priorities per Message. For example, an implementation of HTTP/2 priorities per Message. For example, an implementation of HTTP/2
could choose to send Messages of different Priority on streams of could choose to send Messages of different Priority on streams of
different priority. different priority.
* Ordered: when this is false, this disables the requirement of in- * Ordered: when this is false, this disables the requirement of in-
order-delivery for protocols that support configurable ordering. order-delivery for protocols that support configurable ordering.
When the protocol stack does not support configurable ordering,
this property may be ignored.
* Safely Replayable: when this is true, this means that the Message * Safely Replayable: when this is true, this means that the Message
can be used by mechanisms that might transfer it multiple times - can be used by mechanisms that might transfer it multiple times -
e.g., as a result of racing multiple transports or as part of TCP e.g., as a result of racing multiple transports or as part of TCP
Fast Open. Also, protocols that do not protect against duplicated Fast Open. Also, protocols that do not protect against duplicated
messages, such as UDP, can only be used with Messages that are messages, such as UDP, can only be used with Messages that are
Safely Replayable. Safely Replayable.
* Final: when this is true, this means that a transport connection * Final: when this is true, this means that the sender will not send
can be closed immediately after transmission of the message. any further messages. The Connection need not be closed (in case
the Protocol Stack supports half-close operation, like TCP). Any
messages sent after a Final message will result in a SendError.
* Corruption Protection Length: when this is set to any value other * Corruption Protection Length: when this is set to any value other
than "Full Coverage", it sets the minimum protection in protocols than "Full Coverage", it sets the minimum protection in protocols
that allow limiting the checksum length (e.g. UDP-Lite). that allow limiting the checksum length (e.g. UDP-Lite). If the
protocol stack does not support checksum length limitation, this
property may be ignored.
* Reliable Data Transfer (Message): When true, the property * Reliable Data Transfer (Message): When true, the property
specifies that the Message must be reliably transmitted. When specifies that the Message must be reliably transmitted. When
false, and if unreliable transmission is supported by the false, and if unreliable transmission is supported by the
underlying protocol, then the Message should be unreliably underlying protocol, then the Message should be unreliably
transmitted. If the underlying protocol does not support transmitted. If the underlying protocol does not support
unreliable transmission, the Message should be reliably unreliable transmission, the Message should be reliably
transmitted. transmitted.
* Message Capacity Profile Override: When true, this expresses a * Message Capacity Profile Override: When true, this expresses a
wish to override the Generic Connection Property "Capacity wish to override the Generic Connection Property "Capacity
Profile" for this Message. Depending on the value, this can, for Profile" for this Message. Depending on the value, this can, for
example, be implemented by changing the DSCP value of the example, be implemented by changing the DSCP value of the
associated packet (note that the he guidelines in Section 6 of associated packet (note that the guidelines in Section 6 of
[RFC7657] apply; e.g., the DSCP value should not be changed for [RFC7657] apply; e.g., the DSCP value should not be changed for
different packets within a reliable transport protocol session or different packets within a reliable transport protocol session or
DCCP connection). DCCP connection).
* No Fragmentation: When set, this property limits the message size * No Fragmentation: When set, this property limits the message size
to the Maximum Message Size Before Fragmentation or Segmentation to the Maximum Message Size Before Fragmentation or Segmentation
(see Section 10.1.7 of [I-D.ietf-taps-interface]). Messages (see Section 10.1.7 of [I-D.ietf-taps-interface]). Messages
larger than this size generate an error. Setting this avoids larger than this size generate an error. Setting this avoids
transport-layer segmentation or network-layer fragmentation. When transport-layer segmentation or network-layer fragmentation. When
used with transports running over IP version 4 the Don't Fragment used with transports running over IP version 4 the Don't Fragment
bit will be set to avoid on-path IP fragmentation ([RFC8304]). bit will be set to avoid on-path IP fragmentation ([RFC8304]).
5.1.2. Send Completion 5.1.2. Send Completion
The application should be notified whenever a Message or partial The application should be notified whenever a Message or partial
Message has been consumed by the Protocol Stack, or has failed to Message has been consumed by the Protocol Stack, or has failed to
send. The meaning of the Message being consumed by the stack may send. The time at which a Message is considered to have been
vary depending on the protocol. For a basic datagram protocol like consumed by the Protocol Stack may vary depending on the protocol.
UDP, this may correspond to the time when the packet is sent into the For example, for a basic datagram protocol like UDP, this may
interface driver. For a protocol that buffers data in queues, like correspond to the time when the packet is sent into the interface
TCP, this may correspond to when the data has entered the send driver. For a protocol that buffers data in queues, like TCP, this
buffer. may correspond to when the data has entered the send buffer. The
time at which a message has failed to send is after the Protocol
Stack or the Transport Services implementation itself has not
successfully sent the entire Message content or partial Message
content on any open candidate connection; this may depend on
protocol-specific timeouts.
5.1.3. Batching Sends 5.1.3. Batching Sends
Since sending a Message may involve a context switch between the Since sending a Message may involve a context switch between the
application and the transport system, sending patterns that involve application and the transport system, sending patterns that involve
multiple small Messages can incur high overhead if each needs to be multiple small Messages can incur high overhead if each needs to be
enqueued separately. To avoid this, the application can indicate a enqueued separately. To avoid this, the application can indicate a
batch of Send actions through the API. When this is used, the batch of Send actions through the API. When this is used, the
implementation should hold off on processing Messages until the batch implementation can defer the processing of Messages until the batch
is complete. is complete.
5.2. Receiving Messages 5.2. Receiving Messages
Similar to sending, Receiving a Message is determined by the top- Similar to sending, Receiving a Message is determined by the top-
level protocol in the established Protocol Stack. The main level protocol in the established Protocol Stack. The main
difference with Receiving is that the size and boundaries of the difference with Receiving is that the size and boundaries of the
Message are not known beforehand. The application can communicate in Message are not known beforehand. The application can communicate in
its Receive action the parameters for the Message, which can help the its Receive action the parameters for the Message, which can help the
implementation know how much data to deliver and when. For example, implementation know how much data to deliver and when. For example,
skipping to change at page 24, line 45 skipping to change at page 25, line 24
implementation should wait until an entire Message (datagram, stream, implementation should wait until an entire Message (datagram, stream,
or frame) is read before delivering any Message content to the or frame) is read before delivering any Message content to the
application. This requires the implementation to understand where application. This requires the implementation to understand where
messages end, either via a supplied deframer or because the top-level messages end, either via a supplied deframer or because the top-level
protocol in the established Protocol Stack preserves message protocol in the established Protocol Stack preserves message
boundaries. If the top-level protocol only supports a byte-stream boundaries. If the top-level protocol only supports a byte-stream
and no framers were supported, the application can control the flow and no framers were supported, the application can control the flow
of received data by specifying the minimum number of bytes of Message of received data by specifying the minimum number of bytes of Message
content it wants to receive at one time. content it wants to receive at one time.
If a Connection becomes finished before a requested Receive action If a Connection finishes before a requested Receive action can be
can be satisfied, the implementation should deliver any partial satisfied, the implementation should deliver any partial Message
Message content outstanding, or if none is available, an indication content outstanding, or if none is available, an indication that
that there will be no more received Messages. there will be no more received Messages.
5.3. Handling of data for fast-open protocols 5.3. Handling of data for fast-open protocols
Several protocols allow sending higher-level protocol or application Several protocols allow sending higher-level protocol or application
data during their protocol establishment, such as TCP Fast Open data during their protocol establishment, such as TCP Fast Open
[RFC7413] and TLS 1.3 [RFC8446]. This approach is referred to as [RFC7413] and TLS 1.3 [RFC8446]. This approach is referred to as
sending Zero-RTT (0-RTT) data. This is a desirable property, but sending Zero-RTT (0-RTT) data. This is a desirable feature, but
poses challenges to an implementation that uses racing during poses challenges to an implementation that uses racing during
connection establishment. connection establishment.
The amount of data that can be sent as 0-RTT data varies by protocol The amount of data that can be sent as 0-RTT data varies by protocol
and can be queried by the application using the "Maximum Message Size and can be queried by the application using the "Maximum Message Size
Concurrent with Connection Establishment" Connection Property. An Concurrent with Connection Establishment" Connection Property. An
implementation can set this property according to the protocols that implementation can set this property according to the protocols that
it will race based on the given Selection Properties when the it will race based on the given Selection Properties when the
application requests to establish a connection. application requests to establish a connection.
skipping to change at page 26, line 10 skipping to change at page 26, line 34
or PSK should only be used on one leaf node, since servers will or PSK should only be used on one leaf node, since servers will
likely reject duplicate tickets in order to prevent replays (see likely reject duplicate tickets in order to prevent replays (see
section-8.1 [RFC8446]). If implementations have multiple tickets section-8.1 [RFC8446]). If implementations have multiple tickets
available from a previous connection, each leaf node attempt can use available from a previous connection, each leaf node attempt can use
a different ticket. In effect, each leaf node will send the same a different ticket. In effect, each leaf node will send the same
early application data, yet encoded (encrypted) differently on the early application data, yet encoded (encrypted) differently on the
wire. wire.
6. Implementing Message Framers 6. Implementing Message Framers
Message Framers are pieces of code that define simple transformations Message Framers are functions that define simple transformations
between application Message data and raw transport protocol data. A between application Message data and raw transport protocol data. A
Framer can encapsulate or encode outbound Messages, and decapsulate Framer can encapsulate or encode outbound Messages, and decapsulate
or decode inbound data into Messages. or decode inbound data into Messages.
While many protocols can be represented as Message Framers, for the While many protocols can be represented as Message Framers, for the
purposes of the Transport Services interface these are ways for purposes of the Transport Services interface these are ways for
applications or application frameworks to define their own Message applications or application frameworks to define their own Message
parsing to be included within a Connection's Protocol Stack. As an parsing to be included within a Connection's Protocol Stack. As an
example, TLS can serve the purpose of framing data over TCP, but is example, TLS is exposed as a protocol natively supported by the
exposed as a protocol natively supported by the Transport Services Transport Services interface, even though it could also serve the
interface. purpose of framing data over TCP.
Most Message Framers fall into one of two categories: Most Message Framers fall into one of two categories:
* Header-prefixed record formats, such as a basic Type-Length-Value * Header-prefixed record formats, such as a basic Type-Length-Value
(TLV) structure (TLV) structure
* Delimiter-separated formats, such as HTTP/1.1. * Delimiter-separated formats, such as HTTP/1.1.
Common Message Framers can be provided by the Transport Services Common Message Framers can be provided by the Transport Services
implementation, but an implementation ought to allow custom Message implementation, but an implementation ought to allow custom Message
Framers to be defined by the application or some other piece of Framers to be defined by the application or some other piece of
software. This section describes one possible interface for defining software. This section describes one possible interface for defining
Message Framers as an example. Message Framers as an example.
6.1. Defining Message Framers 6.1. Defining Message Framers
A Message Framer is primarily defined by the set of code that handles A Message Framer is primarily defined by the code that handles events
events for a framer implementation, specifically how it handles for a framer implementation, specifically how it handles inbound and
inbound and outbound data parsing. The piece of code that implements outbound data parsing. The function that implements custom framing
custom framing logic will be referred to as the "framer logic will be referred to as the "framer implementation", which may
implementation", which may be provided by the Transport Services be provided by the Transport Services implementation or the
implementation or the application itself. The Message Framer refers application itself. The Message Framer refers to the object or
to the object or piece of code within the main Connection function within the main Connection implementation that delivers
implementation that delivers events to the custom framer events to the custom framer implementation whenever data is ready to
implementation whenever data is ready to be parsed or framed. be parsed or framed.
When a Connection establishment attempt begins, an event can be When a Connection establishment attempt begins, an event can be
delivered to notify the framer implementation that a new Connection delivered to notify the framer implementation that a new Connection
is being created. Similarly, a stop event can be delivered when a is being created. Similarly, a stop event can be delivered when a
Connection is being torn down. The framer implementation can use the Connection is being torn down. The framer implementation can use the
Connection object to look up specific properties of the Connection or Connection object to look up specific properties of the Connection or
the network being used that may influence how to frame Messages. the network being used that may influence how to frame Messages.
MessageFramer -> Start(Connection) MessageFramer -> Start(Connection)
MessageFramer -> Stop(Connection) MessageFramer -> Stop(Connection)
skipping to change at page 27, line 45 skipping to change at page 28, line 16
Should the framer implementation deem the candidate selected during Should the framer implementation deem the candidate selected during
racing unsuitable it can signal this by failing the Connection prior racing unsuitable it can signal this by failing the Connection prior
to marking it as ready. If there are no other candidates available, to marking it as ready. If there are no other candidates available,
the Connection will fail. Otherwise, the Connection will select a the Connection will fail. Otherwise, the Connection will select a
different candidate and the Message Framer will generate a new different candidate and the Message Framer will generate a new
"Start" event. "Start" event.
Before an implementation marks a Message Framer as ready, it can also Before an implementation marks a Message Framer as ready, it can also
dynamically add a protocol or framer above it in the stack. This dynamically add a protocol or framer above it in the stack. This
allows protocols like STARTTLS, that need to add TLS conditionally, allows protocols that need to add TLS conditionally, like STARTTLS
to modify the Protocol Stack based on a handshake result. [RFC3207], to modify the Protocol Stack based on a handshake result.
otherFramer := NewMessageFramer() otherFramer := NewMessageFramer()
MessageFramer.PrependFramer(Connection, otherFramer) MessageFramer.PrependFramer(Connection, otherFramer)
A Message Framer might also choose to go into a passthrough mode once
an initial exchange or handshake has been completed, such as the
STARTTLS case mentioned above. This can also be useful for proxy
protocols like SOCKS [RFC1928] or HTTP CONNECT [RFC7230]. In such
cases, a Message Framer implementation can intercept sending and
receiving of messages at first, but then indicate that no more
processing is needed.
MessageFramer.StartPassthrough()
6.2. Sender-side Message Framing 6.2. Sender-side Message Framing
Message Framers generate an event whenever a Connection sends a new Message Framers generate an event whenever a Connection sends a new
Message. Message.
MessageFramer -> NewSentMessage<Connection, MessageData, MessageContext, IsEndOfMessage> MessageFramer -> NewSentMessage<Connection, MessageData, MessageContext, IsEndOfMessage>
Upon receiving this event, a framer implementation is responsible for Upon receiving this event, a framer implementation is responsible for
performing any necessary transformations and sending the resulting performing any necessary transformations and sending the resulting
data back to the Message Framer, which will in turn send it to the data back to the Message Framer, which will in turn send it to the
skipping to change at page 29, line 34 skipping to change at page 30, line 16
Once a Connection is established, the Transport Services system Once a Connection is established, the Transport Services system
allows applications to interact with the Connection by modifying or allows applications to interact with the Connection by modifying or
inspecting Connection Properties. A Connection can also generate inspecting Connection Properties. A Connection can also generate
events in the form of Soft Errors. events in the form of Soft Errors.
The set of Connection Properties that are supported for setting and The set of Connection Properties that are supported for setting and
getting on a Connection are described in [I-D.ietf-taps-interface]. getting on a Connection are described in [I-D.ietf-taps-interface].
For any properties that are generic, and thus could apply to all For any properties that are generic, and thus could apply to all
protocols being used by a Connection, the Transport System should protocols being used by a Connection, the Transport System should
store the properties in a generic storage, and notify all protocol store the properties in storage common to all protocols, and notify
instances in the Protocol Stack whenever the properties have been all protocol instances in the Protocol Stack whenever the properties
modified by the application. For protocol-specfic properties, such have been modified by the application. For protocol-specfic
as the User Timeout that applies to TCP, the Transport System only properties, such as the User Timeout that applies to TCP, the
needs to update the relevant protocol instance. Transport System only needs to update the relevant protocol instance.
If an error is encountered in setting a property (for example, if the If an error is encountered in setting a property (for example, if the
application tries to set a TCP-specific property on a Connection that application tries to set a TCP-specific property on a Connection that
is not using TCP), the action should fail gracefully. The is not using TCP), the action should fail gracefully. The
application may be informed of the error, but the Connection itself application may be informed of the error, but the Connection itself
should not be terminated. should not be terminated.
The Transport Services implementation should allow protocol instances The Transport Services implementation should allow protocol instances
in the Protocol Stack to pass up arbitrary generic or protocol- in the Protocol Stack to pass up arbitrary generic or protocol-
specific errors that can be delivered to the application as Soft specific errors that can be delivered to the application as Soft
skipping to change at page 30, line 25 skipping to change at page 31, line 9
all of these satisfy the requirements, and prohibitions specified in all of these satisfy the requirements, and prohibitions specified in
the Selection Properties of the Pooled Connection. This enables the Selection Properties of the Pooled Connection. This enables
implementations to realize transparent connection coalescing, implementations to realize transparent connection coalescing,
connection migration, and to perform per-message endpoint and path connection migration, and to perform per-message endpoint and path
selection by choosing among these underlying connections. selection by choosing among these underlying connections.
7.2. Handling Path Changes 7.2. Handling Path Changes
When a path change occurs, e.g., when the IP address of an interface When a path change occurs, e.g., when the IP address of an interface
changes or a new interface becomes available, the Transport Services changes or a new interface becomes available, the Transport Services
implementation is responsible for notifying the application of the implementation is responsible for notifying the Protocol Instance of
change. The path change may interrupt connectivity on a path for an the change. The path change may interrupt connectivity on a path for
active connection or provide an opportunity for a transport that an active connection or provide an opportunity for a transport that
supports multipath or migration to adapt to the new paths. supports multipath or migration to adapt to the new paths. Note
that, from the Transport Services API point of view, migration is
considered a part of multipath connectivity; it is just a limiting
policy on multipath usage. If the "multipath" Selection Property is
set to "Disabled", migration is disallowed.
For protocols that do not support multipath or migration, the For protocols that do not support multipath or migration, the
Protocol Instances should be informed of the path change, but should Protocol Instances should be informed of the path change, but should
not be forcibly disconnected if the previously used path becomes not be forcibly disconnected if the previously used path becomes
unavailable. unavailable. There are many common user scenarios that can lead to a
path becoming temporarily unavailable, and then recovering before the
transport protocol reaches a timeout error. These are particularly
common using mobile devices. Examples include: an Ethernet cable
becoming unplugged and then plugged back in; a device losing a Wi-Fi
signal while a user is in an elevator, and reattaching when the user
leaves the elevator; and a user losing the radio signal while riding
a train through a tunnel. If the device is able to rejoin a network
with the same IP address, a stateful transport connection can
generally resume. Thus, while it is useful for a Protocol Instance
to be aware of a temporary loss of connectivity, the Transport
Services implementation should not aggressively close connections in
these scenarios.
If the Protocol Stack includes a transport protocol that also If the Protocol Stack includes a transport protocol that supports
supports multipath connectivity with migration support, the Transport multipath connectivity, the Transport Services implementation should
Services implementation should also inform the Protocol Instance of also inform the Protocol Instance of potentially new paths that
potentially new paths that become permissible based on the Selection become permissible based on the "multipath" Selection Property and
Properties passed by the application. A protocol can then establish the "multipath-policy" Connection Property choices made by the
new subflows over new paths while an active path is still available application. A protocol can then establish new subflows over new
or, if migration is supported, also after a break has been detected, paths while an active path is still available or, if migration is
and should attempt to tear down subflows over paths that are no supported, also after a break has been detected, and should attempt
longer used. The Transport Services API provides an interface to set to tear down subflows over paths that are no longer used. The
a multipath policy that indicates when and how different paths should Transport Services API's Connection Property "multipath-policy"
allows an application to indicate when and how different paths should
be used. However, detailed handling of these policies is still be used. However, detailed handling of these policies is still
implementation-specific. The decision about when to create a new implementation-specific. For example, if the "multipath" Selection
Property is set to "active", the decision about when to create a new
path or to announce a new path or set of paths to the remote path or to announce a new path or set of paths to the remote
endpoint, e.g., in the form of additional IP addresses, is endpoint, e.g., in the form of additional IP addresses, is
implementation-specific or could be be supported by future API implementation-specific. If the Protocol Stack includes a transport
extensions. If the Protocol Stack includes a transport protocol that protocol that does not support multipath, but does support migrating
does not support multipath, but does support migrating between paths, between paths, the update to the set of available paths can trigger
the update to the set of available paths can trigger the connection the connection to be migrated.
to be migrated.
In case of Pooled Connections Section 7.1, the transport system may In case of Pooled Connections Section 7.1, the Transport Services
add connections over new paths or different protocols to the pool if implementation may add connections over new paths to the pool if
permissible based on the multipath policy and Selection Properties. permissible based on the multipath policy and Selection Properties.
In case a previously used path becomes unavailable, the transport In case a previously used path becomes unavailable, the transport
system may disconnect all connections that require this path, but system may disconnect all connections that require this path, but
should not disconnect the pooled connection object exposed to the should not disconnect the pooled connection object exposed to the
application. The strategy how is implementation-specific, but should application. The strategy to do so is implementation-specific, but
be consistent with the behavior of multipath transports. should be consistent with the behavior of multipath transports.
8. Implementing Connection Termination 8. Implementing Connection Termination
With TCP, when an application closes a connection, this means that it With TCP, when an application closes a connection, this means that it
has no more data to send (but expects all data that has been handed has no more data to send (but expects all data that has been handed
over to be reliably delivered). However, with TCP only, "close" does over to be reliably delivered). However, with TCP only, "close" does
not mean that the application will stop receiving data. This is not mean that the application will stop receiving data. This is
related to TCP's ability to support half-closed connections. related to TCP's ability to support half-closed connections.
SCTP is an example of a protocol that does not support such half- SCTP is an example of a protocol that does not support such half-
skipping to change at page 33, line 31 skipping to change at page 34, line 22
* TCP can cache cookies for use in TCP Fast Open. * TCP can cache cookies for use in TCP Fast Open.
Cached protocol state is primarily used during Connection Cached protocol state is primarily used during Connection
establishment for a single Protocol Stack, but may be used to establishment for a single Protocol Stack, but may be used to
influence an implementation's preference between several candidate influence an implementation's preference between several candidate
Protocol Stacks. For example, if two IP address Endpoints are Protocol Stacks. For example, if two IP address Endpoints are
otherwise equally preferred, an implementation may choose to attempt otherwise equally preferred, an implementation may choose to attempt
a connection to an address for which it has a TCP Fast Open cookie. a connection to an address for which it has a TCP Fast Open cookie.
Applications must have a way to flush protocol cache state if Applications can request that a Connection Group maintain a separate
desired. This may be necessary, for example, if application-layer cache for protocol state. Connections in the group will not use
cached state from connections outside the group, and connections
outside the group will not use state cached from connections inside
the group. This may be necessary, for example, if application-layer
identifiers rotate and clients wish to avoid linkability via identifiers rotate and clients wish to avoid linkability via
trackable TLS tickets or TFO cookies. trackable TLS tickets or TFO cookies.
9.2. Performance caches 9.2. Performance caches
In addition to protocol state, Protocol Instances should provide data In addition to protocol state, Protocol Instances should provide data
into a performance-oriented cache to help guide future protocol and into a performance-oriented cache to help guide future protocol and
path selection. Some performance information can be gathered path selection. Some performance information can be gathered
generically across several protocols to allow predictive comparisons generically across several protocols to allow predictive comparisons
between protocols on given paths: between protocols on given paths:
skipping to change at page 34, line 14 skipping to change at page 35, line 17
different network attachments will have different performance different network attachments will have different performance
characteristics. Besides Protocol Instances, other system entities characteristics. Besides Protocol Instances, other system entities
may also provide data into performance-oriented caches. This could may also provide data into performance-oriented caches. This could
for instance be signal strength information reported by radio modems for instance be signal strength information reported by radio modems
like Wi-Fi and mobile broadband or information about the battery- like Wi-Fi and mobile broadband or information about the battery-
level of the device. Furthermore, the system may cache the observed level of the device. Furthermore, the system may cache the observed
maximum throughput on a path as an estimate of the available maximum throughput on a path as an estimate of the available
bandwidth. bandwidth.
An implementation should use this information, when possible, to An implementation should use this information, when possible, to
determine preference between candidate paths, endpoints, and protocol influence preference between candidate paths, endpoints, and protocol
options. Eligible options that historically had significantly better options. Eligible options that historically had significantly better
performance than others should be selected first when gathering performance than others should be selected first when gathering
candidates (see Section 4.1) to ensure better performance for the candidates (see Section 4.1) to ensure better performance for the
application. application.
The reasonable lifetime for cached performance values will vary The reasonable lifetime for cached performance values will vary
depending on the nature of the value. Certain information, like the depending on the nature of the value. Certain information, like the
connection establishment success rate to a Remote Endpoint using a connection establishment success rate to a Remote Endpoint using a
given protocol stack, can be stored for a long period of time (hours given protocol stack, can be stored for a long period of time (hours
or longer), since it is expected that the capabilities of the Remote or longer), since it is expected that the capabilities of the Remote
skipping to change at page 34, line 46 skipping to change at page 35, line 49
Each protocol that can run as part of a Transport Services Each protocol that can run as part of a Transport Services
implementation should have a well-defined API mapping. API mappings implementation should have a well-defined API mapping. API mappings
for a protocol apply most to Connections in which the given protocol for a protocol apply most to Connections in which the given protocol
is the "top" of the Protocol Stack. For example, the mapping of the is the "top" of the Protocol Stack. For example, the mapping of the
"Send" function for TCP applies to Connections in which the "Send" function for TCP applies to Connections in which the
application directly sends over TCP. application directly sends over TCP.
Each protocol has a notion of Connectedness. Possible values for Each protocol has a notion of Connectedness. Possible values for
Connectedness are: Connectedness are:
* Unconnected. Unconnected protocols do not establish explicit * Connectionless. Connectionless protocols do not establish
state between endpoints, and do not perform a handshake during explicit state between endpoints, and do not perform a handshake
Connection establishment. during Connection establishment.
* Connected. Connected protocols establish state between endpoints, * Connected. Connected protocols establish state between endpoints,
and perform a handshake during Connection establishment. The and perform a handshake during Connection establishment. The
handshake may be 0-RTT to send data or resume a session, but handshake may be 0-RTT to send data or resume a session, but
bidirectional traffic is required to confirm connectedness. bidirectional traffic is required to confirm connectedness.
* Multiplexing Connected. Multiplexing Connected protocols share * Multiplexing Connected. Multiplexing Connected protocols share
properties with Connected protocols, but also explictly support properties with Connected protocols, but also explictly support
opening multiple application-level flows. This means that they opening multiple application-level flows. This means that they
can support cloning new Connection objects without a new explicit can support cloning new Connection objects without a new explicit
skipping to change at page 36, line 25 skipping to change at page 37, line 25
Ready: A TCP Connection is ready once the three-way handshake is Ready: A TCP Connection is ready once the three-way handshake is
complete. complete.
InitiateError: Failure of CONNECT.TCP. TCP can throw various errors InitiateError: Failure of CONNECT.TCP. TCP can throw various errors
during connection setup. Specifically, it is important to handle during connection setup. Specifically, it is important to handle
a RST being sent by the peer during the handshake. a RST being sent by the peer during the handshake.
ConnectionError: Once established, TCP throws errors whenever the ConnectionError: Once established, TCP throws errors whenever the
connection is disconnected, such as due to receiving a RST from connection is disconnected, such as due to receiving a RST from
the peer; or hitting a TCP retransmission timeout. the peer.
Listen: LISTEN.TCP. Calling "Listen" for TCP binds a local port and Listen: LISTEN.TCP. Calling "Listen" for TCP binds a local port and
prepares it to receive inbound SYN packets from peers. prepares it to receive inbound SYN packets from peers.
ConnectionReceived: TCP Listeners will deliver new connections once ConnectionReceived: TCP Listeners will deliver new connections once
they have replied to an inbound SYN with a SYN-ACK. they have replied to an inbound SYN with a SYN-ACK.
Clone: Calling "Clone" on a TCP Connection creates a new Connection Clone: Calling "Clone" on a TCP Connection creates a new Connection
with equivalent parameters. The two Connections are otherwise with equivalent parameters. These Connections, and Connections
independent. generated via later calls to "Clone" on one of them, form a
Connection Group. To realize entanglement for these Connections,
with the exception of "Connection Priority", changing a Connection
Property on one of them must affect the Connection Properties of
the others too. No guarantees of honoring the Connection Property
"Connection Priority" are given, and thus it is safe for an
implementation of a transport system to ignore this property.
When it is reasonable to assume that Connections traverse the same
path (e.g., when they share the same encapsulation), support for
it can also experimentally be implemented using a congestion
control coupling mechanism (see for example [TCP-COUPLING] or
[RFC3124]).
Send: SEND.TCP. TCP does not on its own preserve Message Send: SEND.TCP. TCP does not on its own preserve Message
boundaries. Calling "Send" on a TCP connection lays out the bytes boundaries. Calling "Send" on a TCP connection lays out the bytes
on the TCP send stream without any other delineation. Any Message on the TCP send stream without any other delineation. Any Message
marked as Final will cause TCP to send a FIN once the Message has marked as Final will cause TCP to send a FIN once the Message has
been completely written, by calling CLOSE.TCP immediately upon been completely written, by calling CLOSE.TCP immediately upon
successful termination of SEND.TCP. successful termination of SEND.TCP. Note that transmitting a
Message marked as Final should not cause the "Closed" event to be
delivered to the application, as it will still be possible to
receive data until the peer closes or aborts the TCP connection.
Receive: With RECEIVE.TCP, TCP delivers a stream of bytes without Receive: With RECEIVE.TCP, TCP delivers a stream of bytes without
any Message delineation. All data delivered in the "Received" or any Message delineation. All data delivered in the "Received" or
"ReceivedPartial" event will be part of a single stream-wide "ReceivedPartial" event will be part of a single stream-wide
Message that is marked Final (unless a Message Framer is used). Message that is marked Final (unless a Message Framer is used).
EndOfMessage will be delivered when the TCP Connection has EndOfMessage will be delivered when the TCP Connection has
received a FIN (CLOSE-EVENT.TCP or ABORT-EVENT.TCP) from the peer. received a FIN (CLOSE-EVENT.TCP) from the peer. Note that
reception of a FIN should not cause the "Closed" event to be
delivered to the application, as it will still be possible for the
application to send data.
Close: Calling "Close" on a TCP Connection indicates that the Close: Calling "Close" on a TCP Connection indicates that the
Connection should be gracefully closed (CLOSE.TCP) by sending a Connection should be gracefully closed (CLOSE.TCP) by sending a
FIN to the peer and waiting for a FIN-ACK before delivering the FIN to the peer. It will then still be possible to receive data
"Closed" event. until the peer closes or aborts the TCP connection. The "Closed"
event will be issued upon reception of a FIN.
Abort: Calling "Abort" on a TCP Connection indicates that the Abort: Calling "Abort" on a TCP Connection indicates that the
Connection should be immediately closed by sending a RST to the Connection should be immediately closed by sending a RST to the
peer (ABORT.TCP). peer (ABORT.TCP).
10.2. MPTCP 10.2. MPTCP
Connectedness: Connected Connectedness: Connected
Data Unit: Byte-stream Data Unit: Byte-stream
API mappings for MPTCP are identical to TCP. MPTCP adds support for API mappings for MPTCP are identical to TCP. MPTCP adds support for
multipath properties, such as "Multi-Paths Transport" and "Policy for multipath properties, such as "Multipath Transport" and "Policy for
using Multi-Path Transports". using Multipath Transports".
10.3. UDP 10.3. UDP
Connectedness: Unconnected Connectedness: Connectionless
Data Unit: Datagram Data Unit: Datagram
API mappings for UDP are as follows: API mappings for UDP are as follows:
Connection Object: UDP connections represent a pair of specific IP Connection Object: UDP connections represent a pair of specific IP
addresses and ports on two hosts. addresses and ports on two hosts.
Initiate: CONNECT.UDP. Calling "Initiate" on a UDP Connection Initiate: CONNECT.UDP. Calling "Initiate" on a UDP Connection
causes it to reserve a local port, but does not generate any causes it to reserve a local port, but does not generate any
skipping to change at page 38, line 33 skipping to change at page 40, line 7
the IP header can be obtained (GET_ECN.UDP(-Lite)). the IP header can be obtained (GET_ECN.UDP(-Lite)).
Close: Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) Close: Calling "Close" on a UDP Connection (ABORT.UDP(-Lite))
releases the local port reservation. releases the local port reservation.
Abort: Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is Abort: Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is
identical to calling "Close". identical to calling "Close".
10.4. UDP-Lite 10.4. UDP-Lite
Connectedness: Unconnected Connectedness: Connectionless
Data Unit: Datagram Data Unit: Datagram
API mappings for UDP-Lite are identical to UDP. Properties that API mappings for UDP-Lite are identical to UDP. Properties that
require checksum coverage are not supported by UDP-Lite, such as require checksum coverage are not supported by UDP-Lite, such as
"Corruption Protection Length", "Full Checksum Coverage on Sending", "Corruption Protection Length", "Full Checksum Coverage on Sending",
"Required Minimum Corruption Protection Coverage for Receiving", and "Required Minimum Corruption Protection Coverage for Receiving", and
"Full Checksum Coverage on Receiving". "Full Checksum Coverage on Receiving".
10.5. UDP Multicast Receive 10.5. UDP Multicast Receive
Connectedness: Unconnected Connectedness: Connectionless
Data Unit: Datagram Data Unit: Datagram
API mappings for Receiving Multicast UDP are as follows: API mappings for Receiving Multicast UDP are as follows:
Connection Object: Established UDP Multicast Receive connections Connection Object: Established UDP Multicast Receive connections
represent a pair of specific IP addresses and ports. The represent a pair of specific IP addresses and ports. The
"unidirectional receive" transport property is required, and the "unidirectional receive" transport property is required, and the
local endpoint must be configured with a group IP address and a local endpoint must be configured with a group IP address and a
port. port.
skipping to change at page 41, line 5 skipping to change at page 42, line 22
the transport connection will use even stream numbers whereas the the transport connection will use even stream numbers whereas the
remote side will map its flows to odd stream numbers. Both sides remote side will map its flows to odd stream numbers. Both sides
maintain a status map of the assigned stream numbers. Generally, maintain a status map of the assigned stream numbers. Generally,
new streams must consume the lowest available (even or odd, new streams must consume the lowest available (even or odd,
depending on the side) stream number; this rule is relevant when depending on the side) stream number; this rule is relevant when
lower numbers become available because Connection objects lower numbers become available because Connection objects
associated to the streams are closed. associated to the streams are closed.
Initiate: If this is the only Connection object that is assigned to Initiate: If this is the only Connection object that is assigned to
the SCTP association or stream mapping has not been negotiated, the SCTP association or stream mapping has not been negotiated,
CONNECT.SCTP is called. Else, a new stream is used: if there are CONNECT.SCTP is called. Else, unless the Selection Property
enough streams available, "Initiate" is just a local operation "activeReadBeforeSend" is Preferred or Required, a new stream is
that assigns a new stream number to the Connection object. The used: if there are enough streams available, "Initiate" is just a
number of streams is negotiated as a parameter of the prior local operation that assigns a new stream number to the Connection
CONNECT.SCTP call, and it represents a trade-off between local object. The number of streams is negotiated as a parameter of the
resource usage and the number of Connection objects that can be prior CONNECT.SCTP call, and it represents a trade-off between
mapped without requiring a reconfiguration signal. When running local resource usage and the number of Connection objects that can
out of streams, ADD_STREAM.SCTP must be called. be mapped without requiring a reconfiguration signal. When
running out of streams, ADD_STREAM.SCTP must be called.
InitiateWithSend: If this is the only Connection object that is InitiateWithSend: If this is the only Connection object that is
assigned to the SCTP association or stream mapping has not been assigned to the SCTP association or stream mapping has not been
negotiated, CONNECT.SCTP is called with the "user message" negotiated, CONNECT.SCTP is called with the "user message"
parameter. Else, a new stream is used (see "Initiate" for how to parameter. Else, a new stream is used (see "Initiate" for how to
handle running out of streams), and this just sends the first handle running out of streams), and this just sends the first
message on a new stream. message on a new stream.
Ready: "Initiate" or "InitiateWithSend" returns without an error, Ready: "Initiate" or "InitiateWithSend" returns without an error,
i.e. SCTP's four-way handshake has completed. If an association i.e. SCTP's four-way handshake has completed. If an association
skipping to change at page 42, line 16 skipping to change at page 43, line 32
CONFIGURE_STREAM_SCHEDULER.SCTP is called to adjust the priorities CONFIGURE_STREAM_SCHEDULER.SCTP is called to adjust the priorities
of streams in the SCTP association. of streams in the SCTP association.
Send: SEND.SCTP. Message Properties such as "Lifetime" and Send: SEND.SCTP. Message Properties such as "Lifetime" and
"Ordered" map to parameters of this primitive. "Ordered" map to parameters of this primitive.
Receive: RECEIVE.SCTP. The "partial flag" of RECEIVE.SCTP invokes a Receive: RECEIVE.SCTP. The "partial flag" of RECEIVE.SCTP invokes a
"ReceivedPartial" event. "ReceivedPartial" event.
Close: If this is the only Connection object that is assigned to the Close: If this is the only Connection object that is assigned to the
SCTP association, CLOSE.SCTP is called. Else, the Connection object SCTP association, CLOSE.SCTP is called, and the "Closed" event will
is one out of several Connection objects that are assigned to the be delivered to the application upon the ensuing CLOSE-EVENT.SCTP.
same SCTP assocation, and RESET_STREAM.SCTP must be called, which Else, the Connection object is one out of several Connection objects
informs the peer that the stream will no longer be used for mapping that are assigned to the same SCTP assocation, and RESET_STREAM.SCTP
and can be used by future "Initiate", "InitiateWithSend" or "Listen" must be called, which informs the peer that the stream will no longer
calls. At the peer, the event RESET_STREAM-EVENT.SCTP will fire, be used for mapping and can be used by future "Initiate",
which the peer must answer by issuing RESET_STREAM.SCTP too. The "InitiateWithSend" or "Listen" calls. At the peer, the event
resulting local RESET_STREAM-EVENT.SCTP informs the transport system RESET_STREAM-EVENT.SCTP will fire, which the peer must answer by
that the stream number can now be re-used by the next "Initiate", issuing RESET_STREAM.SCTP too. The resulting local RESET_STREAM-
"InitiateWithSend" or "Listen" calls. EVENT.SCTP informs the transport system that the stream number can
now be re-used by the next "Initiate", "InitiateWithSend" or "Listen"
calls, and invokes a "Closed" event towards the application.
Abort: If this is the only Connection object that is assigned to the Abort: If this is the only Connection object that is assigned to the
SCTP association, ABORT.SCTP is called. Else, the Connection object SCTP association, ABORT.SCTP is called. Else, the Connection object
is one out of several Connection objects that are assigned to the is one out of several Connection objects that are assigned to the
same SCTP assocation, and shutdown proceeds as described under same SCTP assocation, and shutdown proceeds as described under
"Close". "Close".
11. IANA Considerations 11. 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.
12. Security Considerations 12. Security Considerations
[I-D.ietf-taps-arch] outlines general security consideration and [I-D.ietf-taps-arch] outlines general security consideration and
requirements for any system that implements the TAPS archtecture. requirements for any system that implements the Transport Services
[I-D.ietf-taps-interface] provides further discussion on security and archtecture. [I-D.ietf-taps-interface] provides further discussion
privacy implications of the TAPS API. This document provides on security and privacy implications of the Transport Services API.
additional guidance on implementation specifics for the TAPS API and This document provides additional guidance on implementation
as such the security considerations in both of these documents apply. specifics for the Transport Services API and as such the security
The next two subsections discuss further considerations that are considerations in both of these documents apply. The next two
specific to mechanisms specified in this document. subsections discuss further considerations that are specific to
mechanisms specified in this document.
12.1. Considerations for Candidate Gathering 12.1. Considerations for Candidate Gathering
Implementations should avoid downgrade attacks that allow network Implementations should avoid downgrade attacks that allow network
interference to cause the implementation to select less secure, or interference to cause the implementation to select less secure, or
entirely insecure, combinations of paths and protocols. entirely insecure, combinations of paths and protocols.
12.2. Considerations for Candidate Racing 12.2. Considerations for Candidate Racing
See Section 5.3 for security considerations around racing with 0-RTT See Section 5.3 for security considerations around racing with 0-RTT
skipping to change at page 44, line 4 skipping to change at page 45, line 26
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
This work has been supported by the Research Council of Norway under This work has been supported by the Research Council of Norway under
its "Toppforsk" programme through the "OCARINA" project. its "Toppforsk" programme through the "OCARINA" project.
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.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", Work in Progress, Internet-Draft, Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-arch-08, 13 July 2020, draft-ietf-taps-arch-09, 2 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-taps-arch- <https://www.ietf.org/internet-drafts/draft-ietf-taps-
08.txt>. arch-09.txt>.
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., Pauly,
Pauly, "An Abstract Application Layer Interface to T., and K. Rose, "An Abstract Application Layer Interface
Transport Services", Work in Progress, Internet-Draft, to Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-interface-09, 27 July 2020, draft-ietf-taps-interface-12, 9 April 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-taps- <https://www.ietf.org/internet-drafts/draft-ietf-taps-
interface-09.txt>. interface-12.txt>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
skipping to change at page 45, line 24 skipping to change at page 46, line 50
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/info/rfc8923>. October 2020, <https://www.rfc-editor.org/info/rfc8923>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-32, 20 October 2020, draft-ietf-quic-transport-34, 14 January 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <https://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-32.txt>. transport-34.txt>.
[I-D.ietf-tcpm-2140bis] [I-D.ietf-tcpm-2140bis]
Touch, J., Welzl, M., and S. Islam, "TCP Control Block Touch, J., Welzl, M., and S. Islam, "TCP Control Block
Interdependence", Work in Progress, Internet-Draft, draft- Interdependence", Work in Progress, Internet-Draft, draft-
ietf-tcpm-2140bis-05, 29 April 2020, <http://www.ietf.org/ ietf-tcpm-2140bis-11, 12 April 2021,
internet-drafts/draft-ietf-tcpm-2140bis-05.txt>. <https://www.ietf.org/internet-drafts/draft-ietf-tcpm-
2140bis-11.txt>.
[NEAT-flow-mapping] [NEAT-flow-mapping]
"Transparent Flow Mapping for NEAT", Workshop on Future of "Transparent Flow Mapping for NEAT", Workshop on Future of
Internet Transport (FIT 2017) , 2017. Internet Transport (FIT 2017) , 2017.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, DOI 10.17487/RFC3124, June 2001,
<https://www.rfc-editor.org/info/rfc3124>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>. <https://www.rfc-editor.org/info/rfc5766>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/info/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[TCP-COUPLING]
"ctrlTCP: Reducing Latency through Coupled, Heterogeneous
Multi-Flow TCP Congestion Control", IEEE INFOCOM Global
Internet Symposium (GI) workshop (GI 2018) , n.d..
Appendix A. API Mapping Template Appendix A. API Mapping Template
Any protocol mapping for the Transport Services API should follow a Any protocol mapping for the Transport Services API should follow a
common template. common template.
Connectedness: (Unconnected/Connected/Multiplexing Connected) Connectedness: (Connectionless/Connected/Multiplexing Connected)
Data Unit: (Byte-stream/Datagram/Message) Data Unit: (Byte-stream/Datagram/Message)
Connection Object: Connection Object:
Initiate: Initiate:
InitiateWithSend: InitiateWithSend:
Ready: Ready:
skipping to change at page 48, line 12 skipping to change at page 50, line 12
active open or using a multicast group address while not active open or using a multicast group address while not
requesting a unidirectional receive. requesting a unidirectional receive.
* NoCandidates: The configuration is valid, but none of the * NoCandidates: The configuration is valid, but none of the
available transport protocols can satisfy the transport properties available transport protocols can satisfy the transport properties
provided by the application. provided by the application.
* ResolutionFailed: The remote or local specifier provided by the * ResolutionFailed: The remote or local specifier provided by the
application can not be resolved. application can not be resolved.
* EstablishmentFailed: The TAPS system was unable to establish a * EstablishmentFailed: The Transport Services system was unable to
transport-layer connection to the remote endpoint specified by the establish a transport-layer connection to the remote endpoint
application. specified by the application.
* PolicyProhibited: The system policy prevents the transport system * PolicyProhibited: The system policy prevents the transport system
from performing the action requested by the application. from performing the action requested by the application.
* NotCloneable: The protocol stack is not capable of being cloned. * NotCloneable: The protocol stack is not capable of being cloned.
* MessageTooLarge: The message size is too big for the transport * MessageTooLarge: The message size is too big for the transport
system to handle. system to handle.
* ProtocolFailed: The underlying protocol stack failed. * ProtocolFailed: The underlying protocol stack failed.
skipping to change at page 50, line 29 skipping to change at page 52, line 29
Tom Jones Tom Jones
University of Aberdeen University of Aberdeen
Fraser Noble Building Fraser Noble Building
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
United Kingdom United Kingdom
Email: tom@erg.abdn.ac.uk Email: tom@erg.abdn.ac.uk
Philipp S. Tiesel Philipp S. Tiesel
TU Berlin SAP SE
Einsteinufer 25 Konrad-Zuse-Ring 10
10587 Berlin 14469 Potsdam
Germany Germany
Email: philipp@tiesel.net Email: philipp@tiesel.net
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
 End of changes. 91 change blocks. 
252 lines changed or deleted 347 lines changed or added

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