1 / 34

TCP Behavior of a Busy Web Server: Analysis and Improvements

TCP Behavior of a Busy Web Server: Analysis and Improvements. Nitin Gupta Sandhya Gupta. Outline. TCP basics Problems with Internet Key observations Integrated Congestion & Loss Management Congestion Manager Implementation Some issues for discussion. Overall TCP Behavior.

terrence-quinones
Download Presentation

TCP Behavior of a Busy Web Server: Analysis and Improvements

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. TCP Behavior of a Busy Web Server:Analysis and Improvements Nitin Gupta Sandhya Gupta

  2. Outline • TCP basics • Problems with Internet • Key observations • Integrated Congestion & Loss Management • Congestion Manager Implementation • Some issues for discussion

  3. Overall TCP Behavior Congestion Avoidance Congestion Window Slow Start ssthresh Time • Slow Start – Double window every RTT • Congestion Avoidance – Increase window by 1 MSS every RTT

  4. Retransmissions • Timeout • RTO = b * RTT, where b = 2 • Many TCP implementations set RTO in multiples of 200,500,1000ms • Fast Retransmit • Use receipt of 3 or more dupacks* as indication of loss • Don’t wait for timeout to retransmit packet * Dupacks (Duplicate acks) - Repeated acks for the same sequence

  5. Fast Retransmit Retransmission X Duplicate Acks Sequence No Data packets Acks Time

  6. Two Questions Internet • Q2: Can we remain sanguine about the future outlook? Router Shared infrastructure and overload causes congestion • Q1: Why has the Internet not crumbled under its own load in recent years? • A: Soundness of TCP congestion control + friendly TCP workload A: Not Really!!!

  7. Internet Problem #1: The Web r1 • Multiple reliable streams • Individual objects are small • So what? • N “slow starts” =Far too inefficient! • No shared learning =Far too aggressive! r2 r3 Server Client r-n

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

  9. Motivation • Understand TCP behavior and performance in the Internet today, in the context of HTTP • Identify problems and shortcomings in TCP • Identify any possible protocol improvements • Focus primarily on sender-side changes to TCP, to enable easy deployment • Testbed: IBM’s 1996 Olympic WWW server • Hundreds of thousands of clients • Tens of millions of hits per day

  10. Trace Collector Web Server Setup Token Ring Load Balancing Router Web Client Router Token Ring Client Request Server Response Internet ATM Switch Server Nodes HTTP Request, TCP acks TCP data packets

  11. Data Collection Methodology • Had access only to incoming traffic, i.e., all HTTP request packets and TCP acks but not data sent • Modified Web servers to announce when TCP performed a retransmission • TCP emulation engine reconstructs precise sender behavior and evolution of TCP state variables

  12. Receiver Socket Buffer • Receiver Buffer was Bottleneck in 14% of connections • Should increase from a default value of 4k

  13. Analysis of Individual Connections • Strong correlation between loss probability and Ack bandwidth ratio / Ack compression • Ack compression factor easier to compute

  14. Analysis of Concurrent Connections • Effective multiplicative decrease of concurrent connections is 0.6-0.75 • Concurrent connections window behavior is more aggressive than standard TCP Reno

  15. Enhanced TCP Loss Recovery • Send a new packet when first or second duplicate ack arrives as enablesbetter data-driven loss recovery. • Avoided 25% of all coarsetimeouts (compared to only 4% with basic SACKs).

  16. “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

  17. “Solution” #2: Integrated TCP Sessions r1 r2 r3 Server Client r-n • Independent TCP connections, but shared control parameters • But many applications don’t want a connection-oriented reliable in-order stream of data

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

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

  20. Integrated Congestion Control • Problem: poor congestion control and loss recovery by short, concurrent connections • Solution: integrated congestion control and loss recovery across multiple concurrent connections • One Congestion wnd per macro-flow • AIMD • Congestion wnd halved on a packet loss • Exponential aging when feedback low • Halve window every RTT (minimum)

  21. Integrated Loss Recovery 1 2 Router Server 3 2 3 1 Client Later acks Router Server Client 1 1 1 2 3 dupack Router 2 Server Client 3 Acknowledgments Data Packets

  22. TCP Sack vs TCP-INT • Integrated loss recovery helps prevent coarse timeouts • Integrated congestion control allows different connections to obtain equal share of bandwidth • Later connections do not have to slow start

  23. Results: Integrated Congestion Control • TCP-SACK does per-connection congestion control, TCP-INT does per-host • TCP-INT connection C avoids performing slow-start

  24. Integrated Loss Recovery - Performance

  25. CM Linux Implementation App stream Stream requests, updates cmapp_*() libcm.a User-level library; implements API System calls (e.g., ioctl) Control socket for callbacks UDP-CC TCP CM macroflows, kernel API Congestion controller Scheduler Prober ip_output() ip_output() cm_notify() IP

  26. CM TCP Performance TCP Newreno Flows using CM show good social behavior Sequence number With CM Time (s) CM greatly improves performance predictability and consistency

  27. System Performance

  28. Summary • CM enables proper and stable congestion behavior • Simple API to enable application to learn and adapt to network state • Improves consistency and predictability of network transfers • CM provides benefit even when deployed at senders alone

  29. Some Issues for Discussion • Why should anyone deploy it? (Given that total throughput is less than sum of individual throughputs). • How much is the system overhead if a user-space application uses the provided APIs? • What are the other possible ways of forming macro-flows? • How practical is CM’s deployment? (presently implemented only in kernel version 2.2.9) • CM is specific to unicast flows but what about multicast?

  30. Multiple Losses X X Now what? X Retransmission X Duplicate Acks Sequence No Time

  31. Tahoe X X X X Sequence No Time

  32. Reno X X X Now what? - timeout X Sequence No Time

  33. NewReno X X X Now what? – partial ack recovery X Sequence No Time

  34. SACK X X X Now what? – send retransmissions as soon as detected X Sequence No Time

More Related