--- 1/draft-ietf-taps-transports-10.txt 2016-07-07 07:16:09.734956431 -0700 +++ 2/draft-ietf-taps-transports-11.txt 2016-07-07 07:16:09.838959037 -0700 @@ -1,53 +1,53 @@ Network Working Group G. Fairhurst, Ed. Internet-Draft University of Aberdeen Intended status: Informational B. Trammell, Ed. -Expires: September 5, 2016 M. Kuehlewind, Ed. +Expires: January 8, 2017 M. Kuehlewind, Ed. ETH Zurich - March 04, 2016 + July 07, 2016 Services provided by IETF transport protocols and congestion control mechanisms - draft-ietf-taps-transports-10 + draft-ietf-taps-transports-11 Abstract This document describes, surveys, classifies and compares the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -151,37 +151,37 @@ 1.1. Overview of Transport Features Transport protocols can be differentiated by the features of the services they provide. Some of these provided features are closely related to basic control function that a protocol needs to work over a network path, such as addressing. The number of participants in a given association also determines its applicability: if a connection is between endpoints - (unicast), to one of multiple endpoints (anycast), and/or - simultaneously to multiple endpoints (multicast). Unicast protocols - usually support bidirectional communication, while multicast is - generally unidirectional. Another feature is whether a transport - requires a control exchange across the network at setup (e.g., TCP), - or whether it connection-less (e.g., UDP). + (unicast), to one of multiple endpoints (anycast), or simultaneously + to multiple endpoints (multicast). Unicast protocols usually support + bidirectional communication, while multicast is generally + unidirectional. Another feature is whether a transport requires a + control exchange across the network at setup (e.g., TCP), or whether + it is connection-less (e.g., UDP). - For the delivery of the packets itself, reliability and integrity - protection, ordering, and framing are basic features. However, these - features are implemented with different levels of assurance in - different protocols. As an example, a transport service may provide - full reliability, providing detection of loss and retransmission - (e.g., TCP). SCTP offers a message-based service that can provide - full or partial reliability, and allows the protocol to minimize the - head of line blocking due to the support of ordered and unordered - message delivery within multiple streams. UDP-Lite and DCCP can - provide partial integrity protection to enable corruption tolerance. + For packet delivery itself, reliability and integrity protection, + ordering, and framing are basic features. However, these features + are implemented with different levels of assurance in different + protocols. As an example, a transport service may provide full + reliability, providing detection of loss and retransmission (e.g., + TCP). SCTP offers a message-based service that can provide full or + partial reliability, and allows the protocol to minimize the head of + line blocking due to the support of ordered and unordered message + delivery within multiple streams. UDP-Lite and DCCP can provide + partial integrity protection to enable corruption tolerance. Usually a protocol has been designed to support one specific type of delivery/framing: data either needs to be divided into transmission units based on network packets (datagram service), a data stream is segmented and re-combined across multiple packets (stream service), or whole objects such as files are handled accordingly. This decision strongly influences the interface that is provided to the upper layer. In addition, transport protocols offer a certain support for @@ -267,22 +267,22 @@ [RFC1191][RFC1981] as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] have been defined by the IETF. Each byte in the stream is identified by a sequence number. The sequence number is used to order segments on receipt, to identify segments in acknowledgments, and to detect unacknowledged segments for retransmission. This is the basis of the reliable, ordered delivery of data in a TCP stream. TCP Selective Acknowledgment (SACK) [RFC2018] extends this mechanism by making it possible to provide earlier identification of which segments are missing, - allowing faster retransmission. SACK-based methods (e.g. DSACK) can - also result in less spurious retransmission. + allowing faster retransmission. SACK-based methods (e.g. Duplicate + Selective ACK) can also result in less spurious retransmission. Receiver flow control is provided by a sliding window: limiting the amount of unacknowledged data that can be outstanding at a given time. The window scale option [RFC7323] allows a receiver to use windows greater than 64KB. All TCP senders provide congestion control, such as described in [RFC5681]. TCP uses a sequence number with a sliding receiver window for flow control. The TCP congestion control mechanism also utilises this TCP sequence number to manage a separate congestion window @@ -383,33 +383,33 @@ o segmentation, o data bundling (optional; uses Nagle's algorithm to coalesce data sent within the same RTT into full-sized segments), o flow control (implemented using a window-based mechanism where the receiver advertises the window that it is willing to buffer), 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, and fast recovery [RFC5681]). 3.2. Multipath TCP (MPTCP) Multipath TCP [RFC6824] is an extension for TCP to support multi- homing for resilience, mobility and load-balancing. It is designed - to be as transparent as possible to middleboxes. It does so by - establishing regular TCP flows between a pair of source/destination - endpoints, and multiplexing the application's stream over these - flows. Sub-flows can be started over IPv4 or IPv6 for the same - session. + to be as indistinguishable to middleboxes from non-multipath TCP as + possible. It does so by establishing regular TCP flows between a + pair of source/destination endpoints, and multiplexing the + application's stream over these flows. Sub- flows can be started + over IPv4 or IPv6 for the same session. 3.2.1. Protocol Description MPTCP uses TCP options for its control plane. They are used to signal multipath capabilities, as well as to negotiate data sequence numbers, and advertise other available IP addresses and establish new sessions between pairs of endpoints. By multiplexing one byte stream over separate paths, MPTCP can achieve a higher throughput than TCP in certain situations. However, @@ -483,23 +483,23 @@ It is possible to create IPv4 UDP datagrams with no checksum, and while this is generally discouraged [RFC1122] [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. These datagrams rely on the IPv4 header checksum to protect from misdelivery to an unintended endpoint. IPv6 does not permit UDP datagrams with no checksum, although in certain cases this rule may be relaxed [RFC6935]. UDP does not provide reliability and does not provide retransmission. - This implies messages may be re-ordered, lost, or duplicated in - transit. Note that due to the relatively weak form of checksum used - by UDP, applications that require end to end integrity of data are + Messages may be re-ordered, lost, or duplicated in transit. Note + that due to the relatively weak form of checksum used by UDP, + applications that require end to end integrity of data are recommended to include a stronger integrity check of their payload data. Because UDP provides no flow control, a receiving application that is unable to run sufficiently fast, or frequently, may miss messages. The lack of congestion handling implies UDP traffic may experience loss when using an overloaded path, and may cause the loss of messages from other protocols (e.g., TCP) when sharing the same network path. @@ -565,24 +565,24 @@ 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]. A UDP-Lite service may support IPv4 broadcast, multicast, anycast and unicast, and IPv6 multicast, anycast and unicast. 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]). + discarded. One use is to provider header integrity checks but allow + delivery of corrupted payloads to error-tolerant applications, or + when payload integrity is provided by some other mechanism (see + [RFC6936]). 3.4.1. Protocol Description Like UDP, UDP-Lite is a connection-less datagram protocol, with no connection setup or feature negotiation. It 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. The "checksum coverage length" field specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error-insensitive part". Applications using @@ -677,26 +677,26 @@ [RFC4960] specifies TCP-friendly congestion control to protect the network against overload. SCTP also uses sliding window flow control to protect receivers against overflow. Similar to TCP, SCTP also supports delaying acknowledgments. [RFC7053] provides a way for the sender of user messages to request the immediate sending of the corresponding acknowledgments. Each SCTP association has between 1 and 65536 uni-directional streams in each direction. The number of streams can be different in each direction. Every user message is sent on a particular stream. User - messages can be sent un-ordered, or ordered upon request by the upper - layer. Un-ordered messages can be delivered as soon as they are - completely received. Ordered messages sent on the same stream are - delivered at the receiver in the same order as sent by the sender. - For user messages not requiring fragmentation, this minimizes head of - line blocking. + 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 completely received. For user messages not requiring + fragmentation, this minimizes head of line blocking. On the other + hand, ordered messages sent on the same stream are delivered at the + receiver in the same order as sent by the sender. The base protocol defined in [RFC4960] does not allow interleaving of user- messages. Large messages on one stream can therefore block the sending of user messages on other streams. [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. This draft also specifies multiple algorithms for the sender side selection of which streams to send data from, supporting a 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 @@ -1011,22 +1011,22 @@ o unordered delivery, o flow control (implemented using the slow receiver function) o partial and full payload error detection (with optional strong integrity check). 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a pseudotransport - Transport Layer Security (TLS) [RFC5246]} and Datagram TLS (DTLS) - [RFC6347]} are IETF protocols that provide several security-related + Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) + [RFC6347] are IETF protocols that provide several security-related features to applications. TLS is designed to run on top of a reliable streaming transport protocol (usually TCP), while DTLS is 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 is 1.2; which is defined in [RFC5246]. DTLS provides nearly identical functionality to applications; it is defined in [RFC6347] and its current version is also 1.2. The TLS protocol evolved from the Secure Sockets Layer (SSL) protocols developed in the mid-1990s to support protection of HTTP traffic. @@ -1070,21 +1070,21 @@ duplicated datagrams. Like TLS, DTLS conveys application data in a sequence of independent records. However, because records are mapped to unreliable datagrams, there are several features unique to DTLS that are not applicable to TLS: o Record replay detection (optional). o Record size negotiation (estimates of PMTU and record size 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). Generally, DTLS follows the TLS design as closely as possible. To operate over datagrams, DTLS includes a sequence number and limited forms of retransmission and fragmentation for its internal operations. The sequence number may be used for detecting replayed information, according to the windowing procedure described in Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream ciphers, which are essentially incompatible when operating on @@ -1253,21 +1253,21 @@ o performance metric reporting (using associated protocols). 3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport The Hypertext Transfer Protocol (HTTP) is an application-level protocol widely used on the Internet. It provides object-oriented delivery of discrete data or files. Version 1.1 of the protocol is specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], and version 2 in [RFC7540]. HTTP is usually transported 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 existing method and data formats, or specify new methods and data formats. There are various reasons for this practice listed in [RFC3205]; these include being a well-known and well-understood protocol, reusability of existing servers and client libraries, easy use of existing security mechanisms such as HTTP digest authentication [RFC2617] and TLS [RFC5246], the ability of HTTP to traverse firewalls makes it work over many types of infrastructure, and in cases where an application server often needs to support HTTP @@ -1306,43 +1306,43 @@ resource. The client and server negotiate acceptable data formats, character sets, data encoding (e.g., data can be transferred compressed using gzip). HTTP can accommodate exchange of messages as well as data streaming (using chunked transfer encoding [RFC7230]). It is also possible to request a part of a resource using an object range request [RFC7233]. The protocol provides powerful cache control signaling defined in [RFC7234]. The persistent connections of HTTP 1.1 and HTTP 2.0 allow multiple request- response transactions (streams) during the life-time of a - single HTTP connection. HTTP 2.0 connections can multiplex many - request/response pairs in parallel on a single transport connection. - This reduces overhead during connection establishment and mitigates - transport layer slow-start that would have otherwise been incurred - for each transaction. Both are important to reduce latency for - HTTP's primary use case. + single HTTP connection. This reduces overhead during connection + establishment and mitigates transport layer slow-start that would + have otherwise been incurred for each transaction. HTTP 2.0 + connections can multiplex many request/response pairs in parallel on + a single transport connection. Both are important to reduce latency + for HTTP's primary use case. HTTP can be combined with security mechanisms, such as TLS (denoted by HTTPS). This adds protocol properties provided by such a mechanism (e.g., authentication, encryption). The TLS Application- Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to negotiate the HTTP version within the TLS handshake, eliminating the latency incurred by additional round-trip exchanges. Arbitrary cookie strings, included as part of the MIME headers, are often used as bearer tokens in HTTP. 3.9.2. Interface Description There are many HTTP libraries available exposing different APIs. The APIs provide a way to specify a request by providing a URI, a method, request modifiers and optionally a request body. For the response, 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 certificate verification is needed. The World Wide Web Consortium (W3C) has standardized the XMLHttpRequest API [XHR]. This API can be used for sending HTTP/ HTTPS requests and receiving server responses. Besides the XML data format, the request and response data format can also be JSON, HTML, and plain text. JavaScript and XMLHttpRequest are ubiquitous programming models for websites, and more general applications, where native code is less attractive. @@ -1537,24 +1537,24 @@ The protocol was designed to support reliable bulk data dissemination to receiver groups using IP Multicast but also provides for point-to- point unicast operation. Support for bulk data dissemination includes discrete file or computer memory-based "objects" as well as byte- and message-streaming. NORM can incorporate packet erasure coding as a part of its selective ARQ in response to negative acknowledgments from the receiver. The packet erasure coding can also be proactively applied for forward - protection from packet loss. NORM transmissions are governed by the - TCP-friendly congestion control. The reliability, congestion control - and flow control mechanisms can be separately controlled to meet - different application needs. + protection from packet loss. NORM transmissions are governed by TCP- + friendly multicast congestion control (TFMCC, [RFC4654]). The + reliability, congestion control and flow control mechanisms can be + separately controlled to meet different application needs. 3.11.1. Protocol Description The NORM protocol is encapsulated in UDP datagrams and thus provides multiplexing for multiple sockets on hosts using port numbers. For loosely coordinated IP Multicast, NORM is not strictly connection- oriented although per-sender state is maintained by receivers for protocol operation. [RFC5740] does not specify a handshake protocol for connection establishment. Separate session initiation can be used to coordinate port numbers. However, in-band "client-server" @@ -1681,22 +1681,22 @@ 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 a reported issue. Some formats of messages can also carry other payload data. Each message carries an integrity check calculated in the same way as for UDP, this checksum is not optional. The RFC series defines additional IPv6 message formats to support a range of uses. In the case of IPv6 the protocol incorporates - neighbor discovery [RFC2461] [RFC3971]} (provided by ARP for IPv4) - and the Multicast Listener Discovery (MLD) [RFC2710] group management + neighbor 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. 3.12.2. Interface Description ICMP processing is integrated in many connection-oriented transports, @@ -1734,64 +1734,64 @@ Many protocols use a separate window to determine the maximum sending rate that is allowed by the congestion control. The used congestion control mechanism will increase the congestion window if feedback is received that indicates that the currently used network path is not congested, and will reduce the window otherwise. Window-based mechanisms often increase their window slowing over multiple RTTs, while decreasing strongly when the first indication of congestion is received. One example is an Additive Increase Multiplicative Decrease (AIMD) scheme, where the window is increased by a certain number of packets/bytes for each data segment that has been - successfully transmitted, while the window is multiplicatively - decrease on the occurrence of a congestion event. This can lead to a - rather unstable, oscillating sending rate, but will resolve a - congestion situation quickly. TCP New Reno [RFC5681] which is one of - the initial proposed schemes for TCP as well as TCP Cubic + successfully transmitted, while the window decreases multiplicatively + on the occurrence of a congestion event. This can lead to a rather + unstable, oscillating sending rate, but will resolve a congestion + situation quickly. TCP New Reno [RFC5681] which is one of the + initial proposed schemes for TCP as well as TCP Cubic [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 also used by DCCP CCID-2 for datagram congestion control. Some classes of applications prefer to use a transport service that allows sending at a more stable rate, that is slowly varied in response to congestion. Rate-based methods offer this type of congestion control and have been defined based on the loss ratio and observed round trip time, such as TFRC [RFC5348] and TFRC-SP [RFC4828]. These methods utilize a throughput equation to determine the maximum acceptable rate. Such methods are used with DCCP CCID-3 [RFC4342] and CCID-4 [RFC5622], WEBRC [RFC3738], and other applications. Another class of applications prefer a transport service that yields to other (higher-priority) traffic, such as interactive transmissions. While most traffic in the Internet uses loss-based - congestion control and therefore need to fill the network buffers (to - a certain level if Active Queue Management (AQM) is used), low- + congestion control and therefore tends to fill the network buffers + (to a certain level if Active Queue Management (AQM) is used), low- priority congestion control methods often react to changes in delay as an earlier indication of congestion. This approach tends to induce less loss than a loss-based method but does generally not compete well with loss-based traffic across shared bottleneck links. Therefore, methods such as LEDBAT [RFC6824], are deployed in the Internet for scavenger traffic that aim to only utilize otherwise unused capacity. 5. Transport Features The tables below summarize some key features to illustrate the range of functions provided across the IETF-specified transports. Figure 1 considers transports that may be directly layered over the network, and Figure 2 considers transports layered over another transport service. Features that are permitted, but not required, are marked as "Poss" indicating that it is possible for the transport service to 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 | +---------------+------+------+------+------+------+------+------+ | Conn. Oriented| Yes | Yes | No | No | Yes | Yes | No | +---------------+------+------+------+------+------+------+------+ | Reliability | Yes | Yes | No | No | Yes | No | No | +---------------+------+------+------+------+------+------+------+ | Partial Rel. | No | No | N/A | N/A | Poss | Yes | N/A | +---------------+------+------+------+------+------+------+------+ | Corupt. Tol | No | No | No | Yes | No | Yes | No | @@ -1922,22 +1922,21 @@ + message-oriented delivery (UDP, UDP-Lite, SCTP, DCCP, DTLS, RTP) + object-oriented delivery of discrete data or files and associated metadata (HTTP, FLUTE/ALC, NORM) - with partial delivery of object ranges (HTTP) * Directionality - + unidirectional (TCP, UDP, UDP-Lite, SCTP, DCCP, RTP, FLUTE/ - ALC, NORM) + + unidirectional (UDP, UDP-Lite, DCCP, RTP, FLUTE/ALC, NORM) + bidirectional (TCP, MPTCP, SCTP, TLS, HTTP) o Transmission control * flow control (TCP, MPTCP, SCTP, DCCP, TLS, RTP, HTTP) * congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, NORM). Congestion control can also provided by the transport supporting an upper later transport (e.g., TLS, RTP, HTTP). @@ -1986,118 +1985,118 @@ o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera (ferlin@simula.no) and Olivier Mehani (olivier.mehani@nicta.com.au) 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- 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 (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 (vincent.roca@inria.fr) o Section 3.11 on NORM was contributed by Brian Adamson (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 - Thanks to Joe Touch, Michael Welzl, and the TAPS Working Group for - the comments, feedback, and discussion. This work is supported by - the European Commission under grant agreement No. 318627 mPlane and - from the Horizon 2020 research and innovation program under grant - agreements No. 644334 (NEAT) and No. 688421 (MAMI). This support - does not imply endorsement. + Thanks to Joe Touch, Michael Welzl, Spencer Dawkins, and the TAPS + Working Group for the comments, feedback, and discussion. This work + is supported by the European Commission under grant agreement No. + 318627 mPlane and from the Horizon 2020 research and innovation + program under grant agreements No. 644334 (NEAT) and No. 688421 + (MAMI). This support does not imply endorsement. 10. Informative References - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI - 10.17487/RFC0768, August 1980, + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC - 793, DOI 10.17487/RFC0793, September 1981, + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - - Communication Layers", STD 3, RFC 1122, DOI 10.17487/ - RFC1122, October 1989, + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for IP Routers", RFC 1716, DOI 10.17487/RFC1716, November 1994, . [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP - Selective Acknowledgment Options", RFC 2018, DOI 10.17487/ - RFC2018, October 1996, + Selective Acknowledgment Options", RFC 2018, + DOI 10.17487/RFC2018, October 1996, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, DOI - 10.17487/RFC2461, December 1998, + Discovery for IP Version 6 (IPv6)", RFC 2461, + DOI 10.17487/RFC2461, December 1998, . [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, . [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast - Listener Discovery (MLD) for IPv6", RFC 2710, DOI - 10.17487/RFC2710, October 1999, + Listener Discovery (MLD) for IPv6", RFC 2710, + DOI 10.17487/RFC2710, October 1999, . [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP - Payload Format Specifications", BCP 36, RFC 2736, DOI - 10.17487/RFC2736, December 1999, + Payload Format Specifications", BCP 36, RFC 2736, + DOI 10.17487/RFC2736, December 1999, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition - of Explicit Congestion Notification (ECN) to IP", RFC - 3168, DOI 10.17487/RFC3168, September 2001, + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, DOI 10.17487/RFC3205, February 2002, . [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, . @@ -2115,351 +2114,351 @@ M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, DOI 10.17487/RFC3452, December 2002, . [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, . [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate - Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/ - RFC3738, April 2004, + Control (WEBRC) Building Block", RFC 3738, + DOI 10.17487/RFC3738, April 2004, . [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) - Partial Reliability Extension", RFC 3758, DOI 10.17487/ - RFC3758, May 2004, + Partial Reliability Extension", RFC 3758, + DOI 10.17487/RFC3758, May 2004, . [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, . [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, + "FLUTE - File Delivery over Unidirectional Transport", + RFC 3926, DOI 10.17487/RFC3926, October 2004, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, - "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI - 10.17487/RFC3971, March 2005, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + DOI 10.17487/RFC3971, March 2005, . [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December 2005, . [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement - for the Datagram Congestion Control Protocol (DCCP)", RFC - 4336, DOI 10.17487/RFC4336, March 2006, + for the Datagram Congestion Control Protocol (DCCP)", + RFC 4336, DOI 10.17487/RFC4336, March 2006, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram - Congestion Control Protocol (DCCP)", RFC 4340, DOI - 10.17487/RFC4340, March 2006, + Congestion Control Protocol (DCCP)", RFC 4340, + DOI 10.17487/RFC4340, March 2006, . [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, . [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, . [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 - Dynamic Home Agent (HA) Assignment", RFC 4433, DOI - 10.17487/RFC4433, March 2006, + Dynamic Home Agent (HA) Assignment", RFC 4433, + DOI 10.17487/RFC4433, March 2006, . [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast - Congestion Control (TFMCC): Protocol Specification", RFC - 4654, DOI 10.17487/RFC4654, August 2006, + Congestion Control (TFMCC): Protocol Specification", + RFC 4654, DOI 10.17487/RFC4654, August 2006, . [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control - (TFRC): The Small-Packet (SP) Variant", RFC 4828, DOI - 10.17487/RFC4828, April 2007, + (TFRC): The Small-Packet (SP) Variant", RFC 4828, + DOI 10.17487/RFC4828, April 2007, . [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) - Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/ - RFC5061, September 2007, + Dynamic Address Reconfiguration", RFC 5061, + DOI 10.17487/RFC5061, September 2007, . [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ - RFC5246, August 2008, + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, . [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over - the Datagram Congestion Control Protocol (DCCP)", RFC - 5238, DOI 10.17487/RFC5238, May 2008, + the Datagram Congestion Control Protocol (DCCP)", + RFC 5238, DOI 10.17487/RFC5238, May 2008, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP - Friendly Rate Control (TFRC): Protocol Specification", RFC - 5348, DOI 10.17487/RFC5348, September 2008, + Friendly Rate Control (TFRC): Protocol Specification", + RFC 5348, DOI 10.17487/RFC5348, September 2008, . - [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI - 10.17487/RFC5461, February 2009, + [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, + DOI 10.17487/RFC5461, February 2009, . [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, . [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/ Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, September 2009, . [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate - Control for Small Packets (TFRC-SP)", RFC 5622, DOI - 10.17487/RFC5622, August 2009, + Control for Small Packets (TFRC-SP)", RFC 5622, + DOI 10.17487/RFC5622, August 2009, . [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding - Transport (LCT) Building Block", RFC 5651, DOI 10.17487/ - RFC5651, October 2009, + Transport (LCT) Building Block", RFC 5651, + DOI 10.17487/RFC5651, October 2009, . [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail - (DKIM) Signatures -- Update", RFC 5672, DOI 10.17487/ - RFC5672, August 2009, + (DKIM) Signatures -- Update", RFC 5672, + DOI 10.17487/RFC5672, August 2009, . [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, . [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- - Protocol Port Randomization", BCP 156, RFC 6056, DOI - 10.17487/RFC6056, January 2011, + Protocol Port Randomization", BCP 156, RFC 6056, + DOI 10.17487/RFC6056, January 2011, . [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control - Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/ - RFC6083, January 2011, + Transmission Protocol (SCTP)", RFC 6083, + DOI 10.17487/RFC6083, January 2011, . [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, . [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control - Transmission Protocol (SCTP) Stream Reconfiguration", RFC - 6525, DOI 10.17487/RFC6525, February 2012, + Transmission Protocol (SCTP) Stream Reconfiguration", + RFC 6525, DOI 10.17487/RFC6525, February 2012, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled - Congestion Control for Multipath Transport Protocols", RFC - 6356, DOI 10.17487/RFC6356, October 2011, + Congestion Control for Multipath Transport Protocols", + RFC 6356, DOI 10.17487/RFC6356, October 2011, . [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error - Correction (FEC) Framework", RFC 6363, DOI 10.17487/ - RFC6363, October 2011, + Correction (FEC) Framework", RFC 6363, + DOI 10.17487/RFC6363, October 2011, . [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control - Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/ - RFC6458, December 2011, + Transmission Protocol (SCTP)", RFC 6458, + DOI 10.17487/RFC6458, December 2011, . [RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented - Reliable Multicast (NORM) Protocols", RFC 6584, DOI - 10.17487/RFC6584, April 2012, + Reliable Multicast (NORM) Protocols", RFC 6584, + DOI 10.17487/RFC6584, April 2012, . [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, + "FLUTE - File Delivery over Unidirectional Transport", + RFC 6726, DOI 10.17487/RFC6726, November 2012, . [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, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and - UDP Checksums for Tunneled Packets", RFC 6935, DOI - 10.17487/RFC6935, April 2013, + UDP Checksums for Tunneled Packets", RFC 6935, + DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host - to End-Host Communication", RFC 6951, DOI 10.17487/ - RFC6951, May 2013, + to End-Host Communication", RFC 6951, + DOI 10.17487/RFC6951, May 2013, . [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, . [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Message Syntax and Routing", RFC - 7230, DOI 10.17487/RFC7230, June 2014, + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI - 10.17487/RFC7231, June 2014, + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, . [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI - 10.17487/RFC7232, June 2014, + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + DOI 10.17487/RFC7232, June 2014, . [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, . [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Authentication", RFC 7235, DOI - 10.17487/RFC7235, June 2014, + Protocol (HTTP/1.1): Authentication", RFC 7235, + DOI 10.17487/RFC7235, June 2014, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol - (TCP) Specification Documents", RFC 7414, DOI 10.17487/ - RFC7414, February 2015, + (TCP) Specification Documents", RFC 7414, + DOI 10.17487/RFC7414, February 2015, . [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, . [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, + Control Transmission Protocol Extension", RFC 7496, + DOI 10.17487/RFC7496, April 2015, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext - Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI - 10.17487/RFC7540, May 2015, + Transfer Protocol Version 2 (HTTP/2)", RFC 7540, + DOI 10.17487/RFC7540, May 2015, . [I-D.ietf-tsvwg-rfc5405bis] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage - Guidelines", draft-ietf-tsvwg-rfc5405bis-07 (work in - progress), November 2015. + Guidelines", draft-ietf-tsvwg-rfc5405bis-15 (work in + progress), June 2016. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-09 (work in progress), January 2015. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the 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] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation - Support", draft-ietf-tsvwg-natsupp-08 (work in progress), - July 2015. + Support", draft-ietf-tsvwg-natsupp-09 (work in progress), + May 2016. [I-D.ietf-tcpm-cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", draft-ietf-tcpm-cubic-01 (work in progress), January 2016. [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, "XMLHttpRequest working draft (http://www.w3.org/TR/XMLHttpRequest/)", 2000.