Why bits go wrong, and why we must notice
From the physical-layer rung you already know the unhappy truth: the medium is analog and noisy, and every now and then the receiver mistakes a sent 1 for a 0, or the reverse. How often this happens is captured by the bit error rate — say, one flipped bit in every ten million. That sounds tiny, until you remember a single web page might be tens of millions of bits. A flip you never notice can turn a bank balance, a pixel, or a line of code into quiet nonsense.
The data link layer sits right above the wire, so it is the first place that can do something about this. In guide 1 you learned how it wraps the bits into a frame with clear boundaries. The natural next question is: once I have a frame, how do I know whether it survived the trip intact? The whole point of error detection is to let the receiver answer that question without ever seeing the original.
The trick is to send a little extra alongside the data: a short summary computed from the bits, sent in the frame's trailer. The sender computes the summary, the receiver recomputes it from the bits it actually received, and the two are compared. If they disagree, something changed in flight. This extra is called redundancy — it carries no new information, only a way to check the information you already have.
Parity: one bit that catches one flip
The simplest detector adds a single extra bit, the parity bit. Pick a rule — say, even parity — and set the extra bit so that the total number of 1s, counting the parity bit itself, is always even. To send 1011001, count the 1s: there are four, already even, so the parity bit is 0 and you send 10110010. If instead the data were 1011000 (three 1s, odd), the parity bit would be 1, giving 10110001. The receiver simply counts the 1s in everything it got and checks they are even.
Now suppose one bit flips on the way. The count of 1s changes by exactly one, so an even total becomes odd, and the receiver instantly knows the frame is damaged. Beautifully simple — but watch the crack: if two bits flip, the count changes by two and stays even, so the error sails through undetected. Single-bit parity catches any odd number of flips and is blind to any even number. It is the cheapest possible check, and also the weakest.
You can do better by arranging the bits in a grid and adding parity to every row and every column — two-dimensional parity. A single flip now breaks exactly one row check and one column check, and their intersection pinpoints the guilty bit, so you can even repair it. That hop from detecting to locating is the seed of error correction, which we meet at the end. But two-dimensional parity is still fooled by certain clusters of flips, so for real links we want something far stronger.
Checksums: add it all up
A checksum takes a different angle. Instead of counting 1s, it treats the data as a list of numbers and adds them up, then sends the sum (or a tidied-up version of it) alongside. The Internet checksum used in IP, TCP, and UDP, for example, chops the data into 16-bit words, sums them with a special end-around carry, and sends the inverted total. The receiver adds up everything including the checksum; if nothing changed, the result is a known fixed pattern of all 1s.
A checksum is stronger than a single parity bit because every data bit contributes to the sum in a way that ripples through the carries. But it has well-known blind spots: because addition does not care about order, swapping two words leaves the sum unchanged, and certain pairs of flips can cancel each other out. The Internet checksum was chosen for being fast and easy to compute in software on slow 1970s machines, not for being the strongest detector — an honest engineering trade-off, not the best math available.
The CRC: dividing by a magic number
The workhorse of nearly every real link — Ethernet, Wi-Fi, disk drives — is the cyclic redundancy check, or CRC. The idea is wonderfully concrete: treat the whole frame of bits as one enormous binary number, then divide it by a fixed, agreed-upon number called the generator polynomial. We do not keep the quotient; we keep the remainder. That remainder is the CRC, and it gets appended to the frame.
Here is the elegant part. The sender first tacks on some zero bits, divides, and replaces those zeros with the remainder it found. Now the whole frame-plus-CRC is exactly divisible by the generator, with no remainder. The receiver does just one thing: divide the bits it received by the same generator. If the remainder is zero, the frame is almost certainly clean; if it is anything but zero, an error is shouting at you. The receiver never needs to know the original — the zero remainder is the proof.
SENDER RECEIVER data: 1 1 0 1 0 1 1 received: 1101011 . 100 generator: 1 0 0 1 (degree 3) divide by 1001 append 3 zeros -> 1101011000 remainder = 000 -> OK divide by 1001 (XOR, no borrows) remainder -> 1 0 0 but if a bit flipped: send: 1101011 . 100 (data + CRC) remainder != 000 -> DROP
Why is the CRC so much better than a checksum? Because this is not ordinary arithmetic — the division uses bitwise XOR with no carries, which behaves like algebra over polynomials, and mathematicians have hand-picked generators with provable powers. A good standard generator is guaranteed to catch every single-bit and double-bit error, every odd number of errors, and any burst of flipped bits shorter than the CRC itself — exactly the clustered noise that real wires produce. It is fast in hardware too: a few shift registers and XOR gates clock through a frame at line speed.
Detecting is not fixing: a word on correction
Everything so far only detects. When a CRC fails, the frame is dropped, and something higher up must arrange for it to be sent again. That retry machinery is Automatic Repeat reQuest, the subject of the very next guide, where a sender resends anything the receiver could not confirm. Detection plus retransmission is the dominant recipe on the wired Internet, because resending is cheap when the link is fast and rarely wrong.
Sometimes resending is too slow or impossible — a deep-space probe, a live radio stream, a scratched disk you cannot ask again. There the receiver must repair the data on its own, using forward error correction. The price is more redundancy: instead of a tiny CRC, you send extra bits carefully arranged so that the most likely error patterns can be reversed. A Hamming code is the classic teaching example — by overlapping several parity checks, it not only detects a single flipped bit but names exactly which bit flipped, so the receiver can turn it back.
So there is a genuine trade-off, not a clear winner. Detection is cheap but needs a way to retry; correction needs no return trip but pays in bandwidth all the time, even when nothing is wrong. Real systems mix them: Wi-Fi and cellular lean on forward error correction because their links are noisy and round trips are slow, while a quiet fiber inside a data center is happy with a CRC and an occasional resend. The right choice always depends on how noisy the link is and how expensive it is to ask again.