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

ORG

138

TCP Versus UDP Performance In Term Of Bandwidth Usage 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 in this paper we analyze and compare the UDP and different congestion control and avoidance mechanisms which proposed for TCP/IP protocols, namely: Fack, Reno, and Sack, that adept in network on chip (NoC). We simulate Mesh NoC architecture with Network Simulator 2 (NS2). The simulation results reveal the applicability of UDP protocol in bandwidth usage of proposed architecture. Keywords- Network-on-Chip, UDP, TCP Fack, TCP Reno, TCP Sack.

INTRODUCTION

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].Three major trends of design, all employed a FPGA chip in it, are introduced, showing in Fig. 1.

Packet-based interconnection networks, known as Network-on-Chip (NoC) architectures, are increasingly adopted in System-on-Chip (SoC) designs, which support numerous homogeneous and heterogeneous functional modules. Systems-on-chip (SoCs) for multimedia or telecommunication applications will contain a large number of process-ing elements (PEs) such as a DSP processor, RISC CPU, embedded RAM, graphics engine, etc. As a result, there is a need for high-throughput communications links between these blocks. There exist many bus based SoCs which are widely used in industry such as AMBA [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

Fig. 1. Different designs using FPGA.

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

139

Fig. 2. TCP header format based on RFC 793.

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.

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 which every switch is connected to its four closest neighbor switches and to its corresponding resource.

Fig. 3. UDP header format.

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 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

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

140

TCP TYPES OF PROTOCOL

3.1 Tcp Fack TCP FACK is a set of new heuristics for handling the congestion window during periods of loss. It includes a number of ideas which other groups have worked on in parallel, but rolls them all up into one package. The development in TCP SACK with Forward Acknowledgement is identified as TCP FACK [10]. The utilization of TCP FACK is almost identical to SACK but it establishes a little enhancement evaluated to it. It uses SACK option to better estimate the amount of data in transit [10]. TCP FACK introduces a better way to halve the window when congestion is detected. When CWND is immediately halved, the sender stops transmitting for a while and then resumes when enough data has left the network. In this one RTT can be avoided when the window is gradually decreased [10]. When congestion occurs; the window should be halved according to the multiplicative decrease of the correct CWND. Since the sender identifies congestion at least one RTT after it happened, if during that RTT it was in slow start mode, then the current CWND will be almost double than CWND when congestion occurred. Therefore, in this case, CWND is first halved to estimate the correct CWND that should be further decreased. 3.2 Tcp Reno This Reno retains the basic principle of Tahoe, such as slow starts and the coarse grain re-transmit timer. However it adds some intelligence over it so that lost packets are detected earlier and the pipeline is not emptied every time a packet is lost. Reno requires that we receive immediate acknowledgement whenever a segment is received. The logic behind this is that whenever we receive a duplicate acknowledgment, then his duplicate acknowledgment could have been received if the next segment in sequence expected, has been delayed in the network and the segments reached there out of order or else that the packet is lost. If we receive a number of duplicate acknowledgements then that means that sufficient time has passed and even if the segment had taken a longer path, it should have gotten to the receiver by now. There is a very high probability that it was lost so Reno suggests an algorithm called Fast Re-Transmit. Whenever we receive 3 duplicate ACKs we take it as a sign that the segment was lost, so we re-transmit the segment without waiting for timeout. Thus we manage to re-transmit the segment with the pipe almost full. [11]. 3.3 Tcp Sack TCP with Selective Acknowledgments is an extension of TCP Reno and it works around the problems face by TCP RENO and TCP New-Reno, namely detection of multiple lost packets, and re-transmission of more than one lost packet per RTT. A SACK retains the slow-start and fast retransmits parts of RENO. It also has the coarse grained timeout of Tahoe to fall back on, incase a packet loss is not detected by the modified algorithm. SACK TCP requires that segments not be acknowledged cumulatively but should be acknowledged selectively. Thus each ACK has a block

which describes which segments are being acknowledged. Thus the sender has a picture of which segments have been acknowledged and which are still outstanding. Whenever the sender enters fast recovery, it initializes a variable pipe which is an estimate of how much data is outstanding in the network, and it also set CWND to half the current size. Every time it receives an ACK it reduces the pipe by 1 and every time it retransmits a segment it increments it by 1. Whenever the pipe goes smaller than the CWD window it checks which segments are un received and send them. If there are no such segments outstanding then it sends a new packet [12]. Thus more than one lost segment can be sent in one RTT.

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:

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 other. We consider that two core 0 and 15 communicate with each other through network.

EVALUATIONS

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.

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

141

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.

for detecting loss-based flows sharing the same link queue with delay-based flows.

7
[1]

REFERENCES
J. Park, I. Kim, S. Kim, S. Park, B. Koo, K. Shin, K. Seo, and J. Cha, MPEG-4 video codec on an ARM core and AMBA, in Proc. of Workshop and Exhibition on MPEG-4, Jun. 2001, pp. 9598. 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. Mandakini Tayade et al, " REVIEW OF DIFFERENT TCP VARIANTS IN AD-HOC NETWORKS", International Journal of Engineering Scince and Technology(IJEST), Vol. 3, No. 3, March 2011, pp. 1906-1913. K. Fall, S. Floyd Simulation Based Comparison of Tahoe, Reno and SACK TCP, 1998. 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.

[2] [3]

[4]

[5]

[6]

[7]

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

[8]

Although fig. 5, shows that the communication load with UDP was more than TCP types, but the UDP protocol was unreliable protocol and this is because that the UDP was not sent acknowledge(ACK) from destination node to source node. The other trend in fig. 5, is that the communication load between mentioned cores with UDP protocol was two times bigger than TCP relatively, this is because that 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 type was reduces.

[9]

[10] [11]

[12] [13] [14] [15]

CONCLUSION AND FUTUREWORK

This paper shows that UDP protocol have the most influence on throughput relative to TCP Fack, TCP Reno and TCP Sack. In the future, we will investigate the problem of optimal buffer allocation for loss-based and delay-based protocols in more detail. Also, we will explore mechanisms