Worked examples — TCP flow control — sliding window, receive buffer

This page drills the flow-control machinery from the parent topic until no scenario can surprise you. We take the two formulas you already met — the advertised window and the sender's budget — and run them through every corner case: normal, empty, full, zero, scaled, and a couple of exam traps.

The scenario matrix

Before we solve anything, let us list every kind of situation these formulas can land in. Think of this as a checklist: by the end, every row has a worked example next to it, so you never meet a case you have not seen.

The subtle pair to keep separate is C vs E. In C the buffer is physically full. In E the buffer has free space but the sender is not allowed to use it yet because its earlier bytes are still unacknowledged in the network. Same "you can't send" result, totally different cause — we give each its own example.

Example 1 — Cell A: the ordinary healthy connection

Forecast: guess before computing — is the sender free to send a healthy chunk, or nearly stalled? (It "feels" healthy — small occupancy.)

1. Occupancy $=\text{LastByteRcvd}-\text{LastByteRead}=24000-22500=1500$. Why this step? These are bytes that arrived but the app has not read() yet — they sit taking up buffer space.
2. rwnd $=8000-1500=6500$. Why this step? rwnd is the literal free space: total minus occupied.
3. In-flight $=\text{LastByteSent}-\text{LastByteAcked}=24000-23200=800$. Why this step? Those 800 bytes are on the wire, unacknowledged; they already have reserved seats in the buffer.
4. Room to send $=\text{rwnd}-\text{in-flight}=6500-800=5700$. Why this step? We must not promise more room than exists, so subtract what is already claimed.

Verify: if the sender pushes all 5700, in-flight becomes $800+5700=6500=\text{rwnd}$. Exactly filling the advertised room without exceeding it. Units: all bytes. ✓

Example 2 — Cell B: the empty buffer (degenerate low input)

Forecast: the buffer is empty — does rwnd equal the full buffer, or zero?

1. Occupancy $=40000-40000=0$. Why this step? Nothing accepted-but-unread means zero bytes occupy the buffer.
2. rwnd $=8000-0=8000$. Why this step? All memory is free, so the receiver advertises the entire buffer.

Verify: occupancy can never be negative (you cannot read bytes you have not received, so LastByteRead ≤ LastByteRcvd). The maximum possible rwnd is RcvBuffer itself, reached exactly here. ✓ This is the upper limiting case — the mirror of Cell C.

Example 3 — Cell C: buffer exactly full, rwnd = 0 (limiting value)

Forecast: the app stopped reading — will rwnd be small-but-positive, or hit hard zero?

1. Occupancy $=33000-25000=8000$. Why this step? Standard occupancy count.
2. rwnd $=8000-8000=0$. Why this step? Occupancy equals the whole buffer, so free space is nothing left.
3. Consequence: the receiver advertises Window = 0; the sender's rule $\text{LastByteSent}-\text{LastByteAcked}\le 0$ forces it to send no new data. Why this step? Any new byte would have nowhere to land and would be dropped.

Verify: room to send $=0-(\text{in-flight})$. If in-flight is already $0$ (all acked), room to send $=0$: correct, the sender is frozen. Occupancy can never exceed RcvBuffer, so rwnd never goes negative — $0$ is the floor. ✓ This is the lower limiting case.

Example 4 — Cell E: window saturated but buffer NOT full

Forecast: the buffer still has 6500 free — surely the sender can send something? (Trap!)

1. In-flight $=30000-23500=6500$. Why this step? Count the unacknowledged bytes riding the network.
2. Room to send $=6500-6500=0$. Why this step? The window is exactly full of in-flight bytes; every seat rwnd promised is already claimed by data in transit.

Verify: the buffer is not physically full — those 6500 bytes have not arrived yet, they are on the wire. The sender is blocked purely by the promise, not by real occupancy. Contrast with Example 3, where the buffer was genuinely full. When an ACK arrives, LastByteAcked rises, in-flight drops, and room reopens — the window slides. ✓

Example 5 — Cell F: zero-window probe recovery

Forecast: the app freed 3000 bytes — will the sender automatically find out?

1. New occupancy $=33000-28000=5000$. Why this step? 3000 fewer unread bytes now sit in the buffer.
2. New rwnd $=8000-5000=3000$. Why this step? Freed space becomes advertisable room again.
3. The catch: the receiver only sends a segment when it has data or an ACK to send. With no data flowing, this fresh rwnd = 3000 might never leave. Why this step? This is the zero-window deadlock the parent warned about.
4. The fix: the sender periodically transmits a 1-byte zero-window probe. The receiver's reply carries the current Window = 3000, unsticking the flow. Why this step? The probe forces the receiver to emit a fresh advertisement.

Verify: after recovery the sender may push $\min (3000,3000)=3000$ new bytes (assuming nothing in flight). rwnd climbed from $0$ to $3000$ — exactly the 3000 the app drained. Conservation holds: bytes freed = window regained. ✓

Example 6 — Cell D: window scaling past the 16-bit wall

Forecast: can a 16-bit field ever mean more than 65535? (Yes — via the shift multiplier.)

1. Effective window formula: ${\text{rwnd}}_{\text{eff}}=\text{Window}\times 2^s$. Why this step? The scale option (built in the parent's Example 3) multiplies the raw field by $2^s$ instead of widening it — old TCPs stay compatible.
2. Multiplier $=2^6=64$. Why this step? $s=6$ means "shift left 6 bits," i.e. multiply by 64.
3. Raw Window $=\frac{1,200,000}{64}=18750$. Why this step? Invert the formula: $\text{Window}={\text{rwnd}}_{\text{eff}}/2^s$. And $18750\le 65535$, so it fits the 16-bit field. ✓
4. Sender interprets: $18750\times 64=1,200,000$ bytes. Why this step? Confirms the receiver's intent survives the shift.

Verify: $18750\times 64=1,200,000$ exactly, and $18750<65535$ so it is a legal field value. Without scaling, the ceiling would be $65535$ bytes — about 18× too small for this link. ✓

Example 7 — Cell G: real-world drain-vs-fill over time

Forecast: net fill is fill minus drain — is it positive (buffer grows) or does the app keep up?

1. Net fill rate $=50000-30000=20000$ bytes/s. Why this step? Occupancy changes at (bytes arriving) − (bytes read). Positive means the buffer is losing free space.
2. Time to full $=\frac{\text{RcvBuffer}}{\text{net fill}}=\frac{60000}{20000}=3$ s. Why this step? Starting empty, occupancy grows at 20000 B/s; it reaches 60000 B (full) after $60000/20000$ seconds.
3. At $t=3$ s: occupancy $=60000$, so $\text{rwnd}=60000-60000=0$. Why this step? The buffer is full → receiver advertises Window 0 → flow control brakes the sender down toward the app's 30000 B/s.

Verify: units — $\text{bytes}/(\text{bytes/s})=\text{s}$. ✓ Sanity: after the brake, sustained throughput cannot exceed the app's read rate of 30000 B/s — flow control matches sender speed to consumer speed, exactly its job. ✓

Example 8 — Cell H: the exam twist, min(rwnd, cwnd)

Forecast: rwnd is huge (40000) — does the sender get to use all of it? (Trap: two brakes, not one.)

1. Effective window $=\min (\text{rwnd},\text{cwnd})=\min (40000,12000)=12000$. Why this step? The sender must respect both limits: rwnd protects the receiver's buffer, cwnd protects the network. The tighter one wins. See TCP congestion control — cwnd, AIMD.
2. Room to send $=12000-5000=7000$. Why this step? Subtract in-flight from the binding window, exactly as in every other example — just with the effective window in place of rwnd.

Verify: had we naively used rwnd, we'd get $40000-5000=35000$ — nearly 5× too much, flooding a lossy network. The bottleneck here is the network, not the receiver's buffer. Either window can bind; here cwnd does. ✓

Recall

Connections

• 4.3.21 TCP flow control — sliding window, receive buffer (Hinglish)
• TCP congestion control — cwnd, AIMD
• Bandwidth-delay product
• Buffer overflow & packet loss
• TCP segment header format
• Stop-and-wait vs sliding window protocols
• TCP three-way handshake & options

Scenario Map