Summary

  • MAX_DATA and MAX_STREAM_DATA advertise absolute byte-offset ceilings, not new-byte grants or free-memory measurements.
  • Credit cannot be revoked by sending a smaller value, and a missing DATA_BLOCKED frame does not prove that the sender is unblocked.
  • Capacity claims require the credit ledger to be joined with stream offsets, application consumption, buffer occupancy and congestion state.

A capacity dashboard sees a receiver raise MAX_DATA to 16 MiB and records 16 MiB of headroom. That is the first arithmetic mistake. The number is cumulative. Earlier stream offsets and final sizes already consume part of it. The second mistake is semantic: the value controls what the sender may send; it does not directly measure unused memory or application readiness.

RFC 9000 §4.1 defines two simultaneous limits. Connection flow control bounds stream data across the connection, while stream flow control prevents one stream from consuming the whole receive buffer. A sender must respect both. Usable permission for a write therefore depends on the greatest connection limit, connection-wide consumption, the greatest limit for that stream and its largest accounted offset.

The limits are absolute, not increments. MAX_DATA raises the maximum sum of stream offsets across the connection; MAX_STREAM_DATA raises the maximum offset on one stream. A later smaller value has no effect, and the sender must ignore frames that do not increase the limit. “Latest value” is the wrong metric. The correct ledger retains the maximum accepted value and the consumption governed by it.

RFC 9000 §19.9 makes connection accounting durable. All STREAM data counts, and the sum of final sizes across streams—including streams already in terminal states—must remain within the advertised maximum. RFC 9000 §4.5 defines final size as the credit consumed by a stream. Closing or resetting a stream settles that accounting; it does not erase the historical offsets and refill the connection window.

Per-stream arithmetic has another trap. RFC 9000 §19.10 accounts against the largest offset. Loss or reordering can push that offset beyond the amount of contiguous data currently available, while another STREAM frame might add bytes without moving it. Raw packet bytes or receive-buffer occupancy cannot substitute for the protocol's offset ledger.

Credit does correspond to a receiver commitment, but not to a reservation receipt. RFC 9000 §4.2 leaves timing and amount to the implementation. Frequent small updates cost control overhead; less frequent updates need larger increments and larger resource commitments. An implementation may autotune using RTT and the rate at which its application consumes data. Those inputs explain policy, not a fixed conversion from advertised credit to free RAM.

Nor is credit a throughput promise. RFC 9000 §4.3 warns that throughput becomes flow-control limited when available credit is not kept above the connection's bandwidth-delay product. This makes credit necessary for some rates, not sufficient. Congestion control, path loss, scheduling and the sender's own work can still prevent permitted bytes from reaching the receiver.

Packet loss can leave gaps that stop the application consuming data and freeing receive-buffer space. The receiver might have advertised a generous ceiling while its contiguous delivery frontier stalls. A rising limit and a healthy application-consumption rate can correlate; neither proves the other.

Blocked signals are also incomplete evidence. RFC 9000 §19.12 says a sender should report DATA_BLOCKED when connection flow control prevents a desired write. But §4.2 says the sender is not required to send the frame. A receiver must not wait for it before granting credit, or the sender could remain blocked for the rest of the connection. Absence of the frame is absence of an observation, not proof of spare credit.

The defensible operational record therefore has several columns: greatest connection limit, cumulative connection consumption, greatest per-stream limits, largest stream offsets, final sizes, observed blocked frames, application-consumption frontier, buffer occupancy, congestion window, RTT, loss and update time. MAX_DATA owns only the first transition: permission to extend the protocol ledger.