| Internet-Draft | QUIC QoS Optimization | July 2026 |
| Li, et al. | Expires 5 January 2027 | [Page] |
This document defines a fine-grained, dynamically adaptive QoS mechanism for QUIC transport. The mechanism encodes a priority mapping table index in the QUIC Destination Connection ID (DCID), enabling host NICs or user gateways to translate QUIC-layer service priority information into network-layer QoS mechanisms (DSCP/ToS per RFC 2474) and traffic engineering policies (SRv6 TE, MPLS TE, etc.) for end-to-end QoS enforcement. Stream IDs carry endpoint priority information for local scheduling. The mechanism supports host-side, network-side, and coordinated deployment modes with no intrusion into the host protocol stack.¶
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 5 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Vertical industry services (connected vehicles, remote healthcare, etc.) and AI-driven applications increasingly demand differentiated network service quality. QUIC [RFC9000], as a modern transport protocol, provides encryption, multiplexing, and connection migration, but currently lacks mechanisms for end-to-end QoS enforcement across the network path.¶
QUIC's existing stream priority mechanism operates only at the endpoints. Intermediate network devices (routers, switches) do not inspect or act on QUIC priority markings because they are encrypted within the QUIC payload. Additionally, QUIC Datagrams [RFC9221] are typically excluded from priority scheduling mechanisms.¶
This document proposes a mechanism that bridges the gap between QUIC transport-layer priorities and network-layer QoS enforcement by leveraging the Destination Connection ID field, which remains visible in the QUIC header even under encryption, as a carrier for priority mapping table indices.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
QUIC stream priorities are enforced through application-layer marking, transport-layer scheduling, and congestion control coordination. High-priority streams receive preferential packet encapsulation, loss retransmission, and potentially larger congestion windows. However, these priorities are effective only at the endpoints. Intermediate network devices do not process QUIC priority information, and the network layer has no awareness of QUIC-layer priorities, preventing end-to-end precise QoS enforcement.¶
Per [RFC9000] and [RFC9221], QUIC priority mechanisms are primarily designed for streams. Datagrams, as an unreliable transport mode, are typically not included in priority scheduling mechanisms.¶
QUIC transport-layer priority information cannot be directly mapped to network-layer DSCP/ToS mechanisms or traffic engineering policies, resulting in a broken end-to-end QoS enforcement chain.¶
The core idea is to use the QUIC Destination Connection ID (DCID) as a carrier for priority information. Service priority is encoded as an index value in the DCID. A priority mapping table on the host NIC or user gateway translates this index into the real Connection ID and corresponding network-layer QoS parameters.¶
The DCID is structured as follows: DCID = Index_Prefix | Frame_Type | Stream_ID | Priority. Index Prefix: configurable byte pattern (e.g., 0xAAB00000) identifying this DCID as a mapping table index. Frame Type: 0 = STREAM frame, 1 = DATAGRAM frame. Stream ID: identifies the associated stream. Priority: optional application-specified fine-grained priority (e.g., differentiating CSS, JS, HTML objects within a web page).¶
An implementation MUST construct a priority mapping table. The table deployment location depends on the deployment mode: on the host NIC for host-side deployment, or on the user gateway/router for network-side deployment. Each mapping table entry contains: Index (the DCID index value); Real DCID (the actual Connection ID used in network transmission); ToS/DSCP (network-layer QoS marking per [RFC2474]); TE Policy (traffic engineering policy identifier); Reserved (set to 0, reserved for future finer-grained QoS constraints).¶
In host-side deployment mode: (1) The application issues a QUIC connection request via API, specifying service priority requirements. (2) Before the API request enters the host protocol stack, a mapping table index is generated and replaces the original DCID. This step MUST NOT intrude upon the host protocol stack. (3) The host QUIC stack processes the connection normally; outbound QUIC packets carry the index value as DCID. (4) The host NIC (or NIC driver) intercepts outbound packets, looks up the priority mapping table using the DCID index: replaces the DCID with the real Connection ID, sets the IP header ToS/DSCP field, and selects the corresponding TE Policy path. (5) Packets traverse the network with QoS and TE enforcement.¶
The Priority Controller is responsible for generation, update, and management of the priority mapping table. It MAY be deployed as: a standalone component; a functional module within a network controller (e.g., SDN controller); integrated within the NIC or user gateway/router. Applications MAY configure whether the ToS/TC/DSCP and TE Policy values in the mapping table are allowed to auto-adjust dynamically based on network quality feedback.¶
Host-Side Deployment: Priority mapping table resides on the host NIC; no network-side changes required. Network-Side Deployment: Priority mapping table resides on the user gateway/router; no host-side changes required. Coordinated Deployment: Host-side and network-side collaborate on priority mapping.¶
Mapping Table Confidentiality: The priority mapping table contains real Connection IDs and QoS policy information, which constitute sensitive data. Storage and transmission of mapping table information MUST be encrypted. Index Prefix Collision: If a third party can guess the index prefix, non-mechanism traffic could be incorrectly intercepted and processed. The index prefix SHOULD have sufficient randomness or be negotiated out-of-band. Priority Escalation Attack: Malicious applications may attempt to forge high-priority identifiers to obtain unwarranted QoS treatment. The Priority Controller MUST authenticate and authorize application priority requests. Stack Non-Intrusion Safety: The DCID replacement at the API layer SHOULD NOT introduce new attack surfaces. Implementations SHOULD ensure the security of the index generation process.¶
This document requests IANA consideration for: (1) If a standardized index prefix value is adopted, reserved space or a registered prefix within the QUIC Connection ID format may be needed. (2) If the DCID encoding format requires interoperation with the QUIC standard, registration of a new QUIC transport parameter type may be required.¶