Transport-Layer Error Control Despite Data-Link Error Control: Why “Multiple Times” Is Necessary

Even if the data link layer performs error detection and sometimes error recovery, transport-layer reliability is still needed because end-to-end communication differs fundamentally from hop-by-hop communication. The core motivation is the end-to-end principle: placing reliability mechanisms only at lower layers does not guarantee correctness for the entire path, especially when failures can occur between link-layer segments, in routers, or due to congestion-driven loss.

Key ideas you should internalize:

• keyword: Reliability should be implemented at the endpoints because lower layers can’t guarantee end-to-end correctness.
• keyword: Each link segment is handled independently; success on one hop doesn’t imply success over the whole route.
• keyword: The receiver at the destination must reliably get the correct data bytes in order (or the sender must be informed).
• keyword: Retransmission protocol used to recover from loss/corruption detected by acknowledgments and sequence numbers.

A transport protocol (e.g., TCP) provides end-to-end error control using sequence numbers, checksums, acknowledgments, and retransmissions—because link-layer mechanisms are not designed to survive all forms of failure that affect an application’s data stream.

Mermaid view of “why repeated effort” happens in a multi-hop path:

Why Data-Link Error Control Is Not Enough End-to-End

Data-link protocols typically operate per link (per hop). Even when they use error recovery (e.g., link-layer ARQ), their scope is limited to that specific physical/data-link segment. Transport-layer error control addresses failures that can occur despite successful delivery on each individual hop.

1) Scope mismatch: hop-by-hop reliability ≠ end-to-end reliability

If hop-by-hop protocols retransmit until each link frame is correct, that reduces corruption on that link, but the overall path still includes:

• multiple independent links
• routing and buffering in intermediate nodes
• transport-layer segmentation/assembly
• potential packet drops due to queue overflow

A frame’s correctness on hop $i$ does not imply that the corresponding end-to-end byte stream arrives unmodified on the destination. Transport reliability covers the entire route using end-to-end acknowledgments.

2) Packet loss is often caused by congestion and buffering, not just link bit errors

Many real networks drop packets due to:

• buffer overflow
• congestion management
• scheduling and queue limits

These losses can happen in routers, and the link layer usually cannot know which higher-layer “data unit” was lost (because transport segmentation, ordering, and semantics are at/above the transport layer).

So even if the data link layer corrects typical bit errors, loss events still happen, and the transport layer must recover the missing data.

3) Corruption that survives link layers and mapping to transport data can’t be ignored

Even with CRC-like detection, errors can still slip through due to:

• hardware/implementation faults
• rare corner cases
• configuration differences across links

Transport checksums and sequence numbers act as a second line of defense, but more importantly they provide ordering and completeness of the reassembled transport stream.

4) Reordering across hops requires end-to-end sequencing

Transport protocols enforce correct ordering using sequence numbers. Hop-by-hop delivery does not guarantee that the receiver sees segments in the correct order for a transport stream, especially with:

• variable propagation and transmission delays
• retransmissions on some hops but not others
• different per-link timing behavior

5) Endpoints need a common abstraction for applications

Applications want a reliable stream (or at least reliable delivery semantics and feedback). Transport provides a uniform service abstraction regardless of the heterogeneous link technologies underneath.

Why retransmission is “multiple times” (and why that’s still okay)

It can feel wasteful to correct errors at multiple layers. But the retries are not redundant in the strict sense, because:

1. Different failure modes
   Link layer mainly targets bit/frame errors on a local segment. Transport targets end-to-end loss, missing segments, and reordering across the entire path.

2. Different observability
   The link layer does not (and should not) know which higher-layer segment corresponds to a lost/reordered packet. Transport layer has that mapping (sequence numbers over the stream).

3. Different correctness criteria
   Link layer correctness often means “frame received without detected corruption.”
   Transport correctness means “the receiving application obtains the intended sequence of bytes, without gaps and in order.”

Thus, the “multiple times” approach is a consequence of layered design: each layer provides the best possible guarantees within its scope.

Conceptual Comparison Table

Key Takeaways (Learning Checklist)

• keyword: Guarantees that the destination application receives correct, complete data despite intermediate failures.
• keyword: Guarantees limited to individual link segments; does not cover the whole route.
• keyword: Transport identifiers used to detect loss and enforce ordering.
• keyword: Feedback that lets sender infer what arrived and what is missing.
• keyword: Packet drops caused by queue limits in routers, largely outside link-layer error correction scope.