Foundations — TCP flow control — sliding window, receive buffer

This page assumes nothing. Before you can read the parent note TCP flow control, you need a small toolkit of ideas. We build each from the ground up, in an order where every new thing rests on the last.

0 · What is a "byte" and a "byte stream"?

Look at the figure: each little box is one byte, and the number under it is that byte's fixed position. This numbering is the secret that makes everything else work — because now any pointer is just a number saying "up to here."

Why does the topic need this? Because every symbol in the parent note (LastByteSent, LastByteRcvd, …) is nothing more than a number pointing at one position on this tape. Master the tape and the symbols become obvious.

1 · Sender and receiver

Picture a person pouring water down a hose (sender) into a friend's cup (receiver). We will keep coming back to this picture.

2 · The receive buffer — a waiting room for bytes

Look at the figure: the box is the buffer. Bytes flow in from the left (from the network) and are pulled out on the right (by the program). The red segment is the part currently occupied. The topic exists entirely to keep that red part from ever filling the whole box.

Why the topic needs it: flow control is only about protecting this one buffer. Nothing about the network in between — that is a different mechanism (see Buffer overflow & packet loss and TCP congestion control — cwnd, AIMD).

3 · Two pointers on the receiver's side

Now that bytes are numbered (Section 0) and wait in a buffer (Section 2), we need to say where the buffer starts and ends on the tape. That takes exactly two numbers.

Why subtraction gives a count: if arrivals go up to seat $10500$ and departures up to seat $9000$, then seats $9001\dots 10500$ are occupied — that's $10500-9000=1500$ bytes.

4 · The receive window rwnd — announced free room

Why the topic needs it: this single number is the brake pedal. When it's large, the sender may pour fast; when it hits $0$, the sender must stop.

5 · Two pointers on the sender's side + "in-flight"

The receiver had two pointers; the sender needs two of its own to track what it has launched.

Look at the figure: on the numbered tape, everything up to LastByteAcked is done and confirmed. The red stretch between LastByteAcked and LastByteSent is in-flight — launched, fate unknown. Bytes past LastByteSent are not sent yet.

6 · Putting it together — the one inequality

Now every symbol is earned, and the whole parent topic collapses to a single line:

And the practical question "how many more may I send right now?": $\text{extra}=\text{rwnd}-(\text{LastByteSent}-\text{LastByteAcked})$ Free room, minus seats already reserved by in-flight bytes.

7 · One more symbol you'll meet: min(rwnd, cwnd) and 2^s

Two small notations appear later in the parent note. Meet them now so they never surprise you.

Prerequisite map

Read top to bottom: the numbered stream lets us define pointers; pointers give occupancy and in-flight; buffer size minus occupancy gives rwnd; rwnd versus in-flight gives the rule. Every arrow is a "you need this before that."

Equipment checklist

Test yourself — you're ready for the parent note when each answer comes instantly.

Connections

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