| Internet-Draft | QoE-Driven Transport | November 2025 |
| Zhang, et al. | Expires 14 May 2026 | [Page] |
This document specifies requirements for a QoE-driven transport system, which enables network stack to adjust its transport strategy according to the QoE intent expressed by applications. The Application Layer MUST provide a structured QoE Intent Signal detailing performance objectives to the transport layer. A QoE Mapping Engine is required to translate this intent into adaptive transport strategies. The Transport Protocol Stack SHOULD continuously feed a Transport Feedback Signal on current performance and network status back to the Application Layer, thereby closing the control loop essential for continuous QoE optimization.¶
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 14 May 2026.¶
Copyright (c) 2025 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.¶
The rigid separation inherent in traditional networking models between the Application Layer and the Transport Layer frequently results in suboptimal Quality of Experience (QoE) for end-users. The Transport Layer's reliance on generic network metrics (e.g., RTT, throughput) is insufficient, as these metrics fail to correlate accurately with application-specific QoE contexts (e.g., video stall rate or guaranteed low-latency stability required for real-time gaming).¶
This structural deficiency is incapable of meeting the diverse and dynamic QoE demands of modern applications. A common conflict arises, for instance, when strategies focused on maximizing aggregate throughput actively undermine the requirements for stable low-latency. To fundamentally resolve this performance gap, the Transport Layer SHOULD evolve to become QoE-aware and cooperate directly with the Application Layer. This document specifies the requirements for a QoE-Driven Transport Paradigm, establishing a closed-loop control system defined by three core functional flows essential for cross-layer cooperation: Intent Declaration, Adaptive Strategy, and Feedback Optimization. This architecture mandates a fundamental shift in responsibility to ensure continuous QoE management.¶
QoE: Quality of Experience. QoE Intent Signal: The structured, encoded declaration of the application's real-time QoE goals and priorities. QoE Mapping Engine: The logical component responsible for translating the abstract QoE Intent Signal into concrete, executable Transport Strategy. Transport Strategy: The specific, low-level control commands generated by the Mapping Engine that modify the Transport Protocol Stack's behavior. Transport Feedback Signal: The signal containing real-time performance metrics (e.g., RTT, achieved throughput, loss rate) provided by the Transport Stack back to the Application Layer.¶
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.¶
The QoE-Driven Transport Paradigm is based on a closed-loop system where responsibility is fundamentally shifted to achieve Application-Aware transport. This architecture is composed of three interconnected requirements for the system's components:¶
The Application Layer MUST provide a structured QoE Intent Signal to the transport system, explicitly declaring real-time performance objectives and shifting the optimization target from generic metrics (e.g., RTT) to user-centric QoE goals (e.g., stall avoidance).¶
A QoE Mapping Engine is fundamentally required. It MUST process the QoE Intent Signal and translate those high-level goals into concrete, adaptive transport strategies, including dynamic adjustments to congestion control algorithms, scheduling policies, and pacing rates.¶
The Transport Protocol Stack SHOULD continuously furnish a Transport Feedback Signal on current performance and network status back to the Application Layer. This explicit linkage enables the Application Layer to accurately assess the effectiveness of the current transport strategy relative to the desired subjective QoE goal. This feedback closes the control loop, enabling the Application Layer to adjust its subsequent QoE Intent Signal, ensuring continuous QoE optimization.¶
The flow diagram below illustrates the relationship between these components:¶
+--------------------------------------------------------------+ | Application Layer | | +-----------+ +----------+ +----------+ +-----+ |<------- | | Video | | Web | | Gaming | | ... | | | | +-----------+ +----------+ +----------+ +-----+ | | +--------------------v----------------------v------------------+ | | Notification | | QoE Signal | v | +--------------------------------------------------------------+ ^ | +----------------------------------------------------------+ | | | | QoE Mapping Engine | | | | | Parse QoE Intent, Translate Transport Strategy | | | | +----------------------------------------------------------+ | | +--------------------v----------------------v------------------+ ^ | | | Transport Strategy Transport Feedback | v | +--------------------------------------------------------------+ | | Transport Protocol Stack | | | | | | +----------+ +----------+ +----------+ +----------+ +------+ | | | |Congestion| |Retransmit| |Connection| |Data | |Pacing| |-------> | |Control | |Confirm. | |Management| |Scheduling| | Rate | | | +----- ----+ +----------+ +----------+ +----------+ +------+ | | | +--------------------------------------------------------------+ | | v +---------+ +----------------+ | Network |<------------>| Remote End Host| +---------+ +----------------+¶
This section details the specific requirements for the functional flows of the Application-Transport Cooperation system, mirroring the closed-loop diagram presented in Section 2.¶
The Intent Flow carries the demand for QoE optimization from the Application Layer.¶
R3.1.1. QoE Signal Provision The Application Layer MUST generate and transmit the QoE Intent Signal. This signal SHALL explicitly declare the application's real-time performance objectives, including objective metrics (e.g., maximum latency) and qualitative priorities (e.g., urgency weighting).¶
R3.1.2. Intent Processing and Validation The QoE Mapping Engine MUST receive and process the QoE Intent Signal. This processing SHALL include:¶
The Strategy Flow is where abstract QoE intent is converted into executable protocol actions.¶
R3.2.1. Strategy Translation The QoE Mapping Engine MUST translate the parsed QoE Intent into a set of specific Transport Strategies. This translation SHALL map high-level goals into the available low-level control knobs of the Transport Protocol Stack.¶
R3.2.2. Strategy Execution (Transport Protocol Stack) The Transport Protocol Stack MUST expose controllable components that accept and execute the Transport Strategies. Execution SHALL involve dynamic adjustments to the following functions based on the input from the Mapping Engine:¶
R3.2.2.1. Congestion Control: Dynamically adjusting the active CC algorithm or modifying its parameters (e.g., aggression level) to Select Algorithm.¶
R3.2.2.2. Retransmission Confirmation: Adjusting the retransmission policy to Set Mode, balancing recovery speed against latency tolerance.¶
R3.2.2.3. Connection Management: Controlling parameters related to connection establishment, migration, or resource partitioning to Control Behavior.¶
R3.2.2.4. Data Scheduling: Modifying the criteria used to sequence data packets or streams for transmission based on their relative priority, thus Tuning Policy.¶
R3.2.2.5. Pacing: Adjusting the rate at which data is injected into the network to enforce a specific sending rate or smoothing behavior, fulfilling the requirement to Modify Rate.¶
The Feedback Flow is essential for closing the control loop and enabling continuous adaptation.¶
R3.3.1. Performance Measurement The Transport Protocol Stack MUST continuously measure the real-time performance metrics of the current connection. This measurement SHALL include fundamental indicators such as RTT, packet loss rate, and achieved throughput.¶
R3.3.2. Feedback and Notification Provision The Transport Protocol Stack SHOULD provide this performance information as a Transport Feedback Signal back to the Application Layer. Additionally, the transport system SHOULD provide Notification when critical events occur (e.g., inability to meet the declared QoE Intent) or when a significant change in strategy is executed. This signal SHALL enable the Application Layer to assess the success of the current Transport Strategy relative to its declared QoE Intent.¶
This document does not introduce any new security considerations.¶