--- 1/draft-ietf-taps-arch-09.txt 2021-04-30 11:13:13.971828557 -0700 +++ 2/draft-ietf-taps-arch-10.txt 2021-04-30 11:13:14.031830036 -0700 @@ -1,29 +1,29 @@ TAPS Working Group T. Pauly, Ed. Internet-Draft Apple Inc. Intended status: Standards Track B. Trammell, Ed. -Expires: 6 May 2021 Google Switzerland GmbH +Expires: 1 November 2021 Google Switzerland GmbH A. Brunstrom Karlstad University G. Fairhurst University of Aberdeen C. Perkins University of Glasgow P. Tiesel - TU Berlin + SAP SE C.A. Wood Cloudflare - 2 November 2020 + 30 April 2021 An Architecture for Transport Services - draft-ietf-taps-arch-09 + draft-ietf-taps-arch-10 Abstract This document describes an architecture for exposing transport protocol features to applications for network communication, the Transport Services architecture. The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern. It uses messages for representing data transfer to applications, and it describes how implementations can use multiple IP addresses, multiple protocols, and multiple paths, and @@ -38,25 +38,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. @@ -82,28 +82,28 @@ 4.1.2. Connections and Related Objects . . . . . . . . . . . 15 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 16 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 17 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 18 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 19 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 20 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 20 4.2. Transport Services Implementation Concepts . . . . . . . 21 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 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 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Many application programming interfaces (APIs) to perform transport networking have been deployed, perhaps the most widely known and imitated being the BSD Socket [POSIX] interface (Socket API). The naming of objects and functions across these APIs is not consistent, and varies depending on the protocol being used. For example, sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and @@ -890,25 +890,26 @@ Properties when sending.) * Abort: The action the application takes on a Connection to indicate a Close and also indicate that the Transport Services system should not attempt to deliver any outstanding data. This is intended for immediate termination of a connection, without cleaning up state. 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 within the same Connection Group are allowed to be multiplexed - together. An application can explicitly define Connection Groups to - control caching boundaries, as discussed in Section 4.2.3. + together. While Connection Groups are managed by the transport + system, an application can define Connection Contexts to control + caching boundaries, as discussed in Section 4.2.3. 4.2. Transport Services Implementation Concepts This section defines the set of objects used internally to a system or library to implement the functionality needed to provide a transport service across a network, as required by the abstract interface. * Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as @@ -986,21 +987,21 @@ addresses and DNS servers, attempts across different Paths will perform separate DNS resolution steps, which can lead to further racing of the resolved Remote Endpoints. * Remote Endpoint Racing: Remote Endpoint Racing is the act of attempting to establish, or scheduling attempts to establish, multiple Protocol Stacks that differ based on the specific representation of the Remote Endpoint, such as a particular IP 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 protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application). This provides efficiency and convenience for the application, since the Transport Services implementation can automatically optimize behavior. There are several reasons, however, that an application might want to explicitly isolate some Connections. These reasons include: @@ -1011,31 +1012,25 @@ * Privacy concerns about allowing Connections to multiplex together, which can tell a Remote Endpoint that all of the Connections are coming from the same application (for example, when Connections are multiplexed HTTP/2 or QUIC streams). * Performance concerns about Connections introducing head-of-line blocking due to multiplexing or needing to share state on a single thread. 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 - Connection Groups with separate caches for different tabs in the + Connection Contexts with separate caches for different tabs in the 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 RFC-EDITOR: Please remove this section before publication. This document has no actions for IANA. 6. Security Considerations The Transport Services architecture does not recommend use of specific security protocols or algorithms. Its goal is to offer ease @@ -1086,50 +1081,49 @@ Sciences Research Council under grant EP/R04144X/1. Thanks to Theresa Enghardt, Max Franke, Mirja Kuehlewind, Jonathan Lennox, and Michael Welzl for the discussions and feedback that helped shape the architecture described here. Thanks as well to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for their implementation and design efforts, including Happy Eyeballs, that heavily influenced this work. 8. References - 8.1. Normative References [I-D.ietf-taps-interface] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., - Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. - Pauly, "An Abstract Application Layer Interface to - Transport Services", Work in Progress, Internet-Draft, - draft-ietf-taps-interface-09, 27 July 2020, - . + Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., Pauly, + T., and K. Rose, "An Abstract Application Layer Interface + to Transport Services", Work in Progress, Internet-Draft, + draft-ietf-taps-interface-12, 9 April 2021, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [I-D.ietf-taps-impl] Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., Jones, T., Tiesel, P., Perkins, C., and M. Welzl, "Implementing Interfaces to Transport Services", Work in - Progress, Internet-Draft, draft-ietf-taps-impl-07, 13 July - 2020, . + Progress, Internet-Draft, draft-ietf-taps-impl-08, 2 + November 2020, . [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open group Technical Standard: Base Specifications, Issue 7", 2008. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . @@ -1214,26 +1207,27 @@ Aberdeen, AB24 3UE Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/ Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom + Email: csp@csperkins.org Philipp S. Tiesel - TU Berlin - Einsteinufer 25 - 10587 Berlin + SAP SE + Konrad-Zuse-Ring 10 + 14469 Potsdam Germany Email: philipp@tiesel.net Christopher A. Wood Cloudflare 101 Townsend St San Francisco, United States of America