Download doc

Lab 009
TCP: Transmission Control Protocol
Matthew Anders
Jeffrey Cavacini
David Pipkin
CSC 4900/8560
February 26, 2009
Summary
This lab demonstrates the capabilities of the Transmission Control Protocol. The congestion window
and segment sequence number of a TCP session is specifically tracked and examined. OPNET IT Guru
is the tool that is used to simulate the network environment and collect the data which will be analyzed.
TCP implements a state variable called the congestion window which is used by the source to limit how
much data can be sent over the network at one time. This helps in decreasing overall network
congestion and, in turn, decreasing the amount of timeouts and dropped packets.
Some other relevant functions of TCP are “slow start,” “fast retransmit,” and “fast recovery.” Slow
start increases the congestion window exponentially from a cold start in TCP sessions. Fast retransmit
and fast recovery are heuristics that trigger the retransmission of dropped packets sooner than the
regular timeout mechanism.
Objective
The objective of this lab is to simulate, analyze, and learn about the congestion control algorithms
implemented in TCP. This can be done visually by simulating a network in OPNET and generating
graphs from collected data. The application protocol that will be used to analyze TCP will be FTP.
Implementation
To capture the congestion window data for TCP, two subnets are setup on opposite ends of the USA
connected by an IP cloud. One subnet contains a server which hosts an FTP service. The other
contains a client which will connect to the server using TCP. For the lab, a 10 MB file is transferred
during the FTP session and the congestion windows and sequence segment number are tracked. There
are three scenarios which have slight differences in this process. The first scenario has no dropped
packets, the second has 5% packet drop in the IP cloud and does not have the fast retransmit function
enabled on TCP, the final also has 5% packet drop and has fast retransmit enabled.
Results
The NoDrop scenario shows a consistently ascending line for both the congestion window and the sent
segment sequence number. This makes perfect sense because there are no dropped packets and
therefore no detected congestion and therefore the congestion window constantly increases and the
segment sequence number sequentially rises as equal sized packets are delivered in order.
The DropNoFast scenario shows a fluctuating congestion window and a sequence segment number that
has a constant increase except in the areas where the congestion window is dropping. This is due to the
5% packet drop in the IP cloud. Every so often, as seen in the graph, the packet drop takes place and
timeouts are detected, therefore the congestion window decreases and the packets that are being
dropped have to be resent... this is where you see the horizontal lines on the segment sequence number
graph.
In the DropFast scenario, the congestion window is fluctuating once again, however, the sent segment
sequence number graph looks like it constantly increases. If the segment sequence number graph is
zoomed in, you can actually see small areas of horizontal lines where the congestion window drops in
size, as in the previous scenario. However, since the fast retransmit option was set, the horizontal area,
or the area where packets have to be resent, is minimal.
Exercises
1. Why does the Segment Sequence Number remain unchanged (indicated by a horizontal line in
the graphs) with every drop in the congestion window?
As explained in the results, this is due to congestion in the network and packets being dropped. The
congestion window only decreases in size when it detects timeouts, which it did since 5% packet drop
was assigned to the IP cloud.
2. Analyze the graph that compares the Segment Sequence numbers of the three scenarios. Why
does the Drop_NoFast scenario have the slowest growth in sequence numbers?
The Drop_NoFast scenario has the slowest growth because it has 5% packet drop and the fast
retransmit option disabled in the TCP settings. This means that there are timeouts in the network every
once in a while and the entire length of the TCP timeout period passes before a packet is resent. With
Drop_Fast, since fast retransmit is set, only three round trips worth of time is passed before a packet is
resent, so the recovery from dropped packets is much faster. With NoDrop, there is no packet loss and
all of the data is sent sequentially.
3. In the Drop_NoFast scenario, obtain the overlaid graph that compares Sent Segment
Sequence Number with Received Segment ACK Number for Server_West. Explain the
graph.
This graph visually shows the packet loss and retransmission of packets during the timeout periods in
the network. You can see that the blue line (sent segment sequence number) rises above the red line
(received segment ack number) and then the red line reaches the same level seconds later. This means
that the client didn't acknowledge that segment until after that period of time.
4. Create another scenario as a duplicate of the Drop_Fast scenario. Name the new scenario
Q4_Drop_Fast_Buffer. In the new scenario, edit the attributes of the Client_East node and
assign 65535 to its Receiver Buffer (bytes) attribute (one of the TCP Parameters). Generate a
graph that shows how the Congestion Window Size (bytes) of Server_West gets affected by
the increase in the receiver buffer (compare the congestion window size graph from the
Drop_Fast scenario with the corresponding graph from the Q4_Drop_Fast_Buffer scenario.)
The blue line indicates the increased receive buffer. With the increased buffer, more bytes can be
received in the same amount of time and only a couple periods of packets loss are able to happen
before the full 10 MB file is transmitted. This results in the entire session completing in about a quarter
of the time than with the smaller receive buffer.
Conclusion
This lab helped to visualize the concepts of the congestion control mechanisms in TCP. We learned
how much some of the other functions such as fast retransmit and the size of the receive buffer can
affect the time it takes to transfer data. We also closely examined and came to understand what affect
these mechanisms have on the segment sequence number and segment acknowledgement number. In
setting up the simulated environment for this lab, we achieved a greater understanding of OPNET IT
Guru and some of the capabilities it has in testing various network aspects.