draft-ietf-taps-minset-06.txt   draft-ietf-taps-minset-07.txt 
TAPS M. Welzl TAPS M. Welzl
Internet-Draft S. Gjessing Internet-Draft S. Gjessing
Intended status: Informational University of Oslo Intended status: Informational University of Oslo
Expires: February 23, 2019 August 22, 2018 Expires: March 4, 2019 August 31, 2018
A Minimal Set of Transport Services for End Systems A Minimal Set of Transport Services for End Systems
draft-ietf-taps-minset-06 draft-ietf-taps-minset-07
Abstract Abstract
This draft recommends a minimal set of Transport Services offered by This draft recommends a minimal set of Transport Services offered by
end systems, and gives guidance on choosing among the available end systems, and gives guidance on choosing among the available
mechanisms and protocols. It is based on the set of transport mechanisms and protocols. It is based on the set of transport
features in RFC 8303. features in RFC 8303.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 23, 2019. This Internet-Draft will expire on March 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Minimal Set of Transport Features . . . . . . . . . . . . 5 3. The Minimal Set of Transport Features . . . . . . . . . . . . 5
3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5 3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5
3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8 3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8
3.2.2. Individual connections . . . . . . . . . . . . . . . 10 3.2.2. Individual connections . . . . . . . . . . . . . . . 10
3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10 3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11 3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 14
Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15
A.1. Step 1: Categorization -- The Superset of Transport A.1. Step 1: Categorization -- The Superset of Transport
Features . . . . . . . . . . . . . . . . . . . . . . . . 15 Features . . . . . . . . . . . . . . . . . . . . . . . . 15
A.1.1. CONNECTION Related Transport Features . . . . . . . . 17 A.1.1. CONNECTION Related Transport Features . . . . . . . . 17
A.1.2. DATA Transfer Related Transport Features . . . . . . 33 A.1.2. DATA Transfer Related Transport Features . . . . . . 33
A.2. Step 2: Reduction -- The Reduced Set of Transport A.2. Step 2: Reduction -- The Reduced Set of Transport
Features . . . . . . . . . . . . . . . . . . . . . . . . 39 Features . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2.1. CONNECTION Related Transport Features . . . . . . . . 40 A.2.1. CONNECTION Related Transport Features . . . . . . . . 39
A.2.2. DATA Transfer Related Transport Features . . . . . . 41 A.2.2. DATA Transfer Related Transport Features . . . . . . 40
A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41 A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41
A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42 A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 41
A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43 A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 42
A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44 A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 43
A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44 A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44
A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 45 A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 44
A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45 A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45
A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46 A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Revision information . . . . . . . . . . . . . . . . 46 Appendix B. Revision information . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
The task of a transport system is to offer transport services to its Currently, the set of transport services that most applications use
applications, i.e. the applications running on top of the transport is based on TCP and UDP (and protocols that are layered on top of
system. Ideally, it does so without statically binding applications them); this limits the ability for the network stack to make use of
to particular transport protocols. Currently, the set of transport features of other transport protocols. For example, if a protocol
services that most applications use is based on TCP and UDP (and supports out-of-order message delivery but applications always assume
protocols that are layered on top of them); this limits the ability that the network provides an ordered bytestream, then the network
for the network stack to make use of features of other transport stack can not immediately deliver a message that arrives out-of-
protocols. For example, if a protocol supports out-of-order message order: doing so would break a fundamental assumption of the
delivery but applications always assume that the network provides an application. The net result is unnecessary head-of-line blocking
ordered bytestream, then the network stack can not immediately delay.
deliver a message that arrives out-of-order: doing so would break a
fundamental assumption of the application. The net result is
unnecessary head-of-line blocking delay.
By exposing the transport services of multiple transport protocols, a By exposing the transport services of multiple transport protocols, a
transport system can make it possible to use these services without transport system can make it possible for applications to use these
having to statically bind an application to a specific transport services without being statically bound to a specific transport
protocol. The first step towards the design of such a system was protocol. The first step towards the design of such a system was
taken by [RFC8095], which surveys a large number of transports, and taken by [RFC8095], which surveys a large number of transports, and
[RFC8303] as well as [RFC8304], which identify the specific transport [RFC8303] as well as [RFC8304], which identify the specific transport
features that are exposed to applications by the protocols TCP, features that are exposed to applications by the protocols TCP,
MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control
mechanism. This memo is based on these documents and follows the mechanism. This memo is based on these documents and follows the
same terminology (also listed below). Because the considered same terminology (also listed below). Because the considered
transport protocols conjointly cover a wide range of transport transport protocols conjointly cover a wide range of transport
features, there is reason to hope that the resulting set (and the features, there is reason to hope that the resulting set (and the
reasoning that led to it) will also apply to many aspects of other reasoning that led to it) will also apply to many aspects of other
transport protocols that may be in use today, or may be designed in transport protocols that may be in use today, or may be designed in
the future. the future.
The number of transport features of current IETF transports is large, By decoupling applications from transport protocols, a transport
and exposing all of them has a number of disadvantages: generally, system provides a different abstraction level than the Berkeley
the more functionality is exposed, the less freedom a transport sockets interface. As with high- vs. low-level programming
system has to automate usage of the various functions of its languages, a higher abstraction level allows more freedom for
available set of transport protocols. Some functions only exist in automation below the interface, yet it takes some control away from
one particular protocol, and if an application used them, this would the application programmer. This is the design trade-off that a
statically tie the application to this protocol, limiting the transport system developer is facing, and this document provides
flexibility of the transport system. Also, if the number of exposed guidance on the design of this abstraction level. Some transport
features is exceedingly large, a transport system might become very features are currently rarely offered by APIs, yet they must be
difficult to use for an application programmer. Taking [RFC8303] as offered or they can never be used. Other transport features are
a basis, this document therefore develops a minimal set of transport offered by the APIs of the protocols covered here, but not exposing
features, removing the ones that could get in the way of transport them in an API would allow for more freedom to automate protocol
flexibility but keeping the ones that must be retained for usage in a transport system. The minimal set presented in this
applications to benefit from useful transport functionality. document is an effort to find a middle ground that can be recommended
for transport systems to implement, on the basis of the transport
features discussed in [RFC8303].
Applications use a wide variety of APIs today. The transport Applications use a wide variety of APIs today. The transport
features in the minimal set in this document must be reflected in features in the minimal set in this document must be reflected in
*all* network APIs in order for the underlying functionality to *all* network APIs in order for the underlying functionality to
become usable everywhere. For example, it does not help an become usable everywhere. For example, it does not help an
application that talks to a library which offers its own application that talks to a library which offers its own
communication interface if the underlying Berkeley Sockets API is communication interface if the underlying Berkeley Sockets API is
extended to offer "unordered message delivery", but the library only extended to offer "unordered message delivery", but the library only
exposes an ordered bytestream. Both the Berkeley Sockets API and the exposes an ordered bytestream. Both the Berkeley Sockets API and the
library would have to expose the "unordered message delivery" library would have to expose the "unordered message delivery"
skipping to change at page 6, line 8 skipping to change at page 6, line 6
For ungrouped connections, early configuration is necessary because For ungrouped connections, early configuration is necessary because
it allows the transport system to know which protocols it should try it allows the transport system to know which protocols it should try
to use. In particular, a transport system that only makes a one-time to use. In particular, a transport system that only makes a one-time
choice for a particular protocol must know early about strict choice for a particular protocol must know early about strict
requirements that must be kept, or it can end up in a deadlock requirements that must be kept, or it can end up in a deadlock
situation (e.g., having chosen UDP and later be asked to support situation (e.g., having chosen UDP and later be asked to support
reliable transfer). As an example description of how to correctly reliable transfer). As an example description of how to correctly
handle these cases, we provide the following decision tree (this is handle these cases, we provide the following decision tree (this is
derived from Appendix A.2.1 excluding authentication, as explained in derived from Appendix A.2.1 excluding authentication, as explained in
Section 7): Section 6):
- Will it ever be necessary to offer any of the following? - Will it ever be necessary to offer any of the following?
* Reliably transfer data * Reliably transfer data
* Notify the peer of closing/aborting * Notify the peer of closing/aborting
* Preserve data ordering * Preserve data ordering
Yes: SCTP or TCP can be used. Yes: SCTP or TCP can be used.
- Is any of the following useful to the application? - Is any of the following useful to the application?
* Choosing a scheduler to operate between connections * Choosing a scheduler to operate between connections
in a group, with the possibility to configure a priority in a group, with the possibility to configure a priority
skipping to change at page 12, line 13 skipping to change at page 12, line 10
implemented to directly use TCP). implemented to directly use TCP).
Different from TCP's semantics, if the sending application has Different from TCP's semantics, if the sending application has
allowed that messages are not fully reliably transferred, or allowed that messages are not fully reliably transferred, or
delivered out of order, then such re-ordering or unreliability may be delivered out of order, then such re-ordering or unreliability may be
reflected per message in the arriving data. Messages will always reflected per message in the arriving data. Messages will always
stay intact - i.e. if an incomplete message is contained at the end stay intact - i.e. if an incomplete message is contained at the end
of the arriving data block, this message is guaranteed to continue in of the arriving data block, this message is guaranteed to continue in
the next arriving data block. the next arriving data block.
4. Conclusion 4. Acknowledgements
By decoupling applications from transport protocols, a transport
system provides a different abstraction level than the Berkeley
sockets interface. As with high- vs. low-level programming
languages, a 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
transport system developer is facing, and this document provides
guidance on the design of this abstraction level. Some transport
features are currently rarely offered by APIs, yet they must be
offered or they can never be used ("functional" transport features).
Other transport features are offered by the APIs of the protocols
covered here, but not exposing them in an API would allow for more
freedom to automate protocol usage in a transport system. The
minimal set presented in this document is an effort to find a middle
ground that can be recommended for transport systems to implement, on
the basis of the transport features discussed in [RFC8303].
5. Acknowledgements
The authors would like to thank all the participants of the TAPS The authors would like to thank all the participants of the TAPS
Working Group and the NEAT and MAMI research projects for valuable Working Group and the NEAT and MAMI research projects for valuable
input to this document. We especially thank Michael Tuexen for help input to this document. We especially thank Michael Tuexen for help
with connection connection establishment/teardown and Gorry Fairhurst with connection connection establishment/teardown, Gorry Fairhurst
for his suggestions regarding fragmentation and packet sizes, and for his suggestions regarding fragmentation and packet sizes, and
Spencer Dawkins for his extremely detailed and constructive review. Spencer Dawkins for his extremely detailed and constructive review.
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334 research and innovation programme under grant agreement No. 644334
(NEAT). (NEAT).
6. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 6. Security Considerations
Authentication, confidentiality protection, and integrity protection Authentication, confidentiality protection, and integrity protection
are identified as transport features by [RFC8095]. As currently are identified as transport features by [RFC8095]. As currently
deployed in the Internet, these features are generally provided by a deployed in the Internet, these features are generally provided by a
protocol or layer on top of the transport protocol; no current full- protocol or layer on top of the transport protocol; no current full-
featured standards-track transport protocol provides all of these featured standards-track transport protocol provides all of these
transport features on its own. Therefore, these transport features transport features on its own. Therefore, these transport features
are not considered in this document, with the exception of native are not considered in this document, with the exception of native
authentication capabilities of TCP and SCTP for which the security authentication capabilities of TCP and SCTP for which the security
considerations in [RFC5925] and [RFC4895] apply. The minimum considerations in [RFC5925] and [RFC4895] apply. The minimum
requirements for a secure transport system are discussed in a requirements for a secure transport system are discussed in a
separate document (Section 5 on Security Features and Transport separate document (Section 5 on Security Features and Transport
Dependencies of [I-D.ietf-taps-transport-security]). Dependencies of [I-D.ietf-taps-transport-security]).
8. References 7. References
8.1. Normative References 7.1. Normative References
[I-D.ietf-taps-transport-security]
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
of Transport Security Protocols", draft-ietf-taps-
transport-security-02 (work in progress), June 2018.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols", Transport Features Provided by IETF Transport Protocols",
RFC 8303, DOI 10.17487/RFC8303, February 2018, RFC 8303, DOI 10.17487/RFC8303, February 2018,
<https://www.rfc-editor.org/info/rfc8303>. <https://www.rfc-editor.org/info/rfc8303>.
8.2. Informative References 7.2. Informative References
[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte
Stuffing", September 1997, Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No.
<http://stuartcheshire.org/papers/COBSforToN.pdf>. 2, April 1999.
[I-D.ietf-taps-transport-security]
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
of Transport Security Protocols", draft-ietf-taps-
transport-security-01 (work in progress), May 2018.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
qos-18 (work in progress), August 2016. qos-18 (work in progress), August 2016.
[LBE-draft] [LBE-draft]
Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
Internet-draft draft-tsvwg-le-phb-03, February 2018. Internet-draft draft-tsvwg-le-phb-03, February 2018.
skipping to change at page 14, line 33 skipping to change at page 14, line 20
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
"Additional Policies for the Partially Reliable Stream "Additional Policies for the Partially Reliable Stream
Control Transmission Protocol Extension", RFC 7496, Control Transmission Protocol Extension", RFC 7496,
DOI 10.17487/RFC7496, April 2015, DOI 10.17487/RFC7496, April 2015,
<https://www.rfc-editor.org/info/rfc7496>. <https://www.rfc-editor.org/info/rfc7496>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the "Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", RFC 8260, Stream Control Transmission Protocol", RFC 8260,
DOI 10.17487/RFC8260, November 2017, DOI 10.17487/RFC8260, November 2017,
<https://www.rfc-editor.org/info/rfc8260>. <https://www.rfc-editor.org/info/rfc8260>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP- User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>. <https://www.rfc-editor.org/info/rfc8304>.
skipping to change at page 47, line 46 skipping to change at page 47, line 28
that referred to it. that referred to it.
WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As
part of that, removed "TAPS" as a term everywhere (abstract, intro, part of that, removed "TAPS" as a term everywhere (abstract, intro,
..). ..).
WG -05: addressed comments from Spencer Dawkins. WG -05: addressed comments from Spencer Dawkins.
WG -06: Fixed nits. WG -06: Fixed nits.
WG -07: Addressed Genart comments from Robert Sparks.
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
Stein Gjessing Stein Gjessing
 End of changes. 23 change blocks. 
88 lines changed or deleted 70 lines changed or added

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