Transport-Services M.J. Montpetit Internet Draft MIT Intended status: Informational I. Zhovnirovsky Expires: August 11, 2014 QFactor B. Reuther University of Kaiserslautern February 11, 2014 Transport Services Strawman Architecture draft-montpetit-transport-strawman-01 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html This Internet-Draft will expire on July 27, 2014. Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document presents one possible architecture to provide Montpetit Expires August 11, 2014 [Page 1] Internet-Draft draft-montpetit-transport-strawman January 2014 appropriate transport services to applications. It uses a shim layer between the application and the transports. The transport is chosen via the shim based on parameters that reflect the needs of the applications. Table of Contents 1. Introduction 2. Conventions used in this document 3. Basic Architectural Concepts 3.1 Parameters 3.2 Transport Selection 4. Implementation Aspects 5. Security Considerations 6. IANA Considerations 7. Conclusions 8. References 9. Acknowledgments Montpetit Expires August 11, 2014 [Page 2] Internet-Draft draft-montpetit-transport-strawman January 2014 1. Introduction The need for a new approach to providing transport services has been presented in [3] and corresponding APIs were sketched in [4]. This draft presents a transport-services strawman architecture that relies on a shim layer between an application and the different transports. This is only one approach and of course there could be more than one way to support TAPS. A shim approach may imply some changes to the apps if they communicate directly with it but could leave applications unchanged when they use existing middleware that can interact with the shim. The rest of the draft is dedicated to a summary of the architecture. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[1]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Basic Architectural Concepts It is assumed that there exists a "TAPS shim layer" between an application and the transport services. The purpose of this "shim layer" is to decouple applications from transport protocols. An application may (and should) use the "shim layer" so that the transport protocols become transparent for the application. Thus the "shim layer" is responsible to select and configure the most appropriate transport protocol based on application requirements and other parameters if appropriate. The "TAPS shim layer" may be used only at one side of a communication, thus the "shim layer" must not implement any mandatory protocol on its own. The shim should introduce common mechanisms to a range of applications when these are needed to provide path robustness. Examples include support for dealing with middleboxes traversal, uPNP or MIF functions, methods to leverage PMTUD etc., basic mechanisms that should be done for all transports, but are in practice often only added to TCP. Putting them in the shim enables better integration of generic transport functionality. One embodiment of the functionality is to have the application open a generic socket and then specify some parameters that will allow to select the "best" transport. Montpetit Expires August 11, 2014 [Page 3] Internet-Draft draft-montpetit-transport-strawman January 2014 3.1 Parameters The "TAPS shim layer" will select and configure a transport protocol. This will be done at runtime, i.e. when the application is trying to open a socket (or something similar). At this point in time several parameters might be available that should be considered in order to make a good decision: application requirements, network resources, platform resources and administrative policies. An application has two kinds of requirements: First mandatory requirements; these must be fulfilled, otherwise it is likely that the application does not work correctly; the set of all mandatory requirements define the transport service required by the application. [From my perspective this is one outcome of discussions on "How to identify transport services" on the mailing list]. Second there are optional requirements which should be considered in order to select the most appropriate transport service whenever more than one transport protocol might be used. Defining a list of transport services that will be offered by TAPS is subject of further work. It is likely that the service definition will cover: * reliable transmission (yes or no) * encryption (yes or no) * supported data type: byte stream, packet or message Optional requirements of applications may be: * performance (delay, loss...) * security preference considerations Parameters about network resources may be: * mobile (yes or no) * classification of available bandwidth (high, moderate, low) * classification of expected delay (high, moderate, low) Parameters about platform resources may be: * device feature specifics (battery level or battery requirements, location etc.) * CPU requirements * memory limitations Administrative Policies may be: * use encryption if applicable [From my point of view "Administrative Policies" define requirements which are not defined by the application itself. May be we do not need to mention this, because it can be implemented just by overriding application requirements] 3.2. Transport Service Selection The matching of the parameters to the transports will be part of later versions. Montpetit Expires August 11, 2014 [Page 4] Internet-Draft draft-montpetit-transport-strawman January 2014 In addition the "TAPS shim layer" is also responsible for selecting an alternative transport if the preferred transport can not be used. The "TAPS shim layer" may therefore implement a mechanisms similar to happy eyeballs[2] or may simply use TCP as a fallback if appropriate. It is essential that the mechanisms for transport service selection do not introduce too much delay or network traffic or to much any other kind of resource utilization (for example several parallel connection attempts may cause unnecessary load at the server side) 3.3. Services beyond TCP [We need to discuss how TAPS may support offering transport functionality beyond TCP e.g. TAPS may come with a library implementing an alternative protocol at application layer as a fallback.] 3.4 Error Handling tbd [must be generic] 4. Implementation Aspects This architecture requires to define an interface between the application and the shim and between the shim and the transports. The actual implementation of this interface is outside the scope of an ID, but other topics that may need to be addressed include: * dynamics the best transport could change over time if for example the performance is not acceptable anymore or the location has changed (likely in mobile or wireless); initially a transport could be chosen for a session or being fixed for an application or class of applications * extensibility define how can a new transport can be added without recompiling or rebuilding applications, and changing middleware and shim * scalability the shim implementation may become a bottleneck if not implemented correctly Montpetit Expires August 11, 2014 [Page 5] Internet-Draft draft-montpetit-transport-strawman January 2014 5. Security Considerations None relating to the document. Specific use case security requirements to be detailed later. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Conclusion 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] D. Wing and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. 8.2. Informative References [3] T. Moncaster, Ed. J. Crowcroft, M. Welzl, D. Ros, M. Tuexen, "Problem Statement: Why the IETF Needs Defined Transport Services", draft-moncaster-tsvwg-transport-services-01, December 4, 2013. [4] P. Hurtig, Ed., S. Gjessing, M. Welzl, M. Sustrik, "Transport APIs", draft-hurtig-tsvwg-transport-apis-00, December 15, 2013. 9. Acknowledgments The author would like to thank Michael Welzl for suggestions and technical discussions prior to and during the preparation of this draft. Copyright (c) 2014 IETF Trust and the persons identified as authors. All rights reserved. Montpetit Expires August 11, 2014 [Page 6] Internet-Draft draft-montpetit-transport-strawman January 2014 Authors' Addresses Marie-Jose Montpetit MIT Email: mariejo@mit.edu Igor Zhovnirovsky QFactor Communications Email: iez@qfactor.com Bernd Reuther University of Kaiserslautern Email: breuther@rhrk.uni-kl.de Montpetit Expires August 11, 2014 [Page 7]