1 / 48

THE FUTURE OF TCP: TRAIN-WRECK OR EVOLUTION?

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

rossa
Download Presentation

THE FUTURE OF TCP: TRAIN-WRECK OR EVOLUTION?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. THE FUTURE OF TCP: TRAIN-WRECK OR EVOLUTION? Summarization of demos  2008. 12. 03 Presented by Jaeryong Hwang

  2. 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. Brief view of the workshop

  3. 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 Outline

  4. 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? ‘TCP challenges in multi-hop wireless networks,’ Konstantinos Psounis@USC

  5. Congestion in the multi-hop wireless world

  6. An example

  7. What is wrong with TCP

  8. Neighborhood-centric world

  9. From flow RTT to neighborhood RTT

  10. Simulation setup

  11. Stack topology (flow in the middle)

  12. Experimental setup

  13. Experimental setup (cont.)

  14. Stack topology

  15. Evolution or a new scheme?

  16. ‘Video Streaming Over Wireless: Where TCP is Not Enough,’ Xiaoqing Zhu, Jatinder Pal Singh and Bernd Girod@USC 6 Mbps 24 Mbps 54 Mbps 12 Mbps

  17. Heterogeneity in Wireless Link Speeds CN C1 Cl … Channel Time

  18. Stream 1 ) ) ) ) ) 54Mbps 6 ~ 54 Mbps ) ) ) ) ) Stream 2 TCP Throughput over Wireless Simulation in NS2, for 802.11a network 20 Stream 1, alone 15 Stream 2, alone Throughput (Mbps) Stream 1, shared 10 Stream 2, shared 5 0 10 20 30 40 50 Nominal Speed of Second Link (Mbps)

  19. Overhead of TCP ACK

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

  21. TCP Performance Video Streaming @ 2 Mbps … ~ 30 s Rate File Transfer @ 1.0 Mbps Time

  22. What Could Have Happened … Video Streaming @ 2 Mbps … Rate File Transfer @ 0.7 Mbps ~ 42 s Time

  23. Scenario B Link Speed: 2 Mbps File Transfer Source: 3.7MB Throughput : 1.4 Mbps Shared : 1.2 Mbps (~ 85% Channel Time) Shared : 1.2 Mbps (~ 6% Channel Time) Link Speed: 54 Mbps Throughput : 20 Mbps Video Source @ 3 Mbps

  24. TCP Performance Video Streaming @ 3 Mbps … Rate ~ 25 s File Transfer @ 1.2 Mbps Time

  25. What Could Have Happened … Video Streaming @ 3 Mbps … Rate ~ 27 s File Transfer @ 1.2 Mbps Time

  26. 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

  27. Clean Slate Design or Evolution? • TCP Throughput over Wireless • 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 packet size data rate [Heusse et al. 2003] packet loss rate round trip time [Mahdavi, Floyd 1997] [Floyd et al. 2000]

  28. Congestion Control saved the day! ‘TCP for Home Multimedia: Why you can’t teach an old dog new tricks?,’Hariharan Rahul@MIT You are an analog computer in a digital world!

  29. Home Entertainment to grow to $12B by 2010 – Jupiter Research Multimedia home networks growing at 46% compounded – Frost and Sullivan The last straw: Wireless Multimedia Why should TCP change? • Wireless is lossy  Needs loss recovery • Wireless is a scarce shared resource  Needs congestion control

  30. 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 TCP’s Architecture Is Too Rigid

  31. Live Video Streaming TCP Video Packets Server Client TCP ACKs • Server and client using 802.11b • VLC for video streaming over TCP • Asymmetric links • Forward link good • Reverse link poor

  32. Live Video Streaming TCP Video Packets TCP ignores higher layer needs and lower layer characteristics! Server Client TCP recovered, Video still frozen TCP ACKs Burst ACK Loss Video recovers

  33. 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! Multicasting Video

  34. Lecture streamed via an access point All nodes use 802.11b Nodes simultaneously subscribe to lecture video The Multicast Experiment

  35. Many Unicasts Congest the Medium Capacity ReTxUsr3 User 1 ReTxUsr1 User 2 ReTxUsr2 User 3 Wastes the fundamental broadcast advantage of wireless!

  36. Smarter Multicast Scales Better! Capacity ReTxUsr6 Common ReTxUsr1 ReTxUsr2 ReTxUsr3 ReTxUsr4 ReTxUsr5

  37. 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

  38. The time has come for a newer, nimbler alternative!

  39. 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. ‘Why is TCP not good enough for Mobile Operators?,’ kozat@docomolabs-usa.com

  40. MH2 MH3 MH3 MH1 MH2 MH1 Demo scenarios S2 S1 S1 50Mbps, 25ms 50Mbps, 25ms 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.

  41. 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. Summary of Problems

  42. Long wait times in accessing the cloud • Motivatins: • Uploads take a long time • End user wants: Share the content at the soonest possible ‘TCP IN A WORLD OF CLOUD SERVICES,’ Jiang Zhu@stanford

  43. 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? Conclusions

More Related