1 / 25

Equation-Based Congestion Control for Unicast Applications

Sally Floyd, Mark Handley, Jitendra Padhye & Jorg Widmer. Equation-Based Congestion Control for Unicast Applications.

ila-bell
Download Presentation

Equation-Based Congestion Control for Unicast Applications

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. Sally Floyd, Mark Handley, Jitendra Padhye & Jorg Widmer Equation-Based Congestion Control for Unicast Applications August 2000, ACM SIGCOMM Computer Communication Review, Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, Volume 30 Issue 4

  2. Motivation • Smooth adjustment of sending rate • Respond to congestion slower and less severe • TCP-friendly • Coexist TCP-Friendly Rate Control (TFRC)

  3. Outline • Introduction of TFRC • TCP response function • Protocol features • Simulation and experiments • Conclusion

  4. TCP-Friendly Rate Control (TFRC) • Equation-based (c.f. window-based of TCP) • Adjust sending rate according to control equation • Calculate at sender side with the aid of receiver feedback • Do not aggressively seek out available bandwidth; increase sending rate slowly in response to a decrease in loss event rate • Do not halve sending rate upon single loss event; however, do halve in response to several successive loss event

  5. TFRC • Advantage: • Smooth-changing sending rate • Disadvantage: • Slower response to sudden bandwidth increase

  6. TCP response function • T: sending rating (calculated at sender) • s: packet size (known by sender) • R: round trip time (calculated at sender) • tRTO: timeout value, estimated from R • p: loss event rate (calculated at receiver)

  7. TCP response function • SRTT: estimate round trip time (calculated from receiver feedback) • RTTvar: variance of round trip time

  8. TCP response function • p is loss event rate instead of packet loss rate • loss event can consist of several packet lost within a round-trip time • loss interval is defined as the number of packets between loss events • use Average Loss interval method

  9. Average Loss Interval method

  10. Average Loss Interval method

  11. Average Loss Interval method • s0 is the most recent loss interval • when a loss event occurs, s0 becomes s1 and new s0 becomes zero • ignore s0 unless s0 is large enough to increase the average

  12. History discounting • problem of average loss interval method: • slow to respond to a sustained decrease in congestion • when s0 > twice the average loss interval • reduce the weights of older loss intervals

  13. TCP response function • If Tactual < Tnew increase sending rate else decrease sending rate

  14. Slowstart • Reno increase sending rate by 2 for each round-trip time • rate-based protocol does not have such a limitation; to prevent overshoot • Treceived : rate of packets arrived at receiver • slowstart terminates upon loss occurs

  15. Protocol features • loss fraction vs loss event fraction • stable steady-state packet loss rate, difference at most 10% • multiple packet drops is uncommon in RED, but relatively more common in droptail • difference diminishes if congestion persists

  16. Protocol features • increasing transmission rate • ~0.14 packet/RTT (without history discounting)* • ~0.22 packet/RTT (with history discounting)* • no need of explicit control of bursty traffic • response to persistent congestion • require 4-8 RTT to halve sending rate • response to quiescent senders *derivation skipped, interested readers may refer to the paper

  17. Simulation Results

  18. Simulation Results

  19. Simulation Results

  20. Simulation Results

  21. Long background traffic

  22. Short background traffic

  23. Experiment Results

  24. Experiment Results

  25. Conclusion • highly varying throughput not suitable for streaming • TFRC is one of the protocols trying to cope to it • smoothness and interflow fairness • loss event • do not halve sending rate upon a loss event • do halve sending rate upon persistent congestion and more gentle increase in sending rate

More Related