CONGESTION CONTROL (Control by TCP) in 97-2003 ms office compatible

8/7/2019 CONGESTION CONTROL (Control by TCP) in 97-2003 ms office compatible

1/33

CONGESTION CONTROLAn academic work in B.Tech 3rd year (6th sem.)

SUBMITTED BY SUBMITTED TO

Ankit Mathur Mr. Rohit Ranka (C.S.Dep't.)

1

AnAnkitMathurPre

sentation


2/33

CONGESTION CONTROL

What is congestion?

Methods for dealing with congestion

TCP congestion control

2

An

Ankit

M athurPre

sentation


3/33

REVIEW OF FLOW CONTROL

Receiver advertises window in ACK packets Receiver window size = amount of free space in

receive buffer

Sender will limit number of unACKed packetsto receiver window Invariant: every packet that arrives at receiver

can be buffered

3

An

AnkitM

athurPre

sentation


4/33

FLOW CONTROL

Sender

recv window = 5

Receiver

recv window = 0

4

An

AnkitM

athurPre

sentation


5/33

FLOW CONTROL, CONTD

Sender Receiver

recv wind = 2

recv wind = 2

5

An

AnkitM

athurPre

sentation


6/33

FLOW CONTROL JUSTIFICATION

TCP flow control is conservativeOnly send data if receiver is sure to have

space for it

Consider aggressive alternativeSend data optimistically, hoping receiver

has space for it

If receiver cant buffer packet, simply

discardWhich is more efficient?

6

An

AnkitM

athurPre

sentation


7/33

EFFICIENCY METRICS

Transmission speedGet as many bytes from sender to receiver

as quickly as possible

Network utilizationMaximize good put

Fraction of bytes spent on delivering new,useful data

E.g. delayed ack hurts transmissionspeed, but improves network utilization

7

An

AnkitM

athurPre

sentation


8/33

CONGESTION

What is congestion?Higher rate of inputs to a router than

outputs

What are effects of congestion?Delays

Loss

What layer does congestion occur at?Network layer

So why are we talking about it now?

8

An

AnkitM

athurPre

sentation


9/33

CONGESTION, SIMPLE CASE

Assume: Sender transmits at full line rate (i.e. receiver

window infinite)

Instant, free, precise loss notification

No other traffic on network

Sender Router Receiver

10 Mbps 5 Mbps

9

An

AnkitM

athurPre

sentation


10/33

CONGESTION, TWO SENDERS

Assume: Each sender transmits at 1/2 line rate

Sender 2

Router

Receiver 120 Mbps

5 MbpsSender 1

Receiver 220 Mbps

10

An

AnkitM

athurPre

sentation


11/33

CONGESTION AND DELAYS

During congestion, delay is much greaterthan ordinary delay

Since loss notification is imperfect, mayretransmit packets still in the queue!

Sender Router

retransmission original

11

An

AnkitM

athurPre

sentation


12/33

CONGESTION PROBLEMS

Excessive queuing delaysWasted network capacity on

retransmissions

Could have been used by other flowsSituation gets worse with multi-hop paths

Wasteful retransmit of prematurelytimed out packets

How bad does it get?1000-fold reduction in bandwidth!

12

An

AnkitM

athurPre

sentation


13/33

CONGESTION CONTROL

Congestion control involves two tasks:Detect congestion

Limit sending rate

Today we look at TCP approach to this

13

An

AnkitM

athurPre

sentation


14/33

TCP CONGESTION CONTROL

IdeaAssumes best-effort network

FIFO or FQEach source determines network capacity

for itself Implicit feedbackACKs pace transmission (self-clocking)

Challenge

Determining initial available capacityAdjusting to changes in capacity in atimely manner

14

An

AnkitM

athurPre

sentation


15/33


Basic idea Add notion of congestion window

Effective window is smaller of Advertised window (flow control) Congestion window (congestion control)

Changes in congestion window size Slow increases to absorb new bandwidth Quick decreases to eliminate congestion

15

An

AnkitM

athurPre

sentation


16/33


Specific strategySelf-clocking

Send data only when outstanding data ACKdEquivalent to send window limitation mentioned

GrowthAdd one maximum segment size (MSS) per

congestion window of data ACKd Its really done this way, at least in Linux:

see tcp_cong_avoid in tcp_input.c. Actually, every ack for new data is treated as an

MSS ACKdKnown as additive increase

16

An

AnkitM

athurPre

sentation


17/33


Specific strategy (continued)Decrease

Cut window in half when timeout occurs In practice, set window = window /2

Known as multiplicative decrease Additive increase, multiplicative decrease (AIMD)

17

An

AnkitM

athurPre

sentation


18/33

ADDITIVE INCREASE/ MULTIPLICATIVEDECREASE

ObjectiveAdjust to changes in available capacity

Tools

React to observance of congestionProbe channel to detect more resources

ObservationOn notice of congestion

Decreasing too slowly will not be reactive enoughOn probe of network

Increasing too quickly will overshoot limits

18

An

AnkitM

athurPre

sentation


19/33


New TCP state variable CongestionWindow

Similar toAdvertisedWindow for flow control Limits how much data source can have in transit

MaxWin = MIN(CongestionWindow,

AdvertisedWindow) EffWin = MaxWin - (LastByteSent -LastByteAcked)

TCP can send no faster then the slowest component,network or destination

Idea Increase CongestionWindow when congestion goes

down Decrease CongestionWindow when congestion goes

up

19

An

AnkitM

athurPre

sentation


20/33


Question How does the source determine whether or not the

network is congested?

AnswerTimeout signals packet loss

Packet loss is rarely due to transmission error (onwired lines)

Lost packet implies congestion!

20

An

AnkitM

athurPre

sentation


21/33


Algorithm Increment CongestionWindow by one

packet per RTT

Linear increaseDivide CongestionWindow by

two whenever a timeout occursMultiplicative decrease

Source Destination

21

An

AnkitM

athurPre

sentation


22/33


Saw tooth trace

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

KB

Time (seconds)

70

30

4050

10

10.0

22

An

AnkitM

athurPre

sentation


23/33

TCP START UP BEHAVIOR

How should TCP start sending data? AIMD is good for channels operating at capacity

AIMD can take a long time to ramp up to fullcapacity from scratch

Use Slow Start to increase window rapidly from acold start

23

An

AnkitM

athurPre

sentation


24/33

TCP START UP BEHAVIOR

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 coarse-grained, ~1/2sec)

Known as slow start

24

An

AnkitM

athurPre

sentation


25/33

SLOW START

Objective Determine initial available capacity

Idea Begin with CongestionWindow = 1 packet Double CongestionWindow each RTT

Increment by 1 packet for each ACK Continue increasing until loss Result

Exponential growth Slower than all at once

Used When first starting connection When connection times

Source Destination

25

An

AnkitM

athurPre

sentation


26/33


To make up for slow start, ramp upcongestion window quickly

Maintain threshold window size Use multiplicative increase

When congestion window smaller than threshold Double window for each window ACKdThreshold value

Initially set to maximum window size Set to 1/2 of current window on timeout

In practice, increase congestion window byone MSS for each ACK of new data (or Nbytes for N bytes)

26

An

AnkitM

athurPre

sentation


27/33

SLOW START

How long should the exponential increase from slow start continue? New variable: target window size CongestionThreshold

Estimate network capacity

When CongestionWindow reaches CongestionThresholdswitch to additiveincrease

Initial values CongestionThreshold = 8

CongestionWindow = 1

Loss after transmission 7 CongestionWindow currently 12

Set Congestionthreshold = CongestionWindow/2

Set CongestionWindow = 1

27

An

AnkitM

athurPre

sentation


28/33

SLOW START

Example trace ofCongestionWindow

Problem

Have to wait for timeout Can lose halfCongestionWindow of data

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

KB

70

30

40

50

10

CW flattens out due to loss

Slow start until CW = CT

Linear increase

28

An

AnkitM

athurPre

sentation


29/33

FAST RETRANSMIT AND FASTRECOVERY

Problem Coarse-grain TCP timeouts lead to idle periods

Solution Fast retransmit: use duplicate

ACKs to trigger retransmissionPacket 1Packet 2Packet 3

Packet 4

Packet 5

Packet 6

Retransmitpacket 3

ACK 1

ACK 2

ACK 2ACK 2

ACK 6

ACK 2

Sender Receiver

29

An

AnkitM

athurPre

sentation


30/33


Send ACK for each segment receivedWhen duplicate ACKs receivedResend lost segment immediately

Do not wait for timeout In practice, retransmit on 3rd duplicate

Fast recoveryWhen fast retransmission occurs, skip slow

startCongestion window becomes 1/2 previousStart additive increase immediately

30

An

AnkitM

athurPre

sentation


31/33


Results

Fast Recovery

Bypass slow start phase Increase immediately to one half last successful

CongestionWindow (ssthresh)

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0

KB

70

30

40

50

10

31

An

AnkitM

athurPre

sentation


32/33

TCP CONGESTION WINDOW TRACE

0

10

20

30

40

50

60

70

0 10 20 30 40 50 60

Time

CongestionWindow

threshold

congestionwindowtimeouts

slow start period

additive increase

fast retransmission

32

An

AnkitM

athurPre

sentation


33/33

AN ANKIT MATHUR PRESENTATION

Pop-up yourself for any queries

33

An

AnkitM

athurPre

sentation

CONGESTION CONTROL (Control by TCP) in 97-2003 ms office compatible

Documents

Transcript of CONGESTION CONTROL (Control by TCP) in 97-2003 ms office compatible