Why is error control (reliability) required at the transport layer even when lower layers exist?

Introduction / Context:
Transport-layer reliability (e.g., in TCP) provides end-to-end error control beyond what data link and physical layers can guarantee. The network core may reorder, drop, or duplicate packets; only the endpoints can fully detect and correct such end-to-end faults across multiple hops.

Given Data / Assumptions:

• Multi-hop packet-switched networks are used.
• Lower layers reduce but do not eliminate errors, losses, or reordering.
• Applications expect ordered, reliable byte streams for many use cases.

Concept / Approach:
End-to-end reliability adds sequence numbers, acknowledgments, retransmissions, and reassembly at the transport layer. This counters drops/duplicates that can occur in queues, during congestion, or due to transient faults that lower layers cannot address across the entire path.

Step-by-Step Solution:

Verification / Alternative check:
Observe TCP traces: gaps in sequence numbers and resulting retransmissions confirm end-to-end error control responding to network loss, not just physical noise in one link.

Why Other Options Are Wrong:

• Physical noise is often corrected with link-layer checks/retries; transport still needed for multi-hop path issues.
• Routers do not “routinely corrupt” packets; corruption is rare and checked by link and transport checksums.
• Applications do not control network packet order; transport ensures in-order delivery to apps.
• Password encryption is a security concern, not error control.

Common Pitfalls:
Assuming link-layer ARQ eliminates all losses end-to-end; conflating error control with security; believing reordering equals “error” rather than a normal network behavior that transport must handle.

Final Answer:
Because packets can be lost or duplicated within the network, requiring end-to-end recovery