idnits 2.17.1 draft-montpetit-transport-strawman-01.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 11, 2014) is 3719 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6555 (ref. '2') (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport-Services M.J. Montpetit 3 Internet Draft MIT 4 Intended status: Informational I. Zhovnirovsky 5 Expires: August 11, 2014 QFactor 6 B. Reuther 7 University of Kaiserslautern 8 February 11, 2014 10 Transport Services Strawman Architecture 11 draft-montpetit-transport-strawman-01 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on July 27, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document presents one possible architecture to provide 49 appropriate transport services to applications. It uses a shim 50 layer between the application and the transports. The transport 51 is chosen via the shim based on parameters that reflect the needs 52 of the applications. 54 Table of Contents 56 1. Introduction 58 2. Conventions used in this document 60 3. Basic Architectural Concepts 61 3.1 Parameters 62 3.2 Transport Selection 64 4. Implementation Aspects 66 5. Security Considerations 68 6. IANA Considerations 70 7. Conclusions 72 8. References 74 9. Acknowledgments 75 1. Introduction 77 The need for a new approach to providing transport services has been 78 presented in [3] and corresponding APIs were sketched in [4]. This 79 draft presents a transport-services strawman architecture that 80 relies on a shim layer between an application and the different 81 transports. This is only one approach and of course there could be 82 more than one way to support TAPS. A shim approach may imply 83 some changes to the apps if they communicate directly with it 84 but could leave applications unchanged when they use existing 85 middleware that can interact with the shim. The rest of the 86 draft is dedicated to a summary of the architecture. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC-2119[1]. 94 In this document, these words will appear with that interpretation 95 only when in ALL CAPS. Lower case uses of these words are not to be 96 interpreted as carrying RFC-2119 significance. 98 3. Basic Architectural Concepts 100 It is assumed that there exists a "TAPS shim layer" between an 101 application and the transport services. The purpose of this "shim 102 layer" is to decouple applications from transport protocols. An 103 application may (and should) use the "shim layer" so that the 104 transport protocols become transparent for the application. Thus the 105 "shim layer" is responsible to select and configure the most 106 appropriate transport protocol based on application requirements and 107 other parameters if appropriate. 109 The "TAPS shim layer" may be used only at one side of a 110 communication, thus the "shim layer" must not implement any mandatory 111 protocol on its own. 113 The shim should introduce common mechanisms to a range of applications 114 when these are needed to provide path robustness. Examples include 115 support for dealing with middleboxes traversal, uPNP or MIF functions, 116 methods to leverage PMTUD etc., basic mechanisms that should be done 117 for all transports, but are in practice often only added to TCP. 118 Putting them in the shim enables better integration of generic 119 transport functionality. 121 One embodiment of the functionality is to have the application open 122 a generic socket and then specify some parameters that will allow to 123 select the "best" transport. 125 3.1 Parameters 127 The "TAPS shim layer" will select and configure a transport protocol. 128 This will be done at runtime, i.e. when the application is trying to 129 open a socket (or something similar). At this point in time several 130 parameters might be available that should be considered in order to 131 make a good decision: application requirements, network resources, 132 platform resources and administrative policies. 134 An application has two kinds of requirements: First mandatory 135 requirements; these must be fulfilled, otherwise it is likely that 136 the application does not work correctly; the set of all mandatory 137 requirements define the transport service required by the 138 application. [From my perspective this is one outcome of discussions 139 on "How to identify transport services" on the mailing list]. Second 140 there are optional requirements which should be considered in order 141 to select the most appropriate transport service whenever more than 142 one transport protocol might be used. 144 Defining a list of transport services that will be offered by TAPS 145 is subject of further work. It is likely that the service definition 146 will cover: 147 * reliable transmission (yes or no) 148 * encryption (yes or no) 149 * supported data type: byte stream, packet or message 151 Optional requirements of applications may be: 152 * performance (delay, loss...) 153 * security preference considerations 155 Parameters about network resources may be: 156 * mobile (yes or no) 157 * classification of available bandwidth (high, moderate, low) 158 * classification of expected delay (high, moderate, low) 160 Parameters about platform resources may be: 161 * device feature specifics (battery level or battery requirements, 162 location etc.) 163 * CPU requirements 164 * memory limitations 166 Administrative Policies may be: 167 * use encryption if applicable 168 [From my point of view "Administrative Policies" define requirements 169 which are not defined by the application itself. May be we do not 170 need to mention this, because it can be implemented just by 171 overriding application requirements] 173 3.2. Transport Service Selection 175 The matching of the parameters to the transports will be part of 176 later versions. 178 In addition the "TAPS shim layer" is also responsible for selecting 179 an alternative transport if the preferred transport can not be used. 180 The "TAPS shim layer" may therefore implement a mechanisms similar to 181 happy eyeballs[2] or may simply use TCP as a fallback if appropriate. 182 It is essential that the mechanisms for transport service selection 183 do not introduce too much delay or network traffic or to much any 184 other kind of resource utilization (for example several parallel 185 connection attempts may cause unnecessary load at the server side) 187 3.3. Services beyond TCP 189 [We need to discuss how TAPS may support offering transport 190 functionality beyond TCP e.g. TAPS may come with a library 191 implementing an alternative protocol at application layer as a 192 fallback.] 194 3.4 Error Handling 196 tbd [must be generic] 198 4. Implementation Aspects 200 This architecture requires to define an interface between the 201 application and the shim and between the shim and the transports. 202 The actual implementation of this interface is outside the scope 203 of an ID, but other topics that may need to be addressed include: 204 * dynamics 205 the best transport could change over time if for example the 206 performance is not acceptable anymore or the location has changed 207 (likely in mobile or wireless); initially a transport could be 208 chosen for a session or being fixed for an application or class 209 of applications 210 * extensibility 211 define how can a new transport can be added without recompiling 212 or rebuilding applications, and changing middleware and shim 213 * scalability 214 the shim implementation may become a bottleneck if not implemented 215 correctly 217 5. Security Considerations 219 None relating to the document. Specific use case security 220 requirements to be detailed later. 222 6. IANA Considerations 224 This document makes no request of IANA. 226 Note to RFC Editor: this section may be removed on publication as an 227 RFC. 229 7. Conclusion 231 8. References 233 8.1. Normative References 235 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 236 Levels", BCP 14, RFC 2119, March 1997. 238 [2] D. Wing and A. Yourtchenko, "Happy Eyeballs: Success with 239 Dual-Stack Hosts", RFC 6555, April 2012. 241 8.2. Informative References 243 [3] T. Moncaster, Ed. J. Crowcroft, M. Welzl, D. Ros, M. Tuexen, 244 "Problem Statement: Why the IETF Needs Defined Transport 245 Services", draft-moncaster-tsvwg-transport-services-01, 246 December 4, 2013. 248 [4] P. Hurtig, Ed., S. Gjessing, M. Welzl, M. Sustrik, "Transport 249 APIs", draft-hurtig-tsvwg-transport-apis-00, 250 December 15, 2013. 252 9. Acknowledgments 254 The author would like to thank Michael Welzl for suggestions and 255 technical discussions prior to and during the preparation of 256 this draft. 258 Copyright (c) 2014 IETF Trust and the persons identified as authors. 259 All rights reserved. 261 Authors' Addresses 263 Marie-Jose Montpetit 264 MIT 265 Email: mariejo@mit.edu 267 Igor Zhovnirovsky 268 QFactor Communications 269 Email: iez@qfactor.com 271 Bernd Reuther 272 University of Kaiserslautern 273 Email: breuther@rhrk.uni-kl.de