WEB / WEB-04.04

QUIC’s transport model

Read QUIC v1’s UDP, TLS and stream roles alongside packet recovery and application-outcome boundaries.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Crypto handshake

QUIC v1 initial context
ClientHello is selected as prepared Initial CRYPTO; peer identity is not yet verified.
Client transport
Initial ready; TLS complete=false; confirmed=false
Server transport
awaiting Initial; TLS complete=false; confirmed=false
Initial flight arrived at server
The server received ClientHello/transport context; Initial protection is not peer-secret confidentiality.
Client transport
Initial ready; TLS complete=false; confirmed=false
Server transport
Initial received; TLS complete=false; confirmed=false
Local server crypto flight
The server prepares the selected response flight including its Finished. Peer Finished is still absent.
Client transport
Initial ready; TLS complete=false; confirmed=false
Server transport
server Finished emitted; awaiting client Finished; TLS complete=false; confirmed=false
Server crypto flight at client
The aggregated Initial/Handshake response arrived; selected server identity and Finished are verified. Sending own Finished is a separate condition.
Client transport
peer Finished verified; own Finished pending; TLS complete=false; confirmed=false
Server transport
server Finished emitted; awaiting client Finished; TLS complete=false; confirmed=false
Local Finished emission
Client TLS emitted its Finished for sending and reported local completion; server arrival has not occurred.
Client transport
own Finished emitted; TLS complete=true; confirmed=false
Server transport
server Finished emitted; awaiting client Finished; TLS complete=false; confirmed=false
Client Finished at server
The server verified peer Finished, giving TLS completion and server confirmation.
Client transport
own Finished emitted; TLS complete=true; confirmed=false
Server transport
peer Finished verified; TLS complete=true; confirmed=true
Local HANDSHAKE_DONE preparation
After completion the server prepares 1-RTT HANDSHAKE_DONE; the client has not received confirmation.
Client transport
own Finished emitted; TLS complete=true; confirmed=false
Server transport
confirmed=true; 1-RTT HANDSHAKE_DONE prepared
HANDSHAKE_DONE at client
The client completed the selected confirmation path. No HTTP request or application authorization is modeled.
Client transport
TLS complete=true; confirmed=true; app outcome unmodeled
Server transport
confirmed=true; 1-RTT HANDSHAKE_DONE prepared

Stream gap

Established 1-RTT context
Both peers are confirmed. The client sent NO for stream 0 in PN10, with no observed arrival. It also has TES ready in PN11 for stream 0 offset 2 and OK in PN12 for stream 4 offset 0; the receiver knows none of these bytes yet.
Client transport
1-RTT confirmed; PN10 unacknowledged; PN11/12 ready
Server transport
1-RTT confirmed; stream0 empty; stream4 empty
PN11 / stream0 offset2 arrived
TES is held; stream0 offset0 is missing so its contiguous prefix is empty.
Client transport
1-RTT confirmed; PN10 unacknowledged; PN11/12 ready
Server transport
PN11 received; s0 held[2,5); s0 prefix empty; s4 empty
Local stream0 read gate
Stream0 ordered data is not yet ready for application consumption; this local wait need not block another stream.
Client transport
1-RTT confirmed; PN10 unacknowledged; PN11/12 ready
Server transport
s0 gap blocks local read; held[2,5); s4 empty
PN12 / stream4 offset0 arrived
OK is contiguous on stream4 while stream0’s gap remains.
Client transport
1-RTT confirmed; PN10 unacknowledged; PN11/12 ready
Server transport
PN12 received; s4 prefix OK; s0 gap; held[2,5)
Local stream4 consumption
The application consumes stream4 OK while stream0 still has no ordered prefix.
Client transport
1-RTT confirmed; PN10 unacknowledged; PN11/12 ready
Server transport
s4 app read OK; s0 gap; ACK range[11,12] prepared
Packet-range ACK arrival
The client learned PN11–12 were received; this acknowledges neither PN10 nor business completion.
Client transport
ACK range[11,12] received; PN10 unacknowledged
Server transport
s4 app read OK; s0 gap; ACK range[11,12] prepared
Local time-threshold recovery
Selected age100>threshold90 ms and a later-packet ACK permit declaring PN10 lost. Required NO information is placed in new PN13.
Client transport
PN10 declared lost by selected time threshold; PN13 s0@0 NO prepared
Server transport
s4 app read OK; s0 gap; ACK range[11,12] prepared
PN13 information arrival
NO at offset0 fills the gap and stream0’s prefix becomes NOTES. A new packet number does not allocate new stream offsets. The following ACK is outside the branch.
Client transport
PN10 declared lost by selected time threshold; PN13 s0@0 NO prepared
Server transport
PN13 received; s0 prefix NOTES; s0 app unread; s4 consumed OK

PTO probe

PTO context
PN20 is selected as unacknowledged on a confirmed connection, without a loss declaration.
Client transport
1-RTT confirmed; PN20 unacknowledged
Server transport
1-RTT confirmed; no probe received
Local PTO expiry
PTO seeks acknowledgment information without automatically marking PN20 lost. Selected PN21 PING is prepared.
Client transport
PTO selected; PN21 PING prepared; PN20 fate unknown
Server transport
1-RTT confirmed; no probe received
Probe arrival
New PN21 PING reached the receiver without application data.
Client transport
PTO selected; PN21 PING prepared; PN20 fate unknown
Server transport
PN21 PING received; ACK21 prepared
Probe ACK arrival
The client learned about PN21 without a result for PN20 or application work.
Client transport
ACK21 received; PN20 fate remains unknown; app outcome unmodeled
Server transport
PN21 PING received; ACK21 prepared

Early-data policy

Resumption context selected
Prior context makes early data possible; application policy has not yet been evaluated.
Client transport
prior context selected; change-setting pending
Server transport
no early-data request received
Local operation classification
Unwanted repeated effects are a selected condition; no network request is sent.
Client transport
change-setting repetition-sensitive; early policy pending
Server transport
no early-data request received
Local early-data denial
Policy rejects this operation for 0-RTT and defers it to an ordinary 1-RTT application phase.
Client transport
0-RTT disallowed for operation; deferred to ordinary phase
Server transport
no early-data request received
A separate application result is needed
Deferral produces neither completed work nor replay. Later transaction/retry semantics remain separate even after 1-RTT.
Client transport
request not sent; no business outcome; retry semantics separate
Server transport
no early-data request received

ACTORS · STATE · DATA FLOW

QUIC builds its own transport over UDP

QUIC v1 uses UDP datagrams as its carrier but is more than a socket label claiming reliable UDP. Connection context, stream multiplexing, flow/loss/congestion control and packet protection are QUIC mechanisms. UDP supplies its header and ports; QUIC defines packets and frames inside that payload.

With TLS over TCP, TCP supplies an ordered stream and the TLS record layer protects it. QUIC uses the TLS 1.3 handshake for authentication and key negotiation, taking over packet protection rather than putting unchanged TLS records into a QUIC stream. Describing QUIC as replacing TLS or running over TCP assigns the roles incorrectly.

Handshake completion and confirmation are distinct peer knowledge

The normal scene summarizes Initial and Handshake CRYPTO messages as aggregated flights, not actual packet counts, padding or complete TLS encoding. After the server flight, the client performs selected identity/Finished checks; completion is reported once its own Finished is also sent. The server gains completion/confirmation upon receiving client Finished.

The selected client confirmation is receipt of the server’s 1-RTT HANDSHAKE_DONE frame, which is not sent before server completion. Optional confirmation from an ACK of a client 1-RTT packet is another permitted path, omitted here. Publicly derivable Initial protection is not peer-secret confidentiality; distinguish it from stronger Handshake/1-RTT protection.

Packet numbers are not stream offsets

Artifact PN10 carries NO at stream0 offset0; PN11 carries TES at offset2 on that stream; PN12 carries OK at stream4 offset0. A packet number identifies a transmission in its packet-number space, while an offset identifies bytes in a stream. Initial, Handshake and Application Data spaces are separate; the same small number across spaces is not the same event.

With PN10 absent, PN11 is held and stream0 has no ordered prefix. Arrival of PN12 can advance stream4 with OK; stream0’s gap does not inherently block that transport progress. Ordering is within each stream, not across streams. IDs 0 and 4 are selected client-initiated bidirectional stream IDs.

Loss recovery resends information, not old packets

ACK frames report packet ranges; acknowledging PN11–12 does not acknowledge PN10. In our selected RFC 9002 time-threshold branch, later PN12 is acknowledged; RTT80 ms times 9/8 gives a 90 ms threshold, exceeded by age100 ms. The sender declares PN10 lost and carries needed stream bytes again at offset0 in new packet PN13.

Whole old packets/frames are not retransmitted byte-for-byte; required information is placed in new frames and packets. PTO alone does not declare packet loss: it sends ack-eliciting probes to seek information. Our separate PTO branch leaves PN20’s fate undetermined and selects a new PN21 PING/ACK exchange, without measuring clocks, recovery implementations or loss causes.

Independent streams do not mean unlimited independent resources

QUIC advertises both stream and connection flow-control limits. Our stream0 limit5 and stream4 limit2 meet connection MAX_DATA7 through final offsets 5+2=7. Recovery of the same offsets does not consume flow credit twice. Congestion and transmitted-byte costs still apply; retransmission is not free.

Even when stream4 advances independently of the gap, connection congestion/flow budgets, CPU and application dependencies can be shared. HTTP/3 header-compression dependencies may create upper-layer waiting. This small example does not imply no head-of-line blocking anywhere or faster requests under every condition.

For the web, a gain is transport-visible multiplexing

HTTP/2 multiplexes application streams over a TCP byte stream whose request boundaries are invisible to TCP. A missing TCP range can delay later ordered delivery on that connection. HTTP/3 maps the same HTTP semantics to QUIC, making streams visible to transport loss recovery.

Integrated crypto/transport setup and a connection-ID architecture suited to path changes are further motivations, without simulating migration/path validation here. Benefits depend on network conditions, peer support and application dependencies. A client may use another supported HTTP transport when the UDP/HTTP3 path is unavailable; selecting a version is not a universal performance guarantee.

0-RTT is early data, not once-only execution

With prior resumption context a client may send some application data before the new handshake finishes; the server need not accept it. Replay risk particularly concerns application side effects. QUIC’s handling of duplicate transport frames does not automatically make business operations execute once.

Our local policy identifies unwanted repeated effects for change-setting and disallows early data, deferring it to the selected ordinary 1-RTT application phase. The branch sends no real request or replay. Deferral reduces early-data risk, while application retry, transaction and idempotency decisions remain separate.

Read every scenario without motion

ACK scope

Packet ranges were separated from stream offsets
ApplicationData ACK range 11–12 is inclusive, leaving PN10 unacknowledged. PN11 carries TES at stream 0 offset 2. A larger acknowledged packet number does not complete the earlier stream prefix.
Packet/policy ledger
ACK11–12 / PN10 not acknowledged
Transport/action gate
Gate pending
Business boundary
No verdict
Stream acceptance waited while a gap remained
Stream 0 has an empty prefix with held range [2,5). TES has arrived but NO is missing. Packet receipt and contiguous stream bytes are different states; waiting is not labeled malformed input or application denial.
Packet/policy ledger
ACK11–12 / PN10 not acknowledged
Transport/action gate
Stream0 prefix empty / held [2,5)
Business boundary
No verdict
ACK was not promoted to application processing
businessCompletionProven is false. ACK supplies transport-receipt information, not application reading, persistence or a user-setting change. Resource permission also does not follow from packet protection or stream ID.
Packet/policy ledger
ACK11–12 / PN10 not acknowledged
Transport/action gate
Stream0 prefix empty / held [2,5)
Business boundary
Packet receipt known / business outcome unknown
Information recovery used a new packet number
PN13 carries NO at offset 0, recovering information from PN10. The packet number is not reused; bytes at the same stream offset are carried again. PN13 acknowledgement is outside this branch.
Packet/policy ledger
New PN13 / existing offset0 NO
Transport/action gate
Stream0 prefix empty / held [2,5)
Business boundary
Packet receipt known / business outcome unknown
Flow accounting remained separate after prefix completion
NO and TES form NOTES on stream 0 while stream 4 retains OK. Recovery at an existing offset consumes no new flow credit. Unique final offsets total 5+2=7; connection accounting is not a sum of transmitted bytes.
Packet/policy ledger
New PN13 / existing offset0 NO
Transport/action gate
Stream0 NOTES / unique offsets sum7
Business boundary
Packet receipt known / business outcome unknown
Transport results retained an unknown business verdict
Contiguous content is established in this ledger without running real QUIC, cryptography, certificates or application processing. Independent stream progress does not remove shared congestion, credit or application dependencies.
Packet/policy ledger
New PN13 / existing offset0 NO
Transport/action gate
Stream0 NOTES / unique offsets sum7
Business boundary
Stream prefix complete / business unmeasured

Early action

The operation’s repeated effect became a policy input
change-setting is supplied as having unwanted effects if repeated. A prior resumption context does not make it suitable for early data. Operation semantics are evaluated separately from transport encryption.
Packet/policy ledger
change-setting / repeated effects unwanted
Transport/action gate
Gate pending
Business boundary
No verdict
The early gate deferred the sensitive operation
permittedInEarlyData is false and deferUntil is the ordinary selected 1-RTT application phase. actual0RTTRequestSent stays false. A local policy decision does not establish sending or successful execution.
Packet/policy ledger
change-setting / repeated effects unwanted
Transport/action gate
Early action withheld / no 0-RTT request sent
Business boundary
No verdict
Encryption was not treated as a once-only guarantee
replayProtectionPerfect and oneRttGuaranteesBusinessOnceOnly are false. Deferral narrows early-data risk, but business idempotency and current authorization remain necessary. The ordinary phase alone does not promise exactly once.
Packet/policy ledger
change-setting / repeated effects unwanted
Transport/action gate
Early action withheld / no 0-RTT request sent
Business boundary
Deferred / business once-only not guaranteed
Crypto phases retained distinct trust predicates
Initial protection does not provide peer-secret confidentiality. Handshake and 1-RTT negotiated protection have different contexts. An encrypted-packet label is not verified service identity or an application grant.
Packet/policy ledger
Initial ≠ negotiated peer-secret protection
Transport/action gate
Early action withheld / no 0-RTT request sent
Business boundary
Deferred / business once-only not guaranteed
Completion and confirmation were separated by endpoint
Client TLS completion requires verified peer Finished and sending its own Finished. Selected client confirmation is HANDSHAKE_DONE arrival; server confirmation occurs at its own TLS completion. These semantic conditions are not cryptographic execution.
Packet/policy ledger
Initial ≠ negotiated peer-secret protection
Transport/action gate
Endpoint-local completion / selected confirmation separate
Business boundary
Deferred / business once-only not guaranteed
The action outcome remained unknown
The review demonstrates the deferral policy and phase conditions without executing a request, replay or business mutation. Current user/resource policy and actual application results need separate evidence in the ordinary phase.
Packet/policy ledger
Initial ≠ negotiated peer-secret protection
Transport/action gate
Endpoint-local completion / selected confirmation separate
Business boundary
Policy defers / actual action outcome unknown

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: packet ACK is application delivery

A QUIC packet ACK does not prove every earlier stream offset is contiguous or application-processed. A stream with a gap can wait even when later packets are acknowledged.

Separate packet receipt, stream-prefix and business-outcome evidence. ACKs for PN11–12 do not fill stream0’s gap.

Broken assumption: every protected QUIC packet has equal trust

Equating Initial protection with negotiated Handshake/1-RTT confidentiality moves verified-peer state too early. TLS completion and QUIC confirmation carry different endpoint knowledge.

Track encryption level, packet-number space and verification/confirmation status explicitly. Strong wire protection alone does not authorize application resources.

Broken assumption: early data executes side effects once

Accepting repetition-sensitive operations in 0-RTT exposes application effects to replay risk. It requires unwanted repeated effects and a policy allowing early data.

Define replay-safe scope, defer unsuitable work or disable early data. Encryption alone does not supply business idempotency.

Read every scenario without motion

Offset ledger

Two numbering families retained separate columns
PN11 carries stream 0 offset 2, PN12 stream 4 offset 0 and PN13 stream 0 offset 0. Packet numbers belong to a connection space; offsets belong to streams. Concatenating by packet number produces incorrect content.
Packet/timer record
PN11:S0@2 / PN12:S4@0 / PN13:S0@0
Recovery comparison
Gate pending
Evidence verdict
No verdict
The stream-prefix ledger was reconstructed independently
After PN11, stream 0 has no prefix; after PN12, stream 4 holds OK. PN13 fills stream 0's gap and completes NOTES. Stream 4 byte ordering does not depend on stream 0's gap; shared connection limits still apply.
Packet/timer record
PN11:S0@2 / PN12:S4@0 / PN13:S0@0
Recovery comparison
Prefixes: S0 NOTES / S4 OK
Evidence verdict
No verdict
ACK-range scope was separated from stream bytes
inclusivePacketRanges [11,12] reports receipt of PN11 and PN12, excluding PN10. Stream 0 completion comes from its offset ledger rather than that range. ApplicationData space is not mixed with other packet spaces.
Packet/timer record
ACK receipt only / space ApplicationData
Recovery comparison
Prefixes: S0 NOTES / S4 OK
Evidence verdict
No verdict
Flow credit was calculated from unique information
Final offsets are 5 for stream 0 and 2 for stream 4, totaling sumUniqueFinalOffsets 7. PN13 recovers the same offset information. Duplicate transmission is not counted as new unique flow data.
Packet/timer record
ACK receipt only / space ApplicationData
Recovery comparison
Unique final offsets 5+2=7
Evidence verdict
No verdict
Local reconstruction was not a wire capture
Prefix and accounting are consistent for these semantic packet summaries. Wire encoding, cryptographic verification and actual delivery are unmeasured. The connection alias is not a real wire ID; mapping is limited to this record.
Packet/timer record
ACK receipt only / space ApplicationData
Recovery comparison
Unique final offsets 5+2=7
Evidence verdict
Ledger consistent / QUIC runtime unmeasured
Business outcomes required new evidence
Transport receipt needs endpoint ACK evidence in the same packet-number space; ordered data needs the corresponding stream offset/prefix information. Business completion needs a correlated application outcome or commit record. Fields from one layer cannot replace another's.
Packet/timer record
ACK receipt only / space ApplicationData
Recovery comparison
Unique final offsets 5+2=7
Evidence verdict
Needed: scoped application outcome

Loss/PTO scope

Time-threshold inputs were separated from measurement
latestRttMs and smoothedRttMs are 80 with granularity 1 supplied. The selected RFC9002 threshold calculation is not a measured timer. Missing PN10 and largest acknowledged PN12 share one ApplicationData context.
Packet/timer record
RTT80/80 / granularity1 / missingPN10
Recovery comparison
Gate pending
Evidence verdict
No verdict
The selected loss threshold was calculated independently
max(9/8 × max(80,80),1) yields 90 ms. Elapsed 100 ms exceeds it, making selectedDeclaredLost true. This local classification is neither packet arrival nor the actual cause of loss.
Packet/timer record
RTT80/80 / granularity1 / missingPN10
Recovery comparison
Threshold90ms / elapsed100ms / declared lost
Evidence verdict
No verdict
PTO was read as another context and event
The PTO record supplies probe PN21 with PING for original PN20 and timeoutSeconds not-computed. Sending a probe does not declare PN20 lost from PTO alone; priorPnMarkedLostFromPtoAlone remains false.
Packet/timer record
PN21 probe / PTO-alone loss false
Recovery comparison
Threshold90ms / elapsed100ms / declared lost
Evidence verdict
No verdict
A probe ACK was not a business result
probeAckBusinessOutcome is false. PING probing may provide transport-progress information, not note persistence or action completion. Timeout, declared loss and application failure retain separate reasons.
Packet/timer record
PN21 probe / PTO-alone loss false
Recovery comparison
Probe receipt ≠ business completion
Evidence verdict
No verdict
The missing-arrival cause remained unknown
actualCauseOfMissingArrival is not-determined. Crossing the selected threshold supplies no causal attribution. Establishing a network cause without actual packet-loss, congestion or timing observations exceeds scope.
Packet/timer record
PN21 probe / PTO-alone loss false
Recovery comparison
Probe receipt ≠ business completion
Evidence verdict
UNKNOWN: cause of missing arrival
Recovery regression stayed with the right owner
Reviewing a loss declaration requires the sender's send/ACK times, RTT calculation and packet-number space together. A PTO-probe ACK establishes neither PN20's fate nor an application outcome. This compares supplied numbers without measuring real loss recovery, migration or HTTP/3 behavior.
Packet/timer record
PN21 probe / PTO-alone loss false
Recovery comparison
Probe receipt ≠ business completion
Evidence verdict
Recheck threshold/space/offset; runtime separate

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Compute the two number families separately

PN10/11/12/13 belong to one Application Data space. Stream0 offsets 0+2 and 2+3 reconstruct NOTES; stream4 offset0+2 gives OK. PN13 is a new transmission carrying the same NO information at offset0.

Compute max(9/8×max(80,80),1)=90 ms. This local decision is not a packet arrival; PTO alone does not make the same loss declaration.

Track completion and confirmation boundaries

Client verification of peer Finished is distinct from sending its own Finished. Server selected completion/confirmation follows peer Finished arrival; the client becomes confirmed at selected HANDSHAKE_DONE arrival.

The flight summary is not a full TLS/QUIC parser or certificate check. Snapshot ownership explains protocol roles without producing actual cryptographic results.

State conditions for performance and early-data policy

Evaluate stream independence alongside connection resources. MAX_DATA7 exhaustion or congestion can affect new data on both streams, with additional application dependencies.

Classify replay safety using business semantics. Deferral in the early-policy branch does not mean a request succeeded; ordinary-phase execution and its application outcome are separate.

NOW APPLY IT TO THE CASE

How are packet receipt, stream prefixes, crypto phases and business policy separated?

PN11 carries TES at stream 0 offset 2, leaving an empty prefix while NO is missing. Stream 4 progresses with OK; PN13 recovers NO using a new packet number. change-setting is withheld from early data and needs separate business-outcome evidence.

Where does the connection carrying the response differ from application outcome? Do not substitute network or transport evidence for body-parsing or DOM success.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Packet/offset, crypto-phase and early-policy ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "version": "QUIC v1 (RFC9000/9001/9002)",
    "carrier": "UDP datagrams",
    "addresses": [
      "192.0.2.10:54000",
      "198.51.100.200:443"
    ],
    "tlsVersion": "TLS 1.3",
    "fullCryptoOrHTTP3Implementation": false,
    "certificateVerification": "selected-success-condition-not-executed",
    "connectionId": "teaching-alias-only-no-wire-ID"
  },
  "handshake": {
    "cryptoFlights": "aggregated semantic arrivals, not one packet per flight",
    "clientCompletionCondition": [
      "peer Finished verified",
      "own Finished sent"
    ],
    "serverCompletionCondition": [
      "own Finished sent",
      "peer Finished verified"
    ],
    "serverConfirmation": "on server TLS completion",
    "clientSelectedConfirmation": "HANDSHAKE_DONE arrival in 1-RTT",
    "alternativeClientConfirmation": "optional ACK of client 1-RTT packet; not selected",
    "initialPacketsProvidePeerSecretConfidentiality": false
  },
  "streamPackets": [
    {
      "pn": 10,
      "space": "ApplicationData",
      "protection": "1-RTT",
      "streamId": 0,
      "offset": 0,
      "payload": "NO",
      "bytes": 2,
      "selectedArrival": false
    },
    {
      "pn": 11,
      "space": "ApplicationData",
      "protection": "1-RTT",
      "streamId": 0,
      "offset": 2,
      "payload": "TES",
      "bytes": 3,
      "selectedArrival": true
    },
    {
      "pn": 12,
      "space": "ApplicationData",
      "protection": "1-RTT",
      "streamId": 4,
      "offset": 0,
      "payload": "OK",
      "bytes": 2,
      "selectedArrival": true
    },
    {
      "pn": 13,
      "space": "ApplicationData",
      "protection": "1-RTT",
      "streamId": 0,
      "offset": 0,
      "payload": "NO",
      "bytes": 2,
      "selectedArrival": true,
      "informationRecoveryOfPn": 10
    }
  ],
  "streamSnapshots": [
    {
      "afterPn": 11,
      "stream0Prefix": "",
      "stream0Held": [
        2,
        5
      ],
      "stream4Prefix": ""
    },
    {
      "afterPn": 12,
      "stream0Prefix": "",
      "stream0Held": [
        2,
        5
      ],
      "stream4Prefix": "OK"
    },
    {
      "afterPn": 13,
      "stream0Prefix": "NOTES",
      "stream0Held": null,
      "stream4Prefix": "OK"
    }
  ],
  "ackRanges": {
    "space": "ApplicationData",
    "inclusivePacketRanges": [
      [
        11,
        12
      ]
    ],
    "largestAcknowledged": 12,
    "pn10Acknowledged": false,
    "businessCompletionProven": false
  },
  "timeThresholdDecision": {
    "profile": "selected RFC9002 recommended threshold, no measured timer",
    "missingPn": 10,
    "largestAcknowledged": 12,
    "latestRttMs": 80,
    "smoothedRttMs": 80,
    "timerGranularityMs": 1,
    "multiplierNumerator": 9,
    "multiplierDenominator": 8,
    "thresholdMs": 90,
    "elapsedSincePn10SentMs": 100,
    "selectedDeclaredLost": true,
    "actualCauseOfMissingArrival": "not-determined"
  },
  "pto": {
    "context": "established confirmed connection; ApplicationData space",
    "originalUnacknowledgedPn": 20,
    "probePn": 21,
    "probeFrame": "PING",
    "priorPnMarkedLostFromPtoAlone": false,
    "probeAckBusinessOutcome": false,
    "timeoutSeconds": "not-computed"
  },
  "flowControl": {
    "streamLimits": {
      "0": 5,
      "4": 2
    },
    "connectionMaxData": 7,
    "uniqueStreamFinalOffsets": {
      "0": 5,
      "4": 2
    },
    "sumUniqueFinalOffsets": 7,
    "recoveryAtExistingOffsetConsumesNewFlowCredit": false,
    "congestionControlSharedAcrossConnection": true
  },
  "comparison": {
    "tcpTransportOrdering": "one ordered byte stream per connection",
    "http2StreamsVisibleToTCP": false,
    "quicOrdering": "ordered bytes within each stream; no cross-stream order",
    "independentProgressUnlimited": false,
    "sharedConstraints": [
      "connection congestion",
      "connection flow credit",
      "CPU/application dependencies",
      "HTTP3 QPACK dependencies if present"
    ]
  },
  "earlyPolicy": {
    "priorResumptionContextSelected": true,
    "operation": "change-setting",
    "unwantedEffectsIfRepeated": true,
    "permittedInEarlyData": false,
    "deferUntil": "ordinary selected 1-RTT application phase",
    "actual0RTTRequestSent": false,
    "replayProtectionPerfect": false,
    "oneRttGuaranteesBusinessOnceOnly": false
  },
  "limits": {
    "streamIds": "0 and 4 are selected client-initiated bidirectional streams",
    "streamBranchStarts": "established confirmed 1-RTT context",
    "recoveryPn13Ack": "outside branch",
    "migrationAndPathValidation": "not-simulated",
    "wireEncodingCryptoKeysCongestionAlgorithm": "omitted"
  }
}

handshake: Endpoint-local completion versus selected HANDSHAKE_DONE confirmation.
streamPackets: Recovery at the same stream offset with a new packet number.
ackRanges: Inclusive packet ranges, not stream prefixes or business outcomes.
flowControl: Unique stream-offset totals consume connection credit.
earlyPolicy: Locally excludes a repetition-sensitive operation from early data.

An inert semantic summary for QUIC v1, without full datagrams, ciphers, certificates, handshake messages, recovery implementation, migration, HTTP3/QPACK or request/replay execution.

Two reality checks

QUIC lacks reliability because it uses UDP.

UDP is the carrier; QUIC supplies its own ordered streams, acknowledgments/loss recovery and congestion mechanisms.

Independent QUIC streams remove every kind of waiting.

One stream gap need not block another through transport ordering, but connection resources and upper-layer dependencies remain shared.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Stream 0 offset 0 is missing and offset 2 is held. Stream 4 offset 0 OK arrived. Can stream 4 progress?

Yes; stream 4 has prefix OK in the selected snapshot.
No; QUIC holds all streams in one ordered byte queue.

Read the explained answer

Yes; stream 4 has prefix OK in the selected snapshot. — The stream 0 gap does not break stream 4 byte ordering. Shared congestion/flow/application limits still exist.

PN13 recovers the same offset 0 NO information. Is PN10 reused?

Selected lesson artifact fields; teaching example

streamPackets[0]: {"pn":10,"space":"ApplicationData","protection":"1-RTT","streamId":0,"offset":0,"payload":"NO","bytes":2,"selectedArrival":false}
streamPackets[3]: {"pn":13,"space":"ApplicationData","protection":"1-RTT","streamId":0,"offset":0,"payload":"NO","bytes":2,"selectedArrival":true,"informationRecoveryOfPn":10}

No; the information uses a new packet number at the same stream offset.
Yes; the packet number must match whenever the stream offset matches.

Read the explained answer

No; the information uses a new packet number at the same stream offset. — PN13 carries information from PN10. Stream offset is preserved; existing-offset recovery consumes no new unique flow credit.

change-setting is disallowed in early data. Why do resumption context and even 1-RTT not guarantee business exactly-once?

Read the explained answer

The selected prior context does not eliminate early-data replay risk; an operation with unwanted repeated effects is deferred to the ordinary 1-RTT phase. This deferral does not prove exactly-once behavior for application retries/duplicates. Business invariants and idempotency remain separate requirements.

□ I tied early-data policy to operation effects.

□ I did not treat 1-RTT as exactly-once.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport1 Overview; 2 Streams; 2.1 Stream Types and Identifiers · 4.1 Data Flow Control; 5 Connection ID; 7 Cryptographic and Transport Handshake · 12.3 Packet Number Spaces; 13.3 Retransmission of Information; 19.20 HANDSHAKE_DONE Frames
RFC 9001 — Using TLS to Secure QUIC3 Protocol Overview; 4.1.1 Handshake Complete; 4.1.2 Handshake Confirmed · 4.6 0-RTT; 5 Packet Protection; 9.2 Replay Attacks with 0-RTT
RFC 9002 — QUIC Loss Detection and Congestion Control3 Design of the QUIC Transmission Machinery · 6.1.2 Time Threshold; 6.2 Probe Timeout; 7 Congestion Control
RFC 9114 — HTTP/31.1 Prior Versions of HTTP; 1.2 Delegation to QUIC · 2 HTTP/3 Protocol Overview; 3.1 Discovering an HTTP/3 Endpoint; 3.3 Connection Reuse
RFC 9293 — Transmission Control Protocol (TCP)3.1 Header Format; 3.4 Sequence Numbers · 3.3.2 State Machine Overview; 3.5.3 Reset Processing; 3.6 Closing a Connection; 3.6.1 Half-Closed Connections · 3.7 Segmentation; 3.8.1 Retransmission Timeout; 3.8.6 Managing the Window
RFC 768 — User Datagram ProtocolIntroduction; Format; Fields; User Interface
RFC 5737 — IPv4 Address Blocks Reserved for Documentation3 Documentation Address Blocks

YOUR NOTES / THIS BROWSER

QUIC’s transport model

1. Core · Mechanism

Crypto handshake

Stream gap

PTO probe

Early-data policy

QUIC builds its own transport over UDP

Handshake completion and confirmation are distinct peer knowledge

Packet numbers are not stream offsets

Loss recovery resends information, not old packets

Independent streams do not mean unlimited independent resources

For the web, a gain is transport-visible multiplexing

0-RTT is early data, not once-only execution

2. Red · Trust & Impact

ACK scope

Early action

Broken assumption: packet ACK is application delivery

Broken assumption: every protected QUIC packet has equal trust

Broken assumption: early data executes side effects once

3. Blue · Secure development & defense

Offset ledger

Loss/PTO scope

Compute the two number families separately

Track completion and confirmation boundaries

State conditions for performance and early-data policy

How are packet receipt, stream prefixes, crypto phases and business policy separated?

Two reality checks

Stream 0 offset 0 is missing and offset 2 is held. Stream 4 offset 0 OK arrived. Can stream 4 progress?

PN13 recovers the same offset 0 NO information. Is PN10 reused?

change-setting is disallowed in early data. Why do resumption context and even 1-RTT not guarantee business exactly-once?

Sources and scope