idnits 2.17.1 draft-gjessing-taps-minset-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2015) is 3221 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5290' is mentioned on line 98, but not defined == Missing Reference: 'RFC7305' is mentioned on line 98, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-taps-transports-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS S. Gjessing 3 Internet-Draft M. Welzl 4 Intended status: Informational University of Oslo 5 Expires: December 24, 2015 June 22, 2015 7 A Minimal Set of Transport Services for TAPS Systems 8 draft-gjessing-taps-minset-00 10 Abstract 12 This draft will eventually recommend a minimal set of IETF Transport 13 Services offered by end systems supporting TAPS, and give guidance on 14 choosing among the available mechanisms and protocols. As a starting 15 point for discussion, it currently only gives an overview of some 16 ways to categorize the set of transport services in the first TAPS 17 document (version 4: draft-ietf-taps-transports-04), assuming that 18 the eventual minimal set of transport services will be based on a 19 similar form of categorization. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 24, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology (as defined by draft-ietf-taps-transports-04) . . 4 57 3. A list of all features in the considered IETF Transport 58 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Grouping of the features . . . . . . . . . . . . . . . . . . . 6 60 4.1. Functional vs. non-functional . . . . . . . . . . . . . . 7 61 4.1.1. Functional features . . . . . . . . . . . . . . . . . 7 62 4.1.2. Non-functional features . . . . . . . . . . . . . . . 7 63 4.2. Components from draft-ietf-taps-transports-04 that are 64 not specified or seen by the applications . . . . . . . . 9 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 An application has an intended usage and demands for transport 74 services, and the task of any system that implements TAPS is to offer 75 these services to its applications, i.e. the applications running on 76 top of TAPS, without binding an application to a particular transport 77 protocol. 79 The present draft is based on [TAPS1] and follows the same 80 terminology (also listed below). We include an "inversion" (in the 81 database sense) of [TAPS1], in that, based on the lists of protocol 82 components in [TAPS1] we list all protocol features, and for each 83 feature, we list the Transport Protocols that support this feature 84 (as a component). The resulting list is very long. If the list of 85 Transport Services that a TAPS system offers to applications was a 86 simple copy of this list, the resulting system would be very hard to 87 use. It is therefore necessary to minimize the number of services 88 that are offered. We begin this by grouping these transport 89 features. 91 The groups of features offered to applications are divided as 92 follows: 93 1. functional vs. non-functional 94 2. static vs. initialization vs. dynamic 95 3. single-sided vs. both-sided 97 Because QoS is out of scope of TAPS, this document assumes a "best 98 effort" service model [RFC5290, RFC7305]. Applications using a TAPS 99 system can therefore not make any assumptions about e.g. the time it 100 will take to send a message. There are however certain requirements 101 that are strictly kept by transport protocols today, and a TAPS 102 system. 104 Functional features use components that cannot be used without the 105 application knowing about them, or else they violate assumptions that 106 might cause the application to break. Components implementing non- 107 functional features may be used without involving the application. 108 For example, unordered message delivery is a functional feature: it 109 cannot be used without the application knowing about it because the 110 application's assumption could be that messages arrive in-order, and 111 in this case unordered delivery could cause the application to break. 112 Multihoming and data bundling (Nagle in TCP) are non-functional 113 features: if a TAPS system autonomously decides to enable or disable 114 them, an application will not break (but a TAPS system may be able to 115 communicate more efficiently if the application is in control of this 116 feature). 118 If a transport protocol offers a feature that can not be changed or 119 opted out, this feature is called static in this protocol. An 120 application uses a static feature either because it has requested it 121 (and TAPS decide to fulfill this request by a protocol that has a 122 component that implements this feature as static), or the static 123 feature is offered to the application implicitly because TAPS chooses 124 a protocol that implements it. For example, if an application 125 chooses byte-stream-oriented delivery, it automatically also gets 126 reliable delivery. 128 Initialization features can be chosen when communication begins but 129 not adjusted later; this assumes that a TAPS system does not change 130 protocols during a communication session. Examples of initialization 131 features are flow control and congestion control. 133 Dynamic features are changeable during runtime. An example of a 134 dynamic feature is data bundling (Nagle in TCP). 136 Single-sided features can be provided via components that are 137 implemented only on the side where they applications requests the 138 Transport Service. An example of a single-sided feature is data 139 bundling (Nagle in TCP). Both-sided features can only be provided 140 via components that are implemented on both sides. An example is 141 error detection (checksum). Possibly certain features could benefit 142 from, but do not need to be, implemented on both sides. Since the 143 point of categorization is to determine the minimal set of Transport 144 Services that a TAPS system must provide, the essential property of 145 such features is that they *can* be implemented on only one side. 147 2. Terminology (as defined by draft-ietf-taps-transports-04) 149 The following terms are defined throughout this document, and in 150 subsequent documents produced by TAPS describing the composition and 151 decomposition of transport services. 153 Transport Service Feature: a specific end-to-end feature that a 154 transport service provides to its clients. Examples include 155 confidentiality, reliable delivery, ordered delivery, message- 156 versus-stream orientation, etc. 157 Transport Service: a set of transport service features, without an 158 association to any given framing protocol, which provides a 159 complete service to an application. 160 Transport Protocol: an implementation that provides one or more 161 different transport services using a specific framing and header 162 format on the wire. 164 Transport Protocol Component: an implementation of a transport 165 service feature within a protocol. 166 Transport Service Instance: an arrangement of transport protocols 167 with a selected set of features and configuration parameters that 168 implements a single transport service, e.g. a protocol stack (RTP 169 over UDP). 170 Application: an entity that uses the transport layer for end-to-end 171 delivery data across the network (this may also be an upper layer 172 protocol or tunnel encapsulation). 174 3. A list of all features in the considered IETF Transport Protocols 176 [TAPS1] provides a list of known IETF transport protocols and 177 transport protocols frameworks. Here all features from [TAPS1] are 178 listed: 180 o unicast: TCP SCTP UDP-Lite DCCP NORM 181 o IPv6 multicast and anycast: UDP 182 o IPv4 broadcast, multicast and anycast: UDP UDP-Lite 183 o multicast: NORM 185 o unidirectional: UDP 186 o bidirectional: TCP 188 o message-oriented delivery: SCTP UDP UDP-Lite DCCP 189 o byte-stream-oriented delivery: TCP 191 o user message fragmentation and reassembly: SCTP 192 o IPv6 jumbograms: UDP 194 o connection setup with feature negotiation and application-to-port 195 mapping: TCP SCTP DCCP 197 o port multiplexing: TCP SCTP UDP UDP-Lite DCCP 198 o port multiplexing (UDP ports): NORM 199 o 2-tuple endpoints: UDP 201 o transport layer multihoming for resilience: SCTP 203 o transport layer mobility: SCTP 205 o non-reliable delivery: UDP-Lite DCCP 206 o reliable delivery: TCP NORM 207 o reliable or partially reliable delivery: SCTP 208 o drop notification: DCCP 209 o ordered delivery: DCCP 210 o ordered delivery for each byte stream: TCP 211 o ordered delivery for each byte or message stream: NORM 212 o ordered and unordered delivery within a stream (of messages): SCTP 213 o unordered delivery: UDP-Lite UDP 214 o unordered delivery of in-memory data or file bulk content objects: 215 NORM 216 o object-oriented delivery of discrete data or file items: NORM 218 o partial integrity protection: UDP-Lite DCCP 219 o checksum optional: UDP 220 o error detection (checksum): TCP UDP 221 o error detection (UDP checksum): NORM 222 o strong error detection (CRC32C): SCTP 223 o packet erasure coding (both proactively and as part of ARQ): NORM 225 o flow control: TCP SCTP 226 o flow control (slow receiver function): DCCP 227 o flow control (timer-based and/or ack-based): NORM 229 o segmentation: TCP NORM 231 o stream-oriented delivery in a single stream: TCP NORM 232 o support for multiple concurrent streams: SCTP 233 o support for stream scheduling prioritization: SCTP 235 o data bundling (Nagle's algorithm): TCP NORM 236 o user message bundling: SCTP 238 o congestion control: TCP SCTP NORM 239 o no congestion control: UDP 241 o timestamps: DCCP 243 4. Grouping of the features 245 This section presents a grouping of the features from [TAPS1] 246 according to the three categories: functional vs. non-functional; 247 static vs. initialization vs. dynamic; one-sided vs. two-sided. 249 The current version only includes the functional vs. non-functional 250 categorization. The other categories will be included in future 251 versions. 253 4.1. Functional vs. non-functional 255 4.1.1. Functional features 257 What is delivered (delivery type): 259 o message-oriented delivery: SCTP UDP UDP-Lite DCCP 260 o byte-stream-oriented delivery: TCP 261 o object-oriented delivery of discrete data or file items: NORM 263 Reliability of delivery: 265 o non-reliable delivery: UDP UDP-Lite DCCP 266 o reliable delivery: TCP NORM 267 o reliable or partially reliable delivery: SCTP 268 o drop notification: DCCP 270 Direction of communication: 272 o unidirectional: UDP 273 o bidirectional: TCP 275 Ordered or unordered delivery: 277 o ordered delivery: DCCP 278 o ordered delivery for each byte stream: TCP 279 o ordered delivery for each byte or message stream: NORM 280 o ordered and unordered delivery within a stream (of messages): SCTP 281 o unordered delivery: UDP-Lite UDP 282 o unordered delivery of in-memory data or file bulk content objects: 283 NORM 285 Unicast, anycast, multicast or broadcast: 287 o unicast: TCP SCTP UDP UDP-Lite DCCP NORM 288 o IPv6 multicast and anycast: UDP 289 o IPv4 broadcast, multicast and anycast: UDP UDP-Lite 290 o multicast: NORM 292 4.1.2. Non-functional features 294 These are features that the application can optionally specify. If a 295 feature is not specified by the application it is undefined, i.e. the 296 TAPS system may choose an implementation of any of the features 297 listed. 299 Congestion control: 301 o congestion control: TCP SCTP NORM 302 o no congestion control: UDP 304 Resilience: 306 o multihoming: SCTP 307 o no resilience: UDP UDP-lite TCP 309 Connection oriented (or not): 311 o connection oriented: TCP DCCP SCTP 312 o not connection oriented: UDP UDP-Lite 314 Message sizes and fragmentation: 316 o user message fragmentation and reassembly: SCTP 317 o IPv6 jumbograms: UDP 319 Setup negotiation: 321 o connection setup with feature negotiation and application-to-port 322 mapping: TCP SCTP DCCP 324 Flow control: 326 o flow control: TCP SCTP 327 o flow control (slow receiver function): DCCP 328 o flow control (timer-based and/or ack-based): NORM 329 o no flow control: UDP 331 Multiplexing: 333 o multistreaming: SCTP 334 o port multiplexing: TCP SCTP UDP UDP-Lite DCCP 335 o port multiplexing (UDP ports): NORM 336 o 2-tuple endpoints: UDP 337 Transport layer mobility: 339 o transport layer mobility: SCTP 341 Error detection, protection, FEC and integrity (divided into more 342 groups?): 344 o partial integrity protection: UDP-Lite DCCP 345 o checksum optional: UDP 346 o error detection (checksum): TCP UDP 347 o error detection (UDP checksum): NORM 348 o strong error detection (CRC32C): SCTP 349 o packet erasure coding (both proactively and as part of ARQ): NORM 350 o content privacy to in-path devices: ? (intro of [TAPS1]) 352 Streams: 354 o stream-oriented delivery in a single stream: TCP NORM 355 o support for multiple concurrent streams: SCTP 356 o support for stream scheduling prioritization: SCTP 358 Bundling: 360 o data bundling (Nagle's algorithm): TCP NORM 361 o user message bundling: SCTP 363 4.2. Components from draft-ietf-taps-transports-04 that are not 364 specified or seen by the applications 366 Segmentation: 368 o segmentation: TCP NORM 370 Timestamps: 372 o timestamps: DCCP 373 o Service Codes: DCCP 375 5. Acknowledgements 377 This work has received funding from the European Union's Horizon 2020 378 research and innovation programme under grant agreement No. 644334 379 (NEAT). The views expressed are solely those of the author(s). 381 6. IANA Considerations 383 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 385 This memo includes no request to IANA. 387 7. Security Considerations 389 Security will be considered in future versions of this document. 391 8. Normative References 393 [TAPS1] Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 394 provided by IETF transport protocols and congestion control 395 mechanisms", draft-ietf-taps-transports-04 (work in 396 progress), May 2015. 398 Authors' Addresses 400 Stein Gjessing 401 University of Oslo 402 PO Box 1080 Blindern 403 Oslo, N-0316 404 Norway 406 Phone: +47 22 85 24 44 407 Email: steing@ifi.uio.no 409 Michael Welzl 410 University of Oslo 411 PO Box 1080 Blindern 412 Oslo, N-0316 413 Norway 415 Phone: +47 22 85 24 20 416 Email: michawe@ifi.uio.no