TCP Congestion Control Workbench
Trace cwnd, ssthresh, receiver window limits, loss recovery, and IoT latency effects
TCP congestion control: keep the pipe full without flooding it
TCP does not send unlimited data just because the application has bytes ready. The sender keeps a congestion window, watches ACKs and loss, and changes how much data may be in flight across the network path.
Clean Reno ramp
The sender starts cautiously, doubles during slow start, then switches to additive growth at ssthresh.
| RTT | Phase | cwnd | send limit | event |
|---|
What is cwnd?
cwnd is a sender-side congestion limit. It says how much data may be outstanding before ACKs return.
What is rwnd?
rwnd is the receiver's advertised flow-control window. The sender must respect both cwnd and rwnd.
Why ACKs matter
ACKs are the clock. They tell the sender that data left the network and more data can be injected.
Why IoT teams care
High RTT, wireless loss, and small telemetry bursts can make TCP setup and recovery dominate the useful payload time.
Slow start
Start small and increase quickly while ACKs return. The teaching model doubles once per RTT until ssthresh.
Congestion avoidance
After ssthresh, Reno-style growth becomes additive, about one MSS per RTT in the simplified view.
Duplicate ACK loss
Three duplicate ACKs suggest one segment may be missing while later data arrived, so fast retransmit can avoid waiting for RTO.
Fast recovery
Reno/NewReno halves the flight estimate, retransmits, and returns to congestion avoidance after recovery.
Timeout response
RTO is harsher: ssthresh is cut and the loss window returns to one SMSS in this baseline teaching model.
Flow-control limit
If rwnd is smaller than cwnd, the receiver, not network congestion, is the current send limit.
Slow start is active
ACKs are returning, so the sender can open cwnd quickly until the threshold is reached.
cwnd is limiting
The send limit is min(cwnd, rwnd), so the smaller window controls bytes in flight.
No loss yet
Loss responses change ssthresh and cwnd; timeout is more disruptive than duplicate ACK recovery.
RTT shapes progress
A small number of RTT rounds can be acceptable on Ethernet and expensive on a sleepy IoT link.
Quick mental model
- cwnd protects the network path.
- rwnd protects the receiver buffer.
- The sender's usable window is bounded by the smaller one.
Baseline formulas
- send limit = min(cwnd, rwnd)
- slow start: about doubling per RTT in the teaching view
- avoidance: about plus 1 MSS per RTT for Reno-style AIMD
Loss formulas
- ssthresh = max(flight / 2, 2 * SMSS)
- timeout: cwnd returns to the loss window
- duplicate ACK recovery avoids a full RTO wait when later data was ACKed
| Concept | Meaning | Common mistake | IoT design implication |
|---|---|---|---|
| cwnd | Sender congestion window; limits in-flight data based on path feedback. | Treating it as the receiver buffer size. | High RTT makes cwnd growth take longer in wall-clock time. |
| rwnd | Receiver advertised window; flow-control limit from the receiver. | Calling every small send limit congestion. | Small gateways or proxies can throttle bursts even on a clean link. |
| ssthresh | Boundary between slow start and congestion avoidance. | Assuming slow start always continues until loss. | A conservative threshold can stretch short transfers over more RTTs. |
| RTO | Retransmission timeout; severe loss signal when expected ACKs do not arrive. | Equating timeout with three duplicate ACKs. | Timeouts keep radios active and can dominate battery cost. |
Window check
Set rwnd below cwnd. The bottleneck shifts from congestion control to receiver flow control.
Loss check
Compare duplicate ACK recovery with timeout. Both cut the threshold; timeout also collapses the active window.
Latency check
Raise RTT and watch the throughput estimate fall even when cwnd is unchanged.
Deeper notes for careful readers
- This workbench uses MSS units and one-RTT rounds so the shape is inspectable. Real TCP updates cwnd per ACK and also depends on ACK policy, pacing, implementation details, and path behavior.
- The initial window here starts at 1 SMSS to make the slow-start shape visible. Many deployed TCP stacks use larger initial windows; the learning goal is the control loop, not a stack default audit.
- Wireless loss is not always congestion. TCP still treats loss as a congestion signal unless the implementation and path provide better information.
- CUBIC is standardized for fast and long-distance networks. The CUBIC scenario shows the growth shape and caveat, not every implementation parameter.
TCP congestion control
RFC 5681 defines slow start, congestion avoidance, fast retransmit, and fast recovery.
Core TCP behavior
RFC 9293 is the current TCP specification and context for sender and receiver windows.