Congestion Control Congestion Control n n n What

Congestion Control

Congestion Control n n n What is congestion? Methods for dealing with congestion TCP congestion control

Review of Flow Control n Receiver advertises window in ACK packets ¡ n Receiver window size = amount of free space in receive buffer Sender will limit number of un. ACK’ed packets to receiver window ¡ Invariant: every packet that arrives at receiver can be buffered

Flow Control Sender Receiver recv window = 5 recv window = 0

Flow Control, Cont’d Sender Receiver recv wind = 2

Flow Control Justification n TCP flow control is conservative ¡ n Consider aggressive alternative ¡ ¡ n Only send data if receiver is sure to have space for it Send data optimistically, hoping receiver has space for it If receiver can’t buffer packet, simply discard Which is more efficient?

Efficiency Metrics n Transmission speed ¡ n Network utilization ¡ ¡ n Get as many bytes from sender to receiver as quickly as possible Maximize “goodput” Fraction of bytes spent on delivering new, useful data E. g. delayed ack hurts transmission speed, but improves network utilization

Congestion n What is congestion? ¡ n What are effects of congestion? ¡ ¡ n Higher rate of inputs to a router than outputs Delays Loss What layer does congestion occur at? ¡ ¡ Network layer So why are we talking about it now?

Congestion, simple case n Assume: ¡ ¡ ¡ Sender transmits at full line rate (i. e. receiver window infinite) Instant, free, precise loss notification No other traffic on network Sender 10 Mbps Router 5 Mbps Receiver

Congestion, two senders n Assume: ¡ Each sender transmits at 1/2 line rate Sender 1 Sender 2 20 Mbps 5 Mbps Receiver 1 20 Mbps Receiver 2 Router

Congestion and Delays n n During congestion, delay is much greater than ordinary delay Since loss notification is imperfect, may retransmit packets still in the queue! queue Router Sender retransmission original

Congestion Problems n n Excessive queueing delays Wasted network capacity on retransmissions ¡ ¡ n n Could have been used by other flows Situation gets worse with multi-hop paths Wasteful retransmit of prematurely timed out packets How bad does it get? ¡ 1000 -fold reduction in bandwidth!

Congestion Control n Congestion control involves two tasks: ¡ ¡ n Detect congestion Limit sending rate Today we look at TCP approach to this

TCP Congestion Control n Idea ¡ Assumes best-effort network n ¡ ¡ ¡ n FIFO or FQ Each source determines network capacity for itself Implicit feedback ACKs pace transmission (self-clocking) Challenge ¡ ¡ Determining initial available capacity Adjusting to changes in capacity in a timely manner

TCP Congestion Control n Basic idea Add notion of congestion window ¡ Effective window is smaller of ¡ n Advertised window (flow control) n Congestion window (congestion control) ¡ Changes in congestion window size n Slow increases to absorb new bandwidth n Quick decreases to eliminate congestion

TCP Congestion Control n Specific strategy ¡ Self-clocking n n ¡ Send data only when outstanding data ACK’d Equivalent to send window limitation mentioned Growth n n Add one maximum segment size (MSS) per congestion window of data ACK’d It’s really done this way, at least in Linux: ¡ ¡ n see tcp_cong_avoid in tcp_input. c. Actually, every ack for new data is treated as an MSS ACK’d Known as additive increase

TCP Congestion Control n Specific strategy (continued) ¡ Decrease n n n ¡ Cut window in half when timeout occurs In practice, set window = window /2 Known as multiplicative decrease Additive increase, multiplicative decrease (AIMD)

Additive Increase/ Multiplicative Decrease n Objective ¡ n Tools ¡ ¡ n Adjust to changes in available capacity React to observance of congestion Probe channel to detect more resources Observation ¡ On notice of congestion n ¡ Decreasing too slowly will not be reactive enough On probe of network n Increasing too quickly will overshoot limits

Additive Increase/ Multiplicative Decrease n New TCP state variable ¡ Congestion. Window n ¡ Limits how much data source can have in transit n n Similar to Advertised. Window for flow control Max. Win = MIN(Congestion. Window, Advertised. Window) Eff. Win = Max. Win - (Last. Byte. Sent Last. Byte. Acked) TCP can send no faster then the slowest component, network or destination Idea ¡ ¡ Increase Congestion. Window when congestion goes down Decrease Congestion. Window when congestion goes up

Additive Increase/ Multiplicative Decrease n Question ¡ n How does the source determine whether or not the network is congested? Answer ¡ ¡ ¡ Timeout signals packet loss Packet loss is rarely due to transmission error (on wired lines) Lost packet implies congestion!

Additive Increase/ Multiplicative Decrease Algorithm ¡ Increment Congestion. Window by one packet per RTT n ¡ Source Destination Linear increase Divide Congestion. Window by two whenever a timeout occurs n Multiplicative decrease … n

Additive Increase/ Multiplicative Decrease KB n Sawtooth trace 70 60 50 40 30 20 10 1. 0 2. 0 3. 0 4. 0 5. 0 Time (seconds) 6. 0 7. 0 8. 0 9. 0 10. 0

TCP Start Up Behavior n How should TCP start sending data? ¡ ¡ ¡ AIMD is good for channels operating at capacity AIMD can take a long time to ramp up to full capacity from scratch Use Slow Start to increase window rapidly from a cold start

TCP Start Up Behavior n Initialization of the congestion window ¡ ¡ Congestion window should start small Avoid congestion due to new connections Start at 1 MSS, reset to 1 MSS with each timeout (note that timeouts are coarsegrained, ~1/2 sec) Known as slow start

Slow Start Objective ¡ n Determine initial available capacity ¡ Begin with Congestion. Window = 1 packet Double Congestion. Window each RTT n ¡ Increment by 1 packet for each ACK Continue increasing until loss Result ¡ ¡ n Destination Idea ¡ n Source Exponential growth Slower than all at once Used ¡ ¡ When first starting connection When connection times out … n

TCP Congestion Control n n n To make up for slow start, ramp up congestion window quickly Maintain threshold window size Use multiplicative increase ¡ ¡ n Threshold value ¡ ¡ n When congestion window smaller than threshold Double window for each window ACK’d Initially set to maximum window size Set to 1/2 of current window on timeout In practice, increase congestion window by one MSS for each ACK of new data (or N bytes for N bytes)

Slow Start n How long should the exponential increase from slow start continue? ¡ New variable: target window size Congestion. Threshold ¡ Estimate network capacity When Congestion. Window reaches Congestion. Threshold switch to additive increase ¡ n Initial values ¡ ¡ n Congestion. Threshold = 8 Congestion. Window = 1 Loss after transmission 7 ¡ ¡ ¡ Congestion. Window currently 12 Set Congestionthreshold = Congestion. Window/2 Set Congestion. Window = 1

Slow Start Example trace of Congestion. Window KB n 70 60 50 40 30 20 10 CW flattens out due to loss Linear increase Slow start until CW = CT 1. 0 2. 0 3. 0 4. 0 5. 0 6. 0 7. 0 8. 0 9. 0 Timeout: CT = CT/2 = 11 CW = 1 n Problem n Have to wait for timeout n Can lose half Congestion. Window of data

Fast Retransmit and Fast Recovery n Problem ¡ n Coarse-grain TCP timeouts lead to idle periods Solution ¡ Fast retransmit: use duplicate ACKs to trigger retransmission Sender Receiver Packet 1 Packet 2 Packet 3 Packet 4 ACK 1 Packet 5 ACK 2 Packet 6 ACK 2 Retransmit packet 3 ACK 6

Fast Retransmit and Fast Recovery n n Send ACK for each segment received When duplicate ACK’s received ¡ ¡ ¡ n Resend lost segment immediately Do not wait for timeout In practice, retransmit on 3 rd duplicate Fast recovery ¡ ¡ ¡ When fast retransmission occurs, skip slow start Congestion window becomes 1/2 previous Start additive increase immediately

Fast Retransmit and Fast Recovery KB n Results 70 60 50 40 30 20 10 1. 0 n 2. 0 3. 0 4. 0 5. 0 6. 0 Fast Recovery n Bypass slow start phase n Increase immediately to one half last successful Congestion. Window (ssthresh) 7. 0

TCP Congestion Window Trace