draft-ietf-taps-arch-16.txt   draft-ietf-taps-arch-17.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: 10 September 2023 Google Switzerland GmbH Expires: 30 September 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
9 March 2023 29 March 2023
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-16 draft-ietf-taps-arch-17
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 10 September 2023. This Internet-Draft will expire on 30 September 2023.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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 5, line 27 skipping to change at page 5, line 27
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.4. Glossary of Key Terms 1.4. Glossary of Key Terms
This subsection provides a glossary of key terms related to the This subsection provides a glossary of key terms related to the
Transport Services architecture. Transport Services architecture. It provides a short description of
key terms that are later defined in this document.
* Application: An entity that uses the transport layer for end-to- * Application: An entity that uses the transport layer for end-to-
end delivery of data across the network [RFC8095]. end delivery of data across the network [RFC8095].
* Cached State: The state and history that the implementation keeps * Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used for each set of associated Endpoints that have been used
previously. previously.
* Candidate Path: One path that is available to an application and * Candidate Path: One path that is available to an application and
conforms to the Selection Properties and System Policy during conforms to the Selection Properties and System Policy during
skipping to change at page 6, line 29 skipping to change at page 6, line 29
* Framer: A data translation layer that can be added to a Connection * Framer: A data translation layer that can be added to a Connection
to define how application-layer Messages are transmitted over a to define how application-layer Messages are transmitted over a
Protocol Stack. Protocol Stack.
* Local Endpoint: A representation of the application's identifier * Local Endpoint: A representation of the application's identifier
for itself that it uses for a Connection. for itself that it uses for a Connection.
* Message: A unit of data that can be transferred between two * Message: A unit of data that can be transferred between two
Endpoints over a Connection. Endpoints over a Connection.
* Message Property: A property than can be used to specify details * Message Property: A property that can be used to specify details
about Message transmission, or obtain details about the about Message transmission, or obtain details about the
transmission after receiving a Message. transmission after receiving a Message.
* Parameter: A value passed between an application and a transport * Parameter: A value passed between an application and a transport
protocol by a primitive [RFC8303]. protocol by a primitive [RFC8303].
* Path: A representation of an available set of properties that a * Path: A representation of an available set of properties that a
Local Endpoint can use to communicate with a Remote Endpoint. Local Endpoint can use to communicate with a Remote Endpoint.
* Peer: An endpoint application party to a Connection. * Peer: An endpoint application party to a Connection.
* Preconnection: an object that repesents a Connection that has not * Preconnection: an object that represents a Connection that has not
yet been established. yet been established.
* Preference: A preference to prohibit, avoid, ignore prefer or * Preference: A preference to prohibit, avoid, ignore prefer or
require a specific Transport Feature. require a specific Transport Feature.
* Primitive: A function call that is used to locally communicate * Primitive: A function call that is used to locally communicate
between an application and an endpoint, which is related to one or between an application and an endpoint, which is related to one or
more Transport Features [RFC8303]. more Transport Features [RFC8303].
* Protocol Instance: A single instance of one protocol, including * Protocol Instance: A single instance of one protocol, including
skipping to change at page 9, line 34 skipping to change at page 9, line 34
The Transport Services API [I-D.ietf-taps-interface] defines the The Transport Services API [I-D.ietf-taps-interface] defines the
interface for an application to create Connections and transfer data. interface for an application to create Connections and transfer data.
It combines interfaces for multiple interaction patterns into a It combines interfaces for multiple interaction patterns into a
unified whole. By combining name resolution with connection unified whole. By combining name resolution with connection
establishment and data transfer in a single API, it allows for more establishment and data transfer in a single API, it allows for more
flexible implementations to provide path and transport protocol flexible implementations to provide path and transport protocol
agility on the application's behalf. agility on the application's behalf.
The Transport Services implementation [I-D.ietf-taps-impl] implements The Transport Services implementation [I-D.ietf-taps-impl] implements
the transport layer protocols and other functions needed to send and the transport layer protocols and other functions needed to send and
receive data. It is is responsible for mapping the API to a specific receive data. It is responsible for mapping the API to a specific
available transport protocol stack and managing the available network available transport protocol stack and managing the available network
interfaces and paths. interfaces and paths.
There are key differences between the Transport Services architecture There are key differences between the Transport Services architecture
and the architecture of the Socket API: the API of the Transport and the architecture of the Socket API: the API of the Transport
Services architecture is asynchronous and event-driven; it uses Services architecture is asynchronous and event-driven; it uses
messages for representing data transfer to applications; and it messages for representing data transfer to applications; and it
describes how implementations can use multiple IP addresses, multiple describes how implementations can use multiple IP addresses, multiple
protocols, multiple paths, and provide multiple application streams. protocols, multiple paths, and provide multiple application streams.
skipping to change at page 10, line 26 skipping to change at page 10, line 26
contain the data. Error handling is also asynchronous; a failure to contain the data. Error handling is also asynchronous; a failure to
send data results in an asynchronous error event. send data results in an asynchronous error event.
This API also delivers events regarding the lifetime of a connection This API also delivers events regarding the lifetime of a connection
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 represents 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 Transport Services API that are not directly interactions with the Transport Services API that are not directly
related to events on the 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.
skipping to change at page 13, line 50 skipping to change at page 13, line 50
not require reliability can function correctly when a protocol not require reliability can function correctly when a protocol
provides reliability, reliability ought to be enabled by default. As provides reliability, reliability ought to be enabled by default. As
another example, the default value for a Property regarding the another example, the default value for a Property regarding the
selection of network interfaces ought to permit as many interfaces as selection of network interfaces ought to permit as many interfaces as
possible. possible.
Applications using the Transport Services API are REQUIRED to be Applications using the Transport Services API are REQUIRED to be
robust to the automated selection provided by the Transport Services robust to the automated selection provided by the Transport Services
implementation. This automated selection is constrained by the implementation. This automated selection is constrained by the
properties and preferences expressed by the application and requires properties and preferences expressed by the application and requires
applications to explictly set properties that define any necssary applications to explicitly set properties that define any necessary
constraints on protocol, path, and interface selection. constraints on protocol, path, and interface selection.
3.2. Allow Access to Specialized Features 3.2. Allow Access to Specialized Features
There are applications that will need to control fine-grained details There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure of transport protocols to optimize their behavior and ensure
compatibility with remote systems. It is therefore RECOMMENDED that compatibility with remote systems. It is therefore RECOMMENDED that
the Transport Services API and the Transport Services implementation the Transport Services API and the Transport Services implementation
permit more specialized protocol features to be used. permit more specialized protocol features to be used.
skipping to change at page 27, line 10 skipping to change at page 27, line 10
* Cached State: The state and history that the implementation keeps * Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used for each set of associated Endpoints that have been used
previously. This can include DNS results, TLS session state, previously. This can include DNS results, TLS session state,
previous success and quality of transport protocols over certain previous success and quality of transport protocols over certain
paths, as well as other information. This caching does not imply paths, as well as other information. This caching does not imply
that the same decisions are necessarily made for subsequent that the same decisions are necessarily made for subsequent
connections, rather, it means that cached state is used by the connections, rather, it means that cached state is used by the
Transport Services architecture to inform functions such as Transport Services architecture to inform functions such as
choosing the candidates to be raced, selecting appropriate choosing the candidates to be raced, selecting appropriate
transport parameters, etc. An application SHOULD NOT depend on transport parameters, etc. An application SHOULD NOT rely on
specific caching behaviour, instead it ought to explicitly request specific caching behaviour, instead it ought to explicitly request
any required or desired properties via the Transport Services API. any required or desired properties via the Transport Services API.
4.2.1. Candidate Gathering 4.2.1. Candidate Gathering
* Candidate Path Selection: Candidate Path Selection represents the * Candidate Path Selection: Candidate Path Selection represents the
act of choosing one or more paths that are available to use based act of choosing one or more paths that are available to use based
on the Selection Properties and any available Local and Remote on the Selection Properties and any available Local and Remote
Endpoints provided by the application, as well as the policies and Endpoints provided by the application, as well as the policies and
heuristics of a Transport Services implementation. heuristics of a Transport Services implementation.
skipping to change at page 30, line 8 skipping to change at page 30, line 8
research and innovation programme under grant agreements No. 644334 research and innovation programme under grant agreements No. 644334
(NEAT), No. 688421 (MAMI) and No 815178 (5GENESIS). (NEAT), No. 688421 (MAMI) 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.
Thanks to Theresa Enghardt, Max Franke, Mirja Kuehlewind, Jonathan Thanks to Reese Enghardt, Max Franke, Mirja Kuehlewind, Jonathan
Lennox, and Michael Welzl for the discussions and feedback that Lennox, and Michael Welzl for the discussions and feedback that
helped shape the architecture described here. Particular thanks is helped shape the architecture described here. Particular thanks is
also due to Philipp S. Tiesel and Christopher A. Wood, who were also due to Philipp S. Tiesel and Christopher A. Wood, who were
both co-authors of this architecture specification as it progressed both co-authors of this architecture specification as it progressed
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
skipping to change at page 30, line 36 skipping to change at page 30, line 36
[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, R., 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-14, Work in Progress, Internet-Draft, draft-ietf-taps-impl-15,
20 October 2022, <https://datatracker.ietf.org/doc/html/ 9 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-taps-impl-14>. draft-ietf-taps-impl-15>.
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
K├╝hlewind, 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-18, 24 October 2022, taps-interface-19, 9 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps- <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
interface-18>. interface-19>.
[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.
[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>.
 End of changes. 15 change blocks. 
17 lines changed or deleted 18 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/