= Solution
<TCP> implements both restrictions at the sending <endpoint>, using information from different places. For <flow control>, the receiving <TCP> advertises its available <receive window> $\mathrm{rwnd}$ in <TCP> headers. The sending <TCP> tracks that advertised range together with the <acknowledgement> number, and must not send ordinary new data beyond its right edge. As the receiving application consumes data, the receiver can advertise more space. A zero <receive window> stops ordinary new data and invokes the separate probing mechanism.
For <congestion control>, the sender maintains a <congestion window> $\mathrm{cwnd}$ representing its permitted amount of outstanding data given the path's condition. <Acknowledgements>, duplicate <acknowledgements> and <data retransmission> timeouts supply feedback; explicit congestion notifications can also contribute when negotiated. <Routers> supply the underlying evidence through queuing, drops or marks, but ordinary <TCP> <congestion window> management takes place at the <endpoints>, rather than through a per-connection capacity reservation at each <router>.<TCP Congestion Control (RFC 5681)>[§§2–3: cwnd, rwnd, flight size and sender mechanisms]{ref}
Ignoring exceptional probe behaviour, let $F$ be the number of sent but not yet acknowledged <bytes>. The two controls combine approximately as
$$
\boxed{F\leq\min(\mathrm{rwnd},\mathrm{cwnd}),\qquad
\text{new-data allowance}=\max\{0,\min(\mathrm{rwnd},\mathrm{cwnd})-F\}.}
$$
The <send window> is anchored by the acknowledged sequence position, rather than authorizing a fresh windowful on every send. <Acknowledgements> release room as old data leave flight. A sudden reduction of a limit can leave already transmitted data above it; the sender then waits instead of recalling those <bytes>. The <receive window> is explicit receiver feedback, whereas the <congestion window> is a local sender variable. No details of their parameter-adjustment algorithms are needed for this distinction.
Back to article page
