CSS432 Congestion Control

Textbook Ch6.1 6.4

Instructor: Joe McCarthy (based on Prof. Fukudas slides)

CSS432: Congestion Control

Taxonomy

Limited resources in network systems

Link bandwidth Buffer size in routers or switches

Resource allocation & congestion control: 2 sides of same coin

Pre-allocate resources so as to avoid congestion Control congestion only when it occurs

Flow control vs. congestion control

Flow control: to keep a fast sender from overrunning a slow receiver Congestion control: to keep a set of senders from sending two much data into the network

Two points of implementation

Router Centric QoS-based service Host Centric Best-effort service Reservation-based Feedback-based Rate-based Window-based

CSS432: Congestion Control

Connectionless Flow

Datagrams

Switched independently Typically flow through same set of routers if transmitted from the same source to the same destination Connectionless Flows

Routers & states:

No state: purely connectionless service Hard state: purely connection-oriented service Soft state: allocate resources on a per-flow basis
CSS432: Congestion Control 3

Queuing Discipline

First-In-First-Out (FIFO) w/ Tail Drop

Does not discriminate between traffic sources (flows)

Fair Queuing (FQ)

Work conserving: link is never left idle (if data to be sent) Explicitly segregates traffic based on flows Ensures no flow captures more than its share of capacity If there are n flows sending data, each is allocated 1/n bandwidth Variation: weighted fair queuing (WFQ)
Flow 1

Problem:

Variable packet length

Flow 2

H1

R1

R2

R3

H8

Round-robin service Flow 3

ETH IP (1400)

FDDI IP (1400)

PPP IP (512) PPP IP (512) PPP IP (376)

ETH IP (512) ETH IP (512) ETH IP (376)

Flow 4

[Section 3.2]
CSS432: Congestion Control 4

Bit-Round Fair Queuing (BRFQ)

Algorithm

For each queue, compute the virtual finish time (F) upon arrival of a new packet. Choose a packet with the lowest virtual finish time. No preemption Emulates bit-by-bit fair queuing Not perfect: cant preempt a large packet currently being transmitted

Pros and Cons

Example of fair queuing in action: (a) packets with earlier finishing times are sent first; (b) sending of a packet already in progress is completed
CSS432: Congestion Control 5

TCP Congestion Control

Created by Van Jacobson, 1980s,

~8

years after TCP/IP protocol stack became operational

Immediately preceding this time, the Internet was suffering from congestion collapse
hosts

would send their packets into the Internet as fast as the advertised window would allow, congestion would occur at some router (causing packets to be dropped), and the hosts would time out hosts retransmit their packets, resulting in even more congestion
CSS432: Congestion Control 6

TCP Congestion Control

Concept:
Assumes

best-effort network (FIFO or FQ routers) Determines network capacity at each source host Uses implicit feedback Uses ACKs to pace packet transmission (self-clocking)

Challenge:
Determining

the available capacity in the first place Adjusting # of in-transit packets in response to dynamic changes in the available capacity

CSS432: Congestion Control

Additive Increase/Multiplicative Decrease (AIMD)

0 4 SrcPort HdrLen 0

10

16 DstPort SequenceNum

31

Acknowledgment Flags AdvertisedWindow UrgPtr Options (variable) Data

Checksum

New state variable per connection: CongestionWindow Limits how much data source can send: Previously:
EffectiveWindow = AdvertisedWindow (LastbyteSent - LastByteAcked)

Sending application

Now:
EffectiveWindow = Min( CongestionWindow, AdvertisedWindow ) (LastByteSent LastByteAcked)

TCP LastByteWritten

y
LastByteAcked LastByteSent

Idea: Increase CongestionWindow when congestion deceases Decrease CongestionWindow when congestion increases

LastByteSent LastByteAcked AdvertisedWindow

EffectiveWindow = AdvertisedWindow (LastByteSent LastByteAcked)

CSS432: Congestion Control

AIMD (cont)

Question: how does the source determine whether or not the network is congested?

CSS432: Congestion Control

AIMD (cont)

Question: how does the source determine whether or not the network is congested?
Answer: a timeout occurs
Timeout signals that a packet was lost Packets are seldom lost due to transmission Lost packet implies congestion

error

CSS432: Congestion Control

10

AIMD (cont)

Algorithm

CongestionWindow Size

Increment CongestionWindow by 1 packet per RTT (additive increase) Divide CongestionWindow by 2 whenever a timeout occurs (multiplicative decrease)
70 60 50 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0

KB

Time (seconds)

In practice: increment a little for each ACK

Increment = MSS * (MSS/CongestionWindow) CongestionWindow += Increment
CSS432: Congestion Control 11

Slow Start
Source Destination

Objective: reach the available capacity as fast as possible Idea:

Begin

with CongestionWindow = 1 packet Double CongestionWindow each RTT (increment by 1 packet for each ACK) When timeout occurs:

Observe

slow start with tcpdump in assignment 3.

CSS432: Congestion Control 12

Set congestionThreashold to CongestionWindow / 2 Begin with CongestionWindow = 1 packet again

Slow Start

Exponential growth, but slower than all at once Used when first starting connection When Nagles algorithm is used and packets are lost, (timeout occurs and the congestion window is already 0)

Final Algorithm:
CongestionThreshold = INF while (true) { CongestionWindow = 1 while ( CongestionWindow < CongestionThreshold ) CongestionWindow *= 2 (based on slow start, exponential growth) while ( ACK returned ) CongestionWindow++ (based on additive increase, linear growth) if timeout occurs, CongestionThreshold = CongestionWindow / 2 Continue }
CSS432: Congestion Control 13

Slow Start

Trace:
70 60 50 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

KB

Where:

Colored line = value of CongestionWindow Solid bullets at top = timeouts Hash marks = time when each packet is transmitted Vertical bars = time when a packet that was eventually retransmitted (i.e., was lost) was first transmitted

CSS432: Congestion Control

14

Slow Start

http://www.6test.edu.cn/~lujx/linux_networking/0131777203_ch24lev1sec4.html
CSS432: Congestion Control 15

Slow Start

Trace:
70 60 50 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

KB

Problem: lose up to half a CongestionWindows worth of data

Timeout

Packets lost
The actual congestion threshold Congestion window

CSS432: Congestion Control

16

Fast Retransmit (TCP Tahoe)

Problem: coarse-grained TCP timeouts lead to idle periods

Sender Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6

Receiver

ACK 1
ACK 2 ACK 2 Duplicate ACK 1 ACK 2 Duplicate ACK 2 ACK 2 Duplicate ACK 3

Fast retransmit: use duplicate ACKs to trigger retransmission

The receiver sends back the same ACK as the last packet received in the correct sequential order. The sender retransmits the packet whose ID is one larger than this duplicate ACK, upon receiving 3 ACKs.

Retransmit packet 3 ACK 6

CSS432: Congestion Control

17

Effect of Fast Retransmit

70 60 50 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB

70 60 50 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0

KB

CSS432: Congestion Control

18

Effect of Fast Retransmit

Too many packets sent A half of them dropped off No ACKs returned CongestionWindow stays flat (no increase) A packet lost Duplicate ACKs allow transmission of more packets CongestionWindow is divided in a half upon retransmits rather than timeouts

Coarse-grained timeouts
70 60 50 40 30 20 10 1.0 2.0 3.0 4.0

KB

5.0

6.0

7.0

CSS432: Congestion Control

19

Fast Recovery (TCP Reno)

Fast recovery
skip

the slow start phase go directly to half the last successful

CongestionWindow (ssthresh)

CSS432: Congestion Control

20

Congestion

CSS432: Congestion Control

21

Congestion Avoidance

TCPs strategy: congestion control

control congestion after it happens repeatedly increase load in an effort to find the point at which congestion occurs, and then back off predict when congestion is about to happen reduce rate before packets start being discarded

Alternative strategy: congestion avoidance

Two possibilities

router-centric: RED Gateways Explanation in the following slides host-centric: TCP Vegas Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller.
CSS432: Congestion Control 22

Summary of TCP Versions

RFC 1122 TCP Tahoe TCP Reno TCP Vegas

RTT Estimation

Karns Algorithm

Slow Start

AIMD

Fast Retransmit

Fast Recovery

Throughput-rate congestion control

CSS432: Congestion Control

23

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
Congestion avoidance Global synchronization avoidance

CSS432: Congestion Control 24

RED Details

Detect / respond to long-lived congestion (vs. short bursts)

Low-pass filter

Compute average queue length

AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (usually 0.002) SampleLen is queue length each time a packet arrives

CSS432: Congestion Control

25

RED Details (cont)

Two queue length thresholds

if AvgLen <= MinThreshold then enqueue the packet else if AvgLen >= MaxThreshold then drop arriving packet else // MinThreshold < AvgLen < MaxThreshold calculate probability P drop arriving pack with probability P

CSS432: Congestion Control

26

RED Details (cont)

Computing probability P
TempP = MaxP * (AvgLen - MinThreshold) / (MaxThreshold - MinThreshold) P = TempP / (1 - count * TempP)
Typically 0.02

Drop Probability Curve

Keep track of how many newly arriving packets have been queued while AvgLen has remained between the 2 thresholds

Typically: MaxThreshold = MinThreshold * 2 MaxThreshold < MaxBuffer

CSS432: Congestion Control

27

Reviews
Queuing

disciplines: FIFO FQ TCP congestion control: AIMD, cold/slow start, and fast retransmit/fast recovery Congestion avoidance: RED and TCP vegas

Exercises in Chapter 6
Ex.

2 (Avoidance) Ex. 6 (Router congestions) Ex. 25(Slow start) Ex. 27 (AIMD, slow start) Ex. 34 (RED)

CSS432: Congestion Control

28

Exercise 2

TCP uses a host-centric, feedback-based, window-based resource allocation model. How might TCP have been designed to use instead the following models:
(a)

Host-centric, feedback-based and ratebased. (b) Router-centric and feedback-based.

CSS432: Congestion Control

29

Exercise 6

Consider the arrangement of hosts H and routers R and R1 in Figure 6.27. All links are full-duplex, and all routers are faster than their links. Show that R1 cannot become congested and for any other router R, we can find a traffic pattern that congests that router alone.

CSS432: Congestion Control

30

Exercise 25

You are an Internet Service Provider; your client hosts connect directly to your routers. You know some hosts are using experimental TCPs and suspect some may be using a greedy TCP with no congestion control.

What measurements might you make at your router to establish that a client was not using a slow start at all? If a client used slow start on startup but not after a timeout, could you detect that?

CSS432: Congestion Control

31

27. Consider the TCP trace in Figure 6.28. Identify time intervals representing slow start on startup, slow start after timeout, and linear-increase congestion avoidance. Explain what is going on from T=0.5 to T=1.9. The TCP version that generated this trace includes a feature absent from the TCP that generated Figure 6.11. What is this feature? This trace and the one in Figure 6.13 both lack a feature. What is it?
Figure 6.28

Figure 6.11

Figure 6.13

CSS432: Congestion Control

32

Exercise 34

Consider a RED gateway with MaxP = 0.01 and with an average queue length halfway between the two thresholds
Find

the drop probability Pcount for count = 1 and count = 100 Calculate the probability that none of the first 50 packets is dropped. Note that this is (1 P1) * * (1 P50)
CSS432: Congestion Control 33