Laboratory 5
Objective
The purpose of this lab is to demonstrate the functioning of TCP, and particularly the four
algorithms used for congestion control: slow start, congestion avoidance, fast retransmit
and fast recovery. The lab provides a number of scenarios to simulate and compare these
algorithms.
Overview
In this lab we will study TCP’s four intertwined congestion control algorithms, namely:
slow start, congestion avoidance, fast retransmit and fast recovery.
The objectives are:
• To study the behavior and implementation of slow start and congestion avoidance
algorithms.
• To study modifications to the congestion avoidance algorithm, namely fast
retransmit and fast recovery.
Procedure
Slow start and congestion avoidance
Previous versions of TCP start a connection with the sender injecting multiple segments
into the network, up to the windows size advertised by the receiver. This is ok when the
hosts are placed on the same LAN. But if there are routers and slower links between the
sender and the receiver different problems can arise. Some intermediate router must
queue the packets and it is possible for the router to run out of space in the queue. The
algorithm to avoid this is called slow start.
Beginning transmission into a network with unknown conditions requires TCP to slowly
probe the network to determine the available capacity, in order to avoid congesting the
network with an inappropriate large burst of data.
Slow start adds another window to the sender’s TCP: the congestion window, called
cwnd. When a new connection is established with a host on another network, the
congestion window is initialized to one segment (typically 536 bytes or 512 bytes). The
sender starts by transmitting one segment and waiting for its ACK. When that ACK is
received, the congestion window is increased from one to two, and two segments can be
sent. When each of those two segments is acknowledged, the congestion window is
increased to four. This provides an exponential growth, although it is not exactly
exponential because the receiver may delay its ACK’s, typically sending one ACK every
two segments that it receives. The sender can transmit up to the minimum of the
congestion window and the advertised window. The congestion window is flow control
imposed by the sender, while the advertised window is flow control imposed by the
receiver.
At some point the capacity of the internet can be reached and an intermediate router will
start discarding packets. This tells the sender that its congestion window has gotten too
large.
Congestion avoidance is a way to deal with lost packets. Congestion can occur when data
arrives on a big pipe (a fast LAN) and outputs on a smaller pipe (a slower WAN).
Congestion can also occur when multiple input streams arrive at a router whose output
capacity is less than the sum of the inputs. There are two indications of packet loss at a
sender: a timeout occurring and the receipt of duplicate ACK’s. However, the overall
assumption of the algorithm is that packet loss caused by damage is very small (much
less than 1%), therefore the loss of a packet signals congestion somewhere in the network
between the source and destination.
Although congestion avoidance and slow start are independent algorithms with different
objectives, in practice they are implemented together. When congestion occurs TCP must
slow down its transmission rate of packets into the network, and then invokes slow start
to get things going again.
The combined congestion avoidance and slow start algorithms require that two variables
are maintained for each connection:
•
•
A congestion window (cwnd).
A slow start threshold size (ssthresh).
The combined algorithm operates as follows:
a) Initialization for a given connection sets cwnd to one segment and sstresh to 65535
bytes.
The initial value of cwnd must be less than or equal to 2*SMSS bytes and must not be
more than 2 segments. SMSS, Sender Maximum Segment Size, is the size of the largest
segment that the sender can transmit.
The initial value of cwnd may be arbitrarily high (some implementations use the size of
the advertised window), but it may be reduced in response to congestion.
b) The TCP output routine never sends more than the minimum of cwnd and receiver’s
advertised window.
c) When congestion occurs one-half of the current window size is saved in ssthresh.
Additionally, if the congestion is indicated by a timeout, cwnd is set to one segment.
Congestion is indicated by a timeout or the reception of duplicate ACK’s.
d) When new data is acknowledged by the other end, increase cwnd. The way in which
cwnd is increased depends on whether TCP is performing slow start or congestion
avoidance. If cwnd is less than or equal to ssthresh, TCP is in slow start, otherwise TCP
is performing congestion avoidance. Slow start continues until TCP is halfway to where it
was when congestion occurred, and then congestion avoidance takes over. This is done
due to the recorded half of the window size that caused the problem.
As mentioned earlier slow start increases congestion window (cwnd) exponentially.
Congestion avoidance on the other hand dictates that congestion window (cwnd) be
incremented by segsize * segsize / cwnd each time an ACK is received, where segsize is
the segment size and cwnd is maintained in bytes. This results in a linear growth of
cwnd, compared to slow start’s exponential growth. The increase in cwnd should be at
most one segment each round-trip time (regardless how many ACK’s are received in
that RTT) whereas slow start increments cwnd by the number of ACK’s received in a
round-trip time.
Slow start and congestion avoidance simulation
This network setup utilizes TCP as its End-to-End transmission protocol. One server is
placed in Paris and one client is placed in Stockholm. The Congestion window size will
be analyzed with different mechanism. This network is assumed to be perfect with no
packet loss.
Create the network
1) Start OPNET and create a new project. File ! New… and choose project
in the pop-up window.
2) Name the project <initials>_TCP and the scenario NoDrop. Click OK.
3) Select Create Empty Scenario and click next.
4) Select Choose From Maps and click next.
5) Choose Europe from the maps and click next.
6) Do not include any technologies and click next.
7) Review the values and click OK.
8) Open the Object palette if it’s not already open and make sure that the
opened palette is internet_toolbox.
Figure 1 - Internet toolbox selected in the object palette
9) Add an Application Config object to the workspace and rename it to
Applications.
10) Right click on the Applications node and choose Edit Attributes.
11) Click in the value column on the Application Definitions row. Choose
Edit…
Figure 2 - Applications attributes
12) Set the Rows attribute value to 1.
13) Set the Application name to FTP_Application. Click OK.
14) Go to Application definitions ! Row 0 ! Description ! FTP and
choose Edit…
15) Set the following values:
Attribute
Value
100%
Command Mix (Get/Total)
constant (3600)
Inter-Request Time (seconds)
constant (9000000)
File Size (bytes)
FTP Server
Symbolic Server Name
Best Effort (0)
Type of service
None
RSVP Parameters
Not Used
Back-End Custom Application
16) Click OK.
17) Click OK to close Application Attributes.
18) Add a Profile Config object to the workspace and rename it to Profiles.
19) Right click on the Profile node and choose Edit attributes…
20) Click in the value column on the Profile Configuration row. Choose
Edit…
Figure 3 - Profiles attribute
21) Set the Rows attribute to 1.
22) Set Profile Name to FTP_Profile.
23) Set Operation Mode to Serial (Ordered).
24) Set Start Time to constant (100) and Duration to End of Simulation.
25) Set Repeatability to Once at Start Time.
26) Click in the Applications column and choose Edit…
27) Set the Rows attribute to 1.
28) Set Name to FTP_Application.
29) Set Start Time Offset to constant (5) and Duration to End of Profile.
30) Set Repeatability to Once at Start Time.
31) Click OK to close the Applications Table.
32) Click OK to close the Profile Configuration Table.
The Profiles Attributes should look like the picture below:
Figure 4 - Profiles Attributes
33) Click OK to close the Profiles Attributes dialog.
Create the Paris subnet
34) Place a subnet in Paris.
35) Set the name to Paris.
36) Double click on the Paris subnet node.
37) Place an ethernet_server in the workspace. Rename it to Server_Paris.
38) Place an ethernet4_slip8_gtwy router in the workspace next to the server.
39) Rename it to Router_Paris.
40) Connect the server and the router with a 100BaseT cable.
41) Right click on Server_Paris and choose Edit Attibutes…
42) Go to the Application: Supported Services attribute and choose Edit…
Figure 5 - Server Paris attributes
43) Set the Rows attribute to 1.
44) Choose the name FTP_Application and click OK.
45) Edit the Server Address attribute and set value to Server_Paris.
46) Expand TCP Parameters.
47) Disable both Fast Retransmit and Fast Recovery.
48) Click OK.
49) Save the project. File ! Save.
Figure 6 - Paris Subnet nodes
50) Click the Go to next higher level action button.
The Paris subnet is now configured.
Create the Stockholm subnet
51) Place a subnet in Stockholm.
52) Set the name to Sthlm.
53) Double click on the Sthlm subnet node.
54) Place an ethernet_wkstn in the workspace. Rename it to Client_Sthlm.
55) Place an ethernet4_slip8_gtwy router in the workspace next to the client.
56) Rename it to Router_Sthlm.
57) Connect the client and the router with a 100BaseT cable.
58) Right click on the Client_Sthlm node and choose Edit Attributes…
59) Go to the Application: Supported Profiles and choose Edit…
Figure 7 - Edit Application: Supported Profiles
60) Set the Rows attribute to 1.
61) Change the Profile Name attribute to FTP_Profile.
62) Click OK.
63) Set the Client Address attribute value to Client_Sthlm.
64) Go to the Application: Destination Preferences and choose Edit…
65) Set the Rows attribute to 1.
66) Set the Symbolic Name attribute to FTP Server.
67) Click in the Actual name column.
68) Set the Name attribute to Server_Paris. Click OK to close Actual name
table dialog.
69) Click OK to close Application: Destination Preferences dialog.
70) Click OK to close Client_Sthlm Attributes dialog.
71) Save the project. File ! Save.
The Stockholm subnet is now configured.
Figure 8 - Subnet Sthlm nodes
72) Click the Go to next higher level action button.
Create the IP Cloud
73) Place an ip32_cloud on the workspace between Stockholm and Paris.
74) Set the name to Europa_Internet.
75) Connect the Paris subnet to the Europa_Internet IP Cloud with a
PPP_DS3 cable.
76) Select Paris.Router_Paris in the pop-up menu.
77) Connect the Sthlm subnet to the Europa_Internet IP Cloud with a
PPP_DS3 cable.
78) Select Sthlm.Router_Sthlm in the pop-up menu.
The IP Cloud is now configured.
Figure 9 - Network overview
Choose Statistics
79) Enter the Paris Subnet.
80) Right click on Server_Paris and select Choose Indivitual Statistics from
the pop-up menu.
81) Expand Node Statistics ! TCP Connection and select Congestion
Windows Size (bytes)
Figure 10 – Choose Results dialogue
82) Right click on the Congestion Window Size (bytes) and select Change
Collection mode.
83) Check the Advanced checkbox in the pop-up dialog.
84) Change Capture mode to all values.
85) Click OK to close the dialog.
86) Click OK to close the Choose results dialog.
87) Save the project. File ! Save.
Slow start and Congestion avoidance simulation
88) Select Simulation ! Configure Discrete Event Simulation in the menu.
89) Set Duration to 10 minutes.
90) Click Run.
91) Click Close when the simulation has finished.
View the results
92) Right click on the workspace and choose View Results.
93) Expand Object statistics ! Choose From Maps Network !Paris !
Server Paris !TCP Connection and select Congestion Window Size.
94) Click Show.
The graph should resemble the one below.
Figure 11 - Slow start and Congestion Avoidance
Fast retransmit
Fast retransmit is a modification to the congestion avoidance algorithm.
The TCP sender should use fast retransmit algorithm to detect and repair loss, based on
incoming duplicate ACK’s. The fast retransmit algorithm uses the arrival of 3 duplicate
ACKs (4 identical ACK’s without the arrival of any other intervening packets) as an
indication that a segment has been lost. After receiving 3 duplicate ACK’s, TCP
performs a retransmission of what appears to be the missing segment, without waiting for
the retransmission timer to expire. The fast retransmit algorithm first appeared in the
4.3BSD Tahoe release.
Fast recovery
Congestion avoidance without slow start is performed after fast retransmit sends what
appears to be the missing segment. It is an improvement that allows high throughput
under moderate congestion, especially for large windows.
In this case the reason for not performing slow start is that the receipt of duplicate
ACK’s tells TCP that more than just one packet has been lost. Since the receiver can
only generate the duplicate ACK when another segment is received, that segment has left
the network and is in the receiver’s buffer. In other words there is still data flowing
between the two ends, and TCP does not want to reduce the flow abruptly by going into
slow start. The fast recovery algorithm appeared in the 4.3BSD Reno release.
The fast retransmit and fast recovery algorithms are usually implemented together as
follows:
a) When the third duplicate ACK is received, set ssthresh to no more than one-half the
current congestion window, cwnd, but no less than two segments. Retransmit the missing
segment, and then set cwnd to ssthresh plus 3 times the segment size. This increases the
congestion window by the number of segments that have left the network and which the
other end has cached.
b) Each time another duplicate ACK arrives, increment cwnd by the segment size. This
inflates the congestion window for the additional segment that has left the network.
c) Transmit a segment (packet) if allowed by the new value of cwnd and the receiver’s
advertised window.
d) When the next ACK arrives that acknowledges new data, set cwnd to ssthresh. This
ACK should be the acknowledgment of the retransmission from step a, one round-trip
time after the retransmission. Additionally, this ACK should acknowledge all the
intermediate segments sent between the lost packet and the receipt of the first duplicate
ACK. This step is congestion avoidance, since TCP is down to one-half the rate it was at
when the packet was lost.
Fast Retransmit and Fast Recovery simulation
Two additional scenarios will be created to study the behavior of fast retransmit and
fast recovery algorithms. The network just created was assumed to be perfect with no
packet loss. In the following scenarios packet loss will be introduced.
Create the Tahoe scenario
95) Select Scenarios ! Duplicate Scenario.
96) Name the scenario Tahoe.
97) Right click on the IP Cloud, Europa Internet, and choose Edit Attributes.
98) Set the Packet Discard Ratio attribute to 0.5%.
Figure 12 - Europa internet attributes
99) Click OK.
100) Enter the Paris subnet.
101) Right click on Server_Paris and choose Edit Attributes…
102) Expand TCP Parameters.
103) Change the Fast Retransmit attribute to Enabled.
Figure 13 - Server Paris TCP attributes
104) Click OK.
105) Save the project. File ! Save.
Create the Reno scenario
106) Select Scenarios ! Duplicate Scenario.
107) Name the scenario Reno.
108) Right click on the Server_Paris and choose Edit Attributes…
109) Expand TCP Parameters.
110) Change the Fast Recovery attribute to Reno.
Figure 14 - Server Paris TCP attributes
111) Click OK.
112) Save the project. File ! Save.
Simulate the scenarios
113) Select Scenarios ! Manage scenarios.
114) Change the Results attribute to collect or recollect.
Figure 15 - Manage Scenarios dialog
115) Click OK.
116) Click Close when the simulations has finished.
View results
117) Right click on the workspace and choose Compare Results.
118) Expand Object statistics ! Choose From Maps Network ! Paris !
Server Paris ! TCP Connection.
119) Check Congestion Window size (bytes).
120) Select Statistics Stacked in the bottom left roll-down menu.
Figure 16 - Compare results dialog
121) Click Show.
The graph should resemble the one below.
Figure 17 - Resluts Graphs
The first graph illustrates the NoDrop scenario which has no packet loss.
The second graph illustrates the Tahoe scenario which has 0.5% packet loss. When
congestion is indicated by a timeout, cwnd is set to one segment. In other words, slow
start is performed.
The third graph illustrates the Reno scenario which also has 0.5% packet loss. The
congestion window size does not drop to zero as in the Tahoe graph. Fast recovery is
performed instead of slow start.
The lab is completed.