You are on page 1of 5

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.

ORG

14

TCP and UDP Performance comparison In Network on Chip


Mohammad Reza Nouri Rad
Department of Computer Engineering Islamic Azad University KhorramAbad Branch, Iran

Reza Kourdy
Department of Computer Engineering Islamic Azad University KhorramAbad Branch, Iran

Abstract this paper was focused on study Transport Control Protocol (TCP) and User Datagram Protocol (UDP) performance in network on chip (NoC). We investigate the performance of TCP and UDP in term of bandwidth usage for increases throughput in network on chip (NoC), using simulation tool NS-2. Also two types of traffic (FTP and CBR) used during the simulation course in Mesh NoC architecture, and we used TCPs types (New Reno, and Vegas) which we used in our experiments. Keywords- Network-on-Chip, UDP, TCP New Reno, TCP Vegas.

INTRODUCTION

Although NoCs are widely used in ASIC design for complex and multi processor SoCs, we mainly address NoCs on FPGA where aspects like increasing design complexity, parasitic, and end-to-end latency have to be considered similarly. However, since NoCs are not yet matured in current design ows, EDA tools, and industrial applications, a lot of research is still necessary. Thus, one hot research area is the simulation and evaluation of NoCs in general and with regard to feasibility for a given application scenario [1]. TCP is a reliable connection oriented end-to-end protocol. It contains within itself, mechanisms for ensuring reliability by requiring the receiver the acknowledge the segments that it receives. The network is not perfect and a small percentage of packets are lost en route, either due to network error or due to the fact that there is congestion in the network and the routers are dropping packets. We shall assume that packet losses due to network loss are minimal and most of the packet losses are due to buffer overflows at the router [2]. In [3] we have proposed an adaptive strategy which is responsible for making decisions at run-time. Decisions are taken by processors in a distributed fashion and relate mostly to application performance. This present paper puts focus on the task migration strategy, and mostly addresses both the benefits brought by this technique as well as the associated performance penalty. The new architecture relies on a RTOS with support for semaphores, mutexes and task priority based scheduling algorithm. Moreover, a tiny implementation of a communication stack comprising UDP TCP/IP protocols is available. In recent years due to the growing interest for MPSoCs, task migration mechanisms have been explored in

order to deal with problems related to load balancing among PEs. Some works have adopted the benefits of such strategies for thermal balancing [4], [5] and [6]. A FPGA device may contain one or more CPUs beside controllers and on-chip memory. CPUs can be either hard-core (ASIC) or soft-core. An example of hard-core CPU in FPGA device is Xlinx Virtex 2 containing Power PC CPUs. NIOS II is a softcore CPU built and distributed by Altera and can be implanted into FPGA device to provide CPU functionalities [7]. A resource can be a processor core, a memory block, an FPGA, a custom hardware block or any other intellectual property (IP) block, which fits into the available slot and complies with the interface with the NOC switch or router. The NoC architecture using packet forwarding was showing in Fig. 1.

Fig. 1. Concept of Network-On-Chip Architecture.

BACKGROUND

2.1 Transmission Control Protocols (TCP) TCP provides a reliable transport service by monitoring the data that it sends. TCP uses the sequence numbers to monitor individual bytes of data, acknowledgment flags to tell if some of hose bytes have been lost somewhere, and checksum to validate the data itself. The TCP header format is shown in fig. 2.

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

15

Fig. 2. TCP header format.

TCP is a transport layer protocol used by applications that require guaranteed delivery. It is a sliding window protocol that provides handling for both timeouts and retransmissions. The byte stream is transferred in segments. The window size determines the number of bytes of data that can be sent before an acknowledgement from the receiver is necessary. 2.2 User Datagram Protocol (UDP) The user datagram protocol (UDP) is an unreliable and light weight transport layer protocol. UDP is more appropriate for any application that has to issue frequent update messages or that does not require every message to get delivered. If an application needs to use broadcasts or multicast in order to send data to multiple hosts simultaneously, then the application uses UDP. The UDP header format is shown in fig. 3.

Chip. TCP provides a highly monitored and reliable transport service, while User Datagram Protocol provides a simple transport with no error-correcting or flow-control services. Transmission control protocol is the dominant method of reliable and efficient moving of network traffic between a client application on one host and server application on another host. TCP accepts the responsibility for maintaining reliable connections between the hosts, while managing the efficient packaging and transmission of network traffic that application protocols prefer to avoid handling. The Transmission Control Protocol is like UDP (User Datagram Protocol), a transport layer protocol. The UDP is a fairly simple and straightforward protocol offering very little in the way of reliability or guarantees, TCP provides a way to connect the hosts across an internetwork reliably. UDPs unit of exchange is the UDP datagrams, a standalone message and a TCP, packages its data into segments containing both data and session control information. Whereas UDP is connectionless, TCP connections are virtual circuits, acting as if there is a direct, two-way connection between the hosts. Whereas UDP is an unreliable, TCP provides end-to-end reliability, requiring that communication host coordinate and agree to make connections and acknowledge receipt of network traffic. Whereas each UDP datagrams stands by itself as an individual message or reply, TCP supports out-of-order delivery of segments, reassembling data streams from IP (Internet Protocol) datagrams that have been delivered out of order [8]. 2.4 Network on Chip Protocols Since the Network on chip concepts has extensively borrowed from computer networks where the process in the chip are communicates by sending and receiving packets between each other as in computer networks where the two process in different computer are communicates by sending packets. And also, as in computer networks, the packets from the NoC process are switched or routed individually irrespective of its successor or predecessor. It is possible to use the same routing protocols from the computer networks, but these protocols are well suits for unknown topology of the network or complex network topology. So we have to simplify these protocols in order to get best performance/cost in implementation. To decrease the time to market, it is better to use the existing communication architecture to design new NoC systems. The Nostrum, one of such NoC protocols is discussed in following section. The Nostrum concept [9] the communication architecture for Networks on chip is to provide a platform with versatile communication capabilities, which can be reused for a large number of SoC designs. Nostrum architecture [9] suggests how the resource and switch are physical organized in the NoC based system. The Nostrum architecture offers a general architecture which can be used for all NoC based system design and these architecture uses the packet switched communication platform, which can be reused for a large number of SoC designs. Nostrum suggested the 2D mesh architecture consists of Resources(R) and switches (S) which are connected logically in a structured manner in

Fig. 3. UDP with IP Datagram.

as shown in fig. 3, minimum packet size without any data in UDP/IP was equal to 28 Byte. this 28 Byte was overhead in real world, but in Ns-2 the small packet size can be 8 Byte corrently. 2.3 TCP Versus UDP Protocols We have assumed that the application process in the internet uses the Transmission control protocols (TCP) for sending and receiving the application data to Network on

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

16

which every switch is connected to its four closest neighbor switches and to its corresponding resource.

and Actual Throughput are calculated using the following formula [12]:
Expected Throughput= congestion window / baseRTT (2) Actual Throughput = cwnd / RTT (3)

TCP TYPES OF PROTOCOL

3.1 Tcp Vegas Vegas are a TCP implementation which is a modification of Reno TCP Vegas [10] is different from TCP Reno in the sense that: 1. A new retransmission mechanism is used 2. An improved congestion avoidance mechanism that controls buffer occupy 3. A modified slow start mechanism That solve the problem of coarse gain timeout TCP Vega s include a modified retransmission strategy that is based on fire-gained measurements of the RTT (means define d by system clock) as well as new mechanism for congestion detection during slow start and congestion avoidance. In TCP Reno, a rather coarse grained timer is used to estimate the RTT and the variance, which results in poor estimates. Vegas extend Renos retransmission mechanism as follows. As mentioned before, Vegas record the system clock each time a packet is sent. When an ACK is received, Vegas calculate the RTT and use this more accurate estimate to decide to retransmit in the following two situations: 1. When it receives a duplicate ACK, Vegas checks to se e if the RTT is greater than timeout. If it is, then without waiting for the third duplicate ACK, it immediately retransmits the packet. 2. When a non-duplicate ACK is received, if it is the first or second ACK after a retransmission, Vegas again checks to see if the RTT is greater than timeout. If it is, then Vegas retransmit the packet. the Problems of Vegas is that, If there are enough buffer in the routers it means that Vegas congestion avoidance mechanism can function effectively a higher throughput and a faster response time result. As the load increase or the number or router buffer decrease, Vegas congestion avoidance mechanism is not as effective and Vegas start to behave more like Reno. Vegas is less aggressive in its use of router buffer than Reno because Vegas is limited. Finally Vegas congestion detection algorithm depends on the accurate value for Base RTT [11]. Vegas adds a intelligent scheme to increase the performance of parameters like throughput and cwnd, as it tries to outburst the initial phase of connection, in spite of increasing the window size to one it overshoots the band width capacity and tries to attain the ssthresh value as early as possible. It implements the following procedure [12]:
{diff=( Expected Throughput - Actual Throughput)*Base RTT} (1)

3.2 Tcp New Reno All the TCP clones basically rely over two most important phases i.e. Slow start phase and congestion avoidance phase New Reno source begins transmitting a new data flow in slow start. The initial congestion window is typically one segment. Each time a New Reno source receives an acknowledgment (ACK) packet, it increases the congestion window cwnd by one segment. With this approach, the congestion window size expands multiplicatively, doubling every RTT. After reaching to the threshold value New Reno enters in to the congestion avoidance phase and to overcome this fault it resets its congestion window to half of the ssthresh(Slow Start Threshold) value and then it increases its cwnd size by one each RTT, which results in degrading the performance and utilization of Link. New Reno follows the following equation to resolve congestion avoidance phase [12].

SYSTEM ARCHITECTURE

4.1 Hardware Architectures The common characteristic of NoC architectures is that the constituent IP cores communicate with each other through switches [13]. In network-on-chip the bandwidth between resource (IPs) and switches is very higher than the bandwidth between switch to switch. The Nostrum mesh 4x4 has shown as below:

Where diff mentioned in equation 1 is additional packets calculated by TCP Vegas, Expected Throughput is the expected throughput, Actual Throughput is the actual observed throughput, and Base RTT is the minimum RTT observed for the network path. The Expected Throughput

Fig. 4. The Nostrum Network on Chip.

As shown in fig. 4, The Square was processor elements and the circle elements were switches that connect to each

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

17

other. We consider that two core 0 and 15 communicate with each other through network.

parametrical aspects of UDP, TCP New Reno and TCP Vegas to bring out some more efficient transmission.

EVALUATIONS

REFERENCES
U. Ogras, J. Hu, and R. Marculescu, Key Research Problems in NoC Design: A Holistic Perspective, in Proc. of CODES+ISSS, Jersey City, NJ, USA, September 2005. V. Jacobson, Congestion Avoidance and Control. Proceedings of SIGCOMM '88 (Palo Alto, CA, Aug. 1988). G. Marchesan Almeida, G. Sassatelli, P. Benoit, N. Saint-Jean, S. Varyani, L. Torres, and M. Robert. An adaptive message passing mpsoc framework. International Journal of Recongurable Computing, Volume October, 2009. P. Chaparro, J. Gonzalez, G. Magklis, Cai Qiong, and A. Gonzalez. Understanding the thermal implications of multi-core architectures. Parallel and Distributed Systems, IEEE Transactions on, 18(8):1055 1065, August 2007. T. Sato, J. Ichimiya, N. Ono, K. Hachiya, and M. Hashimoto. On-chip thermal gradient analysis and temperature attening for soc design. In ASP-DAC 05: Proceedings of the 2005 Asia and South Pacic Design Automation Conference, pages 10741077, NewYork, NY, USA, 2005. ACM. I.Yeo,C.C.Liu,andE.J.Kim.Predictivedynamic thermal management for multicore systems. In DAC 08: Proceedings of the 45th annual Design Automation Conference, pages 734739, New York, NY, USA, 2008. ACM. Nios II Processor Architecture and Programming: CEG4131 course notes by Miodrag Bolic, http://www.site.uottawa.ca/~mbolic/ceg4131/ceg4131_nios2.ppt Bhavani Prasad Kommineni, Rajkumar Srinivasanm, " Interfacing Network on Chip Systems to Internet", Master of Science Thesis 2004. Mikael Millberg, Erland Nilsson, Rikard Thid, Shashi Kumar, and Axel Jantsch The Nostrum Backbone a Communication Protocol Stack for Networks on Chip, VLSI Design 2004, India. B. Qureshi, M. Othman, Member, IEEE, and N. A. W. Hami Progress in Various TCP Variants, IEEE, February 2009. M. Mathis, J. Mahdavi,Forward Acknowledgement: Refining TCP Congestion Control in Proceedings of ACM SIGCOMM, 1996. Mandakini Tayade, sanjeev sharma, "REVIEW OF DIFFERENT TCP VARIANTS IN AD-HOC NETWORKS", International Journal of Engineering Science and Technology (IJEST), Vol. 3, No. 3, March 2011, PP. 1906-1913. Kaushlendra Sharma, Mrs. Varsha Singh, "Adaption of Proactive Measure for Improving Performance Throughput Of TCP-Vegas", International Journal on Computer Science and Engineering (IJCSE), Vol. 3, No. 3, March 2011, PP. 1114-1117. Nostrum, http://www.imit.kth.se/info/FOFU/Nostrum. www.isi.edu/nsnam/ns. R. Lemaire, F. Clermidy, Y. Durand, D. Lattard, and A. Jerraya, Performance Evaluation of a NoC-Based Design for MC-CDMA Telecommunications Using NS-2, in The 16th IEEE International Workshop on Rapid System Prototyping, Jun. 2005, pp. 2430.

5.1 Simulation Framework In this paper, we have modeled our NoC architecture concepts with the widely used network simulator ns-2 [14]. NS-2 has been widely applied in research related to the design and evaluation of computer networks and to evaluate various design options for NoC architectures [15], including the design of routers, communication protocols, etc. 5.2 Simulation Results As shown in fig. 5, the communication load between mentioned cores with UDP protocol was more than the other TCP types.

[1] [2]

[3]

[4]

[5]

[6]

[7]

[8]

Fig. 5. Communication load in NoC with UDP and TCP types.

[9] [10] [11]

Although fig. 5, shows the communication load with UDP was more than TCP types, but the UDP protocol was unreliable protocol and this is because the UDP was not sent acknowledge (ACK) from destination node to source node. The other trend in fig. 5, is the communication load between mentioned cores with UDP protocol was two times bigger than TCP relatively. This is because the TCP delay sending packet up to the ACK of packet was received, and because the Round Trip Time (RTT) the communication load in TCP New Reno and TCP Vegas was reduces.

[12]

CONCLUSION AND FUTUREWORK

[13] [14] [15]

This paper presents some of the results obtained by using represents a hopeful improvement in the congestion avoidance in TCP phase which can be further deployed over to some different network on chip scenarios to find out other

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

18

Reza Kourdy received his B.Sc. Degree in Computer Engineering and his M.Sc. Degree in Computer Architecture both from Azad University of Arak, Iran, in 2002 and 2007, respectively. His research interests include Network-On-Chip Architecture and Fault-tolerance.
Mohammad Reza Nouri Rad received his B.Sc. Degree in Computer Engineering Software from Azad University of Najafabad, Iran, in 2001, and his M.Sc. Degree in Computer Software from Azad University of Arak, Iran, in 2010. His research interests include Network-OnChip Architecture and Network Security. He is Program Committee of following conferences : WICT 2011 CSNT 2011 CICN 2011 SocProS 2011 CSNT 2012 CICN 2012 BIC-TA 2012

You might also like