One connection. Many ordered byte streams.

Follow each stream through the same packet loss.

Each row shows three byte ranges in one sending direction. The first range already arrived.

Missing bytes delay later bytes on the same QUIC stream. Other streams can deliver contiguous received bytes. One packet can carry several streams.

The TCP row shows bytes after the first selected gap. QUIC streams share congestion control, and application dependencies can still cause waiting.

Source: RFC 9000 §2 and §13. Stream names represent a custom application, not HTTP/3 stream assignments.

Byte offsets determine delivery order.

Send the text ABCDEFGH on one stream. Offsets run from 0 through 7. A FIN at offset 8 declares the final size.

Later offsets wait for a gap. Duplicate data does not become new application bytes. FIN declares the end; it does not fill missing ranges.

Source: RFC 9000 §2.2, §3, and §19.8. Frame boundaries are not application message boundaries.

A stream allowance and a connection allowance both apply.

Each send adds four new bytes. These small limits make the accounting visible. Assume the congestion allowance permits every illustrated send.

RESET_STREAM ends one sending direction. It does not close the connection or refund the final size from flow-control accounting.

The receiver can grant more credit as it consumes data. An acknowledgment alone does not raise MAX_DATA or MAX_STREAM_DATA.

Source: RFC 9000 §3.5 and §4. This model isolates flow control from congestion control.

The low two bits describe the stream type.

Each of the four stream types has its own sequence. Increasing the stream index by one adds four to the stream ID.

Client bidirectional IDs start at 0; server bidirectional IDs start at 1. Client and server unidirectional IDs start at 2 and 3.

MAX_STREAMS limits how many streams of each directionality a peer can open. A stream ID is not a packet number.

Source: RFC 9000 §2.1 and §4.6.