Cross Layer Information Assisted Flow Control

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 11 January 2024.¶

Copyright Notice

Copyright (c) 2023 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.¶

Table of Contents

1. 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[UPF] and the base station([gNB]), 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[RFC5681] and QUIC[RFC9000] 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.¶

2. Terminology

In this document, the term "[RLC]" 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 [RFC2119] and [RFC8174].¶

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

    MSG_TYPE_APINFO {
               MessageType = 0x31,
               Time,
               Rlc Id,
               Rlc Buffer,
               Scs,
               Tdd,
               Tb Sise,
               L1L2 Delay,
               }
Figure 1: MSG_TYPE_APINFO Format

4. Information Transmission and Processing

In the 5G New Radio network, the base station utilizes the dedicated [GTP-U] tunnel between the UPF and the base station to transmit base station information to the UPF.¶

  +---------+                    +-------------+
  |   gNB   |      GTP-U         |     UPF     |
  +---------|--------------------|-------------|
  |         |      APINFO        |             |
  +---------+                    +-------------+

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

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

6. 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[RFC2018], 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.¶

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

8. IANA Considerations

This memo includes no request to IANA.¶

9. Security Considerations

This document only modifies the rwnd number of ACK packets.¶

Authors' Addresses