1 / 42

Adaptive Transmission Protocols for the Future Internet

Adaptive Transmission Protocols for the Future Internet. Hari Balakrishnan MIT Lab for Computer Science http://www.sds.lcs.mit.edu/~hari. Internet Service Model. Internet. Congestion due to overload causes losses Transmission protocols provide end-to-end data transport

kostya
Download Presentation

Adaptive Transmission Protocols for the Future Internet

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. Adaptive Transmission Protocols for the Future Internet Hari Balakrishnan MIT Lab for Computer Science http://www.sds.lcs.mit.edu/~hari

  2. Internet Service Model Internet • Congestion due to overload causes losses • Transmission protocols provide end-to-end data transport • Loss recovery (if reliability is important) • Congestion management (to reduce instability) • Connection setup/teardown Router A best-effort network: losses & reordering can occur

  3. Transmission Protocols • User Datagram Protocol (UDP) • Simple datagram delivery • Other protocols built on top (e.g., RTP for video) • Transmission Control Protocol (TCP) • Reliable, in-order byte stream delivery • Loss recovery & congestion control • TCP is dominant today, and is tuned for: • Long-running transfers • Wired links and symmetric topologies

  4. Internet Problem #1: The Web! r1 • Multiple reliable streams • Individual objects are small • So what? Far too inefficient! Far too aggressive! r2 r3 Server Client r-n

  5. Internet Problem #2: Application Heterogeneity u1 r1 u2 • New applications (e.g., real-time streams) • The world isn’t only about HTTP or even TCP! • So what? Applications do not adapt to congestion Long-term Internet stability is threatened r2 u3 r3 Server Client u-m r-n

  6. Metricom Ricochet Lucent WaveLAN Regional-Area + Asymmetry Metro-Area Cellular Digital Packet Data (CDPD) IBM Infrared Campus-Area Packet Radio In-Building Problem #3: Technology Heterogeneity • Tremendous diversity • So what? Awful performance Mobility-related inefficiencies

  7. Why is Efficient Transport Hard? • Congestion • Channel errors • Asymmetry • Latency variability • Packet reordering • Mobility • Large network “pipes” • Small network “pipes”

  8. Solution: Adaptive Transmissions • A framework to adapt to various network conditions • Guiding principle: the end-to-end argument • Do only the “right” amount inside the network • Expose important information to applications • Algorithms to adapt to different conditions • Wanted: A grand unified architecture for Internet data transport

  9. This Talk • Congestion • Channel errors • Asymmetry • Latency variability • Packet reordering • Mobility • Large network “pipes” • Small network “pipes”

  10. TCP Overview • Loss recovery 7 8 6 10 9 5 • Congestion control • Window-based algorithm to determine sustainable rate • Upon congestion, reduce window • “ACK clocking” sends data smoothly 4 3 1 0 1 1 lost 0 2 1 1 Timeouts based on mean round-trip time (RTT) and deviation Fast retransmissions based on duplicate ACKs

  11. Congestion Management Challenges • Heterogeneous traffic mix • Multiple concurrent streams • Variety of applications and transports • Control algorithms must be stable • Clean separation from other tasks like loss recovery

  12. “Solution” #1: Persistent Connections r1 Put everyone on same ordered byte stream r2 r3 Server Client r-n While this fixes some of the problems of independent connections, it really is a step in the wrong direction! 1. Far too much coupling between objects 2. Far too application-specific 3. Does not enable application adaptation

  13. “Solution” #2: Web Accelerators • Is your Web experience too slow? • Chances are, it’s because of pesky TCP congestion control and those annoying timeouts • Web accelerators will greatly speed up your transfers… • By just “adjusting” TCP’s congestion control! • Who cares if the Internet is stable or not?

  14. “Solution” #3: Integrated TCP Sessions r1 r2 r3 Server Client r-n • Independent TCP connections, but shared control parameters [BPS+98, Touch98] • Shared congestion windows, round-trip estimates • But, this approach doesn’t accomodate non-TCP traffic

  15. Internet What is the World Heading Toward? u1 r1 u2 r2 u3 r3 Server Client u-m r-n • The world won’t be just HTTP • The world won’t be just TCP Logically different streams (objects) should be kept separate, yet efficient congestion management must be performed.

  16. Congestion Manager What We Really Need… HTTP Audio Video1 Video2 An integrated approach to end-to-end congestion management for the Internet using the CM TCP1 TCP2 UDP IP

  17. CM: Some Salient Features • Shared learning • Maintains host- and domain-specific information • Heterogeneous application support • Simple application interfaces to CM • Robust and stable rate control algorithms • Flexible bandwidth-apportioning using receiver hints • Enables application adaptation to congestion and changing bandwidth

  18. The CM API • A simple but powerful application-to-CM API • Three classes of functions • Query • Control • Application callback • Design principle: Application-Level Framing (ALF) • Feed information up to application • Application decides what to send; CM tells it how fast

  19. How the API Works CM does not buffer any data; request/callback/notify API

  20. Preliminary Results • Simulation results show significant improvements in performance predictability • E.g., TCP with CM reduces timeouts and shares bandwidth well between connections • CM’s internal congestion algorithm is rate-based • Great platform for experimenting with new control schemes • Experiments with scheduling algorithms planned • Proxy receiver hosts are problematic

  21. Summary & Status • The CM provides a simple API to make applications adaptive and network-aware • Enables all traffic to adhere to basic congestion control principles • Improves performance predictability • Enables shared state learning • ns-2 experiments in progress • Linux implementation coming soon (including rate-adaptive applications)

  22. This Talk • Congestion • Channel errors • Asymmetry • Latency variability • Packet reordering • Mobility • Large network “pipes” • Small network “pipes”

  23. Goal: To bridge the gap between perceived and rated performance TCP/Wireless Performance Today

  24. Internet 0 Burst losses lead to coarse-grained timeouts 3 1 1 2 2 2 Loss ==> Congestion Result: Low throughput Channel Errors Router Loss  Congestion

  25. Performance Degradation Best possible TCP with no errors (1.30 Mbps) TCP Reno (280 Kbps) Sequence number (bytes) Time (s) 2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN

  26. Fixed to mobile: transport-aware link protocol Mobile to fixed: link-aware transport protocol Our Solution: Snoop Protocol • Shield TCP sender from wireless vagaries • Eliminate adverse interactions between protocol layers • Congestion control only when congestion occurs • The End-to-End Argument [SRC84] • Preserve TCP/IP service model: end-to-end semantics • Is connection splitting fundamentally important? • Eliminate non-TCP protocol messages • Is link-layer messaging fundamentally important?

  27. 4 6 5 1 Snoop Protocol: FH to MH 3 2 1 Snoop agent Base Station Snoop agent: active interposition agent • Snoops on TCP segments and ACKs • Detects losses by duplicate ACKs and timers • Suppresses duplicate ACKs from FH sender Cross-layer protocol design: snoop agent state is soft FH Sender Mobile Host

  28. 1 Snoop Protocol: FH to MH Snoop Agent Base Station FH Sender Mobile Host

  29. 4 1 3 2 Snoop Protocol: FH to MH 5 Base Station FH Sender Mobile Host

  30. 4 6 5 1 Snoop Protocol: FH to MH 3 2 1 Base Station FH Sender Mobile Host

  31. 4 2 1 2 Snoop Protocol: FH to MH 6 3 2 1 5 Base Station 3 Sender Mobile Host

  32. 5 4 6 4 3 2 Snoop Protocol: FH to MH 3 2 1 Base Station Sender ack 0 Duplicate ACK Mobile Host 1

  33. 6 6 5 5 4 1 4 3 2 Snoop Protocol: FH to MH 3 2 1 Base Station Retransmit from cache at higher priority Sender ack 0 ack 0 ack 0 Mobile Host 1

  34. 6 5 4 4 3 2 5 1 Snoop Protocol: FH to MH 3 2 1 Base Station Sender ack 0 Suppress Duplicate Acks ack 4 Mobile Host 1

  35. 6 5 6 1 4 3 2 Snoop Protocol: FH to MH Clean cache on new ACK Base Station Sender ack 4 5 ack 5

  36. 6 6 5 4 3 2 Snoop Protocol: FH to MH Base Station Sender ack 4 ack 5 1 ack 6 Mobile Host

  37. 5 4 3 2 Active soft state agent at base station Transport-aware reliable link protocol Preserves end-to-end semantics Snoop Protocol: FH to MH 7 9 8 Base Station Sender ack 5 ack 6 6 1 Mobile Host

  38. Snoop Performance Improvement Best possible TCP (1.30 Mbps) Snoop (1.11 Mbps) TCP Reno (280 Kbps) Sequence number (bytes) Time (s) Time (s) 2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN

  39. 60000 50000 40000 30000 20000 10000 Suppressing duplicate acknowledgments and TCP-awareness leads to better utilization of link bandwidth and performance Benefits of TCP-Awareness Snoop • 30-35% improvement for Snoop: LL congestion window is small (but no coarse timeouts occur) • Connection bandwidth-delay product = 25 KB Congestion Window (bytes) LL (no duplicate ack suppression) 0 0 10 20 30 40 50 60 70 80 Time (sec)

  40. Snoop Protocol Status • BSD/OS implementation • Integrated with Daedalus low-latency handoff software • Version 1 released 1996; Version 2 released 1998 • In daily production use at Berkeley and UC Santa Cruz • Several hundred downloads • Ports to Linux, FreeBSD, NetBSD

  41. Summary: Wireless Bit-Errors • Problem: wireless corruption mistaken for congestion • Solution: Snoop Protocol • General lessons • Lightweight soft-state agent in network infrastructure • Guided by the End-to-End Argument • Fully conforms to the IP service model • Cross-layer protocol design & optimizations Transport Link-aware transport (Explicit Loss Notification) Network Transport-aware link(Snoop agent at BS) Link Physical

  42. Conclusions • Efficient data transport is a hard problem: congestion, errors, asymmetry,... • Adaptive transmission schemes are essential in the future Internet • Architectural components should include • Congestion Manager (CM) • Error-handlers (e.g., Snoop protocol) • (And many other features) • Wanted: a grand unified transmission architecture for resource management and application adaptation

More Related