draft-ietf-taps-minset-10.txt   draft-ietf-taps-minset-11.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: March 22, 2019 September 18, 2018 Expires: March 31, 2019 September 27, 2018
A Minimal Set of Transport Services for End Systems A Minimal Set of Transport Services for End Systems
draft-ietf-taps-minset-10 draft-ietf-taps-minset-11
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 March 22, 2019. This Internet-Draft will expire on March 31, 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. Deriving the minimal set . . . . . . . . . . . . . . . . . . 5 3. Deriving the minimal set . . . . . . . . . . . . . . . . . . 5
4. The Reduced Set of Transport Features . . . . . . . . . . . . 6 4. The Reduced Set of Transport Features . . . . . . . . . . . . 6
4.1. CONNECTION Related Transport Features . . . . . . . . . . 7 4.1. CONNECTION Related Transport Features . . . . . . . . . . 7
4.2. DATA Transfer Related Transport Features . . . . . . . . 8 4.2. DATA Transfer Related Transport Features . . . . . . . . 8
4.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 9 4.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 9
4.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 9
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Sending Messages, Receiving Bytes . . . . . . . . . . . . 9 5.1. Sending Messages, Receiving Bytes . . . . . . . . . . . . 10
5.2. Stream Schedulers Without Streams . . . . . . . . . . . . 10 5.2. Stream Schedulers Without Streams . . . . . . . . . . . . 11
5.3. Early Data Transmission . . . . . . . . . . . . . . . . . 11 5.3. Early Data Transmission . . . . . . . . . . . . . . . . . 11
5.4. Sender Running Dry . . . . . . . . . . . . . . . . . . . 12 5.4. Sender Running Dry . . . . . . . . . . . . . . . . . . . 12
5.5. Capacity Profile . . . . . . . . . . . . . . . . . . . . 12 5.5. Capacity Profile . . . . . . . . . . . . . . . . . . . . 13
5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 13 5.7. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 14
6. The Minimal Set of Transport Features . . . . . . . . . . . . 14 6. The Minimal Set of Transport Features . . . . . . . . . . . . 14
6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 14 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 14
6.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Connection groups . . . . . . . . . . . . . . . . . . 18 6.2.1. Connection groups . . . . . . . . . . . . . . . . . . 18
6.2.2. Individual connections . . . . . . . . . . . . . . . 19 6.2.2. Individual connections . . . . . . . . . . . . . . . 20
6.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 20 6.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 20
6.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 20 6.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 20
6.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 21 6.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. The Superset of Transport Features . . . . . . . . . 24 Appendix A. The Superset of Transport Features . . . . . . . . . 25
A.1. CONNECTION Related Transport Features . . . . . . . . . . 25 A.1. CONNECTION Related Transport Features . . . . . . . . . . 26
A.2. DATA Transfer Related Transport Features . . . . . . . . 41 A.2. DATA Transfer Related Transport Features . . . . . . . . 42
A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 41 A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 42
A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 45 A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 46
A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 46 A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 47
Appendix B. Revision information . . . . . . . . . . . . . . . . 47 Appendix B. Revision information . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
Currently, the set of transport services that most applications use Currently, the set of transport services that most applications use
is based on TCP and UDP (and protocols that are layered on top of is based on TCP and UDP (and protocols that are layered on top of
them); this limits the ability for the network stack to make use of them); this limits the ability for the network stack to make use of
features of other transport protocols. For example, if a protocol features of other transport protocols. For example, if a protocol
supports out-of-order message delivery but applications always assume supports out-of-order message delivery but applications always assume
that the network provides an ordered bytestream, then the network that the network provides an ordered bytestream, then the network
stack can not immediately deliver a message that arrives out-of- stack can not immediately deliver a message that arrives out-of-
skipping to change at page 3, line 47 skipping to change at page 3, line 47
guidance on the design of this abstraction level. Some transport guidance on the design of this abstraction level. Some transport
features are currently rarely offered by APIs, yet they must be features are currently rarely offered by APIs, yet they must be
offered or they can never be used. Other transport features are offered or they can never be used. Other transport features are
offered by the APIs of the protocols covered here, but not exposing offered by the APIs of the protocols covered here, but not exposing
them in an API would allow for more freedom to automate protocol them in an API would allow for more freedom to automate protocol
usage in a transport system. The minimal set presented here is an usage in a transport system. The minimal set presented here is an
effort to find a middle ground that can be recommended for transport effort to find a middle ground that can be recommended for transport
systems to implement, on the basis of the transport features systems to implement, on the basis of the transport features
discussed in [RFC8303]. discussed in [RFC8303].
Applications use a wide variety of APIs today. The transport Applications use a wide variety of APIs today. While this document
features in the minimal set in this document must be reflected in was created to ensure the API developed in the Transport Services
*all* network APIs in order for the underlying functionality to (TAPS) Working Group ([I-D.ietf-taps-interface]) includes the most
become usable everywhere. For example, it does not help an important transport features, the minimal set presented here must be
application that talks to a library which offers its own reflected in *all* network APIs in order for the underlying
functionality to become usable everywhere. For example, it does not
help an 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"
transport feature (alternatively, there may be ways for certain types transport feature (alternatively, there may be ways for certain types
of libraries to use this transport feature without exposing it, based of libraries to use this transport feature without exposing it, based
on knowledge about the applications -- but this is not the general on knowledge about the applications -- but this is not the general
case). Similarly, transport protocols such as SCTP offer multi- case). Similarly, transport protocols such as SCTP offer multi-
streaming, which cannot be utilized, e.g., to prioritize messages streaming, which cannot be utilized, e.g., to prioritize messages
between streams, unless applications communicate the priorities and between streams, unless applications communicate the priorities and
skipping to change at page 21, line 44 skipping to change at page 22, line 29
research and innovation programme under grant agreement No. 644334 research and innovation programme under grant agreement No. 644334
(NEAT). (NEAT).
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. 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]. Often, these
deployed in the Internet, these features are generally provided by a features are provided by a protocol or layer on top of the transport
protocol or layer on top of the transport protocol; no current full- protocol; none of the full-featured standards-track transport
featured standards-track transport protocol provides all of these protocols in [RFC8303], which this document is based upon, provides
transport features on its own. Therefore, these transport features all of these transport features on its own. Therefore, they are not
are not considered in this document, with the exception of native 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]).
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 22, line 33 skipping to change at page 23, line 22
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>.
10.2. Informative References 10.2. Informative References
[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte
Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No. Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No.
2, April 1999. 2, April 1999.
[I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
Abstract Application Layer Interface to Transport
Services", draft-ietf-taps-interface-01 (work in
progress), July 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.
[POSIX] "IEEE Standard for Information Technology--Portable [POSIX] "IEEE Standard for Information Technology--Portable
skipping to change at page 49, line 12 skipping to change at page 50, line 12
WG -07: Addressed Genart comments from Robert Sparks. WG -07: Addressed Genart comments from Robert Sparks.
WG -08: Addressed one more Genart comment from Robert Sparks. WG -08: Addressed one more Genart comment from Robert Sparks.
WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben
Campbell, Benjamin Kaduk and Eric Rescorla. Campbell, Benjamin Kaduk and Eric Rescorla.
WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla. WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla.
WG -11: Addressed comments from Alissa Cooper.
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
 End of changes. 14 change blocks. 
32 lines changed or deleted 43 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/