draft-ietf-taps-transports-02.txt		draft-ietf-taps-transports-03.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: August 10, 2015 M. Kuehlewind, Ed.		Expires: August 31, 2015 M. Kuehlewind, Ed.
	ETH Zurich		ETH Zurich
	February 06, 2015		February 27, 2015
	Services provided by IETF transport protocols and congestion control		Services provided by IETF transport protocols and congestion control
	mechanisms		mechanisms
	draft-ietf-taps-transports-02		draft-ietf-taps-transports-03
	Abstract		Abstract
	This document describes services provided by existing IETF protocols		This document describes services provided by existing IETF protocols
	and congestion control mechanisms. It is designed to help		and congestion control mechanisms. It is designed to help
	application and network stack programmers and to inform the work of		application and network stack programmers and to inform the work of
	the IETF TAPS Working Group.		the IETF TAPS Working Group.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 August 10, 2015.		This Internet-Draft will expire on August 31, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 50		skipping to change at page 2, line 50
	2. Terminology		2. Terminology
	The following terms are defined throughout this document, and in		The following terms are defined throughout this document, and in
	subsequent documents produced by TAPS describing the composition and		subsequent documents produced by TAPS describing the composition and
	decomposition of transport services.		decomposition of transport services.
	[NOTE: The terminology below was presented at the TAPS WG meeting in		[NOTE: The terminology below was presented at the TAPS WG meeting in
	Honolulu. While the factoring of the terminology seems		Honolulu. While the factoring of the terminology seems
	uncontroversial, there may be some entities which still require names		uncontroversial, there may be some entities which still require names
	(e.g. information about the interface between the transport and lower		(e.g. information about the interface between the transport and lower
	layers which could lead to the availablity or unavailibility of		layers which could lead to the availability or unavailability of
	certain transport protocol features). Comments are welcome via the		certain transport protocol features). Comments are welcome via the
	TAPS mailing list.]		TAPS mailing list.]
	Transport Service Feature: a specific end-to-end feature that a		Transport Service Feature: a specific end-to-end feature that a
	transport service provides to its clients. Examples include		transport service provides to its clients. Examples include
	confidentiality, reliable delivery, ordered delivery, message-		confidentiality, reliable delivery, ordered delivery, message-
	versus-stream orientation, etc.		versus-stream orientation, etc.
	Transport Service: a set of transport service features, without an		Transport Service: a set of transport service features, without an
	association to any given framing protocol, which provides a		association to any given framing protocol, which provides a
	skipping to change at page 3, line 30		skipping to change at page 3, line 30
	Transport Protocol Component: an implementation of a transport		Transport Protocol Component: an implementation of a transport
	service feature within a protocol.		service feature within a protocol.
	Transport Service Instance: an arrangement of transport protocols		Transport Service Instance: an arrangement of transport protocols
	with a selected set of features and configuration parameters that		with a selected set of features and configuration parameters that
	implements a single transport service, e.g. a protocol stack (RTP		implements a single transport service, e.g. a protocol stack (RTP
	over UDP).		over UDP).
	Application: an entity that uses the transport layer for end-to-end		Application: an entity that uses the transport layer for end-to-end
	delivery data across the network (this may also be an upper layer		delivery data across the network (this may also be an upper layer
	protocol or tunnel encpasulation).		protocol or tunnel encapsulation).
	3. Existing Transport Protocols		3. Existing Transport Protocols
	This section provides a list of known IETF transport protocol and		This section provides a list of known IETF transport protocol and
	transport protocol frameworks.		transport protocol frameworks.
	[EDITOR'S NOTE: Contributions to the subsections below are welcome]		[EDITOR'S NOTE: Contributions to the subsections below are welcome]
	3.1. Transport Control Protocol (TCP)		3.1. Transport Control Protocol (TCP)
	skipping to change at page 6, line 27		skipping to change at page 6, line 27
	decide based on network characteristics?]		decide based on network characteristics?]
	3.2. Multipath TCP (MP-TCP)		3.2. Multipath TCP (MP-TCP)
	[EDITOR'S NOTE: a few sentences describing Multipath TCP [RFC6824] go		[EDITOR'S NOTE: a few sentences describing Multipath TCP [RFC6824] go
	here. Note that this adds transport-layer multihoming to the		here. Note that this adds transport-layer multihoming to the
	components TCP provides]		components TCP provides]
	3.3. Stream Control Transmission Protocol (SCTP)		3.3. Stream Control Transmission Protocol (SCTP)
	SCTP [RFC4960] is an IETF standards track transport protocol that		SCTP is a message oriented standards track transport protocol and the
	provides a bidirectional set of logical unicast meessage streams over		base protocol is specified in [RFC4960]. It supports multi-homing to
	a connection-oriented protocol.		handle path failures. An SCTP association has multiple
	Compared to TCP, this protocol and API use messages, rather than a		unidirectional streams in each direction and provides in-sequence
	byte-stream. Each stream of messages is independently managed,		delivery of user messages only within each stream. This allows to
	therefore retransmission does not hold back data sent using other		minimize head of line blocking. SCTP is extensible and the currently
	logical streams.		defined extensions include mechanisms for dynamic re-configurations
			of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the
	An SCTP Integrity Check is mandatory across the entire packet (it		extension specified in [RFC3758] introduces the concept of partial
	does not support partial corruption protection as in DCCP/UD-Lite).		reliability for user messages.
	The SCTP Partial Reliability Extension (SCTP-PR) is defined in
	[RFC3758].
	SCTP supports PLPMTU discovery using padding chunks to construct path		SCTP was originally developed for transporting telephony signalling
	probes.		messages and is deployed in telephony signalling networks, especially
			in mobile telephony networks. Additionally, it is used in the WebRTC
			framework for data channels and is therefore deployed in all WEB-
			browsers supporting WebRTC.
	[EDITOR'S NOTE: Michael Tuexen and Karen Nielsen signed up as		[EDITOR'S NOTE: Michael Tuexen and Karen Nielsen signed up as
	contributors for these sections.]		contributors for these sections.]
	3.3.1. Protocol Description		3.3.1. Protocol Description
	An SCTP service is unicast.		SCTP is a connection oriented protocol using a four way handshake to
			establish an SCTP association and a three way message exchange to
			gracefully shut it down. It uses the same port number concept as
			DCCP, TCP, UDP, and UDP-Lite do and only supports unicast.
	PLPMTUD is required for SCTP.		SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit
			errors. This is stronger than the 16-bit checksums used by TCP or
			UDP. However, a partial checksum coverage as provided by DCCP or
			UDP-Lite is not supported.
			SCTP has been designed with extensibility in mind. Each SCTP packet
			starts with a single common header containing the port numbers, a
			verification tag and the CRC32c checksum. This common header is
			followed by a sequence of chunks. Each chunk consists of a type
			field, flags, a length field and a value. [RFC4960] defines how a
			receiver processes chunks with an unknown chunk type. The support of
			extensions can be negotiated during the SCTP handshake.
			SCTP provides a message-oriented service. Multiple small user
			messages can be bundled into a single SCTP packet to improve the
			efficiency. User messages which would result in IP packets larger
			than the MTU will be fragmented at the sender side and reassembled at
			the receiver side. There is no protocol limit on the user message
			size. [RFC4821] defines a method to perform packetization layer path
			MTU discovery with probe packets using the padding chunks defined the
			[RFC4820].
			[RFC4960] specifies a TCP friendly congestion control to protect the
			network against overload. SCTP also uses a sliding window flow
			control to protect receivers against overflow.
			Each SCTP association has between 1 and 65536 uni-directional streams
			in each direction. The number of streams can be different in each
			direction. Every user-message is sent on a particular stream. User
			messages can be sent ordered or un-ordered upon request by the upper
			layer. Only all ordered messages sent on the same stream are
			delivered at the receiver in the same order as sent by the sender.
			For user messages not requiring fragmentation, this minimises head of
			line blocking. The base protocol defined in [RFC4960] doesn't allow
			interleaving of user-messages, which results in sending a large
			message on one stream can block the sending of user messages on other
			streams. [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and
			also allows to specify a scheduler for the sender side streams
			selection. The stream re-configuration extension defined in
			[RFC6525] allows to reset streams during the lifetime of an
			association and to increase the number of streams, if the number of
			streams negotiated in the SCTP handshake is not sufficient.
			According to [RFC4960], each user message sent is either delivered to
			the receiver or, in case of excessive retransmissions, the
			association is terminated in a non-graceful way, similar to the TCP
			behaviour. In addition to this reliable transfer, the partial
			reliability extension defined in [RFC3758] allows the sender to
			abandon user messages. The application can specify the policy for
			abandoning user messages. Examples for these policies include:
			o Limiting the time a user message is dealt with by the sender.
			o Limiting the number of retransmissions for each fragment of a user
			message.
			o Abandoning messages of lower priority in case of a send buffer
			shortage.
			SCTP supports multi-homing. Each SCTP end-point uses a list of IP-
			addresses and a single port number. These addresses can be any
			mixture of IPv4 and IPv6 addresses. These addresses are negotiated
			during the handshake and the address re-configuration extension
			specified in [RFC5061] can be used to change these addresses during
			the livetime of an SCTP association. This allows for transport layer
			mobility. Multiple addresses are used for improved resilience. If a
			remote address becomes unreachable, the traffic is switched over to a
			reachable one, if one exists. Each SCTP end-point supervises
			continuously the reachability of all peer addresses using a heartbeat
			mechanism.
			For securing user messages, the use of TLS over SCTP has been
			specified in [RFC3436]. However, this solution does not support all
			services provided by SCTP (for example un-ordered delivery or partial
			reliability), and therefore the use of DTLS over SCTP has been
			specified in [RFC6083] to overcome these limitations. When using
			DTLS over SCTP, the application can use almost all services provided
			by SCTP.
			For legacy NAT traversal, [RFC6951] defines the UDP encapsulation of
			SCTP-packets. Alternatively, SCTP packets can be encapsulated in
			DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The
			latter encapsulation is used with in the WebRTC context.
			Having a well defined API is also a feature provided by SCTP as
			described in the next subsection.
	3.3.2. Interface Description		3.3.2. Interface Description
	The SCTP API is described in the specifications published in the RFC		[RFC4960] defines an abstract API for the base protocol. An
	series.		extension to the BSD Sockets API is defined in [RFC6458] and covers:
			o the base protocol defined in [RFC4960].
			o the SCTP Partial Reliability extension defined in [RFC3758].
			o the SCTP Authentication extension defined in [RFC4895].
			o the SCTP Dynamic Address Reconfiguration extension defined in
			[RFC5061].
			For the following SCTP protocol extensions the BSD Sockets API
			extension is defined in the document specifying the protocol
			extensions:
			o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053].
			o the SCTP Stream Reconfiguration extension defined in [RFC6525].
			o the UDP Encapsulation of SCTP packets extension defined in
			[RFC6951].
			o the additional PR-SCTP policies defined in
			[I-D.ietf-tsvwg-sctp-prpolicies].
			Future documents describing SCTP protocol extensions are expected to
			describe the corresponding BSD Sockets API extension in a "Socket API
			Considerations" section.
			The SCTP socket API supports two kinds of sockets:
			o one-to-one style sockets (by using the socket type "SOCK_STREAM").
			o one-to-many style socket (by using the socket type
			"SOCK_SEQPACKET").
			One-to-one style sockets are similar to TCP sockets, there is a 1:1
			relationship between the sockets and the SCTP associations (except
			for listening sockets). One-to-many style SCTP sockets are similar
			to unconnected UDP sockets as there is a 1:n relationship between the
			sockets and the SCTP associations.
			The SCTP stack can provide information to the applications about
			state changes of the individual paths and the association whenever
			they occur. These events are delivered similar to user messages but
			are specifically marked as notifications.
			A couple of new functions have been introduced to support the use of
			multiple local and remote addresses. Additional SCTP-specific send
			and receive calls have been defined to allow dealing with the SCTP
			specific information without using ancillary data in the form of
			additional cmsgs, which are also defined. These functions provide
			support for detecting partial delivery of user messages and
			notifications.
			The SCTP socket API allows a fine-grained control of the protocol
			behaviour through an extensive set of socket options.
			The SCTP kernel implementations of FreeBSD, Linux and Solaris follow
			mostly the specified extension to the BSD Sockets API for the base
			protocol and the corresponding supported protocol extensions.
	3.3.3. Transport Protocol Components		3.3.3. Transport Protocol Components
	The transport protocol components provided by SCTP are:		The transport protocol components provided by SCTP are:
	o unicast		o unicast
	o connection setup with feature negotiation and application-to-port		o connection setup with feature negotiation and application-to-port
	mapping		mapping
	o port multiplexing		o port multiplexing
	o reliable or partially reliable delivery		o reliable or partially reliable delivery
	o ordered delivery within a stream		o ordered and unordered delivery within a stream
	o support for multiple prioritised streams		o support for multiple prioritised streams
	o flow control (slow receiver function)		o flow control (slow receiver function)
	o message-oriented delivery		o message-oriented delivery
	o congestion control		o congestion control
	o application PDU bundling		o application PDU bundling
			o application PDU fragmentation and reassembly
	o integrity check		o integrity check
			o transport layer multihoming for resilience
			o transport layer mobility
	[EDITOR'S NOTE: update this list.]		[EDITOR'S NOTE: update this list.]
	3.4. User Datagram Protocol (UDP)		3.4. User Datagram Protocol (UDP)
	The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF		The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF
	standards track transport protocol. It provides a uni-directional		standards track transport protocol. It provides a uni-directional,
	minimal message-passing transport that has no inherent congestion		datagram protocol which preserves message boundaries. It provides
	control mechanisms or other transport functions. IETF guidance on		none of the following transport features: error correction,
	the use of UDP is provided in [RFC5405]. UDP is widely implemented		congestion control, or flow control. It can be used to send
	by endpoints and widely used by common applications.		broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in
			addition to unicast (and anycast) datagrams. IETF guidance on the
			use of UDP is provided in[RFC5405]. UDP is widely implemented and
			widely used by common applications, especially DNS.
	[EDITOR'S NOTE: Kevin Fall signed up as a contributor for this		[EDITOR'S NOTE: Kevin Fall signed up as a contributor for this
	section.]		section.]
	3.4.1. Protocol Description		3.4.1. Protocol Description
	UDP is a connection-less datagram protocol, with no connection setup		UDP is a connection-less protocol which maintains message boundaries,
	or feature negotiation. The protocol and API use messages, rather		with no connection setup or feature negotiation. The protocol uses
	than a byte-stream. Each stream of messages is independently		independent messages, ordinarily called datagrams. The lack of error
	managed, therefore retransmission does not hold back data sent using		control and flow control implies messages may be damaged, re-ordered,
	other logical streams.		lost, or duplicated in transit. A receiving application unable to
			run sufficiently fast or frequently may miss messages. The lack of
	It provides multiplexing to multiple sockets on each host using port		congestion handling implies UDP traffic may cause the loss of
	numbers. An active UDP session is identified by its four-tuple of		messages from other protocols (e.g., TCP) when sharing the same
	local and remote IP addresses and local port and remote port numbers.		network paths. UDP traffic can also cause the loss of other UDP
			traffic in the same or other flows for the same reasons.
	UDP maps each data segement into an IP packet, or a sequence of IP
	fragemnts.
	UDP is connectionless. However, applications send a sequence of
	messages that constitute a UDP flow. Therefore mechanisms for
	receiver flow control, congestion control, PathMTU discovery/PLPMTUD,
	support for ECN, etc need to be provided by upper layer protocols
	[RFC5405].
	PMTU discovery and PLPMTU discovery may be used by upper layer
	protocols built on top of UDP [RFC5405].
	For IPv4 the UDP checksum is optional, but recommended for use in the
	general Internet [RFC5405]. [RFC2460] requires the use of this
	checksum for IPv6, but [RFC6935] permits this to be relaxed for
	specific types of application. The checksum support considerations
	for omitting the checksum are defined in [RFC6936].
	This check protects from misdelivery of data corrupted data, but is		Messages with bit errors are ordinarily detected by an invalid end-
	relatively weak, and applications that require end to end integrity		to-end checksum and are discarded before being delivered to an
	of data are recommended to include a stronger integrity check of		application. There are some exceptions to this general rule,
	their payload data.		however. UDP-Lite (see [RFC3828], and below) provides the ability
			for portions of the message contents to be exempt from checksum
			coverage. It is also possible to create UDP datagrams with no
			checksum, and while this is generally discouraged [RFC1122]
			[RFC5405], certain special cases permit its use [RFC6935]. The
			checksum support considerations for omitting the checksum are defined
			in [RFC6936]. Note that due to the relatively weak form of checksum
			used by UDP, applications that require end to end integrity of data
			are recommended to include a stronger integrity check of their
			payload data.
	A UDP service may support IPv4 broadcast, multicast, anycast and		On transmission, UDP encapsulates each datagram into an IP packet,
	unicast, determined by the IP destination address.		which may in turn be fragmented by IP. Applications concerned with
			fragmentation or that have other requirements such as receiver flow
			control, congestion control, PathMTU discovery/PLPMTUD, support for
			ECN, etc need to be provided by protocols other than UDP [RFC5405].
	3.4.2. Interface Description		3.4.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 [RFC5405].		on use of common APIs is provided in [RFC5405].
	Many operating systems also allow a UDP socket to be connected, i.e.,		A UDP endpoint consists of a tuple of (IP address, port number).
	to bind a UDP socket to a specific pair of addresses and ports. This		Demultiplexing using multiple abstract endpoints (sockets) on the
	is similar to the corresponding TCP sockets API functionality.		same IP address are supported. The same socket may be used by a
	However, for UDP, this is only a local operation that serves to		single server to interact with multiple clients (note: this behavior
	simplify the local send/receive functions and to filter the traffic		differs from TCP, which uses a pair of tuples to identify a
	for the specified addresses and ports [RFC5405].		connection). Multiple server instances (processes) binding the same
			socket can cooperate to service multiple clients- the socket
			implementation arranges to not duplicate the same received unicast
			message to multiple server processes.
			Many operating systems also allow a UDP socket to be "connected",
			i.e., to bind a UDP socket to a specific (remote) UDP endpoint.
			Unlike TCP's connect primitive, for UDP, this is only a local
			operation that serves to simplify the local send/receive functions
			and to filter the traffic for the specified addresses and ports
			[RFC5405].
	3.4.3. Transport Protocol Components		3.4.3. Transport Protocol Components
	The transport protocol components provided by UDP are:		The transport protocol components provided by UDP are:
	o unicast		o unidirectional
	o port multiplexing		o port multiplexing
	o IPv4 broadcast, multicast and anycast		o 2-tuple endpoints
	o non-reliable delivery		o IPv4 broadcast, multicast and anycast
	o flow control (slow receiver function)		o IPv6 multicast and anycast
	o non-ordered delivery		o IPv6 jumbograms
	o message-oriented delivery		o message-oriented delivery
	o optional checksum protection.		o error detection (checksum)
			o checksum optional
	3.5. Lightweight User Datagram Protocol (UDP-Lite)		3.5. Lightweight User Datagram Protocol (UDP-Lite)
	The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an		The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an
	IETF standards track transport protocol. UDP-Lite provides a		IETF standards track transport protocol. UDP-Lite provides a
	bidirectional set of logical unicast or multicast message streams		bidirectional set of logical unicast or multicast message streams
	over a datagram protocol. IETF guidance on the use of UDP-Lite is		over a datagram protocol. IETF guidance on the use of UDP-Lite is
	provided in [RFC5405].		provided in [RFC5405].
	[EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this		[EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this
	skipping to change at page 11, line 44		skipping to change at page 15, line 22
	connection. The protocol is defined by a family of RFCs.		connection. The protocol is defined by a family of RFCs.
	It provides multiplexing to multiple sockets on each host using port		It provides multiplexing to multiple sockets on each host using port
	numbers. An active DCCP session is identified by its four-tuple of		numbers. An active DCCP session is identified by its four-tuple of
	local and remote IP addresses and local port and remote port numbers.		local and remote IP addresses and local port and remote port numbers.
	At connection setup, DCCP also exchanges the the service code		At connection setup, DCCP also exchanges the the service code
	[RFC5595] mechanism to allow transport instantiations to indicate the		[RFC5595] mechanism to allow transport instantiations to indicate the
	service treatment that is expected from the network.		service treatment that is expected from the network.
	The protocol segments data into messages, typically sized to fit in		The protocol segments data into messages, typically sized to fit in
	IP packets, but which may be fragemented providing they are less than		IP packets, but which may be fragmented providing they are less than
	the A DCCP interface MAY allow applications to request fragmentation		the A DCCP interface MAY allow applications to request fragmentation
	for packets larger than PMTU, but not larger than the maximum packet		for packets larger than PMTU, but not larger than the maximum packet
	size allowed by the current congestion control mechanism (CCMPS)		size allowed by the current congestion control mechanism (CCMPS)
	[RFC4340].		[RFC4340].
	Each message is identified by a sequence number. The sequence number		Each message is identified by a sequence number. The sequence number
	is used to identify segments in acknowledgments, to detect		is used to identify segments in acknowledgments, to detect
	unacknowledged segments, to measure RTT, etc. The protocol may		unacknowledged segments, to measure RTT, etc. The protocol may
	support ordered or unordered delivery of data, and does not itself		support ordered or unordered delivery of data, and does not itself
	provide retransmission. There is a Data Checksum option, which		provide retransmission. There is a Data Checksum option, which
	skipping to change at page 12, line 45		skipping to change at page 16, line 23
	Upper layer protocols specified on top of DCCP include: DTLS		Upper layer protocols specified on top of DCCP include: DTLS
	[RFC5595], RTP [RFC5672], ICE/SDP [RFC6773].		[RFC5595], RTP [RFC5672], ICE/SDP [RFC6773].
	A DCCP service is unicast.		A DCCP service is unicast.
	A common packet format has allowed tools to evolve that can read and		A common packet format has allowed tools to evolve that can read and
	interpret DCCP packets (e.g. Wireshark).		interpret DCCP packets (e.g. Wireshark).
	3.6.2. Interface Description		3.6.2. Interface Description
	API charactersitics include: - Datagram transmission. - Notification		API characteristics include: - Datagram transmission. - Notification
	of the current maximum packet size. - Send and reception of zero-		of the current maximum packet size. - Send and reception of zero-
	length payloads. - Set the Slow Receiver flow control at areceiver.		length payloads. - Set the Slow Receiver flow control at a receiver.
	- Detct a Slow receiver at the sender.		- Detect a Slow receiver at the sender.
	There is no current API specified in the RFC Series.		There is no current API specified in the RFC Series.
	3.6.3. Transport Protocol Components		3.6.3. Transport Protocol Components
	The transport protocol components provided by DCCP are:		The transport protocol components provided by DCCP are:
	o unicast		o unicast
	o connection setup with feature negotiation and application-to-port		o connection setup with feature negotiation and application-to-port
	skipping to change at page 15, line 14		skipping to change at page 19, line 14
	+-----------------+---------+---------+---------+---------+---------+		+-----------------+---------+---------+---------+---------+---------+
	| Mechanism | UDP | UDP-L | DCCP | SCTP | TCP |		| Mechanism | UDP | UDP-L | DCCP | SCTP | TCP |
	+-----------------+---------+---------+---------+---------+---------+		+-----------------+---------+---------+---------+---------+---------+
	| Unicast | Yes | Yes | Yes | Yes | Yes |		| Unicast | Yes | Yes | Yes | Yes | Yes |
	| | | | | | |		| | | | | | |
	| Mcast/IPv4Bcast | Yes(2) | Yes | No | No | No |		| Mcast/IPv4Bcast | Yes(2) | Yes | No | No | No |
	| | | | | | |		| | | | | | |
	| Port Mux | Yes | Yes | Yes | Yes | Yes |		| Port Mux | Yes | Yes | Yes | Yes | Yes |
	| | | | | | |		| | | | | | |
	| Mode | Dgram | Dgram | Dgram | Stream | Stream |		| Mode | Dgram | Dgram | Dgram | Dgram | Stream |
	| | | | | | |		| | | | | | |
	| Connected | No | No | Yes | Yes | Yes |		| Connected | No | No | Yes | Yes | Yes |
	| | | | | | |		| | | | | | |
	| Data bundling | No | No | No | No | Yes |		| Data bundling | No | No | No | Yes | Yes |
	| | | | | | |		| | | | | | |
	| Feature Nego | No | No | Yes | Yes | Yes |		| Feature Nego | No | No | Yes | Yes | Yes |
	| | | | | | |		| | | | | | |
	| Options | No | No | Support | Support | Support |		| Options | No | No | Support | Support | Support |
	| | | | | | |		| | | | | | |
	| Data priority | * | * | * | Yes | No |		| Data priority | * | * | * | Yes | No |
	| | | | | | |		| | | | | | |
	| Data bundling | No | No | No | No | Yes |		| Data bundling | No | No | No | Yes | Yes |
	| | | | | | |		| | | | | | |
	| Reliability | None | None | None | Select | Full |		| Reliability | None | None | None | Select | Full |
	| | | | | | |		| | | | | | |
	| Ordered deliv | No | No | No | Stream | Yes |		| Ordered deliv | No | No | No | Stream | Yes |
	| | | | | | |		| | | | | | |
	| Corruption Tol. | No | Support | Support | No | No |		| Corruption Tol. | No | Support | Support | No | No |
	| | | | | | |		| | | | | | |
	| Flow Control | No | No | Support | Yes | Yes |		| Flow Control | No | No | Support | Yes | Yes |
	| | | | | | |		| | | | | | |
	| PMTU/PLPMTU | (1) | (1) | Yes | Yes | Yes |		| PMTU/PLPMTU | (1) | (1) | Yes | Yes | Yes |
	| | | | | | |		| | | | | | |
	| Cong Control | (1) | (1) | Yes | Yes | Yes |		| Cong Control | (1) | (1) | Yes | Yes | Yes |
	| | | | | | |		| | | | | | |
	| ECN Support | (1) | (1) | Yes | No | Yes |		| ECN Support | (1) | (1) | Yes | TBD | Yes |
	| | | | | | |		| | | | | | |
	| NAT support | Limited | Limited | Support | TBD | Support |		| NAT support | Limited | Limited | Support | TBD | Support |
	| | | | | | |		| | | | | | |
	| Security | DTLS | DTLS | DTLS | DTLS | TLS, AO |		| Security | DTLS | DTLS | DTLS | DTLS | TLS, AO |
	| | | | | | |		| | | | | | |
	| UDP encaps | N/A | None | Yes | Yes | None |		| UDP encaps | N/A | None | Yes | Yes | None |
	| | | | | | |		| | | | | | |
	| RTP support | Support | Support | Support | ? | Support |		| RTP support | Support | Support | Support | ? | Support |
	+-----------------+---------+---------+---------+---------+---------+		+-----------------+---------+---------+---------+---------+---------+
	skipping to change at page 16, line 23		skipping to change at page 20, line 23
	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
	document does not specify any new components or mechanisms for		document does not specify any new components or mechanisms for
	providing these features. Each RFC listed in this document discusses		providing these features. Each RFC listed in this document discusses
	the security considerations of the specification it contains.		the security considerations of the specification it contains.
	7. Contributors		7. Contributors
	[EDITOR'S NOTE: Non-editor contributors of text will be listed here,		[Editor's Note: turn this into a real contributors section with
	as noted in the authors section.]		addresses once we figure out how to trick the toolchain into doing
			so]
			o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com)
			o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh-
			muenster.de)
	8. Acknowledgments		8. Acknowledgments
	This work is partially supported by the European Commission under		This work is partially supported by the European Commission under
	grant agreement FP7-ICT-318627 mPlane; support does not imply		grant agreement FP7-ICT-318627 mPlane; support does not imply
	endorsement.		endorsement.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	skipping to change at page 17, line 27		skipping to change at page 21, line 33
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP", RFC		of Explicit Congestion Notification (ECN) to IP", RFC
	3168, September 2001.		3168, September 2001.
	[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,		[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
	RFC 3205, February 2002.		RFC 3205, February 2002.
	[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's		[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
	Initial Window", RFC 3390, October 2002.		Initial Window", RFC 3390, October 2002.
			[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
			Layer Security over Stream Control Transmission Protocol",
			RFC 3436, December 2002.
	[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.		[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
	Conrad, "Stream Control Transmission Protocol (SCTP)		Conrad, "Stream Control Transmission Protocol (SCTP)
	Partial Reliability Extension", RFC 3758, May 2004.		Partial Reliability Extension", RFC 3758, May 2004.
	[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and		[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
	G. Fairhurst, "The Lightweight User Datagram Protocol		G. Fairhurst, "The Lightweight User Datagram Protocol
	(UDP-Lite)", RFC 3828, July 2004.		(UDP-Lite)", RFC 3828, July 2004.
	[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement		[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement
	for the Datagram Congestion Control Protocol (DCCP)", RFC		for the Datagram Congestion Control Protocol (DCCP)", RFC
	skipping to change at page 18, line 9		skipping to change at page 22, line 18
	[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,
	March 2006.		March 2006.
	[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap		[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
	for Transmission Control Protocol (TCP) Specification		for Transmission Control Protocol (TCP) Specification
	Documents", RFC 4614, September 2006.		Documents", RFC 4614, September 2006.
			[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
			Parameter for the Stream Control Transmission Protocol
			(SCTP)", RFC 4820, March 2007.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
			[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
			"Authenticated Chunks for the Stream Control Transmission
			Protocol (SCTP)", RFC 4895, August 2007.
	[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC		[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
	4960, September 2007.		4960, September 2007.
			[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
			Kozuka, "Stream Control Transmission Protocol (SCTP)
			Dynamic Address Reconfiguration", RFC 5061, September
			2007.
	[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite		[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite
	protocol", RFC 5097, January 2008.		protocol", RFC 5097, January 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP		[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
	Friendly Rate Control (TFRC): Protocol Specification", RFC		Friendly Rate Control (TFRC): Protocol Specification", RFC
	5348, September 2008.		5348, September 2008.
	skipping to change at page 19, line 5		skipping to change at page 23, line 27
	[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, November 2012.		NAT Traversal", RFC 6773, November 2012.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, June 2010.		Authentication Option", RFC 5925, June 2010.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, September 2009.		Control", RFC 5681, September 2009.
			[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
			Transport Layer Security (DTLS) for Stream Control
			Transmission Protocol (SCTP)", RFC 6083, January 2011.
	[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, January 2011.		TCP Urgent Mechanism", RFC 6093, January 2011.
			[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
			Transmission Protocol (SCTP) Stream Reconfiguration", RFC
			6525, February 2012.
	[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,		[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
	"Computing TCP's Retransmission Timer", RFC 6298, June		"Computing TCP's Retransmission Timer", RFC 6298, June
	2011.		2011.
	[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and		[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
	UDP Checksums for Tunneled Packets", RFC 6935, April 2013.		UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
	[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement		[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
	for the Use of IPv6 UDP Datagrams with Zero Checksums",		for the Use of IPv6 UDP Datagrams with Zero Checksums",
	RFC 6936, April 2013.		RFC 6936, April 2013.
	[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC		[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
	6455, December 2011.		6455, December 2011.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, January 2012.
			[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
			Yasevich, "Sockets API Extensions for the Stream Control
			Transmission Protocol (SCTP)", RFC 6458, December 2011.
	[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",		[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
	RFC 6691, July 2012.		RFC 6691, July 2012.
	[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, January 2013.		Addresses", RFC 6824, January 2013.
			[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
			Control Transmission Protocol (SCTP) Packets for End-Host
			to End-Host Communication", RFC 6951, May 2013.
			[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
			IMMEDIATELY Extension for the Stream Control Transmission
			Protocol", RFC 7053, November 2013.
	[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.		[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
	Scheffenegger, "TCP Extensions for High Performance", RFC		Scheffenegger, "TCP Extensions for High Performance", RFC
	7323, September 2014.		7323, September 2014.
	[I-D.ietf-aqm-ecn-benefits]		[I-D.ietf-aqm-ecn-benefits]
	Welzl, M. and G. Fairhurst, "The Benefits and Pitfalls of		Welzl, M. and G. Fairhurst, "The Benefits and Pitfalls of
	using Explicit Congestion Notification (ECN)", draft-ietf-		using Explicit Congestion Notification (ECN)", draft-ietf-
	aqm-ecn-benefits-00 (work in progress), October 2014.		aqm-ecn-benefits-00 (work in progress), October 2014.
			[I-D.ietf-tsvwg-sctp-dtls-encaps]
			Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
			Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
			dtls-encaps-09 (work in progress), January 2015.
			[I-D.ietf-tsvwg-sctp-prpolicies]
			Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
			"Additional Policies for the Partial Reliability Extension
			of the Stream Control Transmission Protocol", draft-ietf-
			tsvwg-sctp-prpolicies-07 (work in progress), February
			2015.
			[I-D.ietf-tsvwg-sctp-ndata]
			Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
			"Stream Schedulers and a New Data Chunk for the Stream
			Control Transmission Protocol", draft-ietf-tsvwg-sctp-
			ndata-02 (work in progress), January 2015.
	Authors' Addresses		Authors' Addresses
	Godred Fairhurst (editor)		Godred Fairhurst (editor)
	University of Aberdeen		University of Aberdeen
	School of Engineering, Fraser Noble Building		School of Engineering, Fraser Noble Building
	Aberdeen AB24 3UE		Aberdeen AB24 3UE
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
	Brian Trammell (editor)		Brian Trammell (editor)
	ETH Zurich		ETH Zurich
	Gloriastrasse 35		Gloriastrasse 35
	8092 Zurich		8092 Zurich
	Switzerland		Switzerland
	Email: ietf@trammell.ch		Email: ietf@trammell.ch
	Mirja Kuehlewind (editor)		Mirja Kuehlewind (editor)
	ETH Zurich		ETH Zurich
End of changes. 43 change blocks.
	86 lines changed or deleted		312 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/