Standard Communication with Network Elements J. Zhang Internet-Draft G. Lv Intended status: Standards Track Q. Wu Expires: 14 May 2026 Z. Li Chinese Academy of Sciences 10 November 2025 QoE-Driven Application-Transport Cooperation Requirements draft-zhang-qoe-driven-transport-requirement-00 Abstract 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. 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 14 May 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires 14 May 2026 [Page 1] Internet-Draft QoE-Driven Transport November 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. System Architecture . . . . . . . . . . . . . . . . . . . . . 3 2.1. Application Layer Requirements: Intent Declaration . . . 3 2.2. QoE Mapping Engine Requirements: Adaptive Strategy . . . 3 2.3. Transport Protocol Stack Requirements: Feedback and Optimization . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements for the QoE-Driven Cooperation Flow . . . . . . 5 3.1. Intent Flow (Application -> Transport System) . . . . . . 5 3.2. Strategy Flow (Mapping Engine -> Transport Protocol Stack) . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Feedback Flow (Transport Protocol Stack -> Application Layer) . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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 Zhang, et al. Expires 14 May 2026 [Page 2] Internet-Draft QoE-Driven Transport November 2025 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. 1.1. Terminology 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. 1.2. Requirements Language 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. 2. System Architecture 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: 2.1. Application Layer Requirements: Intent Declaration 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). 2.2. QoE Mapping Engine Requirements: Adaptive Strategy 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. Zhang, et al. Expires 14 May 2026 [Page 3] Internet-Draft QoE-Driven Transport November 2025 2.3. Transport Protocol Stack Requirements: Feedback and Optimization 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| +---------+ +----------------+ Zhang, et al. Expires 14 May 2026 [Page 4] Internet-Draft QoE-Driven Transport November 2025 3. Requirements for the QoE-Driven Cooperation Flow 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. 3.1. Intent Flow (Application -> Transport System) 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: * Conflict Resolution: Utilizing priority fields to resolve competition among multiple concurrent intents. * Security Sanitization: Enforcing constraints to ensure the requested intent does not violate network fairness principles or security policies. 3.2. Strategy Flow (Mapping Engine -> Transport Protocol Stack) 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. Zhang, et al. Expires 14 May 2026 [Page 5] Internet-Draft QoE-Driven Transport November 2025 * 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. 3.3. Feedback Flow (Transport Protocol Stack -> Application Layer) 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. 4. Security Considerations This document does not introduce any new security considerations. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Zhang, et al. Expires 14 May 2026 [Page 6] Internet-Draft QoE-Driven Transport November 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Jiaxing Zhang Chinese Academy of Sciences Beijing China Email: zhangjiaxing20g@ict.ac.cn Gerui Lv Chinese Academy of Sciences Beijing China Email: lvgerui@ict.ac.cn Qinghua Wu Chinese Academy of Sciences Beijing China Email: wuqinghua@ict.ac.cn Zhenyu Li Chinese Academy of Sciences Beijing China Email: zyli@ict.ac.cn Zhang, et al. Expires 14 May 2026 [Page 7]