draft-ietf-taps-minset-05.txt | draft-ietf-taps-minset-06.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 21, 2019 August 20, 2018 | Expires: February 23, 2019 August 22, 2018 | |||
A Minimal Set of Transport Services for End Systems | A Minimal Set of Transport Services for End Systems | |||
draft-ietf-taps-minset-05 | draft-ietf-taps-minset-06 | |||
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 21, 2019. | This Internet-Draft will expire on February 23, 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 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
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. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 13 | 8.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15 | 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 . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
A.2.1. CONNECTION Related Transport Features . . . . . . . . 40 | A.2.1. CONNECTION Related Transport Features . . . . . . . . 40 | |||
A.2.2. DATA Transfer Related Transport Features . . . . . . 41 | A.2.2. DATA Transfer Related Transport Features . . . . . . 41 | |||
A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 42 | A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41 | |||
A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42 | A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42 | |||
A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43 | A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43 | |||
A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44 | A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44 | |||
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 . . . . . . . . . . . . . . . . . . 45 | |||
A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 46 | A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45 | |||
A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46 | A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46 | |||
Appendix B. Revision information . . . . . . . . . . . . . . . . 46 | Appendix B. Revision information . . . . . . . . . . . . . . . . 46 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
1. Introduction | 1. Introduction | |||
The task of a transport system is to offer transport services to its | The task of a transport system is to offer transport services to its | |||
applications, i.e. the applications running on top of the transport | applications, i.e. the applications running on top of the transport | |||
system. Ideally, it does so without statically binding applications | system. Ideally, it does so without statically binding applications | |||
to particular transport protocols. Currently, the set of transport | to particular transport protocols. Currently, the set of transport | |||
services that most applications use is based on TCP and UDP (and | services that most applications use is based on TCP and UDP (and | |||
protocols that are layered on top of them); this limits the ability | protocols that are layered on top of them); this limits the ability | |||
for the network stack to make use of features of other transport | for the network stack to make use of features of other transport | |||
skipping to change at page 12, line 46 ¶ | skipping to change at page 12, line 46 ¶ | |||
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 and 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 | 6. IANA Considerations | |||
XX RFC ED - PLEASE REMOVE THIS SECTION XXX | ||||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
7. Security Considerations | 7. 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 of [I-D.ietf-taps-transport-security]). | separate document (Section 5 on Security Features and Transport | |||
Dependencies of [I-D.ietf-taps-transport-security]). | ||||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[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>. | |||
skipping to change at page 30, line 4 ¶ | skipping to change at page 29, line 37 ¶ | |||
Implementation: via SET_CHECKSUM_REQUIRED.UDP. | Implementation: via SET_CHECKSUM_REQUIRED.UDP. | |||
Implementation over TCP: do nothing (TCP does not offer to disable | Implementation over TCP: do nothing (TCP does not offer to disable | |||
the checksum, but transmitting data with an intact checksum will | the checksum, but transmitting data with an intact checksum will | |||
not yield a semantically wrong result). | not yield a semantically wrong result). | |||
o Specify checksum coverage used by the sender | o Specify checksum coverage used by the sender | |||
Protocols: UDP-Lite | Protocols: UDP-Lite | |||
Functional because application-specific knowledge is necessary to | Functional because application-specific knowledge is necessary to | |||
decide for which parts of the data it can be acceptable to lose | decide for which parts of the data it can be acceptable to lose | |||
data integrity. | data integrity. | |||
Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. | Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. | |||
Implementation over TCP: do nothing (TCP does not offer to limit | Implementation over TCP: do nothing (TCP does not offer to limit | |||
the checksum length, but transmitting data with an intact checksum | the checksum length, but transmitting data with an intact checksum | |||
will not yield a semantically wrong result). Implementation over | will not yield a semantically wrong result). | |||
UDP: if checksum coverage is set to cover payload data, do | Implementation over UDP: if checksum coverage is set to cover | |||
nothing. Else, either do nothing (transmitting data with an | payload data, do nothing. Else, either do nothing (transmitting | |||
intact checksum will not yield a semantically wrong result), or | data with an intact checksum will not yield a semantically wrong | |||
use the transport feature "Disable checksum when sending". | result), or use the transport feature "Disable checksum when | |||
sending". | ||||
o Specify minimum checksum coverage required by receiver | o Specify minimum checksum coverage required by receiver | |||
Protocols: UDP-Lite | Protocols: UDP-Lite | |||
Functional because application-specific knowledge is necessary to | Functional because application-specific knowledge is necessary to | |||
decide for which parts of the data it can be acceptable to lose | decide for which parts of the data it can be acceptable to lose | |||
data integrity. | data integrity. | |||
Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. | Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. | |||
Implementation over TCP: do nothing (TCP does not offer to limit | Implementation over TCP: do nothing (TCP does not offer to limit | |||
the checksum length, but transmitting data with an intact checksum | the checksum length, but transmitting data with an intact checksum | |||
will not yield a semantically wrong result). Implementation over | will not yield a semantically wrong result). | |||
UDP: if checksum coverage is set to cover payload data, do | Implementation over UDP: if checksum coverage is set to cover | |||
nothing. Else, either do nothing (transmitting data with an | payload data, do nothing. Else, either do nothing (transmitting | |||
intact checksum will not yield a semantically wrong result), or | data with an intact checksum will not yield a semantically wrong | |||
use the transport feature "Disable checksum requirement when | result), or use the transport feature "Disable checksum | |||
receiving". | requirement when receiving". | |||
o Specify DF field | o Specify DF field | |||
Protocols: UDP(-Lite) | Protocols: UDP(-Lite) | |||
Optimizing because the DF field can be used to carry out Path MTU | Optimizing because the DF field can be used to carry out Path MTU | |||
Discovery, which can lead an application to choose message sizes | Discovery, which can lead an application to choose message sizes | |||
that can be transmitted more efficiently. | that can be transmitted more efficiently. | |||
Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and | Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and | |||
SEND_FAILURE.UDP(-Lite). | SEND_FAILURE.UDP(-Lite). | |||
Implementation over TCP: do nothing (with TCP, the sending | Implementation over TCP: do nothing (with TCP, the sending | |||
application is not in control of transport message sizes, making | application is not in control of transport message sizes, making | |||
skipping to change at page 48, line 11 ¶ | skipping to change at page 47, line 44 ¶ | |||
document", wrote "example" in the paragraph introducing the decision | document", wrote "example" in the paragraph introducing the decision | |||
tree. Removed reference draft-grinnemo-taps-he-03 and the sentence | tree. Removed reference draft-grinnemo-taps-he-03 and the sentence | |||
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. | |||
Authors' Addresses | WG -06: Fixed nits. | |||
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. 14 change blocks. | ||||
23 lines changed or deleted | 23 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/ |