Implementing Real-Time Transport Services over an Ossified Network
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.