TCP: Transmission Control Protocol

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.

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

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

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