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/