THE FUTURE OF TCP: TRAIN-WRECK OR EVOLUTION?

2008. 12. 03Presented by Jaeryong Hwang

Summarization of demos 

Brief view of the workshop

a widespread belief TCP is showing its age and needs replacing a deeper understanding of the dynamics of congestion control

The whole purpose of the workshop it to focus on the problem, not the solutions. We are most definitely not interested in your favorite scheme, or ours. So we need some ground-rules

No-one is allowed to mention a specific mechanism, algorithm or proposal at any time during the workshop: Not in their talk, not in a panel, and not in questions to the speakers.

The only mechanisms that will be allowed mention are: TCP (in its standard and deployed flavors), and idealized alternatives for purposes of demonstration.

2

Outline

TCP challenges in multi-hop wireless networks

Video Streaming Over Wireless

TCP for Home Multimedia: Wireless Multicast

Why is TCP not good enough for Mobile

Operators?

TCP IN A WORLD OF CLOUD SERVICES

3

‘TCP challenges in multi-hop wireless networks,’ Konstantinos Psounis@USC

Why multi-hop? Easy to deploy Easy to upgrade Inexpensive The only option for some killer applications, e.g.

disaster recovery networks vehicular ad hoc networks environmental monitoring (underwater, forests, …)

Why not multi-hop? Bad performance

e.g. consider a mesh network using TCP over de facto MAC standard (802.11)

throughput reduces significantly after 3 hops severe capture effects which leads to extreme unfairness

But, is this inherent to multi-hop, or we don’t do things right? Specifically, is TCP regulating the end-to-end rates properly?

4

Congestion in the multi-hop wireless world

5

An example

6

What is wrong with TCP

7

Neighborhood-centric world

8

From flow RTT to neighborhood RTT

9

Simulation setup

10

Stack topology (flow in the middle)

11

Experimental setup

12

Experimental setup (cont.)

13

Stack topology

14

Evolution or a new scheme?

15

‘Video Streaming Over Wireless: Where TCP is Not Enough,’ Xiaoqing Zhu, Jatinder Pal Singh and Bernd

Girod@USC

16

54 Mbps

6 Mbps

24 Mbps

12 Mbps

Heterogeneity in Wireless Link Speeds

C1Cl

CN

Channel Time

…

TCP Throughput over Wireless

10 20 30 40 500

5

10

15

20

Nominal Speed of Second Link (Mbps)

Thr

ough

put (

Mbp

s)

54Mbps

) ) ) ) )

) ) ) ) )

Stream 2

Stream 1

6 ~ 54 Mbps

Simulation in NS2, for 802.11a network

Stream 1, alone

Stream 2, alone

Stream 1, shared

Stream 2, shared

Overhead of TCP ACK

6 9 12 18 24 36 48 540

20

40

60

80

100

Nominal Link Speed (Mbps)

Per

cent

age

of C

hann

el T

ime

(%)

Data ACK

Demo: Two Nodes

Link Speed: 11 Mbps

Throughput : 4.4 MbpsShared : 1.0 Mbps (~ 20 % channel time)

Link Speed: 2 Mbps

Throughput : 1.4 Mbps

Shared : 1.0 Mbps (~ 70% channel time)

Video Source @ 2Mbps

File Transfer Source: 3.7MB

Scenario AScenario A

TCP Performance

Video Streaming @ 2 Mbps

Time

Rat

e

…

File Transfer @ 1.0 Mbps

Share of Channel Time

23%

71%

6%

Video Streaming

File Transfer

ContentionOverhead

~ 30 s

What Could Have Happened …

Share of Channel Time

45%

50%

5%

Video Streaming

File Transfer

ContentionOverhead

Rat

e

Time

…

Video Streaming @ 2 Mbps

File Transfer @ 0.7 Mbps

~ 42 s

Scenario B

Link Speed: 54 Mbps

Throughput : 20 Mbps

Shared : 1.2 Mbps(~ 6% Channel Time)

Link Speed: 2 Mbps

Throughput : 1.4 Mbps

Shared : 1.2 Mbps(~ 85% Channel Time)

Video Source @ 3 Mbps

File Transfer Source: 3.7MB

TCP Performance

Time

Video Streaming @ 3 Mbps

File Transfer @ 1.2 Mbps

~ 25 s

Share of Channel Time6%

86%

8%

Video Streaming

File Transfer

ContentionOverhead

Rat

e …

What Could Have Happened …

Rat

e

Time

Video Streaming @ 3 Mbps

File Transfer @ 1.2 Mbps

…

~ 27 s

Share of Channel Time

15%

79%

6%

Video Streaming

File Transfer

ContentionOverhead

What’s Missing in TCP?

Awareness of application’s utility function For file transfer, aggregate rate matters For video streaming, instantaneous rate matters Video streams differ in their rate-quality tradeoffs

Utility function only needed at the source

• Knowledge of wireless link heterogeneity– Channel time shared among competing links– Congestion due to neighboring transmissions– High rate over a fast link vs. low rate over a slow link

End-to-end measurement no longer suffices

Notion of fairness should be revisited

Clean Slate Design or Evolution?

1.22 MTUR

RTT p

1.22 MTUR

RTT p

packet size

roundtrip time

packetloss rate

data rate

[Mahdavi, Floyd 1997]

[Floyd et al. 2000]

Per-packet fairness at the MAC layer

Similar end-to-end observations of p, and RTT for competing wireless links

Approximately equal rate, regardless of link speed

[Heusse et al. 2003]

TCP Throughput over Wireless

‘TCP for Home Multimedia: Why you can’t teach an old dog new tricks?,’ Hariharan Rahul@MIT

Congestion Control saved the day!

28

You are an analog computer in a digital world!

The last straw: Wireless Multimedia

Home Entertainment to grow to $12B by 2010 – Jupiter Research

Multimedia home networks growing at 46% compounded – Frost and Sullivan

Why should TCP change? Why should TCP change?

Wireless is lossy Needs loss recoveryWireless is a scarce shared resource Needs congestion control

TCP’s Architecture Is Too Rigid

Ignores the characteristics of the higher layer Provides complete reliability regardless of what the

application needs

Ignores the characteristics of the lower layer Congestion control reacts to all losses, regardless of their

cause

Live Video Streaming

TCP Video Packets

TCP ACKs

Server Client

• Server and client using 802.11b• VLC for video streaming over TCP• Asymmetric links

– Forward link good– Reverse link poor

Live Video Streaming

TCP Video Packets

TCP ACKs

Server ClientTCP ignores higher layer needs and lower layer characteristics!

TCP ignores higher layer needs and lower layer characteristics!

Multicasting Video

Many popular applications Mobile TV Security videos in airports and train stations Commercials or music videos in malls and

nightclubs

But wireless multicast needs loss recovery!

The Multicast Experiment

Lecture streamed via an access pointAll nodes use 802.11bNodes simultaneously subscribe to lecture

video

Many Unicasts Congest the Medium

Capacity

User 1ReTxUsr1

User 2ReTxUsr2

User 3ReTxUsr3

Wastes the fundamental broadcast advantage of wireless!

Wastes the fundamental broadcast advantage of wireless!

Smarter Multicast Scales Better!

Capacity

CommonReTxUsr1

ReTxUsr2

ReTxUsr3

ReTxUsr4

ReTxUsr5

ReTxUsr6

Conclusion

• We need TCP’s functions!• But TCP’s architecture shackles us!

– Rigid layering does not understand application needs or medium behavior

– Tight coupling of physical and logical packets not conducive to multicast

– Intertwined reliability and congestion control stifle innovations for high throughput

The time has come for a newer, nimbler alternative!

‘Why is TCP not good enough for Mobile Operators?,’ kozat@docomolabs-usa.com

Cellular networks are carefully engineered: Starvation are unlikely to occur in cellular But, TCP can lead to substantially sub-optimal operating points

for highly optimized/expensive cellular radio An operator like NTT DoCoMo do not use standard TCP

Split with proxies, use a modified proprietary TCP version

Demo setting: Channel model: ITU IMT-2000 channel models PHY layer: 1x-EVDO Features of state-of-the-art Wireless Transmission

Opportunistic scheduling Hybrid ARQ at PHY layer and aggressive re-transmission at

link layer Constant-size radio link layer PDUs.

E.g. 1024 bits in HDR, 320 bits in HSDPA.

42

Demo scenarios

43

MH1

MH3

S1

MH2

50Mbps, 25ms

50Mbps, 25ms

MH1

MH2

MH3

S1 S2

50Mbps, 25ms

• 1 down-stream video (1.2Mbps) & 3 uploads in the same cell.• Wireless capacity is the bottleneck.• Each user sees symmetric channel rates.• We compare TCP vs. backlogged UDP.

• 2 Downloads and 1 P2P streaming (600Kbps).• Wireless capacity is the bottleneck.• Each user sees symmetric channel rates.• We compare TCP vs. backlogged UDP.

Summary of Problems

ACK traffic substantially interferes with the payload traffic.

Load asymmetries substantially impact the performance.

TCP fairness and scheduler fairness are not necessarily the same.

Large RTT misses transmission opportunities. Mobile P2P with TCP looks problematic.

Unmatched channel states increases RTT.

44

‘TCP IN A WORLD OF CLOUD SERVICES,’ Jiang Zhu@stanford

Long wait times in accessing the cloud

Motivatins: Uploads take a long time End user wants: Share the content at the

soonest possible

45

46

47

Conclusions

TCP is showing its age and needs replacing Ignores the characteristics of the higher layer and of the

lower layer Configure congestion Wireless multimedia services

Clean slate or evolution?

48