HARDWARE INSTRUCTION BASED CRC32C, A BETTER ALTERNATIVE TO THE TCP ONE’S COMPLEMENT CHECKSUM

End-to-end data integrity is of utmost importance when sending data through a communication network, and a common way to ensure this is by appending a few bits for error detection (e.g., a checksum or cyclic redundancy check) to the data sent. Data can be corrupted at the sending or receiving hosts, in one of the intermediate systems (e.g., routers and switches), in the network interface card, or on the transmission link. The Internet’s Transmission Control Protocol (TCP) uses a 16-bit one’s complement checksum for end-to-end error detection of each TCP segment [1]. The TCP protocol specification dates back to the 1970s, and better error detection alternatives exist (e.g., Fletcher checksum, Adler checksum, Cyclic Redundancy Check (CRC)) that provide higher error detection efficiency; nevertheless, the one’s complement checksum is still in use today as part of the TCP standard. The TCP checksum has low computational complexity when compared to software implementations of the other algorithms. Some of the original reasons for selecting the 16-bit one’s complement checksum are its simple calculation, and the property that its computation on big- and little-endian machines result in the same checksum but byte-swapped. This latter characteristic is not true for a two’s complement checksum. A negative characteristic of one’s and two’s complement checksums is that changing the order of the data does not affect the checksum. In [2], the authors collected two years of data and concluded after analysis that the TCP checksum “will fail to detect errors for roughly one in 16 million to 10 billion packets.” While some of the sources responsible for TCP checksum errors have decreased in the nearly 20 years since this study was published (e.g., the ACK-of-FIN TCP software bug), it is not clear what we would find if the study were repeated. It would also be difficult to repeat this study today because of privacy concerns. The advent of hardware CRC32C instructions on Intel x86 and ARM CPUs offers the promise of significantly improved error detection (probability of undetected errors proportional to 2 -32 versus 2-16) at a comparable CPU time to the one’s complement checksum. The goal of this research is to compare the execution time of the following error detection algorithms: CRC32C (using generator polynomial 0x1EDC6F41), Adler checksum, Fletcher check sum, and one’s complement checksum using both software and special hardware instructions. For CRC32C, the software implementations tested were bit-wise, nibble-wise, byte-wise, slicing-by-4 and slicing-by-8 algorithms. Intel’s CRC32 and PCLMULQDQ instructions and ARM’s CRC32C instruction were also used as part of testing hardware instruction implementations. A comparative study of all these algorithms on Intel Core i3-2330M shows that the CRC32C hardware instruction implementation is approximately 38% faster than the 16-bit TCP one’s complement checksum at 1500 bytes, and the 16-bit TCP one’s complement checksum is roughly 11% faster than the hardware instruction based CRC32C at 64 bytes. On the ARM Cortex-A53, the hardware CRC32C algorithm is approximately 20% faster than the 16-bit TCP one’s complement checksum at 64 bytes, and the 16-bit TCP one’s complement checksum is roughly 13% faster than the hardware instruction based CRC32C at 1500 bytes. Because the hardware CRC32C instruction is commonly available on most Intel processors and a growing number of ARM processors these days, we argue that it is time to reconsider adding a TCP Option to use hardware CRC32C. The primary impediments to replacing the TCP one’s complement checksum with CRC32C are Network Address Translation (NAT) and TCP checksum offload. NAT requires the recalculation of the TCP checksum in the NAT device because the IPv4 address, and possibly the TCP port number change, when packets move through a NAT device. These NAT devices are able to compute the new checksum incrementally due to the properties of the one’s complement checksum. The eventual transition to IPv6 will hopefully eliminate the need for NAT. Most Ethernet Network Interface Cards (NIC) support TCP checksum offload, where the TCP checksum is computed in the NIC rather than on the host CPU. There is a risk of undetected errors with this approach since the error detection is no longer end-to-end; nevertheless, it is the default configuration in many operating systems including Windows 10 [3] and MacOS. CRC32C has been implemented in some NICs to support the iSCSI protocol, so it is possible that TCP CRC32C offload could be supported in the future. In the near term, our proposal is to include a TCP Option for CRC32C in addition to the one’s complement checksum for higher reliability

Unicast UDP Usage Guidelines for Application Designers

Publisher PD

Information Technology and Computer Science

Abstract-Error and error related issues have been a challenge in the development and reliable usage of computing systems and application. The ability to detect minute error in a system improves the reliability of the system by aiding developers and users to know were challenges are so that they can be fixed during development and even when the system is already in use. In other to achieve that different algorithm have been used including the Cyclic Redundancy Check 16-bit, 32-bit and higher bits. In this paper, error detection schemes are examined and the way they check and detect error in multi-user request and transmitted system. The paper also offers improvement on a Cyclic Redundancy Checks 32-bit detection algorithm for the detection of error that can occur in transmitted data and on stored, backed-up and archived data in the system without consuming large resources as the higher bits.

Implicit Simulations using Messaging Protocols

A novel algorithm for performing parallel, distributed computer simulations on the Internet using IP control messages is introduced. The algorithm employs carefully constructed ICMP packets which enable the required computations to be completed as part of the standard IP communication protocol. After providing a detailed description of the algorithm, experimental applications in the areas of stochastic neural networks and deterministic cellular automata are discussed. As an example of the algorithms potential power, a simulation of a deterministic cellular automaton involving 10^5 Internet connected devices was performed.Comment: 14 pages, 3 figure

A 60 GHz Wireless Network for Enabling Uncompressed Video Communication

Uncompressed high-definition video streaming over wireless personal area networks is a challenging problem because of the high data rate requirement and channel variations. With the advances in RF technology and the huge bandwidth available worldwide in the 57–66 GHz millimeter-wave unlicensed spectrum, mmWave WPANs that can support multigigabit transmission are being developed. However, compared to low-frequency signals (2.4 or 5 GHz), mmWave signals are more fragile; indeed, the propagation losses are significantly higher. In this article we present an mmWave system for supporting uncompressed HD video up to 3 Gb/s. The system includes various efficient error protection and concealment schemes that exploit unequal error resilience properties of uncompressed video. Some of them have been adopted in the emerging 60 GHz WPAN standards such as WirelessHD, ECMA TC48, and IEEE 802.15.3c. Simulations using real uncompressed HD images indicate that the proposed mmWave system can maintain, under poor channel conditions, good average peak-signal-to-noise-ratio and low video quality metric scores