draft-ietf-taps-transports-usage-08.txt   draft-ietf-taps-transports-usage-09.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: February 27, 2018 Muenster Univ. of Appl. Sciences Expires: April 29, 2018 Muenster Univ. of Appl. Sciences
N. Khademi N. Khademi
University of Oslo University of Oslo
August 26, 2017 October 26, 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-08 draft-ietf-taps-transports-usage-09
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. For UDP transport abstractions that can be exported in a TAPS API.
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 February 27, 2018. This Internet-Draft will expire on April 29, 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 22 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. 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 . . . . . . . . . . . . . . . 10
3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 11 3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 11
3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 17 3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . 18 3.5. The service of LEDBAT . . . . . . . . . . . . . . . . . . 18
4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 20 4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 20
4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 32 4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 38
5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1. CONNECTION Related Transport Features . . . . . . . . . . 34 5.1. CONNECTION Related Transport Features . . . . . . . . . . 41
5.2. DATA Transfer Related Transport Features . . . . . . . . . 40 5.2. DATA Transfer Related Transport Features . . . . . . . . . 47
5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40 5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 47
5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41 5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 48
5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . . 43 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . . 45 9.2. Informative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 47 Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 53
Appendix B. How this document was developed . . . . . . . . . . . 47 Appendix B. How this document was developed . . . . . . . . . . . 54
Appendix C. Revision information . . . . . . . . . . . . . . . . 48 Appendix C. Revision information . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
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.
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
This specification describes an (abstract) interface for applications This specification describes an abstract interface for applications
to make use of Transport Services, such that applications are no to make use of Transport Services, such that applications are no
longer directly tied to a specific protocol. Breaking this strict longer directly tied to a specific protocol. Breaking this strict
connection can reduce the effort for an application programmer, yet connection can reduce the effort for an application programmer, yet
attain greater transport flexibility by pushing complexity into an attain greater transport flexibility by pushing complexity into an
underlying TAPS system. underlying Transport Services (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
skipping to change at page 6, line 49 skipping to change at page 6, line 49
given for the usage of source route (section 4.2.3.8 of given for the usage of source route (section 4.2.3.8 of
[RFC1122]). Source route is the only non-optional IP option in [RFC1122]). Source route is the only non-optional IP option in
this parameter, allowing an application to specify a source route this parameter, allowing an application to specify a source route
when it actively opens a TCP connection. when it actively opens a TCP connection.
Master Key Tuples (MKTs) for authentication can optionally be Master Key Tuples (MKTs) for authentication can optionally be
configured when calling open (section 7.1 of [RFC5925]). When configured when calling open (section 7.1 of [RFC5925]). When
authentication is in use, complete TCP segments are authenticated, authentication is in use, complete TCP segments are authenticated,
including the TCP IPv4 pseudoheader, TCP header, and TCP data. including the TCP IPv4 pseudoheader, TCP header, and TCP data.
TCP Fast Open (TFO) [RFC7413] allows to immediately hand over a TCP Fast Open (TFO) [RFC7413] allows applications to immediately
message from the active open to the passive open side of a TCP hand over a message from the active open to the passive open side
connection together with the first message establishment packet of a TCP connection together with the first message establishment
(the SYN). This can be useful for applications that are sensitive packet (the SYN). This can be useful for applications that are
to TCP's connection setup delay. TCP implementations MUST NOT use sensitive to TCP's connection setup delay. [RFC7413] states that
TFO by default, but only use TFO if requested explicitly by the "TCP implementations MUST NOT use TFO by default, but only use TFO
application on a per-service-port basis. more than TCP's maximum if requested explicitly by the application on a per-service-port
segment size (minus options used in the SYN). For the active open basis". The size of the message sent with TFO cannot be more than
side, it is recommended to change or replace the connect() call in TCP's maximum segment size (minus options used in the SYN). For
order to support a user data buffer argument [RFC7413]. For the the active open side, it is recommended to change or replace the
passive open side, the application needs to enable the reception connect() call in order to support a user data buffer argument
of Fast Open requests, e.g. via a new TCP_FASTOPEN setsockopt() [RFC7413]. For the passive open side, the application needs to
socket option before listen(). The receiving application must be enable the reception of Fast Open requests, e.g. via a new
prepared to accept duplicates of the TFO message, as the first TCP_FASTOPEN setsockopt() socket option before listen(). The
data written to a socket can be delivered more than once to the receiving application must be prepared to accept duplicates of the
application on the remote host. TFO message, as the first data written to a socket can be
delivered more than once to the application on the remote host.
Send: this is the primitive that an application uses to give the Send: this is the primitive that an application uses to give the
local TCP transport endpoint a number of bytes that TCP should local TCP transport endpoint a number of bytes that TCP should
reliably send to the other side of the connection. The 'urgent' reliably send to the other side of the connection. The 'urgent'
flag, if set, states that the data handed over by this send call flag, if set, states that the data handed over by this send call
is urgent and this urgency should be indicated to the receiving is urgent and this urgency should be indicated to the receiving
process in case the receiving application has not yet consumed all process in case the receiving application has not yet consumed all
non-urgent data preceding it. An optional timeout parameter can non-urgent data preceding it. An optional timeout parameter can
be provided that updates the connection's timeout (see 'open'). be provided that updates the connection's timeout (see 'open').
Additionally, optional parameters allow to indicate the preferred Additionally, optional parameters allow to indicate the preferred
skipping to change at page 8, line 30 skipping to change at page 8, line 30
flushed and the application is informed that the connection had to flushed and the application is informed that the connection had to
be aborted due to user timeout. be aborted due to user timeout.
Error_Report event: This event informs the application of "soft Error_Report event: This event informs the application of "soft
errors" that can be safely ignored [RFC5461], including the errors" that can be safely ignored [RFC5461], including the
arrival of an ICMP error message or excessive retransmissions arrival of an ICMP error message or excessive retransmissions
(reaching a threshold below the threshold where the connection is (reaching a threshold below the threshold where the connection is
aborted). See section 4.2.4.1 of [RFC1122]. aborted). See section 4.2.4.1 of [RFC1122].
Type-of-Service: Section 4.2.4.2 of the requirements for Internet Type-of-Service: Section 4.2.4.2 of the requirements for Internet
hosts [RFC1122] states that the application layer MUST be able to hosts [RFC1122] states that "the application layer MUST be able to
specify the Type-of-Service (TOS) for segments that are sent on a specify the Type-of-Service (TOS) for segments that are sent on a
connection. The application should be able to change the TOS connection". The application should be able to change the TOS
during the connection lifetime, and the TOS value should be passed during the connection lifetime, and the TOS value should be passed
to the IP layer unchanged. Since then the TOS field has been to the IP layer unchanged. Since then the TOS field has been
redefined. The Differentiated Services (diffuser) model [RFC2475] redefined. The Differentiated Services (DiffServ) model [RFC2475]
[RFC3260] replaces this field in the IP Header, assigning the six [RFC3260] replaces this field in the IP Header, assigning the six
most significant bits to carry the Differentiated Services Code most significant bits to carry the Differentiated Services Code
Point (DSCP) field [RFC2474]. Point (DSCP) field [RFC2474].
Nagle: The Nagle algorithm delays sending data for some time to Nagle: The Nagle algorithm delays sending data for some time to
increase the likelihood of sending a full-sized segment (section increase the likelihood of sending a full-sized segment (section
4.2.3.4 of [RFC1122]). An application can disable the Nagle 4.2.3.4 of [RFC1122]). An application can disable the Nagle
algorithm for an individual connection. algorithm for an individual connection.
User Timeout Option: The User Timeout Option (UTO) [RFC5482] allows User Timeout Option: The User Timeout Option (UTO) [RFC5482] allows
skipping to change at page 9, line 30 skipping to change at page 9, line 30
The 'open' primitive can be handed optional Precedence or security/ The 'open' primitive can be handed optional Precedence or security/
compartment information [RFC0793], but this was not included here compartment information [RFC0793], but this was not included here
because it is mostly irrelevant today [RFC7414]. because it is mostly irrelevant today [RFC7414].
The 'Status' primitive was not included because the initial TCP The 'Status' primitive was not included because the initial TCP
specification describes this primitive as "implementation dependent" specification describes this primitive as "implementation dependent"
and states that it "could be excluded without adverse effect" and states that it "could be excluded without adverse effect"
[RFC0793]. Moreover, while a data block containing specific [RFC0793]. Moreover, while a data block containing specific
information is described, it is also stated that not all of this information is described, it is also stated that not all of this
information may always be available. While 'Status' SHOULD be information may always be available. While [RFC5925] states that
augmented to allow the MKTs of a current or pending connection to be 'Status' "SHOULD be augmented to allow the MKTs of a current or
read (for confirmation), the same information is also available via pending connection to be read (for confirmation)", the same
'Receive', which MUST be augmented with that functionality [RFC5925]. information is also available via 'Receive', which, following
The 'Send' primitive includes an optional 'push' flag which, if set, [RFC5925], "MUST be augmented" with that functionality. The 'Send'
requires data to be promptly transmitted to the receiver without primitive includes an optional 'push' flag which, if set, requires
delay [RFC0793]; the 'Receive' primitive described in can (under some data to be promptly transmitted to the receiver without delay
[RFC0793]; the 'Receive' primitive described in can (under some
conditions) yield the status of the 'push' flag. Because "push" conditions) yield the status of the 'push' flag. Because "push"
functionality is optional to implement for both the 'send' and functionality is optional to implement for both the 'send' and
'receive' primitives [RFC1122], this functionality is not included 'receive' primitives [RFC1122], this functionality is not included
here. The requirements for Internet hosts [RFC1122] also introduce here. The requirements for Internet hosts [RFC1122] also introduce
keep-alives to TCP, but these are optional to implement and hence not keep-alives to TCP, but these are optional to implement and hence not
considered here. The same document also describes that "some TCP considered here. The same document also describes that "some TCP
implementations have included a FLUSH call", indicating that this implementations have included a FLUSH call", indicating that this
call is also optional to implement. It is therefore not considered call is also optional to implement. It is therefore not considered
here. here.
3.2. Primitives Provided by MPTCP 3.2. Primitives Provided by MPTCP
Multipath TCP (MPTCP) is an extension to TCP that allows the use of Multipath TCP (MPTCP) is an extension to TCP that allows the use of
multiple paths for a single data-stream. It achieves this by multiple paths for a single data-stream. It achieves this by
creating different so-called TCP subflows for each of the interfaces creating different so-called TCP subflows for each of the interfaces
and scheduling the traffic across these TCP subflows. The service and scheduling the traffic across these TCP subflows. The service
provided by MPTCP is described as follows [RFC6182]: "Multipath TCP provided by MPTCP is described as follows in [RFC6182]: "Multipath
MUST follow the same service model as TCP [RFC0793]: in- order, TCP MUST follow the same service model as TCP [RFC0793]: in- order,
reliable, and byte-oriented delivery. Furthermore, a Multipath TCP reliable, and byte-oriented delivery. Furthermore, a Multipath TCP
connection SHOULD provide the application with no worse throughput or connection SHOULD provide the application with no worse throughput or
resilience than it would expect from running a single TCP connection resilience than it would expect from running a single TCP connection
over any one of its available paths." over any one of its available paths."
Further, there are some constraints on the API exposed by MPTCP Further, there are some constraints on the API exposed by MPTCP,
[RFC6182]: "A multipath-capable equivalent of TCP MUST retain some stated in [RFC6182]: "A multipath-capable equivalent of TCP MUST
level of backward compatibility with existing TCP APIs, so that retain some level of backward compatibility with existing TCP APIs,
existing applications can use the newer merely by upgrading the so that existing applications can use the newer merely by upgrading
operating systems of the end hosts." As such, the primitives the operating systems of the end hosts." As such, the primitives
provided by MPTCP are equivalent to the ones provided by TCP. provided by MPTCP are equivalent to the ones provided by TCP.
Nevertheless, the MPTCP RFCs [RFC6824] and [RFC6897] clarify some Nevertheless, the MPTCP RFCs [RFC6824] and [RFC6897] clarify some
parts of TCP's primitives with respect to MPTCP and add some parts of TCP's primitives with respect to MPTCP and add some
extensions for better control on MPTCP's subflows. Hereafter is a extensions for better control on MPTCP's subflows. Hereafter is a
list of the clarifications and extensions the above cited RFCs list of the clarifications and extensions the above cited RFCs
provide to TCP's primitives. provide to TCP's primitives.
Open: "An application should be able to request to turn on or turn Open: "An application should be able to request to turn on or turn
off the usage of MPTCP" [RFC6897]. This functionality can be off the usage of MPTCP" [RFC6897]. This functionality can be
provided through a socket-option called 'tcp_multipath_enable'. provided through a socket-option called 'tcp_multipath_enable'.
Further, MPTCP must be disabled in case the application is binding Further, MPTCP must be disabled in case the application is binding
to a specific address [RFC6897]. to a specific address [RFC6897].
Send/Receive: The sending and receiving of data does not require any Send/Receive: The sending and receiving of data does not require any
changes to the application when MPTCP is being used [RFC6824]. changes to the application when MPTCP is being used [RFC6824].
The MPTCP-layer will "take one input data stream from an The MPTCP-layer will "take one input data stream from an
application, and split it into one or more subflows, with application, and split it into one or more subflows, with
sufficient control information to allow it to be reassembled and sufficient control information to allow it to be reassembled and
delivered reliably and in order to the recipient application." delivered reliably and in order to the recipient application."
The use of the Urgent Pointer is special in MPTCP [RFC6824]: "a The use of the Urgent Pointer is special in MPTCP [RFC6824], which
TCP subflow MUST NOT use the Urgent Pointer to interrupt an states: "a TCP subflow MUST NOT use the Urgent Pointer to
existing mapping." interrupt an existing mapping."
Address and Subflow Management: MPTCP uses different addresses and Address and Subflow Management: MPTCP uses different addresses and
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 SCTP 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 delimiters; 2)
it does not provide in-order or reliable delivery unless the it does not provide in-order or reliable delivery unless the
application wants that; 3) multi-homing is supported. In SCTP, application wants that; 3) multi-homing is supported. In SCTP,
connections are called "associations" and they can be between not connections are called "associations" and they can be between 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 SCTP calls the specifies the interaction with the application (which SCTP calls 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
skipping to change at page 19, line 4 skipping to change at page 19, line 17
Congestion Control Protocol (DCCP), with appropriate extensions where Congestion Control Protocol (DCCP), with appropriate extensions where
necessary; and it can be used with proprietary application protocols, necessary; and it can be used with proprietary application protocols,
such as those built on top of UDP for peer-to- peer (P2P) such as those built on top of UDP for peer-to- peer (P2P)
applications." At the time of writing, the appropriate extensions applications." At the time of writing, the appropriate extensions
for TCP, SCTP or DCCP do not exist. for TCP, SCTP or DCCP do not exist.
A numer of configurable parameters exist in the LEDBAT specification: A numer of configurable parameters exist in the LEDBAT specification:
TARGET, which is the queuing delay target at which LEDBAT tries to TARGET, which is the queuing delay target at which LEDBAT tries to
operate, must be set to 100ms or less. 'allowed_increase' (should be operate, must be set to 100ms or less. 'allowed_increase' (should be
1, must be greater than 0) limits the speed at which LEDBAT increases 1, must be greater than 0) limits the speed at which LEDBAT increases
its rate. 'gain', which MUST be set to 1 or less to avoid a faster its rate. 'gain', which, according to [RFC6817], "MUST be set to 1 or
ramp-up than TCP Reno, determines how quickly the sender responds to less" to avoid a faster ramp-up than TCP Reno, determines how quickly
changes in queueing delay. Implementations may divide 'gain' into the sender responds to changes in queueing delay. Implementations
two parameters, one for increase and a possibly larger one for may divide 'gain' into two parameters, one for increase and a
decrease. We call these parameters 'Gain_Inc' and 'Gain_Dec' here. possibly larger one for decrease. We call these parameters
'Base_History' is the size of the list of measured base delays, and 'Gain_Inc' and 'Gain_Dec' here. 'Base_History' is the size of the
SHOULD be 10. This list can be filtered using a 'Filter' function list of measured base delays, and, according to [RFC6817], "SHOULD be
which is not prescribed [RFC6817], yielding a list of size 10". This list can be filtered using a 'Filter' function which is
'Current_Filter'. The initial and minimum congestion windows, not prescribed [RFC6817], yielding a list of size 'Current_Filter'.
'Init_CWND' and 'Min_CWND', should both be 2. The initial and minimum congestion windows, 'Init_CWND' and
'Min_CWND', should both be 2.
Regarding which of these parameters should be under control of an Regarding which of these parameters should be under control of an
application, the possible range goes from exposing nothing on the one application, the possible range goes from exposing nothing on the one
hand, to considering everything that is not prescribed with a MUST in hand, to considering everything that is not prescribed with a "MUST"
the specification as a parameter on the other hand. Function in the specification as a parameter on the other hand. Function
implementations are not provided as a parameter to any of the implementations are not provided as a parameter to any of the
transport protocols discussed here, and hence we do not regard the transport protocols discussed here, and hence we do not regard the
'Filter' function as a parameter. However, to avoid unnecessarily 'Filter' function as a parameter. However, to avoid unnecessarily
limiting future implementations, we consider all other parameters limiting future implementations, we consider all other parameters
above as tunable parameters that should be exposed. above as tunable parameters that should be exposed.
4. Pass 2 4. Pass 2
This pass categorizes the primitives from pass 1 based on whether This pass categorizes the primitives from pass 1 based on whether
they relate to a connection or to data transmission. Primitives are they relate to a connection or to data transmission. Primitives are
skipping to change at page 20, line 7 skipping to change at page 20, line 21
e.g., SCTP's 'Close' [RFC4960] returns success or failure, and lets e.g., SCTP's 'Close' [RFC4960] returns success or failure, and lets
the application control whether further receive or send operations or the application control whether further receive or send operations or
both are disabled [RFC6458]. This is not described in the same way both are disabled [RFC6458]. This is not described in the same way
for TCP [RFC0793], but these details play no significant role for the for TCP [RFC0793], but these details play no significant role for the
primitives provided by either TCP or SCTP (for the sake of being primitives provided by either TCP or SCTP (for the sake of being
generic, it could be assumed that both receive and send operations generic, it could be assumed that both receive and send operations
are disabled in both cases). are disabled in both cases).
The TCP 'Send' and 'Receive' primitives include usage of an 'urgent' The TCP 'Send' and 'Receive' primitives include usage of an 'urgent'
parameter. This parameter controls a mechanism that is required to parameter. This parameter controls a mechanism that is required to
implement the "synch signal" used by telnet [RFC0854], but SHOULD NOT implement the "synch signal" used by telnet [RFC0854], but [RFC6093]
be used by new applications [RFC6093]. Because pass 2 is meant as a states that "new applications SHOULD NOT employ the TCP urgent
basis for the creation of future systems, the "urgent" mechanism is mechanism". Because pass 2 is meant as a basis for the creation of
excluded. This also concerns the notification 'Urgent Pointer future systems, the "urgent" mechanism is excluded. This also
Advance' in the 'Error_Report' (section 4.2.4.1 of [RFC1122]). concerns the notification 'Urgent Pointer Advance' in the
'Error_Report' (section 4.2.4.1 of [RFC1122]).
Since LEDBAT is a congestion control mechanism and not a protocol, it Since LEDBAT is a congestion control mechanism and not a protocol, it
is not currently defined when to enable / disable or configure the is not currently defined when to enable / disable or configure the
mechanism. For instance, it could be a one-time choice upon mechanism. For instance, it could be a one-time choice upon
connection establishment or when listening for incoming connections, connection establishment or when listening for incoming connections,
in which case it should be categorized under CONNECTION.ESTABLISHMENT in which case it should be categorized under CONNECTION.ESTABLISHMENT
or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily
limiting future implementations, it was decided to place it under limiting future implementations, it was decided to place it under
CONNECTION.MAINTENANCE, with all parameters that are described in the CONNECTION.MAINTENANCE, with all parameters that are described in the
specification [RFC6817] made configurable. specification [RFC6817] made configurable.
skipping to change at page 35, line 37 skipping to change at page 42, line 28
(MKTs). In SCTP, this allows to specify which chunk types must (MKTs). In SCTP, this allows to specify which chunk types must
always be authenticated. DATA, ACK etc. are different 'chunks' in always be authenticated. DATA, ACK etc. are different 'chunks' in
SCTP; one or more chunks may be included in a single packet. SCTP; one or more chunks may be included in a single packet.
o Indicate an Adaptation Layer (via an adaptation code point) o Indicate an Adaptation Layer (via an adaptation code point)
Protocols: SCTP Protocols: SCTP
o Request to negotiate interleaving of user messages o Request to negotiate interleaving of user messages
Protocols: SCTP Protocols: SCTP
o Hand over a message to transfer (possibly multiple times) before o Hand over a message to reliably transfer (possibly multiple times)
connection establishment before connection establishment
Protocols: TCP Protocols: TCP
o Hand over a message to transfer during connection establishment o Hand over a message to reliably transfer during connection
establishment
Protocols: SCTP Protocols: SCTP
o Enable UDP encapsulation with a specified remote UDP port number o Enable UDP encapsulation with a specified remote UDP port number
Protocols: SCTP Protocols: SCTP
AVAILABILITY: AVAILABILITY:
Preparing to receive incoming connection requests. Preparing to receive incoming connection requests.
o Listen, 1 specified local interface o Listen, 1 specified local interface
Protocols: TCP, SCTP, UDP(-Lite) Protocols: TCP, SCTP, UDP(-Lite)
skipping to change at page 41, line 27 skipping to change at page 48, line 20
o Configurable Message Reliability o Configurable Message Reliability
Protocols: SCTP Protocols: SCTP
o Choice of stream o Choice of stream
Protocols: SCTP Protocols: SCTP
o Choice of path (destination address) o Choice of path (destination address)
Protocols: SCTP Protocols: SCTP
o Choice between unordered (potentially faster) or ordered delivery o Ordered message delivery (potentially slower than unordered)
of messages
Protocols: SCTP Protocols: SCTP
o Unordered message delivery (potentially faster than ordered)
Protocols: SCTP, UDP(-Lite)
o Request not to bundle messages o Request not to bundle messages
Protocols: SCTP Protocols: SCTP
o Specifying a "payload protocol-id" (handed over as such by the o Specifying a "payload protocol-id" (handed over as such by the
receiver) receiver)
Protocols: SCTP Protocols: SCTP
o Specifying a key id to be used to authenticate a message o Specifying a key id to be used to authenticate a message
Protocols: SCTP Protocols: SCTP
skipping to change at page 42, line 5 skipping to change at page 48, line 47
Protocols: SCTP Protocols: SCTP
5.2.2. Receiving Data 5.2.2. Receiving Data
All transport features in this section are provided by DATA.RECEIVE All transport features in this section are provided by DATA.RECEIVE
from pass 2. DATA.RECEIVE fills a buffer provided by the from pass 2. DATA.RECEIVE fills a buffer provided by the
application, with what we here call a "message" if the beginning and application, with what we here call a "message" if the beginning and
end of the data block can be identified at the receiver, and "data" end of the data block can be identified at the receiver, and "data"
otherwise. otherwise.
o Receive data (with no message delineation) o Receive data (with no message delimiting)
Protocols: TCP Protocols: TCP
o Receive a message o Receive a message
Protocols: SCTP, UDP(-Lite) Protocols: SCTP, UDP(-Lite)
o Choice of stream to receive from o Choice of stream to receive from
Protocols: SCTP Protocols: SCTP
o Information about partial message arrival o Information about partial message arrival
Protocols: SCTP Protocols: SCTP
skipping to change at page 42, line 47 skipping to change at page 49, line 44
6. Acknowledgements 6. Acknowledgements
The authors would like to thank (in alphabetical order) Bob Briscoe, The authors would like to thank (in alphabetical order) Bob Briscoe,
Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly,
Joe Touch and Brian Trammell for providing valuable feedback on this Joe Touch and Brian Trammell for providing valuable feedback on this
document. We especially thank Christoph Paasch for providing input document. We especially thank Christoph Paasch for providing input
related to Multipath TCP, and Gorry Fairhurst and Tom Jones for related to Multipath TCP, and Gorry Fairhurst and Tom Jones for
providing input related to UDP(-Lite). This work has received providing input related to UDP(-Lite). This work has received
funding from the European Union's Horizon 2020 research and funding from the European Union's Horizon 2020 research and
innovation programme under grant agreement No. 644334 (NEAT). The innovation programme under grant agreement No. 644334 (NEAT).
views expressed are solely those of the author(s).
7. IANA Considerations 7. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
Authentication, confidentiality protection, and integrity protection Authentication, confidentiality protection, and integrity protection
are identified as transport features [RFC8095]. As currently are identified as transport features [RFC8095]. These transport
deployed in the Internet, these transport features are generally features are generally provided by a protocol or layer on top of the
provided by a protocol or layer on top of the transport protocol; no transport protocol; none of the transport protocols considered in
current full-featured standards-track transport protocol provides this document provides these transport features on its own.
these transport features on its own. Therefore, these transport Therefore, these transport features are not considered in this
features are not considered in this document, with the exception of document, with the exception of native authentication capabilities of
native authentication capabilities of TCP and SCTP for which the TCP and SCTP for which the security considerations in [RFC5925] and
security considerations in [RFC5925] and [RFC4895] apply. [RFC4895] apply.
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
skipping to change at page 47, line 30 skipping to change at page 54, line 27
be helpful for future updates or extensions. be helpful for future updates or extensions.
This document is only concerned with transport features that are This document is only concerned with transport features that are
explicitly exposed to applications via primitives. It also strictly explicitly exposed to applications via primitives. It also strictly
follows RFC text: if a transport feature is truly relevant for an follows RFC text: if a transport feature is truly relevant for an
application, the RFCs should say so, and they should describe how to application, the RFCs should say so, and they should describe how to
use and configure it. Thus, the approach followed for developing use and configure it. Thus, the approach followed for developing
this document was to identify the right RFCs, then analyze and this document was to identify the right RFCs, then analyze and
process their text. process their text.
Primitives that MAY be implemented by a transport protocol were Primitives that "MAY" be implemented by a transport protocol were
excluded. To be included, the minimum requirement level for a excluded. To be included, the minimum requirement level for a
primitive to be implemented by a protocol was SHOULD. Where primitive to be implemented by a protocol was "SHOULD". Where
[RFC2119]-style requirements levels are not used, primitives were [RFC2119]-style requirements levels are not used, primitives were
excluded when they are described in conjunction with statements like, excluded when they are described in conjunction with statements like,
e.g.: "some implementations also provide" or "an implementation may e.g.: "some implementations also provide" or "an implementation may
also". Excluded primitives or parameters were briefly described in a also". Excluded primitives or parameters were briefly described in a
dedicated subsection. dedicated subsection.
Pass 1: This began by identifying text that talks about primitives. Pass 1: This began by identifying text that talks about primitives.
An API specification, abstract or not, obviously describes primitives An API specification, abstract or not, obviously describes primitives
-- but we are not *only* interested in API specifications. The text -- but we are not *only* interested in API specifications. The text
describing the 'send' primitive in the API specified in [RFC0793], describing the 'send' primitive in the API specified in [RFC0793],
skipping to change at page 49, line 19 skipping to change at page 56, line 17
Gorry Fairhurst; various other fixes. Appendices (TCP overview and Gorry Fairhurst; various other fixes. Appendices (TCP overview and
how-to-contribute) added. how-to-contribute) added.
-01: this now also covers MPTCP based on [RFC6182], [RFC6824] and -01: this now also covers MPTCP based on [RFC6182], [RFC6824] and
[RFC6897]. [RFC6897].
-02: included UDP, UDP-Lite, and all extensions of SCTPs. This -02: included UDP, UDP-Lite, and all extensions of SCTPs. This
includes fixing the [RFC6458] omission from -00. includes fixing the [RFC6458] omission from -00.
-03: wrote security considerations. The "how to contribute" section -03: wrote security considerations. The "how to contribute" section
was updated to reflect how the document WAS created, not how it was updated to reflect how the document *was* created, not how it
SHOULD BE created; it also no longer wrongly says that Experimental *should be* created; it also no longer wrongly says that Experimental
RFCs are excluded. Included LEDBAT. Changed abstract and intro to RFCs are excluded. Included LEDBAT. Changed abstract and intro to
reflect which protocols/mechanisms are covered (TCP, MPTCP, SCTP, reflect which protocols/mechanisms are covered (TCP, MPTCP, SCTP,
UDP, UDP-Lite, LEDBAT) instead of talking about "transport UDP, UDP-Lite, LEDBAT) instead of talking about "transport
protocols". Interleaving and stream scheduling added protocols". Interleaving and stream scheduling added
(draft-ietf-tsvwg-sctp-ndata). TFO added. "Set protocol parameters" (draft-ietf-tsvwg-sctp-ndata). TFO added. "Set protocol parameters"
in SCTP replaced with per-parameter (or parameter group) primitives. in SCTP replaced with per-parameter (or parameter group) primitives.
More primitives added, mostly previously overlooked ones from More primitives added, mostly previously overlooked ones from
[RFC6458]. Updated terminology (s/transport service feature/ [RFC6458]. Updated terminology (s/transport service feature/
transport feature) in line with an update of [RFC8095]. Made transport feature) in line with an update of [RFC8095]. Made
sequence of transport features / primitives more logical. Combined sequence of transport features / primitives more logical. Combined
skipping to change at page 50, line 7 skipping to change at page 57, line 5
updated to align with latest taps-transport-usage-udp ID. updated to align with latest taps-transport-usage-udp ID.
-06: addressed WGLC comments from Aaron Falk and Tommy Pauly. -06: addressed WGLC comments from Aaron Falk and Tommy Pauly.
-07: addressed AD review comments from Spencer Dawkins. -07: addressed AD review comments from Spencer Dawkins.
-08: removed "delivery number" which was based on an error in RFC -08: removed "delivery number" which was based on an error in RFC
4960: https://tools.ietf.org/html/ 4960: https://tools.ietf.org/html/
draft-ietf-tsvwg-rfc4960-errata-02#section-3.34. draft-ietf-tsvwg-rfc4960-errata-02#section-3.34.
-09: for consistency with the draft-ietf-taps-minset-00, adjusted the
following transport features in "pass 3": "Choice between unordered
(potentially faster) or ordered delivery of messages" divided into
two transport features (one for unordered, one for ordered); the word
"reliably" was added to the transport features "Hand over a message
to reliably transfer (possibly multiple times) before connection
establishment" and "Hand over a message to reliably transfer during
connection establishment". Fixed RFC2119-style language into
explicit citations (comment by Eric Rescorla and others). Addressed
editorial comments by Mirja Kuehlewind, Ben Campbell, Benoit Claise
and the Gen-ART reviewer Roni Even, except for moving terminology
section after the intro because the terminology is already used in
the intro text.
Authors' Addresses Authors' Addresses
Michael Welzl Michael Welzl
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
Oslo, N-0316 Oslo, N-0316
Norway Norway
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
 End of changes. 34 change blocks. 
105 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/