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

Abstract

Provided in the embodiments of the present disclosure are a congestion control method, a network interface card device, a storage medium and a program product. The method in the embodiments of the present disclosure comprises: by means of a network state probe packet, detecting current network state information of other nodes on a data path where a sending node is located; on the basis of the current network state information of the nodes and the historical bottleneck bandwidth occupancy rate used in historical congestion control, generating the current bottleneck bandwidth occupancy rate; on the basis of the current bottleneck bandwidth occupancy rate, determining whether congestion occurs; and when it is determined that congestion has occurred, directly using the current bottleneck bandwidth occupancy rate for adjusting congestion control parameters without the need of calling an additional congestion parameter adjustment algorithm, such that the congestion control convergence speed is high. Furthermore, more accurate network state information can be obtained on the basis of the network state probe technology, and using the bottleneck bandwidth occupancy rate generated on the basis of the network state information to perform congestion determination and congestion control parameter adjustment can improve the parameter adjustment precision and improve the congestion control effect.

Description

[0001] Congestion Control Method, Network Card Device, Storage Medium, and Program Product Cross-Reference This disclosure claims priority to a Chinese patent publication with publication number 202410362684.3, filed with the Patent Office of China on March 27, 2024, entitled "Congestion Control Method, Network Card Device, Storage Medium, and Program Product," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of network communications technology, and more particularly to a congestion control method, network card device, storage medium, and program product. Background: Remote Direct Memory Access (RDMA) enables network interface cards (NICs) to directly read and write memory data through a memory region mechanism, bypassing the kernel and avoiding data copies. It has become a mainstream network solution in data centers.

[0002] RDMA uses a packet loss retransmission mechanism, so packet loss can degrade RDMA network performance. To reduce the packet loss rate, some solutions use Priority-based Flow Control (PFC) to control traffic flow at the port level, thereby reducing the packet loss rate.

[0003] PFC cannot limit data flows, leading to the emergence of congestion control methods for data flows. For example, Data Center Quantized Congestion Notification (DCQCN) uses explicit congestion control indicators to determine whether a data flow with that indicator is congested. If congestion is detected, a congestion control algorithm is further scheduled to perform congestion control. However, this leads to long congestion control delays and slow speed convergence. SUMMARY Various aspects of the present disclosure provide a congestion control method, a network interface card (NIC), a storage medium, and a program product for better congestion control. Embodiments of the present disclosure provide a congestion control method, applied to a network interface card (NIC) device of a sending node. The method comprises: detecting, based on a network status detection message, current network status information of at least one node on a data path where the sending node is located, other than the sending node; generating, based on the current network status information of the at least one other node and a historical bottleneck bandwidth occupancy used in historical congestion control, a current bottleneck bandwidth occupancy used in current congestion control; if congestion is determined to have occurred based on the current bottleneck bandwidth occupancy, adjusting congestion control parameters currently used by the NIC device based on the current bottleneck bandwidth occupancy to obtain new congestion control parameters; and performing congestion control on data traffic to be sent by the NIC device based on the new congestion control parameters. The present disclosure also provides a network card device, which is a sending node and includes: a hardware-implemented congestion control component, a scheduling component, a sending component, and a receiving component. The scheduling component is configured to detect current network status information of nodes other than the sending node on a data path where the sending node is located based on network status detection messages, and provide the information to the congestion control component. There is at least one other node, and the network status detection message is sent by the sending component, and the current network status information is received by the receiving component. The congestion control component is configured to generate a current bottleneck bandwidth occupancy rate used in current congestion control based on the current network status information of the at least one other node and a historical bottleneck bandwidth occupancy rate used in historical congestion control. The congestion control component adjusts the congestion control parameters currently used by the network card device based on the current bottleneck bandwidth occupancy rate to obtain new congestion control parameters, and provides the new congestion control parameters to the scheduling component, so that the scheduling component can perform congestion control on data traffic to be sent by the network card device based on the new congestion control parameters. The present disclosure also provides a computer device, which includes the network card device provided by the present disclosure.Embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program. When executed by a processor, the computer program causes the processor to implement the steps of the congestion control method. Embodiments of the present disclosure also provide a computer program product, including a computer program / instructions. When executed by a processor, the computer program / instructions causes the processor to implement the steps of the congestion control method. Embodiments of the present disclosure provide a congestion control method applicable to a network interface card device. In this congestion control method, current network status information of other nodes on a data path where a sending node is located is detected using network status detection messages. Based on the current network status information of these nodes and taking into account historical bottleneck bandwidth occupancy used in historical congestion control, a current bottleneck bandwidth occupancy is generated. Whether congestion occurs is determined based on the current bottleneck bandwidth occupancy. If congestion is determined to occur, the congestion control parameters currently used by the network interface card device are adjusted directly based on the current bottleneck bandwidth occupancy, and congestion control is performed based on the adjusted congestion control parameters. In this process, the current bottleneck bandwidth occupancy rate, used to determine whether congestion has occurred, can be directly used to adjust congestion control parameters when congestion is determined, eliminating the need to invoke a separate congestion parameter adjustment algorithm. Consequently, congestion control converges quickly. Furthermore, network status detection technology can obtain more accurate network status information, enabling congestion determination and congestion control parameter adjustment based on the bottleneck bandwidth occupancy rate generated based on this network status information. This improves parameter adjustment accuracy and congestion control effectiveness. Furthermore, the congestion control method provided in embodiments of the present disclosure can be applied to hardware-based network interface cards (NICs), such as those implemented using FPGAs, CPLDs, or ASICs. This method can fully leverage the low latency and high parallelism of hardware implementations, reduce congestion control processing delays, and improve the throughput of packets carrying network status information through a multi-stage pipeline. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are provided to illustrate the present disclosure and are not intended to unduly limit the present disclosure. In the accompanying drawings: Figure 1 is a structural diagram of a congestion control network system provided by an embodiment of the present disclosure; Figure 2 is a flow chart of a congestion control method provided by an embodiment of the present disclosure; Figure 3 is a flow chart of another congestion control method provided by an embodiment of the present disclosure; Figure 4 is a structural diagram of a network card device provided by an embodiment of the present disclosure; Figure 5 is a structural diagram of a congestion control component provided by an embodiment of the present disclosure; Figure 6 is a structural diagram of a scheduling component provided by an embodiment of the present disclosure; Figure 7 is a structural diagram of a computer device provided by an embodiment of the present disclosure.To further clarify the objectives, technical solutions, and advantages of this disclosure, the following will provide a clear and complete description of the technical solutions of this disclosure in conjunction with specific embodiments and corresponding figures. Obviously, the described embodiments represent only a portion of the embodiments of this disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure. 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, storage, and display) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding entry points are provided for users to choose to authorize or deny such data. Furthermore, the various models involved in this disclosure (including but not limited to language models and large models) comply with relevant laws and standards. High bandwidth, low latency, and high reliability are fundamental requirements for current data center applications. Remote Direct Memory Access (RDMA) uses a memory region mechanism to enable network interface cards (NICs) to directly read and write memory data, eliminating data copies. It has become a mainstream network solution in data centers. Due to RDMA's retransmission mechanism, packet loss can degrade RDMA network performance. Existing solutions often rely on PFC to achieve low packet loss rates. PFC controls traffic based on ports and their priorities without differentiating between data flows. This can lead to unfairness between data flows and even PFC storms. Consequently, the industry has proposed using data flow-specific congestion control methods to mitigate PFC's shortcomings. DCQCN, a mainstream congestion control algorithm, uses displayed congestion marking signals to infer congestion levels and implement debugging. However, its response to congestion is delayed, and congestion markings cannot guide speed regulation, resulting in slow convergence. Swift, another mainstream congestion control algorithm, regulates traffic based on the latency of each hop on the data path and the round-trip time (RTT). It relies on proprietary network cards and sending machines, and has significant processing delays. This processing delay is only suitable for 100Gbps networks and is incompatible with delays caused by data flow priority. Furthermore, its support is only available on proprietary switches, resulting in limited general use and low performance.To this end, a congestion control method suitable for a network card device is provided. In this congestion control method, the current network status information of nodes other than the sending node on the data path of the sending node is detected using network status detection messages. Based on the current network status information of these nodes and taking into account the historical bottleneck bandwidth occupancy used in historical congestion control, a current bottleneck bandwidth occupancy is generated. Whether congestion has occurred is determined based on the current bottleneck bandwidth occupancy. If congestion is determined to have occurred, the congestion control parameters currently used by the network card device are adjusted directly based on the current bottleneck bandwidth occupancy, and congestion control is performed based on the adjusted congestion control parameters. In this process, the current bottleneck bandwidth occupancy used to determine whether congestion has occurred can be directly used to adjust the congestion control parameters when congestion is determined, eliminating the need to invoke a separate congestion parameter adjustment algorithm. Consequently, congestion control converges quickly. Furthermore, network status detection technology can obtain more accurate network status information. The bottleneck bandwidth occupancy generated based on the network status information is then used to determine congestion and adjust the congestion control parameters, thereby improving parameter adjustment accuracy and congestion control effectiveness. Furthermore, the congestion control method provided in the embodiments of the present disclosure can be implemented in a hardware-based network interface card (NIC) device, such as a NIC device implemented with a field programmable gate array (FPGA), a complex programmable logic device (CPLD), or an application-specific integrated circuit (ASIC). This method can fully leverage the advantages of hardware implementation, such as low latency and high parallelism, to reduce congestion control processing delay and improve the throughput of messages carrying network status information through a multi-stage pipeline. The technical solutions provided in various embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. Figure 1 is a schematic diagram of the structure of a congestion control network system provided in an embodiment of the present disclosure. As shown in Figure 1 , the system may include a sending node 10 and a receiving node 30. One or more intermediate hop nodes 20 may also be included between the sending node 10 and the receiving node 30. The sending node (Sender) or the receiving node (Receiver) can be any network device with network communication function. The network interface card (NIC) device in the sending node or the receiving node is not limited. Examples of NIC devices include but are not limited to: smart NICs and onboard NICs.The intermediate hop node 20 can be any network device with forwarding functionality, including, but not limited to, a switch, a router, or a bridge. In practical applications, various messages, such as data packets and control messages, sent from the sending node 10 are forwarded by the intermediate hop node 20 and transmitted to the receiving node 30. During data transmission, the sending node 10 periodically or irregularly detects congestion on the link and performs congestion control (CC) based on the congestion detection results. The control messages sent by the sending node 10 when performing congestion control are referred to herein as network status detection messages. The network status detection messages are configured to detect the current network status information of the intermediate hop node or the receiving node. The current network status information includes, but is not limited to, in-band network telemetry (INT) information. Accordingly, the network status detection messages may also be referred to as INT messages. Referring to FIG. 1 , a sending node 10 sends a network status detection message (e.g., an INT message). When an intermediate hop node 20 receives the network status detection message, it detects its own current network status information, adds its current network status information to the received network status detection message, and generates a new network status detection message. The new network status detection message is then sent to the next intermediate hop node 20 or a receiving node 30. After receiving the network status detection message, the receiving node 30 returns a network status response message to the sending node 10. The network status response message includes the current network status information of each intermediate hop node 20 and the current network status information of the receiving node 30. The sending node 10 obtains the current network status information of each other node (including the intermediate hop nodes and the receiving node) on its data path from the network status response message and performs congestion control based on the current network status information of each other node. In the embodiments of the present disclosure, the manner in which the receiving node 30 generates the network status response message is not limited.In an optional embodiment, after receiving the network status detection message, the receiving node 30 parses the network status detection message to obtain the current network status information of each intermediate hop node 20, and detects the current network status information of the receiving node 30 itself, encapsulates the current network status information of each intermediate hop node 20 and the current network status information of the receiving node 30 itself according to the format of the network status response message to obtain a network status response message, and sends the network status response message to the sending node 10 through one or more intermediate hop nodes 20. In another optional embodiment, after receiving the network status detection message, the receiving node 30 detects its own current network status information, adds the detected current network status information to the received network status detection message, and modifies the type field value of the network status detection message from the first value indicating the network status detection message to the second value indicating the network status response message, to obtain a network status response message. The type field indicates the type of message. A first value, such as 0, indicates a network status detection message, while a second value, such as 1, indicates a network status response message. In the network system shown in FIG1 , an example is provided in which the data path from sending node 10 to receiving node 30 includes an intermediate hop node 20, but the present invention is not limited thereto. In some special scenarios, there may not be an intermediate hop node 20 between sending node 10 and receiving node 30. For the data path from a sending node 10 to a receiving node 30, embodiments of the present disclosure provide a high-precision, low-latency, and fast-convergence congestion control method. This method is based on network detection technology (such as in-band network telemetry). The sending node detects network status information for each hop on the data path through network status detection messages. Based on this information, the sending node calculates the bandwidth occupancy rate of each hop on the data path. The bandwidth occupancy rate of each hop is correlated with the congestion level of that hop. The bottleneck bandwidth occupancy rate on the data path is then used to determine the congestion level and adjust congestion control parameters (such as the sending rate) to achieve congestion control. Furthermore, because network detection technology can more accurately detect various network status information, the bottleneck bandwidth occupancy rate used to determine whether congestion has occurred on the data path is not only highly accurate, but also, if congestion is determined, the bottleneck bandwidth occupancy rate can be directly used to adjust congestion control parameters (such as the sending rate and sending window length). This eliminates the need for heuristic speed control, resulting in more accurate speed control and faster convergence. The following describes the congestion control process performed by the sending node. FIG2 is a flow chart of a congestion control method provided by an embodiment of the present disclosure. The method may be applied to a network card device of a sending node. Referring to FIG2 , the method may include the following steps:

[0004] 201. Detect current network status information of other nodes on a data path where a sending node is located, excluding the sending node, based on a network status detection message, where the other node is at least one.

[0005] 202. Generate a current bottleneck bandwidth occupancy rate used in current congestion control according to current network status information of at least one other node and historical bottleneck bandwidth occupancy rates used in historical congestion control.

[0006] 203. When congestion is determined to have occurred according to the current bottleneck bandwidth occupancy rate, adjust the congestion control parameters currently used by the network card device according to the current bottleneck bandwidth occupancy rate to obtain new congestion control parameters.

[0007] 204. Congestion control is performed on the data traffic to be sent by the network card device based on the new congestion control parameters. In this embodiment, the network status detection message sent by the sending node can be a detection message using any network detection technology, including, but not limited to, an INT message and an out-band network telemetry (ONT) message. The network status detection message sent by the sending node is transmitted to the receiving node via a data path. In addition to the sending node, the data path also includes one or more other nodes. If there is one other node, the data path includes the sending node and the receiving node. If there are multiple other nodes, the data path includes the sending node, one or more intermediate hop nodes, and the receiving node. When an intermediate hop node on the data path receives the network status detection message, it detects its own current network status information, adds its own current network status information to the received network status detection message, and forms a new network status detection message. The new network status detection message is then sent to the next intermediate hop node or the receiving node. After receiving the network status probe message, the receiving node on the data node returns a network probe response message to the sending node. If the data path does not include any intermediate hop nodes, the network probe response message includes the current network status information of the receiving node. If the data path includes any intermediate hop nodes, the network probe response message includes the current network status information of each intermediate hop node and the receiving node. The method for generating the network probe response message is described above and will not be repeated here. In this embodiment, the network card of the sending node can initiate network status probes on its data path at regular intervals or irregularly based on various protocols, such as network protocols or congestion control protocols. The implementation of the network status probe message is not limited in the disclosed embodiments. The network status probe message can be implemented as an independent message, that is, different from the data message or data packet transmitted on the data path; alternatively, the network status probe message can be integrated into the data message or data packet for implementation.Regardless of the implementation method, the network status detection message includes a message header and a message body. The message header is used to indicate that the message is a message for detecting network status information or is used to indicate that the message has a network status information detection function. The message body in the network status detection message is used to carry the current network status information of other nodes. Optionally, based on the functions of the message header and the message body, the message header can be referred to as a probe header, and the current network status information of other nodes carried in the message body can be referred to as metadata (MD) information. The probe header includes at least a probe identifier, which indicates that the message is a network status probe message. It may also include a sender identifier identifying the sending node, a hop limit (i.e., the maximum number of hops allowed for the message transmission), and the current hop count. Upon receiving the network status probe message, a node automatically determines whether the current hop count has reached the hop limit. If not, it increments the current hop count by 1 and continues to send the network status probe message to the next hop. Upon receiving the network status probe message, each hop on the data path other than the sending node writes its current network status information as MD information into the message body. Taking Figure 1 as an example, the red part in the network status detection message represents the detection header, and the white part represents the message body; after the network status detection message passes through the first intermediate hop node 20, a yellow part is added. The yellow part represents the current network status information of the first intermediate hop node 20 and serves as the MD information in the network status detection message; after the network status detection message passes through the second intermediate hop node 20, a green part is added. The green part represents the current network status information of the second intermediate hop node 20 and also serves as the MD information in the network status detection message; and so on. After passing through several intermediate hop nodes 20, the network status detection message arrives at the receiving node 30. At this time, the network status detection message includes the current network status information of multiple intermediate hop nodes 20, and the current network status information of different intermediate hop nodes 20 is distinguished by different colors. Receiving node 30 generates a network status response message based on the received network status detection message. As shown in FIG1 , the network status response message includes the detection header in the network status detection message and the current network status information of each intermediate hop node 20 in the message body. It should be noted that the current network status information of the receiving node itself is not shown in the network status response message in FIG1 , but this does not mean that the network status response message in FIG1 does not carry the current network status information of the receiving node 30 itself.In this embodiment, the specific current network status information of each intermediate hop node and receiving node detected via the network status detection message is not limited. Considering that congestion control in this disclosed embodiment uses the bandwidth occupancy of each intermediate hop node and receiving node, the current network status information may include any status information that can assist in calculating the bandwidth occupancy, including, but not limited to, the device number (device D), the buffer queue length (denoted as qlen), the amount of data sent in the egress queue, and the send timestamp (denoted as txTimestamp). Optionally, it may also include a rate code (denoted as PT) and a congestion identifier. For any node device in an intermediate hop or receiving node, the device number uniquely identifies the node device. The buffer queue length refers to the number of data tasks cached in the buffer queue corresponding to the node device. The buffer queue is also the queue for caching data tasks. The egress queue's sent data volume indicates the amount of data sent each time. Examples include, but are not limited to, the number of sent bytes (denoted as txBytes) and the number of sent bits. The sent bytes of an egress queue indicate the number of bytes sent each time; the sent bits of an egress queue indicate the number of bits sent each time. The send timestamp records the timestamp of the data sent by the egress queue. The rate code can identify the network bandwidth type. Different rate codes correspond to different network bandwidths, such as 40 Gbps, 100 Gbps, and 200 Gbps. There is a certain relationship between congestion handling delay and network bandwidth. A smaller congestion handling delay supports a larger network bandwidth. In the disclosed embodiments, the rate code is carried in the network status detection message to, to a certain extent, reflect the congestion handling delay requirements of each node. The congestion identifier indicates whether congestion has occurred on the current data path. It should be noted that the purpose of this solution is to prevent congestion. If congestion does not occur, the congestion identifier will not be marked as valid. However, if congestion still occurs after congestion control in this solution, the congestion identifier will be marked as invalid, allowing other control algorithms to intervene and quickly resolve congestion control. Upon detecting the current network status information of at least one other node on the data path where the sending node is located, as shown in step 202, the current bottleneck bandwidth occupancy rate used in the current congestion control can be generated based on the current network status information of the at least one other node and the historical bottleneck bandwidth occupancy rate used in historical congestion control. In this embodiment, the sending node can continuously perform congestion control.Each congestion control session determines the current bottleneck bandwidth occupancy rate. The bottleneck bandwidth occupancy rate can be understood as the maximum bandwidth occupancy rate allowed on the data path where the sending node is located. For details on how to calculate the bottleneck bandwidth occupancy rate, see the subsequent embodiments. For ease of understanding and distinction, congestion control sessions initiated by the sending node in the past are referred to as historical congestion control sessions, and the bottleneck bandwidth occupancy rates determined by these historical congestion control sessions are referred to as historical bottleneck bandwidth occupancy rates. Congestion control sessions initiated at the current time are referred to as current congestion control sessions, and the bottleneck bandwidth occupancy rates determined by these congestion control sessions are referred to as current bottleneck bandwidth occupancy rates. In this embodiment, when calculating the current bottleneck bandwidth occupancy rate used in the current congestion control session, not only the current network status information of at least one other node is considered, but also the historical bottleneck bandwidth occupancy rates used in historical congestion control sessions. Introducing the historical bottleneck bandwidth occupancy rate to iterate the bottleneck bandwidth occupancy rate can provide a smoothing effect and prevent sudden changes in the bandwidth occupancy rate. The disclosed embodiments do not limit the number of historical bottleneck bandwidth occupancy rates used. The iteration may use historical bottleneck bandwidth occupancy rates from the previous congestion control round, or historical bottleneck bandwidth occupancy rates from the previous M congestion control rounds, where M is a positive integer greater than or equal to 2. Optionally, one implementation of step 202 includes: generating the current bandwidth occupancy rate of at least one other node based on the current network status information and historical network status information of at least one other node; determining the target bandwidth occupancy rate corresponding to the data path of the sending node based on the current bandwidth occupancy rate of the at least one other node; and generating the current bottleneck bandwidth occupancy rate based on the target bandwidth occupancy rate and the historical bottleneck bandwidth occupancy rate. This embodiment does not limit the implementation of generating the current bandwidth occupancy rate of at least one other node based on the current network status information and historical network status information of at least one other node. Several exemplary implementations are described below. Method 1: For any other node, a first bandwidth occupancy rate is predicted based on the buffer queue length in the current network status information of the other node, the buffer queue length in the historical network status information, and the maximum transmission bandwidth of the other node. For any other node, its current bandwidth occupancy can be determined based on its first bandwidth occupancy. In practical applications, when predicting the first bandwidth occupancy, either the buffer queue length in the current network status information of the other node or the buffer queue length in the historical network status information can be selected, either the largest or the smallest, and the selected buffer queue length can be used to calculate the first bandwidth occupancy.Divide the selected buffer queue length by the maximum transmission bandwidth of any other node, and obtain the first bandwidth based on the division result. In Equation (1), Uqkn represents the first bandwidth occupancy rate of any other node (taking the i-th node as an example), and this bandwidth occupancy rate is a predicted bandwidth occupancy rate; qlem represents the buffer queue length in the current network state information of any other node (i.e., the i-th node); pre-qleni represents the buffer queue length in the historical network state information of any other node (i.e., the i-th node). In Equation (1), the queue buffer length in the historical network state information in the previous congestion control process is taken as an example; Bi represents the maximum transmission bandwidth of any other node (i.e., the i-th node); uintien represents the number of data tasks in the buffer queue of any other node (i.e., the i-th node), which can also be referred to as the number of bytes of the egress queue component, T represents the preset RTT, and max() represents the function of taking the maximum value. After obtaining the first bandwidth occupancy rate, the first bandwidth occupancy rate can be used as the current bandwidth occupancy rate; or, add or subtract a fixed value from the first bandwidth occupancy rate to obtain the current bandwidth occupancy rate; or, divide or multiply the first bandwidth occupancy rate by a constant coefficient to obtain the current bandwidth occupancy rate; but it is not limited to the above examples. Method 2: Calculate the second bandwidth occupancy rate based on the send timestamp and send data volume in the current network state information of any other node, the send timestamp and send data volume in the historical network state information, and the maximum transmission bandwidth of any other node. For any other node, its current bandwidth occupancy rate can be determined based on its second bandwidth occupancy rate. In practical applications, when predicting the second bandwidth occupancy rate, various operations such as addition and subtraction can be performed on "the number of bytes sent by the egress queue in the current network state information of other nodes" and "the number of bytes sent by the egress queue in the historical network state information of other nodes" to obtain the first operation result; various operations such as addition and subtraction can be performed on "the send timestamp in the current network state information of other nodes" and "the send timestamp in the historical network state information of other nodes" to obtain the second operation result; various operations are performed on the first operation result, the second operation result, and the maximum transmission bandwidth of other nodes to obtain the second bandwidth occupancy rate. Preferably, for any other node txRate, =

[0008] T T - tXRate i ⑶ txRate 口. (刁

[0009] B Wherein, txByteSi represents the number of bytes sent by the egress queue in the current network status information of any other node (i.e., the i-th node); pre.txBytesi represents the number of bytes sent by the egress queue in the historical network status information of any other node (i.e., the i-th node). In formula (2), the number of bytes sent in the historical network status information during the previous congestion control process is used as an example. txTimestampi represents the sending timestamp of the egress queue in the current network status information of any other node (i.e., the i-th node); pre.txTimestampi represents the sending timestamp of the egress queue in the historical network status information of any other node (i.e., the i-th node). In formula (2), the sending timestamp of the historical network status information during the previous congestion control process is used as an example. txRatei represents the predicted bandwidth; Bi represents the maximum transmission bandwidth of any other node (i.e., the i-th node); and U txRate represents the second bandwidth occupancy rate of any other node (i.e., the i-th node). After obtaining the second bandwidth occupancy, the second bandwidth occupancy can be used as the current bandwidth occupancy; alternatively, a fixed value can be added to or subtracted from the second bandwidth occupancy to obtain the current bandwidth occupancy; alternatively, the second bandwidth occupancy can be divided or multiplied by a constant coefficient to obtain the current bandwidth occupancy; however, this is not limited to the above examples. Method 3: For any other node, the first bandwidth occupancy is predicted based on the buffer queue length in the current network status information of the other node, the buffer queue length in the historical network status information, and the maximum transmission bandwidth of the other node; the second bandwidth occupancy is calculated based on the sending timestamp and sent data volume in the current network status information of the other node, the sending timestamp and sent data volume in the historical network status information, and the maximum transmission bandwidth of the other node; and the current bandwidth occupancy of the other node is generated based on the first bandwidth occupancy and the second bandwidth occupancy of the other node. For any other node, after predicting the first and second bandwidth occupancy rates of the other node, various operations such as weighted summation, averaging, maximum value, or minimum value are performed on the first and second bandwidth occupancy rates to obtain the current bandwidth occupancy rate. Alternatively, assuming the i-th other node as an example, the current bandwidth occupancy rate is denoted as U. The current bandwidth occupancy rate is calculated according to formula (4). The target bandwidth occupancy is determined based on the current bandwidth occupancy of at least one other node. The target bandwidth occupancy is the initial bottleneck bandwidth occupancy of the data path where the sending node is located. The current bottleneck bandwidth occupancy is generated based on the target bandwidth occupancy and the historical bottleneck bandwidth occupancy. Optionally, the current bandwidth occupancy with the largest or smallest value can be selected from the current bandwidth occupancy of at least one other node as the target bandwidth occupancy. Alternatively, the current bandwidth occupancy of at least one other node can be weighted summed or averaged to obtain the target bandwidth occupancy, but this is not limited to this. Optionally, the current bottleneck bandwidth occupancy with the largest or smallest value can be selected from the target bandwidth occupancy and the historical bottleneck bandwidth occupancy. Alternatively, the current bottleneck bandwidth occupancy with the target bandwidth occupancy and the historical bottleneck bandwidth occupancy can be weighted summed or averaged to obtain the target bandwidth occupancy, but this is not limited to this. For example, assuming there are N other nodes on a data path, where N is a positive integer, the current bandwidth occupancy with the largest value can be selected from the current bandwidth occupancy of the N other nodes as the target bandwidth occupancy. Assume that the target bandwidth occupancy is recorded as U, the current bottleneck bandwidth occupancy is recorded as U, the historical bottleneck bandwidth occupancy is recorded as pre.U, and the preset update rate is recorded as a. The preset update rate is a constant coefficient greater than 0 and less than 1, which can be flexibly set as needed. Preferably, for the current bottleneck bandwidth occupancy of the data path where the sending node is located in this congestion control, When the current bottleneck bandwidth occupancy rate is obtained, referring to step 203, whether congestion occurs on the data path where the sending node is located is first determined based on the current bottleneck bandwidth occupancy rate. Furthermore, if congestion is determined based on the current bottleneck bandwidth occupancy rate, the congestion control parameters currently used by the network card device are adjusted based on the current bottleneck bandwidth occupancy rate to obtain new congestion control parameters. This embodiment does not limit the implementation method for determining whether congestion occurs on the data path where the sending node is located based on the current bottleneck bandwidth occupancy rate. For example, the current bottleneck bandwidth occupancy rate can be compared with a set bandwidth occupancy rate. If the current bottleneck bandwidth occupancy rate is greater than the set bandwidth occupancy rate, congestion is determined to have occurred; if the current bottleneck bandwidth occupancy rate is less than or equal to the set bandwidth occupancy rate, congestion is determined not to have occurred. The set bandwidth occupancy rate can be flexibly set as needed. Of course, the ratio of the current bottleneck bandwidth occupancy rate to the set bandwidth occupancy rate can also be calculated. If the ratio is greater than a set ratio threshold, congestion is determined to have occurred; if the ratio is less than or equal to the set ratio threshold, congestion is determined not to have occurred. The set bandwidth occupancy rate and the set percentage threshold can be flexibly set as needed. The percentage threshold can be, but is not limited to, 90%, 95%, etc. In this embodiment, when congestion is determined to have occurred based on the current bottleneck bandwidth occupancy rate, the current bottleneck bandwidth occupancy rate can be directly used to adjust the congestion control parameters currently used by the network card device, without invoking other congestion control algorithms. This has the advantages of reduced congestion control delay and rapid convergence. The congestion control parameters currently used by the network card device include, but are not limited to, the current sending window length and the current sending rate. The current sending window length can be understood as the size of the currently used sending window, and the current sending rate is the currently used sending rate. In this embodiment, the sending window is used to limit the transmission of data packets to achieve congestion control, and is therefore also referred to as the congestion window. Optionally, if the current bottleneck bandwidth occupancy rate is greater than the set bandwidth occupancy rate, the congestion control parameters currently used by the network card device can be adjusted downward, that is, adjusted to decrease the current congestion control parameters. The extent of the reduction can be flexibly set as needed and is not limited. Further optionally, when the current bottleneck bandwidth occupancy is greater than the set bandwidth occupancy, the congestion control parameter currently used by the network card device is adjusted downward according to the ratio of the set bandwidth occupancy to the current bottleneck bandwidth occupancy to obtain a new congestion control parameter.Assume that the bandwidth utilization rate is set as Utarget and the current bottleneck bandwidth utilization rate is U; the ratio of the set bandwidth utilization rate to the current bottleneck bandwidth utilization rate is Utarget / U, the current sending rate is rate, and the adjusted sending rate is rate'. Multiply Utarget / U by rate to obtain the product, and use the product to obtain the adjusted sending rate. Alternatively, add or subtract a configurable constant from the product to obtain the adjusted sending rate. Multiply the adjusted sending rate by the preset RTT to obtain the adjusted sending window size. Further optionally, based on the ratio of the current bottleneck bandwidth occupancy to the set bandwidth occupancy, a congestion control parameter currently used by the network card device is adjusted downward to obtain a new congestion control parameter, including: generating a basic multiplication coefficient based on the ratio of the current bottleneck bandwidth occupancy to the set bandwidth occupancy and a preset update coefficient, where the basic multiplication coefficient is greater than 0 and less than 1; selecting a larger one between the basic multiplication coefficient and a protection multiplication coefficient as a target multiplication coefficient, where the protection multiplication coefficient is greater than 0 and less than 1; and multiplicatively adjusting the congestion control parameter currently used by the network card device downward based on the target multiplication coefficient to obtain the new congestion control parameter. Optionally, based on the target multiplicative coefficient, the congestion control parameters currently used by the network card device are multiplicatively adjusted downward to obtain new congestion control parameters, including: multiplying the target multiplicative coefficient by the current sending rate in the congestion control parameters currently used by the network card device to obtain a new sending rate; and multiplying the new sending rate by a preset sending time period to obtain a new sending window length. The new congestion control parameters include a new sending window length and a new sending rate. The preset sending time period can be implemented as a preset round-trip time (RTT), which is not limited to this. The preset update coefficient and the protection multiplicative coefficient are flexibly set as needed, and the preset update coefficient is greater than 0 and less than 1. The protection multiplicative coefficient can prevent the sending rate from decreasing too quickly. The adjusted value is calculated according to Formula (6). rate. (6) Where, P X(U target / U) represents the base multiplicative coefficient, max() represents the function of taking the larger value, and max(pX (廿栖尊廨1!人辑桩%血)) represents the target multiplicative coefficient. Assume that the length of the adjusted sending window is denoted as cwnd, and the preset RTT is denoted as T. T also represents the preset sending time period. Calculate the length of the adjusted sending window (i.e., the new sending window length) according to formula (7). cwnd = rate'xT. (7) It can be understood that in the case of congestion, multiplying the sending rate by a factor of decrease can better perform congestion control. Further optionally, when the current bottleneck bandwidth occupancy rate is less than or equal to the set bandwidth occupancy rate, it means that no congestion has occurred. In this case, the congestion control parameters currently used by the network card device can be adjusted upward, that is, the currently used congestion control parameters are adjusted in the increasing direction, and the increasing amplitude can be flexibly set according to needs, and no limit is imposed on this. Further optionally, when the current bottleneck bandwidth occupancy rate is less than or equal to the set bandwidth occupancy rate, according to the preset parameter adjustment threshold, the congestion control parameters currently used by the network card device are adjusted upward to obtain new congestion control parameters. Optionally, the implementation method of adjusting the congestion control parameters currently used by the network card device upward according to the preset parameter adjustment threshold to obtain new congestion control parameters is as follows: determine the target additive step size according to the size relationship between the congestion control parameters currently used by the network card device and the preset parameter adjustment threshold; perform an additive upward adjustment on the congestion control parameters currently used by the network card device according to the target additive step size and the preset step size weight to obtain new congestion control parameters. Optionally, the preset parameter adjustment threshold includes a sending rate threshold and an adjustment number threshold. Then, determine the target additive step size according to the size relationship between the congestion control parameters currently used by the network card device and the preset parameter adjustment threshold, including: if the current sending rate in the congestion control parameters currently used by the network card device is less than the sending rate threshold, determine the first step size as the target additive step size; if the current sending rate is greater than or equal to the sending rate threshold and the number of consecutive upward adjustments is greater than or equal to the adjustment number threshold, determine the second step size as the target additive step size; if the current sending rate is greater than or equal to the sending rate threshold and the number of consecutive upward adjustments is less than the adjustment number threshold, determine the third step size as the target additive step size; where the third step size is less than the second step size, and the second step size is less than the first step size. Among them, for the number of consecutive upward adjustments, it is incremented by 1 each time it is adjusted upward, and cleared to 0 when it becomes a downward adjustment; when starting to adjust upward again, the counting starts over.Using the first step size can significantly adjust the sending rate, facilitating the transmission of more data and improving bandwidth utilization. Using the second step size allows for timely and significant adjustment of the sending rate. Using the third step size allows for normal adjustment of the sending rate. The first, second, and third step sizes can be flexibly set as needed. Optionally, based on the target additive step size and a preset step size weight, the congestion control parameters currently used by the network card device are additively adjusted upward to obtain new congestion control parameters. This includes: determining a rate increment based on the target additive step size and the preset step size weight; adding the rate increment to the current sending rate in the congestion control parameters currently used by the network card device to obtain a new sending rate; and multiplying the new sending rate by a preset sending time period to obtain a new sending window length. The new congestion control parameters include the new sending window length and the new sending rate. The rate increment can be obtained by performing various operations, such as multiplication, addition, or subtraction, on the target additive step size and the preset step size weight. Assume the sending rate threshold is denoted as ratethresh, the adjustment threshold is denoted as A, the number of consecutive upward adjustments is denoted as B, the first step length is denoted as uai, the second step length is denoted as hai, the third step length is denoted as ai, and w is the flexibly set preset step weight. The set bandwidth utilization is denoted as Utarget, and the current bottleneck bandwidth utilization is denoted as U; the current sending rate is denoted as rate, and the adjusted sending rate is denoted as rate'. Referring to Figure 3, the congestion control process includes:

[0010] 51. Obtain the current bottleneck bandwidth usage U and set the bandwidth usage Utarget;

[0011] 52, determine whether U> Utarget; if the judgment result is yes, execute step S3; if the judgment result is no, execute step S4;

[0012] 53, confirming that congestion occurs, the sending rate is multiplied and decreased; proceed to step S5; wherein, in accordance with rate 1 =max(PX (%) (0) X rat*formula, calculate the new sending rate rate 1 .

[0013] 54. Determine that no congestion occurs, and increase the sending rate additively; then proceed to step S5.

[0014] 55. Update the current sending window length according to the new sending rate to obtain a new sending window length. 1The xT formula calculates the new transmission window length cwnd.

[0015] 56. Control data transmission according to the new transmission rate and the new transmission window length. Specifically, the specific process of step S4 includes:

[0016] 541. Determine whether rate is less than rate thresh ; If the judgment result is yes, execute step S42; if the judgment result is no, execute step S43;

[0017] 542. Calculate the transmission rate rate according to the formula rate 1= rate + w> <uai formula to increase the transmission rate additively. S43. Determine whether B > A; if the judgment result is yes, execute step S44; if the judgment result is no, execute step S45; 1 , to increase the transmission rate additively. S43. Determine whether B > A; if the judgment result is yes, execute step S44; if the judgment result is no, execute step S45;

[0018] 544. Calculate the transmission rate rate according to the formula rate 1= rate + w> <hai formula to increase the transmission rate additively. 1 , to increase the transmission rate additively.

[0019] 545. Calculate the transmission rate rate according to the formula rate 1= rate + w> <ai formula to increase the transmission rate additively. 1, thereby additively increasing the sending rate. When new congestion control parameters are obtained, referring to step 204, congestion control can be performed on the data traffic to be sent by the network card device based on the new congestion control parameters. In practical applications, the data traffic sent by the network card device is controlled according to the sending rate and new sending window length in the new congestion control parameters to perform congestion control. Further, optionally, to better perform congestion control, step 204 can be implemented by: converting the new sending rate into a token number, and adding the token number and new sending window length to a congestion parameter buffer. The token number and sending window length are continuously consumed as data packets are sent. For example, each data packet sent consumes one token and one sending window, and accordingly, the remaining token number and remaining sending window length are both reduced by 1. Based on the remaining token number and remaining sending window length, as well as the data sending status information corresponding to the data path, a determination is made as to whether data packet sending is permitted. If data packet sending is permitted, information about the data packet to be sent and the data path is provided to the sending component, so that the sending component can send the data packet to be sent based on the data path information. Specifically, if the number of remaining tokens is zero or the remaining send window length is zero, data packet transmission is prohibited; otherwise, data packet transmission is permitted. Data transmission status information indicates whether data packets in the egress queue have been sent. The congestion control method provided in the disclosed embodiments uses network status detection messages to detect the current network status information of other nodes on the data path where the sending node is located. Based on the current network status information of these nodes and taking into account the historical bottleneck bandwidth occupancy used in historical congestion control, a current bottleneck bandwidth occupancy is generated. Congestion is determined based on this current bottleneck bandwidth occupancy. If congestion is determined to have occurred, the congestion control parameters currently used by the network card device are adjusted directly based on the current bottleneck bandwidth occupancy, and congestion control is performed based on the adjusted congestion control parameters. In this process, the current bottleneck bandwidth occupancy rate, used to determine whether congestion has occurred, can be directly used to adjust congestion control parameters when congestion is determined, eliminating the need to invoke a separate congestion parameter adjustment algorithm. Consequently, congestion control converges quickly. Furthermore, network status detection technology can obtain more accurate network status information, allowing congestion determination and congestion control parameter adjustment based on the bottleneck bandwidth occupancy rate generated based on this network status information to be used. This improves parameter adjustment accuracy and enhances congestion control effectiveness. It should be noted that the execution entity of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices.For example, the execution entity of steps 201 to 204 may be device A; for another example, the execution entity of steps 201 and 202 may be device A, and the execution entity of steps 203 to 204 may be device B; and so on. Furthermore, some of the processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be understood that these operations may not be executed in the order in which they appear herein or may be executed in parallel. Operation sequence numbers, such as 201 and 202, are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that terms such as "first" and "second" herein are used to distinguish between different messages, devices, components, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types. It should be noted that the congestion control method provided in the embodiments of the present disclosure can be implemented by a network card device of a sending node. In the embodiments of the present disclosure, the manner in which the network card device implements the above-mentioned congestion control method is not limited; hardware or software implementation is possible. For the case where the network card device implements the above-mentioned congestion control method using software, the embodiments of the present disclosure provide a network card device comprising a processor and a memory, wherein the memory stores a computer program / instructions. The processor is coupled to the memory and configured to execute the computer program / instructions stored in the memory to implement each step in the above-mentioned method embodiment. The detailed implementation process of the processor executing each action can be found in the relevant descriptions in the aforementioned method embodiment or device embodiment and will not be repeated here. For the case where the network card device implements the above-mentioned congestion control method using software, the embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program. When the computer program is executed by the processor, it can implement each step in the above-mentioned method embodiment. Furthermore, the embodiments of the present disclosure also provide a computer program product comprising the computer program / instructions. When the computer program / instructions are executed by the processor, the processor can implement each step in the above-mentioned method embodiment that can be performed by a computer device.In the case where a network card device implements the congestion control method using hardware, the device can be implemented on programmable hardware such as an FPGA or CPLD, or on a chip such as an ASIC (Application Specific Integrated Circuit), without limitation. Furthermore, the hardware implementation structure of the network card device is not limited; any hardware implementation structure capable of implementing the congestion control method is applicable to the embodiments of the present disclosure. The following embodiments provide a hardware implementation structure of a network card device for implementing the congestion control method. Figure 4 is a schematic structural diagram of a network card device provided in an embodiment of the present disclosure. A network card device is a sending node. As shown in FIG4 , the network card device includes a hardware-implemented congestion control component 10, a scheduling component 20, a sending component 30, and a receiving component 40. The scheduling component 20 is configured to detect the current network status information of nodes other than the sending node on the data path of the sending node based on network status detection messages, and provide the information to the congestion control component 10. There is at least one other node, and the network status detection message is sent by the sending component 30, and the current network status information is received by the receiving component 40. The congestion control component 10 is configured to generate a current bottleneck bandwidth occupancy rate used in current congestion control based on the current network status information of the at least one other node and the historical bottleneck bandwidth occupancy rate used in historical congestion control. Based on the current bottleneck bandwidth occupancy rate, the congestion control parameters currently used by the network card device are adjusted to obtain new congestion control parameters, and the new congestion control parameters are provided to the scheduling component 20. The scheduling component 20 is also configured to perform congestion control on the data traffic to be sent by the network card device based on the new congestion control parameters. In actual applications, the sending component in the network card device of the sending node sends a network status detection message, and the receiving component in the network card device of the sending node sends the current network status information of other nodes on the data path of the sending node. Each other node can directly return a response message to the sending node, and the sending node can obtain the current network status information of other nodes from the response message. Alternatively, the response message returned by the receiving node can be transmitted via the data path to the receiving component in the network card device of the sending node, and the receiving component can parse the current network status information of other nodes on the data path of the sending node. There is no limitation on this. In actual applications, the receiving node can modify the message type field in the received network status detection message to the response message type to obtain the response message.Alternatively, the receiving node parses the received network status detection message to obtain the current network status information of each other node, and encapsulates the current network status information of each other node and the receiving node's own current network status information into a response message. Optionally, referring to FIG5 , the congestion control component 10 includes a hardware-implemented data cache 11, a computing component 12, and a status cache 13. The scheduling component 20 is specifically configured to write the current network status information of at least one other node into the data cache; the status cache stores historical bottleneck bandwidth occupancy rates used in historical congestion control. The computing component 12 is configured to read the current network status information and historical bottleneck bandwidth occupancy of at least one other node from the data cache and the status cache, respectively; generate a current bottleneck bandwidth occupancy based on the current network status information and the historical bottleneck bandwidth occupancy of the at least one other node; adjust the congestion control parameters currently used by the network card device based on the current bottleneck bandwidth occupancy to obtain new congestion control parameters; and output the new congestion control parameters to the scheduling component 20. Optionally, referring to FIG. 5 , the computing component 12 includes multiple computing components and an adjustment component. The multiple computing components execute in parallel and are configured to generate the current bandwidth occupancy of the at least one other node based on the current network status information and historical network status information of the at least one other node stored in the data cache and the status cache, and provide the current bandwidth occupancy to the adjustment component. Each computing component is responsible for generating the current bandwidth occupancy of one other node at a time. The adjustment component is configured to determine a target bandwidth occupancy rate based on the current bandwidth occupancy rate of at least one other node; generate a current bottleneck bandwidth occupancy rate based on the target bandwidth occupancy rate and the historical bottleneck bandwidth occupancy rate read from the status buffer; and write the current bottleneck bandwidth occupancy rate to the status buffer to update the historical bottleneck bandwidth occupancy rate. In actual applications, any computing component in the multi-path computing component reads the current network status information and historical network status information of at least one other node from the data buffer and the status buffer, and performs subsequent processing based on the read current network status information and historical network status information of the at least one other node.Optionally, each computing component is specifically configured to: predict, for any other node, a first bandwidth occupancy rate based on a buffer queue length in current network status information of any other node, a buffer queue length in historical network status information, and a maximum transmission bandwidth of any other node; calculate a second bandwidth occupancy rate based on a sending timestamp and a sent data volume in current network status information of any other node, a sending timestamp and a sent data volume in historical network status information, and the maximum transmission bandwidth of any other node; and generate a current bandwidth occupancy rate of any other node based on the first bandwidth occupancy rate and the second bandwidth occupancy rate of any other node. Optionally, referring to FIG5 , the adjustment component includes: a comparison subcomponent, a first adjustment subcomponent, and a second adjustment subcomponent; the comparison subcomponent is configured to compare the current bottleneck bandwidth occupancy with the set bandwidth occupancy, and trigger the first adjustment subcomponent when the current bottleneck bandwidth occupancy is greater than the set bandwidth occupancy, and trigger the second adjustment subcomponent when the current bottleneck bandwidth occupancy is less than or equal to the set bandwidth occupancy; the first adjustment subcomponent, triggered by the comparison subcomponent, adjusts downward the congestion control parameter currently used by the network card device according to the ratio of the set bandwidth occupancy to the current bottleneck bandwidth occupancy to obtain a new congestion control parameter; the second adjustment subcomponent, triggered by the comparison subcomponent, adjusts upward the congestion control parameter currently used by the network card device according to a preset parameter adjustment threshold to obtain the new congestion control parameter. Optionally, the first adjustment subcomponent is specifically configured to: generate a base multiplicative coefficient based on a ratio of the current bottleneck bandwidth occupancy rate to the set bandwidth occupancy rate and a preset update system, the base multiplicative coefficient being greater than 0 and less than 1; select the larger of the base multiplicative coefficient and the protection multiplicative coefficient and use the larger as the target multiplicative coefficient, wherein the protection multiplicative coefficient is greater than 0 and less than 1; and multiply downwardly adjust the congestion control parameters currently used by the network card device based on the target multiplicative coefficient to obtain new congestion control parameters. Optionally, when multiply downwardly adjusting the congestion control parameters currently used by the network card device, the first adjustment subcomponent is specifically configured to: multiply the target multiplicative coefficient by a current sending rate in the congestion control parameters currently used by the network card device to obtain a new sending rate; and multiply the new sending rate by a preset sending time period to obtain a new sending window length; wherein the new congestion control parameters include a new sending window length and a new sending rate.Optionally, the second adjustment subcomponent is specifically configured to: determine a target additive step size based on a relationship between a congestion control parameter currently used by the network card device and a preset parameter adjustment threshold; and additively adjust the congestion control parameter currently used by the network card device based on the target additive step size and a preset step size weight to obtain a new congestion control parameter. Optionally, the preset parameter adjustment threshold includes a sending rate threshold and an adjustment count threshold. In this case, when determining the target additive step size, the second adjustment subcomponent is specifically configured to: in response to a current sending rate in the congestion control parameter currently used by the network card device being less than the sending rate threshold, determine a first step size as the target additive step size; in response to a current sending rate being greater than or equal to the sending rate threshold and a number of consecutive upward adjustments being greater than or equal to the adjustment count threshold, determine a second step size as the target additive step size; and in response to a current sending rate being greater than or equal to the sending rate threshold and a number of consecutive upward adjustments being less than the adjustment count threshold, determine a third step size as the target additive step size; wherein the third step size is smaller than the second step size, and the second step size is smaller than the first step size. Optionally, when additively adjusting the congestion control parameters currently used by the network card device, the second adjustment subcomponent is specifically configured to: determine a rate increment based on a target additive step size and a preset step size weight, add the rate increment to a current sending rate in the congestion control parameters currently used by the network card device to obtain a new sending rate; and multiply the new sending rate by a preset sending time period to obtain a new sending window length; wherein the new congestion control parameters include a new sending window length and a new sending rate. 6 , the scheduling component 20 includes: a hardware-implemented congestion parameter buffer 21, a connection status buffer 22, a token conversion component 23, a permission determination component 24, and a processing component 25. The token conversion component 23 is configured to convert a new sending rate into a token number and add the token number and the new sending window length to the congestion parameter buffer 21, where the token number and the sending window length are continuously consumed as data packets are sent. The connection status buffer 22 stores data sending status information corresponding to a data path. The permission determination component 24 is configured to, upon determining that sending of a data packet is permitted based on the remaining token number, the remaining sending window length, and the data sending status information corresponding to the data path, provide information about the data packet to be sent and the data path to the processing component, and update the remaining token number and the remaining sending window length. The processing component 25 is configured to generate a sending request based on the information about the data packet to be sent and the data path, and provide the sending request to the sending component, so that the sending component can send the data packet to be sent based on the information about the data path.In actual applications, the permission determination component reads the remaining token count and remaining send window length from the congestion parameter buffer, and reads the data transmission status information corresponding to the data path from the connection status buffer, and performs subsequent processing based on the read data. It should be noted that the network card device in the embodiments of the present disclosure can be a network card that supports the RDMA protocol or a network card that supports the TCP / IP protocol, without limitation. When the network device is implemented as a network card that supports the RDMA protocol, the scheduling component 20 may also include functional components related to RDMA network transmission, such as various queues such as CQ, SQ, and RQ. Accordingly, the processing component 25 may also be implemented as a CQE component. When generating a send request and providing it to the sending component, it may also generate a CQE and send a send completion message back to the upper-layer host or application. The detailed implementation and beneficial effects of each component in the network card device have been described in detail in the aforementioned embodiments and will not be elaborated here. In the disclosed embodiments, a low-latency, high-precision, and fast-convergence congestion control method based on network detection technology (such as INT) is implemented on a hardware network card based on an FPGA, CPLD, or ASIC. Without requiring software or CPU intervention, this method fully leverages the low latency and high parallelism of hardware implementations while acquiring accurate network status information along the data path. This reduces congestion control processing delays and improves the throughput of messages carrying network status information through a multi-stage pipeline. Furthermore, through speed regulation based on the sending rate and sending window, and token-based sending control, network bandwidth can be fully utilized while avoiding excessive network congestion. In addition, in the congestion control method provided in this embodiment, the current bottleneck bandwidth occupancy rate, used to determine whether congestion has occurred, can be directly used to adjust congestion control parameters when congestion is determined, eliminating the need to invoke a separate congestion parameter adjustment algorithm. Consequently, congestion control converges quickly. Furthermore, network status detection technology can obtain more accurate network status information, allowing congestion determination and congestion control parameter adjustment based on the bottleneck bandwidth occupancy rate generated based on this network status information to be used. This improves parameter adjustment accuracy and enhances congestion control effectiveness. Figure 7 is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. As shown in Figure 7, the computer device includes a memory 71, a processor 72, and a communication component 73, which includes at least a network interface card 731. Memory 71 is configured to store computer programs and can be configured to store various other data to support operations on the computing platform.Examples of this data include instructions for any application or method configured to operate on the computing platform, contact data, phone book data, messages, images, videos, and the like. Memory 71 can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Processor 72 is coupled to memory 71 and is configured to execute computer programs stored in memory 71 to implement various functions of the computing device. In this embodiment, a network card device 731 is used to execute the steps of the congestion control method provided in the above-mentioned method embodiment. The network card device 731 can execute the congestion control method via software or hardware. When using hardware, the implementation structure of the network card device 731 can be seen in Figures 4-6 and will not be described in detail here. Furthermore, as shown in Figure 7 , the computer device may also include other components, such as a display 74, a power supply component 75, and an audio component 76. Figure 7 only schematically illustrates some components and does not mean that the computer device only includes the components shown in Figure 7 . Furthermore, the components within the dashed box in Figure 7 are optional, not mandatory, components, and may vary depending on the product form of the computer device. The computer device in this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or Internet of Things (IoT) device, or as a server device such as a conventional server, cloud server, or server array. If the computer device of this embodiment is implemented as a terminal device such as a desktop computer, a laptop computer, or a smart phone, it may include the components within the dotted box in Figure 7; if the computer device of this embodiment is implemented as a server device such as a conventional server, a cloud server, or a server array, it may not include the components within the dotted box in Figure 7.The aforementioned communication component is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access wireless networks based on communication standards, such as Wireless Fidelity (WiFi), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G) / Long Term Evolution (LTE), 5th Generation (5G), or other mobile communication networks, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a Near Field Communication (NFC) component to facilitate short-range communication. For example, the NFC component can be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology, and other technologies. The aforementioned display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only sense the boundaries of a touch or slide action, but also the duration and pressure associated with the touch or slide action. The aforementioned power supply component provides power to various components of the device in which the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located. The audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC). When the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode, the microphone is configured to receive external audio signals.The received audio signal may be further stored in a memory or transmitted via a communication component. In some embodiments, the audio component further includes a speaker configured to output the audio signal. Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, may be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a device configured to implement the functions specified in one or more flow charts and / or one or more blocks in a block diagram. These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more flow charts and / or one or more blocks in a block diagram. These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, such that the instructions executed on the computer or other programmable device provide steps configured to implement the functions specified in one or more flow charts and / or one or more blocks in a block diagram. In a typical configuration, a computing device includes one or more processors (Central Processing Unit, referred to as CPU), input / output interfaces, network interfaces, and memory. Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.Computer-readable media, including permanent and non-permanent, removable and non-removable media, can be implemented using any method or technology to store information. The information can be computer-readable instructions, data structures, program components, or other data. Examples of computer storage media include, but are not limited to, phase change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be configured to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements may include not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the elements. The foregoing are merely examples of the present disclosure and are not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.Industrial Applicability: The method provided by the embodiments of the present disclosure can be applied to the congestion control process of a network card device. Network status detection messages are used to detect the current network status information of other nodes on the data path of the sending node. Based on the current network status information of these nodes and taking into account the historical bottleneck bandwidth occupancy used in historical congestion control, the current bottleneck bandwidth occupancy is generated. Congestion is determined based on the current bottleneck bandwidth occupancy. If congestion is determined to have occurred, the congestion control parameters currently used by the network card device are adjusted directly based on the current bottleneck bandwidth occupancy, and congestion control is performed based on the adjusted congestion control parameters. In this process, the current bottleneck bandwidth occupancy, which is used to determine whether congestion has occurred, can be directly used to adjust the congestion control parameters when congestion is determined, eliminating the need to invoke a separate congestion parameter adjustment algorithm. This results in faster congestion control convergence. Furthermore, network status detection technology can obtain more accurate network status information. The bottleneck bandwidth occupancy generated based on this network status information can then be used to determine congestion and adjust congestion control parameters, improving parameter adjustment accuracy and congestion control effectiveness.

Claims

Claims A network card device, wherein the network card device belongs to a sending node and comprises: Hardware-based congestion control components, scheduling components, sending components, and receiving components; The scheduling component is configured to detect current network status information of other nodes on the data path where the sending node is located, excluding the sending node, based on the network status detection message, and provide the current network status information to the congestion control component; There is at least one other node; the network status detection message is sent by the sending component, and the current network status information is received by the receiving component; the congestion control component is configured to generate a current bottleneck bandwidth occupancy rate used in current congestion control based on the current network status information of the at least one other node and a historical bottleneck bandwidth occupancy rate used in historical congestion control; adjust a congestion control parameter currently used by the network card device based on the current bottleneck bandwidth occupancy rate to obtain a new congestion control parameter, and provide the new congestion control parameter to the scheduling component, so that the scheduling component performs congestion control on data traffic to be sent by the network card device based on the new congestion control parameter.

2. The network card device according to claim 1, wherein: The congestion control component includes: a data cache area, a calculation component, and a status cache area implemented based on hardware; the scheduling component is further configured to: write current network status information of at least one other node into the data cache area; the status cache area stores historical bottleneck bandwidth occupancy rates used in historical congestion control; the calculation component is configured to: read the current network status information and historical bottleneck bandwidth occupancy rates of at least one other node from the data cache area and the status cache area, respectively, generate a current bottleneck bandwidth occupancy rate based on the current network status information of at least one other node and the historical bottleneck bandwidth occupancy rates, adjust the congestion control parameters currently used by the network card device based on the current bottleneck bandwidth occupancy rates to obtain new congestion control parameters, and output the new congestion control parameters to the scheduling component.

3. The network card device according to claim 2, wherein: The calculation component includes: a multi-path calculation component and an adjustment component; wherein the multi-path calculation components are executed in parallel and are configured to generate a current bandwidth occupancy of at least one other node based on current network status information and historical network status information of at least one other node stored in the data cache and the status cache, and provide the current bandwidth occupancy to the adjustment component; wherein each path calculation component is responsible for generating the current bandwidth occupancy of one other node at a time; the adjustment component is configured to determine a target bandwidth occupancy based on the current bandwidth occupancy of at least one other node; generate a current bottleneck bandwidth occupancy based on the target bandwidth occupancy and the historical bottleneck bandwidth occupancy read from the status cache, and write the current bottleneck bandwidth occupancy into the status cache to update the historical bottleneck bandwidth occupancy.

4. The network card device according to claim 3, wherein: Each computing component is configured to: for any other node, predict a first bandwidth occupancy rate based on a buffer queue length in current network status information of any other node, a buffer queue length in historical network status information, and a maximum transmission bandwidth of any other node; and predict a first bandwidth occupancy rate based on a sending timestamp and a sending data volume in current network status information of any other node, a sending timestamp and a sending data volume in historical network status information, and a maximum transmission bandwidth of any other node. The method further comprises calculating a second bandwidth occupancy rate based on the sending timestamp and the sending data volume in the network state information and the maximum transmission bandwidth of any other node; and generating the current bandwidth occupancy rate of any other node according to the first bandwidth occupancy rate and the second bandwidth occupancy rate of any other node.

5. The network card device according to claim 3, wherein: The adjustment component includes: a comparison subcomponent and a first adjustment subcomponent; the comparison subcomponent is configured to compare the current bottleneck bandwidth occupancy with a set bandwidth occupancy and trigger the first adjustment subcomponent when the current bottleneck bandwidth occupancy is greater than the set bandwidth occupancy; the first adjustment subcomponent, triggered by the comparison subcomponent, adjusts downward a congestion control parameter currently used by the network card device according to a ratio of the set bandwidth occupancy to the current bottleneck bandwidth occupancy to obtain a new congestion control parameter.

6. The network card device according to claim 5, wherein: The first adjustment subcomponent is further configured to: generate a basic multiplication coefficient based on a ratio of the current bottleneck bandwidth occupancy rate to the set bandwidth occupancy rate and a preset update system, wherein the basic multiplication coefficient is greater than 0 and less than 1; select the larger of the basic multiplication coefficient and the protection multiplication coefficient and use the larger as a target multiplication coefficient, wherein the protection multiplication coefficient is greater than 0 and less than 1; and multiplicatively adjust the congestion control parameter currently used by the network card device based on the target multiplication coefficient to obtain a new congestion control parameter.

7. The network card device according to claim 5, wherein: The adjustment component further includes: a second adjustment subcomponent; the second adjustment subcomponent, triggered by the comparison subcomponent, adjusts the congestion control parameter currently used by the network card device upward according to a preset parameter adjustment threshold to obtain a new congestion control parameter.

8. The network card device according to claim 7, wherein: The second adjustment subcomponent is further configured to: determine a target additive step size based on a relationship between a congestion control parameter currently used by the network card device and a preset parameter adjustment threshold; and additively increase the congestion control parameter currently used by the network card device based on the target additive step size and a preset step size weight to obtain a new congestion control parameter.

9. The network card device according to claim 8, wherein: The preset parameter adjustment threshold includes a sending rate threshold and an adjustment number threshold. Then, when determining the target additive step size, the second adjustment subcomponent is set to: in response to the current sending rate in the congestion control parameters currently used by the network card device being less than the sending rate threshold, determine the first step size as the target additive step size; in response to the current sending rate being greater than or equal to the sending rate threshold and the number of consecutive upward adjustments being greater than or equal to the adjustment number threshold, determine the second step size as the target additive step size; in response to the current sending rate being greater than or equal to the sending rate threshold and the number of consecutive upward adjustments being less than the adjustment number threshold, determine the third step size as the target additive step size; wherein the third step size is smaller than the second step size, and the second step size is smaller than the first step size.

10. The network card device according to any one of claims 1 to 9, wherein: The new congestion control parameters include a new sending window length and a new sending rate; The scheduling component includes: a hardware-implemented congestion parameter buffer, a connection status buffer, a token conversion component, a permission judgment component, and a processing component; the token conversion component is configured to convert the new sending rate into a token number and add the token number and the new sending window length to the congestion parameter buffer, wherein the token number and the sending window length are continuously consumed as data packets are sent; the connection status buffer stores data sending status information corresponding to the data path; the permission judgment component is configured to, upon determining that sending of a data packet is permitted based on the remaining token number and the remaining sending window length, as well as the data sending status information corresponding to the data path, provide information about the data packet to be sent and the data path to the processing component, and update the remaining token number and the remaining sending window length; the processing component is configured to generate a sending request based on the data packet to be sent and the data path information, and provide the sending request to the sending component, so that the sending component sends the data packet to be sent based on the data path information.

11. A congestion control method, applied to a network card device of a sending node, the method comprising: detecting, based on the network status detection message, current network status information of other nodes on a data path where the sending node is located, excluding the sending node, where the other node is at least one; generating, based on the current network status information of the at least one other node and a historical bottleneck bandwidth occupancy rate used in historical congestion control, a current bottleneck bandwidth occupancy rate used in current congestion control; and, if congestion is determined to have occurred based on the current bottleneck bandwidth occupancy rate, adjusting congestion control parameters currently used by the network card device based on the current bottleneck bandwidth occupancy rate to obtain new congestion control parameters; Congestion control is performed on the data traffic to be sent by the network card device according to the new congestion control parameter.

12. The method according to claim 11, wherein: Generating a current bottleneck bandwidth occupancy rate for use in current congestion control based on current network status information of at least one other node and a historical bottleneck bandwidth occupancy rate used in historical congestion control includes: generating a current bandwidth occupancy rate of at least one other node based on the current network status information and historical network status information of at least one other node; determining a target bandwidth occupancy rate based on the current bandwidth occupancy rate of at least one other node; and generating the current bottleneck bandwidth occupancy rate based on the target bandwidth occupancy rate and the historical bottleneck bandwidth occupancy rate.

13. The method according to claim 12, wherein: Generating a current bandwidth occupancy rate of at least one of the other nodes based on the current network status information and the historical network status information of at least one of the other nodes, including: for any other node, predicting a first bandwidth occupancy rate based on a buffer queue length in the current network status information of the any other node, a buffer queue length in the historical network status information, and a maximum transmission bandwidth of the any other node; and predicting a first bandwidth occupancy rate based on a sending timestamp and a sending data volume in the current network status information of the any other node, a sending timestamp and a sending data volume in the historical network status information, and a maximum transmission bandwidth of the any other node. The second bandwidth occupancy rate is calculated based on the sending timestamp and the sending data volume in the network state information and the maximum transmission bandwidth of any other node; and the current bandwidth occupancy rate of any other node is generated based on the first bandwidth occupancy rate and the second bandwidth occupancy rate of any other node.

14. The method according to claim 11, wherein: Adjusting, based on the current bottleneck bandwidth occupancy, a congestion control parameter currently used by the network card device to obtain a new congestion control parameter, including: if the current bottleneck bandwidth occupancy is greater than a set bandwidth occupancy, downwardly adjusting the congestion control parameter currently used by the network card device based on a ratio between the set bandwidth occupancy and the current bottleneck bandwidth occupancy to obtain the new congestion control parameter.

15. The method according to claim 14, wherein: The method further includes: when the current bottleneck bandwidth occupancy is less than or equal to the set bandwidth occupancy, adjusting the congestion control parameter currently used by the network card device upward according to a preset parameter adjustment threshold to obtain a new congestion control parameter.

16. The method according to any one of claims 11 to 15, wherein: Congestion control is performed on data traffic to be sent by the network card device according to the new congestion control parameters, including: converting the new sending rate into a number of tokens, and adding the number of tokens and the new sending window length to a congestion parameter buffer, wherein the number of tokens and the sending window length are continuously consumed as data packets are sent; and in response to determining that sending of the data packet is permitted based on the remaining number of tokens and the remaining sending window length, as well as data sending status information corresponding to the data path, providing information about the data packet to be sent and the data path to a sending component, so that the sending component sends the data packet to be sent according to the data path information.

17. A computer device comprising the network card device according to any one of claims 1 to 10.

18. A computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps of the method according to any one of claims 11 to 16.

19. A computer program product, comprising a computer program / instructions, which, when executed by a processor, causes the processor to implement the steps of the method according to any one of claims 11 to 16.

Images