Implementing Real-Time Transport Services over an Ossified Network
16 July 2016
/ tcp-hollywood
Stephen McQuistin presented our paper on
Implementing
Real-Time Transport Services over an Ossified Network at the ACM, IRTF,
and ISOC Applied Networking Research Workshop in Berlin, on 16 July 2016
(slides).
This paper considers the transport services needed by real-time applications,
based on a top-down analysis of their requirements, and their implementation
on ossified networks such as the Internet, and based on this proposes
an abstract transport API. A cut-down version of this talk was also
given in the TAPS working group at IETF 96
(slides).
There are three parts to this paper.
Firstly, it performs a top-down analysis of the requirements of a
transport protocol for real-time traffic, and from this derives a
set of desirable transport services that the protocol should provide.
Then, it reviews these services, and proposes an abstract transport
API, and how this can be implemented above TCP and UDP.
Finally, it reviews our TCP Hollywood prototype, and considers how
partial reliability can be implemented in this API and in the TCP
Hollywood protocol. Early deployment results for TCP Hollywood are
then reviewed, to show that there is some potential that the protocol
can be safely deployed.
This transport services considered are as follows. Timing and
deadlines: Timing is the most salient feature of real-time
applications. Since their data must be conveyed with real-time
demands, they all have some concept of a deadline. Data that fails to
present within the deadline is otherwise useless. Interactive
applications, such as telephony, video conferencing, or telepresence,
require low end-to-end latency. Their deadlines for presenting the
media, i.e., playing the audio and displaying the video frame, range
from tens to a few hundred milliseconds. Non-interactive application
deadlines associated with broadcast and on-demand programming are on
the order of seconds.
Partial Reliability: In a best-effort network, deadlines
constrain packet delivery service to partial reliability. For example,
when used to repair loss, the limits of forward error correction imply
some probability that packet will be non-recoverable. By contrast,
retransmissions used to recover from loss have potentially unbounded
delay (since any retransmission may itself be lost). Accordingly, a
transport protocol that includes support for deadlines should provide
partial reliability, acknowledging that it may be unable to deliver all
data by its deadline.
Message-oriented Dependencies: The combination of deadlines
and partial reliability makes dependency management an important
transport service. In particular, data should never be sent when it
relies on a previous transmission that was never received.
In the context of both deadlines and dependencies coupled with packet
loss, partial reliability requires
application-level framing to make the best use of payload data. At
the transport layer, this implies a message oriented service,
that maintains application data unit (ADU) boundaries. Messages are
delivered to the application in the order they arrive. As seen in TCP,
in-order delivery can introduce significant latency: incoming segments
may be head-of-line blocked waiting for the delivery of an earlier
segment. Message orientation may also be used to construct a sub-stream
service. Many multimedia applications make use of multiple data
streams. For example, a simple IPTV application will maintain separate
audio and video stream. These could be sent across multiple
transport-layer connections, but overheads can be reduced by
multiplexing these flows on a single connection.
We note the importance of congestion control and connection
oriented transport, but consider these secondary. Congestion control
is important to protect the network, but experience has shown that many
real-time applications can be widely deployed with minimal congestion
control, without significant long-lived ill-effects. Exposing connection
state to the network can help maintain NAT and firewall bindings, but
again, many transport operate without, so it cannot be considered as
essential.
Considering all these transport services, the paper proposes an abstract
API for multimedia transport. It's interesting to note that the result
is not dissimilar to the PR-SCTP API, although it has been derived in
a somewhat different manner. Full details, and discussion of how a
similar API has been implemented and shown to be deployable in the
TCP Hollywood prototype can be found
in the
paper.