1

Computer Networks

Lecture 17

Congestion Control; AIMD; TCP Reno

10/31/2013

Admin.: Assignment 4

proj-sol (part 1): 129 400 3045 FishThread.java 388 1457 12873 Node.java 51 167 1145 PingRequest.java 83 250 2106

SimpleTCPSockSpace.java 181 605 5248 TCPManager.java 889 3088 26381 TCPSock.java 60 149 1316 TCPSockID.java 123 382 3866 TransferClient.java 147 500 5059 TransferServer.java 2051 6998 61039 total

2

proj: 129 400 3045 FishThread.java 341 1301 11313 Node.java 51 167 1145 PingRequest.java

50 128 909 TCPManager.java 132 460 3146 TCPSock.java

123 382 3866 TransferClient.java 147 500 5059 TransferServer.java 973 3338 28483 total

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.

3

Recap: Connection Management

Connection setup: agree on initial sequence numbers to avoid

accepting duplicate/out of order packets Internet solution: Three-Way-Handshake

(TWH)

Connection close both sides can release allocated resources Internet solution: time wait

4

%netstat -t -a CLOSED

LISTEN

SYN RCVD

SYN

SYN/ACK

ACK

CLOSED

SYN SENT

ESTABLSIHED

ESTABLSIHED

FIN

ACK

ACK

FINWAIT 1

ESTABLSIHED ESTABLSIHED

CLOSEWAIT

FINLASTACK

FINWAIT 2

TIMEWAIT

5

A Summary of Questions

How to improve the performance of rdt3.0? sliding window protocols

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 How to determine the “right” parameters?

6

History

Key parameters for TCP in mid-1980s fixed window size W timeout value = 2 RTT

Network collapse in the mid-1980s UCB LBL throughput dropped by 1000X ! Blamed timeout and fixed window size

7

Timeout Ideal timeout = RTT

too short: premature timeout• unnecessary retransmissions/duplicates

too long: slow reaction to segment loss

Measure RTT: measuretime from segment transmission until ACK receipt

8

From Ideal to Implementation

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

Exponential weighted moving average influence of past sample decreases exponentially

fast typical value: = 0.125

Problem: SampleRTT vary, want a “smoother” estimated RTT

o use several recent measurements, not just current SampleRTT

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

9

Setting TimeoutProblem: using the average of SampleRTT will generate many timeouts due to network variations

Solution: EstimtedRTT plus “safety

margin” Q: what is margin in original

TCP Margin should depend on

variation: large variation in EstimatedRTT -> larger safety margin

RTT

10

TCP Timeout

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|

(typically, = 0.25)

Then set timeout interval:

RTT

freq.

11

An Example TCP Session

12

A Summary of Questions

How to improve the performance of rdt3.0? sliding window protocols

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 How to determine the “right” parameters?

timeout: mean + variationo sliding window size

13

Principles of Congestion Control

Big picture: How to determine a flow’s sending rate? a top-10 problem !Congestion: informally: “too many sources sending too much

data too fast for the network to handle” different from flow control ! manifestations:

lost packets (buffer overflow at routers) long delays (queueing in router buffers) wasted bandwidth

14

Some General Questions

How can congestion happen?

What is congestion control?

Why is congestion control difficult?

15

flow 2 (5 Mbps)

flow 1

router 1 router 2

10 Mbps5 Mbps20 Mbps

Cause/Cost of Congestion: Single Bottleneck

- Flow 2 has a fixed sending rate of 5 Mbps- We vary the sending rate of flow 1 from 0 to 20 Mbps- Assume

no retransmission; link from router 1 to router 2 has infinite buffer

20 Mbps

20 Mbps

throughput: e2e packets delivered in

unit time

Delay?

sending rate by flow 1 (Mbps)

throughput of flow 1 & 2 (Mbps)

5

10

50

sending rate by flow 1 (Mbps)

delay at central link

50

16

flow 2 (5 Mbps)

flow 1

router 1

10 Mbps5 Mbps20 Mbps

Cause/Cost of Congestion: Single Bottleneck

Assume no retransmission the link from router 1 to router 2 has finite buffer throughput: e2e packets delivered in unit time

20 Mbps

20 Mbps

Zombie packet: a packet dropped at the link from router 2 to router 5; the upstream transmission from router 1 to router 2 used for that packet was wasted!

router 3

router 4

router 2

router 5

router 6

sending rate by flow 1 (Mbps)

throughput of flow 1 & 2 (Mbps)

5

10

50 x

10)5,10min( 55

5 xxx

17

Summary: The Cost of Congestion

Cost Packet loss

wasted upstream bandwidth when a pkt is discarded at downstream

wasted bandwidth due to retransmission (a pkt goes through a link multiple times)

High delayLoad

Load

De

lay

Th

rou

ghp

ut knee cliff

congestioncollapse

packetloss

18

Outline

Admin and recap Transport congestion control

what is congestion congestion control

19

Window-based: Congestion control by

controlling the window size of a transport scheme, e.g., set window size to 64KBytes

Example: TCP

Rate-based: Congestion control by

explicitly controlling the sending rate of a flow, e.g., set sending rate to 128Kbps

Example: ATM

Discussion: rate-based vs. window-based

Rate-based vs. Window-based

20

Window-based Congestion Control

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

21

Sliding Window Congestion Control

Transmission rate limited by congestion window size, cwnd, over segments:

Assume cwnd segments, each with MSS bytes sent in one RTT:

throughput cwnd * MSS

RTT Bytes/sec

cwnd

MSS: Minimum Segment Size

22

The Desired Properties of a Congestion Control Scheme

Efficiency: close to full utilization but low delay- fast convergence after disturbance

Fairness (resource sharing)

Distributedness (no central knowledge for scalability)

23

A Simple Model

User 1

User 2

User n

d =

xi > Xgoal?

x1

x2

xn

Flows observe congestion signal d, and locally take actions to adjust rates.

24

Linear Control

Proposed by Chiu and Jain (1988) The simplest control strategy

cong.d(t) if)(

cong. nod(t) if )()1(

txba

txbatx

iDD

iIIi

Discussion: values of the parameters?

25

State Space of Two Flows

x2

x1

overload

underload

efficiency line: x1+x2=C

fairness line: x1=x2

cong.d(t) if)(

cong. nod(t) if )()1(

txba

txbatx

iDD

iIIi

x(0)

26

x0

efficiency efficiency: distributed linear rule

x0

intersection

x0

congestion

fairness

x0

cong.d(t) if)(

cong. nod(t) if )()1(

txba

txbatx

iDD

iIIi

27

Implication: Congestion (overload) Case

In order to get closer to efficiency and fairness after each update, decreasing of rate must be multiplicative decrease (MD) aD = 0

bD < 1

cong.d(t) if)(

cong. nod(t) if )()1(

txb

txbatx

iD

iIIi

28

efficiency: distributed linear rule

x0

no-congestion

x0

efficiency

fairness

x0

convergencex0

cong.d(t) if)(

cong. nod(t) if )()1(

txba

txbatx

iDD

iIIi

29

Implication: No Congestion Case

In order to get closer to efficiency and fairness after each update, additive and multiplicative increasing (AMI), i.e., aI > 0, bI > 1

Simply additive increase gives better improvement in fairness (i.e., getting closer to the fairness line)

Multiplicative increase is faster

cong.d(t) if)(

cong. nod(t) if )()1(

txb

txbatx

iD

iIIi

30

Four Special Cases

Additive Decrease

Multiplicative Decrease

Additive Increase

AIAD(bI=bD=1)

AIMD(bI=1, aD=0)

Multiplicative Increase

MIAD(aI=0, bI>1,

bD=1)

MIMD(aI=aD=0)

cong.d(t) if)(

cong. nod(t) if )()1(

txba

txbatx

iDD

iIIi

Discussion: state transition trace.

31

AIMD: State Transition Trace

x1

x2

x0

fairness line:x1=x2

efficiency line: x1+x2=C

overload

underload

32

Another Look

Consider the difference or ratio of the rates of two flows AIAD

MIMD

MIAD

AIMD

33

Mapping A(M)I-MD to Protocol

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

cong.d(t) if)(

cong. nod(t) if )()1(

txb

txatx

iD

iIi

34

Mapping A(M)I-MD to Protocol

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

cong.d(t) if)(

cong. nod(t) if )()1(

txb

txatx

iD

iIi

35

Implicit vs. Explicit

Implicit: congestion inferred by

end systems through observed loss, delay

Explicit: routers provide feedback

to end systems explicit rate sender

should send at single bit indicating

congestion (SNA, DECbit, TCP ECN, ATM)

36

Outline

Admin and recap Transport congestion control

what is congestion congestion control principle TCP congestion control: Reno

37

TCP Congestion Control Closed-loop, end-to-end, window-based

congestion control Designed by Van Jacobson in late 1980s, based

on the AIMD alg. of Dah-Ming Chu and Raj Jain Works well when the bandwidth of the Internet

has increased by more than 200,000 times Many versions

TCP/Tahoe: this is a less optimized version TCP/Reno: many OSs today implement Reno

type congestion control TCP/Vegas: not currently used TCP CUBIC

For more details: see TCP/IP illustrated; or readhttp://lxr.linux.no/source/net/ipv4/tcp_input.c for linux implementation

38

TCP/Reno Congestion Detection

• 3 dup ACKs indicates network capable of delivering some segments

• timeout is “more alarming”

Philosophy:

Detect congestion (d) in two cases and react differently:

3 dup ACKs timeout event

39

Basic Structure

Two “phases”slow-start: MIcongestion avoidance: AIMD

Important variables:cwnd: congestion window sizessthresh: threshold between the slow-

start phase and the congestion avoidance phase

40

Visualization of the Two Phases

41

Slow Start: MI

What is the goal? getting to equilibrium gradually but quickly

Implements the MI algorithm double cwnd every RTT until network

congested get a rough estimate of the optimal of cwnd

42

Slow-start

ACK for segment 1

segment 1cwnd = 1

cwnd = 2 segment 2segment 3

ACK for segments 2 + 3

cwnd = 4 segment 4segment 5segment 6segment 7

cwnd = 6

Initially:cwnd = 1;ssthresh = infinite (e.g., 64K);

For each newly ACKed segment:if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1;

cwnd = 8

43

Startup Behavior with Slow-start

See [Jac89]

44

TCP/Reno Congestion Avoidance Maintains equilibrium and reacts around

equilibrium

Implements the AIMD algorithm increases window by 1 per round-trip time

(how?) cuts window size

• to half when detecting congestion by 3DUP• to 1 if timeout• if already timeout, doubles timeout

45

TCP/Reno Congestion AvoidanceInitially:

cwnd = 1;ssthresh = infinite (e.g., 64K);

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)

46

TCP/Reno: Big Picture

Time

cwnd

slowstart

congestionavoidance

TD

TD: Triple duplicate acknowledgementsTO: Timeout

TOssthresh

ssthresh ssthreshssthresh

congestionavoidance

TD

congestionavoidance

slow start

congestionavoidance

TD

47

A Session

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

48

Backup Slides

High-level Idea

Ideally, we set timeout = RTT, but RTT is not a fixed value (why?)

49

Set timeout = average + safe margin

High-level Idea

Ideally, we set timeout = RTT, but RTT is not a fixed value (why?)

50

Set timeout = average + safe margin