TCP Goes to Hollywood Stephen McQuistin and Colin Perkins - - PowerPoint PPT Presentation

▶
tcp goes to hollywood
SMART_READER_LITE
LIVE PREVIEW

TCP Goes to Hollywood Stephen McQuistin and Colin Perkins - - PowerPoint PPT Presentation

Sep 27, 2023 488 likes •974 views

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

slide-1
SLIDE 1

TCP Goes to Hollywood

Stephen McQuistin and Colin Perkins

University of Glasgow

Marwan Fayed

University of Stirling

slide-2
SLIDE 2

Multimedia Applications and HTTP

2

  • 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
slide-3
SLIDE 3

TCP adds latency

3

  • 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

slide-4
SLIDE 4

Introducing TCP Hollywood

4

  • 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
slide-5
SLIDE 5

Architecture

  • Functionality split between

user-space intermediary layer, and kernel extensions

  • Intermediary layer works
  • ver either standard TCP or

TCP Hollywood

  • Supports partial

deployments

5

Application TCP Hollywood Intermediary Layer Standard TCP or TCP Hollywood

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

TCP Hollywood in action

8

Sender Receiver

time user kernel user kernel

Tframing

Network

Buffers

slide-9
SLIDE 9

TCP Hollywood in action

9

Sender Receiver

time user kernel user kernel

Network

slide-10
SLIDE 10

TCP Hollywood in action

10

Sender Receiver

time user kernel user kernel

Network

slide-11
SLIDE 11

TCP Hollywood in action

11

Sender Receiver

time user kernel user kernel

Network

slide-12
SLIDE 12

TCP Hollywood in action

12

Sender Receiver

time user kernel user kernel

Tplayout reduces gaps in playback due to jitter

Network

slide-13
SLIDE 13

TCP Hollywood in action

13

Sender Receiver

time user kernel user kernel

Network

Playout begins

slide-14
SLIDE 14

TCP Hollywood in action

14

Sender Receiver

time user kernel user kernel

x

Network

Segment lost

slide-15
SLIDE 15

TCP Hollywood in action

15

Sender Receiver

time user kernel user kernel

x

Network

Segment arrives out-of-

  • rder, but is delivered

under TCP Hollywood

slide-16
SLIDE 16

TCP Hollywood in action

16

Sender Receiver

time user kernel user kernel

x

Network

slide-17
SLIDE 17

TCP Hollywood in action

17

Sender Receiver

time user kernel user kernel

x

Trexmit = 4 × Tframing + Trtt

Network

The original message wouldn’t arrive on time to be played out

slide-18
SLIDE 18

TCP Hollywood in action

18

Sender Receiver

time user kernel user kernel

x

TCP Hollywood sends an inconsistent retransmission: a different message, but with the same TCP sequence number

Network

. . . . . . . . .

slide-19
SLIDE 19

TCP Hollywood in action

19

Sender Receiver

time user kernel user kernel

x

Network

. . . . . . . . .

Gap where segment was lost, but no bandwidth wasted in retransmitting it

slide-20
SLIDE 20

TCP Hollywood in action

20

Sender Receiver

time user kernel user kernel

x

Network

. . . . . . . . .

These segments wouldn’t have arrived on time under standard TCP

slide-21
SLIDE 21

Feasibility Region

Tplayout Trtt

21

TCP Hollywood helps when Tplayout is less than Trexmit

slide-22
SLIDE 22

Feasibility Region

Tplayout Trtt

22

Time between a frame arriving at the receiving application, and being played out

slide-23
SLIDE 23

Feasibility Region

Tplayout Trtt

23

Network round-trip time

slide-24
SLIDE 24

Feasibility Region

Tplayout Trtt

24

Plotting the region of feasible values of Tplayout across round-trip times

slide-25
SLIDE 25

Feasibility Region

Tplayout Trtt

Tframing

25

Duration of media in each message

slide-26
SLIDE 26

Feasibility Region

Tplayout Trtt

Tframing

26

Message needs to be decoded before being played out

slide-27
SLIDE 27

Feasibility Region

Tplayout Trtt

Tframing

T m a x

  • T

f r a m i n g

  • T

r t t / 2

27

Application delay bound

slide-28
SLIDE 28

Feasibility Region

Tplayout Trtt

Tframing

Trtt + 4⋅Tframing

T m a x

  • T

f r a m i n g

  • T

r t t / 2

28

Trexmit

slide-29
SLIDE 29

Feasibility Region

Tplayout Trtt

Tframing

Trtt + 4⋅Tframing

T m a x

  • T

f r a m i n g

  • T

r t t / 2

29

Standard TCP retransmissions are useful, and no head-

  • f-line blocking
slide-30
SLIDE 30

Feasibility Region

Tplayout Trtt

Tframing

Trtt + 4⋅Tframing

T m a x

  • T

f r a m i n g

  • T

r t t / 2

30

Standard TCP retransmissions arrive too late to be used, and head-of-line blocking possible

slide-31
SLIDE 31

Feasibility Region

Tplayout Trtt

Tframing

Trtt + 4⋅Tframing

T m a x

  • T

f r a m i n g

  • T

r t t / 2

31

Standard TCP retransmissions arrive too late to be used, and head-of-line blocking possible TCP Hollywood helps: removes head-of-line blocking, and sends inconsistent retransmissions

slide-32
SLIDE 32

Example Application

32

  • IPTV application, using MPEG-DASH configured for low-

latency delivery

  • Tmax = 1 second, within zap time recommendations
  • Tframing determined by number of frames in message
  • Trade-off between size of Tframing, and utility of standard TCP

retransmissions

slide-33
SLIDE 33

Example

33

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 1 frame

Standard TCP retransmissions are useful when a small number of frames are sent — but overheads are higher

slide-34
SLIDE 34

Example

34

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 2 frames

slide-35
SLIDE 35

Example

35

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 3 frames

slide-36
SLIDE 36

Example

36

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 4 frames

slide-37
SLIDE 37

Example

37

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 5 frames

slide-38
SLIDE 38

Example

38

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 6 frames

slide-39
SLIDE 39

Example

39

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 7 frames

The utility of standard TCP retransmissions decreases as Tframing increases (and

  • verheads become

lower)

slide-40
SLIDE 40

Example

40

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 8 frames

slide-41
SLIDE 41

Example

41

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 9 frames

slide-42
SLIDE 42

Example

42

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 10 frames

slide-43
SLIDE 43

Example

43

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 11 frames

slide-44
SLIDE 44

Example

44

0.2 0.4 0.6 0.8 1 0.5 1 1.5 Tplayout (seconds) Trtt (seconds) Tframing = 12 frames

Standard TCP retransmissions are effectively useless; TCP Hollywood recovers this lost utility

slide-45
SLIDE 45

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

slide-46
SLIDE 46

TCP Hollywood is deployable

46

Fixed-line Cellular Port 4001 Port 80

  • Tested on two ports to check

if HTTP traffic treated differently

  • inconsistent

retransmission delivered successfully

  • riginal segment

delivered instead

  • Intermediary layer handles

cases where original delivered - performance no worse than standard TCP

slide-47
SLIDE 47

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

  • Deployable across all major

UK ISPs

47

“Hollywood Sign”, Gnaphron - CC BY-SA 2.0 flickr.com/photos/gnaphron/8485145044