draft-ietf-taps-arch-13.txt   draft-ietf-taps-arch-14.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: 29 December 2022 Google Switzerland GmbH Expires: 31 March 2023 Google Switzerland GmbH
A. Brunstrom A. Brunstrom
Karlstad University Karlstad University
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
C. Perkins C. Perkins
University of Glasgow University of Glasgow
27 June 2022 27 September 2022
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-13 draft-ietf-taps-arch-14
Abstract Abstract
This document describes an architecture for exposing transport This document describes an architecture for exposing transport
protocol features to applications for network communication, a protocol features to applications for network communication, a
Transport Services system. The Transport Services Application Transport Services system. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. This API uses messages for representing data interaction pattern. This API uses messages for representing data
transfer to applications, and describes how implementations can use transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and multiple IP addresses, multiple protocols, and multiple paths, and
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 29 December 2022. This Internet-Draft will expire on 31 March 2023.
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 8, line 12 skipping to change at page 8, line 12
and changes in the available network links, which were not previously and changes in the available network links, which were not previously
made explicit in the Socket API. made explicit in the Socket API.
Using asynchronous events allows for a more natural interaction model Using asynchronous events allows for a more natural interaction model
when establishing connections and transferring data. Events in time when establishing connections and transferring data. Events in time
more closely reflect the nature of interactions over networks, as more closely reflect the nature of interactions over networks, as
opposed to how the Socket API represent network resources as file opposed to how the Socket API represent network resources as file
system objects that may be temporarily unavailable. system objects that may be temporarily unavailable.
Separate from events, callbacks are also provided for asynchronous Separate from events, callbacks are also provided for asynchronous
interactions with the API not directly related to events on the interactions with the Transport Services API that are not directly
network or network interfaces. related to events on the network or network interfaces.
2.2. Data Transfer Using Messages 2.2. Data Transfer Using Messages
The Socket API provides a message interface for datagram protocols The Socket API provides a message interface for datagram protocols
like UDP, but provides an unstructured stream abstraction for TCP. like UDP, but provides an unstructured stream abstraction for TCP.
While TCP has the ability to send and receive data as a byte-stream, While TCP has the ability to send and receive data as a byte-stream,
most applications need to interpret structure within this byte- most applications need to interpret structure within this byte-
stream. For example, HTTP/1.1 uses character delimiters to segment stream. For example, HTTP/1.1 uses character delimiters to segment
messages over a byte-stream [RFC7230]; TLS record headers carry a messages over a byte-stream [RFC7230]; TLS record headers carry a
version, content type, and length [RFC8446]; and HTTP/2 uses frames version, content type, and length [RFC8446]; and HTTP/2 uses frames
skipping to change at page 12, line 5 skipping to change at page 12, line 5
using a specific protocol, and not when using others. For example, using a specific protocol, and not when using others. For example,
if an application is using TCP, it could require control over the if an application is using TCP, it could require control over the
User Timeout Option for TCP; these options would not take effect for User Timeout Option for TCP; these options would not take effect for
other transport protocols. In such cases, the API ought to expose other transport protocols. In such cases, the API ought to expose
the features in such a way that they take effect when a particular the features in such a way that they take effect when a particular
protocol is selected, but do not imply that only that protocol could protocol is selected, but do not imply that only that protocol could
be used. For example, if the API allows an application to specify a be used. For example, if the API allows an application to specify a
preference to use the User Timeout Option, communication would not preference to use the User Timeout Option, communication would not
fail when a protocol such as QUIC is selected. fail when a protocol such as QUIC is selected.
Other specialized features, however, can be strictly required by an Other specialized features, however, can also be strictly required by
application and thus constrain the set of protocols that can be used. an application and thus further constrain the set of protocols that
For example, if an application requires support for automatic can be used. For example, if an application requires support for
handover or failover for a connection, only protocol stacks that automatic handover or failover for a connection, only protocol stacks
provide this feature are eligible to be used, e.g., protocol stacks that provide this feature are eligible to be used, e.g., protocol
that include a multipath protocol or a protocol that supports stacks that include a multipath protocol or a protocol that supports
connection migration. A Transport Services API needs to allow connection migration. A Transport Services API needs to allow
applications to define such requirements and constrain the options applications to define such requirements and constrain the options
available to a Transport Services implementation. Since such options available to a Transport Services implementation. Since such options
are not part of the core/common features, it will generally be simple are not part of the core/common features, it will generally be simple
for an application to modify its set of constraints and change the for an application to modify its set of constraints and change the
set of allowable protocol features without changing the core set of allowable protocol features without changing the core
implementation. implementation.
3.3. Select Equivalent Protocol Stacks 3.3. Select Equivalent Protocol Stacks
skipping to change at page 15, line 36 skipping to change at page 15, line 36
* Establishment (Section 4.1.4) focuses on the actions that an * Establishment (Section 4.1.4) focuses on the actions that an
application takes on the connection objects to prepare for data application takes on the connection objects to prepare for data
transfer. transfer.
* Data Transfer (Section 4.1.5) consists of how an application * Data Transfer (Section 4.1.5) consists of how an application
represents the data to be sent and received, the functions represents the data to be sent and received, the functions
required to send and receive that data, and how the application is required to send and receive that data, and how the application is
notified of the status of its data transfer. notified of the status of its data transfer.
* Event Handling (Section 4.1.6) defines categories of notifications * Event Handling (Section 4.1.6) defines categories of notifications
which an application can receive during the lifetime of transport that an application can receive during the lifetime of transport
objects. Events also provide opportunities for the application to objects. Events also provide opportunities for the application to
interact with the underlying transport by querying state or interact with the underlying transport by querying state or
updating maintenance options. updating maintenance options.
* Termination (Section 4.1.7) focuses on the methods by which data * Termination (Section 4.1.7) focuses on the methods by which data
transmission is stopped, and state is torn down in the transport. transmission is stopped, and state is torn down in the transport.
The diagram below provides a high-level view of the actions and The diagram below provides a high-level view of the actions and
events during the lifetime of a Connection object. Note that some events during the lifetime of a Connection object. Note that some
actions are alternatives (e.g., whether to initiate a connection or actions are alternatives (e.g., whether to initiate a connection or
skipping to change at page 17, line 44 skipping to change at page 17, line 44
* Connection: A Connection object represents one or more active * Connection: A Connection object represents one or more active
transport protocol instances that can send and/or receive Messages transport protocol instances that can send and/or receive Messages
between Local and Remote Endpoints. It is an abstraction that between Local and Remote Endpoints. It is an abstraction that
represents the communication. The Connection object holds state represents the communication. The Connection object holds state
pertaining to the underlying transport protocol instances and any pertaining to the underlying transport protocol instances and any
ongoing data transfers. For example, an active Connection can ongoing data transfers. For example, an active Connection can
represent a connection-oriented protocol such as TCP, or can represent a connection-oriented protocol such as TCP, or can
represent a fully-specified 5-tuple for a connectionless protocol represent a fully-specified 5-tuple for a connectionless protocol
such as UDP, where the Connection remains an abstraction at the such as UDP, where the Connection remains an abstraction at the
end points. It can also represent a pool of transport protocol endpoints. It can also represent a pool of transport protocol
instances, e.g., a set of TCP and QUIC connections to equivalent instances, e.g., a set of TCP and QUIC connections to equivalent
endpoints, or a stream of a multi-streaming transport protocol endpoints, or a stream of a multi-streaming transport protocol
instance. Connections can be created from a Preconnection or by a instance. Connections can be created from a Preconnection or by a
Listener. Listener.
* Listener: A Listener object accepts incoming transport protocol * Listener: A Listener object accepts incoming transport protocol
connections from Remote Endpoints and generates corresponding connections from Remote Endpoints and generates corresponding
Connection objects. It is created from a Preconnection object Connection objects. It is created from a Preconnection object
that specifies the type of incoming Connections it will accept. that specifies the type of incoming Connections it will accept.
skipping to change at page 22, line 20 skipping to change at page 22, line 20
While Connection Groups are managed by the Transport Services system, While Connection Groups are managed by the Transport Services system,
an application can define Connection Contexts to control caching an application can define Connection Contexts to control caching
boundaries, as discussed in Section 4.2.3. boundaries, as discussed in Section 4.2.3.
4.2. Transport Services Implementation 4.2. Transport Services Implementation
This section defines the key concepts of the Transport Services This section defines the key concepts of the Transport Services
architecture. architecture.
* Transport Service implementaion: This consists of all objects and * Transport Service implementation: This consists of all objects and
protocol instances used internally to a system or library to protocol instances used internally to a system or library to
implement the functionality needed to provide a transport service implement the functionality needed to provide a transport service
across a network, as required by the abstract interface. across a network, as required by the abstract interface.
* Transport Service system: This consists of the Transport Service * Transport Service system: This consists of the Transport Service
implementaion and the Transport Services API. implementation and the Transport Services API.
* Path: Represents an available set of properties that a local * Path: Represents an available set of properties that a Local
endpoint can use to communicate with a Remote Endpoint, such as Endpoint can use to communicate with a Remote Endpoint, such as
routes, addresses, and physical and virtual network interfaces. routes, addresses, and physical and virtual network interfaces.
* Protocol Instance: A single instance of one protocol, including * Protocol Instance: A single instance of one protocol, including
any state necessary to establish connectivity or send and receive any state necessary to establish connectivity or send and receive
Messages. Messages.
* Protocol Stack: A set of Protocol Instances (including relevant * Protocol Stack: A set of Protocol Instances (including relevant
application, security, transport, or Internet protocols) that are application, security, transport, or Internet protocols) that are
used together to establish connectivity or send and receive used together to establish connectivity or send and receive
Messages. A single stack can be simple (a single transport Messages. A single stack can be simple (a single transport
skipping to change at page 24, line 21 skipping to change at page 24, line 21
racing of the resolved Remote Endpoints. racing of the resolved Remote Endpoints.
* Remote Endpoint Racing: Remote Endpoint Racing is the act of * Remote Endpoint Racing: Remote Endpoint Racing is the act of
attempting to establish, or scheduling attempts to establish, attempting to establish, or scheduling attempts to establish,
multiple Protocol Stacks that differ based on the specific multiple Protocol Stacks that differ based on the specific
representation of the Remote Endpoint, such as a particular IP representation of the Remote Endpoint, such as a particular IP
address that was resolved from a DNS hostname. address that was resolved from a DNS hostname.
4.2.3. Separating Connection Contexts 4.2.3. Separating Connection Contexts
By default, stored properties of the implementation, such as cached A Transport Services implementation can by default share stored
protocol state, cached path state, and heuristics, may be shared properties across Connections within an application, such as cached
(e.g. across multiple connections in an application). This provides protocol state, cached path state, and heuristics. This provides
efficiency and convenience for the application, since the Transport efficiency and convenience for the application, since the Transport
Services system can automatically optimize behavior. Services system can automatically optimize behavior.
The Transport Services API can allow applications to explicitly The Transport Services API can allow applications to explicitly
define Connection Contexts that force separation of Cached State and define Connection Contexts that force separation of Cached State and
Protocol Stacks. For example, a web browser application could use Protocol Stacks. For example, a web browser application could use
Connection Contexts with separate caches when implementing different Connection Contexts with separate caches when implementing different
tabs. Possible reasons to isolate Connections using separate tabs. Possible reasons to isolate Connections using separate
Connection Contexts include: Connection Contexts include:
skipping to change at page 26, line 33 skipping to change at page 26, line 33
through the TAPS working group. Thanks as well to Stuart Cheshire, through the TAPS working group. Thanks as well to Stuart Cheshire,
Josh Graessley, David Schinazi, and Eric Kinnear for their Josh Graessley, David Schinazi, and Eric Kinnear for their
implementation and design efforts, including Happy Eyeballs, that implementation and design efforts, including Happy Eyeballs, that
heavily influenced this work. heavily influenced this work.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly, K├╝hlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
"An Abstract Application Layer Interface to Transport "An Abstract Application Layer Interface to Transport
Services", Work in Progress, Internet-Draft, draft-ietf- Services", Work in Progress, Internet-Draft, draft-ietf-
taps-interface-15, 7 March 2022, taps-interface-17, 27 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps- <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
interface-15>. interface-17>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, T., Tiesel, P. S., and Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and
M. Welzl, "Implementing Interfaces to Transport Services", M. Welzl, "Implementing Interfaces to Transport Services",
Work in Progress, Internet-Draft, draft-ietf-taps-impl-12, Work in Progress, Internet-Draft, draft-ietf-taps-impl-13,
7 March 2022, <https://datatracker.ietf.org/doc/html/ 31 August 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-taps-impl-12>. draft-ietf-taps-impl-13>.
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open -- Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7", group Technical Standard: Base Specifications, Issue 7",
2008. 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
RFC 793, DOI 10.17487/RFC0793, September 1981, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/rfc/rfc793>. <https://www.rfc-editor.org/rfc/rfc793>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[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/rfc/rfc7230>. <https://www.rfc-editor.org/rfc/rfc7230>.
 End of changes. 18 change blocks. 
31 lines changed or deleted 31 lines changed or added

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