Brazil x1colegal@outlook.com.br

This document describes iQUIC (Independent QUIC), an experimental operational profile for HTTP/3 over QUIC. iQUIC aims to reduce aggressive application-level multiplexing behavior commonly associated with HTTP/3 deployments while preserving compatibility with QUIC, TLS 1.3, and HTTP/3 semantics. Instead of removing mandatory HTTP/3 internal streams, iQUIC limits concurrent application requests per QUIC connection and encourages the use of multiple independent QUIC keep-alive sessions.

Introduction HTTP/3 introduces multiplexed HTTP semantics over QUIC transport streams. While QUIC solves transport-layer Head-of-Line blocking present in TCP-based HTTP/2 deployments, modern HTTP/3 deployments frequently utilize large numbers of concurrent streams within a single QUIC connection. This behavior introduces operational complexity, including:

• Stream explosion
• Large long-lived super-connections
• Complex prioritization logic
• Difficult debugging and observability
• Cross-request coupling

iQUIC proposes a simplified operational model inspired by HTTP/1.1 keep-alive behavior.

Goals The goals of iQUIC are:

• Preserve compatibility with QUIC and HTTP/3
• Preserve TLS 1.3 security guarantees
• Reduce aggressive request multiplexing
• Encourage request isolation
• Improve operational simplicity
• Improve implementation predictability

Non-Goals iQUIC does not:

• Replace QUIC transport
• Replace HTTP/3 framing
• Remove TLS 1.3 requirements
• Remove mandatory HTTP/3 internal streams
• Define a new wire format

Operational Model iQUIC implementations SHOULD limit concurrent application-level requests per QUIC connection. Mandatory HTTP/3 internal streams remain fully operational, including:

• Control streams
• QPACK encoder streams
• QPACK decoder streams

An example iQUIC deployment MAY allow only one active application request per QUIC connection.

Connection Philosophy Traditional HTTP/3 deployments frequently optimize for maximal multiplexing efficiency. iQUIC instead prioritizes:

• Request isolation
• Predictable behavior
• Reduced cross-request coupling
• Simplified debugging characteristics

This behavior intentionally resembles HTTP/1.1 keep-alive operational patterns while retaining QUIC transport capabilities.

Security Considerations iQUIC relies entirely on existing QUIC and TLS 1.3 security properties. This document introduces no new cryptographic mechanisms. All QUIC encryption and authentication requirements from RFC 9001 remain mandatory.

Performance Considerations iQUIC deployments may experience:

• Increased connection counts
• Reduced multiplexing efficiency
• Improved request isolation
• Simplified failure behavior

Compatibility Considerations iQUIC is designed as an operational profile rather than a protocol replacement. Standard HTTP/3 clients and servers MAY interoperate with iQUIC deployments without wire-format modifications.

Future Work

• Explicit iQUIC negotiation mechanisms
• HTTP/3 SETTINGS extensions
• Browser experimentation
• Independent recovery policies

Normative References