Internet DRAFT - 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


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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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
   ( 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

   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

   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|... |
     |  | +---+   +---+    +----+  +----+    |
     |  +-+---+---+---+-^--+----+--+----+----+
     |                  |
     |                  |
   | (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

     . 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

     . One or more components either from the user space or the kernel

   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

   |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
   . 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

   . 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

   . 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

   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

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",
   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


6. IANA Considerations

   IANA definition of protocol IDs, as described in section 2.

7. Conclusions


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

   [TLP-EN] Enablers for Transport Layer Protocol Evolution, draft-

   [TAPS] Transport Services Charter,

   [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,

Westberg              Expires September 6, 2015               [Page 15]
Internet-Draft    Component-based Transport Protocol         March 2015

9. Acknowledgments

   This document was prepared using

   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

Westberg              Expires September 6, 2015               [Page 16]
Internet-Draft    Component-based Transport Protocol         March 2015

Authors' Addresses

   Lars Westberg


   Robert Skog


   Attila Mihaly


Westberg              Expires September 6, 2015               [Page 17]