--- 1/draft-ietf-taps-impl-01.txt 2018-10-22 09:14:07.569965166 -0700 +++ 2/draft-ietf-taps-impl-02.txt 2018-10-22 09:14:07.645966966 -0700 @@ -1,31 +1,31 @@ TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. -Expires: January 2, 2019 Apple Inc. +Expires: April 25, 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 - July 01, 2018 + October 22, 2018 Implementing Interfaces to Transport Services - draft-ietf-taps-impl-01 + draft-ietf-taps-impl-02 Abstract 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 @@ -35,21 +35,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 January 2, 2019. + This Internet-Draft will expire on April 25, 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 @@ -261,21 +261,22 @@ application expresses intent to communicate with a remote endpoint by calling Initiate. (At this point, any constraints or requirements the application may have on the connection are available from pre- establishment.) The process can be considered complete once there is at least one Protocol Stack that has completed any required setup to the point that it can transmit and receive the application's data. Connection establishment is divided into two top-level steps: Candidate Gathering, to identify the paths, protocols, and endpoints to use, and Candidate Racing, in which the necessary protocol - handshakes are conducted in order to select which set to use. + handshakes are conducted so that the transport system can select + which set to use. The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect, using the system's current default interface or path, and starting a TCP handshake to establish a stream to the specified IP address. However, each step may also vary depending on the requirements of the connection: if the endpoint is defined as a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple interfaces or paths available, other than the default system interface; and some protocols may not need any @@ -876,21 +877,21 @@ datagram. Generally, these will be short enough that sending and receiving will always use a complete Message. For protocols that expose byte-streams, the only delineation provided by the protocol is the end of the stream in a given direction. Each Message in this case corresponds to the entire stream of bytes in a direction. These Messages may be quite long, in which case they can be sent in multiple parts. Protocols that provide the framing (such as length-value protocols, - or protocols that use delimeters) provide data boundaries that may be + or protocols that use delimiters) provide data boundaries that may be longer than a traditional packet datagram. Each Message for framing protocols corresponds to a single frame, which may be sent either as a complete Message, or in multiple parts. 5.1.1. Sending Messages The effect of the application sending a Message is determined by the top-level protocol in the established Protocol Stack. That is, if the top-level protocol provides an abstraction of framed messages over a connection, the receiving application will be able to obtain @@ -1125,27 +1126,27 @@ Implementing a protocol independent transport system means that the exposed semantics must be the strictest subset of the semantics of all supported protocols. Hence, as is common with all reliable transport protocols, after a Close action, the application can expect to have its reliability requirements honored regarding the data it has given to the Transport System, but it cannot expect to be able to read any more data after calling Close. Abort differs from Close only in that no guarantees are given - regarding data that the application has handed over to the Tranport + regarding data that the application has handed over to the Transport System before calling Abort. - As explained in section Section 4.6, when a new stream is multiplexed - on an already existing connection of a Transport Protocol Instance, - there is no need for a connection establishment procedure. Because - the Connections that are offered by the Transport System can be + As explained in Section 4.6, when a new stream is multiplexed on an + already existing connection of a Transport Protocol Instance, there + is no need for a connection establishment procedure. Because the + Connections that are offered by the Transport System can be implemented as streams that are multiplexed on a transport protocol's connection, it can therefore not be guaranteed that one Endpoint's Initiate action provokes a ConnectionReceived event at its peer. For Close (provoking a Finished event) and Abort (provoking a ConnectionError event), the same logic applies: while it is desirable to be informed when a peer closes or aborts a Connection, whether this is possible depends on the underlying protocol, and no guarantees can be given. With SCTP, the transport system can use the stream reset procedure to cause a Finish event upon a Close action @@ -1389,25 +1390,25 @@ If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering phase [RFC5245]. The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT) and relayed locals (e.g., via a TURN server or other relay), for each interface and network protocol. These are added to the set of candidate Local Endpoints for this connection. - Gathering locals is primarily an endpoint local operation, - although it might involve exchanges with a STUN server to derive - server reflexive locals, or with a TURN server or other relay to - derive relayed locals. It does not involve communication with the - Remote Endpoint. + Gathering Local Endpoints is primarily a local operation, although + it might involve exchanges with a STUN server to derive server + reflexive locals, or with a TURN server or other relay to derive + relayed locals. It does not involve communication with the Remote + Endpoint. o Gathering Remote Endpoint Candidates The Remote Endpoint is typically a name that needs to be resolved into a set of possible addresses that can be used for communication. Resolving the Remote Endpoint is the process of recursively performing such name lookups, until fully resolved, to return the set of candidates for the remote of this connection. How this is done will depend on the type of the Remote Endpoint, @@ -1518,34 +1519,34 @@ 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-arch] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Perkins, C., Tiesel, P., and C. Wood, "An Architecture for - Transport Services", draft-ietf-taps-arch-00 (work in - progress), April 2018. + Transport Services", draft-ietf-taps-arch-01 (work in + progress), July 2018. [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-00 (work in - progress), April 2018. + Services", draft-ietf-taps-interface-01 (work in + progress), July 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. + Services for End Systems", draft-ietf-taps-minset-11 (work + in progress), September 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 +1574,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-13 (work - in progress), June 2018. + and Secure Transport", draft-ietf-quic-transport-15 (work + in progress), October 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..