If you look at the many fields in a typical IP packet, you might hesitate when you see there are several error check fields. In the Ethernet part of the packet we find a Frame Check Sequence at the end of the data frame, and in the IP header we find a checksum. Further into the packet, where the TCP or UDP header is located, we see another checksum field. Why so many checks on whether an error has occurred? And, what purpose is the purpose of each of these checks? Isn’t it the practice that if there is an error, the frame or packet will be dropped?
Figure 1: Error Codes in Ethernet/IP Packets
Well, the answer to the last question is that in most situations the packet will indeed be dropped. But the purpose of each error code is different because each is used by different processes in the network or in the destination station. Let’s look at each of these separately. First, the Frame Check Sequence (FCS) in the Ethernet portion of the packet is calculated by the sending network interface card (NIC). It’s checked again after reaching the first router or the destination station NIC. If the FCS it is errored—meaning the frame was corrupted—the frame will be discarded by that NIC. This is a check on the entire data frame and all that it contains. (For clarity, the more accurate term is “erred,” but here we’ll use the familiar term “errored.”)
Suppose the frame is correctly received by the router or destination and has no errors. It will be read and handed to the IP process for routing in the router or for further processing in the destination station. The Ethernet information has been discarded. Now, the focus is on what IP needs to do. So, IP uses the checksum field to make sure the IP header has no errors. It could have been the case that the Ethernet frame had an error, but the error was not in the IP header. If the IP checksum is the correct value, the IP header is rewritten with a lower hop count value and a new checksum is calculated and is inserted. It is interesting that the IP checksum validates only the integrity of the header, but not any of the data. This task is another layer’s responsibility. If the checksum is valid, the router will route the packet. If the check is made in the destination station, the IP packet will be handed up to the layer four process, TCP or UDP.
Finally, in the layer four header we will find another checksum. If layer four is TCP, the checksum will only be used by the destination station. However, this error check will be on the entire TCP portion of the packet including the application data. If an error is found, the TCP segment will not be acknowledged. It will eventually be retransmitted. If layer four is UDP, the checksum only pertains to the header, not the data. If this code is not valid, the UDP segment will be dropped and the response must be mitigated by the application code. This difference in the reactions in layer four explains, in part, why DASH video rarely shows tiling while IPTV will exhibit tiling in the presence of such errors.
