COMP 631: NETWORKED & DISTRIBUTED SYSTEMS Congestion Avoidance Jasleen Kaur Fall 2016 1 Avoiding Congestion: Strategies TCP s strategy: congestion control Ø Control congestion once it occurs Repeatedly increase load imposed on network Back-off when congestion occurs Ø TCP needs to create losses to find available bandwidth for transfer Alternative strategy: congestion avoidance Ø Predict when congestion is about to happen Ø Reduce host sending rate before packets start getting dropped We ll study four different congestion avoidance strategies: Ø Router-assisted strategies: ECN RED Ø End-point strategy: TCP Vegas TCP Rapid 2 Copyright by Jasleen Kaur 1
ECN: Explicit Congestion Notification Basic Approach: Ø Equally split responsibility of congestion control between routers and hosts Router: Ø Monitors the load it is experiencing Average queue length, average utilization, etc Ø Explicitly notifies end hosts when congestion is about to occur By setting a binary congestion bit in packets that it forwards Destination hosts echo the bit in ACKs sent to the source Source: Ø Adjusts sending rate on receiving congestion notification 3 RED: Random Early Detection Two main characteristics: Ø Implicit notification Just drop packet (end-host detects loss and infers congestion) Ø Early random drop Don t wait for queues to be full Drop packets with some drop probability whenever queue exceeds some drop level Is an example of an Active Queue Management (AQM) scheme Ø Queues are monitored and managed before heavy congestion sets in Ø Other examples: PI, REM, Blue, 4 Copyright by Jasleen Kaur 2
RED: Queue Monitoring Computes an average queue length: AvgLen = (1-a)*AvgLen + a*samplelen; where a ~ 0.002 Ø Captures the notion of long-lived congestion Bursty traffic could cause queue to fill up and empty again quickly Uses two queue length thresholds: if AvgLen MinThresh enqueue the packet else if AvgLen < MaxThresh drop arriving packet with probability p else drop arriving packet MaxThresh AvgLen MinThresh Max queue length Max thresh Min thresh Courtesy: Kevin Jeffay & Michele Weigle Forced drop Probabilistic early drop No drop 5 RED: Discussion Fairness of resource allocation: Ø The probability that RED drops a packet from a given flow is proportional to the flow s current share of bandwidth Flows that are sending more traffic are more likely to be penalized if queues grow How to set the MinThresh and MaxThresh? Ø If traffic is bursty? MinThresh should be set high to allow good link utilization Ø Given that sources take RTT delay to respond to first indication of congestion? (MaxThresh-MinThresh) should be larger than typical increase in AvgLen in RTT MaxThresh = 2*MinThresh Value of a should help filter out changes in queue length over timescales much smaller than 100 ms 7 Copyright by Jasleen Kaur 3
End-point Congestion Avoidance: Indicators How can you detect incipient stages of congestion at end-hosts? Ø See if there s a measurable increase in RTTs Ø See if it is correlated with increase in cwin if (currwin oldwin)/(currrtt oldrtt) > 0, decrease cwin; else increase cwin Sending rate fla,ens as network approaches conges4on cwin KB Sending KBps 70 60 50 40 30 20 10 1100 900 700 500 300 100 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 Time (seconds) 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 Time (seconds) Queue size in router 10 5 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 Time (seconds) 8 TCP Vegas: Approach Vegas uses a mixture of above ideas Ø Controls the amount of extra data that a transfer has in transit Extra data that would not have been transmitted if sending at exactly the network s available bandwidth Ø Computes and maintains for the transfer: BaseRTT: min RTT seen for this transfer ExpectedRate = cwin/basertt ActualRate: # of packets sent before an ACK for the first one arrives Ø Window update (where: diff = ExpectedRate ActualRate): If diff < 0, update BaseRTT Goal: Keep between Else if diff < a, increase cwin linearly a*rtt b*rtt bytes Else if diff > b, decrease cwin linearly in bottleneck queue Else leave cwin unchanged If packet loss, decrease cwin multiplicatively 9 Copyright by Jasleen Kaur 4
TCP Vegas: Approach Objective: Keep between a*rtt b*rtt bytes in bottleneck queue CWIN KB 70 60 50 40 30 20 10 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 T ime (seconds) Sending Rate KBps 240 200 160 120 80 40 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 T ime (seconds) 10 Rapid: The Packet-scale Paradigm High speed protocols Ø Still too sluggish speed-time overhead Ø Still too un-friendly overwhelm shared queues Manage speed-time dilemma Ø By shrinking congestion-control timescale Higher rates tried out for only very small durations Make them friendlier Ø By reacting to high delays as well Back off before TCP does Packet-scale paradigm instantiation of above ideas Ø Faster, smaller queues, friendlier, fair(er) Ø Issues sensitive to noise and cross-traffic burstiness 11 Copyright by Jasleen Kaur 5
Rapid: Explicit Bandwidth Estimation Abc Abc 12 RAPID Congestion Control r avg r 1 r 2 r 3 r 4 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 Time Multi-rate p-stream k-1 Multi-rate p-stream k Multi-rate p-stream k+1 No Persistent Queuing RAPID Feedback Loop: 1. Sender continuously sends multi-rate probe-streams: Ø Controls packet-gaps to probe for an exponentially-wide range 2. Receiver estimates available bandwidth for each p-stream: Ø By observing for increasing trends in inter-packet gaps Ø Sends AB estimate back to sender Simultaneous Probing for AB Increase/Decrease 3. Sender acquires estimated AB: Ø Quick AB-search By setting the average rate of next p-stream equal to AB estimate 13 Copyright by Jasleen Kaur 6
Friendliness to Regular TCP Traffic: HighSpeed Available" Bandwidth" (only Tmix)" Queues with" only Tmix" HighSpeed highly intrusive to TCP traffic! HighSpeed" Throughput" Queues with" HighSpeed+Tmix" 14 Friendliness to Regular TCP Traffic: RAPID Available" Bandwidth" (only Tmix)" Queues with" only Tmix" RAPID uses available bandwidth efficiently! While being friendly to low-speed TCP traffic RAPID" Throughput" Queues with" RAPID+Tmix" 15 Copyright by Jasleen Kaur 7
Delay-based Congestion Control: Concerns Is it efficient? Ø Will it react to transient queues (that loss-based TCP will simply let the buffers absorb)? Ø Can the RTT signal be tainted by OS issues such as interruptcoalescence, burst-switching, etc? Ø Will Vegas react to queuing on the reverse path? Is it fair? Ø How will Vegas survive in a TCP-dominated world? Would it get a fair share of bandwidth against competing TCP transfers? How will it survive in wireless environments? Ø Where several sources of random delays exist Medium access times Collision-induced exponential retransmissions Environment-based rate-adaptation 16 Can Noise Be Addressed? What causes noise? Ø Short-scale traffic bursts at bottleneck queue Ø Temporary queuing at non-bottleneck queues You want to smooth one and ignore other What is short-scale, anyways? Ø What type of bursts do you not want to ignore? How to eliminate noise? Ø Smoothing? Over what timescale? Is a fixed timescale going to work? Ø Buffering-aware smoothing strategy (BASS): Identify start and end of short-scale buffering event Smooth within each event 17 Copyright by Jasleen Kaur 8