In TCP, what problem does flow control solve, and how is it different from congestion control?

## The problem flow control solves TCP delivers a reliable, ordered **byte stream** between two endpoints. Each endpoint holds received data in a **receive buffer** until its application reads it. If a fast sender keeps transmitting while a slow reader lets that buffer fill, bytes arrive with nowhere to go. RFC 9293 §3.8.6 is blunt about the result: data that arrives beyond what the receiver can accept is **discarded**, and the sender must then retransmit it, wasting both the network and the two hosts. **Flow control** is TCP's answer: the **receiver** tells the sender, continuously, how much more data it is prepared to accept. The sender never has more unacknowledged data outstanding than that amount. It is an end-to-end agreement between two hosts about one buffer. ## How the receiver tells the sender Every TCP segment carries a 16-bit `Window` field. RFC 9293 defines it as the number of data octets, beginning with the one named in the acknowledgment field, that the sender of this segment is willing to accept. So the advertisement is always relative to the acknowledgment number: - the **left edge** is the acknowledgment number (the next byte the receiver expects); - the **right edge** is acknowledgment number + window; - the value is counted in **bytes**, never in segments. RFC 5681 names the most recently advertised value the **receiver window**, `rwnd`. RFC 9293 calls the receiver's own copy `RCV.WND` and the sender's copy `SND.WND`. The receiver derives it from free buffer space: roughly, buffer size minus data received but not yet read by the application. When the application reads, space frees and the next segment advertises a larger window. When the application stalls, the window shrinks towards zero. ## Flow control versus congestion control The two mechanisms are often confused because both limit how much a sender may have in flight. They protect different things and are driven by different endpoints. | | Flow control | Congestion control | |---|---|---| | Protects | the **receiver's** buffer | the **network's** queues and links | | Variable | `rwnd` (advertised by the receiver) | `cwnd` (computed by the sender) | | Who sets it | the data **receiver** | the data **sender** | | Signal | explicit: the `Window` field | mostly inferred: loss, duplicate ACKs, delay; ECN marks where supported | | Specification | RFC 9293 | RFC 5681 and its successors | Flow control is **explicit**: the receiver knows its buffer and says so. Congestion control is mostly **inferred**: routers do not report how much room their queues have, so the sender reacts to evidence such as loss, delay or, where ECN is in use, a congestion mark. The algorithms that grow and cut `cwnd` belong to congestion control and are a separate subject. ## How the two combine RFC 5681 states the rule that ties them together: **the minimum of `cwnd` and `rwnd` governs data transmission**. A worked example: 1. A receiver advertises `rwnd` = 64,000 bytes; the sender's `cwnd` is 20,000 bytes. The sender may have 20,000 bytes outstanding: the network is the constraint. 2. `cwnd` grows to 90,000 bytes on a clean path. Now the limit is 64,000 bytes: the receiver is the constraint. 3. The receiving application stops reading and `rwnd` falls to 8,000 bytes. The sender is held to 8,000 bytes even though the network could take far more. So a connection can be slow on a perfectly healthy network because of flow control alone, and fast-looking buffers at the receiver do not help when the path is congested. ## Why the split matters when diagnosing Because the two limits have different owners, they point at different fixes. A connection held back by `rwnd` is telling you about the **receiving application or its buffer**: it reads slowly, or it was given too little space. A connection held back by `cwnd` is telling you about the **path**: loss or queueing somewhere between the hosts. Tuning the network will not speed up a slow reader, and enlarging a receive buffer will not cure a lossy link. An interviewer asking this question is usually checking exactly that you will look at the right end first. ## Common confusions - **"The window is set once in the handshake."** The window is advertised in every segment and changes continuously; only the window-scale *shift* is fixed at connection setup. - **"A small window means the network is congested."** A small or zero `rwnd` means the receiving application is not reading fast enough, or its buffer is small. - **"The sender picks rwnd."** The sender only obeys it; `cwnd` is the sender's own variable. - **"Flow control is per packet."** Windows are in bytes; a 16,000-byte window may be one segment or many.