Summary

  • The IESG approved a common method that caps congestion-window growth for application- or receiver-limited senders by the largest flight actually exercised since the last cwnd reduction.
  • A valid ACK proves receipt of transmitted data. It does not prove that unused window credit, never placed on the path, is safe to multiply without limit.

The counter reached twenty-four before the path did

Begin with the draft's deliberately simple case. A sender has an initial congestion window of ten segments. It sends all ten and pauses. With no loss and one ACK for each segment, slow start raises cwnd to twenty.

The application later supplies four segments. They are sent and acknowledged. Under unconstrained arithmetic, those four ACKs raise cwnd again, from twenty to twenty-four. Yet the largest flight the path has carried in one RTT is still ten.

Nothing is wrong with the ACKs. They report delivery of real packets. The mistake is to let delivery of a small, rate-limited flight manufacture permission for capacity that has not been exercised.

This is an illustrative calculation, not a reported incident. Real stacks face delayed ACKs, byte accounting, pacing, flow-control changes and loss. The example matters because it isolates one authority question: what evidence entitles a sender to enlarge the number of unacknowledged bytes it may place in the network?

What the IESG approved

The IETF announcement is dated 24 August at 17:57 UTC. The IESG approved revision 10 of “Increase of the Congestion Window when the Sender Is Rate-Limited” as a Proposed Standard. It is a Congestion Control Working Group document and updates the rules cited in DCCP CCID 2, TCP, QUIC, SCTP and CUBIC.

Approval is one state. At the 28 August evidence freeze, Datatracker still showed an Active Internet-Draft in the RFC Editor queue, with author input required. No IANA action is requested. A numbered RFC, implementation release, default enablement and measured service outcome are later and separate facts.

The announcement reports broad working-group support and multiple implementations. It also says behavior described by the document has been deployed in Linux since version 3.16. That is meaningful running-code history. It is not proof that every kernel, QUIC library, appliance or service uses the same build, gate or observable counters.

Rate-limited is not congestion-limited

A sender can be allowed to send more by congestion control and still transmit less. The application may have no data ready. The receiver may withhold TCP receive-window space or QUIC connection or stream credit. A pacer or rate controller may also space transmission below the cwnd ceiling.

The draft calls a flow cwnd-limited when it consumes the sending allowance. It calls a flow rate-limited, in the RFC 7661 sense, when it uses no more than half of cwnd and is in a non-validated phase.

These states locate different decision makers. The transport sets cwnd. The application decides whether bytes exist. The receiver controls advertised credit. The pacing mechanism schedules departure. The path supplies loss, ECN, delay and delivery evidence. A single “underutilized” label erases which surface held transmission back.

Cwnd is therefore permission, not a bandwidth reading. A twenty-segment window says what the sender may have outstanding under its current algorithmic state. It does not say that the link has twenty segments of spare capacity, that the receiving application is ready, or that the path will remain unchanged.

The cap follows exercised flight size

The new rule introduces maxFS, the largest FlightSize observed since the last cwnd decrease. It starts at the initial congestion window. Whenever flight size changes, the sender retains the greater of the current observation and the existing maximum.

When cwnd is reduced for any reason, maxFS is reset to zero. The next flight then creates a new exercised baseline. This reset matters: a loss response, ECN reaction or other reduction must also end the authority of the old maximum.

When FlightSize is below cwnd, the sender may process ACK-driven growth but must cap the result at limit(maxFS). That function asks what the underlying algorithm would have produced if one complete window of the largest exercised size had been sent and successfully acknowledged.

For RFC 5681 slow start, the example limit is twice maxFS. In congestion avoidance, it is maxFS plus one sender maximum segment size. The rule does not discard delivery evidence. It bounds what that evidence may authorize.

Return to ten plus four. After the first round, maxFS is ten and cwnd may reach twenty. The later four ACKs remain real, but slow-start cwnd stays capped at twenty. Only when a later flight actually grows beyond ten does maxFS move and the cap acquire a larger evidentiary base.

One rule replaces several incompatible assumptions

TCP's standard text did not limit growth in this condition. DCCP CCID 2 could grow during an uncongested period without being cwnd-limited. QUIC said an underutilized window should not increase. SCTP and CUBIC also used conservative gates in parts of their algorithms.

The approved document replaces that divergence with one bounded method. For QUIC, SCTP and CUBIC, this can be less conservative than refusing all increase. For TCP and DCCP, it prevents unbounded growth from small flights. The convergence is around an evidence ceiling, not around identical code.

Rate-based controllers must keep their maximum sustained rate no higher than the cwnd method would permit. Pacing remains available when it changes spacing rather than the amount in flight per RTT. Hybrids such as BBR make the implementation lesson sharper: rate estimate, pacing rate, cwnd and application-limited samples need separate observation.

Old evidence can outlive the path

The draft states its own limit. If cwnd is not reduced, maxFS can remain valid for a long time and stop reflecting the end-to-end path. A mobile handover, route change, tunnel change or queue-policy change may occur without conveniently resetting the variable.

RFC 7661 Congestion Window Validation addresses the related problem of a window larger than recent flight and defines pipeACK for recently acknowledged pipe size. The two mechanisms are related but not interchangeable. Rate-Limited Increase governs growth; CWV governs an underused window and its response to congestion.

This is where a counter can become institutional memory. An old maximum is useful because it avoids needlessly relearning capacity after every application pause. It is dangerous when operators forget the time, path and reduction history that made it credible.

ACK security is necessary, not sufficient

Congestion control relies on the receiver acknowledging delivered data appropriately. The ability of an attacker to manipulate the sender depends on the transport's authentication and protection properties. QUIC protects more of this exchange than bare TCP, while TCP has its own sequence and validation defenses.

But an authentic ACK still has a bounded meaning. It proves that particular transmitted bytes were received under the transport semantics. It does not certify unused capacity, future RTT, fairness, a stable route or application readiness.

Security review should therefore keep three questions apart: was the ACK acceptable, what transmission did it acknowledge, and what growth did the local algorithm authorize from that evidence?

Running code must close the chain

Current Linux Reno code checks whether the flow is cwnd-limited before applying slow start or additive increase. Current Linux CUBIC uses the same gate before its own update. These public sources support the distinction between exercised and underused windows.

They do not identify a production fleet. Builds, backports, offloads, congestion-control selection and transport libraries vary. Running-Code Primacy requires the local chain: implementation and configuration, application or receiver constraint, flight measurements, ACK processing, the cap decision, actual resumed burst, loss and latency outcome.

For one episode, preserve the transport and build; algorithmic state; application queue; receiver credit; pacing or rate limit; cwnd, flight size, maxFS, initial window and slow-start threshold; ACKed bytes; loss or ECN reduction; the computed cap; path identity; and post-resume delivery result.

The standard supplies a minimum shared rule. It does not transfer operational judgment to the document. Publication describes the rule; deployment and observed behavior establish whether the permission was safe.

Sources