draft-ietf-taps-impl-11.txt   draft-ietf-taps-impl-12.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 July 2022 Apple Inc. Expires: 8 September 2022 Apple Inc.
T. Enghardt T. Enghardt
Netflix Netflix
P. Tiesel P. Tiesel
SAP SE SAP SE
M. Welzl M. Welzl
University of Oslo University of Oslo
9 January 2022 7 March 2022
Implementing Interfaces to Transport Services Implementing Interfaces to Transport Services
draft-ietf-taps-impl-11 draft-ietf-taps-impl-12
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 42 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 July 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 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
skipping to change at page 2, line 51 skipping to change at page 2, line 51
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 . . . . . . . . . . . . . . 29 6.3. Receiver-side Message Framing . . . . . . . . . . . . . . 30
7. Implementing Connection Management . . . . . . . . . . . . . 30 7. Implementing Connection Management . . . . . . . . . . . . . 31
7.1. Pooled Connection . . . . . . . . . . . . . . . . . . . . 31 7.1. Pooled Connection . . . . . . . . . . . . . . . . . . . . 31
7.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 31 7.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . . . . . . . . . 40 10.4. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 40
10.5. UDP Multicast Receive . . . . . . . . . . . . . . . . . 40 10.5. UDP Multicast Receive . . . . . . . . . . . . . . . . . 40
skipping to change at page 4, line 32 skipping to change at page 4, line 32
influences a Connection only at one point in time: when the influences a Connection only at one point in time: when the
Connection is created. Connection objects represent the interface Connection is created. Connection objects represent the interface
between the application and the implementation to manage transport between the application and the implementation to manage transport
state, and conduct data transfer. During the process of state, and conduct data transfer. During the process of
establishment (Section 4), the Connection will not be bound to a establishment (Section 4), the Connection will not be bound to a
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 cannot be mutated by
the application makes changes to a Preconnection object. This may the application making changes to the original Preconnection object.
involve the implementation performing a deep-copy, copying the object This may involve the implementation performing a deep-copy, copying
with all the objects that it references. the object with all the objects that it references.
Once the Connection is established, Transport Services implementation Once the Connection is established, Transport Services implementation
maps actions and events to the details of the chosen Protocol Stack. maps actions and events to the details of the chosen Protocol Stack.
For example, the same Connection object may ultimately represent a For example, the same Connection object may ultimately represent a
single instance of one transport protocol (e.g., a TCP connection, a single instance of one transport protocol (e.g., a TCP connection, a
TLS session over TCP, a UDP flow with fully-specified Local and TLS session over TCP, a UDP flow with fully-specified Local and
Remote Endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an Remote Endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an
HTTP/2 stream). The properties held by a Connection or Listener is HTTP/2 stream). The properties held by a Connection or Listener is
independent of other connections that are not part of the same independent of other connections that are not part of the same
Connection Group. Connection Group.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
[I-D.ietf-taps-arch]), in which the necessary protocol handshakes are [I-D.ietf-taps-arch]), in which the necessary protocol handshakes are
conducted so that the transport system can select which set to use. conducted so that the transport system can select which set to use.
This document structures the candidates for racing as a tree as This document structures the candidates for racing as a tree as
terminological convention. While a a tree structure is not the only terminological convention. While a a tree structure is not the only
way in which racing can be implemented, it does ease the illustration way in which racing can be implemented, it does ease the illustration
of how racing works. of how racing works.
The most simple example of this process might involve identifying the The most simple example of this process might involve identifying the
single IP address to which the implementation wishes to connect, single IP address to which the implementation wishes to connect,
using the system's current default interface or path, and starting a using the system's current default path (i.e., using the default
TCP handshake to establish a stream to the specified IP address. interface), and starting a TCP handshake to establish a stream to the
However, each step may also differ depending on the requirements of specified IP address. However, each step may also differ depending
the connection: if the endpoint is defined as a hostname and port, on the requirements of the connection: if the endpoint is defined as
then there may be multiple resolved addresses that are available; a hostname and port, then there may be multiple resolved addresses
there may also be multiple interfaces or paths available, other than that are available; there may also be multiple paths available, (in
the default system interface; and some protocols may not need any this case using an interface other than the default system
transport handshake to be considered "established" (such as UDP), interface); and some protocols may not need any transport handshake
while other connections may utilize layered protocol handshakes, such to be considered "established" (such as UDP), while other connections
as TLS over TCP. may utilize layered protocol handshakes, such as TLS over TCP.
Whenever an implementation has multiple options for connection Whenever an implementation has multiple options for connection
establishment, it can view the set of all individual connection establishment, it can view the set of all individual connection
establishment options as a single, aggregate connection establishment options as a single, aggregate connection
establishment. The aggregate set conceptually includes every valid establishment. The aggregate set conceptually includes every valid
combination of endpoints, paths, and protocols. As an example, combination of endpoints, paths, and protocols. As an example,
consider an implementation that initiates a TCP connection to a consider an implementation that initiates a TCP connection to a
hostname + port endpoint, and has two valid interfaces available (Wi- hostname + port endpoint, and has two valid interfaces available (Wi-
Fi and LTE). The hostname resolves to a single IPv4 address on the Fi and LTE). The hostname resolves to a single IPv4 address on the
Wi-Fi network, and resolves to the same IPv4 address on the LTE Wi-Fi network, and resolves to the same IPv4 address on the LTE
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 network path, and a set of protocols
directly negotiate and send data on the network. Each node in the that can directly negotiate and send data on the network. Each node
tree that is not a leaf represents a connection attempt that is in the tree that is not a leaf represents a connection attempt that
either underspecified, or else includes multiple distinct options. is 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
decision between the paths, with a branch for each interface. decision between the network paths, with a branch for each interface.
The example aggregate connection attempt above can be drawn as a tree The example aggregate connection attempt above can be drawn as a tree
by grouping the addresses resolved on the same interface into by grouping the addresses resolved on the same interface into
branches: branches:
|| ||
+==========================+ +==========================+
| www.example.com:80/Any | | www.example.com:80/Any |
+==========================+ +==========================+
// \\ // \\
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 (labeled here by interface), and protocol. The above
more succinctly as: example can now be written 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
attempts as a single connection establishment, it only will use one attempts as a single connection establishment, it only will use one
skipping to change at page 10, line 18 skipping to change at page 10, line 18
4.1.1. Branch Types 4.1.1. Branch Types
There are three types of branching from a parent node into one or There are three types of branching from a parent node into one or
more child nodes. Any parent node of the tree must only use one type more child nodes. Any parent node of the tree must only use one type
of branching. of branching.
4.1.1.1. Derived Endpoints 4.1.1.1. Derived Endpoints
If a connection originally targets a single endpoint, there may be If a connection originally targets a single endpoint, there may be
multiple endpoints of different types that can be derived from the multiple endpoints of different types that can be derived from the
original. The connection library creates an ordered list of the original. This creates an ordered list of the derived endpoints
derived endpoints according to application preference, system policy according to application preference, system policy and expected
and expected performance. performance.
DNS hostname-to-address resolution is the most common method of DNS hostname-to-address resolution is the most common method of
endpoint derivation. When trying to connect to a hostname endpoint endpoint derivation. When trying to connect to a hostname endpoint
on a traditional IP network, the implementation should send DNS on a traditional IP network, the implementation should send DNS
queries for both A (IPv4) and AAAA (IPv6) records if both are queries for both A (IPv4) and AAAA (IPv6) records if both are
supported on the local interface. The algorithm for ordering and supported on the local interface. The algorithm for ordering and
racing these addresses should follow the recommendations in Happy racing these addresses should follow the recommendations in Happy
Eyeballs [RFC8305]. Eyeballs [RFC8305].
1 [www.example.com:80, Wi-Fi, TCP] 1 [www.example.com:80, Wi-Fi, TCP]
skipping to change at page 11, line 5 skipping to change at page 11, line 5
client may discover one or more hostname and port pairs on the local client may discover one or more hostname and port pairs on the local
network using multicast DNS [RFC6762]. These hostnames should each network using multicast DNS [RFC6762]. These hostnames should each
be treated as a branch that can be attempted independently from other be treated as a branch that can be attempted independently from other
hostnames. Each of these hostnames might resolve to one or more hostnames. Each of these hostnames might resolve to one or more
addresses, which would create multiple layers of branching. addresses, which would create multiple layers of branching.
1 [term-printer._ipp._tcp.meeting.ietf.org, Wi-Fi, TCP] 1 [term-printer._ipp._tcp.meeting.ietf.org, Wi-Fi, TCP]
1.1 [term-printer.meeting.ietf.org:631, Wi-Fi, TCP] 1.1 [term-printer.meeting.ietf.org:631, Wi-Fi, TCP]
1.1.1 [31.133.160.18.631, Wi-Fi, TCP] 1.1.1 [31.133.160.18.631, Wi-Fi, TCP]
Applications can influence which derived endpoints are allowed and
preferred via Selection Properties set on the Preconnection. For
example, setting a preference for useTemporaryLocalAddress would
prefer the use of IPv6 over IPv4, and requiring
useTemporaryLocalAddress would eliminate IPv4 options, since IPv4
does not support temporary addresses.
4.1.1.2. Alternate Paths 4.1.1.2. Alternate Paths
If a client has multiple network interfaces available to it, e.g., a If a client has multiple network paths available to it, e.g., a
mobile client with both Wi-Fi and Cellular connectivity, it can mobile client with intefaces for both Wi-Fi and Cellular
attempt a connection over any of the interfaces. This represents a connectivity, it can attempt a connection over any of the paths.
branch point in the connection establishment. Similar to a derived This represents a branch point in the connection establishment.
endpoint, the interfaces should be ranked based on preference, system Similar to a derived endpoint, the paths should be ranked based on
policy, and performance. Attempts should be started on one preference, system policy, and performance. Attempts should be
interface, and then on other interfaces successively after delays started on one path (e.g., a specific interface), and then
based on expected round-trip-time or other available metrics. successively on other paths (or interfaces) after delays based on
expected path round-trip-time or other available metrics.
1 [192.0.2.1:80, Any, TCP] 1 [192.0.2.1:80, Any, TCP]
1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.1 [192.0.2.1:80, Wi-Fi, TCP]
1.2 [192.0.2.1:80, LTE, TCP] 1.2 [192.0.2.1:80, LTE, TCP]
This same approach applies to any situation in which the client is This same approach applies to any situation in which the client is
aware of multiple links or views of the network. Multiple Paths, aware of multiple links or views of the network. A single interface
each with a coherent set of addresses, routes, DNS server, and more, may be shared by multiple network paths, each with a coherent set of
may share a single interface. A path may also represent a virtual addresses, routes, DNS server, and more. A path may also represent a
interface service such as a Virtual Private Network (VPN). virtual interface service such as a Virtual Private Network (VPN).
The list of available paths should be constrained by any requirements The list of available paths should be constrained by any requirements
or prohibitions the application sets, as well as system policy. the application sets, as well as by the system policy.
4.1.1.3. Protocol Options 4.1.1.3. Protocol Options
Differences in possible protocol compositions and options can also Differences in possible protocol compositions and options can also
provide a branching point in connection establishment. This allows provide a branching point in connection establishment. This allows
clients to be resilient to situations in which a certain protocol is clients to be resilient to situations in which a certain protocol is
not functioning on a server or network. not functioning on a server or network.
This approach is commonly used for connections with optional proxy This approach is commonly used for connections with optional proxy
server configurations. A single connection might have several server configurations. A single connection might have several
skipping to change at page 24, line 16 skipping to change at page 24, line 16
could choose to send Messages of different Priority on streams of could choose to send Messages of different Priority on streams of
different priority. different priority.
* Ordered: when this is false, this disables the requirement of in- * Ordered: when this is false, this disables the requirement of in-
order-delivery for protocols that support configurable ordering. order-delivery for protocols that support configurable ordering.
When the protocol stack does not support configurable ordering, When the protocol stack does not support configurable ordering,
this property may be ignored. this property may be ignored.
* Safely Replayable: when this is true, this means that the Message * Safely Replayable: when this is true, this means that the Message
can be used by a transport mechanism that might transfer it can be used by a transport mechanism that might transfer it
multiple times - e.g., as a result of racing multiple transports multiple times -- e.g., as a result of racing multiple transports
or as part of TCP Fast Open. Also, protocols that do not protect or as part of TCP Fast Open. Also, protocols that do not protect
against duplicated messages, such as UDP (when used directly, against duplicated messages, such as UDP (when used directly,
without a protocol layered atop), can only be used with Messages without a protocol layered atop), can only be used with Messages
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
skipping to change at page 28, line 16 skipping to change at page 28, line 16
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 a Transport Services implementation or the application be provided by a Transport Services implementation or the application
itself. The Message Framer refers to the object or function within itself. The Message Framer refers to the object or function within
the main Connection implementation that delivers events to the custom the main Connection implementation that delivers events to the custom
framer implementation whenever data is ready to be parsed or framed. framer implementation whenever data is ready to be parsed or framed.
The Transport Services implementation needs to ensure that all of the
events and actions taken on a Message Framer are synchronized to
ensure consistent behavior. For example, some of the actions defined
below (such as PrependFramer and StartPassthrough) modify how data
flows in a protocol stack, and require synchronization with sending
and parsing data in the Message Framer.
When a Connection establishment attempt begins, an event can be When a Connection establishment attempt begins, an event can be
delivered to notify the framer implementation that a new Connection delivered to notify the framer implementation that a new Connection
is being created. Similarly, a stop event can be delivered when a is being created. Similarly, a stop event can be delivered when a
Connection is being torn down. The framer implementation can use the Connection is being torn down. The framer implementation can use the
Connection object to look up specific properties of the Connection or Connection object to look up specific properties of the Connection or
the network being used that may influence how to frame Messages. the network being used that may influence how to frame Messages.
MessageFramer -> Start(Connection) MessageFramer -> Start(Connection)
MessageFramer -> Stop(Connection) MessageFramer -> Stop(Connection)
skipping to change at page 46, line 35 skipping to change at page 46, line 35
efforts, including Happy Eyeballs, that heavily influenced this work. 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., and Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and
C. Perkins, "An Architecture for Transport Services", Work C. Perkins, "An Architecture for Transport Services", Work
in Progress, Internet-Draft, draft-ietf-taps-arch-12, 3 in Progress, Internet-Draft, draft-ietf-taps-arch-12, 3
January 2022, <https://www.ietf.org/archive/id/draft-ietf- January 2022, <https://datatracker.ietf.org/doc/html/
taps-arch-12.txt>. draft-ietf-taps-arch-12>.
[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-14, 3 January Internet-Draft, draft-ietf-taps-interface-14, 3 January
2022, <https://www.ietf.org/archive/id/draft-ietf-taps- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
interface-14.txt>. taps-interface-14>.
[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/rfc/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/rfc/rfc7540>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols", Transport Features Provided by IETF Transport Protocols",
RFC 8303, DOI 10.17487/RFC8303, February 2018, RFC 8303, DOI 10.17487/RFC8303, February 2018,
<https://www.rfc-editor.org/info/rfc8303>. <https://www.rfc-editor.org/rfc/rfc8303>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP- User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>. <https://www.rfc-editor.org/rfc/rfc8304>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/rfc/rfc8305>.
[RFC8421] Martinsen, P., Reddy, T., and P. Patil, "Guidelines for [RFC8421] Martinsen, P., Reddy, T., and P. Patil, "Guidelines for
Multihomed and IPv4/IPv6 Dual-Stack Interactive Multihomed and IPv4/IPv6 Dual-Stack Interactive
Connectivity Establishment (ICE)", BCP 217, RFC 8421, Connectivity Establishment (ICE)", BCP 217, RFC 8421,
DOI 10.17487/RFC8421, July 2018, DOI 10.17487/RFC8421, July 2018,
<https://www.rfc-editor.org/info/rfc8421>. <https://www.rfc-editor.org/rfc/rfc8421>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/info/rfc8923>. October 2020, <https://www.rfc-editor.org/rfc/rfc8923>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-34, 14 January 2021, draft-ietf-quic-transport-34, 14 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
transport-34.txt>. transport-34>.
[I-D.ietf-tcpm-2140bis] [I-D.ietf-tcpm-2140bis]
Touch, J., Welzl, M., and S. Islam, "TCP Control Block Touch, J., Welzl, M., and S. Islam, "TCP Control Block
Interdependence", Work in Progress, Internet-Draft, draft- Interdependence", Work in Progress, Internet-Draft, draft-
ietf-tcpm-2140bis-11, 12 April 2021, ietf-tcpm-2140bis-11, 12 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-tcpm-2140bis- <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-
11.txt>. 2140bis-11>.
[NEAT-flow-mapping] [NEAT-flow-mapping]
"Transparent Flow Mapping for NEAT", IFIP NETWORKING 2017 "Transparent Flow Mapping for NEAT", IFIP NETWORKING 2017
Workshop on Future of Internet Transport (FIT 2017) , Workshop on Future of Internet Transport (FIT 2017) ,
2017. 2017.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996, DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>. <https://www.rfc-editor.org/rfc/rfc1928>.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, DOI 10.17487/RFC3124, June 2001, RFC 3124, DOI 10.17487/RFC3124, June 2001,
<https://www.rfc-editor.org/info/rfc3124>. <https://www.rfc-editor.org/rfc/rfc3124>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/info/rfc3207>. February 2002, <https://www.rfc-editor.org/rfc/rfc3207>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/rfc/rfc5389>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>. <https://www.rfc-editor.org/rfc/rfc5766>.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
Transmission Protocol (SCTP) Stream Reconfiguration", Transmission Protocol (SCTP) Stream Reconfiguration",
RFC 6525, DOI 10.17487/RFC6525, February 2012, RFC 6525, DOI 10.17487/RFC6525, February 2012,
<https://www.rfc-editor.org/info/rfc6525>. <https://www.rfc-editor.org/rfc/rfc6525>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/rfc/rfc6763>.
[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/rfc/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/rfc/rfc7657>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/rfc/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/rfc/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,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/rfc/rfc8445>.
[TCP-COUPLING] [TCP-COUPLING]
"ctrlTCP: Reducing Latency through Coupled, Heterogeneous "ctrlTCP: Reducing Latency through Coupled, Heterogeneous
Multi-Flow TCP Congestion Control", IEEE INFOCOM Global Multi-Flow TCP Congestion Control", IEEE INFOCOM Global
Internet Symposium (GI) workshop (GI 2018) , n.d.. Internet Symposium (GI) workshop (GI 2018) , n.d..
Appendix A. API Mapping Template Appendix A. API Mapping Template
Any protocol mapping for the Transport Services API should follow a Any protocol mapping for the Transport Services API should follow a
common template. common template.
 End of changes. 43 change blocks. 
74 lines changed or deleted 89 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/