End-network cooperation rate control method based on time delay, medium and equipment

Abstract

The invention provides an end-network cooperative rate control method based on time delay, a medium and equipment, and belongs to the field of RDMA rate control. The method comprises the following steps: sensing a network congestion condition on a gNB, and returning a CC signal to an RH; and the RH dynamically maintains a target time delay, judges the difference between the measurement time delay and the target time delay after receiving the CC signal, and correspondingly adjusts the rate. According to the method, the return without using the ACK is selected as the time delay signal, the network congestion condition is sensed on the gNB, and the congestion information is returned, so that the sending end can judge the time delay more accurately. According to the invention, a target time delay is dynamically maintained at the end side, and after a control signal is received, the rate is adjusted in a targeted manner by judging the difference between the measurement time delay and the target time delay.

Description

Technical Field

[0001] This invention belongs to the field of RDMA rate control, specifically relating to a time-delay-based end-to-end network cooperative rate control method, medium, and device. Background Technology

[0002] In RDMA traffic scenarios, one part is a 5G wireless link, and the other part is a RoCEv2 Ethernet link. This combined wireless and wired scenario presents a unique problem compared to ordinary scenarios: the wireless and wired speeds differ significantly, which negatively impacts traditional rate control methods. For example... Figure 1 As shown.

[0003] If a time-delay-based congestion notification algorithm is used, the ACK returned by the UE is a congestion notification. The ACK needs to go through a one-hop air interface path, which greatly increases the time delay. Therefore, for the sending end, the time interval for receiving the ACK is seriously too long. This will lead to the opposite result - underthrough, that is, the sending end rate drops too much, causing the receiving end to be unable to receive at a linear speed.

[0004] Furthermore, in the native Swift algorithm, it is necessary to wait for the receiver to return an ACK and judge the network congestion based on the time interval between sending data and returning an ACK. However, the ACK needs to go through a one-hop wireless link, which leads to a high arrival delay, causing the sender to misjudge the time interval and resulting in underthrough. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a time-delay-based end-to-end network cooperative rate control method, medium, and device.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a latency-based end-to-end network cooperative rate control method, applied to a wireless RDMA traffic scenario. In the wireless RDMA traffic scenario, the remote server RH, gateway GW, and base station gNB are connected via a RoCEv2 Ethernet link, and the gNB and terminal UE are connected via a 5G wireless link. In the control method, the gNB senses network congestion and returns a CC signal to the RH. The RH dynamically maintains a target latency. After receiving the CC signal, it determines the difference between the measured latency and the target latency and adjusts the rate accordingly.

[0008] Optionally, the CC signal is generated at the RLC layer of the gNB, and the RLC layer sends the CC signal when the data packet is dequeued.

[0009] Optionally, when the gNB sends the CC signal, the maximum value of the PSN in the queued data packet is taken as the PSN of the CC signal.

[0010] Optionally, the target delay D t The formula is as follows:

[0011]

[0012]

[0013] Where base_target represents the theoretical optimal single-hop latency, and base_rtt represents the round-trip time. It maps the rate ratio to a nonlinear weight, γ is used for normalization to normalize the rate to a pre-defined range (rate_min, rate_max), and R is the maximum value of the additional delay.

[0014] Optionally, after receiving the CC signal, RH determines the current measurement delay D and the target delay D. t The difference, and the rate is adjusted as follows:

[0015] If D <D t Increase the congestion window and perform additive rate increase as follows:

[0016]

[0017] Where, rateRatio old and rateRatio new Δ represents the ratio of the rate before and after the update. AI The step size is incremented additively, where cwnd is the current congestion window and packetSize is the packet size;

[0018] If D≥D t The following deceleration is achieved using a multiplicative reduction method:

[0019] rateRatio new =rateRatio old (1-factor);

[0020]

[0021] Where β is the basic deceleration factor, factor max That is the maximum reduction rate.

[0022] Optionally, after performing a multiplicative subtraction, the speed reduction should be prohibited until the cooldown period ends.

[0023] In a second aspect, the present invention provides a computer-readable storage medium storing a computer program that causes a computer to execute the latency-based end-to-end cooperative rate control method as described in the first aspect.

[0024] Thirdly, the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the latency-based end-to-end network cooperative rate control method as described in the first aspect.

[0025] The beneficial effects of this invention are:

[0026] (1) Intra-network node speed control: This invention chooses not to use the return of ACK as a delay signal, but instead senses the network congestion on the gNB and returns congestion information so that the sending end can more accurately judge the delay.

[0027] (2) End-side response speed control: The present invention dynamically maintains a target time delay on the end side. After receiving the control signal, the speed can be adjusted in a targeted manner by judging the difference between the current measurement time delay and the target time delay. Attached Figure Description

[0028] Figure 1 This is a diagram illustrating the long delay in the control path caused by the wireless link.

[0029] Figure 2 This is a mechanism diagram of a latency-based end-to-end network cooperative rate control method.

[0030] Figure 3 These are experimental results in a zero-packet-loss scenario, where (a) and (b) represent the native Swift algorithm and the latency-based end-to-end network collaborative rate control method under the ideal state of zero packet loss, respectively.

[0031] Figure 4 The results show experimental results in a packet loss scenario. (a) and (b) show the native Swift algorithm and the latency-based end-to-end network collaborative rate control method, respectively, under a packet loss rate of 0.05. Detailed Implementation

[0032] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0033] In one embodiment, the present invention proposes a time-delay-based end-to-end network cooperative rate control method, the mechanism of which is as follows: Figure 2 As shown, the rate control algorithm for end-to-end network coordination is realized through the response of internal network nodes to the rate control signal and the response of end-side nodes to the rate control signal. It mainly includes the following two parts:

[0034] 1. Intra-network node speed control: By actively sending a CC signal to the sender when data packets are dequeued, the sender can reduce its speed based on the delay.

[0035] like Figure 2 As shown, the RH sends data to the UE, passing through the gNB node. If a native Swift-like latency-based rate control algorithm were used, the ACK1 for data1 would take until t1+t2+t3 to return to the RH side, significantly increasing the latency compared to the normal control path. This embodiment uses the gNB as the location for sending back the "ACK" (actually sending a CC notification signal), placing the control signal generation at the RLC layer, and choosing to send the CC signal when the data packet is dequeued. The reason is as follows... Figure 2 The reason for the long interval between transmissions from data2 to CC2 in t4 is that the dequeue time of RLC layer data packets is affected by the underlying physical link status, which can serve as a representation of the underlying wireless link status. Therefore, this embodiment chooses to send back the CC signal at the dequeue point. After the receiver RH receives the CC signal, it slows down the transmission speed.

[0036] In this implementation, the CC signal is implemented by adding a type NEWCC_NOTICE to the RDMA opcode, alongside ACK and NACK, thus disabling the congestion response when receiving an ACK in native Swift and moving it to the NEWCC_NOTICE response. When sending data back from the gNB, the maximum value of the PSN in the queue-time aggregated data packet is taken as the PSN of the CC signal.

[0037] 2. End-side response rate control: Based on the arrival rate control signal, the transmission rate is quantified and reduced, and parameters are selected specifically to address the problem of high packet loss rate in wireless scenarios.

[0038] Delay-based congestion control algorithms require an open window, i.e., a congestion window limit (cwnd). Each time a data packet is sent, the sender records the current timestamp for each packet, maintaining it in a tsMap. When the sender receives a CC signal from the gNB, it calculates the latency D experienced by that data packet and compares it with the target latency D. t Compare.

[0039] The target delay D is dynamically adjusted, as shown in the following formula:

[0040]

[0041] The base latency is base_target + base_rtt, and the dynamically added latency range is dynamically adjusted based on the current rate. The rate ratio is mapped to a non-linear weight. The lower the rate (the more severe the congestion), the higher the additional delay will be. γ is used for normalization, which normalizes the rate to a pre-defined range (rate_min, rate_max). min is used to limit the additional delay to not exceed the maximum value R, and max is used to prevent negative values ​​from appearing.

[0042] The latency D experienced by the data packet is different from the target latency D. t Compare:

[0043] If D <D t This indicates that the current speed is high enough and the network is not congested. The congestion window can be increased to allow for additive growth.

[0044]

[0045] Where Δ AI To increase the step size additively, cwnd is the current congestion window (in bytes), and packetSize is the packet size (in bytes).

[0046] If D≥D t This indicates that the current latency is higher than expected, and network congestion has occurred, requiring speed reduction. A multiplicative-subtractive approach is used, which does not directly operate on the absolute rate but calculates a rate ratio.

[0047] rateRatio new =rateRatio old (1-factor)

[0048]

[0049] Where β is a basic deceleration factor, factor max This represents the maximum reduction ratio.

[0050] Note that multiplicative reduction is not performed every time a CC signal is received and the rate is higher than expected. There is a cooldown period. After multiplicative reduction is performed, the rate reduction needs to be disabled for a period of time until the cooldown period ends. This is because in most cases, a large number of CC signals arrive in a short period of time (this situation is more serious in wireless scenarios where data packets are aggregated). If the rate is attenuated every time, the rate will drop too low and may even lead to underthrough.

[0051] Table 1 presents the pseudocode of the end-side processing logic of the entire time-delay-based end-to-end network cooperative rate control algorithm.

[0052] Table 1. Delay-based terminal-network cooperative rate control algorithm

[0053]

[0054] Figure 3 (a) and (b) show the native Swift algorithm and the latency-based end-to-end cooperative algorithm designed in this embodiment, respectively, in a zero-packet-loss scenario. In the native Swift algorithm, the sending end adjusts its rate entirely based on the delay of receiving the ACK. Since the ACK needs to go through two wireless links, it arrives significantly later than the correct rate control signal, resulting in an excessive reduction in the sending end's rate and under-throughput. The most obvious symptom of this is that the orange line at the receiving end is not a straight line, meaning that the receiving end has not continuously received data packets for a period of time. In the end-to-end cooperative algorithm proposed in this embodiment, since the wireless link status is still used as an indicator, but the control path is shortened and two wireless links are no longer required, the under-throughput phenomenon is eliminated, while maintaining network congestion and preventing queue backlog.

[0055] Figure 4 (a) and (b) illustrate the native Swift algorithm and the latency-based end-to-end collaborative congestion control algorithm proposed in this embodiment under a static packet loss rate of 0.05%. It is evident that the native Swift algorithm suffers from severe underthrough. This is because packet loss leads to prolonged periods without ACKs (due to the lack of received valid packets), resulting in extremely long delays for the sender. Consequently, the algorithm drastically reduces the data transmission rate, leading to a significant decrease in overall system throughput. The end-to-end collaborative algorithm designed in this embodiment effectively solves this problem. Even with packet loss and prolonged periods without ACKs from the receiver, the algorithm generates a CC signal whenever the gNB sends data, reflecting air interface fluctuations without the issue of failing to receive ACKs.

[0056] In another embodiment, the present invention provides a computer-readable storage medium storing a computer program that causes a computer to execute the latency-based end-to-end cooperative rate control method of the foregoing embodiments.

[0057] In another embodiment, the present invention provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the latency-based end-to-end network cooperative rate control method of the foregoing embodiment.

[0058] In the embodiments disclosed in this application, a computer storage medium may be a tangible medium that may contain or store programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of computer storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CDROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0059] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0060] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A latency-based end-to-end network cooperative rate control method, applied to a wireless RDMA traffic scenario, wherein the remote server (RH), gateway (GW), and base station (gNB) are connected via a RoCEv2 Ethernet link, and the gNB is connected to the terminal UE via a 5G wireless link; characterized in that: In the control method, the gNB senses network congestion and returns a CC signal to the RH; the RH dynamically maintains a target delay, and after receiving the CC signal, it judges the difference between the current measured delay and the target delay and adjusts the rate accordingly.

2. The time-delay-based end-to-end network cooperative rate control method as described in claim 1, characterized in that: The CC signal is generated at the RLC layer of the gNB, and the RLC layer sends the CC signal when the data packet is dequeued.

3. The time-delay-based end-to-end network cooperative rate control method as described in claim 1, characterized in that: When the gNB sends the CC signal, the maximum value of the PSN in the dequeue data packet is used as the PSN of the CC signal.

4. The time-delay-based end-to-end network cooperative rate control method as described in claim 1, characterized in that: The target delay D t The formula is as follows: Where base_target represents the theoretical optimal single-hop latency, and base_rtt represents the round-trip time. It maps the rate ratio to a nonlinear weight, γ is used for normalization to normalize the rate to a pre-defined range (rate_min, rate_max), and R is the maximum value of the additional delay.

5. The time-delay-based end-to-end network cooperative rate control method as described in claim 1, characterized in that: After receiving the CC signal, RH determines the current measurement delay D and the target delay D. t The difference, and the rate is adjusted as follows: If D <D t Increase the congestion window and perform additive rate increase as follows: Where, rateRatio old and rateRatio new These represent the rate ratios before and after the update, Δ AI The step size is incremented additively, where cwnd is the current congestion window and packetSize is the packet size; If D≥D t The following deceleration is achieved using a multiplicative reduction method: rateRatio new =rateRatio old ·(1-factor); Where β is the basic deceleration factor, factor max That is the maximum reduction rate.

6. The time-delay-based end-to-end network cooperative rate control method as described in claim 5, characterized in that: After performing a multiplicative decrease, speed reduction is prohibited until the cooldown period ends.

7. A computer-readable storage medium storing a computer program, characterized in that, The computer program causes the computer to execute the time-delay-based end-to-end cooperative rate control method as described in any one of claims 1-6.

8. An electronic device, characterized in that, include: The memory, the processor, and the computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the time-delay-based end-to-end network cooperative rate control method as described in any one of claims 1-6.

Images