Often we discuss errored packets that are dropped without understanding the underlying techniques that determine why the packets are discarded. There are checks for errors at several protocol layers. As a result, packets are checked for problems at several points in the network and also at various levels when they are received at the destination.
The first examination that is made on nearly all packets is at layer two. It is called the frame check sequence (FCS). Each Ethernet frame has a four-byte field appended to the end of the frame that is the result of a calculation done by the sender. The input to the calculation is comprised of all the fields in the frame. Each switch, router, and end station recalculates the FCS. If the result is different from the one recorded in the frame, the frame is dropped. If just one bit has been corrupted, the likelihood the value matches the receiver’s calculated result is considerably below one in a billion. An assumption in the process is that a higher layer will deal with the issue of retransmissions.
Related: Byte-Sized Lesson: What Causes Latency?
The IP field also contains an error check code called the checksum. This value is calculated by using all the fields in the IP header. However, unlike with Ethernet, the data is not included in the calculation. IP is not responsible for detecting corrupt payload data. Since the calculation uses the hop count field, which changes with each router, the IP checksum changes each time the packet is routed. The next router will discard the packet if the code in the header does not match the checksum it computes.
The layer-four protocols, TCP and UDP, have different ways for dealing with errors in packets. At the destination, TCP does a calculation that is based on the TCP header, the payload data, and critical fields in the IP header. (These fields are sometimes referred to the IP pseudo-header.) Nevertheless, if the calculation does not match the values stored in the checksum field, TCP simply discards the packet. Contrary to popular belief, TCP does not explicitly inform the sender of this discard. It just doesn’t acknowledge receipt of the segment. Because of the sequencing of the segments, the sender will eventually realize that the segment was not properly received and it will be retransmitted.
Related: Byte-Sized Lesson: Network Buffers
UDP does not make provision for retransmission, but it does perform an error check. UDP does not want to pass a segment of data up to the application layer if there is an error in its header. This is especially important because that header contains the port that properly identifies the correct receiving application.
When error checking of the payload data is not included, the receiver gets invalid data. This can become evident in VoIP, especially if compression is being used: the user may hear distortion of the sound. On the contrary, in adaptive bitrate video such as Apple’s HLS, TCP is being used. Corrupted data will be retransmitted before it is played. Therefore, although delay might increase, the video should play out correctly.
Phil Hippenstel, EdD, is a regular columnist with AV Technology. He teaches information systems at Penn State Harrisburg.
