Summary

  • draft-ietf-ccwg-ratelimited-increase-11 would let several transports grow their congestion window while application supply or receiver flow control limits sending, but caps the result against the largest observed FlightSize.
  • That cap disciplines sender state. It does not reserve future bandwidth, open receiver credit, prove pacing, or guarantee that a later flight will survive then-current path conditions.

Picture a connection with a congestion window of twenty segments. The application supplies four. All four are acknowledged. The arithmetic is clean; no loss is visible. A dashboard can now say that the window remained healthy, perhaps even grew.

What the dashboard cannot say is that the network has set aside twenty-four segments for tomorrow.

That is the useful boundary inside draft-ietf-ccwg-ratelimited-increase-11, published on 6 September by the IETF Congestion Control Working Group. The draft tries to harmonise rules that currently diverge across TCP, QUIC, SCTP, DCCP and CUBIC. Some specifications stop increasing the congestion window when a sender is application-limited. Others can allow growth that drifts far above what the flow has recently exercised. The proposal permits an increase, but constrains it.

A sender is “rate-limited” here when it sends less than congestion control would allow. The application may have no more data. The receiver may withhold flow-control credit. Neither condition is a congestion signal. Yet both leave FlightSize—the data sent but not cumulatively acknowledged—below cwnd, the sender’s limit on outstanding data.

The draft introduces a deliberately narrow memory. maxFS is the largest FlightSize observed since the last reduction of cwnd. When FlightSize changes, maxFS keeps the larger value. When cwnd is reduced for any reason, maxFS resets. Any later increase must be capped by limit(maxFS): the result the congestion-control algorithm would have produced from acknowledgements for one successfully transmitted window of that size. In the draft’s slow-start illustration, the ceiling is twice maxFS; in congestion avoidance it is maxFS plus one sender maximum segment size.

This is not a gift of unused capacity. It is a guard against two opposite mistakes. Refusing every increase can penalise variable-rate applications after a short lull. Allowing unrestricted increase can produce a window that bears little relation to the path the sender actually used. The proposal says that acknowledged flight can support bounded state growth. It does not say that empty space inside the old window was tested.

The document makes the expiry problem explicit. Without a separate method to reduce a stale window, maxFS can remain valid for a long time and stop reflecting the reality of the end-to-end path. It therefore points to RFC 7661, Congestion Window Validation. That experimental RFC uses pipeACK samples—the volume acknowledged over a measured round-trip interval—to distinguish recently validated state from a window based on older capacity. FlightSize is an instant; pipeACK is an observation over time. Neither is a transferable claim on the future.

Three authorities must remain separate. The application controls whether bytes exist to send. The receiver controls connection or stream credit. Congestion control limits what the sender may inject based on network evidence. A high cwnd cannot create application demand, overrule receiver back-pressure or guarantee a queue along the current route. Combining the three into a single “available throughput” number destroys the reason each control exists.

Pacing adds another boundary. A sender can have permission to keep more data in flight and still spread packets to avoid a burst. The draft says its maxFS cap does not prevent pacing. It does not certify that a specific implementation enabled pacing, chose a safe interval or avoided offload-induced packet trains. That requires implementation and wire evidence.

The same restraint applies to acknowledgements. An ACK records transport receipt under one protocol’s rules for earlier data. It can update loss recovery and congestion state. It does not attest that the route is unchanged, competing traffic is absent, a policer will not engage, receiver credit will expand or the application will accept the next object. An authenticated ACK may improve confidence in who sent the signal; it still cannot speak for future network conditions.

The draft is ambitious in scope but modest in status. If approved, it would update RFCs 4341, 5681, 9002, 9260 and 9438. It remains an Internet-Draft, may change, and requests no IANA action. Standards advancement, code support, feature enablement and production outcome require different records.

Sources