draft-ietf-taps-transports-10.txt | draft-ietf-taps-transports-11.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: September 5, 2016 M. Kuehlewind, Ed. | Expires: January 8, 2017 M. Kuehlewind, Ed. | |||
ETH Zurich | ETH Zurich | |||
March 04, 2016 | July 07, 2016 | |||
Services provided by IETF transport protocols and congestion control | Services provided by IETF transport protocols and congestion control | |||
mechanisms | mechanisms | |||
draft-ietf-taps-transports-10 | draft-ietf-taps-transports-11 | |||
Abstract | Abstract | |||
This document describes, surveys, classifies and compares the | This document describes, surveys, classifies and compares the | |||
protocol mechanisms provided by existing IETF protocols, as | protocol mechanisms provided by existing IETF protocols, as | |||
background for determining a common set of transport services. It | background for determining a common set of transport services. It | |||
examines the Transmission Control Protocol (TCP), Multipath TCP, the | examines the Transmission Control Protocol (TCP), Multipath TCP, the | |||
Stream Control Transmission Protocol (SCTP), the User Datagram | Stream Control Transmission Protocol (SCTP), the User Datagram | |||
Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol | Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol | |||
(DCCP), the Internet Control Message Protocol (ICMP), the Realtime | (DCCP), the Internet Control Message Protocol (ICMP), the Realtime | |||
Transport Protocol (RTP), File Delivery over Unidirectional | Transport Protocol (RTP), File Delivery over Unidirectional | |||
Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), | Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), | |||
and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security | and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security | |||
(TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol | (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol | |||
(HTTP) when used as a pseudotransport. | (HTTP), when HTTP is used as a pseudotransport. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 5, 2016. | This Internet-Draft will expire on January 8, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 4, line 25 ¶ | skipping to change at page 4, line 25 ¶ | |||
1.1. Overview of Transport Features | 1.1. Overview of Transport Features | |||
Transport protocols can be differentiated by the features of the | Transport protocols can be differentiated by the features of the | |||
services they provide. | services they provide. | |||
Some of these provided features are closely related to basic control | Some of these provided features are closely related to basic control | |||
function that a protocol needs to work over a network path, such as | function that a protocol needs to work over a network path, such as | |||
addressing. The number of participants in a given association also | addressing. The number of participants in a given association also | |||
determines its applicability: if a connection is between endpoints | determines its applicability: if a connection is between endpoints | |||
(unicast), to one of multiple endpoints (anycast), and/or | (unicast), to one of multiple endpoints (anycast), or simultaneously | |||
simultaneously to multiple endpoints (multicast). Unicast protocols | to multiple endpoints (multicast). Unicast protocols usually support | |||
usually support bidirectional communication, while multicast is | bidirectional communication, while multicast is generally | |||
generally unidirectional. Another feature is whether a transport | unidirectional. Another feature is whether a transport requires a | |||
requires a control exchange across the network at setup (e.g., TCP), | control exchange across the network at setup (e.g., TCP), or whether | |||
or whether it connection-less (e.g., UDP). | it is connection-less (e.g., UDP). | |||
For the delivery of the packets itself, reliability and integrity | For packet delivery itself, reliability and integrity protection, | |||
protection, ordering, and framing are basic features. However, these | ordering, and framing are basic features. However, these features | |||
features are implemented with different levels of assurance in | are implemented with different levels of assurance in different | |||
different protocols. As an example, a transport service may provide | protocols. As an example, a transport service may provide full | |||
full reliability, providing detection of loss and retransmission | reliability, providing detection of loss and retransmission (e.g., | |||
(e.g., TCP). SCTP offers a message-based service that can provide | TCP). SCTP offers a message-based service that can provide full or | |||
full or partial reliability, and allows the protocol to minimize the | partial reliability, and allows the protocol to minimize the head of | |||
head of line blocking due to the support of ordered and unordered | line blocking due to the support of ordered and unordered message | |||
message delivery within multiple streams. UDP-Lite and DCCP can | delivery within multiple streams. UDP-Lite and DCCP can provide | |||
provide partial integrity protection to enable corruption tolerance. | partial integrity protection to enable corruption tolerance. | |||
Usually a protocol has been designed to support one specific type of | Usually a protocol has been designed to support one specific type of | |||
delivery/framing: data either needs to be divided into transmission | delivery/framing: data either needs to be divided into transmission | |||
units based on network packets (datagram service), a data stream is | units based on network packets (datagram service), a data stream is | |||
segmented and re-combined across multiple packets (stream service), | segmented and re-combined across multiple packets (stream service), | |||
or whole objects such as files are handled accordingly. This | or whole objects such as files are handled accordingly. This | |||
decision strongly influences the interface that is provided to the | decision strongly influences the interface that is provided to the | |||
upper layer. | upper layer. | |||
In addition, transport protocols offer a certain support for | In addition, transport protocols offer a certain support for | |||
skipping to change at page 6, line 45 ¶ | skipping to change at page 6, line 45 ¶ | |||
[RFC1191][RFC1981] as well as Packetization Layer Path MTU Discovery | [RFC1191][RFC1981] as well as Packetization Layer Path MTU Discovery | |||
(PMTUD) [RFC4821] have been defined by the IETF. | (PMTUD) [RFC4821] have been defined by the IETF. | |||
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 the reliable, ordered | for retransmission. This is the basis of the reliable, ordered | |||
delivery of data in a TCP stream. TCP Selective Acknowledgment | delivery of data in a TCP stream. TCP Selective Acknowledgment | |||
(SACK) [RFC2018] extends this mechanism by making it possible to | (SACK) [RFC2018] extends this mechanism by making it possible to | |||
provide earlier identification of which segments are missing, | provide earlier identification of which segments are missing, | |||
allowing faster retransmission. SACK-based methods (e.g. DSACK) can | allowing faster retransmission. SACK-based methods (e.g. Duplicate | |||
also result in less spurious retransmission. | Selective ACK) can also result in less 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, such as described in | All TCP senders provide congestion control, such as described in | |||
[RFC5681]. TCP uses a sequence number with a sliding receiver window | [RFC5681]. TCP uses a sequence number with a sliding receiver window | |||
for flow control. The TCP congestion control mechanism also utilises | for flow control. The TCP congestion control mechanism also utilises | |||
this TCP sequence number to manage a separate congestion window | this TCP sequence number to manage a separate congestion window | |||
skipping to change at page 9, line 18 ¶ | skipping to change at page 9, line 18 ¶ | |||
o segmentation, | o segmentation, | |||
o data bundling (optional; uses Nagle's algorithm to coalesce data | o data bundling (optional; uses Nagle's algorithm to coalesce data | |||
sent within the same RTT into full-sized segments), | sent within the same RTT into full-sized segments), | |||
o flow control (implemented using a window-based mechanism where the | o flow control (implemented using a window-based mechanism where the | |||
receiver advertises the window that it is willing to buffer), | receiver advertises the window that it is willing to buffer), | |||
o congestion control (usually implemented using a window-based | o congestion control (usually implemented using a window-based | |||
mechanism and four algorithm for different phases of the | mechanism and four algorithms for different phases of the | |||
transmission: slow start, congestion avoidance, fast retransmit, | transmission: slow start, congestion avoidance, fast retransmit, | |||
and fast recovery [RFC5681]). | and fast recovery [RFC5681]). | |||
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 for resilience, mobility and load-balancing. It is designed | homing for resilience, mobility and load-balancing. It is designed | |||
to be as transparent as possible to middleboxes. It does so by | to be as indistinguishable to middleboxes from non-multipath TCP as | |||
establishing regular TCP flows between a pair of source/destination | possible. It does so by establishing regular TCP flows between a | |||
endpoints, and multiplexing the application's stream over these | pair of source/destination endpoints, and multiplexing the | |||
flows. Sub-flows can be started over IPv4 or IPv6 for the same | application's stream over these flows. Sub- flows can be started | |||
session. | over IPv4 or IPv6 for the same session. | |||
3.2.1. Protocol Description | 3.2.1. Protocol Description | |||
MPTCP uses TCP options for its control plane. They are used to | MPTCP uses TCP options for its control plane. They are used to | |||
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. | |||
By multiplexing one byte stream over separate paths, MPTCP can | By multiplexing one byte stream over separate paths, MPTCP can | |||
achieve a higher throughput than TCP in certain situations. However, | achieve a higher throughput than TCP in certain situations. However, | |||
skipping to change at page 11, line 23 ¶ | skipping to change at page 11, line 23 ¶ | |||
It is possible to create IPv4 UDP datagrams with no checksum, and | It is possible to create IPv4 UDP datagrams with no checksum, and | |||
while this is generally discouraged [RFC1122] | while this is generally discouraged [RFC1122] | |||
[I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. | [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. | |||
These datagrams rely on the IPv4 header checksum to protect from | These datagrams rely on the IPv4 header checksum to protect from | |||
misdelivery to an unintended endpoint. IPv6 does not permit UDP | misdelivery to an unintended endpoint. IPv6 does not permit UDP | |||
datagrams with no checksum, although in certain cases this rule may | datagrams with no checksum, although in certain cases this rule may | |||
be relaxed [RFC6935]. | be relaxed [RFC6935]. | |||
UDP does not provide reliability and does not provide retransmission. | UDP does not provide reliability and does not provide retransmission. | |||
This implies messages may be re-ordered, lost, or duplicated in | Messages may be re-ordered, lost, or duplicated in transit. Note | |||
transit. Note that due to the relatively weak form of checksum used | that due to the relatively weak form of checksum used by UDP, | |||
by UDP, applications that require end to end integrity of data are | applications that require end to end integrity of data are | |||
recommended to include a stronger integrity check of their payload | recommended to include a stronger integrity check of their payload | |||
data. | data. | |||
Because UDP provides no flow control, a receiving application that is | Because UDP provides no flow control, a receiving application that is | |||
unable to run sufficiently fast, or frequently, may miss messages. | unable to run sufficiently fast, or frequently, may miss messages. | |||
The lack of congestion handling implies UDP traffic may experience | The lack of congestion handling implies UDP traffic may experience | |||
loss when using an overloaded path, and may cause the loss of | loss when using an overloaded path, and may cause the loss of | |||
messages from other protocols (e.g., TCP) when sharing the same | messages from other protocols (e.g., TCP) when sharing the same | |||
network path. | network path. | |||
skipping to change at page 13, line 9 ¶ | skipping to change at page 13, line 9 ¶ | |||
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. It provides a | IETF standards track transport protocol. It provides a | |||
unidirectional, datagram protocol that preserves message boundaries. | unidirectional, datagram protocol that preserves message boundaries. | |||
IETF guidance on the use of UDP- Lite is provided in | IETF guidance on the use of UDP- Lite is provided in | |||
[I-D.ietf-tsvwg-rfc5405bis]. A UDP-Lite service may support IPv4 | [I-D.ietf-tsvwg-rfc5405bis]. A UDP-Lite service may support IPv4 | |||
broadcast, multicast, anycast and unicast, and IPv6 multicast, | broadcast, multicast, anycast and unicast, and IPv6 multicast, | |||
anycast and unicast. | anycast and unicast. | |||
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 provider header integrity checks but allow | |||
when used over paths that include error-prone links, another | delivery of corrupted payloads to error-tolerant applications, or | |||
application is when header integrity checks are required, but payload | when payload integrity is provided by some other mechanism (see | |||
integrity is provided by some other mechanism (e.g., [RFC6936]). | [RFC6936]). | |||
3.4.1. Protocol Description | 3.4.1. Protocol Description | |||
Like UDP, UDP-Lite is a connection-less datagram protocol, with no | Like UDP, UDP-Lite is a connection-less datagram protocol, with no | |||
connection setup or feature negotiation. It changes the semantics of | connection setup or feature negotiation. It changes the semantics of | |||
the UDP "payload length" field to that of a "checksum coverage | the UDP "payload length" field to that of a "checksum coverage | |||
length" field, and is identified by a different IP protocol/next- | length" field, and is identified by a different IP protocol/next- | |||
header value. The "checksum coverage length" field specifies the | header value. The "checksum coverage length" field specifies the | |||
intended checksum coverage, with the remaining unprotected part of | intended checksum coverage, with the remaining unprotected part of | |||
the payload called the "error-insensitive part". Applications using | the payload called the "error-insensitive part". Applications using | |||
skipping to change at page 15, line 26 ¶ | skipping to change at page 15, line 26 ¶ | |||
[RFC4960] specifies TCP-friendly congestion control to protect the | [RFC4960] specifies TCP-friendly congestion control to protect the | |||
network against overload. SCTP also uses sliding window flow control | network against overload. SCTP also uses sliding window flow control | |||
to protect receivers against overflow. Similar to TCP, SCTP also | to protect receivers against overflow. Similar to TCP, SCTP also | |||
supports delaying acknowledgments. [RFC7053] provides a way for the | supports delaying acknowledgments. [RFC7053] provides a way for the | |||
sender of user messages to request the immediate sending of the | sender of user messages to request the immediate sending of the | |||
corresponding acknowledgments. | corresponding acknowledgments. | |||
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 | |||
layer. Un-ordered messages can be delivered as soon as they are | upper layer. Un-ordered messages can be delivered as soon as they | |||
completely received. Ordered messages sent on the same stream are | are completely received. For user messages not requiring | |||
delivered at the receiver in the same order as sent by the sender. | fragmentation, this minimizes head of line blocking. On the other | |||
For user messages not requiring fragmentation, this minimizes head of | hand, ordered messages sent on the same stream are delivered at the | |||
line blocking. | receiver in the same order as sent by the sender. | |||
The base protocol defined in [RFC4960] does not allow interleaving of | The base protocol defined in [RFC4960] does not allow interleaving of | |||
user- messages. Large messages on one stream can therefore block the | user- messages. Large messages on one stream can therefore block the | |||
sending of user messages on other streams. | sending of user messages on other streams. | |||
[I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. This draft | [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. This draft | |||
also specifies multiple algorithms for the sender side selection of | also specifies multiple algorithms for the sender side selection of | |||
which streams to send data from, supporting a variety of scheduling | which streams to send data from, supporting a variety of scheduling | |||
algorithms including priority based methods. The stream re- | algorithms including priority based methods. The stream re- | |||
configuration extension defined in [RFC6525] allows streams to be | configuration extension defined in [RFC6525] allows streams to be | |||
reset during the lifetime of an association and to increase the | reset during the lifetime of an association and to increase the | |||
skipping to change at page 22, line 23 ¶ | skipping to change at page 22, line 23 ¶ | |||
o unordered delivery, | o unordered delivery, | |||
o flow control (implemented using the slow receiver function) | o flow control (implemented using the slow receiver function) | |||
o partial and full payload error detection (with optional strong | o partial and full payload error detection (with optional strong | |||
integrity check). | integrity check). | |||
3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a | 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a | |||
pseudotransport | pseudotransport | |||
Transport Layer Security (TLS) [RFC5246]} and Datagram TLS (DTLS) | Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) | |||
[RFC6347]} are IETF protocols that provide several security-related | [RFC6347] are IETF protocols that provide several security-related | |||
features to applications. TLS is designed to run on top of a | features to applications. TLS is designed to run on top of a | |||
reliable streaming transport protocol (usually TCP), while DTLS is | reliable streaming transport protocol (usually TCP), while DTLS is | |||
designed to run on top of a best-effort datagram protocol (UDP or | designed to run on top of a best-effort datagram protocol (UDP or | |||
DCCP [RFC5238]). At the time of writing, the current version of TLS | DCCP [RFC5238]). At the time of writing, the current version of TLS | |||
is 1.2; which is defined in [RFC5246]. DTLS provides nearly | is 1.2; which is defined in [RFC5246]. DTLS provides nearly | |||
identical functionality to applications; it is defined in [RFC6347] | identical functionality to applications; it is defined in [RFC6347] | |||
and its current version is also 1.2. The TLS protocol evolved from | and its current version is also 1.2. The TLS protocol evolved from | |||
the Secure Sockets Layer (SSL) protocols developed in the mid-1990s | the Secure Sockets Layer (SSL) protocols developed in the mid-1990s | |||
to support protection of HTTP traffic. | to support protection of HTTP traffic. | |||
skipping to change at page 23, line 34 ¶ | skipping to change at page 23, line 34 ¶ | |||
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 Conveyance 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]. DTLS forbids the use of stream | Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream | |||
ciphers, which are essentially incompatible when operating on | ciphers, which are essentially incompatible when operating on | |||
skipping to change at page 27, line 24 ¶ | skipping to change at page 27, line 24 ¶ | |||
o performance metric reporting (using associated protocols). | o performance metric reporting (using associated protocols). | |||
3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport | 3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol widely used on the Internet. It provides object-oriented | protocol widely used on the Internet. It provides object-oriented | |||
delivery of discrete data or files. Version 1.1 of the protocol is | delivery of discrete data or files. 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]. HTTP is usually transported | [RFC7235], and version 2 in [RFC7540]. HTTP is usually transported | |||
over TCP using port 80 and 443, although it can be used with other | over TCP using port 80 and 443, although it can be used with other | |||
transports. When used over TCP it inherits its properties. | transports. When used over TCP it inherits TCP's properties. | |||
Application layer protocols may use HTTP as a substrate with an | Application layer protocols may use HTTP as a substrate with an | |||
existing method and data formats, or specify new methods and data | existing method and data formats, or specify new methods and data | |||
formats. There are various reasons for this practice listed in | formats. There are various reasons for this practice listed in | |||
[RFC3205]; these include being a well-known and well-understood | [RFC3205]; these include being a well-known and well-understood | |||
protocol, reusability of existing servers and client libraries, easy | protocol, reusability of existing servers and client libraries, easy | |||
use of existing security mechanisms such as HTTP digest | use of existing security mechanisms such as HTTP digest | |||
authentication [RFC2617] and TLS [RFC5246], the ability of HTTP to | authentication [RFC2617] and TLS [RFC5246], the ability of HTTP to | |||
traverse firewalls makes it work over many types of infrastructure, | traverse firewalls makes it work over many types of infrastructure, | |||
and in cases where an application server often needs to support HTTP | and in cases where an application server often needs to support HTTP | |||
skipping to change at page 28, line 32 ¶ | skipping to change at page 28, line 32 ¶ | |||
resource. The client and server negotiate acceptable data formats, | resource. The client and server negotiate acceptable data formats, | |||
character sets, data encoding (e.g., data can be transferred | character sets, data encoding (e.g., data can be transferred | |||
compressed using gzip). HTTP can accommodate exchange of messages as | compressed using gzip). HTTP can accommodate exchange of messages as | |||
well as data streaming (using chunked transfer encoding [RFC7230]). | well as data streaming (using chunked transfer encoding [RFC7230]). | |||
It is also possible to request a part of a resource using an object | It is also possible to request a part of a resource using an object | |||
range request [RFC7233]. The protocol provides powerful cache | range request [RFC7233]. The protocol provides powerful cache | |||
control signaling defined in [RFC7234]. | control signaling defined in [RFC7234]. | |||
The persistent connections of HTTP 1.1 and HTTP 2.0 allow multiple | The persistent connections of HTTP 1.1 and HTTP 2.0 allow multiple | |||
request- response transactions (streams) during the life-time of a | request- response transactions (streams) during the life-time of a | |||
single HTTP connection. HTTP 2.0 connections can multiplex many | single HTTP connection. This reduces overhead during connection | |||
request/response pairs in parallel on a single transport connection. | establishment and mitigates transport layer slow-start that would | |||
This reduces overhead during connection establishment and mitigates | have otherwise been incurred for each transaction. HTTP 2.0 | |||
transport layer slow-start that would have otherwise been incurred | connections can multiplex many request/response pairs in parallel on | |||
for each transaction. Both are important to reduce latency for | a single transport connection. Both are important to reduce latency | |||
HTTP's primary use case. | for HTTP's primary use case. | |||
HTTP can be combined with security mechanisms, such as TLS (denoted | HTTP can be combined with security mechanisms, such as TLS (denoted | |||
by HTTPS). This adds protocol properties provided by such a | by HTTPS). This adds protocol properties provided by such a | |||
mechanism (e.g., authentication, encryption). The TLS Application- | mechanism (e.g., authentication, encryption). The TLS Application- | |||
Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to | Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to | |||
negotiate the HTTP version within the TLS handshake, eliminating the | negotiate the HTTP version within the TLS handshake, eliminating the | |||
latency incurred by additional round-trip exchanges. Arbitrary | latency incurred by additional round-trip exchanges. Arbitrary | |||
cookie strings, included as part of the MIME headers, are often used | cookie strings, included as part of the MIME headers, are often used | |||
as bearer tokens in HTTP. | as bearer tokens in HTTP. | |||
3.9.2. Interface Description | 3.9.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, the API exposes a registration of | received. If HTTPS is used, the API exposes a registration of | |||
callbacks for a server that requests client authentication and when | callbacks for a server that requests client authentication and when | |||
certificate verification is needed. | certificate verification is needed. | |||
The World Wide Web Consortium (W3C) has standardized the | The World Wide Web Consortium (W3C) has standardized the | |||
XMLHttpRequest API [XHR]. This API can be used for sending HTTP/ | XMLHttpRequest API [XHR]. This API can be used for sending HTTP/ | |||
HTTPS requests and receiving server responses. Besides the XML data | HTTPS requests and receiving server responses. Besides the XML data | |||
format, the request and response data format can also be JSON, HTML, | format, the request and response data format can also be JSON, HTML, | |||
and plain text. JavaScript and XMLHttpRequest are ubiquitous | and plain text. JavaScript and XMLHttpRequest are ubiquitous | |||
programming models for websites, and more general applications, where | programming models for websites, and more general applications, where | |||
native code is less attractive. | native code is less attractive. | |||
skipping to change at page 33, line 24 ¶ | skipping to change at page 33, line 24 ¶ | |||
The protocol was designed to support reliable bulk data dissemination | The protocol was designed to support reliable bulk data dissemination | |||
to receiver groups using IP Multicast but also provides for point-to- | to receiver groups using IP Multicast but also provides for point-to- | |||
point unicast operation. Support for bulk data dissemination | point unicast operation. 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. | byte- and message-streaming. | |||
NORM can incorporate packet erasure coding as a part of its selective | NORM can incorporate packet erasure coding as a part of its selective | |||
ARQ in response to negative acknowledgments from the receiver. The | ARQ in response to negative acknowledgments from the receiver. The | |||
packet erasure coding can also be proactively applied for forward | packet erasure coding can also be proactively applied for forward | |||
protection from packet loss. NORM transmissions are governed by the | protection from packet loss. NORM transmissions are governed by TCP- | |||
TCP-friendly congestion control. The reliability, congestion control | friendly multicast congestion control (TFMCC, [RFC4654]). The | |||
and flow control mechanisms can be separately controlled to meet | reliability, congestion control and flow control mechanisms can be | |||
different application needs. | separately controlled to meet different application needs. | |||
3.11.1. Protocol Description | 3.11.1. Protocol Description | |||
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 | |||
loosely coordinated IP Multicast, NORM is not strictly connection- | loosely coordinated IP Multicast, NORM is not strictly connection- | |||
oriented although per-sender state is maintained by receivers for | oriented although per-sender state is maintained by receivers for | |||
protocol operation. [RFC5740] does not specify a handshake protocol | protocol operation. [RFC5740] does not specify a handshake protocol | |||
for connection establishment. Separate session initiation can be | for connection establishment. Separate session initiation can be | |||
used to coordinate port numbers. However, in-band "client-server" | used to coordinate port numbers. However, in-band "client-server" | |||
skipping to change at page 36, line 27 ¶ | skipping to change at page 36, line 27 ¶ | |||
ICMP messages typically relay diagnostic information from an endpoint | ICMP messages typically relay diagnostic information from an endpoint | |||
[RFC1122] or network device [RFC1716] addressed to the sender of a | [RFC1122] or network device [RFC1716] addressed to the sender of a | |||
flow. This usually contains the network protocol header of a packet | flow. This usually contains the network protocol header of a packet | |||
that encountered a reported issue. Some formats of messages can also | that encountered a reported issue. Some formats of messages can also | |||
carry other payload data. Each message carries an integrity check | carry other payload data. Each message carries an integrity check | |||
calculated in the same way as for UDP, this checksum is not optional. | calculated in the same way as for UDP, this checksum is not optional. | |||
The RFC series defines additional IPv6 message formats to support a | The RFC series defines additional IPv6 message formats to support a | |||
range of uses. In the case of IPv6 the protocol incorporates | range of uses. In the case of IPv6 the protocol incorporates | |||
neighbor discovery [RFC2461] [RFC3971]} (provided by ARP for IPv4) | neighbor discovery [RFC2461] [RFC3971] (provided by ARP for IPv4) and | |||
and the Multicast Listener Discovery (MLD) [RFC2710] group management | the Multicast Listener Discovery (MLD) [RFC2710] group management | |||
functions (provided by IGMP for IPv4). | functions (provided by IGMP for IPv4). | |||
Reliable transmission can not be assumed. A receiving application | Reliable transmission can not be assumed. A receiving application | |||
that is unable to run sufficiently fast, or frequently, may miss | that is unable to run sufficiently fast, or frequently, may miss | |||
messages since there is no flow or congestion control. In addition | messages since there is no flow or congestion control. In addition | |||
some network devices rate-limit ICMP messages. | some network devices rate-limit ICMP messages. | |||
3.12.2. Interface Description | 3.12.2. Interface Description | |||
ICMP processing is integrated in many connection-oriented transports, | ICMP processing is integrated in many connection-oriented transports, | |||
skipping to change at page 37, line 34 ¶ | skipping to change at page 37, line 34 ¶ | |||
Many protocols use a separate window to determine the maximum sending | Many protocols use a separate window to determine the maximum sending | |||
rate that is allowed by the congestion control. The used congestion | rate that is allowed by the congestion control. The used congestion | |||
control mechanism will increase the congestion window if feedback is | control mechanism will increase the congestion window if feedback is | |||
received that indicates that the currently used network path is not | received that indicates that the currently used network path is not | |||
congested, and will reduce the window otherwise. Window-based | congested, and will reduce the window otherwise. Window-based | |||
mechanisms often increase their window slowing over multiple RTTs, | mechanisms often increase their window slowing over multiple RTTs, | |||
while decreasing strongly when the first indication of congestion is | while decreasing strongly when the first indication of congestion is | |||
received. One example is an Additive Increase Multiplicative | received. One example is an Additive Increase Multiplicative | |||
Decrease (AIMD) scheme, where the window is increased by a certain | Decrease (AIMD) scheme, where the window is increased by a certain | |||
number of packets/bytes for each data segment that has been | number of packets/bytes for each data segment that has been | |||
successfully transmitted, while the window is multiplicatively | successfully transmitted, while the window decreases multiplicatively | |||
decrease on the occurrence of a congestion event. This can lead to a | on the occurrence of a congestion event. This can lead to a rather | |||
rather unstable, oscillating sending rate, but will resolve a | unstable, oscillating sending rate, but will resolve a congestion | |||
congestion situation quickly. TCP New Reno [RFC5681] which is one of | situation quickly. TCP New Reno [RFC5681] which is one of the | |||
the initial proposed schemes for TCP as well as TCP Cubic | initial proposed schemes for TCP as well as TCP Cubic | |||
[I-D.ietf-tcpm-cubic] which is the default mechanism for TCP in Linux | [I-D.ietf-tcpm-cubic] which is the default mechanism for TCP in Linux | |||
are two examples for window-based AIMD schemes. This approach is | are two examples for window-based AIMD schemes. This approach is | |||
also used by DCCP CCID-2 for datagram congestion control. | also used by DCCP CCID-2 for datagram congestion control. | |||
Some classes of applications prefer to use a transport service that | Some classes of applications prefer to use a transport service that | |||
allows sending at a more stable rate, that is slowly varied in | allows sending at a more stable rate, that is slowly varied in | |||
response to congestion. Rate-based methods offer this type of | response to congestion. Rate-based methods offer this type of | |||
congestion control and have been defined based on the loss ratio and | congestion control and have been defined based on the loss ratio and | |||
observed round trip time, such as TFRC [RFC5348] and TFRC-SP | observed round trip time, such as TFRC [RFC5348] and TFRC-SP | |||
[RFC4828]. These methods utilize a throughput equation to determine | [RFC4828]. These methods utilize a throughput equation to determine | |||
the maximum acceptable rate. Such methods are used with DCCP CCID-3 | the maximum acceptable rate. Such methods are used with DCCP CCID-3 | |||
[RFC4342] and CCID-4 [RFC5622], WEBRC [RFC3738], and other | [RFC4342] and CCID-4 [RFC5622], WEBRC [RFC3738], and other | |||
applications. | applications. | |||
Another class of applications prefer a transport service that yields | Another class of applications prefer a transport service that yields | |||
to other (higher-priority) traffic, such as interactive | to other (higher-priority) traffic, such as interactive | |||
transmissions. While most traffic in the Internet uses loss-based | transmissions. While most traffic in the Internet uses loss-based | |||
congestion control and therefore need to fill the network buffers (to | congestion control and therefore tends to fill the network buffers | |||
a certain level if Active Queue Management (AQM) is used), low- | (to a certain level if Active Queue Management (AQM) is used), low- | |||
priority congestion control methods often react to changes in delay | priority congestion control methods often react to changes in delay | |||
as an earlier indication of congestion. This approach tends to | as an earlier indication of congestion. This approach tends to | |||
induce less loss than a loss-based method but does generally not | induce less loss than a loss-based method but does generally not | |||
compete well with loss-based traffic across shared bottleneck links. | compete well with loss-based traffic across shared bottleneck links. | |||
Therefore, methods such as LEDBAT [RFC6824], are deployed in the | Therefore, methods such as LEDBAT [RFC6824], are deployed in the | |||
Internet for scavenger traffic that aim to only utilize otherwise | Internet for scavenger traffic that aim to only utilize otherwise | |||
unused capacity. | unused capacity. | |||
5. Transport Features | 5. Transport Features | |||
The tables below summarize some key features to illustrate the range | The tables below summarize some key features to illustrate the range | |||
of functions provided across the IETF-specified transports. Figure 1 | of functions provided across the IETF-specified transports. Figure 1 | |||
considers transports that may be directly layered over the network, | considers transports that may be directly layered over the network, | |||
and Figure 2 considers transports layered over another transport | and Figure 2 considers transports layered over another transport | |||
service. Features that are permitted, but not required, are marked | service. Features that are permitted, but not required, are marked | |||
as "Poss" indicating that it is possible for the transport service to | as "Poss" indicating that it is possible for the transport service to | |||
offer this feature. | offer this feature. | |||
+---------------+------+------+------+------+------+------+------+ | +---------------+------+------+------+------+------+------+------+ | |||
| Feature | TCP | MPTCP| UDP | UDP | SCTP |DCCP |ICMP | | | Feature | TCP | MPTCP| UDP | UDPL | SCTP | DCCP | ICMP | | |||
+---------------+------+------+------+------+------+------+------+ | +---------------+------+------+------+------+------+------+------+ | |||
| Datagram | No | No | Yes | Yes | Yes | Yes | Yes | | | Datagram | No | No | Yes | Yes | Yes | Yes | Yes | | |||
+---------------+------+------+------+------+------+------+------+ | +---------------+------+------+------+------+------+------+------+ | |||
| Conn. Oriented| Yes | Yes | No | No | Yes | Yes | No | | | Conn. Oriented| Yes | Yes | No | No | Yes | Yes | No | | |||
+---------------+------+------+------+------+------+------+------+ | +---------------+------+------+------+------+------+------+------+ | |||
| Reliability | Yes | Yes | No | No | Yes | No | No | | | Reliability | Yes | Yes | No | No | Yes | No | No | | |||
+---------------+------+------+------+------+------+------+------+ | +---------------+------+------+------+------+------+------+------+ | |||
| Partial Rel. | No | No | N/A | N/A | Poss | Yes | N/A | | | Partial Rel. | No | No | N/A | N/A | Poss | Yes | N/A | | |||
+---------------+------+------+------+------+------+------+------+ | +---------------+------+------+------+------+------+------+------+ | |||
| Corupt. Tol | No | No | No | Yes | No | Yes | No | | | Corupt. Tol | No | No | No | Yes | No | Yes | No | | |||
skipping to change at page 41, line 36 ¶ | skipping to change at page 41, line 36 ¶ | |||
+ message-oriented delivery (UDP, UDP-Lite, SCTP, DCCP, DTLS, | + message-oriented delivery (UDP, UDP-Lite, SCTP, DCCP, DTLS, | |||
RTP) | RTP) | |||
+ object-oriented delivery of discrete data or files and | + object-oriented delivery of discrete data or files and | |||
associated metadata (HTTP, FLUTE/ALC, NORM) | associated metadata (HTTP, FLUTE/ALC, NORM) | |||
- with partial delivery of object ranges (HTTP) | - with partial delivery of object ranges (HTTP) | |||
* Directionality | * Directionality | |||
+ unidirectional (TCP, UDP, UDP-Lite, SCTP, DCCP, RTP, FLUTE/ | + unidirectional (UDP, UDP-Lite, DCCP, RTP, FLUTE/ALC, NORM) | |||
ALC, NORM) | ||||
+ bidirectional (TCP, MPTCP, SCTP, TLS, HTTP) | + bidirectional (TCP, MPTCP, SCTP, TLS, HTTP) | |||
o Transmission control | o Transmission control | |||
* flow control (TCP, MPTCP, SCTP, DCCP, TLS, RTP, HTTP) | * flow control (TCP, MPTCP, SCTP, DCCP, TLS, RTP, HTTP) | |||
* congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, | * congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, | |||
NORM). Congestion control can also provided by the transport | NORM). Congestion control can also provided by the transport | |||
supporting an upper later transport (e.g., TLS, RTP, HTTP). | supporting an upper later transport (e.g., TLS, RTP, HTTP). | |||
skipping to change at page 43, line 5 ¶ | skipping to change at page 43, line 5 ¶ | |||
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.3 on UDP was contributed by Kevin Fall (kfall@kfall.com) | o Section 3.3 on UDP was contributed by Kevin Fall (kfall@kfall.com) | |||
o Section 3.5 on SCTP was contributed by Michael Tuexen (tuexen@fh- | o Section 3.5 on SCTP was contributed by Michael Tuexen (tuexen@fh- | |||
muenster.de) and Karen Nielsen (karen.nielsen@tieto.com) | muenster.de) and Karen Nielsen (karen.nielsen@tieto.com) | |||
o Section 3.7 on TLS and DTLS was contributed by Ralph Holz | ||||
(ralph.holz@nicta.com.au) and Olivier Mehani | ||||
(olivier.mehani@nicta.com.au) | ||||
o Section 3.8 on RTP contains contributions from Colin Perkins | o Section 3.8 on RTP contains contributions from Colin Perkins | |||
(csp@csperkins.org) | (csp@csperkins.org) | |||
o Section 3.9 on HTTP was contributed by Dragana Damjanovic | ||||
(ddamjanovic@mozilla.com) | ||||
o Section 3.10 on FLUTE/ALC was contributed by Vincent Roca | o Section 3.10 on FLUTE/ALC was contributed by Vincent Roca | |||
(vincent.roca@inria.fr) | (vincent.roca@inria.fr) | |||
o Section 3.11 on NORM was contributed by Brian Adamson | o Section 3.11 on NORM was contributed by Brian Adamson | |||
(brian.adamson@nrl.navy.mil) | (brian.adamson@nrl.navy.mil) | |||
o Section 3.7 on TLS and DTLS was contributed by Ralph Holz | ||||
(ralph.holz@nicta.com.au) and Olivier Mehani | ||||
(olivier.mehani@nicta.com.au) | ||||
o Section 3.9 on HTTP was contributed by Dragana Damjanovic | ||||
(ddamjanovic@mozilla.com) | ||||
9. Acknowledgments | 9. Acknowledgments | |||
Thanks to Joe Touch, Michael Welzl, and the TAPS Working Group for | Thanks to Joe Touch, Michael Welzl, Spencer Dawkins, and the TAPS | |||
the comments, feedback, and discussion. This work is supported by | Working Group for the comments, feedback, and discussion. This work | |||
the European Commission under grant agreement No. 318627 mPlane and | is supported by the European Commission under grant agreement No. | |||
from the Horizon 2020 research and innovation program under grant | 318627 mPlane and from the Horizon 2020 research and innovation | |||
agreements No. 644334 (NEAT) and No. 688421 (MAMI). This support | program under grant agreements No. 644334 (NEAT) and No. 688421 | |||
does not imply endorsement. | (MAMI). This support does not imply endorsement. | |||
10. Informative References | 10. Informative References | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
10.17487/RFC0768, August 1980, | DOI 10.17487/RFC0768, August 1980, | |||
<http://www.rfc-editor.org/info/rfc768>. | <http://www.rfc-editor.org/info/rfc768>. | |||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
RFC 792, DOI 10.17487/RFC0792, September 1981, | RFC 792, DOI 10.17487/RFC0792, September 1981, | |||
<http://www.rfc-editor.org/info/rfc792>. | <http://www.rfc-editor.org/info/rfc792>. | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
793, DOI 10.17487/RFC0793, September 1981, | RFC 793, DOI 10.17487/RFC0793, September 1981, | |||
<http://www.rfc-editor.org/info/rfc793>. | <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, DOI 10.17487/RFC0896, January 1984, | RFC 896, DOI 10.17487/RFC0896, January 1984, | |||
<http://www.rfc-editor.org/info/rfc896>. | <http://www.rfc-editor.org/info/rfc896>. | |||
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - | [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - | |||
Communication Layers", STD 3, RFC 1122, DOI 10.17487/ | Communication Layers", STD 3, RFC 1122, | |||
RFC1122, October 1989, | DOI 10.17487/RFC1122, October 1989, | |||
<http://www.rfc-editor.org/info/rfc1122>. | <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, | |||
DOI 10.17487/RFC1191, November 1990, | DOI 10.17487/RFC1191, November 1990, | |||
<http://www.rfc-editor.org/info/rfc1191>. | <http://www.rfc-editor.org/info/rfc1191>. | |||
[RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for | [RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for | |||
IP Routers", RFC 1716, DOI 10.17487/RFC1716, November | IP Routers", RFC 1716, DOI 10.17487/RFC1716, November | |||
1994, <http://www.rfc-editor.org/info/rfc1716>. | 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, DOI 10.17487/RFC1981, August | for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August | |||
1996, <http://www.rfc-editor.org/info/rfc1981>. | 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, DOI 10.17487/ | Selective Acknowledgment Options", RFC 2018, | |||
RFC2018, October 1996, | DOI 10.17487/RFC2018, October 1996, | |||
<http://www.rfc-editor.org/info/rfc2018>. | <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, DOI 10.17487/RFC2045, November 1996, | Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | |||
<http://www.rfc-editor.org/info/rfc2045>. | <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, DOI 10.17487/RFC2460, | (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, | |||
December 1998, <http://www.rfc-editor.org/info/rfc2460>. | December 1998, <http://www.rfc-editor.org/info/rfc2460>. | |||
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor | [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor | |||
Discovery for IP Version 6 (IPv6)", RFC 2461, DOI | Discovery for IP Version 6 (IPv6)", RFC 2461, | |||
10.17487/RFC2461, December 1998, | DOI 10.17487/RFC2461, December 1998, | |||
<http://www.rfc-editor.org/info/rfc2461>. | <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, DOI 10.17487/RFC2617, June 1999, | RFC 2617, DOI 10.17487/RFC2617, June 1999, | |||
<http://www.rfc-editor.org/info/rfc2617>. | <http://www.rfc-editor.org/info/rfc2617>. | |||
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast | [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast | |||
Listener Discovery (MLD) for IPv6", RFC 2710, DOI | Listener Discovery (MLD) for IPv6", RFC 2710, | |||
10.17487/RFC2710, October 1999, | DOI 10.17487/RFC2710, October 1999, | |||
<http://www.rfc-editor.org/info/rfc2710>. | <http://www.rfc-editor.org/info/rfc2710>. | |||
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP | [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP | |||
Payload Format Specifications", BCP 36, RFC 2736, DOI | Payload Format Specifications", BCP 36, RFC 2736, | |||
10.17487/RFC2736, December 1999, | DOI 10.17487/RFC2736, December 1999, | |||
<http://www.rfc-editor.org/info/rfc2736>. | <http://www.rfc-editor.org/info/rfc2736>. | |||
[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", | |||
3168, DOI 10.17487/RFC3168, September 2001, | RFC 3168, DOI 10.17487/RFC3168, September 2001, | |||
<http://www.rfc-editor.org/info/rfc3168>. | <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, DOI 10.17487/RFC3205, February 2002, | RFC 3205, DOI 10.17487/RFC3205, February 2002, | |||
<http://www.rfc-editor.org/info/rfc3205>. | <http://www.rfc-editor.org/info/rfc3205>. | |||
[RFC3260] Grossman, D., "New Terminology and Clarifications for | [RFC3260] Grossman, D., "New Terminology and Clarifications for | |||
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, | Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, | |||
<http://www.rfc-editor.org/info/rfc3260>. | <http://www.rfc-editor.org/info/rfc3260>. | |||
skipping to change at page 45, line 39 ¶ | skipping to change at page 45, line 39 ¶ | |||
M., and J. Crowcroft, "Forward Error Correction (FEC) | M., and J. Crowcroft, "Forward Error Correction (FEC) | |||
Building Block", RFC 3452, DOI 10.17487/RFC3452, December | Building Block", RFC 3452, DOI 10.17487/RFC3452, December | |||
2002, <http://www.rfc-editor.org/info/rfc3452>. | 2002, <http://www.rfc-editor.org/info/rfc3452>. | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <http://www.rfc-editor.org/info/rfc3550>. | July 2003, <http://www.rfc-editor.org/info/rfc3550>. | |||
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate | [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate | |||
Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/ | Control (WEBRC) Building Block", RFC 3738, | |||
RFC3738, April 2004, | DOI 10.17487/RFC3738, April 2004, | |||
<http://www.rfc-editor.org/info/rfc3738>. | <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, DOI 10.17487/ | Partial Reliability Extension", RFC 3758, | |||
RFC3758, May 2004, | DOI 10.17487/RFC3758, May 2004, | |||
<http://www.rfc-editor.org/info/rfc3758>. | <http://www.rfc-editor.org/info/rfc3758>. | |||
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., | [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., | |||
and G. Fairhurst, Ed., "The Lightweight User Datagram | and G. Fairhurst, Ed., "The Lightweight User Datagram | |||
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July | Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July | |||
2004, <http://www.rfc-editor.org/info/rfc3828>. | 2004, <http://www.rfc-editor.org/info/rfc3828>. | |||
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, | [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, | |||
"FLUTE - File Delivery over Unidirectional Transport", RFC | "FLUTE - File Delivery over Unidirectional Transport", | |||
3926, DOI 10.17487/RFC3926, October 2004, | RFC 3926, DOI 10.17487/RFC3926, October 2004, | |||
<http://www.rfc-editor.org/info/rfc3926>. | <http://www.rfc-editor.org/info/rfc3926>. | |||
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | |||
"SEcure Neighbor Discovery (SEND)", RFC 3971, DOI | "SEcure Neighbor Discovery (SEND)", RFC 3971, | |||
10.17487/RFC3971, March 2005, | DOI 10.17487/RFC3971, March 2005, | |||
<http://www.rfc-editor.org/info/rfc3971>. | <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, DOI 10.17487/RFC4324, December | Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December | |||
2005, <http://www.rfc-editor.org/info/rfc4324>. | 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)", | |||
4336, DOI 10.17487/RFC4336, March 2006, | RFC 4336, DOI 10.17487/RFC4336, March 2006, | |||
<http://www.rfc-editor.org/info/rfc4336>. | <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, DOI | Congestion Control Protocol (DCCP)", RFC 4340, | |||
10.17487/RFC4340, March 2006, | DOI 10.17487/RFC4340, March 2006, | |||
<http://www.rfc-editor.org/info/rfc4340>. | <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, DOI 10.17487/RFC4341, March | Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March | |||
2006, <http://www.rfc-editor.org/info/rfc4341>. | 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, | |||
DOI 10.17487/RFC4342, March 2006, | DOI 10.17487/RFC4342, March 2006, | |||
<http://www.rfc-editor.org/info/rfc4342>. | <http://www.rfc-editor.org/info/rfc4342>. | |||
[RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 | [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 | |||
Dynamic Home Agent (HA) Assignment", RFC 4433, DOI | Dynamic Home Agent (HA) Assignment", RFC 4433, | |||
10.17487/RFC4433, March 2006, | DOI 10.17487/RFC4433, March 2006, | |||
<http://www.rfc-editor.org/info/rfc4433>. | <http://www.rfc-editor.org/info/rfc4433>. | |||
[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", | |||
4654, DOI 10.17487/RFC4654, August 2006, | RFC 4654, DOI 10.17487/RFC4654, August 2006, | |||
<http://www.rfc-editor.org/info/rfc4654>. | <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, DOI 10.17487/RFC4820, March 2007, | (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, | |||
<http://www.rfc-editor.org/info/rfc4820>. | <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, DOI 10.17487/RFC4821, March 2007, | Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, | |||
<http://www.rfc-editor.org/info/rfc4821>. | <http://www.rfc-editor.org/info/rfc4821>. | |||
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control | [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control | |||
(TFRC): The Small-Packet (SP) Variant", RFC 4828, DOI | (TFRC): The Small-Packet (SP) Variant", RFC 4828, | |||
10.17487/RFC4828, April 2007, | DOI 10.17487/RFC4828, April 2007, | |||
<http://www.rfc-editor.org/info/rfc4828>. | <http://www.rfc-editor.org/info/rfc4828>. | |||
[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, DOI 10.17487/RFC4895, August | Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August | |||
2007, <http://www.rfc-editor.org/info/rfc4895>. | 2007, <http://www.rfc-editor.org/info/rfc4895>. | |||
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | |||
RFC 4960, DOI 10.17487/RFC4960, September 2007, | RFC 4960, DOI 10.17487/RFC4960, September 2007, | |||
<http://www.rfc-editor.org/info/rfc4960>. | <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, DOI 10.17487/ | Dynamic Address Reconfiguration", RFC 5061, | |||
RFC5061, September 2007, | DOI 10.17487/RFC5061, September 2007, | |||
<http://www.rfc-editor.org/info/rfc5061>. | <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, DOI 10.17487/RFC5097, January 2008, | protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, | |||
<http://www.rfc-editor.org/info/rfc5097>. | <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, DOI 10.17487/ | (TLS) Protocol Version 1.2", RFC 5246, | |||
RFC5246, August 2008, | DOI 10.17487/RFC5246, August 2008, | |||
<http://www.rfc-editor.org/info/rfc5246>. | <http://www.rfc-editor.org/info/rfc5246>. | |||
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over | [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over | |||
the Datagram Congestion Control Protocol (DCCP)", RFC | the Datagram Congestion Control Protocol (DCCP)", | |||
5238, DOI 10.17487/RFC5238, May 2008, | RFC 5238, DOI 10.17487/RFC5238, May 2008, | |||
<http://www.rfc-editor.org/info/rfc5238>. | <http://www.rfc-editor.org/info/rfc5238>. | |||
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP | [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP | |||
Friendly Rate Control (TFRC): Protocol Specification", RFC | Friendly Rate Control (TFRC): Protocol Specification", | |||
5348, DOI 10.17487/RFC5348, September 2008, | RFC 5348, DOI 10.17487/RFC5348, September 2008, | |||
<http://www.rfc-editor.org/info/rfc5348>. | <http://www.rfc-editor.org/info/rfc5348>. | |||
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI | [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, | |||
10.17487/RFC5461, February 2009, | DOI 10.17487/RFC5461, February 2009, | |||
<http://www.rfc-editor.org/info/rfc5461>. | <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, DOI 10.17487/RFC5595, | (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, | |||
September 2009, <http://www.rfc-editor.org/info/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, DOI 10.17487/RFC5596, | Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, | |||
September 2009, <http://www.rfc-editor.org/info/rfc5596>. | September 2009, <http://www.rfc-editor.org/info/rfc5596>. | |||
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion | [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion | |||
Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate | Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate | |||
Control for Small Packets (TFRC-SP)", RFC 5622, DOI | Control for Small Packets (TFRC-SP)", RFC 5622, | |||
10.17487/RFC5622, August 2009, | DOI 10.17487/RFC5622, August 2009, | |||
<http://www.rfc-editor.org/info/rfc5622>. | <http://www.rfc-editor.org/info/rfc5622>. | |||
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding | [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding | |||
Transport (LCT) Building Block", RFC 5651, DOI 10.17487/ | Transport (LCT) Building Block", RFC 5651, | |||
RFC5651, October 2009, | DOI 10.17487/RFC5651, October 2009, | |||
<http://www.rfc-editor.org/info/rfc5651>. | <http://www.rfc-editor.org/info/rfc5651>. | |||
[RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail | [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail | |||
(DKIM) Signatures -- Update", RFC 5672, DOI 10.17487/ | (DKIM) Signatures -- Update", RFC 5672, | |||
RFC5672, August 2009, | DOI 10.17487/RFC5672, August 2009, | |||
<http://www.rfc-editor.org/info/rfc5672>. | <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, DOI 10.17487/RFC5740, November 2009, | Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, | |||
<http://www.rfc-editor.org/info/rfc5740>. | <http://www.rfc-editor.org/info/rfc5740>. | |||
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous | [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous | |||
Layered Coding (ALC) Protocol Instantiation", RFC 5775, | Layered Coding (ALC) Protocol Instantiation", RFC 5775, | |||
DOI 10.17487/RFC5775, April 2010, | DOI 10.17487/RFC5775, April 2010, | |||
<http://www.rfc-editor.org/info/rfc5775>. | <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, DOI 10.17487/RFC5681, September 2009, | Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, | |||
<http://www.rfc-editor.org/info/rfc5681>. | <http://www.rfc-editor.org/info/rfc5681>. | |||
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | |||
Protocol Port Randomization", BCP 156, RFC 6056, DOI | Protocol Port Randomization", BCP 156, RFC 6056, | |||
10.17487/RFC6056, January 2011, | DOI 10.17487/RFC6056, January 2011, | |||
<http://www.rfc-editor.org/info/rfc6056>. | <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, DOI 10.17487/ | Transmission Protocol (SCTP)", RFC 6083, | |||
RFC6083, January 2011, | DOI 10.17487/RFC6083, January 2011, | |||
<http://www.rfc-editor.org/info/rfc6083>. | <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, DOI 10.17487/RFC6093, | TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, | |||
January 2011, <http://www.rfc-editor.org/info/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", | |||
6525, DOI 10.17487/RFC6525, February 2012, | RFC 6525, DOI 10.17487/RFC6525, February 2012, | |||
<http://www.rfc-editor.org/info/rfc6525>. | <http://www.rfc-editor.org/info/rfc6525>. | |||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | |||
January 2012, <http://www.rfc-editor.org/info/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", | |||
6356, DOI 10.17487/RFC6356, October 2011, | RFC 6356, DOI 10.17487/RFC6356, October 2011, | |||
<http://www.rfc-editor.org/info/rfc6356>. | <http://www.rfc-editor.org/info/rfc6356>. | |||
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error | [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error | |||
Correction (FEC) Framework", RFC 6363, DOI 10.17487/ | Correction (FEC) Framework", RFC 6363, | |||
RFC6363, October 2011, | DOI 10.17487/RFC6363, October 2011, | |||
<http://www.rfc-editor.org/info/rfc6363>. | <http://www.rfc-editor.org/info/rfc6363>. | |||
[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, DOI 10.17487/ | Transmission Protocol (SCTP)", RFC 6458, | |||
RFC6458, December 2011, | DOI 10.17487/RFC6458, December 2011, | |||
<http://www.rfc-editor.org/info/rfc6458>. | <http://www.rfc-editor.org/info/rfc6458>. | |||
[RFC6584] Roca, V., "Simple Authentication Schemes for the | [RFC6584] Roca, V., "Simple Authentication Schemes for the | |||
Asynchronous Layered Coding (ALC) and NACK-Oriented | Asynchronous Layered Coding (ALC) and NACK-Oriented | |||
Reliable Multicast (NORM) Protocols", RFC 6584, DOI | Reliable Multicast (NORM) Protocols", RFC 6584, | |||
10.17487/RFC6584, April 2012, | DOI 10.17487/RFC6584, April 2012, | |||
<http://www.rfc-editor.org/info/rfc6584>. | <http://www.rfc-editor.org/info/rfc6584>. | |||
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, | [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, | |||
"FLUTE - File Delivery over Unidirectional Transport", RFC | "FLUTE - File Delivery over Unidirectional Transport", | |||
6726, DOI 10.17487/RFC6726, November 2012, | RFC 6726, DOI 10.17487/RFC6726, November 2012, | |||
<http://www.rfc-editor.org/info/rfc6726>. | <http://www.rfc-editor.org/info/rfc6726>. | |||
[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A | [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A | |||
Datagram Congestion Control Protocol UDP Encapsulation for | Datagram Congestion Control Protocol UDP Encapsulation for | |||
NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November | NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November | |||
2012, <http://www.rfc-editor.org/info/rfc6773>. | 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, DOI 10.17487/RFC6824, January 2013, | Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, | |||
<http://www.rfc-editor.org/info/rfc6824>. | <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, DOI 10.17487/RFC6897, | Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, | |||
March 2013, <http://www.rfc-editor.org/info/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, DOI | UDP Checksums for Tunneled Packets", RFC 6935, | |||
10.17487/RFC6935, April 2013, | DOI 10.17487/RFC6935, April 2013, | |||
<http://www.rfc-editor.org/info/rfc6935>. | <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, DOI 10.17487/RFC6936, April 2013, | RFC 6936, DOI 10.17487/RFC6936, April 2013, | |||
<http://www.rfc-editor.org/info/rfc6936>. | <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, DOI 10.17487/ | to End-Host Communication", RFC 6951, | |||
RFC6951, May 2013, | DOI 10.17487/RFC6951, May 2013, | |||
<http://www.rfc-editor.org/info/rfc6951>. | <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, DOI 10.17487/RFC7053, November 2013, | Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, | |||
<http://www.rfc-editor.org/info/rfc7053>. | <http://www.rfc-editor.org/info/rfc7053>. | |||
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP | [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP | |||
Framework: Why RTP Does Not Mandate a Single Media | Framework: Why RTP Does Not Mandate a Single Media | |||
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April | Security Solution", RFC 7202, DOI 10.17487/RFC7202, April | |||
2014, <http://www.rfc-editor.org/info/rfc7202>. | 2014, <http://www.rfc-editor.org/info/rfc7202>. | |||
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Message Syntax and Routing", RFC | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
7230, DOI 10.17487/RFC7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7230>. | <http://www.rfc-editor.org/info/rfc7230>. | |||
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, | |||
10.17487/RFC7231, June 2014, | DOI 10.17487/RFC7231, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7231>. | <http://www.rfc-editor.org/info/rfc7231>. | |||
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI | Protocol (HTTP/1.1): Conditional Requests", RFC 7232, | |||
10.17487/RFC7232, June 2014, | DOI 10.17487/RFC7232, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7232>. | <http://www.rfc-editor.org/info/rfc7232>. | |||
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", | |||
RFC 7233, DOI 10.17487/RFC7233, June 2014, | RFC 7233, DOI 10.17487/RFC7233, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7233>. | <http://www.rfc-editor.org/info/rfc7233>. | |||
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | |||
RFC 7234, DOI 10.17487/RFC7234, June 2014, | RFC 7234, DOI 10.17487/RFC7234, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7234>. | <http://www.rfc-editor.org/info/rfc7234>. | |||
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Authentication", RFC 7235, DOI | Protocol (HTTP/1.1): Authentication", RFC 7235, | |||
10.17487/RFC7235, June 2014, | DOI 10.17487/RFC7235, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7235>. | <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, DOI 10.17487/RFC7301, | Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | |||
July 2014, <http://www.rfc-editor.org/info/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, Ed., "TCP Extensions for High Performance", | Scheffenegger, Ed., "TCP Extensions for High Performance", | |||
RFC 7323, DOI 10.17487/RFC7323, September 2014, | RFC 7323, DOI 10.17487/RFC7323, September 2014, | |||
<http://www.rfc-editor.org/info/rfc7323>. | <http://www.rfc-editor.org/info/rfc7323>. | |||
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. | [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. | |||
Zimmermann, "A Roadmap for Transmission Control Protocol | Zimmermann, "A Roadmap for Transmission Control Protocol | |||
(TCP) Specification Documents", RFC 7414, DOI 10.17487/ | (TCP) Specification Documents", RFC 7414, | |||
RFC7414, February 2015, | DOI 10.17487/RFC7414, February 2015, | |||
<http://www.rfc-editor.org/info/rfc7414>. | <http://www.rfc-editor.org/info/rfc7414>. | |||
[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, DOI 10.17487/RFC7457, | Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, | |||
February 2015, <http://www.rfc-editor.org/info/rfc7457>. | February 2015, <http://www.rfc-editor.org/info/rfc7457>. | |||
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, | [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, | |||
"Additional Policies for the Partially Reliable Stream | "Additional Policies for the Partially Reliable Stream | |||
Control Transmission Protocol Extension", RFC 7496, DOI | Control Transmission Protocol Extension", RFC 7496, | |||
10.17487/RFC7496, April 2015, | DOI 10.17487/RFC7496, April 2015, | |||
<http://www.rfc-editor.org/info/rfc7496>. | <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, DOI 10.17487/RFC7525, May | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | |||
2015, <http://www.rfc-editor.org/info/rfc7525>. | 2015, <http://www.rfc-editor.org/info/rfc7525>. | |||
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | |||
10.17487/RFC7540, May 2015, | DOI 10.17487/RFC7540, May 2015, | |||
<http://www.rfc-editor.org/info/rfc7540>. | <http://www.rfc-editor.org/info/rfc7540>. | |||
[I-D.ietf-tsvwg-rfc5405bis] | [I-D.ietf-tsvwg-rfc5405bis] | |||
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | |||
Guidelines", draft-ietf-tsvwg-rfc5405bis-07 (work in | Guidelines", draft-ietf-tsvwg-rfc5405bis-15 (work in | |||
progress), November 2015. | progress), June 2016. | |||
[I-D.ietf-tsvwg-sctp-dtls-encaps] | [I-D.ietf-tsvwg-sctp-dtls-encaps] | |||
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS | Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS | |||
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- | Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- | |||
dtls-encaps-09 (work in progress), January 2015. | dtls-encaps-09 (work in progress), January 2015. | |||
[I-D.ietf-tsvwg-sctp-ndata] | [I-D.ietf-tsvwg-sctp-ndata] | |||
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, | Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, | |||
"Stream Schedulers and User Message Interleaving for the | "Stream Schedulers and User Message Interleaving for the | |||
Stream Control Transmission Protocol", draft-ietf-tsvwg- | Stream Control Transmission Protocol", draft-ietf-tsvwg- | |||
sctp-ndata-04 (work in progress), July 2015. | sctp-ndata-05 (work in progress), March 2016. | |||
[I-D.ietf-tsvwg-natsupp] | [I-D.ietf-tsvwg-natsupp] | |||
Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control | Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control | |||
Transmission Protocol (SCTP) Network Address Translation | Transmission Protocol (SCTP) Network Address Translation | |||
Support", draft-ietf-tsvwg-natsupp-08 (work in progress), | Support", draft-ietf-tsvwg-natsupp-09 (work in progress), | |||
July 2015. | May 2016. | |||
[I-D.ietf-tcpm-cubic] | [I-D.ietf-tcpm-cubic] | |||
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and | Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and | |||
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", | R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", | |||
draft-ietf-tcpm-cubic-01 (work in progress), January 2016. | draft-ietf-tcpm-cubic-01 (work in progress), January 2016. | |||
[XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, | [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, | |||
"XMLHttpRequest working draft | "XMLHttpRequest working draft | |||
(http://www.w3.org/TR/XMLHttpRequest/)", 2000. | (http://www.w3.org/TR/XMLHttpRequest/)", 2000. | |||
End of changes. 73 change blocks. | ||||
171 lines changed or deleted | 170 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |