draft-ietf-taps-impl-10.txt   draft-ietf-taps-impl-11.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: 13 January 2022 Apple Inc. Expires: 13 July 2022 Apple Inc.
T. Enghardt T. Enghardt
Netflix Netflix
K-J. Grinnemo
Karlstad University
T. Jones
University of Aberdeen
P. Tiesel P. Tiesel
SAP SE SAP SE
C. Perkins
University of Glasgow
M. Welzl M. Welzl
University of Oslo University of Oslo
12 July 2021 9 January 2022
Implementing Interfaces to Transport Services Implementing Interfaces to Transport Services
draft-ietf-taps-impl-10 draft-ietf-taps-impl-11
Abstract Abstract
The Transport Services system enables applications to use transport The Transport Services system enables applications to use transport
protocols flexibly for network communication and defines a protocol- protocols flexibly for network communication and defines a protocol-
independent Transport Services Application Programming Interface independent Transport Services Application Programming Interface
(API) that is based on an asynchronous, event-driven interaction (API) that is based on an asynchronous, event-driven interaction
pattern. This document serves as a guide to implementation on how to pattern. This document serves as a guide to implementation on how to
build such a system. build such a system.
skipping to change at page 1, line 48 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 January 2022. This Internet-Draft will expire on 13 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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. Structuring Candidates as a Tree . . . . . . . . . . . . 8 4.1. Structuring Candidates as a Tree . . . . . . . . . . . . 8
skipping to change at page 3, line 4 skipping to change at page 2, line 48
4.7.2. Implementing listeners for Connectionless 4.7.2. Implementing listeners for Connectionless
Protocols . . . . . . . . . . . . . . . . . . . . . . 22 Protocols . . . . . . . . . . . . . . . . . . . . . . 22
4.7.3. Implementing listeners for Multiplexed Protocols . . 22 4.7.3. Implementing listeners for Multiplexed Protocols . . 22
5. Implementing Sending and Receiving Data . . . . . . . . . . . 23 5. Implementing Sending and Receiving Data . . . . . . . . . . . 23
5.1. Sending Messages . . . . . . . . . . . . . . . . . . . . 23 5.1. Sending Messages . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Message Properties . . . . . . . . . . . . . . . . . 23 5.1.1. Message Properties . . . . . . . . . . . . . . . . . 23
5.1.2. Send Completion . . . . . . . . . . . . . . . . . . . 25 5.1.2. Send Completion . . . . . . . . . . . . . . . . . . . 25
5.1.3. Batching Sends . . . . . . . . . . . . . . . . . . . 25 5.1.3. Batching Sends . . . . . . . . . . . . . . . . . . . 25
5.2. Receiving Messages . . . . . . . . . . . . . . . . . . . 25 5.2. Receiving Messages . . . . . . . . . . . . . . . . . . . 25
5.3. Handling of data for fast-open protocols . . . . . . . . 26 5.3. Handling of data for fast-open protocols . . . . . . . . 26
6. Implementing Message Framers . . . . . . . . . . . . . . . . 27 6. Implementing Message Framers . . . . . . . . . . . . . . . . 27
6.1. Defining Message Framers . . . . . . . . . . . . . . . . 28 6.1. Defining Message Framers . . . . . . . . . . . . . . . . 28
6.2. Sender-side Message Framing . . . . . . . . . . . . . . . 29 6.2. Sender-side Message Framing . . . . . . . . . . . . . . . 29
6.3. Receiver-side Message Framing . . . . . . . . . . . . . . 30 6.3. Receiver-side Message Framing . . . . . . . . . . . . . . 29
7. Implementing Connection Management . . . . . . . . . . . . . 31 7. Implementing Connection Management . . . . . . . . . . . . . 30
7.1. Pooled Connection . . . . . . . . . . . . . . . . . . . . 31 7.1. Pooled Connection . . . . . . . . . . . . . . . . . . . . 31
7.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 32 7.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 31
8. Implementing Connection Termination . . . . . . . . . . . . . 33 8. Implementing Connection Termination . . . . . . . . . . . . . 33
9. Cached State . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Cached State . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Protocol state caches . . . . . . . . . . . . . . . . . . 34 9.1. Protocol state caches . . . . . . . . . . . . . . . . . . 34
9.2. Performance caches . . . . . . . . . . . . . . . . . . . 35 9.2. Performance caches . . . . . . . . . . . . . . . . . . . 35
10. Specific Transport Protocol Considerations . . . . . . . . . 36 10. Specific Transport Protocol Considerations . . . . . . . . . 36
10.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.2. MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.2. MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.4. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 41 10.4. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 40
10.5. UDP Multicast Receive . . . . . . . . . . . . . . . . . 41 10.5. UDP Multicast Receive . . . . . . . . . . . . . . . . . 40
10.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 42 10.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 12. Security Considerations . . . . . . . . . . . . . . . . . . . 45
12.1. Considerations for Candidate Gathering . . . . . . . . . 45 12.1. Considerations for Candidate Gathering . . . . . . . . . 45
12.2. Considerations for Candidate Racing . . . . . . . . . . 45 12.2. Considerations for Candidate Racing . . . . . . . . . . 45
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.1. Normative References . . . . . . . . . . . . . . . . . . 46 14.1. Normative References . . . . . . . . . . . . . . . . . . 46
14.2. Informative References . . . . . . . . . . . . . . . . . 47 14.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. API Mapping Template . . . . . . . . . . . . . . . . 49 Appendix A. API Mapping Template . . . . . . . . . . . . . . . . 49
Appendix B. Additional Properties . . . . . . . . . . . . . . . 50 Appendix B. Additional Properties . . . . . . . . . . . . . . . 50
B.1. Properties Affecting Sorting of Branches . . . . . . . . 50 B.1. Properties Affecting Sorting of Branches . . . . . . . . 50
Appendix C. Reasons for errors . . . . . . . . . . . . . . . . . 51 Appendix C. Reasons for errors . . . . . . . . . . . . . . . . . 51
Appendix D. Existing Implementations . . . . . . . . . . . . . . 52 Appendix D. Existing Implementations . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
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 flexibly use transport networking
flexibly. The interface such a system exposes to applications is protocols. The API that 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.
This document serves as a guide to implementation on how to build a This document serves as a guide to implementation on how to build a
system that provides a Transport Services API. It is the job of an system that provides a Transport Services API. It is the job of an
implementation of a Transport Services system to turn the requests of implementation of a Transport Services system to turn the requests of
an application into decisions on how to establish connections, and an application into decisions on how to establish connections, and
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
skipping to change at page 4, line 45 skipping to change at page 4, line 37
specific transport protocol instance, since multiple candidate specific transport protocol instance, since multiple candidate
Protocol Stacks might be raced. Protocol Stacks might be raced.
Once a Preconnection has been used to create an outbound Connection Once a Preconnection has been used to create an outbound Connection
or a Listener, the implementation should ensure that the copy of the or a Listener, the implementation should ensure that the copy of the
properties held by the Connection or Listener is not affected when properties held by the Connection or Listener is not affected when
the application makes changes to a Preconnection object. This may the application makes changes to a Preconnection object. This may
involve the implementation performing a deep-copy, copying the object involve the implementation performing a deep-copy, copying the object
with all the objects that it references. with all the objects that it references.
Once the Connection is established, its interface maps actions and Once the Connection is established, Transport Services implementation
events to the details of the chosen Protocol Stack. For example, the maps actions and events to the details of the chosen Protocol Stack.
same Connection object may ultimately represent a single instance of For example, the same Connection object may ultimately represent a
one transport protocol (e.g., a TCP connection, a TLS session over single instance of one transport protocol (e.g., a TCP connection, a
TCP, a UDP flow with fully-specified Local and Remote Endpoints, a TLS session over TCP, a UDP flow with fully-specified Local and
DTLS session, a SCTP stream, a QUIC stream, or an HTTP/2 stream). Remote Endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an
The properties held by a Connection or Listener is independent of HTTP/2 stream). The properties held by a Connection or Listener is
other connections that are not part of the same Connection Group. independent of other connections that are not part of the same
Connection Group.
Once Initate has been called, the Selection Properties and Endpoint Connection establishment is only a local operation for a Datagram
transport (e.g., UDP(-Lite)), which serves to simplify the local
send/receive functions and to filter the traffic for the specified
addresses and ports [RFC8085].
Once Initiate has been called, the Selection Properties and Endpoint
information are immutable (i.e, an application is not able to later information are immutable (i.e, an application is not able to later
modify Selection Properties on the original Preconnection object). modify Selection Properties on the original Preconnection object).
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.7. Section 4.7.
3. Implementing Pre-Establishment 3. Implementing Pre-Establishment
During pre-establishment the application specifies one or more During pre-establishment the application specifies one or more
skipping to change at page 5, line 42 skipping to change at page 5, line 42
The Transport Services system should have a list of supported The Transport Services system should have a list of supported
protocols available, which each have transport features reflecting protocols available, which each have transport features reflecting
the 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 cannot be
requirements or prohibitions that cannot be satisfied by any of satisfied by any of the available protocols. For example, if an
the available protocols. For example, if an application requires application requires "Configure Reliability per Message", but no
"Configure Reliability per Message", but no such feature is such feature is available in any protocol the host running the
available in any protocol the host running the transport system on transport system on the host running the transport system this
the host running the transport system this should result in an should result in an error, e.g., when SCTP is not supported by the
error, e.g., when SCTP is not supported by the 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 that are not finally needed, it is To avoid allocating resources that are not finally needed, it is
important that configuration-time errors fail as early as possible. important that configuration-time errors fail as early as possible.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
interfaces, supported transport protocols, and current/previous interfaces, supported transport protocols, and current/previous
Connections. Examples of ways to externally retrieve policy- Connections. Examples of ways to externally retrieve policy-
support information are through OS-specific statistics/ support information are through OS-specific statistics/
measurement tools and tools that reside on middleboxes and measurement tools and tools that reside on middleboxes and
routers. routers.
3. Default implementation policy, i.e., predefined policy by OS or 3. Default implementation policy, i.e., predefined policy by OS or
application. application.
In general, any protocol or path used for a connection must conform In general, any protocol or path used for a connection must conform
to all three sources of constraints. A violation of any of the to all three sources of constraints. A violation that occurs at any
layers should cause a protocol or path to be considered ineligible of the policy layers should cause a protocol or path to be considered
for use. For an example of application preferences leading to ineligible for use. For an example of application preferences
constraints, an application may prohibit the use of metered network leading to constraints, an application may prohibit the use of
interfaces for a given Connection to avoid user cost. Similarly, the metered network interfaces for a given Connection to avoid user cost.
system policy at a given time may prohibit the use of such a metered Similarly, the system policy at a given time may prohibit the use of
network interface from the application's process. Lastly, the such a metered network interface from the application's process.
implementation itself may default to disallowing certain network Lastly, the implementation itself may default to disallowing certain
interfaces unless explicitly requested by the application and allowed network interfaces unless explicitly requested by the application and
by the system. allowed by the system.
It is expected that the database of system policies and the method of It is expected that the database of system policies and the method of
looking up these policies will vary across various platforms. An looking up these policies will vary across various platforms. An
implementation should attempt to look up the relevant policies for implementation should attempt to look up the relevant policies for
the system in a dynamic way to make sure it is reflecting an accurate the system in a dynamic way to make sure it is reflecting an accurate
version of the system policy, since the system's policy regarding the version of the system policy, since the system's policy regarding the
application's traffic may change over time due to user or application's traffic may change over time due to user or
administrative changes. administrative changes.
4. Implementing Connection Establishment 4. Implementing Connection Establishment
skipping to change at page 8, line 29 skipping to change at page 8, line 29
criteria. criteria.
4.1. Structuring Candidates as a Tree 4.1. Structuring Candidates as a Tree
As noted above, the considereration of multiple candidates in a As noted above, the considereration of multiple candidates in a
gathering and racing process can be conceptually structured as a gathering and racing process can be conceptually structured as a
tree; this terminological convention is used throughout this tree; this terminological convention is used throughout this
document. document.
Each leaf node of the tree represents a single, coherent connection Each leaf node of the tree represents a single, coherent connection
attempt, with an Endpoint, a Path, and a set of protocols that can attempt, with an endpoint, a path, and a set of protocols that can
directly negotiate and send data on the network. Each node in the directly negotiate and send data on the network. Each node in the
tree that is not a leaf represents a connection attempt that is tree that is not a leaf represents a connection attempt that is
either underspecified, or else includes multiple distinct options. either underspecified, or else includes multiple distinct options.
For example, when connecting on an IP network, a connection attempt For example, when connecting on an IP network, a connection attempt
to a hostname and port is underspecified, because the connection to a hostname and port is underspecified, because the connection
attempt requires a resolved IP address as its Remote Endpoint. In attempt requires a resolved IP address as its Remote Endpoint. In
this case, the node represented by the connection attempt to the this case, the node represented by the connection attempt to the
hostname is a parent node, with child nodes for each IP address. hostname is a parent node, with child nodes for each IP address.
Similarly, an implementation that is allowed to connect using Similarly, an implementation that is allowed to connect using
multiple interfaces will have a parent node of the tree for the multiple interfaces will have a parent node of the tree for the
skipping to change at page 9, line 25 skipping to change at page 9, line 25
| 192.0.2.1:80/Wi-Fi | | 192.0.2.1:80/LTE | | 2001:DB8::1.80/LTE | | 192.0.2.1:80/Wi-Fi | | 192.0.2.1:80/LTE | | 2001:DB8::1.80/LTE |
+====================+ +====================+ +======================+ +====================+ +====================+ +======================+
The rest of this section will use a notation scheme to represent this The rest of this section will use a notation scheme to represent this
tree. The parent (or trunk) node of the tree will be represented by tree. The parent (or trunk) node of the tree will be represented by
a single integer, such as "1". Each child of that node will have an a single integer, such as "1". Each child of that node will have an
integer that identifies it, from 1 to the number of children. That integer that identifies it, from 1 to the number of children. That
child node will be uniquely identified by concatenating its integer child node will be uniquely identified by concatenating its integer
to it's parents identifier with a dot in between, such as "1.1" and to it's parents identifier with a dot in between, such as "1.1" and
"1.2". Each node will be summarized by a tuple of three elements: "1.2". Each node will be summarized by a tuple of three elements:
Endpoint, Path, and Protocol. The above example can now be written endpoint, path, and protocol. The above example can now be written
more succinctly as: more succinctly as:
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]
1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP]
1.2.2 [2001:DB8::1.80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]
When an implementation views this aggregate set of connection When an implementation views this aggregate set of connection
skipping to change at page 17, line 8 skipping to change at page 17, line 8
Resolving the Remote Endpoint is not a local operation. It will Resolving the Remote Endpoint is not a local operation. It will
involve a directory service, and can require communication with the involve a directory service, and can require communication with the
Remote Endpoint to rendezvous and exchange peer addresses. This can Remote Endpoint to rendezvous and exchange peer addresses. This can
expose some or all of the candidate Local Endpoints to the Remote expose some or all of the candidate Local Endpoints to the Remote
Endpoint. Endpoint.
4.3. Candidate Racing 4.3. Candidate Racing
The primary goal of the Candidate Racing process is to successfully The primary goal of the Candidate Racing process is to successfully
negotiate a protocol stack to an endpoint over an interface--to negotiate a protocol stack to an endpoint over an interface to
connect a single leaf node of the tree--with as little delay and as connect a single leaf node of the tree with as little delay and as
few unnecessary connections attempts as possible. Optimizing these few unnecessary connections attempts as possible. Optimizing these
two factors improves the user experience, while minimizing network two factors improves the user experience, while minimizing network
load. load.
This section covers the dynamic aspect of connection establishment. This section covers the dynamic aspect of connection establishment.
The tree described above is a useful conceptual and architectural The tree described above is a useful conceptual and architectural
model. However, an implementation is unable to know the full tree model. However, an implementation is unable to know the full tree
before it is formed and many of the possible branches ultimately before it is formed and many of the possible branches ultimately
might not be used. might not be used.
skipping to change at page 21, line 11 skipping to change at page 21, line 11
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.5. Establishing multiplexed connections 4.5. Establishing multiplexed connections
Multiplexing several Connections over a single underlying transport Multiplexing several Connections over a single underlying transport
connection requires that the Connections to be multiplexed belong to connection requires that the Connections to be multiplexed belong to
the same Connection Group (as is indicated by the application using the same Connection Group (as is indicated by the application using
the Clone call). When the underlying transport connection supports the Clone call). When the underlying transport connection supports
multi-streaming, the Transport System can map each Connection in the multi-streaming, the Transport Services System can map each
Connection Group to a different stream. Thus, when the Connections Connection in the Connection Group to a different stream. Thus, when
that are offered to an application by the Transport System are the Connections that are offered to an application by the Transport
multiplexed, the Transport System may implement the establishment of Services API are multiplexed, the Transport Services implementation
a new Connection by simply beginning to use a new stream of an can establish a new Connection by simply beginning to use a new
already established transport connection and there is no need for a stream of an already established transport Connection and there is no
connection establishment procedure. This, then, also means that need for a connection establishment procedure. This, then, also
there may not be any "establishment" message (like a TCP SYN), but means that there may not be any "establishment" message (like a TCP
the application can simply start sending or receiving. Therefore, SYN), but the application can simply start sending or receiving.
when the Initiate action of a Transport System is called without Therefore, when the Initiate action of a Transport Services API is
Messages being handed over, it cannot be guaranteed that the other called without Messages being handed over, it cannot be guaranteed
endpoint will have any way to know about this, and hence a passive that the Remote Endpoint will have any way to know about this, and
endpoint's ConnectionReceived event may not be called upon an active hence a passive endpoint's ConnectionReceived event might not be
endpoint's Inititate. Instead, calling the ConnectionReceived event called until data is received. Instead, calling the
may be delayed until the first Message arrives. ConnectionReceived event could be delayed until the first Message
arrives.
4.6. Handling connectionless protocols 4.6. 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, connectionless 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 the consider such a protocol stack to be established as soon as the
Transport Services system has selected a path on which to send data. Transport Services system has selected a path on which to send data.
skipping to change at page 24, line 30 skipping to change at page 24, line 30
that are Safely Replayable. When a transport system is permitted that are Safely Replayable. When a transport system is permitted
to replay messages, replay protection could be provided by the to replay messages, replay protection could be provided by the
application. application.
* Final: when this is true, this means that the sender will not send * Final: when this is true, this means that the sender will not send
any further messages. The Connection need not be closed (in case any further messages. The Connection need not be closed (in case
the Protocol Stack supports half-close operation, like TCP). Any the Protocol Stack supports half-close operation, like TCP). Any
messages sent after a Final message will result in a SendError. 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). If the that allow limiting the checksum length (e.g. UDP-Lite). If the
protocol stack does not support checksum length limitation, this protocol stack does not support checksum length limitation, this
property may be ignored. 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
Profile" for this Message. Depending on the value, this can, for for this Message. Depending on the value, this can, for example,
example, be implemented by changing the DSCP value of the be implemented by changing the DSCP value of the associated packet
associated packet (note that the guidelines in Section 6 of (note that the guidelines in Section 6 of [RFC7657] apply; e.g.,
[RFC7657] apply; e.g., the DSCP value should not be changed for the DSCP value should not be changed for different packets within
different packets within a reliable transport protocol session or 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 time at which a Message is considered to have been send. The time at which a Message is considered to have been
consumed by the Protocol Stack may vary depending on the protocol. consumed by the Protocol Stack may vary depending on the protocol.
For example, for a basic datagram protocol like UDP, this may For example, for a basic datagram protocol like UDP, this may
correspond to the time when the packet is sent into the interface correspond to the time when the packet is sent into the interface
driver. For a protocol that buffers data in queues, like TCP, this driver. For a protocol that buffers data in queues, like TCP, this
may correspond to when the data has entered the send buffer. The 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 time at which a message failed to send is when Transport Services
Stack or the Transport Services implementation itself has not implementation (including the Protocol Stack) has not successfully
successfully sent the entire Message content or partial Message sent the entire Message content or partial Message content on any
content on any open candidate connection; this may depend on open candidate connection; this can depend on protocol-specific
protocol-specific timeouts. 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 Services system, sending patterns that
multiple small Messages can incur high overhead if each needs to be involve multiple small Messages can incur high overhead if each needs
enqueued separately. To avoid this, the application can indicate a to be enqueued separately. To avoid this, the application can
batch of Send actions through the API. When this is used, the indicate a batch of Send actions through the API. When this is used,
implementation can defer the processing of Messages until the batch the implementation can defer the processing of Messages until the
is complete. batch 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, Transport Services implementation know how much data to deliver and
if the application only wants to receive a complete Message, the when. For example, if the application only wants to receive a
implementation should wait until an entire Message (datagram, stream, complete Message, the implementation should wait until an entire
or frame) is read before delivering any Message content to the Message (datagram, stream, or frame) is read before delivering any
application. This requires the implementation to understand where Message content to the application. This requires the implementation
messages end, either via a supplied deframer or because the top-level to understand where messages end, either via a supplied deframer or
protocol in the established Protocol Stack preserves message because the top-level protocol in the established Protocol Stack
boundaries. If the top-level protocol only supports a byte-stream preserves message boundaries. If the top-level protocol only
and no framers were supported, the application can control the flow supports a byte-stream and no framers were supported, the application
of received data by specifying the minimum number of bytes of Message can control the flow of received data by specifying the minimum
content it wants to receive at one time. number of bytes of Message content it wants to receive at one time.
If a Connection finishes before a requested Receive action can be If a Connection finishes before a requested Receive action can be
satisfied, the implementation should deliver any partial Message satisfied, the Transport Services API should deliver any partial
content outstanding, or if none is available, an indication that Message content outstanding, or if none is available, an indication
there will be no more received Messages. that 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 feature, 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.
If the application has 0-RTT data to send in any protocol handshakes, If the application has 0-RTT data to send in any protocol handshakes,
it needs to provide this data before the handshakes have begun. When it needs to provide this data before the handshakes have begun. When
racing, this means that the data should be provided before the racing, this means that the data should be provided before the
process of connection establishment has begun. If the application process of connection establishment has begun. If the application
wants to send 0-RTT data, it must indicate this to the implementation wants to send 0-RTT data, it must indicate this to the implementation
by setting the "Safely Replayable" send parameter to true when by setting the Safely Replayable send parameter to true when sending
sending the data. In general, 0-RTT data may be replayed (for the data. In general, 0-RTT data may be replayed (for example, if a
example, if a TCP SYN contains data, and the SYN is retransmitted, TCP SYN contains data, and the SYN is retransmitted, the data will be
the data will be retransmitted as well but may be considered as a new retransmitted as well but may be considered as a new connection
connection instead of a retransmission). Also, when racing instead of a retransmission). Also, when racing connections,
connections, different leaf nodes have the opportunity to send the different leaf nodes have the opportunity to send the same data
same data independently. If data is truly safely replayable, this independently. If data is truly safely replayable, this should be
should be permissible. permissible.
Once the application has provided its 0-RTT data, an implementation Once the application has provided its 0-RTT data, a Transport
should keep a copy of this data and provide it to each new leaf node Services implementation should keep a copy of this data and provide
that is started and for which a 0-RTT protocol is being used. it to each new leaf node that is started and for which a 0-RTT
protocol is being used.
It is also possible that protocol stacks within a particular leaf It is also possible that protocol stacks within a particular leaf
node use 0-RTT handshakes without any safely replayable application node use 0-RTT handshakes without any safely replayable application
data. For example, TCP Fast Open could use a Client Hello from TLS data. For example, TCP Fast Open could use a Client Hello from TLS
as its 0-RTT data, shortening the cumulative handshake time. as its 0-RTT data, shortening the cumulative handshake time.
0-RTT handshakes often rely on previous state, such as TCP Fast Open 0-RTT handshakes often rely on previous state, such as TCP Fast Open
cookies, previously established TLS tickets, or out-of-band cookies, previously established TLS tickets, or out-of-band
distributed pre-shared keys (PSKs). Implementations should be aware distributed pre-shared keys (PSKs). Implementations should be aware
of security concerns around using these tokens across multiple of security concerns around using these tokens across multiple
skipping to change at page 27, line 26 skipping to change at page 27, line 31
wire. wire.
6. Implementing Message Framers 6. Implementing Message Framers
Message Framers are functions 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 API, 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 is exposed as a protocol natively supported by the example, TLS is exposed as a protocol natively supported by the
Transport Services interface, even though it could also serve the Transport Services API, even though it could also serve the purpose
purpose of framing data over TCP. 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 a 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 API 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 code that handles events A Message Framer is primarily defined by the code that handles events
for a framer implementation, specifically how it handles inbound and for a framer implementation, specifically how it handles inbound and
outbound data parsing. The function that implements custom framing outbound data parsing. The function that implements custom framing
logic will be referred to as the "framer implementation", which may logic will be referred to as the "framer implementation", which may
be provided by the Transport Services implementation or the be provided by a Transport Services implementation or the application
application itself. The Message Framer refers to the object or itself. The Message Framer refers to the object or function within
function within the main Connection implementation that delivers the main Connection implementation that delivers events to the custom
events to the custom framer implementation whenever data is ready to framer 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)
When a Message Framer generates a "Start" event, the framer When a Message Framer generates a Start event, the framer
implementation has the opportunity to start writing some data prior implementation has the opportunity to start writing some data prior
to the Connection delivering its "Ready" event. This allows the to the Connection delivering its Ready event. This allows the
implementation to communicate control data to the Remote Endpoint implementation to communicate control data to the Remote Endpoint
that can be used to parse Messages. that can be used to parse Messages.
MessageFramer.MakeConnectionReady(Connection) MessageFramer.MakeConnectionReady(Connection)
Similarly, when a Message Framer generates a "Stop" event, the framer Similarly, when a Message Framer generates a Stop event, the framer
implementation has the opportunity to write some final data or clear implementation has the opportunity to write some final data or clear
up its local state before the "Closed" event is delivered to the up its local state before the Closed event is delivered to the
Application. The framer implementation can indicate that it has Application. The framer implementation can indicate that it has
finished with this. finished with this.
MessageFramer.MakeConnectionClosed(Connection) MessageFramer.MakeConnectionClosed(Connection)
At any time if the implementation encounters a fatal error, it can At any time if the implementation encounters a fatal error, it can
also cause the Connection to fail and provide an error. also cause the Connection to fail and provide an error.
MessageFramer.FailConnection(Connection, Error) MessageFramer.FailConnection(Connection, Error)
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 to the Transport Services API
to marking it as ready. If there are no other candidates available, by failing the Connection prior to marking it as ready. If there are
the Connection will fail. Otherwise, the Connection will select a no other candidates available, the Connection will fail. Otherwise,
different candidate and the Message Framer will generate a new the Connection will select a different candidate and the Message
"Start" event. Framer will generate a new 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 that need to add TLS conditionally, like STARTTLS allows protocols that need to add TLS conditionally, like STARTTLS
[RFC3207], 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 A Message Framer might also choose to go into a passthrough mode once
skipping to change at page 29, line 46 skipping to change at page 29, line 40
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
next protocol. Implementations SHOULD ensure that there is a way to next protocol. Implementations SHOULD ensure that there is a way to
pass the original data through without copying to improve pass the original data through without copying to improve
performance. performance.
MessageFramer.Send(Connection, Data) MessageFramer.Send(Connection, Data)
To provide an example, a simple protocol that adds a length as a To provide an example, a simple protocol that adds a length as a
header would receive the "NewSentMessage" event, create a data header would receive the NewSentMessage event, create a data
representation of the length of the Message data, and then send a representation of the length of the Message data, and then send a
block of data that is the concatenation of the length header and the block of data that is the concatenation of the length header and the
original Message data. original Message data.
6.3. Receiver-side Message Framing 6.3. Receiver-side Message Framing
In order to parse a received flow of data into Messages, the Message In order to parse a received flow of data into Messages, the Message
Framer notifies the framer implementation whenever new data is Framer notifies the framer implementation whenever new data is
available to parse. available to parse.
skipping to change at page 30, line 34 skipping to change at page 30, line 25
To deliver a Message to the application, the framer implementation To deliver a Message to the application, the framer implementation
can either directly deliver data that it has allocated, or deliver a can either directly deliver data that it has allocated, or deliver a
range of data directly from the underlying transport and range of data directly from the underlying transport and
simultaneously advance the receive cursor. simultaneously advance the receive cursor.
MessageFramer.AdvanceReceiveCursor(Connection, Length) MessageFramer.AdvanceReceiveCursor(Connection, Length)
MessageFramer.DeliverAndAdvanceReceiveCursor(Connection, MessageContext, Length, IsEndOfMessage) MessageFramer.DeliverAndAdvanceReceiveCursor(Connection, MessageContext, Length, IsEndOfMessage)
MessageFramer.Deliver(Connection, MessageContext, Data, IsEndOfMessage) MessageFramer.Deliver(Connection, MessageContext, Data, IsEndOfMessage)
Note that "MessageFramer.DeliverAndAdvanceReceiveCursor" allows the Note that MessageFramer.DeliverAndAdvanceReceiveCursor allows the
framer implementation to earmark bytes as part of a Message even framer implementation to earmark bytes as part of a Message even
before they are received by the transport. This allows the delivery before they are received by the transport. This allows the delivery
of very large Messages without requiring the implementation to of very large Messages without requiring the implementation to
directly inspect all of the bytes. directly inspect all of the bytes.
To provide an example, a simple protocol that parses a length as a To provide an example, a simple protocol that parses a length as a
header value would receive the "HandleReceivedData" event, and call header value would receive the HandleReceivedData event, and call
"Parse" with a minimum and maximum set to the length of the header Parse with a minimum and maximum set to the length of the header
field. Once the parse succeeded, it would call field. Once the parse succeeded, it would call AdvanceReceiveCursor
"AdvanceReceiveCursor" with the length of the header field, and then with the length of the header field, and then call
call "DeliverAndAdvanceReceiveCursor" with the length of the body DeliverAndAdvanceReceiveCursor with the length of the body that was
that was parsed from the header, marking the new Message as complete. parsed from the header, marking the new Message as complete.
7. Implementing Connection Management 7. Implementing Connection Management
Once a Connection is established, the Transport Services system Once a Connection is established, the Transport Services API allows
allows applications to interact with the Connection by modifying or 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 Services
store the properties in storage common to all protocols, and notify implementation should store the properties in storage common to all
all protocol instances in the Protocol Stack whenever the properties protocols, and notify all protocol instances in the Protocol Stack
have been modified by the application. For protocol-specfic whenever the properties have been modified by the application. For
properties, such as the User Timeout that applies to TCP, the protocol-specfic properties, such as the User Timeout that applies to
Transport System only needs to update the relevant protocol instance. TCP, the Transport Services implementation 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 API should allow protocol instances in the
in the Protocol Stack to pass up arbitrary generic or protocol- Protocol Stack to pass up arbitrary generic or protocol-specific
specific errors that can be delivered to the application as Soft errors that can be delivered to the application as Soft Errors.
Errors. These allow the application to be informed of ICMP errors, These allow the application to be informed of ICMP errors, and other
and other similar events. similar events.
7.1. Pooled Connection 7.1. Pooled Connection
For protocols that employ request/response pairs and do not require For applications that do not need in-order delivery of Messages, the
in-order delivery of the responses, like HTTP, the transport Transport Services implementation may distribute Messages of a single
implementation may distribute interactions across several underlying Connection across several underlying transport connections or
transport connections. For these kinds of protocols, implementations multiple streams of multi-streaming connections between endpoints, as
may hide the connection management and only expose a single long as all of these satisfy the Selection Properties. The Transport
Connection object and the individual requests/responses as messages. Services implementation will then hide this connection management and
These Pooled Connections can use multiple connections or multiple only expose a single Connection object, which we here call a "Pooled
streams of multi-streaming connections between endpoints, as long as Connection". This is in contrast to Connection Groups, which
all of these satisfy the requirements, and prohibitions specified in explicitly expose combined treatment of Connections, giving the
the Selection Properties of the Pooled Connection. This enables application control over multiplexing, for example.
implementations to realize transparent connection coalescing,
connection migration, and to perform per-message endpoint and path Pooled Connections can be useful when the application using the
selection by choosing among these underlying connections. Transport Services system implements a protocol such as HTTP, which
employs request/response pairs and does not require in-order delivery
of responses. This enables implementations of Transport Services
systems to realize transparent connection coalescing, connection
migration, and to perform per-message endpoint and path selection by
choosing among multiple 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 Protocol Instance of implementation is responsible for notifying the Protocol Instance of
the change. The path change may interrupt connectivity on a path for the change. The path change may interrupt connectivity on a path for
an 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. Note supports multipath or migration to adapt to the new paths. Note
that, from the Transport Services API point of view, migration is that, in the model of the Transport Services API, migration is
considered a part of multipath connectivity; it is just a limiting considered a part of multipath connectivity; it is just a limiting
policy on multipath usage. If the "multipath" Selection Property is policy on multipath usage. If the multipath Selection Property is
set to "Disabled", migration is disallowed. 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. There are many common user scenarios that can lead to a unavailable. There are many common user scenarios that can lead to a
path becoming temporarily unavailable, and then recovering before the path becoming temporarily unavailable, and then recovering before the
transport protocol reaches a timeout error. These are particularly transport protocol reaches a timeout error. These are particularly
common using mobile devices. Examples include: an Ethernet cable common using mobile devices. Examples include: an Ethernet cable
becoming unplugged and then plugged back in; a device losing a Wi-Fi 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 signal while a user is in an elevator, and reattaching when the user
skipping to change at page 33, line 8 skipping to change at page 32, line 27
a train through a tunnel. If the device is able to rejoin a network a train through a tunnel. If the device is able to rejoin a network
with the same IP address, a stateful transport connection can with the same IP address, a stateful transport connection can
generally resume. Thus, while it is useful for a Protocol Instance generally resume. Thus, while it is useful for a Protocol Instance
to be aware of a temporary loss of connectivity, the Transport to be aware of a temporary loss of connectivity, the Transport
Services implementation should not aggressively close connections in Services implementation should not aggressively close connections in
these scenarios. these scenarios.
If the Protocol Stack includes a transport protocol that supports If the Protocol Stack includes a transport protocol that supports
multipath connectivity, the Transport Services implementation should multipath connectivity, the Transport Services implementation should
also inform the Protocol Instance of potentially new paths that also inform the Protocol Instance of potentially new paths that
become permissible based on the "multipath" Selection Property and become permissible based on the multipath Selection Property and the
the "multipath-policy" Connection Property choices made by the multipath-policy Connection Property choices made by the application.
application. A protocol can then establish new subflows over new A protocol can then establish new subflows over new paths while an
paths while an active path is still available or, if migration is active path is still available or, if migration is supported, also
supported, also after a break has been detected, and should attempt after a break has been detected, and should attempt to tear down
to tear down subflows over paths that are no longer used. The subflows over paths that are no longer used. The Connection Property
Transport Services API's Connection Property "multipath-policy" multipath-policy of the Transport Services API allows an application
allows an application to indicate when and how different paths should to indicate when and how different paths should be used. However,
be used. However, detailed handling of these policies is still detailed handling of these policies is still implementation-specific.
implementation-specific. For example, if the "multipath" Selection For example, if the multipath Selection Property is set to active,
Property is set to "active", the decision about when to create a new the decision about when to create a new path or to announce a new
path or to announce a new path or set of paths to the Remote path or set of paths to the Remote Endpoint, e.g., in the form of
Endpoint, e.g., in the form of additional IP addresses, is additional IP addresses, is implementation-specific. If the Protocol
implementation-specific. If the Protocol Stack includes a transport Stack includes a transport protocol that does not support multipath,
protocol that does not support multipath, but does support migrating but does support migrating between paths, the update to the set of
between paths, the update to the set of available paths can trigger available paths can trigger the connection to be migrated.
the connection to be migrated.
In case of Pooled Connections Section 7.1, the Transport Services In case of Pooled Connections Section 7.1, the Transport Services
implementation may add connections over new paths 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 to do so is implementation-specific, but application. The strategy to do so is implementation-specific, but
should be consistent with the behavior of multipath transports. should be consistent with the behavior of multipath transports.
skipping to change at page 34, line 4 skipping to change at page 33, line 23
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-
closed connections. Hence, with SCTP, the meaning of "close" is closed connections. Hence, with SCTP, the meaning of "close" is
stricter: an application has no more data to send (but expects all stricter: an application has no more data to send (but expects all
data that has been handed over to be reliably delivered), and will data that has been handed over to be reliably delivered), and will
also not receive any more data. also not receive any more data.
Implementing a protocol independent transport system means that the Implementing a protocol independent transport system means that the
exposed semantics must be the strictest subset of the semantics of exposed semantics must be the strictest subset of the semantics of
all supported protocols. Hence, as is common with all reliable all supported protocols. Hence, as is common with all reliable
transport protocols, after a Close action, the application can expect transport protocols, after a Close action, the application can expect
to have its reliability requirements honored regarding the data it to have its reliability requirements honored regarding the data
has given to the Transport System, but it cannot expect to be able to provided to the Transport Services API, but it cannot expect to be
read any more data after calling Close. able to read any more data after calling Close.
Abort differs from Close only in that no guarantees are given Abort differs from Close only in that no guarantees are given
regarding data that the application has handed over to the Transport regarding any data that the application sent to the Transport
System before calling Abort. Services API before calling Abort.
As explained in Section 4.5, when a new stream is multiplexed on an As explained in Section 4.5, when a new stream is multiplexed on an
already existing connection of a Transport Protocol Instance, there already existing connection of a Transport Protocol Instance, there
is no need for a connection establishment procedure. Because the is no need for a connection establishment procedure. Because the
Connections that are offered by the Transport System can be Connections that are offered by a Transport Services implementation
implemented as streams that are multiplexed on a transport protocol's can be implemented as streams that are multiplexed on a transport
connection, it can therefore not be guaranteed that one Endpoint's protocol's connection, it can therefore not be guaranteed an Initiate
Initiate action provokes a ConnectionReceived event at its peer. action from one endpoint provokes a ConnectionReceived event at its
peer.
For Close (provoking a Finished event) and Abort (provoking a For Close (provoking a Finished event) and Abort (provoking a
ConnectionError event), the same logic applies: while it is desirable ConnectionError event), the same logic applies: while it is desirable
to be informed when a peer closes or aborts a Connection, whether to be informed when a peer closes or aborts a Connection, whether
this is possible depends on the underlying protocol, and no this is possible depends on the underlying protocol, and no
guarantees can be given. With SCTP, the transport system can use the guarantees can be given. With SCTP, the transport system can use the
stream reset procedure to cause a Finish event upon a Close action stream reset procedure to cause a Finish event upon a Close action
from the peer [NEAT-flow-mapping]. from the peer [NEAT-flow-mapping].
9. Cached State 9. Cached State
Beyond a single Connection's lifetime, it is useful for an Beyond a single Connection's lifetime, it is useful for an
implementation to keep state and history. This cached state can help implementation to keep state and history. This cached state can help
improve future Connection establishment due to re-using results and improve future Connection establishment due to re-using results and
credentials, and favoring paths and protocols that performed well in credentials, and favoring paths and protocols that performed well in
the past. the past.
Cached state may be associated with different Endpoints for the same Cached state may be associated with different endpoints for the same
Connection, depending on the protocol generating the cached content. Connection, depending on the protocol generating the cached content.
For example, session tickets for TLS are associated with specific For example, session tickets for TLS are associated with specific
endpoints, and thus should be cached based on a Connection's hostname endpoints, and thus should be cached based on a Connection's hostname
Endpoint (if applicable). On the other hand, performance endpoint (if applicable). However, performance characteristics of a
characteristics of a path are more likely tied to the IP address and path are more likely tied to the IP address and subnet being used.
subnet being used.
9.1. Protocol state caches 9.1. Protocol state caches
Some protocols will have long-term state to be cached in association Some protocols will have long-term state to be cached in association
with Endpoints. This state often has some time after which it is with endpoints. This state often has some time after which it is
expired, so the implementation should allow each protocol to specify expired, so the implementation should allow each protocol to specify
an expiration for cached content. an expiration for cached content.
Examples of cached protocol state include: Examples of cached protocol state include:
* The DNS protocol can cache resolution answers (A and AAAA queries, * The DNS protocol can cache resolution answers (A and AAAA queries,
for example), associated with a Time To Live (TTL) to be used for for example), associated with a Time To Live (TTL) to be used for
future hostname resolutions without requiring asking the DNS future hostname resolutions without requiring asking the DNS
resolver again. resolver again.
* TLS caches session state and tickets based on a hostname, which * TLS caches session state and tickets based on a hostname, which
can be used for resuming sessions with a server. can be used for resuming sessions with a server.
* 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 can request that a Connection Group maintain a separate Applications can use the Transport Services API to request that a
cache for protocol state. Connections in the group will not use Connection Group maintain a separate cache for protocol state.
cached state from connections outside the group, and connections Connections in the group will not use cached state from connections
outside the group will not use state cached from connections inside outside the group, and connections outside the group will not use
the group. This may be necessary, for example, if application-layer state cached from connections inside the group. This may be
identifiers rotate and clients wish to avoid linkability via necessary, for example, if application-layer identifiers rotate and
trackable TLS tickets or TFO cookies. clients wish to avoid linkability via 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:
* Observed Round Trip Time * Observed Round Trip Time
skipping to change at page 36, line 39 skipping to change at page 36, line 14
Trip Time observed by TCP over a particular network path may vary Trip Time observed by TCP over a particular network path may vary
over a relatively short time interval. For such values, the over a relatively short time interval. For such values, the
implementation should remove them from the cache more quickly, or implementation should remove them from the cache more quickly, or
treat older values with less confidence/weight. treat older values with less confidence/weight.
[I-D.ietf-tcpm-2140bis] provides guidance about sharing of TCP [I-D.ietf-tcpm-2140bis] provides guidance about sharing of TCP
Control Block information between connections on initialization. Control Block information between connections on initialization.
10. Specific Transport Protocol Considerations 10. Specific Transport Protocol Considerations
Each protocol that can run as part of a Transport Services Each protocol that is supported by 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 are important for Connections in which a given
is the "top" of the Protocol Stack. For example, the mapping of the protocol is the "top" of the Protocol Stack. For example, the
"Send" function for TCP applies to Connections in which the mapping of the Send function for TCP applies to Connections in which
application directly sends over TCP. the 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:
* Connectionless. Connectionless protocols do not establish * Connectionless. Connectionless protocols do not establish
explicit state between endpoints, and do not perform a handshake explicit state between endpoints, and do not perform a handshake
during 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
skipping to change at page 38, line 8 skipping to change at page 37, line 35
Connectedness: Connected Connectedness: Connected
Data Unit: Byte-stream Data Unit: Byte-stream
API mappings for TCP are as follows: API mappings for TCP are as follows:
Connection Object: TCP connections between two hosts map directly to Connection Object: TCP connections between two hosts map directly to
Connection objects. Connection objects.
Initiate: CONNECT.TCP. Calling "Initiate" on a TCP Connection Initiate: CONNECT.TCP. Calling Initiate on a TCP Connection causes
causes it to reserve a local port, and send a SYN to the Remote it to reserve a local port, and send a SYN to the Remote Endpoint.
Endpoint.
InitiateWithSend: CONNECT.TCP with parameter "user message". Early InitiateWithSend: CONNECT.TCP with parameter user message. Early
safely replayable data is sent on a TCP Connection in the SYN, as safely replayable data is sent on a TCP Connection in the SYN, as
TCP Fast Open data. TCP Fast Open data.
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. 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. These Connections, and Connections with equivalent parameters. These Connections, and Connections
generated via later calls to "Clone" on one of them, form a generated via later calls to Clone on an Establied Connection,
Connection Group. To realize entanglement for these Connections, form a Connection Group. To realize entanglement for these
with the exception of "Connection Priority", changing a Connection Connections, with the exception of Connection Priority, changing a
Property on one of them must affect the Connection Properties of Connection Property on one of them must affect the Connection
the others too. No guarantees of honoring the Connection Property Properties of the others too. No guarantees of honoring the
"Connection Priority" are given, and thus it is safe for an Connection Property Connection Priority are given, and thus it is
implementation of a transport system to ignore this property. safe for an implementation of a transport system to ignore this
When it is reasonable to assume that Connections traverse the same property. When it is reasonable to assume that Connections
path (e.g., when they share the same encapsulation), support for traverse the same path (e.g., when they share the same
it can also experimentally be implemented using a congestion encapsulation), support for it can also experimentally be
control coupling mechanism (see for example [TCP-COUPLING] or implemented using a congestion control coupling mechanism (see for
[RFC3124]). 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. Note that transmitting a successful termination of SEND.TCP. Note that transmitting a
Message marked as Final should not cause the "Closed" event to be Message marked as Final should not cause the Closed event to be
delivered to the application, as it will still be possible to delivered to the application, as it will still be possible to
receive data until the peer closes or aborts the TCP connection. 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
Message that is marked Final (unless a Message Framer is used). 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) from the peer. Note that received a FIN (CLOSE-EVENT.TCP) from the peer. Note that
reception of a FIN should not cause the "Closed" event to be reception of a FIN should not cause the Closed event to be
delivered to the application, as it will still be possible for the delivered to the application, as it will still be possible for the
application to send data. 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. It will then still be possible to receive data FIN to the peer. It will then still be possible to receive data
until the peer closes or aborts the TCP connection. The "Closed" until the peer closes or aborts the TCP connection. The Closed
event will be issued upon reception of a FIN. 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 the Transport Services API mappings for MPTCP are identical to TCP.
multipath properties, such as "Multipath Transport" and "Policy for MPTCP adds support for multipath properties, such as "Multipath
using Multipath Transports". Transport" and "Policy for using Multipath Transports".
10.3. UDP 10.3. UDP
Connectedness: Connectionless 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
causes it to reserve a local port, but does not generate any it to reserve a local port, but does not generate any traffic.
traffic.
InitiateWithSend: Early data on a UDP Connection does not have any InitiateWithSend: Early data on a UDP Connection does not have any
special meaning. The data is sent whenever the Connection is special meaning. The data is sent whenever the Connection is
Ready. Ready.
Ready: A UDP Connection is ready once the system has reserved a Ready: A UDP Connection is ready once the system has reserved a
local port and has a path to send to the Remote Endpoint. local port and has a path to send to the Remote Endpoint.
InitiateError: UDP Connections can only generate errors on InitiateError: UDP Connections can only generate errors on
initiation due to port conflicts on the local system. initiation due to port conflicts on the local system.
ConnectionError: Once in use, UDP throws "soft errors" (ERROR.UDP(- ConnectionError: Once in use, UDP throws "soft errors" (ERROR.UDP(-
Lite)) upon receiving ICMP notifications indicating failures in Lite)) upon receiving ICMP notifications indicating failures in
the network. the network.
Listen: LISTEN.UDP. Calling "Listen" for UDP binds a local port and Listen: LISTEN.UDP. Calling Listen for UDP binds a local port and
prepares it to receive inbound UDP datagrams from peers. prepares it to receive inbound UDP datagrams from peers.
ConnectionReceived: UDP Listeners will deliver new connections once ConnectionReceived: UDP Listeners will deliver new connections once
they have received traffic from a new Remote Endpoint. they have received traffic from a new Remote Endpoint.
Clone: Calling "Clone" on a UDP Connection creates a new Connection Clone: Calling Clone on a UDP Connection creates a new Connection
with equivalent parameters. The two Connections are otherwise with equivalent parameters. The two Connections are otherwise
independent. independent.
Send: SEND.UDP(-Lite). Calling "Send" on a UDP connection sends the Send: SEND.UDP(-Lite). Calling Send on a UDP connection sends the
data as the payload of a complete UDP datagram. Marking Messages data as the payload of a complete UDP datagram. Marking Messages
as Final does not change anything in the datagram's contents. as Final does not change anything in the datagram's contents.
Upon sending a UDP datagram, some relevant fields and flags in the Upon sending a UDP datagram, some relevant fields and flags in the
IP header can be controlled: DSCP (SET_DSCP.UDP(-Lite)), DF in IP header can be controlled: DSCP (SET_DSCP.UDP(-Lite)), DF in
IPv4 (SET_DF.UDP(-Lite)) and ECN flag (SET_ECN.UDP(-Lite)). IPv4 (SET_DF.UDP(-Lite)) and ECN flag (SET_ECN.UDP(-Lite)).
Receive: RECEIVE.UDP(-Lite). UDP only delivers complete Messages to Receive: RECEIVE.UDP(-Lite). UDP only delivers complete Messages to
"Received", each of which represents a single datagram received in Received, each of which represents a single datagram received in a
a UDP packet. Upon receiving a UDP datagram, the ECN flag from UDP packet. Upon receiving a UDP datagram, the ECN flag from the
the IP header can be obtained (GET_ECN.UDP(-Lite)). 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
releases the local port reservation. 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: Connectionless Connectedness: Connectionless
Data Unit: Datagram Data Unit: Datagram
API mappings for UDP-Lite are identical to UDP. Properties that The Transport Services API mappings for UDP-Lite are identical to
require checksum coverage are not supported by UDP-Lite, such as UDP. Properties that require checksum coverage are not supported by
"Corruption Protection Length", "Full Checksum Coverage on Sending", UDP-Lite, such as "Corruption Protection Length", "Full Checksum
"Required Minimum Corruption Protection Coverage for Receiving", and Coverage on Sending", "Required Minimum Corruption Protection
"Full Checksum Coverage on Receiving". Coverage for Receiving", and "Full Checksum Coverage on Receiving".
10.5. UDP Multicast Receive 10.5. UDP Multicast Receive
Connectedness: Connectionless 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.
Initiate: Calling "Initiate" on a UDP Multicast Receive Connection Initiate: Calling Initiate on a UDP Multicast Receive Connection
causes an immediate InitiateError. This is an unsupported causes an immediate InitiateError. This is an unsupported
operation. operation.
InitiateWithSend: Calling "InitiateWithSend" on a UDP Multicast InitiateWithSend: Calling InitiateWithSend on a UDP Multicast
Receive Connection causes an immediate InitiateError. This is an Receive Connection causes an immediate InitiateError. This is an
unsupported operation. unsupported operation.
Ready: A UDP Multicast Receive Connection is ready once the system Ready: A UDP Multicast Receive Connection is ready once the system
has received traffic for the appropriate group and port. has received traffic for the appropriate group and port.
InitiateError: UDP Multicast Receive Connections generate an InitiateError: UDP Multicast Receive Connections generate an
InitiateError if Initiate is called. InitiateError if Initiate is called.
ConnectionError: Once in use, UDP throws "soft errors" (ERROR.UDP(- ConnectionError: Once in use, UDP throws "soft errors" (ERROR.UDP(-
Lite)) upon receiving ICMP notifications indicating failures in Lite)) upon receiving ICMP notifications indicating failures in
the network. the network.
Listen: LISTEN.UDP. Calling "Listen" for UDP Multicast Receive Listen: LISTEN.UDP. Calling Listen for UDP Multicast Receive binds
binds a local port, prepares it to receive inbound UDP datagrams a local port, prepares it to receive inbound UDP datagrams from
from peers, and issues a multicast host join. If a Remote peers, and issues a multicast host join. If a Remote Endpoint
Endpoint with an address is supplied, the join is Source-specific with an address is supplied, the join is Source-specific
Multicast, and the path selection is based on the route to the Multicast, and the path selection is based on the route to the
Remote Endpoint. If a Remote Endpoint is not supplied, the join Remote Endpoint. If a Remote Endpoint is not supplied, the join
is Any-source Multicast, and the path selection is based on the is Any-source Multicast, and the path selection is based on the
outbound route to the group supplied in the Local Endpoint. outbound route to the group supplied in the Local Endpoint.
There are cases where it is required to open multiple connections for
the same address(es). For example, one Connection might be opened
for a multicast group to for a multicast control bus, and another
application later opens a separate Connection to the same group to
send signals to and/or receive signals from the common bus. In such
cases, the Transport Services system needs to explicitly enable re-
use of the same set of addresses (equivalent to setting SO_REUSEADDR
in the socket API).
ConnectionReceived: UDP Multicast Receive Listeners will deliver new ConnectionReceived: UDP Multicast Receive Listeners will deliver new
connections once they have received traffic from a new Remote connections once they have received traffic from a new Remote
Endpoint. Endpoint.
Clone: Calling "Clone" on a UDP Multicast Receive Connection creates Clone: Calling Clone on a UDP Multicast Receive Connection creates a
a new Connection with equivalent parameters. The two Connections new Connection with equivalent parameters. The two Connections
are otherwise independent. are otherwise independent.
Send: SEND.UDP(-Lite). Calling "Send" on a UDP Multicast Receive Send: SEND.UDP(-Lite). Calling Send on a UDP Multicast Receive
connection causes an immediate SendError. This is an unsupported connection causes an immediate SendError. This is an unsupported
operation. operation.
Receive: RECEIVE.UDP(-Lite). The Receive operation in a UDP Receive: RECEIVE.UDP(-Lite). The Receive operation in a UDP
Multicast Receive connection only delivers complete Messages to Multicast Receive connection only delivers complete Messages to
"Received", each of which represents a single datagram received in Received, each of which represents a single datagram received in a
a UDP packet. Upon receiving a UDP datagram, the ECN flag from UDP packet. Upon receiving a UDP datagram, the ECN flag from the
the IP header can be obtained (GET_ECN.UDP(-Lite)). IP header can be obtained (GET_ECN.UDP(-Lite)).
Close: Calling "Close" on a UDP Multicast Receive Connection Close: Calling Close on a UDP Multicast Receive Connection
(ABORT.UDP(-Lite)) releases the local port reservation and leaves (ABORT.UDP(-Lite)) releases the local port reservation and leaves
the group. the group.
Abort: Calling "Abort" on a UDP Multicast Receive Connection Abort: Calling Abort on a UDP Multicast Receive Connection
(ABORT.UDP(-Lite)) is identical to calling "Close". (ABORT.UDP(-Lite)) is identical to calling Close.
10.6. SCTP 10.6. SCTP
Connectedness: Connected Connectedness: Connected
Data Unit: Message Data Unit: Message
API mappings for SCTP are as follows: API mappings for SCTP are as follows:
Connection Object: Connection objects can be mapped to an SCTP Connection Object: Connection objects can be mapped to an SCTP
association or a stream in an SCTP association. Mapping association or a stream in an SCTP association. Mapping
Connection objects to SCTP streams is called "stream mapping" and Connection objects to SCTP streams is called "stream mapping" and
has additional requirements as follows. The following explanation has additional requirements as follows. The following explanation
assumes a client-server communication model. assumes a client-server communication model.
Stream mapping requires an association to already be in place between Stream mapping requires an association to already be in place between
the client and the server, and it requires the server to understand the client and the server, and it requires the server to understand
that a new incoming stream should be represented as a new Connection that a new incoming stream should be represented as a new Connection
Object by the Transport Services system. A new SCTP stream is Object by the Transport Services system. A new SCTP stream is
created by sending an SCTP message with a new stream id. Thus, to created by sending an SCTP message with a new stream id. Thus, to
implement stream mapping, the Transport Services system MUST provide implement stream mapping, the Transport Services API MUST provide a
a newly created Connection Object to the application upon the newly created Connection Object to the application upon the reception
reception of such a message. The necessary semantics to implement a of such a message. The necessary semantics to implement a Transport
Transport Services system's Close and Abort primitives are provided Services system Close and Abort primitives are provided by the stream
by the stream reconfiguration (reset) procedure described in reconfiguration (reset) procedure described in [RFC6525]. This also
[RFC6525]. This also allows to re-use a stream id after resetting allows to re-use a stream id after resetting ("closing") the stream.
("closing") the stream. To implement this functionality, SCTP stream To implement this functionality, SCTP stream reconfiguration
reconfiguration [RFC6525] MUST be supported by both the client and [RFC6525] MUST be supported by both the client and the server side.
the server side.
To avoid head-of-line blocking, stream mapping SHOULD only be To avoid head-of-line blocking, stream mapping SHOULD only be
implemented when both sides support message interleaving [RFC8260]. implemented when both sides support message interleaving [RFC8260].
This allows a sender to schedule transmissions between multiple This allows a sender to schedule transmissions between multiple
streams without risking that transmission of a large message on one streams without risking that transmission of a large message on one
stream might block transmissions on other streams for a long time. stream might block transmissions on other streams for a long time.
To avoid conflicts between stream ids, the following procedure is To avoid conflicts between stream ids, the following procedure is
recommended: the first Connection, for which the SCTP association has recommended: the first Connection, for which the SCTP association has
been created, MUST always use stream id zero. All additional been created, MUST always use stream id zero. All additional
skipping to change at page 43, line 39 skipping to change at page 43, line 23
ids. Generally, new streams SHOULD consume the lowest available ids. Generally, new streams SHOULD consume the lowest available
(even or odd, depending on the side) stream id; this rule is relevant (even or odd, depending on the side) stream id; this rule is relevant
when lower ids become available because Connection objects associated when lower ids become available because Connection objects associated
with the streams are closed. with the streams are closed.
SCTP stream mapping as described here has been implemented in a SCTP stream mapping as described here has been implemented in a
research prototype; a desription of this implementation is given in research prototype; a desription of this implementation is given in
[NEAT-flow-mapping]. [NEAT-flow-mapping].
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 is not used, CONNECT.SCTP the SCTP Association or stream mapping is not used, CONNECT.SCTP
is called. Else, unless the Selection Property is called. Else, unless the Selection Property
"activeReadBeforeSend" is Preferred or Required, a new stream is activeReadBeforeSend is Preferred or Required, a new stream is
used: if there are enough streams available, "Initiate" is a local used: if there are enough streams available, Initiate is a local
operation that assigns a new stream id to the Connection object. operation that assigns a new stream id to the Connection object.
The number of streams is negotiated as a parameter of the prior The number of streams is negotiated as a parameter of the prior
CONNECT.SCTP call, and it represents a trade-off between local CONNECT.SCTP call, and it represents a trade-off between local
resource usage and the number of Connection objects that can be resource usage and the number of Connection objects that can be
mapped without requiring a reconfiguration signal. When running mapped without requiring a reconfiguration signal. When running
out of streams, ADD_STREAM.SCTP must be called. 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 is not used, assigned to the SCTP association or stream mapping is not used,
CONNECT.SCTP is called with the "user message" parameter. Else, a CONNECT.SCTP is called with the "user message" parameter. Else, a
new stream is used (see "Initiate" for how to handle running out new stream is used (see Initiate for how to handle running out of
of streams), and this just sends the first message on a new streams), and this just sends the first message on a new stream.
stream.
Ready: "Initiate" or "InitiateWithSend" returns without an error, Ready: Initiate or InitiateWithSend returns without an error, i.e.
i.e. SCTP's four-way handshake has completed. If an association SCTP's four-way handshake has completed. If an association with
with the peer already exists, stream mapping is used and enough the peer already exists, stream mapping is used and enough streams
streams are available, a Connection Object instantly becomes Ready are available, a Connection Object instantly becomes Ready after
after calling "Initiate" or "InitiateWithSend". calling Initiate or InitiateWithSend.
InitiateError: Failure of CONNECT.SCTP. InitiateError: Failure of CONNECT.SCTP.
ConnectionError: TIMEOUT.SCTP or ABORT-EVENT.SCTP. ConnectionError: TIMEOUT.SCTP or ABORT-EVENT.SCTP.
Listen: LISTEN.SCTP. If an association with the peer already exists Listen: LISTEN.SCTP. If an association with the peer already exists
and stream mapping is used, "Listen" just expects to receive a new and stream mapping is used, Listen just expects to receive a new
message with a new stream id (chosen in accordance with the stream message with a new stream id (chosen in accordance with the stream
id assignment procedure described above). id assignment procedure described above).
ConnectionReceived: LISTEN.SCTP returns without an error (a result ConnectionReceived: LISTEN.SCTP returns without an error (a result
of successful CONNECT.SCTP from the peer), or, in case of stream of successful CONNECT.SCTP from the peer), or, in case of stream
mapping, the first message has arrived on a new stream (in this mapping, the first message has arrived on a new stream (in this
case, "Receive" is also invoked). case, Receive is also invoked).
Clone: Calling "Clone" on an SCTP association creates a new Clone: Calling Clone on an SCTP association creates a new Connection
Connection object and assigns it a new stream id in accordance object and assigns it a new stream id in accordance with the
with the stream id assignment procedure described above. If there stream id assignment procedure described above. If there are not
are not enough streams available, ADD_STREAM.SCTP must be called. enough streams available, ADD_STREAM.SCTP must be called.
Priority (Connection): When this value is changed, or a Message with Priority (Connection): When this value is changed, or a Message with
Message Property "Priority" is sent, and there are multiple Message Property Priority is sent, and there are multiple
Connection objects assigned to the same SCTP association, Connection objects assigned to the same SCTP association,
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
"Ordered" map to parameters of this primitive. 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, and the "Closed" event will SCTP association, CLOSE.SCTP is called, and the Closed event will be
be delivered to the application upon the ensuing CLOSE-EVENT.SCTP. delivered to the application upon the ensuing CLOSE-EVENT.SCTP.
Else, the Connection object is one out of several Connection objects Else, the Connection object is one out of several Connection objects
that are assigned to the same SCTP assocation, and RESET_STREAM.SCTP that are assigned to the same SCTP assocation, and RESET_STREAM.SCTP
must be called, which informs the peer that the stream will no longer must be called, which informs the peer that the stream will no longer
be used for mapping and can be used by future "Initiate", be used for mapping and can be used by future Initiate,
"InitiateWithSend" or "Listen" calls. At the peer, the event InitiateWithSend or Listen calls. At the peer, the event
RESET_STREAM-EVENT.SCTP will fire, which the peer must answer by RESET_STREAM-EVENT.SCTP will fire, which the peer must answer by
issuing RESET_STREAM.SCTP too. The resulting local RESET_STREAM- issuing RESET_STREAM.SCTP too. The resulting local RESET_STREAM-
EVENT.SCTP informs the Transport Services system that the stream id EVENT.SCTP informs the Transport Services system that the stream id
can now be re-used by the next "Initiate", "InitiateWithSend" or can now be re-used by the next Initiate, InitiateWithSend or Listen
"Listen" calls, and invokes a "Closed" event towards the application. 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
skipping to change at page 46, line 20 skipping to change at page 46, line 9
it is possible for the network to cause an implementation to consume it is possible for the network to cause an implementation to consume
significant on-device resources. Implementations should limit the significant on-device resources. Implementations should limit the
maximum amount of state allowed for any given node, including the maximum amount of state allowed for any given node, including the
number of child nodes, especially when the state is based on results number of child nodes, especially when the state is based on results
from the network. from the network.
13. Acknowledgements 13. Acknowledgements
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334 research and innovation programme under grant agreement No. 644334
(NEAT). (NEAT) and No. 815178 (5GENESIS).
This work has been supported by Leibniz Prize project funds of DFG - This work has been supported by Leibniz Prize project funds of DFG -
German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ
FE 570/4-1). FE 570/4-1).
This work has been supported by the UK Engineering and Physical This work has been supported by the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
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 Colin Perkins, Tom Jones, Karl-Johan Grinnemo, Gorry
Kinnear for their implementation and design efforts, including Happy Fairhurst, for their contributions to the design of this
Eyeballs, that heavily influenced this work. specification. Thanks also to Stuart Cheshire, Josh Graessley, David
Schinazi, and Eric Kinnear for their implementation and design
efforts, including Happy 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., and
Perkins, C., Tiesel, P. S., and C. A. Wood, "An C. Perkins, "An Architecture for Transport Services", Work
Architecture for Transport Services", Work in Progress, in Progress, Internet-Draft, draft-ietf-taps-arch-12, 3
Internet-Draft, draft-ietf-taps-arch-10, 30 April 2021, January 2022, <https://www.ietf.org/archive/id/draft-ietf-
<https://www.ietf.org/archive/id/draft-ietf-taps-arch- taps-arch-12.txt>.
10.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. S., Wood, C. A., Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A.,
Pauly, T., and K. Rose, "An Abstract Application Layer Pauly, T., and K. Rose, "An Abstract Application Layer
Interface to Transport Services", Work in Progress, Interface to Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-interface-12, 9 April Internet-Draft, draft-ietf-taps-interface-14, 3 January
2021, <https://www.ietf.org/archive/id/draft-ietf-taps- 2022, <https://www.ietf.org/archive/id/draft-ietf-taps-
interface-12.txt>. interface-14.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 49, line 19 skipping to change at page 49, line 15
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the "Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", RFC 8260, Stream Control Transmission Protocol", RFC 8260,
DOI 10.17487/RFC8260, November 2017, DOI 10.17487/RFC8260, November 2017,
<https://www.rfc-editor.org/info/rfc8260>. <https://www.rfc-editor.org/info/rfc8260>.
[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,
skipping to change at page 51, line 26 skipping to change at page 51, line 26
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 Transport Services system was unable to * EstablishmentFailed: The Transport Services system was unable to
establish a transport-layer connection to the remote endpoint establish a transport-layer connection to the Remote Endpoint
specified by the 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.
skipping to change at page 52, line 36 skipping to change at page 52, line 36
communication on top of TCP, UDP and SCTP, with many more communication on top of TCP, UDP and SCTP, with many more
features such as a policy manager. features such as a policy manager.
- Code: https://github.com/NEAT-project/neat (https://github.com/ - Code: https://github.com/NEAT-project/neat (https://github.com/
NEAT-project/neat) NEAT-project/neat)
- NEAT project: https://www.neat-project.org (https://www.neat- - NEAT project: https://www.neat-project.org (https://www.neat-
project.org) project.org)
- NEATPy is a Python shim over NEAT which updates the NEAT API to - NEATPy is a Python shim over NEAT which updates the NEAT API to
be in line with version 6 of the TAPS interface draft. be in line with version 6 of the Transport Services API draft.
- Code: https://github.com/theagilepadawan/NEATPy - Code: https://github.com/theagilepadawan/NEATPy
(https://github.com/theagilepadawan/NEATPy) (https://github.com/theagilepadawan/NEATPy)
* PyTAPS: * PyTAPS:
- A TAPS implementation based on Python asyncio, offering - A TAPS implementation based on Python asyncio, offering
protocol-independent communication to applications on top of protocol-independent communication to applications on top of
TCP, UDP and TLS, with support for multicast. TCP, UDP and TLS, with support for multicast.
skipping to change at page 53, line 28 skipping to change at page 53, line 28
Email: tpauly@apple.com Email: tpauly@apple.com
Theresa Enghardt Theresa Enghardt
Netflix Netflix
121 Albright Way 121 Albright Way
Los Gatos, CA 95032, Los Gatos, CA 95032,
United States of America United States of America
Email: ietf@tenghardt.net Email: ietf@tenghardt.net
Karl-Johan Grinnemo
Karlstad University
Universitetsgatan 2
651 88 Karlstad
Sweden
Email: karl-johan.grinnemo@kau.se
Tom Jones
University of Aberdeen
Fraser Noble Building
Aberdeen, AB24 3UE
United Kingdom
Email: tom@erg.abdn.ac.uk
Philipp S. Tiesel Philipp S. Tiesel
SAP SE SAP SE
Konrad-Zuse-Ring 10 Konrad-Zuse-Ring 10
14469 Potsdam 14469 Potsdam
Germany Germany
Email: philipp@tiesel.net Email: philipp@tiesel.net
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
United Kingdom
Email: csp@csperkins.org
Michael Welzl Michael Welzl
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
0316 Oslo 0316 Oslo
Norway Norway
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
 End of changes. 115 change blocks. 
353 lines changed or deleted 344 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/