draft-ietf-taps-minset-10.txt		draft-ietf-taps-minset-11.txt
	TAPS M. Welzl		TAPS M. Welzl
	Internet-Draft S. Gjessing		Internet-Draft S. Gjessing
	Intended status: Informational University of Oslo		Intended status: Informational University of Oslo
	Expires: March 22, 2019 September 18, 2018		Expires: March 31, 2019 September 27, 2018
	A Minimal Set of Transport Services for End Systems		A Minimal Set of Transport Services for End Systems
	draft-ietf-taps-minset-10		draft-ietf-taps-minset-11
	Abstract		Abstract
	This draft recommends a minimal set of Transport Services offered by		This draft recommends a minimal set of Transport Services offered by
	end systems, and gives guidance on choosing among the available		end systems, and gives guidance on choosing among the available
	mechanisms and protocols. It is based on the set of transport		mechanisms and protocols. It is based on the set of transport
	features in RFC 8303.		features in RFC 8303.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 March 22, 2019.		This Internet-Draft will expire on March 31, 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 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Deriving the minimal set . . . . . . . . . . . . . . . . . . 5		3. Deriving the minimal set . . . . . . . . . . . . . . . . . . 5
	4. The Reduced Set of Transport Features . . . . . . . . . . . . 6		4. The Reduced Set of Transport Features . . . . . . . . . . . . 6
	4.1. CONNECTION Related Transport Features . . . . . . . . . . 7		4.1. CONNECTION Related Transport Features . . . . . . . . . . 7
	4.2. DATA Transfer Related Transport Features . . . . . . . . 8		4.2. DATA Transfer Related Transport Features . . . . . . . . 8
	4.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 8		4.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 8
	4.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 9		4.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 9
	4.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 9		4.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Sending Messages, Receiving Bytes . . . . . . . . . . . . 9		5.1. Sending Messages, Receiving Bytes . . . . . . . . . . . . 10
	5.2. Stream Schedulers Without Streams . . . . . . . . . . . . 10		5.2. Stream Schedulers Without Streams . . . . . . . . . . . . 11
	5.3. Early Data Transmission . . . . . . . . . . . . . . . . . 11		5.3. Early Data Transmission . . . . . . . . . . . . . . . . . 11
	5.4. Sender Running Dry . . . . . . . . . . . . . . . . . . . 12		5.4. Sender Running Dry . . . . . . . . . . . . . . . . . . . 12
	5.5. Capacity Profile . . . . . . . . . . . . . . . . . . . . 12		5.5. Capacity Profile . . . . . . . . . . . . . . . . . . . . 13
	5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 13		5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.7. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 13		5.7. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 14
	6. The Minimal Set of Transport Features . . . . . . . . . . . . 14		6. The Minimal Set of Transport Features . . . . . . . . . . . . 14
	6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 14		6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 14
	6.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 17		6.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 18
	6.2.1. Connection groups . . . . . . . . . . . . . . . . . . 18		6.2.1. Connection groups . . . . . . . . . . . . . . . . . . 18
	6.2.2. Individual connections . . . . . . . . . . . . . . . 19		6.2.2. Individual connections . . . . . . . . . . . . . . . 20
	6.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 20		6.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 20
	6.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 20		6.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 20
	6.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 21		6.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 21
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 21		9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . 22		10.1. Normative References . . . . . . . . . . . . . . . . . . 22
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		10.2. Informative References . . . . . . . . . . . . . . . . . 23
	Appendix A. The Superset of Transport Features . . . . . . . . . 24		Appendix A. The Superset of Transport Features . . . . . . . . . 25
	A.1. CONNECTION Related Transport Features . . . . . . . . . . 25		A.1. CONNECTION Related Transport Features . . . . . . . . . . 26
	A.2. DATA Transfer Related Transport Features . . . . . . . . 41		A.2. DATA Transfer Related Transport Features . . . . . . . . 42
	A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 41		A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 42
	A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 45		A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 46
	A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 46		A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 47
	Appendix B. Revision information . . . . . . . . . . . . . . . . 47		Appendix B. Revision information . . . . . . . . . . . . . . . . 48
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
	1. Introduction		1. Introduction
	Currently, the set of transport services that most applications use		Currently, the set of transport services that most applications use
	is based on TCP and UDP (and protocols that are layered on top of		is based on TCP and UDP (and protocols that are layered on top of
	them); this limits the ability for the network stack to make use of		them); this limits the ability for the network stack to make use of
	features of other transport protocols. For example, if a protocol		features of other transport protocols. For example, if a protocol
	supports out-of-order message delivery but applications always assume		supports out-of-order message delivery but applications always assume
	that the network provides an ordered bytestream, then the network		that the network provides an ordered bytestream, then the network
	stack can not immediately deliver a message that arrives out-of-		stack can not immediately deliver a message that arrives out-of-
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	guidance on the design of this abstraction level. Some transport		guidance on the design of this abstraction level. Some transport
	features are currently rarely offered by APIs, yet they must be		features are currently rarely offered by APIs, yet they must be
	offered or they can never be used. Other transport features are		offered or they can never be used. Other transport features are
	offered by the APIs of the protocols covered here, but not exposing		offered by the APIs of the protocols covered here, but not exposing
	them in an API would allow for more freedom to automate protocol		them in an API would allow for more freedom to automate protocol
	usage in a transport system. The minimal set presented here is an		usage in a transport system. The minimal set presented here is an
	effort to find a middle ground that can be recommended for transport		effort to find a middle ground that can be recommended for transport
	systems to implement, on the basis of the transport features		systems to implement, on the basis of the transport features
	discussed in [RFC8303].		discussed in [RFC8303].
	Applications use a wide variety of APIs today. The transport		Applications use a wide variety of APIs today. While this document
	features in the minimal set in this document must be reflected in		was created to ensure the API developed in the Transport Services
	*all* network APIs in order for the underlying functionality to		(TAPS) Working Group ([I-D.ietf-taps-interface]) includes the most
	become usable everywhere. For example, it does not help an		important transport features, the minimal set presented here must be
	application that talks to a library which offers its own		reflected in *all* network APIs in order for the underlying
			functionality to become usable everywhere. For example, it does not
			help an application that talks to a library which offers its own
	communication interface if the underlying Berkeley Sockets API is		communication interface if the underlying Berkeley Sockets API is
	extended to offer "unordered message delivery", but the library only		extended to offer "unordered message delivery", but the library only
	exposes an ordered bytestream. Both the Berkeley Sockets API and the		exposes an ordered bytestream. Both the Berkeley Sockets API and the
	library would have to expose the "unordered message delivery"		library would have to expose the "unordered message delivery"
	transport feature (alternatively, there may be ways for certain types		transport feature (alternatively, there may be ways for certain types
	of libraries to use this transport feature without exposing it, based		of libraries to use this transport feature without exposing it, based
	on knowledge about the applications -- but this is not the general		on knowledge about the applications -- but this is not the general
	case). Similarly, transport protocols such as SCTP offer multi-		case). Similarly, transport protocols such as SCTP offer multi-
	streaming, which cannot be utilized, e.g., to prioritize messages		streaming, which cannot be utilized, e.g., to prioritize messages
	between streams, unless applications communicate the priorities and		between streams, unless applications communicate the priorities and
	skipping to change at page 21, line 44 ¶		skipping to change at page 22, line 29 ¶
	research and innovation programme under grant agreement No. 644334		research and innovation programme under grant agreement No. 644334
	(NEAT).		(NEAT).
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Security Considerations		9. Security Considerations
	Authentication, confidentiality protection, and integrity protection		Authentication, confidentiality protection, and integrity protection
	are identified as transport features by [RFC8095]. As currently		are identified as transport features by [RFC8095]. Often, these
	deployed in the Internet, these features are generally provided by a		features are provided by a protocol or layer on top of the transport
	protocol or layer on top of the transport protocol; no current full-		protocol; none of the full-featured standards-track transport
	featured standards-track transport protocol provides all of these		protocols in [RFC8303], which this document is based upon, provides
	transport features on its own. Therefore, these transport features		all of these transport features on its own. Therefore, they are not
	are not considered in this document, with the exception of native		considered in this document, with the exception of native
	authentication capabilities of TCP and SCTP for which the security		authentication capabilities of TCP and SCTP for which the security
	considerations in [RFC5925] and [RFC4895] apply. The minimum		considerations in [RFC5925] and [RFC4895] apply. The minimum
	requirements for a secure transport system are discussed in a		requirements for a secure transport system are discussed in a
	separate document (Section 5 on Security Features and Transport		separate document (Section 5 on Security Features and Transport
	Dependencies of [I-D.ietf-taps-transport-security]).		Dependencies of [I-D.ietf-taps-transport-security]).
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	skipping to change at page 22, line 33 ¶		skipping to change at page 23, line 22 ¶
	Transport Features Provided by IETF Transport Protocols",		Transport Features Provided by IETF Transport Protocols",
	RFC 8303, DOI 10.17487/RFC8303, February 2018,		RFC 8303, DOI 10.17487/RFC8303, February 2018,
	<https://www.rfc-editor.org/info/rfc8303>.		<https://www.rfc-editor.org/info/rfc8303>.
	10.2. Informative References		10.2. Informative References
	[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte		[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte
	Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No.		Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No.
	2, April 1999.		2, April 1999.
			[I-D.ietf-taps-interface]
			Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
			Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
			Abstract Application Layer Interface to Transport
			Services", draft-ietf-taps-interface-01 (work in
			progress), July 2018.
	[I-D.ietf-tsvwg-rtcweb-qos]		[I-D.ietf-tsvwg-rtcweb-qos]
	Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP		Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
	Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-		Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
	qos-18 (work in progress), August 2016.		qos-18 (work in progress), August 2016.
	[LBE-draft]		[LBE-draft]
	Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",		Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
	Internet-draft draft-tsvwg-le-phb-03, February 2018.		Internet-draft draft-tsvwg-le-phb-03, February 2018.
	[POSIX] "IEEE Standard for Information Technology--Portable		[POSIX] "IEEE Standard for Information Technology--Portable
	skipping to change at page 49, line 12 ¶		skipping to change at page 50, line 12 ¶
	WG -07: Addressed Genart comments from Robert Sparks.		WG -07: Addressed Genart comments from Robert Sparks.
	WG -08: Addressed one more Genart comment from Robert Sparks.		WG -08: Addressed one more Genart comment from Robert Sparks.
	WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben		WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben
	Campbell, Benjamin Kaduk and Eric Rescorla.		Campbell, Benjamin Kaduk and Eric Rescorla.
	WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla.		WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla.
			WG -11: Addressed comments from Alissa Cooper.
	Authors' Addresses		Authors' Addresses
	Michael Welzl		Michael Welzl
	University of Oslo		University of Oslo
	PO Box 1080 Blindern		PO Box 1080 Blindern
	Oslo N-0316		Oslo N-0316
	Norway		Norway
	Phone: +47 22 85 24 20		Phone: +47 22 85 24 20
	Email: michawe@ifi.uio.no		Email: michawe@ifi.uio.no
End of changes. 14 change blocks.
	32 lines changed or deleted		43 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/