Internet DRAFT - draft-petlund-latency-transport-services
draft-petlund-latency-transport-services
Transport-Services A. Petlund
Internet-Draft Simula Research Laboratory
Intended status: Informational February 14, 2014
Expires: August 18, 2014
Transport Services and low latency
draft-petlund-latency-transport-services-00
Abstract
This document categorises different classes of network latency,
discusses possible metrics for determining the characteristics of
latency-sensitive flows and addresses the use of transport services
as a means for achieving transport latency reduction.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Copyright (c) 2014 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Petlund Expires August 18, 2014 [Page 1]
Internet-Draft Transport Services and low latency February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Time-dependent applications . . . . . . . . . . . . . . . . . 2
2.1. On the characteristics of latency-sensitive traffic . . . 3
3. Challenges in identifying traffic characteristics . . . . . . 4
4. Examples of choices of protocols and options that influence
latency . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Protocols . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Options and mechanisms . . . . . . . . . . . . . . . . . 6
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Modern operating systems provide a myriad of different protocols and
options to tweak the network performance. Even for veterans within
the field of transport protocols it is hard to stay fully up to date
on all possibilities and combinations of options that may help reduce
latency for a networked application. Also, care needs to be taken so
that the transport protocols and options chosen will not be
disruptive to other services or to an application if it changes
network behaviour. For application developers in general to be able
to select the best possible subset of mechanisms and protocols to
support their time-dependent networked application, a measure of
abstraction is required. This document discusses different classes
of network latency with examples of how to reduce the delay for each
class. It also makes suggestions for how an application can specify
its intended behaviour to the transport services as a foundation for
optimising the underlying services with regard to latency.
1.1. Requirements Language
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].
2. Time-dependent applications
While completion time for bulk data transfer is deemed important, the
focus of industry and research has lately shifted towards
understanding the diversity of Internet traffic today. Many flows
Petlund Expires August 18, 2014 [Page 2]
Internet-Draft Transport Services and low latency February 2014
are in some way application limited, that is, their sending pattern
is not exclusively determined by congestion control, but also by the
timing of data received from the application. Such applications are
in many cases time-dependent, since the events driving the data
production is triggered by real-life interaction or events [AP09].
While downloading applications dominated the Internet for a long
time, overprovisioning in backbone networks has allowed interactive
applications to succeed. Audio and video conferences that previously
required leased lines are conducted over the Internet. Multiplayer
games that are played over the Internet are also prevalent. Even Web
applications generate increasingly interactive Internet traffic as
more web pages are generated dynamically and contain interactively
updated elements. The flows of such time-dependent applications now
represent a large proportion of the total number of flows in the
Internet. These flows have to tackle a large variety of access
network technologies, all with different characteristics. Depending
on the type of application, "low latency" may carry several meanings
from a transport viewpoint. The next section elaborates on different
classes of latency.
2.1. On the characteristics of latency-sensitive traffic
The scenarios described in this section are derived from a set of
known latency-creating factors from which networked applications
suffer. These categories are not exclusive, an application may
suffer from more than one of them. They are, however,
distinguishable at the transport layer and may require different
avoidance techniques. The main categories of application latency
that have been identified so far are:
(1) Real-time interaction for applications with a lasting duration:
(a) Per-packet latency: applications that have signalling-like
communication driven by actions or events. Each small
message is equally important and congestion-control is not
applied as there is never a queue building on the sender
side. Examples include sensors triggered by events or
online gaming traffic.
(b) Per-burst latency: interactive elements are sent in bursts
over a persistent connection. Collapsing the congestion
window (cwnd) between bursts will reduce the per-burst
completion time and increase the delivery latency for a
burst while keeping the cwnd open may cause overestimation
of the available bandwidth. Examples include video
streaming over persistent connections and financial
Petlund Expires August 18, 2014 [Page 3]
Internet-Draft Transport Services and low latency February 2014
applications synchronised by trading synchronisation
barriers.
(c) Per-burst latency with multiple reconnects: is the above
scenario, but where the streams makes new connections with
regular intervals. This behaviour aggravates the bursty
scenario by adding connection initialisation latency and
start-up latency to each newly initialised connection.
Examples include several methods of adaptive TCP-based
video streaming and Web-based Content Management Systems.
(2) Start-up latency: the time it takes for a connection to find its
correct send-rate. The faster the correct bandwidth can be
determined and the flow assume the correct send rate, the lower
the latency. Examples include non-adaptive high-quality video-
on-demand delivery and Cloud-based office applications.
(3) Flow completion time: when a browser opens a range of different
connections when loading a specific webpage, the latency
experienced by the user is determined by the completion time of
the subflows. Very often, such flows are very small, often not
more then one packet, thus motivating measures like increasing
the initial window. Examples include heavily styled web pages,
messaging systems and news tickers, but this problem affects
also interactive web browsing.
There is also the latency induced by extra RTTs needed to set up a
connection, for instance to initiate a security protocol or to
negotiate options.
There are flows that fluctuate between the behaviours described
above. In such cases, care must be taken to not blindly apply
mechanisms that will reduce the latency for one of the cases, but
increase latency for others. In addition, some particular
applications suffer more when there is a large variation in latency
(jitter) than from a somewhat higher mean latency. This includes
applications with real-time interaction, such as on-line games. In
general, latency is characterised by a number of features including
its higher order moments and distribution. The most important set of
features varies between different latency-sensitive applications.
There is a need to consider all of these traffic behaviours to
properly address the topic of latency for transport services.
3. Challenges in identifying traffic characteristics
It can be hard to reliably identify the flow characteristics from the
viewpoint of the transport layer. At the time when a flow starts,
the transport can make no assumptions about what its traffic patterns
Petlund Expires August 18, 2014 [Page 4]
Internet-Draft Transport Services and low latency February 2014
can be [MF14] (AP: unless guessing from 5-tuple). In order for the
transport to make qualified decision on which protocols and options
to apply for a given flow to reduce latency, more information must be
provided to the transport:
(1) The transport service tries to identify the traffic
characteristics of the flow. This is a possibility for long-
lasting flows that can be instrumented by the transport service.
Such monitoring is, however, challenging since the experienced
behaviour is dependent network characteristics like RTT and
bottleneck capacity.
(2) The application informs the transport layer about its intended
behaviour. For short flows and reducing startup latency, this
is the only option as no information are yet available about the
flow's characteristics.
For the transport layer to be able to identify relevant traffic
characteristics, it is useful to review the metrics that are
available to the transport layer. Examples of metrics are:
(1) Packets in flight: "FLIGHT SIZE", according to the TCP
congestion control specification [RFC5681], is the number of
packets that have been transmitted, but not yet acknowledged.
For efficient retransmissions, in reliable protocols, this is an
important metric as a flow with less than 4 packets in flight
cannot trigger a fast retransmission. This leads to high
recovery delays for many application-limited flows. Packets in
flight is, however, not a static indicator of traffic behaviour
as it is dependent on the RTT of the connection.
(2) Packet intertransmission time: the rate by which the application
delivers data to the transport layer over time gives an
indication of the traffic characteristics of the application. A
constantly application-limited flow will not need a tuned
congestion control, but will be sensitive to recovery delays as
discussed in the bullet about "Packets in flight".
(3) Payload size: the payload size is application-specific and does
not relate to any network phenomena. Time-dependent, event
driven traffic often send packets with payload sizes less than
the maximum transmission unit (MTU)[AP09]. For greedy streams,
the packets will all fill an MTU.
(4) Stream duration: Analysis of Internet traffic shows that a
majority of the flows are very short in duration[MF14]. When a
browser loads a webpage, dozens of connections are usually
opened, each transferring a small part of the webpage content.
Petlund Expires August 18, 2014 [Page 5]
Internet-Draft Transport Services and low latency February 2014
Streams carrying event-based or interactive communication, on
the contrary, are usually persistent and longer-lasting. Thus,
measuring whether a stream terminates within a short time
interval (less than one second) can provide information that may
help predict the continued behaviour of the flow.
(5) Burstiness: if a flow has a traffic pattern with bursts of
activity followed by periods of inactivity, getting up to speed
quickly in the active periods will be important to the
application. The size of each burst is also relevant to the
choices made by the transport layer.
(6) Send queue backlog: a flow that is network limited will build a
send queue while waiting for data to be transferred. By
monitoring the send queue size, the transport layer can get
relevant information about the flow.
The combination of information provided by the above listed metrics
may help the transport services to make qualified decisions on the
flow characteristics and choose the right services for reducing
latency.
4. Examples of choices of protocols and options that influence latency
List examples of protocols and options that influence latency.
4.1. Protocols
Examples of protocols with a short discussion on latency
implications.
o TCP:
o UDP:
o SCTP:
o Other: DCCP ++?
4.2. Options and mechanisms
Examples of protocol options and mechanisms with a short discussion
on their influence on latency.
o Nagle's algorithm (delays small packets)
o Delayed ACKs (delays feedback)
Petlund Expires August 18, 2014 [Page 6]
Internet-Draft Transport Services and low latency February 2014
o Limited transmit
o Early retransmit
o RTO restart
o New CWV
o TFO
o PRSCTP
5. Discussion
Whether properties should be submitted by the applications in
addition to services is an item for discussion and should be treated
in future revisions of the document.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
This document does not raise any new security issues.
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.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
8.2. Informative References
[AP09] Petlund, A., "Improving Latency for interactive, thin-
stream applications over reliable transport", Thesis
Unipub, Kristian Ottosens hus, Pb. 33 Blindern, 0313
Oslo, December 2009.
[MF14] Fuchs, M., "Time-Dependent Thin Transport Layer Streams:
Characterization, Empirical Observation and Protocol
Support", Master Thesis University of Kaiserslautern,
Germany, January 2014.
Petlund Expires August 18, 2014 [Page 7]
Internet-Draft Transport Services and low latency February 2014
Author's Address
Andreas Petlund
Simula Research Laboratory
Rolfsbukta 4 B,
Fornebu 1364
Norway
Phone: +47 99 27 36 22
Email: apetlund@simula.no
Petlund Expires August 18, 2014 [Page 8]
