Part 4 - Data Checks

In the previous sections of this lab, you have already looked at one problem that may corrupt data on the Internet or other networks, packet loss. However, this is relatively rare and is easily handled as with TCP handshaking to establish a connection and request replacements for missing packets. Except in rare cases, an issue only arises if there is a bad connection with packet loss of 5% or more.

Another issue that can arise is corruption of the data within the packet. With data communicated in bits of 0 or 1, even one packet contains up to half a million bits. Even if only one in a billion bits has an error, this still means that about one out of every thousand packets will have an error.

Bit errors like these are impossible to catch without an extra data check. Both IP and TCP implement a data check process called checksum in order to catch errors. IP checks only the header and is focused on making sure this information that is crucial to directing the packet is correct. TCP checks the data carried in the packet, and if a problem is identified, a request for a new copy of the packet is sent just like if the packet was missing.

Checksums are relatively simple. Consider a set of data consisting of 31 bits. The data might be 1001011101101001111001110000101. A checksum just counts the number of 1s. Here, that would be a checksum value of 17 or 10001 in binary. If one bit is corrupted in the data like 1001011101101001111001110000001 then there are only 16 1s rather than 17; so, the checksum does not match, and a problem is identified.

4A) A 31-bit message received is 0010011110010110101000111011000. The checksum received is 10000. How many 1s are in the message received? What is the decimal value of the checksum? Does the checksum identify a problem?

4B) A 31-bit message received is 1001001110101010111001010000110. The checksum received is 01111. How many 1s are in the message received? What is the decimal value of the checksum? Does the checksum identify a problem?

4C) A 31-bit message received is 0000000010001000011001000000001. The checksum received is 00110. How many 1s are in the message received? What is the decimal value of the checksum? Does the checksum identify a problem? Explain how you know.

The checksum calculations for the IP header or for the data with TCP include some additional mathematics designed to reduce the size of the checksum value, but the end result of identifying bit errors is the same as these examples.

Checksum identifies errors, but it cannot correct them. When an error is identified, there is no way to tell from the checksum at which bit the error occurred. Instead, the solution is to ask the server to resend the information. An alternative to this is a process called lockstep where multiple copies of the message are sent and compared. If three copies are sent, triple modular redundancy, then even when an error occurs, the two that agree can be assumed to be correct.

4D) Why is checksum the preferred form of error checking even though lockstep techniques could specifically identify and correct the error?