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]