Computer Networks Lecture 17 Congestion Control AIMD TCP

Computer Networks Lecture 17 Congestion Control; AIMD; TCP Reno 10/31/2013 1

Admin. : Assignment 4 Part 1: Design discussion with instructor or a TF: Nov. 11; Code check point: 11: 55 pm, Nov. 15 Part 2: Design discussion with instructor or a TF: Nov. 14; Code and report: 11: 55 pm, Nov. 19. proj-sol (part 1): proj: 129 400 3045 Fish. Thread. java 129 388 1457 12873 Node. java 341 51 167 1145 Ping. Request. java 51 83 250 2106 Simple. TCPSock. Space. java 181 605 5248 TCPManager. java 50 889 3088 26381 TCPSock. java 132 60 149 1316 TCPSock. ID. java 123 382 3866 Transfer. Client. java 147 500 5059 Transfer. Server. java 973 2051 6998 61039 total 400 3045 Fish. Thread. java 1301 11313 Node. java 167 1145 Ping. Request. java 128 909 TCPManager. java 460 3146 TCPSock. java 382 3866 Transfer. Client. java 500 5059 Transfer. Server. java 3338 28483 total 2

Recap: Connection Management r Connection setup: m agree on initial sequence numbers to avoid accepting duplicate/out of order packets m Internet solution: Three-Way-Handshake (TWH) r Connection close m both sides can release allocated resources m Internet solution: time wait 3

%netstat -t -a CLOSED SYN SENT CLOSED LISTEN SYN RCVD K /AC SYN ESTABLSIHED ACK ESTABLSIHED FIN WAIT 1 FIN ACK FIN WAIT 2 TIME WAIT FIN CLOSE WAIT LAST ACK 4

A Summary of Questions q How to improve the performance of rdt 3. 0? ü sliding window protocols r What if there are duplication and reordering? ü ü ü network guarantee: max packet life time transport guarantee: sender not reuses a seq# before life time seq# management and connection management r How to determine the “right” parameters? 5

History r Key parameters for TCP in mid-1980 s m fixed window size W m timeout value = 2 RTT r Network collapse in the mid-1980 s m UCB LBL throughput dropped by 1000 X ! m Blamed timeout and fixed window size 6

Timeout r Ideal timeout = RTT m too short: premature timeout • unnecessary retransmissions/duplicates m too long: slow reaction to segment loss r Measure RTT: measure time from segment transmission until ACK receipt 7

From Ideal to Implementation r Problem: Sample. RTT vary, want a “smoother” estimated RTT o use several recent measurements, not just current Sample. RTT Estimated. RTT = (1 - )*Estimated. RTT + *Sample. RTT r Exponential weighted moving average r influence of past sample decreases exponentially fast r typical value: = 0. 125 8

Setting Timeout Problem: r using the average of Sample. RTT will generate many timeouts due to network variations RTT Solution: r Estimted. RTT plus “safety margin” m Q: what is margin in original TCP m Margin should depend on variation: large variation in Estimated. RTT -> larger safety margin 9

TCP Timeout freq. RTT Dev. RTT = (1 - )*Dev. RTT + *|Sample. RTT-Estimated. RTT| (typically, = 0. 25) Then set timeout interval: Timeout. Interval = Estimated. RTT + 4*Dev. RTT 10

An Example TCP Session 11

A Summary of Questions q How to improve the performance of rdt 3. 0? ü sliding window protocols r What if there are duplication and reordering? ü ü ü network guarantee: max packet life time transport guarantee: sender not reuses a seq# before life time seq# management and connection management r How to determine the “right” parameters? ü timeout: mean + variation o sliding window size 12

Principles of Congestion Control Big picture: r How to determine a flow’s sending rate? r a top-10 problem ! Congestion: r informally: “too many sources sending too much data too fast for the network to handle” r different from flow control ! r manifestations: m lost packets (buffer overflow at routers) m long delays (queueing in router buffers) m wasted bandwidth 13

Some General Questions r How can congestion happen? r What is congestion control? r Why is congestion control difficult? 14

Cause/Cost of Congestion: Single Bottleneck flow 1 20 M bps flow 2 (5 Mbps) 10 Mbps 5 M 20 bps 20 M router 1 bps Mb ps router 2 - Flow 2 has a fixed sending rate of 5 Mbps - We vary the sending rate of flow 1 from 0 to 20 Mbps - Assume m no retransmission; link from router 1 to router 2 has infinite buffer throughput: e 2 e packets delivered in unit time Delay? delay at central link throughput of flow 1 & 2 (Mbps) 10 5 sending rate by flow 1 (Mbps) 0 5 15

Cause/Cost of Congestion: Single Bottleneck router 5 router 3 flow 1 20 M bps 5 M 10 Mbps 20 flow 2 (5 Mbps) bps router 1 20 M router 4 router 2 bps Mb ps router 6 q. Assume m no retransmission m the link from router 1 to router 2 has finite buffer m throughput: e 2 e packets delivered in unit time r Zombie packet: a packet throughput of flow 1 & 2 (Mbps) 10 5 sending rate by flow 1 (Mbps) 0 5 x dropped at the link from router 2 to router 5; the upstream transmission from router 1 to router 2 used for that packet wasted! 16

m m wasted upstream bandwidth when a pkt is discarded at downstream wasted bandwidth due to retransmission (a pkt goes through a link multiple times) Delay Cost r Packet loss Throughput Summary: The Cost of Congestion knee packet loss cliff congestion collapse Load r High delay Load 17

Outline r Admin and recap Ø Transport congestion control ¦ what is congestion Ø congestion control 18

Rate-based vs. Window-based Rate-based: r Congestion control by explicitly controlling the sending rate of a flow, e. g. , set sending rate to 128 Kbps r Example: ATM Window-based: r Congestion control by controlling the window size of a transport scheme, e. g. , set window size to 64 KBytes r Example: TCP Discussion: rate-based vs. window-based 19

Window-based Congestion Control r A main advantage of window-based congestion control is self-clocking: considers flow conservation, and adjusts to RTT variation automatically 20

Sliding Window Congestion Control r Transmission rate limited by congestion window size, cwnd, over segments: cwnd r Assume cwnd segments, each with MSS bytes sent in one RTT: throughput MSS: Minimum Segment Size cwnd * MSS Bytes/sec RTT 21

The Desired Properties of a Congestion Control Scheme r Efficiency: close to full utilization but low delay - fast convergence after disturbance r Fairness (resource sharing) r Distributedness (no central knowledge for scalability) 22

A Simple Model User 1 x 1 User 2 x 2 User n d= xi > Xgoal? xn Flows observe congestion signal d, and locally take actions to adjust rates. 23

Linear Control r Proposed by Chiu and Jain (1988) r The simplest control strategy Discussion: values of the parameters? 24

State Space of Two Flows fairness line: x 1=x 2 x(0) overload efficiency line: x 1+x 2=C underload x 1 25

congestion x 0 efficiency: distributed linear rule x 0 fairness intersection 26

Implication: Congestion (overload) Case r In order to get closer to efficiency and fairness after each update, decreasing of rate must be multiplicative decrease (MD) a. D = 0 m b. D < 1 m 27

no-congestion x 0 efficiency x 0 fairness efficiency: distributed linear rule x 0 convergence 28

Implication: No Congestion Case r In order to get closer to efficiency and fairness after each update, additive and multiplicative increasing (AMI), i. e. , m a. I > 0, b. I > 1 r Simply additive increase gives better improvement in fairness (i. e. , getting closer to the fairness line) r Multiplicative increase is faster 29

Four Special Cases Additive Increase Multiplicative Increase Additive Decrease Multiplicative Decrease AIAD (b. I=b. D=1) AIMD (b. I=1, a. D=0) MIAD (a. I=0, b. I>1, b. D=1) MIMD (a. I=a. D=0) Discussion: state transition trace. 30

AIMD: State Transition Trace x 2 fairness line: x 1=x 2 overload x 0 underload efficiency line: x 1+x 2=C x 1 31

Another Look r Consider the difference or ratio of the rates of two flows m AIAD m MIMD m MIAD m AIMD 32

Mapping A(M)I-MD to Protocol r What do we need to apply the A(M)I-MD algorithm to a sliding window protocol? 33

Mapping A(M)I-MD to Protocol r What do we need to apply the A(M)I-MD algorithm to a sliding window protocol? 34

Implicit vs. Explicit: r routers provide feedback to end systems m explicit rate sender should send at m single bit indicating congestion (SNA, DECbit, TCP ECN, ATM) Implicit: r congestion inferred by end systems through observed loss, delay 35

Outline r Admin and recap Ø Transport congestion control ¦ what is congestion ¦ congestion control principle Ø TCP congestion control: Reno 36

TCP Congestion Control r Closed-loop, end-to-end, window-based congestion control r Designed by Van Jacobson in late 1980 s, based on the AIMD alg. of Dah-Ming Chu and Raj Jain r Works well when the bandwidth of the Internet has increased by more than 200, 000 times r Many versions m TCP/Tahoe: this is a less optimized version m TCP/Reno: many OSs today implement Reno type congestion control m TCP/Vegas: not currently used m TCP CUBIC For more details: see TCP/IP illustrated; or read http: //lxr. linux. no/source/net/ipv 4/tcp_input. c for linux implementation 37

TCP/Reno Congestion Detection r Detect congestion (d) in two cases and react differently: m 3 dup ACKs m timeout event Philosophy: • 3 dup ACKs indicates network capable of delivering some segments • timeout is “more alarming” 38

Basic Structure r Two “phases” m slow-start: MI m congestion avoidance: AIMD r Important variables: m cwnd: congestion window size m ssthresh: threshold between the slowstart phase and the congestion avoidance phase 39

Visualization of the Two Phases 40

Slow Start: MI r What is the goal? m getting to equilibrium gradually but quickly r Implements the MI algorithm m double cwnd every RTT until network congested get a rough estimate of the optimal of cwnd 41

Slow-start Initially: cwnd = 1; ssthresh = infinite (e. g. , 64 K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; cwnd = 1 segment 1 ACK for segm cwnd = 2 ent 1 segment 2 segment 3 ents 2 + 3 ACK for segm cwnd = 4 segment 5 segment 6 segment 7 cwnd = 6 cwnd = 8 42

Startup Behavior with Slow-start See [Jac 89] 43

TCP/Reno Congestion Avoidance r Maintains equilibrium and reacts around equilibrium r Implements the AIMD algorithm m increases window by 1 per round-trip time (how? ) m cuts window size • to half when detecting congestion by 3 DUP • to 1 if timeout • if already timeout, doubles timeout 44

TCP/Reno Congestion Avoidance Initially: cwnd = 1; ssthresh = infinite (e. g. , 64 K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; else /* congestion avoidance; cwnd increases (approx. ) by 1 per RTT */ cwnd += 1/cwnd; Triple-duplicate ACKs: /* multiplicative decrease */ cwnd = ssthresh = cwnd/2; Timeout: ssthresh = cwnd/2; cwnd = 1; (if already timed out, double timeout value; this is called exponential backoff) 45

TCP/Reno: Big Picture cwnd TD TD TD TO ssthresh Time slow start congestion avoidance TD: Triple duplicate acknowledgements TO: Timeout congestion avoidance slow congestion start avoidance 46

A Session Question: when cwnd is cut to half, why sending rate is not? 47

Backup Slides 48

High-level Ideally, we set timeout = RTT, but RTT is not a fixed value (why? ) Set timeout = average + safe margin 49

High-level Ideally, we set timeout = RTT, but RTT is not a fixed value (why? ) Set timeout = average + safe margin 50