Internet DRAFT - draft-dispatch-clfc
draft-dispatch-clfc
Dispatch W. Yang
Internet-Draft W. Du
Intended status: Informational B. Zhao
Expires: 11 January 2024 Y. Ren
X. Zhou
G. Xie
CNIC
10 July 2023
Cross Layer Information Assisted Flow Control
draft-dispatch-clfc-00
Abstract
Bursty concurrent streams from holographic applications can cause
congestion in wireless access networks, leading to increased delay
and QoS issues. The egress server of a data center (DC egress) can
regulate outbound network traffic and mitigate congestion if it
obtains dynamic information about the wireless access network's queue
and capabilities. The document proposes a network-assisted multi-
flow transmission control scheme that leverages underlying link state
information of access points to perform delay prediction and flow
control at the DC egress to alleviate congestion and improve user
experience.
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.
Yang, et al. Expires 11 January 2024 [Page 1]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Message Type and Parameters . . . . . . . . . . . . . . . 3
4. Information Transmission and Processing . . . . . . . . . . . 4
5. Traffic Monitoring at the DC egress . . . . . . . . . . . . . 5
6. ACK Manager . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Clock Synchronization . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
Yang, et al. Expires 11 January 2024 [Page 2]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
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.
Yang, et al. Expires 11 January 2024 [Page 3]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
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 | |
+---------+ +-------------+
Figure 1: 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.
Yang, et al. Expires 11 January 2024 [Page 4]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
*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.
Yang, et al. Expires 11 January 2024 [Page 5]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
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.
Yang, et al. Expires 11 January 2024 [Page 6]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
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.
10. References
10.1. 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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/rfc/rfc5681>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
10.2. Informative References
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/rfc/rfc2018>.
Yang, et al. Expires 11 January 2024 [Page 7]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
[UPF] 3GPP TS 23.501 (2023-06), "System architecture for the 5G
System (5GS) (Release 15)", n.d..
[gNB] 3GPP TS 38.300 (2023-06), "NR and NG-RAN Overall
description (Release 15)", n.d..
[GTP-U] 3GPP TS 29.281 V18.0.0 (2023-06), "General Packet Radio
System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)
(Release 18)", n.d..
[RLC] 3GPP TS 38.322 (2023-06), "NR; Radio Link Control (RLC)
protocol specification (Release 15)", n.d..
Authors' Addresses
Wanghong Yang
CNIC
Beijing
100083
China
Email: yangwanghong@cnic.cn
Wenji Du
CNIC
Beijing
100083
China
Email: hjdu@cnic.cn
Baosen Zhao
CNIC
Beijing
100083
China
Email: zhaobaosen@cnic.cn
Yongmao Ren
CNIC
Beijing
100083
China
Email: renyongmao@cstnet.cn
Yang, et al. Expires 11 January 2024 [Page 8]
Internet-Draft Cross Layer Information Assisted Flow Co July 2023
Xu Zhou
CNIC
Beijing
100083
China
Email: zhouxu@cstnet.cn
Gaogang Xie
CNIC
Beijing
100083
China
Email: xie@cnic.cn
Yang, et al. Expires 11 January 2024 [Page 9]
