TCP goes to hollywood

Abstract

Real-time multimedia applications use either TCP or UDP at the transport layer, yet neither of these protocols offer all of the features required. Deploying a new protocol that does offer these features is made difficult by ossification: firewalls, and other middleboxes, in the network expect TCP or UDP, and block other types of traffic. We present TCP Hollywood, a protocol that is wire-compatible with TCP, while offering an unordered, partially reliable messageoriented transport service that is well suited to multimedia applications. Analytical results show that TCP Hollywood extends the feasibility of using TCP for real-time multimedia applications, by reducing latency and increasing utility. Preliminary evaluations also show that TCP Hollywood is deployable on the public Internet, with safe failure modes. Measurements across all major UK fixed-line and cellular networks validate the possibility of deployment.

Deadline‐aware TCP congestion control for HTTP adaptive streaming services

“…Selective negative acknowledgments are used to allow senders to be informed of segments that were skipped by the application, preventing retransmission. Similarly, TCP Hollywood is a protocol offering an unordered, partially reliable message‐oriented transport service that is well suited for multimedia applications . While this approach is focused on deployability, the inconsistent retransmission mechanism is visible to middleboxes performing deep packet inspection, which might disrupt these connections.…”

“…Similarly, TCP Hollywood is a protocol offering an unordered, partially reliable message-oriented transport service that is well suited for multimedia applications. 13 While this approach is focused on deployability, the inconsistent retransmission mechanism is visible to middleboxes performing deep packet inspection, which might disrupt these connections. Furthermore, TCP Hollywood requires changes at both the sender and receiver side.…”

“…When the current throughput measurement T is above T u or below T l , the deadline margin is expected to grow above m u or shrink to less than m l before the end of the stream is reached. To avoid this, the difference m between the current deadline margin and the approaching bound is calculated, as well as the remaining part of the range of values that allows us to change the aggressiveness in the required direction (lines [11][12][13][14][15][16][17][18][19][20]. Based on these values, the critical time period C, by which leaving the margin bounds is expected, can be calculated (line 21).…”

De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives

“…McQuistin et al [84] approach the problem from a slightly different perspective and suggest, at a conceptual level, to reinterpret the semantics of TCP and UDP to support novel services. They propose reinterpretation of UDP headers as transport identification headers where port numbers become dynamic identifiers of the transport protocol carried in the payload, as well as the relaxation of TCP semantics (based on McQuistin et al's [85] earlier work on TCP Hollywood). Earlier work that "relaxes" TCP includes Time-lined TCP (TLTCP) [86] and Receiver-Centered TCP (TCP-RC) [87].…”

The QUIC Fix for Optimal Video Streaming

“…1 The inherent challenges in streaming "real-time" video traffic [21,40] over varying, and sometimes less than ideal, network conditions are only exacerbated by the choice of a reliable transport-so far, TCP. It is well known that TCP is not suited for video streaming: the rich body of prior work on optimizing and extending TCP, and adaptive bitrate (ABR) selection attest to this observation [11,19,22,31,50]. TCP retransmissions of lost packets in a video stream, inadvertently lead to stalls in the video stream.…”