draft-ietf-taps-transports-usage-06.txt   draft-ietf-taps-transports-usage-07.txt 
TAPS M. Welzl TAPS M. Welzl
Internet-Draft University of Oslo Internet-Draft University of Oslo
Intended status: Informational M. Tuexen Intended status: Informational M. Tuexen
Expires: December 26, 2017 Muenster Univ. of Appl. Sciences Expires: February 26, 2018 Muenster Univ. of Appl. Sciences
N. Khademi N. Khademi
University of Oslo University of Oslo
June 24, 2017 August 25, 2017
On the Usage of Transport Features Provided by IETF Transport Protocols On the Usage of Transport Features Provided by IETF Transport Protocols
draft-ietf-taps-transports-usage-06 draft-ietf-taps-transports-usage-07
Abstract Abstract
This document describes how the transport protocols Transmission This document describes how the transport protocols Transmission
Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control
Transmission Protocol (SCTP), User Datagram Protocol (UDP) and Transmission Protocol (SCTP), User Datagram Protocol (UDP) and
Lightweight User Datagram Protocol (UDP-Lite) expose services to Lightweight User Datagram Protocol (UDP-Lite) expose services to
applications and how an application can configure and use the applications and how an application can configure and use the
features that make up these services. It also discusses the service features that make up these services. It also discusses the service
provided by the Low Extra Delay Background Transport (LEDBAT) provided by the Low Extra Delay Background Transport (LEDBAT)
congestion control mechanism. The description results in a set of congestion control mechanism. The description results in a set of
transport abstractions that can be exported in a TAPS API. transport abstractions that can be exported in a TAPS API. For UDP
and UDP-Lite, the first step of the protocol analysis -- a discussion
of relevant RFC text -- is documented in [FJ16]. XX RFC ED - PLEASE
REPLACE [FJ16] WITH THE CORRECT RFC NUMBER XXX
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 December 26, 2017. This Internet-Draft will expire on February 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . . 5 3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . . 5
3.1.1. Excluded Primitives or Parameters . . . . . . . . . . 9 3.1.1. Excluded Primitives or Parameters . . . . . . . . . . 9
3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . . 9 3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . . 9
3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 10 3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 11
3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 17 3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 17
3.4. Primitives Provided by UDP and UDP-Lite . . . . . . . . . 18 3.4. Primitives Provided by UDP and UDP-Lite . . . . . . . . . 18
3.5. The service of LEDBAT . . . . . . . . . . . . . . . . . . 19 3.5. The service of LEDBAT . . . . . . . . . . . . . . . . . . 18
4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 21 4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 20
4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 32 4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 32
5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. CONNECTION Related Transport Features . . . . . . . . . . 35 5.1. CONNECTION Related Transport Features . . . . . . . . . . 34
5.2. DATA Transfer Related Transport Features . . . . . . . . . 41 5.2. DATA Transfer Related Transport Features . . . . . . . . . 40
5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 41 5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40
5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 42 5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41
5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 42
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . . 46 9.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 48 Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 47
Appendix B. How this document was developed . . . . . . . . . . . 48 Appendix B. How this document was developed . . . . . . . . . . . 47
Appendix C. Revision information . . . . . . . . . . . . . . . . 49 Appendix C. Revision information . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Terminology 1. Terminology
Transport Feature: a specific end-to-end feature that the transport Transport Feature: a specific end-to-end feature that the transport
layer provides to an application. Examples include layer provides to an application. Examples include
confidentiality, reliable delivery, ordered delivery, message- confidentiality, reliable delivery, ordered delivery, message-
versus-stream orientation, etc. versus-stream orientation, etc.
Transport Service: a set of Transport Features, without an Transport Service: a set of Transport Features, without an
association to any given framing protocol, which provides a association to any given framing protocol, which provides a
complete service to an application. complete service to an application.
Transport Protocol: an implementation that provides one or more Transport Protocol: an implementation that provides one or more
different transport services using a specific framing and header transport services using a specific framing and header format on
format on the wire. the wire.
Transport Protocol Component: an implementation of a Transport Transport Protocol Component: an implementation of a Transport
Feature within a protocol. Feature within a protocol.
Transport Service Instance: an arrangement of transport protocols Transport Service Instance: an arrangement of transport protocols
with a selected set of features and configuration parameters that with a selected set of features and configuration parameters that
implements a single transport service, e.g., a protocol stack (RTP implements a single transport service, e.g., a protocol stack (RTP
over UDP). over UDP).
Application: an entity that uses the transport layer for end-to-end Application: an entity that uses the transport layer for end-to-end
delivery of data across the network (this may also be an upper delivery of data across the network (this may also be an upper
layer protocol or tunnel encapsulation). layer protocol or tunnel encapsulation).
Endpoint: an entity that communicates with one or more other Endpoint: an entity that communicates with one or more other
skipping to change at page 3, line 43 skipping to change at page 3, line 43
Event: a primitive that is invoked by a transport endpoint. Event: a primitive that is invoked by a transport endpoint.
Parameter: a value passed between an application and a transport Parameter: a value passed between an application and a transport
protocol by a primitive. protocol by a primitive.
Socket: the combination of a destination IP address and a Socket: the combination of a destination IP address and a
destination port number. destination port number.
Transport Address: the combination of an IP address, transport Transport Address: the combination of an IP address, transport
protocol and the port number used by the transport protocol. protocol and the port number used by the transport protocol.
2. Introduction 2. Introduction
The TAPS working group intends to describe an (abstract) interface This specification describes an (abstract) interface for applications
for applications to make use of Transport Services, such that to make use of Transport Services, such that applications are no
applications are no longer directly tied to a specific protocol. longer directly tied to a specific protocol. Breaking this strict
Breaking this strict connection can reduce the effort for an connection can reduce the effort for an application programmer, yet
application programmer, yet attain greater transport flexibility by attain greater transport flexibility by pushing complexity into an
pushing complexity into an underlying TAPS system. underlying TAPS system.
This design process has started with a survey of the services This design process has started with a survey of the services
provided by IETF transport protocols and congestion control provided by IETF transport protocols and congestion control
mechanisms [RFC8095]. The present document and [FJ16] complement mechanisms [RFC8095]. The present document and [FJ16] complement
this survey with an in-depth look at the defined interactions between this survey with an in-depth look at the defined interactions between
applications and the following unicast transport protocols: applications and the following unicast transport protocols:
Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream
Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), Control Transmission Protocol (SCTP), User Datagram Protocol (UDP),
Lightweight User Datagram Protocol (UDP-Lite). We also define a Lightweight User Datagram Protocol (UDP-Lite). We also define a
primitive to enable/disable and configure the Low Extra Delay primitive to enable/disable and configure the Low Extra Delay
Background Transport (LEDBAT) unicast congestion control mechanism. Background Transport (LEDBAT) unicast congestion control mechanism.
For UDP and UDP-Lite, the first step of the protocol analysis -- a
discussion of relevant RFC text -- is documented in [FJ16].
This snapshot in time analysis of the IETF transport protocols is This snapshot in time analysis of the IETF transport protocols is
published as an RFC to document the authors' and working group's published as an RFC to document the authors' and working group's
analysis, generating a set of transport abstractions that can be analysis, generating a set of transport abstractions that can be
exported in a TAPS API. It provides the basis for the minimal set of exported in a TAPS API. It provides the basis for the minimal set of
transport services that end systems supporting TAPS should implement transport services that end systems supporting TAPS should implement
[I-D.draft-gjessing-taps-minset]. [I-D.draft-gjessing-taps-minset].
The list of primitives, events and transport features in this The list of primitives, events and transport features in this
document is strictly based on the parts of protocol specifications document is strictly based on the parts of protocol specifications
that describe what the protocol provides to an application using it that describe what the protocol provides to an application using it
and how the application interacts with it. Transport protocols and how the application interacts with it. Transport protocols
provide communication between processes that operate on network provide communication between processes that operate on network
endpoints, which means that they allow for multiplexing of endpoints, which means that they allow for multiplexing of
communication between the same IP addresses, and normally this communication between the same IP addresses, and this multiplexing is
multiplexing is achieved using port numbers. Port multiplexing is achieved using port numbers. Port multiplexing is therefore assumed
therefore assumed to be always provided and not discussed in this to be always provided and not discussed in this document.
document.
Parts of a protocol that are explicitly stated as optional to Parts of a protocol that are explicitly stated as optional to
implement are not covered. Interactions between the application and implement are not covered. Interactions between the application and
a transport protocol that are not directly related to the operation a transport protocol that are not directly related to the operation
of the protocol are also not covered. For example, there are various of the protocol are also not covered. For example, there are various
ways for an application to use socket options to indicate its ways for an application to use socket options to indicate its
interest in receiving certain notifications [RFC6458]. However, for interest in receiving certain notifications [RFC6458]. However, for
the purpose of identifying primitives, events and transport features, the purpose of identifying primitives, events and transport features,
the ability to enable or disable the reception of notifications is the ability to enable or disable the reception of notifications is
irrelevant. Similarly, "one-to-many style sockets" [RFC6458] just irrelevant. Similarly, "one-to-many style sockets" [RFC6458] just
skipping to change at page 10, line 48 skipping to change at page 11, line 7
allows a host to announce these addresses as part of the protocol. allows a host to announce these addresses as part of the protocol.
The MPTCP API Considerations RFC [RFC6897] says "An application The MPTCP API Considerations RFC [RFC6897] says "An application
should be able to restrict MPTCP to binding to a given set of should be able to restrict MPTCP to binding to a given set of
addresses" and thus allows applications to limit the set of addresses" and thus allows applications to limit the set of
addresses that are being used by MPTCP. Further, "An application addresses that are being used by MPTCP. Further, "An application
should be able to obtain information on the pairs of addresses should be able to obtain information on the pairs of addresses
used by the MPTCP subflows". used by the MPTCP subflows".
3.3. Primitives Provided by SCTP 3.3. Primitives Provided by SCTP
TCP has a number of limitations that SCPT removes (section 1.1 of TCP has a number of limitations that SCTP removes (section 1.1 of
[RFC4960]). The following three removed limitations directly [RFC4960]). The following three removed limitations directly
translate into transport features that are visible to an application translate into transport features that are visible to an application
using SCTP: 1) it allows for preservation of message delineations; 2) using SCTP: 1) it allows for preservation of message delineations; 2)
these messages, do not require to be in order or reliably transferred it does not provide in-order or reliable delivery unless the
unless the application wants it; 3) multi-homing is supported. In application wants that; 3) multi-homing is supported. In SCTP,
SCTP, connections are called "associations" and they can be between connections are called "associations" and they can be between not
not only two (as in TCP) but multiple addresses at each endpoint. only two (as in TCP) but multiple addresses at each endpoint.
Section 10 of the SCTP base protocol specification [RFC4960] Section 10 of the SCTP base protocol specification [RFC4960]
specifies the interaction with the application (which this RFC calls specifies the interaction with the application (which SCTP calls the
the "Upper Layer Protocol" (ULP)). It is assumed that the Operating "Upper Layer Protocol" (ULP)). It is assumed that the Operating
System provides a means for SCTP to asynchronously signal the System provides a means for SCTP to asynchronously signal the
application; the primitives representing such signals are called application; the primitives representing such signals are called
'events' in this section. Here, we describe the relevant primitives. 'events' in this section. Here, we describe the relevant primitives.
In addition to the abstract API described in the section 10 of the In addition to the abstract API described in the section 10 of the
SCTP base protocol specification [RFC4960], an extension to the SCTP base protocol specification [RFC4960], an extension to the
socket API is described in [RFC6458]. This covers the functionality socket API is described in [RFC6458]. This covers the functionality
of the base protocol [RFC4960] and some of its extensions [RFC3758], of the base protocol [RFC4960] and some of its extensions [RFC3758],
[RFC4895], [RFC5061]. For other protocol extensions [RFC6525], [RFC4895], [RFC5061]. For other protocol extensions [RFC6525],
[RFC6951], [RFC7053], [RFC7496], [RFC7829], [RFC6951], [RFC7053], [RFC7496], [RFC7829],
[I-D.ietf-tsvwg-sctp-ndata], the corresponding extensions of the [I-D.ietf-tsvwg-sctp-ndata], the corresponding extensions of the
socket API are specified in these protocol specifications. The socket API are specified in these protocol specifications. The
functionality exposed to the ULP through the all these APIs is functionality exposed to the ULP through all these APIs is considered
considered here. here.
The abstract API contains a 'SetProtocolParameters' primitive that The abstract API contains a 'SetProtocolParameters' primitive that
allows to adjust elements of a parameter list [RFC4960]; it is stated allows to adjust elements of a parameter list [RFC4960]; it is stated
that SCTP implementations "may allow ULP to customize some of these that SCTP implementations "may allow ULP to customize some of these
protocol parameters", indicating that none of the elements of this protocol parameters", indicating that none of the elements of this
parameter list are mandatory to make ULP-configurable. Thus, we only parameter list are mandatory to make ULP-configurable. Thus, we only
consider the parameters in the abstract API that are also covered in consider the parameters in the abstract API that are also covered in
one of the other RFCs listed above, which leads us to exclude the one of the other RFCs listed above, which leads us to exclude the
parameters RTO.Alpha, RTO.Beta and HB.Max.Burst. For clarity, we parameters RTO.Alpha, RTO.Beta and HB.Max.Burst. For clarity, we
also replace 'SetProtocolParameters' itself with primitives that also replace 'SetProtocolParameters' itself with primitives that
skipping to change at page 18, line 23 skipping to change at page 18, line 23
'Shutdown' event informs an application that the peer has sent a 'Shutdown' event informs an application that the peer has sent a
SHUTDOWN, and hence no further data should be sent on this socket SHUTDOWN, and hence no further data should be sent on this socket
(section 6.1 of [RFC6458]). However, if an application would try to (section 6.1 of [RFC6458]). However, if an application would try to
send data on the socket, it would get an error message anyway; thus, send data on the socket, it would get an error message anyway; thus,
this event is classified as "just affecting the application this event is classified as "just affecting the application
programming style, not how the underlying protocol operates" and not programming style, not how the underlying protocol operates" and not
included here. included here.
3.4. Primitives Provided by UDP and UDP-Lite 3.4. Primitives Provided by UDP and UDP-Lite
The initial UDP specification [RFC0768] states: "This User Datagram
Protocol (UDP) is defined to make available a datagram mode of
packet-switched computer communication in the environment of an
interconnected set of computer networks." It "provides a procedure
for application programs to send messages to other programs with a
minimum of protocol mechanism (..)".
The User Interface section of RFC768 states that the user interface
to an application should be able to create receive, source and
destination ports and addresses, and provide operations to receive
data based on ports with an indication of source port and address.
Operations should be provided that allow datagrams be sent specifying
the source and destination ports and addresses to be sent.
UDP offers only a basic transport interface. UDP datagrams may be
directly sent and received, without exchanging messages between the
endpoints to setup a connection (i.e., no handshake is performed by
the transport protocol prior to communication). Neither UDP nor UDP-
Lite provide congestion control, retransmission, nor do they have
support to optimise fragmentation and other transport functions.
This means that applications using UDP need to provide additional
functions on top of the UDP transport API [RFC8085]. Guidance on the
use of the services provided by UDP is provided in the UDP Guidelines
[RFC8085].
The set of pass 1 primitives for UDP and UDP-Lite is documented in The set of pass 1 primitives for UDP and UDP-Lite is documented in
[FJ16]. [FJ16].
3.5. The service of LEDBAT 3.5. The service of LEDBAT
The service of the Low Extra Delay Background Transport (LEDBAT) The service of the Low Extra Delay Background Transport (LEDBAT)
congestion control mechanism is described as follows: "LEDBAT is congestion control mechanism is described as follows: "LEDBAT is
designed for use by background bulk-transfer applications to be no designed for use by background bulk-transfer applications to be no
more aggressive than standard TCP congestion control (as specified in more aggressive than standard TCP congestion control (as specified in
RFC 5681) and to yield in the presence of competing flows, thus RFC 5681) and to yield in the presence of competing flows, thus
skipping to change at page 44, line 27 skipping to change at page 43, line 37
Security considerations for the use of UDP and UDP-Lite are provided Security considerations for the use of UDP and UDP-Lite are provided
in the referenced RFCs. Security guidance for application usage is in the referenced RFCs. Security guidance for application usage is
provided in the UDP-Guidelines [RFC8085]. provided in the UDP-Guidelines [RFC8085].
9. References 9. References
9.1. Normative References 9.1. Normative References
[FJ16] Fairhurst, G. and T. Jones, "Features of the User Datagram [FJ16] Fairhurst, G. and T. Jones, "Features of the User Datagram
Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport
Protocols", draft-ietf-taps-transports-usage-udp-02 (work Protocols", draft-ietf-taps-transports-usage-udp-04 (work
in progress), May 2017. in progress), July 2017.
[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", Stream Control Transmission Protocol",
draft-ietf-tsvwg-sctp-ndata-08 (work in progress), draft-ietf-tsvwg-sctp-ndata-08 (work in progress),
October 2016. October 2016.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[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, DOI 10.17487/
RFC1122, October 1989, RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[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, DOI 10.17487/
RFC3758, May 2004, RFC3758, May 2004,
<http://www.rfc-editor.org/info/rfc3758>. <https://www.rfc-editor.org/info/rfc3758>.
[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, Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895,
August 2007, <http://www.rfc-editor.org/info/rfc4895>. August 2007, <https://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>. <https://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, DOI 10.17487/
RFC5061, September 2007, RFC5061, September 2007,
<http://www.rfc-editor.org/info/rfc5061>. <https://www.rfc-editor.org/info/rfc5061>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, DOI 10.17487/RFC5482, March 2009, RFC 5482, DOI 10.17487/RFC5482, March 2009,
<http://www.rfc-editor.org/info/rfc5482>. <https://www.rfc-editor.org/info/rfc5482>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<http://www.rfc-editor.org/info/rfc6182>. <https://www.rfc-editor.org/info/rfc6182>.
[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, DOI 10.17487/
RFC6458, December 2011, RFC6458, December 2011,
<http://www.rfc-editor.org/info/rfc6458>. <https://www.rfc-editor.org/info/rfc6458>.
[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", Transmission Protocol (SCTP) Stream Reconfiguration",
RFC 6525, DOI 10.17487/RFC6525, February 2012, RFC 6525, DOI 10.17487/RFC6525, February 2012,
<http://www.rfc-editor.org/info/rfc6525>. <https://www.rfc-editor.org/info/rfc6525>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
[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>. <https://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, <https://www.rfc-editor.org/info/rfc6897>.
[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, DOI 10.17487/
RFC6951, May 2013, RFC6951, May 2013,
<http://www.rfc-editor.org/info/rfc6951>. <https://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>. <https://www.rfc-editor.org/info/rfc7053>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[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, Control Transmission Protocol Extension", RFC 7496,
DOI 10.17487/RFC7496, April 2015, DOI 10.17487/RFC7496, April 2015,
<http://www.rfc-editor.org/info/rfc7496>. <https://www.rfc-editor.org/info/rfc7496>.
[RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. [RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K.
Nielsen, "SCTP-PF: A Quick Failover Algorithm for the Nielsen, "SCTP-PF: A Quick Failover Algorithm for the
Stream Control Transmission Protocol", RFC 7829, Stream Control Transmission Protocol", RFC 7829,
DOI 10.17487/RFC7829, April 2016, DOI 10.17487/RFC7829, April 2016,
<http://www.rfc-editor.org/info/rfc7829>. <https://www.rfc-editor.org/info/rfc7829>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <http://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
9.2. Informative References 9.2. Informative References
[I-D.draft-gjessing-taps-minset] [I-D.draft-gjessing-taps-minset]
Gjessing, S. and M. Welzl, "A Minimal Set of Transport Gjessing, S. and M. Welzl, "A Minimal Set of Transport
Services for TAPS Systems", draft-gjessing-taps-minset-05 Services for TAPS Systems", draft-gjessing-taps-minset-05
(work in progress), June 2017. (work in progress), June 2017.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, Specification", STD 8, RFC 854, DOI 10.17487/RFC0854,
May 1983, <http://www.rfc-editor.org/info/rfc854>. May 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[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>. <https://www.rfc-editor.org/info/rfc3260>.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
DOI 10.17487/RFC5461, February 2009, DOI 10.17487/RFC5461, February 2009,
<http://www.rfc-editor.org/info/rfc5461>. <https://www.rfc-editor.org/info/rfc5461>.
[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, <https://www.rfc-editor.org/info/rfc6093>.
[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, DOI 10.17487/
RFC7414, February 2015, RFC7414, February 2015,
<http://www.rfc-editor.org/info/rfc7414>. <https://www.rfc-editor.org/info/rfc7414>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ Congestion Control Mechanisms", RFC 8095, DOI 10.17487/
RFC8095, March 2017, RFC8095, March 2017,
<http://www.rfc-editor.org/info/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
Appendix A. Overview of RFCs used as input for pass 1 Appendix A. Overview of RFCs used as input for pass 1
TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], [RFC7413] TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], [RFC7413]
MPTCP: [RFC6182], [RFC6824], [RFC6897] MPTCP: [RFC6182], [RFC6824], [RFC6897]
SCTP: RFCs without a socket API specification: [RFC3758], [RFC4895], SCTP: RFCs without a socket API specification: [RFC3758], [RFC4895],
[RFC4960], [RFC5061]. [RFC4960], [RFC5061].
RFCs that include a socket API specification: [RFC6458], RFCs that include a socket API specification: [RFC6458],
[RFC6525], [RFC6951], [RFC7053], [RFC7496] [RFC7829]. [RFC6525], [RFC6951], [RFC7053], [RFC7496] [RFC7829].
UDP(-Lite): See [FJ16] UDP(-Lite): See [FJ16]
 End of changes. 51 change blocks. 
103 lines changed or deleted 78 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/