TCP Goes to Hollywood Stephen McQuistin and Colin Perkins University of Glasgow Marwan Fayed University of Stirling
Multimedia Applications and HTTP HTTP-based multimedia delivery protocols (e.g., MPEG- • DASH, HLS) are popular They allow applications to make use of the existing HTTP • infrastructure (e.g., CDNs) These protocols can be configured for low latency • applications: smaller segment sizes and buffers, for example … but latency is added at the transport layer • 2
TCP adds latency In-order delivery means buffering out-of-order segments, • waiting for the delivery of earlier data Reliability involves detecting that a segment has been lost, • and retransmitting it Both of these mechanisms add latency, making TCP a poor • choice for real-time multimedia applications 3
Introducing TCP Hollywood Uses TCP as a substrate, to overcome ossification, but • modified to reduce latency Message-oriented to allow application data units to be sent • Unordered delivery of messages, given independent utility • Partially reliable based on time and dependency information • 4
Architecture Functionality split between • user-space intermediary layer, and kernel extensions Application Intermediary layer works • TCP Hollywood Intermediary Layer over either standard TCP or TCP Hollywood Standard TCP or TCP Hollywood Supports partial • deployments 5
Unordered message delivery Builds on standard TCP’s byte stream, so need to frame • messages At sender, applications pass messages to intermediary layer, for • encoding (to escape framing bytes), and framing Nagle’s algorithm disabled — it would add latency • At receiver, incoming segments delivered as they arrive, • decoded, and passed to application — no latency added by buffering ACKs generated as with standard TCP • 6
Partial reliability Applications pass metadata with messages: deadline and • dependency information Messages might expire — either they won’t arrive on time to be • played out, or they depend on an undelivered message Expired messages aren’t retransmitted — a live message is sent • instead, as an inconsistent retransmission Payload is different, but with the same TCP sequence number • and length Recovers utility lost by retransmitting expired data • 7
TCP Hollywood in action Sender Network Receiver user kernel kernel user T framing Buffers time 8
TCP Hollywood in action Sender Network Receiver user kernel kernel user time 9
TCP Hollywood in action Sender Network Receiver user kernel kernel user time 10
TCP Hollywood in action Sender Network Receiver user kernel kernel user time 11
TCP Hollywood in action Sender Network Receiver user kernel kernel user T playout reduces gaps in playback due to jitter time 12
TCP Hollywood in action Sender Network Receiver user kernel kernel user Playout begins time 13
TCP Hollywood in action Sender Network Receiver user kernel kernel user x Segment lost time 14
TCP Hollywood in action Sender Network Receiver user kernel kernel user x Segment arrives out-of- order, but is delivered under TCP Hollywood time 15
TCP Hollywood in action Sender Network Receiver user kernel kernel user x time 16
TCP Hollywood in action Sender Network Receiver user kernel kernel user x T rexmit = 4 × T framing + T rtt time The original message wouldn’t arrive on time to be played out 17
TCP Hollywood in action Sender Network Receiver user kernel kernel user x . . . . . . TCP Hollywood sends an . . . inconsistent time retransmission : a different message, but with the same TCP sequence number 18
TCP Hollywood in action Sender Network Receiver user kernel kernel user Gap where segment was lost, but no bandwidth wasted in retransmitting it x . . . . . . . . . time 19
TCP Hollywood in action Sender Network Receiver user kernel kernel user These segments wouldn’t have arrived on time under standard TCP x . . . . . . . . . time 20
Feasibility Region T playout TCP Hollywood helps when T playout is less than T rexmit T rtt 21
Feasibility Region Time between a T playout frame arriving at the receiving application, and being played out T rtt 22
Feasibility Region T playout Network round-trip time T rtt 23
Feasibility Region T playout Plotting the region of feasible values of T playout across round-trip times T rtt 24
Feasibility Region T playout Duration of media in each message Tframing T rtt 25
Feasibility Region T playout Message needs to be decoded before being played out Tframing T rtt 26
Feasibility Region T playout Application delay bound T m a x - T f r a m i n g - T r t / t 2 Tframing T rtt 27
Feasibility Region T playout Trtt + 4 ⋅ Tframing T rexmit T m a x - T f r a m i n g - T r t / t 2 Tframing T rtt 28
Feasibility Region T playout Trtt + 4 ⋅ Tframing Standard TCP retransmissions are useful, and no head- of-line blocking T m a x - T f r a m i n g - T r t / t 2 Tframing T rtt 29
Feasibility Region T playout Trtt + 4 ⋅ Tframing Standard TCP retransmissions arrive too late to be used, and head-of-line blocking possible T m a x - T f r a m i n g - T r t / t 2 Tframing T rtt 30
Feasibility Region T playout Trtt + 4 ⋅ Tframing Standard TCP retransmissions arrive too late to be used, and head-of-line blocking possible T m a x - T f r a m i n g - T r t / t 2 TCP Hollywood helps: removes head-of-line Tframing blocking, and sends inconsistent T rtt retransmissions 31
Example Application IPTV application, using MPEG-DASH configured for low- • latency delivery T max = 1 second, within zap time recommendations • T framing determined by number of frames in message • Trade-off between size of T framing , and utility of standard TCP • retransmissions 32
Example T framing = 1 frame 1 Standard TCP retransmissions are 0.8 useful when a small number of frames are sent — but overheads T playout (seconds) 0.6 are higher 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 33
Example T framing = 2 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 34
Example T framing = 3 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 35
Example T framing = 4 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 36
Example T framing = 5 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 37
Example T framing = 6 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 38
Example T framing = 7 frames 1 The utility of standard TCP retransmissions 0.8 decreases as T framing increases (and overheads become T playout (seconds) 0.6 lower) 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 39
Example T framing = 8 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 40
Example T framing = 9 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 41
Example T framing = 10 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 42
Example T framing = 11 frames 1 0.8 T playout (seconds) 0.6 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 43
Example T framing = 12 frames 1 Standard TCP 0.8 retransmissions are effectively useless; TCP Hollywood recovers this T playout (seconds) 0.6 lost utility 0.4 0.2 0 0 0.5 1 1.5 T rtt (seconds) 44
Deployability Inconsistent retransmissions are the only wire-visible • modification vs. standard TCP — same TCP sequence number, different payload Middleboxes performing payload inspection may interpret the • behaviour as an attack — man on the side Experiments between TCP Hollywood server, and 14 UK • clients 8 fixed-line ISPs, 4 cellular operators - all major UK ISPs • 45
TCP Hollywood is deployable Fixed-line Cellular Tested on two ports to check • if HTTP traffic treated differently Port 4001 inconsistent • retransmission delivered successfully original segment • delivered instead Intermediary layer handles Port 80 • cases where original delivered - performance no worse than standard TCP 46
TCP Hollywood Unordered, partially reliable • message-oriented TCP- based transport protocol Eliminates head-of-line • blocking, reducing latency Prevents retransmission of • expired data, increasing utility “Hollywood Sign”, Gnaphron - CC BY-SA 2.0 flickr.com/photos/gnaphron/8485145044 Deployable across all major • UK ISPs 47
Recommend
More recommend
