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

Abstract

The application relates to a congestion control method, device, chip, network interface card, equipment, medium and program product. The method comprises the following steps: receiving a report event of a packet processing module; if no congestion notification packet is received in a speed-up period, updating a quantitative congestion evaluation value; when the report event of the packet processing module comprises a congestion notification packet event, adjusting a congestion window value according to the quantitative congestion evaluation value, updating the quantitative congestion evaluation value, and updating a first timer, wherein the first timer records a time stamp when the quantitative congestion evaluation value is updated last time; when the report event of the packet processing module comprises a token event, obtaining a relationship between the congestion window value and the number of flying tokens, wherein the number of flying tokens is the number of tokens that have been issued but have not received an acknowledgement response packet; generating a number of tokens to be issued based on the relationship; and issuing new tokens to the packet processing module based on the number of tokens to be issued. The method can realize the conversion from a window to a token.

Description

Technical Field

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

[0002] The primary purpose of congestion control (CC) algorithms is to manage network traffic, prevent network congestion, and ensure efficient transmission of data packets within the network. By adjusting the transmission rate, congestion control algorithms can avoid wasting network resources, reduce data loss and latency, improve overall network throughput and stability, and thus guarantee the quality of network service.

[0003] DCTCP (Data Center TCP) is a classic congestion control algorithm for TCP protocols in data centers. It is designed to support TCP networks with high burst tolerance, low latency, and high throughput, and requires no special configuration or changes to the switch (i.e., it is based solely on shallow buffers). The DCTCP algorithm is based on the traditional TCP Reno algorithm and has been specifically optimized for congestion signal processing.

[0004] RDMA (Remote Direct Memory Access) networking is a high-performance networking technology that allows one computer on a network to directly access the memory of another computer without the intervention of the operating system or CPU, thereby achieving efficient data transmission. The IB protocol specifies the constraints that must be met to implement RDMA network cards. These constraints largely limit the design of RDMA congestion control algorithms from TCP implementations, thus introducing TCP algorithms into RDMA network cards presents various challenges.

[0005] For example, the DCTCP algorithm is actually an optimization of the traditional TCP algorithm. It still uses a window as a constraint for packet sending and is controlled by the software layer. However, due to complexity considerations, RDMA network cards, which need to offload the entire protocol stack to hardware, typically use rate or token modes. Therefore, there is an urgent need to correctly implement the window-to-token conversion. Summary of the Invention

[0006] Therefore, it is necessary to provide a congestion control method, apparatus, chip, network interface card, device, medium, and program product that can realize the conversion from window to token, in order to address the above-mentioned technical problems.

[0007] In a first aspect, this application provides a congestion control method applied to an RDMA device, the method comprising:

[0008] If no congestion notification message is received within the acceleration period after receiving the reported events from the message processing module, the quantized congestion assessment value is updated.

[0009] In the case that the message processing module reports a congestion notification message event, the congestion window value is adjusted according to the quantized congestion assessment value, and the quantized congestion assessment value is updated, and the first timer is updated, wherein the first timer records the timestamp of the last update of the quantized congestion assessment value.

[0010] When the message processing module reports events including token events, the relationship between the congestion window value and the number of flying tokens is obtained. Based on the relationship between the congestion window value and the number of flying tokens, a number of tokens to be issued is generated. Based on the number of tokens to be issued, new tokens are issued to the message processing module. The number of flying tokens is the number of tokens that have been issued without receiving an acknowledgment response message.

[0011] In one embodiment, the method includes:

[0012] Obtain the first timestamp and the second timestamp, where the first timestamp is the reporting timestamp of the current reporting event by the message processing module, and the second timestamp is the timestamp of the last update of the quantized congestion assessment value.

[0013] If the first timestamp is more than the second timestamp after the acceleration period, it is detected that no congestion notification message was received during the acceleration period.

[0014] In one embodiment, generating the number of tokens to be issued based on the relationship between the congestion window value and the number of flight tokens includes:

[0015] If the congestion window value is greater than the number of flight tokens, the number of tokens to be issued is obtained based on the congestion window value and the number of flight tokens, and the number of flight tokens is updated based on the number of tokens to be issued.

[0016] If the congestion window value is less than or equal to the number of flight tokens, the number of tokens to be issued is determined to be 0.

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

[0018] In the event reported by the message processing module, including a message denial event, the congestion window value is multiplicatively reduced, and the number of flight tokens and the number of flight messages are updated before entering the congestion avoidance phase; or the number of flight tokens is set to 0 before entering the congestion avoidance phase, where the number of flight messages is the number of messages sent that have not received an acknowledgment response message.

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

[0020] When the message processing module reports an event including a message acknowledgment event, update the number of flight tokens and the number of flight messages, or update the number of flight tokens based on the number of acknowledgment messages corresponding to the message acknowledgment event. The number of flight messages is the number of messages that have been sent without receiving an acknowledgment response message.

[0021] If the current stage is a slow start stage, the congestion window value is increased additively;

[0022] If the cumulatively increasing congestion window value exceeds the slow start threshold, the system enters the congestion avoidance phase.

[0023] If the current phase is not a slow start phase, the congestion window value is increased slowly.

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

[0025] In the case of a message sending event reported by the message processing module, the number of flying messages is updated, which is the number of sent messages for which no acknowledgment response message has been received.

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

[0027] Upon detecting a transmission timeout event, the slow start threshold and the congestion window value are reset, and the number of flight tokens and the number of flight messages are updated before entering the slow start phase. The number of flight messages is the number of messages sent that have not received an acknowledgment response message.

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

[0029] If the difference between the reporting timestamp of the current event and the timestamp of the last message transmission is greater than the message timeout threshold, a transmission timeout is determined.

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

[0031] If the currently reported event is the first event in the current stream processing, the algorithm is initialized and the slow start phase is entered.

[0032] In one embodiment, the reporting events of the message processing module carry priorities: the priority of the quantified congestion assessment value update event is higher than the priority of the message sending event; the priority of the message sending event is higher than the priority of the message acknowledgment event; the priority of the message acknowledgment event is higher than the priority of the congestion notification message event; the priority of the congestion notification message event is higher than the priority of the message denial event; the priority of the message denial event is higher than the priority of the timeout self-check event; and the priority of the timeout self-check event is higher than the priority of the token event.

[0033] Secondly, this application also provides a congestion control device, the device comprising:

[0034] The receiving module is used to receive the reported events from the message processing module. If no congestion notification message is received within the acceleration period, the quantized congestion assessment value is updated.

[0035] The congestion window adjustment module is used to adjust the congestion window value according to the quantized congestion assessment value and update the quantized congestion assessment value when the message processing module reports an event including a congestion notification message event, and to update the first timer, wherein the first timer records the timestamp of the last update of the quantized congestion assessment value.

[0036] A token issuance module is used to, when the message processing module reports events including token events, obtain the relationship between the congestion window value and the number of flying tokens, generate a number of tokens to be issued based on the relationship between the congestion window value and the number of flying tokens, and issue new tokens to the message processing module based on the number of tokens to be issued, wherein the number of flying tokens is the number of tokens that have been issued without receiving an acknowledgment response message. Thirdly, 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 in any of the above embodiments.

[0037] Fourthly, this application also provides a network interface card, including the chip and multiple interfaces as described in any of the above embodiments.

[0038] The chip processes data or communicates with the outside world through the interface.

[0039] Fifthly, this application also provides a computer device including a network interface card in any of the above embodiments, the network interface card being used for processing data or external communication.

[0040] Sixthly, 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 methods in any of the above embodiments.

[0041] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method in any of the above embodiments.

[0042] The aforementioned congestion control method, device, chip, network interface card, equipment, medium, and program products receive events reported by the message processing module. If no congestion notification message is received within the acceleration period, the quantized congestion assessment value is updated. If the message processing module's reported events include congestion notification message events, the congestion window value is adjusted based on the quantized congestion assessment value, and the quantized congestion assessment value is updated, as well as the first timer is updated. The first timer records the timestamp of the last update of the quantized congestion assessment value. If the message processing module's reported events include token events, the relationship between the congestion window value and the number of flying tokens is obtained. The number of flying tokens is the number of tokens that have been sent without receiving an acknowledgment response message. Based on the relationship between the congestion window value and the number of flying tokens, a number of tokens to be issued is generated. Based on the number of tokens to be issued, new tokens are issued to the message processing module. This provides a window and token conversion strategy based on a hardware token mechanism. The algorithm execution module maintains the congestion window value and the number of flying tokens separately, without exposing them to the hardware message processing module, achieving transparent automatic conversion. Attached Figure Description

[0043] 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.

[0044] Figure 1 This is a schematic diagram illustrating the change process of the Reno congestion window, a typical TCP congestion control algorithm in traditional technologies.

[0045] Figure 2 This is a schematic diagram of a classic congestion control topology model;

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

[0047] Figure 4 This is a schematic diagram of a congestion control system in one embodiment;

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

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

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

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

[0052] 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.

[0053] It should be noted that the terms "first," "second," etc., used in this application may 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.

[0054] To facilitate understanding of this article, combined with Figure 1 As shown, Figure 1 This diagram illustrates the typical TCP congestion control algorithm, Reno, and its congestion window change process. The TCP Reno algorithm comprises four main stages: slow start, congestion avoidance, and congestion signaling (including timeout retransmission, fast retransmission, and fast recovery). The following is a description of these processes:

[0055] Slow start: The main purpose of slow start is to gradually probe the available bandwidth of the network during the initial connection establishment phase, preventing sudden network congestion. When a TCP connection begins transmitting data, the initial congestion window (cwnd) is usually set to a small value, such as one or two maximum segment sizes (MSS). Each time an acknowledgment (ACK) packet is received, the congestion window increases by 1 MSS, meaning the congestion window size doubles every round-trip time (RTT), i.e., cwnd = 2 * cwnd. This exponential growth continues until packet loss occurs (meaning network congestion) or a pre-set threshold is reached, called the slow start threshold (ssthresh). Because the window size grows exponentially, the slow start phase can quickly reach the network's maximum transmission capacity, but it can also lead to network congestion too quickly.

[0056] Congestion Avoidance: After reaching the slow start threshold (ssthresh), TCP enters the congestion avoidance phase to prevent network congestion, gradually increasing the sending rate. When cwnd reaches or exceeds the slow start threshold, the growth of the congestion window changes from exponential to linear. Specifically, for each ACK received, the congestion window increases by only MSS / cwnd. At the end of each round-to-trib (RTT), the congestion window increases by approximately one MSS, i.e., cwnd = cwnd + MSS. This linear growth allows for a smoother probe of the network's available bandwidth, reducing the risk of congestion. The growth rate in the congestion avoidance phase is much slower than slow start, making it more robust and helping to maintain network stability.

[0057] Congestion Signal Handling: Timeout Retransmission, Fast Retransmission, and Fast Recovery. TCP primarily detects network congestion through packet loss events and takes corresponding measures. Timeout Retransmission: If a data packet does not receive an ACK within a certain time, TCP assumes the packet is lost. At this time, TCP sets the slow start threshold (ssthresh) to half the current window size, i.e., ssthresh = 0.5 * cwnd, and resets the congestion window (cwnd) to its initial value (usually 1 MSS), i.e., cwnd = MSS, and then enters the slow start phase. Fast Retransmission: When TCP receives three consecutive duplicate ACKs (usually indicating a lost packet but subsequent packets arrived successfully), it immediately retransmits the lost packet instead of waiting for a timeout. This mechanism accelerates the packet loss recovery process. Fast Recovery: After fast retransmission, TCP does not directly enter slow start but instead enters the fast recovery phase. At this point, TCP sets the slow start threshold (ssthresh) to half of the current congestion window, and simultaneously sets the congestion window to the slow start threshold plus 3 MSS (because 3 duplicate ACKs have been received), i.e., cwnd = ssthresh + 3 * MSS. Afterward, TCP enters the congestion avoidance phase instead of slow start. The purpose of this is to quickly restore the transmission rate to its pre-packet loss state and avoid unnecessary slowdowns. Fast retransmit and fast recovery mechanisms effectively reduce the latency of waiting for timeout retransmissions, improving network transmission efficiency and overall performance.

[0058] The core idea of ​​DCTCP is that the magnitude of the response to congestion should be proportional to the degree of congestion, rather than blindly halving the congestion window as in traditional TCP congestion control. Figure 2 As shown, Figure 2It is a schematic diagram of a classic congestion control topology model. In this embodiment, CP (Congestion Point): The congestion point, usually referring to a switch node, is used to determine whether congestion has occurred and adopts the ECN (Explicit Congestion Notification) marking mechanism. When a data packet arrives, the CP evaluates whether the current queue depth exceeds the threshold K. If so, the data packet is marked as ECN CE (Congestion Experienced); otherwise, it is not marked.

[0059] NP (Notification Point): The notification point, usually referring to the destination end of the data packet, is used to send back the congestion signal. When the destination end receives a data packet marked with ECN CE, it needs to mark ECN-Echo in the ACK packet and send it back to the sender. The ECN-Echo marking supports ACK aggregation.

[0060] RP (Reaction Point): The reaction point, usually referring to the sender of the data packet, is used to process the sent-back congestion signal and perform the up / down speed (window) reaction action. The sender maintains a congestion quantization parameter α, which is used to estimate the proportion of data packets marked with ECN CE. It is updated once per window period (RTT). The update formula for α is: α=(1 - g)·α + g·F. Here, 0 < g < 1 is a weight parameter used to adjust the influence of new samples on α; F represents the proportion of data packets marked with ECN CE in the previous statistical window period. It can be seen that the update of α follows the idea of moving average. When the CP queue exceeds the threshold K, for each data packet, the RP can receive ECN Echo; when the CP queue is less than K, the RP cannot receive ECN-Echo. Therefore, it is reasonable to use α to estimate the probability that the queue length exceeds K (that is, the congestion degree). When α is close to 1, it means that the congestion at the CP is very serious; when α is close to 0, it means that the congestion at the CP is very slight.

[0061] The difference between DCTCP and the classic TCP Reno algorithm in adjusting the congestion window lies in the congestion handling logic. In addition to having the duplicate ACK congestion handling and timeout handling, DCTCP also supports the ECN-based quantization congestion handling, that is, cwnd = cwnd·(1 - α / 2). The TCP Reno algorithm does not specifically utilize the ECN signal and does not have the congestion quantization ability. It always halves the congestion window. The DCTCP algorithm uses the α parameter to adjust the window reduction ratio. It is easy to see that when α = 1 (the congestion is very serious), DCTCP degrades to the traditional TCP Reno algorithm. In other words, DCTCP is more gentle in the "multiplicative decrease" process during congestion and can reduce over-reactions.

[0062] The congestion control method provided in this application can be applied to, for example, Figure 3 In the application environment shown, the data transmitter 102 communicates with the data receiver 104 via a network. Both the data transmitter 102 and the data receiver 104 can be terminals or servers. Terminals can be, but are not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted displays, etc. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing cloud computing services.

[0063] Combination Figure 4 As shown, Figure 4 This is a schematic diagram of a congestion control system in one embodiment. The congestion control system can be located at the data sending end 102 and the data receiving end 104, without being specifically limited here. The system includes a message processing module and an algorithm execution module. The message processing module is used to receive and send messages, and generate reporting events based on congestion-related signals during the message receiving and sending process. The reporting events include token events. The algorithm execution module is used to execute the congestion control method.

[0064] Both the data transmitter 102 and the data receiver 104 are RDMA devices. RDMA devices communicate through RDMA technology. RDMA (Remote Direct Memory Access) technology allows one computer on the network to directly access the memory of another computer without the intervention of the operating system or CPU, thereby achieving efficient data transmission. Optionally, the RDMA device can be an RDMA network card.

[0065] In terms of hardware and software division of labor, the hardware, namely the message processing module, is responsible for sending and receiving messages, generating congestion-related event signals, and reporting event requests. The software, namely the algorithm execution module, is responsible for parsing event requests, executing the DCTCP core algorithm logic, and generating token responses.

[0066] Specifically, the algorithm execution module receives events reported by the message processing module. If no congestion notification message is received within the acceleration period, the quantized congestion assessment value is updated. If the message processing module's reported events include congestion notification message events, the congestion window value is adjusted based on the quantized congestion assessment value, and the quantized congestion assessment value is updated, as well as the first timer, which records the timestamp of the last quantized congestion assessment value update. If the message processing module's reported events include token events, the relationship between the congestion window value and the number of flying tokens is obtained. The number of flying tokens is the number of tokens that have been issued without receiving an acknowledgment response message. Based on the relationship between the congestion window value and the number of flying tokens, a number of tokens to be issued is generated. Based on the number of tokens to be issued, new tokens are issued to the message processing module. This hardware token mechanism provides a conversion strategy between the window and the token. The algorithm execution module maintains the congestion window value and the number of flying tokens separately, without exposing them to the hardware message processing module, achieving transparent automatic conversion.

[0067] In one exemplary embodiment, such as Figure 5 As shown, a congestion control method is provided, which is applied to... Figure 4 The algorithm execution module in the example is used for illustration, including the following steps S502 to S506. Wherein:

[0068] S502: The message processing module reports an event. If no congestion notification message is received within the acceleration period, the quantized congestion assessment value is updated.

[0069] Among them, after the algorithm execution module determines whether the reported event is the first time of the current flow processing and performs the corresponding processing, the algorithm execution module detects whether the update event of the quantized congestion assessment value is triggered. That is, if no congestion notification message is received during the acceleration period, the quantized congestion assessment value is updated. The update formula is the same as the update formula during acceleration: alpha=alpha*(1-g), where g is the congestion gain factor (the value range is [0,1], and the initial value is recommended to be 1 / 256).

[0070] In some optional embodiments, the method further includes: obtaining a first timestamp and a second timestamp, wherein the first timestamp is the reporting timestamp of the current reporting event of the message processing module, and the second timestamp is the timestamp of the last update of the quantized congestion assessment value; if the first timestamp is more than the acceleration period away from the second timestamp, it is detected that no congestion notification message was received within the acceleration period.

[0071] Specifically, the algorithm execution module detects whether no Congestion Notification (CNP) messages have been received during the acceleration period. The detection method is to determine whether timestamp – t_alpha_timestamp > T. Here, timestamp is the first timestamp, t_alpha_timestamp is the second timestamp, and T is the acceleration period. If it is true, the quantized congestion assessment value alpha is updated.

[0072] S504: When the message processing module reports events including congestion notification message events, adjust the congestion window value according to the quantized congestion assessment value, update the quantized congestion assessment value, and update the first timer, wherein the first timer records the timestamp of the last quantized congestion assessment value update.

[0073] Adjusting the congestion window value based on the quantified congestion assessment value involves multiplicatively reducing the congestion window value based on the quantified congestion assessment value. After the congestion window value is updated, the quantified congestion assessment value also needs to be updated, and the value of the first time counter needs to be reset. The congestion notification message corresponding to the congestion notification message event is generated by the destination end based on the ECN filtering timeline.

[0074] In traditional technologies, the DCTCP algorithm requires the destination to carry ECN-Echo information in the ACK for the source to perform congestion quantization assessment. RDMA network cards, however, generate CNP packets according to the RoCEv2 protocol, and these CNP packets are generated based on the destination's ECN filtering pipeline. Therefore, implementing the DCTCP algorithm on an RDMA network card requires addressing how to implement the congestion quantization capabilities of the DCTCP algorithm based on CNP packets.

[0075] In this embodiment, the algorithm execution module receives a congestion notification message event, namely the CNP event CNP_EVENT. The CNP is sent back by the destination end according to the ECN filtering timeline K, meaning only one CNP message is generated for each K time period of ECN messages. When the source end detects congestion, it performs a window reduction operation using the congestion quantization logic of DCQCN. This involves multiplicatively reducing the congestion window value based on the quantized congestion assessment value. The window reduction formula is: cwnd = cwnd * (1 – alpha / 2). Furthermore, the quantized congestion assessment value alpha is updated according to the update formula during rate reduction: alpha = alpha * (1 - g) + g. Here, alpha is the congestion quantization assessment value (range [0,1], initial value recommended to be 1), and g is the congestion gain factor (range [0,1], initial value recommended to be 1 / 256). Since the quantized congestion assessment value is updated, the first time counter also needs to be reset.

[0076] The CNP_EVENT event mentioned above is generated when the message processing module receives a CNP message. The reporting information of the CNP_EVENT event includes the current timestamp, which is also the reporting timestamp of the event.

[0077] Through the above embodiments, CNP signals are used to achieve quantified congestion reduction, and a DCQCN-like algorithm strategy is adopted to update the quantified congestion assessment value alpha. alpha can increase or decrease with changes in network congestion conditions, thereby realizing the function of congestion quantification assessment and adjusting the congestion window value accordingly.

[0078] S506: When the message processing module reports events including token events, obtain the relationship between the congestion window value and the number of flying tokens, generate a number of tokens to be issued based on the relationship between the congestion window value and the number of flying tokens, and issue new tokens to the message processing module based on the number of tokens to be issued, wherein the number of flying tokens is the number of tokens that have been issued without receiving an acknowledgment response message.

[0079] Among them, the token event is generated by the message processing module when it determines that the token amount in the local token bucket is insufficient to send the next message (i.e., the token is 0). The reported information of the token event TOKEN_EVENT includes the current timestamp, which is also the reporting timestamp of the token event.

[0080] Specifically, the token control mechanism of the message processing module may include: the message processing module uses a separate token bucket for each flow, and the size of the token bucket represents the number of messages that can be sent. When the token bucket's `token_local` limit for the current flow is greater than 0, if there are messages to be sent, the maximum number of messages corresponding to the `token_local` value can be sent. If there are messages to be sent and `token_local` is 0, a token event `TOKEN_EVENT` needs to be reported to the algorithm execution module. The message processing module puts the response token value `token_response` from the algorithm execution module into the token bucket and resends the messages according to the latest token bucket limit. When the number of messages sent exceeds the single burst limit or the token bucket limit is reset to zero, the next flow is scheduled to send messages.

[0081] The TOKEN_EVENT event is generated when the local token bucket has insufficient tokens to send the next message (i.e., the token amount is 0). The reporting information of the TOKEN_EVENT event includes the current timestamp, which is also the reporting timestamp of the event.

[0082] The number of flight tokens is the number of tokens that have been issued without receiving an acknowledgment response message. In other words, the algorithm execution module has issued the tokens to the message receiving module, but the message receiving module has not received an acknowledgment response message for the message corresponding to the token.

[0083] The window value used internally by the algorithm execution module also adopts the message granularity, and the congestion window value is not exposed to the message processing module. The algorithm execution module performs the conversion between the congestion window and the token, that is, it generates the number of tokens to be issued based on the relationship between the congestion window value and the number of flying tokens.

[0084] In some optional embodiments, the number of tokens to be issued is generated based on the relationship between the congestion window value and the number of flight tokens, including: when the congestion window value is greater than the number of flight tokens, obtaining the number of tokens to be issued based on the congestion window value and the number of flight tokens, and updating the number of flight tokens based on the number of tokens to be issued; when the congestion window value is less than or equal to the number of flight tokens, determining the number of tokens to be issued to be 0.

[0085] Specifically, when the algorithm execution module receives a token event TOKEN_EVENT, it checks whether cwnd > token_una. If so, it updates the number of tokens to be issued, token_return = cwnd – token_una. Here, token_return is the token response value for the current token event TOKEN_EVENT, cwnd is the congestion window value, and token_una is the number of issued but unacknowledged tokens (i.e., the number of tokens explicitly issued by the algorithm execution module that have not been acknowledged by an ACK packet; also understood as the number of fly tokens). Furthermore, the number of fly tokens is updated based on the number of tokens to be issued; that is, after issuing tokens, the algorithm execution module needs to update token_una.

[0086] The method for updating the number of flight tokens is token_una = token_una + token_return, where token_return is the size of the tokens authorized in this instance, which is also the number of tokens to be issued.

[0087] In other embodiments, if the `token_used` parameter is not used (and therefore there is no need to rely on the reporting of the message sending event `PKT_EVENT`), only `token_una` is used to record the amount of tokens that have been issued but not yet confirmed. If `cwnd > token_una`, then `token_una = token_una + token_return`, where `token_return` is the size of the tokens authorized in this instance, i.e., the number of tokens to be issued.

[0088] If cwnd > token_una is not satisfied, token_return is 0.

[0089] To address the contradiction between the window control method and the actual hardware control mode, this embodiment provides a window and token conversion strategy based on a hardware token mechanism, namely, token_return = cwnd – token_una. The algorithm execution module maintains the congestion window cwnd and the distributed but unconfirmed token value token_una information separately, without exposing it to the hardware module, thus achieving transparent automatic conversion.

[0090] Furthermore, since the DCTCP algorithm follows the TCP protocol and uses byte-represented sequence numbers as the basis for congestion window adjustment, while RDMA network cards, according to the IB specification, use packet sequence numbers (PSNs) as packet header information, there is a unit inconsistency in window adjustment. Implementing the DCTCP algorithm on RDMA network cards requires solving how to achieve window adjustment at the packet granularity. This application addresses the contradiction between sequence numbers and PSNs by employing packet-granular congestion windowing and token control, thus resolving the aforementioned contradiction.

[0091] The congestion control method described above receives events reported by the message processing module. If no congestion notification message is received within the acceleration period, the quantized congestion assessment value is updated. If the message processing module's reported events include congestion notification message events, the congestion window value is adjusted based on the quantized congestion assessment value, and the quantized congestion assessment value is updated, along with a first timer, which records the timestamp of the last update of the quantized congestion assessment value. If the message processing module's reported events include token events, the relationship between the congestion window value and the number of flying tokens is obtained, where the number of flying tokens is the number of tokens sent without receiving an acknowledgment response message. Based on the relationship between the congestion window value and the number of flying tokens, a number of tokens to be issued is generated. Based on the number of tokens to be issued, new tokens are issued to the message processing module. This hardware token mechanism provides a conversion strategy between the window and the token. The algorithm execution module maintains the congestion window value and the number of flying tokens separately, without exposing them to the hardware message processing module, achieving transparent automatic conversion.

[0092] In some optional embodiments, the method further includes: when the reported event of the message processing module includes a message denial event, multiplicatively reducing the congestion window value and updating the number of flight tokens and the number of flight messages, and then entering the congestion avoidance phase; or setting the number of flight tokens to 0 and then entering the congestion avoidance phase, wherein the number of flight messages is the number of sent messages for which no acknowledgment response message has been received.

[0093] In traditional DCTCP algorithms, the destination follows the TCP protocol, generating duplicate ACK packets for unexpected out-of-order messages. The source detects congestion by identifying duplicate ACKs. However, RDMA network cards, according to the IB specification, handle out-of-order messages by generating a NAK packet only after the first out-of-order message is received, and silently discarding subsequent out-of-order packets. Implementing the DCTCP algorithm on an RDMA network card requires addressing how to achieve congestion detection based on NAK packets.

[0094] Therefore, the algorithm execution module in this application detects whether the event includes a message denial event NAK_EVENT. The message denial event NAK_EVENT is generated by the message processing module when it receives a NAK message. The reporting information of the NAK_EVENT event includes the current timestamp, which is also the reporting timestamp.

[0095] If the event includes a message denial event (NAK_EVENT), the congestion window value is multiplicatively reduced using the update formula: ssthresh = cwnd * (1 - beta), where cwnd = ssthresh, and beta is 0.5. Then, the distributed unacknowledged token value (token_una) and the used unacknowledged token value (token_used) are updated using the formula: token_una = token_una – token_used, where token_used = 0. This is because in an RDMA network, the destination only sends a NAK signal for the first out-of-order message; subsequent out-of-order messages are silently discarded. Therefore, when the source receives a NAK message, it can be inferred that all previously received out-of-order messages corresponding to token_used will be silently discarded. Finally, the congestion avoidance phase begins.

[0096] In other embodiments, where the token_used parameter is not used (and therefore there is no need to rely on the reporting of the PKT_EVENT event), and only the token_una is used to record the amount of issued but unconfirmed tokens, the number of flight tokens is directly set to 0, i.e., token_una=0.

[0097] In the above embodiments, to address the conflict between the repeated ACK mechanism and the NAK mechanism, the NAK signal is used to identify congestion and the congestion window is updated in real time.

[0098] In some optional embodiments, the method further includes: when the message processing module's reporting event includes a message acknowledgment event, updating the number of flight tokens and the number of flight messages, or updating the number of flight tokens based on the number of acknowledgment messages corresponding to the message acknowledgment event, wherein the number of flight messages is the number of sent messages for which no acknowledgment response message has been received; when the current stage is a slow start stage, additively increasing the congestion window value; when the additively increased congestion window value is greater than the slow start threshold, entering the congestion avoidance stage; when the current stage is not a slow start stage, slowly increasing the congestion window value.

[0099] In traditional technologies, the DCTCP algorithm follows the TCP protocol, and the destination (receiving end) supports out-of-order packet reception, so out-of-order packets are received when they arrive. However, RDMA network cards, according to the IB specification, generate a NAK packet after receiving the first out-of-order packet, and silently discard subsequent packets. The source (sender) executes go-back-N upon receiving the NAK packet, and begins retransmitting packets based on the PSN sequence number indicated in the NAK packet. Implementing the DCTCP algorithm on an RDMA network card requires solving how to calculate the number of packets in flight and the available window size based on the NAK and go-back-N retransmission mechanisms.

[0100] The ACK_EVENT message acknowledgment event is generated when the message processing module receives an ACK message. The reported information for this ACK_EVENT event includes the number of acknowledgment messages (acked_num) and the current timestamp. Typically, acked_num is calculated as: acked_num = psn_acked_cur – psn_acked_last, which means subtracting the PSN from the previous acknowledgment message's PSN in the current acknowledgment message.

[0101] Specifically, the algorithm execution module checks whether the event includes a message acknowledgment event (ACK_EVENT). If so, it updates the distributed unacknowledged token value (token_una) and the used unacknowledged token value (token_used) using the formulas: token_una = token_una – ack_num, token_used = token_used – ack_num. Then, it determines whether the algorithm is in the slow start phase. If so, it rapidly and additively increases the congestion window size using the formula: cwnd = cwnd + ack_num. After updating the congestion window size, it further checks whether it exceeds the slow start threshold (ssthresh). If cwnd > ssthresh, the algorithm enters the congestion avoidance phase; otherwise, it directly executes the next judgment logic. Otherwise, the algorithm remains in the congestion avoidance phase, slowly increasing the congestion window size using the formula: cwnd = cwnd + ack_num / cwnd.

[0102] In other embodiments, i.e., when the token_used parameter is not used (and therefore there is no need to rely on the reporting of the PKT_EVENT event), and only token_una is used to record the amount of issued but unconfirmed tokens, token_una = MAX(token_una – ack_num, 0), where ack_num represents the number of confirmation messages for the current event, and MAX means taking the maximum value to prevent token_una from being updated to a negative number.

[0103] In the above embodiments, based on the characteristics of RDMA source-end go-back-N retransmission and destination-end silent discarding of out-of-order packets, it supports the correct updating of the distributed unacknowledged token value token_una=token_una–token_used and the flight packet count token value token_used=0, and correctly calculates the available window size (which is also the token value that can be issued during the token event) token_return=cwnd–token_una.

[0104] In some optional embodiments, the method further includes: updating the number of flying messages when the reporting event of the message processing module includes a message sending event, wherein the number of flying messages is the number of sent messages for which no acknowledgment response message has been received.

[0105] The message sending event PKT_EVENT is generated after a number of data packets have been successfully sent. The information reported by the message sending event PKT_EVENT includes the number of data packets sent (sent_num) and the current timestamp. Typically, sent_num is calculated as: sent_num = psn_sent_cur – psn_sent_last, which is the PSN of the latest packet sent in the current burst data packet group minus the PSN of the latest packet sent in the last burst.

[0106] The algorithm execution module detects whether the event includes a message sending event PKT_EVENT. If so, it updates the used unconfirmed token value token_used. The update formula is: token_used = token_used + sent_num, where sent_num is calculated as: sent_num = psn_sent_cur – psn_sent_last, which is the PSN of the latest message sent in the current burst data packet group minus the PSN of the latest message sent in the last burst.

[0107] In the above embodiments, the message sending event PKT_EVENT is used to count the number of flying messages, so as to distinguish them from the message processing module that has acquired unused tokens.

[0108] In some optional embodiments, the method further includes: upon detecting a transmission timeout event, resetting the slow start threshold and congestion window value, and updating the number of flight tokens and the number of flight messages, and then entering the slow start phase, wherein the number of flight messages is the number of sent messages for which no acknowledgment response message has been received.

[0109] In some optional embodiments, the method further includes: determining a transmission timeout if the difference between the reporting timestamp of the current reported event and the timestamp of the last message transmission is greater than a message timeout threshold.

[0110] Specifically, the algorithm execution module checks whether timeout information can be inferred. The inference method is to determine whether timestamp – last_sent_timestamp > RTO. Here, last_sent_timestamp is the timestamp of the most recent packet transmission, and RTO is the packet timeout watermark. If it is true, it indicates a transmission timeout, and the congestion window value needs to be reset. The update formula is: ssthresh = cwnd * (1 - beta), cwnd = init_cwnd, where beta is 0.5, meaning that after setting the slow start threshold to half of the current congestion window, the congestion window is reset to its initial value. Subsequently, token_una and token_used are updated in the same way as NAK_EVENT. Finally, the algorithm enters the slow start phase.

[0111] In other embodiments, where the token_used parameter is not used (and therefore there is no need to rely on the reporting of PKT_EVENT events), and only token_una is used to record the amount of issued but unconfirmed tokens, token_una=0.

[0112] In some alternative embodiments, the method further includes: performing algorithm initialization and entering a slow start phase if the currently reported event is the first event of the current stream processing.

[0113] At the beginning, the algorithm execution module first determines whether the reported event is the first event processed in the current stream. If so, it initializes the algorithm state parameters (Congestion Control Context, CCC) and puts the algorithm into the Slow Start (SS) phase.

[0114] For ease of understanding, combined with Figure 6 As shown, Figure 6 Here is a flowchart of a congestion control algorithm in another embodiment, which specifically includes the following steps:

[0115] The algorithm execution module first determines whether the reported event is the first event processed in the current stream. If so, it initializes the algorithm state parameters (Congestion Control Context, CCC) and enters the Slow Start (SS) phase. Otherwise, it directly executes the next judgment logic.

[0116] The algorithm execution module detects whether a congestion notification message has been received during the acceleration period. The detection method is to determine whether timestamp – t_alpha_timestamp > T. Here, timestamp is the event stamp of the current event, and t_alpha_timestamp is the timestamp of the last update of the alpha value. If true, the quantized congestion assessment value alpha is updated using the formula: alpha = alpha * (1 - g). Otherwise, the next judgment logic is executed directly.

[0117] The algorithm checks whether the reported events detected by the module include the message sending event PKT_EVENT. If so, it updates the used unconfirmed token value token_used using the formula: token_used = token_used + sent_num. Otherwise, it proceeds directly to the next judgment logic.

[0118] The algorithm execution module checks if the event includes a message acknowledgment event (ACK_EVENT). If so, it updates the distributed unacknowledged token value (token_una) and the used unacknowledged token value (token_used) using the formulas: token_una = token_una – ack_num, token_used = token_used – ack_num. Then, it determines if the algorithm is in the slow start phase. If so, it rapidly and additively increases the congestion window size using the formula: cwnd = cwnd + ack_num. After updating the congestion window size, it further checks if it exceeds the slow start threshold (ssthresh). If cwnd > ssthresh, the algorithm enters the congestion avoidance phase; otherwise, it proceeds directly to the next step. Otherwise, the algorithm remains in the congestion avoidance phase, slowly increasing the congestion window size using the formula: cwnd = cwnd + ack_num / cwnd. If there is no ACK_EVENT, it proceeds directly to the next step.

[0119] The algorithm execution module checks whether the event includes a congestion notification message (CNP_EVENT). If so, it multiplicatively reduces the congestion window size based on the quantized congestion assessment value, with the update formula: cwnd = cwnd * (1 – alpha / 2). After updating the congestion window, the quantized congestion assessment value alpha also needs to be updated, with the update formula: alpha = alpha * (1 - g) + g. Finally, the first timer is reset, and the first timer records the timestamp of the last update of the quantized congestion assessment value, i.e., t_alpha_timestamp = timestamp. Otherwise, it directly executes the next judgment logic.

[0120] The algorithm execution module checks if the event includes a packet denial event (NAK_EVENT). If so, it multiplicatively reduces the congestion window size using the formula: ssthresh = cwnd * (1 - beta), where cwnd = ssthresh, and beta is 0.5. Then, it updates the distributed unacknowledged token value (token_una) and the used unacknowledged token value (token_used) using the formula: token_una = token_una – token_used, where token_used = 0. This is because in RDMA networks, the destination only sends a NAK signal for the first out-of-order packet; subsequent out-of-order packets are silently discarded. Therefore, when the source receives a NAK packet, it can be inferred that all previously received packets corresponding to token_used will be silently discarded. Finally, it enters the congestion avoidance phase. Otherwise, it directly executes the next judgment logic.

[0121] The algorithm execution module checks for timeout events, which are generated when `timestamp – last_sent_timestamp > RTO` is true. Here, `last_sent_timestamp` is the timestamp of the most recent packet transmission, and `RTO` is the packet timeout watermark. If true, it indicates a transmission timeout, meaning a timeout event has been detected. The congestion window value needs to be reset using the formula: `ssthresh = cwnd * (1 - beta)`, where `cwnd = init_cwnd`, and `beta` is 0.5. This means that after setting the slow start threshold to half the current congestion window value, the congestion window is reset to its initial value. Subsequently, `token_una` and `token_used` are updated in a manner similar to handling the packet denial event `NAK_EVENT`. Finally, the algorithm enters the slow start phase. Otherwise, it directly executes the next judgment logic.

[0122] The algorithm execution module checks if the event includes a token event (TOKEN_EVENT). If so, it determines whether a token can be issued, i.e., whether `cwnd > token_una` is true. If true, it calculates the tokens that can be issued in this instance using the formula `token_return = cwnd – token_una`, and updates the value of the issued but unconfirmed tokens (`token_una = token_una + token_return`). If no token can be issued, it directly returns `token_return = 0`. At this point, all algorithm processing logic ends. If there is no `TOKEN_EVENT`, the algorithm processing logic also ends.

[0123] The above embodiments include at least the following technical effects:

[0124] DCTCP Algorithm Based on RDMA Network Card Characteristics: This application supports the implementation of DCTCP algorithm for RDMA network cards. Compared with DCQCN algorithm, it has advantages such as configuration-based slow start (preventing line rate bursts) and window-based limit on the maximum number of flying packets (preventing congestion caused by excessive network flying packets in rate mode).

[0125] Minimize hardware modification and complexity: This application makes maximum use of existing mechanisms of RDMA network cards, such as CNP mechanism, NAK mechanism, PSN mechanism, etc., without the need for complex hardware modification overhead, and avoids the complexity of offloading the TCP protocol stack to the network card hardware.

[0126] This application provides a highly flexible and scalable DCTCP algorithm: The algorithm execution module is implemented in software, offering advantages in flexibility and scalability. In terms of flexibility, the algorithm behavior can be easily updated for specific event signal processing; in terms of scalability, new event patterns and algorithm logic can be generated based on the parameter information of reported events.

[0127] It should be understood that although the steps in the flowcharts of the above embodiments 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 above embodiments 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.

[0128] In one exemplary embodiment, such as Figure 7 As shown, a congestion control device is provided, including: a receiving module 701, a congestion window value adjustment module 702, and a token issuing module 703, wherein:

[0129] The receiving module 701 is used to receive the reported events from the message processing module. If no congestion notification message is received within the acceleration period, the quantized congestion assessment value is updated.

[0130] The congestion window value adjustment module 702 is used to adjust the congestion window value according to the quantized congestion assessment value and update the quantized congestion assessment value when the message processing module reports an event including a congestion notification message event, and to update the first timer, wherein the first timer records the timestamp of the last update of the quantized congestion assessment value.

[0131] The token issuance module 703 is used to obtain the relationship between the congestion window value and the number of flying tokens when the message processing module reports an event including a token event, generate a number of tokens to be issued based on the relationship between the congestion window value and the number of flying tokens, and issue new tokens to the message processing module based on the number of tokens to be issued, wherein the number of flying tokens is the number of tokens that have been issued without receiving an acknowledgment response message.

[0132] In one optional embodiment, the receiving module 701 is used to obtain a first timestamp and a second timestamp, wherein the first timestamp is the reporting timestamp of the current reporting event of the message processing module, and the second timestamp is the timestamp of the last update of the quantized congestion assessment value. If the first timestamp is more than the second timestamp after the acceleration period, it is detected that no congestion notification message was received within the acceleration period.

[0133] In some optional embodiments, the token issuance module 703 is specifically configured to, when the congestion window value is greater than the number of flight tokens, obtain the number of tokens to be issued based on the congestion window value and the number of flight tokens, and update the number of flight tokens based on the number of tokens to be issued; when the congestion window value is less than or equal to the number of flight tokens, determine that the number of tokens to be issued is 0.

[0134] In some optional embodiments, the above apparatus further includes: a message denial event processing module, configured to, when the message processing module reports an event including a message denial event, multiplicatively reduce the congestion window value, update the number of flight tokens and the number of flight messages, and then enter the congestion avoidance phase; or set the number of flight tokens to 0 and then enter the congestion avoidance phase, wherein the number of flight messages is the number of sent messages for which no acknowledgment response message has been received.

[0135] In some optional embodiments, the above apparatus further includes: a message acknowledgment event processing module, configured to update the number of flight tokens and the number of flight messages, or update the number of flight tokens based on the number of acknowledgment messages corresponding to the message acknowledgment event, wherein the number of flight messages is the number of sent messages for which no acknowledgment response message has been received, when the current stage is a slow start stage; when the cumulatively increased congestion window value is greater than the slow start threshold value, enter the congestion avoidance stage; and when the current stage is not a slow start stage, slowly increase the congestion window value.

[0136] In some optional embodiments, the above apparatus further includes: a message transmission event processing module, configured to update the number of flying messages when the message processing module reports an event including a message transmission event, wherein the number of flying messages is the number of sent messages for which no acknowledgment response message has been received.

[0137] In some optional embodiments, the above apparatus further includes: a timeout event processing module, configured to, upon detecting a transmission timeout event, reset the slow start threshold value and the congestion window value, and update the number of flight tokens and the number of flight messages before entering the slow start phase, wherein the number of flight messages is the number of sent messages for which no acknowledgment response message has been received.

[0138] In some optional embodiments, the timeout event handling module is specifically used to determine a timeout when the difference between the reporting timestamp of the current reported event and the timestamp of the last message transmission is greater than the message timeout threshold.

[0139] In some optional embodiments, the above apparatus further includes an initialization module for performing algorithm initialization and entering a slow start phase when the currently reported event is the first event of the current stream processing.

[0140] In some optional embodiments, each event carries a processing priority, with the priority of the quantified congestion assessment update event being higher than that of the message sending event, the priority of the message sending event being higher than that of the message acknowledgment event, the priority of the message acknowledgment event being higher than that of the congestion notification message event, the priority of the congestion notification message event being higher than that of the message denial event, the priority of the message denial event being higher than that of the timeout self-check event, and the priority of the timeout self-check event being higher than that of the token event.

[0141] 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.

[0142] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing 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 an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface, such as a network interface card, is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a congestion control method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0143] Those skilled in the art will understand that Figure 8 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.

[0144] In one 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 implement the steps of the method in any of the above embodiments.

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

[0146] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0147] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0148] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0149] 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.

[0150] 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.

[0151] 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, Applied to RDMA devices, the method includes: If no congestion notification message is received within the acceleration period after receiving the reported events from the message processing module, the quantized congestion assessment value is updated. In the case that the message processing module reports a congestion notification message event, the congestion window value is adjusted according to the quantized congestion assessment value, and the quantized congestion assessment value is updated, and the first timer is updated, wherein the first timer records the timestamp of the last update of the quantized congestion assessment value. When the message processing module reports events including token events, the relationship between the congestion window value and the number of flying tokens is obtained. Based on the relationship between the congestion window value and the number of flying tokens, a number of tokens to be issued is generated. Based on the number of tokens to be issued, new tokens are issued to the message processing module. The number of flying tokens is the number of tokens that have been issued without receiving an acknowledgment response message.

2. The method according to claim 1, characterized in that, The method includes: Obtain the first timestamp and the second timestamp, where the first timestamp is the reporting timestamp of the current reporting event by the message processing module, and the second timestamp is the timestamp of the last update of the quantized congestion assessment value. If the first timestamp is more than the second timestamp after the acceleration period, it is detected that no congestion notification message was received during the acceleration period.

3. The method according to claim 1, characterized in that, The process of generating the number of tokens to be issued based on the relationship between the congestion window value and the number of flight tokens includes: If the congestion window value is greater than the number of flight tokens, the number of tokens to be issued is obtained based on the congestion window value and the number of flight tokens, and the number of flight tokens is updated based on the number of tokens to be issued. If the congestion window value is less than or equal to the number of flight tokens, the number of tokens to be issued is determined to be 0.

4. The method according to claim 1, characterized in that, The method further includes: In the event reported by the message processing module, including a message denial event, the congestion window value is multiplicatively reduced, and the number of flight tokens and the number of flight messages are updated before entering the congestion avoidance phase; or the number of flight tokens is set to 0 before entering the congestion avoidance phase, where the number of flight messages is the number of messages sent that have not received an acknowledgment response message.

5. The method according to claim 1, characterized in that, The method further includes: When the message processing module reports an event including a message acknowledgment event, update the number of flight tokens and the number of flight messages, or update the number of flight tokens based on the number of acknowledgment messages corresponding to the message acknowledgment event. The number of flight messages is the number of messages that have been sent without receiving an acknowledgment response message. If the current stage is a slow start stage, the congestion window value is increased additively; If the cumulatively increasing congestion window value exceeds the slow start threshold, the system enters the congestion avoidance phase. If the current phase is not a slow start phase, the congestion window value is increased slowly.

6. The method according to claim 1, characterized in that, The method further includes: In the case of a message sending event reported by the message processing module, the number of flying messages is updated, which is the number of sent messages for which no acknowledgment response message has been received.

7. The method according to claim 1, characterized in that, The method further includes: Upon detecting a transmission timeout event, the slow start threshold and the congestion window value are reset, and the number of flight tokens and the number of flight messages are updated before entering the slow start phase. The number of flight messages is the number of messages sent that have not received an acknowledgment response message.

8. The method according to claim 7, characterized in that, The method further includes: If the difference between the reporting timestamp of the current event and the timestamp of the last message transmission is greater than the message timeout threshold, a transmission timeout is determined.

9. The method according to claim 1, characterized in that, The method further includes: If the currently reported event is the first event in the current stream processing, the algorithm is initialized and the slow start phase is entered.

10. The method according to any one of claims 1 to 9, characterized in that, Each event carries a processing priority. The priority of the quantified congestion assessment value update event is higher than that of the message sending event. The priority of the message sending event is higher than that of the message acknowledgment event. The priority of the message acknowledgment event is higher than that of the congestion notification message event. The priority of the congestion notification message event is higher than that of the message denial event. The priority of the message denial event is higher than that of the timeout self-check event. The priority of the timeout self-check event is higher than that of the token event.

11. A congestion control device, characterized in that, The device includes: The receiving module is used to receive the reported events from the message processing module. If no congestion notification message is received within the acceleration period, the quantized congestion assessment value is updated. The congestion window adjustment module is used to adjust the congestion window value according to the quantized congestion assessment value and update the quantized congestion assessment value when the message processing module reports an event including a congestion notification message event, and to update the first timer, wherein the first timer records the timestamp of the last update of the quantized congestion assessment value. The token issuance module is used to obtain the relationship between the congestion window value and the number of flying tokens when the message processing module reports events including token events, generate a number of tokens to be issued based on the relationship between the congestion window value and the number of flying tokens, and issue new tokens to the message processing module based on the number of tokens to be issued. The number of flying tokens is the number of tokens that have been issued without receiving an acknowledgment response message.

12. 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 10.

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

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

15. 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 10.

16. 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 10.

Images