CS419: Computer NetworksLecture 10, Part 4: Apr 18, 2005Transport: TCP congestion controlCS419TCP performance| We’ve seen how TCP “the protocol” worksz Sequencing, receive window, connection setup and teardown| And we’ve seen techniques to make it perform wellz RTT estimation, sending big packets, compression, fast timeoutCS419TCP congestion control| Now lets finish the picture:| How TCP avoids and controls congestion in the network| Without this, TCP still won’t perform well…CS419What is congestion?| Lets distinguish between a strict definition of congestion and a working definition of congestion| Strictly:z Congestion occurs anytime more than one packet competes for the same link at the same timeCS419Question:| Do we want to prevent instances of multiple packets competing for the same link at the same time?CS419Answer:| No!| Pure circuit networks avoid ever having two packets compete for the same link at the same timez (more or less)| By reserving a fixed amount of bandwidth at each link for each connection| But as we’ve already discussed, for bursty traffic, utilization is low!CS419Queues in switches| Queues deal with congestion at packet timescalesz Two packets arrive at the same time, one is queued behind the other| Queues allow us to increase the utilization of linksz At the expense of packet delay| In this sense, packet timescale congestion is actually good!CS419Delay and throughput| With no queue, sender can never send at more than 400Kbps| If sender bursty, then bursts are limited to 400Kbps, z with links unused during periods between burstsCS419Delay and throughput| With a queue, sender can burst at 10Mbps| Burst will start to fill the queue| After burst is over, queue empties into slow linkz Link utilized during silent periods!CS419Load, delay and powerAveragePacket delayLoadTypical behavior of queuing systems with random arrivals:PowerLoadA simple metric of how well the network is performing:LoadPowerDelay=“optimalload”Burstiness tends to moveasymptote to the leftSlide from Nick McKeown, StanfordCS419Our definition of congestion| Where network load is large enough that queues overflow and packets are lost| We are also concerned with “congestion collapse”CS419Load, delay, and throughput: what’s wrong with this picture??CS419Queue’s aren’t infinite, packets get droppedCS419Why congestion collapse?| Lost packets leads to retransmissions| Retransmissions add to load, resulting in more lost packets| Packets may go several hops before being droppedz Using up resources along the way| Note congestion collapse doesn’t occur where there are no retransmissionsCS419TCP was causing congestion collapse| In the late 1980’s---Internet was becoming unusable!| Solution attributed to Van Jacobsen| Problem was that the network did not signal the host when there was congestionz ICMP source quench wasn’t widely implementedCS419TCP congestion control| Basic idea:z TCP gently “probes” the network to determine its capacityz Uses dropped packets as a sign of congestionz Backs off when congestion sensedCS419TCP congestion control goals| First and foremost, prevent congestion collapse| Also, fairly apportion resourcesz Each TCP flow gets an equal amount of the link bandwidth| While achieving good performancez Keep the pipe full, but not too full!CS419Ideal TCP behavior| Bottleneck bandwidth determines inter-packet spacingz Sender should space packetsCS419How can TCP sender space packets properly?| Any ideas?CS419How can TCP sender space packets properly?| Simple solution: use returned ACKs to clock packets out!receiversenderCS419Ideal TCP behavior| Get the pipe full| Once full, use return ACKs to clock out new packets| Now the question is, how to you know when the pipe is full???CS419Answer:| You don’t know when the pipe is full!| You only know when it is too full!z When there is a packet lossz Actually, more recent work challenges this…| So, what TCP does is slowly fill the pipe until it is too full, then drain the pipe some and start filling again . . .CS419TCP congestion control| Sender maintains two windows:z The advertised receive window we learned aboutz A congestion window (cwnd)| The actual window is the minimum of the two:z Window = min{Advertized window, cwnd}| In other words, send at the rate of the slowest component: network or receiverCS419Setting the congestion window (cwnd)| Increase cwnd conservatively| Decrease cwnd aggressivelyz When loss detected, cut in half!z Multiplicative decrease| Cwnd increase has two phases:z Additive phase (when pipe is full)z Multiplicative phase (when pipe is empty)• Called “slow start”!CS419AIMD: Additive Increase Multiplicative Decrease| Used when pipe is full| Every RTT, add one “packet” to the cwndz Actually, one MSS worth of bytesz Since multiple ACKs per RTT, a fraction of MSS added per ACK| If loss detected (timeout or duplicate ACKs), decrease cwnd by halfCS419Additive IncreaseSourceDestination…CS419The famous AIMD sawtoothtWindowhalvedTimeoutsCould take a long time to get started!CS419“Slow start”| Additive increase takes too long to fill pipe when pipe is emptyz i.e. at the beginning of a connection| During slow start, double the cwnd every RTTz Increase the cwnd for every ACK receivedCS419Slow startSourceDestination…CS419Two reasons for an empty pipe| Beginning of the connectionz In this case, do “slow start” until packet loss| Restart after a “stalled connection”z If timeout, then the pipe is emptyz In this case, we remember the previous cwndz Do slow start until cwnd reaches 1/2 the previous cwnd, then do additiveCS419Slow starthalvedTimeoutsExponential “slow start”tWindowSlow start in operation until it reaches half of previous cwnd.CS419Slow start packet sequenceCS419Continued (slow start to ½ previous cwnd)CS419Fast Recovery| Recall fast retransmitz Retransmit after three duplicate ACKs (don’t wait for a timeout)| We can also use the duplicate ACKs to avoid dropping all the way back to slow start| This is called fast recovery (always implemented as part of fast retransmit)CS419Fast Retransmit and Recovery| If we get 3 duplicate acks for segment Nz Retransmit segment Nz Set ssthresh to 0.5*cwndz Set cwnd to ssthresh + 3| For every subsequent duplicate ackz Increase cwnd by 1 segment| When new ack receivedz Reset cwnd to ssthresh (resume congestion avoidance)CS419Fast Recovery Examplefast retransmitafter 3 dup ACKsfast recoverydue to add’tldup ACKsCS419TCP
View Full Document