draft-ietf-taps-transports-11.txt		draft-ietf-taps-transports-12.txt
	Network Working Group G. Fairhurst, Ed.		Network Working Group G. Fairhurst, Ed.
	Internet-Draft University of Aberdeen		Internet-Draft University of Aberdeen
	Intended status: Informational B. Trammell, Ed.		Intended status: Informational B. Trammell, Ed.
	Expires: January 8, 2017 M. Kuehlewind, Ed.		Expires: April 28, 2017 M. Kuehlewind, Ed.
	ETH Zurich		ETH Zurich
	July 07, 2016		October 25, 2016
	Services provided by IETF transport protocols and congestion control		Services provided by IETF transport protocols and congestion control
	mechanisms		mechanisms
	draft-ietf-taps-transports-11		draft-ietf-taps-transports-12
	Abstract		Abstract
	This document describes, surveys, classifies and compares the		This document describes, surveys, classifies and compares the
	protocol mechanisms provided by existing IETF protocols, as		protocol mechanisms provided by existing IETF protocols, as
	background for determining a common set of transport services. It		background for determining a common set of transport services. It
	examines the Transmission Control Protocol (TCP), Multipath TCP, the		examines the Transmission Control Protocol (TCP), Multipath TCP, the
	Stream Control Transmission Protocol (SCTP), the User Datagram		Stream Control Transmission Protocol (SCTP), the User Datagram
	Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol		Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol
	(DCCP), the Internet Control Message Protocol (ICMP), the Realtime		(DCCP), the Internet Control Message Protocol (ICMP), the Realtime
	Transport Protocol (RTP), File Delivery over Unidirectional		Transport Protocol (RTP), File Delivery over Unidirectional
	Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC),		Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC),
	and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security		and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security
	(TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol		(TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol
	(HTTP), when HTTP is used as a pseudotransport.		(HTTP), when HTTP is used as a pseudotransport. This survey provides
			background for the definition of transport services within the TAPS
			working group.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 8, 2017.		This Internet-Draft will expire on April 28, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Overview of Transport Features . . . . . . . . . . . . . 4		1.1. Overview of Transport Features . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Existing Transport Protocols . . . . . . . . . . . . . . . . 5		3. Existing Transport Protocols . . . . . . . . . . . . . . . . 6
	3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 6		3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 6
	3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6		3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6
	3.1.2. Interface description . . . . . . . . . . . . . . . . 8		3.1.2. Interface description . . . . . . . . . . . . . . . . 8
	3.1.3. Transport Features . . . . . . . . . . . . . . . . . 8		3.1.3. Transport Features . . . . . . . . . . . . . . . . . 8
	3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 9		3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 9
	3.2.1. Protocol Description . . . . . . . . . . . . . . . . 9		3.2.1. Protocol Description . . . . . . . . . . . . . . . . 9
	3.2.2. Interface Description . . . . . . . . . . . . . . . . 9		3.2.2. Interface Description . . . . . . . . . . . . . . . . 10
	3.2.3. Transport features . . . . . . . . . . . . . . . . . 10		3.2.3. Transport features . . . . . . . . . . . . . . . . . 10
	3.3. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 10		3.3. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 10
	3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11		3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
	3.3.2. Interface Description . . . . . . . . . . . . . . . . 11		3.3.2. Interface Description . . . . . . . . . . . . . . . . 12
	3.3.3. Transport Features . . . . . . . . . . . . . . . . . 12		3.3.3. Transport Features . . . . . . . . . . . . . . . . . 12
	3.4. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 12		3.4. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 13
	3.4.1. Protocol Description . . . . . . . . . . . . . . . . 13		3.4.1. Protocol Description . . . . . . . . . . . . . . . . 13
	3.4.2. Interface Description . . . . . . . . . . . . . . . . 13		3.4.2. Interface Description . . . . . . . . . . . . . . . . 13
	3.4.3. Transport Features . . . . . . . . . . . . . . . . . 13		3.4.3. Transport Features . . . . . . . . . . . . . . . . . 14
	3.5. Stream Control Transmission Protocol (SCTP) . . . . . . . 14		3.5. Stream Control Transmission Protocol (SCTP) . . . . . . . 14
	3.5.1. Protocol Description . . . . . . . . . . . . . . . . 14		3.5.1. Protocol Description . . . . . . . . . . . . . . . . 14
	3.5.2. Interface Description . . . . . . . . . . . . . . . . 16		3.5.2. Interface Description . . . . . . . . . . . . . . . . 16
	3.5.3. Transport Features . . . . . . . . . . . . . . . . . 19		3.5.3. Transport Features . . . . . . . . . . . . . . . . . 19
	3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 19		3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 20
	3.6.1. Protocol Description . . . . . . . . . . . . . . . . 20		3.6.1. Protocol Description . . . . . . . . . . . . . . . . 20
	3.6.2. Interface Description . . . . . . . . . . . . . . . . 21		3.6.2. Interface Description . . . . . . . . . . . . . . . . 21
	3.6.3. Transport Features . . . . . . . . . . . . . . . . . 21		3.6.3. Transport Features . . . . . . . . . . . . . . . . . 22
	3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as		3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as
	a pseudotransport . . . . . . . . . . . . . . . . . . . . 22		a pseudotransport . . . . . . . . . . . . . . . . . . . . 22
	3.7.1. Protocol Description . . . . . . . . . . . . . . . . 22		3.7.1. Protocol Description . . . . . . . . . . . . . . . . 23
	3.7.2. Interface Description . . . . . . . . . . . . . . . . 23		3.7.2. Interface Description . . . . . . . . . . . . . . . . 24
	3.7.3. Transport Features . . . . . . . . . . . . . . . . . 24		3.7.3. Transport Features . . . . . . . . . . . . . . . . . 24
	3.8. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 25		3.8. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 25
	3.8.1. Protocol Description . . . . . . . . . . . . . . . . 25		3.8.1. Protocol Description . . . . . . . . . . . . . . . . 25
	3.8.2. Interface Description . . . . . . . . . . . . . . . . 26		3.8.2. Interface Description . . . . . . . . . . . . . . . . 26
	3.8.3. Transport Features . . . . . . . . . . . . . . . . . 26		3.8.3. Transport Features . . . . . . . . . . . . . . . . . 27
	3.9. Hypertext Transport Protocol (HTTP) over TCP as a		3.9. Hypertext Transport Protocol (HTTP) over TCP as a
	pseudotransport . . . . . . . . . . . . . . . . . . . . . 27		pseudotransport . . . . . . . . . . . . . . . . . . . . . 27
	3.9.1. Protocol Description . . . . . . . . . . . . . . . . 28		3.9.1. Protocol Description . . . . . . . . . . . . . . . . 28
	3.9.2. Interface Description . . . . . . . . . . . . . . . . 28		3.9.2. Interface Description . . . . . . . . . . . . . . . . 29
	3.9.3. Transport features . . . . . . . . . . . . . . . . . 29		3.9.3. Transport features . . . . . . . . . . . . . . . . . 29
	3.10. File Delivery over Unidirectional Transport/Asynchronous		3.10. File Delivery over Unidirectional Transport/Asynchronous
	Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 30		Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 30
	3.10.1. Protocol Description . . . . . . . . . . . . . . . . 30		3.10.1. Protocol Description . . . . . . . . . . . . . . . . 31
	3.10.2. Interface Description . . . . . . . . . . . . . . . 32		3.10.2. Interface Description . . . . . . . . . . . . . . . 32
	3.10.3. Transport Features . . . . . . . . . . . . . . . . . 32		3.10.3. Transport Features . . . . . . . . . . . . . . . . . 33
	3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 33		3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 33
	3.11.1. Protocol Description . . . . . . . . . . . . . . . . 33		3.11.1. Protocol Description . . . . . . . . . . . . . . . . 34
	3.11.2. Interface Description . . . . . . . . . . . . . . . 34		3.11.2. Interface Description . . . . . . . . . . . . . . . 35
	3.11.3. Transport Features . . . . . . . . . . . . . . . . . 35		3.11.3. Transport Features . . . . . . . . . . . . . . . . . 35
	3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 35		3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 36
	3.12.1. Protocol Description . . . . . . . . . . . . . . . . 36		3.12.1. Protocol Description . . . . . . . . . . . . . . . . 36
	3.12.2. Interface Description . . . . . . . . . . . . . . . 36		3.12.2. Interface Description . . . . . . . . . . . . . . . 37
	3.12.3. Transport Features . . . . . . . . . . . . . . . . . 37		3.12.3. Transport Features . . . . . . . . . . . . . . . . . 37
	4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 37		4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 37
	5. Transport Features . . . . . . . . . . . . . . . . . . . . . 38		5. Transport Features . . . . . . . . . . . . . . . . . . . . . 38
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 42		7. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
	10. Informative References . . . . . . . . . . . . . . . . . . . 43		10. Informative References . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	Internet applications make use of the Services provided by a		Internet applications make use of the Services provided by a
	Transport protocol, such as TCP (a reliable, in-order stream		Transport protocol, such as TCP (a reliable, in-order stream
	protocol) or UDP (an unreliable datagram protocol). We use the term		protocol) or UDP (an unreliable datagram protocol). We use the term
	"Transport Service" to mean the end-to-end service provided to an		"Transport Service" to mean the end-to-end service provided to an
	application by the transport layer. That service can only be		application by the transport layer. That service can only be
	provided correctly if information about the intended usage is		provided correctly if information about the intended usage is
	supplied from the application. The application may determine this		supplied from the application. The application may determine this
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 16 ¶
	and UDP, including SCTP, DCCP, MPTCP, and UDP-Lite. Transport		and UDP, including SCTP, DCCP, MPTCP, and UDP-Lite. Transport
	services may be provided directly by these transport protocols, or		services may be provided directly by these transport protocols, or
	layered on top of them using protocols such as WebSockets (which runs		layered on top of them using protocols such as WebSockets (which runs
	over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run		over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run
	over SCTP over DTLS over UDP or TCP). Services built on top of UDP		over SCTP over DTLS over UDP or TCP). Services built on top of UDP
	or UDP-Lite typically also need to specify additional mechanisms,		or UDP-Lite typically also need to specify additional mechanisms,
	including a congestion control mechanism (such as NewReno, TFRC or		including a congestion control mechanism (such as NewReno, TFRC or
	LEDBAT). This extends the set of available Transport Services beyond		LEDBAT). This extends the set of available Transport Services beyond
	those provided to applications by TCP and UDP.		those provided to applications by TCP and UDP.
			The transport protocols described in this document provide a basis
			for the definition of transport services provided by common
			protocols, as background for the TAPS working group. The protocols
			listed here were chosen to help expose as many potential transport
			services as possible, and are not meant to be a comprehensive survey
			or classification of all transport protocols.
	1.1. Overview of Transport Features		1.1. Overview of Transport Features
	Transport protocols can be differentiated by the features of the		Transport protocols can be differentiated by the features of the
	services they provide.		services they provide.
	Some of these provided features are closely related to basic control		Some of these provided features are closely related to basic control
	function that a protocol needs to work over a network path, such as		function that a protocol needs to work over a network path, such as
	addressing. The number of participants in a given association also		addressing. The number of participants in a given association also
	determines its applicability: if a connection is between endpoints		determines its applicability: if a connection is between endpoints
	(unicast), to one of multiple endpoints (anycast), or simultaneously		(unicast), to one of multiple endpoints (anycast), or simultaneously
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 22 ¶
	All TCP senders provide congestion control, such as described in		All TCP senders provide congestion control, such as described in
	[RFC5681]. TCP uses a sequence number with a sliding receiver window		[RFC5681]. TCP uses a sequence number with a sliding receiver window
	for flow control. The TCP congestion control mechanism also utilises		for flow control. The TCP congestion control mechanism also utilises
	this TCP sequence number to manage a separate congestion window		this TCP sequence number to manage a separate congestion window
	[RFC5681]. The sending window at a given point in time is the		[RFC5681]. The sending window at a given point in time is the
	minimum of the receiver window and the congestion window. The		minimum of the receiver window and the congestion window. The
	congestion window is increased in the absence of congestion and,		congestion window is increased in the absence of congestion and,
	respectively, decreased if congestion is detected. Often loss is		respectively, decreased if congestion is detected. Often loss is
	implicitly handled as a congestion indication which is detected in		implicitly handled as a congestion indication which is detected in
	TCP (also as input for retransmission handling) based on two		TCP (also as input for retransmission handling) based on two
	mechanisms: A retransmission timer with exponential back-up or the		mechanisms: A retransmission timer with exponential back-off or the
	reception of three acknowledgment for the same segment, so called		reception of three acknowledgment for the same segment, so called
	duplicated ACKs (Fast retransmit). In addition, Explicit Congestion		duplicated ACKs (Fast retransmit). In addition, Explicit Congestion
	Notification (ECN) [RFC3168] can be used in TCP, if supported by both		Notification (ECN) [RFC3168] can be used in TCP, if supported by both
	endpoints, that allows a network node to signal congestion without		endpoints, that allows a network node to signal congestion without
	inducing loss. Alternatively, a delay-based congestion control		inducing loss. Alternatively, a delay-based congestion control
	scheme can be used in TCP that reacts to changes in delay as an early		scheme can be used in TCP that reacts to changes in delay as an early
	indication of congestion as also further described in Section 4.		indication of congestion as also further described in Section 4.
	Examples for different kind of congestion control schemes are given		Examples for different kind of congestion control schemes are given
	in Section 4.		in Section 4.
	skipping to change at page 11, line 43 ¶		skipping to change at page 11, line 49 ¶
	messages from other protocols (e.g., TCP) when sharing the same		messages from other protocols (e.g., TCP) when sharing the same
	network path.		network path.
	On transmission, UDP encapsulates each datagram into a single IP		On transmission, UDP encapsulates each datagram into a single IP
	packet or several IP packet fragments. This allows a datagram to be		packet or several IP packet fragments. This allows a datagram to be
	larger than the effective path MTU. Fragments are reassembled before		larger than the effective path MTU. Fragments are reassembled before
	delivery to the UDP receiver, making this transparent to the user of		delivery to the UDP receiver, making this transparent to the user of
	the transport service. When the jumbograms are supported, larger		the transport service. When the jumbograms are supported, larger
	messages may be sent without performing fragmentation.		messages may be sent without performing fragmentation.
	Applications that need to provide fragmentation or that have other		Applications that need to provide fragmentation
	requirements such as receiver flow control, congestion control,		UDP on its own does not provide support for segmentation, receiver
	PathMTU discovery/PLPMTUD, support for ECN, etc. need these to be		flow control, congestion control, PathMTU discovery/PLPMTUD, or ECN.
	provided by protocols operating over UDP [I-D.ietf-tsvwg-rfc5405bis].		Applications that require these features need to provide them on
			their own, or by using a protocol over UDP that provides them
			[I-D.ietf-tsvwg-rfc5405bis].
	3.3.2. Interface Description		3.3.2. Interface Description
	[RFC0768] describes basic requirements for an API for UDP. Guidance		[RFC0768] describes basic requirements for an API for UDP. Guidance
	on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis].		on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis].
	A UDP endpoint consists of a tuple of (IP address, port number). De-		A UDP endpoint consists of a tuple of (IP address, port number). De-
	multiplexing using multiple abstract endpoints (sockets) on the same		multiplexing using multiple abstract endpoints (sockets) on the same
	IP address is supported. The same socket may be used by a single		IP address is supported. The same socket may be used by a single
	server to interact with multiple clients (note: this behavior differs		server to interact with multiple clients (note: this behavior differs
	skipping to change at page 22, line 29 ¶		skipping to change at page 22, line 43 ¶
	3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a		3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a
	pseudotransport		pseudotransport
	Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS)		Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS)
	[RFC6347] are IETF protocols that provide several security-related		[RFC6347] are IETF protocols that provide several security-related
	features to applications. TLS is designed to run on top of a		features to applications. TLS is designed to run on top of a
	reliable streaming transport protocol (usually TCP), while DTLS is		reliable streaming transport protocol (usually TCP), while DTLS is
	designed to run on top of a best-effort datagram protocol (UDP or		designed to run on top of a best-effort datagram protocol (UDP or
	DCCP [RFC5238]). At the time of writing, the current version of TLS		DCCP [RFC5238]). At the time of writing, the current version of TLS
	is 1.2; which is defined in [RFC5246]. DTLS provides nearly		is 1.2, defined in [RFC5246]; work on TLS version 1.3 is nearing
	identical functionality to applications; it is defined in [RFC6347]		completion. DTLS provides nearly identical functionality to
	and its current version is also 1.2. The TLS protocol evolved from		applications; it is defined in [RFC6347] and its current version is
	the Secure Sockets Layer (SSL) protocols developed in the mid-1990s		also 1.2. The TLS protocol evolved from the Secure Sockets Layer
	to support protection of HTTP traffic.		(SSL) protocols developed in the mid-1990s to support protection of
			HTTP traffic.
	While older versions of TLS and DTLS are still in use, they provide		While older versions of TLS and DTLS are still in use, they provide
	weaker security guarantees. [RFC7457] outlines important attacks on		weaker security guarantees. [RFC7457] outlines important attacks on
	TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document		TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document
	that describes secure configurations for TLS and DTLS to counter		that describes secure configurations for TLS and DTLS to counter
	these attacks. The recommendations are applicable for the vast		these attacks. The recommendations are applicable for the vast
	majority of use cases.		majority of use cases.
	3.7.1. Protocol Description		3.7.1. Protocol Description
	skipping to change at page 35, line 42 ¶		skipping to change at page 36, line 15 ¶
	3.12. Internet Control Message Protocol (ICMP)		3.12. Internet Control Message Protocol (ICMP)
	The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and		The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and
	ICMP for IPv6 [RFC4433] are IETF standards track protocols. It is a		ICMP for IPv6 [RFC4433] are IETF standards track protocols. It is a
	connection-less unidirectional protocol that delivers individual		connection-less unidirectional protocol that delivers individual
	messages, without error correction, congestion control, or flow		messages, without error correction, congestion control, or flow
	control. Messages may be sent as unicast, IPv4 broadcast or		control. Messages may be sent as unicast, IPv4 broadcast or
	multicast datagrams (IPv4 and IPv6), in addition to anycast		multicast datagrams (IPv4 and IPv6), in addition to anycast
	datagrams.		datagrams.
			While ICMP is not typically described as a transport protocol, it
			does position itself over the network layer, and the operation of
			other transport protocols can be closely linked to the functions
			provided by ICMP.
	Transport Protocols and upper layer protocols can use received ICMP		Transport Protocols and upper layer protocols can use received ICMP
	messages to help them take appropriate decisions when network or		messages to help them take appropriate decisions when network or
	endpoint errors are reported. For example, to implement, ICMP-based		endpoint errors are reported. For example, to implement, ICMP-based
	Path MTU discovery [RFC1191][RFC1981] or assist in Packetization		Path MTU discovery [RFC1191][RFC1981] or assist in Packetization
	Layer Path MTU Discovery (PMTUD) [RFC4821]. Such reactions to		Layer Path MTU Discovery (PMTUD) [RFC4821]. Such reactions to
	received messages need to protect from off-path data injection		received messages need to protect from off-path data injection
	[I-D.ietf-tsvwg-rfc5405bis], to avoid an application receiving		[I-D.ietf-tsvwg-rfc5405bis], to avoid an application receiving
	packets created by an unauthorized third party. An application		packets created by an unauthorized third party. An application
	therefore needs to ensure that all messages are appropriately		therefore needs to ensure that all messages are appropriately
	validated, by checking the payload of the messages to ensure these		validated, by checking the payload of the messages to ensure these
	skipping to change at page 38, line 20 ¶		skipping to change at page 38, line 45 ¶
	priority congestion control methods often react to changes in delay		priority congestion control methods often react to changes in delay
	as an earlier indication of congestion. This approach tends to		as an earlier indication of congestion. This approach tends to
	induce less loss than a loss-based method but does generally not		induce less loss than a loss-based method but does generally not
	compete well with loss-based traffic across shared bottleneck links.		compete well with loss-based traffic across shared bottleneck links.
	Therefore, methods such as LEDBAT [RFC6824], are deployed in the		Therefore, methods such as LEDBAT [RFC6824], are deployed in the
	Internet for scavenger traffic that aim to only utilize otherwise		Internet for scavenger traffic that aim to only utilize otherwise
	unused capacity.		unused capacity.
	5. Transport Features		5. Transport Features
	The tables below summarize some key features to illustrate the range		The transport protocol features described in this document can be
	of functions provided across the IETF-specified transports. Figure 1		used as a basis for defining common transport features, listed below
	considers transports that may be directly layered over the network,		with the protocols supporting them:
	and Figure 2 considers transports layered over another transport
	service. Features that are permitted, but not required, are marked
	as "Poss" indicating that it is possible for the transport service to
	offer this feature.
	+---------------+------+------+------+------+------+------+------+
	| Feature | TCP | MPTCP| UDP | UDPL | SCTP | DCCP | ICMP |
	+---------------+------+------+------+------+------+------+------+
	| Datagram | No | No | Yes | Yes | Yes | Yes | Yes |
	+---------------+------+------+------+------+------+------+------+
	| Conn. Oriented| Yes | Yes | No | No | Yes | Yes | No |
	+---------------+------+------+------+------+------+------+------+
	| Reliability | Yes | Yes | No | No | Yes | No | No |
	+---------------+------+------+------+------+------+------+------+
	| Partial Rel. | No | No | N/A | N/A | Poss | Yes | N/A |
	+---------------+------+------+------+------+------+------+------+
	| Corupt. Tol | No | No | No | Yes | No | Yes | No |
	+---------------+------+------+------+------+------+------+------+
	| Cong.Control | Yes | Yes | No | No | Yes | Yes | No |
	+---------------+------+------+------+------+------+------+------+
	| Endpoint | 1 | >=1 | >=1 | >=1 | >=1 | 1 | 1 |
	+---------------+------+------+------+------+------+------+------+
	| Multicast Cap.| No | No | Yes | Yes | No | No | No |
	+---------------+------+------+------+------+------+------+------+
	Figure 1: Summary comparison: Transport protocols
	+---------------+------+------+------+------+------+
	| Feature |(D)TLS| RTP | HTTP | FLUTE| NORM |
	+---------------+------+------+------+------+------+
	| Datagram | Both | Yes | No | No | Both |
	+---------------+------+------+------+------+------+
	| Conn. Oriented| Yes | No | Yes | Yes | Yes |
	+---------------+------+------+------+------+------+
	| Reliability | Poss | No | Yes | Yes | Poss |
	+---------------+------+------+------+------+------+
	| Partial R | No | Poss | No | No | Poss |
	+---------------+------+------+------+------+------+
	| Corupt. Tol | No | Poss | No | No | No |
	+---------------+------+------+------+------+------+
	| Cong.Control | N/A | Poss | N/A | Poss | Poss |
	+---------------+------+------+------+------+------+
	| Endpoint | 1 | >=1 | 1 | >=1 | >=1 |
	+---------------+------+------+------+------+------+
	| Multicast Cap.| No | Yes | No | Yes | Yes |
	+---------------+------+------+------+------+------+
	Figure 2: Upper layer transports and frameworks
	The transport protocol features described in this document could be
	used as a basis for defining common transport features:
	o Control Functions		o Control Functions
	* Addressing		* Addressing
	+ unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP,		+ unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP,
	HTTP, ICMP)		HTTP, ICMP)
	+ multicast (UDP, UDP-Lite, RTP, FLUTE/ALC, NORM). Note that,		+ multicast (UDP, UDP-Lite, RTP, FLUTE/ALC, NORM). Note that,
	as TLS and DTLS are unicast-only, there is no widely		as TLS and DTLS are unicast-only, there is no widely
	deployed mechanism for supporting the features in the		deployed mechanism for supporting the features in the
	Security section below when using multicast addressing.		Security section below when using multicast addressing.
	+ IPv4 broadcast (UDP, UDP-Lite, ICMP)		+ IPv4 broadcast (UDP, UDP-Lite, ICMP)
	skipping to change at page 42, line 19 ¶		skipping to change at page 41, line 36 ¶
	* authentication of one end of a connection (TLS, DTLS, FLUTE/		* authentication of one end of a connection (TLS, DTLS, FLUTE/
	ALC)		ALC)
	* authentication of both ends of a connection (TLS, DTLS)		* authentication of both ends of a connection (TLS, DTLS)
	* confidentiality (TLS, DTLS)		* confidentiality (TLS, DTLS)
	* cryptographic integrity protection (TLS, DTLS)		* cryptographic integrity protection (TLS, DTLS)
	* replay protection (FLUTE/ALC, DTLS)		* replay protection (TLS, DTLS, FLUTE/ALC)
	6. IANA Considerations		6. IANA Considerations
	This document has no considerations for IANA.		This document has no considerations for IANA.
	7. Security Considerations		7. Security Considerations
	This document surveys existing transport protocols and protocols		This document surveys existing transport protocols and protocols
	providing transport-like services. Confidentiality, integrity, and		providing transport-like services. Confidentiality, integrity, and
	authenticity are among the features provided by those services. This		authenticity are among the features provided by those services. This
	skipping to change at page 52, line 24 ¶		skipping to change at page 51, line 35 ¶
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <http://www.rfc-editor.org/info/rfc7525>.		2015, <http://www.rfc-editor.org/info/rfc7525>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<http://www.rfc-editor.org/info/rfc7540>.		<http://www.rfc-editor.org/info/rfc7540>.
	[I-D.ietf-tsvwg-rfc5405bis]		[I-D.ietf-tsvwg-rfc5405bis]
	Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", draft-ietf-tsvwg-rfc5405bis-15 (work in		Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in
	progress), June 2016.		progress), October 2016.
	[I-D.ietf-tsvwg-sctp-dtls-encaps]		[I-D.ietf-tsvwg-sctp-dtls-encaps]
	Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS		Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
	Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-		Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
	dtls-encaps-09 (work in progress), January 2015.		dtls-encaps-09 (work in progress), January 2015.
	[I-D.ietf-tsvwg-sctp-ndata]		[I-D.ietf-tsvwg-sctp-ndata]
	Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,		Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
	"Stream Schedulers and User Message Interleaving for the		"Stream Schedulers and User Message Interleaving for the
	Stream Control Transmission Protocol", draft-ietf-tsvwg-		Stream Control Transmission Protocol", draft-ietf-tsvwg-
	sctp-ndata-05 (work in progress), March 2016.		sctp-ndata-07 (work in progress), July 2016.
	[I-D.ietf-tsvwg-natsupp]		[I-D.ietf-tsvwg-natsupp]
	Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control		Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
	Transmission Protocol (SCTP) Network Address Translation		Transmission Protocol (SCTP) Network Address Translation
	Support", draft-ietf-tsvwg-natsupp-09 (work in progress),		Support", draft-ietf-tsvwg-natsupp-09 (work in progress),
	May 2016.		May 2016.
	[I-D.ietf-tcpm-cubic]		[I-D.ietf-tcpm-cubic]
	Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and		Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
	R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",		R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
	draft-ietf-tcpm-cubic-01 (work in progress), January 2016.		draft-ietf-tcpm-cubic-02 (work in progress), August 2016.
	[XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen,		[XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen,
	"XMLHttpRequest working draft		"XMLHttpRequest working draft
	(http://www.w3.org/TR/XMLHttpRequest/)", 2000.		(http://www.w3.org/TR/XMLHttpRequest/)", 2000.
	[REST] Fielding, R., "Architectural Styles and the Design of		[REST] Fielding, R., "Architectural Styles and the Design of
	Network-based Software Architectures, Ph. D. (UC Irvine),		Network-based Software Architectures, Ph. D. (UC Irvine),
	Chapter 5: Representational State Transfer", 2000.		Chapter 5: Representational State Transfer", 2000.
	[POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology		[POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology
End of changes. 33 change blocks.
	97 lines changed or deleted		62 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/