Scribd
Upload
54 views

Congestion Control: Issues

This document discusses various approaches to congestion control in computer networks, including: - TCP uses an additive increase/multiplicative decrease (AIMD) approach where the congestion window is slowly increased until packet loss occurs, then halved, resulting in a sawtooth pattern. - Explicit congestion notification (ECN) and random early detection (RED) gateways aim to notify sources of impending congestion before packet loss occurs. - TCP Vegas aims to avoid congestion by monitoring round-trip times and adjusting the sending rate if the actual rate differs from the expected rate. - TCP is generally fair in how it shares bandwidth among competing flows, as the additive increase and multiplicative decrease

Uploaded by

raw.junk
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
54 views

Congestion Control: Issues

This document discusses various approaches to congestion control in computer networks, including: - TCP uses an additive increase/multiplicative decrease (AIMD) approach where the congestion window is slowly increased until packet loss occurs, then halved, resulting in a sawtooth pattern. - Explicit congestion notification (ECN) and random early detection (RED) gateways aim to notify sources of impending congestion before packet loss occurs. - TCP Vegas aims to avoid congestion by monitoring round-trip times and adjusting the sending rate if the actual rate differs from the expected rate. - TCP is generally fair in how it shares bandwidth among competing flows, as the additive increase and multiplicative decrease

Uploaded by

raw.junk
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Issues

Two sides of the same coin


pre-allocate resources so at to avoid congestion
(reservation based approach)
control congestion if (and when) is occurs
(feedback based approach)

Congestion Control

Source
1
10-M

bps

Ethe

rnet

Router
1.5-Mbps T1 link

Source
2

Destination

I
FDD
bps
00-M

Two points of implementation


hosts at the edges of the network (transport
protocol)
routers inside the network (queuing discipline)

Additive Increase/Multiplicative
Decrease

TCP Congestion Control


Idea

assumes

best-effort network (FIFO or FQ


routers) each source determines network
capacity for itself
uses implicit feedback
ACKs pace transmission (self-clocking)

Objective: adjust to changes in the available capacity


New state variable per connection: CongestionWindow

limits how much data source has in transit


MaxWin = MIN(CongestionWindow,
AdvertisedWindow)
EffWin = MaxWin - (LastByteSent LastByteAcked)

Idea:

Challenge
determining

increase CongestionWindow when congestion goes down


decrease CongestionWindow when congestion goes up

the available capacity in the first

place
adjusting to changes in the available capacity

AIMD (cont)

AIMD (cont)

Source

Question:

how does the source determine


whether or not the network is congested?

Answer:

Destination

Algorithm
increment

CongestionWindow by one
packet per RTT (linear
increase)
divide CongestionWindow by
two whenever a timeout occurs
(multiplicative decrease)

a timeout occurs

timeout

signals that a packet was lost


packets are seldom lost due to transmission
error
lost packet implies congestion

In practice: increment a little for each ACK


Increment = (MSS * MSS)/CongestionWindow
CongestionWindow += Increment

Slow Start

AIMD (cont)

Source

Trace:

sawtooth behavior

Destination

Objective:

determine the
available capacity in the first
Idea:

70
60
50
40
30
20
10

begin

1.0

2.0

3.0

4.0

5.0

6.0

Time (seconds)

7.0

8.0

9.0

10.0

with CongestionWindow
= 1 packet
double CongestionWindow
each RTT (increment by 1
packet for each ACK)

Fast Retransmit and Fast


Recovery

Slow Start (cont)

Exponential growth, but slower than all at


once
Used

Problem:

coarsegrain TCP timeouts


lead to idle periods
Fast retransmit: use
duplicate ACKs to
trigger
retransmission

when first starting connection


when connection goes dead waiting for timeout

Trace
70
60
50
40
30
20
10
1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

Sender

Receiver

Packet 1
Packet 2
Packet 3

ACK 1

Packet 4

ACK 2

Packet 5

ACK 2

Packet 6
ACK 2
ACK 2
Retransmit
packet 3
ACK 6

9.0

Time (seconds)

Problem: lose up to half a


CongestionWindows worth of data

Congestion Avoidance

Results

70
60
50
40
30
20
10

1.0

2.0

3.0

4.0

Time (seconds)

TCPs strategy

5.0

6.0

7.0

predict when congestion is about to happen


reduce rate before packets start being discarded
call this congestion avoidance, instead of
congestion control

skip the slow start phase


go directly to half the last
successful CongestionWindow
(ssthresh)

Alternative strategy

Fast recovery

control congestion once it happens


repeatedly increase load in an effort to find the
point at which congestion occurs, and then back
off

Two possibilities

router-centric: DECbit and RED Gateways


host-centric: TCP Vegas

DECbit

End Hosts

Add binary congestion bit to each packet


header
Router

Destination

echoes bit back to source


Source records how many packets
resulted in set bit
If less than 50% of last windows worth
had bit set

monitors average queue length over last busy+idle


cycle Queue length
Current
time

Previous
cycle
Averaging
interval

Current
cycle

increase CongestionWindow

Time

If

50% or more of last windows worth had


bit set

set congestion bit if average queue length > 1


attempts to balance throughout against delay

Random Early Detection


(RED)

Notification

is implicit

just

drop the packet (TCP will timeout)


could make explicit by marking the packet
Early

random drop

rather

than wait for queue to become full, drop


each arriving packet with some drop
probability whenever the queue length
exceeds some drop level

by 1 packet

decrease CongestionWindow

by 0.875 times

TCP Vegas

Idea: source watches


for some sign that
routers queue is
building up and
congestion will
happen too; e.g.,

RTT grows

sending rate flattens

70
60
50
40
30
20
10
1.0 1.5

2.0

2.5 3.0 3.5 4.0 4.5


Time (seconds)

5.0

5.5 6.0

6.5

7.0 7.5 8.0 8.5

0.5 1.0 1.5

2.0

2.5 3.0 3.5 4.0 4.5


Time (seconds)

5.0

5.5 6.0

6.5

7.0 7.5 8.0 8.5

0.5 1.0 1.5

2.0

2.5 3.0 3.5 4.0 4.5


Time (seconds)

5.0

5.5 6.0

6.5

7.0 7.5 8.0 8.5

0.5

1100
900
700
500
300
100

10
5

Algorithm (cont)

Algorithm

Let BaseRTT be the minimum of all measured RTTs


(commonly the RTT of the first packet)
If not overflowing the connection, then

ExpectRate = CongestionWindow/BaseRTT

Parameters

Source calculates sending rate (ActualRate) once


per RTT
Source compares ActualRate with ExpectRate

0.5

TCP throughput

Let

slow start

W be the window size when loss


occurs.
When window is W, throughput is W/RTT
Just after loss, window drops to W/2,
throughput to W/2RTT.
Average throughout: .75 W/RTT

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

5.5

6.0

6.5

7.0

7.5

8.0

3.5 4.0 4.5 5.0


Time (seconds)

5.5

6.0

6.5

7.0

7.5

8.0

240
200
160
120
80
40
1.0

1.5

2.0

2.5

3.0

Even faster retransmit

Ignore

1.0

Time (seconds)

the average throughout ot TCP as


a function of window size and RTT?

70
60
50
40
30
20
10
0.5

Diff = ExpectedRate - ActualRate


if Diff <
increase CongestionWindow linearly
else if Diff >
decrease CongestionWindow linearly
else
leave CongestionWindow unchanged

Whats

= 1 packet
= 3 packets

keep fine-grained timestamps for each packet


check for timeout on first duplicate ACK

TCP Futures

Example: 1500 byte segments, 100ms RTT,


want 10 Gbps throughput
Requires window size W = 83,333 in-flight
segments
Throughput in terms of loss rate:
1.22 MSS
RTT L

L = 210-10
New versions of TCP for high-speed needed!

TCP Fairness
Fairness goal: if K TCP sessions share same
bottleneck link of bandwidth R, each should
have average rate of R/K

Why is TCP fair?


Two competing sessions:

TCP connection 1

Additive increase gives slope of 1, as throughout


increases
multiplicative decrease decreases throughput
proportionally
equal bandwidth share

TCP
connection 2

Connection 2 throughput

bottleneck
router
capacity R

loss: decrease window by factor of 2


congestion avoidance: additive increase

Connection 1 throughput R

Delay modeling
Q: How long does it take
to receive an object
from a Web server
after sending a
request?
Ignoring congestion,
delay is influenced by:

TCP connection
establishment
data transmission delay
slow start

Fixed congestion window (1)

Notation, assumptions:

Assume one link


between client and
server of rate R
S: MSS (bits)
O: object size (bits)
no retransmissions (no
loss, no corruption)

Window size:

First assume: fixed


congestion window, W
segments
Then dynamic window,
modeling slow start

First case:
WS/R > RTT + S/R: ACK
for first segment in
window returns before
windows worth of data
sent
delay = 2RTT + O/R

Fixed congestion window (2)


Second case:

WS/R < RTT + S/R:


wait for ACK after
sending windows
worth of data sent

delay = 2RTT + O/R


+ (K-1)[S/R + RTT - WS/R]

You might also like