draft-ietf-taps-transports-usage-07.txt		draft-ietf-taps-transports-usage-08.txt
	TAPS M. Welzl		TAPS M. Welzl
	Internet-Draft University of Oslo		Internet-Draft University of Oslo
	Intended status: Informational M. Tuexen		Intended status: Informational M. Tuexen
	Expires: February 26, 2018 Muenster Univ. of Appl. Sciences		Expires: February 27, 2018 Muenster Univ. of Appl. Sciences
	N. Khademi		N. Khademi
	University of Oslo		University of Oslo
	August 25, 2017		August 26, 2017
	On the Usage of Transport Features Provided by IETF Transport Protocols		On the Usage of Transport Features Provided by IETF Transport Protocols
	draft-ietf-taps-transports-usage-07		draft-ietf-taps-transports-usage-08
	Abstract		Abstract
	This document describes how the transport protocols Transmission		This document describes how the transport protocols Transmission
	Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control		Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control
	Transmission Protocol (SCTP), User Datagram Protocol (UDP) and		Transmission Protocol (SCTP), User Datagram Protocol (UDP) and
	Lightweight User Datagram Protocol (UDP-Lite) expose services to		Lightweight User Datagram Protocol (UDP-Lite) expose services to
	applications and how an application can configure and use the		applications and how an application can configure and use the
	features that make up these services. It also discusses the service		features that make up these services. It also discusses the service
	provided by the Low Extra Delay Background Transport (LEDBAT)		provided by the Low Extra Delay Background Transport (LEDBAT)
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 26, 2018.		This Internet-Draft will expire on February 27, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 41 ¶		skipping to change at page 2, line 41 ¶
	5.1. CONNECTION Related Transport Features . . . . . . . . . . 34		5.1. CONNECTION Related Transport Features . . . . . . . . . . 34
	5.2. DATA Transfer Related Transport Features . . . . . . . . . 40		5.2. DATA Transfer Related Transport Features . . . . . . . . . 40
	5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40		5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40
	5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41		5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41
	5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 42		5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 42
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 43		8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 43		9.1. Normative References . . . . . . . . . . . . . . . . . . . 43
	9.2. Informative References . . . . . . . . . . . . . . . . . . 46		9.2. Informative References . . . . . . . . . . . . . . . . . . 45
	Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 47		Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 47
	Appendix B. How this document was developed . . . . . . . . . . . 47		Appendix B. How this document was developed . . . . . . . . . . . 47
	Appendix C. Revision information . . . . . . . . . . . . . . . . 49		Appendix C. Revision information . . . . . . . . . . . . . . . . 48
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
	1. Terminology		1. Terminology
	Transport Feature: a specific end-to-end feature that the transport		Transport Feature: a specific end-to-end feature that the transport
	layer provides to an application. Examples include		layer provides to an application. Examples include
	confidentiality, reliable delivery, ordered delivery, message-		confidentiality, reliable delivery, ordered delivery, message-
	versus-stream orientation, etc.		versus-stream orientation, etc.
	Transport Service: a set of Transport Features, without an		Transport Service: a set of Transport Features, without an
	association to any given framing protocol, which provides a		association to any given framing protocol, which provides a
	skipping to change at page 13, line 18 ¶		skipping to change at page 13, line 18 ¶
	authenticated chunks are used, the key identifier for		authenticated chunks are used, the key identifier for
	authenticating DATA chunks can be provided [RFC4895].		authenticating DATA chunks can be provided [RFC4895].
	Receive: Messages are received from an association, and optionally a		Receive: Messages are received from an association, and optionally a
	stream within the association, with their size returned. The		stream within the association, with their size returned. The
	application is notified of the availability of data via a 'Data		application is notified of the availability of data via a 'Data
	Arrive' notification. If the sender has included a payload		Arrive' notification. If the sender has included a payload
	protocol-id, this value is also returned. If the received message		protocol-id, this value is also returned. If the received message
	is only a partial delivery of a whole message, a partial flag will		is only a partial delivery of a whole message, a partial flag will
	indicate so, in which case the stream id and a stream sequence		indicate so, in which case the stream id and a stream sequence
	number are provided to the application. A delivery number lets		number are provided to the application.
	the application detect reordering.
	Shutdown: This primitive gracefully closes an association, reliably		Shutdown: This primitive gracefully closes an association, reliably
	delivering any data that has already been handed over to SCTP. A		delivering any data that has already been handed over to SCTP. A
	parameter lets the application control whether further receive or		parameter lets the application control whether further receive or
	send operations or both are disabled when the call is issued. A		send operations or both are disabled when the call is issued. A
	return code informs about success or failure of this procedure.		return code informs about success or failure of this procedure.
	Abort: This ungracefully closes an association, by discarding any		Abort: This ungracefully closes an association, by discarding any
	locally queued data and informing the peer that the association		locally queued data and informing the peer that the association
	was aborted. Optionally, an abort reason to be passed to the peer		was aborted. Optionally, an abort reason to be passed to the peer
	skipping to change at page 33, line 39 ¶		skipping to change at page 33, line 39 ¶
	Pass 1 primitive / event: 'Data Arrive' notification, followed by		Pass 1 primitive / event: 'Data Arrive' notification, followed by
	'Receive'		'Receive'
	Parameters: stream number (optional)		Parameters: stream number (optional)
	Returns: stream sequence number (optional); partial flag		Returns: stream sequence number (optional); partial flag
	(optional)		(optional)
	Comments: if the 'stream number' is provided, the call to receive		Comments: if the 'stream number' is provided, the call to receive
	only receives data on one particular stream. If a partial message		only receives data on one particular stream. If a partial message
	arrives, this is indicated by the 'partial flag', and then the		arrives, this is indicated by the 'partial flag', and then the
	'stream sequence number' must be provided such that an application		'stream sequence number' must be provided such that an application
	can restore the correct order of data blocks that comprise an		can restore the correct order of data blocks that comprise an
	entire message. Additionally, a delivery number lets the		entire message.
	application detect reordering.
	o RECEIVE.UDP(-Lite):		o RECEIVE.UDP(-Lite):
	Pass 1 primitive / event: 'Receive',		Pass 1 primitive / event: 'Receive',
	Parameters: buffer for received datagram		Parameters: buffer for received datagram
	Comments: all CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives		Comments: all CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives
	apply per message received.		apply per message received.
	o SENDFAILURE-EVENT.SCTP:		o SENDFAILURE-EVENT.SCTP:
	Pass 1 primitive / event: 'Send Failure' notification, optionally		Pass 1 primitive / event: 'Send Failure' notification, optionally
	followed by 'Receive Unsent Message' or 'Receive Unacknowledged		followed by 'Receive Unsent Message' or 'Receive Unacknowledged
	skipping to change at page 42, line 20 ¶		skipping to change at page 42, line 20 ¶
	o Choice of stream to receive from		o Choice of stream to receive from
	Protocols: SCTP		Protocols: SCTP
	o Information about partial message arrival		o Information about partial message arrival
	Protocols: SCTP		Protocols: SCTP
	Comments: in SCTP, partial messages are combined with a stream		Comments: in SCTP, partial messages are combined with a stream
	sequence number so that the application can restore the correct		sequence number so that the application can restore the correct
	order of data blocks an entire message consists of.		order of data blocks an entire message consists of.
	o Obtain a message delivery number
	Protocols: SCTP
	Comments: this number can let applications detect and, if desired,
	correct reordering.
	5.2.3. Errors		5.2.3. Errors
	This section describes sending failures that are associated with a		This section describes sending failures that are associated with a
	specific call to DATA.SEND from pass 2.		specific call to DATA.SEND from pass 2.
	o Notification of an unsent (part of a) message		o Notification of an unsent (part of a) message
	Protocols: SCTP, UDP(-Lite)		Protocols: SCTP, UDP(-Lite)
	o Notification of an unacknowledged (part of a) message		o Notification of an unacknowledged (part of a) message
	Protocols: SCTP		Protocols: SCTP
	skipping to change at page 42, line 46 ¶		skipping to change at page 42, line 41 ¶
	o Notification that the stack has no more user data to send		o Notification that the stack has no more user data to send
	Protocols: SCTP		Protocols: SCTP
	o Notification to a receiver that a partial message delivery has		o Notification to a receiver that a partial message delivery has
	been aborted		been aborted
	Protocols: SCTP		Protocols: SCTP
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank (in alphabetical order) Bob Briscoe,		The authors would like to thank (in alphabetical order) Bob Briscoe,
	Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Joe Touch and		Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly,
	Brian Trammell for providing valuable feedback on this document. We		Joe Touch and Brian Trammell for providing valuable feedback on this
	especially thank Christoph Paasch for providing input related to		document. We especially thank Christoph Paasch for providing input
	Multipath TCP, and Gorry Fairhurst and Tom Jones for providing input		related to Multipath TCP, and Gorry Fairhurst and Tom Jones for
	related to UDP(-Lite). This work has received funding from the		providing input related to UDP(-Lite). This work has received
	European Union's Horizon 2020 research and innovation programme under		funding from the European Union's Horizon 2020 research and
	grant agreement No. 644334 (NEAT). The views expressed are solely		innovation programme under grant agreement No. 644334 (NEAT). The
	those of the author(s).		views expressed are solely those of the author(s).
	7. IANA Considerations		7. IANA Considerations
	XX RFC ED - PLEASE REMOVE THIS SECTION XXX		XX RFC ED - PLEASE REMOVE THIS SECTION XXX
	This memo includes no request to IANA.		This memo includes no request to IANA.
	8. Security Considerations		8. Security Considerations
	Authentication, confidentiality protection, and integrity protection		Authentication, confidentiality protection, and integrity protection
	skipping to change at page 50, line 11 ¶		skipping to change at page 49, line 49 ¶
	encompass both TCP and SCTP. Added citations of [RFC8095] and minset		encompass both TCP and SCTP. Added citations of [RFC8095] and minset
	[I-D.draft-gjessing-taps-minset] to the intro, to give the context of		[I-D.draft-gjessing-taps-minset] to the intro, to give the context of
	this document.		this document.
	-05: minor fix to TCP authentication (comment from Joe Touch),		-05: minor fix to TCP authentication (comment from Joe Touch),
	several fixes from Gorry Fairhurst and Tom Jones. Language fixes;		several fixes from Gorry Fairhurst and Tom Jones. Language fixes;
	updated to align with latest taps-transport-usage-udp ID.		updated to align with latest taps-transport-usage-udp ID.
	-06: addressed WGLC comments from Aaron Falk and Tommy Pauly.		-06: addressed WGLC comments from Aaron Falk and Tommy Pauly.
			-07: addressed AD review comments from Spencer Dawkins.
			-08: removed "delivery number" which was based on an error in RFC
			4960: https://tools.ietf.org/html/
			draft-ietf-tsvwg-rfc4960-errata-02#section-3.34.
	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
	Email: michawe@ifi.uio.no		Email: michawe@ifi.uio.no
End of changes. 11 change blocks.
	23 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/