Congestion Control in TCP
Outline
Project #2 overview
Overview of RENO TCP
Reacting to Congestion
SS/AIMD example
Fall, 2001
CS 640
1
Project #2 Logistics
• Second of three programming assignments
– Due 11/15 at 11:59:59
• Late solutions not accepted
– Two person teams
– Program will be turned in electronically
• Directions to be posted
– Programs must be written in C or C++
– Use the Linux/TUX lab for your work
Fall, 2001
CS 640
2
Project #2 Overview
• This assignment requires you to write one program
– forwarder
• Receives and sends data
– makefile
• Also requires you to use blaster/blastee from project #1
– Some enhancements required
• The goal of this project is to develop a packet forwarder with
three distinct capabilities
– Forwarding (not routing) packets from source to destination
– Implementing priority queues
– Implementing delays and random loss
Fall, 2001
CS 640
3
Project #2 Details
• Blaster
– Same packet transmission capability as project #1
– PLUS
• A second level of encapsulation (header) to facilitate forwarding
– Priority
– Destination IP/Port
• Ability to specify forwarding header details in command line
8 bit Priority
32 bit Destination IP
Fall, 2001
16 bit Dest Port
8 bit Packet Type
CS 640
32 bit Sequence
Variable Length Payload
4
Project #2 Details contd.
• forwarder
– Receives packets on a port and forwards them on another
– Forwarding is based on a static table
• <source, dest, next hop, delay, avg_loss, var_loss>
– Source, destination and next hop are IP/Port pairs
– Delay (ms) and avg_loss (%) simulate link characteristics
• If forwarder receives a packet not found in static table, it drops the packet
– Packets which can be forwarded are placed in one of three queues – high,
medium and low
• Each queue’s size can be specified (# packets)
• Higher priority packets are always forwarded before lower priority packets
Fall, 2001
CS 640
5
Project #2 Details contd.
• forwarder contd.
– After forwarding, packets enter another queues to simulate delay and
loss for each destination
• Delays are static and defined per packet
– Defined in forwarding table in milliseconds
• Losses are variable and defined per packet
– Defined in forwarding table as a %
– Use normal distribution for random variate distribution
» Use avg_loss and var_loss
– Upon shutdown, forwarder should print log of packet received and
loss statistics
• A concise statement about what happened to all types of packets
Fall, 2001
CS 640
6
Project #2 Details contd.
• blastee
– Retains statistics for each blaster it receives packets from
– Verifies the destination IP is indeed its own
– Upon receiving END packet, indicate how many packets have
been lost
• Based on sequence numbers from each source
Fall, 2001
CS 640
7
Grading
• Grades given by demo only
–
–
–
–
–
–
–
–
20 points: code compiling cleanly
30 points: basic forwarding function works
4 points: blaster sends packets with forwarding header
4 points: blastee verifies packets are meant for it
12 points: queue sizes can be specified and work
10 points: priorities can be specified and work
10 points: delay and loss rates can be specified and work
10 points: forwarder and blastee keep and print logs
Fall, 2001
CS 640
8
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)
• Challenge
– determining the available capacity in the first place
– adjusting to changes in the available capacity
Fall, 2001
CS 640
9
TCP RENO Overview
• Standard TCP functions
– Listed in last lecture: connections, reliability, etc.
• Jacobson/Karles RTT/RTO calculation
• Slow Start
• Congestion control/management
– Additive Increase/ Multiplicative Decrease (AIMD)
– Fast Retransmit/Fast Recovery
Fall, 2001
CS 640
10
Additive Increase/Multiplicative
Decrease
• 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:
– increase CongestionWindow when congestion goes down
– decrease CongestionWindow when congestion goes up
Fall, 2001
CS 640
11
AIMD (cont)
• Question: how does the source determine whether
or not the network is congested?
• Answer: a timeout occurs
–
–
–
–
Fall, 2001
timeout signals that a packet was lost
packets are seldom lost due to transmission error
lost packet implies congestion
RTO calculation is critical
CS 640
12
AIMD (cont)
Source
Destination
– increment CongestionWindow by one
packet per RTT (linear increase)
– divide CongestionWindow by two
whenever a timeout occurs (multiplicative
decrease – fast!!)
– CongestionWindow always >= 1 MSS
…
• Algorithm
• In practice: increment a little for each ACK
Increment = 1/CongestionWindow
CongestionWindow += Increment
MSS = max segment size = size of a single packet
Fall, 2001
CS 640
13
AIMD (cont)
KB
• Trace: sawtooth behavior
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
Time (seconds)
Fall, 2001
CS 640
14
Slow Start
• Objective: determine the available
capacity in the first
Source
Destination
– Additive increase is too slow
• One additional packet per RTT
• Idea:
• SSTHRESH indicates when to
begin additive increase
Fall, 2001
CS 640
…
– begin with CongestionWindow = 1 packet
– double CongestionWindow each RTT
(increment by 1 packet for each ACK)
– This is exponential increase to probe for
available bandwidth
15
Slow Start contd.
• Exponential growth, but slower than all at once
• Used…
– when first starting connection
– when connection goes dead waiting for timeout
KB
• 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
• Problem: lose up to half a CongestionWindow’s worth of
data
Fall, 2001
CS 640
16
SSTHRESH and CWND
• SSTHRESH called CongestionThreshold in book
• Typically set to very large value on connection setup
• Set to one half of CongestionWindow on packet loss
– So, SSTHRESH goes through multiplicative decrease for each
packet loss
– If loss is indicated by timeout, set CongestionWindow = 1
• SSTHRESH and CongestionWindow always >= 1 MSS
• After loss, when new data is ACKed, increase CWND
– Manner depends on whether we’re in slow start or congestion
avoidance
Fall, 2001
CS 640
17
SS Example
Client
Server
Client advertises receive
window of 8KB
SYN (40 bytes)
SYN + ACK (40 bytes)
MSS is 1.5kB with
standard 40B header
ACK + Data (150 bytes)
Client embeds request
For 30KB
Begin by sending
bytes 1:1460
CW=1, DIF=0, SST=44, RW=5
Data 1460
Client uses delayed
acknowledgements
(200ms)
ACK 1461
CW=2, DIF=0, SST=44, RW=5
Data 4380
ACK 4381
CW=3, DIF=0, SST=44, RW=5
Data 8760
ACK 7301
CW=4, DIF=1, SST=44, RW=5
Data 13140
Fall, 2001
ACK 10221
CW=5, DIF=2, SST=44, RW=5
CS 640
18
SS Example contd.
Client
Server
ACK 10221
Data 13140
ACK 13141
CW=5, DIF=2, SST=44, RW=5
CW=6, DIF=3, SST=44, RW=5
Data 17520
ACK 16061
ACK 18981
Data 20440
Data 23360
Data 26280
ACK 21901
ACK 24821
Data 29200
Data 30000
FIN (40 bytes)
ACK 27741
CW=7, DIF=3, SST=44, RW=5
CW=8, DIF=3, SST=44, RW=5
CW=9, DIF=3, SST=44, RW=5
CW=10, DIF=3, SST=44, RW=5
Server initiates active close
CW=11, DIF=3, SST=44, RW=5
ACK 27741
30001
FIN + ACK (40 bytes)
CW=12, DIF=3, SST=44, RW=5
ACK (40 bytes)
Fall, 2001
CS 640
19
Fast Retransmit and Fast Recovery
• Problem: coarse-grain
TCP timeouts lead to idle
periods
• Fast retransmit: use 3
duplicate ACKs to trigger
retransmission
• Fast recovery: start at
SSTHRESH and do
additive increase after fast
retransmit
Fall, 2001
CS 640
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
20
KB
Fast Retransmit Results
70
60
50
40
30
20
10
1.0
2.0
3.0
4.0
5.0
6.0
7.0
• This is a graph of fast retransmit only
– Avoids some of the timeout losses
• Fast recovery
– skip the slow start phase in this graph at 3.8 and 5.5 sec
– go directly to half the last successful CongestionWindow
(ssthresh)
Fall, 2001
CS 640
21