Lecture 8 Congestion Control EECS 122 University of California - PowerPoint PPT Presentation

Lecture 8 Congestion Control EECS 122 University of California Berkeley

TOC: Congestion Control The Problem Questions Approaches TCP: Algorithm TCP Refinements Summary EECS 122 Walrand 2

Congestion Control: The Problem Flows share links: How to share the links bandwidth? EECS 122 Walrand 3

Congestion Control: Questions What should be the ideal sharing? � Does it matter? � Discovering available bandwidth � What is fair? EECS 122 Walrand 4

Questions: Does it matter? Congestion occurs � Access link � Slow link (56k, DSL, T1, wireless, …) � Access network � E.g., behind the DSLAM Can improve treatment of flows � E.g., one flow should not get a much smaller fraction of bandwidth � Some flows might need some guaranteed bandwidth EECS 122 Walrand 5

Questions: Available bandwidth? Example: x A B 10 10 3 6 3 10 10 10 10 z C y E D F = router = host = link with bandwidth of 3Mbps 3 (same for 6 and 10) x, y, z = throughput of flows EECS 122 Walrand 6

Questions: Available bandwidth? Example: x A B 10 10 3 6 3 10 10 10 10 z C y E D F • Assume C � D with rate y and E � F with rate z • How does A “discover” the available bandwidth to B? • Some approaches: 1. Reservation 2. Adapt to congestion 3. Test for sufficient bandwidth 4. Pricing congestion EECS 122 Walrand 7

Questions: Available bandwidth? Example: x A B 10 10 3 6 3 10 10 10 10 z C y E D F • Assume C � D with rate y and E � F with rate z • How does A “discover” the available bandwidth to B? • Some approaches: 1. Reservation 2. Adapt to congestion 3. Test for sufficient bandwidth 4. Pricing congestion EECS 122 Walrand 8

Available bandwidth: Reservation x A B 10 10 3 6 3 10 10 10 10 z C y E D F 1. Routers (or manager) keep track of reserved rates 2. A requests a rate R to B from the network 3. The network figures out if R is available 4. If R is available, routers (or manager) update reservations and confirm to A 5. Note: Complex, Slow, Requires enforcement, Renegotiations, Pricing EECS 122 Walrand 9

Available bandwidth: Adapt x A B 10 10 3 6 3 10 10 10 10 z C y E D F 1. Transmit and slow down if congestion occur 2. Example: • Initially: x= 0, y = 3, z = 3 • Then A increases its rate; C and E notice congestion and slow down • Later, C stops: A and E increase rates 3. Notes: • No guarantees: throughput may drop • Key question: how to adapt rates EECS 122 Walrand 10

Available bandwidth: Test x A B 10 10 3 6 3 10 10 10 10 z C y E D F 1. Assume flows require at most 1Mbps (e.g., video) 2. Routers monitor their rates to see if they have at least 1 Mbps of available bandwidth; they mark packets otherwise 3. If A wants a new flow to B, it sends test packets to B 4. If routers do not mark test packets, then A can start its new flow; otherwise, A does not start it 5. Advantages: 1. relatively simple 2. guarantee EECS 122 Walrand 11

Available bandwidth: Pricing Example: x A B 10 10 3 6 3 10 10 10 10 z C y E D F • When they get saturated, routers mark packets • If a flow with rate R uses saturated links, it gets marks with rate R • Each mark costs one unit • Source slows down if price becomes excessive • x= 1+, y = 2+, z = 2+ � pA = 1 + 1; pC = pE = 2 • x = 2+, y = 1+, z = 1+ � pA = 2 + 2; pC = pE = 1 EECS 122 Walrand 12

Questions: What is Fair? Example: x A B 10 10 3 6 3 10 10 10 10 z C y E D F • x = y = z = 1.5: fair in max-min sense • x = 0, y = z = 3: maximizes x + y + z • 5x = 4y = 4z: equalizes resources flows use with x = 1.33, y = z = 1.67 • What if A � B needs 2Mbps? (and is willing to pay for it) EECS 122 Walrand 13

Congestion Control: Approaches Telephone Network: Reservation Transmission Control Protocol (TCP) � Adapt rate to congestion � Algorithm for adaptation attempts to be fair … User Datagram Protocol (UDP) � Transmit and hope for the best Various proposals for Internet: � Reservation � Pricing � Test � Note: Either by hosts or between domains EECS 122 Walrand 14

Congestion Control: TCP Algorithm Principles Example Multiple Sources A Bad Algorithm: AIAD AIMD: Additive Increase – Multiplicative Decrease Why AIAD Fails EECS 122 Walrand 15

TCP Algorithm: Principles We focus on the “standard” TCP (reno) Idea: � Not congested => increase rate � Congested => slow down Questions: � How to detect congestion? Missing ACKs � � How to increase/slow down? AIMD � EECS 122 Walrand 16

TCP Algorithm: Example C = 50 pkts/RTT x A B No congestion � x increases by one packet/RTT every RTT Congestion � decrease x by factor 2 Rate (pkts/RTT) 60 50 40 30 Backlog in router (pkts) 20 Congested if > 20 10 0 1 28 55 82 109 136 163 190 217 244 271 298 325 352 379 406 433 460 487 EECS 122 Walrand 17

TCP Algorithm: Multiple Sources C = 50 pkts/RTT x A B y D E No congestion � rate increases by one packet/RTT every RTT Congestion � decrease rate by factor 2 60 Rates equalize � fair share 50 40 30 20 10 0 1 28 55 82 109 136 163 190 217 244 271 298 325 352 379 406 433 460 487 EECS 122 Walrand 18

TCP Algorithm: Bad Algorithm C = 50 pkts/RTT x A B y D E No congestion � x increases by one packet/RTT every RTT Congestion � decrease x by 1 60 50 40 30 20 10 0 1 28 55 82 109 136 163 190 217 244 271 298 325 352 379 406 433 460 487 EECS 122 Walrand 19

TCP Algorithm: AIMD C x A B y D E y C Limit rates: x = y x EECS 122 Walrand 20

TCP Algorithm: Why AIAD Fails C x A B y D E y C Limit rates: x and y depend on initial values x EECS 122 Walrand 21

Congestion Control: TCP Refinements Fast Retransmit Fast Recovery: 1 st Look Fast Recovery: 2 nd Look Slow Start Window Updates Flow Control Summary EECS 122 Walrand 22

Refinements: Fast Retransmit Cumulative ACKs: n ACK # = next expected # n+1 n+2 n+3 n+1 timeout 3 rd duplicated ACK: n+1 n+1 � likely packet loss n+1 � retransmit EECS 122 Walrand 23

Refinements : Fast Recovery (1) Timeout � Reset Window = 1 unit (MSS) 3 rd Dup ACK � Window/2 3 rd Dup ACK Window Timeout Slope = n 1 MSS/RTT n/2 1 Moderate congestion Severe congestion (subsequent pkts arrived) EECS 122 Walrand 24

Refinements : Fast Recovery (2) Window adjustment is tricky: Want W � W/2 W/2 outstanding W/2 outstanding ssthresh = W/2 packets: packets: W = ssthresh + 3 n+1, …, n+W/2 n+1, …, n+W/2 W = W + 1 at each Dup Ack W = n + W/2 W = ssthresh n - 3 W n 1 EECS 122 Walrand 25

Refinements : Slow Start Objective: Discover available bdw fast Solution: Exponential increase of window 65KB Threshold W Additive n Slope = 1/RTT n/2 exp exp 1 Timeout EECS 122 Walrand 26

Refinements : Window Updates Exponential: W = W + 1 at each ACK: W = 1 W = 2 W = 4 W = 8 Additive: W = W + 1/W at each ACK: W = 8.125 + 1/8.125 ? 8 + 2/8 W = 8 + 1/8 W ? 8 + 8/8 = 9 W = 8 W ? 9 + 9/9 = 10 EECS 122 Walrand 27

Refinements : Flow Control Objective: Avoid saturating destination Algorithm: Receiver avertizes window RAW window = min{RAW – OUT, W} where OUT = Oustanding = Last sent – last ACKed W = Cong. Window from AIMD + refinements RAW [ACK | RAW | …] EECS 122 Walrand 28

Refinements : Summary Actual window = min{RAW - OUT, W} 65KB W 3DA 3DA TO X 0.5 X 0.5 X 0.5 X 0.5 3 3 TO 1 CA SS SS CA EECS 122 Walrand 29

Congestion Control: Summary Slow Start: Discover available bandwidth Congestion Avoidance: AIMD � Tries to be fair Refinements: � Fast Retransmit: 3DA � Fast Recovery: Reset W to W/2 (instead of W = 1) [More precisely: ssthresh = W/2, W = W + 1 per DA, W = ssthresh when get new ACK.] � TO: set ssthresh = W/2, W = 1, SS until W = ssthresh, then CA Timers: � Timeout = Average + 4 Deviations � If time out � Timeout x 2 Reset after new packet or new ACK Flow Control: � Window = min{RAW – OUT, W} EECS 122 Walrand 30