Goals of Today s Lecture! Congestion Control! Course So Far.! Congestion Control Overview! It s Not Just The Sender & Receiver! Congestion is Natural!

Transcription

1 Goals of Today s Lecture! Congestion Control! EE 22: Intro to Communication Networks Fall 200 (MW 4-5:30 in 0 Barker) Scott Shenker TAs: Sameer Agarwal, Sara Alspaugh, Igor Ganichev, Prayag Narula Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson and other colleagues at Princeton and UC Berkeley Congestion Control: Overview End system adaptation controlling network load Congestion Control: Some Details Additive-increase, multiplicative-decrease (AIMD) How to begin transmitting: Slow Start (really fast start ) Why AIMD? Listing of Additional Congestion Control Topics Will repeat myself several times in this lecture Easy to think you understand congestion control Trust me, you don t!!because I don t either! 2 Course So Far.! We know: How to process packets in a switch How to route packets in the network How to send packets reliably How to not overload a receiver How to split infinitives!! We don t know: How to not overload the network! 3 Congestion Control Overview! 4 It s Not Just The Sender & Receiver! Flow control keeps one fast sender from overwhelming a slow receiver Congestion control keeps a set of senders from overloading the network Huge academic literature on congestion control Advances in mid-80s by Jacobson saved the Internet Well-defined performance question: easy to write papers Less of a focus now (bottlenecked access links?)!!but still far from academically settled o E.g. battle over with Bob Briscoe! 5 Congestion is Natural! Because Internet traffic is bursty! If two packets arrive at the same time The node can only transmit one! and either buffers or drops the other If many packets arrive in a short period of time The node cannot keep up with the arriving traffic! delays, and the buffer may eventually overflow 6

2 Load and Delay! Typical behavior of queuing systems with bursty arrivals: Average Packet delay Ideal: low delays and high utilization Reality: must balance the two Maximizing power is an example Power Load Power = Delay Dynamic Adjustment by End systems! Probe network to test level of congestion Speed up when no congestion Slow down when congestion Drawbacks: Suboptimal (always above or below optimal point) Messy dynamics Relies on end system cooperation Load optimal load Load Might seem complicated to implement But algorithms are pretty simple (Jacobson/Karels 88) Understanding global behavior is not simple!. Question: How do we balance utilization and delay?! 7 8 Basics of TCP Congestion Control! Each source determines the available capacity! so it knows how many packets to have in flight Congestion window (CWND) Maximum # of unacknowledged bytes to have in flight Congestion-control equivalent of receiver window MaxWindow = min{congestion window, receiver window} Send at the rate of the slowest component Adapting the congestion window Decrease upon detecting congestion Increase upon lack of congestion: optimistic exploration Note: TCP congestion control done only by end systems, not by mechanisms inside the network 9 Detecting Congestion! How can a TCP sender determine that the network is under stress? Network could tell it (ICMP Source Quench) Risky, because during times of overload the signal itself could be dropped (and add to congestion)! Packet delays go up (knee of load-delay curve) Tricky: noisy signal (delay often varies considerably) Packet loss Fail-safe signal that TCP already has to detect Complication: non-congestive loss (checksum errors) 0 How to Adjust CWND?! Increase arly, decrease multiplicatively (AIMD) Consequences of over-sized window much worse than having an under-sized window o Over-sized window: packets dropped and retransmitted o Under-sized window: somewhat lower throughput Will come back to this later Leads to the TCP Sawtooth! Window Loss Additive increase On success for last window of data, increase arly o TCP uses an increase of one packet (MSS) per RTT halved Multiplicative decrease On loss of packet, TCP divides congestion window in half t 2

3 AIMD Starts Too Slowly!! Need to start with a small CWND to avoid overloading the network. Window It could take a long time to get started! t 3 Slow Start Phase! Start with a small congestion window Initially, CWND is MSS So, initial sending rate is MSS/RTT That could be pretty wasteful Might be much less than the actual bandwidth Linear increase takes a long time to accelerate Slow-start phase (actually fast start ) Sender starts at a slow rate (hence the name)! but increases the rate exponentially! until the first loss event 4 Slow Start in Action! Double CWND per round-trip time Simple implementation: on each ack, CWND += MSS Another Picture of Slow-Start! Each ACK releases two packets cwnd = segment Src Dest D A D D A A D D D D A A A A 8 cwnd = 2 cwnd = 3 cwnd = 4 cwnd = 5 cwnd = 6 cwnd = 7 cwnd = 8 segment 2 segment 3 segment 4 segment 5 segment 6 segment Slow Start and the TCP Sawtooth! This has been incredibly successful! Window Leads to the theoretical puzzle: Loss If TCP congestion control is the answer, then what was the question? Exponential slow start t Not about optimizing, but about robustness Hard to capture! Why is it called slow-start? Because TCP originally had no congestion control mechanism. The source would just start by sending a whole window s worth of data. 7 8

4 Increasing CWND! Increase by MSS for every successful window Congestion Control Details! Increase a fraction of MSS per received ACK # packets (thus ACKs) per window: CWND / MSS Increment per ACK: CWND += MSS * (MSS / CWND) 9 Termed: Congestion Avoidance Very gentle increase 20 Detecting Packet Loss! If retransmitting, already assuming packet loss Two criteria for retransmissions Packet can timeout (RTO timer expires) But RTO is often ~ 500msec Fast retransmit When same packet gets acked 4 times (3 DupACKs) Congestion control treats these events differently Fast Retransmission! Packet n is lost, but packets n+, n+2,!, arrive On each arrival of a packet not in sequence, receiver generates an ACK ACK is for seq.no. just beyond highest in-sequence So as n+, n+2,! arrive, receiver generates repeated ACKs for seq.no. n duplicate acknowledgments since they look the same Sender sees 3 of these dupacks and immediately retransmits packet n (and only n) Multiplicative decrease and keep going CWND halved 2 22 CWND with Fast Retransmit! cwnd = cwnd = 2 cwnd = 3 cwnd = 4 3 duplicate ACKs cwnd = 2 ACK 2 ACK 3 ACK 4 ACK 4 ACK 4 ACK 4 segment segment 2 segment 3 segment 4 segment 5 segment 6 segment 7 segment 4 Loss Detected by Timeout! Sender starts a timer that runs for RTO seconds Every time ack for new data arrives, restart timer If timer expires: Set SSTHRESH! CWND / 2 ( Slow-Start Threshold ) Set CWND! MSS (avoid a burst) Retransmit first lost packet Execute Slow Start until CWND > SSTHRESH After which switch to Additive Increase 23 24

5 Summary of Decrease! Cut CWND half on loss detected by NACK fast retransmit Cut CWND all the way to MSS on timeout Set ssthresh to cwnd/2 Never drop CWND below MSS Summary of Increase! Slow-start : increase cwnd by MSS for each ack Leave slow-start regime when either: cwnd > SSThresh Packet drop Enter AIMD regime Increase by MSS for each window s worth of acked data Repeating Slow Start After Timeout! Slow Start/AIMD Pseudocode (Not FR)! Window Fast Retransmission Slow start in operation until it reaches half of previous CWND, I.e., SSTHRESH Timeout SSThresh Set to Here Slow-start restart: Go back to CWND of MSS, but take advantage of knowing the previous value of CWND. t 27 Initially: cwnd = MSS; ssthresh = infinite; New ack received: if (cwnd < ssthresh) /* Slow Start*/ cwnd = cwnd + MSS; else /* Congestion Avoidance */ cwnd = cwnd + MSS/cwnd; Timeout: /* Multiplicative decrease */ ssthresh = cwnd/2; cwnd = MSS; 28 Announcements! No office hours today HW3a grades released 5 Minute Break! On Monday Igor will review Networking Libraries For 45 minutes Then I will cover Overlays and P2P!. Questions Before We Proceed? 29 30

6 Three Congestion Control Challenges! Why AIMD?! In what follows refer to cwnd in units of MSS Single flow adjusting to bottleneck bandwidth Without any a priori knowledge Could be a Gbps link; could be a modem Single flow adjusting to variations in bandwidth When bandwidth decreases, must lower sending rate When bandwidth increases, must increase sending rate Multiple flows sharing the bandwidth Must avoid overloading network And share bandwidth fairly among the flows 3 32 Problem #: Single Flow, Fixed BW! Want to get a first-order estimate of the available bandwidth Assume bandwidth is fixed Ignore presence of other flows Want to start slow, but rapidly increase rate until packet drop occurs ( slow-start ) Adjustment: cwnd initially set to (MSS) cwnd++ upon receipt of ACK Problems with Slow-Start! Slow-start can result in many losses Roughly the size of cwnd ~ BW*RTT Example: At some point, cwnd is enough to fill pipe After another RTT, cwnd is double its previous value All the excess packets are dropped! Need a more gentle adjustment algorithm once have rough estimate of bandwidth Problem #2: Single Flow, Varying BW! Want to track available bandwidth Oscillate around its current value If you never send more than your current rate, you won t know if more bandwidth is available Possible variations: (in terms of change per RTT) Multiplicative increase or decrease: cwnd" cwnd * / a Additive increase or decrease: cwnd" cwnd +- b 35 Four alternatives! AIAD: gentle increase, gentle decrease AIMD: gentle increase, drastic decrease MIAD: drastic increase, gentle decrease too many losses: eliminate MIMD: drastic increase and decrease 36

7 Why AIMD?! What s wrong with AIAD? Problem #3: Multiple Flows! Want steady state to be fair What s wrong with MIMD? Many notions of, but here just require two identical flows to end up with the same bandwidth This eliminates MIMD and AIAD As we shall see! AIMD is the only remaining solution! Not really, but close enough! Buffer and Window Dynamics! A No congestion! x increases by one packet/rtt every RTT Congestion! decrease x by factor 2 60 x Rate (pkts/rtt) B C = 50 pkts/rtt AIMD Sharing Dynamics! A D x x 2 " No congestion! rate increases by one packet/rtt every RTT " Congestion! decrease rate by factor 2 B E Rates equalize! fair share Backlog in router (pkts) Congested if > AIAD Sharing Dynamics! Simple Model of Congestion Control! A D x x 2 " No congestion! x increases by one packet/rtt every RTT " Congestion! decrease x by B E Two TCP connections Rates x and x 2 Congestion when sum> Efficiency: sum near Fairness: x s converge underload 2 user example overload User : x Efficiency

8 Example! AIAD! Total bandwidth Inefficient: x +x 2 =0.7 Efficient: x +x 2 = Fair (0.2, 0.5) (0.7, 0.5) (0.5, 0.5) Congested: x +x 2 =.2 (0.7, 0.3) Increase: x + a I Decrease: x - a D Does not converge to (x h -a D,x 2h -a D ) (x h -a D +a I ), x 2h -a D +a I )) (x h,x 2h ) Efficient: x +x 2 = Not fair efficiency efficiency User : x 43 User : x 44 MIMD! AIMD! Increase: x*b I Decrease: x*b D Does not converge to (x h,x 2h ) (b d x h,b d x 2h ) (b I b D x h, b I b D x 2h ) Increase: x+a D Decrease: x*b D Converges to (x h,x 2h ) (b D x h,b D x 2h ) (b D x h +a I, b D x 2h +a I ) efficiency efficiency User : x 45 User : x 46 Additional Congestion Control Topics! Other Congestion Control Topics! TCP compatibility Everyone has to use congestion control that shares fairly Equation-based congestion control [ r ~ /sqrt(d) ] Extending TCP to higher speeds Signaling congestion without packet drops (ECN) Router involvement with congestion control Ensuring (no need for single standard) Better than AIMD Economic models (Kelly) 47 48

9 Summary! Congestion is natural Internet does not reserve resources in advance TCP actively tries to grab capacity Congestion control critically important AIMD: Additive Increase, Multiplicative Decrease Congestion detected via packet loss (fail-safe) Slow start to find initial sending rate & to restart after timeout Next class: Igor: Networking Libraries Scott: Overlays and P2P 49