THE FUTURE OF TCP: TRAIN-WRECK OR EVOLUTION? Presented 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  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 Enou gh,’ Xiaoqing Zhu, Jatinder Pal Singh and Bernd Mbps 6 Mbps 24 Mbps 12 Mbps

Heterogeneity in Wireless Link Speeds C1C1 ClCl CNCN Channel Time …

TCP Throughput over Wireless Nominal Speed of Second Link (Mbps) Throughput (Mbps) 54Mbps ) ) ) ) ) Stream 2 Stream 1 6 ~ 54 Mbps Simulation in NS2, for a network Stream 1, alone Stream 2, alone Stream 1, shared Stream 2, shared

Overhead of TCP ACK

Demo: Two Nodes Link Speed: 11 Mbps Throughput : 4.4 Mbps Shared : 1.0 Mbps (~ 20 % channel time) Link Speed: 2 Mbps Throughput : 1.4 Mbps Shared : 1.0 Mbps (~ 70% channel time) Video 2Mbps File Transfer Source: 3.7MB Scenario A

TCP Performance Video 2 Mbps Time Rate … File 1.0 Mbps ~ 30 s

What Could Have Happened … Rate Time … Video 2 Mbps File 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 3 Mbps File Transfer Source: 3.7MB

TCP Performance Time Video 3 Mbps File 1.2 Mbps ~ 25 s Rate …

What Could Have Happened … Rate Time Video 3 Mbps File 1.2 Mbps … ~ 27 s

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? packet size round trip time packet loss rate data rate [Mahdavi, Floyd 1997] [Floyd et al. 2000]  Per-packet fairness at the MAC layer  Similar end-to-end ob servations of p, and R TT for competing wire less links  Approximately equal r ate, 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  Congestion Control saved the day! 28 You are an analog co mputer in a digital w orld!

The last straw: Wireless Multimedia  Home Entertainment to grow to $12B by 2010 – Jupiter Research  Multimedia home networks growing at 46% co mpounded – Frost and Sullivan Why should TCP change?  Wireless is lossy  Needs loss recovery  Wireless 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 b VLC for video streaming over TCP Asymmetric links – Forward link good – Reverse link poor

Live Video Streaming TCP Video Packets TCP ACKs Server Client Burst ACK Loss TCP recovered, Video still frozen Video recovers 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 point  All nodes use b  Nodes simultaneously subscribe to lecture video

Many Unicasts Congest the Medium Capacity User 1 ReTx Usr1 User 2 ReTx Usr2 User 3 ReTx Usr3 Wastes the fundamental broadcast advantage of wireless!

Smarter Multicast Scales Better! Capacity Common ReTx Usr1 ReTx Usr2 ReTx Usr3 ReTx Usr4 ReTx Usr5 ReTx Usr6

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?,’  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 bits in HDR, 320 bits in HSDPA. 42

Demo scenarios 43 MH1 MH3 S1 MH2 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  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