Congestion control method and apparatus, chip, network interface card, device, storage medium and program product

Abstract

This application relates to a congestion control method, apparatus, chip, network interface card, device, storage medium, and program product, belonging to the field of communication technology. It includes: continuously receiving target events, including congestion notification events or round-trip delay (RTT) measurement events; detecting whether a congestion notification event is received within the current rate adjustment period, determining the reception order of the congestion notification event and the RTT measurement event within the current rate adjustment period, and obtaining an event detection result; determining a comparison result between the latest RTT and historical RTT smoothed values; determining a current rate control strategy based on the event detection result and the comparison result, and performing congestion control according to the current rate control strategy. By coupling CNP and RTT signals, it significantly reduces false positives and false negatives caused by the limitations of a single signal, improving the accuracy of congestion identification. Based on different stages and forms of congestion development, it adaptively selects the most suitable rate adjustment strategy, resulting in greater accuracy in rate adjustment.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a congestion control method, apparatus, chip, network interface card, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] Current RDMA (Remote Direct Memory Access) networks rely on sophisticated congestion control algorithms to ensure high throughput and low latency performance. Mainstream research focuses on two key signals: ECN (Explicit Congestion Notification) signals based on explicit forward congestion marking, and RTT (Round-Trip Time) signals based on end-to-end latency measurement.

[0003] ECN-type algorithms, represented by DCQCN, are currently the mainstream in practice, following the RP-CP-NP model. The core process is as follows: when the queue exceeds a threshold, the switch probabilistically marks the ECN bit of a data packet; upon sensing this, the receiver sends an independent, high-priority CNP (Congestion Notification Packet) message back to the sender; the sender uses this to determine network congestion and performs rate reduction operations. However, ECN / CNP is essentially a single-bit switch signal, which can only indicate whether the queue has momentarily exceeded a preset threshold, but cannot quantify the severity of congestion or reflect its dynamic trends, resulting in a lack of precision in the sender's rate adjustment.

[0004] To overcome the limitations of ECN, some solutions use RTT as the core congestion signal, such as the Timely algorithm and the Swift algorithm. Their advantages are: RTT directly reflects network queuing delay and is a continuous multi-bit signal, indicating not only the existence of congestion but also its degree and direction of change. The algorithm dynamically performs additive or multiplicative rate adjustments based on the deviation of RTT from the target delay, achieving smoother bandwidth adaptation.

[0005] However, RTT signals also have their inherent drawbacks. On the one hand, their anti-interference capability is weak, and single measurements are easily affected by receiver processing delays or burst traffic. On the other hand, RTT is a delayed feedback signal—it must wait for the message to go through a complete queue before it can bring congestion information back to the sender, while ECN can provide immediate forward warnings based on the current queue status when the message is sent.

[0006] In summary, existing research largely focuses on a single signal: ECN signals are direct but provide coarse-grained information, while RTT signals are information-rich but suffer from delayed feedback and are susceptible to noise interference. Current mainstream solutions have not yet effectively integrated the advantages of these two signals to construct a more accurate and robust congestion control mechanism. Summary of the Invention

[0007] Therefore, it is necessary to address the aforementioned technical problems by providing a congestion control method, device, chip, network interface card, computer equipment, computer-readable storage medium, and computer program product. By coupling CNP and RTT signals, this significantly reduces false positives and false negatives caused by the limitations of a single signal, making congestion identification more accurate and specific. It can adaptively select the most suitable rate adjustment strategy based on different stages and forms of congestion, resulting in greater accuracy in rate adjustment.

[0008] In a first aspect, this application provides a congestion control method, including:

[0009] Continuously receive target events, including congestion notification events or round-trip delay measurement events;

[0010] Detect whether a congestion notification event is received within the current rate adjustment period, and determine the reception order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period;

[0011] Determine the comparison result between the latest round-trip delay and the historical smoothed round-trip delay value;

[0012] If no congestion notification event is received within the current rate adjustment period, the rate is adjusted based on the preset rate-up strategy; or,

[0013] If the congestion notification event is received after the round-trip time (RTD) measurement event, or if the congestion notification event is received before the RTD measurement event and the latest RTD is greater than the historical RTD smoothing value, then a speed reduction adjustment is performed based on a preset speed reduction strategy; or...

[0014] If the congestion notification event is received before the round-trip delay measurement event, and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, then maintain the rate.

[0015] In one embodiment, if no congestion notification event is received within the current rate adjustment period, a rate increase adjustment is performed based on a preset rate increase strategy, including:

[0016] If no congestion notification event is received within the current rate adjustment period, and the latest round-trip time is not greater than the smoothed historical round-trip time value, then the rate is increased according to a first ratio based on the rate of the previous rate adjustment period; the first ratio is calculated based on the latest round-trip time and the smoothed historical round-trip time value; or,

[0017] If no congestion notification event is received in the current rate adjustment period, and the latest round-trip time is greater than the historical round-trip time smoothing value, then the rate adjustment is performed based on the rate of the previous rate adjustment period, according to the preset rate increase increment value.

[0018] In one embodiment, if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then a speed reduction adjustment is performed based on a preset speed reduction strategy, including:

[0019] If the congestion notification event is received after the round-trip delay measurement event, then the rate is reduced based on the rate of the previous rate adjustment period and according to the quantified congestion factor; or,

[0020] If the congestion notification event is received before the round-trip delay measurement event, and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then the rate is reduced according to the second ratio based on the rate of the previous rate adjustment cycle; the second ratio is calculated based on the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0021] In one embodiment, the method further includes:

[0022] In response to receiving a congestion notification event, the quantization congestion factor is updated.

[0023] In one embodiment, before determining the comparison result between the latest round-trip time delay and the historical round-trip time delay smoothing value, the method further includes:

[0024] Check whether the smoothed value of the latest round-trip latency compared to the historical round-trip latency is effective;

[0025] If both the latest round-trip delay and the historical round-trip delay smoothing values ​​are valid, perform the step of determining the comparison result between the latest round-trip delay and the historical round-trip delay smoothing values.

[0026] In one embodiment, the method further includes:

[0027] If no congestion notification event is received within the current rate adjustment period, and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then maintain the rate; or,

[0028] If a congestion notification event is received during the current rate adjustment period, and at least one of the latest round-trip time delay and the historical round-trip time delay smoothing value is invalid, then the rate is reduced based on the rate of the previous rate adjustment period according to the quantified congestion factor.

[0029] In one embodiment, the method further includes:

[0030] In response to receiving a round-trip delay measurement event, update the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0031] Secondly, this application also provides a congestion control method, including:

[0032] Receive the target message from the source;

[0033] If the target message contains a congestion notification flag and the time allowed for generating a congestion notification message is met, then a congestion notification message is generated and sent to the source so that the source receives the congestion notification event.

[0034] If the target message does not contain a congestion notification flag, but contains a round-trip delay probe request, a round-trip delay probe response message is generated and sent to the source so that the source receives the round-trip delay measurement event.

[0035] The source end is configured to: continuously receive target events, including congestion notification events or round-trip delay measurement events; detect whether a congestion notification event is received within the current rate adjustment period, and determine the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value; if no congestion notification event is received within the current rate adjustment period, perform rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, perform rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, maintain the rate.

[0036] Thirdly, this application also provides a congestion control device, comprising:

[0037] The receiving module is used to continuously receive target events, including congestion notification events or round-trip delay measurement events.

[0038] The detection module is used to detect whether a congestion notification event is received within the current rate adjustment period, and to determine the reception order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; and to determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value.

[0039] The control module is configured to: 1) increase speed based on a preset speed-up strategy if no congestion notification event is received within the current rate adjustment period; 2) decrease speed based on a preset speed-down strategy if the congestion notification event is received after the round-trip delay measurement event, or if the congestion notification event is received before the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value; or 3) maintain the rate if the congestion notification event is received before the round-trip delay measurement event and the latest round-trip delay is not greater than the historical round-trip delay smoothing value.

[0040] Fourthly, this application also provides a chip including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first or second aspect above.

[0041] Fifthly, this application also provides a network interface card, including the chip described in the fourth aspect above and multiple interfaces, wherein the chip processes data or communicates externally through the interfaces.

[0042] Sixthly, this application also provides a computer device including a network interface card as described in the fifth aspect above, the network interface card being used for processing data or external communication.

[0043] In a seventh aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first or second aspect above.

[0044] Eighthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first or second aspect above.

[0045] The aforementioned congestion control method, apparatus, chip, network interface card, computer equipment, computer-readable storage medium, and computer program product continuously receive target events, including congestion notification events or round-trip delay measurement events; detect whether a congestion notification event is received within the current rate adjustment period, and determine the reception order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value; if no congestion notification event is received within the current rate adjustment period, then perform rate increase adjustment based on a preset rate increase strategy; or, if the reception order is that the congestion notification event is later than the round-trip delay measurement event, or if the reception order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then perform rate decrease adjustment based on a preset rate decrease strategy; or, if the reception order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, then maintain the rate. Compared to congestion detection mechanisms relying solely on single signals like CNP or RTT, this method couples both CNP and RTT signals. This allows for the extraction of explicit congestion states indicated by the CNP signal and the utilization of congestion queue change trends reflected by RTT signal variations. By analyzing the arrival order and numerical relationship of these two types of events within the same adjustment period, it supports dual congestion localization, significantly reducing false positives and false negatives caused by the limitations of single signals, resulting in more accurate and specific congestion identification. It can adaptively select the most suitable rate adjustment strategy based on different stages and forms of congestion, leading to greater accuracy in rate adjustment. This method provides congestion judgment and corresponding rate adjustment schemes for multiple scenarios, accurately matching diverse congestion scenarios and significantly improving the accuracy of congestion judgment, rate control, and scenario adaptability. Compared to traditional algorithmic acceleration / deceleration strategies, it possesses more refined control capabilities. For example, it can identify scenarios with no explicit congestion but a slowly increasing queue and execute acceleration actions, and it can maintain rate stability when congestion is reported but the queue is actually decreasing, avoiding unnecessary deceleration. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a diagram illustrating the application environment of a congestion control method in one embodiment;

[0048] Figure 2 This is a flowchart illustrating a congestion control method in one embodiment;

[0049] Figure 3 This is a schematic diagram of the sending end's workflow in one embodiment;

[0050] Figure 4 This is a flowchart illustrating the congestion control method in another embodiment;

[0051] Figure 5 This is a schematic diagram of the message processing flow at the receiving end in one embodiment;

[0052] Figure 6 This is a structural block diagram of a congestion control device in one embodiment;

[0053] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0055] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0056] Before describing the embodiments of this application, it should be noted that the term "in response to" used in the embodiments of this application refers to the state in which a corresponding event occurs or a condition is satisfied. It is understood that the timing of the execution of subsequent actions performed in response to such an event or condition is not necessarily strongly correlated with the time when the event occurs or the condition is met. For example, in some cases, subsequent actions may be executed immediately upon the occurrence of the event or the fulfillment of the condition; while in other cases, subsequent actions may be executed some time after the occurrence of the event or the fulfillment of the condition.

[0057] In this application's embodiments, "ACK" refers to Acknowledgement, i.e., an acknowledgment (message). "CC" refers to Congestion Control. "CE" refers to Congestion Experienced (ECN). "CP" refers to Congestion Point. "ECN" refers to Explicit Congestion Notification. "FAI" refers to Fair Additive Increase (rate configuration). "HAI" refers to Hyper Additive Increase (rate configuration). "RTT" refers to Round-Trip Time. "DCQCN" refers to Data Center Quantized Congestion Notification. "DCTCP" refers to Data Center Transport Control Protocol. In this application's embodiments, "INT" refers to In-band Network Telemetry. "NAK" refers to Not ACK. "NP" refers to Notification Point. "NSCC" refers to Network Signal-based CC. "RDMA" refers to Remote Direct Memory Access. "RoCE" refers to RDMA over Converged Ethernet. "RP" refers to Reaction Point. "UE" refers to UltraEthernet.

[0058] Understandably, current RDMA network cards need to use congestion control algorithms to detect and mitigate network congestion. Mainstream congestion control signals include ACK / NAK, Timeout, ECN, RTT, and INT. Currently, most mainstream congestion control algorithms proposed by industry and academia use ECN as the congestion signal.

[0059] A typical congestion control (CC) algorithm that uses ECN as the congestion signal is DCQCN, which follows the RP-CP-NP model (first proposed in the DCTCP work). In this architecture, the RP (data sender) is the main force executing the algorithm, responsible for speed-up and speed-down operations. The CP marks outgoing packets with ECN by checking the buffer queue size; if the queue size is less than kmin, no marking is performed; if the queue size is between kmin and kma, probabilistic marking is performed (the marking probability is linearly related to the queue size); if the queue size is greater than kma, all packets are marked with ECN. When the NP (data receiver) receives a packet with ECN, if it receives ECN packets from the same flow within the same sampling period T, it ignores them; otherwise, it needs to respond with a Congestion Notification Packet (CNP). After receiving the CNP packet, the RP determines that the current network is congested and performs speed-down operations. The speed-down is achieved by using the α parameter to quantify congestion (the larger α is, the higher the congestion level, and vice versa). If the RP does not receive a CNP message within time period K, it is determined that there is no congestion in the current network and an acceleration operation can be performed. The acceleration is divided into three stages: fast recovery process—restores to the rate before the slowdown, active increase process—continues to probe available bandwidth, and excessive active increase process—more actively probes available bandwidth.

[0060] However, the ECN signal or the backhaul CNP signal it triggers is a typical single-bit signal. The essence of the information it contains is that when the packet is forwarded at the switch's exit, the queuing depth of the exit queue exceeds the preset threshold of the RED policy. It cannot reflect changes in the degree of congestion and cannot effectively guide the sender to adjust its speed according to dynamic changes in congestion.

[0061] With the development of communication technology, the scheme of using RTT as a congestion signal in RDMA networks has been proposed. The advantages of RTT as a signal are: First, RTT is delay information, which can reflect the congestion caused by buffer expansion of the switch (i.e., increased delay); Second, RTT is a multi-bit signal, which can express richer information than the two-bit ECN, not only the existence of congestion, but also the degree and direction of congestion; Third, RTT is easy to measure with high precision.

[0062] The core idea of ​​the Timely algorithm based on RTT is to use the delay gradient value, i.e., the change in the current RTT compared to the previous RTT, as the basis for congestion judgment. After obtaining the current RTT value, the Resource Provider (RP) first calculates the gradient change of RTT. The gradient is calculated by: calculating the difference between two consecutive RTTs, performing weighted smoothing with historical values ​​to filter out deviations caused by sudden jitter, and then normalizing it with the estimated minimum RTT to determine the expected transmission rate. If the new RTT is lower than Tlow, then "additive increment" is used to probe available bandwidth and increase the transmission rate. When traffic first starts, RTT may suddenly increase, which should not be considered as increased congestion. If the new RTT is higher than Thigh, then "multiplicative decrease" is used to reduce the transmission rate. If RTT continues to remain at a high level, but the gradient hardly changes, this mechanism is needed to prevent congestion. If the new RTT is between Tlow and Thigh, then the following calculations are made based on the RTT gradient rate of change: If the RTT gradient rate of change is not positive, it indicates that congestion has eased, so the transmission rate is increased by "additional increase". If the RTT gradient rate of change is not positive for five consecutive times, then the growth step size needs to be increased; if the RTT gradient rate of change is positive, it indicates that congestion has worsened, so the transmission rate is reduced by "multiplicative decrease".

[0063] Swift, an improved version of the Timely algorithm, mainly makes two optimizations based on Timely: First, Swift distinguishes between network propagation delay and host processing delay in RTT, thus distinguishing between network congestion and receiving host congestion; Second, Swift uses the target delay as the consensus point for all flows. When the current RTT is greater than the target delay, it is judged as congestion, and the rate is reduced (since Swift is a window algorithm, what is actually reduced is the window); when the current RTT is less than the target delay, it is judged as non-congestion, and the rate is increased.

[0064] However, RTT signals and algorithms also have their drawbacks. First, they are weaker than ECN signals in terms of interference resistance. The absolute value of a single RTT measurement may be affected by the burst absorption of the switch buffer and the processing capacity of the receiving end, thus failing to accurately reflect network congestion. Second, compared to ECN / CNP signals, RTT signals are delayed congestion information. This is because RTT signals need to wait for data packets to go through a complete queuing process before feeding back congestion information to the sending end, while switches determine whether to mark ECN CE based on whether the egress queue exceeds the waterline when sending packets. In other words, even if the current packet itself is not experiencing congestion, if the switch does experience queuing, it can "in advance" notify of the congestion situation without having to wait for congested packets to reflect it.

[0065] The traditional algorithms described above only use either the ECN or RTT signal, failing to combine the two signals to fully utilize their respective advantages. To address this, the new high-performance network protocol UE (Ultra Ethernet) 1.0 specification introduces a congestion control algorithm that couples ECN and RTT: NSCC (Network Signal-based Congestion Control). NSCC is a window-based algorithm; any subsequent descriptions of speed increases or decreases should be understood within the semantics of the NSCC algorithm as increasing or decreasing the congestion window.

[0066] The NSCC algorithm requires the following enabling actions to be taken at both the sending and receiving ends:

[0067] 1. The sending end supports using tx_state to record the status information of sent packets, such as packet size (payload_size) and sending timestamp (PDS_requsest.transmit_time).

[0068] 2. The receiving end supports calculating the message processing time: Service_time = ACK.transmit_time – PDS_request.arrival_time, which means that the service time is the time difference between when the receiving end receives the data message and when it sends the corresponding ACK message, and this information can be carried in the ACK message.

[0069] 3. To support accurate RTT calculation and ACK packet carrying, the receiving end must support per-packet ACK.

[0070] 4. After receiving the ECN CE flag message, the receiving end can carry ECN-Echo information (M_flag) in the ACK message.

[0071] 5. After receiving the ACK packet, the sending end can simultaneously extract the ECN information and RTT information. RTT = ACK.arrival_time – PDS_request.transmit_time – ACK.Service_time, meaning the network RTT is the total time interval from when the sending end sends a data packet to when it receives the corresponding ACK packet, minus the service time consumed by the receiving end in processing the ACK.

[0072] The congestion detection and rate regulation model of the NSCC algorithm is shown in Table 1 below.

[0073] Table 1:

[0074]

[0075] The UE protocol explains the above congestion detection and rate adjustment model as follows: (1) When the network is not congested, the NSCC algorithm will perform a proportional increase operation. By default, this operation will increase the size of the congestion window proportionally according to the difference between the current delay and the target delay (target_qdelay). Therefore, if the network load is light, its growth rate will be faster than when it is close to the congestion threshold. (2) When a data packet experiences congestion but the ECN shows that its queue has been emptied to below the threshold set by the ECN, the system will perform a fair increase operation. This operation prevents the transmission rate from being too low through an additive increase mechanism. Its function is to make the competing flow rates tend to be fair: all flows that receive the same signal will increase the congestion window by the same absolute amount. Therefore, the flow with the smaller congestion window will get a larger proportion of growth, while the flow with the larger congestion window will have a relatively smaller proportion of growth. (3) When the delay exceeds the threshold and the ECN does not indicate that the queue is decreasing, the system will perform a multiplicative decrease operation. At this time, the average delay directly reflects the extent to which the amount of backlogged data in the queue exceeds the expected value. This operation directly reduces the congestion window proportionally to the excess capacity of the queue. If all data streams perform the same operation under these circumstances, the goal is to reduce the queue to the target level within slightly more than one round-trip time (RTT).

[0076] Based on the above traditional solutions, most congestion control algorithms designed for RDMA only utilize a single signal (ECN or RTT), which leads to the information limitation problems mentioned above, such as insufficient single-bit information content of ECN and feedback delay of RTT.

[0077] Although the NSCC algorithm given by the UE protocol utilizes both ECN and RTT signals, it has many constraints. Based on the current mainstream RoCEv2 protocol, it is difficult to directly adapt to this algorithm. It is necessary to redesign and implement the relevant hardware / message processing capabilities, including but not limited to: (1) window mechanism, (2) ECN-Echo signal and ACK carrying, (3) RTT signal state storage and ACK carrying, and (4) packet-by-packet ACK.

[0078] To address the aforementioned problems, this application provides a congestion control method, apparatus, chip, network interface card, computer device, computer-readable storage medium, and computer program product. The method continuously receives target events, including congestion notification events or round-trip delay (RTD) measurement events. It detects whether a congestion notification event is received within the current rate adjustment period and determines the reception order of the congestion notification event and the RTD measurement event within the current rate adjustment period. It determines the comparison result between the latest RTD and a historical RTD smoothing value. If no congestion notification event is received within the current rate adjustment period, it performs rate increase adjustment based on a preset rate increase strategy; or, if the reception order is that the congestion notification event is later than the RTD measurement event, or if the reception order is that the congestion notification event is earlier than the RTD measurement event and the latest RTD is greater than the historical RTD smoothing value, it performs rate decrease adjustment based on a preset rate decrease strategy; or, if the reception order is that the congestion notification event is earlier than the RTD measurement event and the latest RTD is not greater than the historical RTD smoothing value, it maintains the rate. Compared to congestion detection mechanisms relying solely on single signals like CNP or RTT, this method couples both CNP and RTT signals. This allows for the extraction of explicit congestion states indicated by the CNP signal and the utilization of congestion queue change trends reflected by RTT signal variations. By analyzing the arrival order and numerical relationship of these two types of events within the same adjustment period, it supports dual congestion localization, significantly reducing false positives and false negatives caused by the limitations of single signals, resulting in more accurate and specific congestion identification. It can adaptively select the most suitable rate adjustment strategy based on different stages and forms of congestion, leading to greater accuracy in rate adjustment. This method provides congestion judgment and corresponding rate adjustment schemes for multiple scenarios, accurately matching diverse congestion scenarios and significantly improving the accuracy of congestion judgment, rate control, and scenario adaptability. Compared to traditional algorithmic acceleration / deceleration strategies, it possesses more refined control capabilities. For example, it can identify scenarios with no explicit congestion but a slowly increasing queue and execute acceleration actions, and it can maintain rate stability when congestion is reported but the queue is actually decreasing, avoiding unnecessary deceleration.

[0079] In addition, compared to the NSCC algorithm of the UE protocol, this solution does not require redesigning and implementing related hardware / message processing capabilities, such as window mechanism, ECN-Echo signal and ACK carrying, RTT signal state storage and ACK carrying, per-packet ACK, etc. It only needs to support the in-band or out-of-band implementation of RTT request and response, and can be engineered and verified based on the existing RoCEv2 protocol, making adaptation more convenient and more efficient.

[0080] The congestion control method provided in this application can be applied to, for example, Figure 1 The application environment shown is illustrated. The communication system includes a source end, a network, and a destination end. The source end includes a message processing module and an algorithm module, and the destination end includes a message processing module. The source end is also the data sender, and can be referred to as the sending end. The network consists of one or more interconnected switch nodes, possessing message forwarding and ECN marking capabilities. The destination end is the data receiver, and can be referred to as the receiving end. The algorithm module included in the source end executes the logic of the congestion control method provided in this application embodiment. The interface between this algorithm module and the message processing module is an event request and response mechanism.

[0081] The source-side packet processing module is responsible for generating and sending RTT_REQ probe packets and DATA packets carrying the data. Network devices (such as switches) mark forwarded packets for congestion according to their queue status and ECN policies. The destination-side packet processing module is responsible for generating and sending back ACK acknowledgment packets, NAK retransmission request packets, CNP congestion notification packets, and RTT_RSP probe response packets.

[0082] For example, the source-side message processing module needs to generate events according to the following rules, report them to the algorithm module, and wait for a response. When a new flow starts (Queue Pair creation is completed), it needs to report NEW_FLOW_EVENT (flow creation event), carrying the current timestamp ts. After sending a certain number of messages (usually the number of messages that can be sent in a single scheduling), it needs to report PKT_SENT_EVENT (message sent event), carrying the current timestamp ts and other optional information (such as the number of messages sent, sent_num). When a CNP message is received, it needs to report CNP_EVENT (congestion notification event), carrying the current timestamp ts. Upon receiving an RTT_RSP message, the RTT value must first be calculated: RTT_EVENT.rtt_cur = RTT_RSP.Arrvial_time – RTT_REQ.Transmit_time – RTT_RSP.Service_time. Then, the RTT_EVENT (Round-Trip Delay Measurement Event) is reported, carrying the current timestamp ts and the RTT calculation result rtt_cur. Here, RTT_EVENT.rtt_cur represents the RTT value corresponding to the currently calculated round-trip delay measurement event; RTT_RSP.Arrvial_time represents the time when the RTT_RSP message was received; RTT_REQ.Transmit_time represents the timestamp of the RTT_REQ message sent by the source; and RTT_RSP.Service_time represents the time consumed by the destination in processing the RTT message, which is the time interval between receiving the request message (RTT_REQ) and sending the response message (RTT_RSP) at the destination.

[0083] In one exemplary embodiment, such as Figure 2 As shown, a congestion control method is provided, which is applied to... Figure 1 Taking the source end (i.e., the sender) or algorithm module as an example, the explanation includes:

[0084] Step 202: Continuously receive target events, including congestion notification events or round-trip delay measurement events.

[0085] Among them, reference Figure 1The events sent by the message processing module to the algorithm module include, but are not limited to, at least one of the following: flow creation event (NEW_FLOW_EVENT), message sent event (PKT_SENT_EVENT), congestion notification event (CNP_EVENT), and round-trip time delay measurement event (RTT_EVENT). The congestion notification event (CNP event) is generated in response to the receipt of a congestion notification message and is used to indicate that the sender has received a congestion notification message. The round-trip time delay measurement event (RTT event) is generated in response to the receipt of an RTT probe response message and is used to indicate that the sender has received an RTT probe response message.

[0086] It is understood that the "continuous reception" in this embodiment is used to describe an asynchronous, non-blocking event monitoring and processing mode, in which the sending end captures the target event in real time based on the background processing logic and responds to the target event to perform subsequent processing operations.

[0087] In one exemplary embodiment, the method further includes updating the quantized congestion factor in response to receiving a congestion notification event.

[0088] The sending end maintains a `has_cnp` parameter, which indicates whether a congestion notification event has been received within the current rate adjustment period. If `has_cnp=1`, it indicates that a congestion notification event has been received within the current rate adjustment period; if `has_cnp=0`, it indicates that no congestion notification event has been received within the current rate adjustment period. The sending end also maintains a quantized congestion factor `alpha`, whose initial value is 1. In response to receiving a congestion notification event, the `has_cnp` parameter is set to 1, the quantized congestion factor `alpha` is updated, and the latest CNP timestamp is recorded as the current timestamp: `last_cnp_ts=ts`. For example, following the DCQCN algorithm rules, the quantized congestion factor `alpha` is updated using the following formula: `alpha=alpha×(1-G)+G`, where G ranges from [0,1], with a typical value such as 1 / 256. This embodiment, by updating the quantized congestion factor, can dynamically reflect the network congestion level, providing data support for subsequent rate control, thereby improving the accuracy of congestion control.

[0089] Optionally, after updating the quantized congestion factor, if the rate adjustment time is detected at the current time, the subsequent steps 204 to 212 are executed.

[0090] In an exemplary embodiment, the method further includes updating the latest round-trip time, the historical round-trip time smoothing value, and the historical minimum round-trip time in response to receiving a round-trip time measurement event.

[0091] The sending end maintains the latest round-trip time (RTT)_cur, the historical RTT smoothing value (RTT_his), and the historical minimum RTT_min. In response to receiving a RTT measurement event, rtt_cur, rtt_his, and rtt_min are updated.

[0092] For example, the update rule for rtt_his is: if rtt_his is 0, then rtt_his = rtt_cur; otherwise, rtt_his = rtt_his × beta + rtt_cur × (1 - beta). Where beta is the RTT history smoothing coefficient, with a value range of [0,1], and a typical value such as 0.5.

[0093] For example, the update rule for rtt_cur is: rtt_cur = RTT_EVENT.rtt_cur, which means recording the RTT value corresponding to the round-trip delay measurement event as the latest round-trip delay. The update timestamp of the latest round-trip delay also needs to be updated: last_rtt_ts = ts.

[0094] For example, the update rule for rtt_min is: take the minimum value between rtt_min and the latest round-trip time as the new rtt_min.

[0095] In an exemplary embodiment, the method further includes: in response to receiving a stream creation event, initializing algorithm parameters and performing an initial RTT probe. The relevant parameters, their meanings, and initial values ​​are listed in Table 2 below. During the initial RTT probe, rtt_req is marked as 1 in the event response, and subsequent message processing modules send RTT probe messages according to the indication.

[0096] Table 2:

[0097]

[0098] In an exemplary embodiment, the method further includes: in response to a received message transmission event, detecting whether the current time has reached the rate adjustment time; if so, continuing to execute subsequent steps 204 to 212. For example, the interval between the current time and the last rate adjustment time is calculated as interval = ts – last_rate_ts. If interval ≥ RATE_UPDATE_PERIOD, it indicates that the current time has reached the rate adjustment time, and subsequent rate adjustment tasks need to be executed; otherwise, selective RTT probing (i.e., checking whether the RTT probing trigger time has been reached) is performed. For example, the interval between the current time and the last RTT probing trigger time is calculated as interval = ts – last_probe_ts. If interval ≥ RTT_PROBE_PERIOD, rtt_req = 1 needs to be included in this response; otherwise, rtt_req = 0 is sufficient. RATE_UPDATE_PERIOD is the rate adjustment period, a predefined fixed time threshold that represents the minimum time interval between two consecutive rate adjustments; RTT_PROBE_PERIOD is the RTT detection period, a predefined fixed time threshold that represents the minimum time interval between two consecutive RTT detections.

[0099] In one exemplary embodiment, the method further includes: in response to receiving an undefined event, performing selective RTT probing and filling a response message. Selective RTT probing involves checking whether the RTT probing trigger time has arrived; if so, performing RTT probing.

[0100] Step 204: Detect whether a congestion notification event is received within the current rate adjustment period, and determine the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period.

[0101] The current rate adjustment period refers to the algorithm's preset time window, which begins at the moment the previous rate adjustment action is completed and ends at the moment the current rate adjustment is triggered. Within this time window, the algorithm module responds to each target event, maintains relevant parameters, and at the end of the time window, analyzes the parameters maintained within the current rate adjustment period and triggers a rate calculation and adjustment.

[0102] Optionally, in response to a received message sent event, it checks whether the current time has reached the rate adjustment period; if so, it determines that the current rate adjustment period has ended, analyzes the parameters maintained during the current rate adjustment period, and triggers a rate calculation and adjustment. The end of the period is triggered by the message sent event and time detection.

[0103] Optionally, on some hardware platforms, if the packet processing module cannot provide PKT_SENT_EVENT, a time-based self-detection mechanism can be used as an alternative. The core of this mechanism is a periodically triggered NO_CNP_EVENT (or an unnamed timed event), meaning that the system has not received any CNP packets within a fixed time interval. Whenever this timed condition is met, an event is automatically reported, triggering the algorithm to execute periodic congestion detection and rate adjustment procedures. This mechanism is time-driven; it does not rely on the transmission of a single packet but polls at a fixed clock cycle, ensuring that the algorithm can still run stably according to the designed cycle even in hardware environments lacking fine-grained event support.

[0104] The reception order refers to the chronological order in which the CNP_EVENT and RTT_EVENT events first occur within the same rate adjustment period. In one optional implementation, it checks whether a congestion notification event has been received within the current rate adjustment period, i.e., whether has_cnp=1 is true. If so, it further determines the reception order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period based on the timestamp of has_cnp and the update timestamp of rtt_cur.

[0105] Step 206: Determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value.

[0106] The latest round-trip time (RTT) refers to the most recently measured and calculated RTT value within the current rate adjustment cycle. The historical RTT smoothing value is a stable estimate calculated using a series of RTT measurements over a past period through a filtering algorithm (such as exponentially weighted moving average). For example, the transmitter maintains the latest RTT_cur, the historical RTT smoothing value_rtt_his, and the historical minimum RTT_min. The maintained rtt_cur is compared with rtt_his to obtain the comparison result.

[0107] In an exemplary embodiment, before determining step 206, the method further includes: detecting whether the latest round-trip delay and the historical round-trip delay smoothing value are valid; and if both the latest round-trip delay and the historical round-trip delay smoothing value are valid, performing step 206.

[0108] Specifically, the validity of the maintained rtt_cur and rtt_his is checked. If both rtt_cur and rtt_his are not 0, it indicates that both the latest round-trip delay and the historical round-trip delay smoothing values ​​are valid. The comparison between rtt_cur and rtt_his yields the result. This embodiment provides a method to check the validity of the detection data, ensuring the reliability of the decision-making basis.

[0109] Step 208: If no congestion notification event is received within the current rate adjustment period, then the rate is adjusted based on the preset rate increase strategy.

[0110] Step 210: If the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then the speed reduction adjustment is performed based on the preset speed reduction strategy.

[0111] Step 212: If the congestion notification event is received before the round-trip delay measurement event, and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, then maintain the rate.

[0112] In this process, step 204 yields event detection results. Based on these results and comparisons, a current rate control strategy is determined, and congestion control is implemented accordingly. The current rate control strategy refers to the specific action instructions determined by decision logic based on the event detection and comparison results. These actions may include multiplicative rate reduction, additive rate increase, multiplicative rate increase, and rate maintenance. Congestion control refers to the complete process of applying the action instructions corresponding to the current rate control strategy to the packet processing module, altering its packet transmission behavior (such as adjusting the sending window, token bucket rate, or packet interval). In the specific implementation, a multi-branch conditional decision logic is mapped to a unique current rate control strategy based on the input event detection and comparison results.

[0113] If no congestion notification event is received within the current rate adjustment period, it indicates that there is no congestion signal feedback from the network, and the transmission rate is increased. If the congestion notification event is received after the round-trip time delay (RTD) measurement event, or if the congestion notification event is received before the RTD measurement event and the latest RTD is greater than the historical RTD smoothing value, it indicates that the network is currently congested, and the transmission rate is decreased. If the congestion notification event is received before the RTD measurement event and the latest RTD is not greater than the historical RTD smoothing value, it indicates that the network congestion has eased relative to the CNP event feedback time point, and the network is in the stage of emptying the buffer queue, so the rate maintenance action can be performed.

[0114] In one alternative implementation, refer to Table 3, which lists the congestion detection and rate adjustment model of this application. The RTT information is a comparison between rtt_cur (latest RTT value) and rtt_his (historical smoothed RTT value). This method of utilizing RTT signals does not require configuring or calculating target_qdelay as in the UE protocol NSCC algorithm. The ECN information indicates whether a CNP event was received in the current rate adjustment period (which can be a fixed rate adjustment time threshold, a configurable value). Further, for a CNP event occurring in the current rate adjustment period, there are two possible scenarios: (1) the CNP event was received earlier than the most recent RTT update time, marked as CNP (earlier than RTT) in Table 3; (2) the CNP event was received later than the most recent RTT update time, also marked as CNP (later than RTT) in Table 3.

[0115] Table 3:

[0116]

[0117] In one alternative implementation, referring to Table 3, the congestion control steps include:

[0118] If no CNP event is received within the current rate adjustment period, and the latest RTT value is less than or equal to the historical RTT value, it indicates that there is no congestion signal feedback from the current network, and a proportional rate increase can be performed. Optionally, referring to the NSCC algorithm, the decrease in rtt_cur relative to rtt_his can accurately reflect the degree of reduction in network queue length. This reduction directly corresponds to the space available for increasing the transmission rate. The algorithm calculates the increase proportionally based on this reduction, thereby adjusting the rate. This proportional rate increase has a fast-then-slow effect: the rate increase is large when the queue is significantly reduced, which can quickly recover bandwidth; as the queue gradually stabilizes, the rate increase automatically decreases, thus smoothly approaching the target rate and avoiding overshoot and oscillation.

[0119] If no CNP event is received within the current rate adjustment period, and the latest RTT value is greater than the historical RTT value, it indicates that the current network is not congested but the packet queuing delay has increased. A fair rate increase action can be performed before congestion occurs. Optionally, referring to the NSCC algorithm, fair rate increase is achieved by adding a fixed, small constant to the rate of each flow to ensure that changes between different flows tend towards a fair convergence point.

[0120] If a CNP event is received first within the current rate adjustment period, and the latest RTT value is less than or equal to the historical RTT value, it indicates that the current network congestion has eased relative to the congestion time point reported by the CNP event, and the network is in the stage of emptying the buffer queue. Rate maintenance can be performed to prevent the current flow from injecting new congestion packets into the network, with the expectation of entering a congestion-free state after a period of time.

[0121] If a CNP event is received first within the current rate adjustment period, and the latest RTT value is greater than the historical RTT value, it indicates that the current network congestion has further increased relative to the congestion time point of the CNP event feedback, and is in a stage of intensified congestion. A multiplicative rate reduction should be implemented to alleviate congestion. Optionally, referring to the NSCC algorithm, the increase in rtt_cur relative to rtt_his can accurately reflect the degree to which the amount of backlogged data in the queue exceeds the expected value. Based on the queue excess corresponding to this increase, a corresponding proportional rate reduction can be implemented on the transmission rate; that is, the rate reduction magnitude is related to the queue excess, thereby achieving quantitative feedback and control of the congestion level.

[0122] If, within the current rate adjustment period, the latest RTT value is detected to be less than or equal to the historical RTT value, and then a CNP event is received, it indicates that although the network was in the process of emptying the buffer queue for a period of time, it subsequently re-entered congestion due to some reasons (such as a burst of new flow, excessive acceleration of old flow, etc.), corresponding to the information fed back by the most recent CNP event. A multiplicative rate reduction should be performed to alleviate congestion. For example, referring to the standard DCQCN algorithm, a proportional rate reduction can be performed using a quantized congestion factor alpha.

[0123] If, within the current rate adjustment period, the latest RTT value is detected to be greater than the historical RTT value, and then a CNP event is received, it indicates that the network is eventually entering a congested state as the buffer queue continues to accumulate, corresponding to the information fed back by the most recent CNP event. A multiplicative rate reduction should be implemented to alleviate congestion. For example, referring to the standard DCQCN algorithm, a proportional rate reduction can be performed using a quantized congestion factor alpha.

[0124] In one alternative implementation, a fast-response mode is added to avoid the slow response problem under the rigid rate adjustment interval constraint. For example, the fast-response mode for rate reduction adjustment can be: if K consecutive increases in rtt occur (i.e., rtt_cur > rtt_his), the rate can be reduced without waiting for the rate adjustment interval to arrive. Generally, rate increase adjustment does not require a fast response; it can be triggered simply by waiting for the rate adjustment interval to arrive.

[0125] In one alternative implementation, an aggressive rate-up mode is added to avoid the problem of abundant available network bandwidth but slow rate-up. For example, if F consecutive rate-up adjustments occur but a CNP event is not triggered, the aggressive rate-up mode is entered, with a final rate-up value of: MAX(rate×[1+(rtt_his–rtt_cur) / rtt_his],rate+HAI), where HAI is the ultra-aggressive rate-up configuration, which can be set to an integer multiple of FAI. If the calculated rate-up value based on RTT is higher, that value is directly used as the rate-up result to achieve the goal of faster utilization of potential network bandwidth.

[0126] Compared to congestion detection mechanisms relying solely on single signals like CNP or RTT, this congestion control method couples CNP and RTT signals. This allows for the extraction of explicit congestion states indicated by the CNP signal and the utilization of congestion queue trends reflected by changes in the RTT signal. By analyzing the arrival order and numerical relationship of these two types of events within the same adjustment period, it supports dual congestion localization, significantly reducing false positives and false negatives caused by the limitations of single signals, resulting in more accurate and specific congestion identification. It can adaptively select the most suitable rate adjustment strategy based on different stages and forms of congestion, leading to greater accuracy in rate adjustment. This method provides congestion judgment and corresponding rate adjustment schemes for multiple scenarios, accurately matching diverse congestion scenarios and significantly improving the accuracy of congestion judgment, rate control, and scenario adaptability. Compared to traditional algorithm-based speed-up and speed-down strategies, it has more refined control capabilities. For example, it can identify scenarios where there is no explicit congestion but the queue is slowly increasing and execute speed-up actions. It can also maintain a stable rate when congestion is reported but the queue is actually decreasing, thus avoiding unnecessary speed-down.

[0127] In an exemplary embodiment, step 208 includes: if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is not greater than the historical round-trip time smoothing value, then the speed is increased according to a first ratio based on the rate of the previous rate adjustment period; the first ratio is calculated based on the latest round-trip time and the historical round-trip time smoothing value; or, if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is greater than the historical round-trip time smoothing value, then the speed is increased according to a preset speed increase increment value based on the rate of the previous rate adjustment period.

[0128] Among them, the rate in the previous rate adjustment period refers to the sending rate calculated by the algorithm and finally applied by the sending end at the end of the previous complete rate adjustment period. If no CNP event is received and rtt_cur ≤ rtt_his, it indicates that the network is not congested and the queuing volume decreases, and a proportional rate increase action based on RTT is performed. Exemplarily, the following formula is used for rate increase adjustment: rate = rate × [1 + (rtt_his – rtt_cur) / rtt_his], and (rtt_his – rtt_cur) / rtt_his is the first ratio.

[0129] If no CNP event is received and rtt_cur > rtt_his, it indicates that the network is not congested but the queuing volume increases, and a fair rate increase action of additive increase is performed. Exemplarily, the following formula is used for rate increase adjustment: rate = rate + AI update rate, where AI is a fixed small rate increase step, that is, a preset rate increase increment value.

[0130] In this embodiment, in the scenario where the network is not congested and the queuing volume decreases, fast bandwidth recovery is achieved based on proportional rate increase adjustment to improve data transmission efficiency; in the scenario where the network is not congested but the queuing volume increases, fair and gentle detection is achieved based on a fixed increment to avoid immediate congestion caused by aggressive rate increase.

[0131] In an exemplary embodiment, step 210 includes: if the reception order is that the congestion notification event is later than the round-trip delay measurement event, then perform a rate reduction adjustment based on the rate in the previous rate adjustment period according to the quantization congestion factor; or, if the reception order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothed value, then perform a rate reduction adjustment based on the rate in the previous rate adjustment period according to the second ratio; the second ratio is calculated based on the latest round-trip delay, the historical round-trip delay smoothed value, and the historical minimum round-trip delay.

[0132] Among them, if the received CNP event is later than the RTT event (for example, last_cnp_ts ≥ last_rtt_ts), it indicates that the network finally enters the congestion state, and a multiplicative rate reduction action based on CNP is performed. Exemplarily, the following formula is used for rate reduction adjustment: rate = rate × (1 – alpha / 2).

[0133] If the received CNP event is earlier than the RTT event (for example, last_cnp_ts < last_rtt_ts) and rtt_cur > rtt_his, it indicates that the congestion intensifies, and a multiplicative rate reduction action based on RTT is performed. Exemplarily, the following formula is used for rate reduction adjustment: rate = rate × (rtt_cur – rtt_min) / rtt_cur.

[0134] In this embodiment, the different stages and severity of congestion can be accurately diagnosed, and a corresponding rate-reduction response can be executed to quickly alleviate congestion while minimizing bandwidth waste caused by excessive rate reduction.

[0135] In an exemplary embodiment, the method further includes: if no congestion notification event is received in the current rate adjustment period, and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then maintaining the rate; or, if a congestion notification event is received in the current rate adjustment period, and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then adjusting the rate according to the quantized congestion factor based on the rate of the previous rate adjustment period.

[0136] If no congestion notification event is received within the current rate adjustment period, and at least one of the latest round-trip time (RTT) and historical RTT smoothing values ​​is invalid, the rate maintenance action can be performed directly. For example, in the initial stage of the flow, if no CNP event is received, no valid RTT information is received, or only one RTT message is received (all cases where the relationship between rtt_cur and rtt_his cannot be determined), the algorithm module performs the rate maintenance action.

[0137] If a congestion notification event is received within the current rate adjustment period, and at least one of the latest round-trip time (RTT) and the historical RTT smoothed value is invalid, a CNP-based multiplicative rate reduction action is performed. For example, the rate reduction adjustment is performed using the following formula: rate = rate × (1 – alpha / 2). For instance, in the initial stage of the flow, if a CNP event is received, no valid RTT information is received, or only one RTT message is received (all cases where the relationship between rtt_cur and rtt_his cannot be determined), the algorithm module refers to the standard DCQCN algorithm and uses the quantized congestion factor alpha to perform proportional rate reduction.

[0138] In this embodiment, it is ensured that the algorithm can make conservative and reasonable decisions when the sensing signal is partially failed or not ready, so as to prevent congestion control failure.

[0139] In one alternative implementation, refer to Figure 3 , Figure 3The algorithm workflow at the sending end is demonstrated. In response to a received message, the message processing module sends an event request to the algorithm module. Upon receiving the event report, the algorithm module determines the event type. If the event is NEW_FLOW_EVENT, algorithm parameter initialization is required. The relevant parameters, their meanings, and initial values ​​are listed in Table 2 above. After parameter initialization, the first RTT probe action is performed, marking rtt_req=1 during the event response. Subsequent message processing modules send RTT probe messages according to this instruction. If the event is not NEW_FLOW_EVENT, further event type determination is required.

[0140] If the event is PKT_SENT_EVENT, first check if the rate adjustment time has arrived. For example, calculate the interval between the current time and the last rate adjustment time: interval = ts – last_rate_ts. If interval ≥ RATE_UPDATE_PERIOD, it indicates that the rate adjustment time has arrived, and subsequent rate adjustment tasks need to be executed; otherwise, perform selective RTT probing (i.e., check if the RTT probing trigger time has arrived). For example, calculate the interval between the current time and the last RTT probing trigger time: interval = ts – last_probe_ts. If interval ≥ RTT_PROBE_PERIOD, then rtt_req = 1 needs to be included in this response; otherwise, set rtt_req = 0. When executing the rate adjustment task, it is necessary to first determine whether a CNP has been received within the current rate adjustment period (i.e., whether has_cnp is 1).

[0141] Regardless of whether a CNP event is received, it is necessary to further check whether rtt_cur and rtt_his are valid (both are not 0). If a CNP event is received, has_cnp needs to be reset to 1, and the quantization congestion factor alpha needs to be updated (increasing the quantization congestion factor). The update formula can follow the DCQCN algorithm rule alpha=alpha×(1-G)+G, where G takes values ​​in the range [0,1], with a typical value of 1 / 256.

[0142] If a CNP event is received and both rtt_cur and rtt_his are valid, it is necessary to further determine the order of the CNP event and the RTT event. If the CNP event is later than the RTT event (for example, last_cnp_ts≥last_rtt_ts), perform a multiplicative slowdown action based on CNP, and the rate can be updated using, but not limited to, the following formula: rate = rate×(1–alpha / 2). If the CNP event is earlier than the RTT event (for example, last_cnp_ts<last_rtt_ts), it is necessary to further judge the relationship between rtt_cur and rtt_his. If rtt_cur>rtt_his, indicating congestion aggravation, perform a multiplicative slowdown action based on RTT, and the rate can be updated using, but not limited to, the following formula: rate = rate×(rtt_cur–rtt_min) / rtt_cur. If rtt_cur≤rtt_his, indicating congestion mitigation, the rate can be maintained.

[0143] If a CNP event is received and not all of rtt_cur and rtt_his are valid, perform a multiplicative slowdown action based on CNP.

[0144] If no CNP event is received and both rtt_cur and rtt_his are valid, it is necessary to further judge the relationship between rtt_cur and rtt_his. If rtt_cur≤rtt_his, indicating no network congestion and a decrease in the queue size, perform a proportional speed-up action based on RTT, and the rate can be updated using, but not limited to, the following formula: rate = rate×[1+(rtt_his–rtt_cur) / rtt_his]. If rtt_cur>rtt_his, indicating no network congestion but an increase in the queue size, perform an additive increase fair speed-up action, and the rate can be updated using, but not limited to, the following formula: rate = rate+AI, where AI is a fixed small speed-up step size, that is, a preset speed-up increment value.

[0145] If no CNP event is received and not all of rtt_cur and rtt_his are valid, directly perform a rate maintenance action.

[0146] In all cases without a CNP event, it is necessary to update the quantization congestion factor alpha (reduce the quantization congestion factor), and the update formula can follow the DCQCN algorithm rule: alpha = alpha×(1 - G). After completing the rate adjustment according to the above method, it is necessary to update the rate adjustment time and then perform a selective RTT probe. Finally, complete the event response, fill in the rate and rtt_req values, and return them to the packet processing module. If the event is not a PKT_SENT_EVENT, it is necessary to further judge the event type.

[0147] If the event is CNP_EVENT, update has_cnp to 1 and record the latest CNP timestamp as the current timestamp: last_cnp_ts=ts. Then, the CNP_EVENT processing flow can reuse the algorithm logic of PKT_SENT_EVENT, i.e., continue checking if the rate adjustment time has arrived. If the event is not CNP_EVENT, further determination of the event type is required.

[0148] If the event is RTT_EVENT, then update rtt_his, rtt_cur, and rtt_min. The update rule for rtt_his is: if rtt_his is 0, then rtt_his = rtt_cur; otherwise, rtt_his = rtt_his × beta + rtt_cur × (1 - beta). Here, beta is the RTT history smoothing coefficient, with a value range of [0,1], typically 0.5. The update rule for rtt_cur is: rtt_cur = RTT_EVENT.rtt_cur. The latest round-trip time timestamp also needs to be updated: last_rtt_ts = ts. Then, the RTT_EVENT processing flow can reuse the algorithm logic of PKT_SENT_EVENT, i.e., continue checking whether the rate adjustment time has arrived. If the event is not RTT_EVENT, then the event type is an undefined type, and by default, selective RTT probing is performed and the response message is filled.

[0149] Understandable, Figure 3 This paper assumes that the message processing module reports events in a single-event mode, rather than an aggregation mode that supports multiple events reported at once. In practice, with simple modifications, the congestion control method provided in this embodiment can also support multi-event aggregation mode processing.

[0150] This application provides a highly adaptable ECN-RTT coupling algorithm framework based on the RoCEv2 protocol. Instead of directly using the ECN-Echo signal, it reuses the existing CNP signal from the RoCEv2 protocol to leverage the advantages of both ECN and RTT congestion signals, requiring no complex hardware or software modifications. Compatible with the widely used DCQCN algorithm, this application's embodiment performs congestion control based on rate feedback, eliminating the need for window mechanism adaptation. It directly reuses the CNP message (CNP_EVENT) specified by the RoCEv2 protocol without requiring modifications to the ACK message to support the ECN-Echo signal. This application embodiment also requires the use of RTT signals (RTT_EVENT), but the construction of RTT messages differs slightly from the UE protocol: (1) This application embodiment does not mandate the implementation form of the RTT probe request; it can be implemented either in-band (attaching the RTT message header to the data packet) or out-of-band (sending a special message containing the RTT message header); (2) This application embodiment does not require the sender to record the message transmission time, and the message transmission time can be directly carried in the RTT probe message: that is, the sender's RTT probe request message carries the Transmit_time information. It should be noted that since the sender does not need to record the message transmission status, the receiver does not need to support packet-by-packet ACK, and only needs to perform special processing on the message containing RTT probe to generate a specific RTT response message. The construction of RTT in-band and out-of-band messages and the RTT probe request response are not the core improvements of this application embodiment, so they are not described in detail.

[0151] This embodiment proposes the congestion detection and rate adjustment model described in Table 3, and provides congestion judgment and corresponding rate adjustment schemes for multiple scenarios (covering six types of scenarios), achieving more accurate congestion judgment and rate adjustment. This embodiment creatively distinguishes the order of CNP events and RTT events, and selects different congestion quantization methods. For scenarios where the latest information is presented in the RTT event, RTT is used to perform congestion quantization and adjust the rate; for scenarios where the latest information is presented in the CNP event, alpha-based heuristic congestion quantization and rate adjustment are used. (Refer to...) Figure 3 This application provides a complete source-side algorithm workflow and corresponding algorithm parameter configuration, including the generation of NEW_FLOW_EVENT, PKT_SENT_EVENT, CNP_EVENT and RTT_EVENT events, event processing in the algorithm and algorithm response.

[0152] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0153] In one exemplary embodiment, such as Figure 4 As shown, a congestion control method is provided, which is applied to... Figure 1 Taking the destination (i.e., the receiver) as an example, the explanation includes:

[0154] Step 402: Receive the target message from the source.

[0155] In this process, the receiving end (e.g., a network interface card) receives the target message sent by the source end from the network. The target message is any message sent by the source end.

[0156] Step 404: If the target message contains a congestion notification flag and the time allowed for generating a congestion notification message is met, then a congestion notification message is generated and sent to the source end so that the source end receives the congestion notification event.

[0157] The congestion notification flag (ECN CE flag) is used to indicate that network nodes (such as switches and routers) have detected or are experiencing congestion. In specific implementations, the congestion notification flag can also be a dedicated congestion flag in other custom protocols. The time-based allowance for generating congestion notification messages refers to a time-based judgment criterion used to control the frequency of congestion notification message generation, preventing excessive generation of congestion notification messages in a short period from causing signaling storms or receiver overload. For example, the time-based allowance is: the time interval between the current moment and the last time a congestion notification message was generated is greater than or equal to a preset minimum time interval threshold (e.g., CNP message generation cycle waterline configuration).

[0158] If the target message contains a congestion notification flag, the receiver further checks whether the current time meets the time-permitted conditions for generating a congestion notification message. If both conditions are met (i.e., a congestion notification flag exists and the time-permitted conditions are met), the receiver generates a congestion notification message to notify the source of the network congestion status, thereby triggering the source to perform a rate adjustment operation. For example, the congestion notification message is a CNP message in the RoCEv2 protocol. The receiver encapsulates the congestion notification message into the appropriate message format and sends it to the source over the network.

[0159] If any of the above conditions are not met (e.g., the target message does not contain a congestion notification flag, or although it contains a flag, the current time allowance is not met), the receiver will not generate a congestion notification event and will instead execute other processing logic (e.g., step 406 or the default message processing flow).

[0160] Step 406: If the target message does not contain a congestion notification flag, but contains a round-trip delay probe request, then generate a round-trip delay probe response message and send the round-trip delay probe response message to the source end so that the source end receives the round-trip delay measurement event.

[0161] If the target message does not contain a congestion notification flag, the receiving end further checks whether the target message contains a round-trip time delay (RTT) probe request. If the target message does not contain a congestion notification flag but does contain an RTT probe request, the receiving end generates a RTT probe response message (i.e., an RTT response message). The RTT measurement event is used to provide the source end with the information required to measure the round-trip time.

[0162] In one exemplary embodiment, refer to Figure 5 , Figure 5 The message processing flow at the receiving end is illustrated. After receiving a message from the sending end, the receiving end first checks if the message contains an ECN CE tag. If so, the message indicates network congestion. Next, it checks if the current time exceeds the CNP message generation cycle waterline configuration. If so, a CNP message is generated and sent; otherwise, no CNP message is generated. For example, in the Mellanox CX network interface card, the CNP message generation cycle waterline configuration parameter is min_time_between_cnps. The interval between the current time and the last CNP generation is calculated as interval = ts – last_cnp_gen_ts. If interval ≥ min_time_between_cnps, a CNP message is generated and sent.

[0163] If the ECN CE flag is not included, the process jumps directly to the RTT probe detection and processing stage. The receiving end needs to check if the sending end's message contains an RTT probe request. If it does, an RTT response message needs to be generated. First, the receiving end's processing time RTT_RSP.Service_time = RTT_RSP.Transmit_time – Packet.Arrival_time is calculated. Then, RTT_RSP.Transmit_time and RTT_RSP.Service_time are filled into the RTT_RSP message and sent. Finally, message processing is completed (e.g., generating an ACK or NAK). If the sending end's message does not contain an RTT probe request, message processing is completed directly. Here, RTT_RSP.Transmit_time represents the time when the receiving end sends the RTT response message; Packet.Arrival_time represents the time when the probe message sent by the sending end arrives at the receiving end.

[0164] The source end is configured to: continuously receive target events, including congestion notification events or round-trip delay measurement events; detect whether a congestion notification event is received within the current rate adjustment period, and determine the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value; if no congestion notification event is received within the current rate adjustment period, perform rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, perform rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, maintain the rate.

[0165] It should be noted that the specific processing procedure at the source end can be found in the explanation of steps 202 to 212 above, and will not be repeated here.

[0166] In this embodiment, the congestion feedback and round-trip delay detection mechanisms are organically integrated, and selective triggering is performed based on message characteristics. The generation of congestion notification events is subject to time-permissible restrictions to avoid congestion feedback storms. This enables fine-grained network state awareness and control without increasing additional signaling overhead.

[0167] Based on the same inventive concept, this application also provides a congestion control device for implementing the congestion control method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the congestion control device provided below can be found in the limitations of the congestion control method described above, and will not be repeated here.

[0168] In one exemplary embodiment, such as Figure 6 As shown, a congestion control device is provided, comprising:

[0169] The receiving module 602 is used to continuously receive target events, wherein the target events include congestion notification events or round-trip delay measurement events;

[0170] The detection module 604 is used to detect whether a congestion notification event is received within the current rate adjustment period, and to determine the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; and to determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value.

[0171] The control module 606 is configured to: If no congestion notification event is received within the current rate adjustment period, perform a rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is such that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is such that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, perform a rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is such that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, maintain the rate.

[0172] Compared to congestion detection mechanisms relying solely on single signals like CNP or RTT, this congestion control device couples both CNP and RTT signals. This allows it to mine the explicit congestion state indicated by the CNP signal and utilize the congestion queue change trend reflected by RTT signal variations. By analyzing the arrival order and numerical relationship of these two types of events within the same adjustment cycle, it supports dual congestion localization, significantly reducing false positives and false negatives caused by the limitations of single signals, making congestion identification more accurate and specific. It can adaptively select the most suitable rate adjustment strategy based on different stages and forms of congestion, resulting in greater accuracy in rate adjustment. This device provides congestion judgment and corresponding rate adjustment schemes for multiple scenarios, accurately matching diverse congestion scenarios and significantly improving the accuracy of congestion judgment, rate control, and scenario adaptability. Compared to traditional algorithm-based speed-up and speed-down strategies, it has more refined control capabilities. For example, it can identify scenarios where there is no explicit congestion but the queue is slowly increasing and execute speed-up actions. It can also maintain a stable rate when congestion is reported but the queue is actually decreasing, thus avoiding unnecessary speed-down.

[0173] In an exemplary embodiment, the control module 606 is further configured to, if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is not greater than the historical round-trip time smoothing value, adjust the speed according to a first ratio based on the rate of the previous rate adjustment period; the first ratio is calculated based on the latest round-trip time and the historical round-trip time smoothing value; or, if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is greater than the historical round-trip time smoothing value, adjust the speed according to a preset speed increase increment value based on the rate of the previous rate adjustment period.

[0174] In an exemplary embodiment, the control module 606 is further configured to: if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, then perform a rate reduction adjustment based on the rate of the previous rate adjustment period according to the quantized congestion factor; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then perform a rate reduction adjustment based on the rate of the previous rate adjustment period according to a second ratio; the second ratio is calculated based on the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0175] In an exemplary embodiment, the receiving module 602 is further configured to update the quantized congestion factor in response to receiving a congestion notification event.

[0176] In an exemplary embodiment, the detection module 604 is further configured to detect whether the latest round-trip delay and the historical round-trip delay smoothing value are valid; if both the latest round-trip delay and the historical round-trip delay smoothing value are valid, the step of determining the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value is performed.

[0177] In an exemplary embodiment, the control module 606 is further configured to maintain the rate if no congestion notification event is received in the current rate adjustment period and at least one of the latest round-trip delay and the historical round-trip delay smoothing value is invalid; or, if a congestion notification event is received in the current rate adjustment period and at least one of the latest round-trip delay and the historical round-trip delay smoothing value is invalid, perform a rate reduction adjustment based on the rate of the previous rate adjustment period according to the quantized congestion factor.

[0178] In an exemplary embodiment, the receiving module 602 is further configured to update the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay in response to receiving a round-trip delay measurement event.

[0179] In one exemplary embodiment, a congestion control device is provided, comprising:

[0180] The message receiving module is used to receive target messages from the source end;

[0181] The processing module is configured to generate a congestion notification message and send it to the source end if the target message contains a congestion notification flag and the time allowed for generating the congestion notification message is met, so that the source end receives the congestion notification event; if the target message does not contain a congestion notification flag but contains a round-trip delay probe request, it generates a round-trip delay probe response message and sends it to the source end, so that the source end receives the round-trip delay measurement event.

[0182] The modules in the aforementioned congestion control device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0183] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a congestion control method.

[0184] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0185] In an exemplary embodiment, a chip is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: continuously receiving target events, wherein the target events include congestion notification events or round-trip delay measurement events; detecting whether a congestion notification event is received within the current rate adjustment period, and determining the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; determining a comparison result between the latest round-trip delay and a historical round-trip delay smoothing value; if no congestion notification event is received within the current rate adjustment period, then performing rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then performing rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, then maintaining the rate.

[0186] In one embodiment, when the processor executes the computer program, it further implements the following steps: if no congestion notification event is received in the current rate adjustment period, and the latest round-trip time is not greater than the historical round-trip time smoothing value, then the speed is increased according to a first ratio based on the rate of the previous rate adjustment period; the first ratio is calculated based on the latest round-trip time and the historical round-trip time smoothing value; or, if no congestion notification event is received in the current rate adjustment period, and the latest round-trip time is greater than the historical round-trip time smoothing value, then the speed is increased according to a preset speed increase increment value based on the rate of the previous rate adjustment period.

[0187] In one embodiment, when the processor executes the computer program, it further implements the following steps: if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment period according to the quantized congestion factor; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment period according to a second ratio; the second ratio is calculated based on the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0188] In one embodiment, the processor, when executing the computer program, further performs the following steps: updating the quantized congestion factor in response to receiving a congestion notification event.

[0189] In one embodiment, when the processor executes the computer program, it further performs the following steps: detecting whether the latest round-trip delay and the historical round-trip delay smoothing value are valid; and if both the latest round-trip delay and the historical round-trip delay smoothing value are valid, performing the step of determining the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value.

[0190] In one embodiment, the processor, when executing the computer program, further implements the following steps: if no congestion notification event is received in the current rate adjustment period, and at least one of the latest round-trip time delay and the historical round-trip time delay smoothing value is invalid, then maintain the rate; or, if a congestion notification event is received in the current rate adjustment period, and at least one of the latest round-trip time delay and the historical round-trip time delay smoothing value is invalid, then perform a rate reduction adjustment based on the rate of the previous rate adjustment period according to the quantized congestion factor.

[0191] In one embodiment, the processor, when executing a computer program, further implements the following steps: in response to receiving a round-trip delay measurement event, updating the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0192] In one embodiment, when the processor executes the computer program, it further performs the following steps: receiving a target message from the source; if the target message contains a congestion notification flag and meets the time-permitted condition for generating a congestion notification message, generating a congestion notification message and sending the congestion notification message to the source so that the source receives a congestion notification event; if the target message does not contain a congestion notification flag and the target message contains a round-trip delay probe request, generating a round-trip delay probe response message and sending the round-trip delay probe response message to the source so that the source receives a round-trip delay measurement event.

[0193] In one embodiment, a network interface card is provided, including a chip as described in any of the above embodiments and multiple interfaces, wherein the chip processes data or communicates externally through the interfaces.

[0194] In one embodiment, a computer device is provided, including a network interface card as described in any of the above embodiments, the network interface card being used for processing data or external communication.

[0195] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon. When executed by a processor, the computer program performs the following steps: continuously receiving target events, wherein the target events include congestion notification events or round-trip delay measurement events; detecting whether a congestion notification event is received within the current rate adjustment period, and determining the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; determining a comparison result between the latest round-trip delay and a historical round-trip delay smoothing value; if no congestion notification event is received within the current rate adjustment period, then performing rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then performing rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, then maintaining the rate.

[0196] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is not greater than the historical round-trip time smoothing value, then the speed is increased according to a first ratio based on the rate of the previous rate adjustment period; the first ratio is calculated based on the latest round-trip time and the historical round-trip time smoothing value; or, if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is greater than the historical round-trip time smoothing value, then the speed is increased according to a preset speed increase increment value based on the rate of the previous rate adjustment period.

[0197] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment period according to the quantized congestion factor; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment period according to a second ratio; the second ratio is calculated based on the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0198] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: updating the quantized congestion factor in response to receiving a congestion notification event.

[0199] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: detecting whether the latest round-trip delay and the historical round-trip delay smoothing value are valid; and if both the latest round-trip delay and the historical round-trip delay smoothing value are valid, performing the step of determining the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value.

[0200] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if no congestion notification event is received in the current rate adjustment period and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then maintain the rate; or, if a congestion notification event is received in the current rate adjustment period and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then perform a rate reduction adjustment based on the rate of the previous rate adjustment period according to the quantized congestion factor.

[0201] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: in response to receiving a round-trip delay measurement event, updating the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0202] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: receiving a target message from the source; if the target message contains a congestion notification flag and meets the time-permitted condition for generating a congestion notification message, generating a congestion notification message and sending the congestion notification message to the source so that the source receives a congestion notification event; if the target message does not contain a congestion notification flag and the target message contains a round-trip delay probe request, generating a round-trip delay probe response message and sending the round-trip delay probe response message to the source so that the source receives a round-trip delay measurement event.

[0203] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps: continuously receiving target events, wherein the target events include congestion notification events or round-trip delay measurement events; detecting whether a congestion notification event is received within the current rate adjustment period, and determining the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; determining a comparison result between the latest round-trip delay and a historical round-trip delay smoothing value; if no congestion notification event is received within the current rate adjustment period, then performing rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then performing rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, then maintaining the rate.

[0204] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is not greater than the historical round-trip time smoothing value, then the speed is increased according to a first ratio based on the rate of the previous rate adjustment period; the first ratio is calculated based on the latest round-trip time and the historical round-trip time smoothing value; or, if no congestion notification event is received in the current rate adjustment period and the latest round-trip time is greater than the historical round-trip time smoothing value, then the speed is increased according to a preset speed increase increment value based on the rate of the previous rate adjustment period.

[0205] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment period according to the quantized congestion factor; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment period according to a second ratio; the second ratio is calculated based on the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0206] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: updating the quantized congestion factor in response to receiving a congestion notification event.

[0207] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: detecting whether the latest round-trip delay and the historical round-trip delay smoothing value are valid; and if both the latest round-trip delay and the historical round-trip delay smoothing value are valid, performing the step of determining the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value.

[0208] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if no congestion notification event is received in the current rate adjustment period and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then maintain the rate; or, if a congestion notification event is received in the current rate adjustment period and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then perform a rate reduction adjustment based on the rate of the previous rate adjustment period according to the quantized congestion factor.

[0209] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: in response to receiving a round-trip delay measurement event, updating the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

[0210] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: receiving a target message from the source; if the target message contains a congestion notification flag and meets the time-permitted condition for generating a congestion notification message, generating a congestion notification message and sending the congestion notification message to the source so that the source receives a congestion notification event; if the target message does not contain a congestion notification flag and the target message contains a round-trip delay probe request, generating a round-trip delay probe response message and sending the round-trip delay probe response message to the source so that the source receives a round-trip delay measurement event.

[0211] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0212] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0213] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0214] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A congestion control method, characterized in that, The method includes: Continuously receive target events, wherein the target events include congestion notification events or round-trip delay measurement events; Detect whether a congestion notification event is received within the current rate adjustment period, and determine the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; Determine the comparison result between the latest round-trip delay and the historical smoothed round-trip delay value; If no congestion notification event is received within the current rate adjustment period, the rate is adjusted based on the preset rate-up strategy; or, If the receiving order is such that the congestion notification event is later than the round-trip time (RTD) measurement event, or if the receiving order is such that the congestion notification event is earlier than the RTD measurement event and the latest RTD is greater than the historical RTD smoothing value, then a speed reduction adjustment is performed based on a preset speed reduction strategy; or... If the receiving order is such that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, then maintain the rate.

2. The method according to claim 1, characterized in that, If no congestion notification event is received within the current rate adjustment period, the rate adjustment is performed based on a preset rate-up strategy, including: If no congestion notification event is received within the current rate adjustment period, and the latest round-trip time is not greater than the historical round-trip time smoothing value, then the rate is increased according to a first ratio based on the rate of the previous rate adjustment period; the first ratio is calculated based on the latest round-trip time and the historical round-trip time smoothing value; or... If no congestion notification event is received in the current rate adjustment period, and the latest round-trip time is greater than the historical round-trip time smoothing value, then the rate is adjusted according to the preset rate increase increment value based on the rate of the previous rate adjustment period.

3. The method according to claim 1, characterized in that, If the receiving order is such that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is such that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then a speed reduction adjustment is performed based on a preset speed reduction strategy, including: If the receiving order is such that the congestion notification event is later than the round-trip delay measurement event, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment cycle and according to the quantified congestion factor; or, If the receiving order is such that the congestion notification event is earlier than the round-trip delay measurement event, and the latest round-trip delay is greater than the historical round-trip delay smoothing value, then a rate reduction adjustment is performed based on the rate of the previous rate adjustment cycle according to a second ratio, wherein the second ratio is calculated based on the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

4. The method according to claim 3, characterized in that, The method further includes: In response to receiving a congestion notification event, the quantization congestion factor is updated.

5. The method according to any one of claims 1 to 4, characterized in that, Before determining the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value, the method further includes: Check whether the smoothed value of the latest round-trip latency compared to the historical round-trip latency is effective; If both the latest round-trip delay and the historical round-trip delay smoothing value are valid, perform the step of determining the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value.

6. The method according to claim 5, characterized in that, The method further includes: If no congestion notification event is received within the current rate adjustment period, and at least one of the latest round-trip time and the historical round-trip time smoothing value is invalid, then maintain the rate; or, If a congestion notification event is received during the current rate adjustment period, and at least one of the latest round-trip time delay and the historical round-trip time delay smoothing value is invalid, then the rate is reduced based on the rate of the previous rate adjustment period according to the quantized congestion factor.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: In response to receiving a round-trip delay measurement event, update the latest round-trip delay, the historical round-trip delay smoothing value, and the historical minimum round-trip delay.

8. A congestion control method, characterized in that, The method includes: Receive the target message from the source; If the target message contains a congestion notification flag and meets the time requirement for generating a congestion notification message, then a congestion notification message is generated and sent to the source end so that the source end receives the congestion notification event. If the target message does not contain a congestion notification flag, but contains a round-trip delay probe request, then a round-trip delay probe response message is generated and sent to the source end so that the source end receives the round-trip delay measurement event; The source end is configured to: continuously receive target events, including congestion notification events or round-trip delay measurement events; detect whether a congestion notification event is received within the current rate adjustment period, and determine the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value; if no congestion notification event is received within the current rate adjustment period, perform rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, perform rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, maintain the rate.

9. A congestion control device, characterized in that, The device includes: A receiving module is used to continuously receive target events, wherein the target events include congestion notification events or round-trip delay measurement events; The detection module is used to detect whether a congestion notification event is received within the current rate adjustment period, and to determine the receiving order of the congestion notification event and the round-trip delay measurement event within the current rate adjustment period; and to determine the comparison result between the latest round-trip delay and the historical round-trip delay smoothing value. The control module is configured to: If no congestion notification event is received within the current rate adjustment period, perform a rate increase adjustment based on a preset rate increase strategy; or, if the receiving order is such that the congestion notification event is later than the round-trip delay measurement event, or if the receiving order is such that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is greater than the historical round-trip delay smoothing value, perform a rate decrease adjustment based on a preset rate decrease strategy; or, if the receiving order is such that the congestion notification event is earlier than the round-trip delay measurement event and the latest round-trip delay is not greater than the historical round-trip delay smoothing value, maintain the rate.

10. A chip comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

11. A network interface card, characterized in that, It includes the chip as described in claim 10 and a plurality of interfaces, the chip processing data or communicating externally through the interfaces.

12. A computer device, characterized in that, Includes the network interface card as described in claim 11, wherein the network interface card is used for processing data or external communication.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images