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/ |