EE 122 TCP Congestion Control Ion Stoica TAs

EE 122: TCP Congestion Control Ion Stoica TAs: Junda Liu, DK Moon, David Zats http: //inst. eecs. berkeley. edu/~ee 122/ (Materials with thanks to Vern Paxson, Jennifer Rexford, and colleagues at UC Berkeley) 1

Goals of Today’s Lecture l Principles of congestion control l Learning that congestion is occurring Adapting to alleviate the congestion TCP congestion control l l Additive-increase, multiplicative-decrease (AIMD) How to begin transmitting: Slow Start 2

What We Know We know: l How to process packets in a switch l How to route packets in the network l How to send packets reliably We don’t know: l How fast to send 3

It’s Not Just The Sender & Receiver l l l Flow control keeps one fast sender from overwhelming a slow receiver Congestion control keeps a set of senders from overloading the network Three congestion control problems: l Adjusting to bottleneck bandwidth l l Without any a priori knowledge Could be a Gbps link; could be a modem Adjusting to variations in bandwidth Sharing bandwidth between flows 4

Congestion is Unavoidable l Two packets arrive at the same time l l l The node can only transmit one … and either buffers or drops the other If many packets arrive in a short period of time l l The node cannot keep up with the arriving traffic … and the buffer may eventually overflow 5

Congestion Collapse l l l Definition: Increase in network load results in a decrease of useful work done Due to: l Undelivered packets l Packets consume resources and are dropped later in network l Spurious retransmissions of packets still in flight l Unnecessary retransmissions lead to more load! l Pouring gasoline on a fire Mid-1980 s: Internet grinds to a halt l Until Jacobson/Karels (Berkeley!) devise TCP congestion control 6

Knee – point after which l l l Throughput increases very slowly Delay increases quickly Cliff – point after which l l Throughput starts to decrease very fast to zero (congestion collapse) Delay approaches infinity Delay l Throughput View from a Single Flow knee packet loss cliff congestion collapse Load 7

General Approaches l Send without care l Many packet drops (1) Reservations l l l Pre-arrange bandwidth allocations Requires negotiation before sending packets Low utilization (2) Pricing l l Don’t drop packets for the high-bidders Requires payment model 8

General Approaches (cont’d) (3) Dynamic Adjustment l l l Probe network to test level of congestion Speed up when no congestion Slow down when congestion Suboptimal, messy dynamics, simple to implement All three techniques have their place l l But for generic Internet usage, dynamic adjustment is the most appropriate Due to pricing structure, traffic characteristics, and good citizenship 9

TCP Congestion Control l TCP connection has window l Controls number of unacknowledged packets l Sending rate: ~Window/RTT l Vary window size to control sending rate 10

Sizing the Windows l cwnd (Congestion Windows) l l l How many bytes can be sent without overflowing routers Computed by congestion control algorithm Advertised. Window l l How many bytes can be sent without overflowing the sender Determined by the receiver 11

Effective. Window l l l Limits how much data can be in transit Implemented as # of bytes Described as # packets (segments) in this lecture Max. Window = min(cwnd, Advertised. Window) Effective. Window = Max. Window – (Last. Byte. Sent – Last. Byte. Acked) Max. Window Last. Byte. Acked Last. Byte. Sent Effective. Window sequence number increases 12

Two Basic Components l Detecting congestion l Rate adjustment algorithm l l Depends on congestion or not Three subproblems within adjustment problem l l l Finding fixed bandwidth Adjusting to bandwidth variations Sharing bandwidth 13

Detecting Congestion l Packet dropping is best sign of congestion l l Delay-based methods are hard and risky How do you detect packet drops? ACKs l l TCP uses ACKs to signal receipt of data ACK denotes last contiguous byte received l l Actually, ACKs indicate next segment expected Two signs of packet drops l l No ACK after certain time interval: time-out Several duplicate ACKs (ignore for now) 14

Rate Adjustment l Basic structure: l l l Upon receipt of ACK (of new data): increase rate Upon detection of loss: decrease rate But what increase/decrease functions should we use? l Depends on what problem we are solving 15

Problem #1: Single Flow, Fixed BW l Want to get a first-order estimate of the available bandwidth l l Assume bandwidth is fixed Ignore presence of other flows l Want to start slow, but rapidly increase rate until packet drop occurs (“slow-start”) l Adjustment: l l cwnd initially set to 1 cwnd++ upon receipt of ACK 16

Slow-Start l cwnd increases exponentially: cwnd doubles every time a full cwnd of packets has been sent l Each ACK releases two packets l Slow-start is called “slow” because of starting point cwnd = 1 segment 1 cwnd = 2 segment 3 cwnd = 4 segment 5 segment 6 segment 7 cwnd = 8 17

5 Minute Break Questions Before We Proceed? 18

Problems with Slow-Start l Slow-start can result in many losses l l Example: l l Roughly the size of cwnd ~ BW*RTT 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 19

Problem #2: Single Flow, Varying BW l Want to be able to track available bandwidth, oscillating around its current value l Possible variations: (in terms of RTTs) l l l Multiplicative increase or decrease: cwnd a*cwnd Additive increase or decrease: cwnd + b Four alternatives: l l AIAD: gentle increase, gentle decrease AIMD: gentle increase, drastic decrease MIAD: drastic increase, gentle decrease (too many losses) MIMD: drastic increase and decrease 20

Problem #3: Multiple Flows l Want steady state to be “fair” l Many notions of fairness, but here all we require is that two identical flows end up with the same bandwidth l This eliminates MIMD and AIAD l AIMD is the only remaining solution! 21

Buffer and Window Dynamics A l l x B C = 50 pkts/RTT No congestion x increases by one packet/RTT every RTT Congestion decrease x by factor 2 22

AIMD Sharing Dynamics A D l l x 1 x 2 B E No congestion rate increases by one packet/RTT every RTT Congestion decrease rate by factor 2 Rates equalize fair share 23

AIAD Sharing Dynamics A D l l x 1 x 2 B E No congestion x increases by one packet/RTT every RTT Congestion decrease x by 1 24

Efficient Allocation: Challenges of Congestion Control Too slow l l Too fast l l Overshoot knee overload, high delay, loss Everyone’s doing it l 2 user example Fail to take advantage of available bandwidth underload May all under/over shoot large oscillations Optimal: l xi=Xgoal Efficiency = 1 - distance from efficiency line User 2: x 2 l overload underload Efficiency line User 1: x 1 25

Example 1 Efficient: x 1+x 2=1 Fair Total bandwidth 1 Congested: x 1+x 2=1. 2 User 2: x 2 l fairness line (0. 2, 0. 5) (0. 5, 0. 5) Inefficient: x 1+x 2=0. 7 (0. 7, 0. 5) (0. 7, 0. 3) Efficient: x 1+x 2=1 Not fair User 1: x 1 efficiency line 1 26

MIAD l l l Increase: x*b. I Decrease: x - a. D Does not converge to fairness Does not converges to efficiency (b. I(x 1 h-a. D), b. I(x 2 h-a. D)) (x 1 h, x 2 h) User 2: x 2 l fairness line (x 1 h-a. D, x 2 h-a. D) efficiency line User 1: x 1 27

AIAD l l l Increase: x + a. I Decrease: x - a. D Does not converge to fairness Does not converge to efficiency fairness line (x 1 h, x 2 h) User 2: x 2 l (x 1 h-a. D+a. I), x 2 h-a. D+a. I)) (x 1 h-a. D, x 2 h-a. D) efficiency line User 1: x 1 28

MIMD l l l Increase: x*b. I Decrease: x*b. D Does not converge to fairness Converges to efficiency iff (x 1 h, x 2 h) (b. Ib. Dx 1 h, b. Ib. Dx 2 h) User 2: x 2 l fairness line (bdx 1 h, bdx 2 h) efficiency line User 1: x 1 29

AIMD l l Increase: x+a. D Decrease: x*b. D Converges to fairness Converges to efficiency Increments smaller as fairness increases User 2: x 2 l fairness line (x 1 h, x 2 h) (b. Dx 1 h+a. I, b. Dx 2 h+a. I) (b. Dx 1 h, b. Dx 2 h) efficiency line User 1: x 1 30

Implementing AIMD l After each ACK l l l Increment cwnd by 1/cwnd (cwnd += 1/cwnd) As a result, cwnd is increased by one only if all segments in a cwnd have been acknowledged But need to decide when to leave slow-start and enter AIMD § Use ssthresh variable 31

Slow Start/AIMD Pseudocode Initially: cwnd = 1; ssthresh = infinite; New ack received: if (cwnd < ssthresh) /* Slow Start*/ cwnd = cwnd + 1; else /* Congestion Avoidance */ cwnd = cwnd + 1/cwnd; Timeout: /* Multiplicative decrease */ ssthresh = cwnd/2; cwnd = 1; 32

The big picture (with timeouts) cwnd Timeout AIMD ssthresh Slow Start Time 33

Summary l Congestion is inevitable l l l Congestion control critical for avoiding collapse l l Internet does not reserve resources in advance TCP actively tries to grab capacity 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 l Advanced congestion control 34