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

ORG

77

Communication Load of TCP with Delayed ACK and UDP 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 TCP might underutilize the link and degrade the reliability. TCP uses the acknowledgments (ACKs) to adjust the sending rate. In this paper relies on the fact that TCP uses ACKs to determine its traffic sending to the network. In this paper we analyze and compare the bandwidth utilized of UDP with TCP/IP protocols, namely: Fack, Reno, and Sack with ACKs and Delay ACKs, 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 protocols, Delay ACKs.

INTRODUCTION

Modern integrated circuits (ICs) are becoming increasingly complex. The complexity makes it difficult to design, manufacture and integrate these high-performance ICs. The advent of multiprocessor Systems-on-chip (SoCs) makes it even more challenging for programmers to utilize the full potential of the computation resources on the chips. In the mean time, the complexity of the chip design creates new reliability challenges. As a result, chip designers and users cannot fully exploit the tremendous silicon resources on the chip. This research proposes a Proto type which is composed of a fault-tolerant multiprocessor SoC and a coupled single program, multiple data (SPMD) programming framework. [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]. As described in RFC 2581 [6], TCP increases the congestion window (and so the amount of outstanding data in the network) based on the number of ACKs received. Thus, reducing the number of ACKs received leads to a slower increase of the amount of sent data. For instance, it has been found that the time spent during the slow start phase is doubled when delayed ACK is used [7]. During the congestion avoidance phase, due to the same reason, the increase of the congestion window is also slower. the behavior of TCP Delayed ACK, with ACK for every segment shown in Fig. 1.

Fig. 1. Example of ACK behavior. (A) Every segment is acknowledged by the receiver, (b) Behavior of delayed ACK.

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

78

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.

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.

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

Fig. 3. UDP header format.

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

79

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.

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.

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

80

EVALUATIONS
[1]

REFERENCES
[14] X. Zhu, W. Qin, Prototyping a Fault-Tolerant Multiprocessor SoC with Run-time Fault Recovery , DAC 2006, July 2428, 2006, San Francisco, California, USA. 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. M. Allman and V. Paxson, W. Stevens, TCP Congestion Control, RFC 2581, IETF, April 1999. M. Allman, On the Generation and Use of TCP Acknowledgments, ACM SIGCOMM Computer Communication Review, pp. 4-21, Oct. 1998. 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.

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.

[2] [3]

[4]

[5]

[6] [7]

[8]

[9]

[10] [11]

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

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

Although fig. 5, shows the communication load with UDP was more than TCP versions, 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 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 versions was reduces. When delayed ACK is used in TCP versions, the time to reach the maximum value will be even longer. Thus communication load in TCP versions with delayed ACK was reduces related to the others.

CONCLUSION AND FUTUREWORK

This simulation is to show the effects of bandwidth usage UDP and delayed ACK algorithm in three widely used TCP versions, Fack, Reno and Sack. As a result we can conclude that UDP protocol have the most influence on throughput relative to TCP Fack, TCP Reno and TCP Sack, with ACK for every packet or Delayed ACK.

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.

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

81

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