--- 1/draft-ietf-taps-arch-03.txt 2019-07-08 11:13:15.218848280 -0700 +++ 2/draft-ietf-taps-arch-04.txt 2019-07-08 11:13:15.270849603 -0700 @@ -1,29 +1,29 @@ TAPS Working Group T. Pauly, Ed. Internet-Draft Apple Inc. Intended status: Standards Track B. Trammell, Ed. -Expires: September 12, 2019 Google +Expires: January 9, 2020 Google A. Brunstrom Karlstad University G. Fairhurst University of Aberdeen C. Perkins University of Glasgow P. Tiesel TU Berlin C. Wood Apple Inc. - March 11, 2019 + July 08, 2019 An Architecture for Transport Services - draft-ietf-taps-arch-03 + draft-ietf-taps-arch-04 Abstract This document provides an overview of the architecture of Transport Services, a model for exposing transport protocol features to applications for network communication. In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use @@ -39,21 +39,21 @@ 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 September 12, 2019. + This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 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 @@ -252,20 +252,24 @@ o the ability to provide control of reliability, choosing which messages to retransmit in the event of packet loss, and how best to make use of the data that arrived; o the ability to manage dependencies between messages, when the transport system could decide to not deliver a message, either following packet loss or because it has missed a deadline. In particular, this can avoid (re-)sending data that relies on a previous transmission that was never received. + o the ability to automatically assign messages and connections to + underlaying transport connections to utilize multi-streaming and + pooled connections. + Allowing applications to interact with messages is backwards- compatible with existings protocols and APIs, as it does not change the wire format of any protocol. Instead, it gives the protocol stack additional information to allow it to make better use of modern transport services, while simplifying the application's role in parsing data. 1.4. Flexibile Implementation Sockets, for protocols like TCP, are generally limited to connecting @@ -581,27 +585,30 @@ * Transport Properties: Transport Properties can be specified as part of a Preconnection to allow the application to configure the Transport System and express their requirements, prohibitions, and preferences. There are three kinds of Transport Properties: Selection Properties (Section 4.1.2), Connection Properties (Section 4.1.2), and Message Properties (Section 4.1.4). Message Properties can also be specified during data transfer to affect specific Messages. - o Connection: A Connection object represents an active transport - protocol instance that can send and/or receive Messages between - local and remote systems. It holds state pertaining to the - underlying transport protocol instance and any ongoing data - transfer. This represents, for example, an active connection in a - connection-oriented protocol such as TCP, or a fully-specified - 5-tuple for a connectionless protocol such as UDP. + o Connection: A Connection object represents one or more active + transport protocol instances that can send and/or receive Messages + between local and remote systems. It holds state pertaining to + the underlying transport protocol instances and any ongoing data + transfers. This represents, for example, an active connection in + a connection-oriented protocol such as TCP, or a fully-specified + 5-tuple for a connectionless protocol such as UDP. It can also + represent a pool of transport protocol instance, e.g., a set of + TCP and QUIC connections to equivalent endpoints, or a stream of a + multi-streaming transport protocol instance. o Listener: A Listener object accepts incoming transport protocol connections from remote systems and generates corresponding Connection objects. It is created from a Preconnection object that specifies the type of incoming connections it will accept. 4.1.2. Pre-Establishment o Endpoint: An Endpoint represents an identifier for one side of a transport connection. Endpoints can be Local Endpoints or Remote @@ -1002,28 +1009,28 @@ Thanks 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. 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", draft- - ietf-taps-impl-02 (work in progress), October 2018. + ietf-taps-impl-03 (work in progress), March 2019. [I-D.ietf-taps-interface] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An Abstract Application Layer Interface to Transport - Services", draft-ietf-taps-interface-02 (work in - progress), October 2018. + Services", draft-ietf-taps-interface-03 (work in + progress), March 2019. [I-D.ietf-taps-minset] Welzl, M. and S. Gjessing, "A Minimal Set of Transport Services for End Systems", draft-ietf-taps-minset-11 (work in progress), September 2018. [I-D.ietf-taps-transport-security] Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. Rose, "A Survey of Transport Security Protocols", draft- ietf-taps-transport-security-06 (work in progress), March @@ -1111,23 +1118,23 @@ Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Philipp S. Tiesel TU Berlin - Marchstrasse 23 + Einsteinufer 25 10587 Berlin Germany - Email: philipp@inet.tu-berlin.de + Email: philipp@tiesel.net Chris Wood Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: cawood@apple.com