draft-ietf-taps-arch-16.txt		draft-ietf-taps-arch-17.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: 10 September 2023 Google Switzerland GmbH		Expires: 30 September 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
	9 March 2023		29 March 2023
	An Architecture for Transport Services		An Architecture for Transport Services
	draft-ietf-taps-arch-16		draft-ietf-taps-arch-17
	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 10 September 2023.		This Internet-Draft will expire on 30 September 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 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 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.4. Glossary of Key Terms		1.4. Glossary of Key Terms
	This subsection provides a glossary of key terms related to the		This subsection provides a glossary of key terms related to the
	Transport Services architecture.		Transport Services architecture. It provides a short description of
			key terms that are later defined in this document.
	* Application: An entity that uses the transport layer for end-to-		* Application: An entity that uses the transport layer for end-to-
	end delivery of data across the network [RFC8095].		end delivery of data across the network [RFC8095].
	* Cached State: The state and history that the implementation keeps		* Cached State: The state and history that the implementation keeps
	for each set of associated Endpoints that have been used		for each set of associated Endpoints that have been used
	previously.		previously.
	* Candidate Path: One path that is available to an application and		* Candidate Path: One path that is available to an application and
	conforms to the Selection Properties and System Policy during		conforms to the Selection Properties and System Policy during
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	* Framer: A data translation layer that can be added to a Connection		* Framer: A data translation layer that can be added to a Connection
	to define how application-layer Messages are transmitted over a		to define how application-layer Messages are transmitted over a
	Protocol Stack.		Protocol Stack.
	* Local Endpoint: A representation of the application's identifier		* Local Endpoint: A representation of the application's identifier
	for itself that it uses for a Connection.		for itself that it uses for a Connection.
	* Message: A unit of data that can be transferred between two		* Message: A unit of data that can be transferred between two
	Endpoints over a Connection.		Endpoints over a Connection.
	* Message Property: A property than can be used to specify details		* Message Property: A property that can be used to specify details
	about Message transmission, or obtain details about the		about Message transmission, or obtain details about the
	transmission after receiving a Message.		transmission after receiving a Message.
	* Parameter: A value passed between an application and a transport		* Parameter: A value passed between an application and a transport
	protocol by a primitive [RFC8303].		protocol by a primitive [RFC8303].
	* Path: A representation of an available set of properties that a		* Path: A representation of an available set of properties that a
	Local Endpoint can use to communicate with a Remote Endpoint.		Local Endpoint can use to communicate with a Remote Endpoint.
	* Peer: An endpoint application party to a Connection.		* Peer: An endpoint application party to a Connection.
	* Preconnection: an object that repesents a Connection that has not		* Preconnection: an object that represents a Connection that has not
	yet been established.		yet been established.
	* Preference: A preference to prohibit, avoid, ignore prefer or		* Preference: A preference to prohibit, avoid, ignore prefer or
	require a specific Transport Feature.		require a specific Transport Feature.
	* Primitive: A function call that is used to locally communicate		* Primitive: A function call that is used to locally communicate
	between an application and an endpoint, which is related to one or		between an application and an endpoint, which is related to one or
	more Transport Features [RFC8303].		more Transport Features [RFC8303].
	* Protocol Instance: A single instance of one protocol, including		* Protocol Instance: A single instance of one protocol, including
	skipping to change at page 9, line 34 ¶		skipping to change at page 9, line 34 ¶
	The Transport Services API [I-D.ietf-taps-interface] defines the		The Transport Services API [I-D.ietf-taps-interface] defines the
	interface for an application to create Connections and transfer data.		interface for an application to create Connections and transfer data.
	It combines interfaces for multiple interaction patterns into a		It combines interfaces for multiple interaction patterns into a
	unified whole. By combining name resolution with connection		unified whole. By combining name resolution with connection
	establishment and data transfer in a single API, it allows for more		establishment and data transfer in a single API, it allows for more
	flexible implementations to provide path and transport protocol		flexible implementations to provide path and transport protocol
	agility on the application's behalf.		agility on the application's behalf.
	The Transport Services implementation [I-D.ietf-taps-impl] implements		The Transport Services implementation [I-D.ietf-taps-impl] implements
	the transport layer protocols and other functions needed to send and		the transport layer protocols and other functions needed to send and
	receive data. It is is responsible for mapping the API to a specific		receive data. It is responsible for mapping the API to a specific
	available transport protocol stack and managing the available network		available transport protocol stack and managing the available network
	interfaces and paths.		interfaces and paths.
	There are key differences between the Transport Services architecture		There are key differences between the Transport Services architecture
	and the architecture of the Socket API: the API of the Transport		and the architecture of the Socket API: the API of the Transport
	Services architecture is asynchronous and event-driven; it uses		Services architecture is asynchronous and event-driven; it uses
	messages for representing data transfer to applications; and it		messages for representing data transfer to applications; and it
	describes how implementations can use multiple IP addresses, multiple		describes how implementations can use multiple IP addresses, multiple
	protocols, multiple paths, and provide multiple application streams.		protocols, multiple paths, and provide multiple application streams.
	skipping to change at page 10, line 26 ¶		skipping to change at page 10, line 26 ¶
	contain the data. Error handling is also asynchronous; a failure to		contain the data. Error handling is also asynchronous; a failure to
	send data results in an asynchronous error event.		send data results in an asynchronous error event.
	This API also delivers events regarding the lifetime of a connection		This API also delivers events regarding the lifetime of a connection
	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 represents 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 Transport Services API that are not directly		interactions with the Transport Services API that are not directly
	related to events on the 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.
	skipping to change at page 13, line 50 ¶		skipping to change at page 13, line 50 ¶
	not require reliability can function correctly when a protocol		not require reliability can function correctly when a protocol
	provides reliability, reliability ought to be enabled by default. As		provides reliability, reliability ought to be enabled by default. As
	another example, the default value for a Property regarding the		another example, the default value for a Property regarding the
	selection of network interfaces ought to permit as many interfaces as		selection of network interfaces ought to permit as many interfaces as
	possible.		possible.
	Applications using the Transport Services API are REQUIRED to be		Applications using the Transport Services API are REQUIRED to be
	robust to the automated selection provided by the Transport Services		robust to the automated selection provided by the Transport Services
	implementation. This automated selection is constrained by the		implementation. This automated selection is constrained by the
	properties and preferences expressed by the application and requires		properties and preferences expressed by the application and requires
	applications to explictly set properties that define any necssary		applications to explicitly set properties that define any necessary
	constraints on protocol, path, and interface selection.		constraints on protocol, path, and interface selection.
	3.2. Allow Access to Specialized Features		3.2. Allow Access to Specialized Features
	There are applications that will need to control fine-grained details		There are applications that will need to control fine-grained details
	of transport protocols to optimize their behavior and ensure		of transport protocols to optimize their behavior and ensure
	compatibility with remote systems. It is therefore RECOMMENDED that		compatibility with remote systems. It is therefore RECOMMENDED that
	the Transport Services API and the Transport Services implementation		the Transport Services API and the Transport Services implementation
	permit more specialized protocol features to be used.		permit more specialized protocol features to be used.
	skipping to change at page 27, line 10 ¶		skipping to change at page 27, line 10 ¶
	* Cached State: The state and history that the implementation keeps		* Cached State: The state and history that the implementation keeps
	for each set of associated Endpoints that have been used		for each set of associated Endpoints that have been used
	previously. This can include DNS results, TLS session state,		previously. This can include DNS results, TLS session state,
	previous success and quality of transport protocols over certain		previous success and quality of transport protocols over certain
	paths, as well as other information. This caching does not imply		paths, as well as other information. This caching does not imply
	that the same decisions are necessarily made for subsequent		that the same decisions are necessarily made for subsequent
	connections, rather, it means that cached state is used by the		connections, rather, it means that cached state is used by the
	Transport Services architecture to inform functions such as		Transport Services architecture to inform functions such as
	choosing the candidates to be raced, selecting appropriate		choosing the candidates to be raced, selecting appropriate
	transport parameters, etc. An application SHOULD NOT depend on		transport parameters, etc. An application SHOULD NOT rely on
	specific caching behaviour, instead it ought to explicitly request		specific caching behaviour, instead it ought to explicitly request
	any required or desired properties via the Transport Services API.		any required or desired properties via the Transport Services API.
	4.2.1. Candidate Gathering		4.2.1. Candidate Gathering
	* Candidate Path Selection: Candidate Path Selection represents the		* Candidate Path Selection: Candidate Path Selection represents the
	act of choosing one or more paths that are available to use based		act of choosing one or more paths that are available to use based
	on the Selection Properties and any available Local and Remote		on the Selection Properties and any available Local and Remote
	Endpoints provided by the application, as well as the policies and		Endpoints provided by the application, as well as the policies and
	heuristics of a Transport Services implementation.		heuristics of a Transport Services implementation.
	skipping to change at page 30, line 8 ¶		skipping to change at page 30, line 8 ¶
	research and innovation programme under grant agreements No. 644334		research and innovation programme under grant agreements No. 644334
	(NEAT), No. 688421 (MAMI) and No 815178 (5GENESIS).		(NEAT), No. 688421 (MAMI) and No 815178 (5GENESIS).
	This work has been supported by Leibniz Prize project funds of DFG -		This work has been supported by Leibniz Prize project funds of DFG -
	German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ		German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ
	FE 570/4-1).		FE 570/4-1).
	This work has been supported by the UK Engineering and Physical		This work has been supported by the UK Engineering and Physical
	Sciences Research Council under grant EP/R04144X/1.		Sciences Research Council under grant EP/R04144X/1.
	Thanks to Theresa Enghardt, Max Franke, Mirja Kuehlewind, Jonathan		Thanks to Reese Enghardt, Max Franke, Mirja Kuehlewind, Jonathan
	Lennox, and Michael Welzl for the discussions and feedback that		Lennox, and Michael Welzl for the discussions and feedback that
	helped shape the architecture described here. Particular thanks is		helped shape the architecture described here. Particular thanks is
	also due to Philipp S. Tiesel and Christopher A. Wood, who were		also due to Philipp S. Tiesel and Christopher A. Wood, who were
	both co-authors of this architecture specification as it progressed		both co-authors of this architecture specification as it progressed
	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
	skipping to change at page 30, line 36 ¶		skipping to change at page 30, line 36 ¶
	[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, R., 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-14,		Work in Progress, Internet-Draft, draft-ietf-taps-impl-15,
	20 October 2022, <https://datatracker.ietf.org/doc/html/		9 March 2023, <https://datatracker.ietf.org/doc/html/
	draft-ietf-taps-impl-14>.		draft-ietf-taps-impl-15>.
	[I-D.ietf-taps-interface]		[I-D.ietf-taps-interface]
	Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,		Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
	Kühlewind, 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-18, 24 October 2022,		taps-interface-19, 9 March 2023,
	<https://datatracker.ietf.org/doc/html/draft-ietf-taps-		<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
	interface-18>.		interface-19>.
	[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.
	[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>.
End of changes. 15 change blocks.
	17 lines changed or deleted		18 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/