Internet DRAFT - draft-westberg-tp-compositioning-framework
draft-westberg-tp-compositioning-framework
Internet Engineering Task Force Lars Westberg
Internet-Draft Robert Skog
Intended status: Informational Attila Mihaly
Expires: September 2015 Ericsson
March 6, 2015
Framework for Component-based Transport Layer Protocol
draft-westberg-tp-compositioning-framework-00.txt
Abstract
This document proposes a component-based framework for a future
transport layer protocol in order to allow fast transport protocol
evolution via user space implementations, and to foster competition for
cheap fit-for-the-purpose transport protocols available for all
players.
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 September 6, 2015.
Westberg Expires September 6, 2015 [Page 1]
Internet-Draft Component-based Transport Protocol March 2015
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction...................................................2
2. Component-based framework......................................4
2.1. Overview..................................................4
2.2. Transport layer protocol composition......................6
2.3. Example functions (basic components)......................8
2.4. Selection of a transport layer protocol...................9
2.5. Standardization impact...................................10
2.6. Example: Implicit transport layer protocol negotiation...10
2.7. Example: Adding a new component..........................12
2.8. Related work.............................................13
3. Summary.......................................................14
4. Conventions used in this document.............................14
5. Security Considerations.......................................15
6. IANA Considerations...........................................15
7. Conclusions...................................................15
8. References....................................................15
8.1. Normative References.....................................15
8.2. Informative References...................................15
9. Acknowledgments...............................................16
1. Introduction
Recently there have been more and more proposals, discussions and
architecture work on new transport protocols that are more aligned
with the requirements emerging from the evolution of networked
society, expecting 50+ billion connected devices in near future.
Westberg Expires September 6, 2015 [Page 2]
Internet-Draft Component-based Transport Protocol March 2015
What is generally identified is the need for lower latency of
connection setup and data transfer and in the case of cellular
access, better radio utilization. It has turned out that existing
transport protocols do not provide these features. TCP for instance
has slow connectivity setup and provides inefficient resource
sharing for multiplexed streams of different QoS requirements
because of the Head-of-Line blocking. Recently collected use cases
have demonstrated many other application and access network related
features that should also be supported by a future transport
protocol, which cannot be fulfilled by TCP or any other monolithic
transport protocol [FLEX]. We therefore foresee that the evolution
of transport protocols is a need and we have to provide an
environment that facilitates this evolution. This draft proposes a
framework that enables a fast evolution of the transport layer
protocols.
A trend that is observed today in how the shortcomings of the
transport protocol are 'solved' is that, instead of performing a
standardization process for the new transport features, they are
implemented in the application space on the top of UDP transport
that runs in the kernel space. The advantage is that this speeds up
the innovation on the transport protocol layer and therefore we
believe that user space transport protocol implementations should be
allowed in the eco-system to enable fast evolution in the transport
protocol area. However, this poses a number of requirements, as
discussed in [TLP-EN] , which are summarized below:
. It should be possible to protect against buggy and malicious
transport protocol implementations
. Selection APIs are needed to enable application access to the
different user space transport protocol implementations
. Selection of a consistent transport protocol should be possible
that is supported by both endpoints and also the network
domains on path
. Security of end-to-end communication must be possible to ensure
by the encryption of the transport protocol fields
. Users should be allowed for resource control on the hosts
. All above should not result in significant degradation of
expected TLP performance characteristics
We direct the reader to [TLP-EN] for a detailed reasoning about
these requirements (also complemented with some more requirements
Westberg Expires September 6, 2015 [Page 3]
Internet-Draft Component-based Transport Protocol March 2015
related to middlebox communication, which is now omitted from this
discussion for simplicity).
We complement the above requirements with the goal to create an eco-
system that allows competition in the transport protocol area. This
means to create incentives for many players (including small players
and start-ups) to implement new user space transport protocols.
However, implementation of certain protocol features (e.g.,
congestion control algorithms) is much easier than that of a full
fledge transport protocol. We therefore propose a modular framework
that makes it possible to re-use features designed in the context of
one user space transport layer protocol in another protocol. The
advantage of reusability is less development effort and eliminating
additional risks (e.g., intentional or unintentional mal-function)
of the components. Re-using the same components also simplifies the
control of the components (how this control should be made is TBD).
Designing the transport protocol features for re-usability, however,
represents some additional effort, and can even require potential
standardization.
The goal may be formulated as follows: In the following we make a
first proposal for a transport protocol framework that fulfils the
above requirements and design goal. Some details are still to be
added (TBD) or may even be subject to change.
2. Component-based framework
2.1. Overview
The high-level architectural view of the proposed framework for
transport-layer protocols is shown in Figure 1. Here, an Application
is defined as an entity that uses the transport layer to interact
with a remote Application according to some set of requirements
which should be met by the transport layer. Note that in the
terminology currently used in [TAPS] (which may be subject to
change) the Application requests one or more end-to-end Transport
Service Components (TSC), e.g., reliability, integrity, etc.
Instead of directly opening a socket towards an OS-implemented
protocol, the applications select a user space TLP implementation or
may interface to a Protocol selection/parameter setting interface.
This interface could be the one proposed in the IETF TAPS activity
[TAPS]: the applications signal their needs, and based on this an
appropriate transport protocol or a component list is selected that
accomplishes the list of facilities requested by the APP. Note that
in our terminology used a transport protocol (TP) is an
implementation (using a specific framing/header format) that can
Westberg Expires September 6, 2015 [Page 4]
Internet-Draft Component-based Transport Protocol March 2015
provide one or more different TSCs, while a Transport Protocol
Component (TPC) is an implementation that provides one or more TSCs,
but can work only together with other transport protocols or
components. An example component is the TLS protocol, which provides
confidentiality component on the top of TCP. Also note that a TPC
should not necessarily be pre-compiled software, it can also be a
set of functions and libraries that need to be modified and compiled
to integrate it with other TPs or TPCs.
The advantage of the proposed architecture is that the applications
can use a single API for transport layer protocol selection for all
the different streams with different requirements they handle, but
they are agnostic of the actual protocol that is selected which is
one of the tasks of the protocol selection/parameter handling
interface. The exact information to be communicated through the API
from the Application is TBD. There are basically two alternatives
for this API:
. In one alternative, the Application specifies the specific
protocol function that is needed. For example, in the case of
the congestion avoidance feature, LEDBAT, CUBIC, etc.
. In the other alternative, the Application specifies the effect
of the TSC instead, e.g., low extra delay, pacing based on
bandwidth estimation etc.
Which alternative to use is TBD. A high-level abstraction may be
more flexible. However, it requires a mapping to specific TPC(s) in
the protocol selection API.
The final transport protocol that is selected may be potentially
composed from protocols and components in the user space and/or
kernel space (see 2.2. ). In this way, existing kernel-space
implementations may be re-used.
Westberg Expires September 6, 2015 [Page 5]
Internet-Draft Component-based Transport Protocol March 2015
+-----------+ +-----------+ +-----------+
|Application| |Application| |Application|
+-^---------+- +----^------+ +-----^-----+
| | |
| | |
| +----------v------------+ |
| |Protocol Selection/ | |
| |Parameter setting API | |
| +----------^------------+ |
| | |
| | |
| +---------------v-----------------v--+
| | |
| | +---+ +---+ +----+ +----+ |
| | |TP1| |TP2|... |TPC1| |TPC2|... |
| | +---+ +---+ +----+ +----+ |
| +-+---+---+---+-^--+----+--+----+----+
| |
| |
+-v------------------v------------------------+
| (Operating System) |
| +---+ +---+ +----+ +----+ |
| |TCP| |UDP| ... |TPC3| |TPC4| ... |
| +---+ +---+ +----+ +----+ |
+----+---+---+---+-----+----+--+----+---------+
Figure 1 : Protocol framework overview in the layered architecture
(to be transformed in ASCII art after agreed on)
2.2. Transport layer protocol composition
A transport layer protocol in this framework may be composed either
of
. One pre-compiled user-space transport protocol and zero or more
user-space components
Westberg Expires September 6, 2015 [Page 6]
Internet-Draft Component-based Transport Protocol March 2015
. One kernel-space transport protocol and zero or more user-space
components
. One or more components either from the user space or the kernel
space
Both the pre-compiled transport protocols and components are
composed of some basic components, referred to as functions, as
shown in Figure 2. In the figure the protocol is composed by two
such functions. Each of the functions has a set of parameters that
describe a set of options for that function. Each of these functions
also has a number of associated protocol fields where they can send
information relevant for that function. Last but not least there is
a unique ID that identifies the set of functions the given transport
protocol encompasses.
+---------+
|Unique ID|
+--^---^--+
| |
+-------+ +------+
| |
+--------v---+ +---v--------+
|"Function A"| |"Function B"|
+---^-----^--+ +---^----^---+
| | | |
+--------+ | | +-----------+
| | | |
+----v-----+ +---v----+ +----v-----+ +-----v--+
|Parameters| |Protocol| |Parameters| |Protocol|
+----------+ |fields | +----------+ |fields |
+--------+ +--------+
Figure 2 Example protocol composition
Some functions that were identified from the flexibility
requirements listed in [FLEX] are listed in 2.3. By pre-compilation,
however, some functions may be more efficiently integrated forming a
multi-functional component or protocol, e.g., by building integrated
APIs between the functions, optimizing the protocol header etc.
this is depicted by the example protocol header structure shown in
Figure 3: there may be protocol fields that are relevant for the
Westberg Expires September 6, 2015 [Page 7]
Internet-Draft Component-based Transport Protocol March 2015
combination of functions A and B, while there may be fields specific
only to A or B, respectively. Note that there may also be protocol
fields specific for function A or function B that, however, will be
completely missing from the composed protocol. Note that the unique
ID could just be placed in one of the fields of the 'base' transport
protocol, e.g., it could be the UDP port number. Proper inter-
operability requires that the rules for generating the frame format
for a certain composition are standardized.
+-------+----------------+---------------+-----------------+-------+
|Unique |Protocol fields |Protocol fields|Protocol fields |Payload|
|ID |for "Function A"|for "A&B" |for "Function "B"| |
+-------+----------------+---------------+-----------------+-------+
Figure 3 Example protocol header structure for the example protocol
composition in Figure 2.
The framework also allows for a run-time composition of a pre-
compiled (set of) components and a kernel-space protocol, e.g., UDP,
to build the final transport layer protocol. The pre-requisite for
the components that could form a transport protocol in run-time is a
well-defined API through which they can inter-operate.
Transport protocols and components may be added both in the user
space and in the kernel space. Most likely the new
protocols/components will first be developed in the user space. The
reason is that one cannot predict with 100% accuracy how certain
functions will behave in real life. In the long run, as the
components become stable it can be possible (and beneficial) to move
certain parts to the OS kernel. For example, packet pacing might run
not too efficiently in the user plane. Also, some kind of kernel
policing on a user plane implementation might be in kernel due to
security considerations.
Composing a new transport layer protocol should also be
straightforward according to the extensibility requirement.
Connecting a new component is possible either in run-time, if it has
an API allowing that, or a new user-space transport protocol may be
re-compiled using the libraries for the new component. See an
example in section 2.7.
2.3. Example functions (basic components)
Given the set of flexibility use cases to fulfill in [FLEX], so far
we have identified the following functions:
. FEC
Westberg Expires September 6, 2015 [Page 8]
Internet-Draft Component-based Transport Protocol March 2015
. Re-transmission(Reliable/unreliable transport)
. Congestion control
. Keep alive for NAT
. Balloon buffers, i.e., support for larger buffers for Lower-
than-Best-Effort (LBE) traffic
. Caching, i.e., transport layer caching
. Change transport parameter settings externally
. Application meta-data communication
. Data-center trunking
. Security
. Multi-path
How and where these functions are implemented in the clients is TBD.
Likely, some functions should be provided by the operating system
either because they should act on the top of potentially different
transport protocol implementations (e.g., policy control enforcing
transport protocol behavior) or because they are time-critical
processing components (e.g., packet shaping).
2.4. Selection of a transport layer protocol
As stated above, the selection of a specific transport protocol to
use is the role of the protocol selection/parameter settings
interface. The selection has two phases:
1. Identification of the components needed
2. Negotiation and selection of the transport protocol to be used
and its parameters
The first phase is based on the communication with the application
requiring the transport protocol. This API (described in Section
2.1. ) has to be standardized (currently the TAPS activity is
targeting the standardization of a similar interface).
In the second phase, the two end-points use some kind of TLPN
(Transport Layer Protocol Negotiation) mechanism to negotiate what
transport protocol they support and can agree to use.
Westberg Expires September 6, 2015 [Page 9]
Internet-Draft Component-based Transport Protocol March 2015
The identification of the transport protocol will be based on a
unique ID that reflects the set of functions the given transport
protocol encompasses. This ID also makes the cooperation between
endpoints possible on selecting a common set of functions. This
unique ID or the method how this ID is generated as well as the
fallback options have to be standardized. There can be a 'base'
transport protocol defined that is to be supported in all clients
and may thus serve as ultimate fall-back. The base could be plain
UDP with maybe some selected components, TBD which ones.
For a certain transport protocol instance selected, the parameters
to use as options for the different functions should also be also
negotiated. An example setup message then contains the unique ID for
the function as well as the parameter set proposals for each of the
functions. This is shown in Figure 4. Note that there may be a set
of default parameters defined for each of the functions; this may
shorten the negotiation delay in most of the cases.
The exact functionality of TLPN is TBD and it requires
standardization.
+---------++----------+----------+
|Unique ID||Parameters|Parameters|
+---------++----------+----------+
Figure 4 Example setup message format for the composed protocol in
Figure 2
2.5. Standardization impact
Here we summarize the minimum standardization needs for the
framework presented above:
. The framing structure, e.g., the basic header structure
. The protocol negotiation (TLPN) mechanism
. A generic component identification framework, e.g., IANA
registration and TLV structures that also allow for
experimentation
. Some of the components
2.6. Example: Implicit transport layer protocol negotiation
Below we present a method for protocol negotiation that does not
require a specific control plane signaling between the communicating
hosts. The process is exemplified in Figure 5:
Westberg Expires September 6, 2015 [Page 10]
Internet-Draft Component-based Transport Protocol March 2015
. The client on the left hand side (the Initiator) initiates a
communication towards the other client (the Receiver), by
initially selecting a TP consisting of the components "A" and "B".
It already starts sending also payload packets, the header
containing the set of expected protocol fields, and some default
parameters.
. The Receiver receives the first setup message and it checks the
ID. It recognizes that it does not support the TP represented by
ID1, but using the standard identification it is able to identify
its components and select the closest supported one, which in this
example is the TP having function "A" alone. It also knows from
the standardized encapsulation framework where the parameters and
protocol fields for function "A" are encoded so it can read and
interpret them.
. Receiver answers with packets that are composed according to the
semantics of TP "A", using ID2 and the corresponding protocol
fields.
. Upon receiving the first packet from Receiver, by checking the ID
(ID2), Initiator recognizes that Receiver has selected TP "A" and
will continue the communication by using function "A" only.
Parameter negotiation messages may also be exchanged at this
point.
Note that the above negotiation process does not add any additional
delay to the setup delay of the transport protocol.
Westberg Expires September 6, 2015 [Page 11]
Internet-Draft Component-based Transport Protocol March 2015
+---------+ +---------+
|Initiator| |Receiver |
+---------+ +---------+
| |
| +-------+------------+------------+------------+---------+ |
| | ID1 |Proto fields|Proto fields|Proto fields|Payload X| |
| |("A&B")|for "A" |for "A&B" |for "B" | | |
| +--------------------------------------------------------+ |
|----------------------------------------------------------->|
| |
| +------------------------+
| |If ID1 is not supported,|
| |read and interpret para-|
| |meters & fields for "A" |
| +-----------------------------+ +------------------------+
| | ID2 |Proto fields|Payload Y| |
| | ("A")|for "A" | | |
| +-----------------------------+ |
|<-----------------------------------------------------------|
| |
+----------------------+ |
|Continue communication| |
|using function A only | |
+----------------------+ |
|
Figure 5 example of an implicit TLPN
2.7. Example: Adding a new component
By still keeping the high-level of abstraction in the description,
we try to exemplify how we envision the deployment 'story' of a new
(previously inexistent) component to an existing transport protocol.
Let us assume that the transport protocol currently implements the
function "A" from Figure 2, and somebody wants to add function "B"
to it.
1. In the first, experimenting phase the optimal design of the
feature is researched. For this any proprietary implementation
for function "B" may be used. The standard prescription for the
encapsulation framework would guide the design of the header of
the combined protocol to the form in Figure 3, where the fields
Westberg Expires September 6, 2015 [Page 12]
Internet-Draft Component-based Transport Protocol March 2015
for the function A are identical with that of the original
transport protocol, even if some are redundant or common with
function "B". In this phase an ID for "local use" is assigned
for the new protocol. The output of this phase is the internal
mechanism and the parameter set for the function B as well as a
potential re-design of Function A.
2. If the new protocol is proven benefits, then an "experimental"
ID is registered for the composed protocol in such a way that
the TLPN mechanism would fall back to the usage of the original
transport protocol for hosts that cannot interpret it. At this
stage the new protocol may be used in all the internet hosts
and servers of the designer along with the 'legacy' protocol
"A". That is, the framework provides the means to keep backward
compatibility with the old protocol, a feature that should have
been catered for anyhow for any proprietary implementation.
3. The concept for the new protocol including feature B and the
related ID may be made public and the implementation
potentially open source. Others may start experimenting with
the new protocol, either using the original implementation or
their own. Inter-working between the different implementations
is possible, given that the encapsulation, identification and
selection rules are fulfilled.
4. The community agrees on the functionality, parameter set for
the new compositions and impacts on function A. At this point
it also becomes possible to propose specific header format
e.g., removing some unnecessary components of Function "A" from
the composed TP header. The setup message format similar to
that in Figure 4 is also agreed on. A new unique ID identifying
the new transport protocol is registered in IANA. The
registered ID provides 'knowledge' and thus some guarantee for
network friendliness for the middleboxes. Note that there are
two options for the "standard" IDs: mandatory to implement or
optional to implement. The former may be used as fall-back in
the cases when a given combination is not implemented in the
hosts.
2.8. Related work
As mentioned above, there is an on-going activity and WG in IETF
targeting the definition of a transport-layer interface exposed to
the applications, on which, instead of specifying a protocol, a
'transport service' is specified [TAPS]. The primary scope for the
Westberg Expires September 6, 2015 [Page 13]
Internet-Draft Component-based Transport Protocol March 2015
activity is to make it possible to select the best transport
protocol implementation for the applications, i.e., to use the
existing transport protocol implementations in the clients, which
are currently never of seldom used.
An EU horizon 2020 activity proposal goes beyond this scope
proposing to solve issues for NAT traversal, Path MTU discovery and
falling back to a semantically-equivalent service in the selection
layer, i.e., completely hidden from the application [NEAT] .
Componentization of transport protocol features, multi-vendor,
extension and reuse aspects act are not considered.
Another IETF WG handles small TCP changes, i.e., minor extensions to
TCP algorithms and protocol mechanisms [TCPM]. The WG mostly focuses
on maintenance issues (e.g., bug fixes) and modest changes to the
protocol, algorithms, and interfaces that maintain TCP's utility.
The WG is also a venue for moving current TCP specifications along
the standards track (as community energy is available for such
efforts). Similar aspects are discussed, i.e., how to build a
feature on the top of existing protocol (TCP in this case), how to
provide proper interworking and fall-back, etc.
3. Summary
In this document we suggest a framework that supports adding user
space transport protocol features and re-using existing protocol
components in the design of new transport protocol. This does not
only speeds up transport protocol evolution, but also allows for a
healthy competition of different protocol implementations for the
same transport service.
The intended next step in this process is a concrete specification
of a framework implementation, building on a standardized transport
protocol as base protocol, and specification of one of more specific
functions that would build on this protocol.
4. 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 [RFC2119].
Westberg Expires September 6, 2015 [Page 14]
Internet-Draft Component-based Transport Protocol March 2015
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.
5. Security Considerations
TBD
6. IANA Considerations
IANA definition of protocol IDs, as described in section 2.
7. Conclusions
TBA
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[FLEX] Flexibility of Transport Layer Protocols: Problem Statement
draft-mihaly-TP-flexibility-00.txt
[TLP-EN] Enablers for Transport Layer Protocol Evolution, draft-
mihaly-requirements-for-TLP-evolution-00.txt
[TAPS] Transport Services Charter,
https://datatracker.ietf.org/doc/charter-ietf-taps/
[NEAT] A New, Evolutive API and Transport Architecture for the
Internet (NEAT), project proposal to Call ICT 5-2014
'Smart Networks and Novel Internet Architectures", on the
Horizon 2020 Work programme
[TCPM] TCP Maintenance and Minor Extensions charter,
http://datatracker.ietf.org/wg/tcpm/charter/
Westberg Expires September 6, 2015 [Page 15]
Internet-Draft Component-based Transport Protocol March 2015
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Copyright (c) 2015 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Westberg Expires September 6, 2015 [Page 16]
Internet-Draft Component-based Transport Protocol March 2015
Authors' Addresses
Lars Westberg
Ericsson
Kista
Sweden
Email: lars.westberg@ericsson.com
Robert Skog
Ericsson
Kista
Sweden
Email: robert.skog@ericsson.com
Attila Mihaly
Ericsson
Budapest
Hungary
Email: attila.mihaly@ericsson.com
Westberg Expires September 6, 2015 [Page 17]
