Share congestion control and discard stale sends
06No DATAGRAM flow-control credits does not mean unlimited sending. Reliable and unreliable traffic use the QUIC connection’s congestion controller, which regulates load on the network.
The chosen implementation expires the queued update without sending it. An application notification is optional; the deadline is not an extra DATAGRAM field.
Source for this drawing: RFC 9221 · Read RFC section 5.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Congestion control
- Regulating traffic to avoid overloading the network.
- Sending expiration
- An optional local time after which a queued update should be discarded.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
When congestion control does not allow sending, the sender MUST either delay a DATAGRAM until allowed or drop it without sending. It MAY notify the application when dropping it.
- When congestion control does not allow sending, the sender MUST either delay a DATAGRAM until allowed or drop it without sending. It MAY notify the application when dropping it.
- DATAGRAM frames SHOULD be sent as soon as possible subject to constraints such as congestion control. They MAY be coalesced with other frames; pacing can also delay a send.
- In the delayed example the controller first blocks transmission, then permits the queued datagram. Neither state promises a particular latency or guaranteed delivery.
- An implementation can optionally expose an application-specified sending expiration time. The chosen deadline example drops an expired update without transmitting it; expiration support is not mandatory.
- QUIC implementations SHOULD offer relative-priority APIs for DATAGRAM frames and streams. Priority does not bypass congestion control, peer frame limits or receiver resource limits.
The controller gate is conceptual, not an RFC-mandated queue layout or scheduler. The deadline is an optional local policy, separate from a wire field: DATAGRAM defines no timestamp/deadline field. Dropped-before-send means the peer does not receive this update and no transport retransmission is implied.
Read the RFC section ↗