TCP reliability, flow control, and congestion

Prerequisites: Packets, byte streams, round-trip time, and basic arithmetic.

Learning objectives

• Interpret TCP sequence and acknowledgement numbers.
• Explain retransmission without claiming application-level exactly-once effects.
• Distinguish receive windows from congestion windows.

TCP offers applications an ordered byte stream over a network that can drop, duplicate, delay, or reorder packets. Sequence numbers identify positions in that stream. Acknowledgements report received progress, retransmissions repair loss, and the receiver suppresses duplicate bytes before delivery. These mechanisms do not promise that a connection survives every failure, nor that a remote application has durably completed an operation.

Suppose the next expected byte is 1000. A sender transmits bytes 1000 through 1499 and then 1500 through 1999. If the second segment arrives first, the receiver may buffer it but still acknowledge 1000, the next missing byte. When the first arrives, a cumulative acknowledgement can advance to 2000. An acknowledgement of 2000 confirms receipt of all preceding stream bytes within that connection's sequence space; it does not identify a particular application message boundary.

The sender must distinguish delayed acknowledgements from probable loss. Retransmission timeouts use measured round-trip behavior and variation, and loss signals can trigger earlier retransmission. A timeout does not prove the original packet was lost: the acknowledgement may have been lost, or either direction may simply be slow. Sequence numbers allow retransmitted bytes to be recognized without delivering duplicate stream content.

Flow control protects the receiver. Its advertised receive window limits how much additional data it can buffer. Congestion control protects the network by limiting outstanding data according to observed path behavior. The sender's usable allowance is constrained by both the receive window and its congestion window, plus already outstanding bytes. A large receiver buffer cannot justify flooding a congested bottleneck.

For intuition, consider a 10-megabit-per-second path with a 100-millisecond round trip. Its bandwidth-delay product is 1000000 bits, or 125000 bytes. Roughly that much data must be in flight to keep the path continuously busy under a simplified steady-flow model. A window of 12500 bytes can limit throughput near 1 megabit per second at that RTT, even if the physical link could carry more. Protocol overhead, loss, pacing, and competing traffic modify the actual result.

Classic TCP congestion control increases its sending allowance during successful delivery and reduces it after congestion signals; slow start and congestion avoidance use different growth behavior. Modern implementations may use other algorithms, so avoid assuming a universal packet-by-packet growth rule. Study a named algorithm under stated assumptions.

Finally, distinguish transport receipt from business success. If a client sends a transfer request and loses the connection before receiving a response, the server may have committed it or not. TCP alone cannot resolve that ambiguity. Application identifiers, durable results, and retry semantics belong in the higher-level protocol.

Practice problem

A receiver expects byte 4000. Segments 4000–4499 and 4500–4999 are sent, but only the second arrives initially. Give the cumulative acknowledgement before and after the missing first segment arrives. Then calculate the approximate window-limited throughput for a 20000-byte window and 80-millisecond RTT, ignoring overhead. Explain why receiving a TCP acknowledgement for a database request is insufficient evidence that the transaction committed.

Worked solution

The initial cumulative acknowledgement remains 4000 because that byte is still missing, even if the later segment is buffered. Once the first segment arrives and the buffered bytes become contiguous, it can acknowledge 5000. The simplified throughput ceiling is 20000/0.08=250000 bytes per second, or 2 million bits per second. A TCP acknowledgement reports transport-level byte receipt, commonly by the host networking stack. The application may not yet have parsed, validated, executed, or durably committed the request. A response protocol must explicitly report the business outcome, and a lost response still requires retry-safe operation identifiers or another ambiguity-resolution mechanism.

Check your understanding

A receiver expects byte 1000, buffers segment 1500–1999, then receives 1000–1499. How does the cumulative acknowledgement advance?

• From 1500 to 1999.
• From 2000 back to 1000.
• From 1000 to 2000.
• It remains 1000 until the application commits a transaction.

Explanation

The missing prefix prevents advancement initially; filling it makes all bytes through 1999 contiguous.

A sender has receive window 64KB, congestion window 16KB, and 12KB outstanding. Ignoring other limits, how much additional data can it send?

• 16KB
• 4KB
• 52KB
• 64KB

Explanation

The tighter total-flight limit is min(64,16)=16KB. Subtracting 12KB already outstanding leaves 4KB.

Primary reading

• Transmission Control Protocol, RFC 9293: IETF / RFC Editor
• TCP Congestion Control, RFC 5681: IETF / RFC Editor

Open the study and save your work →