Summary

  • RFC 3742 proposed slowing TCP’s window growth after cwnd exceeded max_ssthresh, because exponential slow-start could add thousands of segments in one round trip.
  • Verified Erratum 236 corrected the stated per-RTT range and made 836 RTTs to reach 83,000 packets a minimum estimate, not an exact forecast.

The distinction matters because “limited” did not mean “fixed rate.” RFC 3742 was an optional Experimental proposal for connections whose congestion windows could reach thousands of maximum-segment-sized units. Below or at max_ssthresh, it retained ordinary slow-start’s one-MSS increase for each arriving acknowledgement. Above that threshold, it calculated K = int(cwnd / (0.5 * max_ssthresh)) and added roughly one Kth of an MSS per ACK. The additional threshold was not a replacement for ssthresh; crossing ssthresh still ended slow-start.

The proposal’s arithmetic was presented with more confidence than the document could support. Section 2 originally said growth above max_ssthresh was at most half that threshold per round-trip time. Yet the ACK-level rule, with K changing in steps as cwnd rose, described a range. Erratum 236, verified by the RFC Editor, corrected the invariant: the increase is no more than max_ssthresh MSS per RTT and no less than half that amount. It also replaced a single reach-time formula with lower and upper bounds. For a 100-MSS threshold and a target window of 83,000 packets, the often-repeated 836-RTT figure became “at least” 836 RTTs.

That is a correction to the account of the mechanism, not a new congestion-control algorithm. The RFC’s original text remains the published 2004 document; the erratum is separate evidence that must be read alongside it. The correction widens the reader’s picture of possible growth and duration, but it does not turn either endpoint into a universal measured outcome.

The reason to limit growth was an externality as well as a sender problem. A large slow-start jump might drop many packets together, trigger retransmission timeouts, and push the connection back to a small congestion window. The same burst could consume queue and loss budget used by other traffic. The RFC gave a 100-MSS example and reported early experiments on a Linux 2.4.16 Web100 kernel, but those are bounded historical claims—not proof of present-day deployment, Internet-wide benefit, or a guarantee that a queue stays below a chosen size.

Later TCP documents show a changed design vocabulary. RFC 9438 generally recommends HyStart++ for CUBIC’s slow-start, while listing Limited Slow-Start as an experimental alternative. RFC 9406 instead uses rising round-trip delay as a clue for when to leave slow-start, followed by a conservative phase that checks whether the exit was premature. That is a different control signal from RFC 3742’s window-dependent increment. The lineage is useful precisely because the mechanisms are not interchangeable.

For network operators, the erratum is a reminder to ask what an algorithm’s headline number actually bounds. A per-round-trip window increment is not a byte-rate cap, a queue measurement, or proof of fairness on a shared path. The threshold, ACK behavior, pacing, buffer, RTT, and competing flows all shape the real consequence. The correction makes the RFC’s own uncertainty legible; it does not remove it.

Sources