Internet Engineering Task Force Attila Mihaly Internet-Draft Lars Westberg Intended status: Informational Robert Skog Expires: September 2015 Ericsson March 6, 2015 Flexibility of Transport Layer Protocols: Use Cases draft-mihaly-tp-flexibility-00.txt Abstract This document argues for increasing the flexibility of the transport layer protocols to be possible to tailor the transport protocols to different needs (today and tomorrow) of different applications and access networks. We discuss various use cases to show that there is a need for transport protocol flexibility. 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. Mihaly Expires September 6, 2015 [Page 1] Internet-Draft Flexible 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. Use Cases......................................................3 2.1. Cloud-based gaming........................................3 2.2. Data-center load-balancer.................................4 2.3. Optimal Web-response......................................5 2.4. Local hosting.............................................5 2.5. Endpoint differentiation..................................6 2.6. Network differentiation...................................6 2.7. Multipath transport.......................................7 2.8. Media transfer............................................7 2.9. Confidentiality, security and encryption..................7 2.10. Sensor communication.....................................8 2.11. Transport layer caching..................................8 3. Summary........................................................8 4. Conventions used in this document..............................9 5. Security Considerations........................................9 6. IANA Considerations............................................9 7. Conclusions....................................................9 8. References.....................................................9 8.1. Normative References......................................9 8.2. Informative References...................................10 9. Acknowledgments...............................................10 1. Introduction This problem statement reflects on the trends that can be identified in relation to the evolution of the transport protocols. TCP has been seen as the single transport protocol solution for many years. Mihaly Expires September 6, 2015 [Page 2] Internet-Draft Flexible Transport Protocol March 2015 However, 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. 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 because the TCP-SYN and SYNACK messages introduce an RTT overhead. Another problem with the TCP relates to the so-called Head-of-Line blocking problem: when a TCP packet is delayed or lost no forthcoming packets may be server to the application layer. This will result in inefficient transfer of the streams in a HTTP2 connection since a low-priority packet could effectively block the transfer of a high-priority one. A general trend is that the new transport protocol features are proposed and implemented in the application space using UDP at the transport layer. The reason is that this provides possibility for fast adaptation of the protocol to the emerging application needs. It is also straightforward to correct potential problems that are observed in the newly implemented protocols by e.g., providing new browser updates. In the following we argue that there are some application and access network related features that should also be supported by transport protocol; moreover, the transport protocol should provide flexibility in utilizing these features. 2. Use Cases 2.1. Cloud-based gaming Today there is no "single" transport protocol that could be used for cloud-based gaming. This is because the game control messages and the rendered video streamed to the client require un-reliable transport. UDP may be used today for this. However, if one would like to include also the other communication with the server, e.g., setup of the game, than this should be done on a reliable transport. Thus, one would need to build a retransmission scheme and likely a congestion control mechanism on the top of UDP. SCTP implementations like libusrsctp supports partial reliability (RFC3758), still SCTP lacks for instance FEC, in which case FEC must be added on the application layer with the risk of suboptimal performance. Note that similar conclusions may be drawn related to other conversational services. For example, there is an rtcweb activity in Mihaly Expires September 6, 2015 [Page 3] Internet-Draft Flexible Transport Protocol March 2015 IETF (cooperating with W3C) targeting plug-in free real-time communication between Web browsers [WEBRTC] that is defining a protocol suite especially for supporting the primitives that are designed by W3C to support this kind of service. Having a transport protocol solution accessible by HTTP that may be configured to support real-time services if needed would result in more simplified design and would provide the extensibility for other web-based services if needed. 2.2. Data-center load-balancer The load-balancer is important for distributing load among the servers in a Cloud. However, to let the load-balancer having an efficient operation, the load-Balancer needs information about the current server load. If one of the servers is highly loaded, the Load-balancer can re-distribute the new session to less loaded servers or inform the orchestrator that new servers needs to be deployed. In general, the above functionality is achieved by using proprietary protocols between the virtual machines in the cloud and Load- balancer. There are, however, cases when the ISPs or mobile operators will have Cloud as a part of their infrastructure, in which case such a solution is not feasible, as shown in Figure 1 Therefore, the protocol should transport an indication about the server load to the load-balancer (LB). This LB entity may also multiplex streams from different Servers to one stream to the same Applications, for efficiency reasons. The load balancer is connected to internet but also has a relation to other server in the same Cloud. We may only need to have a subset of the transport functions in the cloud due to internal security protection with FW, substantial overprovisioned transport compared to path over internet. The above use case highlights the following support from the transport layer protocol used: . Support for the applications to communicate with a load balancer that act as a trusted middlebox on the transport layer . Support for a load-balancer, as a trusted middlebox, to adapt transport protocol to the different network conditions. . Allowing for Cloud specific features for enhancing the interaction of the orchestration system. Mihaly Expires September 6, 2015 [Page 4] Internet-Draft Flexible Transport Protocol March 2015 +------+ +-----------+ | | | Cloud | | | | | |Mobile| | S S | | | +--------+ +-------+ | | | | | |-----+Cellular|----|Network|--------LB-+--+ | | | |Access | | | | | +------+ +--------+ +-------+ +-----------+ Figure 1 Architecture for hosted cloud in a cellular network with a Load Balancer (LB) controlling different Servers (S) 2.3. Optimal Web-response As stated above, TCP may become the bottleneck for web page downloads. The transport layer protocol should be adaptable to web transfers by providing short page load times and fast rendering of information on screen. Some example features achieving that goal are . Using Forward Error Correction (FEC) for trading bandwidth consumption of decreased latency of short transfers of end of files . Using multiplexed stream delivery that on one hand eliminates the head-of-line blocking of TCP, and, on the other hand, makes it possible for differentiated stream transfers over the available resources. These features should be possible to switch on and off on demand, e.g., FEC feature to be switched on only for content of a certain type or a certain size etc. 2.4. Local hosting The mobile operators will have Cloud as a part of their infrastructure, see Figure 1. The local network conditions are dynamically varying over time and different time-scale: peak hour vs night-hour, TCP-bursts<->session. The congestion control of current transport protocols can more or less cope with the fast fluctuations. The transport protocol should be adaptable by re- configuration to slow fluctuation. This makes sense when an application is hosted in a local datacenter where the networking conditions are known. A management interface that allows for reconfiguration of the transport protocol is therefore needed. Mihaly Expires September 6, 2015 [Page 5] Internet-Draft Flexible Transport Protocol March 2015 2.5. Endpoint differentiation Different applications require different end-points congestion control. In TCP several congestion control are available i.e CUBIC and LEDBAT and similar differentiation is also needed in the future. A future transport protocol should be flexible enough to accommodate different congestion control mechanisms, depending on the application that is running on the top of it. If the transport protocol multiplexes streams with different QoS/QoE requirements, then the following has to be supported: . separate congestion handling is needed for each stream with it's own re-transmission function. The parameters of this function shall be controllable by the application . multiplexed transport should represent an aggregated congestion control that maps the aggregated feedback onto the individual streams 2.6. Network differentiation Some applications require differentiated handling also in the different network domains, e.g., on-line gaming and cloud gaming requires expedited forwarding for the control packets. Also, special (low-priority) treatment of background traffic is needed in order to use the bottleneck resources more efficiently (endpoint benefits for such treatment would e.g., be lower price for these types of transfer). However, assuming that the network does some traffic differentiation i.e., treats the packets of the different streams differently, a connection-level differentiation is no longer meaningful in a transport protocol multiplexing different streams. Indeed, the result of differentiation is that the different stream groups undergoing a certain QoS-treatment experience different congestion levels. Thus, a per-stream group congestion avoidance behavior is needed in such cases. Note that there may or may not be traffic differentiation at the bottleneck, depending on the destination, congestion situation etc., in which case a per-connection congestion control is the more efficient solution. A congestion control solution is therefore needed in the transport protocol that is able to react to whether there is traffic differentiation among the streams in the network or not. Mihaly Expires September 6, 2015 [Page 6] Internet-Draft Flexible Transport Protocol March 2015 2.7. Multipath transport The importance of supporting the multi-path feature in a transport protocol has been already realized and proposals exist, e.g., for a Multipath TCP [MPTCP]. Multipath transport may be affectively used e.g., part for bundling WIFi <E access for increased efficiency. Switching some legs ON and OFF (e.g., when going out of the WIFI coverage), which implies some signaling between the endpoint and the network. 2.8. Media transfer The transport protocol should deliver media (video, audio) optimized for different access networks. The deliver should cater for the choice of full download as fast as possible to pacing along with characteristics with access network in the path. The latter would allow a battery-optimized delivery for the mobile clients. 2.9. Confidentiality, security and encryption The end-to-end encryption is more and more prevalent to provide confidentiality for the data transferred. There may be benefits with applying the encryption directly on the transport layer, e.g., elimination of the head-of-line blocking by encryption and protection of the transport layer from unexpected input by third party (change of protocol fields, extension header injection etc.) which is a security hole. There may be cases when the access provider provides transport level performance enhancement solutions to improve the end-to-end quality. However, all these actions are only possible if middleboxes can unencrypt the transport layer. In other cases end-to-end transport layer encryption may not be needed at all. For example, in the case of DRM-protected data transfer applying an additional encryption at the transport layer is redundant. In the case when there is a trust relation between the service provider and network provider (e.g., hosted CDN) this is a valid option from security perspective. A transport protocol should therefore be capable to switch between different encryption methods if needed. Mihaly Expires September 6, 2015 [Page 7] Internet-Draft Flexible Transport Protocol March 2015 2.10. Sensor communication Certain type of sensors may dynamically change the information that is sent to the servers, depending on certain conditions; this may require that different transport layer protocol features should be used in the different cases. For example, a video sensor may have three modes of operation: . Dormant mode, where only keep-alive signals are sent out. Here the requirement for the transport protocol should be lightweight operation for battery savings purpose. . Surveillance mode, where still pictures are sent regularly. . Alert mode (triggered e.g., by movements) when video is streamed. This would require a transport layer protocol optimized for video streaming. 2.11. Transport layer caching Transport layer caching is an interesting caching alternative, which benefits from the fact that it is more generic than an application layer caching solution. Proposals for transport layer caching already exist, see e.g., [TCPSEG]. Note that not all objects are subject of caching, thus the caching property of the transport layer protocol should be controllable by the applications. 3. Summary As we have shown in the use cases in the previous section, transport protocols shall be flexible regarding the following aspects (based on network or application indication): . Switch retransmission mechanisms on and off . Support for the applications to communicate with a trusted middlebox on the transport layer. E.g., receive load information in a load balancer from the servers in a cloud . Support for a trusted middlebox to apply transport protocol enhancements, e.g., be able to support stream (de-)multiplexing feature at a Load balancer . Be able to support transport layer caching if needed . Switch FEC on and off . Change local settings based on received information about the local access network . Apply different congestion control mechanisms for the different streams in the same connection Mihaly Expires September 6, 2015 [Page 8] Internet-Draft Flexible Transport Protocol March 2015 . Accommodate its internal mechanisms (e.g., congestion control) based on indication about utilization of network differentiation . Switch one or more legs of a multipath transfer on and off based on network indication . Switch between different encryption methods . Switch access network specific media transfer on and off . Switch between features based on application request, e.g., switch to battery saving mode . Switch to transport layer segment caching based on application request 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]. 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 The draft includes a set of features and implementation of these features should follow specific design rules allowing for data integrity and confidentiality if needed. See also related description in section 2.9. 6. IANA Considerations This draft presently does not pose any requirements to IANA. 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. Mihaly Expires September 6, 2015 [Page 9] Internet-Draft Flexible Transport Protocol March 2015 8.2. Informative References [WEBRTC] Rtcweb Status Pages, https://tools.ietf.org/wg/rtcweb/charters [MPTCP] Multipath TCP (mptcp) charter: http://datatracker.ietf.org/wg/mptcp/charter/ [TCPSEG] TCP Segment Caching, https://tools.ietf.org/html/draft- sarolahti-irtf-catcp-00 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). Mihaly Expires September 6, 2015 [Page 10] Internet-Draft Flexible Transport Protocol March 2015 Authors' Addresses Attila Mihaly Ericsson H-1117 Budapest, Irinyi Jozsef u 4-20, Hungary Phone: +36-30-486-1730 Email: attila.mihaly@ericsson.com Lars Westberg Ericsson Kista Sweden Email: lars.westberg@ericsson.com Robert Skog Ericsson Kista Sweden Email: robert.skog@ericsson.com Mihaly Expires September 6, 2015 [Page 11]