draft-ietf-taps-arch-09.txt   draft-ietf-taps-arch-10.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: 6 May 2021 Google Switzerland GmbH Expires: 1 November 2021 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
P. Tiesel P. Tiesel
TU Berlin SAP SE
C.A. Wood C.A. Wood
Cloudflare Cloudflare
2 November 2020 30 April 2021
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-09 draft-ietf-taps-arch-10
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, the protocol features to applications for network communication, the
Transport Services architecture. The Transport Services Application Transport Services architecture. 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. It uses messages for representing data transfer interaction pattern. It uses messages for representing data transfer
to applications, and it describes how implementations can use to applications, and it 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 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 May 2021. This Internet-Draft will expire on 1 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 48 skipping to change at page 2, line 48
4.1.2. Connections and Related Objects . . . . . . . . . . . 15 4.1.2. Connections and Related Objects . . . . . . . . . . . 15
4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 16 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 16
4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 17 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 17
4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 18 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 18
4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 19 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 19
4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 20 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 20
4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 20 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 20
4.2. Transport Services Implementation Concepts . . . . . . . 21 4.2. Transport Services Implementation Concepts . . . . . . . 21
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 22 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 22
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22
4.2.3. Separating Connection Groups . . . . . . . . . . . . 23 4.2.3. Separating Connection Contexts . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Many application programming interfaces (APIs) to perform transport Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and networking have been deployed, perhaps the most widely known and
imitated being the BSD Socket [POSIX] interface (Socket API). The imitated being the BSD Socket [POSIX] interface (Socket API). The
naming of objects and functions across these APIs is not consistent, naming of objects and functions across these APIs is not consistent,
and varies depending on the protocol being used. For example, and varies depending on the protocol being used. For example,
sending and receiving streams of data is conceptually the same for sending and receiving streams of data is conceptually the same for
both an unencrypted Transmission Control Protocol (TCP) stream and both an unencrypted Transmission Control Protocol (TCP) stream and
skipping to change at page 20, line 42 skipping to change at page 20, line 42
Properties when sending.) Properties when sending.)
* Abort: The action the application takes on a Connection to * Abort: The action the application takes on a Connection to
indicate a Close and also indicate that the Transport Services indicate a Close and also indicate that the Transport Services
system should not attempt to deliver any outstanding data. This system should not attempt to deliver any outstanding data. This
is intended for immediate termination of a connection, without is intended for immediate termination of a connection, without
cleaning up state. cleaning up state.
4.1.8. Connection Groups 4.1.8. Connection Groups
A Connection Group is a set of Connections that share properties and A Connection Group is a set of Connections that shares properties and
caches. For multiplexing transport protocols, only Connections caches. For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed within the same Connection Group are allowed to be multiplexed
together. An application can explicitly define Connection Groups to together. While Connection Groups are managed by the transport
control caching boundaries, as discussed in Section 4.2.3. system, an application can define Connection Contexts to control
caching boundaries, as discussed in Section 4.2.3.
4.2. Transport Services Implementation Concepts 4.2. Transport Services Implementation Concepts
This section defines the set of objects used internally to a system This section defines the set of objects used internally to a system
or library to implement the functionality needed to provide a or library to implement the functionality needed to provide a
transport service across a network, as required by the abstract transport service across a network, as required by the abstract
interface. interface.
* Path: Represents an available set of properties that a local * Path: Represents an available set of properties that a local
system can use to communicate with a remote system, such as system can use to communicate with a remote system, such as
skipping to change at page 23, line 5 skipping to change at page 23, line 5
addresses and DNS servers, attempts across different Paths will addresses and DNS servers, attempts across different Paths will
perform separate DNS resolution steps, which can lead to further perform separate DNS resolution steps, which can lead to further
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 Groups 4.2.3. Separating Connection Contexts
By default, stored properties of the implementation, such as cached By default, stored properties of the implementation, such as cached
protocol state, cached path state, and heuristics, may be shared protocol state, cached path state, and heuristics, may be shared
(e.g. across multiple connections in an application). This provides (e.g. across multiple connections in an application). This provides
efficiency and convenience for the application, since the Transport efficiency and convenience for the application, since the Transport
Services implementation can automatically optimize behavior. Services implementation can automatically optimize behavior.
There are several reasons, however, that an application might want to There are several reasons, however, that an application might want to
explicitly isolate some Connections. These reasons include: explicitly isolate some Connections. These reasons include:
skipping to change at page 23, line 30 skipping to change at page 23, line 30
* Privacy concerns about allowing Connections to multiplex together, * Privacy concerns about allowing Connections to multiplex together,
which can tell a Remote Endpoint that all of the Connections are which can tell a Remote Endpoint that all of the Connections are
coming from the same application (for example, when Connections coming from the same application (for example, when Connections
are multiplexed HTTP/2 or QUIC streams). are multiplexed HTTP/2 or QUIC streams).
* Performance concerns about Connections introducing head-of-line * Performance concerns about Connections introducing head-of-line
blocking due to multiplexing or needing to share state on a single blocking due to multiplexing or needing to share state on a single
thread. thread.
The Transport Services API can allow applications to explicitly The Transport Services API can allow applications to explicitly
define Connection Groups 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 might use Protocol Stacks. For example, a web browser application might use
Connection Groups with separate caches for different tabs in the Connection Contexts with separate caches for different tabs in the
browser to decrease linkability. browser to decrease linkability.
The interface to specify a Connection Group can expose fine-grained
tuning for which properties and cached state is allowed to be shared
with other Connections. For example, an application might want to
allow sharing TCP Fast Open cookies across groups, but not TLS
session state.
5. IANA Considerations 5. 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.
6. Security Considerations 6. Security Considerations
The Transport Services architecture does not recommend use of The Transport Services architecture does not recommend use of
specific security protocols or algorithms. Its goal is to offer ease specific security protocols or algorithms. Its goal is to offer ease
skipping to change at page 25, line 16 skipping to change at page 25, line 4
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 Theresa 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. Thanks as well to helped shape the architecture described here. Thanks as well to
Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for
their implementation and design efforts, including Happy Eyeballs, their implementation and design efforts, including Happy Eyeballs,
that heavily influenced this work. that 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, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., Pauly,
Pauly, "An Abstract Application Layer Interface to T., and K. Rose, "An Abstract Application Layer Interface
Transport Services", Work in Progress, Internet-Draft, to Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-interface-09, 27 July 2020, draft-ietf-taps-interface-12, 9 April 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-taps- <https://www.ietf.org/internet-drafts/draft-ietf-taps-
interface-09.txt>. interface-12.txt>.
[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/info/rfc2119>. <https://www.rfc-editor.org/info/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/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/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., Grinnemo, K., Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Jones, T., Tiesel, P., Perkins, C., and M. Welzl, Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", Work in "Implementing Interfaces to Transport Services", Work in
Progress, Internet-Draft, draft-ietf-taps-impl-07, 13 July Progress, Internet-Draft, draft-ietf-taps-impl-08, 2
2020, <http://www.ietf.org/internet-drafts/draft-ietf- November 2020, <https://www.ietf.org/internet-drafts/
taps-impl-07.txt>. draft-ietf-taps-impl-08.txt>.
[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", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
skipping to change at page 28, line 4 skipping to change at page 27, line 41
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/ URI: http://www.erg.abdn.ac.uk/
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Philipp S. Tiesel Philipp S. Tiesel
TU Berlin SAP SE
Einsteinufer 25 Konrad-Zuse-Ring 10
10587 Berlin 14469 Potsdam
Germany Germany
Email: philipp@tiesel.net Email: philipp@tiesel.net
Christopher A. Wood Christopher A. Wood
Cloudflare Cloudflare
101 Townsend St 101 Townsend St
San Francisco, San Francisco,
United States of America United States of America
 End of changes. 21 change blocks. 
35 lines changed or deleted 30 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/