draft-ietf-taps-transports-13.txt		draft-ietf-taps-transports-14.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: June 8, 2017 M. Kuehlewind, Ed.		Expires: June 9, 2017 M. Kuehlewind, Ed.
	ETH Zurich		ETH Zurich
	December 05, 2016		December 06, 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-13		draft-ietf-taps-transports-14
	Abstract		Abstract
	This document describes, surveys, and classifies the protocol		This document describes, surveys, and classifies the protocol
	mechanisms provided by existing IETF protocols, as background for		mechanisms provided by existing IETF protocols, as background for
	determining a common set of transport services. It examines the		determining a common set of transport services. It examines the
	Transmission Control Protocol (TCP), Multipath TCP, the Stream		Transmission Control Protocol (TCP), Multipath TCP, the Stream
	Control Transmission Protocol (SCTP), the User Datagram Protocol		Control Transmission Protocol (SCTP), the User Datagram Protocol
	(UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the		(UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the
	Internet Control Message Protocol (ICMP), the Realtime Transport		Internet Control Message Protocol (ICMP), the Realtime Transport
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 June 8, 2017.		This Internet-Draft will expire on June 9, 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 7, line 51 ¶		skipping to change at page 8, line 5 ¶
	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 TCP Reset (RST) control message may be used to force a TCP endpoint
			to close a session [RFC0793], aborting the connection.
	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
	[RFC1071] [RFC2460] does not support partial payload protection (as		[RFC1071] [RFC2460] does not support partial payload protection (as
	in DCCP/UDP-Lite).		in DCCP/UDP-Lite).
	TCP supports only unicast connections.		TCP supports only unicast connections.
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 41 ¶
	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		latter encapsulation is used within the WebRTC
	[I-D.ietf-rtcweb-transports] context.		[I-D.ietf-rtcweb-transports] context.
			An SCTP ABORT chunk may be used to force a SCTP endpoint to close a
			session [RFC4960], aborting the connection.
	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
	Threshold, Set Protocol Parameters, and Destroy. The following		Threshold, Set Protocol Parameters, and Destroy. The following
	skipping to change at page 21, line 26 ¶		skipping to change at page 21, line 29 ¶
	unacknowledged segments, to measure RTT, etc. The protocol may		unacknowledged segments, to measure RTT, etc. The protocol may
	support unordered delivery of data, and does not itself provide		support unordered delivery of data, and does not itself provide
	retransmission. DCCP supports reduced checksum coverage, a partial		retransmission. DCCP supports reduced checksum coverage, a partial
	payload protection mechanism similar to UDP-Lite. There is also a		payload protection mechanism similar to UDP-Lite. There is also a
	Data Checksum option, which when enabled, contains a strong CRC, to		Data Checksum option, which when enabled, contains a strong CRC, to
	enable endpoints to detect application data corruption.		enable endpoints to detect application data corruption.
	Receiver flow control is supported, which limits the amount of		Receiver flow control is supported, which limits the amount of
	unacknowledged data that can be outstanding at a given time.		unacknowledged data that can be outstanding at a given time.
			A DCCP Reset packet may be used to force a DCCP endpoint to close a
			session [RFC4340], aborting the connection.
	DCCP supports negotiation of the congestion control profile between		DCCP supports negotiation of the congestion control profile between
	endpoints, to provide plug-and-play congestion control mechanisms.		endpoints, to provide plug-and-play congestion control mechanisms.
	Examples of specified profiles include "TCP-like" [RFC4341], "TCP-		Examples of specified profiles include "TCP-like" [RFC4341], "TCP-
	friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622].		friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622].
	Additional mechanisms are recorded in an IANA registry.		Additional mechanisms are recorded in an IANA registry.
	A lightweight UDP-based encapsulation (DCCP-UDP) has been defined		A lightweight UDP-based encapsulation (DCCP-UDP) has been defined
	[RFC6773] that permits DCCP to be used over paths where DCCP is not		[RFC6773] that permits DCCP to be used over paths where DCCP is not
	natively supported. Support for DCCP in NAPT/NATs is defined in		natively supported. Support for DCCP in NAPT/NATs is defined in
	[RFC4340] and [RFC5595]. Upper layer protocols specified on top of		[RFC4340] and [RFC5595]. Upper layer protocols specified on top of
End of changes. 7 change blocks.
	5 lines changed or deleted		12 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/