Congestion control method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a congestion control method and device, electronic equipment, a storage medium and a program product. The method comprises the following steps: determining a sending mode of a message to be sent according to a comparison result of the size of the message to be sent and a first threshold value, and sending the message to be sent by adopting the sending mode, the sending mode being a direct sending mode or a Credit dependent mode, and the Credit dependent mode being a Credit dependent mode; the direct sending mode represents a mode of sending a message based on a bandwidth delay product (BDP), and the Credit dependency mode represents a mode of sending a message based on Credit.

Description

Technical Field

[0001] This application relates to the technical field of transmission and transmission, and more particularly to a congestion control method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] In related technologies, when deploying inference services, the EP (Extended Presence) mechanism expands the deployment scale from small-scale single-machine and dual-machine deployments to much larger-scale deployments. The all-to-all communication domain between EPs increases exponentially, placing higher demands on network communication efficiency. However, related technologies have not provided an effective solution for congestion control in communication networks that include both sending and receiving devices. Summary of the Invention

[0003] This application provides a congestion control method, apparatus, electronic device, storage medium, and program product that can effectively control congestion to a certain extent.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a congestion control method applied to a transmitting device, the method comprising: Based on the comparison result between the size of the message to be sent and the first threshold, the sending mode of the message to be sent is determined and the message to be sent is sent using the sending mode. The sending mode is either a direct sending mode or a credit-dependent mode. The direct sending mode represents a mode of sending messages based on the bandwidth-delay product (BDP), and the credit-dependent mode represents a mode of sending messages based on credit.

[0005] This application embodiment also provides another congestion control method applied to a receiving end device, the method comprising: Credit is allocated to the sending device, which then determines the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and a first threshold, and sends the message to be sent using the sending mode. The sending mode is either a direct sending mode or a credit-dependent mode. The direct sending mode represents a mode of sending messages based on the bandwidth-delay product (BDP), and the credit-dependent mode represents a mode of sending messages based on the credit.

[0006] This application also provides another congestion control method applied to intermediate network elements, the method comprising: When the depth of the buffer queue of the intermediate network element is greater than or equal to the third threshold, feedback congestion level indication information or suggested allocation rate of Credit is sent to the receiving device. The receiving device is used to determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on the feedback congestion level indication information or the suggested allocation rate of the credit.

[0007] This application embodiment also provides a congestion control device, the device being located in a transmitting end device, the device comprising: The first processing module is used to determine the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and the first threshold, and to send the message to be sent using the sending mode. The sending mode is either a direct sending mode or a credit-dependent mode. The direct sending mode represents a mode of sending messages based on BDP, and the credit-dependent mode represents a mode of sending messages based on credit.

[0008] This application embodiment also provides another congestion control device, the device being located in a receiving end device, the device comprising: The second processing module is used to allocate Credit to the sending device, so that the sending device determines the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and the first threshold, and sends the message to be sent using the sending mode. The sending mode is either a direct sending mode or a Credit-dependent mode. The direct sending mode represents a mode of sending messages based on BDP, and the Credit-dependent mode represents a mode of sending messages based on Credit.

[0009] This application embodiment also provides another congestion control device, the device being located in an intermediate network element, the intermediate network element being a network element between the transmitting end device and the receiving end device, the device comprising: The third processing module is used to send feedback congestion level indication information or suggested allocation rate of Credit to the receiving device when the depth of the buffer queue of the intermediate network element is greater than or equal to the third threshold. The receiving device is used to determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on the feedback congestion level indication information or the suggested allocation rate of the credit.

[0010] This application also provides an electronic device, which includes a processor and a memory for storing a computer program that can run on the processor; wherein the processor is used to run the computer program to perform any of the congestion control methods described above.

[0011] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements any of the above-described congestion control methods.

[0012] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the above-described congestion control methods.

[0013] The embodiments of this application have the following beneficial effects: It can be seen that in the embodiments of this application, the sending device can determine the sending mode of the message to be sent according to the size of the message to be sent. That is, it can flexibly select the direct sending mode or the credit-dependent mode according to the different sizes of the message to be sent. By flexibly selecting different sending modes, it helps to reduce the possibility of network congestion caused by the sending device sending a large number of data packets at the same time, thereby facilitating the realization of effective network congestion control. Attached Figure Description

[0014] Figure 1 A schematic diagram of an inference network provided for related technologies; Figure 2 A schematic diagram of another inference network provided for related technologies; Figure 3 A schematic diagram of a scenario architecture for generating incast traffic, provided for related technologies; Figure 4 A schematic diagram of another scenario architecture for generating incast traffic, provided for related technologies; Figure 5 This is a schematic diagram of the network architecture between the transmitting end device and the receiving end device provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a congestion control method applied to a transmitting device according to an embodiment of this application. Figure 7 This is a flowchart illustrating a congestion control method applied to a receiving device according to an embodiment of this application. Figure 8 This is a flowchart illustrating a congestion control method applied to intermediate network elements according to an embodiment of this application. Figure 9 This is a schematic diagram of the congestion control device applied to the transmitting device according to an embodiment of this application; Figure 10This is a schematic diagram of the congestion control device applied to the receiving end device according to an embodiment of this application; Figure 11 This is a schematic diagram of the congestion control device applied to intermediate network elements according to an embodiment of this application; Figure 12 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] In related technologies, traditional inference services employ centralized solutions, mostly deployed on a single machine. Even in multi-machine deployments, the machine scale is very small, with low demands on network bandwidth and latency. In Mixture of Experts (MoE) inference systems built around large-scale prefill-decode disaggregation (PD disaggregation) and key-value cache (KVCache), a large-scale expert parallelism (EP) mechanism can be introduced. The EP mechanism expands the machine deployment scale from small single-machine or dual-machine deployments to much larger ones, multiplying the all-to-all communication domain between EPs and placing higher demands on the communication efficiency of network infrastructure and all-to-all operators. In PD disaggregation deployment scenarios, KVCache traffic is transmitted between prefill (P) nodes and decode (D) nodes, and the latency of KVCache communication directly affects the overall performance of the inference service.

[0016] In inference networks, the all-to-all traffic characteristics between EPs are completely different from those of all-reduce traffic. The all-to-all traffic characteristics between EPs lead to very common incast traffic in many-to-one communication. Figure 1 TOR1, TOR2, and TOR3 represent different Top of Rack (TOR) switches, and LEAF1 and LEAF2 represent different Leaf (LEAF) switches. When node A communicates with node E, and node B communicates with node D, there will be many-to-one incast traffic in the inference service network. (See reference...) Figure 2TOR4, TOR5, and TOR6 represent different TOR switches, and LEAF3 and LEAF4 represent different LEAF switches. When node a communicates with node c, and node d communicates with node e, many-to-one incast traffic will occur in the inference network. The severity of incast traffic increases with the size of the distributed inference network. Sudden bursts of incast traffic may cause the uplink switch ports of the receiving network interface card to adopt priority-based flow control. Based Flow Control (PFC) strategies apply flow control to the sending side, leading to a reduction in traffic transmission speed in the inference network. In summary, incast traffic in many-to-one communication severely hinders further performance improvements in large-scale distributed inference networks.

[0017] In related technologies, the Alltoall operator can be implemented by calling the send recv method internally in PyTorch. The following diagram illustrates the incast traffic of many-to-one communication. (Refer to...) Figure 3 and Figure 4 Machine A, Machine B, Machine C, and Machine D represent different electronic devices, and GPU0, GPU1, GPU2, GPU3, GPU4, GPU5, GPU6, and GPU7 represent the different GPUs on each electronic device. (See reference...) Figure 3 Assuming that GPUs 0, 2, 4, and 6 of machine A, and GPUs 0, 2, 4, and 6 of machine C, all need to send data to GPU 0 of machine B, then 8-to-1 incast traffic will occur. In some scenarios, even if the scale of many-to-one incast traffic can be reduced using NCCL's PXN (PCI×NVLink) feature, the incast traffic for many-to-one communication still exists. For example, for... Figure 3 The many-to-one communication traffic shown uses PXN characteristics, which can reduce the scale of many-to-one communication. (Refer to...) Figure 4 This allows traffic from GPUs 2, 4, and 6 of machine A to be aggregated into GPU 0 of machine A, and traffic from GPUs 2, 4, and 6 of machine C to be aggregated into GPU 0 of machine C. Figure 4As can be seen, incast traffic in many-to-one communication still exists. Therefore, for various implementations of the Alltoall operator, incast traffic in many-to-one communication in the inference network is unavoidable. If the network-side congestion control algorithm is poorly configured and overly sensitive to congestion, it will slow down traffic transmission, thus affecting the overall network throughput. Combined with the aforementioned content control, in scenarios deploying inference services, the EP mechanism will increase the deployment scale from small single-machine and dual-machine deployments to larger scales. The all-to-all communication domain between EPs will multiply, placing higher demands on the communication efficiency of network infrastructure, Alltoall operators, etc. The characteristics of all-to-all traffic between EPs may lead to network congestion.

[0018] In related technologies, the following congestion control schemes can be adopted for inference networks: 1) At the queue management level, the EP traffic is configured with special priority through the end-side network card, so that Alltoall traffic is imported into the high-priority queue and other traffic (such as AllReduce traffic) is imported into the low-priority queue.

[0019] 2) At the resource level, more buffers are reserved on the high-priority queues of the end-side network cards and switches, and a higher proportion of bandwidth is allocated to prioritize the traffic of the high-priority queues.

[0020] 3) At the congestion control algorithm configuration level, the explicit congestion notification (ECN) marking function is turned off for high-priority queues, so that congestion control algorithms such as data center quantized congestion notification (DCQCN) do not react to congestion caused by micro-bursts of all-to-all traffic, thereby solving the slowdown in traffic transmission caused by the incast problem.

[0021] In large-scale distributed inference network scenarios, link BDP increases significantly. The congestion control schemes mentioned above in related technologies require buffers that exceed the capacity of the network infrastructure. If the congestion caused by incast traffic is not slowed down by the congestion control algorithm, packet loss will occur, which will affect the data transmission performance of the network. Furthermore, reserving more buffers means longer transmission latency, which will affect the overall inference efficiency of the inference network.

[0022] In view of the technical problems existing in related technologies, this application proposes technical solutions based on its embodiments.

[0023] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the embodiments provided herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application. Furthermore, the embodiments provided below are some embodiments for implementing this application, and not all embodiments for implementing this application. Unless otherwise specified, the technical solutions described in the embodiments of this application can be implemented in any combination.

[0024] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the apparatus, such as portions of circuitry, processors, programs, or software, etc.) in the method or apparatus that includes that element.

[0025] The congestion control method provided in this application includes a series of steps, but the congestion control method provided in this application is not limited to the steps described. Similarly, the congestion control device provided in this application includes a series of modules, but the device provided in this application is not limited to the modules explicitly described, but may also include modules that need to be set up for obtaining relevant information or processing based on the information.

[0026] This application proposes a congestion control method that can be applied to a sending device. Exemplarily, the sending device can be a worker node or cluster in an inference network; for example, the sending device can be a pre-filled node, a pre-filled cluster, a decoding node, a decoding cluster, etc. Exemplarily, refer to... Figure 5 T1 and T2 represent different TOR switches, and Agg1 and Agg2 represent different aggregation devices. Outcast traffic from the sending device can reach T1. T1 and T2 can communicate through the core network. Traffic received by T2 can be transmitted to the receiving device.

[0027] There can be one or more sending devices; there can also be one or more receiving devices. Multiple sending devices can send messages to the same receiving device, and the same sending device can also send messages to multiple different receiving devices.

[0028] Figure 6 This is a flowchart illustrating a congestion control method applied to a transmitting device according to an embodiment of this application, as shown below. Figure 6As shown, the process includes: Step 601: Based on the comparison result between the size of the message to be sent and the first threshold, determine the sending mode of the message to be sent and send the message to be sent using the sending mode. The sending mode is either direct sending mode or credit-dependent mode. Direct sending mode means sending the message based on BDP, and credit-dependent mode means sending the message based on credit.

[0029] In this embodiment, the first threshold can be denoted as Nse. The first threshold can be preset according to actual needs. In some embodiments, the first threshold can be set according to the size of BDP. The implementation method of sending the message to be sent using the direct sending mode can be: sending a data packet of size BDP in the message to be sent to the receiving device. Credit can be applied to flow control, and Credit is used to manage the data transmission rate between the sending device and the receiving device. The implementation method of sending the message to be sent using the Credit-dependent mode can be: after obtaining the Credit allocated by the receiving end, sending the message to be sent according to the Credit allocated by the receiving end.

[0030] In practical applications, after obtaining the message to be sent, the sending device can determine the size of the message; then, it compares the size of the message to be sent with a first threshold to obtain the comparison result; and it can choose different sending modes in direct sending mode and credit-dependent mode according to different comparison results.

[0031] In practical applications, step 601 can be implemented based on a processor and a communication device. The processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), controller, microcontroller, and microprocessor.

[0032] As can be seen, in this embodiment of the application, the sending device can determine the sending mode of the message to be sent according to the size of the message to be sent. That is, it can flexibly select the direct sending mode or the credit-dependent mode according to the different sizes of the message to be sent. By flexibly selecting different sending modes, it helps to reduce the possibility of network congestion caused by the sending device sending a large number of data packets at the same time, thereby facilitating effective network congestion control.

[0033] Regarding the implementation of step 601, in some embodiments, the sending device may send the message to be sent in a direct sending mode if the size of the message to be sent is less than or equal to the first threshold; and in a credit-dependent mode if the size of the message to be sent is greater than the first threshold.

[0034] Based on the foregoing description, when the size of the message to be sent is less than or equal to the first threshold, a data packet of size BDP within the message can be sent to the receiving device. When the size of the message to be sent is greater than the first threshold, the message can be sent according to the credit allocated by the receiving end.

[0035] It can be seen that when the size of the message to be sent is less than or equal to the first threshold, it can be considered that a message with a small amount of data needs to be sent. At this time, sending the message based on BDP can make full use of the transmission bandwidth. When the size of the message to be sent is greater than the first threshold, it can be considered that a message with a large amount of data needs to be sent. At this time, sending the message based on Credit is beneficial to limiting the message sending rate, which is conducive to reasonable congestion control.

[0036] In some implementations of sending messages using a direct sending mode, when the size of the message to be sent is greater than BDP, a first data packet of size BDP from the message to be sent can be sent to the receiving device; based on the Credit allocated by the receiving device, other data packets in the message to be sent are then sent to the receiving device, where the other data packets represent data packets in the message to be sent other than the first data packet. Of course, in other implementations, when the size of the message to be sent is less than or equal to BDP, all data packets of the message to be sent can be sent to the receiving device at once.

[0037] It can be seen that when the size of the message to be sent is less than or equal to the first threshold, it can be considered that a message with a small amount of data needs to be sent. At this time, the message is first sent based on BDP, which can make full use of the transmission bandwidth. After the message is sent based on BDP, the message can be sent based on the credit allocated by the receiving device. This helps to save the bandwidth occupied by the data packets and thus facilitates reasonable congestion control.

[0038] In some embodiments, when it is determined that the message to be sent is to be sent in the direct sending mode, the first data packet of size BDP in the message to be sent can be sent to the receiving device immediately.

[0039] To address the packet loss issue caused by multiple sending devices simultaneously sending BDP-sized content without waiting for the credit allocated by the receiver in long-distance, high-BDP scenarios, a random sending delay mechanism is introduced for each sending device. For example, the sending device can send the first data packet of size BDP in the message to be sent to the receiving device after waiting for a random delay period.

[0040] In this embodiment of the application, after the sending device obtains the message to be sent, if it determines that the size of the message to be sent is less than or equal to a first threshold, it can send the first data packet of size BDP in the message to be sent directly to the receiving device without waiting to receive the credit allocated by the receiving device; then, after waiting to receive the credit allocated by the receiving device, it sends the other data packets in the message to be sent to the receiving device based on the credit allocated by the receiving device.

[0041] As can be seen, since the sending device can send the first data packet of size BDP in the message to be sent to the receiving device after waiting for a random delay, in long-distance high BDP scenarios, if each of the multiple sending devices adopts the random delay sending mechanism of this application embodiment, the multiple sending devices will not send data packets of size BDP at the same time, which will not easily cause packet loss, thereby improving the reliability of data transmission.

[0042] To achieve effective congestion control, in some embodiments, before sending the first data packet of size BDP in the message to be sent to the receiving device, the sending device may, in response to receiving a congestion control message sent by an intermediate network element, determine to send the first data packet in a reduced-rate mode, or stop the sending process of the first data packet; the intermediate network element is the network element between the sending device and the receiving device.

[0043] Here, congestion control messages are used to instruct the sending device to perform congestion control. For example, a congestion control message can be a Congestion Notification Packet (CNP), a PFC-based control message, or other types of congestion notification. For example, an intermediate network element can determine the depth of its own buffer queue and send a congestion control message to the sending end when the depth of the buffer queue exceeds a certain threshold.

[0044] It can be seen that when the sending device receives the congestion control message sent by the intermediate network element, it can be assumed that the link between the sending device and the receiving device has become congested to a certain extent. At this time, congestion control can be effectively achieved by sending the first data packet in a reduced-speed mode or by stopping the sending process of the first data packet.

[0045] In some implementations of sending messages using the Credit dependency mode, the sending device can send each data packet in the message to the receiving device based on the Credit allocated by the receiving device.

[0046] In this embodiment, Credit is used to indicate the number of data packets sent by the sending device to the receiving device each time. After receiving the Credit assigned by the receiving device, the sending device can send the corresponding number of data packets to the receiving device each time according to the Credit assigned by the receiving device. In practical applications, each sending device can receive Credits assigned by multiple receiving devices. In this case, the sending device can send the corresponding number of data packets to the corresponding receiving device according to the Credit assigned by each receiving device. After receiving Credits assigned by multiple receiving devices, the sending device can accumulate the received Credits. After sending a data packet according to a Credit each time, the corresponding Credit can be subtracted from the accumulated value to achieve accurate updating of the accumulated value.

[0047] As can be seen, the sending device can send messages based on the credit allocated by the receiving device. Compared with the BDP-based message sending mode, this helps to save the bandwidth occupied by the data packets, thus facilitating reasonable congestion control.

[0048] To ensure priority for multiple service flows between the same source address (the address of the sending device) and destination address (the address of the receiving device), in some embodiments, the sending device may perform one or more of the following actions when it determines to send the message using the Credit dependency mode: The allocation ratio of Credit allocated by the receiving device to each service message is determined according to one or more of the priority and expected bandwidth information of each service message in the message to be sent. According to the priority of each service message in the message to be sent, add the priority information of Quality of Service (QoS) to each service message.

[0049] Here, the expected bandwidth information can be a relative value or an absolute value of the expected bandwidth. For example, the priority information of QoS can include one or more of the following: Differentiated Services Code Point (DSCP) and Type of Service (ToS).

[0050] In this embodiment, when determining the allocation ratio of Credit allocated by the receiving device to each service message according to one or more of the priority and expected bandwidth information of each service message in the message to be sent, Credit can be reasonably allocated to each service message according to its priority or expected bandwidth information. Adding QoS priority information to each service message according to its priority in the message to be sent is beneficial for ensuring priority for different types of service messages.

[0051] To further achieve network congestion control, in some embodiments, the transmitting device may feed back a first congestion level indication or a first suggested allocation rate for the credit to the receiving device when the accumulated credit is greater than or equal to a second threshold.

[0052] Here, the second threshold can be set according to actual needs, and can be denoted as Ncu. The first congestion level indication information is used to indicate the congestion level between the sending and receiving devices at the current moment. The first suggested allocation rate of Credit represents the suggested value of the credit allocation rate. The credit allocation rate is used to indicate the number of times credits are allocated to the sending device within a fixed time (e.g., per unit time). For example, the first suggested allocation rate of credits could be 3 credits allocated to the sending device per minute.

[0053] In practical applications, after determining the first congestion level indication information or the first suggested allocation rate, the sending device can carry the first congestion level indication information or the first suggested allocation rate in the data packets or messages sent to the receiving device.

[0054] It can be seen that when the accumulated credit of the sending device is greater than or equal to the second threshold, it can be considered that the sending device needs to send more data packets in the future. At this time, by feeding back the first congestion level indication information or the first suggested allocation rate of credit to the receiving device, it is beneficial to reduce the credit allocated by the receiving device to the sending device in the future, thereby helping to achieve effective congestion control between the sending device and the receiving device.

[0055] In high-BDP (Bandwidth-Depth) wide-area high-throughput link scenarios, there exists a situation where one source address corresponds to multiple destination addresses, i.e., one sending device sends messages to multiple receiving devices. In this case, how to achieve rapid convergence among different receiving devices, and how to achieve rapid convergence while differentiating service requirements (high bandwidth, low latency, etc.), are problems that need to be solved. To address this problem, in some embodiments of this application, the sending device can determine the first suggested allocation rate of the credits corresponding to each receiving device based on the service requirements corresponding to the message to be sent and the credits allocated to each receiving device.

[0056] It can be seen that the first suggested allocation rate of Credit for each receiving device is determined based on the business requirements of the message to be sent and the Credit allocated to each receiving device. In this way, when each receiving device allocates Credit to the sending device according to the first suggested allocation rate of the corresponding Credit, the allocated Credit can meet the business requirements of the message to be sent.

[0057] As described above, this application embodiment employs a multi-mode sending mechanism at the sending end to transmit messages. The following is an illustrative description of this multi-mode sending mechanism. For messages to be sent that are less than or equal to Nse, the sending device does not wait for the receiving device to allocate a Credit, but directly sends a first data packet of size BDP. Then, it sends other data packets according to the Credit allocated by the receiving device. For messages to be sent that are greater than Nse, it must wait for the receiving device to allocate a Credit, and then send a specified number of data packets according to the Credit allocated by the receiving device. When the accumulated Credit at the sending end exceeds Ncu, the sending end can carry a first congestion level indication information or a first suggested allocation rate in the data packets sent to the receiving device.

[0058] This application proposes another congestion control method that can be applied to receiving devices. Figure 7 This is a flowchart illustrating a congestion control method applied to a receiving device according to an embodiment of this application, as shown below. Figure 7 As shown, the process includes: Step 701: Allocate Credit to the sending device; The sending device is used to determine the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and the first threshold, and send the message to be sent using the sending mode. The sending mode is either direct sending mode or Credit-dependent mode. Direct sending mode means sending the message based on BDP, and Credit-dependent mode means sending the message based on the Credit allocated by the receiving device.

[0059] In practical applications, step 701 can be implemented based on a processor and a communication device. The processor can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0060] As can be seen, in this embodiment of the application, the sending device can determine the sending mode of the message to be sent according to the size of the message to be sent. That is, it can flexibly select the direct sending mode or the credit-dependent mode according to the different sizes of the message to be sent. By flexibly selecting different sending modes, it helps to reduce the possibility of network congestion caused by the sending device sending a large number of data packets at the same time, thereby facilitating effective network congestion control.

[0061] To accurately allocate credits to the sending device, in some embodiments, the receiving device can also determine the size and allocation rate of the credits allocated to the sending device based on reference information. This reference information includes one or more of the following: congestion level indication information, a suggested credit allocation rate, and the round-trip time (RTT) between the sending and receiving devices. Therefore, in the embodiments of this application, the receiving device can determine the size and allocation rate of the credits allocated to the sending device more accurately and reasonably based on the congestion level indication information, the suggested credit allocation rate, or the RTT between the sending and receiving devices.

[0062] For example, the receiving device can use algorithms such as Additive Increase Multiplicative Decrease (AIMD) and BBR-like (Bottleneck Bandwidth and Round-trip propagation time) to adjust the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on reference information.

[0063] In some embodiments, when the reference information includes a suggested credit allocation rate, the size of the credit allocated to the sending device can be determined based on the suggested credit allocation rate and the size of the credit currently available for allocation by the receiving device.

[0064] In practical applications, the total amount of allocatable credits can be pre-set for the receiving device. For example, the total amount of allocatable credits can be set for the receiving device based on its data receiving capacity at the same time. After setting the total amount of allocatable credits for the receiving device, if the receiving device allocates credits to one or more sending devices, the current amount of allocatable credits can be obtained by subtracting the currently allocated credits from the total amount of allocatable credits.

[0065] As can be seen, the embodiments of this application can determine the size of the credit allocated to the sending device more accurately and reasonably by comprehensively considering the suggested credit allocation rate and the size of the currently allocatable credit of the receiving device.

[0066] For example, the receiving device can determine a suggested value for the size of credits allocated within a fixed period of time (e.g., per unit time) based on the suggested credit allocation rate. Then, it compares the suggested value for the size of credits allocated within the fixed period of time with the size of currently allocable credits. The smaller of the suggested value and the size of currently allocable credits is taken as the size of the credits allocated to the sending device. In this way, since the size of currently allocable credits of the receiving device can reflect the receiving device's current credit allocation capability, the size of the credits allocated to the sending device can be reliably determined within the range of the receiving device's current credit allocation capability.

[0067] In this embodiment, congestion level indication information and the suggested allocation rate of credit can be obtained in various ways. For example, the congestion level indication information includes one or more of the following: first congestion level indication information fed back by the sending device, and second congestion level indication information fed back by an intermediate network element; the suggested allocation rate of credit includes one or more of the following: a first suggested allocation rate of credit fed back by the sending device, and a second suggested allocation rate of the credit fed back by an intermediate network element; the intermediate network element is the network element between the sending device and the receiving device.

[0068] As can be seen, in this embodiment of the application, the receiving device can determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device relatively accurately and reasonably based on the first congestion level indication information fed back by the sending device, the second congestion level indication information fed back by the intermediate network element, the first suggested allocation rate of the credit fed back by the sending device, or the second suggested allocation rate of the credit fed back by the intermediate network element.

[0069] In this embodiment, the receiving device can allocate credit sizes to multiple different sending devices. In some embodiments, when the receiving device allocates credit sizes to multiple different sending devices, the sum of the credit sizes allocated to the multiple different sending devices is greater than BDP. This allows the multiple different sending devices to fully utilize the link bandwidth when transmitting data according to the credit sizes allocated by the receiving device.

[0070] As described above, this application embodiment employs a flexible credit allocation mechanism at the receiving end to allocate credits. The following is an illustrative description of this flexible credit allocation mechanism. The receiving end device dynamically allocates credits for transmitting messages to the sending end device by sensing congestion level indication information, RTT, or suggested transmission rate of the sending end device and intermediate network elements (each hop network element in the network). Based on the congestion level indication information, RTT, and suggested credit allocation rate, the receiving end device adjusts the size and allocation rate of the credits allocated to specific sending end devices, ensuring that the total size of credits allocated to all sending end devices does not exceed G, where G is the total amount of allocable credits described above. The value of G can be adjusted, but it must be greater than BDP to ensure full utilization of link bandwidth.

[0071] This application proposes yet another congestion control method that can be applied to intermediate network elements. Figure 8 This is a flowchart illustrating the congestion control method applied to intermediate network elements according to an embodiment of this application, as shown below. Figure 8 As shown, the process includes: Step 801: When the depth of the intermediate network element's buffer queue is greater than or equal to the third threshold, send feedback second congestion level indication information or the second suggested allocation rate of Credit to the receiving device.

[0072] The receiving device is configured to determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on the second congestion level indication information or the second suggested allocation rate of the credit.

[0073] In practical scenarios, when an intermediate network element receives a data packet, it can store the received data packet in a buffer queue, and then send the data packet in the buffer queue to the next-hop device. The depth of the buffer queue represents the amount of data stored in the buffer queue, and the third threshold can be set according to actual needs. The third threshold can be denoted as Bth.

[0074] In practical applications, step 801 can be implemented based on a processor and a communication device. The processor can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0075] It can be seen that when the depth of the intermediate network element's buffer queue is greater than or equal to the third threshold, it can be considered that the buffer queue of the intermediate network element stores a large amount of data. This indicates that the link between the sending device and the receiving device has experienced a certain degree of congestion. In this case, by sending feedback of the second congestion level indication information or the second suggested allocation rate of credit to the receiving device, the receiving device can reasonably adjust the size and allocation rate of the credit allocated to the sending device according to the second congestion level indication information or the second suggested allocation rate. This is beneficial for effectively achieving congestion control by adjusting the size and allocation rate of the credit.

[0076] As described above, this application embodiment employs an intermediate network element-assisted enhancement mechanism to achieve congestion control. The intermediate network element-assisted enhancement mechanism is explained below by way of example. When the depth of the intermediate network element's buffer queue is greater than or equal to Bth, the intermediate network element can carry a second congestion level indication information or a second suggested allocation rate for Credit in the message sent to the receiving device.

[0077] Based on the foregoing description, when an intermediate network element determines that the depth of its own buffer queue is greater than or equal to the third threshold, it can also send a congestion control message to the sending device. The sending device can then use the congestion control message to send data packets in a reduced-rate mode or stop sending data packets altogether. For example, if the intermediate network element supports a PFC mechanism, it can use PFC-based control messages to apply backpressure step by step to the sending device, thereby mitigating packet loss to some extent.

[0078] The congestion control method of this application can be applied to various data transmission scenarios. For example, the congestion control method of this application can be applied to the transmission optimization scenario of inference networks. In the transmission optimization scenario of inference networks, the network congestion problem caused by many-to-one communication in large-scale distributed inference networks can be solved by adopting a flexible credit allocation mechanism at the receiving end, a multi-mode transmission mechanism at the sending end, and an intermediate network element auxiliary enhancement mechanism, thereby improving the performance of the inference network.

[0079] The following example illustrates congestion control methods in inference networks.

[0080] In inference networks, the sending device can be implemented based on a sending expert (EP), and the receiving device can be implemented based on a receiving EP. For all-to-all traffic, the sending EP can determine the amount of data to be sent or the size of the message to be sent. For example, it can determine the amount of data to be sent or the size of the message to be sent based on factors such as the input / output scale of the inference network model and the parallel strategy. Based on the comparison between the amount of data to be sent or the size of the message to be sent and the NSE (Network Sequence of Action), the sending mode to be adopted is determined.

[0081] If the size of the message to be sent is less than or equal to Nse, the sending device can send the first data packet of size BDP in the message to the receiving device EP after waiting for a random delay. If a congestion control message is received from an intermediate network element before the first data packet of size BDP in the message is sent, the first data packet is sent in a reduced speed mode, or the sending process of the first data packet is stopped.

[0082] When it is determined that the size of the message to be sent is greater than Nse, or after the sending device sends the first data packet of size BDP in the message to be sent to the receiving device, the sending device can send each data packet in the currently unsent message to the receiving device according to the Credit allocated by the receiving device.

[0083] If the sum of the Credits allocated by multiple receiving EPs to a specific sending EP exceeds Ncu, it indicates that the processing capacity of that sending EP cannot reliably transmit according to the Credits allocated to each receiving EP. The sending EP can then carry a first congestion level indication in subsequent data packets sent to the receiving EPs. Alternatively, the sending EP can determine a first suggested allocation rate for the Credits corresponding to each receiving EP based on the service requirements corresponding to the message to be sent and the Credits allocated to each receiving EP, and can carry this first suggested allocation rate in data packets.

[0084] Each receiving end (EP) can determine the size and allocation rate of the credit to be allocated to the sending end (EP) upon receiving the first congestion level indication information. As one implementation, each receiving end (EP) can determine the size of the credit to be allocated to the sending end (EP) after receiving the first suggested allocation rate, taking into account the currently available credit size.

[0085] During data transmission from the sending EP to the receiving EP, the intermediate network element can determine the depth of its own buffer queue. When the depth of the intermediate network element's buffer queue is greater than or equal to Bth, and the transmission mode is Credit-dependent mode, it can carry a second congestion level indication or a second suggested allocation rate for Credit in the messages sent to the receiving EP. When the depth of the intermediate network element's buffer queue is greater than or equal to Bth, and the transmission mode is direct transmission mode, it sends a congestion control message to the sending EP, causing the sending EP to reduce the message transmission rate before obtaining Credit, or to stop the message transmission process before obtaining Credit.

[0086] In summary, the solutions adopted in this application can optimize the transmission of large-scale distributed inference networks. In this application, by employing a flexible credit allocation mechanism at the receiving end, a multi-mode transmission mechanism at the sending end, and an intermediate network element-assisted enhancement mechanism, the network congestion problem caused by many-to-one communication in large-scale distributed inference networks can be solved, thereby improving the performance of the inference network. This application helps to optimize indicators such as high concurrency, low computing power overhead, low TTFT, and TBT in ultra-large-scale distributed inference networks, and also helps to accelerate the large-scale construction and application of Artificial Intelligence (AI).

[0087] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0088] Based on the congestion control method proposed in the foregoing embodiments, this application also proposes a congestion control device. Figure 9 This is a schematic diagram of the congestion control device applied to the transmitting device according to an embodiment of this application, as shown below. Figure 9 As shown, the device includes: The first communication module 901 is used to communicate with the receiving device; The first processing module 902 is used to determine the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and the first threshold, and to send the message to be sent using the sending mode. The sending mode is either a direct sending mode or a credit-dependent mode. The direct sending mode represents a mode of sending messages based on DP, and the credit-dependent mode represents a mode of sending messages based on Credit.

[0089] In some embodiments, the first processing module 902 is specifically used to send the message to be sent in the direct sending mode when the size of the message to be sent is less than or equal to the first threshold; and to send the message to be sent in the credit-dependent mode when the size of the message to be sent is greater than the first threshold.

[0090] In some embodiments, the first processing module 902 is specifically configured to send a first data packet of size BDP in the message to be sent to the receiving device; and based on the Credit allocated by the receiving device, send other data packets in the message to be sent to the receiving device, wherein the other data packets represent data packets in the message to be sent other than the first data packet.

[0091] In some embodiments, the first processing module 902 is specifically configured to send a first data packet of size BDP in the message to be sent to the receiving device after waiting for a random delay.

[0092] In some embodiments, the first processing module 902 is further configured to, in response to receiving a congestion control message sent by an intermediate network element, determine to send the first data packet in a reduced-speed mode or to stop the sending process of the first data packet before sending the first data packet of size BDP in the message to be sent to the receiving end device; the intermediate network element is a network element between the sending end device and the receiving end device.

[0093] In some embodiments, the first processing module 902 is specifically used to send each data packet in the message to be sent to the receiving device based on the Credit allocated by the receiving device.

[0094] In some embodiments, the first processing module 902 is further configured to perform one or more of the following when it is determined that the message to be sent is sent using the Credit dependency mode: The allocation ratio of the Credit allocated by the receiving device in each service message is determined according to one or more of the priority and expected bandwidth information of each service message in the message to be sent. According to the priority of each service message in the message to be sent, add the priority information of Quality of Service (QoS) to each service message.

[0095] In some embodiments, the first processing module 902 is further configured to feed back first congestion level indication information or a first suggested allocation rate of credit to the receiving device when the credit accumulated by the sending device is greater than or equal to a second threshold.

[0096] In some embodiments, the first processing module 902 is further configured to determine a first suggested allocation rate of the credits corresponding to each receiving device based on the service requirements corresponding to the message to be sent and the credits allocated to each receiving device.

[0097] In practical applications, the first communication module 901 can be implemented based on a communication device, and the first processing module 902 can be implemented based on a processor.

[0098] Figure 10 This is a schematic diagram of the congestion control device applied to the receiving end device according to an embodiment of this application, as shown below. Figure 10 As shown, the device includes: The second communication module 1001 is used to communicate with the transmitting device; The second processing module 1002 is used to allocate Credit to the sending device, so that the sending device determines the sending mode of the message to be sent according to the comparison result between the size of the message to be sent and the first threshold, and sends the message to be sent using the sending mode. The sending mode is either a direct sending mode or a Credit-dependent mode. The direct sending mode represents a mode of sending messages based on BDP, and the Credit-dependent mode represents a mode of sending messages based on Credit.

[0099] In some embodiments, the second processing module 1002 is further configured to determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on reference information; wherein the reference information includes one or more of the following: congestion level indication information, the suggested allocation rate of the credit, and the RTT between the sending device and the receiving device.

[0100] In some embodiments, the second processing module 1002 is specifically configured to, when the reference information includes the suggested allocation rate of the Credit, determine the size of the Credit to be allocated to the sending device based on the suggested allocation rate of the Credit and the size of the currently allocatable Credit of the receiving device.

[0101] In some embodiments, the congestion level indication information includes one or more of the following: first congestion level indication information fed back by the transmitting device, and second congestion level indication information fed back by the intermediate network element; the suggested allocation rate of the credit includes one or more of the following: first suggested allocation rate of the credit fed back by the transmitting device, and second suggested allocation rate of the credit fed back by the intermediate network element; the intermediate network element is a network element between the transmitting device and the receiving device.

[0102] In some embodiments, when the receiving device allocates a credit to a plurality of the sending devices, the sum of the credits allocated to the plurality of sending devices is greater than BDP.

[0103] In practical applications, the second communication module 1001 can be implemented based on a communication device, and the second processing module 1002 can be implemented based on a processor.

[0104] Figure 11 This is a schematic diagram of the congestion control device applied to an intermediate network element according to an embodiment of this application, as shown below. Figure 11 As shown, the device includes: The third communication module 1101 is used to communicate with the transmitting end device and the receiving end device; The third processing module 1102 is used to send feedback congestion level indication information or suggested allocation rate of transmission credit to the receiving device when the depth of the buffer queue of the intermediate network element is greater than or equal to the third threshold. The receiving device is used to determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on the feedback congestion level indication information or the suggested allocation rate of the credit.

[0105] In practical applications, the third communication module 1101 can be implemented based on a communication device, and the third processing module 1102 can be implemented based on a processor.

[0106] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0107] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0108] Correspondingly, this application embodiment further provides a computer program product, the computer program product including computer executable instructions, which are used to implement any of the congestion control methods provided in this application embodiment.

[0109] Accordingly, this application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the congestion control methods provided in the above embodiments.

[0110] This application also provides an electronic device. Figure 12 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, as shown below. Figure 12 As shown, the electronic device 120 may include: Memory 1201 is used to store executable instructions; The processor 1202 is used to implement any of the above-described congestion control methods when executing executable instructions stored in the memory 1201.

[0111] The processor 1202 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0112] The aforementioned computer-readable storage medium and memory 1201 may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; or it may be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0113] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0114] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0115] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict.

[0116] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0117] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0119] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims. All of these forms are within the protection scope of this application.

Claims

1. A congestion control method, characterized in that, Applied to a transmitting device, the method includes: Based on the comparison result between the size of the message to be sent and the first threshold, the sending mode of the message to be sent is determined and the message to be sent is sent using the sending mode. The sending mode is either a direct sending mode or a transmission credit-dependent mode. The direct sending mode represents a mode of sending messages based on the bandwidth-delay product (BDP), and the credit-dependent mode represents a mode of sending messages based on credit.

2. The method according to claim 1, characterized in that, The step of determining the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and the first threshold, and sending the message to be sent using the sending mode, includes: If the size of the message to be sent is less than or equal to the first threshold, the message to be sent is sent using the direct sending mode; If the size of the message to be sent is greater than the first threshold, the message to be sent is sent using the Credit dependency mode.

3. The method according to claim 2, characterized in that, Sending the message to be sent using the direct sending mode includes: Send the first data packet of size BDP in the message to be sent to the receiving device; Based on the Credit allocated by the receiving device, other data packets in the message to be sent are sent to the receiving device. The other data packets refer to data packets in the message to be sent other than the first data packet.

4. The method according to claim 3, characterized in that, Sending the first data packet of size BDP in the message to be sent to the receiving device includes: After waiting for a random delay, the first data packet of size BDP in the message to be sent is sent to the receiving device.

5. The method according to claim 3, characterized in that, Before sending the first data packet of size BDP in the message to be sent to the receiving device, the method further includes: In response to receiving a congestion control message from an intermediate network element, the system determines to either transmit the first data packet in a reduced-speed mode or to stop transmitting the first data packet; the intermediate network element is a network element between the transmitting device and the receiving device.

6. The method according to claim 2, characterized in that, Sending the message to be sent using the Credit dependency mode includes: Based on the Credit allocated by the receiving device, each data packet in the message to be sent is sent to the receiving device.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: When determining to send the message using the Credit dependency mode, perform one or more of the following: The allocation ratio of the Credit allocated by the receiving device in each service message is determined according to one or more of the priority and expected bandwidth information of each service message in the message to be sent. According to the priority of each service message in the message to be sent, add the priority information of Quality of Service (QoS) to each service message.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: When the accumulated Credit at the transmitting device is greater than or equal to the second threshold, the transmitting device feeds back the first congestion level indication information or the first suggested allocation rate of Credit to the receiving device.

9. The method according to claim 8, characterized in that, The method further includes: Based on the service requirements corresponding to the message to be sent and the Credits allocated to each receiving device, a first suggested allocation rate for the Credits corresponding to each receiving device is determined.

10. A congestion control method, characterized in that, Applied to a receiving device, the method includes: The sending device is allocated a transmission credit. The sending device is used to determine the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and a first threshold, and to send the message to be sent using the sending mode. The sending mode is either a direct sending mode or a credit-dependent mode. The direct sending mode represents a mode of sending messages based on the bandwidth-delay product (BDP), and the credit-dependent mode represents a mode of sending messages based on the credit allocated by the receiving device.

11. The method according to claim 10, characterized in that, The method further includes: Based on reference information, the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device are determined; wherein the reference information includes one or more of the following: congestion level indication information, the suggested allocation rate of the credit, and the round-trip time (RTT) between the sending device and the receiving device.

12. The method according to claim 11, characterized in that, Based on the reference information, the size of the Credit allocated to the sending device is determined, including: When the reference information includes the suggested allocation rate of the Credit, the size of the Credit allocated to the sending device is determined based on the suggested allocation rate of the Credit and the size of the Credit currently available for allocation by the receiving device.

13. The method according to claim 11, characterized in that, The congestion level indication information includes one or more of the following: the first congestion level indication information fed back by the transmitting device, and the second congestion level indication information fed back by the intermediate network element; the suggested allocation rate of the credit includes one or more of the following: the first suggested allocation rate of the credit fed back by the transmitting device, and the second suggested allocation rate of the credit fed back by the intermediate network element; the intermediate network element is the network element between the transmitting device and the receiving device.

14. The method according to any one of claims 11 to 13, characterized in that, In the case of the credit size allocated by the receiving device to the multiple sending devices, the sum of the credit sizes allocated to the multiple sending devices is greater than BDP.

15. A congestion control method, characterized in that, Applied to an intermediate network element, wherein the intermediate network element is a network element between a transmitting end device and a receiving end device, the method includes: When the depth of the buffer queue of the intermediate network element is greater than or equal to the third threshold, the receiving device is sent feedback second congestion level indication information or a second suggested allocation rate for transmission credit; The receiving device is configured to determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on the second congestion level indication information or the second suggested allocation rate of the credit.

16. A congestion control device, characterized in that, The device is located in the transmitting end equipment, and the device includes: The first processing module is used to determine the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and the first threshold, and to send the message to be sent using the sending mode. The sending mode is either a direct sending mode or a transmission credit-dependent mode. The direct sending mode represents a mode of sending messages based on the bandwidth-delay product (BDP), and the credit-dependent mode represents a mode of sending messages based on credit.

17. A congestion control device, characterized in that, The device is located in the receiving end equipment, and the device includes: The second processing module is used to allocate transmission credits to the sending device, so that the sending device determines the sending mode of the message to be sent based on the comparison result between the size of the message to be sent and a first threshold, and sends the message to be sent using the sending mode. The sending mode is either a direct sending mode or a credit-dependent mode. The direct sending mode represents a mode of sending messages based on the bandwidth-delay product (BDP), and the credit-dependent mode represents a mode of sending messages based on credits.

18. A congestion control device, characterized in that, The device is located in an intermediate network element, which is a network element between the transmitting end device and the receiving end device. The device includes: The third processing module is used to send feedback congestion level indication information or a suggested allocation rate for transmitting credit to the receiving device when the depth of the buffer queue of the intermediate network element is greater than or equal to the third threshold. The receiving device is used to determine the size of the credit allocated to the sending device and the allocation rate of the credit allocated to the sending device based on the feedback congestion level indication information or the suggested allocation rate of the credit.

19. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform the method according to any one of claims 1 to 15.

20. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 15.

21. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 15.

Images