1 / 21

Congestion Control for BIG FAT Pipes

Congestion Control for BIG FAT Pipes. Presentation by Joe Szymanski For Upper Layer Protocols August 24, 2014. What is a big fat pipe?. High bandwidth-delay product What is the unit of measure? Bits per seconds times seconds results in bits? Bandwidth-delay product is max bits “in flight”.

lisle
Télécharger la présentation

Congestion Control for BIG FAT Pipes

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. Congestion Control forBIGFAT Pipes Presentation by Joe Szymanski For Upper Layer Protocols August 24, 2014

  2. What is a big fat pipe? • High bandwidth-delay product • What is the unit of measure? • Bits per seconds times seconds results in bits? • Bandwidth-delay product is max bits “in flight” 1 bps Data 7 6 5 4 3 2 1 Delay = 6 seconds

  3. Why are big fat pipes special? • Two parts to bandwidth-delay • Bandwidth  high speed • Delay • Each requires special considerations with regards to congestion control

  4. The effects of high speed • During steady data transfer: • What error rate is needed to reach a given throughput? • For packet size = 1500 bytes and RTT = 100 ms: • To reach a throughput of 10 Gbps: That’s one lost packet every 1.6 hours!

  5. Other difficulties for high speed • Packet loss rate creates a limit to max window size • How long to reach max throughput in slow start? • For a 10Gbps link, it takes a windows size of 83,333 packets and 17 RTTs • Recovery from consecutive timeouts • Two consecutive timeouts  ? • First timeout  • Second timeout  • To reach 10Gbps again, it takes 83,332 RTTs ssthresh = cwnd/2, cwnd = 1 MSS ssthresh = 2 MSS, cwnd = 1 MSS

  6. What about high delay? • High delay means lots of bits are in flight at once • A single loss takes just over 1 RTT to be detected • 2 × bandwidth-delay product bits are sent between loss and detection of loss • All of these bits potentially need to be retransmitted • What can fix this? • SACK with selective repeat

  7. Proposed Solutions • High Speed TCP • Proposed by Sally Floyd • The ICSI Center for Internet Research • Once the congestion window reaches a threshold, a new function is used for window increases and decreases • H-TCP • Proposed by D. Leith and R. Shorten • Hamilton Institute, NUI Maynooth • Changes the values for additive increase and multiplicative decrease based on congestion

  8. High Speed TCP (Floyd) • While packet drop rate p < 0.0015 (or while congestion window < 31), use standard TCP rules • Otherwise, increase/decrease the congestion window by a function of the current congestion window • If Wi is the current congestion window, let Wi+1 f(Wi) • Different functions are used for increase and decrease of the congestion window

  9. High Speed TCP (Floyd) (cont’d) • Through a lot of math based on the chosen packet drop rate and the required throughput, the following are given for a (the function for increasing the cwnd) and b (the function for decreasing the cwnd) • w is the current congestion window (in packets) • W is the threshold to use the new equations • W1 is the required final throughput • B = b(W1)

  10. HTCP (Leith, Shorten) • Using an analysis of drop-tail networks, it is shown that a TCP friendly congestion control scheme must have the following: • Let α be the additive increase factor • Let β be the multiplicative decrease factor • α = 2(1 - β) • Highest throughput can be achieved by setting • α must be calculated as in the above equation

  11. HTCP (Leith, Shorten) (cont’d) • For each ACK, set α as a factor of the time since the last congestion event • If the last event was recently, set δ = 1 • This corresponds to standard TCP congestion control • Otherwise, set δ = f(t), where f is a function of t, the time since the last congestion event • Set α = 2(1 – β)δ to maintain TCP friendliness • For each congestion event, set β = RTTmin / RTTmax • There are functions that can be used that avoid direct calculations on RTTmin and RTTmax

  12. Implementation • Change SCTP stack to allow for congestion control modules • Implement and test an HTCP module • Standard test cases: • Loss rates of 0%, 5%, and 10% • For more details, contact me later

  13. Results, 0% loss Standard HTCP

  14. Results, 5% loss Standard HTCP

  15. Results, 10% loss HTCP Standard

  16. What happened? • HTCP performed worse than standard congestion control in high loss cases • Why? • HTCP only performed slightly better than standard congestion control otherwise • What changes can be made to increase performance? • Remove some of the multiplicative decrease

  17. Results, 0% loss HTCP Standard HTCP (Modified)

  18. Results, 5% loss Standard HTCP HTCP (Modified)

  19. Results, all cases Don’t panic! I’ll show you what each line means.

  20. What’s wrong with the modification? • Is the modified HTCP algorithm TCP friendly? • Will the modified HTCP algorithm work well on a link that is used by multiple TCP streams?

  21. Questions?

More Related