--- 1/draft-ietf-taps-minset-05.txt 2018-08-22 07:13:51.739249935 -0700 +++ 2/draft-ietf-taps-minset-06.txt 2018-08-22 07:13:51.831252163 -0700 @@ -1,18 +1,18 @@ TAPS M. Welzl Internet-Draft S. Gjessing 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 - draft-ietf-taps-minset-05 + draft-ietf-taps-minset-06 Abstract This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,43 +54,43 @@ 3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5 3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8 3.2.2. Individual connections . . . . . . . . . . . . . . . 10 3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15 A.1. Step 1: Categorization -- The Superset of Transport Features . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1.1. CONNECTION Related Transport Features . . . . . . . . 17 A.1.2. DATA Transfer Related Transport Features . . . . . . 33 A.2. Step 2: Reduction -- The Reduced Set of Transport Features . . . . . . . . . . . . . . . . . . . . . . . . 39 A.2.1. CONNECTION Related Transport Features . . . . . . . . 40 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.2. Stream Schedulers Without Streams . . . . . . . . . . 43 A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44 A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44 A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 45 - A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 46 + A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45 A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46 Appendix B. Revision information . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction The task of a transport system is to offer transport services to its applications, i.e. the applications running on top of the transport system. Ideally, it does so without statically binding applications to particular transport protocols. Currently, the set of transport services that most applications use 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 features of other transport @@ -556,37 +556,36 @@ input to this document. We especially thank Michael Tuexen for help with connection connection establishment/teardown and Gorry Fairhurst for his suggestions regarding fragmentation and packet sizes, and Spencer Dawkins for his extremely detailed and constructive review. This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). 6. IANA Considerations - XX RFC ED - PLEASE REMOVE THIS SECTION XXX - This memo includes no request to IANA. 7. Security Considerations Authentication, confidentiality protection, and integrity protection are identified as transport features by [RFC8095]. As currently deployed in the Internet, these features are generally provided by a protocol or layer on top of the transport protocol; no current full- featured standards-track transport protocol provides all of these transport features on its own. Therefore, these transport features are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply. The minimum 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.1. Normative References [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, . @@ -1271,44 +1272,44 @@ Implementation: via SET_CHECKSUM_REQUIRED.UDP. Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result). o Specify checksum coverage used by the sender Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. - Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum - will not yield a semantically wrong result). Implementation over - UDP: if checksum coverage is set to cover payload data, do - nothing. Else, either do nothing (transmitting data with an - intact checksum will not yield a semantically wrong result), or - use the transport feature "Disable checksum when sending". + will not yield a semantically wrong result). + Implementation over UDP: if checksum coverage is set to cover + payload data, do nothing. Else, either do nothing (transmitting + data with an intact checksum will not yield a semantically wrong + result), or use the transport feature "Disable checksum when + sending". o Specify minimum checksum coverage required by receiver Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum - will not yield a semantically wrong result). Implementation over - UDP: if checksum coverage is set to cover payload data, do - nothing. Else, either do nothing (transmitting data with an - intact checksum will not yield a semantically wrong result), or - use the transport feature "Disable checksum requirement when - receiving". + will not yield a semantically wrong result). + Implementation over UDP: if checksum coverage is set to cover + payload data, do nothing. Else, either do nothing (transmitting + data with an intact checksum will not yield a semantically wrong + result), or use the transport feature "Disable checksum + requirement when receiving". o Specify DF field Protocols: UDP(-Lite) Optimizing because the DF field can be used to carry out Path MTU Discovery, which can lead an application to choose message sizes that can be transmitted more efficiently. Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and SEND_FAILURE.UDP(-Lite). Implementation over TCP: do nothing (with TCP, the sending application is not in control of transport message sizes, making @@ -2059,22 +2062,23 @@ document", wrote "example" in the paragraph introducing the decision tree. Removed reference draft-grinnemo-taps-he-03 and the sentence that referred to it. WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As part of that, removed "TAPS" as a term everywhere (abstract, intro, ..). WG -05: addressed comments from Spencer Dawkins. -Authors' Addresses + WG -06: Fixed nits. +Authors' Addresses Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Stein Gjessing