1. Congestion Control in TCP
Outline
Project #2 overview
Overview of RENO TCP
Reacting to Congestion
SS/AIMD example
Fall, 2001
CS 640

2. 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

3. 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

4. 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
16 bit Dest Port
8 bit Packet Type
32 bit Sequence
Variable Length Payload
Fall, 2001
CS 640

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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 error
lost packet implies congestion
RTO calculation is critical
Fall, 2001
CS 640

13. AIMD (cont) Algorithm In practice: increment a little for each ACK
Source
Destination …
Algorithm
increment CongestionWindow by one packet per RTT (linear increase)
divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease – fast!!)
CongestionWindow always >= 1 MSS
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

14. AIMD (cont) Trace: sawtooth behavior Fall, 2001 CS 640 60 20 1.0 2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0 KB T
ime (seconds) 70 30 40 50 10
10.0
Fall, 2001
CS 640

15. Slow Start SSTHRESH indicates when to begin additive increase
Source
Destination …
Objective: determine the available capacity in the first
Additive increase is too slow
One additional packet per RTT
Idea:
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
SSTHRESH indicates when to begin additive increase
Fall, 2001
CS 640

16. Slow Start contd. Exponential growth, but slower than all at once
Used…
when first starting connection
when connection goes dead waiting for timeout
Trace
Problem: lose up to half a CongestionWindow’s worth 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
Fall, 2001
CS 640

17. 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

18. SS Example Client Server Fall, 2001 CS 640 Client advertises receive
window of 8KB
SYN (40 bytes)
MSS is 1.5kB with
standard 40B header
SYN + ACK (40 bytes)
Client embeds request
For 30KB
ACK + Data (150 bytes)
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
ACK 10221
Data 13140
CW=5, DIF=2, SST=44, RW=5
Fall, 2001
CS 640

19. SS Example contd. Client Server Fall, 2001 CS 640 ACK 10221 Data 13140
CW=5, DIF=2, SST=44, RW=5
ACK 13141
CW=6, DIF=3, SST=44, RW=5
Data 17520
ACK 16061
Data 20440
ACK 18981
CW=7, DIF=3, SST=44, RW=5
CW=8, DIF=3, SST=44, RW=5
Data 23360
ACK 21901
Data 26280
CW=9, DIF=3, SST=44, RW=5
ACK 24821
CW=10, DIF=3, SST=44, RW=5
Data 29200
Server initiates active close
ACK 27741
Data 30000
CW=11, DIF=3, SST=44, RW=5
FIN (40 bytes)
ACK 27741
ACK 30001
CW=12, DIF=3, SST=44, RW=5
FIN + ACK (40 bytes)
ACK (40 bytes)
Fall, 2001
CS 640

20. 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
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 6
Retransmit
packet 3
ACK 1
ACK 2
ACK 6
Sender
Receiver
Fall, 2001
CS 640

21. Fast Retransmit Results60 20
1.0
2.0
3.0
4.0
5.0
6.0
7.0 KB 70 30 40 50 10
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