QoE-Driven Application-Transport Cooperation Requirements

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

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.

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 when, and only when, they appear in all capitals, as shown here.

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:

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

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.

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: | |Control | |Confirm. | |Management| |Scheduling| | Rate | | | +----- ----+ +----------+ +----------+ +----------+ +------+ | | | +--------------------------------------------------------------+ | | v +---------+ +----------------+ | Network |<------------>| Remote End Host| +---------+ +----------------+ ]]>

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.

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.

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

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.

Security Considerations This document does not introduce any new security considerations.