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/ |