draft-ietf-taps-arch-03.txt		draft-ietf-taps-arch-04.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: September 12, 2019 Google		Expires: January 9, 2020 Google
	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
	P. Tiesel		P. Tiesel
	TU Berlin		TU Berlin
	C. Wood		C. Wood
	Apple Inc.		Apple Inc.
	March 11, 2019		July 08, 2019
	An Architecture for Transport Services		An Architecture for Transport Services
	draft-ietf-taps-arch-03		draft-ietf-taps-arch-04
	Abstract		Abstract
	This document provides an overview of the architecture of Transport		This document provides an overview of the architecture of Transport
	Services, a model for exposing transport protocol features to		Services, a model for exposing transport protocol features to
	applications for network communication. In contrast to what is		applications for network communication. In contrast to what is
	provided by most existing Application Programming Interfaces (APIs),		provided by most existing Application Programming Interfaces (APIs),
	Transport Services is based on an asynchronous, event-driven		Transport Services is based on an asynchronous, event-driven
	interaction pattern; it uses messages for representing data transfer		interaction pattern; it uses messages for representing data transfer
	to applications; and it assumes an implementation that can use		to applications; and it assumes an implementation that can use
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 September 12, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 28 ¶		skipping to change at page 6, line 28 ¶
	o the ability to provide control of reliability, choosing which		o the ability to provide control of reliability, choosing which
	messages to retransmit in the event of packet loss, and how best		messages to retransmit in the event of packet loss, and how best
	to make use of the data that arrived;		to make use of the data that arrived;
	o the ability to manage dependencies between messages, when the		o the ability to manage dependencies between messages, when the
	transport system could decide to not deliver a message, either		transport system could decide to not deliver a message, either
	following packet loss or because it has missed a deadline. In		following packet loss or because it has missed a deadline. In
	particular, this can avoid (re-)sending data that relies on a		particular, this can avoid (re-)sending data that relies on a
	previous transmission that was never received.		previous transmission that was never received.
			o the ability to automatically assign messages and connections to
			underlaying transport connections to utilize multi-streaming and
			pooled connections.
	Allowing applications to interact with messages is backwards-		Allowing applications to interact with messages is backwards-
	compatible with existings protocols and APIs, as it does not change		compatible with existings protocols and APIs, as it does not change
	the wire format of any protocol. Instead, it gives the protocol		the wire format of any protocol. Instead, it gives the protocol
	stack additional information to allow it to make better use of modern		stack additional information to allow it to make better use of modern
	transport services, while simplifying the application's role in		transport services, while simplifying the application's role in
	parsing data.		parsing data.
	1.4. Flexibile Implementation		1.4. Flexibile Implementation
	Sockets, for protocols like TCP, are generally limited to connecting		Sockets, for protocols like TCP, are generally limited to connecting
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 10 ¶
	* Transport Properties: Transport Properties can be specified as		* Transport Properties: Transport Properties can be specified as
	part of a Preconnection to allow the application to configure		part of a Preconnection to allow the application to configure
	the Transport System and express their requirements,		the Transport System and express their requirements,
	prohibitions, and preferences. There are three kinds of		prohibitions, and preferences. There are three kinds of
	Transport Properties: Selection Properties (Section 4.1.2),		Transport Properties: Selection Properties (Section 4.1.2),
	Connection Properties (Section 4.1.2), and Message Properties		Connection Properties (Section 4.1.2), and Message Properties
	(Section 4.1.4). Message Properties can also be specified		(Section 4.1.4). Message Properties can also be specified
	during data transfer to affect specific Messages.		during data transfer to affect specific Messages.
	o Connection: A Connection object represents an active transport		o Connection: A Connection object represents one or more active
	protocol instance that can send and/or receive Messages between		transport protocol instances that can send and/or receive Messages
	local and remote systems. It holds state pertaining to the		between local and remote systems. It holds state pertaining to
	underlying transport protocol instance and any ongoing data		the underlying transport protocol instances and any ongoing data
	transfer. This represents, for example, an active connection in a		transfers. This represents, for example, an active connection in
	connection-oriented protocol such as TCP, or a fully-specified		a connection-oriented protocol such as TCP, or a fully-specified
	5-tuple for a connectionless protocol such as UDP.		5-tuple for a connectionless protocol such as UDP. It can also
			represent a pool of transport protocol instance, e.g., a set of
			TCP and QUIC connections to equivalent endpoints, or a stream of a
			multi-streaming transport protocol instance.
	o Listener: A Listener object accepts incoming transport protocol		o Listener: A Listener object accepts incoming transport protocol
	connections from remote systems and generates corresponding		connections from remote systems 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.
	4.1.2. Pre-Establishment		4.1.2. Pre-Establishment
	o Endpoint: An Endpoint represents an identifier for one side of a		o Endpoint: An Endpoint represents an identifier for one side of a
	transport connection. Endpoints can be Local Endpoints or Remote		transport connection. Endpoints can be Local Endpoints or Remote
	skipping to change at page 23, line 11 ¶		skipping to change at page 23, line 11 ¶
	Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric		Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric
	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.
	8. Informative References		8. Informative References
	[I-D.ietf-taps-impl]		[I-D.ietf-taps-impl]
	Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,		Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
	Jones, T., Tiesel, P., Perkins, C., and M. Welzl,		Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
	"Implementing Interfaces to Transport Services", draft-		"Implementing Interfaces to Transport Services", draft-
	ietf-taps-impl-02 (work in progress), October 2018.		ietf-taps-impl-03 (work in progress), March 2019.
	[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-02 (work in		Services", draft-ietf-taps-interface-03 (work in
	progress), October 2018.		progress), March 2019.
	[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-11 (work		Services for End Systems", draft-ietf-taps-minset-11 (work
	in progress), September 2018.		in progress), September 2018.
	[I-D.ietf-taps-transport-security]		[I-D.ietf-taps-transport-security]
	Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K.		Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K.
	Rose, "A Survey of Transport Security Protocols", draft-		Rose, "A Survey of Transport Security Protocols", draft-
	ietf-taps-transport-security-06 (work in progress), March		ietf-taps-transport-security-06 (work in progress), March
	skipping to change at page 25, line 31 ¶		skipping to change at page 25, line 31 ¶
	Colin Perkins		Colin Perkins
	University of Glasgow		University of Glasgow
	School of Computing Science		School of Computing Science
	Glasgow G12 8QQ		Glasgow G12 8QQ
	United Kingdom		United Kingdom
	Email: csp@csperkins.org		Email: csp@csperkins.org
	Philipp S. Tiesel		Philipp S. Tiesel
	TU Berlin		TU Berlin
	Marchstrasse 23		Einsteinufer 25
	10587 Berlin		10587 Berlin
	Germany		Germany
	Email: philipp@inet.tu-berlin.de		Email: philipp@tiesel.net
	Chris Wood		Chris Wood
	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: cawood@apple.com		Email: cawood@apple.com
End of changes. 10 change blocks.
	16 lines changed or deleted		23 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/