draft-ietf-taps-minset-05.txt		draft-ietf-taps-minset-06.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: February 21, 2019 August 20, 2018		Expires: February 23, 2019 August 22, 2018
	A Minimal Set of Transport Services for End Systems		A Minimal Set of Transport Services for End Systems
	draft-ietf-taps-minset-05		draft-ietf-taps-minset-06
	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 February 21, 2019.		This Internet-Draft will expire on February 23, 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 20 ¶		skipping to change at page 2, line 20 ¶
	3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5		3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5
	3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8		3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8
	3.2.2. Individual connections . . . . . . . . . . . . . . . 10		3.2.2. Individual connections . . . . . . . . . . . . . . . 10
	3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10		3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10
	3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10		3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10
	3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11		3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11
	4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15		Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15
	A.1. Step 1: Categorization -- The Superset of Transport		A.1. Step 1: Categorization -- The Superset of Transport
	Features . . . . . . . . . . . . . . . . . . . . . . . . 15		Features . . . . . . . . . . . . . . . . . . . . . . . . 15
	A.1.1. CONNECTION Related Transport Features . . . . . . . . 17		A.1.1. CONNECTION Related Transport Features . . . . . . . . 17
	A.1.2. DATA Transfer Related Transport Features . . . . . . 33		A.1.2. DATA Transfer Related Transport Features . . . . . . 33
	A.2. Step 2: Reduction -- The Reduced Set of Transport		A.2. Step 2: Reduction -- The Reduced Set of Transport
	Features . . . . . . . . . . . . . . . . . . . . . . . . 39		Features . . . . . . . . . . . . . . . . . . . . . . . . 39
	A.2.1. CONNECTION Related Transport Features . . . . . . . . 40		A.2.1. CONNECTION Related Transport Features . . . . . . . . 40
	A.2.2. DATA Transfer Related Transport Features . . . . . . 41		A.2.2. DATA Transfer Related Transport Features . . . . . . 41
	A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 42		A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41
	A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42		A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42
	A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43		A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43
	A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44		A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44
	A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44		A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44
	A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 45		A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 45
	A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 46		A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45
	A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46		A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46
	Appendix B. Revision information . . . . . . . . . . . . . . . . 46		Appendix B. Revision information . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Introduction		1. Introduction
	The task of a transport system is to offer transport services to its		The task of a transport system is to offer transport services to its
	applications, i.e. the applications running on top of the transport		applications, i.e. the applications running on top of the transport
	system. Ideally, it does so without statically binding applications		system. Ideally, it does so without statically binding applications
	to particular transport protocols. Currently, the set of transport		to particular transport protocols. Currently, the set of transport
	services that most applications use is based on TCP and UDP (and		services that most applications use is based on TCP and UDP (and
	protocols that are layered on top of them); this limits the ability		protocols that are layered on top of them); this limits the ability
	for the network stack to make use of features of other transport		for the network stack to make use of features of other transport
	skipping to change at page 12, line 46 ¶		skipping to change at page 12, line 46 ¶
	input to this document. We especially thank Michael Tuexen for help		input to this document. We especially thank Michael Tuexen for help
	with connection connection establishment/teardown and Gorry Fairhurst		with connection connection establishment/teardown and Gorry Fairhurst
	for his suggestions regarding fragmentation and packet sizes, and		for his suggestions regarding fragmentation and packet sizes, and
	Spencer Dawkins for his extremely detailed and constructive review.		Spencer Dawkins for his extremely detailed and constructive review.
	This work has received funding from the European Union's Horizon 2020		This work has received funding from the European Union's Horizon 2020
	research and innovation programme under grant agreement No. 644334		research and innovation programme under grant agreement No. 644334
	(NEAT).		(NEAT).
	6. IANA Considerations		6. IANA Considerations
	XX RFC ED - PLEASE REMOVE THIS SECTION XXX
	This memo includes no request to IANA.		This memo includes no request to IANA.
	7. Security Considerations		7. 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]. As currently
	deployed in the Internet, these features are generally provided by a		deployed in the Internet, these features are generally provided by a
	protocol or layer on top of the transport protocol; no current full-		protocol or layer on top of the transport protocol; no current full-
	featured standards-track transport protocol provides all of these		featured standards-track transport protocol provides all of these
	transport features on its own. Therefore, these transport features		transport features on its own. Therefore, these transport features
	are not considered in this document, with the exception of native		are not 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 of [I-D.ietf-taps-transport-security]).		separate document (Section 5 on Security Features and Transport
			Dependencies of [I-D.ietf-taps-transport-security]).
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of		[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
	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>.
	skipping to change at page 30, line 4 ¶		skipping to change at page 29, line 37 ¶
	Implementation: via SET_CHECKSUM_REQUIRED.UDP.		Implementation: via SET_CHECKSUM_REQUIRED.UDP.
	Implementation over TCP: do nothing (TCP does not offer to disable		Implementation over TCP: do nothing (TCP does not offer to disable
	the checksum, but transmitting data with an intact checksum will		the checksum, but transmitting data with an intact checksum will
	not yield a semantically wrong result).		not yield a semantically wrong result).
	o Specify checksum coverage used by the sender		o Specify checksum coverage used by the sender
	Protocols: UDP-Lite		Protocols: UDP-Lite
	Functional because application-specific knowledge is necessary to		Functional because application-specific knowledge is necessary to
	decide for which parts of the data it can be acceptable to lose		decide for which parts of the data it can be acceptable to lose
	data integrity.		data integrity.
	Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.		Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
	Implementation over TCP: do nothing (TCP does not offer to limit		Implementation over TCP: do nothing (TCP does not offer to limit
	the checksum length, but transmitting data with an intact checksum		the checksum length, but transmitting data with an intact checksum
	will not yield a semantically wrong result). Implementation over		will not yield a semantically wrong result).
	UDP: if checksum coverage is set to cover payload data, do		Implementation over UDP: if checksum coverage is set to cover
	nothing. Else, either do nothing (transmitting data with an		payload data, do nothing. Else, either do nothing (transmitting
	intact checksum will not yield a semantically wrong result), or		data with an intact checksum will not yield a semantically wrong
	use the transport feature "Disable checksum when sending".		result), or use the transport feature "Disable checksum when
			sending".
	o Specify minimum checksum coverage required by receiver		o Specify minimum checksum coverage required by receiver
	Protocols: UDP-Lite		Protocols: UDP-Lite
	Functional because application-specific knowledge is necessary to		Functional because application-specific knowledge is necessary to
	decide for which parts of the data it can be acceptable to lose		decide for which parts of the data it can be acceptable to lose
	data integrity.		data integrity.
	Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite.		Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite.
	Implementation over TCP: do nothing (TCP does not offer to limit		Implementation over TCP: do nothing (TCP does not offer to limit
	the checksum length, but transmitting data with an intact checksum		the checksum length, but transmitting data with an intact checksum
	will not yield a semantically wrong result). Implementation over		will not yield a semantically wrong result).
	UDP: if checksum coverage is set to cover payload data, do		Implementation over UDP: if checksum coverage is set to cover
	nothing. Else, either do nothing (transmitting data with an		payload data, do nothing. Else, either do nothing (transmitting
	intact checksum will not yield a semantically wrong result), or		data with an intact checksum will not yield a semantically wrong
	use the transport feature "Disable checksum requirement when		result), or use the transport feature "Disable checksum
	receiving".		requirement when receiving".
	o Specify DF field		o Specify DF field
	Protocols: UDP(-Lite)		Protocols: UDP(-Lite)
	Optimizing because the DF field can be used to carry out Path MTU		Optimizing because the DF field can be used to carry out Path MTU
	Discovery, which can lead an application to choose message sizes		Discovery, which can lead an application to choose message sizes
	that can be transmitted more efficiently.		that can be transmitted more efficiently.
	Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and		Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and
	SEND_FAILURE.UDP(-Lite).		SEND_FAILURE.UDP(-Lite).
	Implementation over TCP: do nothing (with TCP, the sending		Implementation over TCP: do nothing (with TCP, the sending
	application is not in control of transport message sizes, making		application is not in control of transport message sizes, making
	skipping to change at page 48, line 11 ¶		skipping to change at page 47, line 44 ¶
	document", wrote "example" in the paragraph introducing the decision		document", wrote "example" in the paragraph introducing the decision
	tree. Removed reference draft-grinnemo-taps-he-03 and the sentence		tree. Removed reference draft-grinnemo-taps-he-03 and the sentence
	that referred to it.		that referred to it.
	WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As		WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As
	part of that, removed "TAPS" as a term everywhere (abstract, intro,		part of that, removed "TAPS" as a term everywhere (abstract, intro,
	..).		..).
	WG -05: addressed comments from Spencer Dawkins.		WG -05: addressed comments from Spencer Dawkins.
	Authors' Addresses		WG -06: Fixed nits.
			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
	Stein Gjessing		Stein Gjessing
End of changes. 14 change blocks.
	23 lines changed or deleted		23 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/