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/