1 / 37

Congestion controllers for high bandwidth connections

Congestion controllers for high bandwidth connections. Srisankar Kunniyur University of Pennsylvania http://www.seas.upenn.edu/~kunniyur. Roadmap. Challenges in high bandwidth connections Transient behavior Steady-state behavior Simulations Discussions. Challenges with current TCP.

derica
Download Presentation

Congestion controllers for high bandwidth connections

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 controllers for high bandwidth connections Srisankar Kunniyur University of Pennsylvania http://www.seas.upenn.edu/~kunniyur

  2. Roadmap • Challenges in high bandwidth connections • Transient behavior • Steady-state behavior • Simulations • Discussions

  3. Challenges with current TCP

  4. Congestion Avoidance Phase • After a brief slow-start behavior, connection goes into congestion avoidance • W <- W + 1/W for every ACK received • Congestion window grows linearly with round-trip delay • A 1 Gbps throughput with 100 ms round-trip delay requires W ¼ 12500 packets • Window increase too slow!

  5. Multiplicative decrease • Consider a sample TCP evolution W W/2

  6. Multiplicative decrease • Designed for low capacity links to prevent congestion collapse • Too conservative for high bandwidth links • Effective throughput of TCP is small

  7. Packet corruption rates • TCP considers all packet losses as congestion notification • Packet corruption rates in fibers fp¼ 10-9 • For low bandwidth connections, dropping probability p >> fp • For high bandwidth connections, not true • Provides false congestion notification to TCP

  8. Packet corruption rates • Throughput of a TCP connection / 1 / p1/2 • Assume fp¼ 10-10 packets/sec • Throughput of TCP is limited to 1 Gbps regardless of link capacity • Similar to wireless scenario, but phenomena occurs at high bandwidths

  9. Solution

  10. Congestion Avoidance phase • Diagnosis • Initial congestion avoidance phase too conservative • Solution • Require a more aggressive congestion avoidance phase for high bandwidth links • Modify congestion response for connections through high bandwidth links

  11. Anti-ECN (AECN) Marking • Use a single bit feedback from the routers • An aggressive congestion avoidance phase when links are underutilized • Performance identical to current TCP during periods of congestion • No per flow state at the routers

  12. Modifications to TCP (1/2) • Each packet carries a bit (AECN bit) in its header • Initially set to one • If link is underutilized, router performs an AND operation between AECN bit and 1. • Otherwise, router performs an AND operation between the AECN bit and 0

  13. TCP Modification (2/2) • On receiving a set AECN bit, the source implements W Ã W +  / W • If D = 1, we get the congestion-avoidance phase • If D = W, we get the slow-start • D is a design parameter

  14. Implementation at the routers • On receiving an AECN capable packet, router determines whether the flow can increase its rate • Simple solution is to base this decision using the current load at the router • If current utilization is below a certain threshold(AECN threshold), the router sets the AECN bit

  15. 1 & 1 = 1 1 1 C C B Real Queue C C B* Virtual Queue

  16. 1 & 0 = 0 1 0 C C B Real Queue C C B* Virtual Queue

  17. Incremental Deployment • Many routers on a path might not recognize AECN marking • At the start of a session, the congestion-controller needs to know whether the path supports AECN marking • Achieved using SYN packet along with the TTL field

  18. Connection Startup • Each TCP flow incorporates a new field (AECN-SYN) field in the SYN packet • An AECN capable router decrements this field along with the TTL field • An AECN incapable or unwilling router just decrements the TTL field. • Presence of a single AECN unwilling router will result in different values of the TTL field and AECN-SYN field • For security, the sender can set a random number for the AECN-SYN field and request the receiver to echo back both the AECN-SYN field and the TTL field.

  19. Misbehaving Flows • AECN marking leads to aggressive increase in rates • Receiver has an incentive to misbehave by falsely setting AECN bit in the packet • Misbehaving flows can not only disproportionately increase their share of the bandwidth, but can cause congestion collapse of the network

  20. Solution (1/2) • Use a strategy similar to the one employed by ECN marking • Use two bits instead of one for AECN marking • Sender randomly chooses 01, 10 or 11 to be set in the AECN field • Each router does a bit-wise AND with the AECN bits

  21. Solution (2/2) • Each router performs an AND operation with 11 if AECN is allowed to be set and 00 otherwise. • If AECN cannot be supported, receiver receives 00 • If receiver wants to misbehave, it has to correctly choose between 01, 10 and 11. • The probability of success is 0.33 and it goes down geometrically to zero

  22. Simulation Topology • Single link topology with ns-2 simulator 1 Gbps Destinations Sources

  23. Simulation Parameters • Evolution of congestion window of TCP with and without AECN marking. • Set the round-trip delay to 200ms • Vary the AECN-Threshold (AECN-threshold determines when the router provides AECN marking)

  24. Multiplicative decrease • Diagnosis: • Too aggressive reduction in window size • Solution: • Decrease  to reduce the impact • Proposed by Floyd in high speed TCP • Can show the stability of this scheme using linear system analysis • Throughput / 1 / p0.82

  25. Packet Corruption • The new solution still suffers from throughput degradation due to false congestion notifications from packet corruption • Require p >> fp regardless of capacity of the links

  26. Modified TCP • Use the following congestion controller • T – Round trip delay, qr – Marking Prob • r – Adaptation speed •  and  are constants

  27. Equilibrium Properties • Steady state throughout x*/ 1 / (p - )1/2 • p >  •  >> fp ensures that p >> fp • x*!1) p ! •  also decides TCP friendliness at low capacities

  28. TCP Friendliness • Require TCP friendliness at “low” capacities • Need (p-) ¼ p • Choose  such that the above condition is satisfied for low capacities • Note that this also forces • 1/( x2 + ) ¼ 1/  • Choose  = 0.5 to emulate TCP

  29. Utility maximization • What is the utility of such controllers in the utility maximization problem? • Add a linear term to the utility • Utility of a TCP user ¼ -1/(T2 x) • Utility of the new congestion controller ¼ -1/(T2 x) +  x • Retains the properties of TCP

  30. Simulation • Fluid level simulations • Single link with capacity 6 units • Assume a fiber loss rate of 10-3 • Choose  = 10-2 • Compare the performance of a TCP controller with that of the modified congestion controller

  31. Simulations – High Capacities • Change capacity to 1000 units • Other parameters remain fixed

  32. Discussions • Short flows not considered • A preset rate can be set using the SYN packet • TCP friendliness • What does it mean at high capacities? • Need to consider how “friendly” the algorithm is to large aggregates of TCP connection • Is packet switching the best option for high bandwidth, large data set transfers?

  33. Conclusions • In high bandwidth connections, TCP is limited by three factors • Slow increase in window size • Fix it using feedback from routers • Aggressive decrease of multiplicative decrease parameter • Packet corruption rates • Fix both using adaptive multiplicative decrease parameter.

More Related