1 / 14

TCP Congestion Control

TCP Congestion Control. Ashvin Goel CSE 581: Internet Technology (Winter 2002). TCP. Congestion control crucial for Internet stability TCP uses AIMD congestion control mechanism Additive increase ( α) - one packet increase per RTT Multiplicative decrease ( β) - half send rate per RTT

bonnyj
Download Presentation

TCP Congestion Control

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 Congestion Control Ashvin Goel CSE 581: Internet Technology (Winter 2002)

  2. TCP • Congestion control crucial for Internet stability • TCP uses AIMD congestion control mechanism • Additive increase (α) - one packet increase per RTT • Multiplicative decrease (β) - half send rate per RTT • Some other key mechanisms • Packet conservation (self-clocking feedback) • Slow start

  3. TCP Friendliness • TCP dominant protocol on Internet • Other protocols should be “friendly” with TCP • TCP provides • Roughly equal bandwidth for similarly situated (same RTT) flows with same packet size • Bandwidth is proportional to 1/sqrt(p), p is packet loss rate • Friendliness • Another protocol should have the same characteristics

  4. Slowly Responsive Congestion Control (CC) • Problem: TCP probes for spare bandwidth and reacts to congestion aggressively, decreasing its rate by half • Motivation • Best-effort streaming multimedia traffic can benefit from a slowly changing transmission rate • Smoother bandwidth profile may provide more fairness among flows

  5. Slowly Responsive CC Examples • GAIMD: Generalize TCP • Make α less than 1 • Make β greater than ½ • Equation-based approaches • Calculates maximum sending rate as a function of recently observed loss rate • TCP-Friendly Rate Control (TFRC) • TCP Emulation at Receivers (TEAR)

  6. TFRC - Equation Based CC • Calculates loss event rate at receiver • Not lost packet rate • Calculates RTT at sender • Challenges: • Averaging of loss event rate • Tradeoff between responding rapidly to bandwidth changes and getting a less noisy loss signal • Sending rate response to changing RTT • “Incorrect” response leads to oscillatory sending rate

  7. TFRC (continued) • Averaging uses an Average Loss Interval method • Same weight to last N/2 intervals • Decreasing weight to N/2+1 to N intervals • Use a fancy method to adjust sending rate to changes in RTT (don’t understand fully)! • Sender plugs value of estimated Loss and estimated RTT to figure out sending rate • Doesn’t depend on individual packet loss, unlike AIMD schemes)

  8. Evaluation • Static Behavior • Response to current levels of congestion and bandwidth • Dynamic Behavior (transient response) • Response to increasing congestion • Response to increasing available bandwidth • Measurements • Effects of congestion • Fairness and relative throughput • Smoothness in sending rate

  9. Results: Dangers of slow CC • Slow response to reduced available bandwidth, could lead to longer persistent congestion • Metrics • Stabilization time: nr. of RTT until loss rate is close to steady-state level • Stabilization cost: product of stabilization time and average loss rate • Value of 1 means one round trip worth of packets is lost

  10. Key Finding About Persistent Congestion • Have to incorporate self-clocking in slow CC to reduce stabilization cost • TFRC • Limits sending rate to packet receive rate for round trip following packet loss • Limits sending rate to C * packet receive rate in absence of loss (paper has C set to 1.1!) • Question: how does self-clocking affect smoothness?

  11. Results: Drawbacks of slow CC • Unfairness with respect to TCP • Metrics • Long-term fairness: total throughput • Short-term fairness: delta-fair convergence time • Lower bottleneck link utilization • Metrics • Average link utilization in k round trips after bandwidth has doubled

  12. Key Findings about Fairness, Utilization • Varying network conditions favor TCP (expected) • Only under very short periods, TFRC receives more bandwidth • Period of competing CBR flow has significant impact on throughput • TFRC achieves 65% utilization after 20 round trips after bandwidth has doubled (TCP – 86%)

  13. Results: Benefits of slow CC • Sending rate is smoother than TCP • In a steady-state environment with reasonably (and low) smooth packet losses • Metrics • Smoothness metric: largest ratio of sending rate in two consecutive round trip • TFRC has 1 • TCP has 1 - β

  14. Key Findings about Smoothness • TFRC has much longer memory about losses • TFRC has much better smoothness and slightly better throughput when loss rate is small and reasonably smooth • TFRC can perform worse than TCP in smoothness and throughput in the worst case • It performs worst when there are short, spaced phases of high congestion!

More Related