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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/