Transmission Control Protocol Of The Internet

Published Date: 02 Nov 2017

1. INTRODUCTION

Transmission Control Protocol of the Internet is a end-to-end connection oriented transport layer protocol which

provides a reliable packet delivery over an unreliable network . In spite of the efficient performance of the TCP, it becomes difficult to study and analyze the different versions of TCP because TCP itself was not able to provide the acceptable performance in large and congested networks. TCP variants vary a lot in terms of throughput and fairness. In this paper we perform a set of experiments to compare the different versions of TCP to find which perform better under certain conditions. TCP Tahoe is better than the original TCP as it executes the slow start and has a fast retransmit & congestion avoidance algorithm. TCP Reno implements fast recovery.

The TCP NewReno is more advanced as compared to TCP Reno as it implements fast recovery even for partial acknowledgments. The TCP Vegas provides a very efficient performance as it

implements packet re-transmission depending on RTT and type of acknowledgements.

The experiments that we performed helps us understanding the different variants in real time basis manner. We start the paper by taking a brief look at the different TCP variants and later we

compare them. The part 2 describes the different TCP variants and part 3 describes the methodology and the simulation arrangements for the

experiments we performed. Part 4 gives a comparative analysis of the different TCP variants and finally the conclusion is presented in Part 5.

2.1 TCP Tahoe

TCP Tahoe is a congestion control mechanism which was proposed by Van Jacobson. TCP Tahoe uses the mechanism of slow start where the congestion window size is taken as 1 at the start or a restart of data transmission. Once enough acknowledgement are received the congestion window is additionally increased and once congestion

has been encountered the window size is multiplicatively decreased. This mechanism is called as AIMD (Additive Increase Multiplicative Decrease). When a packet is lost the go back n method is used and the entire pipe is emptied.

2.2 TCP Reno

TCP Reno uses Fast Retransmit mechanism in which three duplicate acknowledgments are received and we understand that there is packet loss. It also has a slow start mechanism and also has the feature to detect packet loss. TCP Reno like TCP Tahoe empties the entire pipe after each packet loss. TCP Reno has the disadvantage of reducing the window size more than required and hence it fails to recover fast.

2.3 TCP New Reno

TCP New Reno is the advanced version of TCP Reno. It has the same mechanism as Reno of fast recovery but it does not reduce the window size. It can detect multiple packet losses. In TCP New Reno it waits till all the acknowledgements of all the congested packets are received. The disadvantage of TCP New Reno is that it takes the entire RTT to detect a single packet loss.

2.4 TCP Vegas

TCP Vegas emphasizes on packet delay rather than packet loss which was developed by Lawrence Brakmo and Larry Peterson. TCP Vegas detects congestion at an early stage based on Round Trip Time values of the packets in the connection unlike other variants like Reno and New Reno which detect congestion after it has actually happened via packet drops. TCP Vegas has a modified slow start algorithm and congestion avoidance scheme.

3.METHODOLOGY

We have used the Network Simulator 2 (NS-2) in the experiments to find out the throughput, average packet loss and fairness among the TCP variants under various load conditions and queuing algorithms. We have designed different scenarios in NS2 to measure the fairness and throughput. NS2 has been used for many years for simulation purposes and it has a record of accuracy and reliability.

NS2 implements network protocols such as TCP and UDP and also traffic behaviour such as FTP,

WEb, Telnet, CBR and VBR, router queue management mechanism such as Drop Tail, Red and CBQ, routing algorithms like Dijkstra and many more. We use Constant Bit Rate (CBR) to consume a specific amount of bandwidth. CBR does not perform any congestion control and doesn't care about dropped packets.

The paper has three set of experiments. In the 1st set of experiment we analyze the performance of TCP variants under the influence of various load conditions.

The parameters of the network topology are as follows:

6 nodes with duplex capacity of : 10 Mbps

Delay is maintained at 10ms

TCP connection is established between Node 1 and Node 4

FTP agent is attached at Node 1

Packet Size of CBR was set 1000

A Constant Bit Rate (CBR) is attached to the UDP connection at Node 2 and sink at Node 3.

The bandwidth of link N2-N3 is varied to create the bottleneck and network congestion so that fairness between the different TCP variants could be compared under varying load conditions.

N1 N4

\ /

\ /

N2-------N3

/ \

/ \

N5 N6

Fig.1. 6 node Network Topology

Calculations Performed :

Average Packet Loss + (Total Dropped Packets ÷ Total number of sent packets)

All drop packets are identified by 'd' field in trace file and total sent packets are identified by the 'r' field in the trace file.

Average Bandwidth =((Sum of Received Packet Size)*8) ÷ (Total Simulation Time*106)

Throughput = ((sum of Received Packet Size)*8) ÷ (Granularity * 106)

Average End-to-end Latency = (Total delay for all packets sent) ÷ (Total Packets Sent)

We use Tool Command Language (TCL) to write scripts that run on NS2. We get a output file after we run the TCL script. Given Below is the layout of the output file with description.

Fig.2.TCL Output file Layout

Experiment 1 :

In the first set of experiments we analyze the performance of TCP variants Tahoe, Reno, New Reno and Vegas. We set up a network topology with six nodes and we set the bandwidth of each link to 10 mbps. We perform test to analyze the performance of different TCP variants in presence of Constant Bit Rate (CBR).We add a CBR at N2 and sink at N3 and we add a single TCP stream from N1 to a sink at N4.

We analyze the throughput, packet drop rate, and latency of the TCP stream as a function of the bandwidth used by the CBR flow. We start the CBR flow t 1Mbps and we record the performance of TCP flow.

We keep increasing the CBR flow till it reaches the bottleneck.

In the graph given below the percentage of packets drop is almost same for all the variants till 6Mbps but after 6Mbps changing the CBR rate causes further percentage drop to increase for the different variants but after some time decreases for TCP Vegas. Hence from the graph it is clear that TCP Vegas has better fairness as compared to other variants. TCP Vegas detects congestion very early as compared to other TCP variants based on increasing RTT values of packets in the connection.

Fig.3.Percentage Drop vs CBR Rate

We compare the throughput of the different TCP variants TCP Tahoe, Reno, New Reno and Vegas against UDP flow.

TCP Reno and New Reno have a better congestion avoidance mechanism as compared to TCP Vegas. TCP Vegas does not have fair throughput as compared to other variants. TCP Reno and New Reno continue to increase the window size until packet loss takes place. The throughput increases as the window size increases which increases the buffer size.

Fig4. Througput of TCP variants vs CBR Rates

Experiment 2:

In Experiment 2 we start with three flows, one Constant Bit Rate and two TCP streams. We add a CBR source at N2 and a sink at N3. We add two TCP streams from N1 to N4 and N5 to N6. We plot the average throughput, packet loss rate and latency of each TCP flow as a function of the bandwidth used by Constant Bit Rate flow.

We perform the experiments using the following pairs of TCP variants :

Reno/Reno

NewReno/Reno

Vegas/Vegas

NewReno/Vegas

We runt the simulation for Reno1 and Reno 2 and we find out that both Percentage drop to CBR rate is comparable as both the variants are same. This is the preferred in a network where almost equal traffic is necessary.

Fig.5. Reno/Reno Packet Drop vs CBR Rate

We run the simulation for New Reno and Reno and we find out that there is not much difference in the percentage drop as Reno and New Reno do not differ much. The congestion mechanism of TCP New Reno is almost same as TCP Reno. TCP New Reno is able to detect multiple packet loss.

Fig.6.New Reno/Reno Percentage Drop

vs CBR Rate

We compare the throughput of New Reno and Reno and we find out that the congestion mechanism of both the variants are almost same except that New Reno is able to detect multiple packet loss. Hence the results do not vary much.

We run the simulation for Vegas1 and Vegas2 and find out that both Percentage drop to CBR rate is comparable as both the variants are same. This is the preferred in a network where almost equal traffic is necessary.

Fig.6. Vegas/Vegas Percentage Drop

vs CBR Rate

We run the simulation for New Reno and Vegas and we find out that Vegas has fewer drops than New Reno and it performs much better than New Reno.

TCP Vegas detects congestion much faster than New Reno as its congestion avoidance mechanism detects congestion at a very early stage.

Vegas congestion avoidance mechanism reduces the window size to maintain a small buffer queue size which reduces the packet losses due to buffer overflows

Fig.6.New Reno/Vegas Percentage Drop

vs CBR Rate

We compare the throughput of New Reno and Vegas and we find that TCP Vegas in not able to receive fair bandwidth allocation and hence the throughput is low when its sharing the bottleneck link with TCP New Reno.

Experiment 3:

In Experiment 3 we have a TCP flow from N1-N$ and one CBR/UDP flow from N5-N6. We start the TCP flow and once it is steady we start the CBR source and analyze how the TCP and CBR flows change under the following queuing algorithms :

DropTail

RED

We perform the experiment with TCP Reno and SACK and we plot the performance of the TCP and CBR flow overtime.

Tne experiment results showed that the two queuing mechanism does not provide equal fairness to both the TCP variants Reno and SACK.

We found that that Drop Tail mechanism provides greater preference to bursty traffic among the different flow in the network.

We found that RED mechanism provides relatively higher preference among all the data flows present.

The following Graphs were plotted where two queuing mechanism Drop Tail and RED are applied to RENO and SACK respectively.

No. Droptail doesn't provide fair bandwidth to each flow. Droptail provides preference to bursty traffic when traffic is bursty and RED provides very less bandwidth.

The end-to-end latency is more for Droptail as the TCP packets are dropped. The end-to-end delay is less when RED is used.

There is congestion in the network as soon as there is creation of CBR flow which results in less number of TCP packets being sent. Before the creation of CBR flow the number of TCP packets sent is very high.

Yes. RED is a good idea while dealing with SACK because it protects against bursty traffic and provides good performance.

Conclusion:

In this paper we compared the different TCP variants and found out that TCP Vegas has less percentage of packet drops as compared to other variants and TCP Vegas does not receive fair throughput as compared to other variants.

We also found out that RED queuing method is preferable over Droptail as it gives protection over bursty traffic and provides better fairness.

In future we can use combination of RED and Droptail to achieve better result.