CORNELL CS 419 - Lecture 10 Transport: TCP congestion control

Unformatted text preview:

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

CORNELL CS 419 - Lecture 10 Transport: TCP congestion control

Download Lecture 10 Transport: TCP congestion control
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 10 Transport: TCP congestion control and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 10 Transport: TCP congestion control 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?