Cross Layer Information Assisted Flow Control

Introduction Holographic applications, such as AR/VR, have high requirements for image quality and low delay, which results in each frame rendered by the server being extremely large, and needs to be sent out as soon as possible after rendering. Under the influence of frame rate, holographic application streams have high peaks with stable intervals between peaks. If these bursty streams occur concurrently, it can cause severe congestion in wireless access networks with limited bandwidth, leading to increased delay and an inability to meet Quality of Service (QoS) requirements. The egress server of a data center (DC egress) is responsible for controlling outbound network traffic. If the egress server can obtain dynamic information about the queue and capabilities of the wireless access network, it will have the ability to regulate the transmission of flows entering the network, thus avoiding congestion and reducing the queuing delay of concurrent flows. Taking the 3GPP path as an example, two nodes of the 5G edge network architecture, User Plane Function and the base station(), possess the capability to rapidly transmit underlying network state information through dedicated signaling tunnels. In actual deployment, UPF is often set up on the egress server. During real-time end-to-end transmission, edge nodes can collect more accurate underlying link information and efficiently interact with servers, enabling effective global transmission control. For TCP and QUIC with congestion control capability and acknowledgement (ACK) confirmation mechanism, this document proposes a network-assisted multi-flow transmission control scheme. Without modifying the servers and terminals, it leverages the underlying link state information reported by access point to perform delay prediction and flow control for concurrent flows at the DC egress. Adjustments to the sending period or sending rate are achieved by modifying the receiver window number (rwnd) of each flow's ACK packets. This approach aims to mitigate or avoid network congestion, enabling a higher number of concurrent users to achieve satisfactory performance without compromising user experience.

Terminology In this document, the term "" refers to the Radio Link Control layer of 5G New Radio system. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and .

New Message Type and Parameters This document defines a new message type MSG_TYPE_APINFO to transmit the transmission capability information of the access point. Note that this information is only transmitted between the access point and the DC egress. Take 3GPP 5G path as example, the format of MSG_TYPE_APINFO is shown in Figure 1. It has the following fields:

Time:: The sending time of the message.
RLC ID:: 5G will create a separate RLC Buffer for each flow, and the RLC ID refers to the number of the RLC Buffer of the data flow.
RLC Buffer:: The length of the buffer corresponding to the RLC ID.
Scs:: Subcarrier Spacing (Scs) is a key parameter in the 5G NR physical layer. It defines the spacing between adjacent subcarriers in a carrier. The Scs can be different for different carriers and it is a significant factor in determining the flexibility and efficiency of spectrum usage.

Tdd: :Time Division Duplexing (Tdd) is duplexing method used in the context of 5G NR.TDD uses a single frequency band for both uplink (UL) and downlink (DL) transmission, with the direction of transmission changing over time. Tb Size: :Transport Block Size (Tb Size) is a key parameter in the 5G NR physical layer. It defines the size of the data block that is transported over the radio interface in a single transmission time interval. L1L2 Delay: :L1L2 Delay is a parameter that represents the time delay between the processing of data at Layer 1 (Physical Layer) and Layer 2 (Data Link Layer) in the 5G NR protocol stack. This delay is a critical factor in the overall delay of the 5G NR system.

Information Transmission and Processing In the 5G New Radio network, the base station utilizes the dedicated tunnel between the UPF and the base station to transmit base station information to the UPF.

Communication between gNB and UPF Information Transmission: The base station encapsulates the cross-layer information into a signaling packet with the related message type (e.g., MSG_TYPE_APINFO) and transmits it to the UPF through the dedicated GTP-U tunnel. Information Extraction: Upon receiving the GTP-U data packet, the UPF parses the packet based on the MSG_TYPE_APINFO message type. It extracts the cross-layer information from the base station and sends this information to the decision-making entity in the DC egress. Decision-Making Based on Extracted Information: The decision-making entity of DC egress can calculate the wired link delay between the base station and the UPF based on the time field. The transmission rate can be calculated based on the Scs, Tdd, and Tb Size information. The queuing delay of the corresponding flow ID can be determined based on the Rlc id and Rlc buffer. The processing delay of a flow can be calculated based on the L1L2 delay.

Traffic Monitoring at the DC egress The DC egress can monitor the traffic of each flow by examining the 5-tuple of the data packets passing through it. Traffic Recording: The DC egress is responsible for tracking the volume of each data flow that passes through it. The DC egress receives data packets from the network and inspects the five-tuple (source IP address, source port number, destination IP address, destination port number, and transport protocol) of each packet. Through the five-tuple, the DC egress can identify and monitor specific data flows. Each unique five-tuple represents a unique data flow. The DC egress records the volume of data for each identified data flow. Timestamp Recording: Whenever a data packet passes through, the DC egress records the current timestamp. This allows the DC egress to calculate the volume of data that has passed through it during a specific time period. The DC egress stores the data volume and the associated timestamp in some form of temporary array or database. Use in Decision-Making: The recorded data volume and timestamp information is used by the decision-making entity at the DC egress to calculate transmit delay.

ACK Manager The DC egress, based on its own recorded information and information provided by base stations, can accurately predict the future delay of each flow. This predictive value can be compared with the delay requirements specified by quality of service(QoS), enabling decision-making and deployment of control schemes for each flow. This document solely describes how the DC egress achieves sender control by modifying the ACK packets of each flow, without delving into the decision-making algorithms of the DC egress as it falls outside the scope of this document. Firstly, due to the prevalent use of batch acknowledgments in many transport protocols, where a single ACK packet acknowledges multiple previously received packets, the number of ACK packets is significantly smaller than the number of transmitted packets. To ensure an adequate number of ACKs for regulating the sender, the DC egress generates intermediate consecutive ACK packets using the currently recorded acknowledgment number and maximum sequence number. These generated ACK packets differ only in sequence numbers from the actual ACK packets, thereby avoiding rejection by the sender. Subsequently, for privacy protection and data security considerations, the DC egress only modifies the rwnd field of the ACK packets to be returned. For data flows that can be fully allowed, no modifications are made, and a regular ACK is returned directly. For data flows that require rate control, the DC egress returns two ACK packets. The first ACK is used to limit the sending rate, with the available bandwidth allocated to the flow being converted into the rwnd parameter of that ACK. The second ACK has an rwnd of 1, preventing the sender from transmitting data without DC egress authorization.

Clock Synchronization In order to account for the potential inconsistency of node clocks between physical devices, clock synchronization is required prior to calculating the one-way delay between two nodes. Firstly, it is necessary to ensure a transmission channel with stable delay between the two nodes. Subsequently, multiple request-response exchanges are performed between the two nodes. During each request-response exchange, the clock deviation between Node A and Node B is denoted as T_x. The time at which Node A sends the request packet is T_0, the time at which Node B receives the request packet is T_1, the time at which Node B sends the response packet is T_2, and the time at which Node A receives the response packet is T_3. Thus, T_x = (T_0 + T_3 - (T_1 + T_2))/2. Taking the average of multiple calculations of T_x yields the deviation value for clock synchronization. This deviation value is an essential parameter to consider when calculating one-way delay.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document only modifies the rwnd number of ACK packets.