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]