Question

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 1’s. 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 1’s 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 1’s 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 1’s 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 1’s 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?

Answer 1

4A. There are 15 1's in the received message. The decimal value of the checksum is 16. Yes in this case the checksum identified the problem of the data corruption since the number of 1's in the received message doesn't match with the checksum vaue.

4B. There are 15 1's in the message received and the decimal value of the cheksum is 16. In this case it seems like there is no data corruption in the received message since both the values are same.

4C. There are 6 1's in the message received and the decimal value of the cheksum is 6. In this case it seems like there is no data corruption in the received message since both the values are same.

4B. Lockstep technique needs more data needs to be sent when compared to checksum. For example for triple modular redundancy we need to send three times more data