the future of tcp: train-wreck or evolution?
DESCRIPTION
THE FUTURE OF TCP: TRAIN-WRECK OR EVOLUTION?. Summarization of demos . 2008. 12. 03 Presented by Jaeryong Hwang. a widespread belief TCP is showing its age and needs replacing a deeper understanding of the dynamics of congestion control - PowerPoint PPT PresentationTRANSCRIPT
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?,’ [email protected]
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