draft-ietf-taps-transports-06.txt | draft-ietf-taps-transports-07.txt | |||
---|---|---|---|---|
Network Working Group G. Fairhurst, Ed. | Network Working Group G. Fairhurst, Ed. | |||
Internet-Draft University of Aberdeen | Internet-Draft University of Aberdeen | |||
Intended status: Informational B. Trammell, Ed. | Intended status: Informational B. Trammell, Ed. | |||
Expires: January 7, 2016 M. Kuehlewind, Ed. | Expires: April 9, 2016 M. Kuehlewind, Ed. | |||
ETH Zurich | ETH Zurich | |||
July 06, 2015 | October 07, 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-06 | draft-ietf-taps-transports-07 | |||
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 December 14, 2015. | This Internet-Draft will expire on April 9, 2016. | |||
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 | |||
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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Existing Transport Protocols . . . . . . . . . . . . . . . . 4 | 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 5 | |||
3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 4 | 3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 5 | |||
3.1.1. Protocol Description . . . . . . . . . . . . . . . . 5 | 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 5 | |||
3.1.2. Interface description . . . . . . . . . . . . . . . . 6 | 3.1.2. Interface description . . . . . . . . . . . . . . . . 6 | |||
3.1.3. Transport Protocol Components . . . . . . . . . . . . 6 | 3.1.3. Transport Features . . . . . . . . . . . . . . . . . 7 | |||
3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 7 | 3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 8 | |||
3.2.1. Protocol Description . . . . . . . . . . . . . . . . 8 | 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 8 | |||
3.2.2. Interface Description . . . . . . . . . . . . . . . . 8 | 3.2.2. Interface Description . . . . . . . . . . . . . . . . 8 | |||
3.2.3. Transport Protocol Components . . . . . . . . . . . . 8 | 3.2.3. Transport features . . . . . . . . . . . . . . . . . 8 | |||
3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 9 | 3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 9 | |||
3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 | 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 | |||
3.3.2. Interface Description . . . . . . . . . . . . . . . . 11 | 3.3.2. Interface Description . . . . . . . . . . . . . . . . 12 | |||
3.3.3. Transport Protocol Components . . . . . . . . . . . . 13 | 3.3.3. Transport Features . . . . . . . . . . . . . . . . . 14 | |||
3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 13 | 3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 15 | |||
3.4.1. Protocol Description . . . . . . . . . . . . . . . . 14 | 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 15 | |||
3.4.2. Interface Description . . . . . . . . . . . . . . . . 14 | 3.4.2. Interface Description . . . . . . . . . . . . . . . . 16 | |||
3.4.3. Transport Protocol Components . . . . . . . . . . . . 15 | 3.4.3. Transport Features . . . . . . . . . . . . . . . . . 16 | |||
3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 15 | 3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 17 | |||
3.5.1. Protocol Description . . . . . . . . . . . . . . . . 15 | 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 17 | |||
3.5.2. Interface Description . . . . . . . . . . . . . . . . 16 | 3.5.2. Interface Description . . . . . . . . . . . . . . . . 18 | |||
3.5.3. Transport Protocol Components . . . . . . . . . . . . 16 | 3.5.3. Transport Features . . . . . . . . . . . . . . . . . 18 | |||
3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 17 | 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 19 | |||
3.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 | 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 19 | |||
3.6.2. Interface Description . . . . . . . . . . . . . . . . 19 | 3.6.2. Interface Description . . . . . . . . . . . . . . . . 20 | |||
3.6.3. Transport Protocol Components . . . . . . . . . . . . 19 | 3.6.3. Transport Features . . . . . . . . . . . . . . . . . 21 | |||
3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 19 | 3.7. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 21 | |||
3.8. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 20 | 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 21 | |||
3.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 | 3.7.2. Interface Description . . . . . . . . . . . . . . . . 22 | |||
3.8.2. Interface Description . . . . . . . . . . . . . . . . 21 | 3.7.3. Transport Features . . . . . . . . . . . . . . . . . 22 | |||
3.8.3. Transport Protocol Components . . . . . . . . . . . . 21 | 3.8. Internet Control Message Protocol (ICMP) . . . . . . . . 23 | |||
3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as | 3.8.1. Protocol Description . . . . . . . . . . . . . . . . 23 | |||
a pseudotransport . . . . . . . . . . . . . . . . . . . . 22 | 3.8.2. Interface Description . . . . . . . . . . . . . . . . 24 | |||
3.9.1. Protocol Description . . . . . . . . . . . . . . . . 23 | 3.8.3. Transport Features . . . . . . . . . . . . . . . . . 24 | |||
3.9.2. Interface Description . . . . . . . . . . . . . . . . 24 | 3.9. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 25 | |||
3.9.3. Transport Protocol Components . . . . . . . . . . . . 24 | 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 25 | |||
3.10. Hypertext Transport Protocol (HTTP) over TCP as a | 3.9.2. Interface Description . . . . . . . . . . . . . . . . 26 | |||
pseudotransport . . . . . . . . . . . . . . . . . . . . . 25 | 3.9.3. Transport Features . . . . . . . . . . . . . . . . . 26 | |||
3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25 | 3.10. File Delivery over Unidirectional Transport/Asynchronous | |||
3.10.2. Interface Description . . . . . . . . . . . . . . . 26 | Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 26 | |||
3.10.3. Transport Protocol Components . . . . . . . . . . . 27 | 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 27 | |||
3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 27 | 3.10.2. Interface Description . . . . . . . . . . . . . . . 29 | |||
3.11.1. Protocol Description . . . . . . . . . . . . . . . . 27 | 3.10.3. Transport Features . . . . . . . . . . . . . . . . . 29 | |||
3.11.2. Interface Description . . . . . . . . . . . . . . . 27 | 3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 30 | |||
3.11.3. Transport Protocol Components . . . . . . . . . . . 28 | 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 30 | |||
4. Transport Service Features . . . . . . . . . . . . . . . . . 28 | 3.11.2. Interface Description . . . . . . . . . . . . . . . 31 | |||
4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 30 | 3.11.3. Transport Features . . . . . . . . . . . . . . . . . 32 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | 3.12. Transport Layer Security (TLS) and Datagram TLS (DTLS) as | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | a pseudotransport . . . . . . . . . . . . . . . . . . . . 32 | |||
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 | 3.12.1. Protocol Description . . . . . . . . . . . . . . . . 33 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 | 3.12.2. Interface Description . . . . . . . . . . . . . . . 34 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 3.12.3. Transport Features . . . . . . . . . . . . . . . . . 34 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 33 | 3.13. Hypertext Transport Protocol (HTTP) over TCP as a | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 33 | pseudotransport . . . . . . . . . . . . . . . . . . . . . 35 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 | 3.13.1. Protocol Description . . . . . . . . . . . . . . . . 36 | |||
3.13.2. Interface Description . . . . . . . . . . . . . . . 37 | ||||
3.13.3. Transport features . . . . . . . . . . . . . . . . . 37 | ||||
4. Transport Service Features . . . . . . . . . . . . . . . . . 38 | ||||
4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 40 | ||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | ||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 | ||||
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 | ||||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 | ||||
9. Informative References . . . . . . . . . . . . . . . . . . . 43 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 | ||||
1. Introduction | 1. Introduction | |||
Most Internet applications make use of the Transport Services | Most Internet applications make use of the Transport Services | |||
provided by TCP (a reliable, in-order stream protocol) or UDP (an | provided by TCP (a reliable, in-order stream protocol) or UDP (an | |||
unreliable datagram protocol). We use the term "Transport Service" | unreliable datagram protocol). We use the term "Transport Service" | |||
to mean the end-to-end service provided to an application by the | to mean the end-to-end service provided to an application by the | |||
transport layer. That service can only be provided correctly if | transport layer. That service can only be provided correctly if | |||
information about the intended usage is supplied from the | information about the intended usage is supplied from the | |||
application. The application may determine this information at | application. The application may determine this information at | |||
design time, compile time, or run time, and may include guidance on | design time, compile time, or run time, and may include guidance on | |||
whether a feature is required, a preference by the application, or | whether a feature is required, a preference by the application, or | |||
something in between. Examples of features of Transport Services are | something in between. Examples of features of Transport Services are | |||
reliable delivery, ordered delivery, content privacy to in-path | reliable delivery, ordered delivery, content privacy to in-path | |||
devices, integrity protection, and minimal latency. | devices, and integrity protection. | |||
The IETF has defined a wide variety of transport protocols beyond TCP | The IETF has defined a wide variety of transport protocols beyond TCP | |||
and UDP, including SCTP, DCCP, MP-TCP, and UDP-Lite. Transport | and UDP, including SCTP, DCCP, MP-TCP, and UDP-Lite. Transport | |||
services may be provided directly by these transport protocols, or | services may be provided directly by these transport protocols, or | |||
layered on top of them using protocols such as WebSockets (which runs | layered on top of them using protocols such as WebSockets (which runs | |||
over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run | over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run | |||
over SCTP over DTLS over UDP or TCP). Services built on top of UDP | over SCTP over DTLS over UDP or TCP). Services built on top of UDP | |||
or UDP-Lite typically also need to specify additional mechanisms, | or UDP-Lite typically also need to specify additional mechanisms, | |||
including a congestion control mechanism (such as a windowed | including a congestion control mechanism (such as NewReno, TFRC or | |||
congestion control, TFRC or LEDBAT congestion control mechanism). | LEDBAT). This extends the set of available Transport Services beyond | |||
This extends the set of available Transport Services beyond those | those provided to applications by TCP and UDP. | |||
provided to applications by TCP and UDP. | ||||
[GF: Ledbat is a mechanism, not protocol - hence use the work | ||||
"support" in para below.] | ||||
Transport protocols can also be differentiated by the features of the | Transport protocols can also be differentiated by the features of the | |||
services they provide: for instance, SCTP offers a message-based | services they provide: for instance, SCTP offers a message-based | |||
service providing full or partial reliability and allowing to | service providing full or partial reliability and allowing to | |||
minimize the head of line blocking due to the support of unordered | minimize the head of line blocking due to the support of unordered | |||
and unordered message delivery within multiple streams, UDP-Lite | and unordered message delivery within multiple streams, UDP-Lite and | |||
provides partial integrity protection, and LEDBAT can provide low- | DCCP provide partial integrity protection, and LEDBAT can support | |||
priority "scavenger" communication. | 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'S NOTE: we may want to add definitions for the different | [EDITOR'S NOTE: we may want to add definitions for the different | |||
kinds of interfaces that are important here.] | kinds of interfaces that are important here.] | |||
[GF: Interfaces may be covered by Micahel Welzl's companion | ||||
document?] | ||||
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 | |||
complete service to an application. | complete service to an application. | |||
Transport Protocol: an implementation that provides one or more | Transport Protocol: an implementation that provides one or more | |||
skipping to change at page 4, line 44 | skipping to change at page 5, line 14 | |||
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 encapsulation). | 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] | ||||
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 | |||
endpoints and widely used by common applications. | endpoints and widely used by common applications. | |||
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 | negotiate features, and mechanisms for orderly completion and | |||
connection. TCP is defined by a family of RFCs [RFC4614]. | immediate teardown of a 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.] A similar approach is adopted by other IETF-defined | |||
transports. 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 | The destination port during connection setup is often used to | |||
it is often used to indicate the requested service. | 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. ICMP-based PathMTU discovery [RFC1191][RFC1981] | fit in IP packets. ICMP-based PathMTU discovery [RFC1191][RFC1981] | |||
as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] | as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] | |||
are supported. | are supported. | |||
Each byte in the stream is identified by a sequence number. The | Each byte in the stream is identified by a sequence number. The | |||
sequence number is used to order segments on receipt, to identify | sequence number is used to order segments on receipt, to identify | |||
segments in acknowledgments, and to detect unacknowledged segments | segments in acknowledgments, and to detect unacknowledged segments | |||
for retransmission. This is the basis of TCP's reliable, ordered | for retransmission. This is the basis of the reliable, ordered | |||
delivery of data in a stream. TCP Selective Acknowledgment [RFC2018] | delivery of data in a TCP stream. TCP Selective Acknowledgment | |||
extends this mechanism by making it possible to identify missing | [RFC2018] extends this mechanism by making it possible to identify | |||
segments more precisely, reducing spurious retransmission. | 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 [RFC5681]: This uses a | |||
window, where each time congestion is detected, this congestion | separate window, where each time congestion is detected, this | |||
window is reduced. A receiver detects congestion using one of three | congestion window is reduced. Most of the used congestion control | |||
mechanisms: A retransmission timer, detection of loss (interpreted as | mechanisms use one of three mechanisms to detect congestion: A | |||
a congestion signal), or Explicit Congestion Notification (ECN) | retransmission timer (with exponential back-up), detection of loss | |||
[RFC3168] to provide early signaling (see | (interpreted as a congestion signal), or Explicit Congestion | |||
[I-D.ietf-aqm-ecn-benefits]) | Notification (ECN) [RFC3168] to provide early signaling (see | |||
[I-D.ietf-aqm-ecn-benefits]). In addition, a congestion control | ||||
mechanism may react to changes in delay as an early indication for | ||||
congestion. | ||||
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 reduce latency | |||
interactive sessions. | for interactive sessions. | |||
[EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD | TCP provides a push and a urgent function to enable data to be | |||
NOT use due to the range of TCP implementations that process TCP | directly accessed by the receiver wihout having to wait for in-order | |||
urgent indications differently.) ] | delivery of the data. However, [RFC6093] does not recommend the use | |||
of the urgent flag due to the range of TCP implementations that | ||||
process TCP urgent indications differently. | ||||
A checksum provides an Integrity Check and is mandatory across the | A checksum provides an Integrity Check and is mandatory across the | |||
entire packet. The TCP checksum does not support partial corruption | entire packet. This check protects from delivery of corrupted data | |||
protection as in DCCP/UDP-Lite). This check protects from | and miselivery of packets to the wrong endpoint. This check is | |||
misdelivery of data corrupted data, but is relatively weak, and | relatively weak, applications that require end to end integrity of | |||
applications that require end to end integrity of data are | data are recommended to include a stronger integrity check of their | |||
recommended to include a stronger integrity check of their payload | payload data. The TCP checksum does not support partial corruption | |||
data. | protection (as in DCCP/UDP-Lite). | |||
A TCP service is unicast. | TCP only supports unicast connections. | |||
3.1.2. Interface description | 3.1.2. Interface description | |||
A User/TCP Interface is defined in [RFC0793] providing six user | A User/TCP Interface is defined in [RFC0793] providing six user | |||
commands: Open, Send, Receive, Close, Status. This interface does | commands: Open, Send, Receive, Close, Status. This interface does | |||
not describe configuration of TCP options or parameters beside use of | not describe configuration of TCP options or parameters beside use of | |||
the PUSH and URGENT flags. | the PUSH and URGENT flags. | |||
[RFC1122] describes extensions of the TCP/application layer interface | ||||
for 1) reporting soft errors such as reception fo ICMP error | ||||
messages, extensive retransmission or urgent pointer advance, 2) | ||||
providing a possibility to specify the Type-of-Service (TOS) for | ||||
segments, 3) providing a fush call to empty the TCP send queue, and | ||||
4) multihoming support. | ||||
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 as described in the | |||
IEEE Portable Operating System Interface (POSIX) Base Specifications | ||||
[POSIX]. The features used by a protocol instance may be set and | ||||
tuned via this API. However, there is no RFC that documents this | ||||
interface. | ||||
The features used by a protocol instance may be set and tuned via | 3.1.3. Transport Features | |||
this API. | ||||
(more on the API goes here) | The transport features provided by TCP are: | |||
3.1.3. Transport Protocol Components | [EDITOR'S NOTE: expand each of these slightly] | |||
The transport protocol components provided by TCP (new version) are: | o unicast transport | |||
[EDITOR'S NOTE: discussion of how to map this to features and TAPS: | o connection setup with feature negotiation and application-to-port | |||
what does the higher layer need to decide? what can the transport | mapping, implemented using SYN segments and the TCP option field | |||
layer decide based on global settings? what must the transport layer | to negotiate features. | |||
decide based on network characteristics?] | ||||
o Connection-oriented bidirectional communication using three-way | o port multiplexing: each TCP session is uniquely identified by a | |||
handshake connection setup with feature negotiation and an | combination of the ports and IP address fields. | |||
explicit distinction between passive and active open: This implies | ||||
both unicast addressing and a guarantee of return routability. | ||||
o Single stream-oriented transmission: The stream abstraction atop | o Uni-or bidirectional communication | |||
the datagram service provided by IP is implemented by dividing the | ||||
stream into segments. | ||||
o Limited control over segment transmission scheduling (Nagle's | o stream-oriented delivery in a single stream | |||
algorithm): This allows for delay minimization in interactive | ||||
applications by preventing the transport to add additional delays | ||||
(by deactivating Nagle's algorithm). | ||||
o Port multiplexing, with application-to-port mapping during | o fully reliable delivery, implemented using ACKs sent from the | |||
connection setup: Note that in the presence of network address and | receiver to confirm delivery. | |||
port translation (NAPT), TCP ports are in effect part of the | ||||
endpoint address for forwarding purposes. | ||||
o Full reliability using (S)ACK- and RTO-based loss detection and | o error detection: a segment checksum verifies delivery to the | |||
retransmissions: Loss is sensed using duplicated ACKs ("fast | correct endpoint and integrity of the data and options. | |||
retransmit"), which places a lower bound on the delay inherent in | ||||
this approach to reliability. The retransmission timeout | ||||
determines the upper bound on the delay (expect if also | ||||
exponential back-off is performed). The use of selective | ||||
acknowlegdements further reduces the latency for retransmissions | ||||
if multiple packets are lost during one congestion event. | ||||
o Error detection based on a checksum covering the network and | o segmentation: packets are fragmented to a negotiated maximum | |||
transport headers as well as payload: Packets that are detected as | segment size, further constrained by the effective MTU from PMTUD. | |||
corrupted are dropped, relying on the reliability mechanism to | ||||
retransmit them. | ||||
o Window-based flow control, with receiver-side window management | o data bundling, an optional mechanism that uses Nagle's algorithm | |||
and signaling of available window: Scaling the flow control window | to coalesce data sent within the same RTT into full-sized | |||
beyond 64kB requires the use of an optional feature, which has | segments. | |||
performance implications in environments where this option is not | ||||
supported; this can be the case either if the receiver does not | ||||
implement window scaling or if a network node on the path strips | ||||
the window scaling option. | ||||
o Window-based congestion control reacting to loss, delay, | o flow control using a window-based mechanism, where the receiver | |||
retransmission timeout, or an explicit congestion signal (ECN): | advertises the window that it is willing to buffer. | |||
Most commonly used is a loss signal from the reliability | ||||
component's retransmission mechanism. TCP reacts to a congestion | o congestion control: a window-based method that uses AIMD to | |||
signal by reducing the size of the congestion window; | control the sending rate and to conservatively choose a rate after | |||
retransmission timeout is generally handled with a larger reaction | congestion is detected. | |||
than other signals. | ||||
3.2. Multipath TCP (MPTCP) | 3.2. Multipath TCP (MPTCP) | |||
Multipath TCP [RFC6824] is an extension for TCP to support multi- | Multipath TCP [RFC6824] is an extension for TCP to support multi- | |||
homing. It is designed to be as transparent as possible to middle- | homing. It is designed to be as transparent as possible to middle- | |||
boxes. It does so by establishing regular TCP flows between a pair | boxes. It does so by establishing regular TCP flows between a pair | |||
of source/destination endpoints, and multiplexing the application's | of source/destination endpoints, and multiplexing the application's | |||
stream over these flows. | stream over these flows. | |||
3.2.1. Protocol Description | 3.2.1. Protocol Description | |||
skipping to change at page 8, line 21 | skipping to change at page 8, line 33 | |||
signal multipath capabilities, as well as to negotiate data sequence | signal multipath capabilities, as well as to negotiate data sequence | |||
numbers, and advertise other available IP addresses and establish new | numbers, and advertise other available IP addresses and establish new | |||
sessions between pairs of endpoints. | sessions between pairs of endpoints. | |||
3.2.2. Interface Description | 3.2.2. Interface Description | |||
By default, MPTCP exposes the same interface as TCP to the | By default, MPTCP exposes the same interface as TCP to the | |||
application. [RFC6897] however describes a richer API for MPTCP- | application. [RFC6897] however describes a richer API for MPTCP- | |||
aware applications. | aware applications. | |||
This Basic API describes how an application can - enable or disable | This Basic API describes how an application can | |||
MPTCP; - bind a socket to one or more selected local endpoints; - | ||||
query local and remote endpoint addresses; - get a unique connection | ||||
identifier (similar to an address-port pair for TCP). | ||||
The document also recommend the use of extensions defined for SCTP | o enable or disable MPTCP; | |||
[RFC6458] (see next section) to deal with multihoming. | ||||
[AUTHOR'S NOTE: research work, and some implementation, also suggest | o bind a socket to one or more selected local endpoints; | |||
that the scheduling algorithm, as well as the path manager, are | ||||
configurable options that should be exposed to higher layer. Should | ||||
this be discussed here?] | ||||
3.2.3. Transport Protocol Components | o query local and remote endpoint addresses; | |||
[AUTHOR'S NOTE: shouldn't it be "service feature"?] | o get a unique connection identifier (similar to an address-port | |||
pair for TCP). | ||||
As an extension to TCP, MPTCP provides mostly the same components. | The document also recommends the use of extensions defined for SCTP | |||
By establishing multiple sessions between available endpoints, it can | [RFC6458] (see next section) to support multihoming. | |||
3.2.3. Transport features | ||||
As an extension to TCP, MPTCP provides mostly the same features. By | ||||
establishing multiple sessions between available endpoints, it can | ||||
additionally provide soft failover solutions should one of the paths | additionally provide soft failover solutions should one of the paths | |||
become unusable. In addition, by multiplexing one byte stream over | become unusable. In addition, by multiplexing one byte stream over | |||
separate paths, it can achieve a higher throughput than TCP in | separate paths, it can achieve a higher throughput than TCP in | |||
certain situations (note however that coupled congestion control | certain situations (note however that coupled congestion control | |||
[RFC6356] might limit this benefit to maintain fairness to other | [RFC6356] might limit this benefit to maintain fairness to other | |||
flows at the bottleneck). When aggregating capacity over multiple | flows at the bottleneck). When aggregating capacity over multiple | |||
paths, and depending on the way packets are scheduled on each TCP | paths, and depending on the way packets are scheduled on each TCP | |||
subflow, an additional delay and higher jitter might be observed | subflow, an additional delay and higher jitter might be observed | |||
observed before in-order delivery of data to the applications. | observed before in-order delivery of data to the applications. | |||
The transport protocol components provided by MPTCP in addition to | The transport features provided by MPTCP in addition to TCP therefore | |||
TCP therefore are: | are: | |||
o congestion control with load balancing over mutiple connections | o congestion control with load balancing over mutiple connections. | |||
o endpoint multiplexing of a single byte stream (higher throughput) | o endpoint multiplexing of a single byte stream (higher throughput). | |||
o resilience to network failure and/or handoverss | o address family multiplexing: sub-flows can be started over IPv4 or | |||
IPv6 for the same session. | ||||
o resilience to network failure and/or handover. | ||||
[AUTHOR'S NOTE: it is unclear whether MPTCP has to provide data | [AUTHOR'S NOTE: it is unclear whether MPTCP has to provide data | |||
bundling.] [AUTHOR'S NOTE: AF muliplexing? sub-flows can be started | bundling.] | |||
over IPv4 or IPv6 for the same session] | ||||
3.3. Stream Control Transmission Protocol (SCTP) | 3.3. Stream Control Transmission Protocol (SCTP) | |||
SCTP is a message oriented standards track transport protocol and the | SCTP is a message-oriented standards track transport protocol. The | |||
base protocol is specified in [RFC4960]. It supports multi-homing to | base protocol is specified in [RFC4960]. It supports multi-homing to | |||
handle path failures. An SCTP association has multiple | handle path failures. It also optionally supports path failover to | |||
unidirectional streams in each direction and provides in-sequence | provide resilliance to path failures. An SCTP association has | |||
delivery of user messages only within each stream. This allows to | multiple unidirectional streams in each direction and provides in- | |||
minimize head of line blocking. SCTP is extensible and the currently | sequence delivery of user messages only within each stream. This | |||
defined extensions include mechanisms for dynamic re-configurations | allows it to minimize head of line blocking. SCTP is extensible and | |||
of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the | the currently defined extensions include mechanisms for dynamic re- | |||
extension specified in [RFC3758] introduces the concept of partial | configurations of streams [RFC6525] and IP-addresses [RFC5061]. | |||
reliability for user messages. | Furthermore, the extension specified in [RFC3758] introduces the | |||
concept of partial reliability for user messages. | ||||
SCTP was originally developed for transporting telephony signalling | SCTP was originally developed for transporting telephony signalling | |||
messages and is deployed in telephony signalling networks, especially | messages and is deployed in telephony signalling networks, especially | |||
in mobile telephony networks. Additionally, it is used in the WebRTC | in mobile telephony networks. It can also be used for other | |||
framework for data channels and is therefore deployed in all WEB- | services, for example in the WebRTC framework for data channels and | |||
browsers supporting WebRTC. | is therefore deployed in all WEB-browsers supporting WebRTC. | |||
3.3.1. Protocol Description | 3.3.1. Protocol Description | |||
SCTP is a connection oriented protocol using a four way handshake to | SCTP is a connection-oriented protocol using a four way handshake to | |||
establish an SCTP association and a three way message exchange to | establish an SCTP association and a three way message exchange to | |||
gracefully shut it down. It uses the same port number concept as | gracefully shut it down. It uses the same port number concept as | |||
DCCP, TCP, UDP, and UDP-Lite do and only supports unicast. | DCCP, TCP, UDP, and UDP-Lite, and only supports unicast. | |||
SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit | 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 | errors and miselivery of packets to the wrong endpoint. This is | |||
UDP. However, a partial checksum coverage as provided by DCCP or | stronger than the 16-bit checksums used by TCP or UDP. However, a | |||
UDP-Lite is not supported. | partial checksum coverage, as provided by DCCP or UDP-Lite is not | |||
supported. | ||||
SCTP has been designed with extensibility in mind. Each SCTP packet | SCTP has been designed with extensibility in mind. Each SCTP packet | |||
starts with a single common header containing the port numbers, a | starts with a single common header containing the port numbers, a | |||
verification tag and the CRC32c checksum. This common header is | verification tag and the CRC32c checksum. This common header is | |||
followed by a sequence of chunks. Each chunk consists of a type | followed by a sequence of chunks. Each chunk consists of a type | |||
field, flags, a length field and a value. [RFC4960] defines how a | field, flags, a length field and a value. [RFC4960] defines how a | |||
receiver processes chunks with an unknown chunk type. The support of | receiver processes chunks with an unknown chunk type. The support of | |||
extensions can be negotiated during the SCTP handshake. | extensions can be negotiated during the SCTP handshake. | |||
SCTP provides a message-oriented service. Multiple small user | SCTP provides a message-oriented service. Multiple small user | |||
messages can be bundled into a single SCTP packet to improve the | messages can be bundled into a single SCTP packet to improve the | |||
efficiency. For example, this bundling may be done by delaying user | efficiency. For example, this bundling may be done by delaying user | |||
messages at the sender side similar to the Nagle algorithm used by | messages at the sender similar to the Nagle algorithm used by TCP. | |||
TCP. User messages which would result in IP packets larger than the | User messages which would result in IP packets larger than the MTU | |||
MTU will be fragmented at the sender side and reassembled at the | will be fragmented at the sender and reassembled at the receiver. | |||
receiver side. There is no protocol limit on the user message size. | There is no protocol limit on the user message size. ICMP-based path | |||
ICMP-based path MTU discovery as specified for IPv4 in [RFC1191] and | MTU discovery as specified for IPv4 in [RFC1191] and for IPv6 in | |||
for IPv6 in [RFC1981] as well as packetization layer path MTU | [RFC1981] as well as packetization layer path MTU discovery as | |||
discovery as specified in [RFC4821] with probe packets using the | specified in [RFC4821] with probe packets using the padding chunks | |||
padding chunks defined the [RFC4820] are supported. | defined the [RFC4820] are supported. | |||
[RFC4960] specifies a TCP friendly congestion control to protect the | [RFC4960] specifies a TCP friendly congestion control to protect the | |||
network against overload. SCTP also uses a sliding window flow | network against overload. SCTP also uses a sliding window flow | |||
control to protect receivers against overflow. | control to protect receivers against overflow. Similar to TCP, SCTP | |||
also supports delaying acknowledgements. [RFC7053] provides a way | ||||
for the sender of user messages to request the immediate sending of | ||||
the corresponding acknowledgements. | ||||
Each SCTP association has between 1 and 65536 uni-directional streams | Each SCTP association has between 1 and 65536 uni-directional streams | |||
in each direction. The number of streams can be different in each | in each direction. The number of streams can be different in each | |||
direction. Every user-message is sent on a particular stream. User | direction. Every user-message is sent on a particular stream. User | |||
messages can be sent un-ordered or ordered upon request by the upper | messages can be sent un-ordered or ordered upon request by the upper | |||
layer. Un-ordered messages can be delivered as soon as they are | layer. Un-ordered messages can be delivered as soon as they are | |||
completely received. Only all ordered messages sent on the same | completely received. Ordered messages sent on the same stream are | |||
stream are delivered at the receiver in the same order as sent by the | delivered at the receiver in the same order as sent by the sender. | |||
sender. For user messages not requiring fragmentation, this | For user messages not requiring fragmentation, this minimises head of | |||
minimises head of line blocking. The base protocol defined in | line blocking. | |||
[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. Furthermore, [I-D.ietf-tsvwg-sctp-ndata] | ||||
specifies multiple algorithms for the sender side selection of which | ||||
streams to send data from supporting a variety of scheduling | ||||
algorithms including priority based ones. 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 base protocol defined in [RFC4960] does not allow interleaving of | |||
the receiver or, in case of excessive retransmissions, the | user-messages, which results in sending a large message on one stream | |||
association is terminated in a non-graceful way, similar to the TCP | can block the sending of user messages on other streams. | |||
behaviour. In addition to this reliable transfer, the partial | [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. Furthermore, | |||
reliability extension defined in [RFC3758] allows the sender to | [I-D.ietf-tsvwg-sctp-ndata] specifies multiple algorithms for the | |||
abandon user messages. The application can specify the policy for | sender side selection of which streams to send data from supporting a | |||
abandoning user messages. Examples for these policies include: | variety of scheduling algorithms including priority based methods. | |||
The stream re-configuration extension defined in [RFC6525] allows | ||||
streams to be reset during the lifetime of an association and to | ||||
increase the number of streams, if the number of streams negotiated | ||||
in the SCTP handshake becomes insufficient. | ||||
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 [RFC4960], similar to TCP behaviour. In addition to | ||||
this reliable transfer, the partial reliability extension [RFC3758] | ||||
allows a sender to abandon user messages. The application can | ||||
specify the policy for abandoning user messages. Examples for these | ||||
policies defined in [RFC3758] and [RFC7496] are: | ||||
o Limiting the time a user message is dealt with by the sender. | 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 | o Limiting the number of retransmissions for each fragment of a user | |||
message. If the number of retransmissions is limited to 0, one | message. If the number of retransmissions is limited to 0, one | |||
gets a service similar to UDP. | gets a service similar to UDP. | |||
o Abandoning messages of lower priority in case of a send buffer | o Abandoning messages of lower priority in case of a send buffer | |||
shortage. | shortage. | |||
SCTP supports multi-homing. Each SCTP end-point uses a list of IP- | SCTP supports multi-homing. Each SCTP endpoint uses a list of IP- | |||
addresses and a single port number. These addresses can be any | addresses and a single port number. These addresses can be any | |||
mixture of IPv4 and IPv6 addresses. These addresses are negotiated | mixture of IPv4 and IPv6 addresses. These addresses are negotiated | |||
during the handshake and the address re-configuration extension | during the handshake and the address re-configuration extension | |||
specified in [RFC5061] in combination with [RFC4895] can be used to | specified in [RFC5061] in combination with [RFC4895] can be used to | |||
change these addresses in an authenticated way during the livetime of | change these addresses in an authenticated way during the livetime of | |||
an SCTP association. This allows for transport layer mobility. | an SCTP association. This allows for transport layer mobility. | |||
Multiple addresses are used for improved resilience. If a remote | Multiple addresses are used for improved resilience. If a remote | |||
address becomes unreachable, the traffic is switched over to a | address becomes unreachable, the traffic is switched over to a | |||
reachable one, if one exists. Each SCTP end-point supervises | reachable one, if one exists. Each SCTP end-point supervises | |||
continuously the reachability of all peer addresses using a heartbeat | continuously the reachability of all peer addresses using a heartbeat | |||
mechanism. | mechanism. | |||
For securing user messages, the use of TLS over SCTP has been | For securing user messages, the use of TLS over SCTP has been | |||
specified in [RFC3436]. However, this solution does not support all | specified in [RFC3436]. However, this solution does not support all | |||
services provided by SCTP (for example un-ordered delivery or partial | services provided by SCTP (for example un-ordered delivery or partial | |||
reliability), and therefore the use of DTLS over SCTP has been | reliability), and therefore the use of DTLS over SCTP has been | |||
specified in [RFC6083] to overcome these limitations. When using | specified in [RFC6083] to overcome these limitations. When using | |||
DTLS over SCTP, the application can use almost all services provided | DTLS over SCTP, the application can use almost all services provided | |||
by SCTP. | by SCTP. | |||
[I-D.ietf-tsvwg-natsupp] defines a methods for end-hosts and | [I-D.ietf-tsvwg-natsupp] defines methods for endpoints and | |||
middleboxes to provide for NAT support for SCTP over IPv4. For | middleboxes to provide support NAT for SCTP over IPv4. For legacy | |||
legacy NAT traversal, [RFC6951] defines the UDP encapsulation of | NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP- | |||
SCTP-packets. Alternatively, SCTP packets can be encapsulated in | packets. Alternatively, SCTP packets can be encapsulated in DTLS | |||
DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The | packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The | |||
latter encapsulation is used with in the WebRTC context. | latter encapsulation is used within the WebRTC context. | |||
Having a well defined API is also a feature provided by SCTP as | SCTP has a well-defined API, described in the next subsection. | |||
described in the next subsection. | ||||
3.3.2. Interface Description | 3.3.2. Interface Description | |||
[RFC4960] defines an abstract API for the base protocol. An | [RFC4960] defines an abstract API for the base protocol. This API | |||
extension to the BSD Sockets API is defined in [RFC6458] and covers: | describes the following functions callable by the upper layer of | |||
SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, | ||||
Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, | ||||
Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure | ||||
Threshold, Set Protocol Parameters, and Destroy. The following | ||||
notifications are provided by the SCTP stack to the upper layer: | ||||
COMMUNICATION UP, DATA ARRIVE, SHUTDOWN COMPLETE, COMMUNICATION LOST, | ||||
COMMUNICATION ERROR, RESTART, SEND FAILURE, NETWORK STATUS CHANGE. | ||||
o the base protocol defined in [RFC4960]. | An extension to the BSD Sockets API is defined in [RFC6458] and | |||
covers: | ||||
o the SCTP Partial Reliability extension defined in [RFC3758]. | o the base protocol defined in [RFC4960]. The API allows to control | |||
the local addresses and port numbers and the primary path. | ||||
Furthermore the application has fine control about parameters like | ||||
retransmission thresholds, the path supervision parameters, the | ||||
delayed acknowledgement timeout, and the fragmentation point. The | ||||
API provides a mechanism to allow the SCTP stack to notify the | ||||
application about event if the application has requested them. | ||||
These notifications provide Information about status changes of | ||||
the association and each of the peer addresses. In case of send | ||||
failures that application can also be notified and user messages | ||||
can be returned to the application. When sending user messages, | ||||
the stream id, a payload protocol identifier, an indication | ||||
whether ordered delivery is requested or not. These parameters | ||||
can also be provided on message reception. Additionally a context | ||||
can be provided when sending, which can be use in case of send | ||||
failures. The sending of arbitrary large user messages is | ||||
supported. | ||||
o the SCTP Authentication extension defined in [RFC4895]. | o the SCTP Partial Reliability extension defined in [RFC3758] to | |||
specify for a user message the PR-SCTP policy and the policy | ||||
specific parameter. | ||||
o the SCTP Authentication extension defined in [RFC4895] allowing to | ||||
manage the shared keys, the HMAC to use, set the chunk types which | ||||
are only accepted in an authenticated way, and get the list of | ||||
chunks which are accepted by the local and remote end point in an | ||||
authenticated way. | ||||
o the SCTP Dynamic Address Reconfiguration extension defined in | o the SCTP Dynamic Address Reconfiguration extension defined in | |||
[RFC5061]. | [RFC5061]. It allows to manually add and delete local addresses | |||
for SCTP associations and the enabling of automatic address | ||||
addition and deletion. Furthermore the peer can be given a hint | ||||
for choosing its primary path. | ||||
For the following SCTP protocol extensions the BSD Sockets API | For the following SCTP protocol extensions the BSD Sockets API | |||
extension is defined in the document specifying the protocol | extension is defined in the document specifying the protocol | |||
extensions: | extensions: | |||
o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. | ||||
o the SCTP Stream Reconfiguration extension defined in [RFC6525]. | o the SCTP Stream Reconfiguration extension defined in [RFC6525]. | |||
The API allows to trigger the reset operation for incoming and | ||||
outgoing streams and the whole association. It provides also a | ||||
way to notify the association about the corresponding events. | ||||
Furthermore the application can increase the number of streams. | ||||
o the UDP Encapsulation of SCTP packets extension defined in | o the UDP Encapsulation of SCTP packets extension defined in | |||
[RFC6951]. | [RFC6951]. The API allows the management of the remote UDP | |||
encapsulation port. | ||||
o the additional PR-SCTP policies defined in | o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. The API | |||
[I-D.ietf-tsvwg-sctp-prpolicies]. | allows the sender of a user message to request the receiver to | |||
send the corresponding acknowledgement immediately. | ||||
o the additional PR-SCTP policies defined in [RFC7496]. The API | ||||
allows to enable/disable the PR-SCTP extension, choose the PR-SCTP | ||||
policies defined in the document and provide statistical | ||||
information about abandoned messages. | ||||
Future documents describing SCTP protocol extensions are expected to | Future documents describing SCTP protocol extensions are expected to | |||
describe the corresponding BSD Sockets API extension in a "Socket API | describe the corresponding BSD Sockets API extension in a "Socket API | |||
Considerations" section. | Considerations" section. | |||
The SCTP socket API supports two kinds of sockets: | 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-one style sockets (by using the socket type "SOCK_STREAM"). | |||
o one-to-many style socket (by using the socket type | o one-to-many style socket (by using the socket type | |||
"SOCK_SEQPACKET"). | "SOCK_SEQPACKET"). | |||
One-to-one style sockets are similar to TCP sockets, there is a 1:1 | One-to-one style sockets are similar to TCP sockets, there is a 1:1 | |||
relationship between the sockets and the SCTP associations (except | relationship between the sockets and the SCTP associations (except | |||
for listening sockets). One-to-many style SCTP sockets are similar | for listening sockets). One-to-many style SCTP sockets are similar | |||
to unconnected UDP sockets as there is a 1:n relationship between the | to unconnected UDP sockets, where there is a 1:n relationship between | |||
sockets and the SCTP associations. | the sockets and the SCTP associations. | |||
The SCTP stack can provide information to the applications about | The SCTP stack can provide information to the applications about | |||
state changes of the individual paths and the association whenever | state changes of the individual paths and the association whenever | |||
they occur. These events are delivered similar to user messages but | they occur. These events are delivered similar to user messages but | |||
are specifically marked as notifications. | are specifically marked as notifications. | |||
A couple of new functions have been introduced to support the use of | New functions have been introduced to support the use of multiple | |||
multiple local and remote addresses. Additional SCTP-specific send | local and remote addresses. Additional SCTP-specific send and | |||
and receive calls have been defined to allow dealing with the SCTP | receive calls have been defined to permit SCTP-specific information | |||
specific information without using ancillary data in the form of | to be snet without using ancillary data in the form of additional | |||
additional cmsgs, which are also defined. These functions provide | cmsgs. These functions provide support for detecting partial | |||
support for detecting partial delivery of user messages and | delivery of user messages and notifications. | |||
notifications. | ||||
The SCTP socket API allows a fine-grained control of the protocol | The SCTP socket API allows a fine-grained control of the protocol | |||
behaviour through an extensive set of socket options. | behaviour through an extensive set of socket options. | |||
The SCTP kernel implementations of FreeBSD, Linux and Solaris follow | The SCTP kernel implementations of FreeBSD, Linux and Solaris follow | |||
mostly the specified extension to the BSD Sockets API for the base | mostly the specified extension to the BSD Sockets API for the base | |||
protocol and the corresponding supported protocol extensions. | protocol and the corresponding supported protocol extensions. | |||
3.3.3. Transport Protocol Components | 3.3.3. Transport Features | |||
The transport protocol components provided by SCTP are: | The transport features provided by SCTP are: | |||
o unicast | [GF: This needs to be harmonised with the components for TCP] | |||
o connection setup with feature negotiation and application-to-port | o unicast. | |||
mapping | ||||
o port multiplexing | o connection setup with feature negotiation and application-to-port | |||
mapping. | ||||
o reliable or partially reliable delivery | o port multiplexing. | |||
o ordered and unordered delivery within a stream | o message-oriented delivery. | |||
o support for multiple concurrent streams | o fully reliable or partially reliable delivery. | |||
o support for stream scheduling prioritization | o ordered and unordered delivery within a stream. | |||
o flow control | o support for multiple concurrent streams. | |||
o message-oriented delivery | o support for stream scheduling prioritization. | |||
o congestion control | o flow control. | |||
o user message bundling | o congestion control. | |||
o user message fragmentation and reassembly | o user message bundling. | |||
o strong error detection (CRC32C) | o user message fragmentation and reassembly. | |||
o transport layer multihoming for resilience | o strong error/misdelivery detection (CRC32c). | |||
o transport layer mobility | o transport layer multihoming for resilience. | |||
[EDITOR'S NOTE: update this list.] | o transport layer mobility. | |||
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 unidirectional, | |||
datagram protocol which preserves message boundaries. It provides | datagram protocol that preserves message boundaries. It provides | |||
none of the following transport features: error correction, | none of the following transport features: error correction, | |||
congestion control, or flow control. It can be used to send | congestion control, or flow control. It can be used to send | |||
broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in | broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in | |||
addition to unicast (and anycast) datagrams. IETF guidance on the | addition to unicast (and anycast) datagrams. IETF guidance on the | |||
use of UDP is provided in[RFC5405]. UDP is widely implemented and | use of UDP is provided in[I-D.ietf-tsvwg-rfc5405bis]. UDP is widely | |||
widely used by common applications, especially DNS. | implemented and widely used by common applications, including DNS. | |||
3.4.1. Protocol Description | 3.4.1. Protocol Description | |||
UDP is a connection-less protocol which maintains message boundaries, | UDP is a connection-less protocol that maintains message boundaries, | |||
with no connection setup or feature negotiation. The protocol uses | with no connection setup or feature negotiation. The protocol uses | |||
independent messages, ordinarily called datagrams. The lack of error | independent messages, ordinarily called datagrams. Each stream of | |||
control and flow control implies messages may be damaged, re-ordered, | messages is independently managed, therefore retransmission does not | |||
lost, or duplicated in transit. A receiving application unable to | hold back data sent using other logical streams. It provides | |||
run sufficiently fast or frequently may miss messages. The lack of | detection of payload errors and misdelivery of packets to the wrong | |||
congestion handling implies UDP traffic may cause the loss of | endpoint, either of which result in discard of received datagrams. | |||
messages from other protocols (e.g., TCP) when sharing the same | ||||
network paths. UDP traffic can also cause the loss of other UDP | ||||
traffic in the same or other flows for the same reasons. | ||||
Messages with bit errors are ordinarily detected by an invalid end- | It is possible to create IPv4 UDP datagrams with no checksum, and | |||
to-end checksum and are discarded before being delivered to an | while this is generally discouraged [RFC1122] | |||
application. There are some exceptions to this general rule, | [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit its use. | |||
however. UDP-Lite (see [RFC3828], and below) provides the ability | These datagrams relie on the IPv4 header checksum to protect from | |||
for portions of the message contents to be exempt from checksum | misdelivery to the wrong endpoint. IPv6 does not by permit UDP | |||
coverage. It is also possible to create UDP datagrams with no | datagrams with no checksum, although in certain cases this rule may | |||
checksum, and while this is generally discouraged [RFC1122] | be relaxed [RFC6935]. The checksum support considerations for | |||
[RFC5405], certain special cases permit its use [RFC6935]. The | omitting the checksum are defined in [RFC6936]. Note that due to the | |||
checksum support considerations for omitting the checksum are defined | relatively weak form of checksum used by UDP, applications that | |||
in [RFC6936]. Note that due to the relatively weak form of checksum | require end to end integrity of data are recommended to include a | |||
used by UDP, applications that require end to end integrity of data | stronger integrity check of their payload data. | |||
are recommended to include a stronger integrity check of their | ||||
payload data. | It does not provide reliability and does not provide retransmission. | |||
This implies messages may be re-ordered, lost, or duplicated in | ||||
transit. | ||||
A receiving application that is unable to run sufficiently fast, or | ||||
frequently, may miss messages since there is no flow control. The | ||||
lack of congestion handling implies UDP traffic may experience loss | ||||
when using an overlaoded path and may cause the loss of messages from | ||||
other protocols (e.g., TCP) when sharing the same network path. | ||||
[GF: This para isn't needed": Messages with payload errors are | ||||
ordinarily detected by an invalid end- to-end checksum and are | ||||
discarded before being delivered to an application. UDP-Lite (see | ||||
[RFC3828], and below) provides the ability for portions of the | ||||
message contents to be exempt from checksum coverage.] | ||||
On transmission, UDP encapsulates each datagram into an IP packet, | On transmission, UDP encapsulates each datagram into an IP packet, | |||
which may in turn be fragmented by IP. Applications concerned with | which may in turn be fragmented by IP and are reassembled before | |||
fragmentation or that have other requirements such as receiver flow | delivery to the UDP receiver. | |||
control, congestion control, PathMTU discovery/PLPMTUD, support for | ||||
ECN, etc need to be provided by protocols other than UDP [RFC5405]. | Applications that need to provide fragmentation or that have other | |||
requirements such as receiver flow control, congestion control, | ||||
PathMTU discovery/PLPMTUD, support for ECN, etc need these to be | ||||
provided by protocols operating over UDP [I-D.ietf-tsvwg-rfc5405bis]. | ||||
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 [I-D.ietf-tsvwg-rfc5405bis]. | |||
A UDP endpoint consists of a tuple of (IP address, port number). | A UDP endpoint consists of a tuple of (IP address, port number). | |||
Demultiplexing using multiple abstract endpoints (sockets) on the | Demultiplexing using multiple abstract endpoints (sockets) on the | |||
same IP address are supported. The same socket may be used by a | same IP address are supported. The same socket may be used by a | |||
single server to interact with multiple clients (note: this behavior | single server to interact with multiple clients (note: this behavior | |||
differs from TCP, which uses a pair of tuples to identify a | differs from TCP, which uses a pair of tuples to identify a | |||
connection). Multiple server instances (processes) binding the same | connection). Multiple server instances (processes) that bind the | |||
socket can cooperate to service multiple clients- the socket | same socket can cooperate to service multiple clients- the socket | |||
implementation arranges to not duplicate the same received unicast | implementation arranges to not duplicate the same received unicast | |||
message to multiple server processes. | message to multiple server processes. | |||
Many operating systems also allow a UDP socket to be "connected", | Many operating systems also allow a UDP socket to be "connected", | |||
i.e., to bind a UDP socket to a specific (remote) UDP endpoint. | 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 | Unlike TCP's connect primitive, for UDP, this is only a local | |||
operation that serves to simplify the local send/receive functions | operation that serves to simplify the local send/receive functions | |||
and to filter the traffic for the specified addresses and ports | and to filter the traffic for the specified addresses and ports | |||
[RFC5405]. | [I-D.ietf-tsvwg-rfc5405bis]. | |||
3.4.3. Transport Protocol Components | 3.4.3. Transport Features | |||
The transport protocol components provided by UDP are: | The transport features provided by UDP are: | |||
o unidirectional | o unicast. | |||
o port multiplexing | o multicast, anycast, or IPv4 broadcast. | |||
o 2-tuple endpoints | o port multiplexing. A receiving port can be configured to receive | |||
datagrams from multiple senders. | ||||
o IPv4 broadcast, multicast and anycast | o message-oriented delivery. | |||
o IPv6 multicast and anycast | o unidirectional or bidirectional. Transmission in each direction | |||
is independent. | ||||
o IPv6 jumbograms | o non-reliable delivery. | |||
o message-oriented delivery | o non-ordered delivery. | |||
o error detection (checksum) | o IPv6 jumbograms. | |||
o checksum optional | o error and misdelivery detection (checksum). | |||
o optional checksum. All or none of the payload data is protected. | ||||
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. It provides a | |||
bidirectional set of logical unicast or multicast message streams | unidirectional, datagram protocol that preserves message boundaries. | |||
over a datagram protocol. IETF guidance on the use of UDP-Lite is | IETF guidance on the use of UDP-Lite is provided in | |||
provided in [RFC5405]. | [I-D.ietf-tsvwg-rfc5405bis]. | |||
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 use messages, rather than | setup or feature negotiation. The protocol use messages, rather than | |||
a byte-stream. Each stream of messages is independently managed, | a byte-stream. Each stream of messages is independently managed, | |||
therefore retransmission does not hold back data sent using other | therefore retransmission does not hold back data sent using 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, and its operation follows that for UDP. An active UDP-Lite | |||
of local and remote IP addresses and local port and remote port | session is identified by its four-tuple of local and remote IP | |||
numbers. | addresses and local port and remote port numbers. | |||
UDP-Lite fragments packets into IP packets, constrained by the | ||||
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, and is identified by a | |||
different IP protocol/next-header value. 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, | |||
PMTU or PLPMTU discovery, support for ECN, etc need to be provided by | PMTU or PLPMTU discovery, support for ECN, etc need to be provided by | |||
upper layer protocols [RFC5405]. | upper layer protocols [I-D.ietf-tsvwg-rfc5405bis]. | |||
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 error tolerate payload corruption | discarded. One use is to support error tolerate payload corruption | |||
when used over paths that include error-prone links, another | when used over paths that include error-prone links, another | |||
application is when header integrity checks are required, but payload | application is when header integrity checks are required, but payload | |||
integrity is 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, and IPv6 multicast, anycast and 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 [I-D.ietf-tsvwg-rfc5405bis]. | |||
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 | |||
a single (socket) option that communicates a checksum coverage length | a single (socket) option that communicates a checksum coverage length | |||
value: at the sender, this specifies the intended checksum coverage, | value: at the sender, this specifies the intended checksum coverage, | |||
with the remaining unprotected part of the payload called the "error- | with the remaining unprotected part of the payload called the "error- | |||
insensitive part". The checksum coverage may also be made visible to | insensitive part". The checksum coverage may also be made visible to | |||
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 Features | |||
The transport protocol components provided by UDP-Lite are: | ||||
o unicast | The transport features provided by UDP-Lite are: | |||
o IPv4 broadcast, multicast and anycast | o unicast. | |||
o port multiplexing | o multicast, anycast, or IPv4 broadcast. | |||
o non-reliable, non-ordered delivery | o port multiplexing (as for UDP). | |||
o message-oriented delivery | o message-oriented delivery (as for UDP). | |||
o partial integrity protection | o non-reliable delivery (as for UDP). | |||
o non-ordered delivery (as for UDP). | ||||
o error and misdelivery detection (checksum). | ||||
o partialor full integrity protection. The checksum coverage field | ||||
indicates the size of the payload data covered by the checksum. | ||||
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 messages without | |||
providing reliability. | ||||
[EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this | ||||
section.] | ||||
The DCCP Problem Statement describes the goals that DCCP sought to | The DCCP Problem Statement describes the goals that DCCP sought to | |||
address [RFC4336]. It is suitable for applications that transfer | address [RFC4336]. It is suitable for applications that transfer | |||
fairly large amounts of data and that can benefit from control over | fairly large amounts of data and that can benefit from control over | |||
the trade off between timeliness and reliability [RFC4336]. | the trade off between timeliness and reliability [RFC4336]. | |||
It offers low overhead, and many characteristics common to UDP, but | It offers low overhead, and many characteristics common to UDP, but | |||
can avoid "Re-inventing the wheel" each time a new multimedia | can avoid "Re-inventing the wheel" each time a new multimedia | |||
application emerges. Specifically it includes core functions | application emerges. Specifically it includes core functions | |||
(feature negotiation, path state management, RTT calculation, PMTUD, | (feature negotiation, path state management, RTT calculation, PMTUD, | |||
skipping to change at page 17, line 48 | skipping to change at page 19, line 33 | |||
to manage their functions. Examples of suitable applications include | to manage their functions. Examples of suitable applications include | |||
interactive applications, streaming media or on-line games [RFC4336]. | 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 at each endpoint using | |||
numbers. An active DCCP session is identified by its four-tuple of | port numbers. An active DCCP session is identified by its four-tuple | |||
local and remote IP addresses and local port and remote port numbers. | of local and remote IP addresses and local port and remote port | |||
At connection setup, DCCP also exchanges the the service code | numbers. At connection setup, DCCP also exchanges the service code | |||
[RFC5595], a mechanism that allows transport instantiations to | ||||
[RFC5595] mechanism to allow transport instantiations to indicate the | 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 fragmented 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 maximum packet size. A DCCP interface allows applications to | |||
for packets larger than PMTU, but not larger than the maximum packet | request fragmentation for packets larger than PMTU, but not larger | |||
size allowed by the current congestion control mechanism (CCMPS) | than the maximum packet size allowed by the current congestion | |||
[RFC4340]. | control mechanism (CCMPS) [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. DCCP supports reduced checksum coverage, a | |||
contains a strong CRC, lets endpoints detect application data | partial integrity mechanisms similar to UDP-lIte. There is also a | |||
corruption. It also supports reduced checksum coverage, a partial | Data Checksum option that when enabled, contains a strong CRC, to | |||
integrity mechanisms similar to UDP-lIte. | enable endpoints to detect application data corruption. | |||
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 using | |||
features are sender-side only, requiring no negotiation with the | features. Some features are sender-side only, requiring no | |||
receiver; some are receiver-side only, some are explicitly negotiated | negotiation with the receiver; some are receiver-side only, some are | |||
during connection setup. | explicitly negotiated during connection setup. | |||
A DCCP service is unicast. | ||||
DCCP supports negotiation of the congestion control profile, to | DCCP supports negotiation of the congestion control profile, to | |||
provide Plug and Play congestion control mechanisms. examples of | provide Plug and Play congestion control mechanisms. Examples of | |||
specified profiles include [RFC4341] [RFC4342] [RFC5662]. All IETF- | specified profiles include [RFC4341] [RFC4342] [RFC5662]. All IETF- | |||
defined methods provide Congestion Control. | defined methods provide Congestion Control. | |||
DCCP use a Connect packet to start a session, and permits half- | DCCP use a Connect packet to initiate a session, and permits half- | |||
connections that allow each client to choose features it wishes to | connections that allow each client to choose the features it wishes | |||
support. Simultaneous open [RFC5596], as in TCP, can enable | to support. Simultaneous open [RFC5596], as in TCP, can enable | |||
interoperability in the presence of middleboxes. The Connect packet | interoperability in the presence of middleboxes. The Connect packet | |||
includes a Service Code field [RFC5595] designed to allow middle | includes a Service Code field [RFC5595] designed to allow middle | |||
boxes and endpoints to identify the characteristics required by a | boxes and endpoints to identify the characteristics required by a | |||
session. A lightweight UDP-based encapsulation (DCCP-UDP) has been | session. | |||
defined [RFC6773] that permits DCCP to be used over paths where it is | ||||
not natively supported. Support in NAPT/NATs is defined in [RFC4340] | A lightweight UDP-based encapsulation (DCCP-UDP) has been defined | |||
and [RFC5595]. | [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 | 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 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 characteristics 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 a receiver. | length payloads. - Slow Receiver flow control at a receiver. - | |||
- Detect 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 curremntly specified in the RFC Series. | |||
3.6.3. Transport Protocol Components | 3.6.3. Transport Features | |||
The transport protocol components provided by DCCP are: | The transport features 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 | |||
mapping | mapping. | |||
o Service Codes | o Service Codes. Identifies the upper layer service to the endpoint | |||
and network. | ||||
o port multiplexing | o port multiplexing. | |||
o non-reliable, ordered delivery | o message-oriented delivery. | |||
o flow control (slow receiver function) | o non-reliable delivery. | |||
o drop notification | o ordered delivery. | |||
o timestamps | o flow control. The slow receiver function allows a receiver to | |||
control the rate of the sender. | ||||
o message-oriented delivery | o drop notification. Allows a receiver to notify which datagrams | |||
were not delivered to the peer upper layer protocol. | ||||
o partial integrity protection | o timestamps. | |||
3.7. Realtime Transport Protocol (RTP) | o partial and full integrity protection (with optional strong | |||
integrity check). | ||||
3.7. Lightweight User Datagram Protocol (UDP-Lite) | ||||
The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an | ||||
IETF standards track transport protocol. It provides a | ||||
unidirectional, datagram protocol that preserves message boundaries. | ||||
IETF guidance on the use of UDP-Lite is provided in | ||||
[I-D.ietf-tsvwg-rfc5405bis]. | ||||
3.7.1. Protocol Description | ||||
UDP-Lite is a connection-less datagram protocol, with no connection | ||||
setup or feature negotiation. The protocol use messages, rather than | ||||
a byte-stream. Each stream of messages is independently managed, | ||||
therefore retransmission does not hold back data sent using other | ||||
logical streams. | ||||
It provides multiplexing to multiple sockets on each host using port | ||||
numbers, and its operation follows that for UDP. An active UDP-Lite | ||||
session is identified by its four-tuple of local and remote IP | ||||
addresses and local port and remote port numbers. | ||||
UDP-Lite changes the semantics of the UDP "payload length" field to | ||||
that of a "checksum coverage length" field, and is identified by a | ||||
different IP protocol/next-header value. Otherwise, UDP-Lite is | ||||
semantically identical to UDP. Applications using UDP-Lite therefore | ||||
can not make assumptions regarding the correctness of the data | ||||
received in the insensitive part of the UDP-Lite payload. | ||||
As for UDP, mechanisms for receiver flow control, congestion control, | ||||
PMTU or PLPMTU discovery, support for ECN, etc need to be provided by | ||||
upper layer protocols [I-D.ietf-tsvwg-rfc5405bis]. | ||||
Examples of use include a class of applications that can derive | ||||
benefit from having partially-damaged payloads delivered, rather than | ||||
discarded. One use is to support error tolerate payload corruption | ||||
when used over paths that include error-prone links, another | ||||
application is when header integrity checks are required, but payload | ||||
integrity is provided by some other mechanism (e.g., [RFC6936]. | ||||
A UDP-Lite service may support IPv4 broadcast, multicast, anycast and | ||||
unicast, and IPv6 multicast, anycast and unicast. | ||||
3.7.2. Interface Description | ||||
There is no current API specified in the RFC Series, but guidance on | ||||
use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. | ||||
The interface of UDP-Lite differs from that of UDP by the addition of | ||||
a single (socket) option that communicates a checksum coverage length | ||||
value: at the sender, this specifies the intended checksum coverage, | ||||
with the remaining unprotected part of the payload called the "error- | ||||
insensitive part". The checksum coverage may also be made visible to | ||||
the application via the UDP-Lite MIB module [RFC5097]. | ||||
3.7.3. Transport Features | ||||
The transport features provided by UDP-Lite are: | ||||
o unicast | ||||
o multicast, anycast, or IPv4 broadcast. | ||||
o port multiplexing (as for UDP). | ||||
o message-oriented delivery (as for UDP). | ||||
o non-reliable delivery(as for UDP). | ||||
o non-ordered delivery (as for UDP). | ||||
o partial or full integrity protection. | ||||
3.8. Internet Control Message Protocol (ICMP) | ||||
The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and | ||||
[RFC4433] for IPv6 are IETF standards track protocols. | ||||
It provides a conection-less unidirectional protocol that delivers | ||||
individual messages. It provides none of the following transport | ||||
features: error correction, congestion control, or flow control. | ||||
Some messages may be sent as broadcast datagrams (IPv4) or multicast | ||||
datagrams (IPv4 and IPv6), in addition to unicast (and anycast) | ||||
datagrams. | ||||
3.8.1. Protocol Description | ||||
ICMP is a conection-less unidirectional protocol that delivers | ||||
individual messages. The protocol uses independent messages, | ||||
ordinarily called datagrams. Each message is required to carry a | ||||
checksum as an integrity check and to protect from misdelivery to the | ||||
wrong endpoint. | ||||
ICMP messages typically relay diagnostic information from an endpoint | ||||
[RFC1122] or network device [RFC1716] addressed to the sender of a | ||||
flow. This usually contains the network protocol header of a packet | ||||
that encountered the reported issue. Some formats of messages may | ||||
also carry other payload data. Each message carries an integrity | ||||
check calculated in the same way as UDP. | ||||
The RFC series defines additional IPv6 message formats to support a | ||||
range of uses. In the case of IPv6 the protocol incorporates | ||||
neighbour discovery [RFC2461] [RFC3971]} (provided by ARP for IPv4) | ||||
and the Multicast Listener Discovery (MLD) [RFC2710] group management | ||||
functions (provided by IGMP for IPv4). | ||||
Reliable transmission can not be assumed. A receiving application | ||||
that is unable to run sufficiently fast, or frequently, may miss | ||||
messages since there is no flow or congestion control. In addition | ||||
some network devices rate-limit ICMP messages. | ||||
Transport Protocols and upper layer protocols can use ICMP messages | ||||
to help them take appropriate decisions when network or endpoint | ||||
errors are reported. For example to implement, ICMP-based PathMTU | ||||
discovery [RFC1191][RFC1981] or assist in Packetization Layer Path | ||||
MTU Discovery (PMTUD) [RFC4821]. Such reactions to received messages | ||||
needs to protects from off-path data injection | ||||
[I-D.ietf-tsvwg-rfc5405bis], avoiding an application receiving | ||||
packets that were created by an unauthorized third party. An | ||||
application therefore needs to ensure that aLL messaged are | ||||
appropriately validated, by checking the payload of the messages to | ||||
ensure these are received in response to actually transmitted traffic | ||||
(e.g., a reported error condition that corresponds to a UDP datagram | ||||
or TCP segment was actually sent by the application). This requires | ||||
context [RFC6056], such as local state about communication instances | ||||
to each destination (e.g., in the TCP, DCCP, or SCTP protocols). | ||||
This state is not always maintained by UDP-based applications | ||||
[I-D.ietf-tsvwg-rfc5405bis]. | ||||
Any response to ICMP error messages ought to be robust to temporary | ||||
routing failures (sometimes called "soft errors"), e.g., transient | ||||
ICMP "unreachable" messages ought to not normally cause a | ||||
communication abort [RFC5461] [I-D.ietf-tsvwg-rfc5405bis]. | ||||
3.8.2. Interface Description | ||||
ICMP processing is integrated into many connection-oriented | ||||
transports, but like other functions needs to be provided by an | ||||
upper-layer protocol when using UDP and UDP-Lite. On some stacks, a | ||||
bound socket also allows a UDP application to be notified when ICMP | ||||
error messages are received for its transmissions | ||||
[I-D.ietf-tsvwg-rfc5405bis]. | ||||
3.8.3. Transport Features | ||||
The transport features provided by ICMP are: | ||||
o unidirectional. | ||||
o multicast, anycast and IP4 broadcast. | ||||
o message-oriented delivery. | ||||
o non-reliable delivery. | ||||
o non-ordered delivery. | ||||
o error and misdelivery detection (checksum). | ||||
3.9. 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, or DCCP. | |||
[EDITOR'S NOTE: Varun Singh signed up as contributor for this | [EDITOR'S NOTE: Varun Singh signed up as contributor for this | |||
section. Given the complexity of RTP, suggest to have an abbreviated | section. Given the complexity of RTP, suggest to have an abbreviated | |||
section here contrasting RTP with other transports, and focusing on | section here contrasting RTP with other transports, and focusing on | |||
those features that are RTP-unique.] | those features that are RTP-unique. Gorry Fairhurst contributed this | |||
stub section] | ||||
3.8. NACK-Oriented Reliable Multicast (NORM) | 3.9.1. Protocol Description | |||
The RTP standard [RFC3550] defines a pair of protocols, RTP and the | ||||
Real Time Control Protocol, RTCP. The transport does not provide | ||||
connection setup, but relies on out-of-band techniques or associated | ||||
control protocols to setup, negotiate parameters or tear-down a | ||||
session. | ||||
An RTP sender encapsulates audio/video data into RTP packets to | ||||
transport media streams. The RFC-series specifies RTP media formats | ||||
allow packets to carry a wide range of media, and specifies a wide | ||||
range of mulriplexing, error control and other support mechanisms. | ||||
If a frame of media data is large, it will be fragment this into | ||||
several RTP packets. If small, several frames may be bundled into a | ||||
single RTP packet. RTP may runs over a congestion-controlled or non- | ||||
congestion-controlled transport protocol. | ||||
An RTP receiver collects RTP packets from network, validates them for | ||||
correctness, and sends them to the media decoder input-queue. | ||||
Missing packet detection is performed by the channel decoder. The | ||||
play-out buffer is ordered by time stamp and is used to reorder | ||||
packets. Damaged frames may be repaired before the media payloads | ||||
are decompressed to display or store the data. | ||||
RTCP is an associated control protocol that works with RTP. Both the | ||||
RTP sender and receiver can send RTCP report packets. This is used | ||||
to periodically send control information and report performance. | ||||
Based on received RTCP feedback, an RTP sender can adjust the | ||||
transmission, e.g., perform rate adaptation at the application layer | ||||
in the case of congestion. | ||||
An RTCP receiver report (RTCP RR) is returned to the sender | ||||
periodically to report key parameters (e.g, the fraction of packets | ||||
lost in the last reporting interval, the cumulative number of packets | ||||
lost, the highest sequence number received, and the inter-arrival | ||||
jitter). The RTCP RR packets also contain timing information that | ||||
allows the sender to estimate the network round trip time (RTT) to | ||||
the receivers. | ||||
The interval between reports sent from each receiver tends to be on | ||||
the order of a few seconds on average, although this varies with the | ||||
session rate, and sub-second reporting intervals are possible for | ||||
high rate sessions. The interval is randomised to avoid | ||||
synchronization of reports from multiple receivers. | ||||
3.9.2. Interface Description | ||||
[EDITOR'S NOTE: to do] | ||||
3.9.3. Transport Features | ||||
The transport features provided by RTP are: | ||||
o unicast. | ||||
o multicast, anycast or IPv4 broadcast. | ||||
o port multiplexing. | ||||
o message-oriented delivery. | ||||
o associated protocols for connection setup with feature negotiation | ||||
and application-to-port mapping. | ||||
o support for media types and other extensions. | ||||
o segmentation and aggregation. | ||||
o performance reporting. | ||||
o drop notification. | ||||
o timestamps. | ||||
3.10. File Delivery over Unidirectional Transport/Asynchronous Layered | ||||
Coding Reliable Multicast (FLUTE/ALC) | ||||
FLUTE/ALC is an IETF standards track protocol specified in [RFC6726] | ||||
and [RFC5775],. ALC provides an underlying reliable transport service | ||||
and FLUTE a file-oriented specialization of the ALC service (e.g., to | ||||
carry associated metadata). The [RFC6726] and [RFC5775] protocols | ||||
are non-backward-compatible updates of the [RFC3926] and [RFC3450] | ||||
experimental protocols; these experimental protocols are currently | ||||
largely deployed in the 3GPP Multimedia Broadcast and Multicast | ||||
Services (MBMS) (see [MBMS], section 7) and similar contexts (e.g., | ||||
the Japanese ISDB-Tmm standard). | ||||
The FLUTE/ALC protocol has been designed to support massively | ||||
scalable reliable bulk data dissemination to receiver groups of | ||||
arbitrary size using IP Multicast over any type of delivery network, | ||||
including unidirectional networks (e.g., broadcast wireless | ||||
channels). However, the FLUTE/ALC protocol also supports point-to- | ||||
point unicast transmissions. | ||||
FLUTE/ALC bulk data dissemination has been designed for discrete file | ||||
or memory-based "objects". Transmissions happen either in push mode, | ||||
where content is sent once, or in on-demand mode, where content is | ||||
continuously sent during periods of time that can largely exceed the | ||||
average time required to download the session objects (see [RFC5651], | ||||
section 4.2). | ||||
Altough FLUTE/ALC is not well adapted to byte- and message-streaming, | ||||
there is an exception: FLUTE/ALC is used to carry 3GPP Dynamic | ||||
Adaptive Streaming over HTTP (DASH) when scalability is a requirement | ||||
(see [MBMS], section 5.6). In that case, each Audio/Video segment is | ||||
transmitted as a distinct FLUTE/ALC object in push mode. FLUTE/ALC | ||||
uses packet erasure coding (also known as Application-Level Forward | ||||
Erasure Correction, or AL-FEC) in a proactive way. The goal of using | ||||
AL-FEC is both to increase the robustness in front of packet erasures | ||||
and to improve the efficiency of the on-demand service. FLUTE/ALC | ||||
transmissions can be governed by a congestion control mechanism such | ||||
as the "Wave and Equation Based Rate Control" (WEBRC) [RFC3738] when | ||||
FLUTE/ALC is used in a layered transmission manner, with several | ||||
session channels over which ALC packets are sent. However many | ||||
FLUTE/ALC deployments involve only Constant Bit Rate (CBR) channels | ||||
with no competing flows, for which a sender-based rate control | ||||
mechanism is sufficient. In any case, FLUTE/ALC's reliability, | ||||
delivery mode, congestion control, and flow/rate control mechanisms | ||||
are distinct components that can be separately controlled to meet | ||||
different application needs. | ||||
3.10.1. Protocol Description | ||||
The FLUTE/ALC protocol works on top of UDP (though it could work on | ||||
top of any datagram delivery transport protocol), without requiring | ||||
any connectivity from receivers to the sender. Purely unidirectional | ||||
networks are therefore supported by FLUTE/ALC. This guarantees | ||||
scalability to an unlimited number of receivers in a session, since | ||||
the sender behaves exactly the same regardness of the number of | ||||
receivers. | ||||
FLUTE/ALC supports the transfer of bulk objects such as file or in- | ||||
memory content, using either a push or an on-demand mode. in push | ||||
mode, content is sent once to the receivers, while in on-demand mode, | ||||
content is sent continuously during periods of time that can greatly | ||||
exceed the average time required to download the session objects. | ||||
This enables receivers to join a session asynchronously, at their own | ||||
discretion, receive the content and leave the session. In this case, | ||||
data content is typically sent continuously, in loops (also known as | ||||
"carousels"). FLUTE/ALC also supports the transfer of an object | ||||
stream, with loose real-time constraints. This is particularly | ||||
useful to carry 3GPP DASH when scalability is a requirement and | ||||
unicast transmissions over HTTP cannot be used ([MBMS], section 5.6). | ||||
In this case, packets are sent in sequence using push mode. FLUTE/ | ||||
ALC is not well adapted to byte- and message-streaming and other | ||||
solutions could be preferred (e.g., FECFRAME [RFC6363] with real-time | ||||
flows). | ||||
The FLUTE file delivery instantiation of ALC provides a metadata | ||||
delivery service. Each object of the FLUTE/ALC session is described | ||||
in a dedicated entry of a File Delivery Table (FDT), using an XML | ||||
format (see [RFC6726], section 3.2). This metadata can include, but | ||||
is not restricted to, a URI attribute (to identify and locate the | ||||
object), a media type attribute, a size attribute, an encoding | ||||
attribute, or a message digest attribute. Since the set of objects | ||||
sent within a session can be dynamic, with new objects being added | ||||
and old ones removed, several instances of the FDT can be sent and a | ||||
mechanism is provided to identify a new FDT Instance. | ||||
To provide robustness against packet loss and improve the efficiency | ||||
of the on-demand mode, FLUTE/ALC relies on packet erasure coding (AL- | ||||
FEC). AL-FEC encoding is proactive (since there is no feedback and | ||||
therefore no (N)ACK-based retransmission) and ALC packets containing | ||||
repair data are sent along with ALC packets containing source data. | ||||
Several FEC Schemes have been standardized; FLUTE/ALC does not | ||||
mandate the use of any particular one. Several strategies concerning | ||||
the transmission order of ALC source and repair packets are possible, | ||||
in particular in on-demand mode where it can deeply impact the | ||||
service provided (e.g., to favor the recovery of objects in sequence, | ||||
or at the other extreme, to favor the recovery of all objects in | ||||
parallel), and FLUTE/ALC does not mandate nor recommend the use of | ||||
any particular one. | ||||
A FLUTE/ALC session is composed of one or more channels, associated | ||||
to different destination unicast and/or multicast IP addresses. ALC | ||||
packets are sent in those channels at a certain transmission rate, | ||||
with a rate that often differs depending on the channel. FLUTE/ALC | ||||
does not mandate nor recommend any strategy to select which ALC | ||||
packet to send on which channel. FLUTE/ALC can use a multiple rate | ||||
congestion control building block (e.g., WEBRC) to provide congestion | ||||
control that is feedback free, where receivers adjust their reception | ||||
rates individually by joining and leaving channels associated with | ||||
the session. To that purpose, the ALC header provides a specific | ||||
field to carry congestion control specific information. However | ||||
FLUTE/ALC does not mandate the use of a particular congestion control | ||||
mechanism although WEBRC is mandatory to support in case of Internet | ||||
([RFC6726], section 1.1.4). FLUTE/ALC is often used over a network | ||||
path with pre-provisoned capacity [RFC5404] whete theres are no flows | ||||
competing for capacity. In this case, a sender-based rate control | ||||
mechanism and a single channel is sufficient. | ||||
[RFC6584] provides per-packet authentication, integrity, and anti- | ||||
replay protection in the context of the ALC and NORM protocols. | ||||
Several mechanisms are proposed that seamlessly integrate into these | ||||
protocols using the ALC and NORM header extension mechanisms. | ||||
3.10.2. Interface Description | ||||
The FLUTE/ALC specification does not describe a specific application | ||||
programming interface (API) to control protocol operation. | ||||
Open source reference implementations of FLUTE/ALC are available at | ||||
http://planete-bcast.inrialpes.fr/ (no longer maintained) and | ||||
http://mad.cs.tut.fi/ (no longer maintained), and these | ||||
implementations specify and document their own APIs. Commercial | ||||
versions are also available, some derived from the above | ||||
implementations, with their own API. | ||||
3.10.3. Transport Features | ||||
The transport features provided by FLUTE/ALC are: | ||||
o unicast | ||||
o multicast, anycast or IPv4 broadcast. | ||||
o per-object dynamic meta-data delivery. | ||||
o push delivery or on-demand delivery service. | ||||
o fully reliable or partially reliable delivery (of file or in- | ||||
memory objects). | ||||
o ordered or unordered delivery (of file or in-memory objects). | ||||
o per-packet authentication, integrity, and anti-replay services. | ||||
o proactive packet erasure coding (AL-FEC) to recover from packet | ||||
erasures and improve the on-demand delivery service, | ||||
o error detection (through UDP and lower level checksums). | ||||
o congestion control for layered flows (e.g., with WEBRC). | ||||
o rate control transmission in a given channel. | ||||
3.11. NACK-Oriented Reliable Multicast (NORM) | ||||
NORM is an IETF standards track protocol specified in [RFC5740]. The | NORM is an IETF standards track protocol specified in [RFC5740]. The | |||
protocol was designed to support reliable bulk data dissemination to | protocol was designed to support reliable bulk data dissemination to | |||
receiver groups using IP Multicast but also provides for point-to- | receiver groups using IP Multicast but also provides for point-to- | |||
point unicast operation. Its support for bulk data dissemination | point unicast operation. Its support for bulk data dissemination | |||
includes discrete file or computer memory-based "objects" as well as | includes discrete file or computer memory-based "objects" as well as | |||
byte- and message-streaming. NORM is designed to incorporate packet | byte- and message-streaming. NORM is designed to incorporate packet | |||
erasure coding as an inherent part of its selective ARQ in response | erasure coding as an inherent part of its selective ARQ in response | |||
to receiver negative acknowledgements. The packet erasure coding can | to receiver negative acknowledgements. The packet erasure coding can | |||
also be proactively applied for forward protection from packet loss. | also be proactively applied for forward protection from packet loss. | |||
NORM transmissions are governed by TCP-friendly congestion control. | NORM transmissions are governed by the TCP-friendly congestion | |||
NORM's reliability, congestion control, and flow control mechanism | control. NORM's reliability, congestion control, and flow control | |||
are distinct components and can be separately controlled to meet | mechanism are distinct components and can be separately controlled to | |||
different application needs. | meet different application needs. | |||
3.8.1. Protocol Description | 3.11.1. Protocol Description | |||
[EDITOR'S NOTE: needs to be more clear about the application of FEC | [EDITOR'S NOTE: needs to be more clear about the application of FEC | |||
and packet erasure coding; expand ARQ.] | and packet erasure coding; expand ARQ.] | |||
The NORM protocol is encapsulated in UDP datagrams and thus provides | The NORM protocol is encapsulated in UDP datagrams and thus provides | |||
multiplexing for multiple sockets on hosts using port numbers. For | multiplexing for multiple sockets on hosts using port numbers. For | |||
purposes of loosely coordinated IP Multicast, NORM is not strictly | purposes of loosely coordinated IP Multicast, NORM is not strictly | |||
connection-oriented although per-sender state is maintained by | connection-oriented although per-sender state is maintained by | |||
receivers for protocol operation. [RFC5740] does not specify a | receivers for protocol operation. [RFC5740] does not specify a | |||
handshake protocol for connection establishment and separate session | handshake protocol for connection establishment and separate session | |||
skipping to change at page 21, line 33 | skipping to change at page 31, line 42 | |||
While NORM is NACK-based for reliability transfer, it also supports a | While NORM is NACK-based for reliability transfer, it also supports a | |||
positive acknowledgment (ACK) mechanism that can be used for receiver | positive acknowledgment (ACK) mechanism that can be used for receiver | |||
flow control. Again, since this mechanism is decoupled from the | flow control. Again, since this mechanism is decoupled from the | |||
reliability and congestion control, applications that have different | reliability and congestion control, applications that have different | |||
needs in this aspect can use the protocol differently. One example | needs in this aspect can use the protocol differently. One example | |||
is the use of NORM for quasi-reliable delivery where timely delivery | is the use of NORM for quasi-reliable delivery where timely delivery | |||
of newer content may be favored over completely reliable delivery of | of newer content may be favored over completely reliable delivery of | |||
older content within buffering and RTT constraints. | older content within buffering and RTT constraints. | |||
3.8.2. Interface Description | 3.11.2. Interface Description | |||
The NORM specification does not describe a specific application | The NORM specification does not describe a specific application | |||
programming interface (API) to control protocol operation. A freely- | programming interface (API) to control protocol operation. A freely- | |||
available, open source reference implementation of NORM is available | available, open source reference implementation of NORM is available | |||
at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented | at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented | |||
API is provided for this implementation. While a sockets-like API is | API is provided for this implementation. While a sockets-like API is | |||
not currently documented, the existing API supports the necessary | not currently documented, the existing API supports the necessary | |||
functions for that to be implemented. | functions for that to be implemented. | |||
3.8.3. Transport Protocol Components | 3.11.3. Transport Features | |||
The transport protocol components provided by NORM are: | ||||
o unicast | The transport features provided by NORM are: | |||
o multicast | o unicast or multicast. | |||
o port multiplexing (UDP ports) | o stream-oriented delivery in a single stream. | |||
o reliable delivery | ||||
o unordered delivery of in-memory data or file bulk content objects | o object-oriented delivery of discrete data or file items. | |||
o error detection (UDP checksum) | o reliable delivery. | |||
o segmentation | o unordered unidirectional delivery (of in-memory data or file bulk | |||
content objects). | ||||
o stream-oriented delivery in a single stream | o error detection (UDP checksum). | |||
o object-oriented delivery of discrete data or file items | o segmentation. | |||
o data bundling (Nagle's algorithm) | o data bundling (Nagle's algorithm). | |||
o flow control (timer-based and/or ack-based) | o flow control (timer-based and/or ack-based). | |||
o congestion control | o congestion control. | |||
o packet erasure coding (both proactively and as part of ARQ) | o packet erasure coding (both proactively and as part of ARQ). | |||
3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a | 3.12. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a | |||
pseudotransport | pseudotransport | |||
Transport Layer Security (TLS) and Datagram TLS (DTLS) are IETF | Transport Layer Security (TLS) and Datagram TLS (DTLS) are IETF | |||
protocols that provide several security-related features to | protocols that provide several security-related features to | |||
applications. TLS is designed to run on top of a reliable streaming | applications. TLS is designed to run on top of a reliable streaming | |||
transport protocol (usually TCP), while DTLS is designed to run on | transport protocol (usually TCP), while DTLS is designed to run on | |||
top of a best-effort datagram protocol (usually UDP). At the time of | top of a best-effort datagram protocol (UDP or DCCP [RFC5238]). At | |||
writing, the current version of TLS is 1.2; it is defined in | the time of writing, the current version of TLS is 1.2; it is defined | |||
[RFC5246]. DTLS provides nearly identical functionality to | in [RFC5246]. DTLS provides nearly identical functionality to | |||
applications; it is defined in [RFC6347] and its current version is | applications; it is defined in [RFC6347] and its current version is | |||
also 1.2. The TLS protocol evolved from the Secure Sockets Layer | also 1.2. The TLS protocol evolved from the Secure Sockets Layer | |||
(SSL) protocols developed in the mid 90s to support protection of | (SSL) protocols developed in the mid 90s to support protection of | |||
HTTP traffic. | HTTP traffic. | |||
While older versions of TLS and DTLS are still in use, they provide | While older versions of TLS and DTLS are still in use, they provide | |||
weaker security guarantees. [RFC7457] outlines important attacks on | weaker security guarantees. [RFC7457] outlines important attacks on | |||
TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document | TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document | |||
that describes secure configurations for TLS and DTLS to counter | that describes secure configurations for TLS and DTLS to counter | |||
these attacks. The recommendations are applicable for the vast | these attacks. The recommendations are applicable for the vast | |||
majority of use cases. | majority of use cases. | |||
[NOTE: The Logjam authors (weakdh.org) give (inconclusive) evidence | [NOTE: The Logjam authors (weakdh.org) give (inconclusive) evidence | |||
that one of the recommendations of [RFC7525], namely the use of | that one of the recommendations of [RFC7525], namely the use of | |||
DHE-1024 as a fallback, may not be sufficient in all cases to counter | DHE-1024 as a fallback, may not be sufficient in all cases to counter | |||
an attacker with the resources of a nation-state. It is unclear at | an attacker with the resources of a nation-state. It is unclear at | |||
this time if the RFC is going to be updated as a result, or whether | this time if the RFC is going to be updated as a result, or whether | |||
there will be an RFC7525bis.] | there will be an RFC7525bis.] | |||
3.9.1. Protocol Description | 3.12.1. Protocol Description | |||
Both TLS and DTLS provide the same security features and can thus be | Both TLS and DTLS provide the same security features and can thus be | |||
discussed together. The features they provide are: | discussed together. The features they provide are: | |||
o Confidentiality | o Confidentiality | |||
o Data integrity | o Data integrity | |||
o Peer authentication (optional) | o Peer authentication (optional) | |||
skipping to change at page 23, line 33 | skipping to change at page 33, line 40 | |||
should be interpreted. For example, in the common use case of | should be interpreted. For example, in the common use case of | |||
authentication by means of an X.509 certificate, it is the | authentication by means of an X.509 certificate, it is the | |||
application's decision whether the certificate of the peering entity | application's decision whether the certificate of the peering entity | |||
is acceptable for authorization decisions. Perfect forward secrecy, | is acceptable for authorization decisions. Perfect forward secrecy, | |||
if enabled and supported by the selected algorithms, ensures that | if enabled and supported by the selected algorithms, ensures that | |||
traffic encrypted and captured during a session at time t0 cannot be | traffic encrypted and captured during a session at time t0 cannot be | |||
later decrypted at time t1 (t1 > t0), even if the long-term secrets | later decrypted at time t1 (t1 > t0), even if the long-term secrets | |||
of the communicating peers are later compromised. | of the communicating peers are later compromised. | |||
As DTLS is generally used over an unreliable datagram transport such | As DTLS is generally used over an unreliable datagram transport such | |||
as TCP, applications will need to tolerate loss, re-ordered, or | as UDP, applications will need to tolerate loss, re-ordered, or | |||
duplicated datagrams. Like TLS, DTLS conveys application data in a | duplicated datagrams. Like TLS, DTLS conveys application data in a | |||
sequence of independent records. However, because records are mapped | sequence of independent records. However, because records are mapped | |||
to unreliable datagrams, there are several features unique to DTLS | to unreliable datagrams, there are several features unique to DTLS | |||
that are not applicable to TLS: | that are not applicable to TLS: | |||
o Record replay detection (optional) | o Record replay detection (optional). | |||
o Record size negotiation (estimates of PMTU and record size | o Record size negotiation (estimates of PMTU and record size | |||
expansion factor) | expansion factor). | |||
o Coveyance of IP don't fragment (DF) bit settings by application | o Coveyance of IP don't fragment (DF) bit settings by application. | |||
o An anti-DoS stateless cookie mechanism (optional) | o An anti-DoS stateless cookie mechanism (optional). | |||
Generally, DTLS follows the TLS design as closely as possible. To | Generally, DTLS follows the TLS design as closely as possible. To | |||
operate over datagrams, DTLS includes a sequence number and limited | operate over datagrams, DTLS includes a sequence number and limited | |||
forms of retransmission and fragmentation for its internal | forms of retransmission and fragmentation for its internal | |||
operations. The sequence number may be used for detecting replayed | operations. The sequence number may be used for detecting replayed | |||
information, according to the windowing procedure described in | information, according to the windowing procedure described in | |||
Section 4.1.2.6 of [RFC6347]. Note also that DTLS bans the use of | Section 4.1.2.6 of [RFC6347]. Note also that DTLS forbids the use of | |||
stream ciphers, which are essentially incompatible when operating on | stream ciphers, which are essentially incompatible when operating on | |||
independent encrypted records. | independent encrypted records. | |||
3.9.2. Interface Description | 3.12.2. Interface Description | |||
TLS is commonly invoked using an API provided by packages such as | TLS is commonly invoked using an API provided by packages such as | |||
OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the | OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the | |||
manipulation of several important abstractions, which fall into the | manipulation of several important abstractions, which fall into the | |||
following categories: long-term keys and algorithms, session state, | following categories: long-term keys and algorithms, session state, | |||
and communications/connections. There may also be special APIs | and communications/connections. There may also be special APIs | |||
required to deal with time and/or random numbers, both of which are | required to deal with time and/or random numbers, both of which are | |||
needed by a variety of encryption algorithms and protocols. | needed by a variety of encryption algorithms and protocols. | |||
Considerable care is required in the use of TLS APIs in order to | Considerable care is required in the use of TLS APIs in order to | |||
skipping to change at page 24, line 35 | skipping to change at page 34, line 43 | |||
As an example, in the case of OpenSSL, the primary abstractions are | As an example, in the case of OpenSSL, the primary abstractions are | |||
the library itself and method (protocol), session, context, cipher | the library itself and method (protocol), session, context, cipher | |||
and connection. After initializing the library and setting the | and connection. After initializing the library and setting the | |||
method, a cipher suite is chosen and used to configure a context | method, a cipher suite is chosen and used to configure a context | |||
object. Session objects may then be minted according to the | object. Session objects may then be minted according to the | |||
parameters present in a context object and associated with individual | parameters present in a context object and associated with individual | |||
connections. Depending on how precisely the programmer wishes to | connections. Depending on how precisely the programmer wishes to | |||
select different algorithmic or protocol options, various levels of | select different algorithmic or protocol options, various levels of | |||
details may be required. | details may be required. | |||
3.9.3. Transport Protocol Components | 3.12.3. Transport Features | |||
Both TLS and DTLS employ a layered architecture. The lower layer is | Both TLS and DTLS employ a layered architecture. The lower layer is | |||
commonly called the record protocol. It is responsible for | commonly called the record protocol. It is responsible for: | |||
fragmenting messages, applying message authentication codes (MACs), | ||||
encrypting data, and invoking transmission from the underlying | o message fragmentation | |||
transport protocol. DTLS augments the TLS record protocol with | ||||
sequence numbers used for ordering and replay detection. | o authentication and integrity via message authentication codes | |||
(MAC) | ||||
o data encryption | ||||
o scheduling transmission using the underlying transport protocol | ||||
DTLS augments the TLS record protocol with: | ||||
o ordering and replay protection, implemented using sequence | ||||
numbers. | ||||
Several protocols are layered on top of the record protocol. These | Several protocols are layered on top of the record protocol. These | |||
include the handshake, alert, and change cipher spec protocols. | include the handshake, alert, and change cipher spec protocols. | |||
There is also the data protocol, used to carry application traffic. | There is also the data protocol, used to carry application traffic. | |||
The handshake protocol is used to establish cryptographic and | The handshake protocol is used to establish cryptographic and | |||
compression parameters when a connection is first set up. In DTLS, | compression parameters when a connection is first set up. In DTLS, | |||
this protocol also has a basic fragmentation and retransmission | this protocol also has a basic fragmentation and retransmission | |||
capability and a cookie-like mechanism to resist DoS attacks. (TLS | capability and a cookie-like mechanism to resist DoS attacks. (TLS | |||
compression is not recommended at present). The alert protocol is | compression is not recommended at present). The alert protocol is | |||
used to inform the peer of various conditions, most of which are | used to inform the peer of various conditions, most of which are | |||
terminal for the connection. The change cipher spec protocol is used | terminal for the connection. The change cipher spec protocol is used | |||
to synchronize changes in cryptographic parameters for each peer. | to synchronize changes in cryptographic parameters for each peer. | |||
3.10. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport | 3.13. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport | |||
Hypertext Transfer Protocol (HTTP) is an application-level protocol | Hypertext Transfer Protocol (HTTP) is an application-level protocol | |||
widely used on the Internet. Version 1.1 of the protocol is | widely used on the Internet. Version 1.1 of the protocol is | |||
specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] | specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] | |||
[RFC7235], and version 2 in [RFC7540]. Furthermore, HTTP is used as | [RFC7235], and version 2 in [RFC7540]. Furthermore, HTTP is used as | |||
a substrate for other application-layer protocols. There are various | a substrate for other application-layer protocols. There are various | |||
reasons for this practice listed in [RFC3205]; these include being a | reasons for this practice listed in [RFC3205]; these include being a | |||
well-known and well-understood protocol, reusability of existing | well-known and well-understood protocol, reusability of existing | |||
servers and client libraries, easy use of existing security | servers and client libraries, easy use of existing security | |||
mechanisms such as HTTP digest authentication [RFC2617] and TLS | mechanisms such as HTTP digest authentication [RFC2617] and TLS | |||
[RFC5246], the ability of HTTP to traverse firewalls which makes it | [RFC5246], the ability of HTTP to traverse firewalls which makes it | |||
work with a lot of infrastructure, and cases where a application | work with a lot of infrastructure, and cases where a application | |||
server often needs to support HTTP anyway. | server often needs to support HTTP anyway. | |||
Depending on application's needs, the use of HTTP as a substrate | Depending on application's needs, the use of HTTP as a substrate | |||
protocol may add complexity and overhead in comparison to a special- | protocol may add complexity and overhead in comparison to a special- | |||
purpose protocol (e.g. HTTP headers, suitability of the HTTP security | purpose protocol (e.g. HTTP headers, suitability of the HTTP | |||
model etc.). [RFC3205] address this issues and provides some | security model etc.). [RFC3205] address this issues and provides | |||
guidelines and concerns about the use of HTTP standard port 80 and | some guidelines and concerns about the use of HTTP standard port 80 | |||
443, the use of HTTP URL scheme and interaction with existing | and 443, the use of HTTP URL scheme and interaction with existing | |||
firewalls, proxies and NATs. | firewalls, proxies and NATs. | |||
Though not strictly bound to TCP, HTTP is almost exclusively run over | Though not strictly bound to TCP, HTTP is almost exclusively run over | |||
TCP, and therefore inherits its properties when used in this way. | TCP, and therefore inherits its properties when used in this way. | |||
3.10.1. Protocol Description | 3.13.1. Protocol Description | |||
Hypertext Transfer Protocol (HTTP) is a request/response protocol. A | Hypertext Transfer Protocol (HTTP) is a request/response protocol. A | |||
client sends a request containing a request method, URI and protocol | client sends a request containing a request method, URI and protocol | |||
version followed by a MIME-like message (see [RFC7231] for the | version followed by a MIME-like message (see [RFC7231] for the | |||
differences between an HTTP object and a MIME message), containing | differences between an HTTP object and a MIME message), containing | |||
information about the client and request modifiers. The message can | information about the client and request modifiers. The message can | |||
contain a message body carrying application data as well. The server | contain a message body carrying application data as well. The server | |||
responds with a status or error code followed by a MIME-like message | responds with a status or error code followed by a MIME-like message | |||
containing information about the server and information about carried | containing information about the server and information about carried | |||
data and it can include a message body. It is possible to specify a | data and it can include a message body. It is possible to specify a | |||
skipping to change at page 26, line 30 | skipping to change at page 36, line 49 | |||
(denoted by HTTPS), which adds protocol properties provided by such a | (denoted by HTTPS), which adds protocol properties provided by such a | |||
mechanism (e.g. authentication, encryption, etc.). TLS's | mechanism (e.g. authentication, encryption, etc.). TLS's | |||
Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can | Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can | |||
be used for HTTP version negotiation within TLS handshake which | be used for HTTP version negotiation within TLS handshake which | |||
eliminates addition round-trip. Arbitrary cookie strings, included | eliminates addition round-trip. Arbitrary cookie strings, included | |||
as part of the MIME headers, are often used as bearer tokens in HTTP. | as part of the MIME headers, are often used as bearer tokens in HTTP. | |||
Application layer protocols using HTTP as substrate may use existing | Application layer protocols using HTTP as substrate may use existing | |||
method and data formats, or specify new methods and data formats. | method and data formats, or specify new methods and data formats. | |||
Furthermore some protocols may not fit a request/response paradigm | Furthermore some protocols may not fit a request/response paradigm | |||
and instead rely on HTTP to send messages (e.g. [RFC6546]). Because | and instead rely on HTTP to send messages (e.g. [RFC6546]). Because | |||
HTTP is working in many restricted infrastructures, it is also used | HTTP is working in many restricted infrastructures, it is also used | |||
to tunnel other application-layer protocols. | to tunnel other application-layer protocols. | |||
3.10.2. Interface Description | 3.13.2. Interface Description | |||
There are many HTTP libraries available exposing different APIs. The | There are many HTTP libraries available exposing different APIs. The | |||
APIs provide a way to specify a request by providing a URI, a method, | APIs provide a way to specify a request by providing a URI, a method, | |||
request modifiers and optionally a request body. For the response, | request modifiers and optionally a request body. For the response, | |||
callbacks can be registered that will be invoked when the response is | callbacks can be registered that will be invoked when the response is | |||
received. If TLS is used, API expose a registration of callbacks in | received. If TLS is used, API expose a registration of callbacks in | |||
case a server requests client authentication and when certificate | case a server requests client authentication and when certificate | |||
verification is needed. | verification is needed. | |||
World Wide Web Consortium (W3C) standardized the XMLHttpRequest API | World Wide Web Consortium (W3C) standardized the XMLHttpRequest API | |||
skipping to change at page 27, line 10 | skipping to change at page 37, line 28 | |||
response data format can also be JSON, HTML and plain text. | response data format can also be JSON, HTML and plain text. | |||
Specifically JavaScript and XMLHttpRequest are a ubiquitous | Specifically JavaScript and XMLHttpRequest are a ubiquitous | |||
programming model for websites, and more general applications, where | programming model for websites, and more general applications, where | |||
native code is less attractive. | native code is less attractive. | |||
Representational State Transfer (REST) [REST] is another example how | Representational State Transfer (REST) [REST] is another example how | |||
applications can use HTTP as transport protocol. REST is an | applications can use HTTP as transport protocol. REST is an | |||
architecture style for building application on the Internet. It uses | architecture style for building application on the Internet. It uses | |||
HTTP as a communication protocol. | HTTP as a communication protocol. | |||
3.10.3. Transport Protocol Components | 3.13.3. Transport features | |||
The transport protocol components provided by HTTP, when used as a | The transport features provided by HTTP, when used as a | |||
pseudotransport, are: | pseudotransport, are: | |||
o unicast | o unicast. | |||
o reliable delivery | ||||
o ordered delivery | ||||
o message and stream-oriented | ||||
o object range request | ||||
o message content type negotiation | o message and stream-oriented transfer. | |||
o congestion control | o bi- or unidirectional transmission. | |||
HTTPS (HTTP over TLS) additionally provides the following components: | o ordered delivery. | |||
o authentication (of one or both ends of a connection) | o fully reliable delivery. | |||
o confidentiality | o object range request. | |||
o integrity protection | o message content type negotiation. | |||
3.11. WebSockets | o flow control. | |||
[RFC6455] | HTTPS (HTTP over TLS) additionally provides the following components: | |||
[EDITOR'S NOTE: Salvatore Loreto will contribute text for this | o authentication (of one or both ends of a connection). | |||
section.] | ||||
3.11.1. Protocol Description | o confidentiality. | |||
3.11.2. Interface Description | o integrity protection. | |||
3.11.3. Transport Protocol Components | ||||
4. Transport Service Features | 4. Transport Service Features | |||
[EDITOR'S NOTE: This section is still work-in-progress. This list is | [EDITOR'S NOTE: This section is still work-in-progress. This list is | |||
probably not complete and/or too detailed.] | probably not complete and/or too detailed.] | |||
The transport protocol components analyzed in this document which can | The transport protocol components analyzed in this document which can | |||
be used as a basis for defining common transport service features, | be used as a basis for defining common transport service features, | |||
normalized and separated into categories, are as follows: | normalized and separated into categories, are as follows: | |||
o Control Functions | o Control Functions | |||
* Addressing | * Addressing | |||
+ unicast | + unicast | |||
+ broadcast (IPv4 only) | + multicast, anycast and IPv4 broadcast | |||
+ multicast | ||||
+ anycast | ||||
+ something on ports and NAT | + use of NAPT-compatible port numbers | |||
* Multihoming support | * Multihoming support | |||
+ multihoming for resilience | + multihoming for resilience | |||
+ multihoming for mobility | + multihoming for mobility | |||
- specify handover latency? | - specify handover latency? | |||
+ multihoming for load-balancing | + multihoming for load-balancing | |||
skipping to change at page 28, line 51 | skipping to change at page 38, line 50 | |||
* Multiplexing | * Multiplexing | |||
+ application to port mapping | + application to port mapping | |||
+ single vs. multiple streaming | + single vs. multiple streaming | |||
o Delivery | o Delivery | |||
* reliability | * reliability | |||
+ reliable delivery | + fully reliable delivery | |||
+ partially reliable delivery | ||||
+ partially reliable delivery | ||||
- packet erasure coding | - packet erasure coding | |||
+ unreliable delivery | + unreliable delivery | |||
- drop notification | - drop notification | |||
- Integrity protection | - Integrity protection | |||
o checksum for error detection | o checksum for error detection | |||
o partial checksum protection | o partial payload checksum protection | |||
o checksum optional | o checksum optional | |||
* ordering | * ordering | |||
+ ordered delivery | + ordered delivery | |||
+ unordered delivery | + unordered delivery | |||
- unordered delivery of in-memory data | - unordered delivery of in-memory data | |||
skipping to change at page 30, line 4 | skipping to change at page 39, line 49 | |||
o Transmission control | o Transmission control | |||
* rate control | * rate control | |||
+ timer-based | + timer-based | |||
+ ACK-based | + ACK-based | |||
* congestion control | * congestion control | |||
* flow control | ||||
* flow control | ||||
* segmentation | * segmentation | |||
* data/message bundling (Nagle's algorithm) | * data/message bundling (Nagle's algorithm) | |||
* stream scheduling prioritization | * stream scheduling prioritization | |||
o Security | o Security | |||
* authentication of one end of a connection | * authentication of one end of a connection | |||
* authentication of both ends of a connection | * authentication of both ends of a connection | |||
* confidentiality | * confidentiality | |||
* cryptographic integrity protection | * cryptographic integrity protection | |||
The next revision of this document will define transport service | A future revision of this document will define transport service | |||
features based upon this list. | features based upon this list. | |||
[EDITOR'S NOTE: this section will drawn from the candidate features | [EDITOR'S NOTE: this section will drawn from the candidate features | |||
provided by protocol components in the previous section - please | provided by protocol components in the previous section - please | |||
discuss on taps@ietf.org list] | discuss on taps@ietf.org list] | |||
4.1. Complete Protocol Feature Matrix | 4.1. Complete Protocol Feature Matrix | |||
[EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this | [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 | section. Michael Welzl also has a beginning of a matrix which could | |||
skipping to change at page 32, line 26 | skipping to change at page 42, line 36 | |||
o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera | o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera | |||
(ferlin@simula.no) and Olivier Mehani | (ferlin@simula.no) and Olivier Mehani | |||
(olivier.mehani@nicta.com.au) | (olivier.mehani@nicta.com.au) | |||
o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com) | 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- | o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh- | |||
muenster.de) | muenster.de) | |||
o Section 3.8 on NORM was contributed by Brian Adamson | o Section 3.10 on FLUTE/ALC was contributed by Vincent Roca | |||
(vincent.roca@inria.fr) | ||||
o Section 3.11 on NORM was contributed by Brian Adamson | ||||
(brian.adamson@nrl.navy.mil) | (brian.adamson@nrl.navy.mil) | |||
o Section 3.9 on MPTCP was contributed by Ralph Holz | o Section 3.12 on TLS and DTLS was contributed by Ralph Holz | |||
(ralph.holz@nicta.com.au) and Olivier Mehani | (ralph.holz@nicta.com.au) and Olivier Mehani | |||
(olivier.mehani@nicta.com.au) | (olivier.mehani@nicta.com.au) | |||
o Section 3.10 on HTTP was contributed by Dragana Damjanovic | o Section 3.13 on HTTP was contributed by Dragana Damjanovic | |||
(ddamjanovic@mozilla.com) | (ddamjanovic@mozilla.com) | |||
8. Acknowledgments | 8. Acknowledgments | |||
Thanks to Karen Nielsen, Joe Touch, and Michael Welzl for the | Thanks to Karen Nielsen, Joe Touch, and Michael Welzl for the | |||
comments, feedback, and discussion. This work is partially supported | comments, feedback, and discussion. This work is partially supported | |||
by the European Commission under grant agreement FP7-ICT-318627 | by the European Commission under grant agreements FP7-ICT-318627 | |||
mPlane; support does not imply endorsement. | mPlane and from the Horizon 2020 research and innovation program | |||
under grant agreement No. 644334 (NEAT); support does not imply | ||||
[EDITOR'S NOTE: add H2020-NEAT ack]. | endorsement. | |||
9. References | ||||
9.1. Normative References | ||||
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September | 9. Informative References | |||
1981. | ||||
9.2. Informative References | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI | |||
10.17487/RFC0768, August 1980, | ||||
<http://www.rfc-editor.org/info/rfc768>. | ||||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
August 1980. | RFC 792, DOI 10.17487/RFC0792, September 1981, | |||
<http://www.rfc-editor.org/info/rfc792>. | ||||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | |||
793, September 1981. | 793, DOI 10.17487/RFC0793, September 1981, | |||
<http://www.rfc-editor.org/info/rfc793>. | ||||
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", | [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", | |||
RFC 896, January 1984. | RFC 896, DOI 10.17487/RFC0896, January 1984, | |||
<http://www.rfc-editor.org/info/rfc896>. | ||||
[RFC1122] Braden, R., "Requirements for Internet Hosts - | [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - | |||
Communication Layers", STD 3, RFC 1122, October 1989. | Communication Layers", STD 3, RFC 1122, DOI 10.17487/ | |||
RFC1122, October 1989, | ||||
<http://www.rfc-editor.org/info/rfc1122>. | ||||
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, | [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, | |||
November 1990. | DOI 10.17487/RFC1191, November 1990, | |||
<http://www.rfc-editor.org/info/rfc1191>. | ||||
[RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for | ||||
IP Routers", RFC 1716, DOI 10.17487/RFC1716, November | ||||
1994, <http://www.rfc-editor.org/info/rfc1716>. | ||||
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | |||
for IP version 6", RFC 1981, August 1996. | for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August | |||
1996, <http://www.rfc-editor.org/info/rfc1981>. | ||||
[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, DOI 10.17487/ | |||
RFC2018, October 1996, | ||||
<http://www.rfc-editor.org/info/rfc2018>. | ||||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
Bodies", RFC 2045, November 1996. | Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | |||
<http://www.rfc-editor.org/info/rfc2045>. | ||||
[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, DOI 10.17487/RFC2460, | |||
December 1998, <http://www.rfc-editor.org/info/rfc2460>. | ||||
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor | ||||
Discovery for IP Version 6 (IPv6)", RFC 2461, DOI | ||||
10.17487/RFC2461, December 1998, | ||||
<http://www.rfc-editor.org/info/rfc2461>. | ||||
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | |||
Leach, P., Luotonen, A., and L. Stewart, "HTTP | Leach, P., Luotonen, A., and L. Stewart, "HTTP | |||
Authentication: Basic and Digest Access Authentication", | Authentication: Basic and Digest Access Authentication", | |||
RFC 2617, June 1999. | RFC 2617, DOI 10.17487/RFC2617, June 1999, | |||
<http://www.rfc-editor.org/info/rfc2617>. | ||||
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast | ||||
Listener Discovery (MLD) for IPv6", RFC 2710, DOI | ||||
10.17487/RFC2710, October 1999, | ||||
<http://www.rfc-editor.org/info/rfc2710>. | ||||
[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, DOI 10.17487/RFC3168, September 2001, | |||
<http://www.rfc-editor.org/info/rfc3168>. | ||||
[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, DOI 10.17487/RFC3205, February 2002, | |||
<http://www.rfc-editor.org/info/rfc3205>. | ||||
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's | ||||
Initial Window", RFC 3390, October 2002. | ||||
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport | [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport | |||
Layer Security over Stream Control Transmission Protocol", | Layer Security over Stream Control Transmission Protocol", | |||
RFC 3436, December 2002. | RFC 3436, DOI 10.17487/RFC3436, December 2002, | |||
<http://www.rfc-editor.org/info/rfc3436>. | ||||
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. | ||||
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol | ||||
Instantiation", RFC 3450, DOI 10.17487/RFC3450, December | ||||
2002, <http://www.rfc-editor.org/info/rfc3450>. | ||||
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, | [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, | |||
M., and J. Crowcroft, "Forward Error Correction (FEC) | M., and J. Crowcroft, "Forward Error Correction (FEC) | |||
Building Block", RFC 3452, December 2002. | Building Block", RFC 3452, DOI 10.17487/RFC3452, December | |||
2002, <http://www.rfc-editor.org/info/rfc3452>. | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | ||||
Jacobson, "RTP: A Transport Protocol for Real-Time | ||||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | ||||
July 2003, <http://www.rfc-editor.org/info/rfc3550>. | ||||
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate | ||||
Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/ | ||||
RFC3738, April 2004, | ||||
<http://www.rfc-editor.org/info/rfc3738>. | ||||
[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, DOI 10.17487/ | |||
RFC3758, May 2004, | ||||
<http://www.rfc-editor.org/info/rfc3758>. | ||||
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and | [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., | |||
G. Fairhurst, "The Lightweight User Datagram Protocol | and G. Fairhurst, Ed., "The Lightweight User Datagram | |||
(UDP-Lite)", RFC 3828, July 2004. | Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July | |||
2004, <http://www.rfc-editor.org/info/rfc3828>. | ||||
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, | ||||
"FLUTE - File Delivery over Unidirectional Transport", RFC | ||||
3926, DOI 10.17487/RFC3926, October 2004, | ||||
<http://www.rfc-editor.org/info/rfc3926>. | ||||
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | ||||
"SEcure Neighbor Discovery (SEND)", RFC 3971, DOI | ||||
10.17487/RFC3971, March 2005, | ||||
<http://www.rfc-editor.org/info/rfc3971>. | ||||
[RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access | [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access | |||
Protocol (CAP)", RFC 4324, December 2005. | Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December | |||
2005, <http://www.rfc-editor.org/info/rfc4324>. | ||||
[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 | |||
4336, March 2006. | 4336, DOI 10.17487/RFC4336, March 2006, | |||
<http://www.rfc-editor.org/info/rfc4336>. | ||||
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram | [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram | |||
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. | Congestion Control Protocol (DCCP)", RFC 4340, DOI | |||
10.17487/RFC4340, March 2006, | ||||
<http://www.rfc-editor.org/info/rfc4340>. | ||||
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion | [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion | |||
Control Protocol (DCCP) Congestion Control ID 2: TCP-like | Control Protocol (DCCP) Congestion Control ID 2: TCP-like | |||
Congestion Control", RFC 4341, March 2006. | Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March | |||
2006, <http://www.rfc-editor.org/info/rfc4341>. | ||||
[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. | DOI 10.17487/RFC4342, March 2006, | |||
<http://www.rfc-editor.org/info/rfc4342>. | ||||
[RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 | ||||
Dynamic Home Agent (HA) Assignment", RFC 4433, DOI | ||||
10.17487/RFC4433, March 2006, | ||||
<http://www.rfc-editor.org/info/rfc4433>. | ||||
[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, DOI 10.17487/RFC4614, September | |||
2006, <http://www.rfc-editor.org/info/rfc4614>. | ||||
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast | [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast | |||
Congestion Control (TFMCC): Protocol Specification", RFC | Congestion Control (TFMCC): Protocol Specification", RFC | |||
4654, August 2006. | 4654, DOI 10.17487/RFC4654, August 2006, | |||
<http://www.rfc-editor.org/info/rfc4654>. | ||||
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and | [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and | |||
Parameter for the Stream Control Transmission Protocol | Parameter for the Stream Control Transmission Protocol | |||
(SCTP)", RFC 4820, March 2007. | (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, | |||
<http://www.rfc-editor.org/info/rfc4820>. | ||||
[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, DOI 10.17487/RFC4821, March 2007, | |||
<http://www.rfc-editor.org/info/rfc4821>. | ||||
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, | [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, | |||
"Authenticated Chunks for the Stream Control Transmission | "Authenticated Chunks for the Stream Control Transmission | |||
Protocol (SCTP)", RFC 4895, August 2007. | Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August | |||
2007, <http://www.rfc-editor.org/info/rfc4895>. | ||||
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC | [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | |||
4960, September 2007. | RFC 4960, DOI 10.17487/RFC4960, September 2007, | |||
<http://www.rfc-editor.org/info/rfc4960>. | ||||
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. | [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. | |||
Kozuka, "Stream Control Transmission Protocol (SCTP) | Kozuka, "Stream Control Transmission Protocol (SCTP) | |||
Dynamic Address Reconfiguration", RFC 5061, September | Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/ | |||
2007. | RFC5061, September 2007, | |||
<http://www.rfc-editor.org/info/rfc5061>. | ||||
[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, DOI 10.17487/RFC5097, January 2008, | |||
<http://www.rfc-editor.org/info/rfc5097>. | ||||
[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, DOI 10.17487/ | |||
RFC5246, August 2008, | ||||
<http://www.rfc-editor.org/info/rfc5246>. | ||||
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP | [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over | |||
Friendly Rate Control (TFRC): Protocol Specification", RFC | the Datagram Congestion Control Protocol (DCCP)", RFC | |||
5348, September 2008. | 5238, DOI 10.17487/RFC5238, May 2008, | |||
<http://www.rfc-editor.org/info/rfc5238>. | ||||
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines | [RFC5404] Westerlund, M. and I. Johansson, "RTP Payload Format for | |||
for Application Designers", BCP 145, RFC 5405, November | G.719", RFC 5404, DOI 10.17487/RFC5404, January 2009, | |||
2008. | <http://www.rfc-editor.org/info/rfc5404>. | |||
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI | ||||
10.17487/RFC5461, February 2009, | ||||
<http://www.rfc-editor.org/info/rfc5461>. | ||||
[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, DOI 10.17487/RFC5595, | |||
September 2009, <http://www.rfc-editor.org/info/rfc5595>. | ||||
[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol | [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol | |||
(DCCP) Simultaneous-Open Technique to Facilitate NAT/ | (DCCP) Simultaneous-Open Technique to Facilitate NAT/ | |||
Middlebox Traversal", RFC 5596, September 2009. | Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, | |||
September 2009, <http://www.rfc-editor.org/info/rfc5596>. | ||||
[RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File | [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding | |||
System (NFS) Version 4 Minor Version 1 External Data | Transport (LCT) Building Block", RFC 5651, DOI 10.17487/ | |||
Representation Standard (XDR) Description", RFC 5662, | RFC5651, October 2009, | |||
January 2010. | <http://www.rfc-editor.org/info/rfc5651>. | |||
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) | [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., | |||
Signatures -- Update", RFC 5672, August 2009. | "Network File System (NFS) Version 4 Minor Version 1 | |||
External Data Representation Standard (XDR) Description", | ||||
RFC 5662, DOI 10.17487/RFC5662, January 2010, | ||||
<http://www.rfc-editor.org/info/rfc5662>. | ||||
[RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail | ||||
(DKIM) Signatures -- Update", RFC 5672, DOI 10.17487/ | ||||
RFC5672, August 2009, | ||||
<http://www.rfc-editor.org/info/rfc5672>. | ||||
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, | [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, | |||
"NACK-Oriented Reliable Multicast (NORM) Transport | "NACK-Oriented Reliable Multicast (NORM) Transport | |||
Protocol", RFC 5740, November 2009. | Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, | |||
<http://www.rfc-editor.org/info/rfc5740>. | ||||
[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 | [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous | |||
Authentication Option", RFC 5925, June 2010. | Layered Coding (ALC) Protocol Instantiation", RFC 5775, | |||
DOI 10.17487/RFC5775, April 2010, | ||||
<http://www.rfc-editor.org/info/rfc5775>. | ||||
[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, DOI 10.17487/RFC5681, September 2009, | |||
<http://www.rfc-editor.org/info/rfc5681>. | ||||
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | ||||
Protocol Port Randomization", BCP 156, RFC 6056, DOI | ||||
10.17487/RFC6056, January 2011, | ||||
<http://www.rfc-editor.org/info/rfc6056>. | ||||
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram | [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram | |||
Transport Layer Security (DTLS) for Stream Control | Transport Layer Security (DTLS) for Stream Control | |||
Transmission Protocol (SCTP)", RFC 6083, January 2011. | Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/ | |||
RFC6083, January 2011, | ||||
<http://www.rfc-editor.org/info/rfc6083>. | ||||
[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, DOI 10.17487/RFC6093, | |||
January 2011, <http://www.rfc-editor.org/info/rfc6093>. | ||||
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control | [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control | |||
Transmission Protocol (SCTP) Stream Reconfiguration", RFC | Transmission Protocol (SCTP) Stream Reconfiguration", RFC | |||
6525, February 2012. | 6525, DOI 10.17487/RFC6525, February 2012, | |||
<http://www.rfc-editor.org/info/rfc6525>. | ||||
[RFC6546] Trammell, B., "Transport of Real-time Inter-network | [RFC6546] Trammell, B., "Transport of Real-time Inter-network | |||
Defense (RID) Messages over HTTP/TLS", RFC 6546, April | Defense (RID) Messages over HTTP/TLS", RFC 6546, DOI | |||
2012. | 10.17487/RFC6546, April 2012, | |||
<http://www.rfc-editor.org/info/rfc6546>. | ||||
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, | ||||
"Computing TCP's Retransmission Timer", RFC 6298, June | ||||
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, DOI 10.17487/RFC6347, | |||
January 2012, <http://www.rfc-editor.org/info/rfc6347>. | ||||
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled | [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled | |||
Congestion Control for Multipath Transport Protocols", RFC | Congestion Control for Multipath Transport Protocols", RFC | |||
6356, October 2011. | 6356, DOI 10.17487/RFC6356, October 2011, | |||
<http://www.rfc-editor.org/info/rfc6356>. | ||||
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error | ||||
Correction (FEC) Framework", RFC 6363, DOI 10.17487/ | ||||
RFC6363, October 2011, | ||||
<http://www.rfc-editor.org/info/rfc6363>. | ||||
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC | [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC | |||
6455, December 2011. | 6455, DOI 10.17487/RFC6455, December 2011, | |||
<http://www.rfc-editor.org/info/rfc6455>. | ||||
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. | [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. | |||
Yasevich, "Sockets API Extensions for the Stream Control | Yasevich, "Sockets API Extensions for the Stream Control | |||
Transmission Protocol (SCTP)", RFC 6458, December 2011. | Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/ | |||
RFC6458, December 2011, | ||||
<http://www.rfc-editor.org/info/rfc6458>. | ||||
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", | [RFC6584] Roca, V., "Simple Authentication Schemes for the | |||
RFC 6691, July 2012. | Asynchronous Layered Coding (ALC) and NACK-Oriented | |||
Reliable Multicast (NORM) Protocols", RFC 6584, DOI | ||||
10.17487/RFC6584, April 2012, | ||||
<http://www.rfc-editor.org/info/rfc6584>. | ||||
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, | ||||
"FLUTE - File Delivery over Unidirectional Transport", RFC | ||||
6726, DOI 10.17487/RFC6726, November 2012, | ||||
<http://www.rfc-editor.org/info/rfc6726>. | ||||
[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A | ||||
Datagram Congestion Control Protocol UDP Encapsulation for | ||||
NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November | ||||
2012, <http://www.rfc-editor.org/info/rfc6773>. | ||||
[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, DOI 10.17487/RFC6824, January 2013, | |||
<http://www.rfc-editor.org/info/rfc6824>. | ||||
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application | [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application | |||
Interface Considerations", RFC 6897, March 2013. | Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, | |||
March 2013, <http://www.rfc-editor.org/info/rfc6897>. | ||||
[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, DOI | |||
10.17487/RFC6935, April 2013, | ||||
<http://www.rfc-editor.org/info/rfc6935>. | ||||
[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, DOI 10.17487/RFC6936, April 2013, | |||
<http://www.rfc-editor.org/info/rfc6936>. | ||||
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream | [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream | |||
Control Transmission Protocol (SCTP) Packets for End-Host | Control Transmission Protocol (SCTP) Packets for End-Host | |||
to End-Host Communication", RFC 6951, May 2013. | to End-Host Communication", RFC 6951, DOI 10.17487/ | |||
RFC6951, May 2013, | ||||
<http://www.rfc-editor.org/info/rfc6951>. | ||||
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- | [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- | |||
IMMEDIATELY Extension for the Stream Control Transmission | IMMEDIATELY Extension for the Stream Control Transmission | |||
Protocol", RFC 7053, November 2013. | Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, | |||
<http://www.rfc-editor.org/info/rfc7053>. | ||||
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June | Protocol (HTTP/1.1): Message Syntax and Routing", RFC | |||
2014. | 7230, DOI 10.17487/RFC7230, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7230>. | ||||
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI | |||
10.17487/RFC7231, June 2014, | ||||
<http://www.rfc-editor.org/info/rfc7231>. | ||||
[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
(HTTP/1.1): Conditional Requests", RFC 7232, June 2014. | Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI | |||
10.17487/RFC7232, June 2014, | ||||
<http://www.rfc-editor.org/info/rfc7232>. | ||||
[RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", | |||
June 2014. | RFC 7233, DOI 10.17487/RFC7233, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7233>. | ||||
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | |||
2014. | RFC 7234, DOI 10.17487/RFC7234, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7234>. | ||||
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
(HTTP/1.1): Authentication", RFC 7235, June 2014. | Protocol (HTTP/1.1): Authentication", RFC 7235, DOI | |||
10.17487/RFC7235, June 2014, | ||||
<http://www.rfc-editor.org/info/rfc7235>. | ||||
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | |||
"Transport Layer Security (TLS) Application-Layer Protocol | "Transport Layer Security (TLS) Application-Layer Protocol | |||
Negotiation Extension", RFC 7301, July 2014. | Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | |||
July 2014, <http://www.rfc-editor.org/info/rfc7301>. | ||||
[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, Ed., "TCP Extensions for High Performance", | |||
7323, September 2014. | RFC 7323, DOI 10.17487/RFC7323, September 2014, | |||
<http://www.rfc-editor.org/info/rfc7323>. | ||||
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing | [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing | |||
Known Attacks on Transport Layer Security (TLS) and | Known Attacks on Transport Layer Security (TLS) and | |||
Datagram TLS (DTLS)", RFC 7457, February 2015. | Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, | |||
February 2015, <http://www.rfc-editor.org/info/rfc7457>. | ||||
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, | ||||
"Additional Policies for the Partially Reliable Stream | ||||
Control Transmission Protocol Extension", RFC 7496, DOI | ||||
10.17487/RFC7496, April 2015, | ||||
<http://www.rfc-editor.org/info/rfc7496>. | ||||
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | |||
"Recommendations for Secure Use of Transport Layer | "Recommendations for Secure Use of Transport Layer | |||
Security (TLS) and Datagram Transport Layer Security | Security (TLS) and Datagram Transport Layer Security | |||
(DTLS)", BCP 195, RFC 7525, May 2015. | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | |||
2015, <http://www.rfc-editor.org/info/rfc7525>. | ||||
[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer | [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI | |||
10.17487/RFC7540, May 2015, | ||||
<http://www.rfc-editor.org/info/rfc7540>. | ||||
[I-D.ietf-tsvwg-rfc5405bis] | ||||
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | ||||
Guidelines", draft-ietf-tsvwg-rfc5405bis-05 (work in | ||||
progress), August 2015. | ||||
[I-D.ietf-aqm-ecn-benefits] | [I-D.ietf-aqm-ecn-benefits] | |||
Fairhurst, G. and M. Welzl, "The Benefits of using | Fairhurst, G. and M. Welzl, "The Benefits of using | |||
Explicit Congestion Notification (ECN)", draft-ietf-aqm- | Explicit Congestion Notification (ECN)", draft-ietf-aqm- | |||
ecn-benefits-05 (work in progress), June 2015. | ecn-benefits-06 (work in progress), July 2015. | |||
[I-D.ietf-tsvwg-sctp-dtls-encaps] | [I-D.ietf-tsvwg-sctp-dtls-encaps] | |||
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS | Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS | |||
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- | Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- | |||
dtls-encaps-09 (work in progress), January 2015. | dtls-encaps-09 (work in progress), January 2015. | |||
[I-D.ietf-tsvwg-sctp-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] | [I-D.ietf-tsvwg-sctp-ndata] | |||
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, | Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, | |||
"Stream Schedulers and User Message Interleaving for the | "Stream Schedulers and User Message Interleaving for the | |||
Stream Control Transmission Protocol", draft-ietf-tsvwg- | Stream Control Transmission Protocol", draft-ietf-tsvwg- | |||
sctp-ndata-03 (work in progress), March 2015. | sctp-ndata-04 (work in progress), July 2015. | |||
[I-D.ietf-tsvwg-natsupp] | [I-D.ietf-tsvwg-natsupp] | |||
Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control | Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control | |||
Transmission Protocol (SCTP) Network Address Translation | Transmission Protocol (SCTP) Network Address Translation | |||
Support", draft-ietf-tsvwg-natsupp-07 (work in progress), | Support", draft-ietf-tsvwg-natsupp-08 (work in progress), | |||
February 2015. | July 2015. | |||
[XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, | [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, | |||
"XMLHttpRequest working draft | "XMLHttpRequest working draft | |||
(http://www.w3.org/TR/XMLHttpRequest/)", 2000. | (http://www.w3.org/TR/XMLHttpRequest/)", 2000. | |||
[REST] Fielding, R., "Architectural Styles and the Design of | [REST] Fielding, R., "Architectural Styles and the Design of | |||
Network-based Software Architectures, Ph. D. (UC Irvune), | Network-based Software Architectures, Ph. D. (UC Irvine), | |||
Chapter 5: Representational State Transfer", 2000. | Chapter 5: Representational State Transfer", 2000. | |||
[POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology | ||||
-- Portable Operating System Interface (POSIX) Base | ||||
Specifications, Issue 7", n.d.. | ||||
[MBMS] 3GPP TSG WS S4, ., "3GPP TS 26.346: Multimedia Broadcast/ | ||||
Multicast Service (MBMS); Protocols and codecs, release 13 | ||||
(http://www.3gpp.org/DynaReport/26346.htm).", 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. 286 change blocks. | ||||
595 lines changed or deleted | 1224 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/ |