TCP Hollywood at ACM NOSSDAV 2016
Stephen McQuistin presented our paper TCP Goes to Hollywood at the ACM NOSSDAV workshop in Klagenfurt am Wörthersee, Austria, on 13 May 2016 (slides). This paper introduces TCP Hollywood, a new TCP variant that aims to reduce transport-induced latency for multimedia applications. It gives an overview of the protocol, and outlines the conditions where it offers benefit over standard TCP.
TCP Hollywood changes the TCP service model and API, to provide a message-oriented interface that allows explicit deadlines and dependencies to be associated with each message. It also changes the TCP retransmission logic to allow for discard of messages that would miss their deadline. The TCP sequence number space is re-used, by sending inconsistent retransmissions, to ensure backwards compatibility. The protocol is described in detail in our forthcoming paper at the IFIP Networking 2016 conference.
Inconsistent retransmissions provide the key benefit of TCP Hollywood, allowing it to make use of data that would otherwise arrive too late to be useful with standard TCP. The diagram below shows the region where standard TCP fails for real-time applications. It plots the application deadline, the play-out bound after which data is useless, against the time taken to retransmit a lost packet. The region above the line labelled Retransmission Time, and below that labelled Application deadline, shows where standard TCP retransmissions of lost packets arrive in time to be used. The region below these lines, but with play-out buffer delay larger than the framing interval, labelled “Region of Wasted TCP Retransmits”, shows where standard TCP retransmissions arrive too late to be used.
It is this Region of Wasted TCP Retransmits that we target. The data that would have been sent in these packets will never arrive in time to be used, but we replace the payload with new data (retaining the original TCP sequence number) that can be used. This allows TCP Hollywood to make better use of the available capacity, rather than sending useless data.
The next figure shows the benefits of TCP Hollywood. Consider an IPTV application that uses MPEG DASH for delivery, and desires low latency delay (in this example, a maximum end-to-end delay of 1 second) for HD content. The figure shows that sending a small number of frames per message allows standard TCP retransmissions to work, reducing both application-level loss and the average one-way delay of each frame. However, the cost of sending a small number of frames is an increase in overheads: it must be possible to independently decode each message, which reduces the compression efficiency of the codec and increases the header overhead. We can reduce these overheads by increasing the number of frames in each message. This allows the multimedia codec to use predictive frames for efficiency, and increases the ratio of payload to headers. The cost of this is shown in the figure, where we see sending more than 10 frames in a message renders TCP retransmissions useless: they arrive too late to be played out.
This, then, is the utility of TCP Hollywood. By changing the TCP service model and application API, we can make use of data that would be wasted in standard TCP, improving good-put and reducing latency of TCP transport. Full details, and an initial discussion around ease of deployment, are in the paper.