Devices & Hardware

COMPARING TCP-IPV4/ TCP-IPV6 NETWORK PERFORMANCE

Published
of 134
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Description
COMPARING TCP-IPV4/ TCP-IPV6 NETWORK PERFORMANCE A Thesis Presented to the Faculty of the Graduate School University of Missouri-Columbia In Partial Fulfillment of the Requirements for the Degree Master
Transcript
COMPARING TCP-IPV4/ TCP-IPV6 NETWORK PERFORMANCE A Thesis Presented to the Faculty of the Graduate School University of Missouri-Columbia In Partial Fulfillment of the Requirements for the Degree Master of Science by HARSHIL SHAH Dr. Gordon K. Springer, Thesis Advisor DECEMBER 2013 The undersigned, appointed by the Dean of the Graduate School, have examined the thesis entitled COMPARING TCP-IPV4/ TCP-IPV6 NETWORK PERFORMANCE Presented by Harshil Shah A candidate for the degree of Master of Science And hereby certify that in their opinion it is worthy of acceptance. Dr. Gordon K Springer Dr. Dmitry Korkin Dr. Justin Legarsky ACKNOWLEDGEMENTS I would like to acknowledge and thank, with gratitude, the following people who helped me throughout my studies and completion of my project. First and foremost, my debt of thanks to my advisor, Gordon K Springer. I would like to thank him for his expert guidance, tutelage and confidence. I would also like to thank him for his patience entrusted upon me to complete the project, while living hundreds of miles away, employed in full-time job. The project would not have been successful without his motivation. Secondly I would like to thank to my committee members for taking time from their busy schedules and contribute valuable insights. Lastly I would like to thank to my friends and my family for their support and collaboration in completion of this project. My honors and achievements are dedicated to all of these people. ii TABLE OF CONTENTS ACKNOWLEDGMENTS... ii LIST OF FIGURES... vi LIST OF TABLES... viii ABSTRACT... ix Chapter 1 Introduction... 1 Chapter 2 Internet Protocol Version Internet Protocol Layer (IP) IPv4 Shortcomings Internet Version 6 (IPv6) IPv6 Addressing IPv6 Extension Header Enhancement Over IPv IPv6 Quality of Service The Concept of Flow Traffic Class Transition Mechanisms to IPv Chapter 3 Network Performance Metrics and Measuring Techniques What Are Different Network Performance Metrics? What Are Different Types of Bandwidths? Capacity Available Bandwidth iii 3.2.3 TCP Throughput and Bulk Transfer Capacity (BTC) What Are Different Bandwidth Measurement Techniques? Chapter 4 Design and Implementation of A Middleware Application Middleware Application Design Considerations What are Sockets? Middleware Application Design Middleware Application Functions Client Server Communication Event Handling to Switch IP Protocol Chapter 5 Design and Implementation of Measurement Tool Design Considerations Bandwidth Measurement Capacity Measurement (Pathrate) Bulk Transfer Capacity Measurement Latency Measurement Chapter 6 Measurement Tool Output and Results Latency Measurement Output Bulk Transfer Capacity (BTC) Measurement Output Capacity Measurement Output Chapter 7 Conclusion Appendix A Internet Protocol Version 4 (IPv4) Appendix B Middleware Application Functions and Constants Appendix C Capacity Measurement Log File iv Bibliography Glossary v LIST OF FIGURES Figure 2.1: TCP/IP Architecture...7 Figure 2.2: OSI Network Architecture... 8 Figure 2.3: IPv6 Packet Figure 2.4: IPv6 Header Compared With IPv Figure 2.5: IPv6 Extension Headers...18 Figure 2.6: Lewis IPv6 Link Local Address Figure 2.7: IPv6 Encapsulation Figure 3.1: Pipe Model for Available Bandwidth Figure 3.2: Packet Pair Dispersion Figure 4.1: Client and Server Communication Using TCP/IP Figure 4.2: fn_socket() Flow Diagram Figure 4.3: Client Server Communication Figure 4.4: fn_send()/fn_write() Packet Structure Figure 5.2: Characteristics of Local Mode Figure 5.3: Histograms of Phase 1 and 2 Measurements Figure 5.4: Capacity Estimate Flow Diagram Figure 5.5: BTC Measurement Packet Figure 5.6: BTC Measurement Flow Diagram Figure 5.7: Latency Measurement Packet Figure 5.8: Latency Measurement Flow Diagram Figure 6.1: Web and Peregrine On Rnet vi Figure 6.2: netaware_snd Output on Web for IPv Figure 6.3: netaware_rcv Output on Peregrine for IPv Figure 6.4: IPv4 vs IPv6 - Time vs Latency (ms) Figure 6.5: IPv4 vs IPv6 Latency Measurements (ms) Figure 6.6: IPv4 vs IPv6 Latency Measurements - 5 Days (ms) Figure 6.7: netaware_snd BTC Output for IPv Figure 6.8: netaware_rcv BTC Output for IPv Figure 6.9: IPv4 vs IPv6 - Time vs BTC (Mbps) Figure 6.10: IPv4 vs IPv6 BTC Measurements (Mbps) Figure 6.11: IPv4 vs IPv6 BTC Measurements - 5 Days (Mbps) Figure 6.12: netaware_snd Capacity Output for IPv6 (Mbps) Figure 6.13: netaware_rcv Capacity Output for IPv6 (Mbps) Figure 6.14: Phase 1 Local Capacity Modes -IPv6 (Mbps) Figure A.1: IPv4 Header Figure A.2: IPv4 Address Classes vii LIST OF TABLES Table 2.1: IPv4-IPv6 Comparison Table 2.2: IPv6 Extension Headers...18 Table 2.3: Traffic Class Field Values Table 4.1: Socket API System Calls Table 4.2: Middleware Application Functions Table 4.3: Signal Values and Action Table 6.1: netaware_snd Options Table 6.2: netaware_rcv Options Table 6.3: IPv4 vs IPv6 Latency Measurements (ms) Table 6.4: IPv4 vs IPv6 Latency Measurements - 5 Days (ms) Table 6.5: IPv4 vs IPv6 BTC Measurements (Mbps) Table 6.6: IPv4 vs IPv6 BTC Measurements (Mbps) - 5 Days (ms) Table 6.7: IPv4 vs IPv6 Capacity Estimation (Mbps) Table A.1: IPv4 Class Range viii ABSTRACT The Internet Protocol version 4 (IPv4) has been the backbone of the Internet since its inception. The growth and success of the Internet has accelerated the consumption of the IPv4 address space and hence its exhaustion is predicted very soon. Despite the use of multiple hidden and private networks to keep things going, a newer version of the protocol, Internet Protocol version 6 (IPv6), is proposed to solve this issue along with many other improvements as part of a better, newer design. For smoother transition and given the decentralized nature of the Internet, both of the protocol stacks, namely IPv4 and IPv6, are expected to be supported by the hosts and hence co-exist for a period of time. Many application programs, especially those involved in large data transfers, currently use the TCP/IP protocol suite. However, there have not been many attempts to leverage the existence of both Internet Protocol versions over a TCP connection. This thesis, through a prototype, is an attempt to improve the network utilization by using either an IPv4 or an IPv6 protocol for a TCP connection based on end-to-end measured performance between two hosts. A measurement tool, named netaware, is developed as part of this thesis to measure the end-to-end network performance for both IPv4 and IPv6 protocols within a single tool. The tool measures two performance parameters, namely the bandwidth and the latency in a multi-threaded environment. The tool utilizes a simple middleware application, also built as part of this thesis, to create and use ix socket connections for interprocess communication across the network between the two hosts. The middleware application is used as an intermediate level application to take care of creating IPv4 or IPv6 connections between the hosts, needed to transmit measurement and control data while measuring the performance parameters. The use of middleware application facilitates the construction of network applications by having an application developer to deal with minimal code to use either IP protocol. The network application may be a file transfer application or any other network application. The middleware application also provides the capability for TCP applications to switch between IPv4 and IPv6 network protocols on the fly, without impacting the application s functionality. The input values for the parameters of the middleware application functions internally control the IP protocol to operate on and the switching technique for an application program. The aim is to enhance the network utilization by having an option of switching between the two IP protocols in order to provide better performance at some point of time. The prototype measurement tool measures the network performance to help decide on the preferred protocol. The preferred protocol can then be used to notify the application program using the middleware application to switch to the preferred protocol while in execution. The combination of the measurement tool to measure the performance for both IP protocols within a single tool and the middleware application s ability to switch between the IP protocols at any point of time, based on measured performance, can help provide better network utilization. x Chapter 1 Introduction In today s information age, data is accessed through various forms of media, be it a paper based newspaper or a digitally stored book. The use of data through various sources has grown exponentially, especially during last decade. These sources can be broadly classified as either digital or non-digital sources. The Internet can undoubtedly be termed as a major contributor to the growth as well as use of digital data. The backbone of the Internet can be attributed to the Internet Protocol version 4 (IPv4) and its success. IPv4 has been in existence for more than fifty years. Due to exponential increase in the number of devices interconnected worldwide, the exhaustion of the remaining pool of IPv4 addresses is predicted soon. The Internet Assigned Numbers Authority (IANA) recently assigned the last block of IPv4 addresses on February 3 rd 2011 [1]. The Internet Protocol version 6 (IPv6) with an extended address space is proposed to meet this addressing shortage. This new version is not a simple derivative of IPv4, but an improvement over the previous version, while keeping many of the characteristics of the IPv4 protocol. IPv6 is designed to have many additional features such as optional IP headers, class and flow labels, jumbo datagrams and fragmentation-less data transfer to name a few [4] [5]. Thus, the aim is to replace the older version of the IPv4 protocol, to meet the increasing demand for IP addresses and also to use the new features offered by the new version. 1 However, due to the vast success and wide spread use of the World Wide Web, the monetary cost and time involved, the transition, to IPv6 is occurring gradually as opposed to a sudden conversion. The two protocol stacks are expected to coexist for an extended period of time and to be supported by almost every host. Although, the past few years have witnessed a global scale deployment of IPv6 networks among IPv4 networks especially in Europe and the United States. This support for both the protocols means, a host can be reached by both the stacks, IPv4 and IPv6. Both of the network stacks may or may not follow the same network paths based on the underlying network infrastructure. Even though IPv6 nodes have increased in recent years, there has not been a corresponding increase in applications using or switching to the IPv6 protocol. With relatively light traffic load on IPv6 and abundant IPv6 backbone bandwidth, there is a high probability of greater IPv6 Bandwidth availability than IPv4 [2]. Additionally, there are still large IPv6-over-IPv4 tunnels widely in use where native IPv6 connectivity is not available [3]. In any public service network, a continuous performance improvement and the offering of a better Quality of Service (QoS) to an end user has always been a key challenge. At any given point of time, the performance over a particular network path with the same underlying infrastructure is not constant. The presence of cross traffic from a wide range of digital sources adds to the dynamics of the changing traffic patterns, especially when the data is bursty in nature. Hence, the QoS offered to an application by either IP protocol, the network path utilization can vary over a given period of time. Thus we have a 2 choice between IPv4 and IPv6 network protocol that an application could choose. This may help to gain better performance and network utilization at a given point of time based on QoS offered. Many transport layer protocols, namely the Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Stream Control Transmission Protocol (SCTP) rely on the Internet Protocol IP as its underlying network layer protocol. Of the above mentioned transport layer protocols, TCP is most widely used protocol. Many application layer protocols like the HTTP, BGP, FTP and SMTP depend on TCP due to its rich collection of features like congestion control, reliable data transfer, and reordering of data packets for sequential transfer [35]. TCP is a connection-oriented protocol. A connection is established between two hosts prior to transmitting the application data, and each data packet travels over the same network path. Thus for TCP, choosing between IPv4 and IPv6 as its underlying IP protocol can drastically change how an application performs. This thesis focuses on helping to choose between the IPv4 and IPv6 protocol for a better performance and network utilization for an application at a given point of time. A simple prototype middleware software foundation is built, which not only helps in developing applications to use either IPv4 or IPv6 protocol with ease but also provides a switching capability between either IP protocols, on the fly without impacting the application s functionality. A demonstration application is built to demonstrate its usefulness and its capability to switch between either the IPv4 or IPv6 protocol. The same middleware 3 foundation/application is also used to construct a measurement tool named netaware, to measure end to end performance parameters for both the IPv4 and IPv6 protocols within a single tool. The parameters measured include bandwidth and latency, but can be further extended to measure other performance parameters like packet loss and CPU utilization. This is done in a multi-threaded environment utilizing algorithms explained briefly in subsequent chapters. Here the aim is to provide an option to use either Internet protocol version to enhance the network utilization and leverage the existence of dual protocol stacks for better performance. With the combined use of the middleware application and the measurement tool, an application can choose to use either IP protocol by doing one time performance measurement using the measurement tool or choose to switch to either protocol version while in execution. This application can be a simple file transfer application or a distributed application involving large data transfers. This thesis is organized into seven chapters. In the next chapter, a detailed description of the IPv4 shortcomings, the IPv6 protocol and its enhancement is provided. This chapter helps the reader understand how an application built using the IPv6 protocol may benefit utilizing its rich new features. It also discusses the current transition mechanism from IPv4 to IPv6. For brief descriptions of IPv4 headers and addressing mechanism, refer to Appendix A. Chapter 3 outlines different types of performance parameters, also known as metrics, and different types of bandwidths. It also provides details on the basics of two of the measurement techniques implemented in the measurement tool 4 netaware built as part of this thesis. Chapter 4 and 5 provides a detailed description of the design and implementation of the middleware application and measurement tool built respectively. These chapters also detail the algorithms used to measure different types of bandwidths and latency. Chapter 6 discusses the measurement performed for both IPv6 and IPv4 protocols between two hosts on the Research Network (Rnet) at the University of Missouri to demonstrate the utility of the measurement tool. Chapter 7 concludes the thesis by summarizing the work done as part of this thesis. It also discusses potential enhancements and future expansion of the middleware application and the measurement tool. 5 Chapter 2 Internet Protocol Version 6 The next generation protocol, Internet Protocol version 6 (IPv6), is designed to overcome some of the limitations of its predecessor IPv4. IPv6 has many useful features added as an enhancement over the existing architecture, based on years of experience with IPv4, to offer better services, but at the same time retain the benefits of the earlier version. An application using these features over an IPv6 protocol may provide better performance in terms of bandwidth and latency as opposed to the performance when using an IPv4 protocol, over the same network path or different network paths followed. In order to leverage the benefits of IPv6, the present connectivity and support for the IPv6 protocol between the communicating hosts (client and server) also plays a significant role. Different transition mechanisms from IPv4 to IPv6 are outlined in Section 2.8. Given the nature of the application and present network conditions for IPv6 support, it can be crucial as well as beneficial to choose an IP protocol that offers better QoS that suits an application. This QoS can be in terms of connectivity, bandwidth offered, latency or a combination of all these factors. This Chapter starts by describing the basics of the Internet Protocol layer. Citing some of the shortcomings of the IPv4 protocol follows the initial descriptions. The discussion then moves on to describing the IPv6 protocol. 6 2.1 Internet Protocol Layer (IP) The Internet architecture evolved out of experiences with an earlier packetswitched network called the ARPANET. It is also called the TCP/IP architecture due to the extensive use of both, TCP and IP in a large number of applications. The hierarchical layer of this architecture is as shown in Figure 2.1. This is in contrast to Figure 2.2 that shows the traditional Open Systems Interconnection (OSI) architecture. As seen from Figure 2.1, the IP (Network Layer or Layer 3) serves as the focal point. A common protocol of exchanging the packets among the networks forms what looks like an hourglass. [4]. The IP layer can be termed as the pivotal protocol of the TCP/IP protocol suite as all the Transport (Layer 4) protocols namely TCP, UDP, SCTP to name a few, data gets transmitted as IP datagrams. IP, by itself offers a connectionless and potentially unreliable service. Figure 2.1: TCP/IP Architecture [4] 7 Source Host Destination Host Figure 2.2: OSI Network Architecture [4] The connectionless oriented service offered by IP is due to the fact that there is no logical connection or advance setup between the communicating hosts. Every datagram contains enough information to be correctly delivered to the destination. Neither the source nor the destination maintains any state information about any packet received from the upper layers. Each datagram is treated as a separate entity and handled separately from all other datagrams. Thus, a datagram may be delivered out of sequence or even multiple times or not at all. IP offers unreliable service, as it does not guarantee that an IP datagram reaches its destination successfully. It also is called a best effort service. The 8 best effort means, if a datagram is lost, mis-delivered or corrupted, the network does nothing. It simply drops the datagram, but may send an ICMP message back to the source. That is all it can do. The network simply made a best effort attempt to deliver the datagram. The layers above IP are supposed to handle any required reliability by providing the feedback in the form of acknowledgments to the sending host (example TCP). The philosophy behind this IP service model is to make it undemanding enough so that any network protocol or technologies built on top of the IP layer would be able to provide the necessary services [8]. 2.2 IPv4 Shortcomings The IPv4 protocol has served as the Internet backbone and has been quite robust and resilient for many years. The IPv4 protocol was designed in an early period of the Internet development when worldwide proliferation of Internet use was not anticipated. For many years, the architects and designers believed in the principle, If it ain t broke, don t fix it. However, in the late 1980 s it became apparent tha
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks