1 / 34

A Survey of Recent High Speed TCP Variants

A Survey of Recent High Speed TCP Variants. Philip Fisher-Ogden U.C. Davis March 16 th , 2007. Outline. Why do we need high speed TCP variants? Three recent variants Compound TCP CUBIC TCP-Adaptive Reno Recent Evaluations Q&A. Standard TCP - advantages. Widely used Standardized

rex
Télécharger la présentation

A Survey of Recent High Speed TCP Variants

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. A Survey of Recent High Speed TCP Variants Philip Fisher-Ogden U.C. Davis March 16th, 2007

  2. Outline • Why do we need high speed TCP variants? • Three recent variants • Compound TCP • CUBIC • TCP-Adaptive Reno • Recent Evaluations • Q&A

  3. Standard TCP - advantages • Widely used • Standardized • Promises, promises • Guaranteed, in-order delivery • Avoids congestion collapse • Evolved: Tahoe, Reno/NewReno, SACK

  4. Standard TCP - disadvantages • Underutilization of the bandwidth in fast long distance networks (FLDnets) • Low window size resiliency to packet loss in FLDnets

  5. Prior High Speed TCPs • Effectively use available bandwidth • Unfriendly – “doesn’t play nicely with others” • Unfair to different RTT flows • Examples: HSTCP, STCP, BIC-TCP

  6. Goals • TCP friendly • Minimize bandwidth-stolen • RTT fair • Co-existing flows with different RTTs are treated fairly • Efficient use of available bandwidth

  7. Compound TCP

  8. Compound TCP - Motivation • Loss-based - uses packet loss as an indicator of congestion and modifies the increase/decrease congestion avoidance TCP parameters. • Delay-based - infers congestion and bottleneck queue size from changes in the RTT and modifies the transfer rates to mitigate the effects of congestion. • Combine both approaches • Focus on efficiency & friendliness

  9. Compound TCP - Design • Maintains a delay window and a congestion window – uses both to determine send window • Estimates the bottleneck queue size: • Diff = (Expected – Actual) * baseRTT • Has a threshold, γ, at which it says “the network is congested”

  10. Compound TCP Delay Window Calculations

  11. Compound TCP - Design • Builds on loss-based (standard) TCP • Reverts to standard TCP at low window sizes • Uses gamma-auto tuning to dynamically adjust γ, the estimated number of packets that indicate a bottleneck in the queue, based on the network configuration

  12. Compound TCP - Evaluation

  13. CUBIC

  14. CUBIC - Motivation • Enhance BIC! • Maintain BIC’s scalability & stability • Simplify the window control • Improve BIC’s friendliness • Use real-time, rather than ACK-clocked, updates to window • Improve the detection of the “TCP Region”

  15. CUBIC - Design • Based on BIC:

  16. CUBIC - Design • Window growth function:

  17. CUBIC – Design Aspects • Stability – The window grows slowly around Wmax. • Scalability – It experiences fast “probing” growth away from Wmax. • Intra-protocol fairness - Two competing CUBIC flows will converge to fair share window sizes. • Fairness – The window growth rate is time dependent and RTT independent, allowing for fairer sharing.

  18. CUBIC – Design Aspects • Standard TCP outperforms CUBIC’s window growth function in short RTT networks. • CUBIC emulates the time-independent TCP window adjustment algorithm so that it can select the greater of the two windows (emulated versus cubic) to use.

  19. CUBIC - Evaluation

  20. TCP-Adaptive Reno (AReno)

  21. TCP-AReno - Motivation • Enhance TCP-Westwood-BBE • Improve on TCP-Reno’s response function by incorporating a congestion estimate that is based on RTT measurements. • Identify if a packet loss was due to congestion or not.

  22. TCP-AReno - Design • Congestion Estimate • RTTcong = the RTT that would indicate a congestion event. • Classifies packet losses as due to congestion or not • RTT values vary between RTTmin and RTTcong. The distance of recent RTT measurements from RTTcong and RTTmin determines the level of congestion in the network.

  23. TCP-AReno - Design • Congestion Window Increase

  24. TCP-AReno - Design • Congestion Window Reduction

  25. TCP-AReno - Evaluation

  26. Recent Evaluations

  27. Recent EvaluationsLinux beats Windows!

  28. Recent EvaluationsLinux beats Windows! • BIC/CUBIC are over aggressive and steal bandwidth. • Serious unfairness

  29. Recent EvaluationsExperimental Evaluation of Cubic-TCP • Conducted partially in response to “should CUBIC be adopted in Linux?” • CUBIC suffers from a slow convergence of congestion windows. • Controversial! A rebuttal was issued by Injong Rhee (CUBIC co-author)

  30. Recent EvaluationsExperimental Evaluation of Cubic-TCP • Example of slow convergence:

  31. Recent EvaluationsAssessing Interactions among Legacy & High-Speed TCPs • Evaluated efficiency, fairness, & friendliness

  32. Recent EvaluationsAssessing Interactions among Legacy & High-Speed TCPs • Delay-based control are not effective in improving RTT-fairness due to the slow-start behavior of short flows that induces RTT measurement problems • TCP-AReno was modified to avoid having the short flow problem impact its delay based mechanism. • TCP-AReno outperformed all others. • Compound TCP came close, but experienced the delay-based control problem.

  33. Summary

  34. Q&A

More Related