draft-ietf-taps-arch-13.txt		draft-ietf-taps-arch-14.txt
	TAPS Working Group T. Pauly, Ed.		TAPS Working Group T. Pauly, Ed.
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Standards Track B. Trammell, Ed.		Intended status: Standards Track B. Trammell, Ed.
	Expires: 29 December 2022 Google Switzerland GmbH		Expires: 31 March 2023 Google Switzerland GmbH
	A. Brunstrom		A. Brunstrom
	Karlstad University		Karlstad University
	G. Fairhurst		G. Fairhurst
	University of Aberdeen		University of Aberdeen
	C. Perkins		C. Perkins
	University of Glasgow		University of Glasgow
	27 June 2022		27 September 2022
	An Architecture for Transport Services		An Architecture for Transport Services
	draft-ietf-taps-arch-13		draft-ietf-taps-arch-14
	Abstract		Abstract
	This document describes an architecture for exposing transport		This document describes an architecture for exposing transport
	protocol features to applications for network communication, a		protocol features to applications for network communication, a
	Transport Services system. The Transport Services Application		Transport Services system. The Transport Services Application
	Programming Interface (API) is based on an asynchronous, event-driven		Programming Interface (API) is based on an asynchronous, event-driven
	interaction pattern. This API uses messages for representing data		interaction pattern. This API uses messages for representing data
	transfer to applications, and describes how implementations can use		transfer to applications, and describes how implementations can use
	multiple IP addresses, multiple protocols, and multiple paths, and		multiple IP addresses, multiple protocols, and multiple paths, and
	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 29 December 2022.		This Internet-Draft will expire on 31 March 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	and changes in the available network links, which were not previously		and changes in the available network links, which were not previously
	made explicit in the Socket API.		made explicit in the Socket API.
	Using asynchronous events allows for a more natural interaction model		Using asynchronous events allows for a more natural interaction model
	when establishing connections and transferring data. Events in time		when establishing connections and transferring data. Events in time
	more closely reflect the nature of interactions over networks, as		more closely reflect the nature of interactions over networks, as
	opposed to how the Socket API represent network resources as file		opposed to how the Socket API represent network resources as file
	system objects that may be temporarily unavailable.		system objects that may be temporarily unavailable.
	Separate from events, callbacks are also provided for asynchronous		Separate from events, callbacks are also provided for asynchronous
	interactions with the API not directly related to events on the		interactions with the Transport Services API that are not directly
	network or network interfaces.		related to events on the network or network interfaces.
	2.2. Data Transfer Using Messages		2.2. Data Transfer Using Messages
	The Socket API provides a message interface for datagram protocols		The Socket API provides a message interface for datagram protocols
	like UDP, but provides an unstructured stream abstraction for TCP.		like UDP, but provides an unstructured stream abstraction for TCP.
	While TCP has the ability to send and receive data as a byte-stream,		While TCP has the ability to send and receive data as a byte-stream,
	most applications need to interpret structure within this byte-		most applications need to interpret structure within this byte-
	stream. For example, HTTP/1.1 uses character delimiters to segment		stream. For example, HTTP/1.1 uses character delimiters to segment
	messages over a byte-stream [RFC7230]; TLS record headers carry a		messages over a byte-stream [RFC7230]; TLS record headers carry a
	version, content type, and length [RFC8446]; and HTTP/2 uses frames		version, content type, and length [RFC8446]; and HTTP/2 uses frames
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	using a specific protocol, and not when using others. For example,		using a specific protocol, and not when using others. For example,
	if an application is using TCP, it could require control over the		if an application is using TCP, it could require control over the
	User Timeout Option for TCP; these options would not take effect for		User Timeout Option for TCP; these options would not take effect for
	other transport protocols. In such cases, the API ought to expose		other transport protocols. In such cases, the API ought to expose
	the features in such a way that they take effect when a particular		the features in such a way that they take effect when a particular
	protocol is selected, but do not imply that only that protocol could		protocol is selected, but do not imply that only that protocol could
	be used. For example, if the API allows an application to specify a		be used. For example, if the API allows an application to specify a
	preference to use the User Timeout Option, communication would not		preference to use the User Timeout Option, communication would not
	fail when a protocol such as QUIC is selected.		fail when a protocol such as QUIC is selected.
	Other specialized features, however, can be strictly required by an		Other specialized features, however, can also be strictly required by
	application and thus constrain the set of protocols that can be used.		an application and thus further constrain the set of protocols that
	For example, if an application requires support for automatic		can be used. For example, if an application requires support for
	handover or failover for a connection, only protocol stacks that		automatic handover or failover for a connection, only protocol stacks
	provide this feature are eligible to be used, e.g., protocol stacks		that provide this feature are eligible to be used, e.g., protocol
	that include a multipath protocol or a protocol that supports		stacks that include a multipath protocol or a protocol that supports
	connection migration. A Transport Services API needs to allow		connection migration. A Transport Services API needs to allow
	applications to define such requirements and constrain the options		applications to define such requirements and constrain the options
	available to a Transport Services implementation. Since such options		available to a Transport Services implementation. Since such options
	are not part of the core/common features, it will generally be simple		are not part of the core/common features, it will generally be simple
	for an application to modify its set of constraints and change the		for an application to modify its set of constraints and change the
	set of allowable protocol features without changing the core		set of allowable protocol features without changing the core
	implementation.		implementation.
	3.3. Select Equivalent Protocol Stacks		3.3. Select Equivalent Protocol Stacks
	skipping to change at page 15, line 36 ¶		skipping to change at page 15, line 36 ¶
	* Establishment (Section 4.1.4) focuses on the actions that an		* Establishment (Section 4.1.4) focuses on the actions that an
	application takes on the connection objects to prepare for data		application takes on the connection objects to prepare for data
	transfer.		transfer.
	* Data Transfer (Section 4.1.5) consists of how an application		* Data Transfer (Section 4.1.5) consists of how an application
	represents the data to be sent and received, the functions		represents the data to be sent and received, the functions
	required to send and receive that data, and how the application is		required to send and receive that data, and how the application is
	notified of the status of its data transfer.		notified of the status of its data transfer.
	* Event Handling (Section 4.1.6) defines categories of notifications		* Event Handling (Section 4.1.6) defines categories of notifications
	which an application can receive during the lifetime of transport		that an application can receive during the lifetime of transport
	objects. Events also provide opportunities for the application to		objects. Events also provide opportunities for the application to
	interact with the underlying transport by querying state or		interact with the underlying transport by querying state or
	updating maintenance options.		updating maintenance options.
	* Termination (Section 4.1.7) focuses on the methods by which data		* Termination (Section 4.1.7) focuses on the methods by which data
	transmission is stopped, and state is torn down in the transport.		transmission is stopped, and state is torn down in the transport.
	The diagram below provides a high-level view of the actions and		The diagram below provides a high-level view of the actions and
	events during the lifetime of a Connection object. Note that some		events during the lifetime of a Connection object. Note that some
	actions are alternatives (e.g., whether to initiate a connection or		actions are alternatives (e.g., whether to initiate a connection or
	skipping to change at page 17, line 44 ¶		skipping to change at page 17, line 44 ¶
	* Connection: A Connection object represents one or more active		* Connection: A Connection object represents one or more active
	transport protocol instances that can send and/or receive Messages		transport protocol instances that can send and/or receive Messages
	between Local and Remote Endpoints. It is an abstraction that		between Local and Remote Endpoints. It is an abstraction that
	represents the communication. The Connection object holds state		represents the communication. The Connection object holds state
	pertaining to the underlying transport protocol instances and any		pertaining to the underlying transport protocol instances and any
	ongoing data transfers. For example, an active Connection can		ongoing data transfers. For example, an active Connection can
	represent a connection-oriented protocol such as TCP, or can		represent a connection-oriented protocol such as TCP, or can
	represent a fully-specified 5-tuple for a connectionless protocol		represent a fully-specified 5-tuple for a connectionless protocol
	such as UDP, where the Connection remains an abstraction at the		such as UDP, where the Connection remains an abstraction at the
	end points. It can also represent a pool of transport protocol		endpoints. It can also represent a pool of transport protocol
	instances, e.g., a set of TCP and QUIC connections to equivalent		instances, e.g., a set of TCP and QUIC connections to equivalent
	endpoints, or a stream of a multi-streaming transport protocol		endpoints, or a stream of a multi-streaming transport protocol
	instance. Connections can be created from a Preconnection or by a		instance. Connections can be created from a Preconnection or by a
	Listener.		Listener.
	* Listener: A Listener object accepts incoming transport protocol		* Listener: A Listener object accepts incoming transport protocol
	connections from Remote Endpoints and generates corresponding		connections from Remote Endpoints and generates corresponding
	Connection objects. It is created from a Preconnection object		Connection objects. It is created from a Preconnection object
	that specifies the type of incoming Connections it will accept.		that specifies the type of incoming Connections it will accept.
	skipping to change at page 22, line 20 ¶		skipping to change at page 22, line 20 ¶
	While Connection Groups are managed by the Transport Services system,		While Connection Groups are managed by the Transport Services system,
	an application can define Connection Contexts to control caching		an application can define Connection Contexts to control caching
	boundaries, as discussed in Section 4.2.3.		boundaries, as discussed in Section 4.2.3.
	4.2. Transport Services Implementation		4.2. Transport Services Implementation
	This section defines the key concepts of the Transport Services		This section defines the key concepts of the Transport Services
	architecture.		architecture.
	* Transport Service implementaion: This consists of all objects and		* Transport Service implementation: This consists of all objects and
	protocol instances used internally to a system or library to		protocol instances used internally to a system or library to
	implement the functionality needed to provide a transport service		implement the functionality needed to provide a transport service
	across a network, as required by the abstract interface.		across a network, as required by the abstract interface.
	* Transport Service system: This consists of the Transport Service		* Transport Service system: This consists of the Transport Service
	implementaion and the Transport Services API.		implementation and the Transport Services API.
	* Path: Represents an available set of properties that a local		* Path: Represents an available set of properties that a Local
	endpoint can use to communicate with a Remote Endpoint, such as		Endpoint can use to communicate with a Remote Endpoint, such as
	routes, addresses, and physical and virtual network interfaces.		routes, addresses, and physical and virtual network interfaces.
	* Protocol Instance: A single instance of one protocol, including		* Protocol Instance: A single instance of one protocol, including
	any state necessary to establish connectivity or send and receive		any state necessary to establish connectivity or send and receive
	Messages.		Messages.
	* Protocol Stack: A set of Protocol Instances (including relevant		* Protocol Stack: A set of Protocol Instances (including relevant
	application, security, transport, or Internet protocols) that are		application, security, transport, or Internet protocols) that are
	used together to establish connectivity or send and receive		used together to establish connectivity or send and receive
	Messages. A single stack can be simple (a single transport		Messages. A single stack can be simple (a single transport
	skipping to change at page 24, line 21 ¶		skipping to change at page 24, line 21 ¶
	racing of the resolved Remote Endpoints.		racing of the resolved Remote Endpoints.
	* Remote Endpoint Racing: Remote Endpoint Racing is the act of		* Remote Endpoint Racing: Remote Endpoint Racing is the act of
	attempting to establish, or scheduling attempts to establish,		attempting to establish, or scheduling attempts to establish,
	multiple Protocol Stacks that differ based on the specific		multiple Protocol Stacks that differ based on the specific
	representation of the Remote Endpoint, such as a particular IP		representation of the Remote Endpoint, such as a particular IP
	address that was resolved from a DNS hostname.		address that was resolved from a DNS hostname.
	4.2.3. Separating Connection Contexts		4.2.3. Separating Connection Contexts
	By default, stored properties of the implementation, such as cached		A Transport Services implementation can by default share stored
	protocol state, cached path state, and heuristics, may be shared		properties across Connections within an application, such as cached
	(e.g. across multiple connections in an application). This provides		protocol state, cached path state, and heuristics. This provides
	efficiency and convenience for the application, since the Transport		efficiency and convenience for the application, since the Transport
	Services system can automatically optimize behavior.		Services system can automatically optimize behavior.
	The Transport Services API can allow applications to explicitly		The Transport Services API can allow applications to explicitly
	define Connection Contexts that force separation of Cached State and		define Connection Contexts that force separation of Cached State and
	Protocol Stacks. For example, a web browser application could use		Protocol Stacks. For example, a web browser application could use
	Connection Contexts with separate caches when implementing different		Connection Contexts with separate caches when implementing different
	tabs. Possible reasons to isolate Connections using separate		tabs. Possible reasons to isolate Connections using separate
	Connection Contexts include:		Connection Contexts include:
	skipping to change at page 26, line 33 ¶		skipping to change at page 26, line 33 ¶
	through the TAPS working group. Thanks as well to Stuart Cheshire,		through the TAPS working group. Thanks as well to Stuart Cheshire,
	Josh Graessley, David Schinazi, and Eric Kinnear for their		Josh Graessley, David Schinazi, and Eric Kinnear for their
	implementation and design efforts, including Happy Eyeballs, that		implementation and design efforts, including Happy Eyeballs, that
	heavily influenced this work.		heavily influenced this work.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-taps-interface]		[I-D.ietf-taps-interface]
	Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,		Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
	Kuehlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,		Kühlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
	"An Abstract Application Layer Interface to Transport		"An Abstract Application Layer Interface to Transport
	Services", Work in Progress, Internet-Draft, draft-ietf-		Services", Work in Progress, Internet-Draft, draft-ietf-
	taps-interface-15, 7 March 2022,		taps-interface-17, 27 September 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-taps-		<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
	interface-15>.		interface-17>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-taps-impl]		[I-D.ietf-taps-impl]
	Brunstrom, A., Pauly, T., Enghardt, T., Tiesel, P. S., and		Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and
	M. Welzl, "Implementing Interfaces to Transport Services",		M. Welzl, "Implementing Interfaces to Transport Services",
	Work in Progress, Internet-Draft, draft-ietf-taps-impl-12,		Work in Progress, Internet-Draft, draft-ietf-taps-impl-13,
	7 March 2022, <https://datatracker.ietf.org/doc/html/		31 August 2022, <https://datatracker.ietf.org/doc/html/
	draft-ietf-taps-impl-12>.		draft-ietf-taps-impl-13>.
	[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology		[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
	-- Portable Operating System Interface (POSIX). Open		-- Portable Operating System Interface (POSIX). Open
	group Technical Standard: Base Specifications, Issue 7",		group Technical Standard: Base Specifications, Issue 7",
	2008.		2008.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		DOI 10.17487/RFC0793, September 1981,
	<https://www.rfc-editor.org/rfc/rfc793>.		<https://www.rfc-editor.org/rfc/rfc793>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/rfc/rfc6265>.		<https://www.rfc-editor.org/rfc/rfc6265>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/rfc/rfc7230>.		<https://www.rfc-editor.org/rfc/rfc7230>.
End of changes. 18 change blocks.
	31 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/