Internet-Draft iQUIC May 2026
x1co Expires 26 November 2026 [Page]
Workgroup:
Network Working Group
Published:
Intended Status:
Experimental
Expires:
Author:
X. x1co

Independent QUIC (iQUIC): A Low-Concurrency Operational Profile for HTTP/3

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 2 November 2026.

Table of Contents

1. 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:

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

2. Goals

The goals of iQUIC are:

3. Non-Goals

iQUIC does not:

4. Operational Model

iQUIC implementations SHOULD limit concurrent application-level requests per QUIC connection.

Mandatory HTTP/3 internal streams remain fully operational, including:

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

5. Connection Philosophy

Traditional HTTP/3 deployments frequently optimize for maximal multiplexing efficiency.

iQUIC instead prioritizes:

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

6. 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.

7. Performance Considerations

iQUIC deployments may experience:

8. 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.

9. Future Work

10. Normative References

[RFC9000]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, , <https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9001]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", RFC 9001, , <https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9114]
Bishop, M., "HTTP/3", RFC 9114, , <https://www.rfc-editor.org/rfc/rfc9114>.

Author's Address

x1co!
Brazil