A Minimal Set of Transport Services for TAPS Systems
draft-gjessing-taps-minset-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Stein Gjessing , Michael Welzl | ||
| Last updated | 2016-10-31 | ||
| Replaced by | draft-ietf-taps-minset, draft-ietf-taps-minset, RFC 8923 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gjessing-taps-minset-03
TAPS S. Gjessing
Internet-Draft M. Welzl
Intended status: Informational University of Oslo
Expires: May 4, 2017 October 31, 2016
A Minimal Set of Transport Services for TAPS Systems
draft-gjessing-taps-minset-03
Abstract
This draft recommends a minimal set of IETF Transport Services
offered by end systems supporting TAPS, and gives guidance on
choosing among the available mechanisms and protocols. It is based
on the set of transport services given in the TAPS document draft-
ietf-taps-transports-usage-02.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gjessing & Welzl Expires May 4, 2017 [Page 1]
Internet-Draft Minimal TAPS Transport Services October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Superset of Transport Service Features . . . . . . . . . 5
3.1. CONNECTION Related Transport Service Features . . . . . . 5
3.2. DATA Transfer Related Transport Service Features . . . . 15
3.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 15
3.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 17
3.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 18
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Revision information . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
An application has an intended usage and demands for transport
services, and the task of any system that implements TAPS is to offer
these services to its applications, i.e. the applications running on
top of TAPS, without binding an application to a particular transport
protocol.
The present draft is based on [TAPS1] and [TAPS2] and follows the
same terminology (also listed below). The purpose of these two
drafts is, according to the TAPS charter, to "Define a set of
Transport Services, identifying the services provided by existing
IETF protocols and congestion control mechanisms." This is item 1 in
the list of working group tasks. Also according to the TAPS charter,
the working group will then "Specify the subset of those Transport
Services, as identified in item 1, that end systems supporting TAPS
will provide, and give guidance on choosing among available
mechanisms and protocols. Note that not all the capabilities of IETF
Transport protocols need to be exposed as Transport Services." Hence
it is necessary to minimize the number of services that are offered.
We begin this by grouping the transport service features.
Following [TAPS2], we divide the transport service features into two
main groups as follows:
1. CONNECTION related transport service features
- ESTABLISHMENT
- AVAILABILITY
- MAINTENANCE
Gjessing & Welzl Expires May 4, 2017 [Page 2]
Internet-Draft Minimal TAPS Transport Services October 2016
- TERMINATION
2. DATA Transfer Related transport service features
- Sending Data
- Receiving Data
- Errors
Because QoS is out of scope of TAPS, this document assumes a "best
effort" service model [RFC5290], [RFC7305]. Applications using a
TAPS system can therefore not make any assumptions about e.g. the
time it will take to send a message. It also assumes that TAPS
applications have no specific requirements that need knowledge about
the network, e.g. regarding the choice of network interface or the
end-to-end path. Even with these assumptions, there are certain
requirements that are strictly kept by transport protocols today, and
these must also be kept by a TAPS system. Some of these requirements
relate to transport service features that we call "Functional".
Functional transport service features provide functionality that
cannot be used without the application knowing about them, or else
they violate assumptions that might cause the application to fail.
For example, unordered message delivery is a functional transport
service feature: it cannot be used without the application knowing
about it because the application's assumption could be that messages
arrive in order. Failure includes any change of the application
behavior that is not performance oriented, e.g. security.
"Change DSCP" and "Disable Nagle algorithm" are what we call
"Optimizing" transport service features: if a TAPS system
autonomously decides to enable or disable them, an application will
not fail, but a TAPS system may be able to communicate more
efficiently if the application is in control of this optimizing
transport service feature. "Change DSCP" and "Disable Nagle
algorithm" are examples of transport service features that require
application-specific knowledge (about delay/bandwidth requirements
and the length of future data blocks that are to be transmitted,
respectively).
To summarize, transport service features that this memo recommends to
offer to applications are divided into two groups as follows:
o Functional
This transport service feature has to be specified by the
application, since if not, it cannot be used or the application
may fail (e.g. crash or be less secure).
o Optimizing
Gjessing & Welzl Expires May 4, 2017 [Page 3]
Internet-Draft Minimal TAPS Transport Services October 2016
This transport service feature may be specified by the
application, and when specified can optimize the performance.
The transport service features of IETF transport protocols that are
not exposed to the TAPS user because they include functionality that
could be transparently utilized by a TAPS system are called
"Automatable".
Finally, some transport service features are aggregated or slightly
changed in the TAPS API. These transport service features are marked
as "ADDED". The corresponding transport service feature(s) is/are
automatable, and they are listed immediately below the "ADDED"
transport service feature.
This document also sketches how some of the TAPS transport services
can be implemented. Wherever it is not obvious how to implement a
service via TCP or UDP, a brief discussion is included. IETF
transport services are presented following the nomenclature
"CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL". The PROTOCOL name
"UDP(-Lite)" is used when transport service features are equivalent
for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both TCP and
MPTCP.
2. Terminology
The following terms are used throughout this document, and in
subsequent documents produced by TAPS that describe the composition
and decomposition of transport services.
Transport Service Feature: a specific end-to-end feature that the
transport layer provides to an application. Examples include
confidentiality, reliable delivery, ordered delivery, message-
versus-stream orientation, etc.
Transport Service: a set of Transport Features, without an
association to any given framing protocol, which provides a
complete service to an application.
Transport Protocol: an implementation that provides one or more
different transport services using a specific framing and header
format on the wire.
Transport Service Instance: an arrangement of transport protocols
with a selected set of features and configuration parameters that
implements a single transport service, e.g., a protocol stack (RTP
over UDP).
Application: an entity that uses the transport layer for end-to-end
delivery data across the network (this may also be an upper layer
protocol or tunnel encapsulation).
Application-specific knowledge: knowledge that only applications
have.
Gjessing & Welzl Expires May 4, 2017 [Page 4]
Internet-Draft Minimal TAPS Transport Services October 2016
Endpoint: an entity that communicates with one or more other
endpoints using a transport protocol.
Connection: shared state of two or more endpoints that persists
across messages that are transmitted between these endpoints.
Socket: the combination of a destination IP address and a
destination port number.
3. The Superset of Transport Service Features
This section is based on the classification of the transport service
features in pass 3 of [TAPS2]. For every transport service feature,
a brief explanation of the classification is provided. Some more
general decisions affect multiple transport service features (e.g.
the decision that multi-streaming is automatable); the rationale for
such decisions is provided in Section 4.
3.1. CONNECTION Related Transport Service Features
ESTABLISHMENT:
o Connect
Protocols: TCP, SCTP, UDP(-Lite)
Functional because the notion of a connection is often reflected
in applications as an expectation to be able to communicate after
a "Connect" succeeded, with a communication sequence relating to
this transport service feature that is defined by the application
protocol.
Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(-
Lite).
o Specify which IP Options must always be used
Protocols: TCP
Automatable because IP Options relate to knowledge about the
network, not the application.
o Request multiple streams
Protocols: SCTP
Automatable because using multi-streaming does not require
application-specific knowledge.
Implementation: see Section 4.
o Obtain multiple sockets
Protocols: SCTP
Gjessing & Welzl Expires May 4, 2017 [Page 5]
Internet-Draft Minimal TAPS Transport Services October 2016
Automatable because the usage of multiple paths to communicate to
the same end host relates to knowledge about the network, not the
application.
Implementation: see Section 4.
o Disable MPTCP
Protocols: MPTCP
Automatable because the usage of multiple paths to communicate to
the same end host relates to knowledge about the network, not the
application.
o Specify which chunk types must always be authenticated
Protocols: SCTP
Optimizing because a TAPS system could always authenticate all
chunk types; knowing which chunk types an application does not
care to have authenticated can then improve the performance.
o Indicate an Adaptation Layer (via an adaptation code point)
Protocols: SCTP
Functional because it allows to send extra data for the sake of
identifying an adaptation layer, which by itself is application-
specific.
AVAILABILITY:
o Listen
Protocols: TCP, SCTP, UDP(-Lite)
Functional because the notion of accepting connection requests is
often reflected in applications as an expectation to be able to
communicate after a "Listen" succeeded, with a communication
sequence relating to this transport service feature that is
defined by the application protocol.
ADDED. This differs from the 3 automatable transport service
features below in that it leaves the choice of interfaces for
listening open.
Implementation: by listening on all interfaces via LISTEN.TCP (not
providing a local IP address) or LISTEN.SCTP (providing SCTP port
number / address pairs for all local IP addresses).
o Listen, 1 specified local interface
Gjessing & Welzl Expires May 4, 2017 [Page 6]
Internet-Draft Minimal TAPS Transport Services October 2016
Protocols: TCP, SCTP, UDP(-Lite)
Automatable because decisions about local interfaces relate to
knowledge about the network and the Operating System, not the
application.
o Listen, N specified local interfaces
Protocols: SCTP, UDP(-Lite)
Automatable because decisions about local interfaces relate to
knowledge about the network and the Operating System, not the
application.
o Listen, all local interfaces
Protocols: TCP, SCTP, UDP(-Lite)
Automatable because decisions about local interfaces relate to
knowledge about the network and the Operating System, not the
application.
o Specify which IP Options must always be used
Protocols: TCP
Automatable because IP Options relate to knowledge about the
network, not the application.
o Disable MPTCP
Protocols: MPTCP
Automatable because the usage of multiple paths to communicate to
the same end host relates to knowledge about the network, not the
application.
o Specify which chunk types must always be authenticated
Protocols: SCTP
Optimizing because a TAPS system could always authenticate all
chunk types; knowing which chunk types an application does not
care to have authenticated can then improve the performance.
o Obtain requested number of streams
Protocols: SCTP
Gjessing & Welzl Expires May 4, 2017 [Page 7]
Internet-Draft Minimal TAPS Transport Services October 2016
Automatable because using multi-streaming does not require
application-specific knowledge.
Implementation: see Section 4.
o Indicate an Adaptation Layer (via an adaptation code point)
Protocols: SCTP
Functional because it allows to send extra data for the sake of
identifying an adaptation layer, which by itself is application-
specific.
MAINTENANCE:
o Change timeout for aborting connection (using retransmit limit or
time value)
Protocols: TCP, SCTP
Functional because this is closely related to potentially assumed
reliable data delivery.
Implementation: via CHANGE-TIMEOUT.TCP or CHANGE-TIMEOUT.SCTP.
o Control advertising timeout for aborting connection to remote
endpoint
Protocols: TCP
Functional because this is closely related to potentially assumed
reliable data delivery.
o Disable Nagle algorithm
Protocols: TCP, SCTP
Optimizing because this decision depends on knowledge about the
size of future data blocks and the delay between them.
Implementation: via DISABLE-NAGLE.TCP and [**Not yet included in
[TAPS2] FOR SCTP**].
o Request an immediate heartbeat, returning success/failure
Protocols: SCTP
Automatable because this informs about network-specific knowledge.
Gjessing & Welzl Expires May 4, 2017 [Page 8]
Internet-Draft Minimal TAPS Transport Services October 2016
o Set protocol parameters
Protocols: SCTP
SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst;
RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans;
Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst;
PotentiallyFailed.Max.Retrans; Primary.Switchover.Max.Retrans;
Remote.UDPEncapsPort
Automatable because these parameters relate to knowledge about the
network, not the application.
o Notification of Excessive Retransmissions (early warning below
abortion threshold)
Protocols: TCP
Optimizing because it is an early warning to the application,
informing it of an impending functional event.
Implementation: via ERROR.TCP.
o Notification of ICMP error message arrival
Protocols: TCP, UDP(-Lite)
Optimizing because these messages can inform about success or
failure of functional transport service features (e.g., host
unreachable relates to "Connect")
Implementation: via ERROR.TCP.
o Status (query or notification)
Protocols: SCTP, MPTCP
SCTP parameters: association connection state; socket list; socket
reachability states; current receiver window size; current
congestion window sizes; number of unacknowledged DATA chunks;
number of DATA chunks pending receipt; primary path; most recent
SRTT on primary path; RTO on primary path; SRTT and RTO on other
destination addresses; socket becoming active / inactive
MPTCP parameters: subflow-list (identified by source-IP; source-
Port; destination-IP; destination-Port)
Automatable because these parameters relate to knowledge about the
network, not the application.
o Change authentication parameters
Protocols: SCTP
Gjessing & Welzl Expires May 4, 2017 [Page 9]
Internet-Draft Minimal TAPS Transport Services October 2016
Optimizing because a TAPS system could always authenticate all
chunk types; changing this behavior can then improve the
performance.
o Obtain authentication information
Protocols: SCTP
Functional because authentication decisions may have been made by
the peer, and this has an influence on the necessary application-
level measures to provide a certain level of security.
o Set primary path
Protocols: SCTP
Automatable because it requires using multiple sockets, but
obtaining multiple sockets in the CONNECTION.ESTABLISHMENT
category is automatable.
Implementation: see Section 4.
o Specify DSCP field
Protocols: TCP, SCTP
Optimizing because choosing a suitable DSCP value requires
application-specific knowledge.
Implementation: via CHANGE-DSCP.TCP and [**Not yet included in
[TAPS2] FOR SCTP**]
o Reset Stream
Protocols: SCTP
Automatable because using multi-streaming does not require
application-specific knowledge.
Implementation: see Section 4.
o Notification of Stream Reset
Protocols: STCP
Automatable because using multi-streaming does not require
application-specific knowledge.
Implementation: see Section 4.
o Reset Association
Protocols: SCTP
Gjessing & Welzl Expires May 4, 2017 [Page 10]
Internet-Draft Minimal TAPS Transport Services October 2016
Functional because it affects "Obtain a message delivery number",
which is functional.
o Notification of Association Reset
Protocols: STCP
Functional because it affects "Obtain a message delivery number",
which is functional.
o Add Streams
Protocols: SCTP
Automatable because using multi-streaming does not require
application-specific knowledge.
Implementation: see Section 4.
o Notification of Added Stream
Protocols: STCP
Automatable because using multi-streaming does not require
application-specific knowledge.
Implementation: see Section 4.
o Set peer primary path
Protocols: SCTP
Automatable because decisions about local interfaces relate to
knowledge about the network and the Operating System, not the
application.
o Add subflow
Protocols: MPTCP
MPTCP Parameters: source-IP; source-Port; destination-IP;
destination-Port
Automatable because the usage of multiple paths to communicate to
the same end host relates to knowledge about the network, not the
application.
o Remove subflow
Protocols: MPTCP
MPTCP Parameters: source-IP; source-Port; destination-IP;
destination-Port
Gjessing & Welzl Expires May 4, 2017 [Page 11]
Internet-Draft Minimal TAPS Transport Services October 2016
Automatable because the usage of multiple paths to communicate to
the same end host relates to knowledge about the network, not the
application.
o Add local address
Protocols: SCTP
Automatable because decisions about local interfaces relate to
knowledge about the network and the Operating System, not the
application.
o Remove local address
Protocols: SCTP
Automatable because decisions about local interfaces relate to
knowledge about the network and the Operating System, not the
application.
o Disable checksum when sending
Protocols: UDP
Functional because application-specific knowledge is necessary to
decide whether it can be acceptable to lose data integrity.
o Disable checksum requirement when receiving
Protocols: UDP
Functional because application-specific knowledge is necessary to
decide whether it can be acceptable to lose data integrity.
o Specify checksum coverage used by the sender
Protocols: UDP-Lite
Functional because application-specific knowledge is necessary to
decide for which parts of the data it can be acceptable to lose
data integrity.
o Specify minimum checksum coverage required by receiver
Protocols: UDP-Lite
Gjessing & Welzl Expires May 4, 2017 [Page 12]
Internet-Draft Minimal TAPS Transport Services October 2016
Functional because application-specific knowledge is necessary to
decide for which parts of the data it can be acceptable to lose
data integrity.
o Specify DF field
Protocols: UDP(-Lite)
Optimizing because the DF field can be used to carry out Path MTU
Discovery, which can lead an application to choose message sizes
that can be transmitted more efficiently.
Implementation: via MAINTENANCE.SET_DF and SEND_FAILURE.UDP(-Lite)
o Specify TTL/Hop count field
Protocols: UDP(-Lite)
Automatable because a TAPS system can use a large enough system
default to avoid communication failures. Allowing an application
to configure it differently can produce notifications of ICMP
error message arrivals that yield information which only relates
to knowledge about the network, not the application.
o Obtain TTL/Hop count field
Protocols: UDP(-Lite)
Automatable because the TTL/Hop count field relates to knowledge
about the network, not the application.
o Specify ECN field
Protocols: UDP(-Lite)
Automatable because the ECN field relates to knowledge about the
network, not the application.
o Obtain ECN field
Protocols: UDP(-Lite)
Automatable because the ECN field relates to knowledge about the
network, not the application.
o Specify IP Options
Protocols: UDP(-Lite)
Gjessing & Welzl Expires May 4, 2017 [Page 13]
Internet-Draft Minimal TAPS Transport Services October 2016
Automatable because IP Options relate to knowledge about the
network, not the application.
o Obtain IP Options
Protocols: UDP(-Lite)
Automatable because IP Options relate to knowledge about the
network, not the application.
TERMINATION:
o Close after reliably delivering all remaining data, causing an
event informing the application on the other side
Protocols: TCP, SCTP
Functional because the notion of a connection is often reflected
in applications as an expectation to have all outstanding data
delivered and no longer be able to communicate after a "Close"
succeeded, with a communication sequence relating to this
transport service feature that is defined by the application
protocol.
Implementation: via CLOSE.TCP and CLOSE.SCTP.
o Abort without delivering remaining data, causing an event
informing the application on the other side
Protocols: TCP, SCTP
Functional because the notion of a connection is often reflected
in applications as an expectation to potentially not have all
outstanding data delivered and no longer be able to communicate
after an "Abort" succeeded, with a communication sequence relating
to this transport service feature that is defined by the
application protocol.
Implementation: via ABORT.TCP and ABORT.SCTP.
o Timeout event when data could not be delivered for too long
Protocols: TCP, SCTP
Functional because this notifies that potentially assumed reliable
data delivery is no longer provided. Implementation: via
TIMEOUT.TCP and TIMEOUT.SCTP.
Gjessing & Welzl Expires May 4, 2017 [Page 14]
Internet-Draft Minimal TAPS Transport Services October 2016
3.2. DATA Transfer Related Transport Service Features
3.2.1. Sending Data
o Reliably transfer data, with congestion control
Protocols: TCP, SCTP
Functional because this is closely tied to properties of the data
that an application sends or expects to receive.
Implementation: via SEND.TCP and SEND.SCTP.
o Reliably transfer a message, with congestion control
Protocols: SCTP
Functional because this is closely tied to properties of the data
that an application sends or expects to receive.
Implementation: via SEND.SCTP.
Fall-back to TCP: By using SEND.TCP and providing a means to let
the application query whether messages can be identified or not.
o Unreliably transfer a message
Protocols: SCTP, UDP(-Lite)
Optimizing because only applications know about the time
criticality of their communication, and reliably transfering a
message is never incorrect for the receiver of a potentially
unreliable data transfer, it is just slower.
ADDED. This differs from the 2 automatable transport service
features below in that it leaves the choice of congestion control
open.
Implementation: via SEND.SCTP or SEND.UDP.
o Unreliably transfer a message, with congestion control
Protocols: SCTP
Automatable because congestion control relates to knowledge about
the network, not the application.
o Unreliably transfer a message, without congestion control
Protocols: UDP(-Lite)
Automatable because congestion control relates to knowledge about
the network, not the application.
Gjessing & Welzl Expires May 4, 2017 [Page 15]
Internet-Draft Minimal TAPS Transport Services October 2016
o Configurable Message Reliability
Protocols: SCTP
Optimizing because only applications know about the time
criticality of their communication, and reliably transfering a
message is never incorrect for the receiver of a potentially
unreliable data transfer, it is just slower.
Implementation: via SEND.SCTP.
Fall-back to TCP: By using SEND.TCP and ignoring this
configuration: based on the assumption of the best-effort service
model, unnecessarily delivering data does not violate application
expectations. Moreover, it is not possible to associate the
requested reliability to a "message" in TCP anyway.
o Choice of stream
Protocols: SCTP
Automatable because it requires using multiple streams, but
requesting multiple streams in the CONNECTION.ESTABLISHMENT
category is automatable. Implementation: see Section 4.
o Choice of path (destination address)
Protocols: SCTP
Automatable because it requires using multiple sockets, but
obtaining multiple sockets in the CONNECTION.ESTABLISHMENT
category is automatable. Implementation: see Section 4.
o Choice between unordered (potentially faster) or ordered delivery
of messages
Protocols: SCTP
Functional because this is closely tied to properties of the data
that an application sends or expects to receive.
Implementation: via SEND.SCTP.
Fall-back to TCP: By using SEND.TCP and always sending data
ordered: based on the assumption of the best-effort service model,
ordered delivery may just be slower and does not violate
application expectations. Moreover, it is not possible to
associate the requested delivery order to a "message" in TCP
anyway.
o Request not to bundle messages
Protocols: SCTP
Optimizing because this decision depends on knowledge about the
size of future data blocks and the delay between them.
Gjessing & Welzl Expires May 4, 2017 [Page 16]
Internet-Draft Minimal TAPS Transport Services October 2016
Implementation: via SEND.SCTP.
Fall-back to TCP: By using SEND.TCP and DISABLE-NAGLE.TCP to
disable the Nagle algorithm when the request is made and enable it
again when the request is no longer made.
o Specifying a "payload protocol-id" (handed over as such by the
receiver)
Protocols: SCTP
Functional because it allows to send extra application data with
every message, for the sake of identification of data, which by
itself is application-specific.
Implementation: SEND.SCTP.
Fall-back to TCP: Not possible.
o Specifying a key id to be used to authenticate a message
Protocols: SCTP
Functional because this has a direct influence on security.
o Request not to delay the acknowledgement (SACK) of a message
Protocols: SCTP
Optimizing because only an application knows for which message it
wants to quickly informed about success / failure of its delivery.
3.2.2. Receiving Data
o Receive data
Protocols: TCP, SCTP
Functional because a TAPS system must be able to send and receive
data.
Implementation: via RECEIVE.SCTP and RECEIVE.TCP
o Receive a message
Protocols: SCTP
Functional because this is closely tied to properties of the data
that an application sends or expects to receive.
Implementation: via RECEIVE.SCTP.
Gjessing & Welzl Expires May 4, 2017 [Page 17]
Internet-Draft Minimal TAPS Transport Services October 2016
Fall-back to TCP: By using RECEIVE.TCP and providing a means to
let the application query whether messages can be identified or
not.
o Choice of stream to receive from
Protocols: SCTP
Automatable because it requires using multiple streams, but
requesting multiple streams in the CONNECTION.ESTABLISHMENT
category is automatable.
Implementation: see Section 4.
o Information about partial message arrival
Protocols: SCTP
Functional because this is closely tied to properties of the data
that an application sends or expects to receive.
Implementation: via RECEIVE.SCTP.
Fall-back to TCP: Not possible (do not provide this event).
o Obtain a message delivery number
Protocols: SCTP
Functional because this number can let applications detect and, if
desired, correct reordering. Whether messages are in the correct
order or not is closely tied to properties of the data that an
application sends or expects to receive.
3.2.3. Errors
o Notification of send failures
Protocols: TCP, SCTP
Functional because this notifies that potentially assumed reliable
data delivery is no longer provided.
ADDED. This differs from the 2 automatable transport service
features below in that it does not distinugish between unsent and
unacknowledged messages.
Implementation: via SENDFAILURE-EVENT.SCTP.
Fall-back to TCP: Not possible (do not provide this event).
o Notification of unsent messages
Protocols: SCTP, UDP(-Lite)
Gjessing & Welzl Expires May 4, 2017 [Page 18]
Internet-Draft Minimal TAPS Transport Services October 2016
Optimizing because the DF field can be used to carry out Path MTU
Discovery, which can lead an application to choose message sizes
that can be transmitted more efficiently.
Implementation: via MAINTENANCE.SET_DF and SEND_FAILURE.UDP(-Lite)
o Notification of unacknowledged messages
Protocols: SCTP
Automatable because the distinction between unsent and
unacknowledged is network-specific.
4. Discussion
Some of transport service features in Section 3 were designated as
"automatable" on the basis of a broader decision that affects
multiple transport service features. These decisions are explained
here:
o All transport service features that are related to multi-streaming
were designated as "automatable". The decision on whether to use
multi-streaming or not does not depend on application-specific
knowledge. This means that a connection that is exhibited to an
application could be implemented by using a single stream of an
SCTP association instead of mapping it to a complete SCTP
association. This could be achieved by using more than one stream
when an SCTP association is first established (CONNECT.SCTP
parameter "outbound stream count"), an internal stream number
could be maintained by the TAPS system, and this stream number
would then be used when sending data (SEND.SCTP parameter "stream
number"). Closing or aborting a connection could then simply free
the stream number for future use.
o All transport service features that are related to usage of
multiple paths or the choice of the network interface were
designated as "automatable". Choosing a path or an interface does
not depend on application-specific knowledge. For example,
"Listen" could always listen on all available interfaces and
"Connect" could use the default interface for the destination IP
address.
5. Conclusion
By decoupling applications from transport protocols, a TAPS system
provides a different abstraction level than the Berkeley sockets
interface. As with high- vs. low-level programming languages, a
Gjessing & Welzl Expires May 4, 2017 [Page 19]
Internet-Draft Minimal TAPS Transport Services October 2016
higher abstraction level allows more freedom for automation below the
interface, yet it takes some control away from the application
programmer. This is the design trade-off that a TAPS system
developer is facing, and this document provides guidance on the
design of this abstraction level. Some transport service features
are currently rarely offered by APIs, yet they must be offered or
they can never be used ("functional" transport service features).
Other transport service features are offered by the APIs of the
protocols covered here, but not exposing them in a TAPS API would
allow for more freedom to automate protocol usage in a TAPS system.
The eventual recommendations are:
o A TAPS system should expose all functional transport service
features that are offered by the transport protocols that it uses
because these transport service features could otherwise not be
utilized by the TAPS system. It can still be possible to
implement a TAPS system that does not offer all functional
transport service features, e.g. for the sake of uniform
application operation across a broader set of protocols, but then
the corresponding functionality of transport protocols is not
exploited. If a protocol that provides a functional transport
service feature is not available, a TAPS system should
automatically fall back to a different protocol (e.g. TCP or UDP)
whenever possible to reduce the potential for protocol dependence
in applications.
o A TAPS system should exhibit all application-specific optimizing
transport service features. If an application-specific optimizing
transport service feature is only available in a subset of the
transport protocols used by the TAPS system, it should be
acceptable for the TAPS system to ignore its usage when the
transport protocol that is currently used does not provide it
because of the performance-optimizing nature of the transport
service feature and the initially mentioned assumption of "best
effort" operation.
o By hiding automatable transport service features from the
application, a TAPS system can gain opportunities to automatize
network-related functionality. This can facilitate using the TAPS
system for the application programmer and it allows for
optimizations that may not be possible for an application. For
instance, a kernel-level TAPS system that hides SCTP multi-
streaming from applications could theoretically map application-
level connections from multiple applications onto the same SCTP
association. Similarly, system-wide configurations regarding the
usage of multiple interfaces could be exploited if the choice of
the interface is not given to the application. However, if an
application wants to directly expose such choices to its user, not
offering this functionality can become a disadvantage of a TAPS
Gjessing & Welzl Expires May 4, 2017 [Page 20]
Internet-Draft Minimal TAPS Transport Services October 2016
system. This is a trade-off that must be considered in TAPS
system design.
6. Acknowledgements
This work has received funding from the European Union'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
XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA.
8. Security Considerations
Security will be considered in future versions of this document.
9. Informative References
[RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of
Simple Best-Effort Traffic", RFC 5290,
DOI 10.17487/RFC5290, July 2008,
<http://www.rfc-editor.org/info/rfc5290>.
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
Technology Adoption and Transition (ITAT)", RFC 7305,
DOI 10.17487/RFC7305, July 2014,
<http://www.rfc-editor.org/info/rfc7305>.
[TAPS1] Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
provided by IETF transport protocols and congestion
control mechanisms", Internet-draft draft-ietf-taps-
transports-12, July 2016.
[TAPS2] Welzl, M., Tuexen, M., and N. Khademi, "An Approach to
Identify Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", Internet-draft draft-ietf-
taps-transports-usage-02, October 2016.
Appendix A. Revision information
XXX RFC-Ed please remove this section prior to publication.
-02: implementation suggestions added, discussion section added,
terminology extended, DELETED category removed, various other fixes;
Gjessing & Welzl Expires May 4, 2017 [Page 21]
Internet-Draft Minimal TAPS Transport Services October 2016
list of Transport Service Features adjusted to -01 version of [TAPS2]
except that MPTCP is not included.
-03: updated to be consistent with -02 version of [TAPS2].
Authors' Addresses
Stein Gjessing
University of Oslo
PO Box 1080 Blindern
Oslo N-0316
Norway
Phone: +47 22 85 24 44
Email: steing@ifi.uio.no
Michael Welzl
University of Oslo
PO Box 1080 Blindern
Oslo N-0316
Norway
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no
Gjessing & Welzl Expires May 4, 2017 [Page 22]