Diff: draft-ietf-taps-arch-14.txt - draft-ietf-taps-arch-15.txt

	draft-ietf-taps-arch-14.txt	draft-ietf-taps-arch-15.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: 31 March 2023 Google Switzerland GmbH	Expires: 23 April 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 September 2022	20 October 2022

	An Architecture for Transport Services	An Architecture for Transport Services

	draft-ietf-taps-arch-14	draft-ietf-taps-arch-15

	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 31 March 2023.	This Internet-Draft will expire on 23 April 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 22 ¶	skipping to change at page 8, line 22 ¶
	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.
	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 [RFC9112]; 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

	to segment its headers and bodies [RFC7540].	to segment its headers and bodies [RFC9113].

	The Transport Services API represents data as messages, so that it	The Transport Services API represents data as messages, so that it
	more closely matches the way applications use the network. Providing	more closely matches the way applications use the network. Providing
	a message-based abstraction provides many benefits, such as:	a message-based abstraction provides many benefits, such as:

	* the ability to associate deadlines with messages, for applications	* the ability to associate deadlines with messages, for applications
	that care about timing;	that care about timing;

	* the ability to control reliability, which messages to retransmit	* the ability to control reliability, which messages to retransmit
	when there is packet loss, and how best to make use of the data	when there is packet loss, and how best to make use of the data

	skipping to change at page 19, line 34 ¶	skipping to change at page 19, line 34 ¶
	connection from that endpoint. The process of identifying options	connection from that endpoint. The process of identifying options
	for the connection, such as resolution of the Remote Endpoint,	for the connection, such as resolution of the Remote Endpoint,
	occurs in response to the Rendezvous call. As with Listeners, the	occurs in response to the Rendezvous call. As with Listeners, the
	set of local paths and endpoints is constrained by Selection	set of local paths and endpoints is constrained by Selection
	Properties. If successful, the Rendezvous call returns a	Properties. If successful, the Rendezvous call returns a
	Connection object to represent the established peer-to-peer	Connection object to represent the established peer-to-peer
	connection. The processes by which connections are initiated	connection. The processes by which connections are initiated
	during a Rendezvous action will depend on the set of Local and	during a Rendezvous action will depend on the set of Local and
	Remote Endpoints configured on the Preconnection. For example, if	Remote Endpoints configured on the Preconnection. For example, if
	the Local and Remote Endpoints are TCP host candidates, then a TCP	the Local and Remote Endpoints are TCP host candidates, then a TCP

	simultaneous open [RFC0793] will be performed. However, if the	simultaneous open [RFC9293] will be performed. However, if the
	set of Local Endpoints includes server reflexive candidates, such	set of Local Endpoints includes server reflexive candidates, such
	as those provided by STUN, a Rendezvous action will race	as those provided by STUN, a Rendezvous action will race
	candidates in the style of the ICE algorithm [RFC8445] to perform	candidates in the style of the ICE algorithm [RFC8445] to perform
	NAT binding discovery and initiate a peer-to-peer connection.	NAT binding discovery and initiate a peer-to-peer connection.

	4.1.5. Data Transfer Objects and Actions	4.1.5. Data Transfer Objects and Actions

	* Message: A Message object is a unit of data that can be	* Message: A Message object is a unit of data that can be
	represented as bytes that can be transferred between two endpoints	represented as bytes that can be transferred between two endpoints
	over a transport connection. The bytes within a Message are	over a transport connection. The bytes within a Message are

	skipping to change at page 26, line 32 ¶	skipping to change at page 26, line 32 ¶
	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

	8.1. Normative References	8.1. Normative References


	[I-D.ietf-taps-interface]
	Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
	Kühlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
	"An Abstract Application Layer Interface to Transport
	Services", Work in Progress, Internet-Draft, draft-ietf-
	taps-interface-17, 27 September 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
	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, 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-13,	Work in Progress, Internet-Draft, draft-ietf-taps-impl-13,
	31 August 2022, <https://datatracker.ietf.org/doc/html/	31 August 2022, <https://datatracker.ietf.org/doc/html/
	draft-ietf-taps-impl-13>.	draft-ietf-taps-impl-13>.


		[I-D.ietf-taps-interface]
		Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
		Kühlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
		"An Abstract Application Layer Interface to Transport
		Services", Work in Progress, Internet-Draft, draft-ietf-
		taps-interface-17, 27 September 2022,
		<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
		interface-17>.

	[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", RFC 793,
	DOI 10.17487/RFC0793, September 1981,
	<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
	Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/rfc/rfc7230>.

	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/rfc/rfc7540>.

	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
	Ed., "Services Provided by IETF Transport Protocols and	Ed., "Services Provided by IETF Transport Protocols and
	Congestion Control Mechanisms", RFC 8095,	Congestion Control Mechanisms", RFC 8095,
	DOI 10.17487/RFC8095, March 2017,	DOI 10.17487/RFC8095, March 2017,
	<https://www.rfc-editor.org/rfc/rfc8095>.	<https://www.rfc-editor.org/rfc/rfc8095>.

	[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/rfc/rfc8305>.	<https://www.rfc-editor.org/rfc/rfc8305>.

	skipping to change at page 28, line 19 ¶	skipping to change at page 28, line 5 ¶
	[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.	[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
	Wood, "A Survey of the Interaction between Security	Wood, "A Survey of the Interaction between Security
	Protocols and Transport Services", RFC 8922,	Protocols and Transport Services", RFC 8922,
	DOI 10.17487/RFC8922, October 2020,	DOI 10.17487/RFC8922, October 2020,
	<https://www.rfc-editor.org/rfc/rfc8922>.	<https://www.rfc-editor.org/rfc/rfc8922>.

	[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport	[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
	Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,	Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
	October 2020, <https://www.rfc-editor.org/rfc/rfc8923>.	October 2020, <https://www.rfc-editor.org/rfc/rfc8923>.


		[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
		Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
		June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

		[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
		DOI 10.17487/RFC9113, June 2022,
		<https://www.rfc-editor.org/rfc/rfc9113>.

		[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
		STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
		<https://www.rfc-editor.org/rfc/rfc9293>.

	Authors' Addresses	Authors' Addresses

	Tommy Pauly (editor)	Tommy Pauly (editor)
	Apple Inc.	Apple Inc.
	One Apple Park Way	One Apple Park Way
	Cupertino, California 95014,	Cupertino, California 95014,
	United States of America	United States of America
	Email: tpauly@apple.com	Email: tpauly@apple.com

	Brian Trammell (editor)	Brian Trammell (editor)

End of changes. 12 change blocks.
	30 lines changed or deleted	28 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/