Ver 14.

1 TCP Congestion Control Algorithms

1.1 Introduction
A key component of TCP is end-to-end congestion control algorithm. The TCP congestion
control algorithm limits the rate at which the sender sends traffic into the network based on the
perceived network congestion. The TCP congestion control algorithm at the sender maintains a
variable called congestion window, commonly referred as cwnd, that limits the amount of
unacknowledged data in the network. The congestion window is adapted based on the network
conditions, and this affects the sender’s transmission rate. The TCP sender reacts to congestion
and other network conditions based on new acknowledgements, duplicate acknowledgements
and timeouts. The TCP congestion control algorithms describe the precise way in which TCP
adapts cwnd with the different events.

The TCP congestion control algorithm has three major phases (a) slow start, (b) congestion
avoidance, and (c) fast recovery. In slow-start, TCP is aggressive and increases cwnd by one
MSS with every new acknowledgement. In congestion avoidance, TCP is cautious and
increases the cwnd by one MSS per round-trip time. Slow-start and congestion avoidance are
mandatory components of all TCP congestion control algorithms. In the event of a packet loss
(inferred by timeout or triple duplicate acknowledgements), the TCP congestion control
algorithm reduces the congestion window to 1 (e.g., Old Tahoe, Tahoe) or by half (e.g., New
Reno). In fast recovery, TCP seeks to recover from intermittent packet losses while maintaining
a high congestion window. The new versions of TCP, including TCP New Reno, incorporate fast
recovery as well. Figure 1-1 presents a simplified view of the TCP New Reno congestion control
algorithm highlighting slow-start, congestion avoidance and fast recovery phases.

TCP congestion control algorithm is often referred to as additive-increase multiplicative-

decrease (AIMD) form of congestion control. The AIMD congestion control algorithm often leads
to a “saw tooth” evolution of the congestion window (with linear increase of the congestion
window during bandwidth probing and a multiplicative decrease in the event of packet losses),
see Figure 1-6.

© TETCOS LLP. All rights reserved Page 1 of 10

 Ver 14.2

Figure 1-1: A simplified view of FSM of the TCP New Reno congestion control algorithm

1.2 Network Setup

We will seek a large file transfer with TCP over a lossy link to study the TCP congestion control
algorithms. We will simulate the network setup illustrated in Figure 1-3 with the configuration
parameters listed in detail in steps to study the working of TCP congestion control algorithms.

Open NetSim and click on Experiments> Internetworks>TCP> TCP Congestion Control

Algorithms > Old-Tahoe then click on the tile in the middle panel to load the example as
shown in below Figure 1-2.

© TETCOS LLP. All rights reserved Page 2 of 10

 Ver 14.2

Figure 1-2: List of scenarios for the example of TCP Congestion Control Algorithms

NetSim UI displays the configuration file corresponding to this experiment as shown below:

Figure 1-3: List of scenarios for the example of TCP Congestion Control Algorithms

1.3 Procedure
Old Tahoe

The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 2
Routers in the “Internetworks” Network Library.

Step 2: In the Wired Node 1(Source node), the Congestion Control Algorithm in the Transport
layer properties is set to OLD TAHOE .

© TETCOS LLP. All rights reserved Page 3 of 10

 Ver 14.2

To configure any properties in the nodes, click on the node, expand the property panel on the
right side, and change the properties as described.

Step 3: In the General Properties of In the Wired Node 1(Source node), Wireshark Capture is
set to Online.

NOTE: Routers properties are set to default.

Step 4: The link properties are configured as shown in the table below. To set the wired link
properties, click on the link, expand the link property panel on the right, and configure the
settings as mentioned in the table.

Wired link Properties

Link 2 Properties (Backbone link)
Parameter Parameter value
Uplink / Downlink Speed (Mbps) 10
Uplink / Downlink BER 0.0000001
Uplink / Downlink Propagation
50000
Delay (µs)
Link 1 and 3 Properties
Uplink / Downlink Speed (Mbps) 10
Uplink / Downlink BER 0
Uplink / Downlink Propagation
100
Delay (µs)
Table 1-1: Wired link properties

Step 5: Configure CBR application between Wired node 1 and Wired node 2 by clicking on Set
traffic tab from the ribbon on top. To configure application properties, click on created
application and set the Packet Size to 1460 Bytes and Inter Arrival Time to 1168 microseconds
by keeping the transport layer to TCP.

Step 6: Click on Show/Hide info > Device IP check box in the NetSim GUI to view the network
topology along with the IP address.

Step 7: Click on Run simulation. The simulation time is set to 20 seconds.

Tahoe

Step 1: In Wired Node 1 (the source node), the congestion control algorithm is set to TAHOE
under the transport layer properties.

Step 2: Run simulation for 20 seconds.

New Reno

© TETCOS LLP. All rights reserved Page 4 of 10

 Ver 14.2

Step 1: In Wired Node 1 (the source node), the congestion control algorithm is set to NEW
RENO under the transport layer properties.

Step 2: Run simulation for 20 seconds.

1.4 Output
We have enabled WireShark Capture in Wired Node 1. The PCAP file is generated during the
simulation. From the PCAP file, the congestion window evolution graph can be obtained as
follows. In Wireshark, select any data packet with a left click, then, go to Statistics > TCP
Stream Graphs > Window Scaling.

The congestion window evolution for Old Tahoe, Tahoe and New Reno congestion control
algorithms are presented in Figure 1-4, Figure 1-5, and Figure 1-6, respectively.

Table 1-2 shows the throughput values of different congestion control algorithms (obtained from
the Application Metrics).

Figure 1-4: Congestion window evolution with TCP Old Tahoe. We note that Old Tahoe infers packet loss
only with timeouts, and updates the slow-start threshold ssthresh and congestion window cwnd as
ssthresh = cwnd/2 and cwnd = 1

© TETCOS LLP. All rights reserved Page 5 of 10

 Ver 14.2

Figure 1-5: Congestion window evolution with TCP Tahoe. We note that Tahoe infers packet loss with
timeout and triple duplicate acknowledgements, and updates the slow-start threshold ssthresh and
congestion window cwnd as ssthresh = cwnd/2 and cwnd = 1

Figure 1-6: Congestion window evolution with TCP New Reno. We note that New Reno infers packet loss

© TETCOS LLP. All rights reserved Page 6 of 10

 Ver 14.2

with timeout and triple duplicate acknowledgements and updates the slow-start threshold ssthresh and
congestion window cwnd as ssthresh = cwnd/2 and cwnd = ssthresh + 3MSS (in the event of triple
duplicate acknowledgements).

Congestion Control Throughput

Algorithm (Mbps)
Old Tahoe 2.98
Tahoe 2.62
New Reno 4.12
Table 1-2: Long-term average throughput of the different TCP congestion control algorithms

1.5 Observations and Inference

1. We can observe slow start, congestion avoidance, timeout, fast retransmit and recovery
phases in the Figure 1-4, Figure 1-5, and Figure 1-6. In Figure 1-4, we note that Old
Tahoe employs timeout, slow-start and congestion avoidance for congestion control. In
Figure 1-5, we note that Tahoe employs fast retransmit, slow-start and congestion
avoidance for congestion control. In Figure 1-6 we note that New Reno employs fast
retransmit and recovery, congestion avoidance and slow-start for congestion control.

2. We note that TCP New Reno reports a higher long term average throughput (in
comparison with Old Tahoe and Tahoe, see Table 1-2) as it employs fast retransmit and
recovery to recover from packet losses.

1.6 Exercises
1. Impact of Bit Error Rate on TCP Congestion Control Algorithms

Consider the similar experiment, change the BER value 1 × 10−7, 2 × 10−7,5 × 10−7,
1 × 10−6 on link 2, simulate it for 500 seconds and compare the performance of TCP Old
Tahoe, Tahoe, and New Reno by analyzing the throughput under different error rates.

Also, attach the window scaling graph obtained from Wireshark for 1 × 10−7 case.

© TETCOS LLP. All rights reserved Page 7 of 10

 Ver 14.2

2. Performance analysis of TCP congestion control algorithms with varying Maximum

Segment Sizes (MSS)

Consider the similar experiment by varying the Maximum Segment Size (MSS) to 500, 700,
900, and 1100 bytes. Simulate the network for 500 seconds and compare the performance
of TCP Old Tahoe, Tahoe, and New Reno by analysing the throughput under different
segment sizes.

3. Comparative Analysis of TCP Congestion Control Algorithms for Video Application

Construct the scenario using 2 Routers and 2 Wired node, set the link properties similar to
settings done in experiment, configure a video application with a generation rate of 5 Mbps,
set transport protocol to TCP and vary the TCP congestion control algorithm. Tabulate the
throughput and jitter values obtained for each case and discuss how each TCP congestion
control algorithm affected throughput and jitter. Include window scaling screenshots to
support your analysis and highlight any notable differences in the graphs.

Configure the Independent Gaussian model with the following values to generate 5 Mbps of
video

© TETCOS LLP. All rights reserved Page 8 of 10

 Ver 14.2

𝑓𝑟𝑎𝑚𝑒𝑠 𝑝𝑒𝑟 𝑠𝑒𝑐𝑜𝑛𝑑 (𝑓𝑝𝑠) = 10

𝑝𝑖𝑥𝑒𝑙 𝑝𝑒𝑟 𝑓𝑟𝑎𝑚𝑒 (𝑝𝑝𝑓) = 961538

𝑀𝑒𝑎𝑛, 𝑏𝑖𝑡𝑠 𝑝𝑒𝑟 𝑝𝑖𝑥𝑒𝑙 (𝑏𝑝𝑝 (µ)) = 0.52

The generation rate for video application can be calculated by using the formula shown
below:

𝐺𝑒𝑛𝑒𝑟𝑎𝑡𝑖𝑜𝑛 𝑅𝑎𝑡𝑒 (𝑏𝑖𝑡𝑠 𝑝𝑒𝑟 𝑠𝑒𝑐𝑜𝑛𝑑) = 𝑓𝑝𝑠 × 𝑝𝑝𝑓 × 𝑏𝑝𝑝

4. Impact of TCP Congestion Control on Video application in Multi-Node Networks

Construct the scenario using 3 wired node and 2 Routers, set the link speed to 20 Mbps,
propagation delay and BER to 0, configure a video application with a generation rate of 5
Mbps, set transport protocol to TCP and vary the TCP congestion control algorithm.
Tabulate the throughput and jitter values obtained for each case and discuss how each TCP
congestion control algorithm affected throughput and jitter.

Case a: Increase the transmitter count to 3 (add one more wired node to the existing
setup) and create one video application from newly dropped device and increase the

© TETCOS LLP. All rights reserved Page 9 of 10

 Ver 14.2

bottleneck link capacity to 30 Mbps. Vary the TCP congestion control algorithms and
tabulate the throughput and jitter values obtained for each algorithm.

Case b: Increase the transmitter count to 4 (add one more wired node for case a) and
create one video application from newly dropped device and increase the bottleneck link
capacity to 40 Mbps. Vary the TCP congestion control algorithms and tabulate the
throughput and jitter values obtained for each algorithm.

© TETCOS LLP. All rights reserved Page 10 of 10