Nt2580 Unit 6 Lab 1

MANAGEMENT INFORMATION SYSTEMS

OMIS 660 FALL 2015

Instructor – Dr. Yipeng Liu

LAB 1 – TCP: TRANSMISSION CONTROL PROTOCOL

Submitted by: Submission Date: 09-25-2015

Divya Malika Vandana

Z1776136

Divya Reddy Chandupatla

Z1768598

SUMMARY

In this lab, we used Transmission Control Protocol (TCP) which is a connection oriented protocol, to demonstrate congestion control algorithms. As the name itself describes, these algorithms are used to avoid network congestion. The algorithms were implemented in three different scenarios i.e. No Drop Scenario, Drop_Fast Scenario and Drop_NoFast Scenario.

OBJECTIVE
The objective of this lab is to set up a network which uses TCP for end – to – end transmission and analyse the size of the congestion window with different scenarios.

IMPLEMENTATION
• We started with creation of a new project in Riverbed Modeler.

According to the manual, we chose USA from the map list and created a network.

• As shown in the picture below, we added Application config, Profile config, ip32_Cloud and two subnets into the project workspace.

• The next step is to set the names of the devices on the network and edit their attributes.

• For the Application config, the name is set to APPLICATIONS. The attributes are edited as shown in the picture below.

Here, the number of rows of Applicaion definition is set to 1 since we are using a single application i.e. FTP. The name of application is given as FTP_Application. In the description of FTP inter request time, the time taken to transfer the file, is set to constant (3600) and the File size is set to constant (10000000) which is 10MB.

• For the Profile config, the name is set to PROFILES and the attributes are edited as shown in the picture below.

Here, the number of rows for profile config is set to 1 and the name is given as FTP_Profile.

• For the west subnet, one ethernet_server and one ethernet4_slip8_gtwy router are connected with a bidirectional 100 BaseT link. The attributes of the server are shown in the picture

below.

• The flavour is set to Tohoe for No_Drop and Drop_NoFast scenarios. For Drop_Fast scenario, the flavor is set to Reno.

• For the east subnet node, the Ethernet_wkstn and ethernet4_slip8_gtwy are set similar to the west subnet node.

RESULTS
1. NO DROP SCENARIO
Let’s consider the No_Drop Scenario. The following image shows the results for No_Drop scenario. It is clearly seen that the congestion window is shooted up because there isn’t any retransmission of packets. The packets are sent at constant time intervals and there isn’t any loss of packets. This is assumed to be an ideal scenario where the Internet works perfectly. However, it isn’t the same in real case.

From the graph, it is seen that the sent segment sequence number remains constant for certain period of time and then increases exponentially upto 10 MB (since the file to be downloaded is 10MB) from the starting point because there is no loss of packets resulting in no retransmission.

2. DROP NO FAST SCENARIO
In the Drop_NoFast scenario, we see that the packets are discarded. The packet discard ratio is set to 0.5% in the Performance Metrics of the IP Cloud. By analysing the report generated, we could see the congestion window size graph with lot of fluctuations and spikes. This is because the discarded packets are retransmitted only after the time out period is reached.

By comparing the graphs for congestion window size and sent segment sequence number, we see that the sent segment sequence number remains flat for corresponding drop in the congestion window and increases exponentially with increase in the congestion window.

3. DROP FAST SCENARIO

For Drop_Fast scenario, we change the flavour of the TCP Properties to Reno for fast recovery and fast retransmit mechanism.

When there is loss of packet, the sender doesn’t wait for the time out and resends the packets immediately using the mechanism of fast recovery and fast retransmit.

Analysing the graph, since there are loss of packets and retransmission, the congestion window size graph fluctuates by increasing and decreasing very frequently.

4. COMPARISION OF THE THREE SCENARIOS

The graph shows comparison of the three scenarios for sent segment sequence number. The green curve represents No_Drop scenario where it shoots up as it is a perfect scenario where there is no loss of packets. Whereas the blue curve which representd Drop_Fast Scenario increases exponentially because there is loss of packets and retransmission takes place.

QUESTIONS
1. Why does the Segment Sequence Number remain unchanged (indicated by a horizontal line in the graphs) with every drop in the congestion window?
The segment sequence number is used as a reference number for the segments that are sent from the sender. This in turn gets an acknowledgement from the receiver. Sequence number is increased only if the sender receives an acknowledgement.
In case if any segment is lost or discarded, the congestion window size drops accordingly. On the other hand, the receiver doesn’t send any acknowledgement because the lost packet is not resent. This causes the segment sequence number to remain unchanged with every drop in the congestion window.

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?
Generally, when a packet drop occurs, the window size drops respectively. For the Drop_NoFast scenario, the lost packet is not recovered and retransmitted until the server reaches the timeout window. Therefore, this results in delayed retransmission owing to slow growth in sequence numbers.

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.
Hint: - Make sure to assign all values to the Capture mode of the Received Segment ACK Number statistic.
We can see that there is a slight difference in the graphs of Sent Segment Sequence Number (Red curve) and Received Segment ACK Number (Blue curve). Initially, the ACK curve is lagging behind a little when compared with Sent Segment Sequence curve because of 0.5% packet ratio resulting in retransmission of the segments. However, there is not much of packet latency (time interval taken for the ACK to be received) between the two curves after a while.

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 picture below shows the comparison of the graphs for the congestion window size of Drop_Fast (blue curve) and Q4_Drop_Fast_Buffer scenarios (red curve). Analysing the graph, we can conclude that if the buffer size is more, then the amount of data to be transmitted is fast and complete. However, the buffer value cannot be extreme as it results in over loading and receiver may not able to take all the data at once. So it is required to maintain a optimal buffer value .

CONCLUSION
Through this lab, we gained practical exposure to the Riverbed Modeler. We got familiar with the Transmission control protocol, why and when TCP uses the additive increase and multiplicative decease mechanisms and how the different algorithms like Tahoe and Reno effect the congestion control mechanisms. We have implemented various scenarios with different parameters, simulated the scenarios and analysed their corresponding graphs. We look forward to gain in depth knowledge of Riverbed Modeler with the upcoming lab projects.