draft-ietf-taps-transports-12.txt		draft-ietf-taps-transports-13.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: April 28, 2017 M. Kuehlewind, Ed.		Expires: June 8, 2017 M. Kuehlewind, Ed.
	ETH Zurich		ETH Zurich
	October 25, 2016		December 05, 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-12		draft-ietf-taps-transports-13
	Abstract		Abstract
	This document describes, surveys, classifies and compares the		This document describes, surveys, and classifies the protocol
	protocol mechanisms provided by existing IETF protocols, as		mechanisms provided by existing IETF protocols, as background for
	background for determining a common set of transport services. It		determining a common set of transport services. It examines the
	examines the Transmission Control Protocol (TCP), Multipath TCP, the		Transmission Control Protocol (TCP), Multipath TCP, the Stream
	Stream Control Transmission Protocol (SCTP), the User Datagram		Control Transmission Protocol (SCTP), the User Datagram Protocol
	Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol		(UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the
	(DCCP), the Internet Control Message Protocol (ICMP), the Realtime		Internet Control Message Protocol (ICMP), the Realtime Transport
	Transport Protocol (RTP), File Delivery over Unidirectional		Protocol (RTP), File Delivery over Unidirectional Transport/
	Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC),		Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK-
	and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security		Oriented Reliable Multicast (NORM), Transport Layer Security (TLS),
	(TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol		Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP),
	(HTTP), when HTTP is used as a pseudotransport. This survey provides		when HTTP is used as a pseudotransport. This survey provides
	background for the definition of transport services within the TAPS		background for the definition of transport services within the TAPS
	working group.		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 April 28, 2017.		This Internet-Draft will expire on June 8, 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 34 ¶		skipping to change at page 2, line 34 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Existing Transport Protocols . . . . . . . . . . . . . . . . 6		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 . . . . . . . . . . . . . . . . 10		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) . . . . . . . . . . . . . . 11
	3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11		3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
	3.3.2. Interface Description . . . . . . . . . . . . . . . . 12		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) . . . . . . 13		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 . . . . . . . . . . . . . . . . . 14		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
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	3.8.3. Transport Features . . . . . . . . . . . . . . . . . 27		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 . . . . . . . . . . . . . . . . 29		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 . . . . . . . . . . . . . . . . 31		3.10.1. Protocol Description . . . . . . . . . . . . . . . . 31
	3.10.2. Interface Description . . . . . . . . . . . . . . . 32		3.10.2. Interface Description . . . . . . . . . . . . . . . 32
	3.10.3. Transport Features . . . . . . . . . . . . . . . . . 33		3.10.3. Transport Features . . . . . . . . . . . . . . . . . 32
	3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 33		3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 33
	3.11.1. Protocol Description . . . . . . . . . . . . . . . . 34		3.11.1. Protocol Description . . . . . . . . . . . . . . . . 33
	3.11.2. Interface Description . . . . . . . . . . . . . . . 35		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) . . . . . . . . 36		3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 35
	3.12.1. Protocol Description . . . . . . . . . . . . . . . . 36		3.12.1. Protocol Description . . . . . . . . . . . . . . . . 36
	3.12.2. Interface Description . . . . . . . . . . . . . . . 37		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 . . . . . . . . . . . . . . . . . . . . . 41		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 41		7. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
	10. Informative References . . . . . . . . . . . . . . . . . . . 42		10. Informative References . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
	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 12 ¶		skipping to change at page 4, line 12 ¶
	Transport Services are reliable delivery, ordered delivery, content		Transport Services are reliable delivery, ordered delivery, content
	privacy to in-path devices, and integrity protection.		privacy to in-path devices, and integrity protection.
	The IETF has defined a wide variety of transport protocols beyond TCP		The IETF has defined a wide variety of transport protocols beyond TCP
	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 [RFC6582],
	LEDBAT). This extends the set of available Transport Services beyond		TFRC [RFC5348] or LEDBAT [RFC6817]). This extends the set of
	those provided to applications by TCP and UDP.		available Transport Services beyond those provided to applications by
			TCP and UDP.
	The transport protocols described in this document provide a basis		The transport protocols described in this document provide a basis
	for the definition of transport services provided by common		for the definition of transport services provided by common
	protocols, as background for the TAPS working group. The protocols		protocols, as background for the TAPS working group. The protocols
	listed here were chosen to help expose as many potential transport		listed here were chosen to help expose as many potential transport
	services as possible, and are not meant to be a comprehensive survey		services as possible, and are not meant to be a comprehensive survey
	or classification of all transport protocols.		or classification of all transport protocols.
	1.1. Overview of Transport Features		1.1. Overview of Transport Features
	skipping to change at page 8, line 5 ¶		skipping to change at page 7, line 51 ¶
	transport service not to delay data. By default, TCP segment		transport service not to delay data. By default, TCP segment
	partitioning uses Nagle's algorithm [RFC0896] to buffer data at the		partitioning uses Nagle's algorithm [RFC0896] to buffer data at the
	sender into large segments, potentially incurring sender-side		sender into large segments, potentially incurring sender-side
	buffering delay; this algorithm can be disabled by the sender to		buffering delay; this algorithm can be disabled by the sender to
	transmit more immediately, e.g., to reduce latency for interactive		transmit more immediately, e.g., to reduce latency for interactive
	sessions.		sessions.
	TCP provides an "urgent data" function for limited out-of-order		TCP provides an "urgent data" function for limited out-of-order
	delivery of the data. This function is deprecated [RFC6093].		delivery of the data. This function is deprecated [RFC6093].
			A RESET control message may be used to close a TCP session [RFC0793].
	A mandatory checksum provides a basic integrity check against		A mandatory checksum provides a basic integrity check against
	misdelivery and data corruption over the entire packet. Applications		misdelivery and data corruption over the entire packet. Applications
	that require end to end integrity of data are recommended to include		that require end to end integrity of data are recommended to include
	a stronger integrity check of their payload data. The TCP checksum		a stronger integrity check of their payload data. The TCP checksum
	does not support partial payload protection (as in DCCP/UDP-Lite).		[RFC1071] [RFC2460] does not support partial payload protection (as
			in DCCP/UDP-Lite).
	TCP supports only unicast connections.		TCP supports only unicast connections.
	3.1.2. Interface description		3.1.2. Interface description
	A User/TCP Interface is defined in [RFC0793] providing six user		A User/TCP Interface is defined in [RFC0793] providing six user
	commands: Open, Send, Receive, Close, Status. This interface does		commands: Open, Send, Receive, Close, Status. This interface does
	not describe configuration of TCP options or parameters beside use of		not describe configuration of TCP options or parameters beside use of
	the PUSH and URGENT flags.		the PUSH and URGENT flags.
	skipping to change at page 11, line 25 ¶		skipping to change at page 11, line 31 ¶
	independent messages, ordinarily called datagrams. It provides		independent messages, ordinarily called datagrams. It provides
	detection of payload errors and misdelivery of packets to an		detection of payload errors and misdelivery of packets to an
	unintended endpoint, either of which result in discard of received		unintended endpoint, either of which result in discard of received
	datagrams, with no indication to the user of the service.		datagrams, with no indication to the user of the service.
	It is possible to create IPv4 UDP datagrams with no checksum, and		It is possible to create IPv4 UDP datagrams with no checksum, and
	while this is generally discouraged [RFC1122]		while this is generally discouraged [RFC1122]
	[I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use.		[I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use.
	These datagrams rely on the IPv4 header checksum to protect from		These datagrams rely on the IPv4 header checksum to protect from
	misdelivery to an unintended endpoint. IPv6 does not permit UDP		misdelivery to an unintended endpoint. IPv6 does not permit UDP
	datagrams with no checksum, although in certain cases this rule may		datagrams with no checksum, although in certain cases [RFC6936] this
	be relaxed [RFC6935].		rule may be relaxed [RFC6935].
	UDP does not provide reliability and does not provide retransmission.		UDP does not provide reliability and does not provide retransmission.
	Messages may be re-ordered, lost, or duplicated in transit. Note		Messages may be re-ordered, lost, or duplicated in transit. Note
	that due to the relatively weak form of checksum used by UDP,		that due to the relatively weak form of checksum used by UDP,
	applications that require end to end integrity of data are		applications that require end to end integrity of data are
	recommended to include a stronger integrity check of their payload		recommended to include a stronger integrity check of their payload
	data.		data.
	Because UDP provides no flow control, a receiving application that is		Because UDP provides no flow control, a receiving application that is
	unable to run sufficiently fast, or frequently, may miss messages.		unable to run sufficiently fast, or frequently, may miss messages.
	skipping to change at page 11, line 49 ¶		skipping to change at page 12, line 7 ¶
	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
	UDP on its own does not provide support for segmentation, receiver		UDP on its own does not provide support for segmentation, receiver
	flow control, congestion control, PathMTU discovery/PLPMTUD, or ECN.		flow control, congestion control, PathMTU discovery/PLPMTUD, or ECN.
	Applications that require these features need to provide them on		Applications that require these features need to provide them on
	their own, or by using a protocol over UDP that provides them		their own, or by using a protocol over UDP that provides them
	[I-D.ietf-tsvwg-rfc5405bis].		[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].
	skipping to change at page 16, line 38 ¶		skipping to change at page 16, line 38 ¶
	services provided by SCTP, such as un-ordered delivery or partial		services provided by SCTP, such as un-ordered delivery or partial
	reliability. Therefore, the use of DTLS over SCTP has been specified		reliability. Therefore, the use of DTLS over SCTP has been specified
	in [RFC6083] to overcome these limitations. When using DTLS over		in [RFC6083] to overcome these limitations. When using DTLS over
	SCTP, the application can use almost all services provided by SCTP.		SCTP, the application can use almost all services provided by SCTP.
	[I-D.ietf-tsvwg-natsupp] defines methods for endpoints and		[I-D.ietf-tsvwg-natsupp] defines methods for endpoints and
	middleboxes to provide NAT traversal for SCTP over IPv4. For legacy		middleboxes to provide NAT traversal for SCTP over IPv4. For legacy
	NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP-		NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP-
	packets. Alternatively, SCTP packets can be encapsulated in DTLS		packets. Alternatively, SCTP packets can be encapsulated in DTLS
	packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The		packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The
	latter encapsulation is used within the WebRTC context.		latter encapsulation is used within the WebRTC
			[I-D.ietf-rtcweb-transports] context.
	SCTP has a well-defined API, described in the next subsection.		SCTP has a well-defined API, described in the next subsection.
	3.5.2. Interface Description		3.5.2. Interface Description
	[RFC4960] defines an abstract API for the base protocol. This API		[RFC4960] defines an abstract API for the base protocol. This API
	describes the following functions callable by the upper layer of		describes the following functions callable by the upper layer of
	SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message,		SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message,
	Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status,		Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status,
	Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure		Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 7 ¶
	are only accepted in an authenticated way, and get the list of		are only accepted in an authenticated way, and get the list of
	chunks which are accepted by the local and remote end point in an		chunks which are accepted by the local and remote end point in an
	authenticated way.		authenticated way.
	o the SCTP Dynamic Address Reconfiguration extension defined in		o the SCTP Dynamic Address Reconfiguration extension defined in
	[RFC5061]. It allows to manually add and delete local addresses		[RFC5061]. It allows to manually add and delete local addresses
	for SCTP associations and the enabling of automatic address		for SCTP associations and the enabling of automatic address
	addition and deletion. Furthermore the peer can be given a hint		addition and deletion. Furthermore the peer can be given a hint
	for choosing its primary path.		for choosing its primary path.
	For the following SCTP protocol extensions the BSD Sockets API		A BSD Sockets API extension has been defined in the documents that
	extension is defined in the document specifying the protocol		specify the following SCTP protocol extensions:
	extensions:
	o the SCTP Stream Reconfiguration extension defined in [RFC6525].		o the SCTP Stream Reconfiguration extension defined in [RFC6525].
	The API allows to trigger the reset operation for incoming and		The API allows to trigger the reset operation for incoming and
	outgoing streams and the whole association. It provides also a		outgoing streams and the whole association. It provides also a
	way to notify the association about the corresponding events.		way to notify the association about the corresponding events.
	Furthermore the application can increase the number of streams.		Furthermore the application can increase the number of streams.
	o the UDP Encapsulation of SCTP packets extension defined in		o the UDP Encapsulation of SCTP packets extension defined in
	[RFC6951]. The API allows the management of the remote UDP		[RFC6951]. The API allows the management of the remote UDP
	encapsulation port.		encapsulation port.
	skipping to change at page 22, line 43 ¶		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, defined in [RFC5246]; work on TLS version 1.3 is nearing		is 1.2, defined in [RFC5246]; work on TLS version 1.3
	completion. DTLS provides nearly identical functionality to		[I-D.ietf-tls-tls13] nearing completion. DTLS provides nearly
	applications; it is defined in [RFC6347] and its current version is		identical functionality to applications; it is defined in [RFC6347]
	also 1.2. The TLS protocol evolved from the Secure Sockets Layer		and its current version is also 1.2. The TLS protocol evolved from
	(SSL) protocols developed in the mid-1990s to support protection of		the Secure Sockets Layer (SSL) [RFC6101] protocols developed in the
	HTTP traffic.		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 24, line 20 ¶		skipping to change at page 24, line 20 ¶
	Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream		Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream
	ciphers, which are essentially incompatible when operating on		ciphers, which are essentially incompatible when operating on
	independent encrypted records.		independent encrypted records.
	3.7.2. Interface Description		3.7.2. Interface Description
	TLS is commonly invoked using an API provided by packages such as		TLS is commonly invoked using an API provided by packages such as
	OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the		OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the
	manipulation of several important abstractions, which fall into the		manipulation of several important abstractions, which fall into the
	following categories: long-term keys and algorithms, session state,		following categories: long-term keys and algorithms, session state,
	and communications/connections. There may also be special APIs		and communications/connections.
	required to deal with time and/or random numbers, both of which are
	needed by a variety of encryption algorithms and protocols.
	Considerable care is required in the use of TLS APIs to ensure		Considerable care is required in the use of TLS APIs to ensure
	creation of a secure application. The programmer should have at		creation of a secure application. The programmer should have at
	least a basic understanding of encryption and digital signature		least a basic understanding of encryption and digital signature
	algorithms and their strengths, public key infrastructure (including		algorithms and their strengths, public key infrastructure (including
	X.509 certificates and certificate revocation), and the sockets API.		X.509 certificates and certificate revocation), and the sockets API.
	See [RFC7525] and [RFC7457], as mentioned above.		See [RFC7525] and [RFC7457], as mentioned above.
	As an example, in the case of OpenSSL, the primary abstractions are		As an example, in the case of OpenSSL, the primary abstractions are
	the library itself and method (protocol), session, context, cipher		the library itself and method (protocol), session, context, cipher
	skipping to change at page 28, line 24 ¶		skipping to change at page 28, line 22 ¶
	Representational State Transfer (REST) [REST] is another example of		Representational State Transfer (REST) [REST] is another example of
	how applications can use HTTP as transport protocol. REST is an		how applications can use HTTP as transport protocol. REST is an
	architecture style that may be used to build applications using HTTP		architecture style that may be used to build applications using HTTP
	as a communication protocol.		as a communication protocol.
	3.9.1. Protocol Description		3.9.1. Protocol Description
	Hypertext Transfer Protocol (HTTP) is a request/response protocol. A		Hypertext Transfer Protocol (HTTP) is a request/response protocol. A
	client sends a request containing a request method, URI and protocol		client sends a request containing a request method, URI and protocol
	version followed by a MIME-like message (see [RFC7231] for the		version followed message whose design is inspired by MIME (see
	differences between an HTTP object and a MIME message), containing		[RFC7231] for the differences between an HTTP object and a MIME
	information about the client and request modifiers. The message can		message), containing information about the client and request
	also contain a message body carrying application data. The server		modifiers. The message can also contain a message body carrying
	responds with a status or error code followed by a MIME-like message		application data. The server responds with a status or error code
	containing information about the server and information about the		followed by a message containing information about the server and
	data. This may include a message body. It is possible to specify a		information about the data. This may include a message body. It is
	data format for the message body using MIME media types [RFC2045].		possible to specify a data format for the message body using MIME
	The protocol has additional features, some relevant to pseudo-		media types [RFC2045]. The protocol has additional features, some
	transport are described below.		relevant to pseudo-transport are described below.
	Content negotiation, specified in [RFC7231], is a mechanism provided		Content negotiation, specified in [RFC7231], is a mechanism provided
	by HTTP to allow selection of a representation for a requested		by HTTP to allow selection of a representation for a requested
	resource. The client and server negotiate acceptable data formats,		resource. The client and server negotiate acceptable data formats,
	character sets, data encoding (e.g., data can be transferred		character sets, data encoding (e.g., data can be transferred
	compressed using gzip). HTTP can accommodate exchange of messages as		compressed using gzip). HTTP can accommodate exchange of messages as
	well as data streaming (using chunked transfer encoding [RFC7230]).		well as data streaming (using chunked transfer encoding [RFC7230]).
	It is also possible to request a part of a resource using an object		It is also possible to request a part of a resource using an object
	range request [RFC7233]. The protocol provides powerful cache		range request [RFC7233]. The protocol provides powerful cache
	control signaling defined in [RFC7234].		control signaling defined in [RFC7234].
	skipping to change at page 29, line 13 ¶		skipping to change at page 29, line 11 ¶
	connections can multiplex many request/response pairs in parallel on		connections can multiplex many request/response pairs in parallel on
	a single transport connection. Both are important to reduce latency		a single transport connection. Both are important to reduce latency
	for HTTP's primary use case.		for HTTP's primary use case.
	HTTP can be combined with security mechanisms, such as TLS (denoted		HTTP can be combined with security mechanisms, such as TLS (denoted
	by HTTPS). This adds protocol properties provided by such a		by HTTPS). This adds protocol properties provided by such a
	mechanism (e.g., authentication, encryption). The TLS Application-		mechanism (e.g., authentication, encryption). The TLS Application-
	Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to		Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to
	negotiate the HTTP version within the TLS handshake, eliminating the		negotiate the HTTP version within the TLS handshake, eliminating the
	latency incurred by additional round-trip exchanges. Arbitrary		latency incurred by additional round-trip exchanges. Arbitrary
	cookie strings, included as part of the MIME headers, are often used		cookie strings, included as part of the request headers, are often
	as bearer tokens in HTTP.		used as bearer tokens in HTTP.
	3.9.2. Interface Description		3.9.2. Interface Description
	There are many HTTP libraries available exposing different APIs. The		There are many HTTP libraries available exposing different APIs. The
	APIs provide a way to specify a request by providing a URI, a method,		APIs provide a way to specify a request by providing a URI, a method,
	request modifiers and optionally a request body. For the response,		request modifiers and optionally a request body. For the response,
	callbacks can be registered that will be invoked when the response is		callbacks can be registered that will be invoked when the response is
	received. If HTTPS is used, the API exposes a registration of		received. If HTTPS is used, the API exposes a registration of
	callbacks for a server that requests client authentication and when		callbacks for a server that requests client authentication and when
	certificate verification is needed.		certificate verification is needed.
	skipping to change at page 32, line 40 ¶		skipping to change at page 32, line 40 ¶
	based rate control mechanism and a single channel is sufficient.		based rate control mechanism and a single channel is sufficient.
	[RFC6584] provides per-packet authentication, integrity, and anti-		[RFC6584] provides per-packet authentication, integrity, and anti-
	replay protection in the context of the ALC and NORM protocols.		replay protection in the context of the ALC and NORM protocols.
	Several mechanisms are proposed that seamlessly integrate into these		Several mechanisms are proposed that seamlessly integrate into these
	protocols using the ALC and NORM header extension mechanisms.		protocols using the ALC and NORM header extension mechanisms.
	3.10.2. Interface Description		3.10.2. Interface Description
	The FLUTE/ALC specification does not describe a specific application		The FLUTE/ALC specification does not describe a specific application
	programming interface (API) to control protocol operation.		programming interface (API) to control protocol operation. Although
			open source and commercial implementations have specified APIs, there
	Open source reference implementations of FLUTE/ALC are available at		is no IETF- specified API for FLUTE/ALC.
	http://planete-bcast.inrialpes.fr/ (no longer maintained) and
	http://mad.cs.tut.fi/ (no longer maintained), and these
	implementations specify and document their own APIs. Commercial
	versions are also available, some derived from the above
	implementations, with their own API.
	3.10.3. Transport Features		3.10.3. Transport Features
	The transport features provided by FLUTE/ALC are:		The transport features provided by FLUTE/ALC are:
	o unicast, multicast, anycast or IPv4 broadcast transmission,		o unicast, multicast, anycast or IPv4 broadcast transmission,
	o object-oriented delivery of discrete data or files and associated		o object-oriented delivery of discrete data or files and associated
	metadata,		metadata,
	skipping to change at page 36, line 8 ¶		skipping to change at page 35, line 45 ¶
	o data bundling (using Nagle's algorithm),		o data bundling (using Nagle's algorithm),
	o flow control (timer-based and/or ack-based),		o flow control (timer-based and/or ack-based),
	o congestion control (also supporting fixed rate reliable or		o congestion control (also supporting fixed rate reliable or
	unreliable delivery).		unreliable delivery).
	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 [RFC4443] 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		While ICMP is not typically described as a transport protocol, it
	does position itself over the network layer, and the operation of		does position itself over the network layer, and the operation of
	other transport protocols can be closely linked to the functions		other transport protocols can be closely linked to the functions
	provided by ICMP.		provided by ICMP.
	skipping to change at page 36, line 46 ¶		skipping to change at page 36, line 36 ¶
	[I-D.ietf-tsvwg-rfc5405bis].		[I-D.ietf-tsvwg-rfc5405bis].
	3.12.1. Protocol Description		3.12.1. Protocol Description
	ICMP is a connection-less unidirectional protocol, It delivers		ICMP is a connection-less unidirectional protocol, It delivers
	independent messages, called datagrams. Each message is required to		independent messages, called datagrams. Each message is required to
	carry a checksum as an integrity check and to protect from mis-		carry a checksum as an integrity check and to protect from mis-
	delivery to an unintended endpoint.		delivery to an unintended endpoint.
	ICMP messages typically relay diagnostic information from an endpoint		ICMP messages typically relay diagnostic information from an endpoint
	[RFC1122] or network device [RFC1716] addressed to the sender of a		[RFC1122] or network device [RFC1812] addressed to the sender of a
	flow. This usually contains the network protocol header of a packet		flow. This usually contains the network protocol header of a packet
	that encountered a reported issue. Some formats of messages can also		that encountered a reported issue. Some formats of messages can also
	carry other payload data. Each message carries an integrity check		carry other payload data. Each message carries an integrity check
	calculated in the same way as for UDP, this checksum is not optional.		calculated in the same way as for UDP, this checksum is not optional.
	The RFC series defines additional IPv6 message formats to support a		The RFC series defines additional IPv6 message formats to support a
	range of uses. In the case of IPv6 the protocol incorporates		range of uses. In the case of IPv6 the protocol incorporates
	neighbor discovery [RFC2461] [RFC3971] (provided by ARP for IPv4) and		neighbor discovery [RFC2461] [RFC3971] (provided by ARP for IPv4) and
	the Multicast Listener Discovery (MLD) [RFC2710] group management		the Multicast Listener Discovery (MLD) [RFC2710] group management
	functions (provided by IGMP for IPv4).		functions (provided by IGMP for IPv4).
	skipping to change at page 39, line 4 ¶		skipping to change at page 38, line 41 ¶
	5. Transport Features		5. Transport Features
	The transport protocol features described in this document can be		The transport protocol features described in this document can be
	used as a basis for defining common transport features, listed below		used as a basis for defining common transport features, listed below
	with the protocols supporting them:		with the protocols supporting them:
	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, ICMP, FLUTE/ALC, NORM). Note
	as TLS and DTLS are unicast-only, there is no widely		that, 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)
	+ anycast (UDP, UDP-Lite). Connection-oriented protocols such		+ anycast (UDP, UDP-Lite). Connection-oriented protocols such
	as TCP and DCCP have also been deployed using anycast		as TCP and DCCP have also been deployed using anycast
	addressing, with the risk that routing changes may cause		addressing, with the risk that routing changes may cause
	connection failure.		connection failure.
	* Association type		* Association type
	+ connection-oriented (TCP, MPTCP, DCCP, SCTP, TLS, RTP, HTTP,		+ connection-oriented (TCP, MPTCP, DCCP, SCTP, TLS, RTP, HTTP,
	NORM)		NORM)
	skipping to change at page 43, line 17 ¶		skipping to change at page 43, line 9 ¶
	<http://www.rfc-editor.org/info/rfc792>.		<http://www.rfc-editor.org/info/rfc792>.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<http://www.rfc-editor.org/info/rfc793>.		<http://www.rfc-editor.org/info/rfc793>.
	[RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks",		[RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks",
	RFC 896, DOI 10.17487/RFC0896, January 1984,		RFC 896, DOI 10.17487/RFC0896, January 1984,
	<http://www.rfc-editor.org/info/rfc896>.		<http://www.rfc-editor.org/info/rfc896>.
			[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
			Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
			September 1988, <http://www.rfc-editor.org/info/rfc1071>.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	<http://www.rfc-editor.org/info/rfc1122>.		<http://www.rfc-editor.org/info/rfc1122>.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<http://www.rfc-editor.org/info/rfc1191>.		<http://www.rfc-editor.org/info/rfc1191>.
	[RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for		[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
	IP Routers", RFC 1716, DOI 10.17487/RFC1716, November		RFC 1812, DOI 10.17487/RFC1812, June 1995,
	1994, <http://www.rfc-editor.org/info/rfc1716>.		<http://www.rfc-editor.org/info/rfc1812>.
	[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery		[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
	for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August		for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
	1996, <http://www.rfc-editor.org/info/rfc1981>.		1996, <http://www.rfc-editor.org/info/rfc1981>.
	[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP		[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
	Selective Acknowledgment Options", RFC 2018,		Selective Acknowledgment Options", RFC 2018,
	DOI 10.17487/RFC2018, October 1996,		DOI 10.17487/RFC2018, October 1996,
	<http://www.rfc-editor.org/info/rfc2018>.		<http://www.rfc-editor.org/info/rfc2018>.
	skipping to change at page 46, line 11 ¶		skipping to change at page 46, line 11 ¶
	Control Protocol (DCCP) Congestion Control ID 2: TCP-like		Control Protocol (DCCP) Congestion Control ID 2: TCP-like
	Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March		Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March
	2006, <http://www.rfc-editor.org/info/rfc4341>.		2006, <http://www.rfc-editor.org/info/rfc4341>.
	[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for		[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
	Datagram Congestion Control Protocol (DCCP) Congestion		Datagram Congestion Control Protocol (DCCP) Congestion
	Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,		Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
	DOI 10.17487/RFC4342, March 2006,		DOI 10.17487/RFC4342, March 2006,
	<http://www.rfc-editor.org/info/rfc4342>.		<http://www.rfc-editor.org/info/rfc4342>.
	[RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Dynamic Home Agent (HA) Assignment", RFC 4433,		Control Message Protocol (ICMPv6) for the Internet
	DOI 10.17487/RFC4433, March 2006,		Protocol Version 6 (IPv6) Specification", RFC 4443,
	<http://www.rfc-editor.org/info/rfc4433>.		DOI 10.17487/RFC4443, March 2006,
			<http://www.rfc-editor.org/info/rfc4443>.
	[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast		[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
	Congestion Control (TFMCC): Protocol Specification",		Congestion Control (TFMCC): Protocol Specification",
	RFC 4654, DOI 10.17487/RFC4654, August 2006,		RFC 4654, DOI 10.17487/RFC4654, August 2006,
	<http://www.rfc-editor.org/info/rfc4654>.		<http://www.rfc-editor.org/info/rfc4654>.
	[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and		[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
	Parameter for the Stream Control Transmission Protocol		Parameter for the Stream Control Transmission Protocol
	(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,		(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
	<http://www.rfc-editor.org/info/rfc4820>.		<http://www.rfc-editor.org/info/rfc4820>.
	skipping to change at page 48, line 29 ¶		skipping to change at page 48, line 34 ¶
	[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram		[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
	Transport Layer Security (DTLS) for Stream Control		Transport Layer Security (DTLS) for Stream Control
	Transmission Protocol (SCTP)", RFC 6083,		Transmission Protocol (SCTP)", RFC 6083,
	DOI 10.17487/RFC6083, January 2011,		DOI 10.17487/RFC6083, January 2011,
	<http://www.rfc-editor.org/info/rfc6083>.		<http://www.rfc-editor.org/info/rfc6083>.
	[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the		[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the
	TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,		TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
	January 2011, <http://www.rfc-editor.org/info/rfc6093>.		January 2011, <http://www.rfc-editor.org/info/rfc6093>.
			[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
			Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
			DOI 10.17487/RFC6101, August 2011,
			<http://www.rfc-editor.org/info/rfc6101>.
	[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control		[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
	Transmission Protocol (SCTP) Stream Reconfiguration",		Transmission Protocol (SCTP) Stream Reconfiguration",
	RFC 6525, DOI 10.17487/RFC6525, February 2012,		RFC 6525, DOI 10.17487/RFC6525, February 2012,
	<http://www.rfc-editor.org/info/rfc6525>.		<http://www.rfc-editor.org/info/rfc6525>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <http://www.rfc-editor.org/info/rfc6347>.
	[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled		[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
	skipping to change at page 49, line 5 ¶		skipping to change at page 49, line 16 ¶
	Correction (FEC) Framework", RFC 6363,		Correction (FEC) Framework", RFC 6363,
	DOI 10.17487/RFC6363, October 2011,		DOI 10.17487/RFC6363, October 2011,
	<http://www.rfc-editor.org/info/rfc6363>.		<http://www.rfc-editor.org/info/rfc6363>.
	[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.		[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
	Yasevich, "Sockets API Extensions for the Stream Control		Yasevich, "Sockets API Extensions for the Stream Control
	Transmission Protocol (SCTP)", RFC 6458,		Transmission Protocol (SCTP)", RFC 6458,
	DOI 10.17487/RFC6458, December 2011,		DOI 10.17487/RFC6458, December 2011,
	<http://www.rfc-editor.org/info/rfc6458>.		<http://www.rfc-editor.org/info/rfc6458>.
			[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
			NewReno Modification to TCP's Fast Recovery Algorithm",
			RFC 6582, DOI 10.17487/RFC6582, April 2012,
			<http://www.rfc-editor.org/info/rfc6582>.
	[RFC6584] Roca, V., "Simple Authentication Schemes for the		[RFC6584] Roca, V., "Simple Authentication Schemes for the
	Asynchronous Layered Coding (ALC) and NACK-Oriented		Asynchronous Layered Coding (ALC) and NACK-Oriented
	Reliable Multicast (NORM) Protocols", RFC 6584,		Reliable Multicast (NORM) Protocols", RFC 6584,
	DOI 10.17487/RFC6584, April 2012,		DOI 10.17487/RFC6584, April 2012,
	<http://www.rfc-editor.org/info/rfc6584>.		<http://www.rfc-editor.org/info/rfc6584>.
	[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,		[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
	"FLUTE - File Delivery over Unidirectional Transport",		"FLUTE - File Delivery over Unidirectional Transport",
	RFC 6726, DOI 10.17487/RFC6726, November 2012,		RFC 6726, DOI 10.17487/RFC6726, November 2012,
	<http://www.rfc-editor.org/info/rfc6726>.		<http://www.rfc-editor.org/info/rfc6726>.
	[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A		[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A
	Datagram Congestion Control Protocol UDP Encapsulation for		Datagram Congestion Control Protocol UDP Encapsulation for
	NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November		NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November
	2012, <http://www.rfc-editor.org/info/rfc6773>.		2012, <http://www.rfc-editor.org/info/rfc6773>.
			[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
			"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
			DOI 10.17487/RFC6817, December 2012,
			<http://www.rfc-editor.org/info/rfc6817>.
	[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,		[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
	"TCP Extensions for Multipath Operation with Multiple		"TCP Extensions for Multipath Operation with Multiple
	Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,		Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
	<http://www.rfc-editor.org/info/rfc6824>.		<http://www.rfc-editor.org/info/rfc6824>.
	[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application		[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
	Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,		Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
	March 2013, <http://www.rfc-editor.org/info/rfc6897>.		March 2013, <http://www.rfc-editor.org/info/rfc6897>.
	[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and		[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
	skipping to change at page 51, line 35 ¶		skipping to change at page 52, line 7 ¶
	(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-19 (work in		Guidelines", draft-ietf-tsvwg-rfc5405bis-16 (work in
	progress), October 2016.		progress), July 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-
	skipping to change at page 52, line 16 ¶		skipping to change at page 52, line 32 ¶
	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-02 (work in progress), August 2016.		draft-ietf-tcpm-cubic-02 (work in progress), August 2016.
			[I-D.ietf-rtcweb-transports]
			Alvestrand, H., "Transports for WebRTC", draft-ietf-
			rtcweb-transports-15 (work in progress), August 2016.
			[I-D.ietf-tls-tls13]
			Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", draft-ietf-tls-tls13-14 (work in progress),
			July 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
	-- Portable Operating System Interface (POSIX) Base		-- Portable Operating System Interface (POSIX) Base
End of changes. 36 change blocks.
	76 lines changed or deleted		101 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/