draft-ietf-taps-transports-01.txt | draft-ietf-taps-transports-02.txt | |||
---|---|---|---|---|
Network Working Group G. Fairhurst, Ed. | Network Working Group G. Fairhurst, Ed. | |||
Internet-Draft University of Aberdeen | Internet-Draft University of Aberdeen | |||
Intended status: Informational B. Trammell, Ed. | Intended status: Informational B. Trammell, Ed. | |||
Expires: June 22, 2015 M. Kuehlewind, Ed. | Expires: August 10, 2015 M. Kuehlewind, Ed. | |||
ETH Zurich | ETH Zurich | |||
December 19, 2014 | February 06, 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-01 | draft-ietf-taps-transports-02 | |||
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 June 22, 2015. | This Internet-Draft will expire on August 10, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
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 | |||
skipping to change at page 2, line 46 | skipping to change at page 2, line 46 | |||
multiple stream, because it can accept blocks of data out of order, | multiple stream, because it can accept blocks of data out of order, | |||
UDP-Lite provides partial integrity protection, and LEDBAT can | UDP-Lite provides partial integrity protection, and LEDBAT can | |||
provide low-priority "scavenger" communication. | provide low-priority "scavenger" communication. | |||
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. | |||
[Editor Note: The terminology below was presented at the TAPS WG | [NOTE: The terminology below was presented at the TAPS WG meeting in | |||
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 availablity or unavailibility 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. | |||
skipping to change at page 3, line 37 | skipping to change at page 3, line 37 | |||
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 encpasulation). | |||
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 Note: Contributions to the sections in the list below are | [EDITOR'S NOTE: Contributions to the subsections below are welcome] | |||
welcome] | ||||
3.1. Transport Control Protocol (TCP) | 3.1. Transport Control Protocol (TCP) | |||
TCP is an IETF standards track transport protocol. [RFC0793] | TCP is an IETF standards track transport protocol. [RFC0793] | |||
introduces TCP as follows: "The Transmission Control Protocol (TCP) | introduces TCP as follows: "The Transmission Control Protocol (TCP) | |||
is intended for use as a highly reliable host-to-host protocol | is intended for use as a highly reliable host-to-host protocol | |||
between hosts in packet-switched computer communication networks, and | between hosts in packet-switched computer communication networks, and | |||
in interconnected systems of such networks." Since its introduction, | in interconnected systems of such networks." Since its introduction, | |||
TCP has become the default connection-oriented, stream-based | TCP has become the default connection-oriented, stream-based | |||
transport protocol in the Internet. It is widely implemented by | transport protocol in the Internet. It is widely implemented by | |||
skipping to change at page 4, line 15 | skipping to change at page 4, line 15 | |||
3.1.1. Protocol Description | 3.1.1. Protocol Description | |||
TCP is a connection-oriented protocol, providing a three way | TCP is a connection-oriented protocol, providing a three way | |||
handshake to allow a client and server to set up a connection, and | handshake to allow a client and server to set up a connection, and | |||
mechanisms for orderly completion and immediate teardown of a | mechanisms for orderly completion and immediate teardown of a | |||
connection. TCP is defined by a family of RFCs [RFC4614]. | connection. TCP is defined by a family of RFCs [RFC4614]. | |||
TCP provides multiplexing to multiple sockets on each host using port | TCP provides multiplexing to multiple sockets on each host using port | |||
numbers. An active TCP session is identified by its four-tuple of | numbers. An active TCP 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. | |||
The destination port during connection setup has a different role as | ||||
it is often used to indicate the requested service. | ||||
TCP partitions a continuous stream of bytes into segments, sized to | TCP partitions a continuous stream of bytes into segments, sized to | |||
fit in IP packets, constrained by the maximum size of lower layer | fit in IP packets. ICMP-based PathMTU discovery [RFC1191][RFC1981] | |||
frame. PathMTU discovery is supported. Each byte in the stream is | as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] | |||
identified by a sequence number. The sequence number is used to | are supported. | |||
order segments on receipt, to identify segments in acknowledgments, | ||||
and to detect unacknowledged segments for retransmission. This is | Each byte in the stream is identified by a sequence number. The | |||
the basis of TCP's reliable, ordered delivery of data in a stream. | sequence number is used to order segments on receipt, to identify | |||
TCP Selective Acknowledgment [RFC2018] extends this mechanism by | segments in acknowledgments, and to detect unacknowledged segments | |||
making it possible to identify missing segments more precisely, | for retransmission. This is the basis of TCP's reliable, ordered | |||
reducing spurious retransmission. | delivery of data in a stream. TCP Selective Acknowledgment [RFC2018] | |||
extends this mechanism by making it possible to identify missing | ||||
segments more precisely, reducing spurious retransmission. | ||||
Receiver flow control is provided by a sliding window: limiting the | Receiver flow control is provided by a sliding window: limiting the | |||
amount of unacknowledged data that can be outstanding at a given | amount of unacknowledged data that can be outstanding at a given | |||
time. The window scale option [RFC7323] allows a receiver to use | time. The window scale option [RFC7323] allows a receiver to use | |||
windows greater than 64KB. | windows greater than 64KB. | |||
All TCP senders provide Congestion Control: This uses a separate | All TCP senders provide Congestion Control: This uses a separate | |||
window, where each time congestion is detected, this congestion | window, where each time congestion is detected, this congestion | |||
window is reduced. A receiver detects congestion using one of three | window is reduced. A receiver detects congestion using one of three | |||
mechanisms: A retransmission timer, loss (interpreted as a congestion | mechanisms: A retransmission timer, detection of loss (interpreted as | |||
signal), and Explicit Congestion Notification (ECN) [RFC3168] to | a congestion signal), or Explicit Congestion Notification (ECN) | |||
provide early signaling (see [I-D.ietf-aqm-ecn-benefits]) | [RFC3168] to provide early signaling (see | |||
[I-D.ietf-aqm-ecn-benefits]) | ||||
A TCP protocol instance can be extended [RFC4614] and tuned. Some | A TCP protocol instance can be extended [RFC4614] and tuned. Some | |||
features are sender-side only, requiring no negotiation with the | features are sender-side only, requiring no negotiation with the | |||
receiver; some are receiver-side only, some are explicitly negotiated | receiver; some are receiver-side only, some are explicitly negotiated | |||
during connection setup. | during connection setup. | |||
By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] | By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] | |||
to buffer data at the sender into large segments, potentially | to buffer data at the sender into large segments, potentially | |||
incurring sender-side buffering delay; this algorithm can be disabled | incurring sender-side buffering delay; this algorithm can be disabled | |||
by the sender to transmit more immediately, e.g. to enable smoother | by the sender to transmit more immediately, e.g. to enable smoother | |||
interactive sessions. | interactive sessions. | |||
[EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD | ||||
NOT use due to the range of TCP implementations that process TCP | ||||
urgent indications differently.) ] | ||||
A checksum provides an Integrity Check and is mandatory across the | ||||
entire packet. The TCP checksum does not support partial corruption | ||||
protection as in DCCP/UDP-Lite). This check protects from | ||||
misdelivery of data corrupted data, but is relatively weak, and | ||||
applications that require end to end integrity of data are | ||||
recommended to include a stronger integrity check of their payload | ||||
data. | ||||
A TCP service is unicast. | A TCP service is unicast. | |||
3.1.2. Interface description | 3.1.2. Interface description | |||
A TCP API is defined in [REF], but there is currently no API | A User/TCP Interface is defined in [RFC0793] providing six user | |||
specified in the RFC series. | commands: Open, Send, Receive, Close, Status. This interface does | |||
not describe configuration of TCP options or parameters beside use of | ||||
the PUSH and URGENT flags. | ||||
In API implementations derived from the BSD Sockets API, TCP sockets | In API implementations derived from the BSD Sockets API, TCP sockets | |||
are created using the "SOCK_STREAM" socket type. | are created using the "SOCK_STREAM" socket type. | |||
The features used by a protocol instance may be set and tuned via | The features used by a protocol instance may be set and tuned via | |||
this API. | this API. | |||
(more on the API goes here) | (more on the API goes here) | |||
3.1.3. Transport Protocol Components | 3.1.3. Transport Protocol Components | |||
The transport protocol components provided by TCP are: | The transport protocol components provided by TCP are: | |||
o unicast | o unicast | |||
o connection-oriented setup with feature negotiation | o connection setup with feature negotiation and application-to-port | |||
mapping | ||||
o port multiplexing | o port multiplexing | |||
o reliable delivery | o reliable delivery | |||
o ordered delivery | o ordered delivery for each byte stream | |||
o segmented, stream-oriented delivery in a single stream | o error detection (checksum) | |||
o segmentation | ||||
o stream-oriented delivery in a single stream | ||||
o data bundling (Nagle's algorithm) | ||||
o flow control | ||||
o congestion control | o congestion control | |||
(discussion of how to map this to features and TAPS: what does the | [EDITOR'S NOTE: discussion of how to map this to features and TAPS: | |||
higher layer need to decide? what can the transport layer decide | what does the higher layer need to decide? what can the transport | |||
based on global settings? what must the transport layer decide based | layer decide based on global settings? what must the transport layer | |||
on network characteristics?) | decide based on network characteristics?] | |||
3.2. Multipath TCP (MP-TCP) | 3.2. Multipath TCP (MP-TCP) | |||
[Editor 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 [RFC4960] is an IETF standards track transport protocol that | |||
provides a bidirectional s set of logical unicast meessage streams | provides a bidirectional set of logical unicast meessage streams over | |||
over a connection-oriented protocol. The protocol and API use | a connection-oriented protocol. | |||
messages, rather than a byte-stream. Each stream of messages is | Compared to TCP, this protocol and API use messages, rather than a | |||
independently managed, therefore retransmission does not hold back | byte-stream. Each stream of messages is independently managed, | |||
data sent using other logical streams. | therefore retransmission does not hold back data sent using other | |||
logical streams. | ||||
An SCTP Integrity Check is mandatory across the entire packet (it | ||||
does not support partial corruption protection as in DCCP/UD-Lite). | ||||
The SCTP Partial Reliability Extension (SCTP-PR) is defined in | The SCTP Partial Reliability Extension (SCTP-PR) is defined in | |||
[RFC3758]. | [RFC3758]. | |||
SCTP supports PLPMTU discovery using padding chunks to construct path | ||||
probes. | ||||
[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. | An SCTP service is unicast. | |||
PLPMTUD is required for SCTP. | ||||
3.3.2. Interface Description | 3.3.2. Interface Description | |||
The SCTP API is described in the specifications published in the RFC | The SCTP API is described in the specifications published in the RFC | |||
series. | series. | |||
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-oriented setup with feature negotiation | o connection setup with feature negotiation and application-to-port | |||
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 delivery within a stream | |||
o support for multiple prioritised streams | o support for multiple prioritised streams | |||
o flow control (slow receiver function) | ||||
o message-oriented delivery | o message-oriented delivery | |||
o congestion control | o congestion control | |||
[EDITOR'S NOTE: Please update list.] | o application PDU bundling | |||
o integrity check | ||||
[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 | minimal message-passing transport that has no inherent congestion | |||
control mechanisms or other transport functions. IETF guidance on | control mechanisms or other transport functions. IETF guidance on | |||
the use of UDP is provided in [RFC5405]. UDP is widely implemented | the use of UDP is provided in [RFC5405]. UDP is widely implemented | |||
by endpoints and widely used by common applications. | by endpoints and widely used by common applications. | |||
skipping to change at page 7, line 20 | skipping to change at page 8, line 17 | |||
UDP is a connection-less datagram protocol, with no connection setup | UDP is a connection-less datagram protocol, with no connection setup | |||
or feature negotiation. The protocol and API use messages, rather | or feature negotiation. The protocol and API use messages, rather | |||
than a byte-stream. Each stream of messages is independently | than a byte-stream. Each stream of messages is independently | |||
managed, therefore retransmission does not hold back data sent using | managed, therefore retransmission does not hold back data sent using | |||
other logical streams. | other logical streams. | |||
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 UDP session is identified by its four-tuple of | numbers. An active UDP 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. | |||
UDP fragments packets into IP packets, constrained by the maximum | UDP maps each data segement into an IP packet, or a sequence of IP | |||
size of lower layer frame. | fragemnts. | |||
Mechanisms for receiver flow control, congestion control, PathMTU | UDP is connectionless. However, applications send a sequence of | |||
discovery, support for ECN, etc need to be provided by upper layer | messages that constitute a UDP flow. Therefore mechanisms for | |||
protocols [RFC5405]. | 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 | For IPv4 the UDP checksum is optional, but recommended for use in the | |||
general Internet [RFC5405]. [RFC2460] requires the use of this | general Internet [RFC5405]. [RFC2460] requires the use of this | |||
checksum for IPv6, but [RFC6935] permits this to be relaxed for | checksum for IPv6, but [RFC6935] permits this to be relaxed for | |||
specific types of application. The checksum support considerations | specific types of application. The checksum support considerations | |||
for omitting the checksum are defined in [RFC6936]. | for omitting the checksum are defined in [RFC6936]. | |||
This check protects from misdelivery of data corrupted data, but is | ||||
relatively weak, and 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 | A UDP service may support IPv4 broadcast, multicast, anycast and | |||
unicast. | unicast, determined by the IP destination address. | |||
3.4.2. Interface Description | 3.4.2. Interface Description | |||
There is no current API specified in the RFC Series, but guidance on | [RFC0768] describes basic requirements for an API for UDP. Guidance | |||
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., | ||||
to bind a UDP socket to a specific pair of addresses and ports. This | ||||
is similar to the corresponding TCP sockets API functionality. | ||||
However, 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 unicast | |||
o port multiplexing | ||||
o IPv4 broadcast, multicast and anycast | o IPv4 broadcast, multicast and anycast | |||
o non-reliable, non-ordered delivery | o non-reliable delivery | |||
o flow control (slow receiver function) | ||||
o non-ordered delivery | ||||
o message-oriented delivery | o message-oriented delivery | |||
o optional checksum protection. | o optional checksum protection. | |||
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]. | |||
skipping to change at page 8, line 20 | skipping to change at page 9, line 41 | |||
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 | |||
section.] | section.] | |||
3.5.1. Protocol Description | 3.5.1. Protocol Description | |||
UDP-Lite is a connection-less datagram protocol, with no connection | UDP-Lite is a connection-less datagram protocol, with no connection | |||
setup or feature negotiation. The protocol and API use messages, | setup or feature negotiation. The protocol use messages, rather than | |||
rather than a byte-stream. Each stream of messages is independently | a byte-stream. Each stream of messages is independently managed, | |||
managed, therefore retransmission does not hold back data sent using | therefore retransmission does not hold back data sent using other | |||
other logical streams. | logical streams. | |||
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 UDP-Lite session is identified by its four-tuple | numbers. An active UDP-Lite session is identified by its four-tuple | |||
of local and remote IP addresses and local port and remote port | of local and remote IP addresses and local port and remote port | |||
numbers. | numbers. | |||
UDP-Lite fragments packets into IP packets, constrained by the | UDP-Lite fragments packets into IP packets, constrained by the | |||
maximum size of lower layer frame. | maximum size of IP packet. | |||
UDP-Lite changes the semantics of the UDP "payload length" field to | UDP-Lite changes the semantics of the UDP "payload length" field to | |||
that of a "checksum coverage length" field. Otherwise, UDP-Lite is | that of a "checksum coverage length" field. Otherwise, UDP-Lite is | |||
semantically identical to UDP. Applications using UDP-Lite therefore | semantically identical to UDP. Applications using UDP-Lite therefore | |||
can not make assumptions regarding the correctness of the data | can not make assumptions regarding the correctness of the data | |||
received in the insensitive part of the UDP-Lite payload. | received in the insensitive part of the UDP-Lite payload. | |||
As for UDP, mechanisms for receiver flow control, congestion control, | As for UDP, mechanisms for receiver flow control, congestion control, | |||
PathMTU discovery, support for ECN, etc need to be provided by upper | PMTU or PLPMTU discovery, support for ECN, etc need to be provided by | |||
layer protocols [RFC5405]. | upper layer protocols [RFC5405]. | |||
Examples of use include a class of applications that can derive | Examples of use include a class of applications that can derive | |||
benefit from having partially-damaged payloads delivered, rather than | benefit from having partially-damaged payloads delivered, rather than | |||
discarded. One use is to support are tolerate payload corruption and | discarded. One use is to support error tolerate payload corruption | |||
over paths that include error-prone links, another application is | when used over paths that include error-prone links, another | |||
when header integrity checks are required but payload integrity is | application is when header integrity checks are required, but payload | |||
provided by some other mechanism (e.g. [RFC6936]. | integrity is provided by some other mechanism (e.g. [RFC6936]. | |||
A UDP-Lite service may support IPv4 broadcast, multicast, anycast and | A UDP-Lite service may support IPv4 broadcast, multicast, anycast and | |||
unicast. | unicast. | |||
3.5.2. Interface Description | 3.5.2. Interface Description | |||
There is no current API specified in the RFC Series, but guidance on | There is no current API specified in the RFC Series, but guidance on | |||
use of common APIs is provided in [RFC5405]. | use of common APIs is provided in [RFC5405]. | |||
The interface of UDP-Lite differs from that of UDP by the addition of | The interface of UDP-Lite differs from that of UDP by the addition of | |||
skipping to change at page 9, line 25 | skipping to change at page 10, line 48 | |||
the application via the UDP-Lite MIB module [RFC5097]. | the application via the UDP-Lite MIB module [RFC5097]. | |||
3.5.3. Transport Protocol Components | 3.5.3. Transport Protocol Components | |||
The transport protocol components provided by UDP-Lite are: | The transport protocol components provided by UDP-Lite are: | |||
o unicast | o unicast | |||
o IPv4 broadcast, multicast and anycast | o IPv4 broadcast, multicast and anycast | |||
o port multiplexing | ||||
o non-reliable, non-ordered delivery | o non-reliable, non-ordered delivery | |||
o message-oriented delivery | o message-oriented delivery | |||
o partial integrity protection | o partial integrity protection | |||
3.6. Datagram Congestion Control Protocol (DCCP) | 3.6. Datagram Congestion Control Protocol (DCCP) | |||
Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF | Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF | |||
standards track bidirectional transport protocol that provides | standards track bidirectional transport protocol that provides | |||
unicast connections of congestion-controlled unreliable messages. | unicast connections of congestion-controlled unreliable messages. | |||
DCCP is suitable for applications that transfer fairly large amounts | ||||
of data and that can benefit from control over the trade off between | ||||
timeliness and reliability [RFC4336]. | ||||
[EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this | [EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this | |||
section.] | section.] | |||
The DCCP Problem Statement describes the goals that DCCP sought to | ||||
address [RFC4336]. It is suitable for applications that transfer | ||||
fairly large amounts of data and that can benefit from control over | ||||
the trade off between timeliness and reliability [RFC4336]. | ||||
It offers low overhead, and many characteristics common to UDP, but | ||||
can avoid "Re-inventing the wheel" each time a new multimedia | ||||
application emerges. Specifically it includes core functions | ||||
(feature negotiation, path state management, RTT calculation, PMTUD, | ||||
etc): This allows applications to use a compatible method defining | ||||
how they send packets and where suitable to choose common algorithms | ||||
to manage their functions. Examples of suitable applications include | ||||
interactive applications, streaming media or on-line games [RFC4336]. | ||||
3.6.1. Protocol Description | 3.6.1. Protocol Description | |||
DCCP is a connection-oriented datagram protocol, providing a three | DCCP is a connection-oriented datagram protocol, providing a three | |||
way handshake to allow a client and server to set up a connection, | way handshake to allow a client and server to set up a connection, | |||
and mechanisms for orderly completion and immediate teardown of a | and mechanisms for orderly completion and immediate teardown of a | |||
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. | |||
skipping to change at page 10, line 4 | skipping to change at page 11, line 39 | |||
3.6.1. Protocol Description | 3.6.1. Protocol Description | |||
DCCP is a connection-oriented datagram protocol, providing a three | DCCP is a connection-oriented datagram protocol, providing a three | |||
way handshake to allow a client and server to set up a connection, | way handshake to allow a client and server to set up a connection, | |||
and mechanisms for orderly completion and immediate teardown of a | and mechanisms for orderly completion and immediate teardown of a | |||
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, sized to fit in IP packets, | The protocol segments data into messages, typically sized to fit in | |||
constrained by the maximum size of lower layer frame. Each message | IP packets, but which may be fragemented providing they are less than | |||
is identified by a sequence number. The sequence number is used to | the A DCCP interface MAY allow applications to request fragmentation | |||
identify segments in acknowledgments, to detect unacknowledged | for packets larger than PMTU, but not larger than the maximum packet | |||
segments, to measure RTT, etc. The protocol may support ordered or | size allowed by the current congestion control mechanism (CCMPS) | |||
unordered delivery of data, and does not itself provide | [RFC4340]. | |||
retransmission. | ||||
Each message is identified by a sequence number. The sequence number | ||||
is used to identify segments in acknowledgments, to detect | ||||
unacknowledged segments, to measure RTT, etc. The protocol may | ||||
support ordered or unordered delivery of data, and does not itself | ||||
provide retransmission. There is a Data Checksum option, which | ||||
contains a strong CRC, lets endpoints detect application data | ||||
corruption. It also supports reduced checksum coverage, a partial | ||||
integrity mechanisms similar to UDP-lIte. | ||||
Receiver flow control is supported: limiting the amount of | Receiver flow control is supported: limiting the amount of | |||
unacknowledged data that can be outstanding at a given time. | unacknowledged data that can be outstanding at a given time. | |||
A DCCP protocol instance can be extended [RFC4340] and tuned. Some | A DCCP protocol instance can be extended [RFC4340] and tuned. Some | |||
features are sender-side only, requiring no negotiation with the | features are sender-side only, requiring no negotiation with the | |||
receiver; some are receiver-side only, some are explicitly negotiated | receiver; some are receiver-side only, some are explicitly negotiated | |||
during connection setup. | during connection setup. | |||
DCCP supports negotiation of the congestion control profile, examples | DCCP supports negotiation of the congestion control profile, to | |||
of specified profiles include [RFC4341] [RFC4342] [RFC5662]. All | provide Plug and Play congestion control mechanisms. examples of | |||
IETF-defined methods provide Congestion Control. | specified profiles include [RFC4341] [RFC4342] [RFC5662]. All IETF- | |||
defined methods provide Congestion Control. | ||||
Examples of suitable applications include interactive applications, | DCCP use a Connect packet to start a session, and permits half- | |||
streaming media or on-line games [RFC4336]. | connections that allow each client to choose features it wishes to | |||
support. Simultaneous open [RFC5596], as in TCP, can enable | ||||
interoperability in the presence of middleboxes. The Connect packet | ||||
includes a Service Code field [RFC5595] designed to allow middle | ||||
boxes and endpoints to identify the characteristics required by a | ||||
session. A lightweight UDP-based encapsulation (DCCP-UDP) has been | ||||
defined [RFC6773] that permits DCCP to be used over paths where it is | ||||
not natively supported. Support in NAPT/NATs is defined in [RFC4340] | ||||
and [RFC5595]. | ||||
Upper layer protocols specified on top of DCCP include: DTLS | ||||
[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 | ||||
interpret DCCP packets (e.g. Wireshark). | ||||
3.6.2. Interface Description | 3.6.2. Interface Description | |||
API charactersitics include: - Datagram transmission. - Notification | ||||
of the current maximum packet size. - Send and reception of zero- | ||||
length payloads. - Set the Slow Receiver flow control at areceiver. | ||||
- Detct 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-oriented setup | o connection setup with feature negotiation and application-to-port | |||
mapping | ||||
o feature negotiation | o Service Codes | |||
o port multiplexing | ||||
o non-reliable, ordered delivery | o non-reliable, ordered delivery | |||
o flow control (slow receiver function) | ||||
o drop notification | ||||
o timestamps | ||||
o message-oriented delivery | o message-oriented delivery | |||
o partial integrity protection | o partial integrity protection | |||
3.7. Realtime Transport Protocol (RTP) | 3.7. Realtime Transport Protocol (RTP) | |||
RTP provides an end-to-end network transport service, suitable for | RTP provides an end-to-end network transport service, suitable for | |||
applications transmitting real-time data, such as audio, video or | applications transmitting real-time data, such as audio, video or | |||
data, over multicast or unicast network services, including TCP, UDP, | data, over multicast or unicast network services, including TCP, UDP, | |||
UDP-Lite, DCCP. | UDP-Lite, DCCP. | |||
[EDITOR'S NOTE: Varun Singh signed up as contributor for this | [EDITOR'S NOTE: Varun Singh signed up as contributor for this | |||
section.] | section.] | |||
3.8. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a | 3.8. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a | |||
pseudotransport | pseudo transport | |||
(A few words on TLS [RFC5246] and DTLS [RFC6347] here, and how they | [NOTE: A few words on TLS [RFC5246] and DTLS [RFC6347] here, and how | |||
get used by other protocols to meet security goals as an add-on | they get used by other protocols to meet security goals as an add-on | |||
interlayer above transport.) | interlayer above transport.] | |||
3.8.1. Protocol Description | 3.8.1. Protocol Description | |||
3.8.2. Interface Description | 3.8.2. Interface Description | |||
3.8.3. Transport Protocol Components | 3.8.3. Transport Protocol Components | |||
3.9. Hypertext Transport Protocol (HTTP) as a pseudotransport | 3.9. Hypertext Transport Protocol (HTTP) as a pseudotransport | |||
[RFC3205] | [RFC3205] | |||
[EDITOR'S NOTE: No identified contributor for this section yet.] | ||||
3.9.1. Protocol Description | 3.9.1. Protocol Description | |||
3.9.2. Interface Description | 3.9.2. Interface Description | |||
3.9.3. Transport Protocol Components | 3.9.3. Transport Protocol Components | |||
3.10. WebSockets | 3.10. WebSockets | |||
[RFC6455] | [RFC6455] | |||
[EDITOR'S NOTE: No identified contributor for this section yet.] | ||||
3.10.1. Protocol Description | 3.10.1. Protocol Description | |||
3.10.2. Interface Description | 3.10.2. Interface Description | |||
3.10.3. Transport Protocol Components | 3.10.3. Transport Protocol Components | |||
4. Transport Service Features | 4. Transport Service Features | |||
(drawn from the candidate features provided by protocol components in | [EDITOR'S NOTE: this section will drawn from the candidate features | |||
the previous section - please discussion on list) | provided by protocol components in the previous section - please | |||
discuss on taps@ietf.org list] | ||||
4.1. Complete Protocol Feature Matrix | 4.1. Complete Protocol Feature Matrix | |||
(a comprehensive matrix table goes here; Volunteer: Dave Thaler) | [EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this | |||
section. Michael Welzl also has a beginning of a matrix which could | ||||
be useful here.] | ||||
[EDITOR'S NOTE: The below is a strawman proposal below by Gorry | ||||
Fairhurst for initial discussion] | ||||
The table below summarises protocol mechanisms that have been | ||||
standardised. It does not make an assessment on whether specific | ||||
implementations are fully compliant to these specifications. | ||||
+-----------------+---------+---------+---------+---------+---------+ | ||||
| Mechanism | UDP | UDP-L | DCCP | SCTP | TCP | | ||||
+-----------------+---------+---------+---------+---------+---------+ | ||||
| Unicast | Yes | Yes | Yes | Yes | Yes | | ||||
| | | | | | | | ||||
| Mcast/IPv4Bcast | Yes(2) | Yes | No | No | No | | ||||
| | | | | | | | ||||
| Port Mux | Yes | Yes | Yes | Yes | Yes | | ||||
| | | | | | | | ||||
| Mode | Dgram | Dgram | Dgram | Stream | Stream | | ||||
| | | | | | | | ||||
| Connected | No | No | Yes | Yes | Yes | | ||||
| | | | | | | | ||||
| Data bundling | No | No | No | No | Yes | | ||||
| | | | | | | | ||||
| Feature Nego | No | No | Yes | Yes | Yes | | ||||
| | | | | | | | ||||
| Options | No | No | Support | Support | Support | | ||||
| | | | | | | | ||||
| Data priority | * | * | * | Yes | No | | ||||
| | | | | | | | ||||
| Data bundling | No | No | No | No | Yes | | ||||
| | | | | | | | ||||
| Reliability | None | None | None | Select | Full | | ||||
| | | | | | | | ||||
| Ordered deliv | No | No | No | Stream | Yes | | ||||
| | | | | | | | ||||
| Corruption Tol. | No | Support | Support | No | No | | ||||
| | | | | | | | ||||
| Flow Control | No | No | Support | Yes | Yes | | ||||
| | | | | | | | ||||
| PMTU/PLPMTU | (1) | (1) | Yes | Yes | Yes | | ||||
| | | | | | | | ||||
| Cong Control | (1) | (1) | Yes | Yes | Yes | | ||||
| | | | | | | | ||||
| ECN Support | (1) | (1) | Yes | No | Yes | | ||||
| | | | | | | | ||||
| NAT support | Limited | Limited | Support | TBD | Support | | ||||
| | | | | | | | ||||
| Security | DTLS | DTLS | DTLS | DTLS | TLS, AO | | ||||
| | | | | | | | ||||
| UDP encaps | N/A | None | Yes | Yes | None | | ||||
| | | | | | | | ||||
| RTP support | Support | Support | Support | ? | Support | | ||||
+-----------------+---------+---------+---------+---------+---------+ | ||||
Note (1): this feature requires support in an upper layer protocol. | ||||
Note (2): this feature requires support in an upper layer protocol | ||||
when used with IPv6. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
This document has no considerations for IANA. | This document has no considerations for IANA. | |||
6. Security Considerations | 6. 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 | |||
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 | |||
Non-editor contributors of text will be listed here, as in the | [EDITOR'S NOTE: Non-editor contributors of text will be listed here, | |||
authors section. | as noted in the authors section.] | |||
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 13, line 11 | skipping to change at page 17, line 5 | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | |||
793, September 1981. | 793, September 1981. | |||
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", | [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", | |||
RFC 896, January 1984. | RFC 896, January 1984. | |||
[RFC1122] Braden, R., "Requirements for Internet Hosts - | [RFC1122] Braden, R., "Requirements for Internet Hosts - | |||
Communication Layers", STD 3, RFC 1122, October 1989. | Communication Layers", STD 3, RFC 1122, October 1989. | |||
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, | ||||
November 1990. | ||||
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | ||||
for IP version 6", RFC 1981, August 1996. | ||||
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP | [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP | |||
Selective Acknowledgment Options", RFC 2018, October 1996. | Selective Acknowledgment Options", RFC 2018, October 1996. | |||
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
(IPv6) Specification", RFC 2460, December 1998. | (IPv6) Specification", RFC 2460, December 1998. | |||
[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. | |||
skipping to change at page 14, line 9 | skipping to change at page 18, line 9 | |||
[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. | |||
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | ||||
Discovery", RFC 4821, March 2007. | ||||
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC | [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC | |||
4960, September 2007. | 4960, 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. | |||
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines | [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines | |||
for Application Designers", BCP 145, RFC 5405, November | for Application Designers", BCP 145, RFC 5405, November | |||
2008. | 2008. | |||
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol | [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol | |||
(DCCP) Service Codes", RFC 5595, September 2009. | (DCCP) Service Codes", RFC 5595, September 2009. | |||
[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol | ||||
(DCCP) Simultaneous-Open Technique to Facilitate NAT/ | ||||
Middlebox Traversal", RFC 5596, September 2009. | ||||
[RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File | [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File | |||
System (NFS) Version 4 Minor Version 1 External Data | System (NFS) Version 4 Minor Version 1 External Data | |||
Representation Standard (XDR) Description", RFC 5662, | Representation Standard (XDR) Description", RFC 5662, | |||
January 2010. | January 2010. | |||
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) | ||||
Signatures -- Update", RFC 5672, August 2009. | ||||
[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A | ||||
Datagram Congestion Control Protocol UDP Encapsulation for | ||||
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. | |||
[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. | |||
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, | [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, | |||
End of changes. 61 change blocks. | ||||
87 lines changed or deleted | 286 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/ |