Reliable Data Transfer and TCP

🧭

On this page — click any heading below to jump straight to it. ⬅️ Back to P-II.II. Computer Communications & Networks

---

OSI Layer: Transport Layer (L4)

Definition

Reliable data transfer (rdt) is the general problem of delivering data correctly, in order, and exactly once over a channel that may corrupt or lose data — solved in practice at the transport layer by TCP, which layers sequence numbers, acknowledgments, timers, and retransmission on top of IP's unreliable, best-effort delivery.

Building Blocks of Reliable Data Transfer (the rdt protocol family)

Networking theory develops reliability in stages, each fixing one weakness of the channel below it — this progression is exactly how TCP's mechanisms should be justified in an exam answer:

• rdt1.0 — assumes a perfectly reliable channel (no loss, no errors); no error control needed at all. Unrealistic, but the starting baseline.
• rdt2.0 — channel can flip bits (corruption) but not lose packets. Adds checksums to detect corruption and ACK/NAK feedback so the sender knows to retransmit.
• rdt2.1 / 2.2 — fixes the ambiguity of a corrupted ACK/NAK itself by adding sequence numbers (0/1) to packets, so a duplicate can be recognised and discarded; rdt2.2 removes NAKs entirely, using only ACKs with sequence numbers.
• rdt3.0 ("stop-and-wait") — channel can now also lose packets. Adds a timer: if no ACK arrives before timeout, the sender retransmits, tolerating both loss and corruption. This is correct but has very poor throughput because only one packet is in flight at a time.
• Pipelined protocols (Go-Back-N, Selective Repeat) — allow multiple unacknowledged packets in flight (a sliding window) to fix rdt3.0's throughput problem; this is the direct conceptual bridge into TCP's actual sliding-window design.

TCP's Reliability Mechanisms in Detail

• Connection establishment — 3-way handshake: SYN → SYN-ACK → ACK, which synchronises initial sequence numbers on both sides before any data flows.
• Sequence numbers: every byte of the stream is numbered, so the receiver can detect gaps, discard duplicates, and reorder segments that arrive out of sequence.
• Acknowledgments (cumulative ACK): the receiver ACKs the next expected byte, implicitly confirming everything before it has arrived correctly.
• Checksum: detects corrupted segments; a failed checksum causes the segment to be silently discarded (treated as if lost).
• Timeout and retransmission: a dynamically estimated RTO (Retransmission Timeout), based on measured RTT and its variance, triggers retransmission if an ACK is not received in time.
• Fast retransmit: on receiving 3 duplicate ACKs, TCP retransmits the missing segment immediately without waiting for the timer — much faster recovery from an isolated loss.
• Flow control (sliding window): the receiver advertises a window size in every ACK, capping how much unacknowledged data the sender may have in flight, preventing a fast sender from overwhelming a slow receiver's buffer.
• In-order delivery: out-of-order segments are buffered and only handed to the application once every earlier byte has arrived — the application always sees a clean, ordered byte stream.
• Connection termination — 4-way handshake: FIN → ACK → FIN → ACK, since TCP is full-duplex, each direction must be closed independently.

Comparison: rdt Stages

Numericals

Q1 — Stop-and-wait throughput

Bandwidth = 1 Mbps, RTT = 20 ms, packet size = 1,000 bits, propagation one-way ≈ 10 ms.

• Transmission time = 1,000 ÷ 1×10⁶ = 1 ms
• Total round-trip cycle ≈ transmission + RTT = 1 + 20 = 21 ms per packet
• Effective throughput = 1,000 bits ÷ 21 ms ≈ 47.6 kbps — far below the 1 Mbps link capacity, showing why stop-and-wait (rdt3.0) alone is inefficient and pipelining/windowing is required.

Q2 — Utilisation formula

Utilisation U = Transmission time / (Transmission time + RTT).

• With numbers above: U = 1 ÷ 21 ≈ 4.76% utilisation of link capacity — the core justification for TCP's sliding window over plain stop-and-wait.

CSS Exam Angle

• Use the rdt progression when asked about reliability design. For a focused misdelivery or numerical question, answer that requirement directly rather than adding a long protocol history.
• Draw a handshake or termination diagram when it directly answers the question; diagram marks are not guaranteed.
• Explicitly distinguish fast retransmit (loss inferred from duplicate ACKs) from timeout-based retransmission (loss inferred from timer expiry) — a common examiner probe.
• Be ready to link flow control (this page) to congestion control (see "Congestion Avoidance") — examiners often ask candidates to distinguish the two.

Example

Downloading a file must arrive byte-for-byte correct — even one corrupted or missing byte can break the file — which is why file transfer (FTP/HTTP downloads) relies on TCP's full reliability stack rather than UDP's best-effort delivery.

Likely Questions

1. Explain how TCP ensures reliable data transfer. Describe the three-way handshake with a diagram.
2. Trace the evolution of reliable data transfer protocols from rdt1.0 to a pipelined protocol.
3. Differentiate timeout-based retransmission from fast retransmit in TCP.
4. Calculate the utilisation of a stop-and-wait protocol given bandwidth, RTT, and packet size.

📜 Past-Paper Questions & Structured Answers

Questions are paraphrased; answer focus is suggested guidance, not an official marking scheme.

2021 · Paper-II · Q5(b) · 6 marks

Question (paraphrased): Explain TCP’s protection against delivery to the wrong endpoint.

Answer focus: Lead with the checksum pseudo-header; then endpoint checking and limits.

Primary mechanism: checksum including the IP pseudo-header. TCP’s checksum covers its own header and data plus a conceptual pseudo-header containing the source and destination IP addresses, transport protocol identifier and TCP length. The pseudo-header is used in calculation; it is not an extra header transmitted inside TCP.

Operation: the sender computes the checksum using the intended endpoints. The receiver reconstructs the pseudo-header from IP information and verifies the checksum. If a segment is accidentally delivered with inconsistent addressing, this check can detect it and the invalid segment is discarded.

Correct application: source/destination ports and IP addresses identify the established TCP connection. Segments must match an appropriate connection and pass protocol-state checks.

Distinguish other mechanisms: sequence numbers, the handshake and TIME_WAIT help deal with duplicates and old connections; ACKs and retransmissions recover loss. These support reliability but do not replace the pseudo-header answer to misdelivery. The checksum is not cryptographic authentication and cannot guarantee detection of every possible corruption. TCP specification

2021 · Paper-II · Q5(c) · 8 marks

Question (paraphrased): Find the TCP window needed to utilise a 2 Mbps WAN link with RTT 300 ms.

Answer focus: Formula derivation, units, numerical result, scaling and assumptions.

1. Principle: while waiting for acknowledgements, a sender must keep a bandwidth-delay product of data in flight. Approximate throughput is limited by W/RTT; therefore full rate R requires W≥R×RTT.

2. Convert: R=2,000,000 bits/s; RTT=300/1000=0.300 s.

3. Compute: W=2,000,000×0.300=600,000 bits.

4. Express as TCP bytes: 600,000/8=75,000 bytes = 75 kB ≈73.24 KiB.

5. Check: 75,000 bytes /0.3 s =250,000 bytes/s =2 Mbps. If MSS is assumed to be 1,460 bytes, ceil(75,000/1,460)=52 segments can span at least this amount; MSS was not specified by the paper.

6. Implementation: 75,000 exceeds the unscaled 16-bit receive-window maximum of 65,535 bytes, so receive-window scaling is needed to advertise sufficient space. Both the congestion window and receive window must allow at least the target flight size.

Assumptions: ideal steady transfer, stated RTT and rate, sufficient buffers and no competing bottleneck. Protocol overhead and losses can require further allowance; the result is the ideal payload-window target.

2022 · Paper-II · Q5(c) · 6 marks

Question (paraphrased): Why can a TCP handshake be attacked, and does a backlog cap solve it?

Answer focus: Vulnerability → attack sequence → backlog’s limit → relevant defences.

Vulnerability: a conventional server allocates state for a half-open connection after receiving SYN, before the final ACK confirms completion.

SYN flood: many SYNs, sometimes with spoofed sources, lead to SYN-ACK responses and pending state. If final ACKs never arrive, half-open entries persist until timeout; legitimate users may be unable to connect.

Backlog: a cap bounds the number of pending entries and therefore resource use. It does not solve denial of service: an attacker can keep the bounded queue full, causing genuine requests to be dropped or delayed. A larger queue only raises the threshold.

Defences: SYN cookies postpone state allocation until a valid final ACK, encoding necessary information in the server’s sequence number. Rate limiting, SYN proxies, source validation and suitable timeouts can complement this. Backlog implementation details vary by operating system. Cookies address state exhaustion, but do not by themselves prevent upstream bandwidth saturation.