draft-ietf-taps-transports-usage-00.txt   draft-ietf-taps-transports-usage-01.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: July 11, 2016 Muenster Univ. of Appl. Sciences Expires: January 9, 2017 Muenster Univ. of Appl. Sciences
N. Khademi N. Khademi
University of Oslo University of Oslo
January 8, 2016 July 8, 2016
On the Usage of Transport Service Features Provided by IETF Transport On the Usage of Transport Service Features Provided by IETF Transport
Protocols Protocols
draft-ietf-taps-transports-usage-00 draft-ietf-taps-transports-usage-01
Abstract Abstract
This document describes how transport protocols expose services to This document describes how transport protocols expose services to
applications and how an application can configure and use the applications and how an application can configure and use the
features of a transport service. features of a transport service.
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 July 11, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . . 5 3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . 4
3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 7 3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 7
3.2. Primitives Provided by SCTP . . . . . . . . . . . . . . . 8 3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . 8
3.2.1. Excluded Primitives . . . . . . . . . . . . . . . . . 11 3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 9
4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Excluded Primitives . . . . . . . . . . . . . . . . . 12
4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 12 4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 16 4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 13
5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. DATA Transfer Related Primitives . . . . . . . . . . . . 19
5.1. CONNECTION Related Transport Service Features . . . . . . 18 5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. DATA Transfer Related Transport Service Features . . . . . 20 5.1. CONNECTION Related Transport Service Features . . . . . . 21
5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 20 5.2. DATA Transfer Related Transport Service Features . . . . 25
5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 25
5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 26
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix B. How to contribute . . . . . . . . . . . . . . . . . . 24 Appendix A. Overview of RFCs used as input for pass 1 . . . . . 29
Appendix C. Revision information . . . . . . . . . . . . . . . . 26 Appendix B. How to contribute . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix C. Revision information . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Terminology 1. Terminology
Transport Service Feature: a specific end-to-end feature that a Transport Service Feature: a specific end-to-end feature that a
transport service provides to its clients. Examples include transport service provides to its clients. Examples include
confidentiality, reliable delivery, ordered delivery, message- confidentiality, reliable delivery, ordered delivery, message-
versus-stream orientation, etc. versus-stream orientation, etc.
Transport Service: a set of transport service features, without an Transport Service: a set of transport service features, without an
association to any given framing protocol, which provides a association to any given framing protocol, which provides a
complete service to an application. complete service to an application.
skipping to change at page 8, line 22 skipping to change at page 8, line 14
receiver without delay; the 'receive' primitive described in receiver without delay; the 'receive' primitive described in
[RFC0793] can (under some conditions) yield the status of the PUSH [RFC0793] can (under some conditions) yield the status of the PUSH
flag. Because PUSH functionality is made optional to implement for flag. Because PUSH functionality is made optional to implement for
both the 'send' and 'receive' primitives in [RFC1122], this both the 'send' and 'receive' primitives in [RFC1122], this
functionality is not included here. [RFC1122] also introduces keep- functionality is not included here. [RFC1122] also introduces keep-
alives to TCP, but these are optional to implement and hence not alives to TCP, but these are optional to implement and hence not
considered here. [RFC1122] describes that "some TCP implementations considered here. [RFC1122] describes that "some TCP implementations
have included a FLUSH call", indicating that this call is also have included a FLUSH call", indicating that this call is also
optional to implement. It is therefore not considered here. optional to implement. It is therefore not considered here.
3.2. Primitives Provided by SCTP 3.2. Primitives Provided by MPTCP
Multipath TCP (MPTCP) is an extension to TCP that allows the use of
multiple paths for a single data-stream. It achieves this by
creating different so-called TCP subflows for each of the interfaces
and scheduling the traffic across these TCP subflows. The service
provided by MPTCP is described in [RFC6182] "Multipath TCP MUST
follow the same service model as TCP [RFC0793]: in- order, reliable,
and byte-oriented delivery. Furthermore, a Multipath TCP connection
SHOULD provide the application with no worse throughput or resilience
than it would expect from running a single TCP connection over any
one of its available paths."
Further, [RFC6182] states constraints on the API exposed by MPTCP: "A
multipath-capable equivalent of TCP MUST retain some level of
backward compatibility with existing TCP APIs, so that existing
applications can use the newer merely by upgrading the operating
systems of the end hosts." As such, the primitives provided by MPTCP
are equivalent to the ones provided by TCP. Nevertheless, [RFC6824]
and [RFC6897] clarify some parts of TCP's primitives with respect to
MPTCP and add some extensions for better control on MPTCP's subflows.
Hereafter is a list of the clarifications and extensions the above
cited RFCs provide to TCP's primitives.
open: [RFC6897] states "An application should be able to request to
turn on or turn off the usage of MPTCP.". The RFC states that
this functionality can be provided through a socket-option called
TCP_MULTIPATH_ENABLE. Further, [RFC6897] says that MPTCP must be
disabled in case the application is binding to a specific address.
send/receive: [RFC6824] states that the sending and receiving of
data does not require any changes to the application when MPTCP is
being used. The MPTCP-layer will "take one input data stream from
an application, and split it into one or more subflows, with
sufficient control information to allow it to be reassembled and
delivered reliably and in order to the recipient application."
The use of the Urgent-Pointer is special in MPTCP and [RFC6824]
says "a TCP subflow MUST NOT use the Urgent Pointer to interrupt
an existing mapping."
address and subflow management:: MPTCP uses different addresses and
allows a host to announce these addresses as part of the protocol.
[RFC6897] says "An application should be able to restrict MPTCP to
binding to a given set of addresses." and thus allows applications
to limit the set of addresses that are being used by MPTCP.
Further, "An application should be able to obtain information on
the pairs of addresses used by the MPTCP subflows.".
3.3. Primitives Provided by SCTP
Section 1.1 of [RFC4960] lists limitations of TCP that SCTP removes. Section 1.1 of [RFC4960] lists limitations of TCP that SCTP removes.
Three of the four mentioned limitations directly translate into a Three of the four mentioned limitations directly translate into a
transport service features that are visible to an application using transport service features that are visible to an application using
SCTP: 1) it allows for preservation of message delineations; 2) these SCTP: 1) it allows for preservation of message delineations; 2) these
messages, while reliably transferred, do not require to be in order messages, while reliably transferred, do not require to be in order
unless the application wants it; 3) multi-homing is supported. In unless the application wants it; 3) multi-homing is supported. In
SCTP, connections are called "association" and they can be between SCTP, connections are called "association" and they can be between
not only two (as in TCP) but multiple addresses at each endpoint. not only two (as in TCP) but multiple addresses at each endpoint.
skipping to change at page 10, line 36 skipping to change at page 11, line 36
user messages, this notification informs the application process user messages, this notification informs the application process
about the affected association, the type of event that has about the affected association, the type of event that has
occurred, the complete set of sockets of the peer, the maximum occurred, the complete set of sockets of the peer, the maximum
number of allowed streams and the inbound stream count (the number number of allowed streams and the inbound stream count (the number
of streams the peer endpoint has requested). of streams the peer endpoint has requested).
DATA ARRIVE notification: When a message is ready to be retrieved DATA ARRIVE notification: When a message is ready to be retrieved
via the Receive primitive, the application is informed by this via the Receive primitive, the application is informed by this
notification. notification.
SEND FAILURE notification / Receive Unsent Message / Receive SEND FAILURE notification / Receive Unsent Message
Unacknowledged Message: When a message cannot be delivered via an / Receive Unacknowledged Message:
association, the sender can be informed about it and learn whether When a message cannot be delivered via an association, the sender
the message has just not been acknowledged or (e.g. in case of can be informed about it and learn whether the message has just
lifetime expiry) if it has not even been sent. not been acknowledged or (e.g. in case of lifetime expiry) if it
has not even been sent.
NETWORK STATUS CHANGE notification: The NETWORK STATUS CHANGE NETWORK STATUS CHANGE notification: The NETWORK STATUS CHANGE
notification informs the application about a socket becoming notification informs the application about a socket becoming
active/inactive. active/inactive.
COMMUNICATION LOST notification: When SCTP loses communication to an COMMUNICATION LOST notification: When SCTP loses communication to an
endpoint (e.g. via Heartbeats or excessive retransmission) or endpoint (e.g. via Heartbeats or excessive retransmission) or
detects an abort, this notification informs the application detects an abort, this notification informs the application
process of the affected association and the type of event (failure process of the affected association and the type of event (failure
OR termination in response to a shutdown or abort request). OR termination in response to a shutdown or abort request).
SHUTDOWN COMPLETE notification: When SCTP completes the shutdown SHUTDOWN COMPLETE notification: When SCTP completes the shutdown
procedures, this notification is passed to the upper layer, procedures, this notification is passed to the upper layer,
informing it about the affected assocation. informing it about the affected assocation.
3.2.1. Excluded Primitives 3.3.1. Excluded Primitives
The 'Receive' primitive can return certain additional information, The 'Receive' primitive can return certain additional information,
but this is optional to implement and therefore not considered. With but this is optional to implement and therefore not considered. With
a COMMUNICATION LOST notification, some more information may a COMMUNICATION LOST notification, some more information may
optionally be passed to the application (e.g., identification to optionally be passed to the application (e.g., identification to
retrieve unsent and unacknowledged data). SCTP "can invoke" a retrieve unsent and unacknowledged data). SCTP "can invoke" a
COMMUNICATION ERROR notification and "may send" a RESTART COMMUNICATION ERROR notification and "may send" a RESTART
notification, making these two notifications optional to implement. notification, making these two notifications optional to implement.
The list provided under 'Status' includes "etc", indicating that more The list provided under 'Status' includes "etc", indicating that more
information could be provided. The primitive 'Get SRTT Report' information could be provided. The primitive 'Get SRTT Report'
skipping to change at page 11, line 33 skipping to change at page 12, line 39
in 'Set Protocol Parameters'. The 'Destroy SCTP Instance' API in 'Set Protocol Parameters'. The 'Destroy SCTP Instance' API
function was excluded: it erases the SCTP instance that was created function was excluded: it erases the SCTP instance that was created
by 'Initialize', but is not a Primitive as defined in this document by 'Initialize', but is not a Primitive as defined in this document
because it does not relate to a Transport Service Feature. because it does not relate to a Transport Service Feature.
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
presented following the nomenclature: presented following the nomenclature:
"CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". A connection is a "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be
general protocol-independent concept and refers to, e.g., TCP CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT,
connections (identifiable by a unique pair of IP addresses and TCP AVAILABILITY, MAINTENANCE and TERMINATION subcategories can be
port numbers) as well as SCTP associations (identifiable by multiple considered. The DATA category does not have any SUBCATEGORY (as of
IP address and port number pairs). now). A connection is a general protocol-independent concept and
refers to, e.g., TCP connections (identifiable by a unique pair of IP
addresses and TCP port numbers) as well as SCTP associations
(identifiable by multiple IP address and port number pairs).
Some minor details are omitted for the sake of generalization -- Some minor details are omitted for the sake of generalization --
e.g., SCTP's 'close' [RFC4960] returns success or failure, whereas e.g., SCTP's 'close' [RFC4960] returns success or failure, whereas
this is not described in the same way for TCP in [RFC0793], but this this is not described in the same way for TCP in [RFC0793], but this
detail plays no significant role for the primitives provided by detail plays no significant role for the primitives provided by
either TCP or SCTP. either TCP or SCTP.
The TCP 'send' and 'receive' primitives include usage of an "URGENT" The TCP 'send' and 'receive' primitives include usage of an "URGENT"
mechanism. This mechanism is required to implement the "synch mechanism. This mechanism is required to implement the "synch
signal" used by telnet [RFC0854], but SHOULD NOT be used by new signal" used by telnet [RFC0854], but SHOULD NOT be used by new
skipping to change at page 12, line 34 skipping to change at page 13, line 44
o CONNECT.SCTP: o CONNECT.SCTP:
Pass 1 primitive / event: 'initialize', followed by 'associate' Pass 1 primitive / event: 'initialize', followed by 'associate'
Parameters: list of local SCTP port number / IP address pairs Parameters: list of local SCTP port number / IP address pairs
(initialize); 1 socket; outbound stream count (initialize); 1 socket; outbound stream count
Returns: socket list Returns: socket list
Comments: 'initialize' needs to be called only once per list of Comments: 'initialize' needs to be called only once per list of
local SCTP port number / IP address pairs. One socket will local SCTP port number / IP address pairs. One socket will
automatically be chosen; it can later be changed in MAINTENANCE. automatically be chosen; it can later be changed in MAINTENANCE.
o Disable-MPTCP.MPTCP:
Pass 1 primitive / event: 'open' (active) or 'open' (passive)
Parameters: one boolean value
Comments: MPTCP is by default enabled on all TCP connections.
However, an application is still able to disable MPTCP for a
particular connection or socket prior to the CONNECT.TCP and
LISTEN.TCP primitives.
AVAILABILITY: AVAILABILITY:
Preparing to receive incoming connection requests. Preparing to receive incoming connection requests.
o LISTEN.TCP: o LISTEN.TCP:
Pass 1 primitive / event: 'open' (passive) Pass 1 primitive / event: 'open' (passive)
Parameters: 1 local IP address (optional); 1 socket (optional); Parameters: 1 local IP address (optional); 1 socket (optional);
timeout (optional) timeout (optional)
Comments: if the socket and/or local IP address is provided, this Comments: if the socket and/or local IP address is provided, this
waits for incoming connections from only and/or to only the waits for incoming connections from only and/or to only the
provided address. Else this waits for incoming connections provided address. Else this waits for incoming connections
skipping to change at page 15, line 6 skipping to change at page 17, line 5
Returns: data block with information about a specified Returns: data block with information about a specified
association, containing: association connection state; socket association, containing: association connection state; socket
list; destination transport address reachability states; current list; destination transport address reachability states; current
receiver window size; current congestion window sizes; number of receiver window size; current congestion window sizes; number of
unacknowledged DATA chunks; number of DATA chunks pending receipt; unacknowledged DATA chunks; number of DATA chunks pending receipt;
primary path; most recent SRTT on primary path; RTO on primary primary path; most recent SRTT on primary path; RTO on primary
path; SRTT and RTO on other destination addresses. The NETWORK path; SRTT and RTO on other destination addresses. The NETWORK
STATUS CHANGE notification informs the application about a socket STATUS CHANGE notification informs the application about a socket
becoming active/inactive. becoming active/inactive.
o STATUS.MPTCP:
Pass 1 primitive / event: not specified
Returns: list of pairs of tuples of IP address and TCP port number
of each subflow. The first of the pair is the local IP and port
number, while the second is the remote IP and port number.
o CHANGE-DSCP.TCP: o CHANGE-DSCP.TCP:
Pass 1 primitive / event: not specified Pass 1 primitive / event: not specified
Parameters: DSCP value Parameters: DSCP value
Comments: This allows an application to change the DSCP value. Comments: this allows an application to change the DSCP value.
For TCP this was originally specified for the TOS field [RFC1122], For TCP this was originally specified for the TOS field [RFC1122],
which is here interpreted to refer to the DSField [RFC3260]. which is here interpreted to refer to the DSField [RFC3260].
o ADD_SUBFLOW.MPTCP:
Pass 1 primitive / event: not specified
Parameters: local IP address and optionally the local port number
Comments: the application specifies the local IP address and port
number that must be used for a new subflow.
o REM_SUBFLOW.MPTCP:
Pass 1 primitive / event: not specified
Parameters: local IP address, local port number, remote IP
address, remote port number
Comments: the application removes the subflow specified by the IP/
port-pair. The MPTCP implementation must trigger a removal of the
subflow that belongs to this IP/port-pair.
TERMINATION: TERMINATION:
Gracefully or forcefully closing a connection, or being informed Gracefully or forcefully closing a connection, or being informed
about this event happening. about this event happening.
o CLOSE.TCP: o CLOSE.TCP:
Pass 1 primitive / event: 'close' Pass 1 primitive / event: 'close'
Comments: this terminates the sending side of a connection after Comments: this terminates the sending side of a connection after
reliably delivering all remaining data. reliably delivering all remaining data.
o CLOSE.SCTP: o CLOSE.SCTP:
skipping to change at page 18, line 23 skipping to change at page 21, line 33
service feature of UDP; however, since it would be strange to call service feature of UDP; however, since it would be strange to call
the lack of congestion control a feature, the natural outcome is then the lack of congestion control a feature, the natural outcome is then
to list "congestion control" as a feature of TCP and SCTP.] to list "congestion control" as a feature of TCP and SCTP.]
5.1. CONNECTION Related Transport Service Features 5.1. CONNECTION Related Transport Service Features
ESTABLISHMENT: ESTABLISHMENT:
Active creation of a connection from one transport endpoint to one or Active creation of a connection from one transport endpoint to one or
more transport endpoints. more transport endpoints.
o Connect
Protocols: TCP, SCTP
o Specify IP Options o Specify IP Options
Protocols: TCP Protocols: TCP
o Request multiple streams o Request multiple streams
Protocols: SCTP Protocols: SCTP
o Obtain multiple sockets o Obtain multiple sockets
Protocols: SCTP Protocols: SCTP
o Disable MPTCP
Protocols: MPTCP/TCP
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 Protocols: TCP, SCTP
o Listen, N specified local interfaces o Listen, N specified local interfaces
Protocols: SCTP Protocols: SCTP
o Listen, all local interfaces (unspecified) o Listen, all local interfaces
Protocols: TCP, SCTP Protocols: TCP, SCTP
o Obtain requested number of streams o Obtain requested number of streams
Protocols: SCTP Protocols: SCTP
MAINTENANCE: MAINTENANCE:
Adjustments made to an open connection, or notifications about it. Adjustments made to an open connection, or notifications about it.
NOTE: all features except "set primary path" in this category apply NOTE: all features except "set primary path" in this category apply
to one out of multiple possible paths (identified via sockets) in to one out of multiple possible paths (identified via sockets) in
SCTP, whereas TCP uses only one path (one socket). SCTP, whereas TCP uses only one path (one socket).
skipping to change at page 19, line 40 skipping to change at page 23, line 30
be a common feature for them called "adjust RTO calculation". be a common feature for them called "adjust RTO calculation".
o Notification of Excessive Retransmissions (early warning below o Notification of Excessive Retransmissions (early warning below
abortion threshold) abortion threshold)
Protocols: TCP Protocols: TCP
o Notification of ICMP error message arrival o Notification of ICMP error message arrival
Protocols: TCP Protocols: TCP
o Status (query or notification) o Status (query or notification)
Protocols: SCTP Protocols: SCTP, MPTCP
SCTP parameters: association connection state; socket list; socket SCTP parameters: association connection state; socket list; socket
reachability states; current receiver window size; current reachability states; current receiver window size; current
congestion window sizes; number of unacknowledged DATA chunks; congestion window sizes; number of unacknowledged DATA chunks;
number of DATA chunks pending receipt; primary path; most recent number of DATA chunks pending receipt; primary path; most recent
SRTT on primary path; RTO on primary path; SRTT and RTO on other SRTT on primary path; RTO on primary path; SRTT and RTO on other
destination addresses; socket becoming active / inactive destination addresses; socket becoming active / inactive
MPTCP parameters: subflow-list (identified by source-IP; source-
Port; destination-IP; destination-Port)
o Set primary path o Set primary path
Protocols: SCTP Protocols: SCTP
o Change DSCP o Change DSCP
Protocols: TCP Protocols: TCP
Comments: This is described to be changeable for SCTP too in Comments: This is described to be changeable for SCTP too in
[RFC6458]. [RFC6458].
o Add subflow
Protocols: MPTCP
MPTCP Parameters: source-IP; source-Port; destination-IP;
destination-Port
o Remove subflow
Protocols: MPTCP
MPTCP Parameters: source-IP; source-Port; destination-IP;
destination-Port
TERMINATION: TERMINATION:
Gracefully or forcefully closing a connection, or being informed Gracefully or forcefully closing a connection, or being informed
about this event happening. about this event happening.
o Close after reliably delivering all remaining data, causing an o Close after reliably delivering all remaining data, causing an
event informing the application on the other side event informing the application on the other side
Protocols: TCP, SCTP Protocols: TCP, SCTP
Comments: A TCP endpoint locally only closes the connection for Comments: A TCP endpoint locally only closes the connection for
sending; it may still receive data afterwards. sending; it may still receive data afterwards.
skipping to change at page 21, line 5 skipping to change at page 25, line 26
5.2.1. Sending Data 5.2.1. Sending Data
All features in this section are provided by DATA.SEND from pass 2. All features in this section are provided by DATA.SEND from pass 2.
DATA.SEND is given a data block from the application, which we here DATA.SEND is given a data block from the application, which we here
call a "message". call a "message".
o Reliably transfer data o Reliably transfer data
Protocols: TCP, SCTP Protocols: TCP, SCTP
o Notifying the receiver to promptly hand over data to application
Protocols: TCP
Comments: This seems unnecessary in SCTP, where data arrival
causes an event for the application.
o Message identification o Message identification
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 Message lifetime o Message lifetime
Protocols: SCTP Protocols: SCTP
o Choice between unordered (potentially faster) or ordered delivery o Choice between unordered (potentially faster) or ordered delivery
of messages
Protocols: SCTP Protocols: SCTP
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
5.2.2. Receiving Data 5.2.2. Receiving Data
skipping to change at page 22, line 26 skipping to change at page 27, line 20
o Notification of unsent messages o Notification of unsent messages
Protocols: SCTP Protocols: SCTP
o Notification of unacknowledged messages o Notification of unacknowledged messages
Protocols: SCTP Protocols: SCTP
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,
David Hayes, Gorry Fairhurst, Karen Nielsen and Joe Touch for David Hayes, Gorry Fairhurst, Karen Nielsen and Joe Touch for
providing valuable feedback on this document. This work has received providing valuable feedback on this document. Special thanks goes
funding from the European Union's Horizon 2020 research and also to Christoph Paasch for providing input related to Multipath
innovation programme under grant agreement No. 644334 (NEAT). The TCP. This work has received funding from the European Union's
views expressed are solely those of the author(s). Horizon 2020 research and innovation programme under grant agreement
No. 644334 (NEAT). The views expressed are solely those of the
author(s).
7. IANA Considerations 7. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX 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
Security will be considered in future versions of this document. Security will be considered in future versions of this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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>. <http://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,
RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
[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>. <http://www.rfc-editor.org/info/rfc5482>.
9.2. Informative References 9.2. Informative References
[FA15] Fairhurst, Ed., G., Trammell, Ed., B., and M. Kuehlewind, [FA15] Fairhurst, Ed., G., Trammell, Ed., B., and M. Kuehlewind,
Ed., "Services provided by IETF transport protocols and Ed., "Services provided by IETF transport protocols and
congestion control mechanisms", congestion control mechanisms", Internet-draft draft-
draft-fairhurst-taps-transports-08.txt (work in progress), fairhurst-taps-transports-08.txt, December 2015.
December 2015.
[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
May 1983, <http://www.rfc-editor.org/info/rfc854>. 1983, <http://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,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <http://www.rfc-editor.org/info/rfc3168>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<http://www.rfc-editor.org/info/rfc3260>. <http://www.rfc-editor.org/info/rfc3260>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
and G. Fairhurst, Ed., "The Lightweight User Datagram and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
July 2004, <http://www.rfc-editor.org/info/rfc3828>. 2004, <http://www.rfc-editor.org/info/rfc3828>.
[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>. <http://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, <http://www.rfc-editor.org/info/rfc6093>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<http://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,
RFC6458, December 2011, DOI 10.17487/RFC6458, December 2011,
<http://www.rfc-editor.org/info/rfc6458>. <http://www.rfc-editor.org/info/rfc6458>.
[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,
<http://www.rfc-editor.org/info/rfc6824>.
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
March 2013, <http://www.rfc-editor.org/info/rfc6897>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, DOI 10.17487/ (TCP) Specification Documents", RFC 7414,
RFC7414, February 2015, DOI 10.17487/RFC7414, February 2015,
<http://www.rfc-editor.org/info/rfc7414>. <http://www.rfc-editor.org/info/rfc7414>.
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] TCP: [RFC0793], [RFC1122], [RFC5482]
MPTCP: [RFC6182], [RFC6824], [RFC6897]
SCTP: [RFC4960], planned: [RFC6458] SCTP: [RFC4960], planned: [RFC6458]
Appendix B. How to contribute Appendix B. How to contribute
This document is only concerned with transport service features that This document is only concerned with transport service features that
are explicitly exposed to applications via primitives. It also are explicitly exposed to applications via primitives. It also
strictly follows RFC text: if a feature is truly relevant for an strictly follows RFC text: if a feature is truly relevant for an
application, the RFCs better say so and in some way describe how to application, the RFCs better say so and in some way describe how to
use and configure it. Thus, the approach to follow for contributing use and configure it. Thus, the approach to follow for contributing
to this document is to identify the right RFCs, then analyze and to this document is to identify the right RFCs, then analyze and
skipping to change at page 26, line 30 skipping to change at page 31, line 42
-00 (from draft-welzl-taps-transports): this now covers TCP based on -00 (from draft-welzl-taps-transports): this now covers TCP based on
all TCP RFCs (this means: if you know of something in any TCP RFC all TCP RFCs (this means: if you know of something in any TCP RFC
that you think should be addressed, please speak up!) as well as that you think should be addressed, please speak up!) as well as
SCTP, exclusively based on [RFC4960]. We decided to also incorporate SCTP, exclusively based on [RFC4960]. We decided to also incorporate
[RFC6458] for SCTP, but this hasn't happened yet. Terminology made [RFC6458] for SCTP, but this hasn't happened yet. Terminology made
in line with [FA15]. Addressed comments by Karen Nielsen and Gorry in line with [FA15]. Addressed comments by Karen Nielsen and Gorry
Fairhurst; various other fixes. Appendices (TCP overview and how-to- Fairhurst; various other fixes. Appendices (TCP overview and how-to-
contribute) added. contribute) added.
-01: this now also covers MPTCP based on [RFC6182], [RFC6824] and
[RFC6897].
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
Phone: +47 22 85 24 20 Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
Steinfurt 48565 Steinfurt 48565
Germany Germany
skipping to change at page 27, line 4 skipping to change at page 32, line 23
Phone: +47 22 85 24 20 Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
Steinfurt 48565 Steinfurt 48565
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Naeem Khademi Naeem Khademi
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
Oslo, N-0316 Oslo N-0316
Norway Norway
Email: naeemk@ifi.uio.no Email: naeemk@ifi.uio.no
 End of changes. 37 change blocks. 
72 lines changed or deleted 187 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/