Transmission Control Protocol (TCP) Model - A Simulation Study

Transcription

1 Journal of Emerging Trends in Engineering and Applied Sciences (JETEAS) 4(2): Scholarlink Research Institute Journals, 2013 (ISSN: ) jeteas.scholarlinkresearch.org Journal of Emerging Trends in Engineering and Applied Sciences (JETEAS) 4(2): (ISSN: ) Transmission Control Protocol (TCP) Model - A Simulation Study Akinwole A.K., Fatoki O.K., Oludipe O., and Yekini N.A Department of Computer Technology, Yaba College of Technology, Yaba, Lagos State, Nigeria. Corresponding Author: Yekini N.A Abstract The purpose of this project work is to evaluate the Transmission Control Protocol Model in a ClientServer network. The transmission of data is between two host; client and server. Simulation and Evaluation of TCP Model is carried out using Network Simulator OMNet++ version 4.x. OMNeT++ is an object-oriented modular discrete event network simulation framework. Two parameters were considered for the evaluation of the model; the Queuing Time and End-To-End Delay for both the Client and Server computer. This project work adhered to the simulation results as evidence that the network response time in the Server computer is better than the network response time in the Client computer based on Queuing Time, likewise End-To-End Delay in both the Client and Server computer is in a low value because the network response time is short which make transmission packets faster. All this evaluation shows that TCP is a good transport protocol for sending and receiving of data in a computer network. Keywords: OMNeT+, end-to-end delay, TCP, clientserver network, simulation, queuing time INTRODUCTION As technology evolves at an ever-increasing pace, time and distance seem to take on new meanings for all of us (Clark, D.D., (1982). Nowhere is this truer than in the computer industry, where the computers of today are often made obsolete by the systems that will arrive next week. In the midst of this constant change, it is good sometimes to reflect on some of the technologies that have been around seemingly forever. The Transmission Control Protocol/Internet Protocol (TCP/IP) is an industry-standard suite of protocols designed to be routable, robust, and functionally efficient (A. Papoulis and S. U. Pillai, 2002). TCP/IP was originally designed as a set of wide area network (WAN) protocols for the express purpose of maintaining communication links and data transfer between sites in the event of an atomic or nuclear war (A. S. Tanenbaum, 1996). Since those early days, development of the protocols has passed from the hands of the military and has been the responsibility of the Internet community (Rob Scrimger 1998). OMNeT++ is a discrete event simulator in development since 1992 (R. G. Ingalls, 2002). OMNeT++ is primarily use to simulate communication networks and other distributed systems and it is an open source simulation package that runs on both UNIX and Window (R. E. Shannon, 1989). Different contributors have written several of models for OMNeT++. Some of these models simulate simple queuing model, others simulate more realistic protocols such as TCP/IP. OMNeT++ is used by universities and companies (Ns-2) (R. G. Ingalls, pp ). The authors of this research work at reviewing related works on Transmission Control Protocol (TCP) model using OMNeT++ and C++, simulate the TCP Model and Evaluate the Queuing time and End-to-End Delay of the client and server of TCP model. Historical Background of Communication Network People communicate. One way or another, they exchange some information among themselves all the times. In the past several decades, many electronic technologies have been invented to aid this process of exchanging information in an efficient and creative way. Among these are the creation of fixed telephone networks, the broadcasting of television and radio, the advent of computers, and the emergence of wireless sensation. Originally, these technologies existed and operated independently, serving their very own purposes. Not until recently that these technological wonders seem to converge, and it is a well-known fact that a computer communication network is a result of this convergence (Issariyakul and Hossain 2009). The Transmission Control Protocol is a connectionbased protocol; this means that it requires the establishment of a session before data is transmitted between two machines. Because TCP sets up a connection between two machines, it is designed to verify that all packets sent by a machine are received on the other end. If, for some reason, packets are lost, 353

2 the sending machine will resend the data. Therefore, it is because a session is established that delivery of packets can be considered reliable. However, there is additional overhead involved with using TCP to transmit packets to support connection oriented communications. (Varga, A. 2004). An event-driven simulation ignores the intervals of inactivity by advancing the simulation clock from one event time to another (Tranter, et al., 2004). This process goes on and on until all the events are executed, or until the system reaches a specific state (e.g., the simulation time reaches a predefined value). Along the way, we certainly need a way to gather some statistics or states of the system for analysis purposes. This process of gathering information can take place right after every event execution. Alternatively, it can be done using a specialized entity which gathers statistics during the simulation (Banks and Carson 1984). RESEARCH METHODOLOGY This project work employed basically OMNeT++ and C++ to implement TCP Model. In this chapter, we describe the Simulator we used, our simulation methods, and the simulation parameters. OMNeT++ is an object-oriented modular discrete event network simulation framework. It has a generic architecture, so it can be (and has been) used in various problem domains: i. Modeling of wired and wireless communication networks. ii. Protocol modeling. iii. iv. Modeling of queuing networks. Modeling of multiprocessors and other distributed hardware systems. v. Validating of hardware architectures. vi. vii. Evaluating performance aspects of complex software systems. In general, modeling and simulation of any system where the discrete event approach is suitable, and can be conveniently mapped into entities communicating by exchanging messages Figure 1: The OMNeT++ 4.x IDE OMNeT++ itself is not a simulator of anything concrete, but rather provides infrastructure and tools for writing simulations. One of the fundamental ingredients of this infrastructure is a component architecture for simulation models. Models are assembled from reusable components termed modules. Well-written modules are truly reusable, and can be combined in various ways like LEGO blocks. Running the Simulation A simulation in OMNeT++ can be run in two different ways: Animation and Text-only. This way of running the simulation is particularly useful when first running the simulation, or to get acquainted with the protocols or networks the program simulates. It shows all the messages that are exchanged between the modules in an animation. The visual simulations are shown in the following graphics. Figure 3 shows the main window of the simulation. This is again the simulation used in section 4.1. This screen includes several controls to run the simulation. Simulations can be run step by step, normal (shows every message as an animation), fast (show animations, but faster) and express (which doesn t shows any animation). It is also possible to run the simulation until some point. In this screen, you can also see all modules and their parameters. There is also a list of scheduled events. 354

3 Figure 4 to Figure 6 show the actual network that is simulated. Figure 4 is the top view of the network, which has only four components (client1, server, configurator, and netamin Trace). Figure 5 show the internal modules of the client1 module. And again, in Figure 6, the internal modules of the Standard Host are shown run the simulation. Simulations can be run step by step, normal (shows every message as an animation), fast (show animations, but faster) and express (which doesn t shows any animation). It is also possible to run the simulation until some point. In this screen, you can also see all modules and their parameters. There is also a list of scheduled events. It is also possible to run the simulation until some point. In this screen, you can also see all modules and their parameters. There is also a list of scheduled events. From Figure 4 above, you can see a message (the dot) travelling between the client1 and the server. This is the way all messages are displayed. Figure 3: OMNeT++ Output window RESULT AND DISCUSSION Results of the Simulation Results from the simulation is gathered and stored in the output files and were stated in table 4-1 to table 4-4. Four graphs were plotted base on the result of the simulation that is the Queuing time and End-to-End Delay each for both the Client and Server computer. Figure 4.1 shows the overall event log of the simulation. Running the Simulation A simulation in OMNeT++ can be run in two different ways: Animation and Text-only. This way of running the simulation is particularly useful when first running the simulation, or to get acquainted with the protocols or networks the program simulates. It shows all the messages that are exchanged between the modules in an animation. Figure 4.1: Simulation Event Log Environment The visual simulations are shown in the following graphics. Figure 3 shows the main window of the simulation. This is again the simulation used in chapter 4.1. This screen includes several controls to 355

4 Table 4.1: ClientServer.client1.tcpApp[0] Queuing time bin_lower(time) bin_upper(time) value(packet kps) #NAME? E E E E Inf 0 Table 4.3: ClientServer.sever.tcpApp[0] Queuing Time bin_lower(time) bin_upper(time) value(packets Kps) #NAME? E E Inf 0 Table 4.4: ClientServer.client1.tcpApp[0] EndToEndDelay bin_lower(time) bin_upper(time) value(packets Kps) #NAME? E E Inf 0 Figure 4.2: Queueing Time (Client1) Table 4.2: ClientServer.client1.tcpApp[0] End-toEnd Delay bin_lower(time) bin_upper(time) value(packets Kps) #NAME? E E E E E E E E E E E E Inf 0 Figure 4.3: End-To-End Delay 356

5 DISCUSSION Queuing Time (Client) From the graph in Figure 4.2 the maximum time for the queue is 4.66E-05seconds when the packets in the Queue is 4, the queuing time reduces dramatically to seconds when the packets in the Queue reduces by 1(3 packets). When the packets in the queue are 3, the queuing time increases to seconds which may be caused by delay acknowledgement. The queuing time increases again to when the packets waiting for transmission reduces to 2. Queuing Time (Server) From the graph in Figure 4.4 the maximum time in the queue is 4.66E-05s when the number of packets in the queue (queue length) is 2. When the number of packets in the queue increases to 7, the queuing time reduces to 1.55E-05s. When the queue length reduces to 2 the queuing time reduces to s. These analyses shows that Queue length (number of packets awaiting transmission) in the Server computer does not determine the queuing time because when the queue length is 7, the queuing time is 1.55E-05s and when the queue length is 4 in the Client computer, the queuing time is 4.66E-05s. This brings us to a conclusion that the network response time in the Server computer is better than the network response time in the Client computer End-To-End Delay (Client) From the graph in Figure 4.3, it shows that the network response time for the TCP to retransmit three (3) lost segments transmission of packets is s and it occur only ones during transmission of packets. End-To-End Delay (Server) From the graph in Figure 4.5, it shows that the network response time for the TCP to retransmit three (3) lost segments transmission of packets is s and it occur only ones during transmission of packets in the network. From these analyses (End-To-End Delay in Client and Server), it shows that their acknowledgements return quickly, the round-trip time is short and the retransmission timer is low, the network response time is short for both the Client and Server computer. Therefore TCP is a good transmission protocol for sending and receiving data in the network base on this research. CONCLUSION In this project work a simulation environment for evaluating the performance of TCP Model in a simple ClientServer network was carried out using OMNeT++ version 4.x. Queuing Time and End-To- End Delay on both the Client and Server computer were the parameters used to evaluate TCP model. The two parameters were clearly stated and analyzed based on the result of the simulation. The results of the simulation were presented in visual event log; which show how data is been exchange between the two hosts, tables and bar charts/graph. This project work adhered to the simulation results as evidence that the network response time in the Server computer is better than the network response time in the Client computer based on Queuing Time, likewise End-To-End Delay in both the Client and Server computer is set to a low value. Based on all this evaluation it shows that TCP is a goon transport protocol for sending and receiving of data in a computer network. RECOMMENDATION TCP model in OMNeT++ proved to be working, but not free of errors. Some features were missing, and some were not correctly implemented. All TCP behavior was coded into one single module (clientserver), which made it hard to understand. For future version, it might be possible to split TCP functionality into several modules. REFERENCE A. Papoulis and S. U. Pillai, (2002) Probability, Random Variables and Stochastic A. S. Tanenbaum, (1996) Computer Networks, 3rd ed. Prentice Hall. Clark, D.D., (1982). RFC 813: Window and acknowledgement strategy in TCP. MIT DOI: / , c_ Springer Science+Business Media. J. Banks and I. J. S. Carson, (1984) Discrete-Event Systems Simulation. Prentice-Hall J. Kurose. The TCP/IP course website.available: com/enp/ John Wiley & Rob Scrimger, pp. 20 (1998) Introduction To Networking With Tcp/Ip Sons, Inc. Stevens, W.R. and G.R. Wright, (1994). TCP/IP illustrated. Addison-Wesley Kaage, U., V. Kahmann, and F. Jondral, (2001). An Omnet++ TCP Model. Laboratory for Computer Science, Computer Systems and Communications Processes, 2nd ed. McGrawHill. R. E. Shannon, (1989 ) Introduction to the art and science of simulation R. G. Ingalls, pp (2002) Introduction to simulation: Introduction to simulation, 357

6 R. M. Goldberg, (2000) Parallel and Distributed Simulation Systems. T. Issariyakul, E. Hossain, (2009) Introduction to Network Simulator NS2, the 30th conference on Winter simulation (WSC 98). Varga, A. (2004). IPSuite documentation. W. H. Tranter, et al., (2004) Principles of Communication Systems Simulation. Prentice Winter Simulation Conference. 358