A multi-path load balancing congestion control method, device, system and medium

Abstract

This application relates to a multi-path load balancing congestion control method, apparatus, system, and medium, comprising: a sending end acquiring path network status information fed back by a receiving end, determining the path congestion level accordingly, filtering out a preset number of overloaded paths, and updating a congestion control context that only records information about overloaded paths; further updating a queue context containing a path bitmap, the path bitmap being used to mark whether each path is available; and finally selecting an available path to send a message. This application only needs to maintain the status information of a small number of overloaded paths, significantly reducing storage overhead, and achieves efficient dynamic load balancing and congestion avoidance through the path bitmap.

Description

Technical Field

[0001] This application relates to the field of network communication technology, specifically to a multi-path load balancing congestion control method, apparatus, system, computer-readable storage medium, and computer program product. Background Technology

[0002] As data center networks continue to expand, Remote Direct Memory Access (RDMA) technology is widely used due to its low latency and high throughput. In RDMA networks, multiple transmission paths often exist between the sender and receiver. Traditional RDMA transmission typically selects paths at the flow level, meaning all packets within the same flow use the same 5-tuple and are transmitted through the same path. However, in large-scale networking environments, when some flows experience significant data bursts, it can easily lead to severe congestion on some paths while other paths remain idle, resulting in wasted network resources and decreased throughput.

[0003] To address the aforementioned issues, packet-by-packet load balancing technology emerged, allowing different packets from the same flow to be transmitted using different paths. Current packet-by-packet load balancing scheduling methods primarily include:

[0004] (1) Round-Robin (RR) scheduling: The sender sequentially polls all available paths to send packets. This method is simple to implement, but it only focuses on the scheduling of the sender and cannot perceive the congestion status of intermediate nodes in the network. This can easily lead to multiple flows being scheduled to the same congested path at the same time, which can exacerbate congestion.

[0005] (2) Weighted Round Robin (WRR) scheduling detects the congestion status of all paths in real time and assigns weights to paths based on their congestion level. Paths with lower congestion levels have higher weights and send more packets. Although WRR can detect congestion, it requires maintaining complete congestion status information for each path. In large-scale networks, the number of paths may be as high as hundreds, and storing the detailed status of each path (such as queue depth, number of ECNs, number of packet losses, etc.) requires a large amount of on-chip storage resources. For example, for 128 paths, several KB of storage space may be required, which is extremely costly for resource-constrained system-on-a-chip chips. In addition, a large amount of storage usage will lead to an increase in cache miss rate in high-concurrency scenarios, affecting overall throughput performance.

[0006] Therefore, how to reduce the resource consumption of congestion control algorithms and improve transmission performance while ensuring load balancing is an urgent technical problem to be solved. Summary of the Invention

[0007] In view of the above problems, this application proposes a multi-path load balancing congestion control method, device, system, computer-readable storage medium and computer program product, which significantly reduces storage overhead by maintaining only the state information of some heavy-load paths, and achieves efficient load balancing by combining a path bitmap-based scheduling mechanism.

[0008] According to the first aspect, this application proposes a multi-path load balancing congestion control method, applied at the sending end, the method comprising: Send messages to the receiving end through multiple paths and receive response messages returned by the receiving end; Obtain the path network status information carried in the response message, which is used to indicate the congestion level of the corresponding path; The congestion level of the corresponding path is determined based on the path network status information, and the congestion control context is updated based on the congestion level of the corresponding path; wherein, the congestion control context includes the path identifier and congestion level of the overloaded path, and the overloaded path is a preset number of paths with the highest congestion level. The queue context is updated according to the path identifier of the overloaded path; wherein, the queue context includes a path bitmap, the path bitmap includes multiple status bits corresponding one-to-one with the multiple paths, each status bit is used to indicate whether the corresponding path is available; when the path is an overloaded path, the corresponding status bit indicates that the path is unavailable; when the path is a non-overloaded path, the corresponding status bit indicates that the path is available. Based on the updated queue context, select the available path indicated by the status bit in the path bitmap for message transmission.

[0009] In some possible implementations, the path network status information includes at least one of packet loss information, explicit congestion notification information, or round-trip delay information; The packet loss information includes path identifier and number of lost packets; the explicit congestion notification information includes path identifier and number of explicit congestion notification markers; and the round-trip delay information includes path identifier and corresponding round-trip transmission delay.

[0010] In some possible implementations, when the path network state information includes at least two of packet loss information, explicit congestion notification information, and round-trip time information, determining the congestion level of the corresponding path based on the path network state information specifically includes: The congestion level of a path with packet loss is greater than that of a path with explicit congestion notification flags. Paths with explicit congestion notification flags are more congested than paths with no packet loss and no explicit congestion notification flags. For any two paths with packet loss, the greater the number of packet losses, the greater the congestion of the paths. For any two paths with explicit congestion notification tags, the greater the number of explicit congestion notification tags, the greater the congestion level of the paths. For any two paths with no packet loss and no explicit congestion notification, the greater the round-trip time, the greater the congestion level of the path.

[0011] In some possible implementations, the congestion control context further includes a sending window, which controls the upper limit of the number of packets that the sender can send; The method further includes: The receiver receives signaling messages sent by the receiving end, parses the signaling messages to obtain the signaling rate, and updates the sending window according to the signaling rate; wherein the signaling rate is determined by the receiving end based on the number of paths currently in a congested state and the upper limit of the receiving end's receiving capacity.

[0012] In some possible implementations, the queue context also includes the number of tokens for controlling message transmission; The step of selecting an available path indicated by the status bit in the path bitmap for message transmission based on the updated queue context specifically includes: Before sending a message, check whether the number of tokens in the queue context is greater than zero; If the number of tokens is greater than zero, the path bitmap in the queue context is queried, and a path is selected from the available paths indicated by the status bit based on the round-robin scheduling strategy to send the message. After the message is sent, the number of tokens is decremented by one. If the token count is zero, message transmission is paused, the token count is updated according to the transmission window in the congestion control context, and message transmission resumes after the token count is updated to be greater than zero.

[0013] In some possible implementations, the packets sent by the sending end are forwarded via a network device; wherein, when forwarding packets, if the output port queue length of the network device is greater than a first preset threshold, the network device discards the packets so that the receiving end detects packet loss and generates the packet loss information; if the output port queue length of the network device is greater than a second preset threshold but less than the first preset threshold, the packets are explicitly marked with congestion notification so that the receiving end generates the explicit congestion notification information based on the marking.

[0014] In some possible implementations, before sending the message to the receiving end via multiple paths, the method further includes: Establish multiple path connections with the receiving end; Initialize the congestion control context and set the overloaded path set to empty; Initialize the queue context by setting all status bits in the path bitmap to indicate availability.

[0015] According to the second aspect, this application proposes a multi-path load balancing congestion control method, applied at the receiving end, the method comprising: Receive messages sent by the sender through multiple paths; Path network status information is generated based on the received messages, and the path network status information is used to indicate the congestion level of the corresponding path. Send a response message carrying the path network status information to the sending end, so that the sending end can determine the path congestion level and update the congestion control context and queue context based on the path network status information. The congestion control context includes path identifiers and congestion levels for overloaded paths, where the overloaded paths are a preset number of paths with the highest congestion levels. The queue context includes a path bitmap, which includes multiple status bits corresponding one-to-one with the multiple paths. Each status bit is used to indicate whether the corresponding path is available. When the path is an overloaded path, the corresponding status bit indicates that the path is unavailable. When the path is a non-overloaded path, the corresponding status bit indicates that the path is available.

[0016] In some possible implementations, the path network status information includes at least one of packet loss information, explicit congestion notification information, or round-trip delay information; The step of generating path network status information based on the received message specifically includes: The system detects whether there is a gap in the sequence number of the received message. If there is a gap, it generates a response message carrying packet loss information, including the path identifier and the number of lost packets. The Internet Protocol header of the received message is parsed. If an explicit congestion notification flag is detected, a response message carrying explicit congestion notification information is generated. The explicit congestion notification information includes the path identifier and the number of flags. Record the timestamp of the received message and generate a response message carrying round-trip delay information.

[0017] In some possible implementations, the method further includes: The number of paths currently in a congested state is counted based on messages carrying explicit congestion notification flags. The signaling rate is determined based on the number of paths in a congested state and the upper limit of its own receiving capacity, and a signaling message is generated based on the signaling rate. The signaling message is sent to the sending end, and the signaling message is used to instruct the sending end to update the sending window in the congestion control context.

[0018] In some possible implementations, the signaling rate is determined based on the number of congested paths and the upper limit of the receiving capacity, and signaling messages are generated based on the signaling rate, specifically including: When the number of congested paths is less than a preset threshold, the signaling rate is determined based on the upper limit of the receiving capacity; When the number of congested paths is greater than or equal to a preset threshold, the signaling rate is determined based on the upper limit of the receiving capacity and an adjustment coefficient. The adjustment coefficient is determined based on the relationship between the number of congested paths and the total number of paths. The more congested paths there are, the smaller the adjustment coefficient becomes.

[0019] According to a third aspect, this application proposes a multi-path load balancing congestion control device, applied at a transmitting end, for performing the method as described in the first aspect, the device comprising: The first sending processing module is used to send messages to the receiving end through multiple paths; The second receiving and processing module is configured to receive the response message returned by the receiving end and obtain the path network status information carried in the response message; wherein the path network status information is used to indicate the congestion level of the corresponding path; and A congestion control module is used to determine the congestion level of a corresponding path based on the path network status information, and update the congestion control context based on the congestion level of the corresponding path; wherein, the congestion control context includes the path identifier and congestion level of the overloaded path, and the overloaded path is a preset number of paths with the highest congestion level. The first sending processing module is further configured to update the queue context according to the path identifier of the overloaded path; wherein, the queue context includes a path bitmap, the path bitmap includes multiple status bits corresponding one-to-one with the multiple paths, each status bit is used to indicate whether the corresponding path is available; when the path is an overloaded path, the corresponding status bit indicates that the path is unavailable; when the path is a non-overloaded path, the corresponding status bit indicates that the path is available. The first sending processing module is further configured to select an available path indicated by a status bit in the path bitmap for message sending based on the updated queue context.

[0020] According to the fourth aspect, this application proposes a multi-path load balancing congestion control device, applied at a receiving end, for performing the method as described in the first aspect, the device comprising: The second receiving and processing module is used to receive messages sent by the sending end through multiple paths, and generate path network status information based on the received messages; wherein, the path network status information is used to indicate the congestion level of the corresponding path. The second sending processing module is used to send a response message carrying the path network status information to the sending end, so that the sending end can determine the path congestion level and update the congestion control context and queue context according to the path network status information. The congestion control context includes path identifiers and congestion levels for overloaded paths, where the overloaded paths are a preset number of paths with the highest congestion levels. The queue context includes a path bitmap, which includes multiple status bits corresponding one-to-one with the multiple paths. Each status bit is used to indicate whether the corresponding path is available. When the path is an overloaded path, the corresponding status bit indicates that the path is unavailable. When the path is a non-overloaded path, the corresponding status bit indicates that the path is available.

[0021] According to the fifth aspect, this application proposes a multi-path load balancing congestion control system, including a transmitter, a network device, and a receiver; The sending end is used to perform the method as described in the first aspect; The receiving end is used to perform the method as described in the second aspect; The network device is configured to forward packets sent by the sending end to the receiving end, and to forward response packets sent by the receiving end to the sending end; wherein, if the output port queue length of the network device is greater than a first preset threshold and less than a second preset threshold, the packet is discarded so that the receiving end detects packet loss and generates packet loss information; if the output port queue length of the network device is greater than or equal to the second preset threshold, the packet is explicitly marked with a congestion notification tag so that the receiving end generates explicit congestion notification information based on the tag.

[0022] According to a sixth aspect, this application proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method as described in the first aspect, or implements the steps of the method as described in the second aspect.

[0023] According to a seventh aspect, this application provides a computer program product including computer program instructions that, when executed by a processor, implement the steps of the method as described in the first aspect, or implement the steps of the method as described in the second aspect.

[0024] The multi-path load balancing congestion control method, apparatus, system, computer-readable storage medium, and computer program product proposed in this application have at least the following beneficial effects: This application employs a congestion control context that records only a preset number (e.g., 8) of the most congested overloaded paths, rather than recording the status of all paths. For example, with 128 paths, a traditional solution might require 4KB of memory, while this solution only requires approximately 128 bytes, reducing memory consumption by about 32 times. This significantly frees up chip storage resources, enabling support for more concurrent streams with limited resources, reducing cache miss rates, and improving overall throughput performance. Furthermore, this application categorizes paths into overloaded and non-overloaded paths, marking path availability through a path bitmap in the queue context (QPC). During transmission, only paths indicating availability (i.e., non-overloaded paths) are scheduled, allowing for real-time removal of severely congested paths and even distribution of traffic across remaining available paths, avoiding the congestion exacerbation issues that can result from RR scheduling. In summary, by maintaining only the status information of a subset of overloaded paths, storage overhead is significantly reduced, and combined with a path bitmap-based scheduling mechanism, efficient load balancing is achieved. Attached Figure Description

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

[0026] Figure 1 This is a diagram illustrating the transmission path between the client and the server.

[0027] Figure 2 This is a flowchart of a multi-path load balancing congestion control method according to Embodiment 1 of this application.

[0028] Figure 3 This is a flowchart of a multi-path load balancing congestion control method according to Embodiment 2 of this application.

[0029] Figure 4 This is a graph showing the change in signaling production rate as a function of the number of congested paths in Embodiment 2 of this application.

[0030] Figure 5 This is a schematic diagram of a multi-path load balancing congestion control device according to Embodiment 3 of this application.

[0031] Figure 6 This is a schematic diagram of a multi-path load balancing congestion control device according to Embodiment 4 of this application.

[0032] Figure 7 This is a schematic diagram of a multipath load balancing congestion control system according to Embodiment 5 of this application.

[0033] Marked in the image: 1-Sender, 11-First transmission processing module, 12-First reception processing module, 13-Congestion control module; 2-Receiver, 21-Second reception processing module, 22-Second transmission processing module; 3-Network device. Detailed Implementation

[0034] The detailed description of the accompanying drawings is intended to illustrate the present preferred embodiments of this application and is not intended to represent only the forms in which this application can be implemented. It should be understood that the same or equivalent functions can be achieved by different embodiments intended to be included within the spirit and scope of this application.

[0035] Example 1 See Figure 2 Embodiment 1 of this application proposes a multi-path load balancing congestion control method, applied to the sending end of a message, the method comprising: Step S11: Send messages to the receiving end through multiple paths and receive response messages returned by the receiving end; Specifically, multiple paths for data transmission are established between the sending end and the receiving end. Each path is identified by a different source port. The sending end is, for example, a client, and the receiving end is, for example, a server. The sending end maintains a queue context (QPC) that records the path information currently available for sending packets. During data transmission, the sending end selects an available path according to the scheduling policy in the queue context, constructs a packet, and sends it. The packet is forwarded through one or more network devices (such as switches) within the network and eventually reaches the receiving end. After successfully receiving the packet, the receiving end generates a corresponding response packet (e.g., an ACK packet, a SACK packet, a CNP packet, etc.) and returns the response packet to the sending end along the corresponding path. The sending end obtains network path status feedback by receiving these response packets.

[0036] Step S12: Obtain the path network status information carried in the response message, the path network status information being used to indicate the congestion level of the corresponding path; Specifically, the path network state information is generated by the receiving end based on the network conditions experienced by the packet during transmission. This path network state information can be carried back to the sending end through specific or extended fields in the response packet. The path network state information may include, but is not limited to, the following forms: packet loss information, indicating the packet loss events and their number that occurred on a certain path; Explicit Congestion Notification (ECN) information, indicating the number of packets marked with ECN by network devices on a certain path; Round-Trip Time (RTT) information, indicating the time delay from packet transmission to receiving a response on a certain path. These pieces of information quantify the congestion status of the path from different dimensions, providing a data basis for the sending end to determine congestion.

[0037] Step S13: Determine the congestion level of the corresponding path based on the path network status information, and update the congestion control context based on the congestion level of the corresponding path; wherein, the congestion control context includes the path identifier and congestion level of the overloaded path, and the overloaded path is a preset number of paths with the highest congestion level. Specifically, after obtaining the latest path network status information, the sending end triggers a path congestion assessment process. First, according to predetermined congestion comparison rules, the congestion levels of the paths involved in the path network status information are quantified and ranked. These comparison rules prioritize severe congestion events; for example, paths with packet loss are considered more congested than paths with only ECN tags, and paths with only ECN tags are considered more congested than paths without packet loss or ECN tags. In similar cases, further comparisons are made based on the specific values ​​of packet loss count, ECN count, or round-trip time (RRT). Subsequently, the sending end compares the currently assessed path congestion level with the set of overloaded paths recorded in the congestion control context. The overloaded path set maintains the identifiers and congestion level parameters of a preset number (e.g., 8) of paths with the highest congestion levels in the current network. The path identifiers are path numbers or indices, and the congestion level parameters include, but are not limited to, the number of packet losses, the number of ECN tags, and the RRT within a preset time period. If the congestion level of the currently evaluated path exceeds that of the path with the lowest congestion level in the set, then the set of overloaded paths is updated, the path with the lowest congestion level is removed, and the current path is inserted and reordered. If the congestion level of the currently evaluated path does not exceed the minimum value in the set, and the set is full, then no update is performed. In this way, the congestion control context only needs to store and maintain the state of a small number of critical paths, rather than the state of all paths, thus greatly saving storage resources.

[0038] Step S14: Update the queue context according to the path identifier of the overloaded path; wherein, the queue context includes a path bitmap, the path bitmap includes multiple status bits corresponding one-to-one with the multiple paths, each status bit is used to indicate whether the corresponding path is available; when the path is an overloaded path, the corresponding status bit indicates that the path is unavailable; when the path is a non-overloaded path, the corresponding status bit indicates that the path is available. Specifically, the queue context is the execution data structure referenced by the sender during actual packet scheduling. Its path bitmap is a multi-bit binary field, with each bit corresponding to a path. After the congestion control context is updated and the latest set of overloaded paths is determined, the sender iterates through this set. For each overloaded path in the set, its path identifier is mapped to the corresponding bit in the path bitmap, and the value of that bit is set to indicate unavailability (e.g., set to "0"). For all other paths not appearing in the overloaded path set (lightly loaded paths), their corresponding bits are set to indicate availability (e.g., set to "1"). Thus, the path bitmap reflects in real time which paths in the current network are determined to be severely congested and need to be avoided, and which paths are relatively unobstructed and available for transmission.

[0039] Step S15: Based on the updated queue context, select the available path indicated by the status bit in the path bitmap for message transmission.

[0040] Specifically, the queue context or congestion control context stores a base port number (base_port), which is a pre-configured starting value for the path source port. Multiple status bits in the path bitmap correspond one-to-one with the path indices (path_index) of multiple paths. When selecting a target path to send a packet, the sender uses a round-robin scheduling strategy to traverse the path bitmap, determine the first status bit indicating an available target status bit, and obtain the target path index accordingly. This ensures that traffic is only scheduled to non-overloaded paths, and that load balancing on non-overloaded paths achieves dynamic load balancing based on real-time congestion feedback. Subsequently, the sender updates the five-tuple information of the current packet according to the target path index. Specifically, the sender obtains the base port number, sums it with the target path index, and obtains the target source port number of the current packet. The sender keeps the source IP address, destination IP address, destination port number, and transmission protocol unchanged in the five-tuple, and fills the source port number into the source port field of the packet header. By modifying the source port field, when parsing the packet 5-tuple for hash routing, the forwarding device in the network will map the packet to the physical path corresponding to the target path index for forwarding, thereby achieving multi-path load balancing transmission based on packet-by-packet granularity.

[0041] This embodiment uses a congestion control context to record only a preset number (e.g., 8) of the most congested overloaded paths, instead of recording the status of all paths. For example, with 128 paths, a traditional solution might require 4KB of memory, while this solution only requires about 128 bytes, reducing memory consumption by approximately 32 times. This significantly frees up chip storage resources, enabling support for more concurrent streams with limited resources, reducing cache miss rates, and improving overall throughput performance. Furthermore, this embodiment divides paths into overloaded and non-overloaded paths, marking path availability through a path bitmap in the queue context (QPC), and scheduling only available paths (i.e., non-overloaded paths) during transmission. This allows for real-time removal of severely congested paths, evenly distributing traffic across the remaining available paths, avoiding the congestion exacerbation problem that might result from RR scheduling. In summary, by maintaining only the status information of a subset of overloaded paths, storage overhead is significantly reduced, and combined with a path bitmap-based scheduling mechanism, efficient load balancing is achieved.

[0042] In some embodiments, the path network status information includes at least one of packet loss information, explicit congestion notification information, or round-trip delay information; wherein, the packet loss information includes a path identifier and the number of lost packets; the explicit congestion notification information includes a path identifier and the number of explicit congestion notification markers; and the round-trip delay information includes a path identifier and the corresponding round-trip transmission delay.

[0043] Specifically, the packet loss information can be carried through a Selective Acknowledgment (SACK) message, whose path identifier (e.g., source port number or path index) can uniquely locate the path where the packet loss occurred, and the number of packet losses represents the number of consecutively lost or detected lost packets on that path. The explicit congestion notification information can be carried in the congestion notification message. It is generated by the receiving end when it detects that the IP header of the data packet carries an ECN mark. Its path identifier indicates the congestion path, and the number of marks can reflect the degree or scale of congestion on the path. The round-trip time information is calculated based on the path probe message with a sending timestamp sent by the sender and the reception time of the corresponding response message returned by the receiver. The round-trip time consists of the propagation delay of the path and the queuing delay of intermediate network devices. When no packet loss information is detected and no explicit congestion notification flag is detected, the increase in the round-trip time indicates that the backlog of the output port queue of intermediate network devices (such as switches) in the path is aggravated. Therefore, the round-trip time serves as the basis for judging the potential congestion state of the path.

[0044] In some embodiments, when the path network status information includes at least two of packet loss information, explicit congestion notification information, and round-trip time delay information, step S13, which determines the congestion level of the corresponding path based on the path network status information, specifically includes: The congestion comparison between paths follows these 5 rules: ① The congestion level of paths with packet loss is greater than that of paths with explicit congestion notification flags. ② The congestion level of a path with an explicit congestion notification flag is greater than that of a path with no packet loss and no explicit congestion notification flag. ③ For any two paths with packet loss, the greater the number of packet losses, the greater the congestion of the paths. ④ For any two paths with explicit congestion notification tags, the greater the number of explicit congestion notification tags, the greater the congestion level of the path. ⑤ For any two paths with no packet loss and no explicit congestion notification, the greater the round-trip time, the greater the congestion of the path.

[0045] Specifically, the congestion level comparison rule in this embodiment can be understood as being based on priority. Packet loss is considered the most severe congestion signal, indicating that the forwarding queues of network devices on the path are full and have begun to drop packets, thus it has the highest priority. ECN marking indicates that the queue depth of the forwarding queues of network devices on the path has exceeded the preset ECN waterline, and congestion has begun to worsen, but has not yet reached the point where packet loss is necessary, so its priority is the second highest. For paths without packet loss and without ECN, congestion judgment depends on RTT. An increase in RTT may be due to an increase in the queue length of switches on the path, leading to an increase in packet queuing time. Therefore, the larger the RTT, the more severe the congestion is presumed. Among paths of the same priority, a finer comparison is made by the number of packet losses, the number of ECN markings, or the size of the RTT value to distinguish the degree of path congestion.

[0046] In some embodiments, the congestion control context further includes a sending window, which is used to control the upper limit of the number of packets that the sender can send; The method further includes: The receiver receives signaling messages sent by the receiving end, parses the signaling messages to obtain the signaling rate, and updates the sending window according to the signaling rate; wherein the signaling rate is determined by the receiving end based on the number of paths currently in a congested state and the upper limit of the receiving end's receiving capacity.

[0047] Specifically, the sending window is a global flow control parameter that limits the maximum number of packets the sender can inject into the network without receiving acknowledgment. The updating of the sending window depends not only on congestion events but also on signaling control from the receiver. Signaling messages are sent periodically or event-triggered by the receiver, and include a signaling rate (Credit) parameter that reflects the receiver's currently recommended data transmission rate. This signaling rate is not a fixed value but is dynamically adjusted by the receiver after considering its own processing capacity (upper limit of receiving capacity) and the network congestion situation (number of currently congested paths). After receiving a signaling message, the sending end extracts the signaling rate and updates its sending window in the congestion control context accordingly. Specifically, in one embodiment, if the signaling arrival time interval is within a preset aging time, an cumulative update strategy can be adopted, i.e., the updated sending window = the current sending window + the signaling rate; if the aging time is exceeded, a replacement strategy can be adopted, i.e., the updated sending window = the signaling rate. This allows the sending end's sending limit to adapt to the receiving end's processing capacity and to make a global response to the overall network congestion level.

[0048] In some embodiments, the queue context further includes the number of tokens for controlling message transmission; The step of selecting an available path indicated by the status bit in the path bitmap for message transmission based on the updated queue context specifically includes: Before sending a message, check whether the number of tokens in the queue context is greater than zero; If the number of tokens is greater than zero, the path bitmap in the queue context is queried, and a path is selected from the available paths indicated by the status bit based on the round-robin scheduling strategy to send the message. After the message is sent, the number of tokens is decremented by one. If the token count is zero, message transmission is paused, the token count is updated according to the transmission window in the congestion control context, and message transmission resumes after the token count is updated to be greater than zero.

[0049] Specifically, the token count in the queue context is initialized to the value of the sending window in the congestion control context. Each time the sender transmits a packet, it consumes one token, thus decrementing the token count by one. When the token count reaches zero, it indicates that the current window's maximum transmission limit has been reached, and the sender will pause new packet transmission and enter a waiting state. During the pause, if the sending window of the congestion control context changes (increases) due to new signaling or congestion adjustment, it will trigger an update of the token count, setting it to the new window value or increasing the corresponding difference, making the token count greater than zero again. This allows packet transmission to resume, thus achieving closed-loop management of flow control and ensuring that the transmission rate does not exceed network congestion limits or the receiver's receiving capacity.

[0050] For example, when the sending processing module needs to send a message, it reads the path bitmap (path_info), token count (swin), base port number (base_port), and current path number / index (cur_path_index) of the QPC. cur_path_index can be understood as the offset relative to base_port. If swin is 0, a token request event is generated and sent to the congestion control module, waiting for the congestion control module to return a response, and then the path bitmap and swin in the QPC are updated. If swin is not 0, the source port with base_port + cur_path_index as the port number is used for sending. After the message is successfully sent, swin is decremented by 1 and cur_path_index is incremented by 1. If the corresponding bit in path_info is 0, it means that the path is a congested overloaded path, and cur_path_index is incremented by 1 again until a non-overloaded path (lightly loaded path) is encountered.

[0051] In some embodiments, the packets sent by the sending end are forwarded via a network device; wherein, when forwarding packets, if the output port queue length of the network device is greater than a first preset threshold, the network device discards the packets so that the receiving end detects packet loss and generates the packet loss information; if the output port queue length of the network device is greater than a second preset threshold and less than the first preset threshold, the packets are explicitly marked with congestion notification so that the receiving end generates the explicit congestion notification information based on the marking.

[0052] Specifically, the network device (e.g., a network utility) is a critical node on the path that generates congestion signals. The network device maintains a forwarding queue for each output port or path. When packets accumulate in the forwarding queue, the queue length (i.e., the number of packets in the forwarding queue) increases. The network device presets two waterline thresholds: a first preset threshold (packet loss waterline) and a second preset threshold (ECN waterline), where the second preset threshold is less than the first preset threshold. When the queue length is greater than the second preset threshold but less than the first preset threshold, the network device sets an ECN marker in the IP header of the packet during forwarding to send an early congestion warning to the receiving end. When the queue length continues to grow and exceeds the first preset threshold, the buffer resources are exhausted, and the network device discards newly arriving packets. The receiving end detects ECN markers and sequence number gaps in the packets, generates ECN information and packet loss information respectively, and feeds back to the sending end through a response message, thus completing the signal transmission from network congestion to end-system awareness.

[0053] In some embodiments, before sending messages to the receiving end via multiple paths, the method further includes: Establish multiple path connections with the receiving end; Initialize the congestion control context and set the overloaded path set to empty; Initialize the queue context by setting all status bits in the path bitmap to indicate availability.

[0054] Specifically, during the connection establishment phase, the sender and receiver negotiate to establish multiple paths. Subsequently, the sender initializes its internal state: for the congestion control context, since there is no network feedback information, its overloaded path set is initialized to empty, meaning that no path is currently identified as an overloaded path; for the queue context, all bits of its path bitmap are initialized to indicate availability, meaning that in the initial stage, all paths are considered available paths, and the sender can use all paths evenly for data transmission until overloaded paths are gradually identified and the path bitmap is updated based on network feedback information.

[0055] Example 2 See Figure 3 Embodiment 2 of this application proposes a multi-path load balancing congestion control method, applied at the receiving end, the method comprising: Step S21: Receive messages sent by the sending end through multiple paths; Specifically, the receiving end receives messages from the sending end through the network interface. Each arriving message is transmitted via a specific network path. This path information can be identified through the source port of the message, metadata added by the network device, or the path mapping table of the receiving end. The receiving end performs verification and processing on each received message.

[0056] Step S22: Generate path network status information based on the received message. The path network status information is used to indicate the congestion level of the corresponding path. Specifically, the receiving end performs deep parsing of the packets to extract and generate information reflecting path congestion. First, the receiving end checks the packet sequence number. Due to multi-path transmission, packets on different paths may arrive out of order. The receiving end maintains the expected next sequence number to receive. If a packet with a sequence number greater than the expected value is received, it indicates a sequence number gap, i.e., packet loss has occurred. The receiving end counts the size of the gap to determine the number of lost packets. Second, the receiving end parses the Internet Protocol header of the packet and checks whether the Explicit Congestion Notification field is marked by the network device. If an ECN mark is detected, it is recorded and the number of ECN marks on the path is accumulated. Third, the arrival timestamp of the packet is recorded. This timestamp can be used to calculate round-trip time or assess path delay changes.

[0057] Step S23: Send a response message carrying the path network status information to the sending end, so that the sending end can determine the path congestion level and update the congestion control context and queue context based on the path network status information. The congestion control context includes path identifiers and congestion levels for overloaded paths, where the overloaded paths are a preset number of paths with the highest congestion levels. The queue context includes a path bitmap, which includes multiple status bits corresponding one-to-one with the multiple paths. Each status bit is used to indicate whether the corresponding path is available. When the path is an overloaded path, the corresponding status bit indicates that the path is unavailable. When the path is a non-overloaded path, the corresponding status bit indicates that the path is available.

[0058] Specifically, the receiving end encapsulates the path congestion information generated in step S22 into a response message. The response message can be a dedicated congestion notification message or an extended field embedded in an acknowledgment message (such as ACK or SACK). The response message is returned to the sending end through the corresponding path. After receiving the response message, the sending end parses the path network status information and updates its congestion control context and queue context according to the method flow described in Embodiment 1, thereby realizing an end-to-end congestion control closed loop.

[0059] In some embodiments, the path network status information includes at least one of packet loss information, explicit congestion notification information, or round-trip delay information; Step S22 specifically includes: Step S221: Detect whether there is a gap in the packet sequence number of the received message. If there is a gap, generate a response message carrying packet loss information, including path identifier and number of lost packets. Specifically, the receiving end maintains an ordered receiving buffer and an expected sequence number. When the received message sequence number is greater than the expected sequence number, the difference indicates the number of missing messages (packet loss). The receiving end associates this packet loss event with the path (path identifier) ​​that received the message, and generates a SACK message or a similar packet loss notification message, clearly informing the sending end which path lost how many messages within a preset time period.

[0060] Step S222: Parse the Internet Protocol header of the received message. If an explicit congestion notification flag is detected, generate a response message carrying explicit congestion notification information, including path identifier and number of flags. Specifically, when processing a packet, the receiver checks the ToS or ECN field in the IP header. If an ECN flag (e.g., ECT(1) or CE code point) is found, the receiver considers the packet to have experienced congestion. The receiver can accumulate the number of packets with ECN flags from the same path and periodically or under certain conditions generate a Congestion Notification Message (CNP), which indicates the congested path identifier and the number of flags observed in the past preset time period, and sends the CNP message to the sender.

[0061] Step S223: Record the timestamp of the received message and generate a response message carrying round-trip delay information.

[0062] Specifically, the receiver records the arrival timestamp for each received message. To measure round-trip time (RTT), the sender typically embeds a sending timestamp in the data packet. When generating the corresponding response message, the receiver can calculate the difference between the current timestamp and the sending timestamp in the data packet to obtain the RTT of the message in the network. The receiver then includes this RTT in the option field of the response message (such as ACK) and returns it to the sender. The sender can then obtain the RTT sample of the path in the past preset time period or the latest time period.

[0063] In some embodiments, the method further includes: Step S24: Count the number of paths currently in a congested state based on the messages carrying explicit congestion notification flags; Specifically, the receiving end can independently maintain a network state view. By parsing all received data packets, identifying packets carrying ECN tags, and counting the number of different paths on which these packets are distributed, the number of paths currently in a congested state can be obtained. This number of paths is a dynamic indicator that reflects the scale of congested paths within the network.

[0064] Step S25: Determine the signaling rate based on the number of paths in a congested state and the upper limit of its own receiving capacity, and generate a signaling message based on the signaling rate; Specifically, the receiving end itself has a fixed upper limit to its data processing capacity, such as the throughput of its network card or host (e.g., 400Gbps). The signaling production module inside the receiving end dynamically adjusts the rate at which it generates signaling messages (signaling rate) based on the statistically obtained number of congested paths. For example, the rate adjustment strategy could be: when the network congestion is small (the number of congested paths is below a preset threshold), the signaling rate is maintained at its maximum value, equal to the receiving capacity limit, to fully utilize bandwidth; when the network congestion expands (the number of congested paths exceeds the preset threshold), the signaling rate gradually decreases. The magnitude of the decrease is related to the proportion of congested paths to the total number of paths; the more congested paths, the greater the decrease. In this way, by controlling the signaling rate, the receiving end indirectly regulates the upper limit of the sending window of the sending end, implementing global traffic control from the receiving side.

[0065] Step S26: Send the signaling message to the sending end. The signaling message is used to instruct the sending end to update the sending window in the congestion control context.

[0066] Specifically, the receiving end encapsulates the determined signaling rate value in a signaling message and sends it to the sending end. The signaling message can be a dedicated control message or a reused management message type. After receiving the signaling message, the sending end parses the signaling rate and updates the transmission window parameters in its congestion control context accordingly, thereby adjusting the overall transmission rate to adapt to network congestion conditions and the receiving end's processing capacity.

[0067] In some embodiments, step S25 specifically includes: Step S251: When the number of congested paths is less than a preset threshold, determine the signaling rate based on the upper limit of the receiving capacity; Specifically, such as Figure 4 As shown, the preset threshold (path_threshold) is a configurable parameter used to distinguish between lightly loaded and heavily loaded network states. When the number of congested paths counted by the receiver is less than this path_threshold, the overall network condition is considered good, with only a few paths congested. At this time, the signaling production module sets the signaling rate (rate) to be equal to the receiver's maximum receiving capacity (rate_max), i.e., rate = rate_max, to instruct the sender to transmit according to the receiver's maximum capacity.

[0068] Step S252: When the number of congested paths is greater than or equal to the preset threshold, the signaling rate is determined according to the upper limit of the receiving capacity and the adjustment coefficient, wherein the adjustment coefficient is determined according to the relationship between the number of congested paths and the total number of paths, and the more congested paths there are, the smaller the adjustment coefficient is.

[0069] Specifically, when the number of congested paths reaches or exceeds `path_threshold`, the network is considered to be in a significantly congested state. At this point, the signaling rate needs to be reduced, where the adjustment factor is a value between 0 and 1, and its calculation depends on the relationship between the number of congested paths and the total number of paths. For example, the adjustment factor can be defined as: a = (path_congested - path_threshold) / (path_max - path_congested), and the final signaling rate calculation formula can be expressed as: rate = rate_max (1 - a / 2). As path_congested increases, the value of 'a' increases, and (1 - a / 2) decreases, leading to a decrease in the signaling rate (rate). Here, path_congested represents the number of congested paths, and path_max represents the total number of paths. This adjustment strategy ensures that the more severe the congestion, the lower the upper limit of the suggested transmission rate at the receiver, thereby effectively alleviating network pressure and preventing congestion-induced collapse.

[0070] In this system, packets sent by the sending end are forwarded via network devices. If the output port queue length of the network device exceeds a first preset threshold, the packet is discarded, allowing the receiving end to detect packet loss and generate packet loss information. If the output port queue length of the network device exceeds a second preset threshold but is less than the first preset threshold, the packet is explicitly marked with a congestion notification tag, allowing the receiving end to generate explicit congestion notification information based on the tag. The network device (e.g., a network utility) is a key node on the path that generates congestion signals. The network device maintains a forwarding queue for each output port or path. When packets to be forwarded accumulate in the forwarding queue, the queue length (i.e., the number of packets in the forwarding queue) increases. The network device presets two waterline thresholds: a first preset threshold (packet loss waterline) and a second preset threshold (ECN waterline), where the second preset threshold is less than the first preset threshold. When the queue length exceeds the second preset threshold but is less than the first preset threshold, the network device sets an ECN tag in the IP header of the packet during forwarding to send an early congestion warning to the receiving end. When the queue length continues to grow and exceeds a first preset threshold, the buffer resources are exhausted, and the network device will discard newly arriving packets. The receiving end detects ECN markers and sequence number gaps in packets, generates ECN information and packet loss information respectively, and feeds them back to the sending end through response packets, thus completing the signal transmission from network congestion to end-system awareness.

[0071] Example 3 Embodiment 3 of this application proposes a multi-path load balancing congestion control device, applied at the transmitting end, for executing the method described in Embodiment 1 above. (See also...) Figure 5 The device includes: The first sending processing module 11 is used to send messages to the receiving end through multiple paths; The first receiving and processing module 12 is configured to receive a response message returned by the receiving end and obtain path network status information carried in the response message; wherein the path network status information is used to indicate the congestion level of the corresponding path; and The congestion control module 13 is used to determine the congestion level of the corresponding path based on the path network status information, and update the congestion control context based on the congestion level of the corresponding path; wherein, the congestion control context includes the path identifier and congestion level of the overloaded path, and the overloaded path is a preset number of paths with the highest congestion level. The first sending processing module 11 is further configured to update the queue context according to the path identifier of the overloaded path; wherein, the queue context includes a path bitmap, the path bitmap includes multiple status bits corresponding one-to-one with the multiple paths, each status bit is used to indicate whether the corresponding path is available; when the path is an overloaded path, the corresponding status bit indicates that the path is unavailable; when the path is a non-overloaded path, the corresponding status bit indicates that the path is available. The first sending processing module 11 is further configured to select an available path indicated by the status bit in the path bitmap for message sending based on the updated queue context.

[0072] Specifically, the first sending processing module is responsible for sending data packets. It reads the current token count and path bitmap from the queue context, selects an available path based on the token mechanism and round-robin scheduling strategy, and constructs and sends the packet. The first receiving processing module is responsible for receiving various response packets from the receiving end and parsing out path network status information (such as packet loss information, ECN information, and RTT information) and signaling rates from the signaling packets. The congestion control module is the core control unit of the entire device. It receives path network status information and signaling rates from the first receiving processing module. For path network status information, it performs congestion level calculation, overload path filtering and sorting, and updates the congestion control context. For signaling rates, it updates the sending window in the congestion control context. The congestion control module is also responsible for instructing the first sending processing module to update the path bitmap and token count in the queue context based on the updated congestion control context. These three modules work together to realize a complete closed loop on the sending end side, from sensing network status and making control decisions to executing traffic scheduling.

[0073] It should be noted that the apparatus in Embodiment 3 corresponds to the method described in Embodiment 1 above. Any details not described in the apparatus of Embodiment 3 can be obtained by referring to the method described in Embodiment 1 above. Therefore, no further details will be provided in Embodiment 3.

[0074] Example 4 Embodiment 4 of this application proposes a multi-path load balancing congestion control device, applied at the receiving end, for executing the method described in Embodiment 2 above. (See also...) Figure 6 The device includes: The second receiving and processing module 21 is used to receive messages sent by the sending end through multiple paths, and generate path network status information based on the received messages; wherein, the path network status information is used to indicate the congestion level of the corresponding path. The second sending processing module 22 is used to send a response message carrying the path network status information to the sending end, so that the sending end can determine the path congestion level and update the congestion control context and queue context according to the path network status information. The congestion control context includes path identifiers and congestion levels for overloaded paths, where the overloaded paths are a preset number of paths with the highest congestion levels. The queue context includes a path bitmap, which includes multiple status bits corresponding one-to-one with the multiple paths. Each status bit is used to indicate whether the corresponding path is available. When the path is an overloaded path, the corresponding status bit indicates that the path is unavailable. When the path is a non-overloaded path, the corresponding status bit indicates that the path is available.

[0075] Specifically, the second receiving and processing module 21 is the core of the receiving end for receiving data and processing information. It receives packets from the network and performs operations such as sequence number checking, IP header ECN parsing, and timestamp recording to generate path network status information such as packet loss information, explicit congestion notification information, and round-trip delay information. It can also count the number of paths currently in a congested state based on the detected ECN markers.

[0076] The second sending processing module 22 is responsible for constructing and sending corresponding response messages (such as SACK, CNP, ACK, etc.) based on the path network status information generated by the second receiving processing module 21.

[0077] In addition, the apparatus of this embodiment may also include a signaling generation module, which generates signaling messages according to a preset strategy based on the statistics of the number of congested paths and the upper limit of receiving capacity, and sends them to the sending end.

[0078] The apparatus in this embodiment provides crucial decision-making support for congestion control at the transmitting end through receiving, analyzing, and providing feedback. It should be noted that the apparatus in Embodiment 4 corresponds to the method described in Embodiment 2 above. Details not elaborated in the apparatus of Embodiment 4 can be obtained by referring to the method described in Embodiment 2 above; therefore, they will not be repeated in Embodiment 4.

[0079] Example 5 See Figure 7Embodiment 5 of this application proposes a multi-path load balancing congestion control system, including a transmitter, a network device, and a receiver. The sending end is used to execute the method described in Embodiment 1 above; The receiving end is used to execute the method described in Embodiment 2 above; The network device is configured to forward packets sent by the sending end to the receiving end, and to forward response packets sent by the receiving end to the sending end; wherein, if the output port queue length of the network device is greater than a first preset threshold and less than a second preset threshold, the packet is discarded so that the receiving end detects packet loss and generates packet loss information; if the output port queue length of the network device is greater than or equal to the second preset threshold, the packet is explicitly marked with a congestion notification tag so that the receiving end generates explicit congestion notification information based on the tag.

[0080] Specifically, the control system in this embodiment is a complete end-to-end communication environment. The sending end and the receiving end are the two endpoints of the communication, and they interact using the methods described in Embodiments 1 and 2. Preferably, the sending end and the receiving end can be servers including DPU smart network cards, which have RDMA functionality. Network devices are located on the network path between the sending end and the receiving end and are key infrastructure for implementing multipathing and generating congestion signals. Based on their own queue status, network devices perform ECN marking or packet loss processing on passing packets, thereby explicitly or implicitly notifying the end system of the congestion status within the network. Preferably, network devices can be switches, routers, or other devices. After the receiving end senses these notification signals, it feeds back to the sending end, which then adjusts its congestion control context and queue context based on the feedback, thereby changing the path selection and transmission rate of subsequent packets. The entire system, through the collaboration of the end system and intermediate network devices, forms a reactive and adaptive congestion control and load balancing system, which can effectively avoid and alleviate network congestion while ensuring network utilization.

[0081] Example 6 Embodiment Six of this application proposes a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in Embodiment One above, or implements the steps of the method described in Embodiment Two above.

[0082] Specifically, the computer-readable storage medium can be any medium capable of containing, storing, transmitting, propagating, or transporting a program for use by or in conjunction with an instruction execution system, apparatus, or device. For example, a computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. Specific examples include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, or any suitable combination of the foregoing. When the computer program is loaded onto a computer or other programmable data processing device, it causes the computer or other programmable data processing device to perform a series of operational steps to produce a computer-implemented process, thereby providing instructions executable on the computer or other programmable device for implementing the program. Figure 2-7 The steps of one or more processes and / or blocks that specify the functions in the flowchart and / or block diagram.

[0083] Example 7 Embodiment 7 of this application proposes a computer program product, including computer program instructions, which, when executed by a processor, implement the steps of the method described in Embodiment 1 above, or implement the steps of the method described in Embodiment 2 above.

[0084] Specifically, the computer program product may be embodied as program code used to cause a computer system to perform some or all of the steps of the method described in the embodiments of this application. The computer program product may be one or more computer-readable media on which computer-readable program code is stored. This computer-readable program code may be accessed, retrieved, loaded, and executed by one or more processors. Various components of the computer program product may be implemented according to various programming languages ​​and / or technologies. The program code may be written in any combination of one or more programming languages, including assembly language, C / C++, Perl, Python, etc. The program code may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer.

[0085] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many updates and modifications will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A multi-path load balancing congestion control method, characterized in that, Applied to the sending end, the method includes: Send messages to the receiving end through multiple paths and receive response messages returned by the receiving end; Obtain the path network status information carried in the response message, which is used to indicate the congestion level of the corresponding path; The congestion level of the corresponding path is determined based on the path network status information, and the congestion control context is updated based on the congestion level of the corresponding path; wherein, the congestion control context includes the path identifier and congestion level of the overloaded path, and the overloaded path is a preset number of paths with the highest congestion level. The queue context is updated according to the path identifier of the overloaded path; wherein, the queue context includes a path bitmap, the path bitmap includes multiple status bits corresponding one-to-one with the multiple paths, each status bit is used to indicate whether the corresponding path is available; when the path is an overloaded path, the corresponding status bit indicates that the path is unavailable; when the path is a non-overloaded path, the corresponding status bit indicates that the path is available. Based on the updated queue context, select the available path indicated by the status bit in the path bitmap for message transmission.

2. The method according to claim 1, characterized in that, The path network status information includes at least one of packet loss information, explicit congestion notification information, or round-trip delay information. The packet loss information includes path identifier and number of lost packets; the explicit congestion notification information includes path identifier and number of explicit congestion notification markers; and the round-trip delay information includes path identifier and corresponding round-trip transmission delay.

3. The method according to claim 2, characterized in that, When the path network status information includes at least two of the following: packet loss information, explicit congestion notification information, and round-trip time delay information, determining the congestion level of the corresponding path based on the path network status information specifically includes: The congestion level of a path with packet loss is greater than that of a path with explicit congestion notification flags. Paths with explicit congestion notification flags are more congested than paths with no packet loss and no explicit congestion notification flags. For any two paths with packet loss, the greater the number of packet losses, the greater the congestion of the paths. For any two paths with explicit congestion notification tags, the greater the number of explicit congestion notification tags, the greater the congestion level of the paths. For any two paths with no packet loss and no explicit congestion notification, the greater the round-trip time, the greater the congestion level of the path.

4. The method according to claim 3, characterized in that, The congestion control context also includes a sending window, which controls the upper limit of the number of packets that the sender can send; The method further includes: The receiver receives signaling messages sent by the receiving end, parses the signaling messages to obtain the signaling rate, and updates the sending window according to the signaling rate; wherein the signaling rate is determined by the receiving end based on the number of paths currently in a congested state and the upper limit of the receiving end's receiving capacity.

5. The method according to claim 4, characterized in that, The queue context also includes the number of tokens used to control message transmission; The step of selecting an available path indicated by the status bit in the path bitmap for message transmission based on the updated queue context specifically includes: Before sending a message, check whether the number of tokens in the queue context is greater than zero; If the number of tokens is greater than zero, the path bitmap in the queue context is queried, and a path is selected from the available paths indicated by the status bit based on the round-robin scheduling strategy to send the message. After the message is sent, the number of tokens is decremented by one. If the token count is zero, message transmission is paused, the token count is updated according to the transmission window in the congestion control context, and message transmission resumes after the token count is updated to be greater than zero.

6. The method according to claim 2, characterized in that, The message sent by the sending end is forwarded by the network device; wherein, when the network device forwards the message, if the length of the output port queue of the network device is greater than a first preset threshold, the message is discarded so that the receiving end can detect the packet loss and generate the packet loss information; if the length of the output port queue of the network device is greater than a second preset threshold and less than the first preset threshold, the message is explicitly marked with a congestion notification so that the receiving end can generate the explicit congestion notification information based on the mark.

7. The method according to claim 1, characterized in that, Before sending messages to the receiving end via multiple paths, the method further includes: Establish multiple path connections with the receiving end; Initialize the congestion control context and set the overloaded path set to empty; Initialize the queue context by setting all status bits in the path bitmap to indicate availability.

8. A multi-path load balancing congestion control method, characterized in that, Applied to the receiving end, the method includes: Receive messages sent by the sender through multiple paths; Path network status information is generated based on the received messages, and the path network status information is used to indicate the congestion level of the corresponding path. Send a response message carrying the path network status information to the sending end, so that the sending end can determine the path congestion level and update the congestion control context and queue context based on the path network status information. The congestion control context includes path identifiers and congestion levels for overloaded paths, where the overloaded paths are a preset number of paths with the highest congestion levels. The queue context includes a path bitmap, which includes multiple status bits corresponding one-to-one with the multiple paths. Each status bit is used to indicate whether the corresponding path is available. When the path is an overloaded path, the corresponding status bit indicates that the path is unavailable. When the path is a non-overloaded path, the corresponding status bit indicates that the path is available.

9. The method according to claim 8, characterized in that, The path network status information includes at least one of packet loss information, explicit congestion notification information, or round-trip delay information. The step of generating path network status information based on the received message specifically includes: The system detects whether there is a gap in the sequence number of the received message. If there is a gap, it generates a response message carrying packet loss information, including the path identifier and the number of lost packets. The Internet Protocol header of the received message is parsed. If an explicit congestion notification flag is detected, a response message carrying explicit congestion notification information is generated. The explicit congestion notification information includes the path identifier and the number of flags. Record the timestamp of the received message and generate a response message carrying round-trip delay information.

10. The method according to claim 8, characterized in that, The method further includes: The number of paths currently in a congested state is counted based on messages carrying explicit congestion notification flags. The signaling rate is determined based on the number of paths in a congested state and the upper limit of its own receiving capacity, and a signaling message is generated based on the signaling rate. The signaling message is sent to the sending end, and the signaling message is used to instruct the sending end to update the sending window in the congestion control context.

11. The method according to claim 10, characterized in that, The signaling rate is determined based on the number of congested paths and the upper limit of its own receiving capacity, and a signaling message is generated based on the signaling rate, specifically including: When the number of congested paths is less than a preset threshold, the signaling rate is determined based on the upper limit of the receiving capacity; When the number of congested paths is greater than or equal to a preset threshold, the signaling rate is determined based on the upper limit of the receiving capacity and an adjustment coefficient. The adjustment coefficient is determined based on the relationship between the number of congested paths and the total number of paths. The more congested paths there are, the smaller the adjustment coefficient becomes.

12. A multi-path load balancing congestion control device, characterized in that, Applied to a transmitting end for performing the method as described in any one of claims 1 to 7, the apparatus comprises: The first sending processing module is used to send messages to the receiving end through multiple paths; The second receiving and processing module is configured to receive the response message returned by the receiving end and obtain the path network status information carried in the response message; wherein the path network status information is used to indicate the congestion level of the corresponding path; and A congestion control module is used to determine the congestion level of a corresponding path based on the path network status information, and update the congestion control context based on the congestion level of the corresponding path; wherein, the congestion control context includes the path identifier and congestion level of the overloaded path, and the overloaded path is a preset number of paths with the highest congestion level. The first sending processing module is further configured to update the queue context according to the path identifier of the overloaded path; wherein, the queue context includes a path bitmap, the path bitmap includes multiple status bits corresponding one-to-one with the multiple paths, each status bit is used to indicate whether the corresponding path is available; when the path is an overloaded path, the corresponding status bit indicates that the path is unavailable; when the path is a non-overloaded path, the corresponding status bit indicates that the path is available. The first sending processing module is further configured to select an available path indicated by a status bit in the path bitmap for message sending based on the updated queue context.

13. A multi-path load balancing congestion control device, characterized in that, Applied at a receiving end for performing the method as described in any one of claims 8 to 11, the apparatus comprises: The second receiving and processing module is used to receive messages sent by the sending end through multiple paths, and generate path network status information based on the received messages; wherein, the path network status information is used to indicate the congestion level of the corresponding path. The second sending processing module is used to send a response message carrying the path network status information to the sending end, so that the sending end can determine the path congestion level and update the congestion control context and queue context according to the path network status information. The congestion control context includes path identifiers and congestion levels for overloaded paths, where the overloaded paths are a preset number of paths with the highest congestion levels. The queue context includes a path bitmap, which includes multiple status bits corresponding one-to-one with the multiple paths. Each status bit is used to indicate whether the corresponding path is available. When the path is an overloaded path, the corresponding status bit indicates that the path is unavailable. When the path is a non-overloaded path, the corresponding status bit indicates that the path is available.

14. A multi-path load balancing congestion control system, characterized in that, Includes the sending end, network equipment, and receiving end; The transmitting end is used to perform the method as described in any one of claims 1 to 7; The receiving end is used to perform the method as described in any one of claims 8 to 11; The network device is configured to forward packets sent by the sending end to the receiving end, and to forward response packets sent by the receiving end to the sending end; wherein, if the output port queue length of the network device is greater than a first preset threshold and less than a second preset threshold, the packet is discarded so that the receiving end detects packet loss and generates packet loss information; if the output port queue length of the network device is greater than or equal to the second preset threshold, the packet is explicitly marked with a congestion notification tag so that the receiving end generates explicit congestion notification information based on the tag.

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

16. A computer program product comprising computer program instructions, characterized in that, When the program instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 7, or the steps of the method as described in any one of claims 8 to 11.

Images