Congestion control method and apparatus, device, storage medium, and program product

Abstract

A congestion control method and apparatus, a device, a storage medium, and a program product. The method comprises: acquiring a response delay corresponding to a terminal device, wherein the response delay is a duration between an update moment of a pointer to be acknowledged and the current moment, and said pointer refers to the sequence number of a first byte that has been sent by the terminal device but for which an acknowledgment message has not yet been received; acquiring a path delay of each virtual link among a plurality of virtual links corresponding to the terminal device, wherein the path delay is determined on the basis of transmission round-trip durations corresponding to a plurality of data packets on the virtual link; and adjusting a congestion window of the terminal device on the basis of the response delay, and on the basis of the path delay of each virtual link, performing load balancing processing on a plurality of physical links corresponding to the plurality of virtual links, wherein the congestion window is used for indicating the maximum data volume the terminal device may consecutively send. The congestion control method can reduce network congestion and improve the load balancing effect of physical links.

Description

Congestion control methods, apparatus, equipment, storage media and program products

[0001] This disclosure claims priority to Chinese Patent Application No. 202411030351.7, filed on July 29, 2024, entitled “Congestion Control Method, Apparatus, Device, Storage Medium and Program Product”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of communication technology, and in particular to a congestion control method, apparatus, device, storage medium, and program product. Background Technology

[0003] When a terminal device communicates with a destination device, the terminal device can continuously send multiple data packets to the destination device.

[0004] Multiple physical links can exist between a terminal device and a destination device. When a terminal device sends a data packet to a destination device, it can select one of these physical links to transmit the data packet.

[0005] When the speed of data packet transmission slows down, it is usually due to network congestion. Currently, there is a lack of congestion control methods that can effectively solve network congestion.

[0006] Summary of the Invention

[0007] This disclosure provides a congestion control method, apparatus, device, storage medium, and program product for solving network congestion problems.

[0008] In a first aspect, embodiments of this disclosure provide a congestion control method, including:

[0009] Obtain the response delay corresponding to the terminal device. The response delay is the duration between the update time of the pending confirmation pointer and the current time. The pending confirmation pointer points to the sequence number of the first byte that the terminal device has sent but has not yet received an confirmation message.

[0010] The path delay of each virtual link in the multiple virtual links corresponding to the terminal device is obtained. The path delay is determined based on the round-trip time of multiple data packets on the virtual link.

[0011] The congestion window of the terminal device is adjusted according to the response delay, and the load balancing of the multiple physical links corresponding to the multiple virtual links is performed according to the path delay of each virtual link. The congestion window is used to indicate the maximum amount of data that the terminal device can continuously send.

[0012] In one possible implementation, load balancing is performed on the multiple physical links corresponding to the multiple virtual links based on the path delay of each virtual link, including:

[0013] Based on the path delay of each virtual link, a path delay statistical value is determined, which is used to characterize the degree of difference in path delay among the virtual links;

[0014] If the path delay statistics value is greater than the first path delay threshold or less than the second path delay threshold, then a target virtual link is determined among the multiple virtual links. The path delay of the target virtual link is greater than a preset duration, and the first path delay threshold is greater than the second path delay threshold.

[0015] Update the path value of the target virtual link to switch the target virtual link from the original physical link to the new physical link, until the load balancing of the multiple physical links is achieved.

[0016] In one possible implementation, updating the path value of the target virtual link includes:

[0017] Generate target path value;

[0018] Determine whether the usage status of the target path value is unused;

[0019] When it is determined that the usage status of the target path value is unused, the path value corresponding to the target virtual link is updated to the target path value.

[0020] In one possible implementation, the terminal device includes a path value bitmap, which comprises multiple bits; determining whether the usage status of the target path value is unused includes:

[0021] In the path value bitmap, the target bit corresponding to the target path value is determined;

[0022] If the target bit is the first value, then the usage status of the target path value is determined to be unused.

[0023] If the target bit is the second value, then the usage status of the target path value is determined to be in the used state.

[0024] In one possible implementation, for any virtual link, obtaining the path delay of the virtual link includes:

[0025] Identify the multiple data packets corresponding to the virtual link within the detection period;

[0026] For any given data packet, determine the round-trip time corresponding to that data packet;

[0027] The path delay of the virtual link within the detection period is determined based on the round-trip time of each data packet in the plurality of data packets.

[0028] In one possible implementation, determining the path delay of the virtual link within the detection period based on the round-trip time of each of the plurality of data packets includes:

[0029] The current data packet is identified from the plurality of data packets, and the current round-trip time corresponding to the current data packet is determined.

[0030] The historical path delay corresponding to the virtual link is determined based on the round-trip time of the transmission of the historical data packets preceding the current data packet in the plurality of data packets;

[0031] Determine the first product of the current round-trip time and the first weight, and the second product of the historical path delay and the second weight;

[0032] The sum of the first product and the second product is determined as the path delay of the virtual link.

[0033] In one possible implementation, determining the round-trip time corresponding to any given data packet includes:

[0034] Receive the response message corresponding to the data packet, and determine the response reception time of receiving the response message, wherein the response message includes the data packet sending time, the data packet receiving time, and the response sending time;

[0035] The round-trip time corresponding to the data packet is determined based on the response reception time and the data packet transmission time.

[0036] The processing time corresponding to the data packet is determined based on the response sending time and the data packet receiving time;

[0037] The difference between the round-trip time and the processing time is determined as the transmission round-trip time.

[0038] In one possible implementation, adjusting the congestion window of the terminal device based on the response delay includes:

[0039] Determine the congestion control algorithm;

[0040] If the response delay is greater than the response delay threshold, then according to the congestion control algorithm, the congestion window is reduced to obtain the adjusted congestion window;

[0041] If the response delay is less than or equal to the response delay threshold, then according to the congestion control algorithm, the congestion window is increased to obtain an adjusted congestion window.

[0042] In one possible implementation, after adjusting the congestion window of the terminal device based on the response delay, the method further includes:

[0043] Obtain the resource utilization rate of the target device, and determine the congestion reference window based on the resource utilization rate;

[0044] If the adjusted congestion window is less than or equal to the congestion reference window, then the adjusted congestion window is determined as the target congestion window;

[0045] If the adjusted congestion window is larger than the congestion reference window, then the congestion reference window is determined as the target congestion window.

[0046] Secondly, embodiments of this disclosure provide a congestion control device, which includes: a first acquisition module, a second acquisition module, an adjustment module, and a leveling processing module, wherein...

[0047] The first acquisition module is used to acquire the response delay corresponding to the terminal device, wherein the response delay is the duration between the update time of the pending confirmation pointer and the current time, and the pending confirmation pointer points to the sequence number of the first byte that the terminal device has sent but has not yet received an confirmation message.

[0048] The second acquisition module is used to acquire the path delay of each virtual link in the multiple virtual links corresponding to the terminal device. The path delay is determined based on the round-trip transmission time of multiple data packets on the virtual link.

[0049] The adjustment module is used to adjust the congestion window of the terminal device according to the response delay.

[0050] The load balancing module is used to perform load balancing on multiple physical links corresponding to the multiple virtual links based on the path delay of each virtual link, and the congestion window is used to indicate the maximum amount of data that the terminal device can continuously send.

[0051] In one possible implementation, the equalization processing module is specifically used for:

[0052] Based on the path delay of each virtual link, a path delay statistical value is determined, which is used to characterize the degree of difference in path delay among the virtual links;

[0053] If the path delay statistics value is greater than the first path delay threshold or less than the second path delay threshold, then a target virtual link is determined among the multiple virtual links. The path delay of the target virtual link is greater than a preset duration, and the first path delay threshold is greater than the second path delay threshold.

[0054] Update the path value of the target virtual link to switch the target virtual link from the original physical link to the new physical link, until the load balancing of the multiple physical links is achieved.

[0055] In one possible implementation, the equalization processing module is specifically used for:

[0056] Generate target path value;

[0057] Determine whether the usage status of the target path value is unused;

[0058] When it is determined that the usage status of the target path value is unused, the path value corresponding to the target virtual link is updated to the target path value.

[0059] In one possible implementation, the terminal device includes a path value bitmap, which comprises multiple bits; the equalization processing module is specifically used for:

[0060] In the path value bitmap, the target bit corresponding to the target path value is determined;

[0061] If the target bit is the first value, then the usage status of the target path value is determined to be unused.

[0062] If the target bit is the second value, then the usage status of the target path value is determined to be in the used state.

[0063] In one possible implementation, for any virtual link, the second acquisition module is specifically used for:

[0064] Identify the multiple data packets corresponding to the virtual link within the detection period;

[0065] For any given data packet, determine the round-trip time corresponding to that data packet;

[0066] The path delay of the virtual link within the detection period is determined based on the round-trip time of each data packet in the plurality of data packets.

[0067] In one possible implementation, the second acquisition module is specifically used for:

[0068] The current data packet is identified from the plurality of data packets, and the current round-trip time corresponding to the current data packet is determined.

[0069] The historical path delay corresponding to the virtual link is determined based on the round-trip time of the transmission of the historical data packets preceding the current data packet in the plurality of data packets;

[0070] Determine the first product of the current round-trip time and the first weight, and the second product of the historical path delay and the second weight;

[0071] The sum of the first product and the second product is determined as the path delay of the virtual link.

[0072] In one possible implementation, for any given data packet, the second acquisition module is specifically used for:

[0073] Receive the response message corresponding to the data packet, and determine the response reception time of receiving the response message, wherein the response message includes the data packet sending time, the data packet receiving time, and the response sending time;

[0074] The round-trip time corresponding to the data packet is determined based on the response reception time and the data packet transmission time.

[0075] The processing time corresponding to the data packet is determined based on the response sending time and the data packet receiving time;

[0076] The difference between the round-trip time and the processing time is determined as the transmission round-trip time.

[0077] In one possible implementation, the adjustment module is specifically used for:

[0078] Determine the congestion control algorithm;

[0079] If the response delay is greater than the response delay threshold, then according to the congestion control algorithm, the congestion window is reduced to obtain the adjusted congestion window;

[0080] If the response delay is less than or equal to the response delay threshold, then according to the congestion control algorithm, the congestion window is increased to obtain an adjusted congestion window.

[0081] In one possible implementation, after adjusting the congestion window of the terminal device based on the response delay, the congestion control device further includes: a third acquisition module, a first determination module, and a second determination module, wherein...

[0082] The third acquisition module is used to acquire the resource utilization rate of the target device;

[0083] The first determining module is used to determine a congestion reference window based on the resource utilization rate;

[0084] The second determining module is used to determine the adjusted congestion window as the target congestion window if the adjusted congestion window is less than or equal to the congestion reference window.

[0085] The second determining module is used to determine the congestion reference window as the target congestion window if the adjusted congestion window is larger than the congestion reference window.

[0086] Thirdly, embodiments of this disclosure provide an electronic device, including: a memory and a processor;

[0087] The memory stores computer-executed instructions;

[0088] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects.

[0089] Fourthly, embodiments of this disclosure provide a congestion control system, comprising: at least one terminal device, at least one network device, and at least one destination device, wherein,

[0090] The terminal device has a communication connection with some or all of the at least one network device;

[0091] The target device has a communication connection with some or all of the at least one network device;

[0092] The terminal device is used to perform the method described in any of the first aspects.

[0093] Fifthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method described in any of the first aspects.

[0094] In a sixth aspect, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method shown in any of the first aspects.

[0095] This disclosure provides a congestion control method, apparatus, device, storage medium, and program product. A terminal device can obtain the response latency corresponding to the terminal device and the path latency of each virtual link among multiple virtual links corresponding to the terminal device. It can then adjust the congestion window of the terminal device based on the response latency and perform load balancing processing on multiple physical links corresponding to multiple virtual links based on the path latency of each virtual link. Through the congestion control method of this disclosure, network congestion can be reduced, the load balancing effect and overall utilization of physical links can be improved, and a healthy network state with low latency and high utilization can be achieved. Attached Figure Description

[0096] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0097] Figure 1 is a schematic diagram of an application scenario provided by an exemplary embodiment of this disclosure;

[0098] Figure 2 is a schematic diagram of a network topology provided by an exemplary embodiment of the present disclosure;

[0099] Figure 3 is a schematic diagram of a virtual link provided by an exemplary embodiment of this disclosure;

[0100] Figure 4 is a flowchart illustrating a congestion control method provided in an exemplary embodiment of this disclosure;

[0101] Figure 5 is a schematic diagram of the pointer to be confirmed provided in an exemplary embodiment of this disclosure;

[0102] Figure 6 is a flowchart illustrating another congestion control method provided by an exemplary embodiment of this disclosure;

[0103] Figure 7 is a flowchart illustrating another congestion control method provided by an exemplary embodiment of this disclosure;

[0104] Figure 8 is a schematic diagram of the data packet transmission time, data packet reception time, response transmission time, and response reception time provided in an exemplary embodiment of this disclosure;

[0105] Figure 9 is a schematic diagram of a path value bitmap provided in an exemplary embodiment of this disclosure;

[0106] Figure 10 is a schematic diagram of a data packet transmission order provided by an exemplary embodiment of the present disclosure;

[0107] Figure 11 is a schematic diagram of the structure of a congestion control device provided in an embodiment of this disclosure;

[0108] Figure 12 is a schematic diagram of another congestion control device provided in an exemplary embodiment of the present disclosure;

[0109] Figure 13 is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of the present disclosure;

[0110] Figure 14 is a schematic diagram of the structure of a congestion control system provided by an exemplary embodiment of the present disclosure. Detailed Implementation

[0111] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use, and processing of relevant data need to comply with relevant laws, regulations, and standards, and corresponding operation entrances are provided for users to choose to authorize or reject.

[0112] To make the purpose, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments of this disclosure and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, rather than all of the embodiments. Based on the embodiments in this disclosure, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of this disclosure.

[0113] Next, for the convenience of understanding the technical solutions of this disclosure, the concepts involved in this disclosure will be explained first.

[0114] 1. Physical link: It refers to an actually existing communication link, such as the physical connection between switch ports or between a switch and a network card.

[0115] 2. Virtual link: An abstract expression concept in this article, whose behavior can be switched among different physical links.

[0116] 3. Round-Trip Time (RTT): The time elapsed from when the sender starts sending data to when the sender receives the confirmation message from the receiver.

[0117] 4. Networking Round-Trip Time (NRTT): In the round-trip time corresponding to a data packet, the time consumed during transmission in the network, excluding the time consumption at the receiver. This metric is proposed to measure the load balancing degree in the network.

[0118] 5. Equal-Cost Multiple Path (ECMP): There are multiple equivalent different physical links to reach the same destination IP or destination network segment.

[0119] 6. Inflight: It refers to the number of data packets being transmitted in a physical link. For example, if device A sends N packets to device B and device B receives M packets (M < N) at time 1, then the inflight is N - M. Here, both N and M are integers greater than or equal to 1.

[0120] 7. Bandwidth Delay Product (BDP): This refers to the maximum inflight that a physical link can accommodate under maximum bandwidth.

[0121] 8. Access Switch (ASW): As the access layer in a classic Layer 3 network, it connects to compute nodes. In Internet Data Centers (IDCs), it is typically placed at the top of several racks, hence it is also called a Top Of Rank (ToR) switch.

[0122] 9. Point-of-Delivery Switch (PSW): Serves as the aggregation layer in a classic Layer 3 network. It receives data packets from one access switch and forwards them to another access switch, or forwards them upwards to a Distribution Switch (DSW).

[0123] 10. Switch (SW): A switch is a network forwarding unit that plays a role in data forwarding in a network.

[0124] 11. Acknowledge (ACK): In data communication, it is a message sent by the receiving end to the sending end to indicate that the data sent by the sending end has been acknowledged to be received without error.

[0125] 12. Selective Acknowledgment (SACK): Used to acknowledge received segments and notify the sender of the received segments. The sender uses these received acknowledgments to determine which segments were lost, allowing the sender to retransmit only the lost segments, thus improving recovery capability and transmission efficiency.

[0126] To facilitate understanding of this solution, we will first explain the application scenario in conjunction with Figure 1.

[0127] Figure 1 is a schematic diagram of an application scenario provided by an exemplary embodiment of this disclosure. Referring to Figure 1, it includes multiple terminal devices, multiple destination devices, and multiple network devices. The multiple network devices include multiple ASWs and multiple PSWs.

[0128] Assuming terminal device 2 communicates with destination device 1, multiple physical links exist between them due to the presence of multiple Access Switches (ASWs) and Power Switches (PSWs). Data packets sent from terminal device 2 to destination device 1 are transmitted through network devices (i.e., ASWs and PSWs). When multiple physical links are available at the packet forwarding exit, the network devices select a suitable physical link using methods such as ECMP.

[0129] In this network, in addition to communication between terminal device 2 and destination device 1, other terminal devices also communicate with other destination devices. For example, in artificial intelligence (AI) scenarios, there are aggregated communications with large bandwidth traffic. Since the available physical ports of any network device are limited, when data packets are transmitted through network devices, hashing the data packets may result in a large number of data packets being allocated to the same physical link. This leads to packet congestion on local egress links, slowing down transmission speed, and low overall utilization of available physical links, thus reducing the overall performance of the application and creating a bottleneck effect.

[0130] When network devices encounter hash collisions, a queuing phenomenon occurs. Currently, the prevailing view in the industry (industry and academia) defines this phenomenon as network congestion. There are various methods for handling network congestion, commonly including retransmission compensation after packet loss, and controlling the RTT (Round-Trip Time) waterline to keep link queuing at a relatively low level, preventing different applications from waiting for each other due to long queues; the latter is also frequently used for network congestion management in data centers. However, the industry has overlooked one problem: the overall link utilization is low, which negatively impacts application performance.

[0131] To address the aforementioned technical problems, the inventors discovered that network congestion is caused by queuing at the exit points of terminal devices or network devices. If multiple physical links at the exit points can distribute traffic, the congestion problem can be greatly alleviated, or even resolved. For example, device A has two physical ports and communicates with device B (also with two physical ports) via ASW and PSW. If the PSW forwards traffic to the ASW exit point connected to device B, selecting only one link, it will reduce performance to that of a single physical port – a clear example of congestion. However, if the PSW forwards traffic to the ASW exit point connected to device B, selecting both physical links evenly, then it's two physical ports communicating with each other, eliminating network congestion. This results in a load-balanced network. Therefore, evenly selecting two physical links promotes load balancing, greatly aiding in network congestion management and improving overall performance. Even in congested situations, if a method can balance traffic pressure among available forwarding exit points, it can not only solve the congestion problem but also improve overall performance. From the perspective of existing industry technology, the phenomenon of low link utilization caused by load imbalance has not been effectively detected. This has put us in a dilemma: whether to switch routes or reduce window size.

[0132] The aforementioned dilemma essentially stems from a lack of clear definition of the load balancing problem and a failure to clearly identify the characteristics that arise when a load balancing problem occurs. This dilemma can be broken down into two separate problems and addressed accordingly:

[0133] Question 1: The terminal device is sending too many data packets continuously, causing network congestion. This is an overall network congestion, and the congestion window of the terminal device should be adjusted.

[0134] Question 2: The network congestion caused by too many data packets being transmitted on the physical link is actually a problem of unbalanced load on the physical link. Load balancing should be implemented on the physical link.

[0135] Therefore, this disclosure provides a congestion control method. In this disclosure, network traffic engineering problems are addressed from two dimensions. For problem 1, the response latency of the terminal device can be determined, and the congestion window of the terminal device can be adjusted based on the response latency. For problem 2, this disclosure abstracts multiple virtual links, which are carried on top of each available physical link in the network. The terminal device obtains the path latency of each virtual link among the multiple virtual links corresponding to the terminal device. By statistically comparing the path latency of each virtual link, the terminal device can effectively detect the load balancing status of each virtual link in the network, and thus detect the load balancing status of each physical link. The virtual links in this disclosure have the ability to switch to real physical links; therefore, when an unbalanced load balancing status is detected, load balancing processing can be performed on multiple physical links based on the path latency of each virtual link. The congestion control method disclosed herein can reduce network congestion, improve the load balancing effect and overall utilization of physical links, and, when combined with existing auxiliary strategies such as packet loss detection and equal-weighted link scheduling, converge the transmission quality to a healthy network state of "low latency and high utilization".

[0136] The principle of this technical solution will be explained below with reference to Figures 2 and 3.

[0137] Figure 2 is a schematic diagram of a network topology provided by an exemplary embodiment of this disclosure. Referring to Figure 2, multiple Switches (SWs) (including multiple Assigned Switches and multiple PSWs) exist between the terminal device and the destination device. These multiple SWs can constitute the network topology. There can be three physical links between the terminal device and the destination device. In this solution, the details of the network topology are not important, and the user is unaware of the network topology.

[0138] When the network topology is viewed as a black box network and the actual network topology details are not considered, multiple virtual links can be abstracted between the terminal device and the destination device, as shown in Figure 3.

[0139] Figure 3 is a schematic diagram of virtual links provided by an exemplary embodiment of this disclosure. Referring to the example in Figure 3, the terminal device corresponds to 64 virtual links, namely virtual link 0, virtual link 1, virtual link 2, ..., virtual link 63. This solution is not actually limited to 64 virtual links; the specific number of virtual links can be determined based on the physical link bandwidth and bandwidth jitter during routing.

[0140] Multiple data packets sent from a terminal device to a destination device can form a data flow. This flow can be transmitted to the destination device via these 64 virtual links and through a black-box network.

[0141] When the network topology is viewed as a black box network, without paying attention to the actual details of the network topology, it is unnecessary to know how many physical links exist in the black box network. Therefore, it is also impossible to know how many physical links these 64 virtual links actually correspond to, or which virtual links each physical link corresponds to.

[0142] For example, assuming there are 3 physical links in a black-box network as shown in Figure 2, then the 64 virtual links can be mapped to these 3 physical links. Assume physical link 1 can correspond to 20 virtual links, meaning that data packets on these 20 virtual links are actually transmitted through physical link 1; physical link 2 can correspond to 22 virtual links, and physical link 3 can also correspond to another 22 virtual links.

[0143] In this technical solution, the path delay corresponding to each virtual link can be determined, and a path delay statistical value can be determined based on the path delay corresponding to each virtual link. The path delay statistical value can be used to characterize the degree of difference in path delay among virtual links. When the path delay statistical value is greater than a first path delay threshold or less than a second path delay threshold (the first path delay threshold is greater than the second path delay threshold), it is considered that the virtual link load is unbalanced, which is essentially an imbalance in the physical link load. In this case, virtual links with path delays greater than a preset duration can be switched to new physical links until the recalculated path delay statistical value is within [the second path delay threshold and the first path delay threshold]. At this point, it indicates that each virtual link has achieved the expected load balancing effect, that is, the load of each physical link has been balanced.

[0144] The data packets in this disclosure will now be described.

[0145] For any given data packet, the packet can include a path value. Network devices can select different virtual links based on this path value. In this implementation, when a data packet arrives at the Packet Deliver Sublayer (PDS), there are two options:

[0146] Option 1: Terminal devices can add overlay encapsulation to data packets through PDS, and the path value can be directly specified to the source port of the outer layer of the data packet, or participate in the hash calculation of the outer port; network devices do not need any modification and can directly use the outer 5-tuple to perform hash calculation for ECMP exit selection.

[0147] Option 2: Without overlay encapsulation, the terminal device can embed the path value into the Internet Protocol (IP) header or define special fields through PDS. After a small amount of adaptation work, the network device's hash algorithm obtains the required input parameters based on a specific offset to participate in ECMP routing selection.

[0148] Some fields included in the data packet can be shown in Table 1:

[0149] Table 1

[0150] It should be noted that the fields "Path Identifier", "Path Value", and "Data Packet Sending Time" in the data packet have corresponding actual values, while the fields "Receiver Buffer Utilization", "Data Packet Receiving Time", "Response Sending Time", and "Response Receiving Time" can have empty values.

[0151] The technical solutions disclosed herein will now be described in detail through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other; identical or similar content will not be repeated in different embodiments.

[0152] The execution entity of this disclosure can be a terminal device or a congestion control device installed in the terminal device. The congestion control device can be implemented in software or a combination of software and hardware. The congestion control device can be a processor in the terminal device. For ease of understanding, the following description uses a terminal device as the execution entity.

[0153] Figure 4 is a flowchart illustrating a congestion control method provided by an exemplary embodiment of this disclosure. Referring to Figure 4, the method may include:

[0154] S401. Obtain the response latency corresponding to the terminal device.

[0155] The response latency can be the duration between the update time of the pending acknowledgment pointer in the terminal device and the current time. The pending acknowledgment pointer points to the sequence number of the first byte that the terminal device has sent but has not yet received an acknowledgment message for. For example, the pending acknowledgment pointer can be a "snd_una" pointer. Optionally, the acknowledgment message can be an ACK acknowledgment message or a SACK acknowledgment message.

[0156] The following explanation of the confirmation pointer, with reference to Figure 5, will now be provided.

[0157] Figure 5 is a schematic diagram of the unconfirmed pointer provided in an exemplary embodiment of this disclosure. Referring to Figure 5, the terminal device can send 100 bytes of data. Each byte has a corresponding sequence number. The sequence numbers corresponding to the 100 bytes can be 0, 1, 2, ..., 31, ..., 99.

[0158] Terminal devices may have a congestion window, which is used to control the amount of data sent. Bytes 0 to 31 represent data that the terminal device has sent and received ACK confirmation messages for; bytes 32 to 41 represent data that the terminal device has sent but has not yet received ACK confirmation messages for; bytes 42 to 49 represent data that is allowed to be sent but has not yet been sent; bytes 50 to 99 represent data that is temporarily not allowed to be sent due to the congestion window constraint.

[0159] The pending confirmation pointer points to the first byte that has been sent but for which an ACK confirmation message has not yet been received. In Figure 5, the pending confirmation pointer points to byte 32.

[0160] If an ACK confirmation message is received for bytes 32 to 40, then byte 41 will become the first byte that has been sent but has not yet received an ACK confirmation message. The pending confirmation pointer will then be updated so that it points to byte 41.

[0161] Therefore, the response latency can be represented by the time between the update time of the pending confirmation pointer and the current time. When the pending confirmation pointer has not been updated for a long time, it indicates that the response latency is relatively large.

[0162] When the response latency exceeds a threshold, it indicates network congestion. Response latency provides an overall picture of network congestion; a longer response latency indicates more severe congestion.

[0163] Optionally, the terminal device can obtain the response latency. For example, the terminal device can obtain a response latency of 100 µs (microseconds).

[0164] S402. Obtain the path delay of each virtual link in the multiple virtual links corresponding to the terminal device.

[0165] The number N of virtual links can be determined based on the network bandwidth of the terminal devices. N is an integer greater than or equal to 2. The larger N is, the less network bandwidth each virtual link occupies.

[0166] For example, if the total network bandwidth of the terminal device is 200Gbps, and N is 64, then each virtual link occupies 200Gbps / 64 = 3.125Gbps of network bandwidth.

[0167] For any given virtual link, there is a corresponding identifier (Path-ID) and path value (Path-seed). Any data packet transmitted over this virtual link includes both the Path-ID and the Path-seed.

[0168] Path-ID is used to identify virtual links. For example, if there are 64 virtual links, the ID value can range from 0 to 63, that is, Path-ID can be Path-0, Path-1, Path-2, ..., Path-63.

[0169] Path-seed is a random number used by network devices in a black-box network to hash data packets. For example, the value of Path-seed can be in the range of [0, 255].

[0170] For any virtual link, the path delay can be determined based on the round-trip time of multiple data packets on the virtual link.

[0171] For example, if there are 64 virtual links, assuming the path delay of the terminal device to obtain each of these 64 virtual links is as shown in Table 2:

[0172] Table 2

[0173] S403, adjust the congestion window of the terminal device according to the response delay, and perform load balancing on multiple physical links corresponding to multiple virtual links according to the path delay of each virtual link.

[0174] A congestion window can be used to indicate the maximum amount of data a terminal device can send. Optionally, the size of the congestion window can be represented by the amount of data or by the number of data packets.

[0175] When adjusting the congestion window based on response delay, the congestion window can be adjusted using a congestion control algorithm.

[0176] For example, congestion control algorithms can be RTT-based or window-based congestion control algorithms.

[0177] If the response delay is greater than the response delay threshold, it indicates that network congestion has occurred. In this case, the congestion window can be reduced according to the congestion control algorithm to reduce the amount of data that the terminal device can continuously send, thereby reducing network congestion.

[0178] If the response delay is less than or equal to the response delay threshold, it indicates that the network is in good condition. The congestion window can be increased according to the congestion control algorithm to increase the amount of data that the terminal device can continuously send, thereby improving the sending efficiency.

[0179] The response delay can reflect the overall network congestion situation. Based on the response delay, the congestion window can be adjusted through congestion control algorithms to reduce network congestion and solve the above-mentioned problem 1.

[0180] For example, if the response latency is 100µs and the response latency threshold is 80µs, and the congestion window size is 90 bytes, then since the response latency is greater than the response latency threshold, the congestion window can be reduced according to the congestion control algorithm. Let's assume the reduced congestion window size is 70 bytes.

[0181] As shown in the embodiment of Figure 3, multiple virtual links can correspond to multiple physical links, and data packets on virtual links are actually randomly assigned to physical links for transmission. When the physical link load is unbalanced, it will lead to large differences in path latency among the virtual links; in other words, when the path latency differences among the virtual links are large, it indicates that the physical link load is unbalanced. Therefore, load balancing can be performed on the multiple physical links corresponding to multiple virtual links based on the path latency of each virtual link.

[0182] Optionally, load balancing of multiple physical links corresponding to multiple virtual links can be performed based on the path latency of each virtual link as follows: determine the path latency statistics based on the path latency of each virtual link; if the path latency statistics are greater than a first path latency threshold or less than a second path latency threshold, then determine the target virtual link among the multiple virtual links, update the path value of the target virtual link, and switch the target virtual link from the original physical link to the new physical link, until the load of multiple physical links is balanced.

[0183] Path delay statistics can be used to characterize the degree of difference in path delay among virtual links. For example, path delay statistics can be standard deviation, variance, deviation, or the difference between the maximum and minimum values.

[0184] The first and second path delay thresholds can be preset manually. The first path delay threshold can be greater than the second path delay threshold. For example, if the path delay statistics are deviations, the first path delay threshold can be 60µs, and the second path delay threshold can be 2µs; the same applies when the path delay statistics are variances or standard deviations.

[0185] Since path delay statistics are used to characterize the degree of difference in path delay among virtual links, if the path delay statistics are greater than the first path delay threshold, it indicates that the path delay of each virtual link is very different, which in turn indicates that the load of each virtual link is unbalanced, that is, the load of the physical link corresponding to each virtual link is unbalanced (for example, physical link 1 may correspond to 40 virtual links, and physical link 2 may correspond to 24 virtual links). Therefore, the target virtual link can be determined among multiple virtual links.

[0186] In real-world scenarios, an extreme case may exist where all virtual links are assigned to the same physical link. In this situation, the path latency of each virtual link may be high, but the difference may be small (e.g., the path latency of each virtual link is 30µs, resulting in a calculated path latency statistical value of 0). Therefore, the calculated path latency statistical value may be less than the second path latency threshold. In this case, the load on the multiple physical links corresponding to the multiple virtual links is also unbalanced. Similarly, the target virtual link can be determined from among the multiple virtual links.

[0187] In one optional embodiment, the path latency of the target virtual link can be greater than a preset duration. For example, the preset duration can be 100µs.

[0188] For example, if there are 64 virtual links, and assuming the path delay of each virtual link is as shown in Table 2, if the path delay statistics are the standard deviation, and assuming the path delay statistics can be determined to be 112 based on the path delay of each virtual link, and if the first path delay threshold is 60, since the path delay statistics are greater than the first path delay threshold, the target virtual link can be determined from multiple virtual links. If the preset duration is 100µs, then as shown in Table 2, virtual link 0 and virtual link 1 can be determined as the target virtual links.

[0189] In another alternative embodiment, the virtual link with the largest path delay can be identified as the target virtual link. For example, if virtual link 0 has the largest path delay, then virtual link 0 can be identified as the target virtual link.

[0190] If the path latency of any target virtual link is high, it indicates that the original physical link corresponding to the target virtual link is overloaded. Therefore, the path value of the target virtual link can be updated to switch the target virtual link from the original physical link to the new physical link, thereby reducing the load on the original physical link and achieving load balancing across multiple physical links.

[0191] Since any virtual link has a corresponding path value, the data packets on that virtual link include the corresponding path value. The path value is used by network devices in the black-box network to hash the data packets and distribute them to various physical links. Therefore, the path value corresponding to the target virtual link can be updated to the target path value so that network devices in the black-box network can switch the target virtual link to a new physical link based on the target path value. That is, the data packets on the target virtual link are hashed and distributed to the new physical link until the load is balanced across multiple physical links (i.e., the path delay statistics are greater than or equal to the second path delay threshold and less than or equal to the first path delay threshold).

[0192] For example, if the target virtual link is virtual link 0, and the path value corresponding to virtual link 0 is 12, and the target path value is 27, then the path value of virtual link 0 can be updated to 27, so that the network device in the black box network can switch virtual link 0 to a new physical link according to the path value 27, thereby reducing the load on the original physical link and achieving load balancing processing for multiple physical links.

[0193] In this embodiment, the terminal device can obtain the response latency corresponding to the terminal device and the path latency of each virtual link in the multiple virtual links corresponding to the terminal device. It can then adjust the congestion window of the terminal device based on the response latency and perform load balancing on the multiple physical links corresponding to the multiple virtual links based on the path latency of each virtual link. Through the congestion control method of this disclosure, network congestion can be reduced, the overall utilization of physical links can be improved, and a healthy network state with low latency and high utilization can be achieved.

[0194] The congestion control algorithm described above will now be explained in detail based on the embodiment shown in Figure 4, in conjunction with Figures 6 and 7.

[0195] Figure 6 is a flowchart illustrating another congestion control method provided by an exemplary embodiment of this disclosure. Referring to Figure 6, the method may include:

[0196] S601. Obtain the response latency corresponding to the terminal device.

[0197] It should be noted that the execution process of step S601 can be found in step S401, and will not be repeated here.

[0198] S602. Adjust the congestion window of the terminal device according to the response delay.

[0199] In an optional embodiment, the congestion window of the terminal device can be adjusted according to the response delay in the following manner: a congestion control algorithm is determined; if the response delay is greater than the response delay threshold, the congestion window is reduced according to the congestion control algorithm to obtain the adjusted congestion window; if the response delay is less than or equal to the response delay threshold, the congestion window is increased according to the congestion control algorithm to obtain the adjusted congestion window.

[0200] The response delay can reflect the overall network congestion situation. Based on the response delay, the congestion window can be adjusted through congestion control algorithms to reduce network congestion and solve the above-mentioned problem 1.

[0201] For example, if the response latency is 100µs and the response latency threshold is 80µs, and the congestion window size is 90 bytes, then since the response latency exceeds the response latency threshold, it indicates network congestion. Therefore, according to the congestion control algorithm, the congestion window can be reduced to obtain an adjusted congestion window. Let's assume the adjusted congestion window size is 70 bytes.

[0202] For example, if the response latency is 20µs and the response latency threshold is 30µs, and the congestion window size is 50 bytes, then since the response latency is less than the response latency threshold, it indicates that the network is good. Therefore, according to the congestion control algorithm, the congestion window can be increased to obtain an adjusted congestion window. Let's assume the adjusted congestion window size is 80 bytes.

[0203] S603, Obtain the resource utilization rate of the target equipment.

[0204] Since the destination device needs to process data packets promptly after receiving them from the terminal device, the amount of data the terminal device can continuously send can also be referenced to the resource utilization rate of the destination device. When the resource utilization rate of the destination device is greater than a first preset threshold, it indicates that the destination device is unable to process the received data packets in a timely manner, and the amount of data continuously sent by the terminal device can be reduced. When the resource utilization rate of the destination device is less than a second preset threshold, it indicates that the destination device is able to process the received data packets in a timely manner, and the amount of data continuously sent by the terminal device can be increased.

[0205] Alternatively, resource utilization can be the utilization rate of the buffer in the destination device.

[0206] In an optional embodiment, the destination device may send a response message to the terminal device. This response message is the aforementioned confirmation message (i.e., an ACK confirmation message or a SACK confirmation message), and may include resource utilization information. The terminal device can obtain the resource utilization rate of the destination device from the response message.

[0207] In another optional embodiment, the destination device may send a resource utilization feedback message to the terminal device, the resource utilization feedback message including the resource utilization rate. The terminal device can obtain the resource utilization rate of the destination device from the resource utilization feedback message.

[0208] S604. Determine the congestion reference window based on resource utilization.

[0209] In an optional embodiment, the congestion reference window can be determined based on resource utilization in the following manner: an initial congestion reference window is determined; if the resource utilization is greater than or equal to a first preset threshold, the window reduction amount is determined according to a preset algorithm, and the initial congestion reference window is adjusted according to the window reduction amount to obtain the congestion reference window; if the resource utilization is less than a second preset threshold, the window increment is determined according to a preset algorithm, and the initial congestion reference window is adjusted according to the window increment to obtain the congestion reference window.

[0210] The initial congestion reference window can be preset manually based on experience.

[0211] Optionally, the window reduction amount or the window increment can be determined according to a preset algorithm, which can be referred to in relevant existing technologies and will not be elaborated here.

[0212] Alternatively, the size of the congestion reference window can be represented by the amount of data or by the number of packets.

[0213] For example, if the initial congestion reference window size is 80 bytes, the first preset threshold is 90%, the second preset threshold is 50%, and the resource utilization rate is 92%, since the resource utilization rate is greater than the first preset threshold, the window reduction amount can be determined according to the preset algorithm. Assuming the window reduction amount is determined to be 20 bytes according to the preset algorithm, the initial congestion reference window can be reduced to a size of 60 bytes. If the resource utilization rate is 45%, since the resource utilization rate is less than the second preset threshold, the window increment can be determined according to the preset algorithm. Assuming the window increment is determined to be 30 bytes according to the preset algorithm, the initial congestion reference window can be increased to a size of 110 bytes.

[0214] S605. Determine whether the adjusted congestion window is less than or equal to the congestion reference window.

[0215] If yes, then S606 can be executed; if no, then S607 can be executed.

[0216] S606. The adjusted congestion window is determined as the target congestion window.

[0217] For example, if the size of the adjusted congestion window is 70 bytes and the size of the congestion reference window is 110 bytes, since the adjusted congestion window is smaller than the congestion reference window, the adjusted congestion window can be determined as the target congestion window, that is, the size of the target congestion window is 70 bytes.

[0218] S607. Set the congestion reference window as the target congestion window.

[0219] For example, if the size of the adjusted congestion window is 70 bytes and the size of the congestion reference window is 60 bytes, since the adjusted congestion window is larger than the congestion reference window, the congestion reference window can be determined as the target congestion window, that is, the size of the target congestion window is 60 bytes.

[0220] It should be noted that the various processing steps (S601-S607) shown in the embodiment of FIG6 do not constitute a specific limitation on the congestion control process. In other embodiments of this disclosure, the congestion control process may include more or fewer steps than in the embodiment of FIG6. For example, the congestion control process may include some of the steps in the embodiment of FIG6, or some steps in the embodiment of FIG6 may be replaced by steps with the same function, or some steps in the embodiment of FIG6 may be split into multiple steps, etc.

[0221] In this embodiment, the terminal device can obtain the response latency corresponding to the terminal device and adjust the congestion window of the terminal device according to the response latency. The terminal device can obtain the resource utilization rate of the destination device and determine the congestion reference window according to the resource utilization rate. The terminal device can determine whether the adjusted congestion window is less than or equal to the congestion reference window. If so, the adjusted congestion window can be determined as the target congestion window; otherwise, the congestion reference window can be determined as the target congestion window. Through the congestion control process of this embodiment, the congestion window can be determined. When the terminal device sends data packets, it can send data packets according to the congestion window, avoiding the terminal device from continuously sending a large number of data packets, which would cause network congestion, thus reducing network congestion.

[0222] Figure 7 is a flowchart illustrating another congestion control method provided by an exemplary embodiment of this disclosure. Referring to Figure 7, the method may include:

[0223] S701. Obtain the path delay of each virtual link in the multiple virtual links corresponding to the terminal device.

[0224] In an optional embodiment, for any virtual link, the path delay of the virtual link can be obtained by: determining multiple data packets corresponding to the virtual link within the detection period; determining the round-trip time of transmission corresponding to any data packet; and determining the path delay of the virtual link within the detection period based on the round-trip time of transmission of each data packet among the multiple data packets.

[0225] Optionally, the terminal device can periodically acquire the path latency of each virtual link. Within a detection period, multiple data packets are transmitted through the virtual links, thus allowing the determination of the multiple data packets corresponding to each virtual link within the detection period.

[0226] For any given data packet, the round-trip time can be determined as follows: receive the response message corresponding to the data packet and determine the response reception time; determine the round-trip time corresponding to the data packet based on the response reception time and the data packet sending time; determine the processing time corresponding to the data packet based on the response sending time and the data packet receiving time; and determine the difference between the round-trip time and the processing time as the transmission round-trip time.

[0227] For any given data packet, there is a corresponding response message. The response message can be an ACK acknowledgment message. The response message includes the time the data packet was sent, the time the data packet was received, and the time the response was sent.

[0228] The response sending time refers to the moment when the destination device sends the response message corresponding to the data packet to the terminal device.

[0229] The terminal device can determine the timing of receiving the response message.

[0230] The following explanation, with reference to Figure 8, will cover the four moments mentioned above.

[0231] Figure 8 is a schematic diagram illustrating the data packet transmission time, data packet reception time, response transmission time, and response reception time provided in an exemplary embodiment of this disclosure. Referring to Figure 8, the time when the terminal device sends a data packet to the destination device, i.e., the data packet transmission time, can be represented by T1; the time when the destination device receives the data packet, i.e., the data packet reception time, can be represented by T2; after receiving the data packet, the destination device needs to process the data packet and then send a response message corresponding to the data packet to the terminal device. The time when the destination device sends the response message to the terminal device, i.e., the response transmission time, can be represented by T3; the response reception time when the terminal device receives the response message can be represented by T4.

[0232] The round-trip time (RTT) for a data packet is equal to the time difference between the response reception time and the data packet transmission time, i.e., the RTT for a data packet = T4 - T1.

[0233] The processing time for a data packet is equal to the time difference between the response sending time and the data packet receiving time, that is, the processing time for a data packet is T3-T2.

[0234] The round-trip time for a data packet is equal to the difference between the round-trip time and the processing time, which can be expressed by formula (1): NRTT=(T4-T1)-(T3-T2) Formula (1)

[0235] For any data packet, the terminal device can calculate the round-trip time of the data packet using formula (1).

[0236] By subtracting the processing time consumed at the destination device from the round-trip time, the transmission round-trip time in the network is obtained. The path delay is determined based on the transmission round-trip time, which can improve the identification of path queuing detection (i.e., improve the accuracy of path delay determination).

[0237] After determining the round-trip time (RTT) for each data packet, the path delay of any virtual link within the detection period can be determined as follows, based on the RTT for each data packet: Identify the current data packet from among multiple data packets and determine its current RTT; determine the historical path delay of the virtual link; determine the first product of the current RTT and the first weight, and the second product of the historical path delay and the second weight; and determine the path delay of the virtual link by summing the first and second products.

[0238] Historical path latency is determined based on the round-trip time of transmission of multiple historical data packets preceding the current data packet.

[0239] Optionally, the first weight can be represented by α, and the second weight can be represented by β. The first and second weights can be preset by humans.

[0240] If the current data packet is the i-th data packet within the detection period, then the current round-trip time corresponding to the i-th data packet can be represented as NRTT. i Historical path delay can be expressed as If the path delay corresponding to the virtual link obtained in the i-th calculation can be expressed as... but It can be calculated using the following formula (2):

[0241] Where i can take the values ​​1, 2, ..., S in sequence, and S represents the number of data packets within the detection period. S is an integer greater than or equal to 1.

[0242] It should be noted that when i equals 1, the current data packet is the first data packet within the detection period. Since there are no historical data packets before the first data packet, therefore... It is 0, that is (α equals 1);

[0243] When i is not equal to 1, the sum of α and β can be equal to 1.

[0244] When i equals S This refers to the path delay of the virtual link within the detection period.

[0245] For example, if for virtual link 0, 10 data packets are transmitted during the detection period, namely data packet 1, data packet 2, ..., data packet 10, then S equals 10, and i can take the values ​​1, 2, ..., 10. If α is 0.8 and β is 0.2, then when data packet 1 is transmitted, the virtual link 0's... NRTT equal to packet 1 1 When transmitting data packet 2, virtual link 0... When data packet 3 is transmitted, virtual link 0... ...; when transmitting data packet 10, virtual link 0... Then you can The path delay is determined to be virtual link 0.

[0246] Formula (2) can be used to smooth the path delay of the virtual link, eliminate interference from other factors, and obtain a more reliable and contoured path delay, thereby improving the accuracy of determining the path delay of the virtual link.

[0247] The terminal device can calculate the path delay of each virtual link using formula (2). For example, if there are 64 virtual links, the terminal device obtains the path delay of each of the 64 virtual links as shown in Table 2.

[0248] S702. Determine the path delay statistics based on the path delay of each virtual link.

[0249] Path delay statistics can be used to characterize the degree of difference in path delay among virtual links.

[0250] For example, if there are 64 virtual links, and the path delay of each virtual link is as shown in Table 2, and if the path delay statistics are the standard deviation, then the path delay statistics can be determined to be 112 based on the path delay of each virtual link.

[0251] S703. If the path delay statistics value is greater than the first path delay threshold or less than the second path delay threshold, then the target virtual link is determined among multiple virtual links.

[0252] For example, if the first path delay threshold is 60 and the path delay statistics value is 112, since the path delay statistics value is greater than the first path delay threshold, the target virtual link can be determined from multiple virtual links. If the preset duration is 100µs, then as shown in Table 2, virtual link 0 and virtual link 1 can be determined as the target virtual link.

[0253] For example, if the second path delay threshold is 2 and the path delay statistic is 0.5, since the path delay statistic is less than the second path delay threshold, the target virtual link can be determined from multiple virtual links. Let's assume the target virtual link can be virtual link 1.

[0254] S704. For any target virtual link, generate the target path value.

[0255] Optionally, the terminal device can generate the target path value randomly; the terminal device can also generate the target path value according to preset rules.

[0256] S705. Determine whether the usage status of the target path value is unused.

[0257] If not, proceed to step S704 to regenerate the target path value; if yes, proceed to step S706.

[0258] Optionally, the terminal device may include a path value bitmap, which contains multiple bits. The path value bitmap can be used to determine whether the target path value is in an unused state.

[0259] The path value bitmap will now be explained with reference to Figure 9.

[0260] Figure 9 is a schematic diagram of a path value bitmap provided in an exemplary embodiment of this disclosure. Referring to Figure 9, if the range of the path value is [0, 255], then the path value may include 256 bits, namely bit 0, ..., bit 255.

[0261] For any given bit, the path value corresponding to that bit can be the same as the bit's index. For example, the path value corresponding to bit 0 can be "0", the path value corresponding to bit 1 can be "1", and so on, the path value corresponding to bit 255 can be "255".

[0262] Any bit can be used to indicate the usage status of the path value corresponding to that bit.

[0263] For example, if the bit corresponding to a bit is the first value (e.g., 0), it can be used to indicate that the path value corresponding to that bit is in an unused state; if the bit corresponding to a bit is the second value (e.g., 1), it can be used to indicate that the path value corresponding to that bit is in a used state.

[0264] As shown in Figure 9, if the bit corresponding to bit 0 is "1", it means that the path value "0" is in the used state.

[0265] By using a path value bitmap, it can be ensured that the path values ​​corresponding to each virtual link are different, which helps to improve the dispersion of each virtual link across multiple physical links.

[0266] In an optional embodiment, the usage status of the target path value can be determined as follows: in the path value bitmap, the target bit corresponding to the target path value is determined; if the target bit is a first value, the usage status of the target path value is determined to be unused; if the target bit is a second value, the usage status of the target path value is determined to be used.

[0267] The target bit can be the bit corresponding to the target bit position. The target bit position refers to the bit position corresponding to the target path value in the path value bitmap.

[0268] If the terminal device determines that the target path value is in a used state, it means that the target path value can no longer be used (cannot be reused). The terminal device can then execute step S704 to regenerate the target path value.

[0269] For example, if the path value bitmap is as shown in Figure 9, and the target virtual link is virtual link 1, and the target path value generated by the terminal device is 3, then the terminal device can determine the target bit corresponding to the target path value 3 as the bit corresponding to bit 3 in the path value bitmap. Since the bit corresponding to bit 3 is 1, it indicates that the target path value 3 is in a used state, and step S704 can be executed. For example, the terminal device can regenerate the target path value as 254.

[0270] If the terminal device determines that the target path value is in an unused state, it can execute step S706 to update the path value corresponding to the target virtual link to the target path value.

[0271] If the target path value generated by the terminal device is 254, the terminal device can determine the target bit corresponding to the target path value 254 as the bit corresponding to bit 254 in the path value bitmap. Since the bit corresponding to bit 254 is 0, it indicates that the target path value 254 is in a used state, and step S706 can be executed.

[0272] S706. Update the path value corresponding to the target virtual link to the target path value to switch the target virtual link from the original physical link to the new physical link, until the load balance of multiple physical links is achieved.

[0273] For example, if the target path value generated by the terminal device is 254, and the usage status of the target path value 254 is unused, the terminal device can update the path value corresponding to virtual link 1 to 254, so that the network device in the black box network can switch virtual link 1 to the new physical link according to the path value 254, reduce the load on the original physical link, and achieve load balancing processing for multiple physical links.

[0274] It should be noted that in a black-box network, network devices randomly hash and assign virtual links to physical links based on path values. Each physical link can correspond to multiple virtual links, and the exact number of physical links in the black-box network is unknown. Therefore, for any given virtual link, it is also unknown which specific physical link the network device will randomly assign it to based on the path value. After the terminal device updates the path value corresponding to the target virtual link to the target path value, the network device randomly assigns the target virtual link based on the target path value, which may result in the following three scenarios:

[0275] Scenario 1: Randomly assign the target virtual link to a new physical link with a lower load.

[0276] In this scenario, the target virtual link can successfully switch from the original physical link with a heavier load to the new physical link with a lighter load, thus balancing the load between the original and new physical links.

[0277] Scenario 2: Randomly assign the target virtual link to a new physical link with a higher load.

[0278] In this case, the new physical link itself is already heavily loaded. Switching the target virtual link to the new physical link will increase the load on the new physical link, thus failing to achieve load balancing.

[0279] Scenario 3: Randomly assign the target virtual link to the original physical link.

[0280] In this case, the target virtual link is randomly assigned to the original physical link, thus failing to achieve load balancing.

[0281] For cases 2 and 3 above, the load on each physical link is still unbalanced. Therefore, steps S701 to S706 can be executed periodically multiple times until the path delay statistics are greater than or equal to the second path delay threshold and less than or equal to the first path delay threshold. This indicates that the load on each virtual link is balanced, and thus the load on each physical link is also balanced.

[0282] It should be noted that the various processing steps (S701-S706) shown in the embodiment of FIG7 do not constitute a specific limitation on the congestion control process. In other embodiments of this disclosure, the congestion control process may include more or fewer steps than in the embodiment of FIG7. For example, the congestion control process may include some of the steps in the embodiment of FIG7, or some steps in the embodiment of FIG7 may be replaced by steps with the same function, or some steps in the embodiment of FIG7 may be split into multiple steps, etc.

[0283] Optionally, between any two updates to the path value of the target virtual link, W preset intervals can be randomly added to avoid redistributing the target virtual link too frequently. Here, W is an integer greater than or equal to 1.

[0284] In this embodiment, the terminal device can obtain the path delay of each virtual link among multiple virtual links corresponding to the terminal device, and determine the path delay statistics based on the path delay of each virtual link. If the path delay statistics are greater than a first path delay threshold or less than a second path delay threshold, the terminal device can determine a target virtual link among the multiple virtual links. For any target virtual link, the terminal device can generate a target path value and determine whether the usage status of the target path value is unused. If so, the path value corresponding to the target virtual link is updated to the target path value to switch the target virtual link from the original physical link to the new physical link, until the load is balanced across multiple physical links. Through the congestion control method of this disclosure, load balancing processing of multiple physical links can be achieved without paying attention to the network topology, improving the overall utilization of multiple physical links, reducing network congestion, and achieving a healthy network state with low latency and high utilization.

[0285] It should be noted that the process in Figure 6 can be the process of implementing a congestion control strategy, and the process in Figure 7 can be the process of implementing a load balancing strategy. The congestion control processes shown in the embodiments of Figures 6 and 7 can be executed simultaneously to reduce network congestion, achieve load balancing of each physical link, and thus maintain a healthy network state with low latency and high utilization.

[0286] Optionally, in order to maintain a healthy network state with low latency, high utilization, and load balancing, in addition to executing the congestion control methods shown in Figures 6 and 7, the terminal device can also execute packet loss detection strategy and equal-weight link scheduling strategy; the destination device can also perform out-of-order submission and order-preserving completion.

[0287] The following explains the packet loss detection strategy, the equal-weighted link scheduling strategy, and out-of-order submission and order-preserving completion:

[0288] (1) Packet loss detection strategy:

[0289] In single-link transmission, packet loss is considered to have occurred if data packets arrive out of order. However, in multi-path transmission, data packets naturally arrive out of order, so it is necessary to identify which data packets have been lost and which are still in transit and will arrive later.

[0290] Lost data packets need to be retransmitted; data packets in transit do not need to be retransmitted. Terminal devices can use packet loss detection algorithms to identify which data packets have been lost.

[0291] Optionally, the terminal device may include an out-of-order window. The size of the out-of-order window can be represented by its duration.

[0292] Ideally, the out-of-order window can be expressed as: Out-of-order window = Response delay + Out-of-order duration. Since the time it takes for any packet to arrive out of order is less than 1 response delay, after simplification, we can consider the out-of-order window to be 2 * Response delay.

[0293] However, in reality, queuing is common on the destination device and the black-box network. The queuing delay of data packets may exceed the value of out-of-order window = 2 * response delay. Therefore, a correction value needs to be added to this value. Finally, the out-of-order window can be simplified to: out-of-order window = a + b * response delay, where b can be 2.

[0294] The packet loss detection process will now be explained with reference to Figure 10.

[0295] Figure 10 is a schematic diagram of a data packet transmission sequence provided by an exemplary embodiment of this disclosure. Referring to Figure 10, it includes 8 data packets and 1 response message.

[0296] The order in which these 8 data packets are sent from morning to night can be: data packet 0, data packet 1, data packet 2, data packet 3, data packet 4, data packet 5, data packet 6, and data packet 7.

[0297] For any given data packet, there is a corresponding transmission time. For example, data packet 0 is transmitted at time t0, data packet 1 at time t1, ..., and data packet 7 at time t7.

[0298] If the terminal device receives a response message corresponding to data packet 5 at the current moment, then the reception time of the response message is tc. Optionally, the response message can be an ACK acknowledgment message or a SACK acknowledgment message.

[0299] Terminal devices can record the sending time of each data packet for subsequent packet loss detection and rapid retransmission.

[0300] The terminal device can receive a response message, which may include acknowledgment information for at least one data packet. The moment the terminal device receives the response message is the current moment.

[0301] The terminal device can determine the out-of-order window. The out-of-order window represents the maximum time the terminal device is willing to wait.

[0302] For any given data packet, the terminal device can calculate the time difference between the packet's transmission time and reception time tc. If this time difference is greater than the out-of-order window, the data packet is determined to have been lost; if the time difference is less than the out-of-order window, the data packet is determined to still be in transmission.

[0303] For example, if the terminal device receives a response message to confirm that data packet 5 has been received, the terminal device can identify each data packet preceding data packet 5. For data packet 0, the terminal device can determine whether the time difference between t0 and tc is greater than the out-of-order window. If it is, it means that data packet 0 has been lost; ...; For data packet 3, the terminal device can determine whether the time difference between t3 and tc is greater than the out-of-order window. If it is less, it means that data packet 3 is still in transmission; For data packet 4, the terminal device can determine whether the time difference between t4 and tc is greater than the out-of-order window. If it is less, it means that data packet 4 is still in transmission.

[0304] Since the response message corresponding to data packet 5 has just been received at the current moment, data packets 6 and 7 may still be in transmission. Therefore, at the current moment, there is no need to identify whether data packets 6 and 7 have been lost.

[0305] If the terminal device determines that a data packet has been lost, it can retransmit the data packet.

[0306] Additionally, when the inflight converges to the BDP position, it is recommended to implement the SACK mechanism in the packet loss detection strategy to maintain the inflight statistics at the current moment, including: retransmission segment statistics, packet loss segment statistics, etc.

[0307] (2) Equal weight link scheduling strategy:

[0308] In multiple virtual links, the weights of each virtual link can be equal. The terminal device can determine the link order of multiple virtual links and allocate data packets to each virtual link sequentially according to the link order, thus ensuring that the data flow is evenly distributed across all virtual links. If Dynamic Weighted Round Robin (DWRR) is used for scheduling, significant skew in data packet allocation may occur, with some virtual links receiving more data packets than others. This can cause elephant stream hash collisions in the black-box network, resulting in low physical link utilization and physical link congestion, leading to low network utilization and poor load balancing. In extreme cases, convergence may occur towards a single physical link.

[0309] By adopting an equal-weighted link scheduling strategy, we can avoid switching convergence time when there is sudden congestion or link failure, while also constraining some virtual links from experiencing sudden congestion on the black-box network due to large traffic.

[0310] (3) Out-of-order submission and order-preserving completion:

[0311] When multiple physical links are used for transmission, data packets are transmitted to the destination device from different physical links. The order in which the data packets arrive at the destination device will inevitably differ from the original order in which they were sent, resulting in out-of-order delivery. If the destination device buffers and sorts the out-of-order data packets, it requires a large amount of memory resources for buffering. In addition to increased costs, the extreme waste of buffering resources may lead to performance degradation. If the packets are discarded directly, they need to be retransmitted for recovery, resulting in wasted computing power. Furthermore, gaps in the retransmission recovery process will reduce transmission efficiency. Therefore, if the destination device has the ability to process out-of-order packets, it can carry the destination storage information in the data packets and process the received packets indiscriminately, thus successfully solving the aforementioned "cost" and "performance" problems.

[0312] Destination storage information may include the destination storage address of the data packet in the destination device. Optionally, for any given data packet, the destination storage address may be pre-negotiated between the destination device and the terminal device. When the terminal device sends a data packet, the data packet may include the destination storage information.

[0313] Out-of-order delivery refers to the process by which the destination device, after receiving a data packet, can store the data packet at a pre-prepared target location based on the destination storage information in the data packet, regardless of the order in which the data packets arrived.

[0314] Order-preserving completion means that after all the preceding in-order data packets have arrived in succession, a completion message is sent to notify the application to process it.

[0315] For example, if there are 3 data packets, and the order in which the data packets are sent is: data packet 1, data packet 2, data packet 3, if the destination device receives data packet 2 first and then data packet 3, it needs to wait for data packet 3 to arrive before submitting the completion message.

[0316] Optionally, if the destination device cannot consume other out-of-order data packets before the arrival of the normally ordered data packets, the destination device can record hole information. Hole information is used to indicate data packets that have not yet arrived.

[0317] For example, in the above example, when data packets 2 and 3 arrive but data packet 1 has not yet arrived, the destination device can record hole information 1, which indicates that data packet 1 has not yet arrived.

[0318] In the technical solution disclosed herein, congestion control and load balancing strategies can operate simultaneously, are orthogonal to each other, and do not interfere with each other. With the combined effect of these two strategies, supplemented by packet loss detection, equal-weighted link scheduling, and out-of-order submission and order-preserving completion, a network state characterized by high bandwidth, low latency, high fairness, and low jitter can be achieved.

[0319] Figure 11 is a schematic diagram of a congestion control device provided in an embodiment of this disclosure. Referring to Figure 11, the congestion control device 10 includes: a first acquisition module 11, a second acquisition module 12, an adjustment module 13, and a leveling processing module 14, wherein...

[0320] The first acquisition module 11 is used to acquire the response delay corresponding to the terminal device, wherein the response delay is the duration between the update time of the pending confirmation pointer and the current time, and the pending confirmation pointer points to the sequence number of the first byte that the terminal device has sent but has not yet received a confirmation message.

[0321] The second acquisition module 12 is used to acquire the path delay of each virtual link in the multiple virtual links corresponding to the terminal device. The path delay is determined based on the round-trip transmission time of multiple data packets on the virtual link.

[0322] The adjustment module 13 is used to adjust the congestion window of the terminal device according to the response delay;

[0323] The load balancing module 14 is used to perform load balancing on the multiple physical links corresponding to the multiple virtual links according to the path delay of each virtual link, and the congestion window is used to indicate the maximum amount of data that the terminal device can continuously send.

[0324] The congestion control device provided in this disclosure can execute the technical solution shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0325] In one possible implementation, the equalization processing module 14 is specifically used for:

[0326] Based on the path delay of each virtual link, a path delay statistical value is determined, which is used to characterize the degree of difference in path delay among the virtual links;

[0327] If the path delay statistics value is greater than the first path delay threshold or less than the second path delay threshold, then a target virtual link is determined among the multiple virtual links. The path delay of the target virtual link is greater than a preset duration, and the first path delay threshold is greater than the second path delay threshold.

[0328] Update the path value of the target virtual link to switch the target virtual link from the original physical link to the new physical link, until the load balancing of the multiple physical links is achieved.

[0329] In one possible implementation, the equalization processing module 14 is specifically used for:

[0330] Generate target path value;

[0331] Determine whether the usage status of the target path value is unused;

[0332] When it is determined that the usage status of the target path value is unused, the path value corresponding to the target virtual link is updated to the target path value.

[0333] In one possible implementation, the terminal device includes a path value bitmap, which comprises multiple bits; the equalization processing module 14 is specifically used for:

[0334] In the path value bitmap, the target bit corresponding to the target path value is determined;

[0335] If the target bit is the first value, then the usage status of the target path value is determined to be unused.

[0336] If the target bit is the second value, then the usage status of the target path value is determined to be in the used state.

[0337] In one possible implementation, for any virtual link, the second acquisition module 12 is specifically used for:

[0338] Identify the multiple data packets corresponding to the virtual link within the detection period;

[0339] For any given data packet, determine the round-trip time corresponding to that data packet;

[0340] The path delay of the virtual link within the detection period is determined based on the round-trip time of each data packet in the plurality of data packets.

[0341] In one possible implementation, the second acquisition module 12 is specifically used for:

[0342] The current data packet is identified from the plurality of data packets, and the current round-trip time corresponding to the current data packet is determined.

[0343] The historical path delay corresponding to the virtual link is determined based on the round-trip time of the transmission of the historical data packets preceding the current data packet in the plurality of data packets;

[0344] Determine the first product of the current round-trip time and the first weight, and the second product of the historical path delay and the second weight;

[0345] The sum of the first product and the second product is determined as the path delay of the virtual link.

[0346] In one possible implementation, for any given data packet, the second acquisition module 12 is specifically used for:

[0347] Receive the response message corresponding to the data packet, and determine the response reception time of receiving the response message, wherein the response message includes the data packet sending time, the data packet receiving time, and the response sending time;

[0348] The round-trip time corresponding to the data packet is determined based on the response reception time and the data packet transmission time.

[0349] The processing time corresponding to the data packet is determined based on the response sending time and the data packet receiving time;

[0350] The difference between the round-trip time and the processing time is determined as the transmission round-trip time.

[0351] In one possible implementation, the adjustment module 13 is specifically used for:

[0352] Determine the congestion control algorithm;

[0353] If the response delay is greater than the response delay threshold, then according to the congestion control algorithm, the congestion window is reduced to obtain the adjusted congestion window;

[0354] If the response delay is less than or equal to the response delay threshold, then according to the congestion control algorithm, the congestion window is increased to obtain the adjusted congestion window.

[0355] The congestion control device provided in this disclosure can execute the technical solution shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0356] Figure 12 is a schematic diagram of another congestion control device provided in an exemplary embodiment of this disclosure. Referring to Figure 12, based on the embodiment shown in Figure 11, the congestion control device 10 may further include: a third acquisition module 15, a first determination module 16, and a second determination module 17, wherein...

[0357] The third acquisition module 15 is used to acquire the resource utilization rate of the target device;

[0358] The first determining module 16 is used to determine a congestion reference window based on the resource utilization rate;

[0359] The second determining module 17 is used to determine the adjusted congestion window as the target congestion window if the adjusted congestion window is less than or equal to the congestion reference window.

[0360] The second determining module 17 is used to determine the congestion reference window as the target congestion window if the adjusted congestion window is larger than the congestion reference window.

[0361] The congestion control device provided in this disclosure can execute the technical solution shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0362] Figure 13 is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present disclosure. Referring to Figure 13, the electronic device 20 may include a processor 21 and a memory 22. Exemplarily, the processor 21 and the memory 22 are interconnected via a bus 23.

[0363] The memory 22 stores computer-executed instructions;

[0364] The processor 21 executes the computer execution instructions stored in the memory 22, causing the processor 21 to perform the method as shown in the above method embodiment.

[0365] The electronic device shown in Figure 13 can be the terminal device or the target device described in any of the above embodiments.

[0366] Figure 14 is a schematic diagram of a congestion control system provided in an exemplary embodiment of this disclosure. Referring to Figure 14, the congestion control system may include at least one terminal device, at least one network device, and at least one destination device.

[0367] The terminal device is communicatively connected to some or all of the at least one network device, and the destination device is communicatively connected to some or all of the at least one network device.

[0368] If there are multiple network devices, then these multiple network devices can communicate with each other.

[0369] The terminal device is used to execute the congestion control method described in any of the above embodiments.

[0370] Accordingly, this disclosure provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the above-described method embodiments.

[0371] Accordingly, this disclosure also provides a computer program product, including a computer program, which, when executed by a processor, can implement the methods shown in the above method embodiments.

[0372] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0373] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0374] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0375] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0376] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0377] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0378] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0379] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0380] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A congestion control method in which, The method comprises the following steps: obtaining a response delay corresponding to a terminal device, the response delay being a time length between an update time of a to-be-confirmed pointer and a current time, the to-be-confirmed pointer pointing to a sequence number of a first byte that has been sent by the terminal device but for which an acknowledgement message has not been received; obtaining path delays of each virtual link in a plurality of virtual links corresponding to the terminal device, the path delay being determined according to transmission round-trip time lengths corresponding to a plurality of data packets on the virtual link; adjusting a congestion window of the terminal device according to the response delay, and performing load balancing processing on a plurality of physical links corresponding to the plurality of virtual links according to the path delays of the virtual links, the congestion window being used to indicate a maximum data amount that is continuously sent by the terminal device.

2. The method of claim 1, wherein, The load balancing processing on the plurality of physical links corresponding to the plurality of virtual links according to the path delays of the virtual links comprises: determining a path delay statistical value according to the path delays of the virtual links, the path delay statistical value being used to represent a difference degree of the path delays of the virtual links; if the path delay statistical value is greater than a first path delay threshold or less than a second path delay threshold, determining a target virtual link in the plurality of virtual links, the path delay of the target virtual link being greater than a preset time length, the first path delay threshold being greater than the second path delay threshold; updating a path value of the target virtual link to switch the target virtual link from an original physical link to a new physical link until the load balancing of the plurality of physical links is achieved.

3. The method of claim 2, wherein, The updating of the path value of the target virtual link comprises: generating a target path value; determining whether a use state of the target path value is an unused state; when it is determined that the use state of the target path value is the unused state, updating a path value corresponding to the target virtual link to the target path value.

4. The method of claim 3, wherein, The terminal device is provided with a path value bitmap, the path value bitmap comprising a plurality of bits; the determination of whether the use state of the target path value is the unused state comprises: determining a target bit corresponding to the target path value in the path value bitmap; if the target bit is a first numerical value, it is determined that the use state of the target path value is the unused state; if the target bit is a second numerical value, it is determined that the use state of the target path value is a used state.

5. The method according to any one of claims 1 to 4, wherein, For any one virtual link, the path delay of the virtual link is obtained by: determining a plurality of data packets corresponding to the virtual link in a detection period; for any one data packet, determining a transmission round-trip time length corresponding to the data packet; determining the path delay of the virtual link in the detection period according to the transmission round-trip time lengths corresponding to each data packet in the plurality of data packets.

6. The method of claim 5, wherein, The determination of the path delay of the virtual link in the detection period according to the transmission round-trip time lengths corresponding to each data packet in the plurality of data packets comprises: determining a current data packet in the plurality of data packets and a current transmission round-trip time length corresponding to the current data packet; determining a historical path delay corresponding to the virtual link, the historical path delay being determined according to a transmission round-trip time length corresponding to a plurality of historical data packets before the current data packet in the plurality of data packets; determining a first product of the current transmission round-trip time length and a first weight, and a second product of the historical path delay and a second weight; determining a sum of the first product and the second product as a path delay of the virtual link.

7. The method of claim 5 or 6, wherein, For any one data packet, determining a transmission round-trip time length corresponding to the data packet, comprising: receiving a response message corresponding to the data packet, and determining a response receiving time of receiving the response message, the response message including a data packet sending time, a data packet receiving time, and a response sending time; determining a round-trip time length corresponding to the data packet according to the response receiving time and the data packet sending time; determining a processing time length corresponding to the data packet according to the response sending time and the data packet receiving time; determining a difference between the round-trip time length and the processing time length as the transmission round-trip time length.

8. The method according to any one of claims 1 to 7, wherein, adjusting a congestion window of the terminal device according to the response delay, comprising: determining a congestion control algorithm; if the response delay is greater than a response delay threshold, then adjusting the congestion window according to the congestion control algorithm to obtain an adjusted congestion window; if the response delay is less than or equal to the response delay threshold, then adjusting the congestion window according to the congestion control algorithm to obtain an adjusted congestion window.

9. The method of claim 8, wherein, After adjusting the congestion window of the terminal device according to the response delay, the method further comprises: obtaining a resource utilization of a destination device, and determining a congestion reference window according to the resource utilization; if the adjusted congestion window is less than or equal to the congestion reference window, then determining the adjusted congestion window as a target congestion window; if the adjusted congestion window is greater than the congestion reference window, then determining the congestion reference window as the target congestion window.

10. A congestion control apparatus, wherein, The apparatus comprises a first obtaining module, a second obtaining module, an adjusting module, and a balancing processing module, wherein, the first obtaining module is configured to obtain a response delay corresponding to a terminal device, the response delay being a time length between an update time of a pending acknowledgement pointer and a current time, the pending acknowledgement pointer pointing to a sequence number of a first byte that has been sent by the terminal device but for which an acknowledgement message has not been received; the second obtaining module is configured to obtain path delays of respective virtual links in a plurality of virtual links corresponding to the terminal device, the path delays being determined according to transmission round-trip time lengths corresponding to a plurality of data packets on the virtual links; the adjusting module is configured to adjust a congestion window of the terminal device according to the response delay; the balancing processing module is configured to perform load balancing processing on a plurality of physical links corresponding to the plurality of virtual links according to the path delays of the respective virtual links, the congestion window being configured to indicate a maximum data amount that can be continuously sent by the terminal device. comprising:

11. A congestion control system wherein, at least one terminal device, at least one network device, and at least one destination device, wherein, ​ The terminal device is communicatively connected with some or all of the at least one network device; The destination device is communicatively connected with some or all of the at least one network device; The terminal device is configured to perform the method of any one of claims 1-9.

12. An electronic device, comprising: Comprise: At least one processor; And A memory communicatively connected with the at least one processor; Wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to cause the electronic device to perform the method of any one of claims 1-9.

13. A computer readable storage medium, wherein, The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the method of any one of claims 1-9 is implemented.

14. A computer program product comprising a computer program, wherein, The computer program is executed by the processor to implement the method of any one of claims 1-9.

Images