) TCP (Opnet

: /161391/

TCP . ) (2
> <arezoo.rajabi.sharif@gmail.com .
:
5 .
)
( . .

.
.
EX3-STUDENTID .

http://ce.sharif.edu/courses/91-92/1/ce443-1/index.php

Laboratory 3
TCP simulation
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.

Terms
Congestion control
Slow start
Congestion avoidance
Fast recovery
Connection handshake
Fast retransmit
Flow Control

Overview
In this lab we will study TCPs 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 senders 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 ACKs, 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.

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 ACKs. 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. [3]
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 receivers
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 ACKs.

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 starts exponential growth. The increase in cwnd should be at
most one segment each round-trip time (regardless how many ACKs are received in
that RTT) whereas slow start increments cwnd by the number of ACKs received in a
round-trip time. [2]

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 its 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
Command Mix (Get/Total)
Inter-Request Time (seconds)
File Size (bytes)
Symbolic Server Name
Type of service
RSVP Parameters
Back-End Custom Application

Value
100%
constant (3600)
constant (9000000)
FTP Server
Best Effort (0)
None
Not Used

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 ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate
ACKs (4 identical ACKs without the arrival of any other intervening packets) as an
indication that a segment has been lost. After receiving 3 duplicate ACKs, 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
ACKs 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 receivers 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 receivers
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 complete!