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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/