Internet DRAFT - draft-mihaly-tp-flexibility
draft-mihaly-tp-flexibility
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]
