--- 1/draft-ietf-taps-impl-00.txt 2018-07-01 13:13:09.301176569 -0700 +++ 2/draft-ietf-taps-impl-01.txt 2018-07-01 13:13:09.377178415 -0700 @@ -1,55 +1,55 @@ TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. -Expires: November 26, 2018 Apple Inc. +Expires: January 2, 2019 Apple Inc. T. Enghardt TU Berlin K-J. Grinnemo Karlstad University T. Jones University of Aberdeen P. Tiesel TU Berlin C. Perkins University of Glasgow M. Welzl University of Oslo - May 25, 2018 + July 01, 2018 Implementing Interfaces to Transport Services - draft-ietf-taps-impl-00 + draft-ietf-taps-impl-01 Abstract - The Transport Services architecture [I-D.pauly-taps-arch] defines a + The Transport Services architecture [I-D.ietf-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 November 26, 2018. + This Internet-Draft will expire on January 2, 2019. Copyright Notice Copyright (c) 2018 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 @@ -112,34 +112,34 @@ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 14.1. Normative References . . . . . . . . . . . . . . . . . . 33 14.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. Additional Properties . . . . . . . . . . . . . . . 34 A.1. Properties Affecting Sorting of Branches . . . . . . . . 35 A.2. Send Parameters . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction - The Transport Services architecture [I-D.pauly-taps-arch] defines a + The Transport Services architecture [I-D.ietf-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. The interface such a system exposes to applications is - defined as the Transport Services API [I-D.trammell-taps-interface]. + defined as the Transport Services API [I-D.ietf-taps-interface]. This API is designed to be generic across multiple transport protocols and sets of protocols features. This document serves as a guide to implementation on how to build a system that provides a Transport Services API. It is the job of an implementation of a Transport Services system to turn the requests of an application into decisions on how to establish connections, and how to transfer data over those connections once established. The terminology used in this document is based on the Architecture - [I-D.pauly-taps-arch]. + [I-D.ietf-taps-arch]. 2. Implementing Basic Objects The basic objects that are exposed to applications for Transport Services are the Preconnection, the bundle of properties that describes the application constraints on the transport; the Connection, the basic object that represents a flow of data in either direction between the Local and Remote Endpoints; and the Listener, a passive waiting object that delivers new Connections. @@ -171,21 +171,21 @@ 3. Implementing Pre-Establishment During pre-establishment the application specifies the Endpoints to be used for communication as well as its preferences regarding Protocol and Path Selection. The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment. For Protocol and Path Selection Properties that are not provided by the application, the implementation must use the default values specified in the Transport Services API - ([I-D.trammell-taps-interface]). + ([I-D.ietf-taps-interface]). 3.1. Configuration-time errors The transport system should have a list of supported protocols available, which each have transport features reflecting the capabilities of the protocol. Once an application specifies its Transport Parameters, the transport system should match the required and prohibited properties against the transport features of the available protocols. @@ -538,21 +538,21 @@ resolution and DNS hostname resolution. 4.3. Sorting Branches Implementations should sort the branches of the tree of connection options in order of their preference rank. Leaf nodes on branches with higher rankings represent connection attempts that will be raced first. Implementations should order the branches to reflect the preferences expressed by the application for its new connection, including Protocol and Path Selection Properties, which are specified - in [I-D.trammell-taps-interface]. + in [I-D.ietf-taps-interface]. In addition to the properties provided by the application, an implementation may include additional criteria such as cached performance estimates, see Section 8.2, or system policy, see Section 3.2, in the ranking. Two examples of how the Protocol and Path Selection Properties may be used to sort branches are provided below: o Interface Type: If the application specifies an interface type to be preferred or avoided, implementations should rank paths @@ -1515,37 +1515,37 @@ Sciences Research Council under grant EP/R04144X/1. 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. 14. References 14.1. Normative References - [I-D.ietf-taps-minset] - Welzl, M. and S. Gjessing, "A Minimal Set of Transport - Services for TAPS Systems", draft-ietf-taps-minset-03 - (work in progress), March 2018. - - [I-D.pauly-taps-arch] + [I-D.ietf-taps-arch] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Perkins, C., Tiesel, P., and C. Wood, "An Architecture for - Transport Services", draft-pauly-taps-arch-00 (work in - progress), February 2018. + Transport Services", draft-ietf-taps-arch-00 (work in + progress), April 2018. - [I-D.trammell-taps-interface] + [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-trammell-taps-interface-00 (work in - progress), March 2018. + Services", draft-ietf-taps-interface-00 (work in + progress), April 2018. + + [I-D.ietf-taps-minset] + Welzl, M. and S. Gjessing, "A Minimal Set of Transport + Services for End Systems", draft-ietf-taps-minset-04 (work + in progress), June 2018. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . @@ -1573,22 +1573,22 @@ [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . 14.2. Informative References [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", draft-ietf-quic-transport-12 (work - in progress), May 2018. + and Secure Transport", draft-ietf-quic-transport-13 (work + in progress), June 2018. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-28 (work in progress), March 2018. [NEAT-flow-mapping] "Transparent Flow Mapping for NEAT (in Workshop on Future of Internet Transport (FIT 2017))", n.d..