Lab 009TCP: Transmission Control Protocol Matthew Anders Jeffrey Cavacini David Pipkin CSC 4900/8560 February 26, 2009 . a 10 MB file is transferred during the FTP session and the congestion windows and sequence segment number are tracked. The application protocol that will be used to analyze TCP will be FTP. This can be done visually by simulating a network in OPNET and generating graphs from collected data. OPNET IT Guru is the tool that is used to simulate the network environment and collect the data which will be analyzed. decreasing the amount of timeouts and dropped packets. Some other relevant functions of TCP are “slow start. The other contains a client which will connect to the server using TCP. For the lab. the final also has 5% packet drop and has fast retransmit enabled. Implementation To capture the congestion window data for TCP. analyze.” “fast retransmit. The congestion window and segment sequence number of a TCP session is specifically tracked and examined. two subnets are setup on opposite ends of the USA connected by an IP cloud. 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. and learn about the congestion control algorithms implemented in TCP. the second has 5% packet drop in the IP cloud and does not have the fast retransmit function enabled on TCP. in turn. Objective The objective of this lab is to simulate. One subnet contains a server which hosts an FTP service.Summary This lab demonstrates the capabilities of the Transmission Control Protocol. The first scenario has no dropped packets.” and “fast recovery. There are three scenarios which have slight differences in this process. This helps in decreasing overall network congestion and.” 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. 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 packet drop takes place and timeouts are detected. this is where you see the horizontal lines on the segment sequence number graph.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. Every so often.. This is due to the 5% packet drop in the IP cloud. . therefore the congestion window decreases and the packets that are being dropped have to be resent.. as seen in the graph. If the segment sequence number graph is zoomed in. However. as in the previous scenario. the sent segment sequence number graph looks like it constantly increases. since the fast retransmit option was set. or the area where packets have to be resent.In the DropFast scenario. the horizontal area. is minimal. . the congestion window is fluctuating once again. however. you can actually see small areas of horizontal lines where the congestion window drops in size. 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. . there is no packet loss and all of the data is sent sequentially. With Drop_Fast. since fast retransmit is set. so the recovery from dropped packets is much faster.Exercises 1. With NoDrop. this is due to congestion in the network and packets being dropped. 2. which it did since 5% packet drop was assigned to the IP cloud. 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. Analyze the graph that compares the Segment Sequence numbers of the three scenarios. 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. only three round trips worth of time is passed before a packet is resent. The congestion window only decreases in size when it detects timeouts. 3. obtain the overlaid graph that compares Sent Segment Sequence Number with Received Segment ACK Number for Server_West. . This graph visually shows the packet loss and retransmission of packets during the timeout periods in the network. Explain the graph. 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. In the Drop_NoFast scenario. This means that the client didn't acknowledge that segment until after that period of time. Create another scenario as a duplicate of the Drop_Fast scenario. . With the increased buffer. Name the new scenario Q4_Drop_Fast_Buffer. In the new scenario. Conclusion This lab helped to visualize the concepts of the congestion control mechanisms in TCP. We also closely examined and came to understand what affect these mechanisms have on the segment sequence number and segment acknowledgement number. 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.) The blue line indicates the increased receive buffer. This results in the entire session completing in about a quarter of the time than with the smaller receive buffer. edit the attributes of the Client_East node and assign 65535 to its Receiver Buffer (bytes) attribute (one of the TCP Parameters). In setting up the simulated environment for this lab. 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. we achieved a greater understanding of OPNET IT Guru and some of the capabilities it has in testing various network aspects. 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.4.