Computer Network & Network Security System — Transport Layer, NEC licence examination syllabus (Nepal Engineering Council).
Flow Control & Buffering at the Transport Layer
Same sliding window idea from the data link layer — now working end-to-end across the whole internet, not just one wire.
throughput ≈ window size ÷ round-trip time With win = 64, rtt = 100, Mbps = 5.24.
64 KB over a 100 ms round trip caps at 5.24 Mbps — no matter how fast the underlying link is. That single number is why window scaling exists.
TCP uses a sliding window mechanism (same concept met in the Data Link Layer, but now applied over the whole network path rather than a single link) — the receiver advertises how much buffer space it currently has, and the sender is only allowed to send that much unacknowledged data before it must pause.
Buffering lets both sender and receiver hold data temporarily — the sender buffers data waiting to be acknowledged (in case retransmission is needed), and the receiver buffers data that's arrived but hasn't been read by the application yet.
💡 One-liner: "How does TCP's receiver tell the sender to slow down?" → It advertises a smaller (even zero) window size in its ACKs, which the sender must respect.
The number this puts a ceiling on
The window does not merely slow a sender down when the receiver is struggling. It sets a hard upper limit on throughput that applies even when nothing is wrong.
A sender may have at most one window of unacknowledged data in flight. Having sent it, it must wait a full round trip for an acknowledgement before continuing — so:
maximum throughput ≈ window size ÷ round-trip time
Worked example: 64 KB window, 100 ms round-trip time
= 64 × 1024 × 8 bits ÷ 0.1 s
= 524,288 bits ÷ 0.1 s
= 5.24 Mbps
That ceiling holds regardless of link speed. Put that connection on a 1 Gbps line and it still achieves 5.24 Mbps, because the sender spends almost all its time waiting for acknowledgements rather than transmitting. The original TCP window field was 16 bits, capping the window at 64 KB — which is precisely why the window scaling option had to be added as links got faster.
💡 This explains something students often find counter-intuitive: a long-distance transfer can be slow on a fast connection. The bottleneck is not bandwidth but latency, and no amount of extra bandwidth fixes it. Only a bigger window does.
Flow control is not congestion control
These are constantly confused, and the distinction is a standard exam question. They solve different problems, using different signals.
🚦 Two different problems
Flow controlProtects the receiver from being overwhelmed. The signal is explicit: the receiver advertises its window in every acknowledgement.
Congestion controlProtects the network from being overwhelmed. There is no explicit signal — the sender infers congestion from packet loss and delay.
TCP runs both simultaneously and sends the minimum of the two windows. A fast receiver on a congested network is limited by congestion control; a slow receiver on an idle network is limited by flow control. Both are always active, and whichever is smaller wins.
💡 A zero window advertisement tells the sender to stop entirely. The sender then sends periodic window probes — because if it simply waited, and the acknowledgement that eventually reopened the window were lost, both sides would wait for each other forever. That deadlock is what the probe exists to prevent.
Syllabus points
Sliding window at transport layer
Buffering
Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.