HTTP/3 maps requests onto QUIC streams without erasing dependencies

A client-initiated bidirectional QUIC stream carries one HTTP/3 request and its response. HTTP/3 frames structure content inside that stream; QUIC packets can carry ranges from multiple streams. Separately, unidirectional streams carry connection control and QPACK instructions. Creating a request stream therefore depends on both usable transport state and the application's HTTP/3 rules. A bidirectional stream is not two unrelated requests: its directions are the request and response sides of the exchange. Unsupported frame placement, missing required control behavior, and invalid message sequencing still produce protocol errors despite reliable transport.

A lost range in request stream A need not prevent contiguous data for independent stream B from reaching its application. A remains ordered within its own stream, and a lost packet containing ranges for both can affect both. Congestion control, endpoint processing, bandwidth, and connection-level flow control remain shared. These distinctions matter when comparing HTTP/2 and HTTP/3: measure request completion under stated loss and dependency conditions, not merely whether the connection supports many streams. A change in transport mapping can remove one critical-path edge while leaving the final useful completion time unchanged for a dependent application.

QUIC uses stream-level and connection-level flow-control limits. These are cumulative permitted byte positions or totals, rather than HTTP/2's decrement-and-replenish DATA windows. A sender's new stream data must respect the stream's limit and the remaining connection allowance; retransmitting the same stream positions does not consume new flow-control credit as if they were new bytes. Stream-count limits separately govern how many streams can be created. Do not compare an HTTP/3 frame's useful body length directly with all QUIC accounting without considering the other bytes carried on that stream and the highest offsets already sent.

Supporting streams also need enough permission and processing to avoid deadlock. A receiver that stops reading control or compression instructions can delay application messages even when the network remains usable. Transport connection credit constrains aggregate new stream data, so one poorly managed consumer can affect others. On cancellation, reset and stop-sending mechanisms have distinct directional meanings, and final sizes remain relevant to flow-control accounting. A canceled request is not permission to forget all previously committed receive-space obligations or to assume that the server never performed its application effect. State transitions and business outcomes require separate evidence.

QPACK lets HTTP/3 use compressed field sections while controlling dependence on dynamic-table instructions delivered separately. A field section can reference an entry that the decoder has not yet received, so the affected stream may block within negotiated bounds. This is not the old TCP-wide delivery dependency, but it is still real waiting. Static references or literal fields make different size-versus-dependency tradeoffs. A measurement should identify whether delay came from missing request-stream bytes, missing encoder instructions, an application dependency, or shared congestion rather than labeling all of them generic head-of-line blocking.

The probability lab illustrates an independent-piece assumption, not HTTP/3 scheduling. Reset, explicitly set BOTH p=0.9 and n=2, predict the chance of all pieces arriving, then Play or Step. Reset and re-set BOTH p=0.9 and n=10 for comparison. The exact binomial bars count successes without stream identities, packet co-location, recovery, or correlated loss. They show why an operation requiring many pieces has a different completeness probability from one requiring few. Use the worked credit ledger and an actual dependency timeline, rather than these bars, to decide whether a particular HTTP/3 request can progress.