draft-ietf-taps-impl-01.txt   draft-ietf-taps-impl-02.txt 
TAPS Working Group A. Brunstrom, Ed. TAPS Working Group A. Brunstrom, Ed.
Internet-Draft Karlstad University Internet-Draft Karlstad University
Intended status: Informational T. Pauly, Ed. Intended status: Informational T. Pauly, Ed.
Expires: January 2, 2019 Apple Inc. Expires: April 25, 2019 Apple Inc.
T. Enghardt T. Enghardt
TU Berlin TU Berlin
K-J. Grinnemo K-J. Grinnemo
Karlstad University Karlstad University
T. Jones T. Jones
University of Aberdeen University of Aberdeen
P. Tiesel P. Tiesel
TU Berlin TU Berlin
C. Perkins C. Perkins
University of Glasgow University of Glasgow
M. Welzl M. Welzl
University of Oslo University of Oslo
July 01, 2018 October 22, 2018
Implementing Interfaces to Transport Services Implementing Interfaces to Transport Services
draft-ietf-taps-impl-01 draft-ietf-taps-impl-02
Abstract Abstract
The Transport Services architecture [I-D.ietf-taps-arch] defines a The Transport Services architecture [I-D.ietf-taps-arch] defines a
system that allows applications to use transport networking protocols system that allows applications to use transport networking protocols
flexibly. This document serves as a guide to implementation on how flexibly. This document serves as a guide to implementation on how
to build such a system. to build such a system.
Status of This Memo Status of This Memo
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 2, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 35 skipping to change at page 6, line 35
application expresses intent to communicate with a remote endpoint by application expresses intent to communicate with a remote endpoint by
calling Initiate. (At this point, any constraints or requirements calling Initiate. (At this point, any constraints or requirements
the application may have on the connection are available from pre- the application may have on the connection are available from pre-
establishment.) The process can be considered complete once there is establishment.) The process can be considered complete once there is
at least one Protocol Stack that has completed any required setup to at least one Protocol Stack that has completed any required setup to
the point that it can transmit and receive the application's data. the point that it can transmit and receive the application's data.
Connection establishment is divided into two top-level steps: Connection establishment is divided into two top-level steps:
Candidate Gathering, to identify the paths, protocols, and endpoints Candidate Gathering, to identify the paths, protocols, and endpoints
to use, and Candidate Racing, in which the necessary protocol 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 The most simple example of this process might involve identifying the
single IP address to which the implementation wishes to connect, single IP address to which the implementation wishes to connect,
using the system's current default interface or path, and starting a using the system's current default interface or path, and starting a
TCP handshake to establish a stream to the specified IP address. TCP handshake to establish a stream to the specified IP address.
However, each step may also vary depending on the requirements of the However, each step may also vary depending on the requirements of the
connection: if the endpoint is defined as a hostname and port, then connection: if the endpoint is defined as a hostname and port, then
there may be multiple resolved addresses that are available; there there may be multiple resolved addresses that are available; there
may also be multiple interfaces or paths available, other than the may also be multiple interfaces or paths available, other than the
default system interface; and some protocols may not need any default system interface; and some protocols may not need any
skipping to change at page 19, line 35 skipping to change at page 19, line 35
datagram. Generally, these will be short enough that sending and datagram. Generally, these will be short enough that sending and
receiving will always use a complete Message. receiving will always use a complete Message.
For protocols that expose byte-streams, the only delineation provided For protocols that expose byte-streams, the only delineation provided
by the protocol is the end of the stream in a given direction. Each 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 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 direction. These Messages may be quite long, in which case they can
be sent in multiple parts. be sent in multiple parts.
Protocols that provide the framing (such as length-value protocols, 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 longer than a traditional packet datagram. Each Message for framing
protocols corresponds to a single frame, which may be sent either as protocols corresponds to a single frame, which may be sent either as
a complete Message, or in multiple parts. a complete Message, or in multiple parts.
5.1.1. Sending Messages 5.1.1. Sending Messages
The effect of the application sending a Message is determined by the The effect of the application sending a Message is determined by the
top-level protocol in the established Protocol Stack. That is, if top-level protocol in the established Protocol Stack. That is, if
the top-level protocol provides an abstraction of framed messages the top-level protocol provides an abstraction of framed messages
over a connection, the receiving application will be able to obtain over a connection, the receiving application will be able to obtain
skipping to change at page 24, line 49 skipping to change at page 24, line 49
Implementing a protocol independent transport system means that the Implementing a protocol independent transport system means that the
exposed semantics must be the strictest subset of the semantics of exposed semantics must be the strictest subset of the semantics of
all supported protocols. Hence, as is common with all reliable all supported protocols. Hence, as is common with all reliable
transport protocols, after a Close action, the application can expect transport protocols, after a Close action, the application can expect
to have its reliability requirements honored regarding the data it to have its reliability requirements honored regarding the data it
has given to the Transport System, but it cannot expect to be able to has given to the Transport System, but it cannot expect to be able to
read any more data after calling Close. read any more data after calling Close.
Abort differs from Close only in that no guarantees are given 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. System before calling Abort.
As explained in section Section 4.6, when a new stream is multiplexed As explained in Section 4.6, when a new stream is multiplexed on an
on an already existing connection of a Transport Protocol Instance, already existing connection of a Transport Protocol Instance, there
there is no need for a connection establishment procedure. Because is no need for a connection establishment procedure. Because the
the Connections that are offered by the Transport System can be Connections that are offered by the Transport System can be
implemented as streams that are multiplexed on a transport protocol's implemented as streams that are multiplexed on a transport protocol's
connection, it can therefore not be guaranteed that one Endpoint's connection, it can therefore not be guaranteed that one Endpoint's
Initiate action provokes a ConnectionReceived event at its peer. Initiate action provokes a ConnectionReceived event at its peer.
For Close (provoking a Finished event) and Abort (provoking a For Close (provoking a Finished event) and Abort (provoking a
ConnectionError event), the same logic applies: while it is desirable ConnectionError event), the same logic applies: while it is desirable
to be informed when a peer closes or aborts a Connection, whether to be informed when a peer closes or aborts a Connection, whether
this is possible depends on the underlying protocol, and no this is possible depends on the underlying protocol, and no
guarantees can be given. With SCTP, the transport system can use the guarantees can be given. With SCTP, the transport system can use the
stream reset procedure to cause a Finish event upon a Close action stream reset procedure to cause a Finish event upon a Close action
skipping to change at page 30, line 29 skipping to change at page 30, line 29
If NAT traversal is required, the process of gathering Local If NAT traversal is required, the process of gathering Local
Endpoints becomes broadly equivalent to the ICE candidate Endpoints becomes broadly equivalent to the ICE candidate
gathering phase [RFC5245]. The endpoint determines its server gathering phase [RFC5245]. The endpoint determines its server
reflexive Local Endpoints (i.e., the translated address of a 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 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 TURN server or other relay), for each interface and network
protocol. These are added to the set of candidate Local Endpoints protocol. These are added to the set of candidate Local Endpoints
for this connection. for this connection.
Gathering locals is primarily an endpoint local operation, Gathering Local Endpoints is primarily a local operation, although
although it might involve exchanges with a STUN server to derive it might involve exchanges with a STUN server to derive server
server reflexive locals, or with a TURN server or other relay to reflexive locals, or with a TURN server or other relay to derive
derive relayed locals. It does not involve communication with the relayed locals. It does not involve communication with the Remote
Remote Endpoint. Endpoint.
o Gathering Remote Endpoint Candidates o Gathering Remote Endpoint Candidates
The Remote Endpoint is typically a name that needs to be resolved The Remote Endpoint is typically a name that needs to be resolved
into a set of possible addresses that can be used for into a set of possible addresses that can be used for
communication. Resolving the Remote Endpoint is the process of communication. Resolving the Remote Endpoint is the process of
recursively performing such name lookups, until fully resolved, to recursively performing such name lookups, until fully resolved, to
return the set of candidates for the remote of this connection. return the set of candidates for the remote of this connection.
How this is done will depend on the type of the Remote Endpoint, How this is done will depend on the type of the Remote Endpoint,
skipping to change at page 33, line 16 skipping to change at page 33, line 16
Kinnear for their implementation and design efforts, including Happy Kinnear for their implementation and design efforts, including Happy
Eyeballs, that heavily influenced this work. Eyeballs, that heavily influenced this work.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", draft-ietf-taps-arch-00 (work in Transport Services", draft-ietf-taps-arch-01 (work in
progress), April 2018. progress), July 2018.
[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., and C. Wood, "An Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
Abstract Application Layer Interface to Transport Abstract Application Layer Interface to Transport
Services", draft-ietf-taps-interface-00 (work in Services", draft-ietf-taps-interface-01 (work in
progress), April 2018. progress), July 2018.
[I-D.ietf-taps-minset] [I-D.ietf-taps-minset]
Welzl, M. and S. Gjessing, "A Minimal Set of Transport Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", draft-ietf-taps-minset-04 (work Services for End Systems", draft-ietf-taps-minset-11 (work
in progress), June 2018. in progress), September 2018.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, Transmission Protocol (SCTP)", RFC 6458,
DOI 10.17487/RFC6458, December 2011, DOI 10.17487/RFC6458, December 2011,
<https://www.rfc-editor.org/info/rfc6458>. <https://www.rfc-editor.org/info/rfc6458>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
skipping to change at page 34, line 24 skipping to change at page 34, line 24
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-13 (work and Secure Transport", draft-ietf-quic-transport-15 (work
in progress), June 2018. in progress), October 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[NEAT-flow-mapping] [NEAT-flow-mapping]
"Transparent Flow Mapping for NEAT (in Workshop on Future "Transparent Flow Mapping for NEAT (in Workshop on Future
of Internet Transport (FIT 2017))", n.d.. of Internet Transport (FIT 2017))", n.d..
 End of changes. 13 change blocks. 
24 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/