Internet DRAFT - draft-mcquistin-taps-low-latency-services
draft-mcquistin-taps-low-latency-services
TAPS Working Group S. McQuistin
Internet-Draft C. Perkins
Intended status: Informational University of Glasgow
Expires: May 4, 2017 M. Fayed
University of Stirling
October 31, 2016
Transport Services for Low-Latency Real-Time Applications
draft-mcquistin-taps-low-latency-services-00
Abstract
This document describes the set of transport services required by
low-latency, real-time applications. These services are derived from
the needs of the applications, rather than from the current
capabilities of the transport layer. An example API, based on the
Berkeley Sockets API, is also provided, alongside examples of how the
target applications would use the API to access the transport
services described.
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 May 4, 2017.
Copyright Notice
Copyright (c) 2016 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
McQuistin, et al. Expires May 4, 2017 [Page 1]
Internet-Draft Low Latency Transport Services October 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Low-Latency Transport Services . . . . . . . . . . . . . . . 3
3. Abstract API . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Socket Setup & Teardown . . . . . . . . . . . . . . . . . 5
3.2. Socket Options . . . . . . . . . . . . . . . . . . . . . 6
3.3. Connection Handling . . . . . . . . . . . . . . . . . . . 6
3.4. Timing . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Utilities . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Design Assumptions . . . . . . . . . . . . . . . . . . . 8
4. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Real-Time Multimedia . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The goal of the TAPS working group is to break down the existing
transport layer into a set of transport services, decoupling these
from the transport protocols that provide them. As a result, the
standardisation of transport services becomes feasible and important.
The first phase of this process has been to inspect the existing
transport protocols, and determine the services they provide. The
next phase, enabled both by the use of transport services and their
separation from transport protocols, is to define novel transport
services based on the needs of applications. In essence, these
services are derived from applications by thinking about what the
transport layer would provide to applications if the constraints of
the existing transport protocols were not in place.
This document considers the transport services required by low-
latency applications. This is an important class of applications,
not only because it represents a significant portion of Internet
traffic, but because it is arguably poorly served by the existing
transport layer: the available transport protocols bundle services
together in such a way that no one protocol provides all the services
required.
McQuistin, et al. Expires May 4, 2017 [Page 2]
Internet-Draft Low Latency Transport Services October 2016
After detailing the transport services required by these
applications, a sample API that provides these services is outlined.
This API is then used to demonstrate how applications might make use
of the transport services described.
This document does not consider how the transport services described
map to the transport protocols that might provide them.
2. Low-Latency Transport Services
The decoupling of transport services from transport protocols allows
for the development of novel transport services, based on the needs
of applications. This section describes the transport services
required by low-latency applications.
Timing
Timing is the most essential characteristic of the data
generated by low-latency applications. Data has a lifetime
associated with it: a deadline, relative to the time the data
was produced, by which it must be delivered. Once this
lifetime has been exceeded, the data is no longer useful to the
receiving application. Data lifetimes depend on the latency
bounds of the application. Interactive applications, such as
telephony, video conferencing, or telepresence, require a low
end-to-end latency, ranging from tens to a few hundred
milliseconds. Non-interactive applications can accomodate
higher latency, with bounds in the order of seconds.
There are a number of factors used in predicting if data will
arrive within its lifetime: the time between being sent by the
application and being sent on the wire, the one-way network
delay, and the length of time the data will be buffered at the
receiver before being used (the play-out delay). Multimedia
applications, which comprise a significant portion of the
target application area, have a play-out buffer to reduce the
impact of jitter. Estimates for both RTT and play-out delay
must be available to the sender.
Partial Reliability
The combination of a lossy, best-effort network (e.g., IP)
layer and support for timing and lifetimes results in the need
for a partially reliable service. Given the limitations of
forward error correct techniques, there is some probability
that packet loss can only be recovered from by retransmitting
the lost packet. This introduces potentially unbounded delay,
given that retransmissions themselves may be lost. Therefore,
timing and fully reliable transport services cannot be provided
McQuistin, et al. Expires May 4, 2017 [Page 3]
Internet-Draft Low Latency Transport Services October 2016
together -- the reliable delivery of data cannot be guaranteed
within a given lifetime.
This implies a partial reliability service, where data is
delivered reliably only while it is likely to be useful to the
receiving application. Once a message has exceeded its
lifetime, attempts to transmit it will be abandoned.
Dependencies
Partial reliability means that not all data that is sent will
be received successfully. This means that a dependency
management transport service is required. Data must not be
sent if it relies upon earlier data that has not been
successfully delivered.
Messaging
Given that not all data will arrive successfully, it is
important to maximise the utility of the data that does arrive.
Application-level framing [CCR20] allows the application to
package data into units that are useful (assuming delivery of
their dependencies) to the receiver. The combination of a
messaging service (to maintain application data unit
boundaries) and a dependency services provides greater utility
to applications than a stream-oriented service on lossy
networks. To minimise latency, messages are delivered to the
application in the order they arrive. Reordering messages into
transmission order introduces latency when applied across a
lossy IP network; messages may be buffered waiting for earlier
messages to be retransmitted. Application-layer protocols,
such as RTP, introduce sequencing, allowing applications to
reorder messages if required. Introducing order at this layer
makes the resultant latency explicit to the application.
Multistreaming
Messaging enables a multistreaming service. Many applications
are comprised of multiple streams, each with their own
characteristics with regards to the other services listed. For
example, a typical multimedia application has at least two
flows for audio and video, each with different properties
(e.g., loss tolerance, message sizes). A multistreaming
service allows these streams to be configured separately.
Multipath
Multiple paths often exist between hosts; a multipath service
is required to allow applications to benefit from this. This
is an extension of the multistreaming service: different
streams should be mapped to the most suitable path, given the
configuration of the stream, and the network conditions of the
McQuistin, et al. Expires May 4, 2017 [Page 4]
Internet-Draft Low Latency Transport Services October 2016
path. Messaging is required to make optimal use of multiple
paths with different loss and delay characteristics.
Congestion Control
Congestion control is an essential service. A given algorithm
is not suitable for all traffic types, and so one is not
prescribed. The service should require the use of a suitable
congestion control algorithm, and enforce this using a circuit
breaker.
Connections (optional)
Maintaining per-connection metadata at the endpoints is helpful
for the implementation of many congestion control algorithms.
Further, connection setup and teardown messages can also
benefit in-network services, including NAT traversal and
firewall pinhole management. As a result, it is often
desirable to have support for a connection-oriented service.
This set of transport services demonstrates the need for a top-down
approach. Timing is a crucial characteristic of low-latency
applications, from which the other services follow.
3. Abstract API
This section describes an abstract API that supports the transport
services described in Section 2. This allows the usage of these
services to be demonstrated in Section 4.
It should be noted that the main contribution of this document is the
set of transport services specified in Section 2. An abstract API is
described here to illustrate how these services might be provided,
based on Berkeley Sockets for familiarity. Other APIs, not
constrained by the limitations of Berkeley Sockets, would be more
appropriate.
3.1. Socket Setup & Teardown
Hosts setup and tear-down sockets using the socket() and close()
functions, as in the standard Berkeley sockets API.
The function signatures are:
int socket(int address_family,
int socket_type);
int close(int sd);
McQuistin, et al. Expires May 4, 2017 [Page 5]
Internet-Draft Low Latency Transport Services October 2016
socket() returns a socket descriptor (sd) on success, while close()
returns 0 on success, and -1 on failure.
3.2. Socket Options
Socket options can be set and read using the setsockopt() and
getsockopt() functions respectively. This mirrors the standard
Berkeley sockets API.
The function signatures are:
int getsockopt(int sd,
int level,
int option,
void *value,
socklen_t *len);
int setsockopt(int sd,
int level,
int option,
const void *value,
socklen_t len);
Both return 0 on success, and -1 on failure.
3.3. Connection Handling
The connection primitives are the same as those of TCP sockets.
Servers bind() to a particular address and port, then listen() for
and accept() incoming connections. Clients connect() to a server.
The function signatures are:
int bind(int sd,
struct sockaddr *addr,
socklen_t addrlen);
int listen(int sd);
int accept(int sd,
struct sockaddr *addr,
socklen_t *addrlen);
int connect(int sd,
const struct sockaddr *addr,
socklen_t addrlen);
All return 0 on success, and -1 on failure.
McQuistin, et al. Expires May 4, 2017 [Page 6]
Internet-Draft Low Latency Transport Services October 2016
3.4. Timing
Once a connection has been establised, the receiver then indicates
its media play-out delay, in milliseconds, via the set_po_delay()
function. This specifies how long the application will buffer data
for before it is rendered to the user. The play-out delay is fed
back to the sender, for use in estimating message liveness.
The function signature is:
int set_po_delay(int delay);
The function returns 0 on success, and -1 on failure.
3.5. Messaging
Message-oriented data transmission is exposed by the send_message()
and recv_message() functions. These expose a partially reliable
message delivery service to the application, framing data such that
either the complete message is delivered, or lost in its entirety.
The function signatures are:
int send_message(int sd,
const void *buf,
size_t len,
uint16_t *seq_num,
int lifetime,
uint16_t depends_on,
uint8_t substream);
int recv_message(int sd,
void *buf,
size_t len,
uint16_t *seq_num,
uint8_t *substream);
send_message() returns the number of bytes sent and the sequence
number of the message, while recv_message returns the sub-stream
identifier and length of the message, along with the received message
data.
It is instructive to compare the partially reliable send and receive
functions to their Berkeley sockets API counterparts. The
send_message() call takes three additional parameters, providing
support for the transport services described in Section 2:
McQuistin, et al. Expires May 4, 2017 [Page 7]
Internet-Draft Low Latency Transport Services October 2016
o Lifetime: combined with an estimate of the round-trip time, the
time that the message has spent in the sending buffer, and the
play-out delay, to estimate message liveness
o Dependency message sequence number: used to determine if this
message depends on another that was not sent successfully
o Sub-stream identifier: to provide the multistreaming service
send_message() returns the sequence number of the sent message,
allowing it to be used as the dependency of future messages. The
sequence number will increase by 1 for each message sent (and wrap
around within the 16-bit field). recv_message() returns the sequence
number of the received message, allowing the application to identify
gaps in the sequence space (indicating reordering or loss).
[Discussion question: would it be useful for recv_message() to expose
the message arrival time?]
3.6. Utilities
Two utility functions are needed to support the other services. To
allow applications to size messages to increase their utility,
get_pmtu() provides the path MTU. get_rtt_est() provides an estimate
of the round-trip time, to enable applications to calculate an
appropriate play-out delay value.
The function signatures are:
int get_pmtu(int sd);
int get_rtt_est(int sd);
get_pmtu() returns the path MTU in bytes. get_rtt_est() returns the
current round-trip time estimate in milliseconds.
Endpoints need to send data regularly to obtain an accurate RTT
estimate. Where an endpoint would not otherwise transmit data, the
messages sent by set_po_delay() will allow an RTT estimate to be
calculated.
3.7. Design Assumptions
The API specified here makes a number of assumptions about how the
services described in Section 2 should be provided. For example, the
way in which sequence numbers are implemented limits messages to
expressing their dependence on messages that have been sent
McQuistin, et al. Expires May 4, 2017 [Page 8]
Internet-Draft Low Latency Transport Services October 2016
previously. A different API may be implement a different set of
constraints on the dependency management service.
[Discussion questions: does this mean that the services aren't
properly defined? How much flexibility should be given when
designing an API?]
4. Example Usage
In this section, examples of how applications might use the API
described in Section 3 are given. This is important, not only for
demonstrating the usability of the API, but for validating the
selection of transport services described.
4.1. HTTP/1.1
tbd
[Not typically described as "low latency", but is used by many
applications that would benefit from lower latency. Mapping to a
message-oriented transport service is not obvious.]
4.2. HTTP/2
tbd
[Mapping to message-oriented transport is a lot more obvious.]
4.3. Real-Time Multimedia
Real-time multimedia applications typically make use of RTP [RFC3550]
as their application-layer protocol. This adds a header to each
message, with timing and sequencing metadata. RTP is compatible with
the partially reliable, unordered message delivery model described,
making its mapping to the API straightforward.
Sender:
o The sender opens a socket(), and bind()s to a particular address
and port. It then listen()s for and accept()s incoming
connections.
o Messages are sent using send_message(). The application specifies
the lifetime of the message; this is the maximum delay each
message can tolerate. For example, a VOIP application would set
this to 150ms. The sequence number of message this message
depends on is set, and the sub-stream specified. get_pmtu() can be
used to help determine the message sizes.
McQuistin, et al. Expires May 4, 2017 [Page 9]
Internet-Draft Low Latency Transport Services October 2016
o At the end of the connection, the sender close()s the socket.
Receiver:
o The receiver opens a socket(), and connect()s to a server.
o Once the connection has been established, the receiver sets its
play-out delay, in milliseconds, using set_po_delay(). The
utility function get_rtt_est() can be used in calculating this
value. The play-out delay can be changed over time.
o Messages are received using recv_message(). The application
receives the sequence number and sub-stream identifier alongside
the message data.
o At the end of the connection, the receiver close()s the socket.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
The transport services described do not themselves introduce any
security considerations beyond those of TCP or UDP. No additional
metadata needs to be exposed on the wire to provide the transport
services described. The transport services result in a partially
reliable, message-oriented delivery model. As a result, Datagram TLS
[RFC6347] is required for security and encryption.
[Discussion question: should DTLS/security be listed as an essential
service?]
There are a number of options for deploying the transport services
described in this document. They could be deployed within a new
protocol, but this will likely limit deployability. Alternatively,
for greater deployability, existing protocols could be modified.
Partially Reliable SCTP [RFC3758] and WebRTC's data channels
[I-D.ietf-rtcweb-data-channel] provide a similar set of services over
SCTP. For maximum deployability, the services should be provided
over TCP. Modifying TCP's in-order byte stream abstraction to
provide an out-of-order message-oriented delivery model is
challenging. The designs of TCP Hollywood [IFIP2016], Minion
[I-D.iyengar-minion-protocol], and QUIC
[I-D.hamilton-quic-transport-protocol] show ways of addressing these
challenges.
McQuistin, et al. Expires May 4, 2017 [Page 10]
Internet-Draft Low Latency Transport Services October 2016
7. Informative References
[CCR20] Clark, D. and D. Tennenhouse, "Architectural
Considerations for a New Generation of Protocols", ACM
SIGCOMM Computer Communications Review 20 (4) 200-208,
DOI 10.1145/99508.99553, September 1990,
<http://dx.doi.org/10.1145/99508.99553>.
[I-D.hamilton-quic-transport-protocol]
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC:
A UDP-Based Multiplexed and Secure Transport", draft-
hamilton-quic-transport-protocol-00 (work in progress),
July 2016.
[I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015.
[I-D.iyengar-minion-protocol]
Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire
Protocol", draft-iyengar-minion-protocol-02 (work in
progress), October 2013.
[IFIP2016]
McQuistin, S., Perkins, C., and M. Fayed, "TCP Hollywood:
An Unordered, Time-Lined, TCP for Networked Multimedia
Applications", IFIP Networking 2016,
DOI 10.1109/IFIPNetworking.2016.7497221, May 2016,
<http://dx.doi.org/10.1109/IFIPNetworking.2016.7497221>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758,
DOI 10.17487/RFC3758, May 2004,
<http://www.rfc-editor.org/info/rfc3758>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
McQuistin, et al. Expires May 4, 2017 [Page 11]
Internet-Draft Low Latency Transport Services October 2016
Authors' Addresses
Stephen McQuistin
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
UK
Email: sm@smcquistin.uk
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
UK
Email: csp@csperkins.org
Marwan Fayed
University of Stirling
Department of Computing Science & Maths
Stirling FK9 4LA
UK
Email: mmf@cs.stir.ac.uk
McQuistin, et al. Expires May 4, 2017 [Page 12]
