Summary

  • RFC 9959 lets a sender use congestion-control parameters observed on an earlier connection to approach a plausible rate faster, but the saved window remains historical path evidence, not currently reserved bandwidth.
  • The same saved congestion window may be used by only one connection at a time. Load-balanced and distributed senders therefore face a coordination question that a correct per-connection algorithm alone cannot answer.
  • A privacy-bounded saved-state reuse lease should bind one version of the observation to one attempting connection, its Lifetime, path check, jump limit, phase transitions and invalidation. This is Daniel Kade’s editorial proposal, not an IETF requirement.

Yesterday’s acknowledgement is not today’s reservation

Congestion control is a conversation with a path. A sender transmits, acknowledgements return, loss or ECN reports pressure, and the sending rate changes. The congestion window is therefore an estimate formed by experience. It is not a property of an address and it is not capacity held in reserve after the connection closes.

RFC 9959 starts from a practical inefficiency. A server may repeatedly send substantial transfers to the same endpoint over a path whose capacity does not change much. Every new connection ordinarily begins from a small initial window and rediscovers what a recent connection already learned. Careful Resume preserves selected congestion-control parameters so the next connection can converge more quickly without simply starting at the old rate.

The distinction between preservation and possession is the centre of the design. The observed saved_cwnd represents utilised capacity over a round-trip time. The sender also saves a minimum RTT, a Remote Endpoint description and a Lifetime. When another connection arrives, it begins with normal congestion control and the normal initial window. Only after reconnaissance may it make a bounded, paced jump.

That sequence refuses an attractive fiction: because the server once filled a pipe, the pipe still belongs to it.

The RFC publication record classifies Careful Resume as an IETF Proposed Standard. It does not certify the capacity of any live path, prove implementation by a named service or promise a performance gain. It specifies how an implementation may treat retained state without turning an old measurement into an immediate burst.

Endpoint identity is a hypothesis about the path

RFC 9959 calls the lookup key a Remote Endpoint, but the term is deliberately implementation-dependent. It includes an identifier for the sending interface and one for the destination, which may be a unicast or anycast address. An implementation can include DSCP or other differentiating information. Adding detail may reduce false matches; it also reduces the number of later connections that can reuse the record.

This is not ordinary cache-key tuning. The key stands in for an unobserved fact: whether the new packets will traverse a path sufficiently like the one that produced the saved state.

The address can stay the same while the route changes. Equal-cost multipath can choose another member. A NAT mapping can change. Anycast can deliver the connection to another site. A mobile sender can retain an address while its access path changes. The Remote Endpoint is therefore a matching rule, not an authenticated path identity.

Reconnaissance supplies current evidence. The connection starts at the initial window, observes acknowledgements and measures RTT. Congestion, an endpoint known to have changed, expiry, a large RTT mismatch or an already-consumed state causes the sender to stop Careful Resume and continue with ordinary congestion control. A current RTT more than ten times the saved minimum is one explicit path-change indication in the RFC; it is a conservative signal, not proof that smaller changes are harmless.

The policy question is who defines the endpoint key and how a revision is handled. If a deployment changes from one source-interface model to another, enables a new DSCP, moves behind a different anycast topology or alters load-balancing, old records may retain the right syntax while losing their intended scope. RFC 9959 accordingly requires a way to flush retained parameters after configuration change.

One saved state has one consumer

The sharpest rule in RFC 9959 is easy to miss because it sounds like an implementation detail: a particular saved_cwnd can be used by only one connection at a time.

Suppose the observation says that a connection recently used 20 units of capacity. Two new connections independently retrieve that state. Each obeys the half-window rule and makes a jump of ten. Each decision looks bounded in isolation; together they reproduce the full old rate before current capacity has been validated. Ten consumers would multiply the error.

That is why the saved window behaves less like a cached value than a single-use capability. Reading it is not enough. A connection must acquire the authority to attempt reuse, and other contenders must see that acquisition before making their own decision.

On one server process, a hash table and an atomic state change may be sufficient. In a fleet behind a load balancer, the same client can reach different workers. If each worker holds a copy, local correctness no longer guarantees the global invariant. Replication lag, retry after timeout, process crash and failover can all create two plausible owners.

The protocol rule remains one user. The architecture decides whether that rule is actually enforced.

This is a classic Policy Mirror boundary. A shared standard defines the narrow safety invariant; product architecture distributes the authority that must honour it. Calling every worker “RFC compliant” at the code level does not answer whether the fleet spent one record twice.

Half is a safety bound, not a quota

After reconnaissance, Careful Resume may raise the congestion window. The unvalidated jump is limited by max_jump and to no more than half of saved_cwnd. It must be paced using the current RTT so the increase does not become a line-rate burst.

Those limits do not allocate half the old path to the new connection. Other senders may have arrived since the observation. The prior connection may have overshot at the end of slow start. The application may have been rate-limited when measured. The actual bottleneck may have moved.

The RFC therefore separates phases. Reconnaissance uses ordinary startup. The unvalidated phase permits a tentative increment. An acknowledgement for an unvalidated packet, the sending of the bounded window or the passage of an RTT moves the controller toward validation. Only current acknowledgements can turn the experiment into a new estimate.

This temporal structure matters for operations. A dashboard that reports only the final congestion window loses whether bytes were sent under ordinary control, a historical jump or validated current feedback. The numbers may be identical while their evidentiary status differs.

The qlog work in progress, draft-ietf-tsvwg-careful-resume-qlog-02, proposes events for transitions among reconnaissance, unvalidated, validating, normal and safe-retreat phases. It can expose restored values and triggers. That is valuable telemetry. As a draft, it is not a final standard; and a phase event from one process does not by itself prove that no other process acquired the same saved state.

Failure revokes the memory

The ethical test for an optimisation is not only how fast it succeeds. It is how much cost it imposes when its assumption is wrong.

If loss, ECN congestion evidence or a path change appears while the tentative capacity is in use, RFC 9959 enters Safe Retreat. The parameters used for the jump are invalid and removed. The congestion window is reduced sharply so unvalidated packets can drain without continuing to crowd a bottleneck. The RFC notes that ordinary Proportional Rate Reduction is not appropriate where the jump may have created significant overshoot.

The reason is externality. A newly accelerated connection can displace packets from established flows that had adapted to the bottleneck. A gentle retreat may leave those existing connections paying for the new sender’s mistaken memory. Careful Resume states the principle directly: trying and failing should not unduly disadvantage connections already sharing the bottleneck.

Safe Retreat is therefore more than an error branch. It is the revocation rule for the temporary authority to reuse old evidence. The trace must show not only that congestion occurred, but that the corresponding saved state became unusable everywhere it had been replicated. Deleting a local copy while another worker retains the same version is not fleet-wide revocation.

The saved-state reuse lease

A minimal operational record should treat retained state as an expiring, single-consumer lease. “Lease” here is a systems metaphor, not a legal interest, a bandwidth reservation or a new protocol object.

The record can be small:

  1. a rotating, keyed identifier for the Remote Endpoint scope and the configuration version that defined it;
  2. a digest and generation number for the saved parameter set, with observation time, saved_cwnd, saved_rtt and Lifetime;
  3. the connection or worker that attempted atomic acquisition, the result and the expiry of that acquisition;
  4. the normal initial-window evidence, current RTT comparison and reason the path was considered consistent;
  5. the base congestion-control algorithm, max_jump, half-window bound, pacing rule and actual tentative increment;
  6. transitions through reconnaissance, unvalidated, validating, normal or Safe Retreat, including their triggers;
  7. release, replacement, expiry, configuration flush or invalidation, plus proof that revocation reached every replica allowed to consume the version;
  8. aggregate impact measures for loss, ECN, overshoot and established-flow displacement, without packet payloads or durable cleartext client identifiers.

The lease should not store a URL, account, cookie, content, credential or full packet trace. Endpoint linkage can rotate on a period shorter than ordinary user profiling and remain accessible only to operators investigating the control. Public evidence can report acquisition conflicts, expired-state attempts, path mismatches, Safe Retreat frequency and revocation lag by build and region.

This does not centralise the sending decision. Minimum Initial Specification asks for the smallest shared facts needed to compare implementations. One operator may use a strongly consistent store; another may partition ownership by endpoint key; a third may disable Careful Resume for anycast cohorts. The common requirement is narrower: the system must be able to show that one version had at most one authorised consumer at the moment of tentative use.

Limits

The frozen sources do not establish present deployment, vendor support, performance benefits or a named failure. They do not show that distributed coordination has failed in any service. An implementation can legitimately choose not to save small windows, can use a short Lifetime or can avoid Careful Resume where a stable path identity cannot be formed.

RFC 2914 supplies the broader duty to avoid congestion collapse and starvation; RFC 7661 discusses non-validated state inside rate-limited TCP; RFC 9002 supplies QUIC congestion-control context; RFC 9040 discusses sharing TCP control-block information. None turns past throughput into owned capacity.

Reality, not advocacy, means retaining that boundary. A saved window is evidence that one connection used a path at one time. Careful Resume permits one later connection to test part of that evidence under strict limits. Governance should make the test’s temporary authority as observable as its transport result.

Sources